Please enable JavaScript.
Coggle requires JavaScript to display documents.
MODELOS DE PROCESOS DE DESARROLLO - Coggle Diagram
MODELOS DE PROCESOS DE DESARROLLO
EL MODELO EN CASCADA
Este modelo se conoce como “modelo en cascada” o ciclo de vida del software. El modelo en cascada es un, ejemplo de un proceso dirigido por un plan: en principio, usted debe planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas.
Las principales etapas de este sistema son:
1. Análisis y definición de requerimientos
: Los servicios, las restricciones y las metas del
sistema se establecen mediante consulta a los usuarios del sistema.
Diseño del sistema y del software
: El proceso de diseño de sistemas asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global.
Implementación y prueba de unidad
: Durante esta etapa, el diseño de software se realiza como un conjunto de programas o unidades del programa.
Integración y prueba de sistema
: Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software.
Operación y mantenimiento
:
Esta es la fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
DESARROLLO INCREMENTAL
: Se basa en la idea de diseñar una implementación inicial, exponer ésta al comentario del usuario, y luego desarrollarla en sus diversas versiones hasta producir un sistema adecuado.
Los procesos basados en transformaciones formales se usan por lo general sólo en el desarrollo de sistemas críticos para protección o seguridad. Requieren experiencia especializada. Para la mayoría de los sistemas, este proceso no ofrece costo/beneficio significativos sobre otros enfoques en el desarrollo de sistemas.
MODELO GENERAL DEL PROCESO DEL DISEÑO
Sugiere que las etapas del proceso de diseño son secuenciales de he hecho las actividades de proceso de diseño están vinculadas. En todos los procesos de diseño es inevitable la retroalimentación de una etapa a otra y la consecuente reelaboración del diseño.
La mayoría del software tiene interfaz junto con otros sistemas de software. En ellos se incluyen sistema operativo, base de datos, middleware y otros sistemas de aplicación.
Si el sistema debe procesar datos existentes, entonces en la especificación de la plataforma se incluirá la descripción de tales datos; de otro modo, la descripción de los datos será una entrada al proceso de diseño, de manera que se defina la organización del sistema de datos.
Los sistemas de tiempo real precisan del diseño de temporización, pero sin incluir una base de datos, por lo que no hay que integrar un diseño de base de datos,
muestra cuatro actividades que podrían formar parte del proceso de diseño para sistemas de información:
1. Diseño arquitectónico:
Aquí se identifica la estructura global del sistema, los principales componentes (llamados en ocasiones subsistemas o módulos), sus relaciones y cómo se distribuyen.
2. Diseño de interfaz:
Se definen las interfaces entre los componentes de sistemas. Esta especificación de interfaz no tiene que presentar ambigüedades. Con una interfaz precisa, es factible usar un componente sin que otros tengan que saber cómo se implementó.
3. Diseño de componentes:
se toma cada componente del sistema y se diseña cómo funcionará. Esto puede ser un simple dato de la funcionalidad que se espera implementar, y al programador se le deja el diseño específico, habría una lista de cambios a realizar sobre un componente que se reutiliza o sobre un modelo de diseño detallado.
4. Diseño de base de datos:
Donde se diseñan las estructuras del sistema de datos y cómo se representarán en una base de datos, el trabajo aquí depende de si una base de datos se reutilizará o se creará una nueva.
Los métodos estructurados para el diseño se desarrollaron en las décadas de 1970 y 1980, y fueron precursores del UML y del diseño orientado a objetos (Budgen, 2003).
MODELO EN ESPIRAL DE BOEHM DEL PROCESO DE SOFTWARE
4. Planeación:
Se revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral. Un ciclo de la espiral comienza por elaborar objetivos como rendimiento y funcionalidad. Luego, se numeran formas alternativas de alcanzar dichos objetivos y de lidiar con las restricciones en cada uno de ellos. Cada alternativa se valora contra cada objetivo y se identifican las fuentes de riesgo del proyecto.
Cada ciclo en la espiral se divide en cuatro sectores:
1. Establecimiento de objetivos
: Se identifican restricciones en el proceso y el producto, y se traza un plan de gestión detallado, los riesgos del proyecto. Pueden planearse estrategias alternativas, según sean los riesgos
2. Valoración y reducción del riesgo:
Se realiza un análisis minucioso. Se dan acciones para reducir el riesgo. Por ejemplo, si existe un riesgo de que los requerimientos sean inadecuados, puede desarrollarse un sistema prototipo.
3. Desarrollo y validación:
Después de una evaluación del riesgo, se elige un modelo de desarrollo para el sistema. Por ejemplo, la creación de prototipos desechables sería el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del usuario.
La diferencia principal entre el modelo en espiral con otros modelos de proceso de software es su reconocimiento explícito del riesgo, comienza por elaborar objetivos como rendimiento y funcionalidad. Luego, se numeran formas alternativas de alcanzar dichos objetivos y de lidiar con las restricciones en cada uno de ellos.
Se valora contra cada objetivo y se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver dichos riesgos, mediante actividades de recopilación de información, como análisis más detallado, creación de prototipos y simulación.
Los riesgos conducen a propuestas de cambios de software y a problemas de proyecto como exceso en las fechas y el costo, de manera que la minimización del riesgo es una actividad muy importante de administración del proyecto.
