Proceso de Software - Modelos del Proceso PDF

CAPÍTULO 2 MODELOS DEL PROCESO E CONCEPTOS CLAVE n un libro fascinante que expone el punto de vista de un econom...

CAPÍTULO 2 MODELOS DEL PROCESO E CONCEPTOS CLAVE n un libro fascinante que expone el punto de vista de un economista sobre el software conjunto de tareas......... 29 y su ingeniería, Howard Baetjer, Jr. [Bae98] comenta acerca del proceso del software. desarrollo basado en componentes.......... 43 Debido a que el software, como todo capital, es conocimiento incorporado y a que el conocimiento modelo de métodos originalmente se halla disperso, tácito, latente e incompleto en gran medida, el desarrollo de software formales................ 44 es un proceso de aprendizaje social. El proceso es un diálogo en el que el conocimiento que debe modelo general de proceso... 27 convertirse en software se reúne e incorpora en éste. El proceso genera interacción entre usuarios y modelos concurrentes...... 40 diseñadores, entre usuarios y herramientas cambiantes, y entre diseñadores y herramientas en evolu- modelos de proceso ción [tecnología]. Es un proceso que se repite y en el que la herramienta que evoluciona sirve por sí evolutivo............... 36 misma como medio para la comunicación: con cada nueva ronda del diálogo se genera más cono- modelos de proceso cimiento útil a partir de las personas involucradas. incremental.............. 35 modelos de proceso En realidad, la elaboración de software de computadora es un proceso reiterativo de apren- prescriptivo............. 33 dizaje social, y el resultado, algo que Baetjer llamaría “capital de software”, es la reunión de patrones del proceso....... 29 conocimiento recabado, depurado y organizado a medida que se realiza el proceso. proceso del equipo Pero desde el punto de vista técnico, ¿qué es exactamente un proceso del software? En el de software............. 49 contexto de este libro, se define proceso del software como una estructura para las actividades, proceso personal del software............. 48 acciones y tareas que se requieren a fin de construir software de alta calidad. ¿“Proceso” es si- proceso unificado......... 45 nónimo de “ingeniería de software”? La respuesta es “sí y no”. Un proceso del software define el enfoque adoptado mientras se hace ingeniería sobre el software. Pero la ingeniería de soft- ware también incluye tecnologías que pueblan el proceso: métodos técnicos y herramientas automatizadas. Más importante aún, la ingeniería de software es llevada a cabo por personas creativas y preparadas que deben adaptar un proceso maduro de software a fin de que resulte apropiado para los productos que construyen y para las demandas de su mercado. UNA MIRADA ¿Qué es? Cuando se trabaja en la construc- ¿Cuáles son los pasos? En un nivel detallado, el proceso RÁPIDA ción de un producto o sistema, es importante que se adopte depende del software que se esté elaboran- ejecutar una serie de pasos predecibles —el do. Un proceso puede ser apropiado para crear software mapa de carreteras que lo ayuda a obtener a destinado a un sistema de control electrónico de un aero- tiempo un resultado de alta calidad—. El mapa que se plano, mientras que para la creación de un sitio web será sigue se llama “proceso del software”. necesario un proceso completamente distinto. ¿Quién lo hace? Los ingenieros de software y sus geren- ¿Cuál es el producto final? Desde el punto de vista de tes adaptan el proceso a sus necesidades y luego lo un ingeniero de software, los productos del trabajo son los siguen. Además, las personas que solicitaron el software programas, documentos y datos que se producen como tienen un papel en el proceso de definición, elaboración y consecuencia de las actividades y tareas definidas por el prueba. proceso. ¿Por qué es importante? Porque da estabilidad, control ¿Cómo me aseguro de que lo hice bien? Hay cierto y organización a una actividad que puede volverse caótica número de mecanismos de evaluación del proceso del si se descontrola. Sin embargo, un enfoque moderno de software que permiten que las organizaciones determinen ingeniería de software debe ser “ágil”. Debe incluir sólo la “madurez” de su proceso. Sin embargo, la calidad, aquellas actividades, controles y productos del trabajo que oportunidad y viabilidad a largo plazo del producto que sean apropiados para el equipo del proyecto y para el se elabora son los mejores indicadores de la eficacia del producto que se busca obtener. proceso que se utiliza. 26 02Pressman(025-054).indd 26 14/1/10 13:36:44  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 27 2.1 UN MODELO GENERAL DE PROCESO En el capítulo 1 se definió un proceso como la colección de actividades de trabajo, acciones y tareas que se realizan cuando va a crearse algún producto terminado. Cada una de las activida- des, acciones y tareas se encuentra dentro de una estructura o modelo que define su relación tanto con el proceso como entre sí. En la figura 2.1 se representa el proceso del software de manera esquemática. En dicha fi- gura, cada actividad estructural está formada por un conjunto de acciones de ingeniería de software y cada una de éstas se encuentra definida por un conjunto de tareas que identifica las PU tareas del trabajo que deben realizarse, los productos del trabajo que se producirán, los puntos N TO de aseguramiento de la calidad que se requieren y los puntos de referencia que se utilizarán para CLAVE evaluar el avance. La jerarquía del trabajo técnico Como se dijo en el capítulo 1, una estructura general para la ingeniería de software define dentro del proceso del software es: actividades, acciones que contiene y cinco actividades estructurales: comunicación, planeación, modelado, construcción y tareas constituyentes. despliegue. Además, a lo largo de todo el proceso se aplica un conjunto de actividades som- FIGURA 2.1 Estructura de un Proceso del software proceso del software Estructura del proceso Actividades sombrilla actividad estructural # 1 acción de ingeniería de software # 1.1 tareas del trabajo Conjuntos productos del trabajo puntos de aseguramiento de la calidad de tareas puntos de referencia del proyecto acción de ingeniería de software # 1.k tareas del trabajo Conjuntos productos del trabajo puntos de aseguramiento de la calidad de tareas puntos de referencia del proyecto actividad estructural # n acción de ingeniería de software # n.1 tareas del trabajo Conjuntos productos del trabajo puntos de aseguramiento de la calidad de tareas puntos de referencia del proyecto acción de ingeniería de software # n.m tareas del trabajo Conjuntos productos del trabajo puntos de aseguramiento de la calidad de tareas puntos de referencia del proyecto 02Pressman(025-054).indd 27 14/1/10 13:36:45  28 PAR TE UNO E L P RO CE SO D EL S O FT WA RE brilla: seguimiento y control del proyecto, administración de riesgos, aseguramiento de la cali- dad, administración de la configuración, revisiones técnicas, entre otras. El lector debe observar que aún no se menciona un aspecto importante del proceso del soft- Cita: ware. En la figura 2.2 se ilustra dicho aspecto —llamado flujo del proceso— y se describe la “Pensamos que los desarrolla- manera en que están organizadas las actividades estructurales y las acciones y tareas que ocu- dores de software pierden de rren dentro de cada una con respecto de la secuencia y el tiempo. vista una verdad fundamental: Un flujo de proceso lineal ejecuta cada una de las cinco actividades estructurales en secuencia, la mayor parte de organizacio- comenzando por la comunicación y terminando con el despliegue (véase la figura 2.2a). Un flujo nes no saben lo que hacen. de proceso iterativo repite una o más de las actividades antes de pasar a la siguiente (véase la Piensan que lo saben, pero no es así.” figura 2.2b). Un flujo de proceso evolutivo realiza las actividades en forma “circular”. A través de las cinco actividades, cada circuito lleva a una versión más completa del software (véase la fi- Tom DeMarco gura 2.2c). Un flujo de proceso paralelo (véase la figura 2.2d) ejecuta una o más actividades en FIGURA 2.2 Flujo del proceso Comunicación Planeación Modelado Construcción Despliegue a) Flujo de proceso lineal Comunicación Planeación Modelado Construcción Despliegue b) Flujo de proceso iterativo Planeación Modelado Comunicación Incremento Despliegue Construcción obtenido c) Flujo de proceso evolutivo Comunicación Planeación Modelado Tiempo Construcción Despliegue d) Flujo de proceso paralelo 02Pressman(025-054).indd 28 14/1/10 13:36:45  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 29 paralelo con otras (por ejemplo, el modelado de un aspecto del software tal vez se ejecute en paralelo con la construcción de otro aspecto del software). 2.1.1 Definición de actividad estructural Aunque en el capítulo 1 se describieron cinco actividades estructurales y se dio una definición básica de cada una, un equipo de software necesitará mucha más información antes de poder ejecutar de manera apropiada cualquiera de ellas como parte del proceso del software. Por tanto, surge una pregunta clave: ¿qué acciones son apropiadas para una actividad estructural, dados la naturaleza del problema por resolver, las características de las personas que hacen el tra- bajo y los participantes que patrocinan el proyecto? ? ¿Cómo se transforma Para un proyecto de software pequeño solicitado por una persona (en una ubicación remota) una actividad con requerimientos sencillos y directos, la actividad de comunicación tal vez no incluya algo estructural cuando más que una llamada telefónica con el participante apropiado. Entonces, la única acción nece- cambia la naturaleza saria es una conversación telefónica, y las tareas del trabajo (el conjunto de tareas) que engloba del proyecto? son las siguientes: 1. Hacer contacto con el participante por vía telefónica. 2. Analizar los requerimientos y tomar notas. 3. Organizar las notas por escrito en una formulación breve de los requerimientos. 4. Enviar correo electrónico al participante para que revise y apruebe. Si el proyecto fuera considerablemente más complejo, con muchos participantes y cada uno con un distinto conjunto de requerimientos (a veces en conflicto), la actividad de comunicación puede tener seis acciones distintas (descritas en el capítulo 5): concepción, indagación, elabora- PU ción, negociación, especificación y validación. Cada una de estas acciones de la ingeniería del N TO software tendrá muchas tareas de trabajo y un número grande de diferentes productos finales. CLAVE Diferentes proyectos demandan 2.1.2 Identificación de un conjunto de tareas diferentes conjuntos de tareas. El equipo de software elige el conjunto En relación con la figura 2.1, cada acción de la ingeniería de software (por ejemplo, obtención, de tareas con base en las asociada a la actividad de comunicación) se representa por cierto número de distintos conjuntos características del problema y el de tareas, cada uno de los cuales es una colección de tareas de trabajo de la ingeniería de soft- proyecto. ware, relacionadas con productos del trabajo, puntos de aseguramiento de la calidad y puntos de referencia del proyecto. Debe escogerse el conjunto de tareas que se adapte mejor a las ne- cesidades del proyecto y a las características del equipo. Esto implica que una acción de la in- geniería de software puede adaptarse a las necesidades específicas del proyecto de software y a las características del equipo del proyecto. 2.1.3 Patrones del proceso ? ¿Qué es un patrón del Cada equipo de software se enfrenta a problemas conforme avanza en el proceso del software. proceso? Si se demostrara que existen soluciones fáciles para dichos problemas, sería útil para el equipo abordarlos y resolverlos rápidamente. Un patrón del proceso1 describe un problema relacionado con el proceso que se encuentra durante el trabajo de ingeniería de software, identifica el am- biente en el que surge el problema y sugiere una o más soluciones para el mismo. Dicho de manera general, un patrón de proceso da un formato [Amb98]: un método consistente para describir soluciones del problema en el contexto del proceso del software. Al combinar patro- nes, un equipo de software resuelve problemas y construye el proceso que mejor satisfaga las necesidades de un proyecto. 1 En el capítulo 12 se hace el análisis detallado de los patrones. 02Pressman(025-054).indd 29 14/1/10 13:36:45  30 PAR TE UNO E L P RO CE SO D EL S O FT WA RE I NFOR MACIÓN Conjunto de tareas 3. Formar la lista preliminar de las funciones y características con Un conjunto de tareas define el trabajo real por efectuar a base en las aportaciones del participante. fin de cumplir los objetivos de una acción de ingeniería de 4. Programar una serie de reuniones para facilitar la elaboración software. Por ejemplo, la indagación (mejor conocida como “recabar de las especificaciones de la aplicación. los requerimientos”) es una acción importante de la ingeniería de soft- 5. Celebrar las reuniones. ware que ocurre durante la actividad de comunicación. La meta al 6. Producir en cada reunión escenarios informales de usuario. recabar los requerimientos es entender lo que los distintos participan- 7. Afinar los escenarios del usuario con base en la retroalimenta- tes desean del software que se va a elaborar. ción de los participantes. Para un proyecto pequeño y relativamente sencillo, el conjunto de 8. Formar una lista revisada de los requerimientos de los partici- tareas para la indagación de requerimientos tendrá un aspecto pare- pantes. cido al siguiente: 9. Usar técnicas de despliegue de la función de calidad para asig- nar prioridades a los requerimientos. 1. Elaborar la lista de participantes del proyecto. 10. Agrupar los requerimientos de modo que puedan entregarse en 2. Invitar a todos los participantes a una reunión informal. forma paulatina y creciente. 3. Pedir a cada participante que haga una relación de las caracte- 11. Resaltar las limitantes y restricciones que se introducirán al sis- rísticas y funciones que requiere. tema. 4. Analizar los requerimientos y construir la lista definitiva. 12. Analizar métodos para validar el sistema. 5. Ordenar los requerimientos según su prioridad. 6. Identificar las áreas de incertidumbre. Los dos conjuntos de tareas mencionados sirven para “recabar los requerimientos”, pero son muy distintos en profundidad y formalidad. Para un proyecto de software más grande y complejo se requerirá El equipo de software elige el conjunto de tareas que le permita de un conjunto de tareas diferente que quizá esté constituido por las alcanzar la meta de cada acción con calidad y agilidad. siguientes tareas de trabajo: 1. Hacer la lista de participantes del proyecto. 2. Entrevistar a cada participante por separado a fin de determi- nar los deseos y necesidades generales. Los patrones se definen en cualquier nivel de abstracción.2 En ciertos casos, un patrón puede Cita: usarse para describir un problema (y su solución) asociado con un modelo completo del proceso (por ejemplo, hacer prototipos). En otras situaciones, los patrones se utilizan para describir un “La repetición de patrones es algo muy diferente de la repeti- problema (y su solución) asociado con una actividad estructural (por ejemplo, planeación) o ción de las partes. En realidad, una acción dentro de una actividad estructural (estimación de proyectos). las distintas partes serán únicas Ambler [Amb98] ha propuesto un formato para describir un patrón del proceso: porque los patrones son los mis- mos.” Nombre del patrón. El patrón recibe un nombre significativo que lo describe en el con- texto del proceso del software (por ejemplo, RevisionesTécnicas). Christopher Alexander Fuerzas. El ambiente en el que se encuentra el patrón y los aspectos que hacen visible el problema y afectan su solución. PU Tipo. Se especifica el tipo de patrón. Ambler [Amb98] sugiere tres tipos: NT O 1. Patrón de etapa: define un problema asociado con una actividad estructural para el CLAVE proceso. Como una actividad estructural incluye múltiples acciones y tareas del tra- Un formato de patrón proporciona un bajo, un patrón de la etapa incorpora múltiples patrones de la tarea (véase a conti- medio consistente para describir al nuación) que son relevantes para la etapa (actividad estructural). Un ejemplo de pa- patrón. trón de etapa sería EstablecerComunicación. Este patrón incorporaría el patrón de tarea RecabarRequerimientos y otros más. 2. Patrón de tarea: define un problema asociado con una acción o tarea de trabajo de la ingeniería de software y que es relevante para el éxito de la práctica de ingeniería de software (por ejemplo, RecabarRequerimientos es un patrón de tarea). 2 Los patrones son aplicables a muchas actividades de la ingeniería de software. El análisis, el diseño y la prueba de patrones se estudian en los capítulos 7, 9, 10, 12 y 14. Los patrones y “antipatrones” para las actividades de administración de proyectos se analizan en la parte 4 del libro. 02Pressman(025-054).indd 30 14/1/10 13:36:45  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 31 3. Patrón de fase: define la secuencia de las actividades estructurales que ocurren dentro del proceso, aun cuando el flujo general de las actividades sea de naturaleza iterativa. Un ejemplo de patrón de fase es ModeloEspiral o Prototipos.3 Contexto inicial. Describe las condiciones en las que se aplica el patrón. Antes de iniciar el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el equipo han ocurrido? 2) ¿Cuál es el estado de entrada para el proceso? 3) ¿Qué información de ingeniería de soft- ware o del proyecto ya existe? Por ejemplo, el patrón Planeación (patrón de etapa) requiere que: 1) los clientes y los ingenieros de software hayan establecido una comunicación colaboradora; 2) haya termi- nado con éxito cierto número de patrones de tarea [especificado] para el patrón Comuni- cación; y 3) se conozcan el alcance del proyecto, los requerimientos básicos del negocio y las restricciones del proyecto. Problema. El problema específico que debe resolver el patrón. Solución. Describe cómo implementar con éxito el patrón. Esta sección describe la forma en la que se modifica el estado inicial del proceso (que existe antes de implementar el pa- trón) como consecuencia de la iniciación del patrón. También describe cómo se transforma la información sobre la ingeniería de software o sobre el proyecto, disponible antes de que inicie el patrón, como consecuencia de la ejecución exitosa del patrón. Contexto resultante. Describe las condiciones que resultarán una vez que se haya im- plementado con éxito el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el equipo deben haber ocurrido? 2) ¿Cuál es el estado de salida del proceso? 3) ¿Qué informa- ción sobre la ingeniería de software o sobre el proyecto se ha desarrollado? Patrones relacionados. Proporciona una lista de todos los patrones de proceso directa- mente relacionados con éste. Puede representarse como una jerarquía o en alguna forma de diagrama. Por ejemplo, el patrón de etapa Comunicación incluye los patrones de tarea: EquipoDelProyecto, LineamientosDeColaboración, DefiniciónDeAlcances, Reca- barRequerimientos, DescripciónDeRestricciones y CreaciónDeEscenarios. Usos y ejemplos conocidos. Indica las instancias específicas en las que es aplicable el patrón. Por ejemplo, Comunicación es obligatoria al principio de todo proyecto de soft- ware, es recomendable a lo largo del proyecto y de nuevo obligatoria una vez alcanzada la actividad de despliegue. Los patrones de proceso dan un mecanismo efectivo para enfrentar problemas asociados con WebRef cualquier proceso del software. Los patrones permiten desarrollar una descripción jerárquica En la dirección www.ambysoft. del proceso, que comienza en un nivel alto de abstracción (un patrón de fase). Después se me- com/processPatternsPage.html jora la descripción como un conjunto de patrones de etapa que describe las actividades estruc- se encuentran recursos amplios sobre turales y se mejora aún más en forma jerárquica en patrones de tarea más detallados para cada los patrones de proceso. patrón de etapa. Una vez desarrollados los patrones de proceso, pueden reutilizarse para la definición de variantes del proceso, es decir, un equipo de software puede definir un modelo de proceso específico con el empleo de los patrones como bloques constituyentes del modelo del proceso. 2.2 EVALUACIÓN Y MEJORA DEL PROCESO La existencia de un proceso del software no es garantía de que el software se entregue a tiempo, que satisfaga las necesidades de los consumidores o que tenga las características técnicas que 3 Estos patrones de fase se estudian en la sección 2.3.3. 02Pressman(025-054).indd 31 14/1/10 13:36:46  32 PAR TE UNO E L P RO CE SO D EL S O FT WA RE I NFOR MACIÓN Ejemplo de patrón de proceso debe hacerse con una solución de software. Los participantes no están El siguiente patrón de proceso abreviado describe un seguros de lo que quieren, es decir, no pueden describir con detalle enfoque aplicable en el caso en el que los participantes los requerimientos del software. tienen una idea general de lo que debe hacerse, pero no están segu- Solución. Aquí se presentaría una descripción del proceso prototi- ros de los requerimientos específicos de software. po, que se describirá más adelante, en la sección 2.3.3. Nombre del patrón. RequerimientosPocoClaros Contexto resultante. Los participantes aprueban un prototipo de Intención. Este patrón describe un enfoque para construir un mode- software que identifica los requerimientos básicos (por ejemplo, lo (un prototipo) que los participantes pueden evaluar en forma itera- modos de interacción, características computacionales, funciones de tiva, en un esfuerzo por identificar o solidificar los requerimientos de procesamiento). Después de esto, 1) el prototipo quizá evolucione a software. través de una serie de incrementos para convertirse en el software de producción, o 2) tal vez se descarte el prototipo y el software de pro- Tipo. Patrón de fase. ducción se elabore con el empleo de otro proceso de patrón. Contexto inicial. Antes de iniciar este patrón deben cumplirse las Patrones relacionados. Los patrones siguientes están relaciona- siguientes condiciones: 1) se ha identificado a los participantes; 2) se dos con este patrón: ComunicaciónConClientes, DiseñoItera- ha establecido un modo de comunicación entre los participantes y el tivo, DesarrolloIterativo, EvaluaciónDelCliente, Obten- equipo de software; 3) los participantes han identificado el problema ciónDeRequerimientos. general de software que se va a resolver; 4) se ha obtenido el enten- dimiento inicial del alcance del proyecto, los requerimientos básicos Usos y ejemplos conocidos. Cuando los requerimientos sean del negocio y las restricciones del proyecto. inciertos, es recomendable hacer prototipos. Problema. Los requerimientos son confusos o inexistentes, pero hay un reconocimiento claro de que existe un problema por resolver y que PU conducirán a características de calidad de largo plazo (véanse los capítulos 14 y 16). Los patro- NT O nes de proceso deben acoplarse con una práctica sólida de ingeniería de software (véase la parte CLAVE 2 del libro). Además, el proceso en sí puede evaluarse para garantizar que cumple con ciertos La evaluación busca entender el criterios de proceso básicos que se haya demostrado que son esenciales para el éxito de la in- estado actual del proceso del geniería de software.4 software con el objeto de mejorarlo. En las últimas décadas se han propuesto numerosos enfoques para la evaluación y mejora de un proceso del software: Método de evaluación del estándar CMMI para el proceso de mejora (SCAMPI, por ? ¿De qué técnicas formales se dispone sus siglas en inglés): proporciona un modelo de cinco fases para evaluar el proceso: inicio, para evaluar el proceso diagnóstico, establecimiento, actuación y aprendizaje. El método SCAMPI emplea el SEI del software? CMMI como la base de la evaluación [SEI00]. Evaluación basada en CMM para la mejora del proceso interno (CBA IPI, por sus si- Cita: glas en inglés): proporciona una técnica de diagnóstico para evaluar la madurez relativa de una organización de software; usa el SEI CMM como la base de la evaluación [Dun01]. “Las organizaciones de software tienen deficiencias significativas SPICE (ISO/IEC 15504): estándar que define un conjunto de requerimientos para la eva- en su capacidad de capitalizar luación del proceso del software. El objetivo del estándar es ayudar a las organizaciones a las experiencias obtenidas de los desarrollar una evaluación objetiva de cualquier proceso del software definido [ISO08]. proyectos terminados.” ISO9001:2000 para software: estándar genérico que se aplica a cualquier organización NASA que desee mejorar la calidad general de los productos, sistemas o servicios que propor- ciona. Por tanto, el estándar es directamente aplicable a las organizaciones y compañías de software [Ant06]. En el capítulo 30 se presenta un análisis detallado de los métodos de evaluación del software y del proceso de mejora. 4 En la publicación CMMI [CMM07] del SEI, se describen con muchos detalles las características de un proceso del software y los criterios para un proceso exitoso. 02Pressman(025-054).indd 32 14/1/10 13:36:46  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 33 2.3 MODELOS DE PROCESO PRESCRIPTIVO Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonable- mente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera siguen “al borde del caos”. En un artículo intrigante sobre la extraña relación entre el orden y el caos en el mundo del Cita: software, Nogueira y sus colegas [Nog00] afirman lo siguiente: “Si el proceso está bien, los El borde del caos se define como “el estado natural entre el orden y el caos, un compromiso grande resultados cuidarán de sí mis- entre la estructura y la sorpresa” [Kau95]. El borde del caos se visualiza como un estado inestable y mos.” parcialmente estructurado […] Es inestable debido a que se ve atraído constantemente hacia el caos Takashi Osada o hacia el orden absoluto. Tenemos la tendencia de pensar que el orden es el estado ideal de la naturaleza. Esto podría ser un error […] las investigaciones apoyan la teoría de que la operación que se aleja del equilibrio genera creatividad, procesos autoorganizados y rendimientos crecientes [Roo96]. El orden absoluto significa ausencia de variabilidad, que podría ser una ventaja en los ambientes impredecibles. El cambio ocurre cuando hay cierta estructura que permita que el cambio pueda organizarse, pero que no sea tan rígi- da como para que no pueda suceder. Por otro lado, demasiado caos hace imposible la coordinación y la coherencia. La falta de estructura no siempre significa desorden. PU Las implicaciones filosóficas de este argumento son significativas para la ingeniería de software. N TO Si los modelos de proceso prescriptivo5 buscan generar estructura y orden, ¿son inapropiados CLAVE para el mundo del software, que se basa en el cambio? Pero si rechazamos los modelos de pro- Los modelos de proceso prescriptivo ceso tradicional (y el orden que implican) y los reemplazamos con algo menos estructurado, definen un conjunto prescrito de ¿hacemos imposible la coordinación y coherencia en el trabajo de software? elementos del proceso y un flujo predecible para el trabajo del No hay respuestas fáciles para estas preguntas, pero existen alternativas disponibles para los proceso. ingenieros de software. En las secciones que siguen se estudia el enfoque de proceso prescrip- tivo en el que los temas dominantes son el orden y la consistencia del proyecto. El autor los llama “prescriptivos” porque prescriben un conjunto de elementos del proceso: actividades es- tructurales, acciones de ingeniería de software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos de control del cambio para cada proyecto. Cada modelo del proceso también prescribe un flujo del proceso (también llamado flujo de trabajo), es decir, la manera en la que los elementos del proceso se relacionan entre sí. Todos los modelos del proceso del software pueden incluir las actividades estructurales ge- nerales descritas en el capítulo 1, pero cada una pone distinto énfasis en ellas y define en forma diferente el flujo de proceso que invoca cada actividad estructural (así como acciones y tareas de ingeniería de software). 2.3.1 Modelo de la cascada Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando el trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras bien defi- nidas a un sistema ya existente (por ejemplo, una adaptación para software de contabilidad que es obligatorio hacer debido a cambios en las regulaciones gubernamentales). También ocurre en cierto número limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los requerimien- tos están bien definidos y tienen una estabilidad razonable. 5 Los modelos de proceso prescriptivo en ocasiones son denominados modelos de proceso “tradicional”. 02Pressman(025-054).indd 33 14/1/10 13:36:46  34 PAR TE UNO E L P RO CE SO D EL S O FT WA RE FIGURA 2.3 Modelo de la cascada Comunicación inicio del proyecto Planeación estimación Modelado recabar los requerimientos análisis Construcción programación código Despliegue seguimiento diseño entrega pruebas asistencia retroalimentación El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial6 para el desarrollo del software, que comienza con la especificación de los reque- rimientos por parte del cliente y avanza a través de planeación, modelado, construcción y des- pliegue, para concluir con el apoyo del software terminado (véase la figura 2.3). PU Una variante de la representación del modelo de la cascada se denomina modelo en V. En la NT O figura 2.4 se ilustra el modelo en V [Buc99], donde se aprecia la relación entre las acciones para CLAVE el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construc- El modelo en V ilustra la forma en la que se asocian las acciones de ción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo verificación y validación con las de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada primeras acciones de ingeniería. vez más detalladas del problema y de su solución. Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo.7 En realidad, no hay diferencias fundamentales entre el ciclo de vida clásico y el modelo en V. Este último proporciona una forma de visualizar el modo de aplicación de las acciones de verificación y validación al trabajo de ingeniería inicial. El modelo de la cascada es el paradigma más antiguo de la ingeniería de software. Sin em- bargo, en las últimas tres décadas, las críticas hechas al modelo han ocasionado que incluso sus defensores más obstinados cuestionen su eficacia [Han95]. Entre los problemas que en ocasio- nes surgen al aplicar el modelo de la cascada se encuentran los siguientes: ? ¿Por qué a veces falla 1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aun- el modelo de la que el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, cascada? los cambios generan confusión conforme el equipo del proyecto avanza. 2. A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimien- tos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la in- certidumbre natural que existe al principio de muchos proyectos. 3. El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los) programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso Cita: si se detectara hasta revisar el programa en funcionamiento. “Con demasiada frecuencia, el En un análisis interesante de proyectos reales, Bradac [Bra94] encontró que la naturaleza trabajo de software sigue la pri- lineal del ciclo de vida clásico llega a “estados de bloqueo” en los que ciertos miembros del mera ley del ciclismo: no equipo de proyecto deben esperar a otros a fin de terminar tareas interdependientes. En reali- importa hacia dónde te dirijas, dad, ¡el tiempo de espera llega a superar al dedicado al trabajo productivo! Los estados de vas hacia arriba y contra el bloqueo tienden a ocurrir más al principio y al final de un proceso secuencial lineal. viento.” Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios Anónimo (en las características, funciones y contenido de información). El modelo de la cascada suele ser 6 Aunque el modelo de la cascada propuesto originalmente por Winston Royce [Roy70] prevé los “bucles de retroa- limentación”, la gran mayoría de organizaciones que aplican este modelo de proceso lo tratan como si fuera estrictamente lineal. 7 En la parte 3 del libro se estudian con detalle las acciones de aseguramiento de la calidad. 02Pressman(025-054).indd 34 14/1/10 13:36:47  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 35 FIGURA 2.4 El modelo en V Modelado de los Pruebas de requerimientos aceptación Diseño de la Pruebas arquitectura del sistema Diseño de los Pruebas de componentes integración Generación Pruebas de código unitarias Software ejecutable inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situa- ciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final. 2.3.2 Modelos de proceso incremental PU Hay muchas situaciones en las que los requerimientos iniciales del software están razonable- N TO mente bien definidos, pero el alcance general del esfuerzo de desarrollo imposibilita un proceso CLAVE lineal. Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta funcionalidad El modelo incremental ejecuta una limitada de software a los usuarios y aumentarla en las entregas posteriores de software. En serie de avances, llamados tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. incrementos, que en forma progresiva dan más funcionalidad al El modelo incremental combina elementos de los flujos de proceso lineal y paralelo estudia- cliente conforme se le entrega cada dos en la sección 2.1. En relación con la figura 2.5, el modelo incremental aplica secuencias li- incremento. neales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse [McD93] de manera pare- cida a los incrementos producidos en un flujo de proceso evolutivo (sección 2.3.3). Por ejemplo, un software para procesar textos que se elabore con el paradigma incremental quizá entregue en el primer incremento las funciones básicas de administración de archivos, edición y producción del documento; en el segundo dará herramientas más sofisticadas de edi- ción y producción de documentos; en el tercero habrá separación de palabras y revisión de la CONSEJO ortografía; y en el cuarto se proporcionará la capacidad para dar formato avanzado a las pági- Su cliente solicita la entrega para nas. Debe observarse que el flujo de proceso para cualquier incremento puede incorporar el una fecha que es imposible de paradigma del prototipo. cumplir. Sugiera entregar uno o más Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el pro- incrementos en la fecha que pide, y ducto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan el resto del software (incrementos adicionales) en un momento muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto posterior. fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, 02Pressman(025-054).indd 35 14/1/10 13:36:47  36 PAR TE UNO E L P RO CE SO D EL S O FT WA RE FIGURA 2.5 Comunicación El modelo Funcionalidad y características del software incremental Planeación Modelado (análisis, diseño) incremento # n Construcción (código, prueba) Despliegue (entrega, retroalimentación) entrega del n-ésimo incremento # 2 incremento entrega del segundo incremento # 1 incremento entrega del primer incremento Calendario del proyecto se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de caracterís- ticas adicionales y más funcionalidad. Este proceso se repite después de entregar cada incre- mento, hasta terminar el producto final. El modelo de proceso incremental se centra en que en cada incremento se entrega un pro- ducto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación.8 El desarrollo incremental es útil en particular cuando no se dispone de personal para la im- plementación completa del proyecto en el plazo establecido por el negocio. Los primeros incre- mentos se desarrollan con pocos trabajadores. Si el producto básico es bien recibido, entonces se agrega más personal (si se requiere) para que labore en el siguiente incremento. Además, los incrementos se planean para administrar riesgos técnicos. Por ejemplo, un sistema grande tal vez requiera que se disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha de entrega sea incierta. En este caso, tal vez sea posible planear los primeros incrementos de forma que eviten el uso de dicho hardware, y así proporcionar una funcionalidad parcial a los usuarios finales sin un retraso importante. 2.3.3 Modelos de proceso evolutivo PU El software, como todos los sistemas complejos, evoluciona en el tiempo. Es frecuente que los NT O requerimientos del negocio y del producto cambien conforme avanza el desarrollo, lo que hace CLAVE que no sea realista trazar una trayectoria rectilínea hacia el producto final; los plazos apretados El modelo del proceso evolutivo del mercado hacen que sea imposible la terminación de un software perfecto, pero debe lan- genera en cada iteración una versión zarse una versión limitada a fin de aliviar la presión de la competencia o del negocio; se com- final cada vez más completa del software. prende bien el conjunto de requerimientos o el producto básico, pero los detalles del producto o extensiones del sistema aún están por definirse. En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado explícitamente para adaptarse a un producto que evo- luciona con el tiempo. Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. En los párrafos que siguen se pre- sentan dos modelos comunes de proceso evolutivo. 8 Es importante observar que para todos los modelos de proceso “ágiles” que se estudian en el capítulo 3 también se usa la filosofía incremental. 02Pressman(025-054).indd 36 14/1/10 13:36:48  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 37 Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales para Cita: el software, pero que no identifique los requerimientos detallados para las funciones y caracte- rísticas. En otros casos, el desarrollador tal vez no esté seguro de la eficiencia de un algoritmo, “Planee para lanzar uno. De todos modos hará eso. Su única de la adaptabilidad de un sistema operativo o de la forma que debe adoptar la interacción entre elección es si tratará de vender el humano y la máquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos a sus clientes lo que lanzó.” tal vez ofrezca el mejor enfoque. Frederick P. Brooks Aunque es posible hacer prototipos como un modelo de proceso aislado, es más común usarlo como una técnica que puede implementarse en el contexto de cualquiera de los modelos de proceso descritos en este capítulo. Sin importar la manera en la que se aplique, el paradigma de hacer prototipos le ayudará a usted y a otros participantes a mejorar la comprensión de lo que hay que elaborar cuando los requerimientos no están claros. El paradigma de hacer prototipos (véase la figura 2.6) comienza con comunicación. Usted se CONSEJO reúne con otros participantes para definir los objetivos generales del software, identifica cuales- Cuando su cliente tiene una quiera requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor necesidad legítima, pero ignora los definición. Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el detalles, como primer paso desarrolle modelado (en forma de un “diseño rápido”). Éste se centra en la representación de aquellos un prototipo. aspectos del software que serán visibles para los usuarios finales (por ejemplo, disposición de la interfaz humana o formatos de la pantalla de salida). El diseño rápido lleva a la construcción de un prototipo. Éste se entrega y es evaluado por los participantes, que dan retroalimenta- ción para mejorar los requerimientos. La iteración ocurre a medida de que el prototipo es afi- nado para satisfacer las necesidades de distintos participantes, y al mismo tiempo le permite a usted entender mejor lo que se necesita hacer. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas existen- tes o aplicar herramientas (por ejemplo, generadores de reportes y administradores de venta- nas) que permitan generar rápidamente programas que funcionen. Pero, ¿qué hacer con el prototipo cuando ya sirvió para el propósito descrito? Brooks [Bro95] da una respuesta: En la mayoría de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy lento, muy grande, difícil de usar o todo a la vez. No hay más alternativa que comenzar de nuevo, con más inteligencia, y construir una versión rediseñada en la que se resuelvan los problemas. FIGURA 2.6 El paradigma de hacer prototipos Plan rápido Comunicación Modelado Diseño rápido Despliegue Entrega y Construcción Retroalimentación del prototipo 02Pressman(025-054).indd 37 14/1/10 13:36:48  38 PAR TE UNO E L P RO CE SO D EL S O FT WA RE El prototipo sirve como “el primer sistema”. Lo que Brooks recomienda es desecharlo. Pero esto quizá sea un punto de vista idealizado. Aunque algunos prototipos se construyen para ser “desechables”, otros son evolutivos; es decir, poco a poco se transforman en el sistema real. Tanto a los participantes como a los ingenieros de software les gusta el paradigma de hacer prototipos. Los usuarios adquieren la sensación del sistema real, y los desarrolladores logran construir algo de inmediato. No obstante, hacer prototipos llega a ser problemático por las si- guientes razones: 1. Los participantes ven lo que parece ser una versión funcional del software, sin darse CONSEJO cuenta de que el prototipo se obtuvo de manera caprichosa; no perciben que en la prisa Resista la presión para convertir un por hacer que funcionara, usted no consideró la calidad general del software o la facili- prototipo burdo en un producto dad de darle mantenimiento a largo plazo. Cuando se les informa que el producto debe terminado. Como resultado de ello, rehacerse a fin de obtener altos niveles de calidad, los participantes gritan que es usted casi siempre disminuye la calidad. un tonto y piden “unos cuantos arreglos” para hacer del prototipo un producto funcio- nal. Con demasiada frecuencia, el gerente de desarrollo del software cede. 2. Como ingeniero de software, es frecuente que llegue a compromisos respecto de la im- plementación a fin de hacer que el prototipo funcione rápido. Quizá utilice un sistema operativo inapropiado, o un lenguaje de programación tan sólo porque cuenta con él y lo conoce; tal vez implementó un algoritmo ineficiente sólo para demostrar capacidad. Después de un tiempo, quizá se sienta cómodo con esas elecciones y olvide todas las razones por las que eran inadecuadas. La elección de algo menos que lo ideal ahora ha pasado a formar parte del sistema. Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la ingeniería de software. La clave es definir desde el principio las reglas del juego; es decir, todos los parti- cipantes deben estar de acuerdo en que el prototipo sirva como el mecanismo para definir los requerimientos. Después se descartará (al menos en parte) y se hará la ingeniería del software real con la mirada puesta en la calidad. C ASA S EGURA Selección de un modelo de proceso, Doug: Es cierto, pero no sin muchos sobresaltos, y este proyecto parte 1 parece más grande y complejo que cualquier cosa que hayamos hecho antes. La escena: Sala de juntas del grupo de ingeniería de software de Jamie: No parece tan mal, pero estoy de acuerdo… nuestro enfo- CPI Corporation, compañía (ficticia) que manufactura artículos de que ad hoc de los proyectos anteriores no funcionará en éste, en consumo para el hogar y para uso comercial. particular si tenemos una fecha de entrega muy apretada. Participantes: Lee Warren, gerente de ingeniería; Doug Miller, Doug (sonríe): Quiero ser un poco más profesional en nuestro gerente de ingeniería de software; Jamie Lazar, miembro del equipo enfoque. La semana pasada asistí a un curso breve y aprendí mucho de software; Vinod Raman, miembro del equipo de software; y Ed sobre ingeniería de software… algo bueno. Aquí necesitamos un Robbins, miembro del equipo de software. proceso. La conversación: Jamie (con el ceño fruncido): Mi trabajo es producir progra- Lee: Recapitulemos. He dedicado algún tiempo al análisis de la mas de computadora, no papel. línea de productos CasaSegura, según la vemos hasta el momento. Doug: Den una oportunidad antes de ser tan negativos conmigo. Lo No hay duda de que hemos efectuado mucho trabajo tan sólo para que quiero decir es esto: [Doug pasa a describir la estructura del definir el concepto, pero me gustaría que ustedes comenzaran a pen- proceso vista en este capítulo y los modelos de proceso prescriptivo sar en cómo van a enfocar la parte del software de este proyecto. presentados hasta el momento.] Doug: Pareciera que en el pasado hemos estado muy desorganiza- Doug: De cualquier forma, parece que un modelo lineal no es para dos en nuestro enfoque del software. nosotros… pues supone que conocemos todos los requerimientos y, Ed: No sé, Doug, siempre sacamos el producto. conociendo esta empresa, eso no parece probable. 02Pressman(025-054).indd 38 14/1/10 13:36:48  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 39 Vinod: Sí, y parece demasiado orientado a las tecnologías de Vinod: Eso es un problema. Me preocupa que no nos dé suficiente información… tal vez sea bueno para hacer un sistema de control de estructura. inventarios o algo así, pero no parece bueno para CasaSegura. Doug: No te preocupes. Tenemos muchas opciones más, y quisiera Doug: Estoy de acuerdo. que ustedes, muchachos, elijan la que sea mejor para el equipo y Ed: Ese enfoque de hacer prototipos parece bueno. En todo caso, se para el proyecto. asemeja mucho a lo que hacemos aquí. El modelo espiral. Propuesto en primer lugar por Barry Boehm [Boe88], el modelo espiral es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas. Boehm [Boe01a] describe el modelo del modo siguiente: El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en soft- ware. Tiene dos características distintivas principales. La primera es el enfoque cíclico para el creci- miento incremental del grado de definición de un sistema y su implementación, mientras que dismi- nuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias. Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. PU Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las N TO iteraciones posteriores se producen versiones cada vez más completas del sistema cuya inge- CLAVE niería se está haciendo. El modelo en espiral se adapta para Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades emplearse a lo largo de todo el ciclo de vida de una aplicación, desde el estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya ana- desarrollo del concepto hasta el lizadas.9 Cada una de ellas representa un segmento de la trayectoria espiral ilustrada en la figura mantenimiento. 2.7. Al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un FIGURA 2.7 Planeación Modelo de espiral estimación común programación análisis de riesgo Comunicación Modelado análisis diseño Inicio Despliegue Construcción entrega código retroalimentación prueba 9 El modelo espiral estudiado en esta sección es una variante del propuesto por Boehm. Para más información acerca del modelo espiral original, consulte [Boe88]. En [Boe98] se encuentra un análisis más reciente del modelo espiral del mismo autor. 02Pressman(025-054).indd 39 14/1/10 13:36:48  40 PAR TE UNO E L P RO CE SO D EL S O FT WA RE circuito alrededor de la espiral en el sentido horario, partiendo del centro. El riesgo se considera conforme se desarrolla cada revolución (capítulo 28). En cada paso evolutivo se marcan puntos de referencia puntuales: combinación de productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria de la espiral. El primer circuito alrededor de la espiral da como resultado el desarrollo de una especifica- ción del producto; las vueltas sucesivas se usan para desarrollar un prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso por la región de planeación da como resul- tado ajustes en el plan del proyecto. El costo y la programación de actividades se ajustan con base en la retroalimentación obtenida del cliente después de la entrega. Además, el gerente del proyecto ajusta el número planeado de iteraciones que se requieren para terminar el software. WebRef A diferencia de otros modelos del proceso que finalizan cuando se entrega el software, En la dirección www.sei.cmu. el modelo espiral puede adaptarse para aplicarse a lo largo de toda la vida del software de edu/publications/ cómputo. Entonces, el primer circuito alrededor de la espiral quizá represente un “proyecto documents/00.reports/ de desarrollo del concepto” que comienza en el centro de la espiral y continúa por iteraciones 00sr008.html se encuentra información útil sobre el modelo múltiples10 hasta que queda terminado el desarrollo del concepto. Si el concepto va a desarro- espiral. llarse en un producto real, el proceso sigue hacia fuera de la espiral y comienza un “proyecto de desarrollo de producto nuevo”. El nuevo producto evolucionará a través de cierto número de iteraciones alrededor de la espiral. Más adelante puede usarse un circuito alrededor de la espiral para que represente un “proyecto de mejora del producto”. En esencia, la espiral, cuando se CONSEJO caracteriza de este modo, sigue operativa hasta que el software se retira. Hay ocasiones en las que el proceso está inmóvil, pero siempre que se inicia un cambio comienza en el punto de Si su administración pide un entrada apropiado (por ejemplo, mejora del producto). desarrollo apegado al presupuesto (mala idea, por lo general), la El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software a gran espiral se convierte en un problema. escala. Como el software evoluciona a medida que el proceso avanza, el desarrollador y cliente El costo se revisa y modifica cada comprenden y reaccionan mejor ante los riesgos en cada nivel de evolución. El modelo espiral vez que se termina un circuito. usa los prototipos como mecanismo de reducción de riesgos, pero, más importante, permite aplicar el enfoque de hacer prototipos en cualquier etapa de la evolución del producto. Mantiene el enfoque de escalón sistemático sugerido por el ciclo de vida clásico, pero lo incorpora en una estructura iterativa que refleja al mundo real en una forma más realista. El modelo espiral de- manda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si Cita: se aplica de manera apropiada, debe reducir los riesgos antes de que se vuelvan un problema. “Sólo voy aquí y sólo el mañana Pero, como otros paradigmas, el modelo espiral no es una panacea. Es difícil convencer a los me guía.” clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Demanda mucha experiencia en la evaluación del riesgo y se basa en ella para llegar al éxito. Dave Matthews Band No hay duda de que habrá problemas si algún riesgo importante no se descubre y administra. 2.3.4 Modelos concurrentes El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que CONSEJO un equipo de software represente elementos iterativos y concurrentes de cualquiera de los mo- delos de proceso descritos en este capítulo. Por ejemplo, la actividad de modelado definida para Con frecuencia, el modelo el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de soft- concurrente es más apropiado para proyectos de ingeniería de productos ware: hacer prototipos, análisis y diseño.11 en los que se involucran varios La figura 2.8 muestra la representación esquemática de una actividad de ingeniería de soft- equipos de trabajo. ware dentro de la actividad de modelado con el uso del enfoque de modelado concurrente. La 10 Las flechas que apuntan hacia dentro a lo largo del eje que separa la región del despliegue de la de comunica- ción indican un potencial para la iteración local a lo largo de la misma trayectoria espiral. 11 Debe observarse que el análisis y diseño son tareas complejas que requieren mucho análisis. La parte 2 de este libro considera en detalle dichos temas. 02Pressman(025-054).indd 40 14/1/10 13:36:49  CAP Í TUL O 2 MO DELO S D EL P R O C E S O 41 C ASA S EGURA Selección de un modelo de proceso, otro incremento. También se ajusta a la naturaleza del producto. parte 2 Podemos lanzar con rapidez algo al mercado y luego agregar fun- cionalidad con cada versión, digo… con cada incremento. La escena: Sala de juntas del grupo de ingeniería de software de Lee: Un momento. Doug, ¿dijiste que volveríamos a hacer el plan a CPI Corporation, compañía que manufactura productos de consumo cada vuelta de la espiral? Eso no es nada bueno; necesitamos un para uso doméstico y comercial. plan, un programa de actividades y apegarnos a ellos. Participantes: Lee Warren, gerente de ingeniería; Doug Miller, Doug: Ésa es la vieja escuela, Lee. Como dijeron los chicos, tene- gerente de ingeniería de software; Vinod y Jamie, miembros del mos que hacerlo apegado a la realidad. Afirmo que es mejor afinar equipo de ingeniería de software. el plan a medida de que aprendamos más y conforme se soliciten La conversación: [Doug describe las opciones de proceso evoluti- cambios. Eso es más realista. ¿Qué sentido tiene un plan si no refleja vo.] la realidad? Jamie: Ahora me doy cuenta de algo. El enfoque incremental tiene Lee (con el ceño fruncido): Supongo, pero… a la alta dirección sentido, y en verdad me gusta el flujo del modelo en espiral. Es bas- no le va a gustar… quieren un plan fijo. tante realista. Doug (sonriente): Entonces tendrás que reeducarlos, amigo. Vinod: De acuerdo. Entregamos un incremento, aprendemos de la retroalimentación del cliente, volvemos a planear y luego entregamos actividad —modelado— puede estar en cualquiera de los estados12 mencionados en un mo- mento dado. En forma similar, es posible representar de manera análoga otras actividades, acciones o tareas (por ejemplo, comunicación o construcción). Todas las actividades de in- geniería de software existen de manera concurrente, pero se hallan en diferentes estados. FIGURA 2.8 Un elemento Inactivo del modelo de proceso Actividad de modelado concurrente Representa el estado En de una actividad o desarrollo tarea de la ingeniería