AO DE LA INVERSION PARA EL DESARROLLO RURAL Y LA SEGURIDAD ALIMENTICIA

Universidad Nacional San Luis Gonzaga de Ica

FACULTAD DE INGENIERIA DE SISTEMAS

Ciclo de Vida del Software

CURSO INTEGRANTES : Control de Calidad de Software : CARDENAS PEA, Christopher. RODRIGUEZ AYBAR, Bryam. TORALVA BALDEON, Deiby. ANGULO GASCO, Jesus. ONOC FUENTES, Amrico. NEIRA LOVERA, Kathia. ICA - 2012

DEDICATORIA
ESTE TRABAJO MONOGRFICO EST DEDICADO A MIS COMPAEROS DE CLASE, PARA QUE A TRAVS DE L SE PUEDAN INFORMAR Y CONOCER MS ACERCA DEL TEMA DE CICLOS DE VIDA DEL SOFTWARE, Y AS MISMO PUEDA SER DE REFERENCIA PARA OCASIONES FUTURAS.

AGRADECIMIENTO
A MIS COMPAEROS DEL EQUIPO DE TRABAJO, YA QUE GRACIAS A SU APORTE DE INFORMACIN SE PUDO

LLEVAR A CABO EL PRESENTE TRABAJO MONOGRFICO.CICLOS DE VIDA DEL SOFTWARE

NDICE
CONTENTS
Dedicatoria .............................................................................................................................................................................................. 2 Agradecimiento ..................................................................................................................................................................................... 3 ndice ......................................................................................................................................................................................................... 4 I. II. III. IV. V. A. 1. 2. 3. 4. 5. B. 1. 2. 3. 4. VI. 1. 1.1 1.2 1.3 2. INTRODUCCION ........................................................................................................................................................................... 7 HISTORIA ........................................................................................................................................................................................ 8 DIFERENCIA ENTRE CICLO DE VIDA Y CICLO DE DESARROLLO ........................................................................ 9 DIFERENCIA ENTRE METODOLOGIAS, METODOS, MODELOS, Y ENFOQUE ............................................ 10 MODELOS DE CICLO DE VIDA ............................................................................................................................................ 11 TRADICIONALES ................................................................................................................................................................. 11 MODELO CASCADA ..................................................................................................................................................... 11 MODELO CASCADA CON SUB PROYECTOS ...................................................................................................... 12 MODELO SASHIMI ........................................................................................................................................................ 13 MODELO DE CICLO DE VIDA EN V ..................................................................................................................... 15 MODELO FUENTE .......................................................................................................................................................... 16 ITERATIVOS ........................................................................................................................................................................... 16 MODELO ESPIRAL ......................................................................................................................................................... 16 MODELO ESPIRAL WIN -WIN................................................................................................................................... 18 MODELO RUP ................................................................................................................................................................. 20 MODELO SCRUM .......................................................................................................................................................... 22 CICLOS DE DESARROLLO ................................................................................................................................................ 24 MODELO CODE & FIX ...................................................................................................................................................... 24 CONCEPTO ...................................................................................................................................................................... 24 ETAPAS .............................................................................................................................................................................. 24 VENTAJAS Y DESVENTAJAS ...................................................................................................................................... 24 MODELO RAD ...................................................................................................................................................................... 25 2.1 CONCEPTO .......................................................................................................................................................................... 25 2.2. 2.3. ETAPAS ......................................................................................................................................................................... 25 VENTAJAS Y DESVENTAJAS ................................................................................................................................. 26

3.

MODELO PROTOTIPADO EVOLUTIVO ....................................................................................................................... 26 3.1. 3.2. 3.3. CONCEPTO ................................................................................................................................................................. 26 ETAPAS ......................................................................................................................................................................... 26 VENTAJAS Y DESVENTAJAS ................................................................................................................................. 27

4.

MODELO BDD...................................................................................................................................................................... 28 4.1. 4.2. 4.3. CONCEPTO ................................................................................................................................................................. 28 ETAPAS ......................................................................................................................................................................... 28 VENTAJAS Y DESVENTAJAS ................................................................................................................................. 29

VII. VIII.

CONCLUSIONES ................................................................................................................................................................. 29 BIBLIOGRAFIA ........................................................................................................... Error! Marcador no definido.

NDICE DE FIGURAS
Figure 1-Equipo de Desarrollo ........................................................................................................................................................ 7 Figure 2 - Desarrollo y la Actualidad ............................................................................................................................................ 8 Figure 3- Metodologia, Metodo , Enfoque y Modelo ......................................................................................................... 10 Figure 4-Fases del Modelo en Cascada .................................................................................................................................... 11 Figure 5 - Fases del Modelo en Cascada con SubProyectos............................................................................................ 13 Figure 6- Etapas del modelo Sashimi ........................................................................................................................................ 14 Figure 7- Modelo en V .................................................................................................................................................................... 15 Figure 8 - Modelo Fuente .............................................................................................................................................................. 16 Figure 9-Modelo en Espiral ........................................................................................................................................................... 17 Figure 10-Modelo Espiral WIN WIN .......................................................................................................................................... 19 Figure 11- Fases de RUP ................................................................................................................................................................. 21 Figure 12-Modelo SCRUM ............................................................................................................................................................. 23 Figure 13-Modelo de Desarrollo RAD ....................................................................................................................................... 25 Figure 14- Modelo de Prototipado Evolutivo ........................................................................................................................ 27 Figure 15- Modelo BDD .................................................................................................................................................................. 28

I.

INTRODUCCION

El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. Tiene como propsito definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de que los mtodos utilizados son apropiados. Estas metodologas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementacin y en los costos asociados. El ciclo de vida bsico de un software consta de los siguientes procedimientos: Definicin de objetivos: definir el resultado del proyecto y su papel en la estrategia global. Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restriccin que haya, ya sea en el aspecto econmico, tcnico u operativo. Diseo general: requisitos generales de la arquitectura de la aplicacin. Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin. Programacin: es el uso de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo. Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para garantizar que se implementaron de acuerdo con las especificaciones. Integracin: para garantizar que los diferentes mdulos se integren con la aplicacin. ste es el propsito de la prueba de integracin que est cuidadosamente documentada. Prueba beta (o validacin): para garantizar que el software cumple con las especificaciones originales. Documentacin: sirve para documentar informacin necesaria para los usuarios del software y para desarrollos futuros. Implementacin: tambin conocido como pase a produccin supone la instalacin y puesta en marcha del nuevo sistema. Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

Figure 1-Equipo de Desarrollo

II.

HISTORIA

Tradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de forma individualizada, a base de codificar y probar lo realizado cuanto antes. A lo largo de los aos esto fueron surgiendo los llamados Ciclos de Vida que son una descripcin de las distintas formas de desarrollo de una aplicacin informtica Hace aos el desarrollo era as: la misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese existir documentacin alguna. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se produjese algn fallo. En principio, el hecho de que desde un primer momento se vaya generando cdigo, podra considerarse como un sntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del cdigo se descubre que el diseo de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificacin pura y dura no se realiza (como, por ejemplo, actividades de planificacin, de documentacin, de aseguramiento de la calidad). Esta forma de desarrollar aplicaciones es muy comn en muchas organizaciones y, generalmente, se utiliza cuando no se elige o sigue un enfoque de desarrollo (ciclo de vida) concreto y/o apenas se realiza la actividad de planificacin. Adems, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podr fcilmente familiarizarse con l.

Figure 2 - Desarrollo y la Actualidad

Esta forma de desarrollar software puede ser eficaz en programas pequeos. Para otro tipo de proyectos, puede resultar peligrosa su utilizacin, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se est codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se vern en los siguientes apartados, permitirn, por ejemplo, conocer el progreso, detectar un error lo antes posible, etc. Por lo tanto, es probable que las aplicaciones realizadas segn este enfoque de codificar y probar: Sean poco flexibles, y ante posibles modificaciones se incremente el coste de los proyectos e,

incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de documentacin (lo que provocar problemas de mantenimiento). Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las

funciones requeridas y, adems, lo hagan con una escasa fiabilidad. Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce

el momento exacto en el que se entregarn), aparecen errores una vez que la aplicacin ha sido entregada (lgico al no haberse realizado de forma sistemtica actividades de verificacin y validacin en el proyecto).

Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve un enfoque lgico para su realizacin. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepcin y finalizando cuando ya no se utiliza o se retira. El ciclo de vida software es la descripcin de las distintas formas de desarrollo de un proyecto o aplicacin informtica, es decir, la orientacin que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.

III.

DIFERENCIA ENTRE CICLO DE VIDA Y CICLO DE DESARROLLO

El ciclo de vida es la orientacin a seguir, el conjunto de pasos, etapas y en s mismo todo el proceso desde que surge el problema o se enfrenta, hasta que se construye el software, se aprovecha, se le da mantenimiento y se deja en desuso. El ciclo de desarrollo centra sus esfuerzos en clarificar y detallar todas las etapas y procesos necesarios para la construccin del software (desarrollo) y solo se centra en este subconjunto de todo el ciclo de vida. Por tanto podemos concluir que el ciclo de vida contiene al ciclo de desarrollo.

IV.

DIFERENCIA ENTRE METODOLOGIAS, METODOS, MODELOS, Y ENFOQUE

Cuando nos referimos a los Ciclos de Vida en el desarrollo de Software es comn encontrar estos trminos usados de manera indistinta. La relacin entre palabras mtodo y metodologa es de especie a gnero, en virtud de que los mtodos se incluyen en la metodologa. La palabra metodologa, desde el punto de vista etimolgico, significa el estudio o tratado de los mtodos; pero si asumimos una perspectiva global se presenta como una teora de procedimientos para alcanzar el conocimiento. Un enfoque, independientemente del tipo de enfoque, es la atencin o inters particular sobre un objeto de estudio que parte de una consideracin propia de un campo de conocimiento o cientfico y que tiene como finalidad la comprensin del objeto de estudio. Por otro lado, un modelo es un esquema o representacin de la realidad, de una parte de ella que posee su propia estructura y complejidad. Un modelo es una representacin, fsica o mental de las caractersticas de un objeto o fenmeno con la intencin de analizarlo y comprenderlo. El conocimiento cientfico es que se obtiene a travs de un mtodo, y que el mtodo no es otra cosa que la derivacin de la razn o expresin de la racionalidad del hombre. En virtud de lo anterior puede considerarse que la metodologa tiene por objeto de estudio los mtodos que indican y constituyen las formas o vas idneas a fin de lograr determinado propsito. Por otro lado, El enfoque con que vemos una realidad depende de nuestro punto de vista, y ste depende de nuestro punto de ubicacin. Por ello, para explicar, justificar y demostrar la validez de nuestro enfoque, tenemos que explicar, justificar y demostrar la validez de nuestra ubicacin, es decir, cmo y por qu llegamos ah y, sobre todo, por qu seguimos ah.

Figure 3- Metodologia, Metodo , Enfoque y Modelo

V.

MODELOS DE CICLO DE VIDA

A. 1. 1.1.

TRADICIONALES MODELO CASCADA CONCEPTO: MODELO CASCADA

Creado en 1970 por Winston Royce, deriva de los ciclo de vida de otras ingenieras. El modelo cascada es usado en aproximadamente el 90% de los proyectos, al ser uno de los ms antiguos y conocidos. El modelo cascada define fases consecuentes, para lo cual se debe terminar una cierta etapa antes de pasar a la siguiente. Prescribe una ejecucin secuencial de un subconjunto de los procesos de desarrollo y de administracin. 1.2. ETAPAS: Ingeniera y anlisis de requerimientos: Se estudian todos los requerimientos de sistemas de la organizacin. Anlisis de requerimientos de software: Se revisan los requerimientos funcionales que irn en el software. Diseo: Se jerarquiza la informacin obtenida de los requerimientos y se define la arquitectura del software que se va implementar. Codificacin: Se traduce el diseo en cdigo entendible para la computadora. Pruebas: Se realizan las determinadas pruebas unitarias y de integracin para validar el funcionamiento del sistema. Mantenimiento: Se realiza el soporte y mantenimiento del sistema, ya sea correctivo, adaptativo y/o extensivo.

Figure 4-Fases del Modelo en Cascada

1.3.

VENTAJAS Y DESVENTAJAS

Ventajas del modelo Cascada Fcil entendimiento e implementacin Ampliamente utilizado y conocido (En teora) Refuerza buenos hbitos: definir antes que disear, disear antes que codificar Identifica entregables e hitos Orientado a documentos Funciona bien en productos maduros y equipos dbiles

Desventajas del modelo cascada No aprovecha la iteracin Espera requerimientos definidos completamente al inicio del proyecto = IRREAL Dificultar para integrar administracin del riesgo El software es entregado tarde en el proyecto. Esto hace que se detecten errores graves muy tarde y tambin puede causar impaciencia en el cliente. Hacer cambios es difcil y costoso. Si se ha cometido un error, es muy complicado volver atrs.

2. 2.1.

MODELO CASCADA CON S UB PROYECTOS CONCEPTO

Se entiende como una variacin sobre el ciclo de vida en Cascada del software, denominada Cascada con Sub proyectos, porque permite la ejecucin de algunas de las tareas de la cascada en paralelo

2.2.

ETAPAS

Posee las mismas etapas en esencia que la cascada pura solo que la administracin cambia, al poder ejecutar tareas en paralelo como se puede apreciar a continuacin:

Figure 5 - Fases del Modelo en Cascada con SubProyectos

2.3.

VENTAJAS Y DESVENTAJAS

Ventajas: Se gana tiempo ya que puede haber ms gente trabajando a la vez en varias sub-etapas. Se pueden realizar varias partes del proyecto al mismo tiempo por diferentes desarrolladores. Adecuado para el desarrollo de proyectos complejos que estiman de 1 a 3 aos de desarrollo. Desventaja: Esta metodologa tiene el problema que la planificacin tiene que ser mucho ms cuidadosa, aunque se gana velocidad. Para implementar la metodologa de cascada con sub proyectos se puede pensar Por qu demorar la implementacin de las reas que son fciles de disear solo porque estamos esperando el diseo de un rea difcil? Si la arquitectura dividi el problema en subsistemas independientes, se puede separar en sub proyectos y cada uno puede proceder a su forma.

3. 3.1.

MODELO SASHIMI CONCEPTO

El ciclo de vida tipo Sashimi podra ser considerado como una variacin del ciclo de vida en cascada puro, en el cual las diferentes etapas pueden ser solapadas, permitiendo as aumentar la eficiencia mediante la retroalimentacin entre las etapas. Deriva del modelo cascada y toma el nombre del plato japons servido en rodajas. Este modelo representa las fases que se solapan entre s, comparten documentacin entre s, y permite una ms rpida transicin entre las fases.

En el modelo Sashimi casi siempre se ve representado una fase llamada concepto, en esta fase se definen los resultados que queremos alcanzar con el proyecto, los beneficios, el tipo de tecnologa que usaremos, entre otros. Tambin el diseo se divide mayormente en 2: Un diseo Arquitectnico, que es el de alto nivel, y un diseo detallado, de bajo nivel. 3.2. ETAPAS

En esencia son las mismas etapas que cascada solo que se solapan. Concepto Anlisis Diseo de Arquitectura Diseo Detallado Implementacin Debugging

Figure 6- Etapas del modelo Sashimi

3.3.

VENTAJAS Y DESVENTAJAS

Ventajas No necesita generar tanta documentacin como el ciclo de vida en cascada debido a la continuidad del mismo personal entre fases. Desventajas Es muy difcil gestionar el comienzo y fin de cada etapa y los problemas de la comunicacin, si aparecen, generan inconsistencias en el proyecto. Ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro. Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir inconsistencias.

4. 4.1.

MODELO DE CICLO DE V IDA EN V CONCEPTO

La metodologa V define un procedimiento uniforme para el desarrollo de productos para las Tecnologas de la Informacin y la Comunicacin. Es el estndar utilizado para los proyectos de la Administracin Federal alemana y de defensa. Como est disponible pblicamente muchas compaas lo usan. El modelo en V es una fcil representacin grfica del ciclo de vida de un sistema, que resume la relacin que tiene las diferentes pruebas, y las etapas que cada una de ellas verifica/valida. 4.2. ETAPAS Especificaciones Diseo Preliminar Diseo en Detalle Programacin Prueba de Unidad Integracin Calificacin

Figure 7- Modelo en V

4.3.

VENTAJAS Y

DESVENTAJAS Ventajas La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localizacin de fallos. Es un modelo sencillo y de fcil aprendizaje Hace explcito parte de la iteracin y trabajo que hay que revisar Especifica bien los roles de los distintos tipos de pruebas a realizar Involucra al usuario en las pruebas

Desventajas Es difcil que el cliente exponga explcitamente todos los requisitos El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas El producto final obtenido puede que no refleje todos los requisitos del usuario

5. 5.1.

MODELO FUENTE CONCEPTO

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientacin a objetos. En la base est el anlisis de requerimientos desde la cul va creciendo el ciclo de vida, cayendo solo en la etapa de mantenimiento. En este caso, la piscina es el repositorio de clases. 5.2. ETAPAS Anlisis Diseo Conceptual Componentes Codificacin Pruebas unitarias Pruebas de Sistema Utilizacin Mantenimiento Evolucin
Figure 8 - Modelo Fuente

5.3.

VENTAJAS Y DESVENTAJAS

Ventajas: Dado que hoy en da la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades, debido a todo esto, el ciclo de vida tpico en una metodologa de diseo orientado a objetos como el modelo de ciclo de vida Fuente nos permite una mejor gestin de los cambios. Desventaja: su principal desventaja es que permite un desarrollo muy solapado y es difcil adaptarlo a un modelo iterativo.

B. 1. 1.1.

ITERATIVOS MODELO ESPIRAL CONCEPTO

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988.

Bsicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser as. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada, con el agregado de gestin de riegos.

Figure 9-Modelo en Espiral

1.2.

ETAPAS

1.2.1. DETERMINAR O FIJAR OBJETIVOS Fijar las restricciones. Identificacin de riesgos y estrategias alternativas para evitarlos. Planificacin inicial. Fijar requerimientos, especificacin, manual del usuario.

1.2.2. ANLISIS DEL RIESGO Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir. 1.2.3. DESARROLLAR Y PROBAR Tareas de la actividad propia y de prueba. Anlisis de alternativas e identificacin resolucin de riesgos. Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo.

1.2.2. PLANIFICAR Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad.

1.3.

VENTAJAS Y DESVENTAJAS

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, etc. Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas 2. 2.1. 1988. Con la variante trata de ajustarse ms a la realidad de lo que es un proyecto de desarrollo de software, en el cual el resultado final no es exactamente la implementacin del catlogo de requisitos, sino que una vez definido se renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre cliente y proveedor con el objetivo de intentar que ambas partes queden satisfechas. 2.2. ETAPAS Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos MODELO ESPIRAL WIN -WIN CONCEPTO

Barry Boehm, aos despus realiz una variante o actualizacin del ciclo de vida en espiral que defini en

1.- Identificar las partes interesadas (Stakeholders) para esta nueva iteracin del producto: Es necesario definir los interlocutores que sern de reas que se vern afectadas por el resultado final de la nueva versin. Estos interlocutores sern del rea del cliente (puede haber ms de uno) y del proveedor. 2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cules son las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versin. 3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales para la versin y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta dnde realmente se va a llegar y cmo, intentando llegar a una solucin en la que todos ganen (cliente y proveedor). Las siguientes etapas tienen una correspondencia con algunas variantes, con la versin inicial del ciclo de vida en espiral:

3b.- Establecer los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en cuenta los objetivos y acuerdos de las fases anteriores, se definiran los requisitos de esta versin, adems de especificarse diversas alternativas en el caso de que existan. 4.- Evaluar las alternativas del producto y del proceso y resolucin de riesgos: Se realizara el anlisis del riesgo tpico de los modelos en espiral. 5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completara el proceso de anlisis y realizara el diseo y la construccin. 6.- Validar las definiciones del producto y del proceso: Comprendera la implantacin y aceptacin de la versin, verificndose si el resultado de la iteracin satisface el alcance indicado. 7.- Revisin y comentarios: Tocara hacer inventario, medir el nivel de satisfaccin de las partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Figure 10-Modelo Espiral WIN WIN

2.3.

VENTAJAS Y DESVENTAJAS

Ventajas: El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

Desventajas: Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas. Genera mucho tiempo en el desarrollo de sistemas.

3. 3.1.

MODELO RUP CONCEPTO

El Proceso Unificado de Rational es una metodologa de desarrollo de software orientada a objetos creada por Rational Software Corporation. Fue definido por los creadores del UML unificando los mtodos de Ivar Jacobson, Grady Booch y James Rumbaugh. Este proceso se maneja por casos de uso para la extraccin de requisitos y la identificacin de las partes funcionales en las que se divide la solucin. La metodologa de RUP es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo), este proceso de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. Para su implementacin se hace a travs de cuatro etapas o fases y en cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Principios RUP: 3.2. Adaptar el proceso. Equilibrar propiedades. Demostrar valor iterativo. Colaboracin entre equipos. Elevar el nivel de abstraccin. Enfocarse en la calidad. ETAPAS

El proceso Unificado consta de ciclos que puede repetir a lo largo del ciclo de vida de un sistema. Un ciclo consiste en cuatro fases: Incepcin, Elaboracin, Construccin y Transicin. Un ciclo concluye con una liberacin, tambin hay versiones dentro de un ciclo. Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas: Gestin del cambio y configuraciones Gestin del proyecto Entorno

Esta es una descripcin breve de las fases de un ciclo: Fase de Incepcin: La fase de incepcin establece la viabilidad del producto y delimita el alcance del proyecto. Se describe el producto final. Fase de Elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de Construccin: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Transicin: En la fase de transicin del objetivo es garantizar que los requisitos se han cumplido, con la satisfaccin de las partes interesadas. Esta fase a menudo se inicia con una versin beta de la aplicacin. Otras actividades incluyen la preparacin del ambiente, se completan, se identifican y corrigen defectos. La fase de transicin termina con un cierre dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos. El producto existe en versin Beta. Cabe recalcar que RUP dentro de cada una de sus fases realiza un serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema.

Figure 11- Fases de RUP

3.3.

VENTAJAS Y DESVENTAJAS Lenguaje unificado Procesos predefinidos Maximiza el valor de los servicios de desarrollo Medicin del impacto de los cambios en los proyectos Proporciona una estrategia slida de control de activos

Desventajas Mtodo pesado Por el grado de complejidad puede ser no muy adecuado. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios.

4. 4.1.

MODELO SCRUM CONCEPTO

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Fue desarrollado por Jeff Sutherland y elaborado ms formalmente por Ken Schwaber. Se divide un proyecto en iteraciones (que ellos llaman sprint) de 30 das. La literatura de Scrum se orienta principalmente en la planeacin iterativa y el seguimiento del proceso. Scrum es una metodologa para la gestin y desarrollo de software basada en un proceso iterativo e incremental, uno de sus principios claves radica en el reconocimiento de que durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan. En este modelo se hacen reuniones diarias o tambin denominadas reuniones cortas (15 min aprox) donde se discute lo que se hizo, lo que se hace, y lo que posteriormente se har. Es una ayuda para organizar a las personas y el flujo de trabajo, es importante destacar que en este modelo los equipos son auto-organizados (no autodirigidos), con margen de decisin suficiente para tomar las decisiones que consideren oportunas. 4.2. ETAPAS

El proceso de desarrollo Scrum se compone de cinco actividades principales: revisin de los planes de release; distribucin, revisin y ajuste de los estndares de producto; sprint; revisin de sprint, y cierre. La fase de sprints en la que se realiza el desarrollo de software propiamente dicho. Dentro de un sprint se efectan varias sub-actividades: desarrollo, empaquetado, revisin y ajuste. No existe secuencia dentro de

esta fase. Algunas veces, un tem del backlog debe ser desarrollado, empaquetado y revisado, y otras veces, el tem slo debe ser revisado y ajustado; todo depende de las caractersticas del tem en cuestin. Cada sprint es seguido por un proceso de revisin. Durante esta etapa, se revisa el software desarrollado en el sprint que acaba de finalizar y, de ser necesario, se agregan nuevos tem en el backlog. El grupo de revisores debe incluir a los stakeholders, los administradores del proyecto, los desarrolladores y los usuarios. Las actividades de sprint y revisin de sprint tienen que repetirse hasta que el producto est en condiciones de ser distribuido por los accionistas. Luego, el proyecto entra en la fase de cierre, tras la cual el producto queda en condiciones para el cierre de versin (release) y distribucin. En la fase de cierre, se realizan las ltimas tareas de depuracin (debugging), luego de lo cual se construyen los entregables y el proyecto se da por finalizado. Debido a lo imprevisible de los procesos de desarrollo de software, no es posible definir exactamente cundo ocurrir la fase de cierre, de modo que los proyectos pueden demorarse ms o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se pueden hacer estimaciones sobre su duracin.

Figure 12-Modelo SCRUM

4.3.

VENTAJAS Y DESVENTAJAS

Ventajas Entrega de un producto funcional al finalizar cada Sprint. Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente Visualizacin del proyecto da a da Alcance acotado y viable

Equipos integrados y comprometidos con el proyecto, toda vez que ellos definieron el alcance y se auto-administran

Desventajas No genera toda la evidencia o documentacin de otras metodologas. No es apto para todos los proyectos( en especial proyectos pequeos). Tal vez sea necesario complementarlo con otros procesos (XP)

VI.

CICLOS DE DESARROLLO

1. MODELO CODE & FIX 1.1 CONCEPTO El ciclo de vida Corregir y Codificar es actualmente el modelo bsico ms utilizado actualmente ya que se trata de saltarse todas los pasos del ciclo de vida normal reduciendo a dos pasos nicamente, los cuales son escribir cdigo, instalarlo y corregir los problemas que este ocasione. Esta tcnica est basada en requerimientos ambiguos y sin especificaciones puntuales. Este tipo de ciclo de vida se ve finalizado cuando al fin se satisfacen las necesidades del usuario incluyendo las que fueron saliendo en el camino. Tiene sus ventajas hacer este tipo de tcnica pero en resumen son ms las desventajas que se encontraran. 1.2 ETAPAS Codificar (Code): codificar la parte del software, representa la etapa de escritura de cdigo, el desarrollo en s. Corregir (Fix): corregir errores, agregar funcionalidades o nuevos elementos. Las etapas se repiten una y otra vez con cada nueva funcionalidad, o correccin. 1.3 VENTAJAS Y DESVENTAJ AS Ventajas Excelente para el desarrollo de software de tarea unipersonal. El problema es claramente comprendido La aplicacin es simple segn estndares actuales

Desventajas

No se planifica ni se controla. Despus de una serie de cambios: La estructura del cdigo se hace ms y ms complicada Los cambios siguientes son ms y ms difciles. Los resultados son menos confiables.

2. MODELO RAD 2.1 CONCEPTO 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. 2.2. . ETAPAS Requisitos fase de planificacin. Fase de diseo del usuario. Fase de construccin. Corte y cambio de fase.

Figure 13-Modelo de Desarrollo RAD

2.3.

VENTAJAS Y DESVENTAJ AS

Ventajas: Con los mtodos convencionales pasa un gran lapso de tiempo antes de que el cliente vea resultados. Con los mtodos convencionales el desarrollo llega a tardar tanto que para cuando el sistema est listo para utilizarse los procesos del cliente han cambiado radicalmente. Con los mtodos convencionales no hay nada hasta que el 100% del proceso de desarrollo se ha realizado, entonces se entrega el 100% del software. Desventajas: Con RAD se ha hace difcil asegurar un producto de software con calidad. Se utiliza ms para generar prototipos funcionales. Proyectos grandes pueden verse perjudicados al emplear este ciclo de desarrollo y el sistema puede no cumplir con los estndares.

3. MODELO PROTOTIPADO EVOLUTIVO 3.1. CONCEPTO

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.

3.2.

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

Entrega del desarrollo final

Figure 14- Modelo de Prototipado Evolutivo

3.3.

VENTAJAS Y DESVENTAJ AS

Ventajas: Disminuyen los costes de mantenimiento del producto final. Los tiempos de desarrollo son

inferiores. El tamao del sistema es menor. La especificacin acta como interface entre cliente y equipo de desarrollo. El propio prototipo sirve de contrato con el cliente y cualquier cambio en el prototipo debe estar

consolidado por ambas partes. El prototipo es un documento vivo de buen funcionamiento del producto final. Ayuda para determinar requerimientos expresados en el prototipo. Experimenta sobre los

aspectos del sistema que representan mayor complejidad. Demuestran la viabilidad del sistema. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no

sobre una especificacin escrita.

Desventajas Modelo evolutivo asume que los requerimientos no son completamente conocido al inicio del

proyecto. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de

documentos, programas, datos de test, etc. Desarrollados para distintas versiones del software. 4. 4.1. MODELO BDD CONCEPTO

Behavior-driven development (BDD) es un modelo de desarrollo de software basado en el desarrollo guiado por pruebas (TDD). Desarrollo impulsado por el comportamiento (como tambin se le conoce) combina las tcnicas generales y los principios de TDD con ideas de diseo basada en el dominio y anlisis orientado a objetos y diseo para ofrecer a los desarrolladores de software y analistas de negocios con herramientas compartidas y un proceso compartido para colaborar en el desarrollo de software, con el objetivo de entregar "software que importa". Aunque BDD es principalmente una idea sobre cmo debe gestionarse desarrollo de software por intereses empresariales y conocimientos tcnicos, la prctica de BDD suponer el uso de herramientas de software especializado para apoyar el proceso de desarrollo. Aunque estas herramientas son a menudo desarrolladas especficamente para su uso en proyectos de BDD, pueden ser vistos como formas especializadas de las herramientas que apoya el desarrollo guiado por pruebas. Las herramientas sirven para aadir automatizacin al lenguaje ubicuo que es un tema central de BDD. 4.2. ETAPAS Escribir un test de aceptacin que falle. Escribir un test unitario que falle Hacer que el test pase. Refactorizar

Figure 15- Modelo BDD

4.3.

VENTAJAS Y DESVENTAJ AS

Ventajas: Nos permite atacar el problema de negocio con software que aporta valor Mejor integracin entre especialistas de negocio y desarrolladores Un continuo aporte de valor a un entregable final que crece poco a poco aportando valor desde el inicio. Desventajas: Nuevo paradigma de desarrollo que va en contra del paradigma tradicional. Resistencia frente a equipos tradicionales. Las herramientas que se requieren para ponerlo en prctica no son tan sencillas de aprender.

VII.

CONCLUSIONES

En este trabajo hemos tratado de recopilar y poner en claro los diversos modelos tanto de ciclo de vida que existen (unos pocos de ellos) y algunos de los ms importantes de los ciclos de desarrollo, pues es necesario tener claro las ventajas y desventajas de cada modelo para su correcta y oportuna aplicacin. La adopcin de una buena metodologa contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin que solo se logra a travs de modelos propios de la calidad que se apoyan siempre en los modelos de ciclo de vida para introducirlos dentro de las etapas de desarrollo y prevenir los errores ms que encontrarlos. En conclusin para el desarrollo de un producto de software de calidad es necesario que tengamos en cuenta que ciclo se adapta de mejor manera a nuestro problema, por ejemplo si tenemos claros los requerimientos desde un inicio o estamos frente a un proyecto de reingeniera pues alguno de los modelos tradicionales se ajustara perfectamente, por otro lado si estamos frente a un desarrollo nuevo un modelo iterativo es necesario para administrar correctamente los riesgos del proyecto, por otro lado una opcin gil como Scrum podra ser una carta interesante a considerar dado que es una de las actuales tendencias la agilidad. Sin embargo todo esto debe de considerarse teniendo en cuenta en el equipo, el problema, el presupuesto, los tiempos, la experiencia y las habilidades de los miembros del equipo.

VIII.

BIBLIOGRAFIA
To-Behavior-Driven-Development-BDD-Part

Azad, M. H. (n.d.). Retrieved from CodeProject: http://www.codeproject.com/Articles/148043/Say-Hello-

Hansen, E. (n.d.). Rincon del Vago. Retrieved from http://html.rincondelvago.com/el-ciclo-de-vida-delsoftware.html Hendrickson, E. (n.d.). Test Obsessed. Retrieved from http://testobsessed.com/2008/12/acceptance-testdriven-development-atdd-an-overview/ Jummp. (n.d.). Retrieved from http://jummp.wordpress.com/2011/03/26/desarrollo-de-software-ciclo-devida-por-prototipos/ Keogh, L. (n.d.). Slideshare. Retrieved from http://www.slideshare.net/lunivore/behavior-drivendevelopment-11754474 Kramer, J. (n.d.). Retrieved from http://dis.unal.edu.co/grupos/unbd/manuales/ciclo/cap6.htm Real, E. S. (n.d.). Grupo Alarcos. Retrieved from http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf Smart, J. F. (n.d.). Retrieved from Dos Ideas. Personas y Software: http://www.dosideas.com/noticias/desarrollo-de-software/747-cuantificando-los-beneficios-detdd.html Tadeas, R. (n.d.). Retrieved from Buenas Tareas: http://www.buenastareas.com/ensayos/Codificar-yCorregir-Code-And-Fix/161513.html Universidad de las Palmas de Gran Canaria. (n.d.). Retrieved from http://serdis.dis.ulpgc.es/~a034403/carpeta/is1/Apuntes/UT02.%20Procesos%20del%20software. pdf Vazques, J. (n.d.). Retrieved from https://sites.google.com/site/programacion1electronica/metodologiasde-desarrollo-de-software/modelo-incremental-o-evolutivo Wikipedia. (n.d.). Retrieved from http://es.wikipedia.org/wiki/Desarrollo_en_espiral Wikipedia. (n.d.). Retrieved from http://es.wikipedia.org/wiki/Modelo_de_prototipos Wikipedia. (n.d.). Wikipedia. Retrieved from http://es.wikipedia.org/wiki/Modelo_de_prototipos