Unidad 5 Modelo Desarrollo Software

Unidad 5.- Modelos de desarrollo de software.

Modelos prescriptivos.

Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para el (los) proceso(s) de software que adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicación, planeación, modelado, construcción y desarrollo. El modelo en cascada.

Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable,

El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un

enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.

El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia [HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están:

Modelos de desarrollo de software

MC Genaro Alberto Gómez Chi Página 2 de 18

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el

modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera

explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.

3. El cliente debe tener paciencia. Una versión que funcione de los programas

estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa.

En un análisis interesante de proyectos reales, Bradac [BRA94] concluyó que la

naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial.

En la actualidad, el trabajo del software está acelerado y sujeto a una cadena

infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal.

Modelos de proceso incrementales.

En muchas situaciones los requisitos iniciales del software están bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado para producir el software en forma incremental. El modelo incremental.

El modelo incrementa! combina elementos del modelo en cascada aplicado en forma iterativa. Como se muestra en la figura, el modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier



incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante.

A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo.

El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones “incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo.

El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitiría la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados. El modelo DRA.

El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido



mediante un enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 días) [MAR91].

Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases —modelado de negocios, modelado de datos y modelado del proceso— y establece representaciones del diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empleo de componentes de software existente y la aplicación de la generación automática de código. Por último, el despliegue establece una base para las iteraciones subsecuentes, si éstas son necesarias [KER94].

El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones de tiempo impuestas sobre un proyecto DRA exigen un "ámbito de escalas" [KER94]. Si una aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de DRA por separado, para después integrarlas y formar un todo. Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:

1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en número correcto de equipos DRA.

2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarán.

3) Si un sistema no se puede modular en forma apropiada, la construcción de los componentes necesarios para el DRA será problemática.

4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar.

5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).



Modelos de proceso evolutivos. El software, como todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de los negocios y productos a menudo cambian conforme se realiza el desarrollo; por lo tanto, la ruta lineal que conduce a un producto final no será real; las estrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, por lo que debe presentar una versión limitada para liberar la presión competitiva y de negocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, pero todavía se deben definir los detalles de las extensiones del producto o sistema. En estas y otras situaciones similares, los ingenieros de software necesitan un modelo de proceso que haya sido diseñado de manera explicita para incluir un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software. Construcción de prototipos. A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. En estas, y muchas otras situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. A pesar de que la construcción de prototipos se puede utilizar como un modelo de proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos en estos apuntes. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cúal será el resultado de la construcción cuando los requisitos estén satisfechos. El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el cliente/usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para



satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer.

De manera ideal, el prototipo debería servir como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta emplear los fragmentos del programa ya existentes o aplica herramientas (como generadores de informes, administradores de ventanas, etcétera) que permiten producir programas de trabajo con rapidez.

Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito descrito? Brooks [BRO75] ofrece una respuesta:

En la mayoría de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o reúna las tres características a la vez. No existe otra opción que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construir una revisión rediseñada en la que se resuelvan estos problemas... Cuando se aplica un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema in-servible y que sea necesario desechar, porque incluso la mejor planeación no es omnisciente como para que el sistema esté perfecto desde la primera vez. Por lo tanto, la pregunta de la administración no es si debe construirse un sistema piloto y desecharlo. Esto tendrá que hacerse. La única pregunta es si se planea la construcción de un desechable o se promete entregárselo a los clientes.

El prototipo puede servir como "primer sistema", el que Brooks recomienda dese-

char. Pero ésta tal vez sea una visión idealizada. Es verdad que a los clientes y los desarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos también se torna problemática por las siguientes razones:

1. El cliente ve lo que parece una versión en funcionamiento del software, sin saber que el prototipo está unido "con chicle y cable para embalaje", que por la prisa de hacerlo funcionar no se ha considerado la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de calidad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes” para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gestión del desarrollo de software sea muy lenta.

2. A menudo, el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo o lenguaje de programación inadecuado sólo porque está disponible y es conocido; se puede implementar un algoritmo ineficiente sólo para mostrar capacidad. Después de un tiempo, el desarrollador quizá se familiarice con estas selecciones y olvide las razones por las que son inapropiadas. La selección menos ideal ahora se convierte en una parte integral del sistema.

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser

un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya y sirva como un mecanismo para la definición de requisitos, en que se descarte, al menos en parte, y en que después se desarrolle el software real con un enfoque hacia la calidad.



El modelo en espiral.

El modelo en espiral, que Boehm [BOE88] propuso originalmente, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Proporciona el material para el desarrollo rápido de versiones increméntales del software. Boehm [BOE01] describe este modelo de la siguiente manera:

El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para el crecimiento incrementa! del grado de definición e implementación de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

Cuando se aplica el modelo en espiral, el software se desarrolla en una serie dé

entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas del sistema desarrollado.

Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniería del software. Para propósitos ilustrativos se aprovechan las actividades genéricas del marco de trabajo expuestas páginas atrás.

Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral que se presenta en la figura. Cuando comienza este proceso evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral que tiene una dirección en el sentido del movimiento de las manecillas del reloj, y que se inicia desde el centro. El riesgo es un factor considerado en cada revolución. Los puntos de fijación —una combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral— se consideran para cada paso evolutivo.

El primer circuito alrededor de la espiral quizá genere el desarrollo de una espe-

cificación del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación derivada de la relación con el cliente después de la entrega. Además, el administrador del proyecto ajusta el número de iteraciones planeado que se requiere para completar el software.

A diferencia de otros modelos de proceso que terminan cuando se entrega el soft-

ware, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podría representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y



continúa por múltiples iteraciones hasta que el desarrollo del concepto esté completo. Si el concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un circuito alrededor de la espiral se podría emplear para representar un "proyecto de mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso está inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto).

El modelo en espiral es un enfoque realista para el desarrollo de software y de sis-

temas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea la construcción de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma más importante, permite al desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más verídica el mundo real. El modelo en espiral exige una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelvan problemáticos.

Así como otros paradigmas, el modelo en espiral no es una panacea. Es difícil

convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable, ya que se requiere una habilidad considerable para evaluar el riesgo y se confía en dicha habilidad para obtener el éxito. Si un riesgo importante no se descubre y administra, sin duda surgirán problemas. El modelo de desarrollo concurrente.

El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se representa en forma esquemática como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la actividad de modelado, definida para el modelo en espiral, se lleva a cabo al invocar las acciones siguientes: construcción de prototipos o modelado y especi-ficación del análisis y diseño.

En la figura se proporciona un esquema de una tarea de ingeniería de software relacionada con la actividad de modelado para el modelo de proceso concurrente. La actividad —modelado— puede estar en alguno de los estados destacados mencionados antes en cualquier momento dado. De forma similar, otras actividades o tareas (por ejemplo, la comunicación y la construcción) se representan de una manera análoga. Todas las actividades existen de forma concurrente, pero se encuentran en



diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicación (no se muestra en la figura) ha completado su primera iteración y existe en el estado de en espera de cambios. La actividad de modelado que existió en el estado ninguno mientras se realizaba la comunicación inicial, ahora realiza una transición al estado en desarrollo. Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado se mueve del estado en desarrollo al estado de en espera de cambios.

El modelo de proceso concurrente define una serie de eventos que dispararán

transiciones de estado a estado para cada una de las actividades, acciones o tareas de la ingeniería del software. Por ejemplo, durante los primeros estados del diseño (una acción de la ingeniería del software que ocurre en el curso de la actividad de modelación) no se detecta una inconsistencia en el modelo del análisis. Esto genera el evento corrección del análisis del modelo, el cual disparará la creación del análisis desde el estado realizado hasta el estado de en espera de cambios.

El modelo de proceso concurrente se aplica a todos los tipos de desarrollo de soft-ware y proporciona una visión exacta del estado actual de un proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniería del software a una secuencia de eventos, define una red de actividades. Cada actividad, acción o tarea en la red existe de manera simultánea con otras actividades, acciones o tareas. Los eventos generados en un punto de la red del proceso disparan transiciones entre los estados. Un comentario final sobre los procesos evolutivos. Ya se ha detectado que al software de computadoras moderno lo caracteriza el cambio continuo, los tiempos de entrega muy reducidos, y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado. Los modelos evolutivos de procesos se concibieron para abocarse a estos aspectos y, además, como modelos de proceso de clase general. Estos modelos también tienen debilidades, las cuales se resumen a continuación:

A pesar de los incuestionables beneficios de los procesos evolutivos de software, se tienen algunas dificultades con este tipo de procesos. La primera dificultad es que la construcción de prototipos [y otros procesos evolutivos más elaborados] implican un problema para la planeación del proyecto debido al número incierto de ciclos requeridos para construir el producto. La mayoría de las técnicas de gestión y estimación de proyectos se basa en configuraciones lineales de las actividades, por lo que éstas no se ajustan por completo.

La segunda dificultad es que los procesos evolutivos de software no establecen la velocidad máxima de la evolución. Si las evoluciones suceden demasiado rápido, sin un periodo de relajación, existe la certidumbre de que el proceso caerá en el caos. Por otro lado, si la velocidad es demasiado lenta, se podría afectar la productividad.

Una tercera dificultad es que los procesos de software se deben enfocar en la flexibilidad y extensibilidad en vez de en la alta calidad. Esta afirmación suena atemorizante. Sin embargo, se debe priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo se extiende para alcanzar una alta calidad, se produciría un retraso en la entrega del producto, la cual se haría cuando el nicho de



oportunidad ya haya desaparecido. Este cambio de paradigma lo impone la competencia en el borde del caos.

En efecto, un proceso de software que se enfoca en la flexibilidad y la velocidad del

desarrollo por encima de la alta calidad suena atemorizante. Aun así, esta idea la ha propuesto cierto número de respetados expertos en la ingeniería del software (por ejemplo, [YOU95], [BAC97]).

El propósito de los modelos evolutivos es desarrollar software de alta calidad de una manera iterativa o incremental. Sin embargo, es posible aplicar un proceso evolutivo para destacar la flexibilidad, extensibilidad y velocidad del desarrollo. El reto para los equipos de software y sus dirigentes es establecer un balance apropiado entre estos parámetros críticos del proyecto y el producto, y el producto y la satisfacción del cliente (el arbitro final de la calidad del software).

Modelos especializados de proceso.

Los modelos especializados de proceso adoptan muchas de las características de uno o más de los modelos convencionales presentados en las secciones anteriores. Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido un enfoque de ingeniería del software definido de una manera muy estrecha. Desarrollo basado en componentes.

Los nuevos componentes de software comerciales (NCSC), desarrollados por vendedores que los ofrecen como productos, se pueden emplear cuando el software está en proceso de construcción. Estos componentes proporcionan funcionalidad dirigida con interfaces bien definidas que permiten que el componente se integre en el software.

El modelo de desarrollo basado en componentes (DBC) incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza [NIE92] y exige un enfoque iterativo para la creación del software. Sin embargo, el modelo configura aplicaciones a partir de componentes de software empaquetados en forma previa.

Las actividades de modelado y construcción comienzan con la identificación de los componentes candidatos. Estos componentes se pueden diseñar como módulos de software convencionales o como clases o paquetes de clases orientados a objetos. Sin importar la tecnología que se aplique en la creación de los componentes, el modelo de desarrollo basado en componentes incorpora los siguientes pasos (implementados mediante un enfoque evolutivo):

Los productos basados en componentes disponibles se investigan y evalúan para el

dominio de aplicación en cuestión. Se consideran los aspectos de integración de componentes. Se diseña una arquitectura de software para adaptar los componentes. Los componentes se integran en la arquitectura. Se realizan pruebas detalladas para asegurar una funcionalidad apropiada.



El modelo de desarrollo basado en componentes conduce a la reutilización de software, la cual proporciona beneficios a los ingenieros de software. Con base en estudios de reutilización, QSM Associates, Inc. informa que el ensamblaje de componentes conduce a una reducción de 70 por ciento del ciclo de desarrollo; 84 por ciento del costo del proyecto y un índice de productividad de 26.2, comparado con una norma de la industria de 16.9 [YOU94]. A pesar de que estos resultados están en función de la robustez de la biblioteca de componentes, no hay duda de que el modelo de desarrollo basado en componentes proporciona ventajas significativas para los ingenieros de software. El modelo de métodos formales.

El modelo de métodos formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora al aplicar una notación matemática rigurosa. Algunas organizaciones de desarrollo del software aplican en la actualidad una variación de este enfoque, llamado ingeniería del software de sala limpia [MIL87, DYE92].

Cuando se utilizan métodos formales durante el desarrollo, éstos proporcionan un

mecanismo para eliminar muchos de los problemas difíciles de superar con otros paradigmas de la ingeniería del software. La ambigüedad, el estado incompleto y la inconsistencia se descubren y corrigen con mayor facilidad —no mediante una revisión ad hoc, sino a través de la aplicación de un análisis matemático—. Cuando los métodos formales se utilizan durante el diseño sirven como base para la verificación de programas y, por consiguiente, permiten que el ingeniero de software descubra y corrija errores que de otra manera podrían no haberse detectado.

A pesar de que aún no existe un enfoque establecido, los modelos de métodos

formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha mencionado una gran preocupación acerca de su aplicabilidad en su entorno de gestión: En la actualidad, el desarrollo de modelos formales es muy caro y consume mucho

tiempo. Se requiere una capacitación detallada, debido a que pocos responsables del

desarrollo de software cuentan con los antecedentes necesarios para aplicar métodos formales.

Es difícil la utilización de estos modelos como un mecanismo de comunicación con clientes que no tienen muchos conocimientos técnicos.

No obstante, tal vez el enfoque a través de métodos formales haya ganado adeptos

entre los desarrolladores de software que deben construir sistemas de alta seguridad (por ejemplo, en los campos de la aeronáutica y de los dispositivos médicos), y entre los desarrolladores que padecen severas penurias económicas cuando aparecen errores en el software.



Desarrollo del software orientado a aspectos.

Sin importar el proceso de software que se elija, los constructores de software complejo implementan de manera invariable un conjunto específico de características, funciones y contenido de información. Estas características específicas del software se modelan como componentes (por ejemplo, clases orientadas a objetos) y después se construyen dentro del contexto de una arquitectura de sistema. Conforme los sistemas basados en computadora se vuelven más elaborados (y complejos), ciertos "intereses" —propiedades requeridas para el cliente o áreas de interés técnico— abarcan toda la arquitectura. Algunos intereses son propiedades de alto nivel de un sistema (por ejemplo, seguridad, falta de tolerancia). Otros intereses afectan las funciones (como la aplicación de reglas de negocios), mientras que otros son sistémicos (como la sincronización de tareas o la gestión de memoria).

Cuando los intereses se relacionan con múltiples funciones, características e información del sistema, con frecuencia se denominan intereses generales. Los requerimientos de aspectos definen estos intereses generales que ejercen un impacto a través de la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), referido con frecuencia como programación orientada a aspectos (POA), es un paradigma de la ingeniería del software relativamente nuevo que proporciona un proceso y enfoque metodológico para definir, especificar, diseñar y construir aspectos "mecanismos más allá de subrutinas y legados para localizar la expresión de un interés general" [ELR01].

Grundy [GRU02] explica con mayor profundidad los aspectos en el contexto de lo que él llama ingeniería de componentes orientada a aspectos [ICOA]:

La ICOA utiliza un concepto de capas horizontales a través de componentes de software descompuestos en forma vertical, llamados "aspectos", para caracterizar propiedades generales de los componentes, los cuales pueden ser funcionales y no funcionales. Por lo general, los aspectos sistémicos incluyen interfases con el usuario, trabajo en colaboración, distribución, persistencia, gestión de la memoria, procesamiento de transiciones, seguridad, integridad y otros. Los componentes pueden proporcionar o requerir uno o más "detalles de aspecto" relacionados con un aspecto particular, como un mecanismo de visión, acceso extensible y tipo de interfase (aspectos de la interfase con el usuario); generación, transportación y recepción de eventos (aspectos de distribución); almacenamiento/recuperación e indización de datos (aspectos de persistencia); autentificación, codificación y derechos de acceso (aspectos de seguridad); atomicidad de la transacción, control de concurrencia y control del transporte (aspectos de transacción), y así sucesivamente. Cada detalle de aspecto tiene una serie de propiedades en relación con características personales y no funcionales del detalle.

Hasta ahora no se ha concretado un proceso orientado a aspectos diferente. Sin

embargo, es probable que tal proceso adopte características de los modelos de proceso en espiral y concurrente. La naturaleza evolutiva del modelo en espiral es apropiada cuando se identifican y construyen los aspectos. La naturaleza paralela del desarrollo concurrente es esencial porque los aspectos se desarrollan de manera independiente de los componentes del software localizados y, aun así, los aspectos tienen un impacto directo sobre estos componentes. Por lo tanto, resulta esencial implementar una comunicación asincrónica entre las actividades del proceso de software aplicadas al desarrollo y la construcción de aspectos y componentes.



El proceso unificado.

En su libro fundamental sobre el proceso unificado, Ivar Jacobson, Grady Booch y James Rumbaugh [JAC99] exponen la necesidad de un proceso de software "guiado por los casos de uso, de arquitectura céntrica, iterativo e incremental". Estos autores establecen:

En la actualidad la tendencia en el software se encamina a sistemas mayores y complejos. Eso se debe en parte al hecho de que las computadoras se volvían más poderosas cada año, lo que alentaba que los usuarios esperaran más de ellas. Esta tendencia también la impulsó el uso expandido de Internet para el intercambio de todo tipo de información. Nuestro apetito por un software cada vez más complejo crece en la medida en la que aprendemos cómo puede mejorarse un producto desde que sale uno hasta que llega el otro. Necesitamos un software que se adapte mejor a nuestras necesidades, pero que, a su vez, haga el software más complejo. En resumen, queremos más.

De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los

mejores rasgos y características de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo ágil de software. El proceso unificado reconoce la importancia de la comunicación con el cliente y los métodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso). El PU enfatiza el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilización" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno.

En esta sección se presenta una visión general de los elementos clave del proceso unificado. Una breve historia.

Durante la década de 1980 y al principio de la década siguiente, los métodos y lenguajes de programación orientados a objetos (OO) obtuvieron una amplia difusión entre la comunidad de la ingeniería del software. Durante el mismo periodo se propuso una amplia variedad de análisis y diseño orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propósito general (similar a los modelos evolutivos presentados en este capítulo). Al igual que la mayoría de los paradigmas "nuevos" para la ingeniería del software, los seguidores de cada uno de los métodos de AOO y DOO argumentaban acerca de cuál de ellos era el mejor, pero ningún método o lenguaje dominó la escena de la ingeniería del software.

Al principio de la década de 1990, James Rumbaugh [RUM91], Grady Booch

[BOO94] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "método unificado" que combinaría las mejores características de cada uno de sus métodos individuales y adoptaría características adicionales que propusieran otros expertos (por ejemplo, [WIR90]) en el campo OO. El resultado fue el lenguaje de modelado unificado (UML, por sus siglas en inglés) —que contiene una notación robusta para el modelado y el desarrollo de sistemas OO—. Para 1997, el UML se convirtió en un estándar de la industria para el desarrollo de software orientado a objetos. Al mismo tiempo,



Rational Corporation y otras firmas desarrollaron herramientas automáticas para apoyar los métodos del UML.

El UML proporciona la tecnología necesaria para apoyar la práctica de la ingeniería

del software orientada a objetos, pero no provee el marco de trabajo del proceso que guíe a los equipos en la aplicación de la tecnología. En los años siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniería del software orientada a objetos, mediante la utilización del UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. El modelo iterativo e incremental que propone el PU puede y debe adaptarse para satisfacer necesidades de proyecto específicas.

Como consecuencia de la aplicación del UML se puede producir un arreglo de productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, éstos los reducen los ingenieros de software para lograr que el desarrollo sea más ágil y reactivo ante el cambio. Fases del proceso unificado.

Se han analizado cinco actividades genéricas del marco de trabajo y se ha explicado que éstas se pueden aplicar para describir cualquier modelo de proceso del software. El proceso unificado no es la excepción. En la siguiente figura se muestran las "fases" del proceso unificado (PU).

La fase de inicio del PU abarca la comunicación con el cliente y las actividades de planeación. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a través de un conjunto preliminar de casos de uso que describen cuáles características y fun-ciones son deseables para cada clase importante de usuarios. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona, una máquina, otro sistema) cuando éste interactúa con el software. Los casos de uso ayudan a identificar el ámbito del proyecto y proporcionan una base para la planeación de éste.

En este punto, la arquitectura no es más que un esquema tentativo de los

subsistemas más importantes y de las funciones y características que los forman. Después, la arquitectura se refinará y expandirá en un conjunto de modelos que representarán visiones diferentes del sistema. La planeación identifica recursos, evalúa los



riesgos importantes, define un itinerario y establece una base para las fases que se aplicarán conforme se desarrolle el incremento del software.

La fase de elaboración abarca la comunicación con el cliente y las actividades de

modelado del modelo genérico del proceso. La elaboración refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de análisis, el modelo de diseño, el modelo de implementación y el modelo de despliegue. En algunos casos, la elaboración crea una "línea de base arquitectónica ejecutable" [ARL02] que representa un sistema ejecutable en su "primer corte". La línea de base arquitectónica demuestra la viabilidad de la arquitectura, pero no proporciona todas las características y funciones necesarias para utilizar el sistema. Además, el plan se, revisa de manera cuidadosa al término de la fase de elaboración para asegurar que el ámbito, los riesgos y los datos entregados aún son razonables. Las modificaciones al plan se deben hacer en este momento.

La fase de construcción del PU es idéntica a la actividad de construcción definida para el proceso genérico del software. Si se utiliza el modelo arquitectónico como entrada, la fase de construcción desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de análisis y diseño iniciados durante la fase de elaboración se completen para reflejar la versión final del incremento del software. Todas las características y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en código fuente. Conforme los componentes están en proceso de implementación, se diseñan y ejecutan pruebas de unidad para cada uno de ellos. Además, se realizan las actividades de integración (ensamblaje de componentes y pruebas de integración). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptación que se ejecutan antes del inicio de la siguiente fase del PU.

La fase de transición del PU abarca las últimas etapas de la actividad genérica de

construcción y la primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (por ejemplo, manuales del usuario, guías de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición, el incremento de software se convierte en un lanzamiento de software utilizable.

La fase de producción del PU coincide con la actividad de despliegue del proceso

genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben y evalúan los informes de defectos y los requerimientos de cambios.

Es probable que mientras se realizan las fases de construcción, transición y

producción ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas.

A lo largo de las fases del PU se distribuye un flujo de trabajo de ingeniería del software. En el contexto del PU, un flujo de trabajo es análogo a un conjunto de tareas. Esto es, un



flujo de trabajo identifica las tareas necesarias para completar una acción importante de ingeniería del software y los productos de trabajo que se producen como consecuencia de la realización exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades.

Productos de trabajo del proceso unificado. En la siguiente figura se ilustran los productos de trabajo clave que se produjeron como consecuencia de las cuatro fases técnicas del PU. Durante la fase de inicio, el propósito es establecer una "visión" general para el proyecto, identificar un conjunto de requisitos de negocios, formar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstáculo para el éxito. Desde el punto de vista del ingeniero de software, el producto de trabajo más impor-tante generado durante la etapa de inicio es el modelo de caso de uso: una colección de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no humanos del software) interactúan con el sistema y obtienen valor a partir de éste. En esencia, el modelo de casos de uso es una colección de escenarios de uso con plantillas estandarizadas que implican características y funciones del software mediante la descripción de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interacción representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstracción es alto). Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada importante para la creación de productos de trabajo subsecuentes. Durante la fase de inicio sólo se completa entre el 10 y 20 por ciento de los casos de uso. Después de la elaboración, se ha creado entre un 80 y 90 por ciento del modelo.

La fase de elaboración produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales), así como una descripción arquitectónica y un diseño preliminar. Cuando el ingeniero de software inicia con el análisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de análisis que describan en forma adecuada el comportamiento del sistema. El modelo de análisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y análisis (colecciones de clases) definidos como una parte del modelo de análisis se refinan después en un modelo de diseño, el cual identifica clases de diseño, subsistemas y las interfases entre los subsistemas. Los modelos de análisis y diseño expanden y refinan una representación evolutiva de la arquitectura del software. Además,



en la fase de elaboración se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez.

La fase de construcción produce un modelo de implementación que traduce las clases de diseño en componentes de software que se construirán para ejecutar el sistema, y un modelo de despliegue convierte los componentes en el ambiente físico de computación. Por último, un modelo de prueba describe las pruebas empleadas para asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha construido.

La fase de transición entrega el incremento del software y evalúa los productos de

trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentación proveniente de las pruebas beta y los requerimientos cualitativos de cambio. Resumen.

Los modelos prescriptivos del proceso de software se han aplicado durante muchos años en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma es diferente, pero todos realizan el mismo conjunto de actividades genéricas del marco de trabajo: comunicación, planeación, modelado, construcción y despliegue.

El modelo en cascada sugiere una progresión lineal de actividades del marco de trabajo que a menudo resulta inconsistente con la realidad moderna en el mundo del software (por ejemplo, con el cambio continuo, los sistemas en evolución, las fechas de entrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones en las cuales los requisitos están bien definidos y son estables.

Los modelos increméntales del proceso de software producen software como una serie de entregas de incrementos. El modelo DRA está diseñado para proyectos gran des que se deben entregar en marcos de tiempo muy reducidos.

Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayoría

de los proyectos de ingeniería del software y están diseñados para ajustarse al cambio. Los modelos evolutivos, como el de construcción de prototipos y el modelo en espiral, generan productos de trabajo increméntales (o versiones del software en funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a través de todas las actividades de la ingeniería del software: desde el desarrollo de conceptos hasta el mantenimiento del sistema a largo plazo.

El modelo basado en componentes destaca la reutilización y ensambladura de

componentes. Los modelos de métodos formales conducen a la utilización de un enfoque basado en las matemáticas para el desarrollo y la verificación del software.

El modelo orientado a aspectos incluye los intereses generales que cubren la arqui-tectura total del sistema.



El proceso unificado es un proceso de software "guiado por los casos de uso, de arquitectura céntrica, iterativo e incremental" diseñado como un marco para los métodos y herramientas del UML. El proceso unificado es un modelo incremental en el que se definen cinco fases:

1) una fase de inicio que abarca la comunicación con el cliente y las actividades de planeación, y destaca el desarrollo y el refinamiento de casos de uso como un modelo primario;

2) una fase de elaboración que abarca la comunicación con el cliente y las actividades de modelado con un enfoque en la creación de modelos de análisis y diseño, con énfasis en las definiciones de clase y representaciones arquitectónicas;

3) una fase de construcción que refina y después traduce el modelo de diseño en componentes de software implementados;

4) una fase de transición que transfiere el software del desarrollador al usuario final para realizar las pruebas beta y obtener la aceptación; y

5) una fase de producción en la cual se realiza el monitoreo continuo y el soporte.

Documents

Unidad 5 Modelo Desarrollo Software