Modelos

1. Modelo DRA (Desarrollo Rápido de Aplicaciones)

1.1. El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos muy cortos de tiempo.

1.1.1. Modelado de Gestión: aquí se modela el flujo de información entre las funciones de gestión. Este flujo debe "responder" a preguntas tales como ¿Qué información conduce el proceso de gestión?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?

1.1.2. Modelado de datos: se definen las características (atributos) de cada objeto, formado a partir del flujo de información, y las relaciones entre ellos.

1.1.3. Modelado del proceso: las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.

1.1.4. Generación de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables.

1.1.5. Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno de los nuevos componentes.

1.2. Ventajas

1.2.1. - Es muy rápido. - Permite trabajar en él a varias personas a la vez

1.3. Desventajas

1.3.1. - El enfoque DRA tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos para crear el numero correcto de equipos. - Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán. - El DRA sería inapropiado cuando los riesgos técnicos son altos.

2. Modelo Incremental

2.1. El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema.

2.1.1. Características: Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia. El usuario se involucra mas. Dificil de evaluar el costo total. Dificil 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 positivo.

2.1.2. Ventajas

2.1.2.1. - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - También 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 sólo al ámbito de cada incremento. - Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

2.1.3. Desventajas

2.1.3.1. - 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 planeación, tanto administrativa como técnica. - Requiere de metas claras para conocer el estado del proyecto.

3. Modelo Espiral

3.1. Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada. El modelo en espiral fue desarrollado por Boehm, quien lo describe así: El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios. Se caracteriza principalmente por: Ø Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo. Ø Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

3.1.1. Comunicación con el cliente.

3.1.1.1. Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.

3.1.2. Planificación.

3.1.2.1. Las tareas requeridas para definir recursos, tiempos e información relacionada con el proyecto.

3.1.3. Análisis de riesgos.

3.1.3.1. Las tareas requeridas para evaluar riesgos técnicos y de gestión.

3.1.4. Construcción y adaptación.

3.1.4.1. Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

3.1.5. Evaluación del cliente.

3.1.5.1. Las tareas requeridas para obtener la reacción del cliente, según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación

3.1.6. Ingeniería

3.1.6.1. - Las tareas requeridas para construir una o más representaciones de la aplicación

4. Construccion de Prototipos

4.1. Pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado.

4.1.1. Etapas

4.1.1.1. + Plan rápido + Modelado, diseño rápido + Construcción del Prototipo + Desarrollo, entrega y retroalimentación + Comunicación

4.1.2. Pasos para la construccion de prototipos

4.1.2.1. Paso 1

4.1.2.1.1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que: 1) El cliente participe en la evaluación y refinamiento del prototipo. 2) El cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente,la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.

4.1.2.2. Paso 2

4.1.2.2.1. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.

4.1.2.3. Paso 3

4.1.2.3.1. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.

4.1.2.4. Paso 4

4.1.2.4.1. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre- maquina usando una serie de hojas de historia.

4.1.2.5. Paso 5

4.1.2.5.1. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.

4.1.2.6. Paso 6

4.1.2.6.1. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) El propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación, 2) El propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y ambos crean problemas.

5. Modelo Concurrente

5.1. El Modelo de Desarrollo Concurrente conocido además como Ingeniería Concurrente dado por Davis Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

5.1.1. Características:

5.1.1.1. • las actividades llevan procesos concurrentes • es aplicable a todo tipo de desarrollo de software • es un modulo aplicable para cliente soñador • esta dirigido por las necesidades del usuario • es aplicable al cliente servidor

5.1.2. Ventajas

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

5.1.3. Desventajas

5.1.3.1. Si no se dan las condiciones señaladas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este método

6. Modelo Unificado

6.1. El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

6.1.1. Fase de concepción

6.1.1.1. Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones.

6.1.2. Fase de elaboración

6.1.2.1. En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

6.1.3. Fase de construcción

6.1.3.1. El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

6.1.4. Fase de transición

6.1.4.1. El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

7. Modelo basado en componentes

7.1. El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).

7.1.1. La Notación de Componentes

7.1.1.1. Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio.

7.1.2. El Diagrama de Componentes

7.1.2.1. El diagrama de componentes muestra la relación entre componentes de software, sus dependencias, su comunicación su ubicación y otras condiciones.

7.1.3. Interfaces

7.1.3.1. Los componentes también pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente está ofreciendo y dejando disponibles a otros componentes de software y clases. Típicamente, un componente está compuesto por numerosas clases y paquetes de clases internos. También se puede crear a partir de una colección de componentes más pequeños.

7.1.4. Los componentes y los Nodos

7.1.4.1. Un diagrama de despliegue muestra el despliegue físico del sistema en un ambiente de producción (o de prueba). Muestra dónde se ubican los componentes, en qué servidores, máquinas o hardware. Puede representar los enlaces de redes.

7.1.5. Restricciones

7.1.5.1. Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna función; las post-condiciones indican lo que debe ser verdadero después de que un componente haya realizado algún trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.