Paradigmas de desarrollo de software

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

1. Modelo Incremental

1.1. Caracteristicas

1.1.1. Ventajas

1.1.1.1. Para desarrollos donde no se determinen de forma clara los requerimientos de usuario al comenzar el sistema.

1.1.2. Desventajas

1.1.2.1. El problema de este modelo radica en que los errores en los requisitos propuestos se detectan tarde y su corrección resulta tan costosa como en el modelo en cascada.

2. Modelo en Espiral

2.1. Caracteristicas

2.1.1. Ventajas

2.1.1.1. Mientras los costos del modelo aumentan, los riesgos de proyecto disminuyen.

2.1.1.2. Buen control sobre el desarrollo del proyecto.

2.1.2. Desventajas

2.1.2.1. Es un modelo complicado.

2.1.2.2. Exige desarrolladores con mucha experiencia para manejar la complejidad de los problemas que enfrenta.

2.2. Aplicable para

2.2.1. El modelo espiral es aplicable a proyectos donde no se trabaje bajo contrato, es decir, proyectos que no involucren fuentes externas de software.

3. Modelo de Desarrollo Concurrente

3.1. Caracteristicas

3.1.1. El modelo de proceso concurrente define una serie de acontecimientos que disparan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones [SHE94]: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con dos: diseño y realización. La concurrencia se logra de dos formas: Las actividades de sistemas y de componentes ocurren simultáneamente y pueden moderarse con el enfoque orientado a objetos descrito anteriormente. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

3.2. Aplicable Para

3.2.1. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

4. Modelos en Función de Prototipos

4.1. Caracteristicas

4.1.1. Ventajas

4.1.1.1. Permite la retroalimentación por parte del usuario.

4.1.1.2. El usuario se siente parte del grupo.

4.1.1.3. Desarrollo rápido.

4.1.2. Desventajas

4.1.2.1. El desarrollador debe dar forma prematuramente a un sistema, incluso antes de comprender de manera básica el problema y su funcionamiento.

4.1.2.2. El usuario puede creer que un prototipo es un software final.

4.2. Aplicables Para

4.2.1. El paradigma de prototipos es aplicable a proyectos de análisis acelerado, donde sólo se cuente con requisitos generales; a proyectos con clientes impacientes de ver algo funcionando; a proyectos con clientes dispuestos a reaccionar abiertamente con el prototipo. No es recomendable aplicarlo a proyectos con clientes exigentes de calidad, pues los prototipos son susceptibles a muchos fallos, y el cliente se puede formar una idea equivocada de la seriedad del desarrollador.

5. Modelo de Desarrollo rápido de Aplicación (DRA)

5.1. Caracteristacas

5.1.1. Desventajas

5.1.1.1. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.

5.1.1.2. DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para complementar un sistema en un marco de tiempo abreviado. Si o hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.

5.2. Aplicable para

5.2.1. No todos los tipos de aplicaciones son apropiados para DRA. No es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperatividad con programas de computadora ya existentes. DRA enfatiza el desarrollo de componentes de programas reutilizables.