Ciclo de Vida Del Software

“AÑO 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 : Control de Calidad de Software

INTEGRANTES : CARDENAS PEÑA, Christopher.

RODRIGUEZ AYBAR, Bryam.

TORALVA BALDEON, Deiby.

ANGULO GASCO, Jesus.

ONOC FUENTES, Américo.

NEIRA LOVERA, Kathia.

ICA - 2012

DEDICATORIA ESTE TRABAJO MONOGRÁFICO ESTÁ

DEDICADO A MIS COMPAÑEROS DE

CLASE, PARA QUE A TRAVÉS DE ÉL SE

PUEDAN INFORMAR Y CONOCER MÁS

ACERCA DEL TEMA DE CICLOS DE VIDA

DEL SOFTWARE, Y ASÍ MISMO PUEDA

SER DE REFERENCIA PARA OCASIONES

FUTURAS.

AGRADECIMIENTO A MIS COMPAÑEROS DEL EQUIPO DE

TRABAJO, YA QUE GRACIAS A SU

APORTE DE INFORMACIÓN SE PUDO

LLEVAR A CABO EL PRESENTE TRABAJO

MONOGRÁFICO.CICLOS DE VIDA DEL

SOFTWARE

ÍNDICE

CONTENTS

Dedicatoria .............................................................................................................................................................................................. 2

Agradecimiento ..................................................................................................................................................................................... 3

Índice ......................................................................................................................................................................................................... 4

I. INTRODUCCION ........................................................................................................................................................................... 7

II. HISTORIA ........................................................................................................................................................................................ 8

III. DIFERENCIA ENTRE CICLO DE VIDA Y CICLO DE DESARROLLO ........................................................................ 9

IV. DIFERENCIA ENTRE METODOLOGIAS, METODOS, MODELOS, Y ENFOQUE ............................................ 10

V. MODELOS DE CICLO DE VIDA ............................................................................................................................................ 11

A. TRADICIONALES ................................................................................................................................................................. 11

1. MODELO CASCADA ..................................................................................................................................................... 11

2. MODELO CASCADA CON SUB PROYECTOS ...................................................................................................... 12

3. MODELO SASHIMI ........................................................................................................................................................ 13

4. MODELO DE CICLO DE VIDA EN “V” ..................................................................................................................... 15

5. MODELO FUENTE .......................................................................................................................................................... 16

B. ITERATIVOS ........................................................................................................................................................................... 16

1. MODELO ESPIRAL ......................................................................................................................................................... 16

2. MODELO ESPIRAL WIN -WIN ................................................................................................................................... 18

3. MODELO RUP ................................................................................................................................................................. 20

4. MODELO SCRUM .......................................................................................................................................................... 22

VI. CICLOS DE DESARROLLO ................................................................................................................................................ 24

1. MODELO CODE & FIX ...................................................................................................................................................... 24

1.1 CONCEPTO ...................................................................................................................................................................... 24

1.2 ETAPAS .............................................................................................................................................................................. 24

1.3 VENTAJAS Y DESVENTAJAS ...................................................................................................................................... 24

2. MODELO RAD ...................................................................................................................................................................... 25

2.1 CONCEPTO .......................................................................................................................................................................... 25

2.2. ETAPAS ......................................................................................................................................................................... 25

2.3. VENTAJAS Y DESVENTAJAS ................................................................................................................................. 26

3. MODELO PROTOTIPADO EVOLUTIVO ....................................................................................................................... 26

3.1. CONCEPTO ................................................................................................................................................................. 26

3.2. ETAPAS ......................................................................................................................................................................... 26


4. MODELO BDD ...................................................................................................................................................................... 28

4.1. CONCEPTO ................................................................................................................................................................. 28

4.2. ETAPAS ......................................................................................................................................................................... 28


VII. CONCLUSIONES ................................................................................................................................................................. 29

VIII. 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 término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase

final. Tiene como propósito definir las distintas fases intermedias que se requieren para validar el

desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la

aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados

son apropiados.

Estas metodologías se originan en el hecho de que es muy costoso rectificar los errores que se detectan

tarde dentro de la fase de implementación. 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 implementación y en los costos asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.

• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y

examinar cualquier restricción que haya, ya sea en el aspecto económico, técnico u operativo.

• Diseño general: requisitos generales de la arquitectura de la aplicación.

• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

• Programación: es el uso de un lenguaje de programación para crear las funciones definidas durante

la etapa de diseño.

• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se

implementaron de acuerdo con las especificaciones.

• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el

propósito de la prueba de integración que está cuidadosamente documentada.

• Prueba beta (o validación): para garantizar que el software cumple con las especificaciones

originales.

• Documentación: sirve para documentar información necesaria para los usuarios del software y para

desarrollos futuros.

• Implementación: también conocido como pase a producción supone la instalación 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 informáticas se llevaba a cabo de forma individualizada, a

base de codificar y probar lo realizado cuanto antes. A lo largo de los años esto fueron surgiendo los

llamados “Ciclos de Vida” que son una descripción de las distintas formas de desarrollo de una aplicación

informática

Hace años el desarrollo era así: la misma persona escribía el código, lo ejecutaba y, si fallaba, lo depuraba.

El proceso se realizaba sin ninguna planificación previa y sin que soliese existir documentación alguna.

Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona

estaría allí cuando se produjese algún fallo.

En principio, el hecho de que desde un primer momento se vaya generando código, podría considerarse

como un síntoma 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 código se

descubre que el diseño 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 codificación pura y dura no se realiza

(como, por ejemplo, actividades de planificación, de documentación, de aseguramiento de la calidad).

Esta forma de desarrollar aplicaciones es muy común 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 planificación.

Además, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca

experiencia y cualquier persona podrá fácilmente familiarizarse con él.

Figure 2 - Desarrollo y la Actualidad

Esta forma de desarrollar software puede ser eficaz en programas pequeños. Para otro tipo de proyectos,

puede resultar peligrosa su utilización, 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 verán en los siguientes apartados, permitirán, por ejemplo,

conocer el progreso, detectar un error lo antes posible, etc.

Por lo tanto, es probable que las aplicaciones realizadas según 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 documentación (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, además, 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 entregarán), aparecen errores una vez que la aplicación ha sido

entregada (lógico al no haberse realizado de forma sistemática actividades de verificación y validación en

el proyecto).

Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve un enfoque lógico para su

realización. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepción y

finalizando cuando ya no se utiliza o se retira.

El ciclo de vida software es la descripción de las distintas formas de desarrollo de un proyecto o aplicación

informática, es decir, la orientación que debe seguirse para obtener, a partir de los requerimientos del

cliente, sistemas que puedan ser utilizados por dicho cliente. También 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 orientación 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 construcción 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 común encontrar estos

términos usados de manera indistinta.

La relación entre palabras método y metodología es de especie a género, en virtud de que los métodos se

incluyen en la metodología. La palabra metodología, desde el punto de vista etimológico, significa el

estudio o tratado de los métodos; pero si asumimos una perspectiva global se presenta como una teoría

de procedimientos para alcanzar el conocimiento.

Un enfoque, independientemente del tipo de enfoque, es la atención o interés particular sobre un objeto

de estudio que parte de una consideración propia de un campo de conocimiento o científico y que tiene

como finalidad la comprensión del objeto de estudio.

Por otro lado, un modelo es un esquema o representación de la realidad, de una parte de ella que posee

su propia estructura y complejidad. Un modelo es una representación, física o mental de las características

de un objeto o fenómeno con la intención de analizarlo y comprenderlo.

El conocimiento científico es que se obtiene a través de un método, y que el método no es otra cosa que

la derivación de la razón o expresión de la racionalidad del hombre. En virtud de lo anterior puede

considerarse que la metodología tiene por objeto de estudio los métodos que indican y constituyen las

formas o vías idóneas a fin de lograr determinado propósito. Por otro lado, El enfoque con que vemos

una realidad depende de nuestro punto de vista, y éste depende de nuestro punto de ubicación. Por ello,

para explicar, justificar y demostrar la validez de nuestro enfoque, tenemos que explicar, justificar y

demostrar la validez de nuestra ubicación, es decir, cómo 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. TRADICIONALES

1. MODELO CASCADA

1.1. CONCEPTO: MODELO CASCADA

Creado en 1970 por Winston Royce, deriva de los ciclo de vida de otras ingenierías. El modelo cascada es

usado en aproximadamente el 90% de los proyectos, al ser uno de los más 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 ejecución secuencial de un subconjunto de los procesos de desarrollo y

de administración.

1.2. ETAPAS:

• Ingeniería y análisis de requerimientos: Se estudian todos los requerimientos de

sistemas de la organización.

• Análisis de requerimientos de software: Se revisan los requerimientos funcionales que

irán en el software.

• Diseño: Se jerarquiza la información obtenida de los requerimientos y se define la

arquitectura del software que se va implementar.

• Codificación: Se traduce el diseño en código entendible para la computadora.

• Pruebas: Se realizan las determinadas pruebas unitarias y de integración 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

• Fácil entendimiento e implementación

• Ampliamente utilizado y conocido (En teoría)

• Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar

• Identifica entregables e hitos

• Orientado a documentos

• Funciona bien en productos maduros y equipos débiles

Desventajas del modelo cascada

• No aprovecha la iteración

• Espera requerimientos definidos completamente al inicio del proyecto = IRREAL

• Dificultar para integrar administración del riesgo

• El software es entregado tarde en el proyecto. Esto hace que se detecten errores graves

muy tarde y también puede causar impaciencia en el cliente.

• Hacer cambios es difícil y costoso. Si se ha cometido un error, es muy complicado volver

atrás.

2. MODELO CASCADA CON SUB PROYECTOS

2.1. CONCEPTO

Se entiende como una variación sobre el ciclo de vida en Cascada del software, denominada Cascada con

Sub proyectos, porque permite la ejecución 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 administración cambia, al poder

ejecutar tareas en paralelo como se puede apreciar a continuación:

Figure 5 - Fases del Modelo en Cascada con SubProyectos


Ventajas: Se gana tiempo ya que puede haber más 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 años de desarrollo.

Desventaja: Esta metodología tiene el problema que la planificación tiene que ser mucho más cuidadosa,

aunque se gana velocidad.

Para implementar la metodología de cascada con sub proyectos se puede pensar “¿Por qué demorar la

implementación de las áreas que son fáciles de diseñar solo porque estamos esperando el diseño de un

área difícil?” Si la arquitectura dividió el problema en subsistemas independientes, se puede separar en

sub proyectos y cada uno puede proceder a su forma.

3. MODELO SASHIMI

3.1. CONCEPTO

El ciclo de vida tipo Sashimi podría ser considerado como una variación del ciclo de vida en cascada puro,

en el cual las diferentes etapas pueden ser solapadas, permitiendo así aumentar la eficiencia mediante la

retroalimentación entre las etapas.

Deriva del modelo cascada y toma el nombre del plato japonés servido en rodajas. Este modelo

representa las fases que se solapan entre sí, comparten documentación entre sí, y permite una más rápida

transición 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 tecnología que

usaremos, entre otros.

También el diseño se divide mayormente en 2: Un diseño Arquitectónico, que es el de alto nivel, y un

diseño detallado, de bajo nivel.

3.2. ETAPAS

En esencia son las mismas etapas que cascada solo que se solapan.

• Concepto

• Análisis

• Diseño de Arquitectura

• Diseño Detallado

• Implementación

• Debugging

Figure 6- Etapas del modelo Sashimi


Ventajas

• No necesita generar tanta documentación como el ciclo de vida en cascada debido a la

continuidad del mismo personal entre fases.

Desventajas

• Es muy difícil gestionar el comienzo y fin de cada etapa y los problemas de la comunicación,

si aparecen, generan inconsistencias en el proyecto.

• Más difícil 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 comunicación pueden surgir inconsistencias.

4. MODELO DE CICLO DE V IDA EN “V”

4.1. CONCEPTO

La metodología V define un procedimiento uniforme para el desarrollo de productos para las Tecnologías

de la Información y la Comunicación. Es el estándar utilizado para los proyectos de la Administración

Federal alemana y de defensa. Como está disponible públicamente muchas compañías lo usan.

El modelo en V es una fácil representación gráfica del ciclo de vida de un sistema, que resume la relación

que tiene las diferentes pruebas, y las etapas que cada una de ellas verifica/valida.

4.2. ETAPAS

• Especificaciones

• Diseño Preliminar

• Diseño en Detalle

• Programación

• Prueba de Unidad

• Integración

• Calificación

4.3. VENTAJAS Y

DESVENTAJAS

Ventajas

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la

localización de fallos.

• Es un modelo sencillo y de fácil aprendizaje

• Hace explícito parte de la iteración 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 difícil que el cliente exponga explícitamente 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

Figure 7- Modelo en V

5. MODELO FUENTE

5.1. CONCEPTO

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la

orientación a objetos. En la base está el análisis de requerimientos desde la cuál 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

• Análisis

• Diseño Conceptual

• Componentes

• Codificación

• Pruebas unitarias

• Pruebas de Sistema

• Utilización

• Mantenimiento

• Evolución


Ventajas: Dado que hoy en día 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 típico en una

metodología de diseño orientado a objetos como el modelo de ciclo de vida Fuente nos permite una

mejor gestión de los cambios.

Desventaja: su principal desventaja es que permite un desarrollo muy solapado y es difícil adaptarlo a

un modelo iterativo.

B. ITERATIVOS

1. MODELO ESPIRAL

1.1. CONCEPTO

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

Boehm en 1988.

Figure 8 - Modelo Fuente

Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el

centro. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función

del análisis 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 sistemáticos del Modelo Cascada, con el agregado de gestión de riegos.

Figure 9-Modelo en Espiral

1.2. ETAPAS

1.2.1. DETERMINAR O FIJAR OBJETIVOS

• Fijar las restricciones.

• Identificación de riesgos y estrategias alternativas para evitarlos.

• Planificación inicial.

• Fijar requerimientos, especificación, manual del usuario.

1.2.2. ANÁLISIS DEL RIESGO

• Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no

deseados y los daños y consecuencias que éstas puedan producir.

1.2.3. DESARROLLAR Y PROBAR

• Tareas de la actividad propia y de prueba.

• Análisis de alternativas e identificación resolución de riesgos.

• Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo.

1.2.2. PLANIFICAR

• Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases

siguientes y planificamos la próxima actividad.

http://commons.wikimedia.org/wiki/File:ModeloEspiral.svg


Ventajas

• El análisis del riesgo se hace de forma explícita 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.

• Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la

metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

• Genera mucho tiempo en el desarrollo del sistema

• Modelo costoso

• Requiere experiencia en la identificación de riesgos

2. MODELO ESPIRAL WIN -WIN

2.1. CONCEPTO

Barry Boehm, años después realizó una variante o actualización del ciclo de vida en espiral que definió en

1988.

Con la variante trata de ajustarse más a la realidad de lo que es un proyecto de desarrollo de software, en

el cual el resultado final no es exactamente la implementación del catálogo 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

1.- Identificar las partes interesadas (Stakeholders) para esta nueva iteración del producto: Es necesario

definir los interlocutores que serán de áreas que se verán afectadas por el resultado final de la nueva

versión. Estos interlocutores serán del área del cliente (puede haber más de uno) y del proveedor.

2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cuáles son

las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales

para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar

hasta dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen

(cliente y proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión 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 definirían los requisitos de esta versión, además de

especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis del

riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el

proceso de análisis y realizaría el diseño y la construcción.

6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la

versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción 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


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 construcción de

prototipos en cualquier etapa de evolución del producto.

• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las

etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se

conviertan en problemas.

Desventajas:

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

• Genera mucho tiempo en el desarrollo de sistemas.

3. MODELO RUP

3.1. CONCEPTO

El Proceso Unificado de Rational es una metodología de desarrollo de software orientada a objetos

creada por Rational Software Corporation. Fue definido por los creadores del UML unificando los

métodos de Ivar Jacobson, Grady Booch y James Rumbaugh. Este proceso se maneja por casos de uso

para la extracción de requisitos y la identificación de las partes funcionales en las que se divide la

solución.

La metodología de RUP es una forma disciplinada de asignar tareas y responsabilidades en una empresa

de desarrollo (quién hace qué, cuándo y cómo), este proceso de RUP estiman tareas y horario del plan

midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. Para su implementación

se hace a través 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:

• Adaptar el proceso.

• Equilibrar propiedades.

• Demostrar valor iterativo.

• Colaboración entre equipos.

• Elevar el nivel de abstracción.

• Enfocarse en la calidad.

3.2. 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: Incepción, Elaboración, Construcción y Transición. Un ciclo concluye con una

liberación, también hay versiones dentro de un ciclo.

• Modelado de negocio

• Requisitos

• Análisis y Diseño

• Implementación

• Pruebas

• Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

• Gestión del cambio y configuraciones

• Gestión del proyecto

• Entorno

Esta es una descripción breve de las fases de un ciclo:

• Fase de Incepción: La fase de incepción establece la viabilidad del producto y delimita el alcance

del proyecto. Se describe el producto final.

• Fase de Elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten

definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación

de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la

solución preliminar.

• Fase de Construcción: El propósito 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 Transición: En la fase de transición del objetivo es garantizar que los requisitos se han

cumplido, con la satisfacción de las partes interesadas. Esta fase a menudo se inicia con una

versión beta de la aplicación. Otras actividades incluyen la preparación del ambiente, se

completan, se identifican y corrigen defectos. La fase de transición termina con un cierre

dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos. El producto existe en

versión Beta.

Cabe recalcar que RUP dentro de cada una de sus fases realiza un serie de artefactos que sirven para

comprender mejor tanto el análisis como el diseño del sistema.

Figure 11- Fases de RUP


• Lenguaje unificado

• Procesos predefinidos

• Maximiza el valor de los servicios de desarrollo

• Medición del impacto de los cambios en los proyectos

• Proporciona una estrategia sólida de control de activos

Desventajas

• Método pesado

• Por el grado de complejidad puede ser no muy adecuado.

• En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del

equipo de profesionales necesarios.

4. MODELO SCRUM

4.1. CONCEPTO

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para

trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas

prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de

equipos altamente productivos.

Fue desarrollado por Jeff Sutherland y elaborado más formalmente por Ken Schwaber. Se divide un

proyecto en iteraciones (que ellos llaman sprint) de 30 días. La literatura de Scrum se orienta principalmente

en la planeación iterativa y el seguimiento del proceso.

Scrum es una metodología para la gestión 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 también 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 auto-

dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas.

4.2. ETAPAS

El proceso de desarrollo Scrum se compone de cinco actividades principales: revisión de los planes de

release; distribución, revisión y ajuste de los estándares de producto; sprint; revisión de sprint, y cierre.

La fase de sprint’s en la que se realiza el desarrollo de software propiamente dicho. Dentro de un sprint se

efectúan varias sub-actividades: desarrollo, empaquetado, revisión 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 sólo debe ser revisado y ajustado; todo depende de las características del ítem en cuestión.

Cada sprint es seguido por un proceso de revisión. 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 revisión 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 versión (release) y distribución. En la fase de cierre, se

realizan las últimas tareas de depuración (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 cuándo ocurrirá la fase de cierre, de modo que los proyectos pueden

demorarse más o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se

pueden hacer estimaciones sobre su duración.

Figure 12-Modelo SCRUM


Ventajas

• Entrega de un producto funcional al finalizar cada Sprint.

• Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente

• Visualización del proyecto día a día

• 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 documentación de otras metodologías.

• No es apto para todos los proyectos( en especial proyectos pequeños).

• 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 básico más 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 código, instalarlo y corregir los problemas que este ocasione.

Esta técnica 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 técnica pero en resumen son más las desventajas que se

encontraran.

1.2 ETAPAS

Codificar (Code): codificar la parte del software, representa la etapa de escritura de código, 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 corrección.

1.3 VENTAJAS Y DESVENTAJAS

Ventajas

• Excelente para el desarrollo de software de tarea unipersonal.

• El problema es claramente comprendido

• La aplicación es simple según estándares actuales

Desventajas

• No se planifica ni se controla.

• Después de una serie de cambios:

• La estructura del código se hace más y más complicada

• Los cambios siguientes son más y más difíciles.

• Los resultados son menos confiables.

2. MODELO RAD

2.1 CONCEPTO

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el

desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término

originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin

en 1991.

2.2. ETAPAS

. Requisitos fase de planificación.

• Fase de diseño del usuario.

• Fase de construcción.

• Corte y cambio de fase.

Figure 13-Modelo de Desarrollo RAD


Ventajas:

• Con los métodos convencionales pasa un gran lapso de tiempo antes de que el cliente vea

resultados.

• Con los métodos 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 métodos 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 difícil asegurar un producto de software con calidad.

• Se utiliza más para generar prototipos funcionales.

• Proyectos grandes pueden verse perjudicados al emplear este ciclo de desarrollo y el sistema

puede no cumplir con los estándares.

3. MODELO PROTOTIPADO EVOLUTIVO

3.1. CONCEPTO

En Ingeniería 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 diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles

para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es

evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software

que se desarrollará. La interacción 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 rápido

• Modelado, diseño rápido

• Construcción del Prototipo

• Desarrollo, entrega y retroalimentación

• Comunicación

• Entrega del desarrollo final

Figure 14- Modelo de Prototipado Evolutivo


Ventajas:

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

inferiores.

• El tamaño del sistema es menor.

• La especificación actúa 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 especificación 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 manipulación de

documentos, programas, datos de test, etc. Desarrollados para distintas versiones del software.

4. MODELO BDD

4.1. 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 también se le conoce)

combina las técnicas generales y los principios de TDD con ideas de diseño basada en el dominio y

análisis orientado a objetos y diseño 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 cómo debe gestionarse desarrollo de software por

intereses empresariales y conocimientos técnicos, la práctica de BDD suponer el uso de herramientas de

software especializado para apoyar el proceso de desarrollo. Aunque estas herramientas son a menudo

desarrolladas específicamente 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 añadir automatización al lenguaje ubicuo que es un tema central de BDD.

4.2. ETAPAS

• Escribir un test de aceptación que falle.

• Escribir un test unitario que falle

• Hacer que el test pase.

• Refactorizar

Figure 15- Modelo BDD


Ventajas:

• Nos permite atacar el problema de negocio con software que aporta valor

• Mejor integración 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 práctica 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 más importantes de los ciclos de desarrollo, pues es

necesario tener claro las ventajas y desventajas de cada modelo para su correcta y oportuna aplicación.

La adopción de una buena metodología 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 evaluación que solo se logra

a través 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 más que encontrarlos.

En conclusión 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 reingeniería pues alguno de los

modelos tradicionales se ajustaría 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 opción ágil como Scrum podría 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

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

To-Behavior-Driven-Development-BDD-Part

Hansen, E. (n.d.). Rincon del Vago. Retrieved from http://html.rincondelvago.com/el-ciclo-de-vida-del-

software.html

Hendrickson, E. (n.d.). Test Obsessed. Retrieved from http://testobsessed.com/2008/12/acceptance-test-

driven-development-atdd-an-overview/

Jummp. (n.d.). Retrieved from http://jummp.wordpress.com/2011/03/26/desarrollo-de-software-ciclo-de-

vida-por-prototipos/

Keogh, L. (n.d.). Slideshare. Retrieved from http://www.slideshare.net/lunivore/behavior-driven-

development-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-de-

tdd.html

Tadeas, R. (n.d.). Retrieved from Buenas Tareas: http://www.buenastareas.com/ensayos/Codificar-y-

Corregir-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/metodologias-

de-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

Documents

Ciclo de Vida Del Software