Nivel Caracteristicas ‘Transicién al siguiente nivel 1 | Inicial ‘Ad hoc, paca Iniciar una administracion rigurosa del proyecto y formalizacin, segura (a calidad. herramientas aplicadas ‘de manera informal al proceso. 2 | Repetible Se cuenta con un Establecer un grupo y una arquitectura de proceso de proceso estable y un | desarrollo de software. Introducir métodos y tecnologias rivel repetibie de de ingenieria de software. control estadistico. 3. | Definido ‘Se cuenta con una | Establocer un conjunto basico de administraciones del base para un progreso | proceso para identiicar Ia calidad y costo de los mayor y continuo. ardmetros, y una base de datos del proceso. Juntar y ‘mantener los datos del proceso. Calcular la calidad felativa de cada producto e informar a a administracién. ‘4 | Administrado | Mejoras sustanciales | Apoyar la recopllacién automatica de datos del proceso. fn la calidad junto con | Usar los datos para analizar y modificar el proceso. medidas compronsivas del proceso. '5 | Optimizado | Mejoras con base en | Conlinuar mejorando y optimizando el proceso. mayor calidad y cantidad. = Optimizacién de los procesos Melon de la ingenieria de desempero | Nivel Cel a Exito de intagracién y prueba de los pro- Nivol 4 ces0s de la Ingenieria de desemperio t ‘Completa dafinicién dal pracasa de Nivel la ingeneeria de desempenio Nivel 2 Consideraciones de la ingenieria ee de desemperio en subprocesoe riesgo de Nivel Prdcticas sin eoordnacién ejecuoion Figura 3.6 Modelo general PEMM.Parte 1 ‘Parle Conceptos y guia | race | L Parie 7 Parte 6 Guia para uso on Guia para uso en | Guia para calificacion y mejora del proceso ceterminar capacidad de | entrenemiento de asesores | pprovaso de un proveador Parle 3 Parte 4 Realizaci6n ——}| Guia pera realizacion de evaluacién de evaluacion ct Parto § Parte 2 Modelo de evaluaciin y Modelo de referencia de guia de indicadores procesos y capacidad eeeesore Figura 3.7 Componentes del modelo 1S0-15504 Parte 1 ~ conceptos y guia introductoria, Parte 2 ~ modelo de referencia de procesos y capacidad Parte 3 ~ realizaciGn de evaluacidn. Parte 4 - guia para realizacién de evaluacién. Parte 5 ~ modelo de evaluacién y guia de indicadores, Parte 6 ~ guia para calificacion y entrenamiento de asesores. Parte 7 — guia para uso en mejora del proceso Parte 8 — guia de uso para determinar la capacidad del proceso de un pro- veedor. Paste 9 — vocabulario. CAP. 3 — PROCESO DE SOFTWARELas siguientes son algunas creencias del modelo de cascada ® Las metas se logran mejor cuando se tienen puntos de revision bien prees- tablecidos y documentados, dividiendo 1 desarrollo en actividades secuen- ciales bien definidas. © Los documentos técnicos son comprensibles para usuarios y acministrado- res no técnicos. © Cada detalle de los requisitos se conoce de antemano antes de desarrollar ¢l software, y los detalles son estables durante e! desarrollo. mies se realizan eficientemente al final del des- © Las pruebas y evaluaci arollo. 3.2.2 Incremental El modelo incremental es un desarrollo inicial de la arquitectura completa del sistema, seguido de incrementos y versiones parciales del mismo. Cada incre- mento tiene su propio ciclo de vida. Cada incremento agrega funcionalidad adi- cional o mejorada sobre el sistema, Conforme se completa cada etapa, se veri- fica € integra la versiGn con las demas versiones ya completadas del sistema. Durante cada increment, el sistema se evalia con respecto al desartollo de versiones futuras. Las actividades se dividen en procesos y subprocesos, dando lugar al término software factory. Para que la secuencia de desarrollo sea exi- tosa, es esencial definir etapas que no requieran cambiar los resultados anterio- res al agregar nuevas. Por lo tanto, es importante comprender al inicio los re- quisitos completos del sistema, algo que normalmente es muy dificil de lograr, Fl desarrollo incremental evita la teoria del “Big Bang” para el desarrollo de software, donde una gran explosién de desarrollo se transforma repentinamen- te en el sistema final Las siguientes son algunas creencias det modelo incremental: © La administracién de proyectos es mis ficil de lograr en incrementos mas pequeiios. @ Es mas ques. La funcionalidad inicial se desarrolla mas temprano, logrando resultados de inversién en menor tiempo. ¢ Hay mas probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del software en el tiempo, que si fueran plancados todos a la vez en un mismo period. cil comprender y probar incrementos de funcionalidad més pe-3.2.3 Evolucionario El modelo evolucionario ¢5 una eatensi6n al modelo incremental, donde los incrementos se hacen de manera secuencial en lugar de en paralelo.* Desde el punto de vista del cliente, el sistema evoluciona segtin se van entregando los incrementos. Desde el punto de vista del desarrollador, los requerimientos que son claros al principio del proyecto diciarin el incremento inicial, mientras que los incrementos para cada uno de los siguientes ciclos de desarrallo seran clarificados a través de la experiencia de los incrementos anteriores. Este mo- delo considera que el desarrollo de sistemas es un proceso de cambios progre- sivos mediante deltas de especificacion de requerimientos. En la figura 3.3 se ilustra este concepto. Primer ciclo de desarrollo peta 1 Delta 1 Dotta 2 Deta n Figura 3.3 Secuencia de versiones en el modelo evolucionario.3.2.4 Espiral El modelo de espiral,** desarrollado durante la década de los ochenta, es una extensién del modelo de cascada. A diferencia del modelo de cascacia, que es dirigido por documentos, el modelo de espiral se basa en una estrategia para reducir el riesgo del proyecto en areas de incertidumbre, como requerimientos iniciales incompletos e inestables. E] modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo, Cada ciclo comienza con la identificacién de los objetivos, soluciones alternativas, restric ciones asociadas con cada alternativa y, finalmente, se procede a su evaluaci6n, Cuando se identifica incertidumbre, se utlizan diversas técnicas para reducir el riesgo de las distintas alternativas. Cada ciclo del modelo de espiral termina con una revisiOn que discute los logros actuales y los planes para el siguiente ciclo. La figura 3.4 muestra un diagrama conceptual del modelo de espiral Disefio Analisis Version + Versi 2] vorsien 3 fista/ eta) | etaCiclo 0. Grupos de aplicaci6n. Se determina la viabilidad de un grupo apro- piado de aplicaciones. Ciclo 1. Objetivos del ciclo de vida de Ia aplicaci6n. Se desarrollan los ob- jetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitec- tura viable para cada aplicacién, Ciclo 2. Arquitectura del ciclo de vida de la aplicaci6n. Se establece una ar quitectura del ciclo de vida detallado, se verifica la viabilidad y determina que no existen riesgos mayores en satisfacer los planes y especificaciones Ciclo 3. Capacidad de operacién inicial. Alcanzar una capacidad operacional inicial para cada etapa critica del proyecto en el ciclo de vida del software.