1. ciclo de_vida_de_software

847 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
847
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

1. ciclo de_vida_de_software

  1. 1. Ciclo de Vida del Software Introduccion Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, desde 10 a 15 años atrás, el modelo cascada ha sido sujeto de numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos. Definición de un Modelo de Ciclo de Vida Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas. Un modelo de ciclo de vida del software:  Describe las fases principales de desarrollo de software.  Define las fases primarias esperadas para ser ejecutadas durante esas fases.  Ayuda a administrar el progreso del proyecto, y  Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software. Así, los modelos por una parte suministran una guía para los desarrolladores de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran, un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
  2. 2. Modelos de ciclo de vida Es el conjunto de etapas que describen el proceso de desarrollo de software desde su nacimiento hasta su reemplazo o eliminación. Se compone de las siguientes fases: ¿…Que es Fase…?. Conjunto de actividades relacionadas con un objetivo en el desarrollo de un proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
  3. 3. REQUISITOS  Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global. o Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. o Diseño general: requisitos generales de la arquitectura de la aplicación. Diseño en detalle: definición precisa de cada subconjunto de la aplicación. ANALISIS DISEÑO o CODIFICACION o Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. o Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones. Integración: el propósito de la prueba de integración es garantizar que los diferentes módulos se integren con la aplicación. esta debe estar cuidadosamente documentada en la liberación. Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales. PRUEBAS o o
  4. 4. LIBERACION (release) o o o Documentación: sirve para documentar información necesaria para los usuarios del software y para futuros desarrollos. Implementación definitiva de la aplicación. Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo). Los Enfoques o paradigmas de desarrollo de software . Orientado por procedimientos o Estructurado . Orientado por datos . Orientado por objetos PARADIGMAS DE CICLO DE VIDA DE DESARROLLO DE SOFTWARE PARADIGMA DE CASCADA Es el modelo más antiguo, propuesto por Winston Royce, comenzó a diseñarse en 1966 y terminó alrededor de 1970. Es una secuencia de fases de un subconjunto de los procesos de desarrollo y Administración, en la que al final de cada una de estas fases, se reúne la documentación adecuada para garantizar que cumpla unas especificaciones y requisitos, antes de pasar a su próxima fase. En este paradigma se reconocen las siguientes etapas o fases para el desarrollo del software:    El Análisis de Requerimientos La Especificación de Requerimientos El Diseño Externo o de la interfaz con el usuario.
  5. 5. Menús manejadores de entrada, pantallas o informes de salida, sonidos de retroalimentación. (def: todo eco (salida de datos) que puede ser reutilizado para pruebas.) Diseño Interno 1. 2  Diseño estructural, Puede ser simultáneo con el de interfaz de usuario. Aquí se definen la estructura del sistema (componentes modulares y sus interrelaciones) y la mayoría de las estructuras de datos. Diseño detallado, Detalle de cómo implementar cada uno de los componentes del diseño estructural. La Implementación. Codificación. Prueba.  El Mantenimiento.
  6. 6. DESVENTAJAS DEL PARADIGMA DE CASCADA      Gran énfasis en la producción de documentos completamente elaborados, producto de las fases de análisis y especificación de requerimientos y de diseño. No muy aplicable a productos de software altamente interactivos (dinámicos). Es difícil tener todos los requerimientos, bien definidos al principio, como lo requiere el modelo y además presenta dificultades para acomodar posibles incertidumbres existentes al comienzo de los proyectos. Los productos de software raramente siguen el flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicación del
  7. 7.      paradigma. Un error importante no detectado al principio puede ser desastroso. Se requiere mucha paciencia por parte del cliente, porque solo hasta las etapas finales del desarrollo podrá tener una versión operativa del producto. No aprovecha la iteración, ni el desarrollo exploratorio. Dificultad para integrar administración del riesgo. Hacer cambios es difícil y costoso. VENTAJAS DEL PARADIGMA DE CASCADA       Fácil entendimiento e implementación. Ampliamente utilizado y conocido (En teoría). Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar. Identifica entregables (son los resultados del proyecto entregados al cliente) e hitos(son las puntas finales de una actividad de un proceso). Orientado a documentos. Funciona bien en productos maduros y equipos débiles. PARADIGMA CODIFICAR Y CORREGIR El modelo codificar y corregir es el modelo utilizado cuando no nos paramos en buscar el modelo más idóneo para nuestro proyecto. Es decir en este modelo no se pierde el tiempo en la planificación, en la calidad, en los documentos que hay que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la codificación. Por lo tanto este modelo no se necesita tener experiencia y una gran cantidad de conocimientos. Al no seguir un modelo no tenemos ningún medio de ver si se cumplen las expectativas creadas, lo cual es un problema si encontramos un error casi al finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos más en ver los errores que en otro modelo que sigue un mínimo de planificación. PARADIGMA EN V Busca hacer la actividad de pruebas más efectiva y productiva. Los planes (y casos de prueba) se van elaborando a medida que se avanza en el desarrollo del proyecto.
  8. 8. Las actividades desde requerimientos hasta implementación se enfocan en una representación detallada del sistema, mientras que las actividades de implementación hasta operación se enfocan en la validación del sistema.
  9. 9. EL PARADIGMA DE PROTOTIPO Puede tomar alguna de las siguientes formas:    Un escenario (simulación del uso del sistema) Una demostración (porciones de código que realizan algunas funciones) Una versión cero(0) ( aplicación liberada (release) que puede usarse bajo condiciones preliminares añadiendo, cambiando o quitando funciones existentes y creándole su documentación) Cuando se Usa: Cuando los requerimientos no son claros o no se identifican en forma detallada los requerimientos de entrada, salida y funciones. Características:        El uso de prototipos no es exclusivo del ciclo de vida iterativo. Los prototipos se pueden usar como una herramienta para obtener y validar los requisitos de clientes y usuarios en cualquier ciclo de vida. Lo habitual es usar prototipos de interfaz de usuario, que pueden reutilizarse (ejecutables) o desecharse (papel). Siempre se debe evaluar si el esfuerzo de desarrollo del prototipo merece la pena (costo de errores). Es fundamental la implicación de los usuarios. Otro tipo de prototipos pueden utilizarse para evaluar diferentes algoritmos antes de tomar decisiones de diseño. Siempre se debe tener en cuenta que el prototipo no es el producto final, ya que su calidad no suele ser la necesaria. VENTAJAS DEL PARADIGMA DE PROTOTIPOS     Son reales y tangibles. Permite al cliente aclarar lo que quiere que haga el sistema. Siente que es oído y tenido en cuenta para el diseño (cliente). Asegura que el trabajo se está haciendo bien y cumpliendo los requerimientos del cliente. DESVENTAJAS DEL PARADIGMA DE PROTOTIPOS  El cliente puede creer que el sistema ya está listo y pedir su entrega rápida.  Crea expectativas más allá de lo que realmente puede hacer.  Se dificulta la dirección y control del proceso de desarrollo más que en el
  10. 10. método clásico.  La presión por entregar rápido el producto compromete la calidad.  Se dificulta mantener el entusiasmo del cliente después de aprobado el prototipo porque creerá que se desperdicia el tiempo en detalles insignificantes. Componentes software  Cada vez es más frecuente el ensamblaje de componentes software desarrollados por terceros en la construcción de nuevos sistemas software.  El uso de componentes tiene implicaciones en todas las actividades del desarrollo desde los requisitos hasta el mantenimiento.
  11. 11. Ingeniería inversa  A veces es necesario mantener sistemas heredados (legacy systems) que fueron desarrollados sin documentación.  La ingeniería inversa consiste en analizar el resultado de una etapa de software para obtener el resultado o la solucion de la anterior; normalmente analizar el código para obtener el diseño. Reingeniería  La reingeniería utiliza la información obtenida por la ingeniería inversa para aplicar cualquier tipo de mantenimiento: o Perfectivo: modificación de un producto software después de la entrega para mejorar el rendimiento o la mantenibilidad). o Adaptativo: modificación de un producto software realizada después de la entrega para permitir que un producto software siga pudiéndose utilizar en un entorno diferente.
  12. 12. o Correctivo: modificaciones reactivas a un producto software hechas después de la entrega para corregir defectos descubiertos. o Preventivo: modificaciones reactivas a un producto software hechas en base a una planeación y a un cronograma. o Emergencia: cuando los cambios se deben hacer sin planificación previa, para mantener un sistema en operación.  El mantenimiento preventivo del efecto 2000 (y2k) ha sido el mayor esfuerzo de ingeniería inversa, reingeniería y mantenimiento en la historia de la Ingeniería del Software. PARADIGMA DE ESPIRAL Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas de ingeniería del sistema. Características           Propuesto por Bohem en 1987 Modelo centrado en la actividades Introduce: manejo de riesgos y creación de prototipos, no incluidas anteriormente. Es el mejor modelo para grandes sistemas. Su elevada complejidad desaconseja su uso en sistemas pequeños. Las actividades son organizadas en ciclos. Es ideal para crear productos con diferentes versiones mejoradas como se hace con el software moderno de microcomputadoras. La ingeniería puede desarrollarse y/o combinarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente. Un ciclo corresponde a la construcción de un producto intermedio, Y este contempla los siguientes elementos:  Concepto de operación.
  13. 13.          Requerimientos de software. Diseño de productos del sistema. Diseño detallado. Código. Prueba unitaria. Integración y pruebas. Prueba de aceptación. Implementación. Las fases de cada ciclo son: 1. Identificar alternativas, restricciones y objetivos. 2. Administrar Riesgos. 3. Desarrollar y validar un prototipo. 4. Planear la siguiente fase. 1 4 2 3 El proyecto P1 se encuentra en la actividad de análisis de riesgos asociados con los requerimientos de software, mientras que el proyecto P2 está en el desarrollo del diseño de productos del sistema.
  14. 14. El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Pero Generalmente, pueden existir entre cuatro y seis regiones de tareas. Comunicación con el cliente: las tareas requeridas para establecer comunicación los desarrolladores y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada
  15. 15. paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente. VENTAJAS:      El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no termina cuando se entrega el software. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos. Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma. La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representa el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
  16. 16. PROBLEMAS:   Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. Requiere gran habilidad y experiencia para valorar el riesgo y saber cuándo detener la evolución PARADIGMA DE PROCESO UNIFICADO El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso (def: es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software), centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento
  17. 17. particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh que a la vez son los creadores de este paradigma. Características principales Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.
  18. 18. Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. Más características    Consiste en varios ciclos. Al final de cada uno, un producto es entregado al cliente. Cada ciclo consiste de cuatro fases:      Inception (inicio - alcance y los objetivos del proyecto) Elaboration Construction Transition Una iteración construye un conjunto de casos de uso relacionados o mitiga algún riesgo de los identificados. DESARROLLO ITERATIVO Y EL PROCESO UNIFICADO
  19. 19. Modelo Team Software Process - TSP
  20. 20. TALLER Investigar en qué consiste la norma ISO 12207. BIBLIOGRAFIA Bernd Bruegge, Dutoit Allen. Object-Oriented Software Engineering: Using UML, Patterns, and Java, 2004, Prentice Hall, segunda edición. http://standards.ieee.org/catalog/olis/arch_se.html

×