Qu es el Ciclo de Vida del SW?

Es el proceso por el que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse. Un proceso est compuesto por un conjunto de actividades y tareas que se deben realizar, y una serie de documentos asociados a ellas. Los procesos del Ciclo de Vida del SW Estndar 12207 Segn esta norma las actividades que se pueden llevar a cabo durante el ciclo de vida del SW se Pueden agrupar en: 5 procesos principales 8 procesos de soporte 4 procesos de organizacin o generales

Cada una de estas actividades est compuesta por diferentes tareas:

PROCESOS PRINCIPALES

Adquisicin: Actividades y tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema, un servicio o un producto software: Preparacin y publicacin de ofertas. Seleccin del suministrador de SW.

Suministro: Actividades y tareas del suministrador: Preparar contratos como respuesta a una peticin de un comprador de un producto SW. Identificar los recursos necesarios para llevar a cabo con xito el desarrollo del producto SW.

Desarrollo: Actividades y tareas enfocadas a la obtencin de un producto Software. Anlisis Diseo Codificacin Pruebas Integracin Implantacin

Explotacin: Explotacin del SW y soporte operativo a los usuarios. Mantenimiento: Actividades que incluyen modificaciones del producto, tanto del cdigo como de la documentacin, debido a errores o a la necesidad de mejora o/y adaptacin. Migracin hacia un nuevo entorno operativo. Retirada del producto.

PROCESOS DE SOPORTE Dan soporte al resto de procesos y se aplican durante cualquier momento del ciclo de vida del SW. Documentacin: Registrar la informacin producida por un proceso o actividad del ciclo de vida: Disear, editar, distribuir y mantener los documentos producidos durante el desarrollo del SW.

Gestin de la Configuracin: Actividades que controlan las modificaciones y versiones de los elementos. Registrar las peticiones de cambios e informar de los estados de stos. Aseguramiento de la calidad: Actividades para asegurar que los productos cumplen los requisitos especificados y se ajustan a los planes establecidos. Verificacin: Actividades para determinar el buen funcionamiento de un producto software.

Validacin: Actividades para determinar si el producto cumple los requisitos previstos. Revisin conjunta: Actividades que permiten determinar el estado de los productos en una determinada actividad del ciclo de vida o en una cierta fase del proyecto. Puede ser una reunin conjunta con el cliente, el grupo de desarrollo y los clientes potenciales para revisar el trabajo hecho. Auditoras: Actividades que permiten determinar en unos momentos determinados si se han conseguido los objetivos propuestos: requisitos, cumplimiento del contrato. Resolucin de problemas: Actividades que permiten analizar y resolver los problemas o disconformidades con los requisitos o con el contrato, que hayan surgido durante el desarrollo, la explotacin, el mantenimiento, o en cualquier otro momento. Disponer de un medio documental que permita asegurar que todos los problemas se han tratado. PROCESOS GENERALES Procesos que dan soporte a la organizacin: gestin, formacin del personal, mejora de los procesos. Gestin: Actividades de planificacin, seguimiento, control, revisin y evaluacin. Infraestructura: Actividades para determinar la infraestructura necesaria para un proceso. Incluye HW, SW, instalaciones Mejora: Valorar, medir, controlar, evaluar y mejorar todos los procesos del ciclo de vida. Formacin: Plan de formacin para los empleados. MODELOS DE PROCESOS Representacin abstracta de un proceso del software. Son estrategias de desarrollo que ayudan a organizar las diferentes actividades del ciclo de vida del software. Estos modelos ayudan al control y a la coordinacin del proyecto. El modelo a utilizar depende del tipo de proyecto.

Modelo Cascada Es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.

Fases del modelo Anlisis de requisitos: En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software. Diseo del Sistema: Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin. Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. Codificacin: Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido. Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final. Verificacin: Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo Mantenimiento: Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Variantes

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final est libre de fallos. Desventajas En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. Modelo Espiral Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. Ciclos o Iteraciones En cada vuelta o iteracin hay que tener en cuenta:

Los Objetivos: qu necesidad debe cubrir el producto. Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: 1. Caractersticas: experiencia del personal, requisitos a cumplir, etc. 2. Formas de gestin del sistema. 3. Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular: 1. Angular: Indica el avance del proyecto del software dentro de un ciclo. 2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos. Tareas Para cada ciclo habr cuatro actividades: 1. 2. 3. 4. Determinar Objetivos. Anlisis del riesgo. Planificacin. Desarrollar y probar.

Determinar o fijar objetivos Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. Fijar las restricciones. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacin inicial. Anlisis del riesgo Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir. Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Desarrollar, verificar y validar (probar) Tareas de la actividad propia y de prueba. Anlisis de alternativas e identificacin resolucin de riesgos. Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el ms apropiado. Mecanismos de control

La dimensin radial mide el coste. La dimensin angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral

Modelo en Espiral Tpico de seis regiones. Modelo en espiral WIN WIN. Ventajas El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos.

Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos Inconvenientes Planificar un proyecto con esta metodologa es a menudo imposible, debido a la incertidumbre en el nmero de iteraciones que sern necesarias. En este contexto la evaluacin de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluacin requiere la intervencin de profesionales de gran experiencia. El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV.

LENGUAJE UNIFICADO DE MODELADO (UML) La notacin de UML est compuesta por dos subdivisiones importantes. Hay una notacin para modelar los elementos estticos tales como clases, atributos y relaciones. Tambin hay otra notacin para modelar los elementos dinmicos tales como objetos, mensajes y mquinas de estado finitas. Los elementos estticos se representan mediante diagramas de estructura esttica, ms conocidos por su nombre corto, diagramas de clases. Muestran el conjunto de clases que forman parte de la estructura esttica de un sistema, junto con las relaciones existentes entre estas clases. Pero cuando se modela la estructura esttica de un sistema, podemos usar los diagramas de clases de tres formas diferentes: 1. para modelar el vocabulario de un sistema

Modelar el vocabulario de un sistema implica tomar una decisin sobre qu abstracciones forman parte del sistema y qu otras caen fuera de sus lmites. Aqu usamos los diagramas de clases para especificar dichas abstracciones y sus responsabilidades. 2. para modelar colaboraciones de forma sencilla Una colaboracin es un conjunto de clases, interfaces y otros elementos que trabajan juntos para proporcionar un comportamiento de cooperacin mayor que la suma de todos los elementos. Por ejemplo, cuando queremos modelar las semnticas de una transaccin en un sistema distribuido, no podemos fijarnos en una sola clase para entender lo que est sucediendo. Es mejor que estas semnticas sean llevadas a cabo por un conjunto de clases que trabajen juntas. Aqu usamos los diagramas de clases para visualizar y especificar este conjunto de clases y sus relaciones. 3. para modelar el esquema lgico de una base de datos En muchos dominios podemos querer almacenar informacin continua (persistent information) en una base de datos relacional u orientada a objetos. Aqu usamos los diagramas de clase para modelar los esquemas de dichas bases de datos. Nosotros vamos a estudiar los diagramas de clases que se utilizan para modelar el vocabulario de un sistema. DIAGRAMAS DE CLASES Un diagrama de Clase muestra los bloques de construccin de cualquier sistema orientado a objetos. Los diagramas de clases describen la vista esttica del modelo o parte del modelo, describiendo que atributos y comportamientos tienen en lugar de detallar los mtodos para realizar operaciones. Los diagramas de Clase son ms tiles para ilustrar relaciones entre clases e interfaces. Las generalizaciones, agregaciones, y asociaciones son todas valiosas al reflejar herencias, composicin o uso, y conexiones respectivamente. Clases

Una clase es un elemento que define los atributos y comportamientos que un objeto podr generar. El comportamiento es el que se describe por posibles mensajes que la clase pueda comprender conjuntamente con las operaciones que son apropiadas para cada mensaje. Las clases pueden tambin contener definiciones de valores etiquetados de restricciones y estereotipos. Notacin de Clase Las clases se representan por rectngulos que muestran el nombre de la clase y opcionalmente el nombre de las operaciones y atributos. Los compartimientos se usan para dividir el nombre de la clase, atributos y operaciones. Adicionalmente las restricciones, valores iniciales y parmetros se pueden asignar a clases.

En el siguiente diagrama la clase contiene el nombre de la clase en el compartimiento ms alto, el compartimiento siguiente detalla los atributos, con el atributo del centro mostrando los valores iniciales. El ltimo compartimiento muestra las operaciones, las operaciones setWidth, setLength y setPosition mostrando sus parmetros. La notacin que precede el nombre del atributo u operacin indica la visibilidad del elemento, si se usa el smbolo + el atributo y la operacin tienen un nivel pblico de visibilidad, si se usa un smbolo el atributo u operacin es privado. Adems, el smbolo # permite definir una operacin o atributo como protegido y el smbolo ~ indica la visibilidad del paquete.

Interfaces Una interfaz es una especificacin que los implementadores han acordado realizar. Es un contrato. Si se realiza una interfaz, se garantiza que las clases soporten un comportamiento requerido, que

permite que el sistema trate los elementos no relacionados en la misma manera es decir a travs de la interfaz comn.

Las interfaces se pueden dibujar en un estilo similar al de una clase, con operaciones especificadas como se muestra a continuacin. Tambin se pueden dibujar como un crculo con ninguna operacin explicita detallada. Cuando se dibujan como un crculo, se dibujan vnculos de realizacin a la forma de crculo de la notacin sin flechas de destino.

Tablas Una tabla es una clase estereotipada. Esto se dibuja con un pequeo icono de la tabla en la esquina superior derecha. Los atributos de la tabla son columnas estereotipadas. La mayora de las tablas tendrn una clave primaria, siendo uno o ms campos los que forman una combinacin nica usada para acceder la tabla, ms una operacin de clave primaria que es PK

estereotipada. Algunas tablas tendrn una o ms claves forneas, siendo uno o ms campos que juntos trazan a una clave fornea en una tabla relacionada, ms una operacin de clave fornea que es FK estereotipada.

Asociaciones Una asociacin implica que dos elementos del modelo tienen una relacin usualmente implementada como una variable de instancia de una clase. Este conector puede incluir roles nombrados en cada extremo, cardinalidad, direccin y restricciones. Una asociacin es el tipo de relacin general entre elementos. Para ms de dos elementos, un elemento de la caja de herramientas de representacin diagonal tambin se puede usar. Cuando se genera cdigo para diagramas de clase, las asociaciones se convierten en variables de instancia en la clase de destino.

Generalizaciones Una generalizacin se usa para indicar herencia. Dibujada desde un clasificador especifico a un clasificador general, la implicacin general es que el origen hereda las caractersticas del destino. El siguiente diagrama muestra una clase padre generalizando una clase hijo. Implcitamente, un objeto instanciado de la clase Circulo tendr atributos x_position, y_position y radius y un mtodo display(). Tener en cuenta que la Forma de clase es abstracta, mostrada por el nombre en itlica.

Agregaciones Las agregaciones se usan para describir elementos que estn compuestos de componentes ms pequeos. Las relaciones de agregacin se muestran por una punta de flecha con forma de diamante apuntando hacia el destino o clase padre. Una forma ms fuerte de agregacin una agregacin compuesta se muestra por una flecha con forma de diamante negro. Si el padre de una agregacin compuesta se elimina, usualmente todas sus partes se eliminan con el mismo; sin embargo una parte puede ser individualmente eliminada desde una composicin sin tener que eliminar toda la composicin. Las composiciones son relaciones transitivas, asimtricas y pueden ser recursivas. Agregacin * Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). * Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).

* Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). * Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. * La composicin (por Valor) se destaca por un rombo relleno. * La agregacin (por Referencia) se destaca por un rombo transparente.

Clase Asociacin Una clase asociacin es una estructura que permite una conexin de asociacin para tener conexiones y atributos. El siguiente ejemplo muestra que hay ms al ubicar un empleado a un proyecto que al hacer un vnculo asociacin simple entre dos clases: el rol que el empleado toma en un proyecto es una entidad compleja y contiene detalles que no pertenecen al empleado o clase del proyecto. Por ejemplo, un empleado puede estar trabajando en muchos proyectos al mismo tiempo y tienen diferentes ttulos de trabajo y niveles de seguridad.

Dependencias Una dependencia se usa para modelar un alto rango de relaciones dependientes entre elementos del modelo. Esto se usara normalmente tempranamente en el proceso de diseo donde se conoce que hay algn tipo de vnculo entre dos elementos pero es muy temprano para saber exactamente cul es la relacin. Luego en el proceso de diseo, las dependencias sern estereotipadas (los estereotipos disponibles incluyen <<instanciar>>, <<trazar>>, <<importar>> y otros) o reemplazar con un tipo de conector ms especfico.

Trazado La relacin de trazado es una especializacin de una dependencia, vinculando elementos del modelo o conjuntos de elementos que representan la misma idea a travs de los modelos. Los trazados se usan a menudo para rastrear cambios de requisitos y del modelo. Como los cambios pueden ocurrir en dos direcciones, la orden de esta dependencia usualmente se ignora. Las propiedades de relacin pueden especificar la asignacin de trazado, pero el trazado es usualmente bidireccional, informal y raramente computable. Realizaciones El objeto fuente implementa o realiza el destino. Realizar se usa para expresar trazabilidad e integridad en el modelo un proceso de negocio o requisitos se realiza por uno o ms casos de uso que a su vez se realizan por un componente, etc. Asignando requisitos, clases, etc. a travs del

diseo de su sistema, hacia arriba a travs de los niveles de abstracciones del modelo, asegura las imgenes grandes de su sistema, recuerda y refleja todas las imagines pequeas y detalla esa restriccin y la define. Una relacin se muestra como una lnea de trazos con una punta de flecha slida y el estereotipo <<realizar>>. Anidamientos Un anidamiento es un conector que muestra que el elemento fuente se anida dentro del elemento destino. El siguiente diagrama muestra la definicin de una clase interna a pesar de que en EA es ms usual mostrarlos por su posicin en la jerarqua de la Vista del Proyecto.