Ciclo de Vida y Metodologías de Desarrollo de Software (O) PDF

Universidad Nacional San Luis Gonzaga de Ica
Facultad de Ingeniera de Sistemas
Ciclo de vida y Metodologas de Desarrollo de Software Ing. Antonio Alonzo Morales Loayza
Elaborada por: Acuache Yalle, Kenny Anchante Muoz, Alexander Caballero Quispe, Edison Conislla Yallico, Martin Hernndez Hernndez, Juan Quinteros Tumba, Eduardo
Ciclo de vida y Metodologas de Desarrollo de Software
Dedicatoria
El presente trabajo de investigacin monogrfica se lo dedicamos a nuestros padres; quienes siempre han estado en todo momento apoyndonos para poder estar en donde ahora estamos. A Dios, ya que gracias a l tenemos esos padres maravillosos que nos guan da a da para ser cada vez mejores personas. A nuestros profesores, quienes nos brindan sus conocimientos y nos guan a lo largo de nuestro camino universitario para poder ser profesionales valiosos para la sociedad.
Facultad de Ingeniera 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 metodologas existentes para el desarrollo de software. Entender la diferencia entre ciclo de vida y metodologas de desarrollo. Comprender las herramientas que se utilizan en las metodologas para el desarrollo. Evaluar las diferencias existentes entre las distintas metodologas.
Ciclo de Vida y Metodologas de Desarrollo de Software
Contenido
Dedicatoria2 Objetivos.3 Contenido..4 Introduccin....6 Ciclo de Vida del Software....7 1. 2. 3. 4. Historia y Antecedentes7 El Antiguo Enfoque.....8 Qu es el Ciclo de Vida del Software?...........................................................................................9 Actividades del Ciclo de Vida del Software.9
Modelos de Ciclo de Vida del Software.10 1. Modelos de Ciclo de Vida de Software10 2. Diferencias entre Modelos..11 3. Modelos Destacados11 3.1 Modelo Clsico o Cascada..11 3.2 Modelo Espiral13 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 Objetos20
Metodologas para el Desarrollo de Software.21
Ciclo de vida y Metodologas de Desarrollo de Software 1. Metodologas y Ciclo de Vida del Software?...............................................................................22 2. Metodologas Existentes..22 2.1 Metodologas Tradicionales....22 2.1.1 RUP (Rational Unified Procces).....23 2.1.2 ICONIX..28 2.2 Metodologas 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 Bibliografa....41
Introduccin
El presente trabajo de investigacin tiene como objetivo dar a conocer y poner en prctica los conocimientos sobre Ciclos de Vida del Software y sus Metodologas de Desarrollo y la importante relacin que existe entre estos para el adecuado desarrollo de un proyecto de software. Al igual que en otros sistemas de ingeniera, 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 funcin de cuales sean las caractersticas del proyecto, se configurar el ciclo de vida de forma diferente. Sin embargo, las exigencias del mercado, la competencia empresarial, el convencimiento y la satisfaccin total de los clientes, son algunos de los puntos que muchas empresas de desarrollo an no alcanzan por no considerar un tema de gran auge como es la calidad. Para esto las Metodologas de Desarrollo de Software tienen como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas que nos indican los procedimientos de trabajo que nos permitan desarrollar software de calidad.
Ciclo de Vida del Software

1. HISTORIA Y ANTECEDENTES
Tradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de forma individualizada, a base de codificar y probar lo realizado cuanto antes. A lo largo de los aos fueron surgiendo los llamados Ciclos de Vida que son una descripcin de las distintas formas de desarrollo de una aplicacin informtica. Hace aos el desarrollo era as: la misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese existir documentacin alguna. Esta forma de desarrollar aplicaciones es muy comn 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 planificacin. Adems, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podr fcilmente familiarizarse con l. Esta forma de desarrollar software puede ser eficaz en programas pequeos. Para otro tipo de proyectos, puede resultar peligrosa su utilizacin, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se est codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, 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.
2. EL ANTIGUO ENFOQUE
Es probable que las aplicaciones realizadas segn 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 documentacin (lo que provocar problemas de mantenimiento). Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las funciones requeridas y, adems, lo hagan con una escasa fiabilidad. Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarn), aparecen errores una vez que la aplicacin ha sido entregada (lgico al no haberse realizado de forma sistemtica actividades de verificacin y validacin en el proyecto). Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve un enfoque lgico para su realizacin. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepcin y finalizando cuando ya no se utiliza o se retira.
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 solucin 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 propsito 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

Implcita o Explcitamente 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. Diseo: En la fase de diseo, el objetivo es conocer las relaciones entre los mdulos del programa, y garantizar que se cumplen cabalmente los requerimientos solicitados de una manera eficiente, lgica y completa.
10
Los diseadores de software consideran los recursos de hardware y software disponibles para poder alcanzar su objetivo. Implementacin: Es la etapa donde efectivamente se programa el sistema. Durante esta fase, el programa se escribe en un lenguaje de programacin. Los programas se escriben usualmente en mdulos separados, cada mdulo desarrolla alguna tarea especfica y debe funcionar independientemente y en relacin 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 tambin 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 aplicacin 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 descripcin desarrollo seguirse de de para las un distintas proyecto a o partir formas de aplicacin de los
informtica, es decir, la orientacin que debe obtener, requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.
11
2. DIFERENCIAS ENTRE MODELOS

Las principales diferencias entre distintos modelos de ciclo de vida estn divididas en tres grandes visiones: El alcance del ciclo de vida, que depende de hasta dnde deseamos llegar con el Proyecto: slo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo ms las actualizaciones y el mantenimiento. La calidad y cantidad de las etapas en que dividiremos el ciclo de vida: segn el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos. La estructura y la sucesin de las etapas, si hay realimentacin 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 Clsico o en cascada Modelo en espiral Desarrollo de prototipos Modelo en V. Modelo R.A.D. Modelo Orientado a Objetos
3.1. Modelo Clsico o Cascada

Es el modelo ms 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 cunto falta para su finalizacin.
12
Ventajas: Es un modelo sencillo y disciplinado. Es fcil 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 planificacin, pues se realiza sin problemas. Desventajas: Los proyectos raramente siguen el proceso lineal tal como se defina originalmente el ciclo de vida. Es difcil que el cliente exponga explcitamente 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 solucin en fases del modelo en cascada con ciclos de experimentacin y aprendizaje. El modelo incorpora un nuevo elemento en el desarrollo de software como es el anlisis de riesgos y define cuatro actividades principales representadas por los cuatro cuadrantes de la figura: 1) 2) 3) 4) Planificacin: Determina objetivos, alternativas y restricciones Anlisis de riesgo: Evala alternativas, identifica y resuelve riesgos. Ingeniera: Desarrollo y verificacin del producto del siguiente nivel. Evaluacin del cliente: Valoracin de los resultados y planificacin de la siguiente fase.
Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se van construyendo sucesivas versiones del software, cada vez ms completas.
14
Ventajas: Proporciona el potencial para el desarrollo rpido de versiones incrementales. Puede adaptarse y aplicarse a lo largo de la vida del software. Permite aplicar el enfoque de construccin de prototipos en cualquier momento para reducir riesgos. Reduce los riesgos antes de que se conviertan en problemticos. Monitoriza y controla los riesgos continuamente. Desventajas: Puede resultar difcil convencer a algunos clientes de que el enfoque evolutivo es controlable. Solo resulta aplicable para proyectos de gran tamao. Supone una carga de trabajo adicional, no presente en otros ciclos de vida Requiere una considerable habilidad para la evaluacin y resolucin 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 construccin de prototipos es un proceso que facilita al ingeniero de software el desarrollo de la aplicacin. El prototipo suele tomar una de las tres formas siguientes: Un modelo en papel o en computadora que describe la interaccin hombre-mquina, de forma que facilite al usuario la comprensin de su funcionamiento. Por ejemplo, si el sistema a construir es un cajero automtico, se puede hacer un programa que simule la interaccin 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 cmo va a funcionar el sistema final sin tener que construirlo, y as discutirlo con el ingeniero de software. Un modelo que implementa una funcin requerida importante. Es el mismo caso que anteriormente pero sin centrarse en la interaccin hombre-mquina. Por ejemplo, el modelo podra 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 aplicacin relacionada con un cajero automtico, 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 construccin suele llevar las siguientes etapas: 1) Recoleccin de requisitos. El ingeniero de software y el cliente definen los objetivos globales del software, y aqullos ms especficos que se desean destacar con el prototipo.
16
2) Diseo rpido: Centrado en los aspectos del software visible al usuario (por ejemplo, interfaz de usuario, entradas y salidas). 3) Construccin del prototipo. 4) Evaluacin 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 mayora 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 rpidamente un prototipo que les permita especificar completamente el sistema y obtener ms consistentemente el producto final. Ventajas:
Permite la construccin del sistema con requisitos poco claros o cambiantes. El cliente recibe una versin 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 evaluacin de la interfaz de usuario. Se reduce el riesgo y la incertidumbre sobre el desarrollo. Permite entender bien el problema antes de la implementacin final.
Desventajas: El cliente puede quedar convencido con las primeras versiones y, quizs, no vea la necesidad de completar el sistema o redisearlo 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 cunto 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 variacin del modelo en cascada que muestra cmo se relacionan las actividades de prueba con el anlisis y el diseo, la codificacin forma el vrtice de la V, con la definicin de requerimientos y el diseo a la izquierda y las pruebas a la derecha.
La unin mediante lneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble informacin. 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 ms explcita parte de las iteraciones y repeticiones de trabajo que estn ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sita en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la correccin. Ventajas: La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localizacin de fallos. Es un modelo sencillo y de fcil aprendizaje.
18
Hace explcito parte de la iteracin y trabajo que hay que revisar. Especifica bien los roles de los distintos tipos de pruebas a realizar. Involucra al usuario en las pruebas. Desventajas: Es difcil que el cliente exponga explcitamente todos los requisitos. El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida. Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas. El producto final obtenido puede que no refleje todos los requisitos del usuario.
3.5. Modelo R.A.D. (Rapid Application Development)

El Desarrollo Rpido de Aplicaciones, abreviado como RAD (del ingls Rapid Application Development) es un modelo de ciclo de vida que enfatiza un desarrollo extremadamente corto. Se trata de una adaptacin del modelo tradicional en cascada en el que se logra el desarrollo rpido utilizando una construccin 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 das). Cuando se utiliza para aplicaciones de sistemas de informacin, el enfoque RAD tiene las siguientes fases: 1) Modelado de Gestin:se modela el flujo de informacin entre las funciones de gestin. 2) Modelado de Datos: se refina el flujo de informacin como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas de cada uno de los objetos y sus relaciones. 3) Modelado del Proceso: se definen las transformaciones (aadir, modificar, suprimir o recuperar) sobre los objetos del modelo de datos para lograr los flujos de informacin de cada funcin de gestin. 4) Generacin de Aplicaciones: codificacin de una funcin de gestin. 5) Pruebas y entrega: prueba de los componentes y entrega del programa que realiza una funcin de gestin.
19
Las limitaciones de tiempo impuestas en un proyecto RAD exigen que la aplicacin cumpla con el requisito de mbito en escalas, que indique que una aplicacin pueda modularse de forma que cada una de las funciones principales pueda completarse en menos de tres meses. Adems, 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 clsico. 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 rpidas actividades necesarias. No resulta adecuado cuando los riesgos tcnicos son elevados. Se pueden tener problemas con la aceptacin del prototipo.
20
3.6. Ciclo de Vida Orientado a objetos

Esta tcnica fue presentada en la dcada del 90, tal vez como una de las mejores metodologas a seguir para la creacin de productos software. Puede considerarse como un modelo pleno a seguir, como as tambin una alternativa dentro de los modelos anteriores. En esta metodologa cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto. Los objetos estn representados por un conjunto de propiedades, a los cuales denominamos atributos, por otra parte, al comportamiento que tendrn estos objetos los denominamos mtodos. Vemos que tanto la filosofa de esta metodologa, los trminos utilizados en ella y sus fines, coinciden con la idea de obtener un concepto de objeto sobre casos de la vida real.
La caracterstica principal de este modelo es la abstraccin de los requerimientos de usuario, por lo que este modelo es mucho ms flexible que los restantes, que son rgidos en requerimientos y definicin, soportando mejor la incertidumbre que los anteriores, aunque sin garantizar la ausencia de riesgos. La abstraccin es lo que nos permite analizar y desarrollar las caractersticas esenciales de un objeto (requerimiento), despreocupndonos de las menos relevantes.
21
Favorece la reduccin de la complejidad del problema que deseamos abordar y permite el perfeccionamiento del producto. En este modelo se utilizan las llamadas fichas CRC (claseresponsabilidades colaboracin) 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 mtodos) y sus colaboradores (otras clases u objetos de los cuales necesita). Estas fichas, adems, nos ayudan a confeccionar los denominados casos de uso.
Metodologas para el Desarrollo de Software

Un proceso y de software suele
detallado
completo
denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas.
22
1. METODOLOGIAS Y CICLO DE VIDA DEL SOFTWARE?

Una metodologa 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 cmo hacerlo. La metodologa indica cmo hay que obtener los distintos productos parciales y finales Segn esto, el Ciclo de Vida nicamente identifica las fases y actividades que habrn de realizarse y el orden que tendrn, mientras que la Metodologa contempla cmo realizar dichas actividades y con qu tcnicas. Cuando se inicia un proyecto, segn los principios generales de la Ingeniera del Software, se debe seleccionar el Modelo de Ciclo de Vida a seguir. Este Modelo se debe elegir en funcin de las caractersticas del proyecto, ya que no hay un modelo aplicable en todos los proyectos. Podemos entender la confusin que se produce entre ambos trminos, en ocasiones debido a que hay metodologas 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. Metodologas Tradicionales

Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema.
23
Entre las metodologas tradicionales o pesadas podemos citar:
RUP (Rational Unified Procces) MSF (Microsoft Solution Framework) Iconix
Detallaremos algunas de estas metodologas
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 metodologa de sistemas estndar ms a utilizada para el anlisis, implementacin y documentacin objetos. El proceso unificado conocido como RUP, es una metodologa de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentacin, garantizando el cumplimiento de ciertos estndares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administracin 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, cmo, cundo y qu debe hacerse en el proyecto. orientados
24
Caractersticas: La mayora de los equipos de proyecto dentro de las empresas an 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 caractersticas esenciales de la metodologa RUP son tres: Dirigida por Casos de Uso: Los casos de uso describen cmo los usuarios interactan 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 automticos, es la de retiro. Iterativos e Incrementales: RUP se basa en la evolucin 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 versin 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 ms 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 ms efectivo del producto final. Centrado en la Arquitectura: En RUP el proceso se basa en disear tempranamente una arquitectura base ejecutable. La arquitectura de un sistema, es la organizacin o estructura de sus partes (componentes) ms relevantes dejando de lado los detalles, incluye los aspectos estticos y dinmicos del sistema. Elementos Bsicos 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 cmo) y flujos de trabajo (el cundo).
25
Roles: Un rol es una definicin abstracta del conjunto de responsabilidades, para las actividades a ser desempeadas 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 especfico.
26
Artefactos: Un artefacto es una pieza de informacin 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 coleccin de actividades relacionadas a un rea de inters principal, dentro de todo el proyecto; por ejemplo, la administracin de los requerimientos. Flujos de Trabajo (Workflows): Un flujo de trabajo es una secuencia de actividades que producen un resultado de valor observable. Una de las grandes dificultades de describir un proceso de software, es que hay muchas formas de organizar el conjunto de actividades dentro de un flujo de trabajo. No siempre es posible representar flujos de trabajo. En RUP se utilizan flujos de trabajo detallados y disciplinas para organizar el proceso de software.
27
Fases del Ciclo de Vida de RUP:

Estructura del ciclo de vida del proceso de desarrollo unificado
Fase de concepcin Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. Fase de elaboracin En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de construccin El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los 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 transicin El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.
2.1.2ICONIX
Es una metodologa de desarrollo de software, basada en la complejidad de anlisis de la metodologa RUP (Rational Unified Processes) y la practicidad para desarrollar de la metodologa 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 muchsimo el proceso sin perder documentacin al dejar solo aquello que es necesario. Esto implica un uso dinmico del UML de tal forma que siempre se pueden utilizar otros diagramas adems de los ya estipulados si se cree conveniente. Iconix se gua a travs 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.
Caractersticas
Iterativo e Incremental: Ocurren varias iteraciones entre el desarrollo del modelo del dominio y los casos de uso. El modelo esttico es incremental Trazabilidad: es la capacidad de seguir una relacin entre los diferentes artefactos producidos, por lo que cada paso esta referenciado por algn requisito. Dinmica del UML: ofrece un uso dinmico del UML, como los diagramas de caso de uso, diagramas de secuencia y de colaboracin.
29
Fases:
1) Revisin de los requisitos/ Anlisis 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) Revisin del diseo preliminar /Anlisis y Diseo Preliminar: En esta fase a partir de cada caso de uso se obtendrn una ficha de caso de uso, (la cual no pertenece a UML), est formada por un nombre, una descripcin, una precondicin que debe cumplir antes de iniciarse, una postcondicion que debe cumplir al terminar si termina correctamente. 3) Revisin crtica del diseo/Diseo: En esta fase se reconocen todos los elementos que forman parte de nuestro sistema. 4) Implementacin: En esta fase a partir del buen diseo logrado se creara el software; que posteriormente se entregara.
30
2.2. Metodologas giles

Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo momento). Entre las metodologas giles identificadas tenemos:

Extreme Programming Scrum Familia de Metodologas Crystal
Detallaremos las metodologas ms conocidas.
2.2.1 Extreme Programming XP

Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin 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 tcnico.
VALORES XP
Simplicidad: XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al proceso y la codificacin. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo maana.
31
Comunicacin: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algn momento. XP hace casi imposible la falta de comunicacin. Realimentacin: Retroalimentacin 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 funcionamejralo)
Principios
La Programacin Extrema se basa en 12 principios bsicos agrupados en cuatro categoras: I. Retroalimentacin a escala fina 1. El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. 2. Proceso de planificacin: 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, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento.
32
4. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. II. Proceso continuo en lugar de por lotes 1. Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. 2. Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. 3. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida 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 mximo. III. Entendimiento compartido 1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. 2. Metfora: La metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas). 3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo.
33
4. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. IV. Bienestar del programador. 1. La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor calidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad.
2.2.2 SCRUM
Scrum es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto.
Cmo Funciona?
Se comienza con la visin 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 das). Cada uno de estos periodos de desarrollo es una iteracin que finaliza con la produccin de un incremento operativo del producto. Antes de iniciar cada iteracin, el equipo revisa las tareas pendientes y selecciona la parte que entregar como un incremento de funcionalidad al finalizar la iteracin (Sprint) Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su evolucin a travs de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el da anterior y el previsto para el da siguiente.
34
Estructura Central de SCRUM
Roles
1. Los Cerdos: Son las personas que estn 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 metodologa 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 retroalimentacin de la salida del proceso y as poder revisar y planear cada sprint. Usuarios: Es el destinatario final del producto
35
Stakeholders: Las personas a las que el proyecto les producir un beneficio. Participan durante la revisin del Sprint. Managers: Toma las decisiones finales participando en la seleccin de los objetivos y los requisitos.
Artefactos
SCRUM define una pequea 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 iteracin 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 grficos, 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, ofrecindonos 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 clculo, 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

Metodologas Tradicionales Metodologas Agiles Basadas en normas provenientes de Basadas en heursticas provenientes de estndares seguidos por el entorno de prcticas de produccin de cdigo. desarrollo. Cierta resistencia a los cambios. Especialmente preparados para cambios durante el proyecto. Proceso mucho ms controlado, con Proceso menos controlado, con pocos numerosas polticas/normas. principios. El cliente interacta con el equipo de El cliente es parte del equipo de desarrollo. desarrollo mediante reuniones. Ms artefactos. Pocos artefactos. Ms roles. Pocos roles. Grupos grandes y posiblemente Grupos pequeos (<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 gestin que permita el xito de producto o servicio a ofrecer, con la adecuada seleccin de la metodologa a seguir de acuerdo a la naturaleza del proyecto que realizar. Es por ello que se desea disear una herramienta que permita facilitar y ayudar a la direccin de proyectos, en la seleccin de metodologas 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 ms la consecucin 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 seleccin ineficaz puede ser una fuente constante de ralentizacin del trabajo, trabajo repetitivo, innecesario y frustrante.
39
Recomendaciones
Luego de ver algunos de los modelos de ciclo de vida ms utilizados surge la pregunta con la respuesta ms 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 eleccin, la complejidad del problema, el tiempo que disponemos para hacer la entrega final, o si el usuario o cliente desea entregas parciales, la comunicacin 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 investigacin cualquier modelo tiene ventajas e inconvenientes, con lo que, al comenzar un proyecto, habr que examinar la situacin actual para comprobar cul es el modelo ms adecuado al caso.
40
Glosario
Metodologa: Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software. Tarea: Actividades elementales en que se dividen los procesos. Procedimiento: Definicin de la forma de ejecutar la tarea. Tcnica: Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias. Herramienta: Para realizar una tcnica, podemos apoyarnos software que automatizan su aplicacin. en las herramientas
Artefacto: Est mayormente asociado a mtodos o procesos de desarrollo especficos. Un artefacto es un producto tangible resultante del proceso de desarrollo de software. Producto: Resultado de cada etapa. Prototipo: representacin limitada de un producto, permite a las partes probarlo en situaciones reales o explorar su uso, creando as un proceso de diseo de iteracin 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.
41
Bibliografa
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

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ciclo de Vida y Metodologías de Desarrollo de Software (O) PDF

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Nacional San Luis Gonzaga de Ica

Facultad de Ingeniera de Sistemas

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Ciclo de Vida y Metodologas de Desarrollo de Software

Metodologas para el Desarrollo de Software.21

Facultad de Ingeniera de Sistemas - UNICA

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Ciclo de Vida del Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

3. QUE ES EL CICLO DE VIDA DEL SOFTWARE?

4. ACTIVIDADES DEL CICLO DE VIDA DEL SOFTWARE

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Modelos de Ciclo de Vida del Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

2. DIFERENCIAS ENTRE MODELOS

3.1. Modelo Clsico o Cascada

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

3.2. Modelo en Espiral

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

3.3. Desarrollo de prototipos

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

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

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

3.6. Ciclo de Vida Orientado a objetos

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Metodologas para el Desarrollo de Software

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

1. METODOLOGIAS Y CICLO DE VIDA DEL SOFTWARE?

2. METODOLOGIAS EXISTENTES 2.1. Metodologas Tradicionales

Facultad de Ingeniera de Sistemas - UNICA

Ciclo de vida y Metodologas de Desarrollo de Software

Entre las metodologas tradicionales o pesadas podemos citar:

RUP (Rational Unified Procces) MSF (Microsoft Solution Framework) Iconix

Detallaremos algunas de estas metodologas

2.1.1 RUP (Rational Unified Procces)