2.

METODOLOGAS CLSICAS

Metodologa de desarrollo de software en ingeniera de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de informacin. Una metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. El framework para metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de programas de computacin con el enfoque del proceso de desarrollo de software Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas. Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como complemento se describirn las metodologas de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental. Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:

Modelo en cascada: Framework lineal.

Prototipo: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

Modelo en cascada Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el diseo, implementacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W. en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo. Los principios bsicos del modelo de cascada son los siguientes:

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases. Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases antes de comenzar la prxima fase. Prototipo El prototipo es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar.

Incremental Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro. Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental

Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final. Espiral Los principios bsicos son:

La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de la continuacin del proyecto durante todo el ciclo de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteracin (2) Evaluar alternativas; Identificar y resolver los riesgos (3) desarrollar y verificar los resultados de la iteracin (4) plan de la prxima iteracin

Cada ciclo comienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.

Rapid Application Development (RAD) El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo iterativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. Principios bsicos:

Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin.

Intenta reducir los riesgos inherentes del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y tcnicas orientada a objetos. Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica. La participacin activa de los usuarios es imprescindible. Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

Bibliografa 1 Autor: Introduccin a la ingeniera del software Autor: Fernando Alonso Amo, Loic A. Martinez Normand, Francisco Javier Segovia Perez. Delta Publicaciones Universitarias Primera edicin

2.1

METODOLOGAS CLSICAS

El concepto de metodologa, dentro de la Ingeniera del Software es, sin duda, uno de los ms oscuros y que ms confusin produce tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software. Tanto es as, que en muchos proyectos de desarrollo (no todos, por supuesto), la aplicacin de una metodologa brilla por su ausencia, siendo ste un concepto casi desconocido. Adems, la constante innovacin tecnolgica hace que cada vez sea necesaria la aplicacin de nuevas metodologas adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologas pensadas para viejos problemas, cosa que no sera necesariamente mala si las nuevas metodologas tuviesen tambin su lugar pero a menudo no es as. Y no es que haya una metodologa claramente superior a las dems. Como ya hemos dicho en ms de una ocasin, todas las metodologas son, en esencia, bienintencionadas. Obviamente, las ms modernas responden a problemas y necesidades ms actuales. Afortunadamente, los tiempos van cambiando (aunque no de la misma manera para todo el mundo). La informtica va madurando y tanto algunos profesionales de las tecnologas de la informacin como algunos de sus clientes se van dando cuenta de que se hace necesario seguir unas ciertas pautas predefinidas en el desarrollo del software de calidad: es decir, llevar un comportamiento metdico: seguir una metodologa.

Qu es una metodologa de desarrollo del software? El ciclo de vida del software se debe completar una serie de tareas para obtener un producto de software. A menudo, se dice que los distintos componentes de software deben pasar por distintas fases o etapas durante el ciclo de vida. Pues bien cada una de esas tareas puede ser abordada y resuelta de mltiples maneras, con distintas herramientas y utilizando distintas tcnicas. Es necesario saber cundo podemos dar por concluida una tarea, quin debe realizarla, qu tareas preceden o anteceden a una dada, qu documentacin utilizaremos para llevar a cabo esa tarea. Por ejemplo: en el desarrollo de cualquier software, es necesario pasar por la etapa de "Toma de requisitos" (es decir, enterarnos de lo

que hay que hacer). Por supuesto, tenemos muchas cosas que hacer para lograrlo: entrevistarnos con clientes, usuarios, tomar notas, escribir informes.

Pero esa descripcin de la tarea es muy vaga. Cuando nos ponemos manos a la obra y hay que enfrentarse a la toma de requisitos de un proyecto real surgen mil detalles Cmo se hace? Con quin hay que entrevistarse? Qu debo preguntar? Cmo es el informe que debo escribir? Quin lo va a leer? Qu va a hacer con l? Cunto debo tardar? Cundo s que he terminado?. Si soy una persona medianamente desenvuelta podr responderme a esas preguntas yo mismo... pero entonces, estara haciendo las cosas a mi manera... Eso quiz podra valer para un proyecto pequeo, en el que el equipo de desarrollo estuviera formado por dos o tres personas... pero en un proyecto de un tamao razonablemente mediano o grande es absurdo... Todo el mundo haran las cosas a su manera! Lamentablemente, eso ocurre en proyectos reales todos los das, generando proyectos fracasados, recursos perdidos y profesionales frustrados. Volvamos a las metodologas: todos los integrantes de un equipo de desarrollo deben seguir un criterio comn a la hora de realizar las tareas del ciclo de vida. Ese criterio, esa manera comn es una metodologa de desarrollo. A lo largo de los aos se han propuesto numerosas metodologas. Algunas han sido escritas por autores del mbito acadmico, otras por autores del mbito empresarial de desarrollo del software, otras por administraciones pblicas. Algunas metodologas estn escritas en infumables tochos de heroica lectura. Otras, se describen en apenas unas pocas pginas. Algunas metodologas intentan describirlo todo al detalle. Otras son ms genricas. Algunas hacen hincapi en los datos, otras en los usuarios, otras en las tareas, otras en la documentacin, o cualquier aspecto o combinacin de aspectos que puedan darse en el desarrollo del software.

Qu metodologa debo utilizar? Tambin es una pregunta de difcil respuesta. Hay una serie de metodologas que solemos llamar tradicionales propuestas casi todas ellas con anterioridad a los aos 90 que pretendan ayudar a los profesionales indicando pautas para realizar y documentar cada una de las tareas del desarrollo del software. Sin embargo, tienen casi todas ellas un gran problema: asumen que un proyecto informtico es casi una extensin de un proyecto burocrtico tradicional. As pues, los pasos que sugieren para llevar a cabo cada tarea, aunque bienintencionados,

estn cargados de burocracia, reiteraciones, ambigedades... No suelen tener en cuenta cosas como la calidad, la satisfaccin, la competitividad, los beneficios. Fueron metodologas creadas en los aos 70-80 pensando en los negocios de los aos 50.

El mundo va ahora mucho ms rpido: slo los negocios inteligentes sobreviven, slo los proyectos de software inteligentemente construidos lo hacen tambin. Ahora las comunicaciones son instantneas., mundiales. La informacin fluye en tiempo real. Las empresas compiten al segundo. El software ya tiene una cierta historia. Hemos aprendido mucho. Utilizamos conceptos abstractos para construir sistemas que van mucho ms all de los datos y los algoritmos. La mayor parte de las metodologas tradicionales ya no funcionan. Estn obsoletas desde casi todos los puntos de vista. Slo algunas metodologas tradicionales han sido revisadas y adaptadas y su funcionalidad suele estar limitada a proyectos no muy innovadores.

Las metodologas surgidas desde los 90 hasta aqu suelen tener otra mentalidad... una cierta agilidad. Siendo conscientes de lo cambiante y amplio que es el mundo del software, una metodologa debe ser lo suficientemente precisa como para que todo el mundo la pueda seguir y sea de utilidad como pauta comn, pero tambin debe ser lo suficientemente adaptable como para poder aplicarse en distintos proyectos, y lo suficientemente sencilla como para que no resulte muy gravosa su utilizacin, pero lo suficientemente completa y compleja como para que la utilizacin por parte del equipo sea provechosa. En una palabra: agilidad.

Bibliografa 2 Autor: Biblioteca multimedia informtica Ingeniera del software Benet Campderrich Falgueras Editorial OUC

2.1.1 CASCADA

El modelo en cascada, algunas veces llamado el ciclo d vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollado del software, que se inicia con la especificacin de requerimientos del cliente y que continan con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. El modelo en cascad es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las crticas a este modelo de proceso han ocasionado que an ms fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn: Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa. En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos. Diseo del Sistema. Diseo del Programa. Codificacin. Pruebas. Implantacin. Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Fases del modelo:

Anlisis de requisitos: En esta fase se analizan las necesidades de los

usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.

Diseo del Sistema: Descompone y organiza el sistema en elementos que

puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. Codificacin: Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido. Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificacin: Es la fase en donde el usuario final ejecuta el sistema, para ello el

o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo.

Mantenimiento: Una de las etapas ms crticas, ya que se destina un 75% de

los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final est libre de fallos. En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

En un anlisis interesante de proyectos reales, Bradac concluyo que la naturaleza lineal del modelo en cascada conduce a estados de bloqueo en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial. En la actualidad, el trabajo del software esta acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.

Bibliografa 1 Autor: Ingeniera del software un enfoque practico Roger S. Pressman Sexta edicin

2.1.1 CASCADA Primer modelo en el proceso del desarrollo del software. Debido a la cascada de una a fase a otra se le conoce como: modelo en cascada o ciclo de vida del software. Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida. Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido ampliamente en la ingeniera el software. La innovacin estuvo en la primera vez que la ingeniera del software fue dividida en fases separadas. La primera descripcin formal del modelo en cascada se cree que fue en un artculo publicado en 1970 por Winston W. Royce, aunque Royce no us el trmino cascada en este artculo. Irnicamente, Royce estaba presentando este modelo como un ejemplo de modelo que no funcionaba, defectuoso. Las principales etapas del modelo en cascada son las siguientes:

1)

Anlisis y definicin de requerimientos: los servicios, restricciones

metas del sistema se definen a partir de las consultas con los usuarios; que luego se definen en detalle como: especificacin del sistema. 2) Diseo del sistema y del software: el proceso del diseo del sistema divide

los requerimientos en Hardware o Software. Establece una arquitectura completa

del sistema. El diseo del software

identifica y describe

las abstracciones

fundamentales del sistema software y sus relaciones. 3) Implementacin y prueba de unidades: Durante esta etapa, el diseo del

software se lleva acabo como un conjunto de unidades de programa. La prueba de unidades implica verificar que cada una cumpla con su especificacin. 4) Integracin y prueba del sistema: Los programas o las unidades

individuales de programas se integran y se prueban como un sistema completo para asegurar que se cumpla con los requerimientos del software. Despus de las pruebas, el sistema software se entrega al cliente. 5) Funcionamiento y mantenimiento: Por lo general (aunque no

necesariamente), esta es la fase ms larga del ciclo de vida. El sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica:

corregir errores no descubiertos en las etapas anteriores del ciclo de vida. mejorar la implementacin de las unidades del sistema. aumentar los servicios requerimientos. del sistema una vez que se descubren nuevos

Durante la fase final

del ciclo de vida (funcionamiento y mantenimiento), el

software se pone en funcionamiento. Se descubren errores y omisiones en los requerimientos originales del software. Los errores de programacin y diseo

emergen y se identifica la necesidad de una nueva funcionalidad. Por lo tanto el sistema debe de evolucionar para mantenerse til.Hacer estos cambios (mantenimientos de software) puede implicar repetir etapas previas del proceso.
Ventajas

El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseadores predigan totalmente reas de problema del sistema y produzcan un diseo correcto antes de que empiece la implementacin. Funciona bien para proyectos pequeos donde los requisitos estn bien entendidos. Es un modelo en el que todo est bien organizado y no se mezclan las fases. Es simple y fcil de usar. Debido a la rigidez del modelo es fcil de gestionar ya que cada fase tiene entregables especficos y un proceso de revisin. Las fases son procesadas y completadas de una vez.

Desventajas: El modelo cascada debe utilizarse solo cuando: 1) Los requerimientos se comprendan bien. 2) Sea improbable que cambien radicalmente sistema.

durante el desarrollo del

Este enfoque se sigue utilizando para el desarrollo de software, en proyectos grandes de ingeniera en sistemas. Inconvenientes En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. Difcilmente un cliente va a establecer al principio todos los requisitos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya est finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Esto tambin implica el tener que tratar con requisitos que no se haban tomado en cuenta desde el principio, y que surgieron al momento de la implementacin, lo cual provocar que haya que volver de nuevo a la fase de requisitos. Hay muchas personas que argumentan que es una mala idea en la prctica, principalmente a causa de su creencia de que es imposible, para un proyecto no trivial, conseguir tener una fase del ciclo de vida del producto software perfecta antes de moverse a las siguientes fases. Por ejemplo, los clientes pueden no ser conscientes exactamente de los requisitos que quieren antes de ver un prototipo del trabajo; pueden cambiar los requisitos constantemente, y los diseadores e implementadores pueden tener poco control sobre esto. Si los clientes cambian sus requisitos despus de que el diseo est terminado, este diseo deber ser modificado para acomodarse a los nuevos requisitos, invalidando una buena parte del esfuerzo. Muchas veces se considera un modelo pobre para proyectos complejos, largos, orientados a objetos y por supuesto en aquellos en los que los requisitos tengan un riesgo de moderado a alto de cambiar. Genera altas cantidades de riesgos e incertidumbres. Bibliografa 2 Autor: Ingeniera del software Iam Sommerville Sptima edicin

2.1.2 INCREMENTAL Propuesto por Mills en 1980. Surgi el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. El modelo incrementa combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. Cada secuencia lineal produce incremento del software. El primer incremento a menudo es un producto esencial (ncleo). A partir de la evaluacin se planea el siguiente incremento y as sucesivamente, es interactivo por naturaleza y es til cuando el personal no es suficiente para la implementacin completa. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental se puede ver aqu en forma grfica:

Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucra ms. Difcil de evaluar el coste total. Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo.

Pipeline: La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.}

Interprete de comandos: Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas: Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucre ms. Difcil de evaluar el costo total. Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo. Ventajas: Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. Desventajas: El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. Requiere de mucha planeacin, tanto administrativa como tcnica. Requiere de metas claras para conocer el estado del proyecto. Bibliografa 1 Autor: http://ingenieraupoliana.blogspot.mx/2010/10/modelo-incremental.html

2.1.2 INCREMENTAL El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada Realimentados aplicados repetidamente, con una filosofa iterativa. En trminos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La descripcin del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificacin, desarrollo y validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.

El diagrama de la Figura 4 muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. Es decir, a medida que cada incremento definido llega a su etapa de operacin y mantenimiento. Cada versin emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios. En la Figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del modelo de ciclo de vida Iterativo Incremental, con sus actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la obtencin de un incremento; estos ltimos se van integrando para obtener el producto final completo.

Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, as por ejemplo, en la Figura, mientras se realiza el diseo detalle del primer incremento ya se est realizando en anlisis del segundo. La Figura 5 es slo esquemtica, un incremento no necesariamente se iniciar durante la fase de diseo del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de operacin y mantenimiento (indicada como Operacin en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fcilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc. Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado. Como se muestra en la Figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema bsico, con muchas funciones suplementarias (conocidas o no) sin entregar. El enfoque incremental resulta muy til cuando se dispone de baja dotacin de personal para el desarrollo; tambin si no hay disponible fecha lmite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad bsica (y cada vez mayor). Tambin es un modelo til a los fines de versiones de evaluacin. Ejemplo: Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en principio, funciones bsicas de edicin de archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le

podra agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de correccin ortogrfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el producto va creciendo, acercndose a su meta final, pero desde la entrega del primer incremento ya es til y funcional para el cliente, el cual observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo de desarrollo. Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar. Se aconseja utilizarlo para: El desarrollo de software en el cual se observe, en su etapa inicial de anlisis, que posee reas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales reas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un anlisis previo, es decir, definir cul ser la primera, la segunda, y as sucesivamente; esto se conoce como definicin de los incrementos con base en la priorizacin. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algn criterio, ya que basndose en ellas se desarrollarn y entregarn los distintos incrementos. En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados incrementos del sistema, que son escogidos segn prioridades predefinidas de algn modo. La seleccin de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para l como para el grupo de desarrollo). Se priorizan las entregas de aquellos mdulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de informacin, indispensable para los incrementos siguientes. Bibliografa 2 Autor: Ingeniera del software: metodologas y ciclos de vida Laboratorio nacional de calidad del software Edicin marzo de 2009

2.1.3 EVOLUTIVO El desarrollo evolutivo se basa en la idea de desarrollar una implementacin inicial, exponindola a los comentarios del usuario y refinndola en a travs de diferentes versiones hasta que se desarrolla un sistema adecuado (figura 4.2).

Las actividades de especificacin, desarrollo y validacin se entrelazan en vez de separarse con una rpida retroalimentacin: Existen dos tipos de desarrollo evolutivo: 1.- Desarrollo exploratorio: donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. 2.- Prototipos desechables: donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definicin mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprende del todo. En la produccin de sistemas, un enfoque evolutivo para el desarrollo del software suele ser ms efectivo que le enfoque de cascada ya que satisface las necesidades emitidas de los clientes. La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la especificacin se puede desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, este se puede reflejar en el sistema de software. Sin embargo desde una perspectiva de evolutivo tiene dos problemas: ingeniera y de gestin el enfoque

1.- el proceso no es visible: los administradores tienen que hacer entregas regulares para medir el proceso. Si los sistemas se desarrollan rpidamente, no es rentable producir documentos que reflejen cada versin del sistema. 2.- A menudo los sistemas tienen una estructura insuficiente: los cambios continuos tienden a corromper la estructura dl software. Incorporar cambios en el se convierte cada vez una tarea ms difcil y costosa. Para sistemas pequeos y de tamaos medios (hasta 500.000 lneas de cdigo), el enfoque de desarrollo evolutivo es el mejor. Los problemas de desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un periodo largo de vida, donde diferentes equipos desarrollan distintas partes del sistema. Es difcil establecer una arquitectura del sistema estable usando este enfoque, el cual hace difcil integrar las contribuciones de los equipos. El modelo Evolutivo conocido tambin como incremental e iterativo, consiste en hacer la documentacin de las fases, realizando un prototipo del sistema, se evala el qu tan lejos el prototipo est de la solucin final esperada por el cliente; se toman en cuenta las observaciones de esta evaluacin, y se crea un nuevo prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeas proporciones hasta cumplir los requerimientos totales. En este mtodo no es necesario esperar hasta que toda una fase est terminada para iniciar la siguiente. Si se cuenta con una parte del anlisis bien entendida, se puede realizar un primer diseo del corazn o de una parte medular del sistema, hacer su codificacin y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los requerimientos originales. La ventaja es que es ideal para sistemas que no tiene bien definidos los requerimientos, es decir, para la mayora de los sistemas que se desarrollan. El cliente desde el principio tiene una idea de los requerimientos de su sistema, pero no estn claros hasta el ltimo detalle. Aun as podemos basarnos en lo ya entendido (cliente y desarrollador), trabajar con esta informacin, y mientras se vayan creando prototipos, el cliente detallar sus especificaciones. Su desventaja es que es difcil distinguirlo del proceso "codifica y corrige", pues en cierta medida son parecidos, la diferencia est que en la prctica se requiere que al construir el prototipo se aplique el anlisis y el diseo pero slo a una parte de los requerimientos ya entendidos, que se documente y se codifique, logrndose con todo esto, un poco de disciplina heredada del modelo en cascada, de esta manera, la desventaja no lo es tanto. La caracterstica de este modelo es que est enfocado a la produccin de prototipos.

Para sistemas grandes se recomienda un proceso mixto que incorpore las mejores caractersticas del modelo de cascada y del desarrollo evolutivo. Esto puede implicar desarrollar un prototipo desechable utilizando un enfoque evolutivo para resolver incertidumbres en la especificacin del sistema. Puede entonces re implementarse utilizando un enfoque ms estructurado. Las partes del sistema bien comprendidas se pueden especificar se pueden desarrollar utilizando un proceso del modelo en cascada. Las otras partes del sistema, como la interfaz que son difciles de especificar or adelantado se deben desarrollar siempre utilizando un enfoque de programacin exploratoria. Bibliografia 1 Autor: Ingeniera del software Iam Sommerville Sptima Edicin

2.1.3 EVOLUTIVO

El software como todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de los negocios y productos a menudo cambian conforme se realiza el desarrollo; por lo tanto la rutina lineal que conduce a un producto final no ser real; las estrictas fechas tope del mercado imposibilitan la conclusin de un producto completo, por lo que se debe presentar una versin limitada pata liberar la presin competitiva y de negocios; se tiene claro un conjunto de requisitos del producto o sistema esencial. En esta y otras situaciones similares, los ingenieros de software necesitan un modelo de un proceso que haya sido diseado de manera explcita para incluir un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez mas completas de software. Construccin de prototipos: A menudo un cliente define unos conjuntos de objetivos generales para software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos el responsable, del desarrollo del software esta inseguro de la eficacia del algoritmo, y de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-maquina. En estas y en muchas otras situaciones, un paradigma de construccin de prototipos puede ofrecen un mejor enfoque. A pesar de que la construccin de prototipos, se puede utilizar como un modelo de proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos que se han expuesto. Sin importar la forma en que se aplique el paradigma de construccin de prototipos ayuda al ingeniero en sistemas y al cliente a entender de mejor manera cual ser el resultado de la construccin cuando los requisitos estn satisfechos.

El paradigma de construccin comunicacin.

de prototipos (figura 3.4) se inicia con la

El ingeniero del software y cliente encuentra y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es nea ms definicin. Entonces se planea con rapidez una interaccin de construccin de prototipos y se presenta el modelado (en forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo la configuracin de la interfaz con el usuario y el formato de pliegues de salida). El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala cliente/usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollara. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que hace. De manera ideal, el prototipo debera servir como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta emplear los fragmentos del programa ya existente o aplica otras herramientas (como generadores de informe, administradores de ventanas, etc.) que permiten producir programas de trabajo con rapidez. El prototipo puede servir como primer sistema, el que Brooks recomienda desechar. Pero esta vez sea una visin idealiza. Es verdad que a los clientes y los desarrolladores les gusta el paradigma de construccin de prototipos. A los

usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos tambin se toma problemtica por las siguientes razones: 1.- El cliente ve lo que parece una versin en funcionamiento del software Sin saber que el prototipo est unido, que por prisa de hacerlo funcionar no se ha considerado la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de calidad, el cliente no lo entiende y pide la aplicacin de unos pequeos ajustes para que se pueda elaborar un producto fi nal a partir del prototipo. Es muy frecuente que la gestin del desarrollo de software sea muy lenta. 2.- A menudo, el desarrollador establece compromisos de implementacin para lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo o lenguaje de programacin inadecuado solo porque est disponible y es conocido, se puede implementar un algoritmo ineficiente solo para mostrar capacidad. Despus de un tiempo, el desarrollador quiz se familiarice con estas selecciones y olvide las razones por las que son inapropiadas. La seleccin menos ideal ahora se convierte en una parte integral del sistema. A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma efectivo para la ingeniera del software. La clave es definir las reglas del juego desde el principio, es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos, en que se descarte, al menos en parte, y en que despus se desarrolle el software real con un enfoque hacia la calidad.

Bibliografia 2 Autor: Ingeniera del software Roger Pressman Sexta edicin

2.1.4 ESPIRAL El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniera del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis de riesgos, comenzando por el bucle anterior. Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de esfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo de vida, ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: el Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos ms asumibles y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo. Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo en cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados. Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en explicar las iteraciones. Este modelo fue propuesto por Boehm en 1988 en su artculo A Spiral Model of Software Development and Enhancement. Bsicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente ha de ser as. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un sistema operativo. Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.

Tareas: Para cada ciclo habr cuatro actividades: 1. Determinar o fijar objetivos: Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. Fijar las restricciones Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos Hay una cosa que solo se hace una vez: planificacin inicial o previa 2. Anlisis del riesgo: Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): Tareas de la actividad propia y de prueba Anlisis de alternativas e identificacin de resolucin de riesgos Dependiendo del resultado de la evaluacin de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. 4. Planificar: Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. El proceso empieza en la posicin central. Desde all se mueve en el sentido de las agujas del reloj.

Las cuatro regiones del grfico son: La tarea de planificacin: para definir recursos, responsabilidades, hitos y planificaciones. La tarea de determinacin de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas. La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin. La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplos de la aplicacin. Ventajas El anlisis de riesgos se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Entre ellos: Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con el modelo, ya que el ciclo de vida no es rgido ni esttico. Mediante este modelo se produce software en etapas tempranas del ciclo de vida y suele ser adecuado para proyectos largos de misin crtica. Inconvenientes Es un modelo que genera mucho trabajo adicional. Al ser el anlisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos (es bastante difcil). Esto puede llevar a que sea un modelo costoso. Adems, no es un modelo que funcione bien para proyectos pequeos. Comparacin con otros modelos La distincin ms destacada entre el modelo en espiral y otros modelos de software es la tarea explcita de evaluacin de riesgos. Aunque la gestin de riesgos es parte de otros procesos tambin, no tiene una representacin propia en el modelo de proceso. Para otros modelos la evaluacin de riesgos es una subtarea, por ejemplo, de la planificacin y gestin global. Adems no hay fases

fijadas para la especificacin de requisitos, diseo y pruebas en el modelo en espiral. Se puede usar prototipado para encontrar y definir los requisitos. La diferencia entre este modelo y el modelo de ciclo incremental es que en el incremental se parte de que no hay incertidumbre en los requisitos iniciales; en este, en cambio, se es consciente de que se comienza con un alto grado de incertidumbre. En el incremental suponemos que conocemos el problema y lo dividimos. Este modelo gestiona la incertidumbre.

Bibliografia 1 Autor: Ingeniera del software: metodologas y ciclos de vida Laboratorio nacional de calidad del software Edicin marzo de 2009

2.1.4 ESPIRAL El modelo en espiral del proceso del software fue originalmente propuesto por Boehm en 1988. Ms que representar el proceso del software como una secuencia de actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cada ciclo en la espiral represente una fase del proceso del software. As, el ciclo ms interno podra referirse a la viabilidad del sistema, el siguiente ciclo a la definicin de requerimientos, el siguiente ciclo al diseo se divide en cuatro sectores:

1.- Definicin de objetivos: Para esta fase del proyecto se definen los objetivos especficos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestin. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean estrategias alternativas.

2.- Evolucin y reduccin de riesgo: Se lleva a cabo un anlisis detallado para cada uno de los riesgos del proyecto identificados. Se definen los pasos para reducir dichos riesgos. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema.

3.- Desarrollo y validacin: Despus de la evaluacin de riesgos, se elige un modelo para el desarrollo del sistema. Por ejemplos, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si los riesgos de seguridad son la principal consideracin, un desarrollo bsico en transformaciones formales podran ser el ms apropiado, y asi sucesivamente. El modelo en cascada puede ser el ms apropiado para el desarrollo si el mayor riesgo identificado es la integracin de los subsistemas.

4.- Planificacin: El proyecto se revisa y se toma la decisin de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.

La diferencia principal entre el modelo en espiral y los otros modelos del proceso del software es la consideracin explicita del riesgo en el modelo en espiral. Informalmente, el riesgo significa sencillamente algo que puede ir mal. Por ejemplo, si la intencin es utilizar un nuevo lenguaje de programacin un riesgo es que los compiladores disponibles sean poco fiables o que no produzcan cdigo objeto suficientemente eficiente. Los riesgos originan problemas en el proyecto, como los de confeccin de agendas y excesos en los costos, por lo tanto, la disminucin de riesgos, una parte fundamental en la gestin de proyectos.

El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniera del software concurrente y con mltiples usuarios. Tiene dos caractersticas distintivas principales. Una de ellas es un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras disminuye su grado de riesgo. La otra es una conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computacin. Por lo tanto, el primer circuito alrededor de la espiral podra representarse un proyecto de desarrollo del concepto, el cual se inicia en el centro de la espiral y continan por mltiples iteraciones hasta que el desarrollo de una producto nuevo. El nuevo producto evolucionara a travs de un nmero de iteraciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra emplear para representa un proyecto de mejoramiento del producto. En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso est inactivo, pero siempre que se inicie un cambio del proceso comienza en el punto de entrada aprobado. El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea la construccin de prototipos como un mecanismo encaminando a reducir riesgos, pero en forma ms importante, permite al desarrollador la aplicacin del enfoque de la construccin de prototipos en cualquier etapa evolutiva del producto. Un ciclo de la espiral empieza con la colaboracin de objetos, como el rendimiento y la funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos objetos y las restricciones impuestas en cada una de ellas. Cada alternativa se evala contra cada objetivo y se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver estos riesgos mediante actividades de recopilacin de informacin como la de detallar ms el anlisis, la construccin de prototipos y la simulacin, seguido de una actividad de planificacin para la siguiente fase del proceso

Bibliografa 2 Autor: Ingenieria Del Software Iam Sommerville Sptima edicin

2.1.5 PROTOTIPOS

El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

ETAPAS

Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin Comunicacin

A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma efectivo para la ingeniera del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

Que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos.

Que el prototipo se descarte, al menos en parte. Que despus se desarrolle el software real con un enfoque hacia la calidad. VENTAJAS

Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina. La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el producto. INCONVENIENTES El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Bibliografa 1 Autor: Ingeniera del software: metodologas y ciclos de vida Laboratorio nacional de calidad del software Edicin marzo de 2009

2.1.5 PROTOTIPOS El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseos para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interacta el hombre y la mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. El paradigma de construccin de prototipos tiene tres pasos: Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definicin. Construir y revisar la maqueta (prototipo). El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este modelo es til cuando: El cliente no identifica los requisitos detallados. El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-mquina.

ETAPAS PARA LA ELABORACIN DEL MODELO DE PROTOTIPO

CICLO DE VIDA DE UN SISTEMA BASADO EN PROTOTIPO

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicacin, su cara externa, pero dicha interfaz est fija, esttica, no procesa datos. El prototipo no tiene desarrollada una lgica interna, slo muestra las pantallas por las que ir pasando la futura aplicacin.

Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las necesidades del cliente y despus no se va a aprovechar ni total ni parcialmente en la implementacin del sistema final se habla de un prototipo desechable. Para que la construccin de prototipos sea posible se debe contar con la participacin activa del cliente. VENTAJAS Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina. DESVENTAJAS Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador haya hecho compromisos de implementacin para hacer que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado. El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema an no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

Bibliografa 2 Autor: Biblioteca multimedia informtica Ingeniera del software Benet Campderrich Falgueras Editorial OUC

2.1.6 Desarrollo basado en componentes La ingeniera de software basada en componentes (CBSE) (tambin conocida como desarrollo basado en componentes (CBD)) es una rama de la ingeniera de software que enfatiza la separacin de asuntos (separation of concerns (SoC)) por lo que se refiere a la funcionalidad de amplio rango disponible a travs de un sistema de software dado. Es un acercamiento basado en la reutilizacin para definir, implementar, y componer, componentes dbilmente acoplados en sistemas. Esta prctica apunta traer igualmente un amplio grado de beneficios tanto en el corto como el largo plazo, para el software en s mismo, y para las organizaciones que patrocinan tal software. Los ingenieros de software consideran los componentes como parte de la plataforma inicial para la orientacin a servicios. Los componentes juegan este rol, por ejemplo, en servicios de web, y ms recientemente, en las arquitecturas orientadas a servicios (SOA), por el que un componente es convertido por el servicio web en un servicio y subsecuentemente hereda otras caractersticas ms all de las de un componente ordinario. Los componentes pueden producir o consumir eventos y pueden ser usados para las arquitecturas dirigidas por eventos (EDA).

Un componente de software individual es un paquete de software, un servicio web, o un mdulo que encapsula un conjunto de funciones relacionadas (o de datos). Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente estn semnticamente relacionadas (justo como con el contenimiento de clases). Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos.

Con respecto a la coordinacin a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, ste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cmo pueden hacerlo. Esta interface puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementacin) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados. Las ilustraciones UML de este artculo representan a las interfaces proporcionadas, con un smbolo lollipop unido al borde externo del componente. Sin embargo, cuando un componente necesita usar otro componente para poder funcionar, adopta una interface usada que especifica los servicios que necesita. En las ilustraciones de UML en este artculo, las interfaces usadas son representadas por un smbolo de zcalo abierto unido al borde externo del componente. Otro atributo importante de los componentes es que son sustituibles, as que un componente puede sustituir a otro (en tiempo de diseo o tiempo de ejecucin), si el componente sucesor cumple los requisitos del componente inicial (expresado por medio de las interfaces). Por lo tanto, los componentes pueden ser sustituidos por una versin actualizada o una alternativa sin romper el sistema en el cual operan. Como una regla de oro general para los ingenieros que sustituyen componentes, el componente B puede sustituir inmediatamente al componente A, si el componente B proporciona por lo menos que el componente A provee y no usa ms cosas que las que el componente A usa. Los componentes de software con frecuencia toman la forma de objetos (no clases) o de colecciones de objetos (de la programacin orientada a objetos), en una cierta forma binaria o textual, adhirindose a un cierto lenguaje de descripcin de interface (IDL) de modo que el componente pueda existir autnomo de otros componentes en una computadora. Cuando un componente debe ser accesado o compartido a travs de contextos de ejecucin o enlaces de red, a menudo son empleados tcnicas tales como serializacin o marshalling para enviar el componente a su destino. La reusabilidad es una importante caracterstica de un componente de software de alta calidad. Los programadores deben disear e implementar componentes de software de una manera tal que diversos programas puedan reutilizarlos. Adems, cuando los componentes de software interactan directamente con los usuarios, debe ser considerada la prueba de usabilidad basada en componentes.

Toma un significativo esfuerzo y conciencia para escribir un componente de software que sea efectivamente reutilizable. El componente necesita estar:

Completamente documentado Probado a fondo Robusto - con una comprensiva comprobacin para la validez de la entrada Capaz de devolver mensajes de error apropiados o cdigos de retorno Diseado con conciencia de que ser puesto en usos imprevistos

En los aos 1960, los programadores construyeron bibliotecas de subrutinas cientficas que eran reusables en un amplio arreglo de aplicaciones de ingeniera y cientficas. Aunque estas bibliotecas de subrutinas reusaban algoritmos bien definidos de una manera efectiva, tenan un limitado dominio de aplicacin. Los sitios comerciales rutinariamente crearon programas de aplicacin a partir de mdulos reusables escritos en ensamblador, COBOL, PL/1 y otros lenguajes de segunda y tercera generacin, usando bibliotecas de aplicacin tanto de sistema como de usuario. Por 2010, los componentes reusables modernos encapsulan las estructuras de datos y los algoritmos que son aplicados a las estructuras de datos. Esto [clarificacin necesaria] se basa en teoras anteriores a los objetos, arquitecturas, frameworks y patrones de diseo de software, y la extensa teora de la programacin orientada a objetos y el diseo orientado a objetos de todos stos. Afirma que los componentes de software, como la idea de componentes de hardware, usados, por ejemplo, en telecomunicaciones, pueden en ltima instancia ser hechos intercambiables y confiables. Por otro lado, se argumenta que es un error enfocarse en componentes independientes en vez del framework (sin el cual el componente no existira).

Bibliografa 1 Autor:
Biblioteca multimedia informtica Ingeniera del software Benet Campderrich Falgueras Editorial OUC

2.1.6 Desarrollo basado en componentes El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases). El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software. El proceso unificado de desarrollo de software representa un nmero de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinacin del desarrollo incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software. Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los aspectos extra funcionales y de calidad, como un paso hacia una verdadera ingeniera. En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos. VENTAJAS: Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema.

 Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo NOTACION DE COMPONENTES: Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio. DIAGRAMA DE COMPONENTES: El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones. INTERFACES: Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos. COMPONENTES Y NODOS: Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes. RESTRICCIONES: Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente. Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software, que traer beneficios inmensos para todos. El desarrollo de software basado en componentes desde siempre fue la idea revolucionaria que nos llev a pensar que s era posible el construir software de calidad en corto tiempo y con la misma calidad que la mayora de las industrias de nuestro tiempo. Al mirar hacia atrs, vemos los increbles avances que hemos logrado en la comprensin de la forma correcta de reutilizar el software y el conocimiento existente, y nos asombramos cada vez ms al darnos cuenta de que este solo es el inicio.

El desarrollo de software basado de componentes se convirti en el pilar de la Revolucin Industrial del Software y se proyecta hoy en da en diversas nuevas formas de hacer software de calidad con los costos ms bajos del mercado y en tiempos que antes eran impensables. Empresas como Microsoft entendieron el potencial de esta metodologa hace aos y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de construccin de software hacia el sitial privilegiado en el que debi colocarse desde un principio. ANLISIS DEL RIESGO Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. VENTAJAS: El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad - Integra el desarrollo con el mantenimiento DESVENTAJAS: Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos Inconvenientes Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

Bibliografa 2 Autor: Ingeniera del software: metodologas y ciclos de vida Laboratorio nacional de calidad del software Edicin marzo de 2009