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

Ciclo de vida y Metodologías de Desarrollo de Software

2

Dedicatoria 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 nuestros profesores, profesores, quienes quienes nos nos brindan brindan sus sus conocimientos y nos guían a lo largo de nuestro camino universitario para poder ser profesionales valiosos para para la sociedad.

Facultad de Ingeniería de Sistemas - UNICA


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

Ciclo de Vida y Metodologías de Desarrollo de Software

Contenido Dedicatoria……………………………………………… Dedicatoria……………………………………………………………………………………………… …………………………………………………………………………………………2 …………………………………………2 Objetivos…………………………………………………… Objetivos…………………………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………….3 Contenido…………………………………………………………………… Contenido………………… ……………………………………………………………………………………………… …………………………………………………………………… ………………………..4 Introducción………………………………………………………… Introducción…………… …………………………………………………………………………………………… ………………………………………………………………………… …………………………....6 Ciclo de Vida del Software………………………………………………………………………………………………………………....7 Software………………………………………………………………………………………………………………....7

1. Historia y Antecedentes………………………………………………………………………………………………………………7 2. El Antiguo Enfoque…………………………………………………………………………………………………………………... Enfoque………………………………………………………………………………………………………………….....8 ..8 3. ¿Qué es el Ciclo de Vida del Software?................... Software?............................... ...................... ...................... ...................... ..................... ...................... .................9 ......9 4. Actividades del Ciclo de Vida del Software………………………………………………………………………………….9 Modelos de Ciclo de Vida del Software…………………………………………………………………………………………….10 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 Software………………………………………………………………………………….21



5

1. ¿Metodologías y Ciclo de Vida del Software?..................... Software?............................... ..................... ...................... ....................... ...................... ..............22 ....22 2. Metodologías Existentes…………………………………………………………………………………………………………..22 2.1 Metodologías Tradicionales…………………………………………..………………………………………..…………22 Tradicionales…………………………………………..………………………………………..…………22

RUP (Rational Unified Procces)…………………………….……………………………………..………..23 Procces)…………………………….……………………………………..………..23 2.1.2 ICONIX…………………………………………………………………..………………………………………………28 2.2 Metodologías Agiles………………….…………………………………….……………………………………..… A giles………………….…………………………………….……………………………………..………….30 ……….30 2.2.1 Extreme Programming XP…………………………….………….………………..………………………….30 2.2.2 SCRUM………………………………………………………………………………..…………………………………33 3. Diferencias: Tradicional vs Ágil………………………………………………………….…………………….…….….……..37 2.1.1

Conclusiones………………………………… Conclusiones………………………………………………………………………………… ……………………………………………………………………………………….… ……………………………………….………..38 ……..38 Recomendaciones…………………………………… Recomendaciones……………………………………………………………………………………… ………………………………………………………………………………….……3 ……………………………….……39 9 Glosario..………………………………………………………… Glosario..……………………………………………………………………………………………………… ……………………………………………………………………….………40 ………………………….………40 Bibliografía…………………………………………… Bibliografía………………………………………………………………………………………… ………………………………………………………………………….….…..……… …………………………….….…..………41 41



6

Introducción

El presente trabajo de investigación tiene como com o 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, cliente s, 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 ANTECEDEN ANTECEDENTES TES 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 e l 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 CICLO DE VIDA DEL SOFTWARE 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. bu gs.

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 desarrollo

de de

las un

distintas proyecto

formas o

de

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 software como es el “análisis de riesgos” y define cuatro actividades principales representadas por los cuatro cuadrantes de la figura:

1) 2) 3) 4)

Planificación: Determina objetivos, alternativas y restricciones Análisis de riesgo: Evalúa alternativas, identifica y resuelve riesgos. Ingeniería: Desarrollo y verificación del producto del siguiente nivel. 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.


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 qu e 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, 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. 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 qui ere 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 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.


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 requerimien to 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– (clase–responsabilidades– 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

detallado

y

de

software

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 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 funcionalidade s del sistema a desarrollar. Un caso de uso representa una funcionalidad puntual del sistema. Por ejempl o, 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 cumpli r 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 cómo) y flujos de trabajo (el cuándo). 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. trabaj o. 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 especifica ciones 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. i ncremental. El objetivo es que a partir de los casos de uso se obtenga el sistema final.

Características  



Iterativo e Incremental: 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 Trazabilidad: artefactos producidos, por lo que cada paso esta referenciado por algún requisito. Dinámica del UML: ofrece 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, inicia rse, 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 cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el 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 Simplicidad: XP 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 Comunicación: 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 Coraje: 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) 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). 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 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 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 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 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

con el proyecto y el

proceso Scrum. 





Product Owner: 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 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 Usuarios: Es el destinatario final del producto





35

Stakeholders: Las 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 Managers: 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: Backlog: Este documento representa lo que el cliente espera del proyecto proyecto en cuanto a objetivos y requisitos, 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 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: Charts: Se trata de gráficos, que reflejan la velocidad con la que avanza nuestro proyecto. Es decir, en el podemos pode mos 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 Spri nt en curso en particular está avanzando.

El soporte en el que se presenta el Sprint Backlog puede pu ede ser: Hoja de cálculo, pizarra, herramientas colaborativas de red.



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 Basadas en heurísticas provenientes de estándares seguidos por el entorno de prácticas de producción de código. desarrollo. Cierta resistencia a los cambios. Especialmente preparados para cambios durante el proyecto. Proceso mucho más controlado, con Proceso menos controlado, con pocos numerosas políticas/normas. principios. El cliente interactúa con el equipo de El cliente es parte del equipo de desarrollo. desarrollo mediante reuniones. Más artefactos. Pocos artefactos. Más roles. Pocos roles. Grupos grandes y posiblemente Grupos pequeños (<10 integrantes) y distribuidos. 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 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 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. Tarea: Actividades Procedimiento: Definición de la forma de ejecutar la tarea. Procedimiento: Definición Técnica: Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o Técnica: Herramienta varias. Herramienta: Para realizar una técnica, podemos apoyarnos apoyarnos software que automatizan su aplicación.

en las herramientas

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. Producto: Resultado Prototipo: representación limitada de un producto, permite a las partes probarlo en Prototipo: situaciones reales o explorar su uso, creando así un proceso un proceso de diseño de iteración que genera calidad. Iterativo e Incremental: 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.



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:isis2603modelosciclosdevida.pdf http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-201011%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


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

Recommend Documents