1.

264 Tema 2
Proceso de software
Estudio de caso: desarrollo rpido
Problemas:
Ofrecer mucho apoyo y desaparecer.
Se mencion el diseo de la interfaz pero no se realiz.
Juan aparece en el cuarto mes con nuevas ideas.
Pudo implementarlas tal como tena pensado?
Los integrantes del equipo trabajaron por separado.
Ante la implementacin visual, empezaron a integrar cdigo.
Comenzaron a las 14 horas del da anterior a la implementacin.
Las pruebas detectaron ms errores que los desarrolladores.
Desmoralizacin y transcurso de los meses. Juan fue el ltimo.
La interfaz del usuario cambi en el ltimo momento.
El proyecto se entreg un 50% despus de lo programado.
Dimensiones de la velocidad de desarrollo
Personas
Lo que ms importa: habilidades y motivacin.
Proceso
Centrado en el cliente.
Fundamentos, calidad, gestin de riesgo, plan de ciclo de vida.
El cdigo insufrible y el caos siguen siendo los enfoques
ms habituales.
Producto
Tamao y caractersticas, fases.
Tecnologa
Herramientas.
Prcticas de programacin
No basta con hacer ciertas cosas bien.
Lo importante es evitar hacer las cosas mal.
Adaptacin de Rapid Development: Taming Wild Software Schedules (McConnell 1996).
Estudio de caso: desarrollo rpido (2)
Prcticas recomendadas:
Aprovechamiento de otros proyectos. Atencin al personal
que alerta sobre posibles errores cometidos.
Seleccin de equipo para fundamentos (la gente es la clave).
Buenos requisitos y diseo, reduccin del trabajo.
Estimacin de gestin del riesgo en la programacin.
Utilizacin de herramientas adecuadas para la estimacin.
Gestin informada, ms recursos y tiempo.
Proceso de prototipo evolutivo: integracin temprana.
Diseo finalizado a los 6 meses, ms prototipos.
Primera versin funcional a los 8 meses, fecha lmite: 14 meses.
Entrega a tiempo en 14 con buena calidad.
Pequea diferencia temporal con respecto al estudio de caso 1
Ms recursos, mejor funcionalidad, ms calidad.
Estudio de caso: fundamentos de desarrollo
No hay una nica solucin.
Gestin: mejor estimacin, planificacin,
seguimiento.
Tcnico: requisitos ms estrictos, diseo,
gestin del desarrollo, control de calidad.
La versin 3 funcion porque se trataba del mismo
cdigo y el mismo equipo.
La capacidad del software del equipo era muy frgil: un solo
producto pensado para una sola cosa.
Esto puede dar una falsa sensacin de confianza al afrontar
un proyecto distinto.
Fundamentos tcnicos
Modelo de la espiral como base para el desarrollo.
Adaptacin de Rapid Development: Taming Wild Software Schedules (McConnell 1996).
Fundamentos de los requisitos
Requisitos: qu hace el sistema?
Lo que hacemos en los ejercicios de este semestre es
esencialmente un anlisis ampliado de los requisitos.
El ejercicio 1 es un estadio preliminar del anlisis de los
requisitos.
Anlisis mediante lenguaje de modelado unificado (UML).
Modelado de datos (diagramas entidad-relacin, se tratarn la
semana que viene) (estrictamente, no forma parte del UML).
Imagen esttica pero completa de todos los datos (u objetos) del
sistema.
Diagramas de clase.
Imagen esttica pero completa de las relaciones de todos los objetos.
Modelos secuenciales y colaboracin (diagrama de flujo de datos)
Vista dinmica de varios flujos de datos y de control en el sistema.
Modelos de estado (diagramas de transicin de estado).
Vista completa y dinmica de los valores y la lgica de los datos.
Diccionario de datos.
Fundamentos de diseo
Diseo: cmo funciona el sistema?
Diseo de objetos y base de datos (prxima semana)
Arquitectura de sistemas (durante el trimestre).
Subsistemas, capas/bibliotecas, comunicaciones.
Principios de diseo de sistemas.
Internacionalizacin, portabilidad, rendimiento, memoria
disponibilidad, fiabilidad, (tambin llamados requisitos
no funcionales).
Seleccin de herramientas: base de datos, middleware,
aplicacin, supervisin,
Fundamentos de desarrollo
Los requisitos y el diseo dictan el xito del
desarrollo.
El 60% de los defectos ya estn presentes en el diseo.
Prcticas de codificacin.
Anlisis unitario y prcticas de depuracin.
Estrategias de integracin: incrementales.
Ajuste y rendimiento del cdigo.
Herramientas CASE (ingeniera de software asistida).
Gestin de configuracin del software (Visual Source Safe,
otros).
UML.
Fundamentos de control de calidad
Anlisis.
El anlisis unitario detecta el 10-50% de los defectos.
El anlisis del sistema detecta el 20-60% de los defectos.
Las revisiones e inspecciones detectan un 60-90%: ms de errores
crticos que el anlisis.
Mdulos propensos a errores: identificacin y reescritura.
57% de errores en el 7% de los mdulos (IBM).
Si hay ms de 10 defectos por cada 1000 lneas de cdigo: reescribir.
El control de calidad se inicia al comienzo del proyecto.
Confirmacin de requisitos y revisiones.
Revisiones del diseo.
Inspecciones del cdigo: inspector, autor, copista.
Prevencin y eliminacin de defectos
Adaptacin de Rapid Development: Taming Wild Software Schedules (McConnell 1996).
Si, una vez completado, encuentra ms de un 5% de errores
tiene un serio problema.
Superpginas (Pginas amarillas digitales)
Superpginas
Prototipo Otoo 1994 sin produccin, muchos atajos
Decisin de publicacin Diciembre 1994
Fecha de lanzamiento de marketing: marzo 1995. Me convert en director en enero de 1995.
Equipo de servidores:
Creadores de prototipos, muy creativos, con fundamentos.
Base de datos de objetos, motor de recuperacin de texto, Netscape Commerce Server, C++
Diseo de produccin demasiado sofisticado (funciones C++ avanzadas), slo 2 personas fueron
capaces de crear el cdigo, y fueron los dos diseadores).
Horas interminables, presiones en la programacin, muchas quejas por parte de los 2 desarrolladores.
Los desarrolladores no tuvieron tiempo para escribir el diseo ni llevar a cabo revisiones.
Equipo de asistencia:
Al menos las empresas de telecomunicaciones saben que la asistencia es realmente importante.
Base de datos relacional, cdigo C, muy conservador.
El equipo tuvo que colaborar con desarrolladores junior; mucha enseanza y necesidad de revisiones.
Lanzamiento poco firme en abril de 1995:
Basado en cdigo prototipo: fallos frecuentes, mal rendimiento (aunque vlido durante el uso inicial).
El hardware no se instal a tiempo.
Enormes problemas de datos: los datos de las pginas amarillas digitales no eran idneos.
Reestructuracin del proyecto:
Se cambi el desarrollador de asistencia para guiar al equipo de servidores; el desarrollador con ms
experiencia se convirti en el jefe tcnico.
Se cambi el proyecto a un departamento.
Se transfirieron dos desarrolladores a otros proyectos.
Los diseadores de las interfaces de usuario eran muy temperamentales (psiclogos), pero muy maduros.
Imposibilidad de cambiar toda la arquitectura hasta julio de 1996:
Un ao de publicaciones trimestrales de funciones agregadas basadas en cdigo prototipo.
Aplicacin de proceso de requisitos, plan trimestral necesario, diseo rpido, aproximaciones de cdigo.
Ausencia de grupo de control de calidad; desarrolladores junior en control en servidores y asistencia.
Competencia: BigYellow (NYNEX: 20 PCs), BigBook (sin modelo empresarial, buena UI), otros
RBOC, empresas de directorio.
Estudio de caso: gestin del riesgo
Problemas:
Ausencia de planificacin del proyecto.
Ausencia de control y seguimiento (despus de 6 semanas
en un proyecto de tres meses).
Sndrome de la bala de plata: la subcontratacin lo arreglar
todo (y no es as).
Contratista irresponsable.
Estudio de caso 2: gestin del riesgo
Prcticas recomendadas:
Encargado del riesgo (uno mismo si es el encargado).
Anlisis de los problemas de cdigo (decisin de rescribir).
Creacin de prototipos para reducir riesgo de documentacin.
Implicacin del cliente para reducir riesgo de requisitos.
Requisitos flexibles para que el rendimiento se ajuste al programa.
Estudio de caso: seleccin del proceso de software
Problemas:
Prototipos como enfoque "ms rpido", sin tener en cuenta
el contexto.
Encargado inepto, consultor inepto (combinacin habitual).
Proceso de requisitos descontrolado.
Los agentes de campo llaman directamente al jefe tcnico para dar ideas.
Estudio de caso 2: seleccin del proceso de software
Prcticas recomendadas:
Tamao cuidado del proyecto, estimacin de recursos para
seleccionar el enfoque adecuado.
Modelo de desarrollo de la espiral para gestionar el riesgo.
Gestin del riesgo en requisitos, seleccin de personal,
seleccin del enfoque (seguro, pero con prioridad en el
diseo para evitar funciones arriesgadas).
Implementacin sencilla de la mayora de las funciones.