Tema 3: El Proceso Unificado de desarrollo de software. · El Proceso Unificado Introducción A...
Transcript of Tema 3: El Proceso Unificado de desarrollo de software. · El Proceso Unificado Introducción A...
Tema 3:
El Proceso Unificado de desarrollo de software. Ejemplo
Departamento de Lenguajes y Sistemas Informáticos II
www.kybele.urjc.es
El Proceso Unificado www.kybele.urjc.es
Introducción
A software development process for a team of one. Philippe Kruchten
El objetivo de un proceso software no es hacermiserables las vidas de los desarrolladores ni limitar la creatividad bajo montañas de documentación
Debe adaptarse al tamaño del proyecto y de la organización
El Proceso Unificado www.kybele.urjc.es
Introducción
Desarrollador: Nick, un ingeniero software con 12 años de experiencia
Sigue deliberadamente un proceso bien definido
Cliente: Gary, responsable de desarrollo software software en una pequeña empresa
Como parte de un esfuerzo para mejorar su eficiencia, están formando al personal en PSP (Personal Software Process)
3
El Proceso Unificado www.kybele.urjc.es
Sábado por la noche
Problema:
Como parte del PSP, los desarrolladores han de hacer un seguimiento del tiempo que dedican a cada actividad(requisitos, diseño, pruebas y gestión)
Diferentes estrategias de captura de datos: problema de recolección y consolidación de los datos. Necesidad de personal administrativo para realizar esta tarea de recolección de correos, notas, llamadas…
Realizar mediciones del esfuerzo en varias actividades esclave para control de productividad, identificar áreaspotenciales para mejora de procesos y mejora de planificación de proyectos
4
El Proceso Unificado www.kybele.urjc.es
Sábado por la noche
Propuesta:
Automatizar la tarea, utilizando un contador en la pantalla que los desarrolladores puedan activar, asociándolo a una tarea, interrumpirlotemporalmente, reactivarlo o cerrarlo al terminar la tarea
Datos almacenados de manera persistente, recuperándolos en una hoja de cálculo al final de la semana
Aceptado: reunión para el día siguiente
5
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
La propuesta:
Idea en la cabeza, reflejada en un “business case” (¿Qué voy a construir? ¿Cuántos recursos necesito? (personal, software) ¿Qué presupuesto voy a presentar?)
4 hojas:
Visión
Plan
Riesgos
Business Case
6
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Visión:
Describir, para desarrollador y cliente, qué esexactamente lo que queremos conseguir. Lo que el cliente está persiguiendo, qué aspecto tendrá la herramienta, y cómo se utilizará.
Todos debemos tener la misma visión
7
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Personal Timer Tool: VisiónProblema Para la organización de Gary, la dificultad de recopilar datos consistentes acerca del
tiempo dedicado a las diferentes actividades por parte de los desarrolladoresprovoca muchas dificultades relativas a estimación del progreso, facturación al cliente, pagos, estimación de proyectos futuros…
Descripción de la visión La herramienta PTT medirá el tiempo empleado y recopilará y almacenará estos
datos. Podrá ordenar y recuperar estos datos, realizar una evaluación sistemática y consistente del esfuerzo, compararlo con las estimaciones, y poder hacer mejoresestimaciones en proyectos futuros
Partes principales involucradas Desarrolladores individuales Asistente administrativo Gestores de proyectos
Casos de Uso Medir el tiempo para una actividad Extraer la hoja de tiempos semanal Consolidar datos para un proyecto Inicializar herramienta y base de datos para un proyecto
8
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
PlanEsbozar una planificación para los próximos días, identificandohitos principales (puntos en los hay que tomar una decisión, en solitario o junto a Gary)Necesario acuerdo con Gary para algún compromiso de suparte. Tendrá que dar su consentimiento a la Visión, el Plan y las estimaciones.Necesidad de Business Case privado que no verá Gary, detallando presupuesto necesario para el proyecto.Tras acuerdo en Visión, Plan y presupuesto, primer hito(LifeCycle Objective, LCO), cerrando la fase de InicioComo medio adicional para convencer a Gary, y también comocobertura para dificultades imprevistas: Pago únicamente por prototipo el martes por la tarde. Sólo entonces,
en caso de aceptar (y si es factible terminar el proyecto el viernes), se solicita compromiso para la cantidad total.
9
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Plan9:30 a.m. No es necesaria una herramienta de planificación para hacer un gráfico tipo GANNT, pero sí al menos un plan que permita descomponer en fases.Incorporado a agenda electrónica:
10
Lunes Martes Miércoles Jueves Viernes Sábado
INICIOVisiónPlanCaso de NegocioRiesgos
PrototipoMitigar riesgos
CONSTRUCCIÓNDiseñoCodificaciónPruebas
DiseñoCodificaciónPruebas
LCO: OK de Gary LCA: OK de Gary IOC: mostrar versión beta
ELABORACIÓNPrototipo
Pruebas casos de uso
DiseñoCodificaciónPruebas
TRANSICIÓNMejoras?
Entrega
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
PlanINICIO/CONCEPCIÓN El objetivo es conseguir el compromiso para el prototipo. Si no se
consigue, fin.
ELABORACIÓN Aproximadamente hasta martes a mediodía. El prototipo permitirá
avanzar en los requisitos, la solución y el plan y en explorar algunasideas. Todo lo tendrá que validar Gary. El prototipo permitirá:
• Algo concreto que mostrar a Gary para conseguir feedback (req)
• Para el desarrollador: dispone de lo necesario para hacer el prototipo (sw, ideas de reutilización de cosas hechas, probar si funciona en su SO…)
• Refinar plan y calendario
• Punto de inicio para comenzar la aplicación real
• Oportunidad de reciclar algunos conocimientos olvidados
Hito LCA (Lifecycle Architecture) -> Decidir si parar o seguir (o cambiar)
11
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Plan
CONSTRUCCIÓN
Si Gary da su aprobación, el miércoles empezaría la construcción del sistema real
Gary y un programador, con su máquina, para probar(jueves)
Por la tarde podría arreglar lo que no les guste
Hito Initial Operational Capability (IOC): primera vez queusuarios reales prueban el software
TRANSICIÓN
Un par de horas, versión final, facturar
12
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Riesgos
No evitarlos, sino anotarlos.
Cualquier cosa que pueda hacer fracasar, retrasar o aumentar el presupuesto
Dinámicos (cambian)
Licencia para las herramientas de desarrollo han expirado
Base de datos muy cara
Soporte a la comunicación entre los nodos en la organización
Algún ordenador no conectado a la red
13
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
Business CaseDocumento interno.
Cuatro días de trabajo
¿Actualizar herramientas (BD, entorno de programación)?: TBD
Trato razonable
Argumentos convincentes: business case desde su perspectiva: Si ahorra media hora semanal por programador y dos horas
administrativas (entrada y consolidación de datos): recuperar la inversión en < 6 meses
Posibilidad de venta a otros compartiendo beneficios con Gary: a detallar
14
El Proceso Unificado www.kybele.urjc.es
Lunes por la mañana
La arquitectura
+ algunos otros modelos UML
15
El Proceso Unificado www.kybele.urjc.es
Lunes comida
El compromiso
Aceptación
Modificación de los requisitos:
Acumular datos en una BD única, conectados por la red:• No datos almacenados individuales porque no es tan fácil mezclar
los datos
• No siempre trabajan en la misma máquina, especialmente durante las pruebas
• -> riesgo de la red
Pequeños retoques a requisitos
Necesidad de administrador para mantener la BD
16
El Proceso Unificado www.kybele.urjc.es
Lunes comida
Visión, II
Cambios en la Visión:
Red
Ideas para desarrollo futuro (pueden afectar al diseño actual)
Plan, II
Para mitigar el riesgo de la arquitectura, traslado LCA a jueves cena
Construcción dos días, uno versión local otra versión red
Transición viernes, entrega final viernes tarde. Viernes mañana versión beta in situ.
17
El Proceso Unificado www.kybele.urjc.es
Lunes comida
Plan, II
18
Lunes Martes Miércoles Jueves Viernes Sábado
INICIOVisiónPlanCaso de NegocioRiesgos
PrototipoMitigar riesgos
CONSTRUCCIÓNLocalDiseñoCodificaciónPruebas
CONSTRUCCIÓNCliente-ServidorDiseñoCodificaciónPruebas
TRANSICIÓNMejoras?
IOC: mostrar versión beta
LCO: OK de Gary
ELABORACIÓNPrototipo
LCA: OK de GaryPruebas casos de uso
DiseñoCodificaciónPruebas
DiseñoCodificaciónPruebas
Entrega
El Proceso Unificado www.kybele.urjc.es
Lunes comida
Riesgos, II
Nuevos:
Sincronización de actualizaciones a la BD
Consistencia de actividades, proyectos y usuarios usando máquinas diferentes
Políticas de acceso para administrador y usuarios normales
Uso de dos máquinas: ¿puede ocurrir? ¿Consecuencias?
Problemas de bloqueo por posible caída de una conexión
19
El Proceso Unificado www.kybele.urjc.es
Lunes comida
Business Case, II
Aumenta la estimación
Retorno de la inversión en 8’5 meses
Gary quiere pagar 2/5 tras LCA martes noche, envía autorización por correo
20
El Proceso Unificado www.kybele.urjc.es
Lunes tarde
ProfundizandoDetalle de los casos de uso principales: Contar una actividad
Recuento de los datos
Expandirlos y construir unos diagramas de secuencia
Boceto del contador, usando algunas clases
21
El Proceso Unificado www.kybele.urjc.es
Lunes tarde
ProfundizandoMás detalles, a consultar: ¿La lista de actividades es predefinida y estática?
¿Pueden los desarrolladores crear listas?
…
Finalmente, un applet, que escribe en un txt:
22
El Proceso Unificado www.kybele.urjc.es
Martes
Progreso:Desaparecen algunos riesgos y aparecen otros Problema con la versión del software trabajando con la BD
Surgen muchos pequeños problemas técnicos
UML: Un diagrama de clases y dos de colaboración
Un diagrama de componentes basado en la arquitectura
Reordenación de la lista de riesgos
Nuevas restricciones a la Visión: La aplicación debe funcionar en Win NT y Unix
Base de datos sobre Win NT 4.0 o superior
Retoques en casos de uso
23
El Proceso Unificado www.kybele.urjc.es
Martes
Progreso:Prototipo con Gary y Eric (un usuario y una actividad)
DB y Applet en máquinas diferentes
Prototipo explota
Retoque del prototipo
Responder a preguntas anotadas Problema:
• Caída mientras el contador en marcha
Un par de cambios a la lista de riesgos, y algunos nuevos casos de uso para el administrador Limpiar BD; Añadir usuario; Limpiar lista de actividades
Ok LCA
24
El Proceso Unificado www.kybele.urjc.es
Miércoles
Progreso y más cambiosSolución al problema de la caída mientras contador en marcha
Uso de herramienta de gestión de configuración para guardar las versiones: una por iteración
Completar lista de pruebas a partir de casos de uso
Trabajo de extracción, ordenación y presentación de datos para usarlos en Excel
Aparece un nuevo requisito: Una persona puede estar trabajando en más de una
actividad y necesita varios contadores a la vez• Cambios en la Visión y en la lista de Riesgos
25
El Proceso Unificado www.kybele.urjc.es
Jueves
TerminandoCambios: el nuevo requisito a cambio de uno antiguo Actividad + proyecto es obligatorio porque muchos
empleados trabajan en varios proyectos
Guía de usuario en HTML basada en casos de uso
Reorganizando las solicitudes de cambio y algunas ideas para mejoras
Diversas pruebas: Capacidad
Concurrencia: error en actualización de usuario + actividad + proyecto a la vez
Finalmente, prácticamente todo funciona
26
El Proceso Unificado www.kybele.urjc.es
Viernes
Versión beta y distribución
Instalación en varias máquinas en cliente
Recogiendo algunas sugerencias
2 errores importantes y 12 menores
Corrección de todo excepto algún error menor
Detección por medio de pruebas sistemáticas de algún otro error
Versión finalizada
27
El Proceso Unificado www.kybele.urjc.es
Conclusiones
Mucha importancia a los riesgos:Técnicos (tecnologías, lenguajes, interfaces…)
De negocio (planificación, gastos, expectativas…)
Proceso iterativo para intentar mitigar los riesgos (ideas para evitarlos, feedback del cliente)
Plan con hitos claros, a pesar de proyecto corto
Business case con estimaciones claras de gastos e ingresos previstos. Modificaciones continuas
Diseño, comenzando con una arquitectura muy temprana. Detalle de diseño en áreas más problemáticas
28
El Proceso Unificado www.kybele.urjc.es
Conclusiones
Mucha importancia a comprensión mutua de necesidades
No asumir las necesidades del cliente
Requisitos, características, restricciones...
Validar varias veces que los dos comparten la Visión
Esfuerzo en las tareas más prioritariasNo dejar de lado nada
Gestión de solicitud de cambios (prioridades):Debidos a problemas o nuevos requisitos
Casos de prueba basados en los requisitos Se van mejorando a medida que avanza el desarrollo
29
El Proceso Unificado www.kybele.urjc.es
Conclusiones
Gestión de la configuraciónMantiene versiones
Evita problemas debido a errores o accidentes
Permite volver a versión previa
Documentación de usuarioVersión, instalación, limitaciones
Guía de usuario
Pequeño pero suficiente número de artefactos y productos:
Herramientas
Facilidad de afrontar versión 2
30