Modelos de desarrollo del software Como ya hemos observado, las actividades son un elemento fundamental en el proceso de desarrollo de software,

las cuales permiten la definicin de otros elementos (mtodo, modelos y herramientas). Existen diversos modelos para desarrollar un software, entre los cuales se encuentra el Modelo de Cascada, Evolutivo, de transformaciones y basado en rehus. En cada uno se relacionan las actividades de forma particular para lograr el desarrollo del producto (software). A continuacin se explicarn algunos de stos modelos. Modelo de Cascada El modelo de la cascada es uno de los primeros modelos empleados en el desarrollo de software, se popularizo en 1970 y an est vigente en algunos desarrollos. ste modelo se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisin bien definidos, es decir, se codifica y reparan los errores; es un proceso continuo de codificacin y reparacin. Sus caractersticas principales son: Es lineal Las actividades estn relacionadas secuencialmente Cada etapa tiene una entrada y una salida Es rgido y sistemtico: La entrada de una actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio a la siguiente fase. Es monoltico: Existe una nica fecha de entrega. La implementacin se pospone hasta que no se comprendan los objetivos. Los documentos a entregar rigen el proceso de software Las fases que contempla el modelo de la cascada son al Anlisis y especificacin de requerimientos, diseo, codificacin, integracin y pruebas, liberacin y mantenimiento.

Ventajas Impone la necesidad de mucha disciplina planificacin y administracin, en el proceso de desarrollo de software, venciendo as la filosofa de los procesos de codificar y probar Impone la necesidad de que la realizacin del producto debe ser pospuesta hasta que los objetivos sean bien entendidos. Desventajas Retrasa la deteccin de errores hasta el final por lo cual es muy difcil realizar cambios cuando el proceso est en las ltimas fases. Toma mucho tiempo ver los resultados Es difcil mantener la trazabilidad entre los requerimientos inciales y el cdigo final.

 Cuando los requerimientos no estn bien definidos no es posible aplicar ste modelo pues ello incrementara los riesgos y retrasara el proceso. Si los requerimientos del usuario varan es muy difcil satisfacerlo si el proceso se encuentra en las ltimas fases. El costo de detectar errores en etapas avanzadas es muy alto dado que ello modificara todo lo que se ha desarrollado. El modelo de cascada ha introducido mucha disciplina en el proceso de desarrollo de software, pero sta disciplina est acompaada de rigidez. sta rigidez, introduce nuevos problemas al proceso, especialmente cuando el software es desarrollado con una pobre comprensin de los requerimeintos. Entre los problemas asociados con la rigidez del modelo estn:

Es dificil estimar con exactitud los recursos cuando solo esta disponible informacin limitada. El modelo de la cascada con frecuencia forza la estimacin de costos y la planificacin del proyecto a ocurrir despus de que una cantidad limitada de anlisis ha sido ejecutado. La especificacin de requerimientos se plasma en un documento que describe los requerimientos. Pero no importa cuan precisa es la descripcin, es muy dificil para el usuario anticipar si el sistema final ser construido de acuerdo a las especificaciones que espera. El usuario no sabe, con frecuencia, o no conoce los requerimientos exactos de la aplicacin. El modelo de la cascada no contempla la necesidad de anticipar los cambios. Al contrario, la filosofa subyacente es que nosotros deberamos esforzarnos para mantener la linealidad congelando todo como sea posible en las tempranas etapas.. El modelo hace cumplir las normas que estn basadas en la produccin de ciertos documentos en determinados momentos. De hecho, caracterizamos el proceso como el conducio por documentos. Este nfasis conduce a un estilo algo burocrtico de trabajo, donde se requiere que muchas formas sean llenadas y aprobadas y el ingeniero de software est inclinado a prestar ms atencin a la sintaxis impuesta en el estndar que a su semntica.

Modelo Evolutivo El modelo Evolutivo surge por la necesidad de generar una aproximacin flexible y no monoltica al proceso de desarrollo del software, se define como un modelo cuyas etapas consisten en ampliar los requerimientos de un software, los requerimientos pueden ser entregados al cliente a medida que son desarrollados; a esto se le denomina una entrega evolutiva he incremental. Aunque la entrega incremental no implica un modelo evolutivo, esto aade un valor al modelo al proveer feedback al usuario desde el inicio del desarrollo. Un aspecto muy importante de estas entregas al usuario es que estos incrementos deben consistir no solo de cdigos y documentaciones internas del proyecto, sino tambin de documentacin orientada al usuario, que este redactada lo ms cercano al lenguaje natural y que provea de un glosario de aquellos trminos tcnicos que se manejen en la documentacin. Se puede definir un incremento como una unidad autnoma funcional del software que desarrolla algunos objetivos tiles para el usuario, con todo el material de apoyo

(requerimientos y datos especficos de diseo, proyectos de prueba, un manual de usuario, material de adiestramiento, entre otros). El modelo evolutivo puede describirse de la siguiente forma: 1. Entregar algo al usuario. 2. Medir el valor agregado al usuario en todas las dimensiones crticas. 3. Ajustar tanto el diseo como los objetivos en funcin a la realidad observada. En el modelo evolutivo se puede decir que desaparece el mantenimiento como una etapa del ciclo de vida del software o que todo el ciclo de vida es un mantenimiento, esto debido a que continuamente se evala y se mejora al software. Otra de las caractersticas del modelo evolutivo es el prototipaje. En el caso de este modelo el prototipo es progresivamente transformado en una aplicacin y permite a los desarrolladores realizar pruebas desde las primeras etapas del desarrollo a las funcionalidades del software. Modelo basado en Ensamblaje de Componentes Este modelo se basa en la reutilizacin de componentes, esta reutilizacin puede hacerse de componentes de especificacin, de programas y de cualquier otro componente. El hecho de reutilizar componentes permite a los desarrolladores reducir el tiempo y los costos del desarrollo. La reutilizacin es la capacidad de los elementos de software de servir para la construccin de muchos elementos diferentes. La necesidad de la reutilizacin surgi de la observacin de que los sistemas software a menudo siguen patrones similares, por ello es posible explotar esta similitud y evitar reinventar soluciones a problemas que ya ha sido encontrado con anterioridad. Capturando tal patrn, un elemento de software reutilizable se podr aplicar en muchos desarrollos diferentes. En el modelo basado en rehus se generan nuevas actividades, estas son: Adaptacin. Recuperacin Evaluacin Clasificacin Reingeniera Calificacin

Todas estas nuevas actividades necesitan de herramientas para su asistencia, de tal forma que para las actividades de adaptacin, recuperacin y evaluacin se tiene un asistente de reusabilidad y para las actividades de clasificacin, reingeniera y calificacin se tiene un asistente de construccin de componentes. De esta forma se puede tener un desarrollo para la reusabilidad o un desarrollo con reusabilidad.

Modelo en espiral La meta del modelo espiral del proceso de produccin del software es proporcionar un marco para disear tales procesos, dirigido por los niveles de riesgo en el proyecto actual. En

comparacin con los actuales modelos, el modelo espiral se puede ver como metamodelo, porque puede acomodar cualquier modelo de proceso del desarrollo. Usndolo como referencia, se puede elegir el modelo de desarrollo ms apropiado (e.g., evolutivo con la cascada). Los riesgos son las circunstancias potencialmente adversas que pueden deteriorar el proceso del desarrollo y la calidad del producto. Boehm [1989] define la gerencia de riesgo como "disciplina cuyo objetivos es identificar, tratar, y eliminar artculos del riesgo del software antes de que se conviertan en las amenazas al adecuado funcionamiento del software o la fuente importante de la reanudacin costosa del software." El modelo de espiral se enfoca en identificar y eliminar los problemas de alto riesgo con el diseo de un proceso cuidadoso, ms que tratar problemas triviales. La caracterstica principal del modelo espiral es que es cclico y no lineal como el modelo de la cascada. Cada ciclo del espiral consiste en cuatro etapas, y cada etapa es representada por un cuadrante del plano cartesiano. El radio del espiral representa el coste acumulado hasta ahora en el proceso; la dimensin angular representa el progreso en el proceso. La etapa 1 identifica los objetivos de la porcin del producto bajo consideracin, en trminos de calidades ha alcanzar. Adems, identifica alternativas -tales como si comprar, disear, o reutilizar cualesquier software- y restricciones en el uso de las alternativas. Las alternativas entonces se evalan en la etapa 2 y se identifican y se tratan las reas potenciales del riesgo. La estimacin del riesgo puede requerir la planificacin de diversas clases de actividades, por ejemplo Prototipaje o la simulacin. La etapa 3 consiste en el desarrollo y verificacin del prximo nivel del producto; otra vez, la estrategia seguida por el proceso es dictada por el anlisis del riesgo. Cuando los requerimientos estn bien definidos, se puede elegir como opcin un modelo convencional como el de la cascada, que conduce a una simple vuelta a la espiral. Cuando los requerimientos no estn claramente definidos, se puede seleccionar un modelo de naturaleza evolutiva; en este caso se necesitaran varias vueltas a la espiral para alcanzar los resultados deseados. Tambin puede realizarse cualquier combinacin con los modelos vistos anteriormente. Finalmente, la etapa 4 consiste en repasar los resultados de las etapas transitadas hasta ahora y el planear la iteracin siguiente del espiral, si la hay. El modelo espiral permite obtener mayor robustez en el proceso de desarrollo del software. Proceso Incremental Un proceso incremental es aquel desarrollo que se hace de forma gradual, donde las partes de algunas etapas son aplazadas para producir un conjunto de funcionales tiles en el desarrollo del proyecto. Se priorizan los requerimientos del usuario y los de ms alta prioridad son incluido en los primeros incrementos Entre la ventajas de un desarrollo incremental podemos decir que se puede generar un prototipo por medio del cual los desarrolladores podrn obtener ayuda para conocer los requisitos para los incrementos posteriores; adems este proceso permite priorizar las funcionalidades, de tal forma que las necesidades mas importantes tienden a recibir la mayor cantidad de pruebas. La aproximacin incremental puede ser utilizada en todas las etapas del ciclo de vida del software, para de esta forma alcanzar una mayor granularidad en el proceso. La granularidad se

define como el nivel de detalle con el cual se describa o defina el proceso de desarrollo del software. El desarrollo comienza con un anlisis incremental a nivel de los requerimientos, luego cada incremento por separado, es diseado, codificado y probado, integrado y finalmente entregado. Los incrementos son desarrollados uno tras otro despus que se recibe el feedback del usuario. Un aspecto muy importante de este proceso es el hecho de que como los usuarios van recibiendo entregas incrementales, van aumentando su conocimiento acerca del sistema y van definiendo mejor sus necesidades reales. Desde el punto de vista de los desarrolladores, desarrollar un incremento es ms sencillo que desarrollar el sistema entero, por lo tanto es ms fcil predecir los recursos necesarios para desarrollar una tarea.

Iteraciones Una iteracin es una secuencia de actividades dentro de un plan establecido, con unos criterios claros de evaluacin, que se organiza con el propsito de entregar parte de la funcionalidad del producto. En las primeras iteraciones se desarrollan o implementan los casos de uso que tienen mayor complejidad y que llevan inherente un alto nivel de riesgo que puede afectar el xito del proyecto. De esta forma, con cada iteracin que se realiza, los riesgos del proyecto se reducen acorde con el plan establecido, el cual est en permanente revisin para monitorear la posible aparicin de nuevos riesgos y ajustarlo si es necesario. La seleccin de los casos de uso para cada iteracin se hace teniendo en cuenta cul es el mnimo conjunto de ellos que se requiere para implementar la funcionalidad que mayor riesgo tenga. Se debe realizar este proceso hasta que la lista de riesgos haya sido cubierta completamente. Cada iteracin puede tener uno o varios propsitos, lo cual determina la duracin de la misma; a su vez se ejecutan varios procesos que van desde la especificacin de requerimientos hasta las pruebas de unidad e integracin, lo cual se asimila a un ciclo de vida en cascada. Adicionalmente, al final de cada iteracin se deben evaluar los resultados del trabajo y se planea detalladamente la siguiente iteracin. Proceso Iterativo Un proceso iterativo es aquel en el que se realizan iteraciones sucesivas, que van generando nuevas versiones de la aplicacin que se desarrolla. Se parte del principio de que los requisitos del sistema SIEMPRE evolucionan en el curso de un proyecto y se requiere iteracin del proceso desde las primeras fases del desarrollo. La iteracin puede aplicarse en cualquiera de los modelos, como por ejemplo el desarrollo incremental y el desarrollo en espiral.

Proceso Unificado El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa Rational", donde confluyen 'los tres

amigos' como se llaman a s mismos o los tres grandes OO: Grady Booch, James Rumbaugh e Ivar Jacobson. El Proceso Unificado gua a los equipos de proyecto en cmo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu artefactos producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas.

Caractersticas del Proceso Unificado Centrado en los Modelos: Los diagramas son un vehculo de comunicacin ms expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de descripciones y especificaciones textuales del sistema. Guiado por lo casos de uso: Los casos de uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba. Centrado en la arquitectura: Los modelos son proyecciones del anlisis y el diseo constituye la arquitectura del producto a desarrollar. Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones incrementales (que se acercan al producto terminado) del producto en desarrollo. Etapas del Proceso Unificado El proceso Unificado incluye cuatro fases importantes que son: la concepcin (iniciacin), elaboracin, construccin y transicin, las cuales muestran que para producir una versin del producto en desarrollo se aplican todas las actividades de ingeniera pero con diferente nfasis; en las versiones preliminares, como adems indica la intuicin, hay ms nfasis en actividades de modelado del negocio, requisitos, anlisis y diseo; conforme se producen versiones el nfasis pasa a las actividades de implementacin y prueba. 1 Etapa de ingeniera: Esta etapa agrupa las fases de concepcin y de elaboracin, lo que bsicamente le da por objetivos la conceptualizacin del sistema y el diseo inicial de la solucin del problema. Se inicia el proceso de administracin de los requerimientos con la identificacin y especificacin de casos de usos, as como el proceso de aseguramiento de la calidad a travs de los casos de prueba. Se identifican los riesgos y se establece su plan de manejo, se ajusta ese plan segn la tabla de priorizacin de riesgos y la de casos de usos vs. riesgos, para determinar en qu orden y en qu iteraciones se desarrollarn los artefactos de software que son la solucin a los casos de uso. Se identifican los recursos necesarios, tanto econmicos como humanos, acordes con las necesidades del proyecto. Se da comienzo al proceso de estimacin y planificacin inicial a un nivel macro para todo el proyecto y posteriormente se realiza una estimacin detallada de tiempos y recursos de las fases de concepcin y elaboracin. 1.1 Fase de concepcin: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una

visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. 1.2. Fase de elaboracin: Los casos de uso seleccionados para desarrollarse en esta fase permiten definir la arquitectura del sistema, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar del problema y comienza la ejecucin del plan de manejo de riesgos, segn las prioridades definidas en l. Al final de la fase se determina la viabilidad de continuar el proyecto y si se decide proseguir, dado que la mayor parte de los riesgos han sido mitigados, se escriben los planes de trabajo de las etapas de construccin y transicin y se detalla el plan de trabajo de la primera iteracin de la fase de construccin. 2 Etapa de Produccin En esta etapa se realiza un proceso de refinamiento de las estimaciones de tiempos y recursos para las fases de construccin y transicin, se define un plan de mantenimiento para los productos entregados en la etapa de ingeniera, se implementan los casos de uso pendientes y se entrega el producto al cliente, garantizando la capacitacin y el soporte adecuados. 2.1. Fase de construccin: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar el cambio de los artefactos construidos, ejecutar el plan de administracin de recursos y mejoras en el proceso de desarrollo para el proyecto. 2.2. Fase de transicin: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto al inicio del mismo.

Escogencia del Modelo de Desarrollo del Software a utilizar La escogencia del modelo de desarrollo a utilizar depende del tipo de aplicacin y del contexto de desarrollo, por ejemplo si tenemos los requerimientos bien definidos se puede utilizar un modelo de cascada, por otra parte si lo que se quiere es asegurar mayor robustez durante el proceso de desarrollo se recomienda aplicar un modelo en espiral. Tambin es importante saber que se pueden combinar diferentes modelos de desarrollo y que finalmente no existe un modelo universal.

Bibliografa 1. [1]Gezzi Ghezzi &al, Fundamentals of Software Engineering. PrenticeHall. Cap.7 2. Sommerville . Requerimientos no funcionales. Addison Wesley 2002. Cap. 4 3. [2]SweboK. Gua del cuerpo de conocimientos de la Ingeniera del Software. Versin 2004. http://www.swebok.org/