Unidad 5.- Modelos de desarrollo de software. Modelos prescriptivos.

Cualquier organizacin de ingeniera del software debe describir un conjunto nico de actividades dentro del marco de trabajo para el (los) proceso(s) de software que adopte. Tambin debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniera del software, y definir cada accin 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. Despus, la organizacin debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especfica de cada proyecto, a las personas que lo realizarn, 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 genrico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicacin, planeacin, modelado, construccin 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 comunicacin a travs del despliegue de una manera casi lineal. Esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente (por ejemplo, una adaptacin a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir tambin en un nmero limitado de proyectos de nuevos desarrollos, pero slo cuando los requerimientos estn bien definidos y son estables en forma razonable,

El modelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia [HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn:

Modelos de desarrollo de software

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 acta. 2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. 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 versin 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 revisin del programa. En un anlisis 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 ms comn 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 caractersticas, funciones y contenido de la informacin). 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 estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.

Modelos de proceso incrementales.

En muchas situaciones los requisitos iniciales del software estn bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseado 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, podra realizar funciones bsicas de administracin de archivos, edicin y produccin de documentos; en el segundo incremento, ediciones ms sofisticadas, y tendra funciones ms complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier
MC Genaro Alberto Gmez Chi Pgina 2 de 18

Modelos de desarrollo de software

incremento puede incorporar el paradigma de construccin de prototipos que se expone ms adelante. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada). Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin 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 implementacin 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) ms personal para implementar el incremento siguiente. Adems, los incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.

El modelo DRA. El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rpido
MC Genaro Alberto Gmez Chi Pgina 3 de 18

Modelos de desarrollo de software

mediante un enfoque de construccin 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 das) [MAR91]. Como otros modelos de proceso, el enfoque DRA cumple con las actividades genricas del marco de trabajo que ya se han presentado. La comunicacin trabaja para entender el problema de negocios y las caractersticas de informacin que debe incluir el software. La planeacin 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 diseo que sirven como base para la actividad de construccin del modelo DRA. La construccin resalta el empleo de componentes de software existente y la aplicacin de la generacin automtica de cdigo. 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 aplicacin de negocios se puede modular de forma que cada gran funcin pueda completarse en menos de tres meses (mediante la aplicacin del enfoque ya descrito), sta es una candidata para el DRA. Cada gran funcin se puede abordar mediante un equipo de DRA por separado, para despus 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 nmero correcto de equipos DRA. 2) Si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarn. 3) Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios para el DRA ser problemtica. 4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfaces en componentes del sistema, el enfoque DRA podra no funcionar. 5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por ejemplo, cuando una aplicacin nueva aplica muchas nuevas tecnologas).

MC Genaro Alberto Gmez Chi

Pgina 4 de 18

Modelos de desarrollo de software

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 conclusin de un producto completo, por lo que debe presentar una versin limitada para liberar la presin competitiva y de negocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, pero todava 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 diseado 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 ms completas del software. Construccin 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 debera tomar la interaccin humano-mquina. En estas, y muchas otras situaciones, un paradigma de construccin de prototipos puede ofrecer el mejor enfoque. A pesar de que la construccin de prototipos se puede utilizar como un modelo de proceso independiente, se emplea ms comnmente como una tcnica 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 construccin de prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cal ser el resultado de la construccin cuando los requisitos estn satisfechos. El paradigma de construccin de prototipos se inicia con la comunicacin. 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 ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el cliente/usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para
MC Genaro Alberto Gmez Chi Pgina 5 de 18

Modelos de desarrollo de software

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 debera 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, etctera) que permiten producir programas de trabajo con rapidez. Pero qu debe hacerse con el prototipo una vez cumplido el propsito descrito? Brooks [BRO75] ofrece una respuesta:
En la mayora de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o rena las tres caractersticas a la vez. No existe otra opcin que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construir una revisin rediseada en la que se resuelvan estos problemas... Cuando se aplica un concepto nuevo de sistema o una tecnologa nueva, se tiene que construir un sistema in-servible y que sea necesario desechar, porque incluso la mejor planeacin no es omnisciente como para que el sistema est perfecto desde la primera vez. Por lo tanto, la pregunta de la administracin no es si debe construirse un sistema piloto y desecharlo. Esto tendr que hacerse. La nica pregunta es si se planea la construccin de un desechable o se promete entregrselo a los clientes.

El prototipo puede servir como "primer sistema", el que Brooks recomienda desechar. Pero sta tal vez sea una visin idealizada. Es verdad que a los clientes y los desarrolladores les gusta el paradigma de construccin de prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos tambin se torna problemtica por las siguientes razones: 1. El cliente ve lo que parece una versin 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 aplicacin de "unos pequeos ajustes para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gestin del desarrollo de software sea muy lenta. 2. A menudo, el desarrollador establece compromisos de implementacin para lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo o lenguaje de programacin inadecuado slo porque est disponible y es conocido; se puede implementar un algoritmo ineficiente slo para mostrar capacidad. Despus de un tiempo, el desarrollador quiz se familiarice con estas selecciones y olvide las razones por las que son inapropiadas. La seleccin menos ideal ahora se convierte en una parte integral del sistema. A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma efectivo para la ingeniera 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 definicin de requisitos, en que se descarte, al menos en parte, y en que despus se desarrolle el software real con un enfoque hacia la calidad.
MC Genaro Alberto Gmez Chi Pgina 6 de 18

Modelos de desarrollo de software

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 construccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada. Proporciona el material para el desarrollo rpido de versiones incremntales 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 ingeniera del software concurrente y con mltiples usuarios. Tiene dos caractersticas distintivas principales. Una de ellas es un enfoque cclico para el crecimiento incrementa! del grado de definicin e implementacin de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijacin 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 ms completas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniera del software. Para propsitos ilustrativos se aprovechan las actividades genricas del marco de trabajo expuestas pginas atrs. 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 direccin 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 revolucin. Los puntos de fijacin una combinacin 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 especificacin del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y despus, en forma progresiva, versiones ms elaboradas del software. Cada paso a travs de la regin de planeacin resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentacin derivada de la relacin con el cliente despus de la entrega. Adems, el administrador del proyecto ajusta el nmero de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega el software, 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 podra representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y
MC Genaro Alberto Gmez Chi Pgina 7 de 18

Modelos de desarrollo de software

contina por mltiples iteraciones hasta que el desarrollo del concepto est completo. Si el concepto se desarrollar en un producto real, el proceso contina en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionar a travs de un nmero de iteraciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra 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 sistemas 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 construccin de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma ms importante, permite al desarrollador la aplicacin del enfoque de la construccin de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemtico de los pasos que sugiere el ciclo de vida clsico, pero lo incorpora al marco de trabajo iterativo que refleja de forma ms verdica el mundo real. El modelo en espiral exige una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelvan problemticos. As como otros paradigmas, el modelo en espiral no es una panacea. Es difcil 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 confa en dicha habilidad para obtener el xito. Si un riesgo importante no se descubre y administra, sin duda surgirn problemas. El modelo de desarrollo concurrente. El modelo de desarrollo concurrente, llamado algunas veces ingeniera concurrente, se representa en forma esquemtica como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniera 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: construccin de prototipos o modelado y especificacin del anlisis y diseo. En la figura se proporciona un esquema de una tarea de ingeniera 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 comunicacin y la construccin) se representan de una manera anloga. Todas las actividades existen de forma concurrente, pero se encuentran en
MC Genaro Alberto Gmez Chi Pgina 8 de 18

Modelos de desarrollo de software

diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicacin (no se muestra en la figura) ha completado su primera iteracin y existe en el estado de en espera de cambios. La actividad de modelado que existi en el estado ninguno mientras se realizaba la comunicacin inicial, ahora realiza una transicin 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 dispararn transiciones de estado a estado para cada una de las actividades, acciones o tareas de la ingeniera del software. Por ejemplo, durante los primeros estados del diseo (una accin de la ingeniera del software que ocurre en el curso de la actividad de modelacin) no se detecta una inconsistencia en el modelo del anlisis. Esto genera el evento correccin del anlisis del modelo, el cual disparar la creacin del anlisis 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 software y proporciona una visin exacta del estado actual de un proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniera del software a una secuencia de eventos, define una red de actividades. Cada actividad, accin o tarea en la red existe de manera simultnea 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 gestin ms 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, adems, como modelos de proceso de clase general. Estos modelos tambin tienen debilidades, las cuales se resumen a continuacin:
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 construccin de prototipos [y otros procesos evolutivos ms elaborados] implican un problema para la planeacin del proyecto debido al nmero incierto de ciclos requeridos para construir el producto. La mayora de las tcnicas de gestin y estimacin 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 mxima de la evolucin. Si las evoluciones suceden demasiado rpido, sin un periodo de relajacin, existe la certidumbre de que el proceso caer en el caos. Por otro lado, si la velocidad es demasiado lenta, se podra 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 afirmacin 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 producira un retraso en la entrega del producto, la cual se hara cuando el nicho de

MC Genaro Alberto Gmez Chi

Pgina 9 de 18

Modelos de desarrollo de software 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 nmero de respetados expertos en la ingeniera del software (por ejemplo, [YOU95], [BAC97]). El propsito 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 parmetros crticos del proyecto y el producto, y el producto y la satisfaccin del cliente (el arbitro final de la calidad del software).

Modelos especializados de proceso.

Los modelos especializados de proceso adoptan muchas de las caractersticas de uno o ms de los modelos convencionales presentados en las secciones anteriores. Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido un enfoque de ingeniera 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 construccin. 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 caractersticas del modelo en espiral. Es evolutivo por naturaleza [NIE92] y exige un enfoque iterativo para la creacin del software. Sin embargo, el modelo configura aplicaciones a partir de componentes de software empaquetados en forma previa. Las actividades de modelado y construccin comienzan con la identificacin de los componentes candidatos. Estos componentes se pueden disear como mdulos de software convencionales o como clases o paquetes de clases orientados a objetos. Sin importar la tecnologa que se aplique en la creacin 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 evalan para el dominio de aplicacin en cuestin. Se consideran los aspectos de integracin de componentes. Se disea una arquitectura de software para adaptar los componentes. Los componentes se integran en la arquitectura. Se realizan pruebas detalladas para asegurar una funcionalidad apropiada.
MC Genaro Alberto Gmez Chi Pgina 10 de 18

Modelos de desarrollo de software

El modelo de desarrollo basado en componentes conduce a la reutilizacin de software, la cual proporciona beneficios a los ingenieros de software. Con base en estudios de reutilizacin, QSM Associates, Inc. informa que el ensamblaje de componentes conduce a una reduccin 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 estn en funcin 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 mtodos formales. El modelo de mtodos formales comprende un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora al aplicar una notacin matemtica rigurosa. Algunas organizaciones de desarrollo del software aplican en la actualidad una variacin de este enfoque, llamado ingeniera del software de sala limpia [MIL87, DYE92]. Cuando se utilizan mtodos formales durante el desarrollo, stos proporcionan un mecanismo para eliminar muchos de los problemas difciles de superar con otros paradigmas de la ingeniera del software. La ambigedad, el estado incompleto y la inconsistencia se descubren y corrigen con mayor facilidad no mediante una revisin ad hoc, sino a travs de la aplicacin de un anlisis matemtico. Cuando los mtodos formales se utilizan durante el diseo sirven como base para la verificacin de programas y, por consiguiente, permiten que el ingeniero de software descubra y corrija errores que de otra manera podran no haberse detectado. A pesar de que an no existe un enfoque establecido, los modelos de mtodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha mencionado una gran preocupacin acerca de su aplicabilidad en su entorno de gestin: En la actualidad, el desarrollo de modelos formales es muy caro y consume mucho tiempo. Se requiere una capacitacin detallada, debido a que pocos responsables del desarrollo de software cuentan con los antecedentes necesarios para aplicar mtodos formales. Es difcil la utilizacin de estos modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos. No obstante, tal vez el enfoque a travs de mtodos formales haya ganado adeptos entre los desarrolladores de software que deben construir sistemas de alta seguridad (por ejemplo, en los campos de la aeronutica y de los dispositivos mdicos), y entre los desarrolladores que padecen severas penurias econmicas cuando aparecen errores en el software.

MC Genaro Alberto Gmez Chi

Pgina 11 de 18

Modelos de desarrollo de 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 especfico de caractersticas, funciones y contenido de informacin. Estas caractersticas especficas del software se modelan como componentes (por ejemplo, clases orientadas a objetos) y despus se construyen dentro del contexto de una arquitectura de sistema. Conforme los sistemas basados en computadora se vuelven ms elaborados (y complejos), ciertos "intereses" propiedades requeridas para el cliente o reas de inters tcnico 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 aplicacin de reglas de negocios), mientras que otros son sistmicos (como la sincronizacin de tareas o la gestin de memoria). Cuando los intereses se relacionan con mltiples funciones, caractersticas e informacin del sistema, con frecuencia se denominan intereses generales. Los requerimientos de aspectos definen estos intereses generales que ejercen un impacto a travs de la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), referido con frecuencia como programacin orientada a aspectos (POA), es un paradigma de la ingeniera del software relativamente nuevo que proporciona un proceso y enfoque metodolgico para definir, especificar, disear y construir aspectos "mecanismos ms all de subrutinas y legados para localizar la expresin de un inters general" [ELR01]. Grundy [GRU02] explica con mayor profundidad los aspectos en el contexto de lo que l llama ingeniera de componentes orientada a aspectos [ICOA]:
La ICOA utiliza un concepto de capas horizontales a travs 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 sistmicos incluyen interfases con el usuario, trabajo en colaboracin, distribucin, persistencia, gestin de la memoria, procesamiento de transiciones, seguridad, integridad y otros. Los componentes pueden proporcionar o requerir uno o ms "detalles de aspecto" relacionados con un aspecto particular, como un mecanismo de visin, acceso extensible y tipo de interfase (aspectos de la interfase con el usuario); generacin, transportacin y recepcin de eventos (aspectos de distribucin); almacenamiento/recuperacin e indizacin de datos (aspectos de persistencia); autentificacin, codificacin y derechos de acceso (aspectos de seguridad); atomicidad de la transaccin, control de concurrencia y control del transporte (aspectos de transaccin), y as sucesivamente. Cada detalle de aspecto tiene una serie de propiedades en relacin con caractersticas 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 caractersticas 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 comunicacin asincrnica entre las actividades del proceso de software aplicadas al desarrollo y la construccin de aspectos y componentes.

MC Genaro Alberto Gmez Chi

Pgina 12 de 18

Modelos de desarrollo de software

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 cntrica, 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 volvan ms poderosas cada ao, lo que alentaba que los usuarios esperaran ms de ellas. Esta tendencia tambin la impuls el uso expandido de Internet para el intercambio de todo tipo de informacin. Nuestro apetito por un software cada vez ms complejo crece en la medida en la que aprendemos cmo 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 ms complejo. En resumen, queremos ms.

De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y caractersticas 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 comunicacin con el cliente y los mtodos 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 reutilizacin" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. En esta seccin se presenta una visin general de los elementos clave del proceso unificado. Una breve historia. Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos y lenguajes de programacin orientados a objetos (OO) obtuvieron una amplia difusin entre la comunidad de la ingeniera del software. Durante el mismo periodo se propuso una amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propsito general (similar a los modelos evolutivos presentados en este captulo). Al igual que la mayora de los paradigmas "nuevos" para la ingeniera del software, los seguidores de cada uno de los mtodos de AOO y DOO argumentaban acerca de cul de ellos era el mejor, pero ningn mtodo o lenguaje domin la escena de la ingeniera del software. Al principio de la dcada de 1990, James Rumbaugh [RUM91], Grady Booch [BOO94] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "mtodo unificado" que combinara las mejores caractersticas de cada uno de sus mtodos individuales y adoptara caractersticas 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 ingls) que contiene una notacin robusta para el modelado y el desarrollo de sistemas OO. Para 1997, el UML se convirti en un estndar de la industria para el desarrollo de software orientado a objetos. Al mismo tiempo,

MC Genaro Alberto Gmez Chi

Pgina 13 de 18

Modelos de desarrollo de software

Rational Corporation y otras firmas desarrollaron herramientas automticas para apoyar los mtodos del UML. El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera del software orientada a objetos, pero no provee el marco de trabajo del proceso que gue a los equipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniera del software orientada a objetos, mediante la utilizacin 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 especficas. Como consecuencia de la aplicacin 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 ms gil y reactivo ante el cambio. Fases del proceso unificado. Se han analizado cinco actividades genricas 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 excepcin. En la siguiente figura se muestran las "fases" del proceso unificado (PU). La fase de inicio del PU abarca la comunicacin con el cliente y las actividades de planeacin. 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 travs de un conjunto preliminar de casos de uso que describen cules caractersticas y funciones 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 mquina, otro sistema) cuando ste interacta con el software. Los casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base para la planeacin de ste. En este punto, la arquitectura no es ms que un esquema tentativo de los subsistemas ms importantes y de las funciones y caractersticas que los forman. Despus, la arquitectura se refinar y expandir en un conjunto de modelos que representarn visiones diferentes del sistema. La planeacin identifica recursos, evala los

MC Genaro Alberto Gmez Chi

Pgina 14 de 18

Modelos de desarrollo de software

riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software. La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso. La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una "lnea de base arquitectnica ejecutable" [ARL02] que representa un sistema ejecutable en su "primer corte". La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las caractersticas y funciones necesarias para utilizar el sistema. Adems, el plan se, revisa de manera cuidadosa al trmino de la fase de elaboracin para asegurar que el mbito, los riesgos y los datos entregados an son razonables. Las modificaciones al plan se deben hacer en este momento. La fase de construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin (ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU. La fase de transicin del PU abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable. La fase de produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben y evalan los informes de defectos y los requerimientos de cambios. Es probable que mientras se realizan las fases de construccin, transicin y produccin 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 ingeniera del software. En el contexto del PU, un flujo de trabajo es anlogo a un conjunto de tareas. Esto es, un
MC Genaro Alberto Gmez Chi Pgina 15 de 18

Modelos de desarrollo de software

flujo de trabajo identifica las tareas necesarias para completar una accin importante de ingeniera del software y los productos de trabajo que se producen como consecuencia de la realizacin 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 tcnicas del PU. Durante la fase de inicio, el propsito es establecer una "visin" 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 obstculo para el xito. Desde el punto de vista del ingeniero de software, el producto de trabajo ms importante generado durante la etapa de inicio es el modelo de caso de uso: una coleccin de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no humanos del software) interactan con el sistema y obtienen valor a partir de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso con plantillas estandarizadas que implican caractersticas y funciones del software mediante la descripcin de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstraccin 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 creacin de productos de trabajo subsecuentes. Durante la fase de inicio slo se completa entre el 10 y 20 por ciento de los casos de uso. Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo. La fase de elaboracin produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales), as como una descripcin arquitectnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de anlisis que describan en forma adecuada el comportamiento del sistema. El modelo de anlisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y anlisis (colecciones de clases) definidos como una parte del modelo de anlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo, subsistemas y las interfases entre los subsistemas. Los modelos de anlisis y diseo expanden y refinan una representacin evolutiva de la arquitectura del software. Adems,

MC Genaro Alberto Gmez Chi

Pgina 16 de 18

Modelos de desarrollo de software

en la fase de elaboracin se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez. La fase de construccin produce un modelo de implementacin que traduce las clases de diseo en componentes de software que se construirn para ejecutar el sistema, y un modelo de despliegue convierte los componentes en el ambiente fsico de computacin. 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 transicin entrega el incremento del software y evala los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y los requerimientos cualitativos de cambio.

Resumen. Los modelos prescriptivos del proceso de software se han aplicado durante muchos aos 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 genricas del marco de trabajo: comunicacin, planeacin, modelado, construccin y despliegue. El modelo en cascada sugiere una progresin 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 evolucin, las fechas de entrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones en las cuales los requisitos estn bien definidos y son estables. Los modelos incremntales del proceso de software producen software como una serie de entregas de incrementos. El modelo DRA est diseado 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 mayora de los proyectos de ingeniera del software y estn diseados para ajustarse al cambio. Los modelos evolutivos, como el de construccin de prototipos y el modelo en espiral, generan productos de trabajo incremntales (o versiones del software en funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a travs de todas las actividades de la ingeniera del software: desde el desarrollo de conceptos hasta el mantenimiento del sistema a largo plazo. El modelo basado en componentes destaca la reutilizacin y ensambladura de componentes. Los modelos de mtodos formales conducen a la utilizacin de un enfoque basado en las matemticas para el desarrollo y la verificacin del software. El modelo orientado a aspectos incluye los intereses generales que cubren la arquitectura total del sistema.

MC Genaro Alberto Gmez Chi

Pgina 17 de 18

Modelos de desarrollo de software

El proceso unificado es un proceso de software "guiado por los casos de uso, de arquitectura cntrica, iterativo e incremental" diseado como un marco para los mtodos 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 comunicacin con el cliente y las actividades de planeacin, y destaca el desarrollo y el refinamiento de casos de uso como un modelo primario; 2) una fase de elaboracin que abarca la comunicacin con el cliente y las actividades de modelado con un enfoque en la creacin de modelos de anlisis y diseo, con nfasis en las definiciones de clase y representaciones arquitectnicas; 3) una fase de construccin que refina y despus traduce el modelo de diseo en componentes de software implementados; 4) una fase de transicin que transfiere el software del desarrollador al usuario final para realizar las pruebas beta y obtener la aceptacin; y 5) una fase de produccin en la cual se realiza el monitoreo continuo y el soporte.

MC Genaro Alberto Gmez Chi

Pgina 18 de 18