Tema 3:

El Proceso Unificado de desarrollo de software. Ejemplo Departamento de Lenguajes y Sistemas Informáticos II 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 hacer miserables 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)

El Proceso Unificado

www.kybele.urjc.es

3

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 es clave para control de productividad, identificar áreas potenciales para mejora de procesos y mejora de planificación de proyectos

El Proceso Unificado

www.kybele.urjc.es

4

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, interrumpirlo temporalmente, 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

El Proceso Unificado

www.kybele.urjc.es

5

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

El Proceso Unificado

www.kybele.urjc.es

6

Lunes por la mañana 

Visión: Describir, para desarrollador y cliente, qué es exactamente 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

El Proceso Unificado

www.kybele.urjc.es

7

Lunes por la mañana 

Personal Timer Tool: Visión Problema  Para la organización de Gary, la dificultad de recopilar datos consistentes acerca del tiempo dedicado a las diferentes actividades por parte de los desarrolladores provoca 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 mejores estimaciones en proyectos futuros

Partes principales involucradas  Desarrolladores individuales  Asistente administrativo  Gestores de proyectos

Casos de Uso     El Proceso Unificado

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 www.kybele.urjc.es

8

Lunes por la mañana 

Plan Esbozar una planificación para los próximos días, identificando hitos 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 su parte. 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 Inicio Como medio adicional para convencer a Gary, y también como cobertura 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.

El Proceso Unificado

www.kybele.urjc.es

9

Lunes por la mañana 

Plan 9: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: Lunes

Martes

Miércoles

Jueves

INICIO Visión Plan Caso de Negocio Riesgos

Prototipo Mitigar riesgos

CONSTRUCCIÓN Diseño Codificación Pruebas

Diseño Codificación Pruebas

LCO: OK de Gary

LCA: OK de Gary

ELABORACIÓN Prototipo

Pruebas casos de uso

Viernes

Sábado

IOC: mostrar versión beta Diseño Codificación Pruebas

TRANSICIÓN Mejoras? Entrega

El Proceso Unificado

www.kybele.urjc.es

10

Lunes por la mañana 

Plan INICIO/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 algunas ideas. 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)

El Proceso Unificado

www.kybele.urjc.es

11

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 que usuarios reales prueban el software

TRANSICIÓN  Un par de horas, versión final, facturar El Proceso Unificado

www.kybele.urjc.es

12

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

El Proceso Unificado

www.kybele.urjc.es

13

Lunes por la mañana 

Business Case Documento 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

El Proceso Unificado

www.kybele.urjc.es

14

Lunes por la mañana 

La arquitectura

+ algunos otros modelos UML El Proceso Unificado

www.kybele.urjc.es

15

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

El Proceso Unificado

www.kybele.urjc.es

16

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.

El Proceso Unificado

www.kybele.urjc.es

17

Lunes comida 

Plan, II

Lunes

Martes

Miércoles

Jueves

Viernes

INICIO Visión Plan Caso de Negocio Riesgos

Prototipo Mitigar riesgos

CONSTRUCCIÓN Local Diseño Codificación Pruebas

CONSTRUCCIÓN Cliente-Servidor Diseño Codificación Pruebas

TRANSICIÓN Mejoras?

Diseño Codificación Pruebas

Diseño Codificación Pruebas

Entrega

Sábado

IOC: mostrar versión beta

LCO: OK de Gary

ELABORACIÓN Prototipo

El Proceso Unificado

LCA: OK de Gary Pruebas casos de uso

www.kybele.urjc.es

18

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

El Proceso Unificado

www.kybele.urjc.es

19

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

El Proceso Unificado

www.kybele.urjc.es

20

Lunes tarde 

Profundizando Detalle 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

El Proceso Unificado

www.kybele.urjc.es

21

Lunes tarde 

Profundizando Má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:

El Proceso Unificado

www.kybele.urjc.es

22

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 El Proceso Unificado

www.kybele.urjc.es

23

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 El Proceso Unificado

www.kybele.urjc.es

24

Miércoles 

Progreso y más cambios Solució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

El Proceso Unificado

www.kybele.urjc.es

25

Jueves 

Terminando Cambios: 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 El Proceso Unificado

www.kybele.urjc.es

26

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

El Proceso Unificado

www.kybele.urjc.es

27

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 

El Proceso Unificado

www.kybele.urjc.es

28

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 prioritarias No 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

El Proceso Unificado

www.kybele.urjc.es

29

Conclusiones 

Gestión de la configuración Mantiene versiones Evita problemas debido a errores o accidentes Permite volver a versión previa



Documentación de usuario Versió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

El Proceso Unificado

www.kybele.urjc.es

30