EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Get Started. It's Free
or sign up with your email address
Rocket clouds
EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE by Mind Map: EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

1. Inicio

1.1. La fase de inicio responde a ¿La pregunta cuanto va a costar el producto y en que tiempo estimado tendremos una primera versión del software? ¿Cuales son los casos de uso esenciales para los usuarios más importantes? ¿Cuál será esbozo o la arquitectura o del producto?

2. Dirigido por caso de uso

2.1. Un caso de uso es una pequeña funcionalidad del sistema que devuelve al usuario un resultado importante. Representa la unidad atómica funcional a través del cual se realizan todas las actividades necesarias para solucionar un problema, el conjunto de casos de uso de un sistema representa la funcionalidad total del producto

3. Centrado en la arquitectura

3.1. La arquitectura del sistema es un modelo que permite ver al producto antes de que este haya sido construido. Es decir los casos de uso representan la funcionalidad del sistema y la arquitectura la forma.

4. Iterativo e incremental

4.1. Es práctico dividir al proyecto en pequeños mini proyectos. Estos mini proyectos o iteraciones incrementan la funcionalidad del sistema para cada mini proyecto se realizan 5 flujos de trabajo requisitos, análisis, diseño, implementación y prueba.

5. Ventajas de las iteraciones

5.1. Reduce el costo de los incrementos a una sola iteración

5.2. Reduce el riesgo de no sacar al mercado el producto en un tiempo calendario

5.3. Resultados claros a corto plazo

5.4. Los clientes rara vez definen los requisitos a un inicio.

6. FASES DEL PROCESO UNIFICADO

7. Fase de elaboración

7.1. En esta fase se identifican la mayoría de los casos de uso y se especifica en detalle se diseña la arquitectura del sistema a través de modelos que representan al sistema entero esto implica que hay una vista arquitectónica del modelo del caso de uso, del modelo análisis del modelo de diseño de implementación y de despliegue.

8. Fase de construcción

8.1. El producto se crece hasta convertirse en un sistema completo preparados para ser empleado a la comunidad de usuarios, puede que no este completamente libre de defectos. Muchos de esos defectos se descubrirán y solucionaran durante la fase de transición.

9. Fase de transición

9.1. Esta fase cubre el periodo de entrega del producto a la comunidad de usuarios. Se capacita al personal o usuario finales de la aplicación, se crean los manuales o ayudas del sistema.

10. MODELOS RESULTANTES DE UN CICLO DE DESARROLLO.-

11. Planificación Temporal.

11.1. La planificación temporal tiene como objetivo evitar el retraso en la entrada del sistema. Un sistema de software general debe cumplir plazos o fechas de entrega impuestas por departamentos fuera del equipo de desarrollo en consecuencia pueden ser fechas irrealistas.

12. Principios de la planificación temporal

12.1. Durante las primeras etapas de la planificación del proyecto se desarrolla una planificación temporal macroscopica es decir se toman en cuenta las principales actividades de la ing. de software y las funciones del producto a las que se aplican a medida que el proyecto va progresando cada entrada en la planificación temporal microscópica se defina en una planificación temporal detallada.

13. Los principios fundamentales de la planificación Temporal son

13.1. Compartimentación

13.1.1. Tiene por finalidad la división del producto y el proceso en tareas mucho más sencillas

13.2. Interdependencia

13.2.1. Cada una de las tareas, fases, modelos del producto están interrelacionadas entre si es decir siguen una traza de desarrollo claramente definida

13.3. Validación de Esfuerzo

13.3.1. No se debe sobrecargar al personal, es decir se deben tener métricas de productividad individual por desarrollador de acuerdo a datos históricos de proyectos similares

13.4. Asignación de Esfuerzo

13.4.1. Cada una de las tareas, fases o modelos dependiendo de la estructura organizativa del equipo de desarrollo debe tener un responsable definido, se le debe asignar una fecha de inicio y una fecha de culminación de cada actividad.

13.5. Resultados definidos

13.5.1. Un proyecto de software debe ser claramente definido en función a sus fronteras del sistema es decir debe tener un objetivo general evitando cualquier ambigüedad en los resultados.

13.6. Responsabilidades definidas

13.7. Hitos definidos

13.7.1. Los hitos formales son reuniones técnicas formales de revisión de cada uno de los modelos que se han producido, aumentados o corregidos en una iteración o incremento.