Principios de Desarrollo de Aplicaciones

Agenda

Qu es MSF?
Introduccin al Modelo de Equipos Administracin de riesgos

Introduccin al modelo de Procesos

Hito Aprobacin de Visin Hito Aprobacin del Plan de Proyectos Hito Alcance Completo Hito Liberacin

Resumen

Qu es MSF?

Porcentaje de Proyectos fracasados

Fracasados

28% 46% Modificados

Exitosos

26%

Proyectos de Desarrollo de Aplicaciones

Las principales causas de los fracasos

Separacin

de objetivos y de negocios y

negocios
Separacin

tecnologa
Carencia

de Lenguaje y proceso comunes

Falla

al comunicar y actuar Cuando un proyecto falla, como equipo

que son inflexibles a los cambios
rara vez es por cuestiones tcnicas.
Jim Johnson, The Standish Group

Procesos

Principios del Desarrollo de Aplicaciones

Apoya

lo que considera Microsoft que son las mejores prcticas y principios del desarrollo de aplicaciones

Es

un miembro de la familia Microsoft Solutions Framework

un framework, no una metodologa focaliza en la gente y en los procesos, no en la tecnologa

Representa

Se

Origen
Grupos de Productos Microsoft todo mundo
Informacin Tecnolgica Microsoft Servicios de Consultora Microsoft

Partners de Microsoft

Mejores Prcticas

Curriculum MSF
Planificar

Construir

MSF
Gerenciar

Introduccin al Modelo de Equipo

Equipos Jerrquicos
Las dificultades del trabajo en equipos jerrquicos

Dificultades en Equipos Jerrquicos

Alta

sobrecarga de comunicaciones

Malos

entendidos por comunicaciones indirectas confusos de equipo y roles no integrados del equipo

Objetivos Miembros Alta

sobrecara de procesos

Metas del equipo para el xito

Clientes

satisfechos dentro de las restricciones del

Entregas

proyecto
Entregas
Entregas

bajo especificaciones basadas en los requerimientos del usuario

despus de tratar todas los temas conocidos incrementado del usuario prolijo y administracin en curso

Rendimiento Despliegue

Entendiendo los objetivos

El

xito total requiere xito en cada objetivo objetivo debe ser igualmente valorado objetivo requiere una disciplina que este enfocada a dicho objetivo

Cada

Cada

Cada

disciplina esta contenida en un

rol
Objetivos

valorados equitativamente se corresponden con roles igualmente valorados, creando un equipo de pares

Equipo de pares
Es

un equipo cuyos miembros se relacionan como iguales miembro tiene roles y responsabilidades especficos a los individuos en sus roles a los miembros por el xito

Cada

Potenciar

Responsabilizar

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.

Modelo de Equipo para el Desarrollo de Aplicaciones

Gerente de Desarrollo Gerente de Producto

Desarrollador

Comunicacin
Formacin De Usuarios Gerente De Logstica Testing

Rol del Gerente de Producto

Actuar Actuar

Gerente De Producto

como un cliente dentro del equipo como equipo avocado a el cliente la visin compartida del proyecto

Conduce Maneja

expectativas del cliente mantiene, y ejecuta el caso de

Desarrolla,

negocio
Conduce

la identificacin y priorizacin de las funcionalidades mantiene y ejecuta el plan de comunicaciones.

Desarrolla,

Rol del Gerente de Desarrollo

Conduce Maneja Maneja

Gerente de Desarrollo

el proceso global

la asignacin de recursos

el cronograma y reporta el estado del proyecto el alcance y la especificacin del producto

Maneja

Facilita

la comunicacin y la negociacin del

equipo
Conduce

los cambios crticos de decisiones en su globalidad.

Rol del Desarrollador

Desarrollador

Construye

y prueba funcionalidades para satisfacer las especificaciones y expectativas del cliente del diseo

Participa Estima

el tiempo y esfuerzo para completar cada funcionalidad al equipo como consultor tecnolgico

Sirve

Rol del Testing

Desarrolla

Testing

estrategias, planes, y scripts de

testeo
Manages

the build process Maneja el proceso de construccin

el testeo para determinar exactamente el estado del desarrollo del producto en establecer la lnea de calidad

Conduce

Participa

Rol de Formacin de Usuarios

Acta Acta

Formacin de Usuarios

como equipo en el usuario final como usuario final dentro del equipo

Participa

en la definicin de los requerimientos de

de las caractersticas de diseo

usuario
Participa

Disean

y desarrollan sistemas de soporte al

el proceso de usabilidad

usuario
Conduce

Rol del Gerente de Logstica

Acta

Gerente de Logstica

como mediador del equipo hacia las operaciones como mediador de las operaciones hacia el equipo y administra el despliegue del producto

Acta

Planea

Participa

del diseo, centrndose en flexibilidad, portabilidad, y despliegue el producto durante la prueba beta

Apoya

Entrena

al personal de operaciones y help desk para la liberacin del producto

Alineacin de Roles y Objetivos

Rol de Equipo
Gerente de Producto Gerente de Desarrollo Desarrollador Testing Formacin de usuarios Gerente de logstica

Objetivo
Clientes satisfechos Entregas cumpliendo los requisitos del proyecto Entregas cumpliendo las especificaciones Entregar despus de resolver todos los temas Rendimiento mejorado del usuario Entrega afinada del producto

NO un organigrama tradicional

Manager Proyecto

Educacin de Usuario

Analista

Desarrollo

Logstica

Desarrollo

Testing

Coordinacin con equipos externos

Usuarios Finales

Foco de Negocios
Gerente de Producto

Usuarios Finales

Formacin de Usuario

Clientes

Equipo de Proyecto Operaciones y grupos de soporte

Desarrollador

Testing

Gerente de Logistica

Gerente de Desarrollo

Arquitectos de negocio y planificadores

Foco Tecnolgico

Arquitectos de Tecnologa Y comits de direccin

Escalando para proyectos pequeos

Product Management Program Management Development Testing User Education Logistics Management

Product Management

N N N P P I P N I I P
Posible

N N N N N I

P I N P P
Improbable

P I N P I N
No

I P N P I

Program Management

Development

Testing

User Education

Logistics Management

Ejemplo: Roles combinados

Gerente De Producto Formacin De Usuarios

Gerente de Desarrollo Gerente De Logstica

Desarrollador

Testing

Escalando para proyectos grandes

Dividir

los equipos grandes en equipos pequeos, que tienen: Menor sobrecarga de proceso Menor sobrecarga de administracin Menor sobrecarga de comunicacin Implementacin ms rpida equipos de funcionalidadSubequipos multidisciplinarios organizados en torno a grupos de funcionalidades del producto equipos de funcin-Subequipos unidisciplinarios organizados en torno a roles funcionales

Crear

Crear

Ejemplo: Equipos de Funcionalidad

Program Management Product Management

Equipo lder

Development

User Education Logistics Management

Program Management

Testing

Program Management

Equipo Impresin
User Education

Development Program Management Testing

Equipo Central
User Education

Development

Testing

Equipo UI
User Education

Development

Testing

Ejemplo: Equipos de Funcin

Gerente de Grupo de Producto Planificador De Producto Gerente De Producto Evangelizador

Relaciones Pblicas

Marketing

Administracin de Riesgos

Riesgo
Definicin

Diccionario: Posibilidad de prdida o perjuicio

Websters Collegiate Dictionary, 10th edition

Comn: Un problema esperando que suceda

Caractersticas

Inherente en cada proyecto

Ni intrnsecamente bueno ni malo

No para temer, si para administrar

Proceso de Administracin de Riesgos

1. Identificar
Declaracin De Riesgos

2. Analizar
Documento

Riesgos Reiterados

5. Control

de estimacin de riesgos Top 10

3. Plan

4. Track El entregable de este proceso es el documento de estimacin de riesgos dinmico

Identificando Riesgos

1. Identificar

Descubriendo y reconociendo problemas potenciales dentro del proyecto

Ejemplo: Identificar el fuego como un riesgo potencial en un depsito

Para identificar riesgos efectivamente

Usar una estrategia colaborativa

Buscar problemas potenciales desde diversas fuentes

Examinar riesgos en dos direcciones
Tpicos potenciales y sus consecuencias probables Consecuencias potenciales y sus causas probables

Analizando Riesgos

2. Analizar

Convertir los datos de riesgos en informacin para la toma de desiciones

Ejemplo: Comprender que podra causar el fuego en el depsito y cul sera el costo del dao

Para analizar riesgos efectivamente

Evaluar la probabilidad del riesgo Evaluar el impacto del riesgo

Calcular la exposicin del riesgo

Diseando el plan de riesgos

3. Plan

Formular acciones para prevenir y minimizar el riesgo y qu hacer si ocurriera

Ejemplo: Planificar como prevenir el fuego en el depsito y qu hacer si ocurre Priorizar

las desiciones de planificacin basadas en la prioridad de los riesgos cinco reas claves
Investigacin: Conoce lo suficiente de los riesgos? Aceptacin: Puede vivir con sus consecuencias? Evasin: Puede evitar el riesgo? Mitigacin: Puede reducir la probabilidad? Contingencia: Puede reducir el impacto?

Considerar

Rastreando Riesgos
Monitorear los riesgos y sus planes de mitigacin
Ejemplo: Revisar los 10 riesgos principales de la lista para un cambio de prioridades

4. Track

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 condicin o consecuencia Cuantificar el efecto del plan de mitigacin Monitorear los disparadores de contingencias

Controlando Riesgos
Conducir los resultados del rastreo de riesgos y del proceso como un todo
Ejemplo: Retirar un riesgo que haya sido exitosamente mitigado

5. Control

Para controlar riesgos efectivamente

Adaptar la prioridad de los riesgos segn los cambios Reaccionar a las variaciones del plan Responder a los eventos disparadores Evaluar el proceso de administracin de riesgos

Introduccin al Modelo de Procesos

Modelos de Procesos
Los

modelos del ciclo de vida establecen el orden para las actividades del proyecto modelos son populares

Dos

El modelo en cascada
El modelo en espiral (o desarrollo rpido de aplicacin)

El

modelo de procesos de MSF para desarrollo de aplicaciones combina los beneficios de ambos

Proceso basado en Hitos Procesos flexibles e iterativos

Modelo de Proceso para el desarrollo de Aplicaciones

Release

Scope Complete

Vision Approved

Project Plan Approved

Proceso Guiado por Hitos

Los

hitos son puntos de revisin y sincronizacin, no puntos de congelamiento hitos permiten al equipo determinar progreso y hacer correcciones en el camino modelos de procesos usan dos tipos de hitos Hitos principales

Los

Los

Hitos interinos

Alcanzar

un hito principal representa un acuerdo entre el equipo y el cliente de continuar

Las

entregas son la evidencia fsica de que los equipos alcanzaron un hito

Responsabilidades guiadas por hitos

Hito
Visin aprobada Plan de proyecto aprobado Alcance completo Entrega Desarrollador y Formacin de usuarios Testing y Gerente de Logstica

Conductor Primario
Gerente de producto Gerente de Desarrollo

Principios de un Proceso Exitoso

Crear

documentacin actualizada

Utilizar

entregas versionadas

Hacer

compensaciones del proyecto

Features

Matriz de compensaciones del proyecto

Features

Optimize

Constrain

Accept

Recursos

Cronograma

Caractersticas

Hito Visin Aprobada

Visionando
Creando una vista de alto nivel de las metas y restricciones del proyecto

Sirve como una forma temprana de planificacin Ayuda al equipo a encontrar un acuerdo comn para diferentes perspectivas Brinda la base para futuras planificaciones

Captura lo que los clientes y los miembros claves consideran esencial para alcanzar el xito

Definiendo el alcance

Visionando Features

Hito de Visin Aprobada

Indica acuerdo en

Release

La razn del proyecto El producto esperado

Factibilidad del proyecto

Metas y restricciones del proyecto Oportunidades y riesgos Estructura del proyecto

Scope Complete

Vision Approved

Project Plan Approved

Hitos interinos sugeridos

Ncleo del equipo formado Borrador del Documento Vision Borrador del Documento de Estimacin de Riesgos
Vision Aprobado

Se

ven a nivel de equipo

Dan

oportunidad a los miembros de equipo para sincronizar su trabajo

a los miembros del equipo, la oportunidad de evaluar el progreso y el estado actual

Dan

Entregables de Visin Aprobado

Entregables
Documento Visin

Propsito
Describe lo que se quiere hacer y cmo se piensa hacerlo Describe los riesgos que conlleva el proyecto

Dueo
Gerente de Producto Gerente de Desarrollo Gerente de Desarrollo

Documento de estimacin de riesgos Documento de estructura del proyecto

Describe la estructura organizacional del proyecto

Documento Visin
Documenta lo que se entiende inicialmente por objetivos y restricciones del proyecto
Es Da

el entregable principal de este hito

las bases para decisiones de seguir o no seguir un punto de encuentro para el equipo

Da

Gua

las decisiones del equipo a un nivel superior una gua para las expectativas de los clientes, usuarios finales y del equipo

Da

Contenidos del Documento Visin

Contenido Declaracin del problema Declaracin de la visin Concepto de la solucin Perfiles del usuario Objetivos de negocio Metas de diseo Propsito Por qu se quiere hacerlo? Qu se quiere que sea el producto? Qu se realizar? Quin utilizar el producto? Qu se quiere lograr? Cmo se planea lograrlo?

Documento de estimacin de riesgos

Estimando los riesgos preliminares del proyecto y planificando su administracin
Se

crea durante el proceso de administracin de riesgos la estimacin inicial de riesgos del proyecto las bases para la posterior gestion del riesgo

Es

Establece

Provee

las bases para organizar cronogramas y tomar decisiones

Documento de estructura del proyecto

Describiendo la estructura organizacional del proyecto y del proceso de gerente de proyecto
Brinda

informacin sobre los miembros del equipo informacin logstica del equipo procesos del equipo

Incluye

Describe Acta

como un repositorio de plantillas de documentacin del proyecto

Hito Aprobacin del Plan de Proyecto

Importancia de planificar
Costo de reparar defectos por fase
100 80 60 40 20
Envisioning Planning Developing Stabilizing

Definiendo ms el alcance

Planificando

Features

Hito Plan de Proyecto Aprobado

Indica acuerdo en

Release

Estrategia de compensaciones del proyecto

Scope Complete Vision Approved

Riesgos del proyecto Qu se construir? Cundo se construir? Cmo ser construido?

Project Plan Approved

Quin lo va a construir?

Hitos interinos sugeridos

Borrador de especificacin funcional

Borrador del plan de proyecto maestro Borrador de Cronograma de proyecto maestro
Plan de Proyecto Aprobado

Revisin del proceso de diseo

Diseo conceptual
Escenarios

Diseo Lgico
Objetos y servicios, Unterfaz de usuario y base de datos lgica

Diseo Fsico
Componentes, interfaz de usuario, y base de datos fsica

Vnculo con la planificacin

Vision Aprobada

Plan Proyecto Aprobado

Lnea base del Diseo Conceptual

Diseo Conceptual

Diseo Lgico
Diseo Fsico

Lnea base del Diseo Lgico Lnea base del Diseo Fsico

Modelo de aplicacin MSF

Aplicacin 1
Servicios de Usuarios

Aplicacin 2

Servicios de Negocios

Servicios De Datos

Entregables para la Aprobacin del Plan de Proyectos

Entregable
Especificacin funcional

Propsito
Describe qu se va a construir Describe como ser construido Describe cundo se construir

Propietario
Gerente de Desarrollo
Gerente de Desarrollo Gerente de Desarrollo

Plan de proyecto maestro

Cronograma de proyecto maestro

Documento revisado Describe los obstculos para de estimacin de construir riesgos

Gerente de Desarrollo

Principios para cronogramas Precisos

Estimar Tener

desde abajo hacia arriba

la mente en una fecha fija de entrega guiado por los riesgos para un futuro incierto

Calendarizar Calendarizar

Sumar un margen de tiempo

Utilizar hitos transitorios de desarrollo Utilizar tareas discretas

Hito Alcance Completo

Hito Alcance Completo

Indica acuerdo en

El conjunto de caracterstica planeadas Si dichas caractersticas Scope han sido desarrolladas Complete Lnea base de materiales para soportar el rendimiento del usuario El proceso estabilizado, incluyendo betas y testing

Release

Vision Approved

Project Plan Approved

Hitos interinos sugeridos

Alcance Completo

Versin Interna n
Versin Interna... Versin Interna 2 Versin Interna 1

Entregas Internas
LLevar el producto a un estado conocido e incrementalmente construir sobre l

Entrega Interna 1
Feature Development

Entrega Interna 2
Tiempo de Testing y estabilizacin margen

6 a 8 semanas

2 a 4 semanas2 a 3 semanas

Test de aceptacin

Hito Revisin

Tendencia Defecto-Cero
Consignar el ms 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

tendencia Defecto-Cero est contenida
Tareas entregables Hitos

La

en

Testing
Asegurarse que las cosas correctas sean hechas correctamente en el tiempo correcto
Descubrir Validar

detalles para que puedan direccionarse

que el equipo est haciendo las cosas correctas que el equipo las est haciendo correctamente decisiones de negocio y cambios

Verificar

Soportar

Mirar

el proceso, no solo el producto

Proceso continuo de Testing

Release Versin Golden Versin Candidata Versin Cero-Bug Betas Especificacin de Testing Completa/Alpha Scope Complete Release

Versin Interna n Versin Interna... Versin Interna 2 Versin Interna 1 Test Plan Project Plan Approved

Categoras de Pruebas
Testing

de aplicacin

Intenta probar a fondo cada caracterstica del producto Intenta probar exhaustivamente el cdigo 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 estabilizacin

Proceso de Bug Tracking

Report Tester

Bug Retired

Close Tester

Prioritize and Assign Development Lead Resolve Developers

Hito Liberacin

Hito Liberacin
Indica acuerdo en

Estabilidad de producto y resolucin de los bugs conocidos Aceptacin del cliente

Scope Complete

Release

Transferencia del dominio para administracin y soporte a largo plazo Cambio en el equipo centrndose en la prxima versin

Vision Approved

Project Plan Approved

Testing durante la Fase Estabilizacin

Es

la transicin del testing de aplicacin al de uso 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 configuracin
El testing de uso externo se realiza principalmente por medio de las betas

Involucra

Se

aproxima al final del juego

Hitos interinos sugeridos

Versin Golden Versin Candidata Versin Cero-Bug Convergencia de Bug

Release

Focalizndose en el lanzamiento
Beta Bug Convergence

Zero-Bug Release Release Candidate

Bugs Activos

Golden Release

Tiempo

Release

Postmortem
Formalizar el proceso de aprendizaje desde las experiencias pasadas
Son Se

encuentros de revisin post-hitos

captura el aprendizaje del proyecto para el desarrollo de los miembros del equipo y la mejora del proceso por finalizado el proyecto

Dar Son

fundamentales para el aprendizaje de la organizacin

Para ms Informacin
Web

sites

Microsoft Solutions Framework site at http://www.microsoft.com/MSF Steve McConnells Survival Guide site at http://www.construx.com/survivalguide/home.htm

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

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.

Microsoft Solutions Framework at a Glance

Methodology A methodology, like a map, applies specific directions and a specific route to a known destination. Orange Street Plum Street 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

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.

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

1st Avenue 2nd Avenue 3rd Avenue

Processes That Are Inflexible to Change

4th Avenue N W S E Smith River

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.

MSF

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.

Relationship of MSF and the Enterprise Architecture

Enterprise Goals
Digital Nervous System Embodies business goals of organisation Project Manager Potential Projects Analyst Developer Logistics

User Education

Features
Developer Testing

Project Tradeoffs
Enterprise architecture Selects the path

Provides the guidance to get there

SYSTEM User Interface Presentation Layer

Team roles
Product management Program management Development

Goal
Satisfied customers Delivery within project constraints Delivery to product specifications Release after addressing all known issues
Milestone Milestone Milestone

Services

Business Layer

Testing User education

Enhanced user performance Smooth product deployment

Milestone

Data Layer Databases

Logistics management

Versioned Releases

Traditional View
Application 1 Application 2 Product Customers Orders Database Customer Database Customers Orders Product Customer Database Orders Database Customers Product Customer Database Application 3

Services View
Application 1 Application 2

Living Documents Steps of the MSF Risk Management Process

Baseline Early
Baseline planning efforts begin as early as possible for an earlier development start

Functional Specification s Vision Document Project Plans Project Schedule Risk Management Document

Identif y Retired Risks

Risk Statement s 5 Contro l

2 Analyse Risk Asessment 3 Document Top 10 4 Track

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. Plan 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 decisionmaking 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.

Freeze Late
Consider documents as dynamic and subject to change

Stovepiped Services

Network of Cooperating Services

MSF Poster March 2001

The ongoing deliverable of this process is a living risk assessment document