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
Ciclo de vida y Metodologías de Desarrollo de Software
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
Ciclo de vida y Metodologías de Desarrollo de Software
3
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
4
Facultad de Ingeniería de Sistemas - UNICA
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
Ciclo de vida y Metodologías de Desarrollo de Software
5
Facultad de Ingeniería de Sistemas - UNICA
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
Ciclo de vida y Metodologías de Desarrollo de Software
6
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
7
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
8
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
9
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
10
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
11
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
12
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
13
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
14
Facultad de Ingeniería de Sistemas - UNICA
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
Ciclo de vida y Metodologías de Desarrollo de Software
15
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
16
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
17
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
18
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
19
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
20
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
21
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
22
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
23
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
24
Facultad de Ingeniería de Sistemas - UNICA
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).
Ciclo de vida y Metodologías de Desarrollo de Software
25
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
26
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
27
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
28
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
29
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
30
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
31
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
32
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
33
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
34
Facultad de Ingeniería de Sistemas - UNICA
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
Ciclo de vida y Metodologías de Desarrollo de Software
35
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
36
Facultad de Ingeniería de Sistemas - UNICA
Flujo SCRUM
Flujo Scrum que se desarrolla a lo largo de todo el proyecto
Ciclo de vida y Metodologías de Desarrollo de Software
37
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
38
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
39
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
40
Facultad de Ingeniería de Sistemas - UNICA
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.
Ciclo de vida y Metodologías de Desarrollo de Software
41
Facultad de Ingeniería de Sistemas - UNICA
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://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf
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
Top Related