METODOLOGIA DE DESARROLLO DE SOFTWARE

Get Started. It's Free
or sign up with your email address
Rocket clouds
METODOLOGIA DE DESARROLLO DE SOFTWARE by Mind Map: METODOLOGIA DE DESARROLLO DE SOFTWARE

1. METODOLOGIA MOF

1.1. MOF se originó en el Lenguaje Unificado de Modelado (UML), el OMG estaba en necesidad de un metamodelado arquitectura para definir el UML.

1.2. CARACTERISTICAS

1.2.1. MOF se configura como un lenguaje de meta-modelado versátil.

1.2.2. se encuentran alineados arquitectónicamente UML, MOF y XMI (XML Metadata Interchange)

1.2.3. Permite a los usuarios definir totalmente nuevos lenguajes a partir de meta-modelos

1.2.4. Esta organizado en dos parte, infraestructura y superestructura

1.2.5. MOF está diseñado como una arquitectura de cuatro capas .

1.2.5.1. En la capa M3 se situan los meta-metamodelos.

1.2.5.2. En la cpa M2, aloja a los metamodelos entre ellos, el modelo UML y CWM es decir estos seran las instancias del correspondiente meta-metamodelo

1.2.5.3. En la capa M1 aloja modelos de dominios semanticos concretos

1.2.5.4. En la capa M0 la encontramos en la parte mas baja de la jerarquia esta contiene las instancias en tiempo de ejecucion de los elementos de los modelos M1

1.3. VENTAJAS

1.3.1. Simplifica las reglas para el modelado de metadatos

1.3.2. Las tecnologías de mapeos de MOF (XMI, JMI, etc.), se pueden aplicar a los modelos UML, incluidos los perfiles UML.

1.3.3. Permite un amplio abanico de herramientas para el metamodelado, ya que cualquier herramienta UML se podrá utilizar para modelar metadatos fácilmente

1.3.4. Facilitan la consecución de las capacidades de reutilización de MOF desde otros modelos o metamodelos.

1.3.5. Permite a los usuarios definir totalmente nuevos lenguajes a partir de metamodelos

1.4. DESVENTAJAS

1.4.1. Permite definir un lenguaje de modelado (UML) mas no permite la comporacion en tre varios lenguajes de modelado

1.4.2. Los modelos se vuelven obsoletos e incompatibles con el codigo

1.4.3. Los modelos no se pueden intercambiar facilmente entre las herramientas

1.4.4. No se puede describir el tipo de detalles que se deben ser implementados.

1.5. REUTILIZACION DE MOF

1.6. REFLECTION

1.6.1. que extiende un modelo con la habilidad de ser autodescriptivo.

1.7. IDENTIFIERS

1.7.1. que provee una extensión para objetos del metamodelo identificados excepcionalmente

1.8. EXTENSION

1.8.1. un simple significado para extensiones de elementos del modelo con el par nombre – valor.

2. METODOLOGIA SCRUM

2.1. Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa

2.2. CARACTERISTICAS

2.2.1. Es una metodologia agil

2.2.2. Es liviano, iterativo e incremental

2.2.3. Serealizan entregas funcionales ffrecuentes

2.2.4. Descentralizado

2.2.5. Simplicidad, adaptativo y flexible

2.2.6. Enfoccdo en la productividad

2.2.7. Requisitos auto-Organizables

2.2.8. Predidposicion y respuesta al cambio

2.2.9. Comunicacion y directa con los stakeholders

2.2.10. Motivacion y responsabilidad.

2.2.11. No es secuencial

2.3. VENTAJAS

2.3.1. El cliente puede comenzar a utilizar el producto rápidamente.

2.3.2. El cliente puede decidir los nuevos objetivos a realizar.

2.3.3. Se agila el proceso, porque se divide el problema en pequeñas tareas.

2.3.4. El cliente en el proceso es parte del equipo

2.3.5. El proceso es trasparente para todos

2.3.6. Mejora la satisfaccion del producto entregado al cliente

2.4. DESVENTAJAS

2.4.1. La deuda tecnica puede perjudicar el sistema

2.4.2. El cambio en un miembro del equipo pone el riesgo el proceso

2.4.3. El equipo puede llegar a una etapa de stress

2.4.4. Mayor tiempo por parte del cliente en el proceso

2.4.5. Es complejo de implantar

2.5. CICLO DE VIDA DE METODOLOGIA SCRUM

2.6. PLANIFICACION DE ITERACION

2.6.1. Seleccion de requisitos

2.7. SINCRONIZACIONES DIARIAS

2.7.1. Colaboracion del cliente

2.8. RETROESPECTIVA

2.8.1. Demostracion de requisitos

2.9. SPRINTS

2.9.1. El ciclo de vida de scrum se divide en sprints

2.9.2. Representa un incremento del producto

2.9.3. Dura tipicamente ente 2-4 semanas

2.9.4. Encada Sprints se Disieña, codifica y testea el producto

2.10. ROLES PRINCIPALES

2.11. SCRUM MASTER

2.11.1. Interactuan con el cliente y el equipo

2.12. PROPIETARIO DEL PROYECTO

2.12.1. Es el responable oficial del proyecto, gestion, control y visivilidad de la lista de acumulacion o lista de retraso del producto

2.13. ROLES AUXILIARES

2.14. MANAGEMENT

2.14.1. Esta a cargo de las decisiones fundamentales y participa en la definicion de los objetivos y requerimientos

2.15. STAKEHOLDERS

2.15.1. Clientes, proveedores, vendedores

3. APLICACIONE WEB

3.1. Son aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador.

3.1.1. TIPOS DE APLICACIONES WEB

3.1.1.1. informacionales

3.1.1.2. Orientados a la desacarga de datos

3.1.1.3. Interactivas

3.1.1.4. Orientada al servivio

3.1.1.5. Transaccionales

3.1.1.6. De flujo de datos

3.1.1.7. Entorno de trabajo Colaborativo

3.1.1.8. Comunidades on-line Sistema C2C

3.1.1.9. Portales WEB

3.1.1.10. O rientado al analisis de datos

3.1.1.11. CARACTERISTICAS DE UNA APLICACION WEB

3.1.1.11.1. DESDEL PUNTO DE VISTA DEL USUARIO

4. METODOLOGIA XP

4.1. XP <EXTREME PROGRAMMING> <Basada en la simplicidad, la comunicación y el reciclado continuo de código.

4.1.1. CARACTERISTICAS

4.1.2. Desarrollo iteratico

4.1.3. Pruebas unitarias continuas

4.1.4. Programacion en parejas

4.1.5. Integracion del equipo de programacion con el cliente

4.1.6. Correccion de todos los errores

4.1.7. Refactorizacion del codigo

4.1.8. Propiedad del codigo compartida

4.1.9. Simplicidad

4.1.10. VENTAJAS

4.1.10.1. Programacion organizada

4.1.10.2. Menor taza de errores

4.1.10.3. Solucion de errores de programa

4.1.10.3.1. Satisfaccion del programador

4.1.10.4. Versiones Nuevas

4.1.10.5. Implementa una nueva forma de trabajo donde se adapte facilmente a las circunstancias

4.1.11. DESVENTAJAS

4.1.11.1. Es reconmendable emplearlo solo en proyectos a corto plazo

4.1.11.2. Altas comision en caso de fallar

4.1.11.3. Imposible prever todo antes de programar

4.1.11.4. Demasiado costoso e innecesario

4.2. FACES DE PROGRAMACION EXTREMA

4.3. PLANIFICACION

4.3.1. Se utilizan historias del usuario

4.3.2. Se crean planes de entrega

4.3.3. Se lleva acabo la planificacion de iteracion

4.4. DISEÑO

4.4.1. Se escoge una metafora del sistema

4.4.2. Se proponen Soluciones

4.4.3. Se ignoran las funcionalidades extras

4.4.4. Se remueve la Redundancias

4.5. CODIFICACION

4.5.1. Se utilizan estandares para escribir codigos

4.5.2. Se crean pruebas antes de empezar el codigo

4.5.3. Se deja la optimizacion para el final

4.6. PRUEBAS

4.6.1. Se crean pruebas de aceptacion

4.6.2. El cliente es responsable de revisar, tanto las pruebas como los resultados

5. METODOLOGIA EN CASCADA

5.1. El modelo en cascada 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.2. CARACTERISTICAS

5.2.1. Es el mas utilizado

5.2.2. Es una vision del proceso de desarrollo del software como una sucesion de etapas que produce productos intermedios .

5.2.3. si se cambia el orden de las faces, el producto final sera de inferior calidad.

5.3. VENTAJAS

5.3.1. Se tiene todo bien organizado y no se mezclan las faces

5.3.2. La planificacion es sencilla

5.3.3. La calidad del producto resultantes es alta

5.4. DESVENTAJAS

5.4.1. Tarda mucho tiempo en pasar por todo el ciclo

5.4.2. Iteraciones costosas

5.4.3. Es dificil incorporar nuevas cosas si se quiere actualizar

5.5. CICLO DE VIDA EN CASCADA

5.5.1. ANALISIS DE LOS REQUERIMIENTOS DEL SOFTWARE

5.5.1.1. Alcance del sistema

5.5.1.2. definicion y analisis de requerimientos

5.5.1.3. necesidades, estudio de viabilidad.

5.5.2. DISEÑO

5.5.2.1. Clasificacion de requisitos

5.5.2.2. Organizar Arquitectura del software

5.5.3. DESARROLLO

5.5.3.1. Codificacion y depuracion del software

5.5.3.2. Documentacion interna, externa y de usuario

5.5.4. IMPLEMENTACION

5.5.4.1. Pruebas de aceptacion

5.5.4.2. Pruebas de fisicas

5.5.4.3. Pruebas logicas

5.5.4.4. Verificar que se cumplen con las caracteristicas identificadas

5.5.4.4.1. MANTENIMIENTO

5.5.4.4.2. Mejoras

5.5.4.4.3. Añadir funcionalidades

5.5.4.4.4. Correccion de errores

6. METODOLOGIA RUP

6.1. La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está diseñado y documentado el uso de la notación UML.

6.1.1. CARATERISTICAS

6.1.1.1. Centrado en la arquitectura

6.1.1.2. Los casos de uso representan los requerimientos base para el desarrollo del sistema

6.1.1.3. desarrolla iterativamente

6.1.1.4. Administra requerimientos

6.1.1.5. Usa Arquitecturas basada en componentes

6.1.1.6. Modela visualmente el software

6.1.1.7. Asegura continuamente la calidad

6.1.1.8. Administra el cambio

6.1.2. VENTAJAS

6.1.2.1. Esta basada totalmente en mejores practicas de la metodologias

6.1.2.2. Reduce riesgos del proyecto.

6.1.2.3. Incorpora fielmente el objetivo de calidad

6.1.2.4. Integra desarrollo con mantenimiento

6.1.3. DESVENTAJAS

6.1.3.1. Pretende prever y tener todo el control de antemano

6.1.3.2. Modelo genera trabajo adicional.

6.1.3.3. Genera muchos costos.

6.1.3.4. No recomendable para proyectos pequeños.

6.2. FASES DEL CICLO DE VIDA DEL RUP

6.3. FASE DE INICION

6.3.1. Definiry acordar el alcance del proyecto con los patrocinadores

6.3.2. Identificar los riesgos asociados al proyecto

6.3.3. proponer una vision my general de la arquitectura del software

6.3.4. Producir el plan de las fases y el de iteraciones posteriores

6.4. FASE DE ELABORACION

6.4.1. Se seleccionan los casos de usos que permiten definir la arquitectura base del sistema y se desarrolla en esta fase.

6.4.2. Se realiza las especificaciones de casos de uso seleccionados y el primer analisis del dominio del problema, se diseña la solucion prelilminar.

6.5. FASE DE DESARROLLO

6.5.1. Completar la funcionalidad del sistema, se deben clarificar los requerimientos pendientes.

6.5.2. Administrar los cambios de acuerdo a las evaluaciones realizadas por los usuarios.

6.5.3. Se realizan las mejoras para el proyecto.

6.6. FASE DE CIERRE

6.6.1. Asegurar que el software este disponible para los usuarios finales

6.6.2. Ajustar los errores y defectos encontrados en las pruebas de aceptacion.

6.6.3. Capacitar a los usuarios y proveer el soporte tecnico necesario