Modelos de desarrollo

Modelo Prescriptivo De Proceso Se propusieron originalmente para ordenar el caos del desarrollo de software, la historia indico que estos han trado consigo cierta cantidad de estructuras tiles para el trabajo en la ingeniera del software. Define un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que requieren para desarrollar software de alta calidad. Los ingenieros de software y sus gerentes adaptan un modelo prescriptivo de proceso a sus necesidades y despus la siguen. El proceso conduce a un equipo de software a travs de un conjunto de actividades del marco de trabajo que se organiza en un flujo de proceso el cual puede ser lineal incremental o evolutivo. Modelos Prescriptivos

Llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingeniera del software. Sin importar el modelo del proceso seleccionado eligen un marco de trabajo genrico para el proceso el cual incluye las siguientes actividades dentro del marco: Comunicacin Planeacin Modelado Construccin Desarrollo El modelo de prescriptivos prescriben un conjunto de elementos del proceso: actividades del marco de trabajo, acciones de ingeniera del software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos del control de cambio para cada proyecto.

Modelo De Cascada 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 del modelado, la construccin y el despliegue para culminar con el soporte del software terminado. Los problemas al aplicar el modelo cascada son: Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. Con frecuencia es difcil para el cliente establecer todos los requerimientos de manera explicita. El cliente debe tener paciencia.

Modelo De Proceso Incremental Cuando existe una necesidad de proporcionar de manera rpida un conjunto limitado de funcionalidad por 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. Incremental Entrega una serie de lanzamientos, llamados incrementos que proporcionan en forma progresiva ms funcionalidad para los clientes a medida que se entrega cada uno de los incrementos. El cliente demanda la entrega en una fecha imposible de cumplir, sugiera su entrega uno o ms incrementos para esa fecha y el resto del software despus. Modelo DRA

El desarrollo rpido de aplicaciones 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 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. 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 software existente y la aplicacin de la generacin automtica de cdigo. Por ultimo, el despliegue establece una base para las iteraciones subsecuentes, si estas son necesarias. Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes como por ejemplo: -Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear el nmero correcto de equipos DRA. -Si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar el sistema en un marco de tiempo breve, los proyectos de DRA fallarn. -Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios para el DRA ser problemtica. -Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfaces en componentes del sistema, el enfoque DRA podra no funcionar. -El DRA seria inapropiado cuando los riesgos tcnicos son altos, por ejemplo cuando una aplicacin nueva aplica muchas nuevas tecnologas.

Modelo De Procesos 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.

Construccin De Prototipos 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 de ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer. De manera ideal, el prototipo 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? 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 resuelven estos problemas Cuando se aplica un concepto nuevo de sistema o una tecnologa nueva, se tiene que construir un sistema inservible 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 esta 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 una problemtica por algunas razones como que el cliente ve lo que parece una versin en funcionamiento del software sin saber que el prototipo esta unido con chicle y cable para embalaje, que por la prosa 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. Conclusiones: Los modelos de desarrollo son necesarios para crear software de alta calidad, para lograr ese objetivo tenemos que considerar ciertos puntos como la planeacin, el modelado, la construccin y el desarrollo. Los modelos de desarrollo nos dan la facilidad de aprender a planear un proyecto para que sea eficiente, eficaz y con una larga trayectoria de vida.