1. Definición
1.1. Es una agrupación de métodos, herramientas y procedimientos con el fin de describir un modelo.
1.2. La estrategia a menudo se llamada modelo de proceso o paradigma de ingeniería del software.
2. Modelo de Desarrollo Concurrente
2.1. Definido por Davis y Sitaram [DAV94], el modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas, y estados asociados a ellas.
2.2. 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.
2.3. 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.
2.4. La concurrencia se logra de dos formas:
2.4.1. 1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden moderarse con el enfoque orientado a objetos descrito anteriormente.
2.4.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.
3. Modelo Scrum
3.1. SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
3.2. Roles Principales del Scrum:
3.2.1. Product Owner: Representa la voz del cliente, se asegura que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio.
3.2.1.1. ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint.
3.2.1.1.1. Equipo de desarrollo:Tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
3.3. Roles Auxiliares del Scrum
3.3.1. Stakeholders (Clientes, Proveedores, Vendedores, etc): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
3.3.1.1. Administradores (Managers): Es la gente que establece el ambiente para el desarrollo del producto.
3.4. Características: Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada.
3.5. Ventajas y Beneficios del Modelo Scrum:
3.5.1. Flexibilidad a cambios, Reducción del Time to Market, Mayor calidad del software, Mayor productividad, Maximizar el retorno de la inversión, Predicciones de tiempos y Reducción de riesgos
4. Modelo XP, Programación extrema
4.1. Es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
4.2. Características:
4.2.1. Desarrollo iterativo e incremental, Pruebas unitarias continuas, Programación en parejas, Frecuente integración del equipo de programación con el cliente o usuario, Corrección de todos los errores, Refactorización del código, Propiedad del código compartido y simplicidad del código.
4.3. Roles del Modelo XP
4.3.1. Programador
4.3.2. Escribe las pruebas unitarias y produce el código del sistema.
4.3.3. Cliente
4.3.4. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.
4.3.5. Tester
4.3.6. Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
4.3.7. Tracker
4.3.8. Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
4.3.9. Entrenador (coach)
4.3.10. Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.
4.3.11. Consultor
4.3.12. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico.
4.3.13. Gestor (Big boss)
4.3.14. Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.
5. Modelo DAS - Desarrollo adaptativo del software
5.1. El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith 1998 como una técnica para construir software y sistemas complejos. Los apoyos filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo.
5.2. Fases del Modelo DAS
5.2.1. Especulación, colaboración y aprendizaje
5.3. ASD resalta que las aproximaciones secuenciales en cascada solo funcionan en entornos bien conocidos. Pero como los cambios ocurren frecuentemente en el desarrollo software, es importante usar un método tolerante a cambios. El primer ciclo de un proyecto ASD suele ser corto, asegurando que el cliente está involucrado y confirmando la viabilidad del proyecto. Cada ciclo termina con una revisión en grupo enfocada al cliente. Durante las reuniones de revisión, se estudia la aplicación funcionando. El resultado de las reuniones son peticiones de cambio documentadas.
6. Lenguaje Unificado de Modelado (UML)
6.1. Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group).
6.2. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
6.3. CARACTERÍSTICAS DEL UML
6.3.1. UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.
6.3.2. UML permite describir un sistema en diferentes niveles de abstracción, simplificando la complejidad sin perder información, para que tanto usuarios, líderes y desarrolladores puedan comprender claramente las características de la aplicación.
6.3.3. UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.
6.3.4. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.
7. MAPA MENTAL - MODELOS DE LOS PARADIGMAS DE DESARROLLO DE SOFTWARE INTEGRANTES Heidy Tatiana Tovar Pulido Cristian Camilo Sterling Lasso
8. Modelo Lineal secuencial o de cascada
8.1. Es un proceso de desarrollo secuencial en el que los pasos de desarrollo son vistos hacía abajo, de manera vertical.
8.2. Es el paradigma más antiguo y fue el más utilizado durante la hegemonía del método estructurado. El número de etapas propuestas varía de acuerdo al proyecto a desarrollar, aunque existen etapas comunes para este paradigma. La primera descripción formal del modelo fue citada en un artículo publicado por Winston Royce en 1970.
8.3. Las Fases: Análisis de las necesidades, el diseño, implantación, pruebas, integración, pruebas y mantenimiento.
8.4. Ventajas:
8.4.1. - Permite un mejor control de cada actividad, en cuanto a fechas de entrega, costos, revisiones y productos desarrollados. - Minimiza los gastos de la planificación del proyecto.
8.5. Desventajas:
8.5.1. - Los proyectos de software rara vez siguen un flujo secuencial. - No involucra al usuario en el desarrollo del producto. - Requiere mucho tiempo para el desarrollo del proyecto. - Si el usuario olvida especificar un requerimiento se incurre un elevado costo.
9. Modelo en Función de Prototipos
9.1. Busca definir los objetivos globales del sistema para luego refinar en conjunto con el cliente los requisitos específicos.
9.2. El paradigma de la elaboración por prototipos resulta una alternativa para el desarrollo rápido de aplicaciones de software; pues el analista acorta en tiempo entre la determinación de los requerimientos de información y la entrega de un sistema funcional, además que el usuario podrá modificar y depurar sus requerimientos conforme avance el desarrollo del proyecto.
9.3. Las Fases: Escuchar al cliente, Construir/Revisar Prototipo y Fase de Prueba por el cliente.
9.4. Ventajas:
9.4.1. - Permite la retroalimentación por parte del usuario. - Desarrollo rápido. - El usuario se siente parte del grupo.
9.5. Desventajas
9.5.1. - El desarrollador debe dar forma prematuramente a un sistema, incluso antes de comprender de manera básica el problema y su funcionamiento. - El usuario puede creer que un prototipo es un software final.
10. Modelo Espiral
10.1. Planifica las actividades de cada ciclo en función de un objetivo específico y del análisis de riesgo de las alternativas disponibles para alcanzar dicho objetivo.
10.2. Este enfoque le entrega al proceso una gran capacidad de responder ante eventuales cambios en los requisitos en cualquier etapa del desarrollo del software, y le entrega al análisis de riesgo, un rol fundamental en la toma de decisiones, lo que permitiría mantener acotados los costos y la duración de un proyecto informático.
10.3. Propuesto por Boehm en 1988 con la finalidad de paliar los inconvenientes del modelo en cascad y adecuar el desarrollo por prototipos a problemas complejos. Este paradigma combina el paradigma de cascada y el de construcción por prototipos, agregando una etapa de "análisis de riesgo"
10.4. VENTAJAS:
10.4.1. - Mientras los costos del modelo aumentan, los riesgos de proyecto disminuyen. - Buen control sobre el desarrollo del proyecto.
10.5. DESVENTAJAS:
10.5.1. - Es un modelo complicado. - Exige desarrolladores con mucha experiencia para manejar la complejidad de los problemas que enfrenta.
11. Modelo de desarrollo rápido de aplicación
11.1. El objetivo clave de este modelo es un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión.
11.2. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.
11.3. Las Fases: Modelado de Gestión, Modelado de datos, Modelado de Proceso, Generación de Aplicaciones, Prueba y entrega.
11.4. Desventajas
11.4.1. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.
11.4.1.1. 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.
12. Modelo RUP - Proceso Racional Unificado
12.1. Es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.
12.2. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
12.3. EL moudelo RUP, tiene la filosofía de 6 principios.
12.3.1. Adaptar el proceso
12.3.2. El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.
12.3.3. Equilibrar prioridades
12.3.4. Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
12.3.5. Demostrar valor iterativamente
12.3.6. Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
12.3.7. Colaboración entre equipos
12.3.8. El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
12.3.9. Enfocarse en la calidad
12.3.10. El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
12.3.11. Elevar el Nivel de Abstracción
12.3.12. Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.
13. Modelo basado en componentes
13.1. El modelo basado en componentes es un paradigma de desarrollo, donde elsoftware es desarrollado mediante la reutilización de componentes de softwarepre-existentes. Emergió como una importante solución al problema del desarrollode sistemas grandes y complejos
13.2. CARACTERÍSTICAS
13.2.1. Evolutivo por naturaleza
13.2.2. Exige un enfoque iterativo para la creación de software
13.2.3. Contiene diagramas de componentes y/o Interfaces
13.2.4. Componentes y nodos
13.2.5. Restriccione
13.3. El desarrollo de software basado en componentes permite reutilizar piezas decódigo preelaborado que permite realizar diversas tareas, conllevando a diversosbeneficios como: La mejora a la calidad, la reducción del ciclo de desarrollo y mayor retorno sobre la inversió
13.4. VENTAJAS
13.4.1. La reutilización de software
13.4.2. Simplificación de pruebas
13.4.3. Simplificación del mantenimiento del sistema
13.4.4. Mayor calidad,
13.4.5. Ciclos de desarrollo más corto y
13.4.6. Funcionalidad mejorada