Tema 3: El Proceso Unificado de desarrollo de software. · El Proceso Unificado Introducción A software development process for a team of one. Philippe Kruchten El objetivo de un

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

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb02/ProcessForOneFeb02.pdf













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

http://www.cs.cofc.edu/~bowring/docs/humphrey.pdf




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


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


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

http://rup.hops-fp6.org/process/artifact/ar_vsion.htm

http://rup.hops-fp6.org/process/artifact/ar_rskls.htm

http://rup.hops-fp6.org/process/artifact/ar_rskls.htm

http://rup.hops-fp6.org/process/artifact/ar_bcase.htm



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



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



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



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


TRANSICIÓNMejoras?

Entrega



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



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



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



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



La arquitectura

+ algunos otros modelos UML

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

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.

17


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



Entrega


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


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


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


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


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


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


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


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


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


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


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


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

Documents

Tema 3: El Proceso Unificado de desarrollo de software. · El Proceso Unificado Introducción A software development process for a team of one. Philippe Kruchten El objetivo de un