Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 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 acta.2. Con frecuencia es difcil para el cliente establecer todos los requisitos de maneraexplcita. 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 versin que funcione de los programasestar disponible cuando el proyecto est muy avanzado. Un error grave ser desastrososi no se detecta antes de la revisin del programa.En un anlisis 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 ms comn al principio y al final del procesosecuencial.En la actualidad, el trabajo del software est acelerado y sujeto a una cadenainfinita de cambios (de caractersticas, funciones y contenido de la informacin). 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 requerimientosestn 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 enforma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un procesopuramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar demanera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla yexpandirla en las entregas posteriores del software. En estos casosse 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 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,podra realizar funciones bsicas de administracin de archivos, edicin y produccin dedocumentos; en el segundo incremento, ediciones ms sofisticadas, y tendra funcionesms complejas de produccin de documentos; en el tercer incremento, funciones decorreccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas deconfiguracin de pgina. 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 conclusin de un producto completo, porlo que debe presentar una versin limitada para liberar la presin competitiva y denegocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, perotodava 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 diseado de manera explicita para incluir un producto que evolucione con eltiempo.Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten quelos 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 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 debera tomar lainteraccin 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 deproceso independiente, se emplea ms comnmente como una tcnica 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 construccinde prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera calser el resultado de la construccin cuando los requisitos estn satisfechos.El paradigma de construccin de prototipos seinicia con la comunicacin. El ingeniero de software y elcliente encuentran y definen los objetivos globales parael software, identifican los requisitos conocidos y lasreas del esquema en donde es necesaria msdefinicin. Entonces se plantea con rapidez unaiteracin de construccin de prototipos y se presenta elmodelado (en la forma de un diseorpido). El diseo rpido se centra en unarepresentacin de aquellos aspectos delsoftware que sern visibles para el cliente o el usuariofinal (por ejemplo, la configuracin de la interfaz con elusuario y el formato de los despliegues de salida). Eldiseo rpido conduce a la construccin de un prototipo. Despus, el prototipo loevala el cliente/usuario y con la retroalimentacin se refinan los requisitos del softwareque se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 6 de 18 satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrolladorentienda mejor lo que se debe hacer.De manera ideal, el prototipo debera

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, etctera) que permiten producirprogramas 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 dese-char. Pero sta tal vez sea una visin idealizada. Es verdad que a los clientes y losdesarrolladores les gusta el paradigma de construccin de prototipos. A los usuarios lesgusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sinembargo, la construccin de prototipos tambin se torna problemtica por las siguientesrazones:1. El cliente ve lo que parece una versin 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 aplicacin de "unos pequeos ajustes para que se puedaelaborar un producto final a partir del prototipo. Es muy frecuente que la gestin deldesarrollo de software sea muy lenta.2. A menudo, el desarrollador establece compromisos de implementacin para lograrque el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo olenguaje 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 yolvide las razones por las que son inapropiadas. La seleccin menos ideal ahora seconvierte en una parte integral del sistema.A pesar de que tal vez surjan problemas, la construccin de prototipos puede serun paradigma efectivo para la ingeniera 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 definicin derequisitos, en que se descarte, al menos en parte, y en que despus se desarrolle elsoftware real con un enfoque hacia la calidad.

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 3 de 18 incremento puede incorporar el paradigma de construccin de prototipos que se exponems adelante.A menudo, al utilizar un modelo incremental el primer incremento es un

producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticassuplementarias (algunas conocidas, otras no) no se incorporan. El producto esencialqueda en manos del cliente (o se somete a una evaluacin detallada). Como resultado dela evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta lamodificacin del producto esencial con el fin de satisfacer de mejor manera lasnecesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Esteproceso se repite despus de la entrega de cada incremento mientras no se hayaelaborado el producto completo.El modelo de proceso incremental, al igual que la construccin de prototipos y otrosenfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin 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 unaimplementacin completa no est disponible. Los primeros incrementos se puedenimplementar con menos gente. Si el producto esencial es bien recibido se agrega (si serequiere) ms personal para implementar el incremento siguiente. Adems, losincrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, unsistema grande podra requerir la disponibilidad de un hardware nuevo que est endesarrollo y cuya fecha de entrega es incierta. Sera posible planear los primerosincrementos de forma que se evite el uso de este hardware, lo que permitira la entrega defuncionalidad parcial a los usuarios finales sin retrasos desordenados. El modelo DRA. El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de softwareincremental 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

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 4 de 18

mediante un enfoque de construccin 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 das) [MAR91].Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenricas del marco de trabajo que ya se han presentado. La comunicacin trabaja paraentender el problema de negocios y las caractersticas de informacin que debe incluir elsoftware. La planeacin es esencial porque varios equipos de software trabajan enparalelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establecerepresentaciones del diseo que sirven como base para la actividad de construccin delmodelo DRA. La construccin resalta el empleo de componentes de software existente y laaplicacin de la generacin automtica de cdigo. Por ltimo, el despliegue 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 aplicacin denegocios se puede modular deforma que cada gran funcinpueda completarse en menos detres meses (mediante la aplicacindel enfoque ya descrito), sta esuna candidata para el DRA. Cadagran funcin se puede abordarmediante un equipo de DRA porseparado, para despus 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 nmero correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rpidasnecesarias para completar el sistema en un marco de tiempo muy breve, losproyectos DRA fallarn.3) Si un sistema no se puede modular en forma apropiada, la construccin de loscomponentes necesarios para el DRA ser problemtica.4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertirinterfaces 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).

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

Cualquier organizacin de ingeniera del software debe describir un conjunto nicode actividades dentro del marco de trabajo para el (los) proceso(s) de software queadopte. Tambin debe llenar cada actividad del marco de trabajo con un conjunto deacciones de ingeniera del software, y definir cada accin en cuanto a un conjunto detareas que identifique el trabajo (y los productos del trabajo) que deben completarse paraalcanzar las metas de desarrollo. Despus, la organizacin debe adaptar el modelo deproceso resultante y ajustarlo a la naturaleza especfica de cada proyecto, a las personasque lo realizarn, 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 genrico para el proceso, el cual incluye las siguientes actividades dentrodel marco: comunicacin, planeacin, modelado, construccin 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 comunicacin a travs del desplieguede una manera casi lineal. Esta situacin se encuentra a veces cuando es necesario haceradaptaciones o mejoras bien definidas a un sistema existente (por ejemplo, unaadaptacin 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 formarazonable,El modelo en cascada, algunas veces llamado el ciclo de vida clsico,

sugiere unenfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con laespecificacin de requerimientos del cliente y que contina con la planeacin, elmodelado, la construccin y el despliegue para culminar en el soporte del softwareterminado.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 hanocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia[HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo encascada estn:

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 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 acta.2. Con frecuencia es difcil para el cliente establecer todos los requisitos de maneraexplcita. 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 versin que funcione de los programasestar disponible cuando el proyecto est muy avanzado. Un error grave ser desastrososi no se detecta antes de la revisin del programa.En un anlisis 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 ms comn al principio y al final del procesosecuencial.En la actualidad, el trabajo del software est acelerado y sujeto a una cadenainfinita de cambios (de caractersticas, funciones y contenido de la informacin). 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 requerimientosestn fijos y donde el trabajo se realiza,hasta su conclusin, de una manera lineal. GGGGGGGGGGGG Modelos de proceso incrementales. En muchas situaciones los requisitos iniciales del software estn bien definidos enforma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un procesopuramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar demanera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla yexpandirla en las entregas posteriores del software. En estos casosse 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 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,podra realizar funciones bsicas de administracin de archivos, edicin y produccin dedocumentos; en el segundo incremento, ediciones ms sofisticadas, y tendra funcionesms complejas de produccin de documentos; en el tercer incremento, funciones decorreccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas deconfiguracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 3 de 18 incremento puede incorporar el paradigma de construccin de prototipos que se exponems adelante.A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticassuplementarias (algunas conocidas, otras no) no se incorporan. El producto esencialqueda en manos del cliente (o se somete a una evaluacin detallada). Como resultado dela evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta lamodificacin del producto esencial con el fin de satisfacer de mejor manera lasnecesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Esteproceso se repite despus de la entrega de cada incremento mientras no se hayaelaborado el producto completo.El modelo de proceso incremental, al igual que la construccin de prototipos y otrosenfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin 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 unaimplementacin completa no est disponible. Los primeros incrementos se puedenimplementar con menos gente. Si el producto esencial es bien recibido se agrega (si serequiere) ms personal para implementar el incremento siguiente. Adems, losincrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, unsistema grande podra requerir la disponibilidad de un hardware nuevo que est endesarrollo y cuya fecha de entrega es incierta. Sera posible planear los primerosincrementos de forma que se evite el uso de este hardware, lo que permitira la entrega defuncionalidad parcial a los usuarios finales sin retrasos desordenados. El modelo DRA. El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de softwareincremental 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

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 4 de 18

mediante un enfoque de construccin 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 das) [MAR91].Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenricas del marco de trabajo que ya se han presentado. La comunicacin trabaja paraentender el problema de negocios y las caractersticas de informacin que debe incluir elsoftware. La planeacin es esencial porque varios equipos de software trabajan enparalelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establecerepresentaciones del diseo que sirven como base para la actividad de construccin delmodelo DRA. La construccin resalta el empleo de componentes de software existente y laaplicacin de la generacin automtica de cdigo. Por ltimo, el despliegue 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 aplicacin denegocios se puede modular deforma que cada gran funcinpueda completarse en menos detres meses (mediante la aplicacindel enfoque ya descrito), sta esuna candidata para el DRA. Cadagran funcin se puede abordarmediante un equipo de DRA porseparado, para despus 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 nmero correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rpidasnecesarias para completar el sistema en un marco de tiempo muy breve, losproyectos DRA fallarn.3) Si un sistema no se puede modular en forma apropiada, la construccin de loscomponentes necesarios para el DRA ser problemtica.4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertirinterfaces 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)

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 5 de 18 Modelos 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 conclusin de un producto completo, porlo que debe presentar una versin

limitada para liberar la presin competitiva y denegocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, perotodava 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 diseado de manera explicita para incluir un producto que evolucione con eltiempo.Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten quelos 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 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 debera tomar lainteraccin 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 deproceso independiente, se emplea ms comnmente como una tcnica 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 construccinde prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera calser el resultado de la construccin cuando los requisitos estn satisfechos.El paradigma de construccin de prototipos seinicia con la comunicacin. El ingeniero de software y elcliente encuentran y definen los objetivos globales parael software, identifican los requisitos conocidos y lasreas del esquema en donde es necesaria msdefinicin. Entonces se plantea con rapidez unaiteracin de construccin de prototipos y se presenta elmodelado (en la forma de un diseorpido). El diseo rpido se centra en unarepresentacin de aquellos aspectos delsoftware que sern visibles para el cliente o el usuariofinal (por ejemplo, la configuracin de la interfaz con elusuario y el formato de los despliegues de salida). Eldiseo rpido conduce a la construccin de un prototipo. Despus, el prototipo loevala el cliente/usuario y con la retroalimentacin se refinan los requisitos del softwareque se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 6 de 18 satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrolladorentienda mejor lo que se debe hacer.De manera ideal, el prototipo debera

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, etctera) que permiten producirprogramas 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 dese-char. Pero sta tal vez sea una visin idealizada. Es verdad que a los clientes y losdesarrolladores les gusta el paradigma de construccin de prototipos. A los usuarios lesgusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sinembargo, la construccin de prototipos tambin se torna problemtica por las siguientesrazones:1. El cliente ve lo que parece una versin 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 aplicacin de "unos pequeos ajustes para que se puedaelaborar un producto final a partir del prototipo. Es muy frecuente que la gestin deldesarrollo de software sea muy lenta.2. A menudo, el desarrollador establece compromisos de implementacin para lograrque el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo olenguaje 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 yolvide las razones por las que son inapropiadas. La seleccin menos ideal ahora seconvierte en una parte integral del sistema.A pesar de que tal vez surjan problemas, la construccin de prototipos puede serun paradigma efectivo para la ingeniera 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 definicin derequisitos, en que se descarte, al menos en parte, y en que despus se desarrolle elsoftware real con un enfoque hacia la calidad.

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 7 de 18 El modelo en espiral. El modelo en espiral, que Boehm [BOE88] propuso originalmente, es un modelo deproceso de software evolutivo que conjuga la naturaleza iterativa de la construccin deprototipos 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 dentregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documentodel modelo o un prototipo. Durante las ltimas iteraciones se producen versiones cada vezms completas del sistema desarrollado.Un proceso en espiral se divide en un conjunto de actividades del marco de trabajoque define el equipo de ingeniera delsoftware. Para propsitos ilustrativos seaprovechan las actividades genricas delmarco de trabajo expuestas pginas atrs. 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 unadireccin en el sentido del movimiento de lasmanecillas del reloj, y que se inicia desde elcentro. El riesgo es un factor considerado en cada revolucin. Los puntos de fijacin unacombinacin 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-cificacin del producto; los pasos subsecuentes alrededor de la espiral se puedenaprovechar para desarrollar un prototipo y despus, en forma progresiva, versiones mselaboradas del software. Cada paso a travs de la regin de planeacin resulta en ajustesal plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentacinderivada de la relacin con el cliente despus de la entrega. Adems, el administrador delproyecto ajusta el nmero 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 podra representarun "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y