Mi Nuevo Modelos de Desarrollo del Software

1. Modelo DRA

1.1. El desarrollo rápido de aplicaciones o RAD por sus siglas en ingles Rapid Application Development. El RAD es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

1.2. El modelado 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. La construcción resalta el empleo de componentes de software existente y laaplicación de la generación automática de código. Por último, el despliegue establece unabase para las iteraciones subsecuentes, si éstas son necesarias

2. Modelo de cascada

2.1. Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

2.2. Ingeniería y análisis del sistema. Interrelación con hardware, personas, bases de datos. (Documentar cada paso.)

2.3. Análisis de los requisitos del software. Hay que comprender el ámbito de la información del software, así como la función, el rendimiento y las interfases requeridas.

2.4. Diseño. La estructura de los datos, la arquitectura del sw, el detalle procedimental, y la caracterización de la interfase.

2.5. Codificación. Traducir el diseño para que lo entienda la máquina.

2.6. Prueba. Cuando ya se ha generado el código.

2.7. Mantenimiento. El software sufrirá cambios después de que se entregue al cliente.

3. Desarrollo Orientado a Prototipos

3.1. Una definición de un prototipo en software podría ser: Las fases que comprende el método de desarrollo orientado a prototipos serían:

3.2. Investigación preliminar En esta etapa lo esencial es determinar el problema y su ámbito, la importancia y los efectos potenciales que tendrán sobre la organización, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.

3.3. Definición de los requerimientos del sistema Esta es la fase mas importante de todo el ciclo de vida del método de prototipos, el objetivo en esta fase es determinar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto que se esta deseando implementar.

3.4. Análisis de los requerimientos Esta etapa es un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. Para la definición de los requerimientos tenemos cinco etapas entre dos de las cuales se establece un ciclo interactivo Análisis grueso y especificación En esta fase se busca desarrollar un diseño básico para el prototipo inicial. Diseño y construcción Lo que se consigue en esta fase en obtener un prototipo inicial, aquí el desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interfaz del usuario. Evaluación Los objetivos de esta etapa son obtener por parte de los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. En el saco de que los usuarios identifiquen fallas en el prototipo el desarrollador corrige dichas fallas antes de continua con la siguiente evaluación. Se modifica y se evalúa cuantas veces sea necesario hasta que los requerimientos del sistemas sean satisfechos. En el proceso de evaluación se efectúan cuatro pasos separados: Preparación. Demostración. Uso del prototipo. Discusión de comentarios. Esta es la fase en donde se decide si el prototipo es aceptado o modificado. Modificación Se da cuando la definición de requerimientos del sistema es alterada en la etapa de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios. Término Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema.

3.5. Diseño técnico En esta etapa el sistema debe ser rediseñado y tener la respectiva documentación guiándose en los estándares que tiene la organización la cual servirá como ayuda en mantenciones futuras del mismo. En este punto existen dos etapas: Producción de una documentación de diseño la cual especifica y describe la estructura del software, interfaces de usuario, funciones y el control de flujo. Producción de todo lo requerido para promover cualquier mantención futura del software.

3.6. Programación y prueba En esta etapa es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos. Las pruebas serán de realizarse tantas veces sea necesarias para verificar cualquier tipo de anomalía en el sistema.

3.7. Operación y mantención En esta fase se realiza ya la instalación y mantención del software, la complejidad en esta caso resulta menor ya que en las etapas anteriores los usuarios han trabajado con el sistemas al momento de hacer las pruebas de prototipos, además la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, mediante lo cual las mantaciones perfectivas se reducirían. Si existiese el caso en el cual se requiera una manutención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.

4. Modelo Espiral

4.1. Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,

4.2. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

4.3. En cada vuelta o iteración hay que tener en cuenta: Los Objetivos: qué necesidad debe cubrir el producto. Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: Características: experiencia del personal, requisitos a cumplir, etc. Formas de gestión del sistema. Riesgo asumido con cada alternativa. Desarrollar y Verificar: Programar y probar el software.

4.4. Ventajas El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc. Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

5. Modelo PSC

5.1. Este modelo toma otro enfoque, igualmente valido, para la modelaci6n del proceso de desarrollo al aceptar que varios puntos de vista o perspectivas sean considerados. Las principales perspectivas descritas dentro del FSC son:

5.2. Pragmática Visualiza al sistema en el contexto de su ambiente.

5.3. Entrada/Salida Estudia el comportamiento externo del sistema y c6mo va a ser adquirido.

5.4. Constructiva Examina el sistema en terminos de una colecci6n de fun-clones y recursos.

5.5. Operativa Estudia el comportamiento interno del sistema.

6. Desarrollo Evolutivo

6.1. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

6.2. Cambio Continuo. Un programa que se utiliza en un ambiente del mundo real debe cambiar o será cada vez menos útil en ese ambiente.

6.3. Complejidad creciente. A medida que un programa en evolución cambia, su estructura se hace más compleja, a menos que se lleven a cabo esfuerzos activos para evitar este fenómeno.

6.4. Evolución del programa. La evolución del programa es un proceso autorregulador, y una medición de atributos del sistema, como el tamaño, el tiempo entre versiones, el número de errores advertidos, etc., revela las tendencias estadísticas significativas y las características invariantes.

6.5. Conservación de la estabilidad organizativa. Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi constante e independiente de los recursos dedicados al desarrollo del sistema.

6.6. Conservación de la familiaridad. Durante el tiempo de vida de un sistema, la evolución del cambio del sistema en cada versión es, aproximadamente, constante.