IV.

Modelos de Proceso
¿Qué es un PSP?
 Un PSP es un proceso personal para desarrollar
software.
 pasos definidos
 formularios
 estándares

 Un PSP es un marco de trabajo de medición y

análisis que nos ayuda a caracterizar nuestro
proceso.

 Es también un procedimiento definido para

ayudar a mejorar nuestro rendimiento.
Desarrollo Software Personal
Principios PSP
 la calidad de un sistema software está condicionada
por la calidad del peor de sus componentes.

 la calidad de un componente software está

condicionada por el individuo que lo desarrolló.

 Está condicionada por el

 conocimiento
 disciplina
 compromiso
del desarrollador
 Principios PSP (cont...)
 Todo profesional software debería conocer su
propio rendimiento.

 Debería medir, seguir/controlar y analizar su

trabajo.

 Debería aprender de las variaciones de su

rendimiento.

 Debería incorporar esas lecciones a su manera

personal de hacer las cosas.
 ¿Qué proporciona el PSP?
 Un PSP estable permite
 estimar y planificar el trabajo
 cumplir los compromisos
 resistir a presiones de compromiso no razonables

 Con un PSP estable, también se podrá

 comprender nuestras capacidades
 estar mas posibilitado para mejorar

 Un PSP también proporciona

 Una base probada para desarrollo y práctica de las disciplinas
personales de la industria.
 Una disciplina que muestra como mejorar el proceso personal.
 Los datos para mejorar de manera continua la productividad,
calidad, y el grado de predicción de trabajo
Tiempo
El proceso de desarrollo de SW
Requisitos

Planificar
Cuadernos
Diseñar
Datos de Datos
Orientación Codificar defectos Datos
Guiones del plan
y tiempos reales
Compilar
Resumen del
Probar plan del
proyecto
Post Mortem
Datos planificados
y reales del
Producto
proyecto y del
acabado proceso
El PSP
 El PSP se aplica en tareas personales
estructuradas:
 Desarrollo de módulos de programas.
 Definición de requisitos o procesos.
 Realización de revisiones o pruebas.
 Escritura de documentación, etc….

 El PSP se puede extender al desarrollo de

sistemas software de gran tamaño.

 Es un proceso de Nivel 5 para los individuos y

es un prerrequisito para el TSP
 Gestión del Tiempo
 Para hacer un plan realista, tienes que controlar tu forma
de gastar el tiempo. Registrar lo que haces te dara
pautas importantes que no conocidas.

 Para comprobar la exactitud de tus estimaciones de

tiempo y los planes, debes documentar y posteriormente
compararlas con lo que realmente haces.

 Para hacer mas precisos tus planes, determina las

equivocaciones de los planes anteriores y que podrías
haber hecho mejor.

 Para gestionar tu tiempo, planifica tu tiempo y sigue el

plan.
Planifica el tiempo
 Clasifica tus actividades.

 Anota el tiempo dedicado a cada actividad.

 Anota el tiempo de manera estándar.

 Guarda los datos de tiempo en un lugar

adecuado
Proceso PSP0
 PSP0 es un proceso sencillo, definido y
personal.

 Utiliza tus métodos actuales de diseño y

desarrollo.

 Recoge datos sobre tu trabajo:

 tiempo gastado por fase
 defectos encontrados en compilación y pruebas

 Proporciona un informe resumen.

El flujo de Proceso del PSP0
Requisitos

Proceso PSP0
Planificación
Desarrollo

Guiones Diseño Logs de

de proceso Código tiempos
y
Compila defectos
Pruebas Resumen
Post-mortem Plan

Producto acabado Proyecto y proceso

Proceso PSP0
 Elementos
 un guión de proceso
 un formulario resumen de plan proyecto
 un registro tiempo
 un registro de defectos
 un estándar de tipos defecto
Guión de proceso
Número Propósito Guiarte en el desarrollo de programas a nivel de módulo
Fase
Entradas  Descripción del problema
Necesarias  Formulario de Resumen del Plan de Proyecto PSP0
 Tablas de Registro de Tiempos y Defectos
 Estándar de Tipos de Defectos
 Cronómetro (opcional)
1 Planificación  Producir o obtener los requisitos.
 Estimar las LOC (Line Of Code) necesarias.
 Estimar el tiempo de desarrollo necesario.
 Indicar los datos del plan en el Resumen del Plan de
Proyecto
 Completar el Log de Registro de Tiempos
2 Desarrollo  Diseñar el programa
 Implementar el diseño.
 Compilar el programa y corregir todos los defectos
encontrados.
 Completar el Tabla de Registro de Tiempos.
3 Post-mortem Completar el Resumen del Plan de Proyecto con los datos
actuales de tiempo, defectos, y tamaño.
Criterios de  Un programa probado.
salida  Un Resumen de Plan de Proyectos con los datos estimados
y los actuales.
 Las Tablas de Registro de Tiempos y Defectos rellenos
 El guión PSP0
 Planificación - estimar tiempo de desarrollo.

 Desarrollo - desarrollar el producto utilizando tus métodos actuales.

 Post-mortem - completar el resumen del plan proyecto, con los

tiempos gastados y defectos encontrados e inyectados en cada fase.

 Diseño - diseñar el programa, usando tus métodos de diseño

actuales.

 Codificación- implementa el programa.

 Compilación - compila hasta que este libre defectos.

 Prueba - prueba el programa y corrige todos los defectos.

 Registra los defectos en el log de defectos y tiempos por fase en el

log de tiempos.
Resumen Plan PSP0
Student Kim Orihuela Date 9-20-96
Program Standard Deviation Program # 1A
Instructor Iraj Hirmanpour Language C

Program Size (LOC): Plan Actual

Total New&Changed 50 33

Time in Phase (min.) Plan Actual To Date To Date %

Planning 2 2 1.6
Design 0 0 0
Code 53 53 44.2
Compile 20 20 16.7
Test 25 25 20.8
Postmortem 20 20 16.7
Total 240 120 120 100.0

Defects Injected Actual To Date To Date %

Planning 0 0 0
Design 0 0 0
Code 10 10 100
Compile 0 0 0
Test 0 0 0
Total Development 10 10 100

Defects Removed Actual To Date To Date %

Planning 0 0 0
Design 0 0 0
Code 3 3 30
Compile 5 5 50
Test 2 2 20
Total Development 10 10 100
After Development 0 0 0
 Resumen Plan PSP0
 Header – Nombre, fecha, programa, instructor,
lenguaje.

 Program Size – Plan -Indica tu mejor estimación del

tiempo total que tendrá el desarrollo.

 Program Size – Actual -Indica el tiempo actual en

minutos gastado en cada fase.

 Time – To Date - indica el tiempo total gastado en

cada fase hasta hoy. Para programa 1A, es el tiempo
gastado en el programa 1A.

 Time – To Date % - indica el porcentaje del total

tiempo hasta hoy que se gasto en cada fase.
Resumen Plan PSP0
 Defects injected and removed - indicar el
numero actual de defectos inyectados y
eliminados en cada fase.

 Defect - To Date - indica el total de defectos

inyectados y eliminados en cada fase hasta
hoy. Para el programa 1A, son los defectos
inyectados y eliminados en el programa 1A.

 Defect - To Date % - indicar el porcentaje

sobre el total defectos inyectados y eliminados
hasta hoy en cada fase.
 Log Registro de tiempo PSP0
Student Date
Instructor Program #

Date Start Stop Interruption Delta Phase Comments

Time Time
Registro del tiempo

C=Completada
U=Unidades
Log Registro de tiempo PSP0
 Header - indicar nombre, fecha, instructor, y
numero de programa.

 Date - indicar la fecha actual.

 Start - indicar el tiempo en minutos cuando

empiezas una fase del proyecto.

 Stop - indicar el tiempo en minutos cuando tu

paraste trabajo en una fase del proyecto, aun
cuando tu no has terminado esa fase.

 Interruption time - indicar el tiempo perdido por

interrupciones desde el periodo de arranque a
parada.
PSP0 Log Registro Tiempos
 Delta time - indicar el tiempo transcurrido
desde el inicio al tiempo de parada descontado
el tiempo de interrupción.

 Phase
 Anotar la fase en la que estas trabajando.
 Use el nombre de fase.

 Comments – descripción de
 la interrupción
 la tarea que estas haciendo
 cualquier aspecto significativo que afecte a tu
trabajo
Defect Types

Log Registro Defectos

10 Documentation 60 Checking
20 Syntax 70 Data
30 Build, Package 80 Function
40 Assignment 90 System
50 Interface 100 Environment

Student Kim Orihuela Date 10-3-96

Instructor Iraj Program # 3A
Date Number Type Inject Remove Fix Time Fix Defect
10-3 1 40 CODE CODE 11
Description: Add variable to structure.

Date Number Type Inject Remove Fix Time Fix Defect

10-3 2 20 CODE CODE 1
Description: Misspelled variable.

Date Number Type Inject Remove Fix Time Fix Defect

10-3 3 20 CODE COMPILE 1
Description: Missing “ in print statement.

Date Number Type Inject Remove Fix Time Fix Defect

10-3 4 10 CODE TEST 39
Description: Align/add print statements - beautify
Log Registro Defectos
 Header - indicar el nombre, fecha, instructor, y
numero de programa.

 Date - indicar la fecha cuando encontraste y

corregiste el defecto.

 Number - indicar un número único para este

defecto. Comienza cada cada proyecto con 1.

 Type - indicar el tipo de defecto a partir del

estándar de tipos de defectos.

 Inject - indicar la fase donde tu juzgas que el

defecto fue inyectado.
Log Registro Defectos
 Remove - indicar la fase en la que encontraste y
eliminaste el defecto.

 Fix Time - indicar el tiempo que tomaste para

corregir el defecto. Tu puedes dar el tiempo exacto
o usar tu mejor estimación.

 Fix defect - Si este defecto fue inyectado durante

la corrección de otro defecto, indicar el numero del
ese defecto o una X si lo desconoces.

 Note - un defecto es cualquier cosa en el programa

que debe ser cambiado para que sea desarrollado,
mejorado o utilizado de manera adecuada.
 Estándar de Tipos de defecto
 El estándar de tipos de defecto proporciona un conjunto
general de categorías de defectos.
 Aunque tu puedes reemplazar este estándar por el tuyo propio,
es deseable que te manejes con estas definiciones simples de
tipos hasta que tengas datos que te puedan guiar en las
modificaciones.

 Los tipos estándar de defecto en PSP son

 10 - Documentación
 20 - Sintaxis
 30 - Construcción, empaquetado
 40 - Asignación
 50 - Interfase
 60 - Comprobación
 70 - Datos
 80 - Funciones
 90 - Sistema
 100 - Entorno
Gestión de los defectos
 Ejercicio Clasificación de Defectos
Describe con al menos un ejemplo de cada tipo para

tu lenguaje y entorno
Tipo Nombre Descripción
10 Documentación comentarios, mensajes
20 Sintaxis ortografía, puntuación, tipos, formatos de instrucción
30 Construcción gestión de cambios, librerías, control de versiones
40 Asignación declaración, nombres duplicados, ámbito, limites
50 Interfaz Llamadas y referencias a rutinas, I/O, formatos
60 Comprobación mensajes error, comprobaciones inadecuadas
70 Datos estructura, contenido
80 Funciones lógica, punteros, bucles, recursion, calculo, defectos en funciones
90 Sistema configuración, tiempos, memoria
100 Entorno diseño, compile, pruebas, y problemas del sistema de soporte

Tipo ejemplo... Tipo ejemplo...

10 ______________________________ 60 ______________________________
20 ______________________________ 70 ______________________________
30 ______________________________ 80 ______________________________
40 ______________________________ 90 ______________________________
50 ______________________________ 100 ______________________________
El marco de trabajo para la
planificación de proyectos
Definir
Necesidades

Producir
Diseño
Conceptual

Estimar Base de datos

Tamaño de tamaño

Estimar Base datos de

Recursos productividad

Producir Recursos
Calendario Disponibles

Datos Tamaño,
Entrega Desarrollar Proceso Informes de
Recursos, Seguimiento
Producto Producto Plazos Análisis
Tamaño frente a esfuerzo de
desarrollo
 El requisito principal: si la medición del tamaño
no esta directamente relacionada con el costo
de desarrollo, no es bueno usarla.

 Hay muchas medidas posibles:

 líneas de código (LOC)
 puntos de función
 páginas, pantallas, scripts, informes

 La medida del tamaño suele ser sensible al

lenguaje, diseño y al modo de desarrollo.
Recuento del tamaño del
programa
 El PSP utiliza un estándar de contador de líneas
físicas.
 utiliza una línea física por cada línea lógica
 utiliza un estándar de codificación definido

 Este estándar debe ser seguido estrictamente.

 Entonces el recuento de líneas físicas será igual

al recuento de líneas lógicas.
El estándar de recuento del
PSP
 Contar todas las instrucciones:
 begin, end, if, then, else, etc.
 {, }, ;, ., etc.
 contar declaraciones, directivas, encabezados, etc.

 No contar blancos, líneas de comentarios,

código generado automáticamente, o código
reutilizado.

 Contar el código nuevo y el cambiado para

medir y estimar la productividad de desarrollo.
Contabilidad de Líneas de
Código
 Para pequeños programas, el seguimiento de
tamaño puede realizarse de manera manual,
aunque requiere cuidado.

 Para grandes programas, el seguimiento del

tamaño requiere un sistema de contabilidad.

 La contabilidad de LOC proporciona una

manera precisa y ordenada para realizar el
seguimiento de los cambios de LOC a través
de las múltiples versiones de programas.
Ejemplo de Contabilidad de LOC - 2
 Sumar Restar Base
 Base V0 0
 Borradas, 0
 Modificadas 0 0
 Añadidas 350
 Total V0 LOC 350 -0 350
 Borradas 0
 Modificadas 25 -25
 Añadidas 100
 Producto Final 125 -25 450
 Total Nuevas y Cambiadas LOC 475
Estimación del tamaño
Programa LOC Funciones estimadas Mín. Med. Máx.
Bucles

4 10 While sencillo

5 14 Repeat sencillo 7 11 14
Case

2 11 Case sencillo 5 8 11
3 14 Case grande

Datos

6 18 Lista enlazada sencilla

Cálculo

1 20 Cálculo pequeño 10 15 20

Total 22 34 45

Este programa tiene una sentencia Case sencilla, un Bucle y un cálculo. Asumo que, como máximo, el tamaño se
obtendrá sumando estos tamaños típicos, 11+14+20=54 LOC. Para el valor mínimo, asumo que estas funciones
podrán combinarse más efectivamente que cuando están como elementos separados. Esto nos da 22 LOC como
valor mínimo. 34 LOC es el punto medio entre los dos valores anteriores.
Resumen del plan del proyecto
Defectos Introducidos Plan Actual Hasta la fecha %Hasta la fecha Def./Hora

Planificación

Diseño 1 5 14,7 1,29

Codificación 4 3 28 82,4 1,84

Revisión del código

Compilación 1 2,9

Pruebas

Total 5 3 34 100

Defectos eliminados Plan Actual Hasta la fecha %Hasta la fecha Def./Hora

Planificación

Diseño

Codificación
Guión del proceso PSP
Guión del proceso PSP

E ntradas requeridas La des cripción del problema.

Tabla Res umen del P lan del P royecto P S P .
Una copia de la lis ta de comprobación para la revis ión de código.
Datos de tamaños y tiempos reales de programas anteriores .
C uaderno de Regis tro de tiempos .
C uaderno de Regis tro de Defectos

1 P lanificación Obtén una des cripción de las funciones del programa.

E s tima las LOC máx., mín., total requeridas .
Determina los minutos /LOC .
C alcula los tiempos de des arrollo máx., mín. y total.
E s tima los defectos a introducir y eliminar en cada fas e.
E s tima los defectos a introducir y eliminar en cada fas e.
E s cribe los datos del plan en la tabla Res umen del P lan del P royecto.
A nota el tiempo de planificación en el C uaderno de Regis tro de Tiempos .

2 Dis eño Dis eña el programa.

A nota el dis eño en el formato es pecificado.
A nota el tiempo de dis eño en el C uaderno de Regis tro de Tiempos .

3 C odificación Implementa el dis eño.

Utiliz a un formato es tándar para introducir el código.
A nota el tiempo de codificación en el C uadero de Regis tro de Tiempos .

4 Revis ión de código Revis ar completamente el código fuente.

S eguir el guión de revis ión de códig de la lis ta de comprobación.
C orregir y regis trar todos los defectos encontrados .
Qué es TSP
 TSP sirve para construir y guiar equipos interdisciplinarios
 Proporciona
 un proceso definido para construir el equipo
 un marco para el trabajo en equipo
 un ambiente de gestión para soportarlo
 Diseñado para equipos de desarrollo y mantenimiento de
entre 2 a 20 ingenieros
 Incluye
 un proceso completamente definido para el trabajo en equipo
 roles definidos para los miembros del equipo
 un proceso estructurado para el lanzamiento y seguimiento
 una herramienta para soportar el trabajo del equipo y del ingeniero
TSP soportaIPPD
• TSP (según Humphrey) es un enfoque bien
definido y probado que soporta el Desarrollo
Integrado de Productos y Procesos (IPPD)
 Foco en el cliente
 desarrollo concurrente
 planificación temprana y continua del ciclo de vida
 flexibilidad para utilizar enfoques originales
 diseño robusto y capacidad de mejora del proceso
 calendario guiado por eventos
 trabajo en equipo multidisciplinario
 “empowerment” (potencia al personal)
 herramientas de gestión coherentes
 identificación y gestión de riesgos proactivas
Equipos efectivos
• para ser efectivos los equipos deben comenzar
por:
 definir sus objetivos
 establecer roles en el equipo
 definir una estrategia de desarrollo
 definir el proceso
 producir un plan general de desarrollo
 detallar los planes para cada ingeniero
 hacer análisis de riesgos
 acordar mecanismos de comunicaciones y de
información
Cómo PSP y TSP se relacionan
TSP en TSP en
PSP desarrolla
construcción trabajo en
habilidades
del equip equipo

Mediciones personales Objetivos del proyecto Análisis de riesgos

Disciplina en el proceso Roles en el equipo Comunicación del equipo

Estimación y planificación Proceso del equipo Coordinación del equipo

Gestión de la Calidad Plan del proyecto registro del estado

Plan balanceado Informes del proyecto

Miembros del Disciplinas Gestión del

equipo del equipo equipo

Equipos Integrados
para el producto
Elementos de TSP
• Preparación
 ingenieros y sus gerentes se entrenan en PSP y TSP
• Lanzamiento (y re-lanzamiento) del equipo
 en hitos principales del proyecto el equipo reevalúa y
replanifica el proyecto
• Gestión y seguimiento del proyecto
 gerentes siguen el trabajo y controlan el proceso
TSP – Visión general
entrenamiento Entrenamiento
de ingenieros de gerentes
entrenamiento
de instructor/
mentor
lanzamiento de
equipo de proyecto

ejecuta primer fase del proyecto Participación y

guía y soporte seguimiento de
del mentor re-lanzamiento de gerentes
equipo de proyecto

ejecuta fase siguiente

ejecuta fase siguiente
ejecuta fase siguiente

postmortem
Lanzamiento de TSP
• Cada proyecto TSP comienza con un lanzamiento
 Lleva 3 o más días
o es parte del proyecto
o está dirigido por un mentor entrenado en TSP
o sigue inmediatamente a entrenamiento en TSP

 En el lanzamiento
o los ingenieros eligen roles personales
o definen sus propios procesos
o producen planes del equipo e individuales
o balancean estos planes
o evalúan y asignan riesgos del proyecto
Proceso de lanzamiento en TSP
Lanzamiento Gerente/Cliente: definen objetivos del proyecto
reuniones 1 y 2 responden preguntas del equipo
Equipo: Establece roles – define objetivos del equipo
Lanzamiento Equipo: define estrategia y proceso para el proyecto,
reuniones 3,4,5 genera planes de calidad y de soporte, desarrolla un
plan general de desarrollo
Lanzamiento Equipo: realiza planes detallados para la próxima fase y
reunión 6 equilibra los planes personales de los ingenieros

Lanzamiento Equipo: realiza una evaluación de riesgos del proyecto,

reunión 7 asigna riesgos a los ingenieros para su seguimiento

Lanzamiento Equipo: revisa el trabajo completado del lanzamiento,

reuniones 8 y 9 prepara presentación a los gerentes, realiza
postmortem del lanzamiento

Lanzamiento Equipo: presenta y defiende el plan

reunión 10 Gerente/Cliente: Revisa el plan del equipo, resuelven
problemas del plan con el equipo
Planificación en TSP
• tres niveles:
 plan general elaborado por el equipo
 plan detallado para la próxima fase por el equipo
 plan detallado personal de cada ingeniero para la
próxima fase
 ingenieros equilibran sus planes para a la vez distribuir
la carga de trabajo y minimizar el calendario
TSP – Planificación
estimar estimar
Requerimientos definir proceso tareas tiempo
y tareas semanal
Diseño
estimar tiempos de horas por
LOC
tamaño tareas semana
resumen de plantilla
tamaño plantilla de calendario
Posibles de tareas
componentee
funciones
producir planes
producir diseño resumen del de tareas y hacer plan
conceptual sistema calendario individual
del equipo

Defectos tareas y
inyectados y calendario indiv
removidos Consolidar planes
estimar resumen de (equipo, ingeniero,
calendario y equilibrar
rango de calidad
defectos calidad)
Parámetros de
Plan consolidado
calidad
Seguimiento de un proyecto TSP
• los planes del equipo e individuales son la base
para un adecuado seguimiento
• los miembros del equipo regularmente reevalúan
los riesgos y consideran formas de mitigarlos
• en reuniones semanales los ingenieros
 informan estado de las tareas
 revisan los riesgos clave
 re-equilibran la carga de trabajo
 el equipo produce informes semanales precisos del
estado para la gerencia
 El proceso unificado
• Es un proceso ORIENTADO A OBJETOS
• El proceso es:
• Guiado por casos de uso
• Centrado en la arquitectura
• Con un ciclo de vida iterativo e incremental

PARTE
DINÁMICA

CICLO Debe ofrecer un

marco de trabajo INTERFAZ
DE VIDA
genérico

PARTE
ESTÁTICA
El proceso unificado de
desarrollo de software
• El Proceso Unificado de Desarrollo
usa UML
UML Notación

Herramientas Proceso

• RATIONAL ROSE
PROCESO UNIFICADO DE
• VISIO DESARROLLO DE RATIONAL
1. Guiado por casos de uso
• Los sistemas se crean para dar servicio
a los usuarios.
– Qué REQUISITOS se necesitan
– Un CASO de USO es una pieza de
FUNCIONALIDAD de un sistema que le
proporciona a algún USUARIO un
RESULTADO o VALOR.
 2. Centrado en la
arquitectura
• La arquitectura de un sistema
software es un extracto de los modelos
del sistema
– Extracto: VISTA DE CADA MODELO
• que da una idea de qué forma que
tiene el sistema completo
 Centrado en la
ARQUITECTURA
1

VISTA DEL MODELO DE CASOS DE USODEL MODELO DEL DOMINIO /

VISTA
VISTA DEL DIAGRAMA DE CLASES

: IU-1 : : : : :
2: 1: 3: G 2: 1: 3: G
r 4 r 4
() ()
o o

VISTA DEL MODELO DEL ANÁLISIS

VISTA DEL MODELO DEL DISEÑO
+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS

SON VISTAS DE LOS MODELOS (NO MODELOS

COMPLETOS).
SÓLO APARECEN LOS QUE CORRESPONDEN
A CASOS DE USOS CRÍTICOS
3. Ciclo de vida iterativo
e incremental
• ITERATIVO
– Se repiten VARIOS MINIPROYECTOS
• INCREMENTAL
– Cada miniproyecto AMPLIA EL
PRODUCTO
 El CV del proceso
unificado
• UN CICLO DE VIDA SE REPITE A LO
LARGO DEL TIEMPO
• TRAS CADA CICLO DE VIDA 
VERSIÓN NUEVA DEL PRODUCTO
• UN CICLO DE VIDA SE DIVIDE EN FASES
• CADA FASE SE DIVIDE EN ITERACIONES
• EN CADA ITERACIÓN SE REALIZAN
FLUJOS DE TRABAJO
El CV del proceso unificado
Flujos de
trabajo:
Fases
Actividades
Inicio Elaboración Construcción Transición

Requisitos

Análisis

Diseño

Implementación

Prueba

ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Iteraciones: #1 #2 #n # n+ 1 # n+2 #m #m +1
64
 El producto
(del proceso unificado)

• NO ES SÓLO CÓDIGO EJECUTABLE

• SON LOS MODELOS O
REPRESENTACIÓN DEL SOFTWARE
• DEBE AJUSTARSE A TODAS LAS
PERSONAS IMPLICADAS
Fases dentro del CV del
proceso unificado
• FASE: PARTE DE UN CV
• CADA FASE TERMINA EN UN HITO
– HAY ARTEFACTOS DISPONIBLES
(SEGÚN LO PLANIFICADO)
– LOS RESULTADOS EN LOS HITOS
PERMITEN GESTIONAR
 Fases dentro del CV del
proceso unificado
• INICIACIÓN:
– DESCRIBIR PRODUCTO FINAL / ANÁLISIS DEL NEGOCIO
– IDENTIFICAR RIESGOS MÁS IMPORTANTES
– ESTABLECER PLANIFICACIÓN INICIAL DEL PROYECTO
– DECIDIR SI SE CONTINÚA
• ELABORACIÓN:
– ESTABLECER PLAN Y ARQUITECTURA ESTABLE
• CONSTRUCCIÓN: DESARROLLAR EL PRODUCTO
• TRANSICION: PROPORCIONAR SISTEMA A USUARIOS
 Iteraciones
• CADA FASE SE DIVIDE EN ITERACIONES
• CADA ITERACIÓN
– MINIPROYECTO (EN CASCADA) QUE EJECUTA FLUJOS
DE TRABAJO
– PRODUCE UN INCREMENTO EN PRODUCTO
• TAL Y COMO ESTABA
• SE REDUCE EL RIESGO
– SE PUEDE PERDER SÓLO LO REALIZADO EN ESA
ITERACIÓN
 Iteraciones
Como se puede ver, el Proceso
Unificado de Desarrollo
incluye actividades
ITERACIÓN correspondientes a un Proceso
de Gestión de Proyectos

PLANIFICACIÓN DE EVALUACIÓN DE LA
LA ITERACIÓN ITERACIÓN

REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBAS

ACTIVIDADES DE LOS FLUJOS DE TRABAJO FUNDAMENTALES69

 Fases: Iniciación
Establecer la planificación del proyecto

• ¿Qué va a hacer el sistema para cada uno de sus

usuarios principales?
– Un MCU simplificado con los CU más críticos
• ¿Cómo sería la arquitectura para un sistema como ese?
– Borrador con los subsistemas principales
• ¿Cuál es el plan y cuánto va a costar desarrollar el
producto?
– Identificar los riesgos principales y priorizarlos, planificar
elaboración y presupuesto aproximado
 Fases: Elaboración
Establecer un plan para el proyecto y una
arquitectura correcta

• Especificar en detalle los CU + críticos

• Diseñar la arquitectura
– Mediante vistas de todos los modelos del SI
– Vista arquitectónica de MCU, M. Análisis, M. Diseño, M.
Implementación (con los componentes que demuestran que la
arquitectura es ejecutable) y M. Distribución.
• Al final de esta fase se debe poder planificar las actividades
y estimar los recursos para poder completar el proyecto.
¿Son los CU, arquitectura y planes lo suficientemente
estables y los riesgos bajo control suficiente para firmar un
contrato para terminar el trabajo de desarrollo? 71
 Fases: Construcción
Desarrollar el sistema

• Se construye el producto. En esta fase:

– La arquitectura se completa para construir un sistema bien
cimentado
– La visión evoluciona hasta convertirse en un producto
preparado para los usuarios
– Es donde se gastan la mayoría de los recursos
– La arquitectura del sistema es estable. Sin embargo, se
pueden realizar cambios mínimos a la misma.
– ¿El producto se ajusta suficientemente a las necesidades de
los usuarios de algunos usuarios como para enviarselo ya?
 Fases: Transición
Proporcionar el sistema a los usuarios finales
• El producto se encuentra en fase beta
– Un grupo reducido de usuarios experimentados prueba el
producto e informa de los defectos y deficiencias y sugieren
mejoras.
– Los desarrolladores corrigen las deficiencias e incorporan
algunas de las mejoras propuestas en una versión para un
grupo de usuarios mayor.
– En esta fase se encuentran actividades como la venta,
formación de los usuarios, ofrecimiento de ayuda en línea y
corrección de defectos descubiertos tras la implantación. Los
defectos: (1) los que justifican la aparición de una nueva
versión del sistema, (2) los que se pueden dejar para la
siguiente versión que se cree.
 3 CONCEPTOS CLAVE:
1. DIRIGIDO POR  PIEZA QUE DA UN
CASOS DE USO: RESULTADO DE
VALOR.
 CAPTURAN LOS
REQUERIMIENTOS
FUNCIONALES.
“MODELO DE CASOS  DIRIGEN EL PROCESO
DE USO” DE
DESARROLLO
  DIFERENTES VISTAS DEL
2. CENTRADO EN LA SISTEMA.
ARQUITECTURA  INVOLUCRA LOS ASPECTOS
ESTÁTICOS Y DINÁMICOS MAS
SIGNIFICATIVOS.
 SURGE DE LAS NECESIDADES DE
LA EMPRESA.

3. ITERATIVO E  ITERACIÓN -> MINI-PROYECTO

INCREMENTAL -> PASOS EN EL FLUJO DE
TRABAJO, DEBEN SER
CONTROLADAS.
 LA ITERACIÓN FINALIZA EN UN
INCREMENTO.
 INCREMENTO ES CRECIMIENTO
EN EL PRODUCTO.