METODOLIGIAS DE DESARROLLO DE SOFTWARE

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
METODOLIGIAS DE DESARROLLO DE SOFTWARE por Mind Map: METODOLIGIAS DE DESARROLLO DE SOFTWARE

1. SCRUM

1.1. Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente en equipo, y obtener el mejor resultado posible de un proyecto; es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software

1.1.1. Caracteristicas

1.1.1.1. Está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.XP tiene la ventaja de estar más orientada a las personas que a los procesos.

1.1.1.2. Es necesario un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo.

1.1.1.3. El equipo de desarrollo, tiene la responsabilidad de entregar el producto.

1.1.2. Fases

1.1.2.1. Planificación de Iteraccion

1.1.2.1.1. Analisis y levantamiento de requisitos

1.1.2.2. Sincronizaciones Diarias

1.1.2.2.1. Colaboracion del cliente

1.1.2.3. Retrospectiva

1.1.2.3.1. Demostracion de requisitos

2. XP (Extreme Programming)

2.1. Basada en la simplicidad, la comunicación y el reciclado continúo de código.

2.1.1. Caracteristicas

2.1.1.1. Tiene la ventaja de estar más orientada a las personas que a los procesos.

2.1.1.2. Esta diseñado para grupos de pequeños programadores.

2.1.2. Etapas

2.1.2.1. Planificacion

2.1.2.1.1. Analisis de la informacion

2.1.2.2. Diseño

2.1.2.2.1. Prototipo

2.1.2.3. Codificacion

2.1.2.3.1. Codigo fuente

2.1.2.3.2. Estandares de programacion

2.1.2.4. Pruebas

2.1.2.4.1. Pruebas de aceptacion

2.1.2.4.2. Pruebas de funcionalidad

3. RUP (Rational Unified Process)

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

3.1.1. Caracteristicas

3.1.1.1. Es un proceso configurable y no estático.

3.1.1.2. Proceso dirigido por casos de uso

3.1.1.3. Proceso centrado en la arquitectura

3.1.1.4. Proceso Iterativo o incremental

3.1.1.5. Asigna disciplinadamente tareas y responsabilidades en la organización desarrolladora.

3.1.2. Fases

3.1.2.1. Inicio

3.1.2.1.1. Analisis de la informacion

3.1.2.1.2. Casos de Usos

3.1.2.1.3. Riesgo del proyecto

3.1.2.1.4. Plan de trabajo

3.1.2.2. Elaboracion

3.1.2.2.1. Diseño y arquitectura

3.1.2.2.2. Prototipo

3.1.2.2.3. Casos de uso completos en un 80%

3.1.2.3. Construccion

3.1.2.3.1. Producto listo y en plataforma

3.1.2.3.2. Manuales de Usuario

3.1.2.4. Transicion

3.1.2.4.1. Entrega a los usuarios

3.1.2.4.2. Mantenimiento y soporte

4. MOF (Meta-Objet Facility

4.1. Se originó en el Lenguaje Unificado de Modelado (UML), está diseñado como una arquitectura de cuatro capas.

4.1.1. Caracteristicas

4.1.1.1. Permite una arquitectura de meta-modelado estricto detectando defectos en las fases iniciales.

4.1.1.2. Cada elemento del modelo en cada capa se corresponde estrictamente con un elemento el modelo de la capa superior

4.1.1.3. Sólo proporciona un medio para definir la estructura, o sintaxis abstracta de un lenguaje o de información.

4.1.2. Capas

4.1.2.1. Nivel M0

4.1.2.1.1. Analisis

4.1.2.2. Nivel M1

4.1.2.2.1. Diseño

4.1.2.3. Nivel M2

4.1.2.3.1. Desarrollo

4.1.2.4. Nivel M3

4.1.2.4.1. Certificacion

5. CASCADA

5.1. Es un proceso de desarrollo secuencial, en el que el desarrollo se ve Fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida

5.1.1. Caracteristicas

5.1.1.1. Levantamiento exhaustivo de requerimientos.

5.1.1.2. Reducir el número de cambios tanto como sea posible.

5.1.1.3. Detectar defectos en las fases iniciales.

5.1.1.4. Análisis y diseño, tan completo como sea posible.

5.1.1.5. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

5.1.1.6. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

5.1.1.7. Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables específicos y un proceso de revisión.

5.1.2. Fases

5.1.2.1. Análisis

5.1.2.1.1. Investigacion Preliminar (datos historicos)

5.1.2.1.2. Levantamiento de Requerimiento Funcionales y No Funcionales

5.1.2.2. Diseño y arquitectura

5.1.2.2.1. Prototipo

5.1.2.3. Desarrollo

5.1.2.3.1. Codigo Fuente (byte code)

5.1.2.4. Pruebas

5.1.2.4.1. Pruebas de Funcionalidad

5.1.2.5. Implementación

5.1.2.5.1. Puesta en marcha

5.1.2.6. Certificación

5.1.2.6.1. Prueba de aceptacion

5.1.2.6.2. ISO 25000

5.1.2.7. Mantenimiento

5.1.2.7.1. Soporte

6. Nace despues de la crisis del software para solucionar incovenientes de un proceso

6.1. se clacifican

6.1.1. CLASICA

6.1.2. AGILES