La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Principios de Desarrollo de Aplicaciones. Agenda Qué es MSF? Introducción al Modelo de Equipos Administración de riesgos Introducción al modelo de Procesos.

Presentaciones similares


Presentación del tema: "Principios de Desarrollo de Aplicaciones. Agenda Qué es MSF? Introducción al Modelo de Equipos Administración de riesgos Introducción al modelo de Procesos."— Transcripción de la presentación:

1 Principios de Desarrollo de Aplicaciones

2 Agenda Qué es MSF? Introducción al Modelo de Equipos Administración de riesgos Introducción al modelo de Procesos Hito Aprobación de Visión Hito Aprobación del Plan de Proyectos Hito Alcance Completo Hito Liberación Resumen

3 Qué es MSF?

4 Porcentaje de Proyectos fracasados Proyectos de Desarrollo de Aplicaciones Modificados Exitosos Fracasados 28% 46% 26%

5 Cuando un proyecto falla, rara vez es por cuestiones técnicas. Jim Johnson, The Standish Group Las principales causas de los fracasos Separación de objetivos y negocios Separación de negocios y tecnología Carencia de Lenguaje y proceso comunes Falla al comunicar y actuar como equipo Procesos que son inflexibles a los cambios

6 Principios del Desarrollo de Aplicaciones Apoya lo que considera Microsoft que son las mejores prácticas y principios del desarrollo de aplicaciones Es un miembro de la familia Microsoft Solutions Framework Representa un framework, no una metodología Se focaliza en la gente y en los procesos, no en la tecnología

7 Origen Grupos de Productos Microsoft todo mundo Grupos de Productos Microsoft todo mundo Información Tecnológica Microsoft Información Tecnológica Microsoft Servicios de Consultoría Microsoft Partners de Microsoft Mejores Prácticas

8 Curriculum MSF Construir Planificar Gerenciar MSF

9 Introducción al Modelo de Equipo

10 Equipos Jerárquicos Las dificultades del trabajo en equipos jerárquicos

11 Dificultades en Equipos Jerárquicos Alta sobrecarga de comunicaciones Malos entendidos por comunicaciones indirectas Objetivos confusos de equipo y roles Miembros no integrados del equipo Alta sobrecara de procesos

12 Metas del equipo para el éxito Clientes satisfechos Entregas dentro de las restricciones del proyecto Entregas bajo especificaciones basadas en los requerimientos del usuario Entregas después de tratar todas los temas conocidos Rendimiento incrementado del usuario Despliegue prolijo y administración en curso

13 El éxito total requiere éxito en cada objetivo Cada objetivo debe ser igualmente valorado Cada objetivo requiere una disciplina que este enfocada a dicho objetivo Cada disciplina esta contenida en un rol Objetivos valorados equitativamente se corresponden con roles igualmente valorados, creando un equipo de pares Entendiendo los objetivos

14 Equipo de pares Es un equipo cuyos miembros se relacionan como iguales Cada miembro tiene roles y responsabilidades específicos Potenciar a los individuos en sus roles Responsabilizar a los miembros por el éxito de sus roles Conducir las desiciones sobre la base del concenso Otorgar a todos los miembros del equipo un riesgo en el éxito del proyecto.

15 Modelo de Equipo para el Desarrollo de Aplicaciones Gerente de Desarrollo Gerente de Desarrollo Desarrollador Testing Gerente De Logística Gerente De Logística Formación De Usuarios Formación De Usuarios Gerente de Producto Gerente de Producto Comunicación

16 Rol del Gerente de Producto Actuar como un cliente dentro del equipo Actuar como equipo avocado a el cliente Conduce la visión compartida del proyecto Maneja expectativas del cliente Desarrolla, mantiene, y ejecuta el caso de negocio Conduce la identificación y priorización de las funcionalidades Desarrolla, mantiene y ejecuta el plan de comunicaciones. Gerente De Producto Gerente De Producto

17 Rol del Gerente de Desarrollo Conduce el proceso global Maneja la asignación de recursos Maneja el cronograma y reporta el estado del proyecto Maneja el alcance y la especificación del producto Facilita la comunicación y la negociación del equipo Conduce los cambios críticos de decisiones en su globalidad. Gerente de Desarrollo Gerente de Desarrollo

18 Rol del Desarrollador Construye y prueba funcionalidades para satisfacer las especificaciones y expectativas del cliente Participa del diseño Estima el tiempo y esfuerzo para completar cada funcionalidad Sirve al equipo como consultor tecnológico Desarrollador

19 Testing Rol del Testing Desarrolla estrategias, planes, y scripts de testeo Manages the build process Maneja el proceso de construcción Conduce el testeo para determinar exactamente el estado del desarrollo del producto Participa en establecer la línea de calidad

20 Rol de Formación de Usuarios Actúa como equipo en el usuario final Actúa como usuario final dentro del equipo Participa en la definición de los requerimientos de usuario Participa de las características de diseño Diseñan y desarrollan sistemas de soporte al usuario Conduce el proceso de usabilidad Formación de Usuarios Formación de Usuarios

21 Gerente de Logística Gerente de Logística Rol del Gerente de Logística Actúa como mediador del equipo hacia las operaciones Actúa como mediador de las operaciones hacia el equipo Planea y administra el despliegue del producto Participa del diseño, centrándose en flexibilidad, portabilidad, y despliegue Apoya el producto durante la prueba beta Entrena al personal de operaciones y help desk para la liberación del producto

22 Alineación de Roles y Objetivos Rol de Equipo Gerente de Producto Gerente de Desarrollo Desarrollador Testing Formación de usuarios Gerente de logística Objetivo Clientes satisfechos Entregas cumpliendo los requisitos del proyecto Entregas cumpliendo las especificaciones Entregar después de resolver todos los temas Rendimiento mejorado del usuario Entrega afinada del producto

23 NO un organigrama tradicional Testing Desarrollo Manager Proyecto Logística Desarrollo Analista Educación de Usuario

24 Coordinación con equipos externos Foco Tecnológico Foco de Negocios Usuarios Finales Arquitectos de negocio y planificadores Clientes Arquitectos de Tecnología Y comités de dirección Operaciones y grupos de soporte Usuarios Finales Equipo de Proyecto Formación de Usuario Desarrollador Testing Gerente de Logistica Gerente de Producto Gerente de Desarrollo

25 Escalando para proyectos pequeños Program Management Program Management Development Testing Logistics Management Logistics Management User Education User Education Product Management Product Management Program Management Program Management Development Testing Logistics Management Logistics Management User Education User Education Product Management Product Management No N Posible P Improbable I P P P P P PP PP P I I II I I I I N N N NN N N N N NNN

26 Gerente De Producto Gerente De Producto Ejemplo: Roles combinados Gerente de Desarrollo Gerente de Desarrollo Desarrollador Testing Gerente De Logística Gerente De Logística Formación De Usuarios Formación De Usuarios

27 Escalando para proyectos grandes Dividir los equipos grandes en equipos pequeños, que tienen: Menor sobrecarga de proceso Menor sobrecarga de administración Menor sobrecarga de comunicación Implementación más rápida Crear equipos de funcionalidad- Subequipos multidisciplinarios organizados en torno a grupos de funcionalidades del producto Crear equipos de función-Subequipos unidisciplinarios organizados en torno a roles funcionales

28 Ejemplo: Equipos de Funcionalidad Development Testing User Education User Education Program Management Program Management Development Testing User Education User Education Program Management Program Management Development Testing User Education User Education Program Management Program Management Program Management Program Management Development Testing Logistics Management Logistics Management User Education User Education Product Management Product Management Equipo líder Equipo UI Equipo Impresión Equipo Central

29 Ejemplo: Equipos de Función Gerente de Grupo de Producto Evangelizador Relaciones Públicas Marketing Planificador De Producto Gerente De Producto Gerente De Producto

30 Administración de Riesgos

31 Riesgo Definición Diccionario: Posibilidad de pérdida o perjuicio Websters Collegiate Dictionary, 10th edition Común: Un problema esperando que suceda Características Inherente en cada proyecto Ni intrínsecamente bueno ni malo No para temer, si para administrar

32 Documento de estimación de riesgos Top 10 Riesgos Reiterados 3. Plan5. Control 2. Analizar 1. Identificar Declaración De Riesgos 4. Track Proceso de Administración de Riesgos El entregable de este proceso es el documento de estimación de riesgos dinámico

33 Identificando Riesgos Descubriendo y reconociendo problemas potenciales dentro del proyecto Ejemplo: Identificar el fuego como un riesgo potencial en un depósito Para identificar riesgos efectivamente Usar una estrategia colaborativa Buscar problemas potenciales desde diversas fuentes Examinar riesgos en dos direcciones Tópicos potenciales y sus consecuencias probables Consecuencias potenciales y sus causas probables 1. Identificar

34 Analizando Riesgos Convertir los datos de riesgos en información para la toma de desiciones Ejemplo: Comprender que podría causar el fuego en el depósito y cuál sería el costo del daño Para analizar riesgos efectivamente Evaluar la probabilidad del riesgo Evaluar el impacto del riesgo Calcular la exposición del riesgo 2. Analizar

35 Diseñando el plan de riesgos Formular acciones para prevenir y minimizar el riesgo y qué hacer si ocurriera Ejemplo: Planificar como prevenir el fuego en el depósito y qué hacer si ocurre Priorizar las desiciones de planificación basadas en la prioridad de los riesgos Considerar cinco áreas claves Investigación: Conoce lo suficiente de los riesgos? Aceptación: Puede vivir con sus consecuencias? Evasión: Puede evitar el riesgo? Mitigación: Puede reducir la probabilidad? Contingencia: Puede reducir el impacto? 3. Plan

36 Rastreando Riesgos Monitorear los riesgos y sus planes de mitigación Ejemplo: Revisar los 10 riesgos principales de la lista para un cambio de prioridades Para rastrear riesgos efectivamente Tratar el rastreo de riesgos como un ejercicio corriente a lo largo de todo el ciclo de vida del proyecto Seguir los riesgos por cualquier cambio en su condición o consecuencia Cuantificar el efecto del plan de mitigación Monitorear los disparadores de contingencias 4. Track

37 Controlando Riesgos Conducir los resultados del rastreo de riesgos y del proceso como un todo Ejemplo: Retirar un riesgo que haya sido exitosamente mitigado Para controlar riesgos efectivamente Adaptar la prioridad de los riesgos según los cambios Reaccionar a las variaciones del plan Responder a los eventos disparadores Evaluar el proceso de administración de riesgos 5. Control

38 Introducción al Modelo de Procesos

39 Modelos de Procesos Los modelos del ciclo de vida establecen el orden para las actividades del proyecto Dos modelos son populares El modelo en cascada El modelo en espiral (o desarrollo rápido de aplicación) El modelo de procesos de MSF para desarrollo de aplicaciones combina los beneficios de ambos Proceso basado en Hitos Procesos flexibles e iterativos

40 Modelo de Proceso para el desarrollo de Aplicaciones I E N V S O G I N N I P L A N I G N N D E V L O P I G E N S T A B I L Z N G I I Vision Approved Project Plan Approved Project Plan Approved Scope Complete Release

41 Proceso Guiado por Hitos Los hitos son puntos de revisión y sincronización, no puntos de congelamiento Los hitos permiten al equipo determinar progreso y hacer correcciones en el camino Los modelos de procesos usan dos tipos de hitos Hitos principales Hitos interinos Alcanzar un hito principal representa un acuerdo entre el equipo y el cliente de continuar Las entregas son la evidencia física de que los equipos alcanzaron un hito

42 Responsabilidades guiadas por hitos Hito Visión aprobada Plan de proyecto aprobado Alcance completo Entrega Conductor Primario Gerente de producto Gerente de Desarrollo Desarrollador y Formación de usuarios Testing y Gerente de Logística

43 Principios de un Proceso Exitoso Crear documentación actualizada Utilizar entregas versionadas Hacer compensaciones del proyecto Resources Features Schedule

44 Matriz de compensaciones del proyecto Constrain Optimize Accept Cronograma Características Recursos Resources Features Schedule

45 Hito Visión Aprobada

46 Visionando Creando una vista de alto nivel de las metas y restricciones del proyecto Sirve como una forma temprana de planificación Ayuda al equipo a encontrar un acuerdo común para diferentes perspectivas Brinda la base para futuras planificaciones Captura lo que los clientes y los miembros claves consideran esencial para alcanzar el éxito

47 Definiendo el alcance Resources Features Schedule Visionando

48 Hito de Visión Aprobada I E N V S O G I N N I P L A N I G N N D E V L O P I G E N S T A B I L Z N G I I Project Plan Approved Project Plan Approved Release Vision Approved Scope Complete Indica acuerdo en La razón del proyecto El producto esperado Factibilidad del proyecto Metas y restricciones del proyecto Oportunidades y riesgos Estructura del proyecto

49 Hitos interinos sugeridos Borrador del Documento de Estimación de Riesgos Borrador del Documento Vision Vision Aprobado Se ven a nivel de equipo Dan oportunidad a los miembros de equipo para sincronizar su trabajo Dan a los miembros del equipo, la oportunidad de evaluar el progreso y el estado actual Núcleo del equipo formado

50 EntregablesPropósito Documento Visión Documento de estimación de riesgos Documento de estructura del proyecto Describe lo que se quiere hacer y cómo se piensa hacerlo Describe los riesgos que conlleva el proyecto Describe la estructura organizacional del proyecto Entregables de Visión Aprobado Dueño Gerente de Producto Gerente de Desarrollo

51 Documento Visión Documenta lo que se entiende inicialmente por objetivos y restricciones del proyecto Es el entregable principal de este hito Da las bases para decisiones de seguir o no seguir Da un punto de encuentro para el equipo Guía las decisiones del equipo a un nivel superior Da una guía para las expectativas de los clientes, usuarios finales y del equipo

52 ContenidoPropósito Declaración del problema Declaración de la visión Concepto de la solución Perfiles del usuario Objetivos de negocio Metas de diseño Por qué se quiere hacerlo? Qué se quiere que sea el producto? Qué se realizará? Quién utilizará el producto? Qué se quiere lograr? Cómo se planea lograrlo? Contenidos del Documento Visión

53 Documento de estimación de riesgos Estimando los riesgos preliminares del proyecto y planificando su administración Se crea durante el proceso de administración de riesgos Es la estimación inicial de riesgos del proyecto Establece las bases para la posterior gestion del riesgo Provee las bases para organizar cronogramas y tomar decisiones

54 Documento de estructura del proyecto Describiendo la estructura organizacional del proyecto y del proceso de gerente de proyecto Brinda información sobre los miembros del equipo Incluye información logística del equipo Describe procesos del equipo Actúa como un repositorio de plantillas de documentación del proyecto

55 Hito Aprobación del Plan de Proyecto

56 Importancia de planificar Costo de reparar defectos por fase Envisioning Planning DevelopingStabilizing

57 Definiendo más el alcance Resources Features Schedule Planificando

58 Hito Plan de Proyecto Aprobado I E N V S O G I N N I P L A N I G N N D E V L O P I G E N L S T A B I Z N G I I Vision Approved Project Plan Approved Project Plan Approved Scope Complete Release Indica acuerdo en Estrategia de compensaciones del proyecto Riesgos del proyecto Qué se construirá? Cuándo se construirá? Cómo será construido? Quién lo va a construir?

59 Hitos interinos sugeridos Borrador de especificación funcional Plan de Proyecto Aprobado Borrador de Cronograma de proyecto maestro Borrador del plan de proyecto maestro

60 Revisión del proceso de diseño Diseño Lógico Diseño conceptual Escenarios Diseño Físico Componentes, interfaz de usuario, y base de datos física Objetos y servicios, Unterfaz de usuario y base de datos lógica

61 Vínculo con la planificación Plan Proyecto Aprobado Plan Proyecto Aprobado Línea base del Diseño Físico Diseño Conceptual Diseño Lógico Diseño Físico Vision Aprobada Vision Aprobada Línea base del Diseño Lógico Línea base del Diseño Conceptual

62 Modelo de aplicación MSF Servicios de Negocios Servicios de Usuarios Servicios De Datos Aplicación 1Aplicación 2

63 EntregablePropósito Especificación funcional Plan de proyecto maestro Cronograma de proyecto maestro Documento revisado de estimación de riesgos Describe qué se va a construir Describe como será construido Describe cuándo se construirá Describe los obstáculos para construir Entregables para la Aprobación del Plan de Proyectos Propietario Gerente de Desarrollo

64 Principios para cronogramas Precisos Estimar desde abajo hacia arriba Tener la mente en una fecha fija de entrega Calendarizar guiado por los riesgos Calendarizar para un futuro incierto Sumar un margen de tiempo Utilizar hitos transitorios de desarrollo Utilizar tareas discretas

65 Hito Alcance Completo

66 Indica acuerdo en El conjunto de característica planeadas Si dichas características han sido desarrolladas Línea base de materiales para soportar el rendimiento del usuario El proceso estabilizado, incluyendo betas y testing I E N V S O G I N N I P L A N I G N N D E V L O P I G E N S T A B I L Z N G I I Vision Approved Project Plan Approved Project Plan Approved Scope Complete Release Hito Alcance Completo

67 Hitos interinos sugeridos Alcance Completo Versión Interna n Versión Interna... Versión Interna 2 Versión Interna 1

68 Entregas Internas LLevar el producto a un estado conocido e incrementalmente construir sobre él Entrega Interna 1 Entrega Interna 2 6 a 8 semanas Feature Development 2 a 4 semanas2 a 3 semanas Testing y estabilización Tiempo de margen Test de aceptación Hito Revisión

69 Tendencia Defecto-Cero Consignar el más alto nivel de calidad posible dentro de las restricciones del proyecto Los miembros del equipo deben comprender el nivel de calidad requerido para su trabajo El trabajo no está completo hasta que no alcance ese nivel de calidad La tendencia Defecto-Cero está contenida en Tareas entregables Hitos

70 Testing Asegurarse que las cosas correctas sean hechas correctamente en el tiempo correcto Descubrir detalles para que puedan direccionarse Validar que el equipo está haciendo las cosas correctas Verificar que el equipo las esté haciendo correctamente Soportar decisiones de negocio y cambios Mirar el proceso, no solo el producto

71 Proceso continuo de Testing D E V L O P I G E N S T A B I L Z N G I I Project Plan Approved Project Plan Approved Scope Complete Release Versión Interna 1 Versión Interna 2 Versión Interna... Test Plan Especificación de Testing Completa/Alpha Betas Versión Candidata Versión Golden Release Versión Interna n Versión Cero-Bug

72 Categorías de Pruebas Testing de aplicación Intenta probar a fondo cada característica del producto Intenta probar exhaustivamente el código base del producto Se usa principalmente durante la fase de desarrollo Testing de uso Intenta completar satisfactoriamente todos los escenarios de uso Intenta probar el producto en su ambiente esperado Se usa principalmente durante la fase de estabilización

73 Proceso de Bug Tracking Resolve Developers Close Tester Prioritize and Assign Development Lead Report Tester Bug Retired

74 Hito Liberación

75 I E N V S O G I N N I P L A N I G N N D E V L O P I G E N S T A B I L Z N G I I Vision Approved Project Plan Approved Project Plan Approved Scope Complete Release Indica acuerdo en Estabilidad de producto y resolución de los bugs conocidos Aceptación del cliente Transferencia del dominio para administración y soporte a largo plazo Cambio en el equipo centrándose en la próxima versión

76 Testing durante la Fase Estabilización Es la transición del testing de aplicación al de uso Involucra tanto el testing interno como el externo El testing de uso interno se focaliza en completar los escenarios de uso y un amplio testing de configuración El testing de uso externo se realiza principalmente por medio de las betas Se aproxima al final del juego

77 Hitos interinos sugeridos Release Convergencia de Bug Versión Cero-Bug Versión Candidata Versión Golden

78 Focalizándose en el lanzamiento Beta Bug Convergence Zero-Bug Release Release Candidate Golden Release Release 0 Bugs Activos Tiempo

79 Postmortem Formalizar el proceso de aprendizaje desde las experiencias pasadas Son encuentros de revisión post-hitos Se captura el aprendizaje del proyecto para el desarrollo de los miembros del equipo y la mejora del proceso Dar por finalizado el proyecto Son fundamentales para el aprendizaje de la organización

80 Para más Información Web sites Microsoft Solutions Framework site at Steve McConnells Survival Guide site at Libros Dynamics of Software Development, Jim McCarthy Rapid Development, Steve McConnell Software Project Survival Guide, Steve McConnell Debugging the Development Process, Steve Maguire Microsoft Secrets, Michael A. Cusumano y Richard W. Selby

81 Resources Features Schedule Project Tradeoffs Versioned Releases Testing Developer Project Manager Logistics Developer Analyst User Education SYSTEM Databases User Interface Services Data Layer Business Layer Presentation Layer Microsoft Solutions Framework at a Glance Why use MSF - Typical Root Causes of Failure: Separation of Goal and Function Separation of Business and Technology Lack of Common Language and Process Failure to Communicate and Act As a Team Processes That Are Inflexible to Change Key MSF Principles Customer-focused projects Project actions are determined by the goal of solving a particular business problem rather than for the sake of interesting technology. This focus helps to align business and technology, because technology is only being used to support the needs of the business. User-centric design This design focus means that the product design is based on how all of the different users need to use the system. This focus aligns what the system does with what it needs to do. If a feature exists in the design, it is to support a use of the product. NOTE: In MSF terminology, the customer is the individual, group, or organisation paying for the project. The user is the individual, group, or organisation that will use the system or the technology when the project is completed. Common language and terminology MSF acts as a baseline for communication. When teams are formed, each member has personal project experience and knowledge of different project methodologies. MSF allows the team to share a simple baseline that each member on the team can agree to and use. Defined team roles and responsibilities The MSF Team Model focuses each of its roles on a singular goal that must be accomplished for the project to be successful. 1st Avenue Plum Street Orange Street.. Smith River 2nd Avenue 3rd Avenue 4th Avenue..... S MSF. EW.. N.... Methodology A methodology, like a map, applies specific directions and a specific route to a known destination. Framework A framework, like a compass, verifies progress and provides directional guidance when the direction or route changes. MSF is a framework ! Its models, principles, and practices provide a guide for planning and building business solutions. MSF serves as a useful tool for measuring progress against the original goals. Potential Projects Enterprise Goals Enterprise architecture Selects the path Enterprise architecture Selects the path Provides the guidance to get there Digital Nervous System Embodies business goals of organisation Relationship of MSF and the Enterprise Architecture Retired Risks Risk Asessment Document Top 10 Identif y Risk Statement s The ongoing deliverable of this process is a living risk assessment document Contro l Track Analyse Plan Briefly, the five steps of the process are: 1. Identify the risk. Bring risks to the surface so teams can deal with them before the risks impact a project. 2. Analyse the risk. Convert risk data into information that a team can use to make decisions. 3. Plan for the risk. Devise plans that will support decision- making and actions taken. 4. Track the risk. Monitor the status of risks and any actions taken to mitigate them. 5. Control the risk. Move risk management into day-to-day project management, which is crucial in ensuring that risk management remains a high-profile activity. Steps of the MSF Risk Management Process Baseline Early Baseline planning efforts begin as early as possible for an earlier development start Freeze Late Consider documents as dynamic and subject to change Functional Specification s Vision Document Project Plans Project Schedule Risk Management Document Living Documents The Six Team Goals for Success Satisfied Customers Delivery within Project Constraints Delivery to Specification Release After Addressing All Known Issues Enhanced User Performance Smooth Deployment and Ongoing Management Customer Database Customer Database Customer Database Customer Database Customer Database Customer Database Orders Database Orders Database Orders Database Orders Database Product Customers Product Orders Customers Product Traditional View Services View Network of Cooperating Services Application 1 Application 2Application 3 Stovepiped Services Application 1Application 2 Milestone Phase One Phase Four Phase Three Phase Two Team roles Product management Program management Development Testing User education Logistics management Goal Satisfied customers Delivery within project constraints Delivery to product specifications Release after addressing all known issues Enhanced user performance Smooth product deployment MSF Poster March 2001


Descargar ppt "Principios de Desarrollo de Aplicaciones. Agenda Qué es MSF? Introducción al Modelo de Equipos Administración de riesgos Introducción al modelo de Procesos."

Presentaciones similares


Anuncios Google