El Proceso Unificado de
Desarrollo de software
Ing. Jorge Luis Chuc López
Síntomas de problemas de
desarrollo de software
Entendimiento sin precisión de las necesidades de los usuarios.
Falta de habilidad para enfrentar requerimientos cambiantes.
Módulos que no se pueden integrar.
Software que es difícil de mantener o extender.
Descubrimiento tardío de serias vulnerabilidades del proyecto.
Pobre calidad del software.
Desempeño inaceptable del software. Esfuerzo no coordinado de los equipos.
Causas raíz de los problemas
de desarrollo de software
Administración de requerimientos ineficiente. Comunicación ambigua e imprecisa.
Arquitecturas frágiles. Complejidad aplastante.
Inconsistencias no detectadas en los requerimientos, diseños e implementaciones.
Pruebas insuficientes.
Evaluación subjetiva de la situación del proyecto. Retardo en la reducción del riesgo debido al uso del desarrollo en cascada.
23/02/2012 Ing. Jorge Luis Chuc López 4 Desarrollo iterativo Administrar requerimientos Usar arquitecturas de componentes Modelar visualmente (UML) Verificar la calidad continuamente Control de cambios (UCM) Mejores prácticas Causas raíz Requerimientos insuficientes Comunicación ambigua Arquitecturas frágiles Complejidad aplastante Inconsistencias no detectadas Pobre verificación Evaluación subjetiva Desarrollo en cascada Cambios no
controlados Automatización insuficiente
Síntomas
Necesidades no conocidas Requirementos cambiantes Móulos que no se integran Difícil de mantener
Descubirmiento tardío Pobre calidad Pobre desempeño Desarrolladores en desacuerdo Construye-y-libera
¿Qué son las mejores
prácticas?
Un conjunto organizado y documentado
de principios, métodos y procesos que
incrementan la calidad y la
Desarrollo iterativo de
software
No es posible conocer todo al inicio:
Probablemente un diseño inicial será defectuoso
con respecto a sus requerimientos clave.
El descubrimiento de defectos del diseño en fases
avanzadas da como resultado altos costos y/o cancelación del proyecto.
El tiempo y el dinero gastado en
Características del desarrollo
en cascada
Retrasa la confirmación de resolución de riesgos críticos Mide el progreso evaluando los productos del trabajo, que son pobre predictores del tiempo-para-finalizar Retarda y agrega la
integración y las pruebas Descarta el despliegue temprano
Frecuentemente resulta en iteraciones mayores no
planeadas
Codificación y pruebas de unidad
Diseño
Integración de subsistemas
Pruebas del sistema Proceso en Cascada
Proceso de software convencional
Inicia la Integración
Rotura tardía del diseño
100%
Calendario del proyecto
P rogre so del des arrol lo (% co d ifi cad o Fecha original de entrega
Actividades secuenciales:
Características del desarrollo iterativo
Resuelve los principales riesgos antes de realizar grandes inversiones
Permite la retroalimentación temprana del usuario Hace contínuas las pruebas y la integración
Se concentra en los hitos de objetivo de corto plazo del proyecto Hace posible el desarrollo de implementaciones parciales
T I E M P O
Iteración 1 Iteración 2 Iteración 3
I C
D R
P I
C D
R
P
I C
D R
Perfiles del riesgo
E xposi ci ón al ri egso del proy ec toCiclo de vida del proyecto Baja Alta Periodo de resolución del riesgo Periodo de exploración del riesgo Periodo de administración del riesgo controlado
Perfil del riesgo del Proyecto convencional (Cascada)
Inicio Elaboración Construcción – Transición
El Desarrollo Iterativo produce un
ejecutable
Planeación Inicial
Planeación
Requerimientos
Análisis y Diseño
Implementación
Pruebas
Despliegue
Evaluación
Adminitración del ambiente
Un proceso de desarrollo de
software deberá:
Definir los pasos que llevan a entregables
y quién es responsable de ellos.
Ayudar a controlar el proyecto y reducir la
confusión.
Ayudar a la administración del proyecto a
planear, definir recursos y medir el avance.
Reducir el riesgo.
El Proceso Unificado de
Desarrollo de Software
Proporciona directrices para el desarrollo
eficiente de software de calidad.
Reduce el riesgo e incrementa la
predecibilidad.
Captura y presenta las mejores prácticas
Historia del Proceso
Objectory Process 3.8
Rational Approach
Rational Objectory Process 4.0
1996
Rational Objectory Process 4.1
1997 SQA Process Requirements College UML 0.8
Rational Unified Process 5.0
Configuration & Change Mgmt
1998 1995 Business Engineering Data Engineering Objectory UI design Performance testing UML 1.1 OMT Booch
Rational Unified Process 5.5
1999 SPC/PMI
Project Management
Rational Unified Process 2000
Estructura del Proceso
Dos estructuras ortogonales
Organización a lo largo del tiempo
Estructura del ciclo de vida: fases, iteraciones
Promulgación del proceso: planeación, ejecución
Administración de actividad, control del proyecto
Organización basada en contenido
Trabajadores, artefactos, actividades, flujos de
trabajo.
Organización a lo largo del tiempo
Hitos principales: Puntos de decisiones
de negocios
Inicio Elaboración Construcción Transición
Compromete los recursos para la fase de Elaboración
Hito de Objetivo del Ciclo de Vida
Compromete
los recursos para la construcción Hito de Arquitectura del Ciclo de Vida Producto bastante Maduro para los clientes
Hito de Capacidad Operacional
Inicial
Aceptación de los Clientes o fin de la vida
Liberación del Producto
Fase de Inicio: Objetivos
Establecer el alcance del proyecto y las
condiciones de frontera.
Determinar los casos de uso y los escenarios
principales que conducirán a los principales
compromisos de diseño.
Demostrar una arquitectura candidata contra
algunos de los escenarios principales.
Actividades
Formular el alcance del
proyecto
Planear y preparar un
caso de negocios
Crear un arquitectura
candidata
Productos
Documento de Visión
Caso de desarrollo
Investigación del
Modelo de casos de Uso
Glosario Inicial
Caso de negocios inicial
Evaluación del riesgo
inicial
Plan del proyecto
Hito: Objetivos de Ciclo de Vida (Lifecycle
Fase de Elaboración: Objetivos
Definir, validar y establecer la línea base de la
arquitectura tan rápidamente como sea
práctico.
Establecer una línea base de la visión.
Establecer una línea base del plan para la
fase de construcción.
Demostrar que la arquitectura preliminar
Actividades
Desarrollar la visión y los
casos de uso más críticos que conducen las decisiones
arquitectónicas y de planeación
Elaborar el proceso y la
infraestructura del ambiente de desarrollo.
Elaborar la arquitectura y
seleccionar componentes.
Productos
Un modelo de casos de uso
(80% completo)
Requerimientos
suplementarios.
Una arquitectura ejecutable
Caso de negocios revisado.
Lista de riesgos revisada.
Plan de desarrollo
Hito: Arquitectura del Ciclo de Vida (Lifecycle
Fase de Construcción: Objetivos
Minimizar los costos de desarrollo
optimizando los recursos y evitando los
desechos y el retrabajo innecesario.
Lograr la calidad adecuada tan
rápidamente como sea práctico.
Actividades
Administración y control de
recursos, así como la
optimización del proceso.
Desarrollo y prueba de
componentes completos contra el criterio de
evaluación definido.
Evaluación de las liberaciones
de producto contra el criterio de aceptación de la visión.
Productos
El producto de software,
integrado en la plataforma adecuada.
Manual del usuario
conforme sea necesario.
Una descripción de la
liberación actual.
Hito: Capacidad Operacional Inicial (Initial
Fase de Transición: Objetivos
Lograr el apoyo autónomo del usuario.
Lograr la concurrencia de las personas
interesadas de que la línea de referencia del
despliegue está completa y es consistente
con el criterio de evaluación de la visión.
Lograr establecer una línea base de producto
final lo más rápido posible a un costo
Actividades
Ingeniería específica al
despliegue
Actividades de puesta a
punto.
Evaluación de la línea de
referencia del despliegue con base en la visión
completa y los criterios de aceptación del
proyecto.
Productos
El sistema completo
Hito: Liberación del producto (“GA”)
Fases e Iteraciones
Compromete los
recursos para la fase de elaboración
Compromete los recursos para la construcción
Producto lo suficientemente Maduro para ser usado por los usuarios
(Entender el problema) (Entender la solución) (Tener una solución)
Aceptación o fin de la vida
Puntos de Decisión (de Negocios) planeados
Iteración preliminar
Iteración de Arquitectura
Iteración de
Arquitectura Iteración de Desarrollo
Iteración de
Desarrollo Iteración de Desarrollo Iteración de transición
Iteración de transición
Puntos de visibilidad (técnicos) planeados
Una iteración
En una
Iteración: número y duración
La duración está conducida por:
El tamaño de la organización
EL tamaño del proyecto
La familiaridad con el proceso, madurez
La simplicidad técnica
6 más/menos 3
Inicio: 0..1
Elaboración: 1..3
Construcción: 1..3
Organización basada en el
contenido
Co
n
te
n
id
Concepto clave: flujo de trabajo
Secuencia de actividades
que producen un
resultado de valor
observable.
Terminología:
Flujos de trabajo
nucleares.
