Principios de Desarrollo de Aplicaciones

Presentación del tema: "Principios de Desarrollo de Aplicaciones"— 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
Modificados Exitosos Fracasados 28% 46% 26% Proyectos de Desarrollo de Aplicaciones

5 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 “Cuando un proyecto falla, rara vez es por cuestiones técnicas.” Jim Johnson, The Standish Group

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 Servicios de ConsultoríaMicrosoft Información Tecnológica
Origen Grupos de Productos Microsoft todo mundo Servicios de ConsultoríaMicrosoft Información Tecnológica Microsoft Partners de Microsoft Mejores Prácticas

8 Curriculum MSF Planificar Construir MSF Gerenciar

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 Entendiendo los objetivos
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

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 Desarrollador Testing Gerente De Logística Formación De Usuarios 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.

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.

18 Desarrollador 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

19 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

21 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 Analista Educación de Usuario

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

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

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

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
Program Management Product Management Development Equipo líder User Education Testing Logistics Management Program Management Program Management Development Development Equipo Impresión Equipo Central Program Management User Education User Education Testing Testing Development Equipo UI User Education Testing

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

30 Administración de Riesgos

31 Riesgo Definición Características
Diccionario: “Posibilidad de pérdida o perjuicio” Webster’s 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 Proceso de Administración de Riesgos
Declaración De Riesgos 1. Identificar 2. Analizar Documento de estimación de riesgos Top 10 Riesgos Reiterados 5. Control 3. Plan 4. Track El entregable de este proceso es el documento de estimación de riesgos dinámico

33 Identificando Riesgos
1. Identificar 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

34 Analizando Riesgos 2. Analizar 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

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?

36 Rastreando Riesgos Monitorear los riesgos y sus planes de mitigación
4. Track 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

37 Controlando Riesgos 5. Control 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

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
V S O G P L A D T B Z Vision 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
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 Schedule Features

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

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 Visionando Resources Schedule Features

48 Hito de Visión Aprobada
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 Release I E N V S O G S T A B I L Z N G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

49 Hitos interinos sugeridos
Núcleo del equipo formado Borrador del Documento Vision Borrador del Documento de Estimación de Riesgos 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

50 Entregables de Visión Aprobado
Propósito Dueño 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 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 Contenidos del Documento Visión
Propó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?

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 100 80 60 40 20 Envisioning Planning Developing Stabilizing

57 Definiendo más el alcance
Resources Schedule Planificando Features

58 Hito Plan de Proyecto Aprobado
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? Release L S T A B I Z N G I E N V S O G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

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

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

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

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

63 Entregables para la Aprobación del Plan de Proyectos
Propósito Propietario 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 Gerente de Desarrollo 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 Hito Alcance Completo 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 Release S T A B I L Z N G I E N V S O G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

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 Feature Development Testing y estabilización Tiempo de margen 6 a 8 semanas 2 a 4 semanas 2 a 3 semanas 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
Release Versión Golden Release Versión Candidata S T A B I L Z N G Versión Cero-Bug Betas Especificación de Testing Completa/Alpha Scope Complete D E V L O P I G N Versión Interna n Versión Interna... Versión Interna 2 Project Plan Approved Versión Interna 1 Test Plan

72 Categorías de Pruebas Testing de aplicación Testing de uso
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
Report Tester Bug Retired Close Tester Prioritize and Assign Development Lead Resolve Developers

74 Hito Liberación

75 Hito Liberación 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 I E N V S O G P L A D T B Z Vision Approved Project Plan Approved Scope Complete Release

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
Versión Golden Release Versión Candidata Versión Cero-Bug Convergencia de Bug

78 Focalizándose en el lanzamiento
Beta Bug Convergence Zero-Bug Release Release Candidate Bugs Activos Golden Release Release 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 Libros
Microsoft Solutions Framework site at Steve McConnell’s 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 Microsoft Solutions Framework at a Glance
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 E W N A methodology, like a map, applies specific directions and a specific route to a known destination. Methodology 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. 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 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 Potential Projects Enterprise Goals 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 Resources Features Schedule Project Tradeoffs Testing Developer Manager Project Logistics Analyst Education User SYSTEM Databases User Interface Services Data Layer Business Layer Presentation Layer 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 Milestone Phase One Phase Four Phase Three Phase Two Versioned Releases Customer Database Orders Product Customers Traditional View Services View Network of Cooperating Services Application 1 Application 2 Application 3 Stovepiped Services 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 Specifications Vision Document Project Plans Project Schedule Risk Management Document Living Documents Steps of the MSF Risk Management Process 1. Identify the risk. Bring risks to the surface so teams can deal with them before the risks impact a project. Briefly, the five steps of the process are: 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. 1 Identify Risk Statements 2 Analyse Retired Risks Risk Asessment Document Top 10 5 Control 3 Plan 4 Track MSF Poster March 2001 The ongoing deliverable of this process is a living risk assessment document