Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Metodología tradicional

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 28 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Anzeige

Ähnlich wie Metodología tradicional (20)

Anzeige

Metodología tradicional

  1. 1. Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.
  2. 2. RUP El Proceso Unificado de Rational
  3. 3. + Es un proceso de desarrollo de software 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. El Proceso Racional Unificado 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. 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.
  4. 4. Las cuatro fases del ciclo de vida son: Ø CONCEPCIÓN: El objetivo es determinar la visión del proyecto y definir lo que se desea realizar. Ø ELABORACIÓN: Etapa en la que se determina la arquitectura óptima del proyecto. Ø CONSTRUCCIÓN: Se obtiene la capacidad operacional inicial. Ø TRANSICIÓN: Obtener el producto acabado y definido.
  5. 5. Evaluación en cada fase que permite cambios de objetivos. Funciona bien en proyectos de innovación. Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Seguimiento detallado en cada una de las fases. La evaluación de riesgos es compleja. Excesiva flexibilidad para algunos proyectos. Estamos poniendo a nuestro cliente en una situación que puede ser muy incómoda para él. Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.
  6. 6. MICROSOFT SOLUTIONS FRAMEWORK Proceso en MSF ComponentesMSFPropuesta ProblemaActual Microsoft Solutions Framework (MSF) puede ser una herramienta eficaz para las organizaciones que desean desarrollar de manera rápida soluciones tecnológicas de alta calidad y relevantes para el negocio. Su flexibilidad permite adaptarlo de manera sencilla a la mayoría de proyectos tecnológicos, lo que ayuda a los equipos a comunicarse y coordinar las actividades más importantes.
  7. 7. Microsoft® Solutions Framework es un marco de trabajo de referencia para construir e implantar sistemas empresariales distribuidos basados en herramientas y tecnologías de Microsoft. MSF
  8. 8. •Alinear los objetivos de negocio y de tecnología •Establecer de manera clara los objetivos, los roles y las responsabilidades •Implementar un proceso iterativo controlado por hitos o puntos de control •Gestionar los riesgos de manera proactiva •Responder con eficacia ante los cambios
  9. 9. DISCIPLINAS EN MSF Identificar prioridades controlar emergencias y tomar la mejor decisión Planificar entregas cortas Registrar y hacer evidentes los cambios Identificar cambios ajustados al cronograma Incorporar nuevas características 1 3 •GESTIÓN DE PROYECTOS •CONTROL DE RIESGOS •CONTROL DE CAMBIOS
  10. 10. Modelo del Proceso en MSF VISIÓN PLANEACIÓN DESARROLLO ESTABILIZACIÓN IMPLANTACIÓN Todo proyecto es separado en cinco principales fases:
  11. 11. MODELO DEL PROCESO EN MSF La fase de visión y alcances trata uno de los requisitos más fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común. El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente. Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.
  12. 12. Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. MODELO DEL PROCESO EN MSF Durante esta fase el equipo realice la mayor parte de la construcción de los componentes (tanto documentación como código), sin embargo, se puede realizar algún trabajo de desarrollo durante la tapa de estabilización en respuesta a los resultados de las pruebas. La infraestructura también es desarrollada durante esta fase.
  13. 13. En esta fase se conducen pruebas sobre la solución, las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento. MODELO DEL PROCESO EN MSF Durante esta fase el equipo implanta la tecnología base y los componentes relacionados, estabiliza la instalación, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobación final del cliente.
  14. 14. 1.Fomente las comunicaciones abiertas. 2.Trabaje hacia una visión compartida. 3.Autorización para los miembros del equipo. 4.Establezca la responsabilidad clara y responsabilidad compartida. 5.Entregue el valor incremental. La entrega de valor incremental tiene dos facetas: ♣ Asegúrese de que lo que se entrega tiene un valor óptimo para las partes interesadas. ♣ Determine los incrementos óptimos en los que entregar valor o “frecuencia de entrega”. 6.Manténgase ágil, expectante y adáptese a los cambios. 7.Invierta en calidad 8.Aprenda de todas las experiencias. 9.Asóciese con clientes internos y externos.
  15. 15.  Crea una disciplina de análisis de riesgos que ayuda y evoluciona con el proyecto. Vinculación con el cliente como también orientado al trabajo en equipo. Tiene facilidad de soporte y mantenimiento.  Es adaptable, se puede utilizar para proyectos de cualquier magnitud.  El modelo tiene facilidad de manejo por ser una empresa conocida.  Aplica mucho e incentiva al trabajo en equipo y a la colaboración.  Al estar basado en tecnología Microsoft, trata de obligar a usar herramientas de ellos mismo.  Solicita demasiada documentación en sus fases.  Si el análisis de riesgos se hace muy exhaustivo puede retardar el proyecto.  Los precios de licencias, capacitación y soporte de Microsoft son caros.
  16. 16. El Modelo en Espiral fue propuesto Originalmente por “Boehm en 1988.” es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con el modelo lineal secuencial.
  17. 17. Modelo de cuatro regiones modelo original de Boehm El Modelo en Espiral, propuesto originalmente por Boehm en 1976
  18. 18. NÚMERO DE ACTIVIDADES DE MARCO DE TRABAJO TAMBIEN LLAMADO REGIONES TAREAS: •COMUNICACIÓN CON EL CLIENTE: Las tareas requeridas para establecer “Comunicación” entre el “Desarrollador” y el “Cliente”. •PLANIFICACIÓN: Las Tareas Requeridas para definir “Recursos” , el “Tiempo” y otra “Información” relacionadas con el Proyecto. •ANÁLISIS DE RIESGO: Las Tareas Requeridas para evaluar “Riesgos Técnicos” y de “Gestión”. •INGENIERÍA: Las Tareas Requeridas para “Construir” una o mas representaciones de la Aplicación. •CONSTRUCCIÓN Y ACCIÓN: Las Tareas Requeridas para “Construir”, “Probar”, “Instalar” y “proporcionar” soporte al Usuario ( por ejemplo: Documentación y Práctica). • EVALUACIÓN DEL CLIENTE: Las Tareas Requeridas para obtener la Reacción del Cliente según la Evaluación de las representaciones del software creadas durante la etapa de “ingeniería” e “implementada” durante la etapa de “instalación”. .
  19. 19. Modelo en espiral de seis regiones Planificación Análisis de riesgos Ingeniería Construcción y adaptación Evaluación del cliente Comunicación con el cliente Producto Final
  20. 20. Define un Conjunto de Actividades de Negociación al principio de cada paso alrededor de la Espiral. Mas que una simple actividad de comunicación con el cliente, se definen las siguientes actividades:
  21. 21. Modelo en espiral WINWIN 2. Identificar las condiciones de victoria de los directivos 3a. Reunir las condiciones de victoria. 3b. Establecer los objetivos, restricciones y alternativas del siguiente nivel. 4. Evaluar las alternativas del producto y del proceso y resolución de riesgos. 5. Definir el siguiente nivel del producto y del proceso incluyendo particiones. 6. Validar las definiciones del producto y del proceso 1. Identificar el siguiente nivel para los directivos 7. Revisión y comentarios.
  22. 22. •El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. •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 niveles evolutivos. •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. •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. •Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. •Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. •Genera mucho tiempo en el desarrollo de sistemas.
  23. 23. ICONIX es la metodología que está de moda por su fácil aplicación y rápida producción de software de calidad. 1. Análisis de requisitos • Elaboración rápida de prototipos • Modelo del dominio • Modelo de casos de usos 2. Análisis y diseño preliminar •Descripción de los casos de uso •Diagramas de robustez 3. Diseño • Diagrama de secuencia 4. Implementación •Código y pruebas
  24. 24. La metodología ICONIX, es una combinación entre la RUP y XP; está basada en el desarrollo de sistemas a partir del análisis y la documentación. Esta metodología se busca tener una retroactividad con el cliente, en la mitad de los procedimientos, comenzando con un prototipo en donde el analista y el cliente definirán pantallas, funcionalidades, en si lo que se espera obtener del programa. Se definirán los modelos de casos de uso, de secuencia y de robustez, con la finalidad de conseguir un buen sistema.
  25. 25. esquema del método ICONIX: Prototipo de interfaz de usuario Diagrama de robustez Modelo de casos de uso Diagrama de secuencia DINÁMICA Código Modelo de dominio Diagrama de clases ESTÁTICA Plan de Prueba ------ ------ ICONIX

×