UNIDAD 2

UML

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).

• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.

• Establecer conceptos y artefactos ejecutables.

• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

• Mejor soporte a la planeación y al control de proyectos.

• Alta reutilización y minimización de costos.
• 
  
• 
• 
• 
• 
• 
• 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.
  Existen varias versiones: 
  
  
  1.-el ciclo de vida clásico o en cascada
  2.-el modelo en espiral
  3.-el desarrollo de prototipos
  4.-el modelo por incrementos 
  ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
  Modelo Cascada
  Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.
  
  
  Modelo Espiral
  El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
  
  
  Ø  Determinar qué quieres lograr.
  Ø  Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
  Ø  Seguir la alternativa seleccionada en el paso 2.
  Ø  Establecer qué tienes terminado.
  Ø  La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
  Modelo de Prototipado de Requerimientos.-
  El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo.
  El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.
  
  
  Modelo De Desarrollo Incremental
  Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
  
  
  Beneficios:
  
  
  Ø  Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
  Ø  Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
  
  
  Ø  Si un error importante es realizado, sólo la última iteración necesita ser descartada.
  
  
  Ø  Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
  
  
  Ø  Si un error importante es realizado, el incremento previo puede ser usado.
  
  
  Ø  Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.