Evolución Histórica

La IS aparece a finales de los años sesenta y principios de los setenta, se puede considerar todavía un disciplina muy nueva, sobre todo si la comparamos con otros tipos de ingenierías.

La principal característica de los métodos de análisis y diseño estructurados es que diferencian claramente las técnicas para la especificación de los procesos (funciones) del software de las técnicas para la especificación de la información (los datos) que tiene que gestionar el software. No hay una integración entre ambas vertientes.

A finales de los ochenta y principios de los noventa, surgieron los métodos de análisis y diseño orientados a objetos. 

Estos métodos intentan aplicar los conceptos (y las ventajas) de la orientación a objetos ya en las fases de análisis y diseño de la aplicación, por lo que se consigue una transición mucho más suave entre las diferentes etapas del desarrollo. 

Algunos de los métodos orientados a objetos más conocidos son: 

• OOD ( Object-Oriented Design ; G. Booch)

• OMT ( Object Modeling Technique , J. Rumbaugh) 
• OOSE ( Object-Oriented Software Engineering ; I. Jacobson). 

Posteriormente, todos estos métodos (y muchos otros) se han diluido dentro del UML ( Unified Modeling Language ), al cual dedicaremos toda una sección en este mismo capítulo. La primera versión del UML apareció en 1997. Desde entonces se han ido generado diferentes versiones hasta llegar a la versión 2.0 (finales de 2004), que es la versión que se utiliza actualmente. El UML es una especificación estándar del OMG.

El Unified Process 

El UP nace en el año 1998 a partir de las aportaciones de G. Booch y J. Rumbaugh al método de desarrollo Objectory creado por I. Jacobson. Más que un único método de desarrollo, el UP pretende ser un marco de trabajo ( framework en inglés) general que se pueda especializar según las necesidades de cada empresa (los métodos adhoc que comentábamos antes). 

Sus principales características son: 

– Es un método dirigido por los requisitos del sistema, expresados en la forma de casos de uso (se dice que el proceso es use-case driven ). Cada caso de uso representa una de las funcionalidades del sistema que el usuario necesita (y que, por lo tanto, el software final tendrá que implementar). Partiendo de esta especificación inicial de los casos de uso, se lleva a cabo todas las demás actividades de desarrollo. 

– Es iterativo e incremental. El proyecto no se desarrolla todo de golpe sino que el desarrollo se divide en una serie de iteraciones, en la que cada iteración genera (o amplía) una parte del software final (que, por lo tanto, va creciendo de forma incremental, primero se crea una primera versión del software con una sola funcionalidad, después se añade una segunda y así sucesivamente). En cada iteración, los desarrolladores tienen que escoger cuáles son los requisitos (casos de uso) que quieren tratar dentro de la iteración. Al final de ésta, se habrá generado la parte del sistema que implementa los casos de uso incluidos dentro de la iteración.

– Reconoce la importancia de definir la arquitectura de software. El UP defiende que los arquitectos estén plenamente involucrados en todas las fases de desarrollo del proyecto. 

– Uso de un lenguaje de modelización visual, necesario para facilitar la comunicación entre los miembros del proyecto. Abogan por el uso del UML. 

– Calidad del software generado. La calidad se contempla como una parte del mismo método y no como una etapa al final del desarrollo. 

– Integración de la gestión, la configuración y los cambios en el proyecto dentro de las iteraciones. Proponen tener en cuenta estos aspectos en cada una de las iteraciones.

Según sus propios impulsores, el UML es “un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos (componentes) de sistemas que involucran una gran cantidad de software”. El UML es un lenguaje muy expresivo y que permite definir todas las vistas (perspectivas) necesarias para desarrollar software (la vista de los datos que hay que gestionar, la vista del comportamiento del software, la vista de la arquitectura), por tanto cubre la especificación de todas las decisiones de análisis, diseño e implementación necesarios.

Además, el mismo lenguaje también define un mecanismo de extensión que permite adaptar el UML a entornos con necesidades muy específicas.