PARADIGMAS DE DESARROLLO DE SOFTWARE

Just an initial demo map, so that you don't start with an empty map list ...

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. Prototipos

1.1. Etapas Plan rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación Entrega del desarrollo final

1.2. VENTAJAS Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

1.3. DESVENTAJAS El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

2. DRA (Rapid Application Development)

2.1. se usa para describir este proceso de crear sistemas funcionales en un periodo muy corto.

2.2. incluir el uso de programacionvisual y otras herramientas para construirinterfaces graficas de usuario

2.3. Puede permitir el desarrollo de un sistema completamente funcional en periodos cortos de tiempo (de 60 a 90 dias).Los componentes que se desarrollen se pueden reutilizar en posteriores proyectos. (Repositorios de componentes) El sistema se descompone en un conjunto de bloques que se pueden desarrollar de manera independiente por distintos equipos de desarrollo.

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

2.5. DESVENTAJAS -Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. -Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran. -No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. -La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. -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 interoperabilidad con programas de computadora ya existentes. -Enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje

3. Modelo Incremental

3.1. En muchas situaciones los requisitos iniciales del software están bien definidos enforma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un procesopuramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar demanera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla yexpandirla en las entregas posteriores del software. En estos casosse elige un modelo de proceso diseñado para producir el software en forma incremental.

3.2. Ventajas -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 re-alimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. -Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

3.3. Desventajas -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

4. Modelo en Cascada

4.1. -Es el más utilizado. -Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. -Para que el proyecto tenga éxito deben desarrollarse todas las fases. -Las fases continúan hasta que los objetivos se han cumplido. -Si se cambia el orden de las fases, el producto final será de inferior calidad

4.2. VENTAJAS -La Documentación se va produciendo en cada fase. -El Modelo cuadra con otros modelos del proceso de ingeniería.

4.3. DESVENTAJAS -Inflexibilidad : al dividir el proyecto en distintas etapas. -Es difícil responder a cambios en los requerimientos del cliente.

5. Modelo Espiral

5.1. -En cada giro se construye un nuevo modelo del sistema completo. -Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada,evolutivo) -Mejor modelo para el desarrollo de grandes sistemas. -El análisis de riesgo requiere la participaciónde personal con alta cualificación

5.2. VENTAJAS -No necesita una definición completa de los requisitos para empezara funcionar. -Al entregar productos desdeel final de la primera iteración es más fácil validar los requisitos. -El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursosinvertidos en una iteración (las anteriores iteraciones estánbien). -El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempode subsanarlos.

5.3. DESVENTAJAS -Es difícil evaluar los riesgos. -Necesita de la participación continua por parte del cliente. -Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

6. Modelo Concurrente

6.1. Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.

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

6.3. DESVENTAJAS -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