Upload
maritza-raso
View
10
Download
0
Embed Size (px)
Citation preview
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
Hito Aprobación de Visión
Hito Aprobación del Plan de Proyectos
Hito Alcance Completo
Hito Liberación
Resumen
Qué es MSF?
Porcentaje de Proyectos fracasados
Proyectos de Desarrollo de Aplicaciones
Modificados
Exitosos
Fracasados 28%28%46%46%
26%26%
“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
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
Origen
Grupos deProductosMicrosoft
todo mundo
Grupos deProductosMicrosoft
todo mundo
Información Tecnológica
Microsoft
Información Tecnológica
Microsoft
Servicios de
ConsultoríaMicrosoft
Servicios de
ConsultoríaMicrosoft
Partners de Microsoft
Partners de Microsoft
Mejores Prácticas
Curriculum MSF
ConstruirPlanificar
Gerenciar
MSF
Introducción alModelo de Equipo
Equipos Jerárquicos
Las dificultades del trabajo en equipos jerárquicos
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
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
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
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.
Modelo de Equipo para el Desarrollo de Aplicaciones
Gerente deDesarrolloGerente deDesarrollo
DesarrolladorDesarrollador
TestingTesting
GerenteDe Logística
GerenteDe Logística
FormaciónDe UsuariosFormación
De Usuarios
Gerente de Producto
Gerente de Producto
Comunicación
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.
GerenteDe Producto
GerenteDe Producto
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 deDesarrolloGerente deDesarrollo
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
DesarrolladorDesarrollador
TestingTestingRol 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
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ónde UsuariosFormación
de Usuarios
Gerentede Logística
Gerentede 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
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
NO un organigrama tradicional
Testing
Desarrollo
ManagerProyecto
Logística
Desarrollo
AnalistaEducaciónde Usuario
Coordinación con equipos externos
Foco Tecnológico
Foco de NegociosUsuarios Finales
Arquitectos de negocio y
planificadores
Clientes
Arquitectos de TecnologíaY comités de dirección
Operaciones y grupos de soporte
Usuarios Finales
Equipo de Proyecto
Formación de Usuario
Desarrollador
Testing
Gerente deLogistica
Gerentede Producto
Gerente de Desarrollo
Escalando para proyectos pequeños
ProgramManagement
ProgramManagement DevelopmentDevelopment TestingTesting Logistics
ManagementLogistics
ManagementUser
EducationUser
EducationProduct
ManagementProduct
Management
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
LogisticsManagement
LogisticsManagement
UserEducation
UserEducation
ProductManagement
ProductManagement
NoNPosibleP ImprobableI
P
P
P
P
P
P P
P P
P
I
I
II
I
I
I
I
N
N
N
N N
N
N
N
N
N N N
GerenteDe Producto
GerenteDe Producto
Ejemplo: Roles combinados
Gerente deDesarrolloGerente deDesarrollo DesarrolladorDesarrollador
TestingTesting
GerenteDe Logística
GerenteDe Logística
FormaciónDe UsuariosFormación
De Usuarios
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
Ejemplo: Equipos de Funcionalidad
DevelopmentDevelopment
TestingTestingUserEducation
UserEducation
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTestingUserEducation
UserEducation
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTestingUserEducation
UserEducation
ProgramManagement
ProgramManagement
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
LogisticsManagement
LogisticsManagement
UserEducation
UserEducation
ProductManagement
ProductManagement
Equipolíder
Equipo UI
EquipoImpresión
EquipoCentral
Ejemplo: Equipos de Función
Gerente deGrupo de Producto
Evangelizador
RelacionesPúblicas
Marketing
PlanificadorDe Producto
Gerente De Producto
Gerente De Producto
Administración de Riesgos
Riesgo
Definición 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
Documento
de estimación
de riesgos
Top 10
Riesgos Reiterados 3. Plan 5. Control
2. Analizar1. IdentificarDeclaraciónDe Riesgos
4. Track
Proceso de Administración de Riesgos
El entregable de este proceso es el documento de estimación de riesgos
dinámico
El entregable de este proceso es el documento de estimación de riesgos
dinámico
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
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
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
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
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
Introducción al Modelo de Procesos
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
Modelo de Proceso para el desarrollo de Aplicaciones
IENV
SO
G
IN
NI
P LA
NI
GN
ND
EV
LO
PIG
E
N
ST
AB
I LZ
NGI
I
Vision Approved
Vision Approved
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
ReleaseRelease
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
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
Principios de un Proceso Exitoso
Crear documentación actualizada
Utilizar entregas versionadas
Hacer compensaciones del proyecto
Res
ourc
es
Res
ourc
es
FeaturesFeatures
Schedule
Schedule
Matriz de compensaciones del proyecto
ConstrainConstrainOptimizeOptimize AcceptAccept
CronogramaCronograma
CaracterísticasCaracterísticas
RecursosRecursos
Res
ourc
es
Res
ourc
es
FeaturesFeatures
Schedule
Schedule
Hito Visión Aprobada
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
Definiendo el alcance
Res
ourc
es
Res
ourc
es
FeaturesFeatures
Schedule
Schedule
VisionandoVisionando
Hito de Visión Aprobada
IENV
SO
G
IN
NI
P LA
NI
GN
N
DE
VL
OPI
GE
N
ST
AB
I LZ
NGI
I
Project PlanApproved
Project PlanApproved
ReleaseRelease
Vision Approved
Vision Approved
Scope Complete
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
Hitos interinos sugeridos
Borrador del Documento de Estimación de Riesgos
Borrador del Documento Vision
Vision Aprobado
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
Entregables Propó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
Gerente de Desarrollo
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
Contenido 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?
Contenidos del Documento Visión
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
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
Hito Aprobación del Plan de Proyecto
Importancia de planificar
Costo de reparar defectos por fase
100
80
60
40
20
Envisioning Planning Developing Stabilizing
Definiendo más el alcance
Res
ourc
es
Res
ourc
es
FeaturesFeatures
Schedule
Schedule
PlanificandoPlanificando
Hito Plan de Proyecto Aprobado
IENV
SO
G
IN
NI
P LA
NI
GN
N
DE
VL
OPI
GE
N
L
ST
ABI
ZNG
II
Vision Approved
Vision Approved
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
ReleaseReleaseIndica 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?
Hitos interinos sugeridos
Borrador de especificación funcional
Plan de Proyecto Aprobado
Plan de Proyecto Aprobado
Borrador de Cronograma de proyecto maestro
Borrador del plan de proyecto maestro
Revisión del proceso de diseño
Diseño LógicoDiseño conceptual
EscenariosEscenariosDiseño Físico
Componentes, interfaz de usuario, y base de datos física
Componentes, interfaz de usuario, y base de datos física
Objetos y servicios, Unterfaz de usuario y base de datos lógica
Objetos y servicios, Unterfaz de usuario y base de datos lógica
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
VisionAprobada
VisionAprobada
Línea base del Diseño Lógico
Línea base del Diseño Conceptual
Modelo de aplicación MSF
Serviciosde Negocios
Serviciosde Usuarios
ServiciosDe Datos
Aplicación 1 Aplicación 2
Entregable Propó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
Gerente de Desarrollo
Gerente de Desarrollo
Gerente de Desarrollo
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
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
IENV
SO
G
IN
NI
P LA
NI
GN
N
DE
VL
OPI
GE
N
ST
AB
I LZ
NGI
I
Vision Approved
Vision Approved
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
ReleaseRelease
Hito Alcance Completo
Hitos interinos sugeridos
Alcance CompletoAlcance
Completo
Versión Interna n
Versión Interna...
Versión Interna 2
Versión Interna 1
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 yestabilización
Tiempo de margen
Test de aceptación
HitoRevisión
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
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
Proceso continuo de Testing
DE
VL
O
PIG
E
NS
TA
BI L
ZNG
II
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
ReleaseRelease
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
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
Proceso de Bug Tracking
ResolveDevelopers
CloseTester
Prioritize and Assign
Development Lead
ReportTester
BugRetired
Hito Liberación
Hito Liberación
IENV
SO
G
IN
NI
P LA
NI
GN
N
DE
VL
OPI
GE
N
ST
AB
I LZ
NGI
I
Vision Approved
Vision Approved
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
ReleaseReleaseIndica 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
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
Hitos interinos sugeridos
ReleaseRelease
Convergencia de Bug
Versión Cero-Bug
Versión Candidata
Versión Golden
Focalizándose en el lanzamiento
BetaBug Convergence
Zero-Bug Release
Release Candidate
Golden Release
Release0
Bugs Activos
Tiempo
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
Para más Información Web sites
Microsoft Solutions Framework site at http://www.microsoft.com/MSF
Steve McConnell’s 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
Res
ourc
es
Features
Schedule
Project TradeoffsProject Tradeoffs
Versioned ReleasesVersioned Releases
Testing
Developer
ProjectManager
Logistics
Developer
AnalystUser 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
Plu
m S
tree
t
Ora
ng
e S
tree
t
. .
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 ProjectsPotential Projects
Enterprise GoalsEnterprise Goals
Enterprisearchitecture
Selects the path
Enterprisearchitecture
Selects the path
Provides theguidance to
get there
Digital Nervous SystemEmbodies business goals of
organisation
Digital Nervous SystemEmbodies business goals of
organisation
Relationship of MSF and the Enterprise Architecture
Retired Risks
Risk Asessment Document
Top 10
Identify
RiskStatement
s
The ongoing deliverable of this process is a living risk assessment document
Control
Track
Analyse
Plan
1122
33
44
55
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 ProcessBaseline Early
Baseline planning efforts begin as early as possible for an earlier development start
Freeze LateConsider documents as dynamic and subject to change
Functional Specifications
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
DatabaseCustomer Database
Customer Database
Customer Database
Customer Database
Customer Database
Orders DatabaseOrders
Database
Orders DatabaseOrders
Database
ProductProduct
CustomersCustomers
CustomersCustomers
ProductProduct
OrdersOrders
CustomersCustomers
ProductProduct
Traditional ViewTraditional View Services ViewServices View
Network of Cooperating Services
Application 1 Application 2 Application 3
Stovepiped Services
Application 1 Application 2
MilestoneMilestone
MilestoneMilestone
MilestoneMilestone
MilestoneMilestone
Phase One
Phas
e Fou
r
Phase Three Phas
e 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 PosterMarch 2001