27-2-2016

Hernández Najera Carlos EnriqueEscobar Barrera Juan de Mata

ING. EN TECNOLOGIAS DE LA INFORMACION Y COMUNICACION

INVESTIGACION:2.3. Modelos de la ingeniería del software: modeló de cascada, modelo de prototipos, modelo de espiral, modelo de Proceso Unificado Racional (RUP).

UNIDAD ll

Unidad 2: Modelos de Ingeniería del software

2.3. Modelos de la ingeniería del software: modeló de cascada, modelo de prototipos, modelo de espiral, modelo de Proceso Unificado Racional (RUP).

1.- Modelo cascada:•Es un modelo sencillo para explicar al cliente.

•También llamado ciclo de vida clásico sugiere un enfoque sistemático. Secuencial en el desarrollo del software.

•Requiere que los requerimientos estén bien definidos y estables en forma razonable.

•Es el paradigma más antiguo para la Ingeniería del Software. 

Fases:

•Ingeniería y Análisis del Sistema: Debido a que el software siempre es parte de un sistema mayor el trabajo comienza estableciendo los requerimientos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

•Análisis de los requerimientos del software: El proceso de recopilación de los requerimientos se centra e intensifica especialmente en el software. El ingeniero del software debe comprender el ámbito de la información del software así como la función del rendimiento y las interfaces requeridas. .•Diseño: Se enfoca en cuatro atributos distintos del programa la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz.

•Codificación: Debe traducirse en una forma legible para la máquina.

•Prueba: Se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requiere.

•Mantenimiento: El software sufriría cambios después de que se entrega al cliente ocurren debido a que hayan encontrado errores que el software deba adaptarse a cambios del entorno externo o que el cliente requiera aplicaciones funcionales o del rendimiento. 

Características:

Es el más utilizado.  Es una visión del proceso de desarrollo de software como una sucesión de etapas

que producen productos intermedios. 

Para que el proyecto tenga éxito deben desarrollarse todas las fases.  Las fases continúan hasta que los objetivos se han cumplido.  Si se cambia el orden de las fases, el producto final será de inferior calidad.

Ventajas:

La planificación es sencilla.  La calidad del producto resultante es alta.  Permite trabajar con personal poco calificado.

Desventajas:

No refleja realmente el proceso de desarrollo del software.  Se tarda mucho tiempo en pasar por todo el ciclo.  El mantenimiento se realiza en el código fuente.  Las revisiones de proyectos de gran complejidad son muy difíciles.

2.- Modelo de prototipos:

•Es una visión preliminar del modelo futuro.•Es un modelo operable. •Fácilmente ampliable y modificable. •Tiene todas las características propuestas pero realmente es un modelo básico que tiene que ser mejorado 

Ventajas:

•La posibilidad de cambiar el modelo.

•La oportunidad para suspender el modelo del desarrollo del modelo sino es funcional. 

•La oportunidad de crear un nuevo modelo que se ajuste a mejor a las necesidades y expectativas de los usuarios.

Relaciones de usuario:

Las sugerencias obtenidas de los usuarios lleven al analista hacia adecuaciones o cambios que se ajustan mejor a las necesidades de los usuarios y que no habían sido pensadas antes de la interacción del usuario con el prototipo. Debe ser construido en poco tiempo, no debe de utilizarse mucho dinero, cuando este sea aprobado podemos iniciar el verdadero desarrollo del software. Podrá ser construido si con el software es posible experimentar.  

Desventajas:

Debido a que el usuario ve que funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software. Debe ir acompañado de otro modelo para su desarrollo. 

Tipo de modelo de prototipo: 

•Desechable. Nos sirve para eliminar dudas sobre las que realmente quiere al cliente además para desarrollar la interfaz que más le convenga al cliente. 

•Evolucionario: Es parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad.

 A favor:

Útiles cuando los requerimientos son cambiantes.  Cuando no se conoce bien la aplicación.  Cuando el usuario no se quiere comprometer con los requerimientos.  Cuando se quiere probar una arquitectura o tecnología. Cuando se requiere

rapidez en el desarrollo.

En contra:

No se conoce cuando se tendrá un producto aceptable. No se sabe cuántas interacciones serán necesarias. Da una falsa ilusión al usuario sobre la velocidad del desarrollo. Se puede volver al producto aun y cuando no esté en los estándares.

Modelo en espiral:

Las actividades se conforman en un espiral en la que cada bucle o interacción representa un conjunto de actividades, no están fijadas a prioridad sino que las siguientes se eligen en función de análisis de riesgo comenzando por el bucle interior.

Características:

•Encada giro se construye un nuevo modelo del sistema completo. •Este modelo puede combinarse con otros modelos de proceso de desarrollo. •Mejo ir modelo para desarrollo de grandes sistemas. •El análisis de riesgo requiere la participación del personal con alta calificación. •No hay número definido de interacciones, deben de decidirlas el equipo de gestión de proyecto.

Ventajas:

Modelo espiral de cuatro regiones o modelo original de Boehm. 

Modelo espiral de seis regiones. 

Modelo espiral WINWIN.

3.- Modelo espiral WINWIN:

WINWIN (Victoria) sugiere una actividad del marco de trabajo que aborda la comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal del desarrollador simplemente pregunta al cliente lo que se necesita y proporciona detalles suficientes para continuar.

Ventajas:

•El modelo en espiral es un enfoque realista del desarrollo de sistemas. •Modelo de proceso adaptable. •El modelo en espiral puede s aplicarse a lo largo de la vida del software. •El desarrollador y el cliente comprenden y reaccionan mejor ante riegos 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 y si se aplicada adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. •Modelos evolutivos como el espiral son apropiados particularmente para el desarrollo de Sistemas OO. •Trata de mejorar los ciclos de vida de clásicos y prototipos. •Permite acomodar otros modelos. •Incorpora objetivos de calidad y gestión de riesgos. •Elimina errores y alternativas no atractivas al comienzo.

Desventajas:

•Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. •Es nuevo y no se ha utilizado tanto como otro modelo de ciclo de vida. •Requiere una considerable habilidad para la evaluación del riesgo y cuenta con esta habilidad para el éxito. •Si un riesgo es importante no es detectado y gestionado a tiempo indudablemente surgirán problemas.

Hitos del modelo WIN-WIN:

Introduce tres hitos son los procesos llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión antes de continuar el proyecto de software. Los puntos de fijación representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral. 

Modelos más destacados del proceso de la producción de software (ciclos de vida).

1.- Codifica y corrige (code-and-fix).

 

Proceso:

o Codifica un poco.

o Prueba y elimina los errores.

o Repite el proceso.

 

Ventaja: efectivo para productos pequeños. 

Desventaja: diseño "spaghetti", no manejable para sistemas grandes. 

Característica: basado en la inspiración personal.

 

2.- Modelo Codifica y corrige. (Transparencia A2)

 

El ciclo de vida o proceso de desarrollo de software más antiguo y utilizado hasta la fecha, sobre todo por la gente que empieza a aprender la programación, es el llamado "code-and-fix", cuya traducción correcta al español sería "codifica y corrige". En este proceso los pasos ha seguir por los desarrolladores son:

 

Codifica un poco, luego

Prueba y elimina los errores, es decir, realiza, si es necesario, la corrección y

Repite el proceso hasta que se obtenga la solución buscada.

 

El ciclo de vida es efectivo para productos o sistemas pequeños, principalmente cuando se trata de desarrollos unipersonales. En contraste, el diseño final puede ser de estilo "spaghetti", es decir, que al ir pegando poco a poco diferentes partes de código, es posible obtener un producto, que aunque funcione, no sea muy coherente, y no cuente, desde el punto de vista del diseño, con una arquitectura legible y razonable. 

Otra desventaja es que este tipo de arquitectura no es adecuado para sistemas medianos y grandes. Su característica principal es que depende de la inspiración personal, del heroísmo, de la experiencia, del conocimiento y de las habilidades del desarrollador. 

 

3.- Modelo Evolutivo.

 A partir de este modelo, encontramos los más recientes originados del de cascada, que actualmente están impactando y adaptándose cada vez más a la orientación a objetos.

El modelo Evolutivo conocido también como incremental e iterativo, consiste en hacer la documentación de las fases, realizando un prototipo del sistema, se evalúa el qué tan lejos el prototipo está de la solución final esperada por el cliente; se toman en cuenta las observaciones de esta evaluación, y se crea un nuevo prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeñas proporciones hasta cumplir los requerimientos totales. 

En este método no es necesario esperar hasta que toda una fase esté terminada para iniciar la siguiente. Si se cuenta con una parte del análisis bien entendida, se puede realizar un primer diseño del corazón o de una parte medular del sistema, hacer su codificación y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los requerimientos originales.

 La ventaja es que es ideal para sistemas que no tiene bien definidos los requerimientos, es decir, para la mayoría de los sistemas que se desarrollan. El cliente desde el principio tiene una idea de los requerimientos de su sistema, pero no están claros hasta el último

detalle. Aun así podemos basarnos en lo ya entendido (cliente y desarrollador), trabajar con esta información, y mientras se vayan creando prototipos, el cliente detallará sus especificaciones.

 

Su desventaja es que es difícil distinguirlo del proceso "codifica y corrige", pues en cierta medida son parecidos, la diferencia está que en la práctica se requiere que al construir el prototipo se aplique el análisis y el diseño pero sólo a una parte de los requerimientos ya entendidos, que se documente y se codifique, lográndose con todo esto, un poco de disciplina heredada del modelo en cascada, de esta manera, la desventaja no lo es tanto. La característica de este modelo es que está enfocado a la producción de prototipos.

4.- Evolutivo (evolutionary).

 

Proceso:

o Haz un prototipo.

o Mide qué tan lejos está de lo esperado.

o Toma en cuenta las observaciones para generar el siguiente prototipo.

o Es un proceso repetitivo y creciente.

 

 Ventaja: ideal para sistemas que no tienen bien definidos los requerimientos.

 Desventaja: es difícil de distinguirlo del proceso "codifica y corrige".

 Característica: enfocado a la producción de prototipos.

4.- Modelo Espiral. 

 La misma idea de prototipos la encontramos en este modelo, (se sugiere revisar las notas de la clase de Ingeniería de Software para mayores detalles). En la propuesta de Boehm, la espiral representa muy bien la idea del desarrollo iterativo e incremental, así como la del desarrollo por prototipos, en donde estos al principio abarcan una pequeña parte del sistema, (la evaluación de riesgos) y empiezan en el centro de la espiral.

 Es un modelo evolutivo pero en cada vuelta, antes de generar un nuevo prototipo, se evalúa el riesgo que se corre si continuáramos con la siguiente iteración, es decir, si aún por parte del cliente y de nosotros existe tiempo, recursos y decisión para seguir mejorando este proceso de desarrollo o por el contrario, si encontramos que los riesgos son demasiado grandes, pues entonces tomar las decisiones adecuadas como la suspensión del proyecto o la solicitud de más recursos. La idea es que antes de generar un prototipo, evaluemos la factibilidad y analicemos los riesgos. Si el resultado es positivo, entonces generamos el primer prototipo (el cual abarca sólo una parte del sistema), continuamos con las fases siguientes (simulación, comparación, validación de

requerimientos) hasta que deje de ser prototipo y se convierta en el sistema completo, cuya puesta en operación, ya integrada y aceptada por el cliente, constituye la salida del proceso. Este modelo es iterativo pues repite los pasos incrementándolos cada vez al ir robusteciendo el prototipo en su funcionalidad.

   

5.- Modelo Transformador. (Transparencia A.6)

 

Este modelo actualmente no es ni básico ni popular en la modelación orientada a objetos, pero sí es el sueño dorado de los desarrolladores, puesto que propone la posibilidad de construir código a partir de las especificaciones dadas. Esto constituye la base para las herramientas CASE, donde, utilizando un lenguaje abstracto o gráfico para describir las especificaciones de manera más agradable, la herramienta automatizada se encarga de realizar el código. En el modelo transformador, se realiza la especificación formal del sistema y la herramienta convierte automáticamente esta especificación en el código. 

Rational Rose pude ser un ejemplo de este modelo porque de una especificación con UML puede generar código en Java, C++ o VisualBasic. En realidad sólo genera esqueletos, especificaciones de clases y encabezados de métodos pero no sus códigos. Existen otras propuestas de lenguajes de especificación formal como Z, que permiten especificar sistemas matemáticamente con mayor precisión y generar el código. Como actualmente estos métodos son poco eficientes y populares, creemos que el proceso de desarrollo de software va encaminado a crear lenguajes de especificación más expresivos.

La desventaja es que es bueno para productores relativamente pequeños de áreas limitadas. Las hojas de cálculo y lenguajes de cuarta generación (4GL) –desarrollados en la práctica para el uso de bases de datos- son ejemplos de lenguajes de especificaciones más abstractas que permite generar el código, pero hasta la fecha, estos lenguajes están restringidos a ciertas aplicaciones (como los constructores de la familia Visual) y aún no existen para propósito general.

 La característica de este modelo es que se trabaja en el nivel de especificación y no se llega al nivel del lenguaje de programación.

Proceso:

o Haz la especificación formal.

o Conviértela automáticamente en código.

 

 

Ventaja: las modificaciones se hacen en el nivel de especificación y no a nivel del código, ahorra tiempo de diseño, codificación y pruebas.

 Desventaja: bueno para productores relativamente pequeños de áreas limitadas (hojas de cálculo, 4GL’s).

 Característica: trabajo en el nivel de especificación.

 

MODELO ITERATIVO INCREMENTAL

El modelo incremental combina elementos del modelo cascada (aplicado repetidamente) así como la filosofía iterativa del prototipado. La parte inicial es el núcleo del producto (es la parte mas importante).Una nueva versión del producto surge cuando nuevas características han sido implementadas a medida que han sido sugeridas por el usuario.

La Descripción del Sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado de los incrementos.

Diagrama genérico del desarrollo evolutivo incremental

El modelo iterativo incremental es sólo esquemática, un incremento no necesariamente se iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de “Operación y Mantenimiento” (indicada "Operación" en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o 17

Dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc. Como se muestra en la anterior imagen, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema básico, con muchas funciones suplementarias (conocidas o no) sin entregar. El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Además también aportan a ese plan otros factores, como lo es la priorización (mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre incrementos (o independencia). Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo. Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construcción de prototipos). La principal característica de estos modelos es que permite crear cada vez versiones más completas de software, para esto construimos versiones sucesivas de un producto. Se crea una primera versión que es utilizada por el usuario donde se provee retroalimentación al desarrollador, y según los requerimientos especificados de éste usuario se crea una segunda versión.