Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 2 de 181. 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 maneraexplícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar laincertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versión que funcione de los programasestará disponible cuando el proyecto esté muy avanzado. Un error grave será desastrososi no se detecta antes de la revisión del programa.En un análisis interesante de proyectos reales, Bradac [BRA94] concluyó que lanaturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cualesalgunos miembros del equipo del proyecto deben esperar a otros para terminar tareasdependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajoproductivo. El estado de bloqueo tiende a ser más común al principio y al final del procesosecuencial.En la actualidad, el trabajo del software está acelerado y sujeto a una cadenainfinita de cambios (de características, funciones y contenido de la información). Confrecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo,puede servir como un modelo de proceso útil en situaciones donde los requerimientosestán fijos y donde el trabajo serealiza,hasta su conclusión, de una manera lineal.Modelos de proceso incrementales.En muchas situaciones los requisitos iniciales del software están bien definidos enforma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un procesopuramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar demanera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla yexpandirla en las entregas posteriores del software. En estos casosse elige un modelo de proceso diseñado para producir el software en forma incremental.El modelo incremental. Elmodelo incrementa! combina elementos del modelo en cascada aplicado enforma iterativa. Como se muestra en la figura, el modelo incremental aplica secuenciaslineales de manera escalonada conforme avanza el tiempo en el calendario. Cadasecuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el softwareprocesador 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 dedocumentos; en el segundo incremento, ediciones más sofisticadas, y tendría funcionesmás complejas de producción de documentos; en el tercer incremento, funciones decorrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas deconfiguración de página. Se debe tener en cuenta que el flujo del proceso de cualquier

Modelos de proceso evolutivos.

MODELOS EVOLUTIVOS

El software, como todos los sistemas complejos, evoluciona con el tiempo. Losrequisitos de los negocios y productos a menudo cambian conforme se realiza eldesarrollo; por lo tanto, la ruta lineal que conduce a un producto final no será real; lasestrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, porlo que debe presentar una versión limitada para liberar la presión competitiva y denegocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, perotodavía se deben definir los detalles de las extensiones del producto o sistema. En estas yotras situaciones similares, los ingenieros de software necesitan un modelo de procesoque haya sido diseñado de manera explicita para incluir un producto que evolucione con eltiempo.Losmodelos evolutivos son iterativos; los caracteriza la forma en que permiten quelos 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 otroscasos, el responsable del desarrollo del software está inseguro de la eficacia de unalgoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar lainteracción humano-máquina. En estas, y muchas otras situaciones, unparadigma 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 deproceso independiente, se emplea más comúnmente como una técnica susceptible deimplementarse dentro del contexto de cualquiera de los modelos de proceso expuestos enestos apuntes. Sin importar la forma en que éste se aplique, el paradigma de construcciónde prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cúalserá el resultado de la construcción cuando los requisitos estén satisfechos.El paradigma de construcción de prototipos seinicia con la comunicación. El ingeniero de software y elcliente encuentran y definen los objetivos globales parael software, identifican los requisitos conocidos y lasáreas del esquema en donde es necesaria másdefinición. Entonces se plantea con rapidez unaiteración de construcción de prototipos y se presenta elmodelado (en la forma de un diseñorápido). El diseño rápido se centra en unarepresentación de aquellos aspectos delsoftware que serán visibles para el cliente o el usuariofinal (por ejemplo, la configuración de la interfaz con elusuario y el formato de los despliegues de salida). Eldiseño rápido conduce a la construcción de un prototipo. Después, el prototipo loevalúa el cliente/usuario y con la retroalimentación se refinan los requisitos del softwareque se desarrollará. La iteración ocurre cuando el prototipo se ajusta para

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 6 de 18satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrolladorentienda mejor lo que se debe hacer.De manera ideal, el prototipo debería

servir como un mecanismo para identificar losrequisitos del software. Si se construye un prototipo de trabajo, el desarrollador intentaemplear los fragmentos del programa ya existentes o aplica herramientas (comogeneradores de informes, administradores de ventanas, etcétera) que permiten producirprogramas 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 losdesarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios lesgusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sinembargo, la construcción de prototipos también se torna problemática por las siguientesrazones:1. El cliente ve lo que parece una versión en funcionamiento del software, sin saberque el prototipo está unido "con chicle y cable para embalaje", que por la prisa dehacerlo funcionar no se ha considerado la calidad del software global o la facilidadde mantenimiento a largo plazo. Cuando se informa que el producto debeconstruirse otra vez para mantener los altos niveles de calidad, el cliente no loentiende y pide la aplicación de "unos pequeños ajustes”para que se puedaelaborar un producto final a partir del prototipo. Es muy frecuente que la gestión deldesarrollo de software sea muy lenta.2. A menudo, el desarrollador establece compromisos de implementación para lograrque el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo olenguaje 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 yolvide las razones por las que son inapropiadas. La selección menos ideal ahora seconvierte en una parte integral del sistema.A pesar de que tal vez surjan problemas, la construcción de prototipos puede serun paradigma efectivo para la ingeniería del software. La clave es definir las reglasdel juego desde el principio; es decir, el cliente y el desarrollador se deben poner deacuerdo en que el prototipo se construya y sirva como un mecanismo para la definición derequisitos, en que se descarte, al menos en parte, y en que después se desarrolle elsoftware real con un enfoque hacia la calidad.

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 3 de 18incremento puede incorporar el paradigma de construcción de prototipos que se exponemá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ísticassuplementarias (algunas conocidas, otras no) no se incorporan. El producto esencialqueda en manos del cliente (o se somete a una evaluación detallada). Como resultado dela evaluación se desarrolla un plan para el incremento siguiente. El plan afronta lamodificación del producto esencial con el fin de satisfacer de mejor manera lasnecesidades del cliente y la entrega de características y funcionalidades adicionales. Esteproceso se repite después de la entrega de cada incremento mientras no se hayaelaborado el producto completo.El modelo de proceso incremental, al igual que la construcción de prototipos y otrosenfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción deprototipos, el modelo incremental se enfoca en la entrega de un producto operacional concada incremento. Los primeros incrementos son versiones“incompletas del producto final,pero proporcionan al usuario la funcionalidad que necesita y una plataforma paraevaluarlo.El desarrollo incremental es útil sobre todo cuando el personal necesario para unaimplementación completa no está disponible. Los primeros incrementos se puedenimplementar con menos gente. Si el producto esencial es bien recibido se agrega (si serequiere) más personal para implementar el incremento siguiente. Además, losincrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, unsistema grande podría requerir la disponibilidad de un hardware nuevo que está endesarrollo y cuya fecha de entrega es incierta. Sería posible planear los primerosincrementos de forma que se evite el uso de este hardware, lo que permitiría la entrega defuncionalidad parcial a los usuarios finales sin retrasos desordenados.El modelo DRA. Eldesarrollo rápido de aplicaciones (DRA) es un modelo de proceso de softwareincremental 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

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 4 de 18

mediante un enfoque de construcción basado en componentes. Si se entienden bienlos requisitos y se limita el ámbito del proyecto, el proceso DRA permite que unequipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muycorto (por ejemplo, de 60 a 90 días) [MAR91].Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenéricas del marco de trabajo que ya se han presentado. Lacomunicación trabaja paraentender el problema de negocios y las características de información que debe incluir elsoftware. Laplaneación es esencial porque varios equipos de software trabajan enparalelo sobre diferentes funciones del sistema. Elmodelado incluye tres grandes fases—modelado de negocios, modelado de datos y modelado del proceso—y establecerepresentaciones del diseño que sirven como base para la actividad de construcción delmodelo DRA. Laconstrucción resalta el empleo de componentes de software existente y laaplicación de la generación automática de código. Por último, eldespliegue establece unabase para las iteraciones subsecuentes, si éstas son necesarias [KER94].El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que lasrestricciones de tiempo impuestas sobre un proyecto DRA exigen un "ámbito de escalas"[KER94]. Si una aplicación denegocios se puede modular deforma que cada gran funciónpueda completarse en menos detres meses (mediante la aplicacióndel enfoque ya descrito), ésta esuna candidata para el DRA. Cadagran función se puede abordarmediante un equipo de DRA porseparado, para después integrarlasy formar un todo.Como todos los modelos deprocesos, el enfoque DRA tieneinconvenientes:1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursoshumanos para crear en número correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rápidasnecesarias para completar el sistema en un marco de tiempo muy breve, losproyectos DRA fallarán.3) Si un sistema no se puede modular en forma apropiada, la construcción de loscomponentes necesarios para el DRA será problemática.4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertirinterfaces 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).

GGGGGGGGGGGGGGGGGGGGGGGG

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

Cualquier organización de ingeniería del software debe describir un conjunto únicode actividades dentro del marco de trabajo para el (los) proceso(s) de software queadopte. También debe llenar cada actividad del marco de trabajo con un conjunto deacciones de ingeniería del software, y definir cada acción en cuanto a un conjunto detareas que identifique el trabajo (y los productos del trabajo) que deben completarse paraalcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo deproceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personasque lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelodel proceso seleccionado, los ingenieros de software han elegido de manera tradicional unmarco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentrodel 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 unamanera razonable: cuando el trabajo fluye desde la comunicación a través del desplieguede una manera casi lineal. Esta situación se encuentraa veces cuando es necesario haceradaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, unaadaptació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 formarazonable,Elmodelo en cascada,algunas veces llamado elciclo de vida clásico,

sugiere unenfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con laespecificación de requerimientos del cliente y que continúa con la planeación, elmodelado, la construcción y el despliegue para culminar en el soporte del softwareterminado.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 hanocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia[HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo encascada están:

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 2 de 181. 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 maneraexplícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar laincertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versión que funcione de los programasestará disponible cuando el proyecto esté muy avanzado. Un error grave será desastrososi no se detecta antes de la revisión del programa.En un análisis interesante de proyectos reales, Bradac [BRA94] concluyó que lanaturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cualesalgunos miembros del equipo del proyecto deben esperar a otros para terminar tareasdependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajoproductivo. El estado de bloqueo tiende a ser más común al principio y al final del procesosecuencial.En la actualidad, el trabajo del software está acelerado y sujeto a una cadenainfinita de cambios (de características, funciones y contenido de la información). Confrecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo,puede servir como un modelo de proceso útil en situaciones donde los requerimientosestán fijos y donde el trabajo serealiza,hasta su conclusión, de una manera lineal.

GGGGGGGGGGGG

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

 Elmodelo incrementa! combina elementos del modelo en cascada aplicado enforma iterativa. Como se muestra en la figura, el modelo incremental aplica secuenciaslineales de manera escalonada conforme avanza el tiempo en el calendario. Cadasecuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el softwareprocesador 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 dedocumentos; en el segundo incremento, ediciones más sofisticadas, y tendría funcionesmás complejas de producción de documentos; en el tercer incremento, funciones decorrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas deconfiguración de página. Se debe tener en cuenta que el flujo del proceso de cualquier

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 3 de 18incremento puede incorporar el paradigma de construcción de prototipos que se exponemás adelante.A menudo, al utilizar un modelo incremental el primer incremento es unproducto esencial.Es decir, se incorporan los requisitos básicos, pero muchas característicassuplementarias (algunas conocidas, otras no) no se incorporan. El producto esencialqueda en manos del cliente (o se somete a una evaluación detallada). Como resultado dela evaluación se desarrolla un plan para el incremento siguiente. El plan afronta lamodificación del producto esencial con el fin de satisfacer de mejor manera lasnecesidades del cliente y la entrega de características y funcionalidades adicionales. Esteproceso se repite después de la entrega de cada incremento mientras no se hayaelaborado el producto completo.El modelo de proceso incremental, al igual que la construcción de prototipos y otrosenfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción deprototipos, el modelo incremental se enfoca en la entrega de un producto operacional concada incremento. Los primeros incrementos son versiones“incompletas del producto final,pero proporcionan al usuario la funcionalidad que necesita y una plataforma paraevaluarlo.El desarrollo incremental es útil sobre todo cuando el personal necesario para unaimplementación completa no está disponible. Los primeros incrementos se puedenimplementar con menos gente. Si el producto esencial es bien recibido se agrega (si serequiere) más personal para implementar el incremento siguiente. Además, losincrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, unsistema grande podría requerir la disponibilidad de un hardware nuevo que está endesarrollo y cuya fecha de entrega es incierta. Sería posible planear los primerosincrementos de forma que se evite el uso de este hardware, lo que permitiría la entrega defuncionalidad parcial a los usuarios finales sin retrasos desordenados.El modelo DRA. Eldesarrollo rápido de aplicaciones (DRA) es un modelo de proceso de softwareincremental 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

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 4 de 18

mediante un enfoque de construcción basado en componentes. Si se entienden bienlos requisitos y se limita el ámbito del proyecto, el proceso DRA permite que unequipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muycorto (por ejemplo, de 60 a 90 días) [MAR91].Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenéricas del marco de trabajo que ya se han presentado. Lacomunicación trabaja paraentender el problema de negocios y las características de información que debe incluir elsoftware. Laplaneación es esencial porque varios equipos de software trabajan enparalelo sobre diferentes funciones del sistema. Elmodelado incluye tres grandes fases—modelado de negocios, modelado de datos y modelado del proceso—y establecerepresentaciones del diseño que sirven como base para la actividad de construcción delmodelo DRA. Laconstrucción resalta el empleo de componentes de software existente y laaplicación de la generación automática de código. Por último, eldespliegue establece unabase para las iteraciones subsecuentes, si éstas son necesarias [KER94].El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que lasrestricciones de tiempo impuestas sobre un proyecto DRA exigen un "ámbito de escalas"[KER94]. Si una aplicación denegocios se puede modular deforma que cada gran funciónpueda completarse en menos detres meses (mediante la aplicacióndel enfoque ya descrito), ésta esuna candidata para el DRA. Cadagran función se puede abordarmediante un equipo de DRA porseparado, para después integrarlasy formar un todo.Como todos los modelos deprocesos, el enfoque DRA tieneinconvenientes:1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursoshumanos para crear en número correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rápidasnecesarias para completar el sistema en un marco de tiempo muy breve, losproyectos DRA fallarán.3) Si un sistema no se puede modular en forma apropiada, la construcción de loscomponentes necesarios para el DRA será problemática.4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertirinterfaces 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 desarrollo de softwareMC Genaro Alberto Gómez Chi Página 5 de 18Modelos de proceso evolutivos.El software, como todos los sistemas complejos, evoluciona con el tiempo. Losrequisitos de los negocios y productos a menudo cambian conforme se realiza eldesarrollo; por lo tanto, la ruta lineal que conduce a un producto final no será real; lasestrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, porlo que debe presentar una

versión limitada para liberar la presión competitiva y denegocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, perotodavía se deben definir los detalles de las extensiones del producto o sistema. En estas yotras situaciones similares, los ingenieros de software necesitan un modelo de procesoque haya sido diseñado de manera explicita para incluir un producto que evolucione con eltiempo.Losmodelos evolutivos son iterativos; los caracteriza la forma en que permiten quelos 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 otroscasos, el

responsable del desarrollo del software está inseguro de la eficacia de unalgoritmo, de la

adaptabilidad de un sistema operativo o de la forma que debería tomar lainteracción humano-máquina. En estas, y muchas otras situaciones, unparadigma 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 deproceso independiente, se emplea más comúnmente como una técnica susceptible deimplementarse dentro del contexto de cualquiera de los modelos de proceso expuestos enestos apuntes. Sin importar la forma en que éste se aplique, el paradigma de construcciónde prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cúalserá el resultado de la construcción cuando los requisitos estén satisfechos.El paradigma de construcción de prototipos seinicia con la comunicación. El ingeniero de software y elcliente encuentran y definen los objetivos globales parael

software, identifican los requisitos conocidos y lasáreas del esquema en donde es necesaria másdefinición. Entonces se plantea con rapidez unaiteración de construcción de prototipos y se presenta elmodelado (en la forma de un diseñorápido). El diseño rápido se centra en unarepresentación de aquellos aspectos delsoftware que serán visibles para el cliente o el usuariofinal (por ejemplo, la configuración de la interfaz con elusuario y el formato de los despliegues de salida). Eldiseño rápido conduce a la construcción de un prototipo. Después, el prototipo loevalúa el cliente/usuario y con la retroalimentación se refinan los requisitos del softwareque se desarrollará. La iteración ocurre cuando el prototipo se ajusta para

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 6 de 18satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrolladorentienda mejor lo que se debe hacer.De manera ideal, el prototipo debería

servir como un mecanismo para identificar losrequisitos del software. Si se construye un prototipo de trabajo, el desarrollador intentaemplear los fragmentos del programa ya existentes o aplica herramientas (comogeneradores de informes, administradores de ventanas, etcétera) que permiten producirprogramas 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 losdesarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios lesgusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sinembargo, la construcción de prototipos también se torna problemática por las siguientesrazones:1. El cliente ve lo que parece una versión en funcionamiento del software, sin saberque el prototipo está unido "con chicle y cable para embalaje", que por la prisa dehacerlo funcionar no se ha considerado la calidad del software global o la facilidadde mantenimiento a largo plazo. Cuando se informa que el producto debeconstruirse otra vez para mantener los altos niveles

de calidad, el cliente no loentiende y pide la aplicación de "unos pequeños ajustes

”para que se puedaelaborar un producto final a partir del prototipo. Es muy frecuente que la gestión deldesarrollo de software sea muy lenta.2. A menudo, el desarrollador establece compromisos de implementación para lograrque el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo olenguaje 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 yolvide las razones por las que son inapropiadas. La selección menos ideal ahora seconvierte en una parte integral del sistema.A pesar de que tal vez surjan problemas, la construcción de prototipos puede serun paradigma efectivo para la ingeniería del software. La clave es definir las reglasdel juego desde el principio; es decir, el cliente y el desarrollador se deben poner deacuerdo en que el prototipo se construya y sirva como un mecanismo para la definición derequisitos, en que se descarte, al menos en parte, y en que después se desarrolle elsoftware real con un enfoque hacia la calidad.

 Modelos de desarrollo de softwareMC Genaro Alberto Gómez Chi Página 7 de 18

El modelo en espiral. Elmodelo en espiral,que Boehm [BOE88] propuso originalmente, es un modelo deproceso de software evolutivo que conjuga la naturaleza iterativa de la construcción deprototipos 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 documentodel modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vezmás completas del sistema desarrollado.Un proceso en espiral se divide en un conjunto de actividades del marco de trabajoque define el equipo de ingeniería delsoftware. Para

propósitos ilustrativos seaprovechan las actividades genéricas delmarco de trabajo

expuestas páginas atrás. Cada una de las actividades del marco detrabajo representa un segmento de la ruta enespiral que se presenta en la figura. Cuandocomienza este proceso evolutivo el equipo desoftware realiza actividades implicadas en uncircuito alrededor de la espiral que tiene unadirección en el sentido del movimiento de lasmanecillas del reloj, y que se inicia desde elcentro. El riesgo es un factor considerado en cada revolución. Lospuntos de fijación —unacombinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de laespiral—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 puedenaprovechar para desarrollar un prototipo y después, en forma progresiva, versiones máselaboradas del software. Cada paso a través de la región de planeación resulta en ajustesal plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentaciónderivada de la relación con el cliente después de la entrega. Además, el administrador delproyecto ajusta el número de iteraciones planeado que se requiere para completar elsoftware.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 softwarede computadora. Por lo tanto, el primer circuito alrededor de la espiral podría representarun "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y