Ciclo de Vida por Prototipos

Descripción del modelo

 Una alternativa de enfoque para la definición de los
requerimientos consiste en capturar un conjunto inicial
de necesidades e implementarlas rápidamente con la
intención declarada de expandirlas y refinarlas
iterativamente al ir aumentando la compresión que del
sistema tienen los usuarios y quien lo desarrolla.

 La definición del sistema se realiza por el

descubrimiento evolutivo y gradual y no a través de la
previsión omnisciente... Ofrece una alternativa atractiva
y practicable a los métodos de especificación para tratar
mejor la incertidumbre, la ambigüedad y la volubilidad de
los proyectos reales.
 Herramientas de software
Dentro del enfoque de prototipos se pretende que el
modelo sea operante, es decir, una colección de
programas de computadora que simulan algunas o todas
las funciones que el usuario desea.

 Un diccionario de datos integrado.

 Un generador de pantallas.
 Un generador de reportes no guiado por procedimientos.
 Un lenguaje de programación de cuarta generación.
 Un lenguaje de consultas no guiado por procedimientos.
 Medios poderosos de administración de base de datos.
Modelo de prototipos
 Características de buenos
candidatos
 El usuario no puede o no está dispuesto a examinar modelos
abstractos en papel, tales como diagramas de flujo de datos.

 El usuario no puede o no está dispuesto a articular sus

requerimientos de ninguna forma y sólo se pueden determinar sus
requerimientos mediante un proceso de tanteo, o ensayo y error.

 Se tiene la intención de que el sistema sea en línea y con operación

total por la pantalla, en contraposición con los sistemas de edición,
actualización y reportes operados por lote.

 El sistema no requiere la especificación de grandes cantidades de

detalles algorítmicos, ni de muchas especificaciones de procesos
para describir los algoritmos con los cuales se obtienen resultados.
PSP/TSP y modelo CMM
 Capability Maturity Model (CMM)
 Elaborado por el SEI (Software Engineering
Institute) de la Universidad de Carnegie Mellon,
Pittsburgh PA (80’s – 90’s).
 Contiene las mejores prácticas organizacionales
para el desarrollo de software.
 Define 5 niveles para medir la madurez de los
procesos en una empresa (certificación).
 Hay varios modelos que atienden aspectos de
Ingeniería de sistemas (SE-CMM), desarrollo de
productos integrados (IPD-CMM), adquisición de
software (SA-CMM) y recursos humanos
(People CMM).
 Personal Software Process (PSP)
 Elaborado por Watts Humprey del SEI.
 Debido a que el costo de personal es el 70%
aprox. del costo del desarrollo de software, las
habilidades y hábitos de trabajo de los ingenieros
determinan los resultados del proceso de
desarrollo del software.
 Aplica los principios del CMM a las prácticas de
desarrollo de software de un solo desarrollador.
 Es un proceso CMM nivel 5.
Qué muestra a los ingenieros ?
 Cómo administrar la calidad de sus proyectos.
 Cómo hacer compromisos que puedan cumplir.
 Cómo mejorar la estimación y la planeación.
 Cómo reducir los defectos en sus productos.

 Puede ser usado como una guía para una

metodología disciplinada y estructurada para
desarrollar software.
 En que fases se aplica ?
 Desarrollo de programas pequeños.
 Definición de requerimientos.
 Escritura de documentos.
 Pruebas del sistema.
 Mantenimiento de sistemas.
 Mejora de sistemas de software grandes.
 Que herramientas utiliza ?
 Reportes de actividades (tiempos).
 Reporte de trabajos (tiempos, LOC).
 Bitácora de tiempos.
 Bitácora de defectos.
 Etc.
 Team Software Process (TSP)
 Elaborado por Watts Humprey del SEI.
 Aplica los principios del CMM a las prácticas de
desarrollo de software de un equipo de
desarrollo.
 Es un proceso CMM nivel 5.
 Realizado para dar soporte a las prácticas de
PSP.
 Ayuda a una organización a establecer prácticas
de ingeniería maduras y disciplinadas, que
producirán software seguro y confiable.
 Para que sirve ?
Ayuda a los ingenieros de alto desempeño a:
 Asegurar productos de software con calidad.
 Crear productos de software seguros.
 Mejorar la administración de proyectos en una organización.

 Usando TSP, una organización puede construir equipos

auto-dirigidos que planean y hacen seguimiento de su
trabajo, establecen metas, y poseen sus propios procesos y
planes. Estos equipos pueden ser de puros ingenieros de
software o multidisciplinarios de 3 a 20 personas.
 Cómo funciona ?
Los equipos usan TSP para aplicar conceptos de
equipos integrados al desarrollo de sistemas. Un
proceso de lanzamiento de cuatro días lleva a los
equipos y sus administradores a través de:
 Establecer metas.
 Definir roles de los equipos.
 Administrar riesgos.
 Producir un plan de equipo.

Después del lanzamiento, TSP provee un marco de

trabajo de procesos definidos para administrar, hacer
seguimiento y reportar el progreso del equipo.
Extreme Programming XP
 Extreme Programming
 Creado por Kent Beck y Ward Cunningham.
 Es una disciplina de desarrollo de software
basada en valores de simplicidad,
comunicación, retroalimentación y valor.
 Funciona reuniendo a todo el equipo en
presencia de prácticas simples, con suficiente
retroalimentación para permitir al equipo ver
donde están, y para afinar las prácticas a
situaciones únicas.
 Reglas y Prácticas de XP
Planeación
 Se escriben historias del usuario. *
 Una reunión de planeación de liberaciones crea el
cronograma de actividades.
 Hacer pequeñas liberaciones frecuentemente. *
 Se mide la velocidad del proyecto.
 El proyecto es dividido en iteraciones.
 La planeación de la iteración inicia cada iteración.
 Rotar al personal.
 Una reunión cada día para ver problemas y soluciones.
 Arreglar a XP cuando se necesite.
 Reglas y Prácticas de XP
Programación
 El usuario siempre está disponible. *
 Código escrito en estándares predefinidos. *
 Se programa primero la prueba de unidad.
 Toda la programación se hace por parejas. *
 Sólo una pareja integra código a la vez.
 Integrar seguido. *
 Usar propiedad colectiva del código. *
 Dejar la optimización al final.
 Sin tiempo extra. *
 Reglas y Prácticas de XP
Diseño
 Simplicidad. *
 Escoger una metáfora del sistema. *
 Usar tarjetas CRC (Class-Responsabilities-
Collaboration) para las sesiones de diseño.
 Crear soluciones rápidas para reducir riesgos.
 No se agrega funcionalidad antes de tiempo.
 Refactorizar cuando y donde sea posible. *
 Reglas y Prácticas de XP
Pruebas
 Todo el código tiene pruebas de unidad. *
 Todo el código debe pasar todas las
pruebas de unidad antes de ser liberado.
 Cuando se encuentra una falla, se crean
pruebas.
 Se ejecutan pruebas de aceptación
seguido y el resultado es publicado.