Ciclo de vida y Metodologías de Desarrollo de Software(o).pdf

Universidad Nacional “San Luis Gonzaga” de Ica

Facultad de Ingeniería de Sistemas

Ciclo de vida y Metodologías de Desarrollo de Software

Ing. Antonio Alonzo Morales Loayza

Elaborada por:

Acuache Yalle, Kenny

Anchante Muñoz, Alexander

Caballero Quispe, Edison

Conislla Yallico, Martin

Hernández Hernández, Juan

Quinteros Tumba, Eduardo


2

Facultad de Ingeniería de Sistemas - UNICA

El presente trabajo de investigación

monográfica se lo dedicamos a nuestros

padres; quienes siempre han estado en todo

momento apoyándonos para poder estar en

donde ahora estamos.

A Dios, ya que gracias a él tenemos esos

padres maravillosos que nos guían día a día

para ser cada vez mejores personas.

A nuestros profesores, quienes nos brindan sus

conocimientos y nos guían a lo largo de

nuestro camino universitario para poder ser

profesionales valiosos para la sociedad.

Dedicatoria


3


Objetivos

Conocer los antecedentes del ciclo de vida del Software.

Entender el concepto de ciclo de vida del software.

Comprender las actividades dentro del ciclo de vida del software.

Analizar los diversos modelos del ciclo de vida del software.

Comprender las diferencias existentes entre los distintos modelos de desarrollo.

Analizar las metodologías existentes para el desarrollo de software.

Entender la diferencia entre ciclo de vida y metodologías de desarrollo.

Comprender las herramientas que se utilizan en las metodologías para el

desarrollo.

Evaluar las diferencias existentes entre las distintas metodologías.


4


Contenido

Dedicatoria…………………………………………………………………………………………………………………………………………2

Objetivos…………………………………………………………………………………………………………………………………………….3

Contenido…………………………………………………………………………………………………………………………………………..4

Introducción……………………………………………………………………………………………………………………………………....6

Ciclo de Vida del Software………………………………………………………………………………………………………………....7

1. Historia y Antecedentes………………………………………………………………………………………………………………7

2. El Antiguo Enfoque………………………………………………………………………………………………………………….....8

3. ¿Qué es el Ciclo de Vida del Software?...........................................................................................9

4. Actividades del Ciclo de Vida del Software………………………………………………………………………………….9

Modelos de Ciclo de Vida del Software…………………………………………………………………………………………….10

1. Modelos de Ciclo de Vida de Software………………………………………………………………………………………10

2. Diferencias entre Modelos………………………………………………………………………………………………………..11

3. Modelos Destacados…………………………………………………………………………………………………………………11

3.1 Modelo Clásico o Cascada…………………………………………………………..………………………………………11

3.2 Modelo Espiral……………………………………………………………………………………………………………………13

3.3 Desarrollo de Prototipos…………………………………………………………………………………………………….14

3.4 Modelo en V……………………………………………………………………………………………………………………….17

3.5 Modelo R.A.D……………………………………………………………………………………………………………………..18

3.6 Ciclo de Vida Orientado a Objetos………………………………………………………………………………………20

Metodologías para el Desarrollo de Software………………………………………………………………………………….21

Ciclo de Vida y Metodologías de

Desarrollo de Software


5


1. ¿Metodologías y Ciclo de Vida del Software?...............................................................................22

2. Metodologías Existentes…………………………………………………………………………………………………………..22

2.1 Metodologías Tradicionales…………………………………………..………………………………………..…………22

2.1.1 RUP (Rational Unified Procces)…………………………….……………………………………..………..23

2.1.2 ICONIX…………………………………………………………………..………………………………………………28

2.2 Metodologías Agiles………………….…………………………………….……………………………………..………….30

2.2.1 Extreme Programming XP…………………………….………….………………..………………………….30

2.2.2 SCRUM………………………………………………………………………………..…………………………………33

3. Diferencias: Tradicional vs Ágil………………………………………………………….…………………….…….….……..37

Conclusiones………………………………………………………………………………………………………………………….………..38

Recomendaciones……………………………………………………………………………………………………………………….……39

Glosario..………………………………………………………………………………………………………………………………….………40

Bibliografía……………………………………………………………………………………………………………………….….…..………41


6


Introducción

El presente trabajo de investigación tiene como objetivo dar a conocer y poner en práctica

los conocimientos sobre Ciclos de Vida del Software y sus Metodologías de Desarrollo y

la importante relación que existe entre estos para el adecuado desarrollo de un proyecto

de software.

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo

y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo

mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad

de construir un sistema de software hasta que este es retirado, se identifican varias etapas

que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de

cuales sean las características del proyecto, se configurará el ciclo de vida de forma

diferente.

Sin embargo, las exigencias del mercado, la competencia empresarial, el convencimiento

y la satisfacción total de los clientes, son algunos de los puntos que muchas empresas de

desarrollo aún no alcanzan por no considerar un tema de gran auge como es la calidad.

Para esto las Metodologías de Desarrollo de Software tienen como objetivo presentar un

conjunto de técnicas tradicionales y modernas de modelado de sistemas que nos indican

los procedimientos de trabajo que nos permitan desarrollar software de calidad.


7


Ciclo de Vida del Software

1. HISTORIA Y ANTECEDENTES

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

Esta forma de desarrollar aplicaciones es muy común en muchos desarrolladores 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.

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,

es basarnos en un modelo de ciclo de vida que nos permitirá, por ejemplo, conocer el

progreso del proyecto, detectar un error lo antes posible, etc.


8


2. EL ANTIGUO ENFOQUE

Es probable que las aplicaciones realizadas según el antiguo 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.


9


3. ¿QUE ES EL CICLO DE VIDA DEL

SOFTWARE?

Es la forma mediante la cual se describen los

diferentes pasos que se deben seguir para el

desarrollo de un software, partiendo desde una

necesidad hasta llegar a la puesta en marcha de

una solución y su apropiado mantenimiento. El

ciclo de vida para un software comienza cuando

se tiene la necesidad de resolver un problema, y

termina cuando el programa que se desarrolló

para cumplir con los requerimientos, deja de ser

utilizado.

El propósito del ciclo de vida es definir las distintas fases intermedias que se requieren

para validar el desarrollo del software, es decir, para garantizar que el software cumpla

los requisitos establecidos por el cliente.

4. ACTIVIDADES DEL CICLO DE VIDA DEL SOFTWARE

Implícita o Explícitamente todos los modelos de ciclo de vida cuentan por lo menos con

las siguientes actividades:

Requerimientos: En la primera fase del ciclo de vida del software, se enlistan las

tareas que el software debe desarrollar, los problemas a ser resueltos, y en esta

fase se estudian sus causas y efectos.

Diseño: En la fase de diseño, el objetivo es conocer las relaciones entre los

módulos del programa, y garantizar que se cumplen cabalmente los

requerimientos solicitados de una manera eficiente, lógica y completa.


10


Los diseñadores de software consideran los recursos de hardware y software

disponibles para poder alcanzar su objetivo.

Implementación: Es la etapa donde efectivamente se programa el sistema. Durante esta

fase, el programa se escribe en un lenguaje de programación. Los programas se

escriben usualmente en módulos separados, cada módulo desarrolla alguna tarea

específica y debe funcionar independientemente y en relación con el resto del

programa.

Pruebas: Durante la fase de pruebas, el programa se ejecuta y se revisa. Las tareas

deben ejecutarse sin errores en los resultados y también sin errores fatales. Los

defectos en los programas se llaman bugs.

Mantenimiento: Una vez que el sistema está completamente implementado y

probado, se pone en marcha la fase de mantenimiento en la que se realiza todos

los procedimientos correctivos (mantenimiento correctivo) y el mantenimiento y

las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de

una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente

y el equipo de desarrolladores.

Modelos de Ciclo de Vida del Software

1. MODELOS DE CICLO DE VIDA DE SOFTWARE

Los modelos de ciclo de vida software son 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.


11


2. DIFERENCIAS ENTRE MODELOS

Las principales diferencias entre distintos modelos de ciclo de vida están divididas en tres

grandes visiones:

El alcance del ciclo de vida, que depende de hasta dónde deseamos llegar con el

Proyecto: sólo saber si es viable el desarrollo de un producto, el desarrollo

completo o el desarrollo completo más las actualizaciones y el mantenimiento.

La calidad y cantidad de las etapas en que dividiremos el ciclo de vida: según

el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos.

La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si

tenemos libertad de repetirlas (iterar).

3. MODELOS DESTACADOS

Existen varias versiones del ciclo de vida del software entre las cuales se destacan:

Modelo Clásico o en cascada

Modelo en espiral

Desarrollo de prototipos

Modelo en V.

Modelo R.A.D.

Modelo Orientado a Objetos

3.1. Modelo Clásico o Cascada

Es el modelo más antiguo, propuesto por Winston Royce en1970.

Como sugiere el esquema del modelo en cascada, antes de poder avanzar a la

siguiente etapa, es necesario haber finalizado completamente la etapa anterior.

Asociada con cada etapa del proceso existen hitos y documentos, de tal forma que

se puede utilizar el modelo para comprobar los avances del proyecto y para estimar

cuánto falta para su finalización.


12


Ventajas:

Es un modelo sencillo y disciplinado.

Es fácil aprender a utilizarlo y comprender su funcionamiento.

Está dirigido por los tipos de documentos y resultados que deben obtenerse

al final de cada etapa.

Ayuda a detectar errores en las primeras etapas a bajo costo.

Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas.

Desventajas:

Los proyectos raramente siguen el proceso lineal tal como se definía

originalmente el ciclo de vida.

Es difícil que el cliente exponga explícitamente todos los requisitos al

principio.

El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de

vida.

Puede resultar complicado regresar a etapas anteriores (ya acabadas) para

realizar correcciones.

El producto final obtenido puede que no refleje todos los requisitos del

usuario.


13


3.2. Modelo en Espiral

Publicado por Boehm en 1988, este sustituye a la solución en fases del “modelo en

cascada” con ciclos de experimentación y aprendizaje. El modelo incorpora un nuevo

elemento en el desarrollo de software como es el “análisis de riesgos” y define cuatro

actividades principales representadas por los cuatro cuadrantes de la figura:

1) Planificación: Determina objetivos, alternativas y restricciones

2) Análisis de riesgo: Evalúa alternativas, identifica y resuelve riesgos.

3) Ingeniería: Desarrollo y verificación del producto del siguiente nivel.

4) Evaluación del cliente: Valoración de los resultados y planificación de la

siguiente fase.

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia

el exterior), se van construyendo sucesivas versiones del software, cada vez más

completas.


14


Ventajas:

Proporciona el potencial para el desarrollo rápido de versiones

incrementales.

Puede adaptarse y aplicarse a lo largo de la vida del software.

Permite aplicar el enfoque de construcción de prototipos en cualquier

momento para reducir riesgos.

Reduce los riesgos antes de que se conviertan en problemáticos.

Monitoriza y controla los riesgos continuamente.

Desventajas:

Puede resultar difícil convencer a algunos clientes de que el enfoque

evolutivo es controlable.

Solo resulta aplicable para proyectos de gran tamaño.

Supone una carga de trabajo adicional, no presente en otros ciclos de vida

Requiere una considerable habilidad para la evaluación y resolución del

riesgo, y se basa en esta habilidad para el éxito.

Es bastante complicado de realizar y su complejidad puede incrementarse

hasta hacerlo impracticable.

3.3. Desarrollo de prototipos

El modelo de ciclo de vida de prototipos fue

propuesto por Gomaa en 1984.

Un prototipo es un mecanismo para

identificar los requisitos del software. La

construcción de prototipos es un proceso que

facilita al ingeniero de software el desarrollo

de la aplicación. El prototipo suele tomar una

de las tres formas siguientes:

• Un modelo en papel o en computadora que describe la interacción hombre-máquina,

de forma que facilite al usuario la comprensión de su funcionamiento. Por ejemplo, si

el sistema a construir es un cajero automático, se puede hacer un programa que

simule la interacción del usuario con el cajero sin que el programa esté conectado a

ninguna base de datos real ni se despache dinero. De esta manera el cliente puede


15


hacerse a la idea de cómo va a funcionar el sistema final sin tener que construirlo, y

así discutirlo con el ingeniero de software.

• Un modelo que implementa una función requerida importante. Es el mismo caso que

anteriormente pero sin centrarse en la interacción hombre-máquina. Por ejemplo, el

modelo podría simular todos los pasos a seguir internamente en el sistema en el

acceso a la base de datos de clientes cuando se quiere obtener dinero del cajero, pero

sin que realmente se trate de una base de datos real ni de un cliente del banco.

• Un programa real que se adecue en parte al software que se desea desarrollar. Por

ejemplo, se puede disponer de una aplicación relacionada con un “cajero

automático”, que al presentarla al cliente, permita al analista identificar las

necesidades del cliente y por lo tanto los requisitos del software a construir.

Normalmente, el prototipo sirve como mecanismo para identificar los requisitos del

software, y su construcción suele llevar las siguientes etapas:

1) Recolección de requisitos. El ingeniero de software y el cliente definen los

objetivos globales del software, y aquéllos más específicos que se desean destacar

con el prototipo.


16


2) Diseño rápido: Centrado en los aspectos del software visible al usuario (por

ejemplo, interfaz de usuario, entradas y salidas…).

3) Construcción del prototipo.

4) Evaluación del prototipo: Se realiza por el cliente y usuarios, lo que permitirá

concretar y refinar los requisitos del software a desarrollar.

5) Refinamiento del prototipo: Se produce un proceso iterativo en el que el

prototipo es refinado para que satisfaga las necesidades del cliente, al tiempo que

facilita al ingeniero de software un mejor conocimiento del sistema.

6) Producto: En la mayoría de los casos este sistema refinado (piloto) hay que

desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe

planificar con el acuerdo expreso del cliente.

Algunos ingenieros del software abogan por desarrollar rápidamente un prototipo

que les permita especificar completamente el sistema y obtener más

consistentemente el producto final.

Ventajas:

Permite la construcción del sistema con requisitos poco claros o cambiantes.

El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede

evaluar, probar e, incluso, empezar a utilizarlo.

Se pueden introducir cambios en las funcionalidades del sistema en cualquier

momento.

Involucra al usuario en la evaluación de la interfaz de usuario.

Se reduce el riesgo y la incertidumbre sobre el desarrollo.

Permite entender bien el problema antes de la implementación final.

Desventajas:

El cliente puede quedar convencido con las primeras versiones y, quizás, no

vea la necesidad de completar el sistema o rediseñarlo con la calidad

necesaria.

Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo

en nuevos requisitos.

Requiere un tiempo adicional para definir adecuadamente el sistema.

No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos

prototipos se tienen que desarrollar.

Si un prototipo fracasa, el coste del proyecto puede resultar muy caro.


17


3.4. Modelo en V

El modelo en V es una variación del modelo en cascada que muestra cómo se

relacionan las actividades de prueba con el análisis y el diseño, la codificación forma

el vértice de la V, con la definición de requerimientos y el diseño a la izquierda y las

pruebas a la derecha.

La unión mediante líneas discontinuas entre las fases de la parte izquierda y las

pruebas de la derecha representa una doble información. Por un lado sirve para

indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por

otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos

en las pruebas correspondientes.

Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones

de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo

en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se

centra en las actividades y la corrección.

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.


18


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.

3.5. Modelo R.A.D. (Rapid Application Development)

El Desarrollo Rápido de Aplicaciones, abreviado como RAD (del inglés Rapid

Application Development) es un modelo de ciclo de vida que enfatiza un desarrollo

extremadamente corto. Se trata de una adaptación del modelo tradicional en cascada

en el que se logra el desarrollo rápido utilizando una construcción basada en

componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto,

el proceso RAD permite crear un sistema completamente funcional dentro de

periodos cortos de tiempo (entre 60 y 90 días).

Cuando se utiliza para aplicaciones de sistemas de información, el enfoque RAD tiene

las siguientes fases:

1) Modelado de Gestión:se modela el flujo de información entre las funciones de

gestión.

2) Modelado de Datos: se refina el flujo de información como un conjunto de

objetos de datos necesarios para apoyar la empresa. Se definen las características de

cada uno de los objetos y sus relaciones.

3) Modelado del Proceso: se definen las transformaciones (añadir, modificar,

suprimir o recuperar) sobre los objetos del modelo de datos para lograr los flujos de

información de cada función de gestión.

4) Generación de Aplicaciones: codificación de una función de gestión.

5) Pruebas y entrega: prueba de los componentes y entrega del programa que

realiza una función de gestión.


19


Las limitaciones de tiempo impuestas en un proyecto RAD exigen que la aplicación

cumpla con el requisito de “ámbito en escalas”, que indique que una aplicación pueda

modularse de forma que cada una de las funciones principales pueda completarse en

menos de tres meses. Además, cada una de las funciones puede ser afrontada por un

equipo RAD separado e integrarse en un único conjunto.

Ventajas:

Enfatiza ciclos de desarrollo extremadamente cortos.

Tiene las ventajas del modelo clásico.

Se asegura de que el producto entregado cumple las necesidades del cliente.

Desventajas:

Solo se puede aplicar si el sistema se puede modularizar de forma que permita

completarse cada una de las funciones principales en menos de tres meses.

Para proyectos grandes puede requerir muchos equipos de trabajo distintos.

Requiere clientes y desarrolladores comprometidos en las rápidas actividades

necesarias.

No resulta adecuado cuando los riesgos técnicos son elevados.

Se pueden tener problemas con la aceptación del prototipo.


20


3.6. Ciclo de Vida Orientado a objetos

Esta técnica fue presentada en la década del 90, tal vez como una de las mejores

metodologías a seguir para la creación de productos software.

Puede considerarse como un modelo pleno a seguir, como así también una

alternativa dentro de los modelos anteriores.

En esta metodología cada funcionalidad, o requerimiento solicitado por el usuario, es

considerado un objeto. Los objetos están representados por un conjunto de

propiedades, a los cuales denominamos atributos, por otra parte, al comportamiento

que tendrán estos objetos los denominamos métodos.

Vemos que tanto la filosofía de esta metodología, los términos utilizados en ella y sus

fines, coinciden con la idea de obtener un concepto de objeto sobre casos de la vida

real.

La característica principal de este modelo es la abstracción de los requerimientos de

usuario, por lo que este modelo es mucho más flexible que los restantes, que son

rígidos en requerimientos y definición, soportando mejor la incertidumbre que los

anteriores, aunque sin garantizar la ausencia de riesgos. La abstracción es lo que nos

permite analizar y desarrollar las características esenciales de un objeto

(requerimiento), despreocupándonos de las menos relevantes.


21


Favorece la reducción de la complejidad del problema que deseamos abordar y

permite el perfeccionamiento del producto.

En este modelo se utilizan las llamadas fichas CRC (clase–responsabilidades–

colaboración) como herramienta para obtener las abstracciones y mecanismos clave

de un sistema analizando los requerimientos del usuario. En la ficha CRC se escribe el

nombre de la clase u objeto, sus responsabilidades (los métodos) y sus colaboradores

(otras clases u objetos de los cuales necesita). Estas fichas, además, nos ayudan a

confeccionar los denominados casos de uso.

Metodologías para el Desarrollo de Software

Un proceso de software

detallado y completo suele

denominarse “Metodología”. Las

metodologías se basan en una

combinación de los modelos de

proceso genéricos (cascada,

evolutivo, incremental, espiral

entre otros). Adicionalmente una

metodología debería definir con

precisión los artefactos, roles y

actividades involucrados, junto

con prácticas y técnicas recomendadas, guías de adaptación de la metodología al

proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el

término “método” para referirse a técnicas, notaciones y guías asociadas, que son

aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele

hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y

alcance de cada una de ellas.


22


1. ¿METODOLOGIAS Y CICLO DE VIDA DEL SOFTWARE?

Una metodología puede seguir uno o

varios modelos de ciclo de vida, es decir,

el ciclo de vida indica qué es lo que hay

que obtener a lo largo del desarrollo del

proyecto pero no cómo hacerlo.

La metodología indica cómo hay que

obtener los distintos productos parciales

y finales

Según esto, el Ciclo de Vida únicamente

identifica las fases y actividades que

habrán de realizarse y el orden que

tendrán, mientras que la Metodología contempla cómo realizar dichas actividades y con

qué técnicas.

Cuando se inicia un proyecto, según los principios generales de la Ingeniería del Software,

se debe seleccionar el Modelo de Ciclo de Vida a seguir. Este Modelo se debe elegir en

función de las características del proyecto, ya que no hay un modelo aplicable en todos

los proyectos.

Podemos entender la confusión que se produce entre ambos términos, en ocasiones

debido a que hay metodologías que proponen un ciclo de vida, caso de RUP. En cualquier

caso, debemos pensar que son dos conceptos íntimamente relacionados pero distintos.

2. METODOLOGIAS EXISTENTES

2.1. Metodologías Tradicionales

Las metodologías no ágiles son aquellas que están guiadas por una fuerte

planificación durante todo el proceso de desarrollo; llamadas también metodologías

tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes

de la construcción del sistema.


23


Entre las metodologías tradicionales o pesadas podemos citar:

RUP (Rational Unified Procces)

MSF (Microsoft Solution

Framework)

Iconix

Detallaremos algunas de estas metodologías

2.1.1 RUP (Rational Unified Procces)

Es un proceso de desarrollo de software y junto

con el Lenguaje Unificado de Modelado UML,

constituye la metodología estándar más

utilizada para el análisis, implementación y

documentación de sistemas orientados a

objetos.

El proceso unificado conocido como RUP, es una

metodología de software que permite el

desarrollo de software a gran escala, mediante

un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento

de ciertos estándares de calidad. Aunque con el inconveniente de generar mayor

complejidad en los controles de administración del mismo. Sin embargo, los

beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.

RUP es un proceso para el desarrollo de un proyecto de un software que define

claramente quien, cómo, cuándo y qué debe hacerse en el proyecto.


24


Características:

La mayoría de los equipos de proyecto dentro de las empresas aún utilizan el modelo

en cascada para desarrollar los proyectos, completando cada fase en una estricta

secuencia; por el contrario RUP usa un enfoque iterativo (mini-proyectos) que es una

secuencia de pasos incrementales (versiones).

Las características esenciales de la metodología RUP son tres:

Dirigida por Casos de Uso: Los casos de uso describen cómo los usuarios

interactúan con el sistema a desarrollar. Donde un usuario, puede ser una

persona u otro sistema que utilice las funcionalidades del sistema a desarrollar.

Un caso de uso representa una funcionalidad puntual del sistema. Por ejemplo,

una funcionalidad puntual, en un sistema para cajeros automáticos, es la de

“retiro”.

Iterativos e Incrementales: RUP se basa en la evolución de prototipos

ejecutables o versiones del producto final que se muestran a los usuarios e

inversionistas del proyecto. Cada paso por el ciclo de vida produce una versión

del producto que incrementalmente se va refinando en las iteraciones de las

diferentes fases. Si llegado el final del ciclo de vida de RUP, el producto no

cumple con los objetivos planteados, se puede realizar un ciclo más para

refinar, corregir y agregar funcionalidades que lleven al software a cumplir con

las expectativas o cancelar el proyecto en base a los resultados obtenidos. Lo

que indica que con un enfoque iterativo e incremental, se tiene un mejor

manejo de los riesgos y un refinamiento más efectivo del producto final.

Centrado en la Arquitectura: En RUP el proceso se basa en diseñar

tempranamente una arquitectura base ejecutable. La arquitectura de un

sistema, es la organización o estructura de sus partes (componentes) más

relevantes dejando de lado los detalles, incluye los aspectos estáticos y

dinámicos del sistema.

Elementos Básicos de RUP:

Con RUP, un proceso de desarrollo es representado usando un conjunto de

elementos de modelado, tales como: roles (el quien), actividades (el que), artefactos

(el cómo) y flujos de trabajo (el cuándo).


25


Roles: Un rol es una definición abstracta del conjunto de responsabilidades, para las

actividades a ser desempeñadas y artefactos a ser producidos dentro del proyecto

por un individuo o grupo.

Actividades: Una actividad es una unidad de trabajo que se asigna a un rol, la cual

se requiere sea ejecutada por el individuo asociado a ese rol. Cada actividad es

asignada a un rol específico.


26


Artefactos: Un artefacto es una pieza de información que es producida o utilizada

por procesos. Los artefactos son los elementos tangibles de un proyecto, elementos

que el proyecto produce o usa mientras se trabaja en busca del producto final.

Disciplina: Una disciplina es una colección de actividades relacionadas a un área de

interés principal, dentro de todo el proyecto; por ejemplo, la administración de los

requerimientos.

Flujos de Trabajo (Workflows): Un flujo de trabajo es una secuencia de actividades

que producen un resultado de valor observable. Una de las grandes dificultades de

describir un proceso de software, es que hay muchas formas de organizar el conjunto

de actividades dentro de un flujo de trabajo. No siempre es posible representar flujos

de trabajo. En RUP se utilizan flujos de trabajo detallados y disciplinas para organizar

el proceso de software.


27


Fases del Ciclo de Vida de RUP:

Estructura del ciclo de vida del proceso de desarrollo unificado

Fase de concepción

Esta fase tiene como propósito definir y acordar el alcance del proyecto con los

patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer

una visión muy general de la arquitectura de software y producir el plan de las fases

y el de iteraciones.

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 requerimientos pendientes, administrar los cambios de acuerdo a las

evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.


28


Fase de transición

El propósito de esta fase es asegurar que el software esté disponible para los usuarios

finales, ajustar los errores y defectos encontrados en las pruebas de aceptación,

capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que

el producto cumpla con las especificaciones entregadas por las personas involucradas

en el proyecto.

2.1.2ICONIX

Es una metodología de desarrollo de software, basada en la complejidad de análisis

de la metodología RUP (Rational Unified Processes) y la practicidad para desarrollar

de la metodología XP (Extreme Programming).

Iconix deriva directamente del RUP y su fundamento es el hecho de que un 80% de

los casos pueden ser resueltos tan solo con un uso del 20% del UML, con lo cual se

simplifica muchísimo el proceso sin perder documentación al dejar solo aquello que

es necesario. Esto implica un uso dinámico del UML de tal forma que siempre se

pueden utilizar otros diagramas además de los ya estipulados si se cree conveniente.

Iconix se guía a través de casos de uso y sigue un ciclo de vida iterativo e incremental.

El objetivo es que a partir de los casos de uso se obtenga el sistema final.

Características

Iterativo e Incremental: Ocurren varias iteraciones entre el desarrollo del

modelo del dominio y los casos de uso. El modelo estático es incremental

Trazabilidad: es la capacidad de seguir una relación entre los diferentes

artefactos producidos, por lo que cada paso esta referenciado por algún

requisito.

Dinámica del UML: ofrece un uso dinámico del UML, como los diagramas de

caso de uso, diagramas de secuencia y de colaboración.


29


Fases:

1) Revisión de los requisitos/ Análisis de Requisitos: Se deben analizar todos

los requisitos que formaran parte del sistema y con estos construir el diagrama

de clases, que representa las agrupaciones funcionales que estructuraran el

sistema en desarrollo.

2) Revisión del diseño preliminar /Análisis y Diseño Preliminar: En esta fase

a partir de cada caso de uso se obtendrán una ficha de caso de uso, (la cual no

pertenece a UML), está formada por un nombre, una descripción, una

precondición que debe cumplir antes de iniciarse, una postcondicion que debe

cumplir al terminar si termina correctamente.

3) Revisión crítica del diseño/Diseño: En esta fase se reconocen todos los

elementos que forman parte de nuestro sistema.

4) Implementación: En esta fase a partir del buen diseño logrado se creara el

software; que posteriormente se entregara.


30


2.2. Metodologías Ágiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas

pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores

trabajan juntos constantemente con una cercana comunicación), sencillo (el método

en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable

(permite realizar cambios de último momento).

Entre las metodologías ágiles identificadas tenemos:

Extreme Programming

Scrum

Familia de Metodologías Crystal

Detallaremos las metodologías más conocidas.

2.2.1 Extreme Programming XP

Es una metodología ágil centrada en potenciar las

relaciones interpersonales como clave para el éxito en

desarrollo de software, promoviendo el trabajo en

equipo, preocupándose por el aprendizaje de los

desarrolladores, y propiciando un buen clima de trabajo.

XP se basa en realimentación continua entre el cliente y

el equipo de desarrollo, comunicación fluida entre todos

los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar

los cambios. XP se define como especialmente adecuada para proyectos con

requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

VALORES XP

Simplicidad: XP propone el principio de hacer la cosa más simple que pueda

funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo

simple, que hacerlo complicado y probablemente nunca usarlo mañana.


31


Comunicación: Algunos problemas en los proyectos tienen origen en que

alguien no dijo algo importante en algún momento. XP hace casi imposible la

falta de comunicación.

Realimentación: Retroalimentación concreta y frecuente del cliente, del

equipo y de los usuarios finales da una mayor oportunidad de dirigir el

esfuerzo eficientemente.

Coraje: El coraje (valor) existe en el contexto de los otros 3 valores.(si

funciona…mejóralo)

Principios

La Programación Extrema se basa en 12 principios básicos agrupados en cuatro

categorías:

I. Retroalimentación a escala fina

1. El principio de pruebas: se tiene que establecer un período de pruebas de

aceptación del programa (llamado también período de caja negra) donde se

definirán las entradas al sistema y los resultados esperados de estas entradas.

2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus

necesidades, definiendo las actividades que realizará el sistema. Se creará un

documento llamado Historias del usuario (UserStories).

3. El cliente en el sitio: se le dará poder para determinar los requerimientos,

definir la funcionalidad, señalar las prioridades y responder las preguntas de los

programadores. Esta fuerte interacción cara a cara con el programador disminuye

el tiempo de comunicación y la cantidad de documentación, junto con los altos

costes de su creación y mantenimiento.


32


4. Programación en parejas: uno de los principios más radicales y en el que la

mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los

programadores XP escriban su código en parejas, compartiendo una sola

máquina.

II. Proceso continuo en lugar de por lotes

1. Integración continua: permite al equipo hacer un rápido progreso

implementando las nuevas características del software. En lugar de crear builds (o

versiones) estables de acuerdo a un cronograma establecido, los equipos de

programadores XP pueden reunir su código y reconstruir el sistema varias veces

al día.

2. Refactorización: permite a los equipos de programadores XP mejorar el

diseño del sistema a través de todo el proceso de desarrollo. Los programadores

evalúan continuamente el diseño y recodifican lo necesario.

3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente

que se actualiza de forma rápida y constante permitiendo que el verdadero valor

de negocio del producto sea evaluado en un ambiente real. Estas entregas no

pueden pasar las 2 o 3 semanas como máximo.

III. Entendimiento compartido

1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es

entregado por el programa más sencillo que cumpla los requerimientos. Simple

Design se enfoca en proporcionar un sistema que cubra las necesidades

inmediatas del cliente, ni más ni menos.

2. Metáfora: La metáfora expresa la visión evolutiva del proyecto que define el

alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y

Colaboración) también ayudarán al equipo a definir actividades durante el diseño

del sistema. Cada tarjeta representa una clase en la programación orientada a

objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones

con las otras clases (cómo se comunica con ellas).

3. Propiedad colectiva del código: un código con propiedad compartida. Nadie

es el propietario de nada, todos son el propietario de todo. Este método difiere

en mucho a los métodos tradicionales en los que un simple programador posee

un conjunto de código.


33


4. Estándar de codificación: define la propiedad del código compartido así

como las reglas para escribir y documentar el código y la comunicación entre

diferentes piezas de código desarrolladas por diferentes equipos.

IV. Bienestar del programador.

1. La semana de 40 horas: la programación extrema sostiene que los

programadores cansados escriben código de menor calidad. Minimizar las horas

extras y mantener los programadores frescos, generará código de mayor calidad.

2.2.2 SCRUM

Scrum es una metodología de desarrollo muy

simple, que requiere trabajo duro porque no se basa

en el seguimiento de un plan, sino en la adaptación

continua a las circunstancias de la evolución del

proyecto. En Scrum se realizan entregas parciales y

regulares del producto final, priorizadas por el

beneficio que aportan al receptor del proyecto.

¿Cómo Funciona?

Se comienza con la visión general del producto, especificando y dando detalle a las

funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden

llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).

Cada uno de estos periodos de desarrollo es una iteración que finaliza con la

producción de un incremento operativo del producto.

Antes de iniciar cada iteración, el equipo revisa las tareas pendientes y selecciona la

parte que entregará como un incremento de funcionalidad al finalizar la iteración

(Sprint)

Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través

de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día

anterior y el previsto para el día siguiente.


34


Estructura Central de SCRUM

Roles

1. Los Cerdos: Son las personas que están comprometidas con el proyecto y el

proceso Scrum.

Product Owner: El responsable de

obtener el mayor valor de producto

para los clientes, usuarios y resto de

implicados.

ScrumMaster: Gestor de los equipos

que es responsable del

funcionamiento de la metodología

Scrum y de la productividad del

equipo de desarrollo y del

cumplimiento de las

responsabilidades de este.

Scrum Team: Grupo o grupos de

trabajo que desarrollan el producto. Deben transformarlas tareas del Sprint

Backlog en un incremento de funcionalidad del software.

2. Las Gallinas: Aunque no son parte del proceso Scrum, ya que son solo

involucrados en el proyecto, es necesario que estos participen de la

retroalimentación de la salida del proceso y así poder revisar y planear cada sprint.

Usuarios: Es el destinatario final del producto


35


Stakeholders: Las personas a las que el proyecto les producirá un beneficio.

Participan durante la revisión del Sprint.

Managers: Toma las decisiones finales participando en la selección de los

objetivos y los requisitos.

Artefactos

SCRUM define una pequeña cantidad de Artefactos para el seguimiento del proyecto

y control de las actividades asociadas al sprint.

Product Backlog: Este documento representa lo que el cliente espera del

proyecto en cuanto a objetivos y requisitos, así como entregas. Por tanto, el

propio cliente se encarga de crear y gestionar esta lista, con la ayuda de un

facilitador y el equipo, quien se encarga de establecer un presupuesto para

completar cada requisito.

Sprint Backlog: En este caso se refleja la totalidad de tareas para la iteración

o Sprint en curso, con el fin de cumplir los objetivos o requisitos para esa

entrega o incremento, y entregar algo funcional al cliente acorde con lo

esperado.

BurnDown Charts: Se trata de gráficos, que reflejan la velocidad con la que

avanza nuestro proyecto. Es decir, en el podemos ver que nos queda por hacer

y que tenemos pendiente, ofreciéndonos una vista general de la rapidez con

la que el proyecto en general o el Sprint en curso en particular está avanzando.

El soporte en el que se presenta el Sprint Backlog puede ser: Hoja de cálculo, pizarra,

herramientas colaborativas de red.

http://www.monografias.com/trabajos13/clapre/clapre.shtml


36


Flujo SCRUM

Flujo Scrum que se desarrolla a lo largo de todo el proyecto


37


3. DIFERENCIAS: TRADICIONAL VS AGIL

Metodologías Tradicionales Metodologías Agiles

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo.

Basadas en heurísticas provenientes de

prácticas de producción de código.

Cierta resistencia a los cambios. Especialmente preparados para cambios

durante el proyecto.

Proceso mucho más controlado, con

numerosas políticas/normas.

Proceso menos controlado, con pocos

principios.

El cliente interactúa con el equipo de

desarrollo mediante reuniones.

El cliente es parte del equipo de desarrollo.

Más artefactos. Pocos artefactos.

Más roles. Pocos roles.

Grupos grandes y posiblemente

distribuidos.

Grupos pequeños (<10 integrantes) y

trabajando en el mismo sitio.


38


Conclusiones

Toda empresa dedicada al desarrollo de software en miras de aprovechar las

oportunidades que se le presentan, deben definir desde un principio un plan de gestión

que permita el éxito de producto o servicio a ofrecer, con la adecuada selección de la

metodología a seguir de acuerdo a la naturaleza del proyecto que realizará. Es por ello

que se desea diseñar una herramienta que permita facilitar y ayudar a la dirección de

proyectos, en la selección de metodologías de desarrollo de software.

El ciclo de vida que se seleccione en un proyecto influirá en el éxito del proyecto, y puede

ayudar a asegurar que cada paso que se dé acorte más la consecución del objetivo.

Dependiendo del ciclo de vida que se seleccione, se puede aumentar la velocidad de

desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar gastos

y riesgos, o mejorar las relaciones con los clientes. Una selección ineficaz puede ser una

fuente constante de ralentización del trabajo, trabajo repetitivo, innecesario y frustrante.


39


Recomendaciones

Luego de ver algunos de los modelos de ciclo de vida más utilizados surge la pregunta

con la respuesta más codiciada: ¿qué modelo de ciclo de vida elegir? Sabemos que

ninguno predomina sobre los otros. Por ello, debemos elegir el modelo que mejor se

adapte al proyecto que desarrollaremos. Podemos analizar, para guiarnos en nuestra

elección, la complejidad del problema, el tiempo que disponemos para hacer la entrega

final, o si el usuario o cliente desea entregas parciales, la comunicación que existe entre

el equipo de desarrollo y el usuario y, por último, qué certeza (o incertidumbre) tenemos

de que los requerimientos dados por el usuario son correctos y completos

Tal y como se ha visto en el trabajo de investigación cualquier modelo tiene ventajas e

inconvenientes, con lo que, al comenzar un proyecto, habrá que examinar la situación

actual para comprobar cuál es el modelo más adecuado al caso.


40


Glosario

Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte

documental que ayuda a los desarrolladores a realizar nuevo software.

Tarea: Actividades elementales en que se dividen los procesos.

Procedimiento: Definición de la forma de ejecutar la tarea.

Técnica: Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o

varias.

Herramienta: Para realizar una técnica, podemos apoyarnos en las herramientas

software que automatizan su aplicación.

Artefacto: Está mayormente asociado a métodos o procesos de desarrollo específicos.

Un artefacto es un producto tangible resultante del proceso de desarrollo de software.

Producto: Resultado de cada etapa.

Prototipo: representación limitada de un producto, permite a las partes probarlo en

situaciones reales o explorar su uso, creando así un proceso de diseño de iteración que

genera calidad.

Iterativo e Incremental: Un desarrollo iterativo e incremental es cuando proyecto se

planifica en diversos bloques temporales llamados iteraciones. Las iteraciones se pueden

entender como mini proyectos: en todas las iteraciones se repite un proceso de trabajo

similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre

producto final.

http://albertolacalle.com/diseno-iteracion.htm


41


Bibliografía

http://spanishpmo.com/index.php/ciclos-de-vida-historia-y-antecedentes/

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.h

tm

http://spanishpmo.com/index.php/ciclos-de-vida-modelo-en-v/

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf

http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf

http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis2603-

modelosciclosdevida.pdf

http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-2010-

11%5DTema2.CicloVidaSW.pdf

http://ciclodevidasoftware.wikispaces.com/ETAPAS+DEL+CICLO+DE+VIDA

http://ciclovidasoftware.blogspot.com/


http://spanishpmo.com/index.php/ciclos-de-vida-conclusiones/

http://ingsoftware072301.obolog.com/rational-unified-process-rup-proceso-racional-unificado-2006524

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm

http://iisoftware.blogspot.com/2013/02/metodologia-iconix.html

http://angellozano.wordpress.com/2009/01/03/%C2%BFque-es-la-metologia-y-que-es-el-ciclo-de-vida/

http://www.proyectosagiles.org/que-es-scrum

http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

http://spanishpmo.com/index.php/ciclos-de-vida-historia-y-antecedentes/

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm

http://spanishpmo.com/index.php/ciclos-de-vida-modelo-en-v/


http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf

http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis2603-modelosciclosdevida.pdf

http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis2603-modelosciclosdevida.pdf

http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-2010-11%5DTema2.CicloVidaSW.pdf

http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-2010-11%5DTema2.CicloVidaSW.pdf

http://ciclodevidasoftware.wikispaces.com/ETAPAS+DEL+CICLO+DE+VIDA

http://ciclovidasoftware.blogspot.com/


http://spanishpmo.com/index.php/ciclos-de-vida-conclusiones/

http://ingsoftware072301.obolog.com/rational-unified-process-rup-proceso-racional-unificado-2006524

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm

http://iisoftware.blogspot.com/2013/02/metodologia-iconix.html

http://angellozano.wordpress.com/2009/01/03/%C2%BFque-es-la-metologia-y-que-es-el-ciclo-de-vida/

http://www.proyectosagiles.org/que-es-scrum

http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

Ciclo de vida y Metodologías de Desarrollo de Software(o).pdf

Documents

Transcript of Ciclo de vida y Metodologías de Desarrollo de Software(o).pdf