METODOLOGIAS DE DISEO El software evoluciona con el tiempo.

Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se aconsejable introducir una versin funcional limitada de alguna forma para aliviar las presiones competitivas. Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin. Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo. Esta familia de modelos se utiliza en las siguientes circunstancias: Si los requisitos cambian conforme el desarrollo avanza. Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versin limitada. Si los requisitos centrales estn bien definidos pero todava hay que definir los detalles de las extensiones del producto

MODELO INCREMENTAL Propuesto por Mills en 1980. -Sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema Caractersticas Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.- El usuario se involucre ms.- Difcil de evaluar el costo

total.- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.- Requiere gestores experimentados.- Los errores en los requisitos se detectan tarde.- El resultado puede ser muy positivo. Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.- Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento.Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada.- Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.- Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. El modelo incremental entrega el software en partes pequeos, pero utilizables, llamadas (incrementos). En general, cado incremento se construye sobre aqul que ya ha sido entregado. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detallada).Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se centra 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 precisa y tambin una plataforma para la evaluacin. El desarrollo incremental es particularmente til cuando la personal no est disponible para una implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. Fases

Ventajas: Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico.

Desventajas: El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. Requiere de mucha planeacin, tanto administrativa como tcnica. Requiere de metas claras para conocer el estado del proyecto. Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto Software denominados incrementos del sistema, que son escogidos en base a prioridades predefinidas de algn modo. El modelo permite una implementacin con refinamientos sucesivos (ampliacin y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software.

MODELO ESPIRAL El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa con los aspectos controlados y sistemticos del Modelo Cascada. Proporciona potencial para desarrollo rpido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versin incremental podra ser un modelo en papel o bien un prototipo. En las ltimas iteraciones se producen versiones cada vez ms completas del sistema diseado. Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos.

Cada mini proyecto se centra en uno o ms riesgos importantes hasta que todos estn controlados. Despus de controlar todos los riesgos ms importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada. Caractersticas Trata de mejorar los ciclos de vida clsicos y prototipos. Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo). En cada giro se construye un nuevo modelo del sistema completo. El anlisis de riesgo requiere la participacin de personal con alta cualificacin. Incorpora objetivos de calidad y gestin de riesgos Elimina errores y alternativas no atractivas al comienzo Permite iteraciones, vuelta atrs y finalizaciones rpidas Cada ciclo empieza identificando: Los objetivos de la porcin correspondiente Las alternativas Restricciones Este modelo se caracteriza por optimizar los tiempos y reducir la incertidumbre del proyecto, partiendo de un pequeo segmento del sistema en funcionamiento, para luego continuar en la creacin de una segunda parte conectada a la anterior, y as construir una nueva interaccin, con una versin aumentada del sistema hasta que se concluye con un nivel de maduracin que permita que el trabajo para el que fue creado se realice sin inconvenientes. El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas regiones de tareas. En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado ms reciente.

Fases

Las regiones definidas en el modelo de la figura son: Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el desarrollador. Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra informacin relacionada con el proyecto. Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del proyecto. Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software. Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentacin y prctica). Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado e instalado en los ciclos anteriores.

Ventajas: El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. Desventajas: Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual es requisito para el xito del proyecto. Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo. Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de implementar y controlar.

MODELO ENSAMBLAJE DE COMPONENTES El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases). Esto se debe gracias a que, si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadoras.

Caractersticas En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicacin y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en una biblioteca de clases o depsito. Acto seguido, se determina cules de ellas ya existen a fin de reutilizarlas. El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software Fases

Ventajas: El uso de este paradigma posee algunas ventajas: Reutilizacin del software. Simplifica las pruebas. Simplifica el mantenimiento del sistema. Mayor calidad. La notacin de componentes Diagrama de componentes Interfaces Componentes y los nodos (diagrama de despliegue) Restricciones Anlisis de riesgo

Desventajas Falta de apoyo de las herramientas Sndrome de aqu no se ha inventado Costo de encontrar, entender y adaptar componentes reutilizables

MODELO DESARROLLO CONCURRENTE El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una divisin de sistemas y una divisin de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseo y realizacin. La concurrencia se logra de dos formas: Las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente;

Una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniera de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultneamente con otras. Los sucesos generados dentro de una actividad dada o algn otro lado de la red de actividad inicia las transiciones entre los estados de una actividad. Caractersticas 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. 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 estado Fases

Ventajas Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas Si no se dan las condiciones sealadas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este mtodo.