1. Incrementales
1.1. Descripcion
1.1.1. Propuesto por Harlan Mills en el año 1980, consiste en crear funcionalidad por pequeña que sea para que a partir de ella, las creaciones posteriores, tendrán características características funcionales, lo cual hace que se constituya en base a elementos que funcionan y que va siendo cada vez más compleja su funcionalidad. Surgió el como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.
1.1.1.1. Características
1.1.1.1.1. Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia
1.1.1.1.2. El usuario se involucra mas.
1.1.1.1.3. Difícil de evaluar el costo total.
1.1.1.1.4. Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
1.1.1.1.5. Requiere gestores experimentados.
1.1.1.1.6. Los errores en los requisitos se detectan tarde.
1.1.1.1.7. El resultado puede ser positivo.
1.2. Ventajas
1.2.1. Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
1.2.2. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
1.2.3. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
1.2.4. Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
1.3. Desventajas
1.3.1. 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.
1.3.2. Requiere de mucha planeación, tanto administrativa como técnica y requiere de metas claras para conocer el estado del proyecto.
2. Basado en Componentes
2.1. Descripción
2.1.1. El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software.
2.2. Ventajas
2.2.1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
2.2.2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
2.2.3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
2.2.4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
2.3. Desventajas
2.3.1. Genera mucho tiempo en el desarrollo del sistema - Modelo costoso –Requiere experiencia en la identificación de riesgos
2.3.2. Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil).
3. RUP
3.1. Descripción
3.1.1. El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administración del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.
3.1.1.1. Características
3.1.1.1.1. Dirigido por casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema
3.1.1.1.2. La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo
3.1.1.1.3. Maneja una serie de entregas ejecutables e Integra continuamente la arquitectura para producir nuevas versiones mejoradas
3.1.1.1.4. Conceptualmente amplio y diverso
3.1.1.1.5. Enfoque orientado a objetos
3.1.1.1.6. En evolución continua, Adaptable, Repetible Permite medición de estimación de costos y tiempo, nivel de avance, etc.
3.2. Ventajas
3.2.1. Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios).
3.2.2. Disminuye la brecha semántica entre la visión interna y la visión externa del sistema.
3.2.3. Mantenimiento más sencillo. Modificaciones locales.
3.3. Desventajas
3.3.1. Método Pesado
3.3.2. Por el grado de complejidad puede ser no muy adecuado.
3.3.3. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.
4. Concurrente
4.1. Descripción
4.1.1. se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes.
4.1.1.1. Formas de Concurrencia
4.1.1.1.1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos.
4.1.1.1.2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.
4.2. Ventajas
4.2.1. Excelente para proyectos en los que se conforman grupos de trabajo independientes.
4.2.2. Proporciona una imagen exacta del estado actual de un proyecto.
4.3. Desventajas
4.3.1. Si no se dan las condiciones señaladas no es aplicable.
4.3.2. Si no existen grupos de trabajo no se puede trabajar en este método
5. Unificado
5.1. Descripción
5.1.1. El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad.
5.1.1.1. Fases
5.1.1.1.1. Fase de concepción
5.1.1.1.2. Fase de elaboración
5.1.1.1.3. Fase de construcción
5.1.1.1.4. Fase de transición
5.2. Ventajas
5.2.1. Coste del riesgo a un solo incremento.
5.2.2. Reduce el riesgo de no sacar el producto en el calendario previsto.
5.2.3. Acelera el ritmo de desarrollo.
5.2.4. Se adapta mejor a las necesidades del cliente.
5.3. Desventajas
5.3.1. Todo el proceso como tal, se encuentra muy ligado al método, lo que puede ocasionar inconvenientes al tratar de combinar con otras metodologías.
5.3.2. A pesar de su desarrollo, el método aún no incluye una metodología totalmente explícita para el control de las actividades de gestión.
6. DRA
6.1. Descripcion
6.1.1. El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto
6.1.1.1. Etapas
6.1.1.1.1. Modelado de Gestion
6.1.1.1.2. Modelado de Datos
6.1.1.1.3. Modelado del proceso
6.1.1.1.4. Generación de aplicaciones
6.1.1.1.5. Prueba y estrega
6.2. Ventajas
6.2.1. Es muy rapido
6.2.2. Permite trabajar con varias personas a la vez
6.3. Desventajas
6.3.1. Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán.
6.3.2. El DRA sería inapropiado cuando los riesgos técnicos son altos.
7. Espiral
7.1. Descripción
7.1.1. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
7.1.1.1. Tipos
7.1.1.1.1. Modelo Original de Boehm.
7.1.1.1.2. Modelo Típico de Seis Regiones.
7.1.1.1.3. Modelo WINWIN.
7.2. Ventajas
7.2.1. El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
7.2.2. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
7.2.3. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
7.2.4. El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
7.2.5. En la utilización de grandes sistemas a doblado la productividad.
7.3. Desventajas
7.3.1. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
7.3.2. Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
7.3.3. Genera mucho tiempo en el desarrollo del sistema
7.3.4. Requiere experiencia en la identificación de riesgos
8. Prototipo
8.1. Descripción
8.1.1. Este modelo se utilizan para dar al usuario una vista preliminar de parte del software, es prueba y error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho, el prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.
8.1.1.1. Etapas
8.1.1.1.1. Recolección y refinamiento de requisitos
8.1.1.1.2. Modelado, diseño rápido
8.1.1.1.3. Construcción del Prototipo
8.1.1.1.4. Desarrollo, evaluación del prototipo por el cliente
8.1.1.1.5. Refinamiento del prototipo
8.1.1.1.6. Producto de Ingeniería
8.2. Ventajas
8.2.1. No modifica el flujo del ciclo de vida
8.2.2. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios
8.2.3. Reduce costo y aumenta la probabilidad de éxito
8.2.4. Exige disponer de las herramientas adecuadas
8.2.5. 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.
8.3. Desventajas
8.3.1. Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.
8.3.2. El desarrolador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente