Ingeniería de Sistemas de Información II

Docente: Dr. Freddy Lizardo Kaseng Solis

Integrantes:Badillo Alvarado, ArturoCarranza Ruiz, JulioLazo Osorio, Sheyla

Universidad N

acional Federico Villarreal

2013

Valor Creativo - Autor: Valor Creativo 1

2

Ingeniería de Sistemas de Información II - Página 2

“El diseño de la arquitectura del software es el equivalente del plano de una casa. Éste ilustra la distribución general de las habitaciones, su tamaño, forma y relaciones entre

ellas, así como las puertas y ventanas que permiten el movimiento entre los cuartos”.

R. S. Pressman

3

Ingeniería de Sistemas de Información II - Página 3

Contenido

Resumen5

Introducción

1. Antecedentes

2. Definición

3. Opiniones Diversas

4. Características de la Arquitectura de Software

4.1 Multitud de actores

4.2 Separación de preocupaciones

4.3 Calidad Impulsada

4.4 Estilos recurrentes

4.5 Integridad Conceptual

5. Motivación

6. ¿Por qué es importante la arquitectura de software?

7. Actividades de Arquitectura

7.1 Análisis Arquitectónico

7.2 Síntesis Arquitectónica

7.3 Evaluación de la Arquitectura

7.4 Evolución de la Arquitectura2

8. Visión de la Arquitectura

8.1 Vista Lógica

Primera Sesión: Arquitectura del Software

4

Ingeniería de Sistemas de Información II - Página 4

8.2 Vista de Procesos

8.3 Vista de Implementación

8.4 Vista de Despliegue

8.5 Vista de Casos de Uso

8.6 Vista de Datos

9. El ciclo de desarrollo de la Arquitectura

9.1 Requerimientos

9.2 Diseño

9.3 Documentación

9.4 Evaluación

10. Organización de Modelos

11. Articulación de Diagramas

11.1 Lenguajes de Descripción de Arquitectura (ADL)

11.1.1 Características escenciales

11.1.2 Prototipos desarrollados

12. Despliegues de códigos ejecutables

12.1 Usos

12.1.1 Sistemas empotrados

12.1.2 Sistemas Cliente-Servidor

12.1.2 Sistemas completamente distribuidos

13. Componentes del Software

13.1 Características

13.2 Granularidad

14. Patrones Arquitectónico

14.1 Modelo de Vista Controlador

14.2 Descripción del Patrón

14.2.1 El Modelo

14.2.2 El Controlador

14.2.3 La Vista

14.3 Interacción de los componentes

14.4 MVC y base de datos

14.5 Usos en Aplicaciones Web

14.6 Frameworks MVC

15. Conclusión

5

Ingeniería de Sistemas de Información II - Página 5

n los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a

las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. La Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".

E

El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo. Al igual que en la ingeniería civil, las decisiones críticas relativas al diseño general de un sistema de software complejo deben de hacerse desde un principio. El no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el producto final satisfaga las necesidades de los clientes. Además, el costo de las correcciones relacionadas con problemas en la arquitectura es muy elevado. Es así que la arquitectura de software juega un papel fundamental dentro del desarrollo.

Resumen

6

Ingeniería de Sistemas de Información II - Página 6

l termino arquitectura de software denota el alto nivel de las estructuras de un sistema de software. Se puede definir como el conjunto de estructuras necesarias para razonar sobre el sistema de software, que comprenden los elementos de software, las relaciones

entre ellos, y las propiedades de ambos elementos y relaciones.EEl termino arquitectura de software también denota el conjunto de las practicas utilizadas para seleccionar, definir y diseñar una arquitectura de software.

Por último, el termino denota a menudo documentación de la “arquitectura de software” del sistema. La documentación de la arquitectura de software facilita la comunicación entre las partes interesadas, capta primeras decisiones sobre el diseño de alto nivel, y permite la reutilización de componentes de diseño entre los proyectos.

Título 1

Título 2

Título 3

Normal

Introducción

7

Ingeniería de Sistemas de Información II - Página 7

Arquitectura del Software

1. Antecedentes

En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de investigación (por ejemplo, EdsgerDijkstra). No obstante, toma popularidad en los años 1990 tras reconocerse la denominada crisis del software y como tema de interés de la incipiente disciplina de la ingeniería del software.

2. Definición

Aplicando el término “arquitectura” de los sistemas de software es una metáfora que hace referencia al ámbito clásico de la arquitectura de los edificios. El término “arquitectura de software” se utiliza para referirse a 3 conceptos:

Estructura de alto nivel de un sistema de software. Disciplina de la creación de una estructura de tan alto nivel. Documentación de esta estructura de alto nivel.

El diseño de la Arquitectura de un Software es el proceso por el cual se define una solución para los requisitos técnicos y operacionales del mismo. Este proceso define qué componentes forman el software, cómo se relacionan entre ellos, y cómo mediante su interacción llevan a cabo la funcionalidad especificada, cumpliendo con los criterios previamente establecidos; como seguridad, disponibilidad, eficiencia o usabilidad.

Durante el diseño de la arquitectura se tratan tópicos que puedan provocar un impacto importante en el éxito o fracaso de nuestro software. Son esenciales realizar las siguientes interrogantes para cubrir este punto:

¿En qué entorno se desplegará nuestro software? ¿Cómo se pondrá en producción nuestro software? ¿Cómo utilizarán los usuarios nuestro software? ¿Existen requisitos adicionales que el software debe cumplir? (Por ejemplo: seguridad,

rendimiento, concurrencia, configuración, disponibilidad, entre otros)

8

Ingeniería de Sistemas de Información II - Página 8

¿Cuáles serían los cambios sobre la arquitectura propuesta, que impactarían al software durante o después de desplegarse?

3. Opiniones Diversas

Hasta la fecha, aún no hay acuerdo sobre la definición precisa de la arquitectura de software. Las opiniones varían sobre lo que es la arquitectura en el mundo del software:

Estructura general, macroscópica sistema; esto se refiere a la arquitectura como un nivel de abstracción más alto de un sistema de software que consta de los componentes y conectores de alto nivel, a diferencia de los detalles de implementación.

Las cosas-lo importante que es, lo que se refiere al hecho de que los arquitectos de software deben preocuparse de esas decisiones que tienen un alto impacto en el sistema y sus grupos de interés-que pueden incluir parecer detalles de bajo nivel.

Lo que es fundamental para la comprensión de un sistema en su entorno”.

Las cosas que la gente percibe como difícil de cambiar, ya que el diseño de la arquitectura se lleva a cabo a principios del ciclo de vida de un sistema de software, el arquitecto debe centrarse en las decisiones que "tiene que" estar en lo cierto la primera vez, ya que revertir esas decisiones puede ser imposible o prohibitivamente caro.

Una serie de decisiones de diseño arquitectónico, arquitectura de software no deben considerarse simplemente un conjunto de modelos o estructuras, sino que deben incluir las decisiones que conducen a estas estructuras particulares, y las razones detrás de ellos. Esta idea ha dado lugar a una investigación sustancial en la gestión del conocimiento arquitectura de software.

No existe una clara distinción entre la arquitectura del software frente del diseño y la ingeniería de requisitos. Todos ellos son parte de una "cadena de la intencionalidad" de las intenciones de alto nivel a los detalles de bajo nivel.

4. Características de la Arquitectura de Software

4.1 Multitud de actoresLos sistemas de software tienen que atender a una gran variedad de partes interesadas, como los gerentes de empresas, propietarios, usuarios y operadores. Estos actores tienen sus propias preocupaciones con respecto al sistema. El equilibrio de estos problemas y demostrar cómo se abordan es parte del diseño del sistema. Esto implica que la arquitectura consiste en hacer frente a una amplia variedad de problemas y las partes interesadas, y tiene un carácter multidisciplinar.

9

Ingeniería de Sistemas de Información II - Página 9

4.2 Separación de preocupacionesLa forma establecida para reducir la complejidad es mediante la separación de las preocupaciones que impulsan el diseño. La documentación muestra que todas las preocupaciones e interesados se dirigen al modelar y describir la arquitectura de diversos puntos de vista relacionados con las diversas preocupaciones de los interesados. Estas descripciones separadas se denominan vistas arquitectónicas.

4.3 Calidad impulsadaLos enfoques clásicos de diseño de software (por ejemplo, Jackson Programación Estructurada) se debieron a la funcionalidad requerida y el flujo de datos a través del sistema, pero el conocimiento actual es que la arquitectura de un sistema está relacionada con su calidad de atributos tales como la tolerancia a fallos, compatibilidad de versiones anteriores, la extensibilidad, confiabilidad, mantenimiento, disponibilidad, seguridad, facilidad de uso, etc. Las preocupaciones de los grupos de interés a menudo se traducen en requisitos de estos atributos de calidad, que se llama indistintamente los requerimientos no funcionales, requerimientos extra funcionales, requerimientos de calidad del sistema o limitaciones.

4.4 Estilos recurrentesComo arquitectura, la disciplina de la arquitectura de software ha desarrollado formas estándar para entender las preocupaciones recurrentes. Estas “formas normales” son llamadas por diferentes nombres en niveles de abstracción. Términos comunes para soluciones recurrentes son de estilo arquitectónico, la estrategia o la táctica, arquitectura de referencia y patrón arquitectónica.

4.5 Integridad conceptualEl término denota la idea de que la arquitectura de un sistema de software representa una visión general de lo que se debe hacer y cómo debe hacerlo. Esta visión debe ser separada de su implementación. El arquitecto asume el papel de “guardián de la visión”, asegurándose de que las adiciones al sistema están en consonancia con la arquitectura, por lo tanto, la preservación de la integridad conceptual.

5. Motivación

Arquitectura de software es una abstracción “intelectualmente aprehensible” de un sistema complejo. Esta abstracción proporciona una serie de beneficios:

Se da una base para el análisis del comportamiento de sistemas de software antes de que el sistema sea construido.

La capacidad de verificar que un sistema de software en el futuro cumple las necesidades de los interesados sin tener que ser construido, lo cual representa el ahorro de costes y de riesgos de mitigación sustancial.

Un número de técnicas han sido desarrolladas para llevar a cabo este tipo de análisis, ATAM.

Proporciona una base para la reutilización de elementos y decisiones. Una arquitectura de software completa o parte de ella, al igual que las estrategias y las decisiones arquitectónicas individuales, pueden ser reutilizados en múltiples sistemas cuyos

10

Ingeniería de Sistemas de Información II - Página 10

interesados requieren atributos de calidad similares o funcionalidad, el ahorro de costes de diseño y mitigar el riesgo de errores de diseño.

Facilita la comunicación con las partes interesadas, lo que contribuye a un sistema que satisface mejor sus necesidades. La comunicación sobre sistemas complejos desde los puntos de vista de las partes interesadas les ayuda a comprender las consecuencias de los requerimientos señalados y las decisiones de diseño basadas en ellos. Da la capacidad de comunicar decisiones de diseño antes de implementar el sistema, cuando todavía son relativamente fáciles de adaptar.

Les ayuda en la gestión de riesgos.

Permite la reducción de costes. La arquitectura de software es un medio para reducir los costos de los proyectos de TI complejos.

6. ¿Por qué es importante la arquitectura de software?

La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición deba transitar por muchos componentes antes de que se devuelva una respuesta podría tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los componentes estén altamente acoplados entre ellos limitará severamente la modificabilidad.

11

Ingeniería de Sistemas de Información II - Página 11

Curiosamente, la estructuración tiene un impacto mucho menor respecto a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los requerimientos funcionales que se le imponen. Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto.

Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos.

7. Actividades de la Arquitectura

Hay muchas actividades que un arquitecto de software realiza. Un arquitecto de software normalmente trabaja con los directores de proyectos, analiza los requerimientos de gran importancia arquitectónica con las partes interesadas, evalúa el diseño, se comunica con los diseñadores y las partes interesadas, documenta el diseño arquitectónico, entre otros.

Existen 4 actividades básicas que se realizan de forma iterativa y en diferentes etapas del ciclo de vida inicial de desarrollo del sistema de software, así como durante su evolución.

7.1 Análisis Arquitectónico

Es el proceso de comprender el entorno en el que un sistema o sistemas propuestos funcionaran y la determinación de los requerimientos del sistema. Los requerimientos pueden venir de cualquier número de partes interesadas e incluir elementos tales como:

Lo que el sistema va a hacer cuando está funcionando (los requisitos funcionales)-

Lo bien que el sistema llevará a cabo los requisitos no funcionales de ejecución, tales como la fiabilidad, operatividad, eficiencia en el rendimiento, la seguridad, la compatibilidad se definen en la norma ISO / IEC 25010:2011.

El desarrollo a tiempo de los requisitos no funcionales tales como mantenimiento y transferencia definidos en la norma ISO 25010:2011.

Los requerimientos del negocio y contextos ambientales de un sistema que puede cambiar con el tiempo, como las preocupaciones legales, sociales, financieras, competitivas, y la tecnología.

7.2 Síntesis Arquitectónica

Es el proceso de creación de una arquitectura. Teniendo en cuenta los requerimientos determinados por el análisis, el estado actual de diseño y los resultados de las actividades de evaluación, el diseño es creado y mejorado.

12

Ingeniería de Sistemas de Información II - Página 12

7.3 Evaluación de la Arquitectura

Es el proceso de determinar qué tan bueno es el diseño actual o si una parte de este cumple con los requerimientos derivados durante el análisis. Una evaluación puede ocurrir siempre que un arquitecto está considerando una decisión de diseño. Puede ocurrir después de que una parte o todo el diseño se ha completado, inclusive puede ocurrir después de que el sistema ha sido construido.

7.4 Evolución de la Arquitectura

Es el proceso de mantenimiento y adaptación de una arquitectura de software existente para satisfacer las necesidades y los cambios ambientales. Como la arquitectura de software proporciona una estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente tendría un impacto en su estructura. Como tal, la evolución de la arquitectura se refiere a la adición de una nueva funcionalidad, así como el mantenimiento de la funcionalidad existente y el comportamiento del sistema.

Adicionalmente la arquitectura de software requiere actividades de apoyo. Tales actividades involucran la gestión del conocimiento, a comunicación, el razonamiento del diseño, la toma de decisiones y la documentación.

8. Visión De La Arquitectura Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se usan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí.

8.1 Vista Lógica (Logicalview)

Audiencia: Diseñadores del software. Área: Requerimientos funcionales: describe el modelo de objetos. También describe

las realizaciones de casos de uso más importantes. Artefactos Relacionados: Designmodel.

8.2 Vista De Procesos (Processview)

Audiencia: Integradores. Área: Requerimientos no funcionales: describe aspectos de concurrencia y

sincronización. Artefactos Relacionados: (ningún artefacto específico).

13

Ingeniería de Sistemas de Información II - Página 13

8.3 Vista De Implementación (Implementationview)

Audiencia: Programadores. Área: Componentes de software: describe las capas y los subsistemas de la aplicación. Artefactos Relacionados: Modelo de implementación, componentes.

8.4 Vista De Despliegue (Deploymentview)

Audiencia: Implementadores. Área: Topología: describe cómo se relaciona el software con el hardware y muestra los

aspectos distribuidos del sistema. Artefactos Relacionados: Modelo de implementación.

8.5 Vista De Casos De Uso (Use Case View)

Audiencia: todos los stakeholders del sistema, incluyendo los usuarios finales. Área: describe un conjunto de escenarios que representan la funcionalidad central y

más representativa del sistema. Artefactos Relacionados: Modelo de casos de uso, documentos de casos de uso.

8.6 Vista De Datos (Data View)

Audiencia: Especialistas en datos y administradores de base de datos. Área: Persistencia: describe los elementos de la arquitectura que son significativos

para la persistencia. Artefactos Relacionados: Modelo de datos.

9. El ciclo de desarrollo de la Arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, está dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo. A continuación se describen dichas etapas.

9.1 Requerimientos

La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones.

14

Ingeniería de Sistemas de Información II - Página 14

9.2 Diseño.

La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías por que están “de moda”.

9.3 Documentación.

Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama.

9.4 Evaluación.

Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.

10. Organización de Modelos

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

La visión estática: describe que componentes tiene la arquitectura. La visión funcional: describe que hace cada componente. La visión dinámica: describe cómo se comportan los componentes a los largo del

tiempo y cómo interactúan entre sí.

15

Ingeniería de Sistemas de Información II - Página 15

11. Articulación de Diagramas

Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).

11.1Lenguajes de Descripción de Arquitecturas (ADL):

Un ADL es un lenguaje que proporciona elementos para modelar la arquitectura conceptual de un sistema de software.

11.1.1 Características Esenciales:

Componentes Conectores Configuraciones Herramientas de soporte y análisis.

11.1.2 Prototipos desarrollados:

16

Ingeniería de Sistemas de Información II - Página 16

12. Despliegues de códigos ejecutables

El UML proporciona un tipo de diagrama que se emplea para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias en el lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre serán entre los nodos y por ejemplo con una base de datos.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un clúster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

12.1 Usos

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

12.1.1 Sistemas empotrados

Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.

12.1.2 Sistemas cliente-servidor:

Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.

12.1.3 Sistemas completamente distribuidos

En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

17

Ingeniería de Sistemas de Información II - Página 17

13. Componentes de Software

Un componente de software es una unidad de composición con interfaces especificadas en forma de contratoy con dependencias de contexto explicitas. Un componente de software puede ser desplegado (deployed) o instalado independientemente. Es decir, puede ser instalado en algún lugar pero debe cumplir con ciertas especificaciones (interfaces) o bien bajo cierto contexto (tecnología).

Ejemplos de componentes de software:

Assemblies de .NET EJB de J2EE

18

Ingeniería de Sistemas de Información II - Página 18

Applets de Java, o incluso los Java Beans.

Los componentes de software están muy ligados a ciertas tecnologías, de ahí que surgen ciertas metodologías como la MDA (ModelDrivenArchitecture) que busca diseñar sistemas en base a modelos o componentes, y que al momento de pasarlo a un sistema, con una serie de traductores se podría desarrollar la tecnología deseada (J2EE o .NET).

13.1Características

Es una unidad ejecutable que puede ser implantada independientemente. Puede ser sujeto de composición por terceras partes, es decir, una compañía o un

desarrollador puede llegar a tomar el componente y agregarlo a lo que está haciendo (composición de componentes).

Se puede tomar a los componentes de software como una analogía de los componentes electrónicos, la idea de esto es tener diversos componentes que puedan ser tomados para hacer un sistema más grande.

Existen diversos modelos de componentes, los más conocidos son .NET, EJB (Enterpise Java Beans) y CCM (CORBA ComponentModel).

13.2 Granularidad

La granularidad de sincronización, o frecuencia, entre procesos en el sistema, es una buena manera de caracterizar multiprocesadores y ubicarlos en un contexto con otras arquitecturas. Se pueden distinguir 5 categorías de paralelismo que difieren en el grado de granularidad.

Tamaño de Grano Descripción Intervalo de sincronización (instrucciones)

Fino Paralelismo inherente en un único flujo de instrucciones.

< 20

Medio Procesamiento paralelo o multitarea dentro de una aplicación

20 – 200

Grueso Multiprocesamiento de procesos concurrentes en un entorno multiprogramado.

200 – 2000

Muy Grueso Proceso distribuido por los nodos de una red para formar un solo entorno de computación.

2000 -1M

Independiente Varios procesos no relacionados

(N/A)

19

Controlador

ModeloVista

Ingeniería de Sistemas de Información II - Página 19

14. Patrones arquitectónico

Los patrones arquitectónicos, son patrones de diseño de software que ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una descripción de los elementos y el tipo de relación que tienen con un conjunto de restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones arquitectónicos tienen un nivel de abstracción mayor.

Aunque un patrón arquitectónico comunica una imagen de un sistema, no es una arquitectura como tal. Un patrón arquitectónico es un concepto que captura elementos esenciales de una arquitectura. Muchas arquitecturas diferentes pueden implementar el mismo patrón y por lo tanto compartir las mismas características. Además, los patrones son a menudo definidos como una cosa “estrictamente descrita y comúnmente disponible”. Por ejemplo, la arquitectura en capas es un estilo de llamamiento y regreso, cuando define uno un estilo general para interaccionar. Cuando esto es descrito estrictamente y comúnmente disponible, es un patrón. Uno de los aspectos más importantes de los patrones arquitectónicos es que encarna diferentes atributos de calidad. Por ejemplo, algunos patrones representan soluciones a problemas de rendimiento y otros pueden ser utilizados con éxito en sistemas de alta disponibilidad. A principios de la fase de diseño, un arquitecto de software escoge que patrones arquitectónicos mejor ofrecen las calidades deseadas para el sistema.Ejemplos de patrones arquitectónicos:

Programación por capas. Tres niveles Pipeline Invocación implícita Arquitectura en pizarra Arquitectura dirigida por eventos, presentación – abstracción – control Peer – to – peer Arquitectura orientada a servicios. Modelo Vista Controlador (MVC).

14.1 Modelo Vista Controlador

El modelo vista controlador (MVC) es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el modulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado se define componentes para la presentación de la información, y por otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de código y la separación

20

Ingeniería de Sistemas de Información II - Página 20

de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

14.2 Descripción del Patrón

De manera genérica, los componentes de MVC se podrán definir como sigue:

14.2.1 El modelo

Es la representación específica de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se han descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la vista aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al modelo a través del controlador.

14.2.2 El controlador

Responde a eventos (usualmente acciones del usuario) e invoca peticiones al modelo cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o registro en una base de datos). También puede enviar comandos a su vista asociada si se solicita un cambio de la forma en que se presenta el modelo (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por lo tanto se podría decir que el controlador hace de intermediario entre la vista y el modelo (Middleware).

14.2.3 La vista

Presenta el modelo (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho modelo la información que debe representar como salida.

14.3 Interacción de los componentes

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue es generalmente el siguiente:

El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, pulsa un botón, enlace, etc.)

El controlador recibe (por parte de los objetos de interfaz - vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.

Model

Controller

Usel

View

21

Ingeniería de Sistemas de Información II - Página 21

El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.

El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta dirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.

Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. Por ejemplo en el MVC usado por Apple en su framework Cocoa. Suele citarse como Modelo-Interface-Control, una variación del MVC más puro

La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente....

14.4 MVC y bases de datos

Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos que debe utilizar la aplicación; en líneas generales del MVC dicha gestión corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre la Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

14.5 Uso en aplicaciones Web

Aunque originalmente MVC fue desarrollado para aplicaciones de escritorio, ha sido ampliamente adaptado como arquitectura para diseñar e implementar aplicaciones web en los principales lenguajes de programación. Se han desarrollado multitud de frameworks, comerciales y no comerciales, que implementan este patrón; estos frameworks se diferencian básicamente en la interpretación de como las funciones MVC se dividen entre cliente y servidor.

22

Ingeniería de Sistemas de Información II - Página 22

Los primeros frameworks MVC para desarrollo web planteaban un enfoque cliente ligero en el que casi todas las funciones, tanto de vista, el modelo y el controlador recaían en el servidor. En este enfoque, el cliente manda la petición de cualquier hiperenlace o formulario al controlador y después recibe de la vista una página completa y actualizada (u otro documento); tanto el modelo como el controlador (y buena parte de la vista) están completamente alojados en el servidor. Como las tecnologías web han madurado, ahora existen frameworks como JavaScriptMVC, Backbone o JQuery que permiten que ciertos componentes MVC se ejecuten parcial o totalmente en el cliente (AJAX).

14.6 Frameworks MVC

Lenguaje Licencia Nombre

Objective C Apple CocoaRuby MIT Ruby onRailsRuby MIT MerbRuby MIT RamazeRuby MIT RhodesJava Apache GrailsJava GPL Interface Java ObjectsJava LGPL Framework DinámicaJava Apache StrutsJava Apache BeehiveJava Apache SpringJava Apache TapestryJava Apache AuroraJava Apache JavaServerFaces

JavaScript GPLv3 ExtJS 4Perl GPL MojoliciousPerl GPL CatalystPerl GPL CGI::ApplicationPerl GPL Gantry FrameworkPerl GPL JiftyPerl GPL MaypolePerl GPL OpenInteract2Perl Comercial PageKitPerl GPL Cyclone 3Perl GPL CGI::BuilderPHP GPL Self Framework ( php5, MVC, ORM, Templates, I18N,

Multiples DB)PHP LGPL ZanPHPPHP LGPL TlalokesPHP GPL SiaMVCPHP LGPL AgaviPHP BSD Zend FrameworkPHP MIT CakePHP

23

Ingeniería de Sistemas de Información II - Página 23

PHP GNU/GPL KumbiaPHPPHP MIT SymfonyPHP MIT QCodoPHP GNU/GPL CodeIgniterPHP BSD KohanaPHP MPL 1.1 PHP4ECorePHP BSD PRADOPHP GNU FlavorPHPPHP Apache 2.0 Yupp PHP FrameworkPHP BSD Yii PHP FrameworkPHP GPL Logick PHP FrameworkPHP GPL Osezno PHP FrameworkPHP MIT (sPHPf) Simple PHP FrameworkPHP GNU/GPL gvHidra

Python ZPL Zope3Python Varias TurbogearsPython GPL Web2pyPython BSD PylonsPython BSD Django

.NET Castle Project MonoRail

.NET Apache Spring .NET

.NET Apache Maverick .NET

.NET MS-PL ASP.NET MVC

.NET Microsoft Patterns&Practices

User Interface Process (UIP) Application Block

AS3 Adobe Open Source CairngormAS3 yFlex

24

Ingeniería de Sistemas de Información II - Página 24

15. Conclusión

La arquitectura del software nos proporciona una visión global del sistema a construir. Los componentes del software incluyen módulos de programas y varias representaciones de datos que son manipulados por el programa.

La arquitectura marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistemas alternativas.

25

Ingeniería de Sistemas de Información II - Página 25

Contenido

Resumen...................................................................................................................................................................27

Introducción...........................................................................................................................................................28

1. Ciclos de vida-Historia/Antecedentes.................................................................................................29

2. Definición............................................................................................................................................................30

3. Características..................................................................................................................................................31

4. Actividades.........................................................................................................................................................31

5. Fases...................................................................................................................................................................... 32

6. Requerimientos del ciclo de vida...........................................................................................................33

6.1 ¿Qué son requerimientos?.................................................................................................................34

6.2 Características de los requerimientos.........................................................................................34

6.3 Dificultados para definir los requerimientos..........................................................................34

7. Ciclos de vida-clasificación.......................................................................................................................35

7.1 Ciclo de vida iterativo..........................................................................................................................35

7.1.1 Beneficios...........................................................................................................................................36

7.1.2 Características del ciclo de vida iterativo.........................................................................36

Segunda Sesión: Ciclo de Vida del Software

26

Ingeniería de Sistemas de Información II - Página 26

7.2 Ciclo de vida en cascada.....................................................................................................................37

7.3 Ciclo de vida lineal.................................................................................................................................38

7.3.1 Diferencia entre secuencia lineal y cascada....................................................................39

7.4 Ciclo de vida en V...................................................................................................................................39

7.5 Ciclo de vida por prototipos.............................................................................................................40

7.5.1 Recolección de requisitos..........................................................................................................40

7.5.2 Construcción del prototipo......................................................................................................40

7.5.3 Diseño rápido...................................................................................................................................40

7.5.4 Evaluación del prototipo...........................................................................................................41

7.5.5 Refinamiento del prototipo......................................................................................................41

7.5.6 Producto.............................................................................................................................................41

7.6 Ciclo de vida de desarrollo rápido de aplicaciones..............................................................42

7.6.1 Fases.....................................................................................................................................................42

7.6.2 Etapas...................................................................................................................................................42

7.7 Modelo en espiral...................................................................................................................................43

7.7.1 Sectores...............................................................................................................................................43

7.7.2 Diferencia entre ciclo de vida en cascada y espiral.....................................................45

8. Otros ciclos de vida........................................................................................................................................46

8.1 Modelo de especificación operativa.............................................................................................46

8.2 Modelo de transformación................................................................................................................46

8.3 Modelo de componentes.....................................................................................................................47

8.4 Modelo tipo Sashimi.............................................................................................................................47

8.5 Modelo en cascada con subproyectos..........................................................................................48

8.6 Modelo evolutivo....................................................................................................................................48

8.7 Modelo iterativo......................................................................................................................................49

9. Ciclos de vida – Ventajas/Desventajas ...................................................................................................50

9.1 Modelo “codificar y corregir”...........................................................................................................50

9.2 Modelo en cascada.................................................................................................................................50

9.3 Modelo en V...............................................................................................................................................51

9.4 Modelo de “prototipos”.......................................................................................................................51

9.5 Modelo “desarrollo rápido de aplicaciones”............................................................................52

9.6 Modelo en espiral...................................................................................................................................52

10. Conclusión........................................................................................................................................................ 53

11. Referencias bibliográficas..........................................................................................................................54

12. Referencias web.............................................................................................................................................55

27

Ingeniería de Sistemas de Información II - Página 27

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

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

Veremos los rasgos generales del ciclo de vida del software. Cada una de sus etapas, las actividades y los modelos más conocidos que existen en el mercado.

Resumen

28

Ingeniería de Sistemas de Información II - Página 28

l igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta

la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento.

A

Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. La apertura comercial, la competencia, la internacionalización, en pocas palabras: la globalización, ha conllevado a la creación de empresas de todo tipo a nivel mundial.

Perú no es ajeno a este fenómeno y es participe de estas actividades. Sin embargo, las exigencias del mercado, la competencia empresarial, el convencimiento y la satisfacción total de los clientes, son algunos de los puntos que muchas empresas aún no alcanzan por no considerar un tema de gran auge como es la calidad. Tal es el caso de las fábricas de software, siendo un modelo de negocio certificable que ofrece sistemas a la medida de sus clientes y que se encuentra basado en la estructura y capacidad de sus procesos, son uno de los principales segmentos empresariales que han sufrido los estragos de la ausencia de normas y estándares que permitan satisfacer totalmente los requerimientos que un cliente plasma para el desarrollo de un software, se podría pensar que los usuarios de software no cuidan ni piensan en la calidad del programa, con procesar rápido y sin errores se sienten satisfechos, pero al paso del tiempo surgen las constantes molestias y quejas por el sistema y optan por no actualizarlo y cambiarlo por alguno de otra compañía. Estas fallas, quejas o deficiencias son ocasionadas por la falta de una adecuada gestión de los procesos de desarrollo de software por parte de la empresa, por lo que la calidad de los productos y servicios será considerada como deficiente al no conocer el estado actual de sus procesos y por lo tanto, la verdadera capacidad de estos

Introducción

29

Ingeniería de Sistemas de Información II - Página 29

Ciclo de Vida del Software

1. Ciclos de Vida – Historia/Antecedentes

Tradicionalmente el desarrollo de aplicaciones informáticas se llevaba a cabo de forma individualizada, a base de codificar (generar líneas de código) y probar lo realizado cuanto antes.

La misma persona escribía el código, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificación previa y sin que soliese existir documentación alguna.

Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estaría allí cuando se produjese algún fallo.

En principio, el hecho de que desde un primer momento se vaya generando código, podría considerarse como un síntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del código se descubre que el diseño de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificación pura y dura no se realiza (como, por ejemplo, actividades de planificación, de documentación, de aseguramiento de la calidad).

Esta forma de desarrollar aplicaciones es muy común en muchas organizaciones y, generalmente, se utiliza cuando no se elige o sigue un enfoque de desarrollo (ciclo de vida) concreto y/o apenas se realiza la actividad de planificación.

Además, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podrá fácilmente familiarizarse con él.

Esta forma de desarrollar software puede ser eficaz en programas pequeños.Para otro tipo de proyectos, puede resultar peligrosa su utilización, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se está codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se verán en los siguientes apartados, permitirán, por ejemplo, conocer el progreso, detectar un error lo antes posible, etc.

30

Ingeniería de Sistemas de Información II - Página 30

Por lo tanto, es probable que las aplicaciones realizadas según este enfoque de codificar y probar:

• Sean poco flexibles, y ante posibles modificaciones se incremente el coste de los proyectos e, incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de documentación (lo que provocará problemas de mantenimiento).

• Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las funciones requeridas y, además, lo hagan con una escasa fiabilidad.

• Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarán), aparecen errores una vez que la aplicación ha sido entregada (lógico al no haberse realizado de forma sistemática actividades de verificación y validación en el proyecto).

Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleveun enfoque lógico para su realización. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepción y finalizando cuando ya no se utiliza o se retira.

El ciclo de vida software es la descripción de las distintas formas de desarrollode un proyecto o aplicación informática, es decir, la orientación que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. También puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.

2. Definición

• Ciclo de vida se refiere al período de tiempo que comienza cuando se concibe la idea de generar el programa hasta que finalmente se retira.

• Se denomina al conjunto de fases como ser: Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto.

• Facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).

• Es un conjunto ordenado de tareas como un proceso: una serie de pasos que incluye actividades, restricciones y recursos que producen un resultado de un determinado tipo.

31

Ingeniería de Sistemas de Información II - Página 31

Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando la vida del sistema desde la definición hasta la finalización de su uso.

(ISO 12207)

3. Características

• El proceso describe todas las actividades principales.

• El proceso utiliza recursos que están sujetos a una serie de restricciones y genera productos intermedios y finales.

• El proceso puede descomponerse en subprocesos que están enlazados de una forma determinada e, incluso, se puede definir como una jerarquía de procesos, organizados de forma que cada subproceso tenga su propio modelo de proceso.

• Cada actividad del proceso tiene definidos criterios de entrada y salida, de forma que queda claramente especificado cuándo empieza y termina cada actividad.

• Las actividades de un proceso están organizadas en forma de secuencia, de forma que puede saberse cuándo se realiza una actividad en relación con el resto.

• Todo proceso incorpora un conjunto de principios básicos que explican los objetivos de cada actividad.

• Pueden existir restricciones o controles para las actividades, recursos o productos. Así, por ejemplo, el presupuesto o la planificación pueden restringir la cantidad de tiempo que se puede dedicar a una actividad o, por otro lado, una herramienta puede limitar la forma en la que se utiliza un recurso.

4. Actividades

Tales actividades son:

Adopción e identificación del sistema: es importante conocer el origen del sistema, así como las motivaciones que impulsaron el desarrollo del sistema (por qué, para qué, etcétera.).

Análisis de requerimientos: identificación de las necesidades del cliente y los usuarios que el sistema debe satisfacer.

Especificación: los requerimientos se realizan en un lenguaje más formal, de manera que se pueda encontrar la función de correspondencia entre las entradas del sistema y las salidas que se supone que genera. Al estar completamente especificado el sistema, se pueden hacer estimaciones cuantitativas del coste, tiempos de diseño y asignación de personal al sistema, así como la planificación general del proyecto.

32

Ingeniería de Sistemas de Información II - Página 32

Especificación de la arquitectura: define las interfaces de interconexión y recursos entre módulos del sistema de manera apropiada para su diseño detallado y administración.

Diseño: en esta etapa, se divide el sistema en partes manejables que, como anteriormente hemos dicho se llaman módulos, y se analizan los elementos que las constituyen. Esto permite afrontar proyectos de muy alta complejidad.

Desarrollo e implementación: codificación y depuración de la etapa de diseño en implementaciones de código fuente operacional.

Integración y prueba del software: ensamble de los componentes de acuerdo a la arquitectura establecida y evaluación del comportamiento de todo el sistema atendiendo a su funcionalidad y eficacia.

Documentación: generación de documentos necesarios para el uso y mantenimiento.

Entrenamiento y uso: instrucciones y guías para los usuarios detallando las posibilidades y limitaciones del sistema, para su uso efectivo.

Mantenimiento del software: actividades para el mantenimiento operativo del sistema. Se clasifican en: evolución, conservación y mantenimiento propiamente dicho.

Existen diversos modelos de ciclo de vida, pero cada uno de ellos va asociado a unos métodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto.

5. Fases

Cada ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición:

Inicio: Definición del proyecto. Elaboración: Planificación del proyecto, especificación de características y elaborar

arquitectura base. Construcción: Construcción del sistema. Transición: Transición a usuarios

33

Ingeniería de Sistemas de Información II - Página 33

Iteraciones dentro del ciclo de vida. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

6. Requerimientos del Ciclo de Vida

El análisis del sistema proporciona el ámbito del software, su relación con el resto de componentes del sistema, pero antes de empezar a desarrollar es necesario hacer una definición más detallada de la función del software.

Existen dos formas de realizar el análisis y refinamiento de los requisitos del software. Por una parte, se puede hacer un análisis formal del ámbito de la información para establecer modelos del fujo y la estructura de la información. Luego se amplían unos modelos para convertirlos en una especificación del software. La otra alternativa consiste en construir un prototipo del software, que será evaluado por el cliente para intentar consolidar los requisitos. Los requisitos de rendimiento y las limitaciones de recursos se traducen en directivas para la fase de diseño.

El análisis y definición de los requisitos es una tarea que debe llevarse a cabo conjuntamente por el desarrollador de software y por el cliente. La especificación de requisitos del software es el documento que se produce como resultado de esta etapa.

6.1 ¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE.

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

(2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

34

Ingeniería de Sistemas de Información II - Página 34

(3) Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

6.2 Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

6.3 Dificultades para definir los requerimientos

•Los requerimientos no son obvios y vienen de muchas fuentes.

•Son difíciles de expresar en palabras (el lenguaje es ambiguo).

•Existen muchos tipos de requerimientos y diferentes niveles de detalle.

•La cantidad de requerimientos en un proyecto puede ser difícil de manejar. •Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.

35

Ingeniería de Sistemas de Información II - Página 35

• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.

•Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

•Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

7. Ciclo de Vida – Clasificación

En la literatura existe una multitud de modelos de ciclo de vida. Algunos son prescripciones sobre la forma en la que debería realizarse el desarrollo de software, mientras que otros son descripciones de la forma en la que se desarrollan programas actualmente. En teoría ambos tipos de modelos deberían ser iguales o similares, pero en la práctica no lo son. La construcción un modelo de ciclo de vida y la discusión sobre sus subprocesos ayuda a comprender este salto entre lo que debería ser y lo que realmente es.

Las principales diferencias entre distintos modelos de ciclo de vida están divididas en tres grandes versiones:

El alcance del ciclo de vida: que depende de hasta dónde deseamos llegar con el proyecto: sólo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo más las actualizaciones y el mantenimiento.

La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida: según el ciclo de vida que adoptemos, y el proyecto para el cual lo adaptemos.

La estructura y la sucesión de las etapas si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

7.1 Ciclo de Vida Iterativo

Todo sistema complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases o mini proyectos.

Una iteración es un bucle de desarrollo completo, es una secuencia de actividades con un plan establecido y criterios de evaluación. Acaba en la edición de un producto ejecutable, subconjunto del producto final bajo desarrollo.

Se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina Iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Cada iteración parte de la anterior incrementado (crece el producto) o revisando la funcionalidad implementada. Los desarrolladores basan la selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso

36

Ingeniería de Sistemas de Información II - Página 36

que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse. Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada.

7.1.1 Beneficios

La iteración controlada reduce el riesgo a los costos de un solo incremento. Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes

primero. Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener

resultados a corto plazo. Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse

completamente al principio.

7.1.2 Características del ciclo de vida iterativo

Es también una repetición de varios ciclos de vida en cascada. Al final de cada ciclo se entrega una versión completa del software mejorada respecto

a la anterior. Los ciclos se repiten hasta obtener un producto satisfactorio. Los usuarios deben evaluar el producto en cada iteración y proponer mejoras. Se suele aplicar en desarrollos en los que los requisitos no están claros, las primeras

versiones pueden ser prototipos que se desechan posteriormente.

7.2 Ciclo de Vida en Cascada

Diseño

Codificación

Pruebas

Diseño

Codificación

Pruebas

Diseño

Codificación

Pruebas

37

Ingeniería de Sistemas de Información II - Página 37

En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la disposición de las distintas fases de desarrollo, en las que los resultados de una fase parecen caer en cascada hacia la siguiente fase).

El método ideado por Royce constituye uno de los primeros modelos de ciclo de vida publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

Como sugiere el esquema del modelo en cascada, antes de poder avanzar a la siguiente etapa, es necesario haber finalizado completamente la etapa anterior. Asociada con cada etapa del proceso existen hitos y documentos, de tal forma que se puede utilizar el modelo para comprobar los avances del proyecto y para estimar cuánto falta para su finalización. Este modelo es muy útil pues ayuda a los desarrolladores a comprender qué es lo que tienen que hacer en cada momento. Su simplicidad hace que resulte sencillo explicárselo a los clientes que no están familiarizados el proceso software. Además, se muestran de forma explícita qué productos intermedios se tienen que obtener antes de abordar las siguientes tareas.

Una modificación sobre este modelo consiste en la introducción de una revisión y vuelta atrás, con el fin de corregir las deficiencias detectadas durante las distintas etapas, o para completar o aumentar las funcionalidades del sistema en desarrollo, resultando un diagrama de fases y etapas tal como el que se muestra en la Figura 2. De esta manera, durante cualquiera de las fases se puede retroceder momentáneamente a una fase previa para solucionar el problema que se pudieran haber encontrado. Normalmente, el ciclo de vida del software se suele dividir en tres fases: una de Planificación, otra de Desarrollo y una tercera de Mantenimiento, que engloban a las seis etapas (Ingeniería del Sistema, Análisis de los Requisitos, Diseño, Codificación, Pruebas y Mantenimiento) tradicionales del ciclo de vida.

La fase de Planificación del software comprende las etapas de Ingeniería del Sistema o Análisis del Sistema (en concreto el establecimiento de los Requisitos del Software o “Plan Software”) y el Análisis de los Requisitos del Software (que se traduce en una “Especificación de Requisitos”). La fase de Desarrollo comprende las etapas de Diseño, Codificación y Pruebas. Por último, la fase de Mantenimiento incorpora solamente la etapa propia de Mantenimiento. A pesar de su antigüedad, el ciclo de vida clásico se ha hecho con un lugar importante en el área de la Ingeniería del Software. Proporciona una guía de trabajo en la que se encuentran métodos para el análisis, diseño, codificación, pruebas y mantenimiento. El ciclo de vida en cascada sigue siendo el modelo de proceso más extensamente utilizado por los ingenieros del

Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento

38

Ingeniería de Sistemas de Información II - Página 38

software, principalmente por su sencillez y facilidad de llevar a cabo. Pese a tener debilidades, es significativamente mejor que un enfoque arbitrario (como el de codificar y corregir) para el desarrollo del software. Muchos de los posteriores modelos de ciclo de vida son, en realidad, modificaciones sobre el modelo clásico, al que se le incorporan iteraciones o nuevas actividades.

7.3 Ciclo de Vida Lineal

Es el más sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas, que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente.

Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa). Las actividades de cada una de las etapas mencionadas deben ser independientes entre sí, es decir, que es condición primordial que no haya retroalimentación entre ellas, aunque si pueden admitirse ciertos supuestos de realimentación correctiva.Desde el punto de vista de la gestión requiere también que se conozca desde el primer momento, con excesiva rigidez lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla. Esto último minimiza, también las posibilidades de errores durante la codificación y reduce al mínimo la necesidad de requerir información del cliente o del usuario.

Se destaca como ventaja la sencillez de su gestión y administración tanto económica como temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas muy pequeños de ABM ( sistemas que realizan altas, bajas y modificaciones sobre un conjunto de datos). Tiene como desventaja que no es aptopara desarrollos que superen mínimamente requerimientos de retroalimentación entre etapas, es decir es muy costoso retomar una etapa anterior al detectar alguna falla.

La sencillez del ciclo de vida lineal es la razón por la cual es el más elegido en el desarrollo de programas pequeños.

7.3.1 Diferencia Entre Secuencia Lineal Y Cascada

Secuencia lineal es el más sencillo de todos los modelos. Consiste en descomponer la actividad global de proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada

Ciclo Línea

Análisis Diseño Implementación

Debugging Instalación Aceptación

39

Ingeniería de Sistema

Análisis de Requisitos

Diseño

Codificación

Pruebas de Unidad e Integración

Pruebas de Validación

Pruebas de Aceptación

Operación y Mantenimiento

Ingeniería de Sistemas de Información II - Página 39

etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente. Con el ciclo de vida lineal es muy fácil dividir las tareas y prever los tiempos. En cambio el ciclo de vida en cascada es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial o lineal. Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo rígido poco flexible y con muchas restricciones.

7.4 Ciclo de Vida en V

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

Modelo de Ciclo de Vida en V

La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.

7.5 Ciclo de Vida por Prototipos

En contraste con la Ingeniería de Software de la década de los 70, que dio respuesta a proyectos grandes pero con requisitos estables, la Ingeniería de Software de los 80 reaccionó a

40

Ingeniería de Sistemas de Información II - Página 40

las complicaciones resultantes de encontrarse con requisitos poco claros y dinámicos, dando lugar a la “construcción de prototipos”. El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984.

Un prototipo es un mecanismo para identificar los requisitos del software. La construcción de prototipos es un proceso que facilita al ingeniero de software el desarrollo de la aplicación. El prototipo suele tomar una de las tres formas siguientes:

• Un modelo en papel o en computadora que describe la interacción hombre-máquina, de forma que facilite al usuario la comprensión de su funcionamiento.

Por ejemplo, si el sistema a construir es un cajero automático, se puede hacer un programa que simule la interacción del usuario con el cajero sin que el programa esté conectado a ninguna base de datos real ni se despache dinero. De esta manera el cliente puede hacerse a la idea de cómo va a funcionar el sistema final sin tener que construirlo, y así discutirlo con el ingeniero de software.

Naturalmente, en un prototipo no se simularán todas las funcionalidades del sistema pero, si es necesario, se podrán construir otros a medida que la aplicación se vaya desarrollando (ver más abajo cuáles son las etapas para su utilización).

• Un modelo que implementa una función requerida importante. Es el mismo caso que anteriormente pero sin centrarse en la interacción hombre-máquina. Por ejemplo, el modelo podría simular todos los pasos a seguir internamente en el sistema en el acceso a la base de datos de clientes cuando se quiere obtener dinero del cajero, pero sin que realmente se trate de una base de datos real ni de un cliente del banco.

• Un programa real que se adecue en parte al software que se desea desarrollar. Por ejemplo, se puede disponer de una aplicación relacionada con un “cajero automático”, que al presentarla al cliente, permita al analista identificar las necesidades del cliente y por lo tanto los requisitos del software a construir.

Normalmente, el prototipo sirve como mecanismo para identificar los requisitos del software, y su construcción suele llevar las siguientes etapas:

7.5.1 Recolección de requisitos El ingeniero de software y el cliente definen los objetivos globales del software, y aquéllos más específicos que se desean destacar con el prototipo.

7.5.2 Construcción del prototipo.

7.5.3 Diseño rápido. Centrado en los aspectos del software visible al usuario (por ejemplo, interfaz de usuario, entradas y salidas...).

7.5.4 Evaluación del prototipo

Se realiza por el cliente y usuarios, lo que permitirá concretar y refinar los requisitos del software a desarrollar.

41

Ingeniería de Sistemas de Información II - Página 41

7.5.5 Refinamiento del prototipo

Se produce un proceso iterativo en el que el prototipo es refinado para que satisfaga las necesidades del cliente, al tiempo que facilita al ingeniero de software un mejor conocimiento del sistema.

7.5.6 Producto

En la mayoría de los casos este sistema refinado (piloto) hay que desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe planificar con el acuerdo expreso del cliente. Algunos ingenieros del software abogan por desarrollar rápidamente un prototipo que les permita especificar completamente el sistema y obtener más consistentemente el producto final. Sobre el desarrollo rápido de prototipos, pueden realizarse las siguientes observaciones:

• Un prototipo rápido es básicamente una técnica de análisis que permite completar el conjunto de requisitos funcionales de un sistema software.

• Lo deseable es evolucionar el prototipo hasta obtener el producto final, en lugar de deshacerlo y construir un producto final nuevo. Este deseo es válido si del prototipo se puede obtener dicho producto (lo que no suele ser fácil), y su coste es inferior a su reconstrucción. Incluso, se podría recomendar utilizar aquellas técnicas que permitan evolucionar un prototipo hasta el producto final.

• Cualquier aplicación nueva que el ingeniero de software sospeche que su funcionalidad puede presentar el riesgo de no ser aceptable para el usuario o si la interfaz de usuario es importante para el éxito de la aplicación, es una aplicación fuertemente candidata para que se desarrolle un rápido prototipo.

• En un proyecto de prototipado bien planificado, aproximadamente el 50% del esfuerzo de desarrollo, desde su inicio hasta la aprobación final de su funcionalidad, es la contribución del usuario. Los equipos de prototipado están compuestos típicamente por la mitad de usuarios y la otra mitad de desarrolladores software.

• Es habitual tener que tirar la primera versión de cualquier sistema que se desarrolle por primera vez. Por ello, es aconsejable que la primera demostración de un prototipo rápido sea intencionalmente imperfecta, de forma que sea barato de producir y muy fácil de modificar, para que se pueda garantizar que el sistema final que se suministra se ajuste mejor a los requisitos del usuario.

• El prototipado rápido es una solución que “evita el riesgo” en lugar de una solución de riesgo. Así, el prototipado rápido no introduce nuevos riesgos políticos o económicos al proceso de desarrollo de software, sino que reduce significativamente varios factores de riesgo asociados con su desarrollo, como los que se han señalado anteriormente.

• El prototipado rápido es un método normal para el desarrollo de nuevas aplicaciones y llegará a ser más y más evidente que el prototipado rápido produce mejores sistemas y con costes más bajos.

42

Ingeniería de Sistemas de Información II - Página 42

7.6 Ciclo de Vida de desarrollo rápido de aplicaciones

El Desarrollo Rápido de Aplicaciones, abreviado como RAD (del inglés Rapid Application Development) es un modelo de ciclo de vida que enfatiza un desarrollo extremadamente corto. Se trata de una adaptación del modelo tradicional en cascada en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite crear un sistema completamente funcional dentro de periodos cortos de tiempo (entre 60 y 90 días).

7.6.1 Fases

Cuando se utiliza para aplicaciones de sistemas de información, el enfoque RAD tiene las siguientes fases:

7.6.1.1 Modelado de Gestión: se modela el flujo de información entre las funciones de gestión.

7.6.1.2 Modelado de Datos: se refina el flujo de información como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características de cada uno de los objetos y sus relaciones.

7.6.1.3 Modelado del Proceso: se definen las transformaciones (añadir, modificar, suprimir o recuperar) sobre los objetos del modelo de datos para lograr los flujos de información de cada función de gestión.

7.6.1.4 Generación de Aplicaciones: codificación de una función de gestión.

7.6.1.5 Pruebas y entrega: prueba de los componentes y entrega del programa que realiza una función de gestión.

7.6.2 Etapas

La clave del modelo RAD está en los cambios en las etapas de codificación y pruebas:

7.6.2.1 Codificación: El modelo RAD asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, se trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construcción de software.

7.6.2.2 Pruebas: Como se enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce en muchos casos el tiempo de pruebas, aunque se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

43

Ingeniería de Sistemas de Información II - Página 43

Equipo 1 Equipo 2 Equipo 3 ...

60-90 días

El modelo de Ciclo de Vida RAD

El modelo de ciclo de vida RAD se muestra en la Figura 4. Las limitaciones de tiempo impuestas en un proyecto RAD exigen que la aplicación cumpla con el requisito de “ámbito en escalas”, que indique que una aplicación pueda modularse de forma que cada una de las funciones principales pueda completarse en menos de tres meses. Además, cada una de las funciones puede ser afrontadas por un equipo RAD separado e integrarse en un único conjunto.

7.7 Modelo en Espiral

Boehm cerró la década de los 80 publicando en 1988 un modelo de ciclo de vida en espiral que sustituye a la solución en fases del “modelo en cascada” con ciclos de experimentación y aprendizaje.

7.7.1 SectoresEl modelo representado mediante la espiral de la figura define cuatro actividades principales, también llamadas regiones de tareas o sectores:

7.7.1.1 Planificación.

Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.

7.7.1.2 Análisis de riesgo

El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.

7.7.1.3 Ingeniería

En este sector se desarrolla y se valida. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema.

44

Ingeniería de Sistemas de Información II - Página 44

7.7.1.4 Evaluación del cliente

El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completas y, al final, el propio sistema operacional.

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se van construyendo sucesivas versiones del software, cada vez más completas. Durante la primera vuelta de la espiral, en el primer cuadrante (superior izquierdo) se determinan objetivos, alternativas y restricciones; y en el segundo cuadrante (superior derecho) se analizan e identifican los riesgos (¿se dispone de personal?, ¿está preparado?, ¿existe mercado para el producto?, etc.). Si el análisis de los riesgos indica que existe incertidumbre en los requisitos se puede desarrollar un prototipo para su valoración, y también se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos.

En el cuadrante tercero (inferior derecho) se incorporan incrementalmente las etapas del ciclo de vida tradicional en cada ciclo de la espiral.

En el cuarto cuadrante (inferior izquierdo) el cliente evalúa el trabajo de ingeniería de esa espiral y sugiere modificaciones. Basándose en los comentarios del cliente, se produce la siguiente fase de planificación y de análisis de riesgos. En cada bucle alrededor de la espiral, al finalizar el análisis de riesgo, se debe tomar la decisión de seguir adelante o no con el proyecto. Si se sigue avanzando, cada vuelta alrededor de la espiral conduce más hacia fuera, hacia un modelo más completo del sistema, y al final al propio sistema operacional. Cada vuelta requiere más desarrollo de ingeniería de software, y el número de actividades del tercer cuadrante aumenta al alejarse del centro de la espiral.

El paradigma del modelo en espiral es actualmente el enfoque más realista en la ingeniería del software tradicional para sistemas grandes, ya que utiliza un enfoque evolutivo que permite al ingeniero y al cliente entender y reaccionar a los riesgos que se detectan en cada espiral. Utiliza la creación de prototipos como un mecanismo de reducción del riesgo y mantiene el enfoque del ciclo de vida clásico, pero incorporándolo dentro de un proceso iterativo que refleja de forma más realista el mundo real. No se disponen de cifras comparativas de su bondad con respecto a otros ciclos de vida, pero indudablemente sus resultados parecen superiores ya que engloba a los ciclos clásicos y de prototipos.

Planificación Análisis de Riesgos

45

Prototipo 1

Prototipo 2

Prototipo 3

Prototipo OperativoAnálisis de

riesgo

Análisis de riesgo

Análisis de riesgo

AR

Plan de requisitos, Plan de ciclo de vida

Plan de desarrollo

Plan de prueba e

Integración

Concepto de operación

Simulaciones, Modelos, Estándares

Validación de requisitos

Requisitos de Software

Verificación y validación de diseño

Diseño del producto de software

Implementación

Prueba de aceptación

Prueba de Integración

Prueba de Unidad

Codificación

Revisión

Modelo de Espiral de BoehmSommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª ed

Diseño detallado

Ingeniería de Sistemas de Información II - Página 45

7.7.2 Diferencia entre ciclo de vida en cascada y espiral

En el ciclo de vida en cascada y espiral, las diferencias son que en el ciclo de vida en espiral, El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.En cambio el ciclo de vida en cascada El modelo en cascada puro difícilmente se utilice tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños desarrollos de sistemas. En estas circunstancias, el paso de una etapa a otra de las mencionadas sería sin retorno, por ejemplo pasar del Diseño a la Codificación implicaría un diseño exacto y sin errores ni probable modificación o evolución: "codifique lo diseñado que no habrán en absoluto variantes ni errores".

8. Otros ciclos de vida

Evaluación del Cliente Ingeniería

46

Especificación Operativa

Especificación Transform ada Pruebas

Especificación Formal

Transformaciones Pruebas

Registro de desarrollo formal

Ingeniería de Sistemas de Información II - Página 46

Con el fin de completar la enumeración de los modelos de ciclo de vida, se recogen de forma muy resumida dos modelos muy distintos de los anteriores:

8.1 Modelo de especificación operativa

Este modelo fue propuesto por Zave en 1984 y se basa en que los requisitos del sistema se evalúan o ejecutan de una forma que demuestra el comportamiento del sistema. Esta especificación operativa (escrita en un lenguaje de especificación formal que pueda ser interpretado por un ordenador) puede transformarse posteriormente una especificación más orientada a la implementación, que se convierte en el sistema.

Modelo de Ciclo de Vida de Especificación Operativa

8.2 Modelo de transformación

Se utiliza soporta automatizado para realizar una serie de transformaciones que conviertan una especificación en un sistema completo. Este modelo fue propuesto por Blazer en 1981 y también requiere la existencia de una especificación escrita en un lenguaje formal.

Modelo de Ciclo de Vida de Transformación

8.3 Modelo de componentes

Ejecutar y Revisar

Requisitos del Sistem a Sistem a Desarrollado

Requisitos del Sistem a Sistem a Desarrollado

Comparar con requisitos; actualizar según sea necesario.

47

Implementación

Ingeniería de Sistemas de Información II - Página 47

Es un ciclo adecuado para los proyectos en los que se dispone de todos los requerimientos al comienzo, para el desarrollo de un producto con funcionalidades conocidas o para proyectos, que aun siendo muy complejos, se entienden perfectamente desde el principio.

Se evidencia que es un modelo puramente teórico, ya que el usuario rara vez mantiene los requerimientos iniciales y existen muchas posibilidades de que debamos retomar alguna etapa anterior. Pero es mejor no seguir ningún ciclo de vida.

Fue utilizado en medianos y grandes proyectos hasta principios de la década de 1990. Por lo que hoy en día solo se cita como mero ejemplo bibliográfico. No podemos evitar decir que hay aspectos a cuestionar. Se le criticó, principalmente, el retardo en entregar partes del producto, su metodología para la corrección de errores, su obstinación por exigir requerimientos previos completos, y su alta rigidez.A pesar de todo no es erróneo adaptarlo para alguna aplicación en la que el modelo de ciclo lineal no sea del todo adecuado, y el uso de un modelo de gestión más elaborado no lo justifique.

8.4 Modelo tipo Sashimi

Este ciclo de vida es parecido al ciclo de vida en cascada puro, con la diferencia de que en el ciclo de vida en cascada no se pueden solapar las etapas, y en éste sí. Esto suele, en muchos casos, aumentar su eficiencia ya que la retroalimentación entre etapas se encuentra implícitamente en el modelo.

Se hace notar como ventajas la ganancia de calidad en lo que respecta al producto final, la falta de necesidad de una documentación detallada (el ahorro proviene por el solapado de las etapas). Sus desventajas también se refieren al solapamiento de las etapas: es muy difícil gestionar el comienzo y fin de cada etapa y los problemas de comunicación, si aparecen, generan inconsistencias en el proyecto.

Cuando necesitemos realizar una aplicación que compartirá los recursos (CPU, memoria o espacio de almacenamiento) con otras aplicaciones en un ambiente productivo, este modelo de ciclo de vida es una opción muy válida. El solapamiento de sus etapas nos permite en la práctica jugar un poco con el modelo de tres capas ahorrando recursos.

El nombre procede del modelo del estilo japonés de presentar el pescado crudo cortado, en el que los cortes se solapan entre sí.

8.5 Modelo en cascada con subproyectos

48

Análisis del Sistema

Diseño del Sistema

Integración de Subsistemas

Pruebas del Sistema

Ingeniería de Sistemas de Información II - Página 48

Sigue el modelo de ciclo de vida en cascada. Cada una de las cascadas se dividen en subetapas independientes que se pueden desarrollar en paralelo.

La ventaja es que se puede tener más gente trabajando al mismo tiempo, pero la desventaja es que pueden surgir dependencias entre las distintas subetapas que detengan el proyecto temporalmente si no es gestionado de manera correcta.Podemos utilizar este modelo para administrar cualquier proyecto mencionado en los modelos anteriores. Pero cuidando de administrar muy bien los tiempos.

El modelo de ciclo de vida ideal cuando se cuenta con un plantel de programadores numeroso

8.6 Modelo evolutivo

Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento. La práctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto es extremadamente difícil, no solo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de vida evolutivo afronta este problema mediante una iteración de ciclos de requerimientos-desarrollo-evaluación.

Resulta ser un modelo muy útil cuando desconocemos la mayoría de los requerimientos iniciales, o estos requerimientos no están completos.

Análisis del Software

Diseño del Software

Codificación

Pruebas del Software

49

Ingeniería de Sistemas de Información II - Página 49

Además, el pedido de un sector puede influir en los requerimientos del otro. Se hace necesario, entonces, lograr que la aplicación evolucione hasta lograr las satisfacciones de todos los sectores involucrados.

8.7 Modelo iterativo

Este modelo de ciclo de vida se basa en la filosofía de construir incrementando las funcionalidades del programa.Se realiza construyendo por módulos que cumplen las diferentes funciones del sistema. Esto permite ir incrementando gradualmente las capacidades del software. este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar un modulo particular en el caso de que el proyecto sea realizado por un equipo de programadores.Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del programa a construir. Al final de cada ciclo le entregamos una versión al cliente que contiene una nueva funcionalidad. Este ciclo de vida nos permite realizar una entrega al cliente antes de terminar el proyecto. El modelo de ciclo de vida incremental nos genera algunos beneficios tales como los que se describen a continuación:

Construir un sistema pequeño siempre es menos riesgoso que construir un sistema grande.

Como desarrollamos independientemente las funcionalidades, es más fácil relevar los requerimientos del usuario.

Si se detecta un error grave, sólo desechamos la última iteración. No es necesario disponer de los requerimientos de todas las funcionalidades en el

comienzo del proyecto y además facilita la labor del desarrollo.

Este modelo de ciclo de vida no está pensado para cierto tipo de aplicaciones, sino que está orientado a cierto tipo de usuario o cliente. Podremos utilizar este modelo de ciclo de vida para casi cualquier proyecto, pero será verdaderamente útil cuando el usuario necesite entregas rápidas, aunque sean parciales.

Diseño

Codificación

Pruebas

Diseño

Codificación

Pruebas

Diseño

Codificación

Pruebas

50

Ingeniería de Sistemas de Información II - Página 50

9 Ciclos de Vida – Ventajas/Desventajas

Cada modelo de los existentes presenta sus ventajas e inconvenientes según el tipo de desarrollo que se quiera realizar y dependiendo de multitud de factores, puede resultar más adecuado utilizar uno y otro. Seguidamente, se van a resumir las principales características de los modelos de ciclo de vida más importantes:

9.1 Modelo “codificar y corregir”

Ventajas:

• Permite una construcción rápida del sistema. • Es útil para sistemas de un tamaño muy reducido, que no requiera más de dos o tres programadores y que no requiera un mantenimiento posterior. • No pierde tiempo en las etapas de planificación, documentación, control de calidad... • Cualquiera, sin preparación técnica, lo puede utilizar.

Desventajas:

• Carece de cualquier control y gestión del proceso. • No dispone de las fases necesarias en todo proyecto de software: especificaciones, diseño... • Se dificulta la corrección de errores y el mantenimiento al carecer de una documentación del proceso adecuada.• No proporciona medios de evaluación ni de prevención de riesgos. • Resulta peligroso para proyectos grandes.

9.2 Modelo en “cascada”

Ventajas:

• Es un modelo sencillo y disciplinado. • Es fácil aprender a utilizarlo y comprender su funcionamiento. • Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa. • Ha sido muy usado y, por tanto, está ampliamente contrastado. • Ayuda a detectar errores en las primeras etapas a bajo costo. • Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas.

Desventajas:

• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida. • Es difícil que el cliente exponga explícitamente todos los requisitos al principio. • El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida. • No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo.

51

Ingeniería de Sistemas de Información II - Página 51

• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones. • El producto final obtenido puede que no refleje todos los requisitos del usuario .

9.3 Modelo en “V”

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos. • Es un modelo sencillo y de fácil aprendizaje. • Hace explícito parte de la iteración y trabajo que hay que revisar. • Especifica bien los roles de los distintos tipos de pruebas a realizar. • Involucra al usuario en las pruebas.

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos. • El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida. • Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas. • El producto final obtenido puede que no refleje todos los requisitos del usuario.

9.4 Modelo de “Prototipos”

Ventajas:

• Permite la construcción del sistema con requisitos poco claros o cambiantes. • El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo. • Se pueden introducir cambios en las funcionalidades del sistema en cualquier momento. • Involucra al usuario en la evaluación de la interfaz de usuario. • Se reduce el riesgo y la incertidumbre sobre el desarrollo. • Genera signos visibles de progreso, que se utilizan cuando existe una demanda en la velocidad del desarrollo. • Permite entender bien el problema antes de la implementación final.

Desventajas:

• El cliente puede quedar convencido con las primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria. • Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos. • Requiere un tiempo adicional para definir adecuadamente el sistema. • No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar. • Si un prototipo fracasa, el coste del proyecto puede resultar muy caro.

52

Ingeniería de Sistemas de Información II - Página 52

9.5 Modelo “Desarrollo Rápido de Aplicaciones”

Ventajas:

• Enfatiza ciclos de desarrollo extremadamente cortos. • Tiene las ventajas del modelo clásico. • Se asegura de que el producto entregado cumple las necesidades del cliente.

Desventajas:

• Solo se puede aplicar si el sistema se puede modularizar de forma que permita completarse cada una de las funciones principales en menos de tres meses. • Para proyectos grandes puede requerir muchos equipos de trabajo distintos. • Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias. • No resulta adecuado cuando los riesgos técnicos son elevados. • Se pueden tener problemas con la aceptación del prototipo.

9.6 Modelo en “espiral”

Ventajas:

• Incorpora muchas de las ventajas de los otros ciclos de vida. • Conjuga la naturaleza iterativa de los prototipos con los aspectos controlados y sistemáticos del modelo clásico.• Proporciona el potencial para el desarrollo rápido de versiones incrementales. • Puede adaptarse y aplicarse a lo largo de la vida del software. • Es un enfoque realista del desarrollo del software. • Permite aplicar el enfoque de construcción de prototipos en cualquier momento para reducir riesgos. • Reduce los riesgos antes de que se conviertan en problemáticos. • Controla muy bien los riesgos y mientras más iteraciones se realicen, menos riesgos habrá. • Monitoriza y controla los riesgos continuamente.

Desventajas:

• Puede resultar difícil convencer a algunos clientes de que el enfoque evolutivo es controlable. • Solo resulta aplicable para proyectos de gran tamaño. • Supone una carga de trabajo adicional, no presente en otros ciclos de vida. • Requiere una considerable habilidad para la evaluación y resolución del riesgo, y se basa en esta habilidad para el éxito. • Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. • Es bastante complicado de realizar y su complejidad puede incrementarse hasta hacerlo impracticable. • El modelo no se ha utilizado tanto como otros, por lo que tendrán que pasar años antes de que determine con certeza la eficacia de este modelo.

53

Ingeniería de Sistemas de Información II - Página 53

10. Conclusión

Luego de ver algunos de los modelos de ciclo de vida más utilizados surge la pregunta con la respuesta más codiciada: ¿qué modelo de ciclo de vida elegir? Sabemos que ninguno predomina sobre los otros. Por ello, debemos elegir el modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar, para guiarnos en nuestra elección, la complejidad del problema, el tiempo que disponemos para hacer la entrega final, o si el usuario o cliente desea entregas parciales, la comunicación que existe entre el equipo de desarrollo y el usuario y, por último, qué certeza (o incertidumbre) tenemos de que los requerimientos dados por el usuario son correctos y completos.

Independientemente del paradigma que se utilice, del área de aplicación, y del tamaño y la complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de fases genéricas, existentes en todos los paradigmas. Estas fases son la definición, el desarrollo y el mantenimiento.

54

Ingeniería de Sistemas de Información II - Página 54

11. Referencias bibliográficas

[1] Booch, Grady. Object-Oriented Analysis and Design. Second Edition. Benjamin/Cummings, Redwood: 1994.

[2] Jacobson, Ivar, Grady Booch, and James Rumbaugh. El Proceso Unificado de Desarrollo de Software. México: Addison-Wesley, 1999.

[3] Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of Software Architecture". IEEE Software, Institute of Electrical and Electronics Engineers. November 1995, pp. 42-50.

[4] Larman, Craig. UML y Patrones, Introducción al análisis y diseño orientado a objetos. México: Prentice Hall, 1999.

[5] Martin, Robert C. "Design Principles and Design Patterns". Objectmentor

[6] Muller, Pierre-Alain. Modèlisation Object avec UML. Paris: Eyrolles, 1997.

[7] Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures. Redmond: Microsoft Press, 1999.

[8] Fernández Aramayo, David Ricardo. Arquitectura de Software. Universidad Tecmilenio, ITESM

[9] Zapata Sanchez, Andres felipe. Arquitectura de Software www.fi.uba.ar

[10] Shaw, M., & Garlan, D. (1996). Introduction to Software Architectures. New perspectives on an emerging discipline. Prentice Hall.

[11] Whitten, J., Bentley, L., & Dittman, K. (2001) Systems Analysis and Design Methods.

[12] Grady, R., & Caswell, D. (1987) Software Metrics: Establishing a company-Wide

[13] Grimán, A. (2000) Propuesta Metodológica Sistémica para la Gestión del Conocimiento en las Organizaciones.

[14] Hofmeister, C.; Nord, R.; Soni D. (2000). Applied Software Architecture. Addison Wesley.

[15] Jain, R. (1991). The Art of Computer System Performance Analysis. Techniques for Experimental Design, Measurments, Simulation, and Modeling. John Wiley & Sons.

[16] Larman, C. (1999). UML y Patrones: Introducción al análisis y diseño orientado a objetos. Prentice-Hall Hispanomericana.

55

Ingeniería de Sistemas de Información II - Página 55

12. Referencias Web

[1] Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid, “Análisis y selección de estrategias de desarrollo de software” [En línea], Madrid España [Consulta: Mayo de 2006], http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/estrategias.pdf

[2] Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>

[3] Tesis doctorales en Zarza, “Ingeniería de Software” [En línea], España [Consulta: Mayo de 2006], <http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102-102210//05Capitulo05.pdf>

[4] Mundo Geek, “Ciclos de vida del software” [En línea], [Consulta: Mayo de 2006], <http://mundogeek.net/archivos/2004/05/20>

[5] Wikipedia Foundation Inc, EUA Desarrollo en Cascada [En línea], St. Petersburg [Consulta: Mayo de 2006], <http://es.wikipedia.org/wiki/Modelo_en_cascada>

[6] Instituto Tecnológico de la paz, “Análisis y diseño de sistemas Modelo de Espiral” [En línea], México [Consulta: Mayo de 2006], <http://www.itlp.edu.mx/publica/tutoriales/analisis/index.htm>

[7] Copyright © Programación en Castellano, [En línea], España [Consulta: Mayo de 2006], <http://www.programacion.com/blogs/46_aprendiendostruts>

[8] Zavala R. 2000. Diseño de un Sistema de Información Geográfica sobre Internet. Tesis de Maestría en Ciencias de la Computación. Universidad Autónoma Metropolitana-Azcapotzalco., “La Ingeniería del Software” [En línea], [Consulta: Abril de 2006], México, D.F. <http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#fig2>

[9] Juan Pavón Maestras, Universidad Complutense de Madrid, “El proceso unificado” [En línea], Madrid España [Consulta: Abril de 2006], <http://www.fdi.ucm.es/profesor/jpavon/is2/03ProcesoUnificado.pdf>

[10] Carlos Reynoso, Universidad de Buenos Aires, Arquitectura de Software [En línea] Buenos Aires Argentina [Consulta: Mayo de 2006], <http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/heterodox.asp>

[11] Grupo de Investigación Kybele, Universidad Rey Juan Carlos, “Fases del proceso unificado” [En linea], Madrid España [Consulta: Abril de 2006], <http://kybele.escet.urjc.es/Documentos/ISI/Fases%20del%20Proceso%20Unificado.pdf>

56

Ingeniería de Sistemas de Información II - Página 56

[12] Wikipedia Foundation Inc, EUA “Proceso Unificado de Rational” [En línea], St. Petersburg [Consulta: Abril de 2006],http://es.wikipedia.org/wiki/RUP

[13] Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA [Consulta: Mayo de 2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>

[14] Gustavo Adolfo Ramírez González, Universidad del Caucan Popayán, “Proceso Unificado para desarrollo de Software”, Colombia [Consulta: Junio de 2006], <http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf>

[15] A.U.S. GustavoTorossi, “El Proceso Unificado de Desarrollo de Software” [En línea], Provincia de Chaco Republica de Argentina [Consulta: Junio de 2006] <http://www.chaco.gov.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.pdf>

[16] Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006], <http://www.jeckle.de/files/uniproc.pdf>

[17] Carriere, J., Kazman, R., Woods, S. (2000). Toward a Discipline of Scenariobased Architectural Engineering. Software Engineering Institute, Carnegie Mellon University. Obtenido el 09-05-2002 de: http://www.sei.cmu.edu/staff/rkazman/annals-scenario.pdf

[18] Clements, P. (1996). A survey of Architecture Description Languages. Software Engineering Institute, Carnegie Mellon University. Obtenido el 16-07-2002 de: http://www.sei.cmu.edu/publications/articles/survey-adl.html

[19] Dromey, G. (1996). Cornering the Chimera. IEEE Software. Vol 13, Nro. 1. Obtenido el 15-08-2002 de: http://www.computer.org/software/so1996/s1033abs.htm