miércoles, 18 de agosto de 2010

CICLO DE VIDA DEL SOFTWARE




El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.





Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.



El ciclo de vida básico de un software consta de los siguientes procedimientos:



• 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.



• 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.



• 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.



• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.



• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.



• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.



• Implementación



• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).



El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.











http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3
CICLO DE VIDA TIPO LINEAL



Es el más sencillo de todos los modelos que consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas linealmente esto quiere decir que cada etapa se realiza una sola vez. Con un ciclo de vida lineal es fácil dividir las tareas y prever los tiempos.



martes, 17 de agosto de 2010

CICLO DE VIDA TIPO CASCADA GRAFICA DEL MODELO DE CASCADA PURA







a) Es el predecesor de todos los modelos de ciclo de vida y ha servido de base para otros modelos.





b) en este modelo, un proyecto progresa a través de una secuencia ordenada de etapas, partiendo desde su concepto inicial hasta la prueba del mismo.







c) El proyecto realiza una revisión final de cada etapa para determinar si esta preparado para pasar a la siguiente.



FACES DEL MODELO







• Planeación



• Análisis



• Diseño



• Implementación



• Optimización







VENTAJAS DEL MODELO DE CASCADA PURA



1.-Se utiliza correctamente para ciclos en los que se tiene una clara resolución de solicitud del producto.

2.-Puede constituir una elección correcta para el desarrollo rápido.

3.-ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas.

4.-Funciona bien

5.-Evita una fuente común de errores importantes.

6.-Presenta el proyecto con una estructura que ayuda a minimizar el esfuerzo inútil.







DESVENTAJAS DEL MODELO DE CASCADA PURA





1.--Dificultad para especificar claramente los requerimientos al comienzo del proyecto (no permite flexibilidad en los cambios).



2.-Para un proyecto de desarrollo rápido, el modelo de cascada puede suponer una cantidad excesiva de documentación.



3.-Si se intenta mantener la flexibilidad, la actualización de la especificación se puede convertir en un trabajo a tiempo completo.


4.-No es imposible volver atrás utilizando el modelo de cascada pura, pero si difícil.


5.-Genera pocos signos visibles de progreso hasta el final.







El modelo de cascada pura es el mas conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias.







Los inconvenientes del modelo hacen que sea, a menudo, poco apropiado para un proyecto de desarrollo rápido.



TIPO DE MODELO DE CICLO DE VIDA



Cada modelo tiene ventajas y desventajas según las condiciones en que se aplican, por eso es importante estudiar el caso del proyecto para aplicar el mejor modelo.





Las principales diferencias entre los modelos están en:



• EL Alcance: un proyecto puede ser un simple estudio de viabilidad de desarrollo de algún producto, o su desarrollo completo, o cubriendo toda su historia, fabricación, modificaciones y retirada.



• Las Características de las fases que dividen el ciclo, esto puede depender del tema del proyecto ya que no son las mismas fases para construcción de un puente que para el de una organización.



• La estructura de la sucesión de las fases que puede ser lineal, con prototipos o en espiral
MODELO DE CICLO DE VIDA V


El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.







Fue creado por Alan Davis y contiene las mismas etapas de cascada puro, con la diferencia que a esta se le agregaron dos subetapas de retroalimentación entre las etapas de análisis y mantemiento, y entre las de diseño debugging. Lo podemos utilizar en aplicaciones que si bien son simples necesitan una confiabilidad muy alta

Ventajas y desventajas son las mismas del ciclo de vaida cascada puro con el agregado de los controles cruzados entre etapas para lograr una mejor correccion.
MODELO DE CICLO DE VIDA SASHIMI



Según el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón.

Ventajas de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases.

Los problemas planteados son:

• Es aún más difícil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.

• Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.

La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. Se ha representado la estructura del ciclo de vida sashimi.




CICLO DE VIDA POR PROTOTIPOS

Pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado.


El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interación ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
CICLO DE VIDA ITERATIVO




El ciclo de vida iterativo consiste en la repetición del ciclo de vida varias veces, después de cada repetición se la entrega una versión cada vez mejor al cliente el cual evalúa y define las fallas en el encontradas, hasta obtener un producto final.

















Ventajas

Con este ciclo se disminuye la probabilidad de insatisfacción del cliente frente al producto final.
CICLO DE VIDA EVOLUTIVO



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 de ser ejecutadas durante esas fases.



• Ayuda a administrar el progreso del desarrollo, y



• Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.







Los modelos por una parte suministran una guía para los ingenieros 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.



El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento.



El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:







• 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.



Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipo evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.



En el modelo evolutivo, los requerimientos son examinados, y sólo los bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.



El sistema es desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada y así el proceso se repite indefinidamente.



El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. El modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.



Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.



El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.







Modelo de Prototipado de Requerimientos



El prototipo 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. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. 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.







El Prototipado se usó frecuentemente en los 90, porque la especificación de los requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer.



Retroalimentación convenientemente basada en la manipulación, leer una especificación de requerimientos potencialmente ambigua y extensa.



Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
CICLO DE VIDA INCREMENTAL








Este ciclo se desprende del ciclo de vida evolutivo que se basa en varios ciclos cascada, es decir donde se permiten y esperan los probables cambios en el tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar, este modelo es aconsejable para el desarrollo del software en su etapa inicial de análisis ya que en sus futuros incrementos (del software) el ciclo de vida incremental llevara a pensar un mejor esquema, por lo tanto este ciclo facilita el paradigma del diseñador con las prioridades ya definidas lo cual facilita la incorporación de nuevos desarrollos en el software



Veamos un ejemplo:







En este diagrama genérico vemos los pasos generales para el desarrollo de un producto del software desde el ciclo de vida incremental





1. La descripción del sistema es esencial para especificar y perfeccionar los distintos incrementos hasta llegar al producto final.







2. Las actividades concurrentes (Especificación, desarrollo y validación) sintetizan el desarrollo generalizado de los incrementos que se harán posteriormente.







3. Cada versión emitida incorpora a los anteriores incrementos, las funcionalidades y requisitos que fueron analizados como necesarios.







4. Finalmente luego de cada integración (las flechas) se entrega el producto con mayor funcionalidad, el proceso se repite hasta alcanzar el software completo.
MODELO DE CICLO DE VIDA EN ESPIRAL




CICLO DE VIDA EN ESPIRAL






Consiste en una serie de ciclos que se repiten, cada uno tiene las mismas fases y cuando termina da un. En este modo es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Este riesgo puede ser por muchas cosas:











Ventajas



No necesita una definición completa de los requisitos para empezar a funcionar.



Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.



El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).



El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.







Inconvenientes



Es difícil evaluar los riesgos.



Necesita de la participación continua por parte del cliente.



Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.







Dónde es adecuado



Sistemas de gran tamaño.



Proyectos donde sea importante el factor riesgo.



Cuando no sea posible definir al principio todos los requisitos.



• Requisitos no comprendidos,



• Mal diseño,



• Errores en la implementación,



• etc.
CICLO DE VIDA ORIENTADO A OBJETOS






Este ciclo de vida fue presentado en la década de los 90, quizá como una de las mejores tecnologías a seguir para la creación de Software; En esta metodología cada funcionalidad o requerimiento solicitado por el usuario es objeto, los objetos están representados por un conjunto de propiedades llamados atributos, mientras que el comportamiento de los objetos se denomina métodos lo cual nos ayuda a tener una idea del concepto de objeto sobre los casos de la vida real. Veamos un ejemplo sobre este ciclo de vida:





La principal característica de este modelo es la abstracción de los requerimientos del usuario lo cual nos da una idea clara sobre el objeto que vamos a diseñar, ahora bien este modelo se divide en tres fases:





1. La planificación del negocio



2. La construcción: Es la más importante de todas y se divide en 5 actividades.







La planificación, la investigación, la especificación, la implementación y la revisión



La primera y tercera fase son independientes de la metodología de este ciclo, además de estas tres fases, existen 2 periodos:



1. Crecimiento: Es el tiempo durante el cual se construye el sistema





2. Madurez: Es el periodo de mantenimiento el producto donde este se va mejorando junto con las fases de planificación de negocio, construcción y entrega (Liberación).



Cada fase puede tener solo un ciclo de vida debido a que cada ciclo puede estar en alguna fase al momento que quiera. Las ventajas de este ciclo son las siguientes:



1. Permite un desarrollo iterativo (renovado y/o repetitivo).



2. El factor de crecimiento de la reducción de la complejidad que deseemos abordar y permitir el perfeccionamiento del producto.