Modelos de desarrollo de software

Get Started. It's Free
or sign up with your email address
Modelos de desarrollo de software by Mind Map: Modelos de desarrollo de software

1. Desarrollo evolutivo

1.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. Cambio Continuo. Un programa que se utiliza en un ambiente del mundo real debe cambiar o será cada vez menos útil en ese ambiente. 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. 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. 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. 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.

2. 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. Ingeniería y análisis del sistema. Interrelación con hardware, personas, bases de datos. (Documentar cada paso.) 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. Diseño. La estructura de los datos, la arquitectura del sw, el detalle procedimental, y la caracterización de la interfase. Codificación. Traducir el diseño para que lo entienda la máquina. Prueba. Cuando ya se ha generado el código. Mantenimiento. El software sufrirá cambios después de que se entregue al cliente

3. Modelo DRA

3.1. El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de softwareincremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a"alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción 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 días) Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenéricas del marco de trabajo que ya se han presentado. La comunicación trabaja paraentender el problema de negocios y las características de información que debe incluir elsoftware. La planeación 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 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

4. Modelo PSC

4.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: Pragmática Visualiza al sistema en el contexto de su ambiente. Entrada/Salida Estudia el comportamiento externo del sistema y c6mo va a ser adquirido. Constructiva Examina el sistema en terminos de una colecci6n de fun-clones y recursos. Operativa Estudia el comportamiento interno del sistema.

5. modelo espiral

5.1. El modelo Espiral de Boehm para Ingeniería de Software agrupa las mejores características del modelo del ciclo de vida clásico y de prototipos. Pero también agrega nuevas funciones que no están incluidas en los otros modelos, como el análisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida. Planificación La determinación de los objetivos del proyecto, alternativas y restricciones. Análisis de Riesgo El análisis de alternativas y la identificación y solución de riesgos. Ingeniería Desarrollo del producto. Evaluación del cliente El asentimiento de los resultados de la ingeniería.

5.2. El modelo Espiral de Boehm para Ingeniería de Software agrupa las mejores características del modelo del ciclo de vida clásico y de prototipos. Pero también agrega nuevas funciones que no están incluidas en los otros modelos, como el análisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida. Planificación La determinación de los objetivos del proyecto, alternativas y restricciones. Análisis de Riesgo El análisis de alternativas y la identificación y solución de riesgos. Ingeniería Desarrollo del producto. Evaluación del cliente El asentimiento de los resultados de la ingeniería.

6. Desarrollo orientado a prototipos

6.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:

6.2. Investigación preliminar Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.

6.3. Definición de los requerimientos del sistema El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.

6.4. Diseño técnico Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.

6.5. Programación y prueba 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.

6.6. Operación y mantención La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al 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, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.

6.7. Análisis grueso y especificación El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial

6.8. Diseño y construcción El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.

6.9. Evaluación Esta etapa tiene dos propósitos: extraer a 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. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.

6.10. Modificación Esto ocurre cuando la definición de requerimientos del sistema es alterada en la subfase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.

6.11. 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 de el sistema.