MSFMartin Luis Req

Microsoft Solutions Framework
Contenido Microsoft Solutions Framework
• Introducción
• Fase de Visionado
• Fase de Planificación
• Fase de Desarrollo
• Fase de Estabilización
• Fase de Distribución
1
Introducción Microsoft Solutions Framework
• En ingeniería de software utilizamos un modelo de
procesos para el éxito de nuestro proyecto
• Un modelo de proceso dirige el orden de las actividades

del proyecto y representa el ciclo de vida
– Modelo Cascada
– Modelo Espiral
– Modelo MSF
2
• Modelo Cascada
– Utiliza punto de control para pasar a la siguiente fase.
– Fases
• Análisis
• Diseño
• Codificación
• Pruebas
• implementación
• Mantenimiento

• Modelo Cascada
– Se tarda mucho tiempo en pasar por todo el ciclo.
– El fracaso de la industria del software es la

comunicación con el usuario final.
– Se utiliza en proyectos con requerimientos bien

definidos.
3
• Modelo Espiral
– Basada en la necesidad continua de refinar los
requerimientos y estimaciones del proyecto.

• Modelo Espiral
– Efectivo para proyectos pequeños donde con la
retroalimentación dada por el cliente, se aprueba las
diferentes etapas.
– Puede ocurrir el riesgo que no se defina bien los

objetivos por lo cual el desarrollo puede ser caótico.
4
• Modelo MSF
– Combina los mejores principios de los modelos
cascada y espiral

• Modelo MSF
– La planificación basada en punto de control y
beneficios de la retroalimentación del cliente
constituye un proyecto bien planificado con lo cual
tenemos mas posibilidades de éxito en nuestro
proyecto.
– MSF es un proceso para el manejo de proyecto, el

acercamiento al desarrollo rápido con herramientas
RAD y la programación extrema se puede utilizar para
poner un proyecto en ejecución.
5
FASE MSF
MODELO DE EQUIPO
6
IN/COMPATIBILIDADES EN ELMODELO DE EQUIPO

TRIANGULO DE
COMPENSACIÓN
“Dada lo que el cliente ha fijado en: ___________________ seleccionamos

determinadas _______________ y ajustamos ________________________ todo lo
que se necesite.”
7
Iteraciones Microsoft Solutions Framework
8
Fase Visionado Microsoft Solutions Framework
DESCRIPCIÓN
– Es la primera fase de modelo MSF
– Se pretende dar una visión general del proyecto
– Identifica las tareas y los entregables que permiten al

equipo a cumplir con los requerimientos y objetivos
del proyecto.
– Esta fase culmina con el punto de control

Visión/Alcance

RESPONSABILIDAD DE LOS MIEMBROS DEL EQUIPO
• Gestión de producto
– Se asegura que el equipo comprenda las necesidades
del cliente
– Colabora con el gestor del programa
– Asegura que establezca una visión común del
proyecto
• Gestión del proyecto

– Establece la metas diseño del proyecto
– Define los factores y las métricas para el éxito
– Articula los concepto de la solución
– Organiza la infraestructura del proyecto
9
• Desarrollo
– Retroalimenta al equipo en las implementaciones
técnicas del desarrollo
– En la factibilidad del concepto de la solución
• Pruebas
– Retroalimenta al equipo sobre las meta de calidad de
la solución
– Especifica las acciones que se necesitarán para
alcanzar ese nivel de calidad

• Gestión de entregas
– Identifica qué se requerirá para distribuir el producto
– Cómo y cuándo se distribuirá,
– Los casos en el que la distribución requiera
infraestructura adicional.
• Experiencia del usuario.

– Analiza las necesidades de rendimiento y los temas de
soporte relativos a los usuarios
– Considera las implicaciones del producto para que
cumpla con esas necesidades.
10
TAREAS A REALIZAS
• Creación de equipo
– En función a sus habilidades y experiencias
• Definir las estructura de proyecto

- Estructura administrativa y estándar a seguir
- Definir objetivos de negocio

- Análisis el problema o necesidades empresarial para
identificar los objetivos de la solución

TAREAS A REALIZAS
- Crear la sentencia de visión y definir el alcance

del proyecto
- Define que y no será incluido en el solución
- Definir los requerimientos y perfiles de usuario

- Plantear los riesgos
- Identificar y crear el plan de mitigación de riesgo
- Cerrar la fase de visionado

- Con la aprobación del documento visión/alcance
11
PUNTOS DE CONTROL
– Equipo principal organizado

• Sólo los miembros principales
• Roles de cada miembro
• Jerarquía de contabilidad, puntos de contacto con el cliente y
estructura del equipo
– Creada el documento visión/alcance

• Primera versión del documento, distribuida al equipo y al
contacto del cliente.
• En la revisión, el documento actualizará con las
modificaciones procedentes de la retroalimentación y las
discusiones.

DOCUMENTO VISION/ALCANCE
– Para crearlo, el equipo realizará entrevistas con los

clientes y los responsables de la empresa, analizará
con más detalle los casos de uso de alto nivel del
negocio e identificará aquello que se puede asumir,
se ha asumido o las limitaciones del negocio.
– Recuerde que se continuará recogiendo información

durante todas las fases del proceso MSF
12
CONTENIDO DOCUMENTO VISION/ALCANCE
– Sentencia del problema

– Sentencia de visión
– Perfiles de usuario
– Alcance del proyecto
– Concepto de la solución
– Metas del proyecto
– Factores críticos para el éxito
– Calendario inicial

DOCUMENTO DE LA ESTRUCTURA DEL PROYECTO
– Define lo que hará el equipo para gestionar y

organizar el proyecto. Describe la estructura
administrativa del proyecto, los estándares y
procesos y los recursos y limitaciones del proyecto.
Sirve como referencia para los integrantes de los
equipos para saber cómo trabajar juntos de un
modo eficiente y satisfactorio.
13
DOCUMENTO DE LA ESTRUCTURA DEL PROYECTO
– Los componentes primarios en el documento de

estructura del proyecto:
• Equipo y estructura
• Estimaciones del proyecto
• Calendarios del proyecto (versión primaria)

ANALISIS DE RIESGO
– Un riesgo puede definirse como un suceso no

deseado. Riesgo es la posibilidad de pérdida. La
pérdida podría ser cualquier cosa, desde la
disminución de la calidad de una solución hasta el
incremento de coste o fallos del proyecto.
– MSF recomienda evaluar los riesgos durante todo

el proyecto.
14
ANALISIS DE RIESGO

CONTENIDO DOCUMENTO ANALISIS DE RIESGO
– Sentencias de riesgo
• describe la naturaleza de cada riesgo
– Probabilidad de riesgo
– Severidad del riesgo especifica el impacto
– Exposición al riesgo Promedio de amenaza al
riesgo. Se calcula multiplicando la probabilidad por
la severidad
15
CONTENIDO DOCUMENTO ANALISIS DE RIESGO
– Planes de mitigación
• describe los esfuerzos para prevenir el riesgo
– Planes de contingencia y los disparadores

• especifica los pasos a seguir cuando ocurra un riesgo y cuándo
se comenzarán a seguir.
– Propiedad del riesgo

• especifica el nombre del equipo que está a cargo de monitorizar
regularmente el riesgo

ENTREGABLES
– Documento de visión/alcance.
• Sentencias del problema y objetivos empresariales
• Procesos existentes
• Definiciones claras de los requerimientos de usuario
• Perfiles de usuario, identificando quién se beneficia de la
aplicación
• Sentencia de visionado y alcance
• Concepto de la solución
• Estrategias del diseño de la solución
16
ENTREGABLES
– Estructura del proyecto

• Descripción de todos los roles del equipo MSF y lista de
miembros
• Estructura del proyecto y estándares a seguir por el equipo
– Planteamiento de los riesgos

• Preliminares del planteamiento
• Lista primaria de riesgos identificados
• Planes de mitigación

ENTREGABLES
– Otros
• Lista inicial de características a probar
• Requerimientos preliminares y casos de uso
• Arquitectura preliminar
• interfaz gráfico de usuario
– Documentos internos
• Catálogo de actores
• Catálogo de reglas empresariales
• Glosario de términos de uso
17
Fase Planificación Microsoft Solutions Framework
DESCRIPCION
– En esta fase se realiza la preparación de la

especificación funcional, diseño de la solución,
planes de trabajo, costes estimados y calendarios
para los entregables
– Implica la recogida y el análisis de los requerimientos

de negocio, de usuario, operacionales y de sistema.
18
– Se asegura de que el plan cumpla con los requerimientos del
cliente.
– Responsable de refinar los requerimientos
– Analizar el estado actual del negocio,
– Optimizar el concepto de la solución
– Crea el diseño conceptual.
– Se asegura de que el equipo tenga todos los recursos que
necesita para completar el plan del proyecto.
– Responsable del diseño general, con énfasis en el diseño
lógico y en la especificación funcional.
– Crea los planes y calendarios del proyecto
– Responsable de completar la fase de planificación.

• Desarrollo
– Se asegura de que el plan es técnicamente factible.
– Es el responsable de crear el diseño lógico y físico de la
solución y adicionarlo a la especificación funcional.
– También determina el tiempo y esfuerzo requerido para
desarrollar y estabilizar la solución.
• Pruebas
– Asegura que el plan cumpla con los requerimientos.
– Es responsable de evaluar el diseño para determinar
qué características pueden ser probadas y de brindar un
plan y calendario para dichas pruebas.
19
– Evalúa el diseño para la facilidad de la distribución, gestión y
soporte.
– Además, planifica y especifica los calendarios de la distribución.
–
• Experiencia del usuario
– Asegura que los usuarios podrán utilizar el producto.
– Es responsable de analizar las necesidades del usuario y de
crear un estrategias de soporte para evaluar la usabilidad del
diseño completado.
– También estima el tiempo y el esfuerzo requerido para
desarrollar los sistemas de soporte de usuario y conducir las
pruebas de usabilidad para todas las interfaces de usuario a
entregar.

ESPECIFICACIONES FUNCIONALES
– Una especificación funcional es un repositorio virtual

de artefactos relacionados con el diseño y con el
proyecto. Estos artefactos son creados durante la
fase de planificación. Son resultado de actividades de
diseño de los procesos de diseño conceptual, lógico y
físico de la fase de planificación. Pueden incluir
modelos UML como los diagramas de casos de uso,
escenarios de uso, requerimientos candidatos (que
evolucionan), características candidatas y varios
modelos de información.
20
PROCESO EN LA FASE DE PLANIFICACIÓN
– Diseño Conceptual
– Diseño lógico
– Diseño Físico
– Los procesos son dependientes y paralelos, por

ejemplo cuando se cambia el diseño lógico cambia el
diseño físico.

DISEÑO CONCEPTUAL
– Este es el proceso de recoger, analizar y priorizar las

perspectivas del negocio y del usuario acerca del
problema y de la solución, y de luego crear una
representación a alto nivel de la solución.
– Para crear diseños conceptuales usables y precisos,

se necesita preparar un método efectivo de
comprensión de la solución y de comunicar la
solución a todos los tipos de usuarios. Para modelar
las tareas cubiertas por el alcance de la solución, se
generan casos de uso y escenarios de uso.
21
DISEÑO CONCEPTUAL - METAS
• Comprender el problema de negocio a resolver

• Comprender los requerimientos del negocio
• Describir el estado futuro del negocio que se quiere alcanzar

DISEÑO CONCEPTUAL
• Pasos a seguir en el diseño conceptual

– Búsqueda
» Obtener respuestas a preguntas clave
» Identificar los procesos y actividades de negocio clave
» Validar, refinar y extender los requerimientos esbozados,
casos de uso y escenarios de uso creados durante la fase
de visionado
– Análisis
» Revisar la investigación realizada a negocio y usuarios
» Refinar los requerimientos candidatos
– Optimización
» Optimizar el concepto de la solución creado durante la fase
de visionado
» Validar y probar los procesos de negocio mejorados
22
DISEÑO CONCEPTUAL – TAREAS A REALIZAR
– Sintetizar la información
– Refinar los diagramas de casos de uso
– Seleccionar una arquitectura de aplicación apropiada
para la solución
– Crear un modelo conceptual de la solución

DISEÑO CONCEPTUAL – ENTREGABLES
– Modelos de información
– Perfiles de usuario actualizados
– Requerimientos candidatos
– Casos de uso detallados
– Escenarios de uso actuales
23
DISEÑO LÓGICO
– El diseño lógico es el proceso de describir la solución
en términos de su organización, su estructura y la
interacción de sus partes desde la perspectiva del
equipo del proyecto.

DISEÑO LÓGICO – TAREAS A REALIZAR
– El análisis del diseño lógico se basa en las siguientes

tareas:
• Redefinir la lista de herramientas y tecnologías candidatas
• Identificar los objetos de negocio y los servicios
• Identificar los atributos importantes y las relaciones clave
– La optimización del diseño lógico sigue las siguientes
tareas:
• Redefinirlo
• Validarlo
24
DISEÑO LÓGICO – REFINAR LA TECNOLOGÍA CANDIDATAS
– se refinan las tecnologías candidatas identificadas en

la fase de diseño conceptual. Para ello, se tendrán en
cuenta las siguientes consideraciones:
• Factibilidad:
– ¿Cumplirá en realidad la tecnología con las necesidades del
negocio y estará dirigida a sus requerimientos?
• Coste del producto:
– Incluirá costes de desarrolladores, servidor, licencias de
reventa y actualización; costes iniciales de hardware y software,
soporte, infraestructura y adiestramiento. Considere que la
inversión puede ser a corto o a largo plazo

DISEÑO LÓGICO - REFINAR LA TECNOLOGÍA CANDIDATAS
• Experiencia:
– ¿Cuánta experiencia necesitarán los usuarios con las diferentes
tecnologías? Esto puede tener grandes repercusiones
• Ganancias sobre la inversión:
– No seleccione una tecnología sólo porque es nueva
• Madurez:
– Un producto maduro es aceptado en el mercado, bien
comprendido, estable y tiene suficientes recursos de soporte
disponibles
• Soportabilidad:
– Cuando se selecciona una tecnología, es importante darse
cuenta que la misma necesitará soporte mientras esté
funcionando la solución creada sobre ella. Considere estas
implicaciones.
25
– A SELECCIONAR LA TECNOLOGI A TENER EN CUENTA
• Seguridad:
– autenticación, autorización, encriptación, auditoria
– Estándares de interacción entre servicios:
» estándares de interacción entre plataformas y temas
relacionados
– Acceso a datos:
» rendimiento, estandarización, dirección futura, gestión de
acceso a datos, diversidad de repositorios de datos
– Almacenamiento de datos:
» Distribución en varias ubicaciones, granja de servidores o
en un solo ordenador

– Servicios del sistema:

» pueden incrementar la disponibilidad, la tolerancia a fallos
y el balanceo de carga.
– Herramientas de desarrollo:
» ayudan a decrementar el tiempo requerido para crear
aplicaciones.
– Sistemas operativos:
» Los servicios que vienen con el sistema operativo pueden
reducir significantemente los requerimientos de
codificación
26
DISEÑO LÓGICO
IDENTIFICAR LOS OBJECTOS DE NEGOCIO CANDIDATOS
– Objetos se le llama a las personas o cosas descritas en los

escenarios de uso. Forman las bases de los servicios, atributos y
relaciones.
– Estudiando los escenarios de uso para un caso de uso en

específico e identificando los sustantivos es una buena forma de
identificar a los objetos.
– Cuando se estudian los sustantivos y los verbos asociados, se

identifican los objetos y los servicios asociados.
– Tenga en cuenta también que un sustantivo podría identificar un

atributo de un objeto y no el objeto en sí.

DISEÑO LÓGICO – IDENTIFICACIÓN DE LOS ATRIBUTOS
– Atributo de un objeto se le llama a las definiciones de los valores

de datos que contiene le objeto. También son conocidos como
propiedades. Al grupo de valores de los atributos de un objeto se
le conoce como estado del objeto.
– Para identificarlos, regrese al escenario de uso. Busque las

palabras o frases que más identifican al objeto.
– Aunque se pueden incluir muchos atributos por objeto, el equipo

del proyecto debe incluir sólo los atributos relevantes.
27
DISEÑO LÓGICO – IDENTIFICACIÓN DE LOS SERVICIOS
– Servicio es llamado al comportamiento específico que puede

realizar un componente de negocio. Se refiere a una operación,
función o transformación que puede aplicarse a un objeto o ser
implementada por él.
– Los servicios se utilizan para implementar las reglas de negocio,

manipular datos y acceder a la información. Puede realizar
cualquier actividad que pueda ser descrita por un grupo de
reglas.
– Para identificarlos, examine nuevamente los escenarios de uso e

identifique las acciones que el objeto debe realizar. Continúe
analizando que se supone que realice el objeto y el tipo de datos
que el objeto debe mantener. Si el objeto mantiene información,
frecuentemente realizará operaciones sobre ella.

DISEÑO LÓGICO – IDENTIFICACIÓN DE LAS RELACIONES
– Las relaciones ilustran el modo en el que los objetos

se relacionan entre ellos. UML define cuatro tipos de
relaciones:
• Dependencia
– Relación entre dos objetos en el que un cambio a uno (independiente)
puede afectar el comportamiento o servicio del otro (dependiente).
Utilícela cuando se quiere mostrar un objeto utilizando a otro.
• Asociación
– Relación estructural que describe una conexión entre objetos. Existen
dos tipos de asociación: agregación y composición.
• Generalización
– Representa una relación entre una cosa general (llamada el padre) y
una cosa especializada o específica (llamada el hijo).
28
DISEÑO LÓGICO – DOCUMENTACIÓN DE LAS SALIDAS
– De entre las técnicas variadas que existen para

documentar las salidas del diseño lógico
• La técnica de tarjetas Clase-Responsabilidad- colaboración

(CRC)
• Los diagramas de secuencia.
– En combinación, las tarjetas CRC y los diagramas de

secuencia se pueden utilizar para validar los objetos y
sus relaciones identificados durante el análisis.

– Tarjetas CRC
• Las tarjetas CRC ayudan al equipo a centrarse en las responsabilidades de
alto nivel de una clase en vez de sus métodos y atributos detallados. El
propósito de ello es identificar sus servicios. Las tarjetas CRC identifican
todas las clases con las que debe interactuar una clase e identifica las
relaciones entre las clases. Para validar estar tarjetas, el equipo recrea los
escenarios de uso a partir de las tarjetas CRC creadas.
29
– Diagramas de secuencias
• Los diagramas de secuencia muestran los actores y los objetos que
participan en una interacción junto a la lista cronológica de eventos que los
mismos generan.

DISEÑO LÓGICO – MODELO LÓGICO DE DATOS
– Se puede utilizar tanto el modelo lógico de objetos

como el de datos para representar el diseño lógico.
– Cuando se realiza el modelo lógico de datos, se

convierten las necesidades conceptuales de datos
identificadas en el diseño conceptual en entidades y
relaciones que definirán cómo interactúan los datos.
Esta información ayuda a modelar el diseño físico.
30
DISEÑO LÓGICO – MODELO LÓGICO DE DATOS

DISEÑO LÓGICO
DISEÑO PREDETERMINAR INTERFAZ USUARIO
– La lista de objetos y servicios da al equipo una idea

acerca del tipo de funcionalidad que esperan los
usuarios. El equipo puede usar esta información para
diseñar elementos de la interfaz de usuario como
botones, campos de texto y elementos de menú.
– Aunque el diseño IU se realiza en el diseño físico,

podemos realizar un previo en el diseño lógico.
31
DISEÑO LÓGICO – ENTREGABLES
– Un modelo lógico de objetos

– Un diseño preliminar de la interfaz de usuario
– Un modelo de datos lógico

DISEÑO FÍSICO
– El diseño físico tiene como tarea principal describir los

componentes, servicios y tecnologías de la solución
desde la perspectivas de los requerimientos de
desarrollo. Define, además, las partes de la solución
que van a desarrollarse, cómo serán desarrolladas y
como interactúan entre ellas.
32
DISEÑO FÍSICO
– Al final del diseño físico el equipo entrega la especificación de un grupo

de componentes, ensamblados de Microsoft .NET, binarios y librerías;
detalles de la interfaz de usuario de la solución; el esquema de la base
de datos; objetos de la base de datos como los triggers, índices,
procedimientos almacenados; y detalles de los reportes que usará la
solución.

DISEÑO FÍSICO
La diferencia entre el diseño lógico al físico es

– Mientras se realiza el diseño lógico de la solución, el equipo
observa el problema desde la perspectiva del equipo del
proyecto. Al pasar al diseño físico, el problema debe analizarse
desde la perspectiva del equipo de desarrollo.
– En el diseño lógico el equipo documenta actividades y

limitaciones del negocio. En el diseño físico el equipo define una
solución encauzando las limitaciones de las tecnologías de
desarrollo seleccionadas y del entorno de desarrollo.
33
DISEÑO FÍSICO – METAS
– Identificar las tecnologías apropiadas para el

desarrollo
– Transformar el diseño lógico en modelos de diseño
físico
– Brindar una línea para el proceso de desarrollo
– Definir cuándo se ha satisfecho el punto de control de
plan del proyecto aprobado.

DISEÑO FÍSICO – BUSQUEDA
– Los entregables de este paso describen la

infraestructura actual del negocio y brindan las bases
para el análisis, la racionalización y los pasos para el
diseño físico. Estos entregables incluyen:
• Topología de red actual
• Topología de datos actual
• Topología de componentes actual
• Requerimientos físicos de la aplicación
• Evaluación de riesgos actualizada y planes de mitigación
34
DISEÑO FÍSICO
– En el proceso de diseño se recoge y analiza

información acerca de requerimientos y limitaciones
del negocio. En el diseño físico, el equipo se centra
en los requerimientos y limitaciones físicos.
– Requerimientos
• Rendimiento, Coste y beneficios, Facilidad de uso,
soportabilidad, fiabilidad, reusabilidad
– Limitaciones
• Presupuesto, Calendario, Topología de red, Topología de
datos, Topología de componentes, Líneas de tecnología,
Seguridad

DISEÑO FÍSICO
– Durante este paso del diseño físico, el equipo crea y

refina los modelos de diseño físicos utilizando la
documentación del diseño lógico.
– Además se refinan los artefactos relacionados con

diseño y especificaciones (modelos UML,
requerimientos y casos de uso) y aquellos
relacionados con el proyecto (documento de riesgos,
planes y calendarios del proyecto y el catálogo de
actores).
35
DISEÑO FÍSICO – TAREAS
– Durante el análisis del diseño físico el equipo
realizará las siguientes tareas para refinar los
diagramas UML:
• Transformar los objetos lógicos en definiciones de clases,
incluyendo sus interfaces
• Identificar objetos que no se encontraron durante el diseño
lógico (como los basados en servicios)
• Consolidar los objetos lógicos si es necesario
• Categorizar los objetos en un modelo basado en servicios
• Los objetos limítrofes son potencialmente servicios de
usuario
• Los objetos de control son potencialmente servicios de
negocio

DISEÑO FÍSICO
- Diagramas de Clases
- Diagramas de secuencias
- Diagramas de actividad
- Diagramas de componentes
36
DISEÑO FÍSICO – TOPOLOGÍA DE RED
– La topología de distribución es un mapa que indica la ubicación

de paquetes, componentes y sus servicios en relación con la
topología de red. Muestra, además, la ubicación de los
almacenes de datos.

DISEÑO FÍSICO – EMPAQUETAR LOS COMPONENTES
– El enfoque principal de la racionalización del diseño físico es la
distribución y empaquetado de los servicios. En el primer paso
de este proceso, éstos se empaquetan en tres capas: de
usuario, de negocio y de datos.
37
DISEÑO FÍSICO – DIAGRAMA DE DISTRIBUCION
– El modelo de distribución es un diagrama que asocia la
aplicación y sus servicios a la topología de servidores actual. Su
propósito es permitir al equipo de desarrollo y al de gestión de
entregas diseñar y planificar la topología de servidores y su
configuración

DISEÑO FÍSICO – ENTREGABLES
– Interfaz preliminar, con seudo código

– Diagramas de clase de la solución
– Modelos de componente, diagramas de secuencia o
diagramas de actividad de la solución
– Esquema de bases de datos de la solución
– Modelo de línea de desarrollo de la solución
– Topología de red, ubicaciones de hardware e
interconexiones
38
DISEÑO FÍSICO – ENTREGABLES
– Topología de implementación, ubicación de los

componentes, servicios y gestores de datos de la
solución en relación con la topología de red
– Especificaciones de componentes con estructura
interna de componentes e interfaces de componentes
– Estrategia de empaquetado y distribución
– Modelo de programación, que identifica las opciones
de implementación, estado en los objetos y modelos
de conexión, líneas para multiprocesamiento, gestión
de errores, opciones de seguridad y documentación
del código.
39
Fase Desarrollo Microsoft Solutions Framework
DESCRIPCION
– La meta de la fase de desarrollo es la construcción de

los elementos y entregables de la solución, incluidos
los códigos de los componentes, infraestructura
(software, hardware, red) y la documentación para el
uso de las operaciones.

– Expectativas del clientes

– Gestión de las especificaciones funcional
– Camino del proyecto
– Plan de actualización
40
• Pruebas
– Pruebas funcional
– Identificación de resultados
– Documentación de pruebas
– Actualización del plan de pruebas
• Desarrollo
– Desarrollo del código
– Infraestructura del desarrollo
– Configuración de documentación

• Gestión del entregas

– Rollout checklists
– Rollout y actualización del plan piloto
– Preparación checklists

– Formación
– Actualización del plan de formación
– Prueba de usabilidad
– Diseño gráfico
41
TAREAS A REALIZAR
– Comenzar el ciclo de desarrollo

• Verificar que las tareas de visionado se hayan completado
– Crear prototipo
• Verificación de conceptos de diseño de la solución en un
entorno que simule el entorno de la solución que se
distribuirá, lo más similar posible al de producción. Debe
completarse antes de comenzar el desarrollo.
– Desarrollo de los componentes de la solución

• Componentes principales y sus extensiones

TAREAS A REALIZAR
– Desarrollo de la solución
• Compilaciones diarias que culminan con una compilación
principal que demuestra los puntos en los que el equipo de
desarrollo entrega las características clave de la solución
– Cerrar la fase de desarrollo

• Entrega de código y documentación
• Punto de control de proceso aprobado
42
PUNTOS DE CONTROL
– Aplicación de prueba de conceptos completada

• Prueba los elementos clave de la solución en un entorno
de pruebas.
– Compilaciones internas completadas

• Aplicación desarrollada en segmentos
• Sincronización de segmentos

ENTREGABLES
– Código fuente y archivos ejecutables

– Scripts de instalación y datos de configuración para
la distribución
– Especificación funcional terminada
– Elementos de soporte del funcionamiento
– Especificaciones para pruebas y casos a probar
43
Fase Estabilización Microsoft Solutions Framework
DESCRIPCIÓN
– La solución se pasa un entorno real de exploración.
– Determinar que la solución cumple los criterios de

calidad necesarios para pasar a la fase de
despliegue.
– Reproducción de condiciones reales y el equipo se

concentra en detectar y priorizar errores, preparando
la solución para su despliegue.
44
– Comunicaciones del estado del proyecto.
– Planeamiento de lanzamiento del producto.

– Seguimiento del proyecto
– Prioridad de errores

• Desarrollo
– Resolución de errores
– Optimización del código
• Pruebas
– Pruebas, detección y comunicación de errores
45
– Soporte de piloto, planeamiento del despliegue
– Formación de soporte
• Experiencia de usuario
– Estabilización de materiales de formación y asistencia

TAREAS A REALIZAR
– Probar la solución
– Implementación de planes de prueba para validar el
producto
– Prueba rigurosas:
• Prueba de componentes
• Prueba de base de datos
• Prueba de Infraestructura
• Prueba de Seguridad
• Prueba de Integración
• Prueba de aceptación y usabilidad del usuario
• Prueba de estrés, capacidad y rendimiento
• Prueba de regresión
46
TAREAS A REALIZAR
– Recogida del número de errores

– Guiar la prueba piloto
– Distribuir la solución en un área temporal con
usuarios y escenarios de uso reales.

PUNTO DE CONTROL
– Convergencia de errores
• Análisis de la cantidad de errores encontrados y corregidos
cada vez
– Entrega libre de errores

– Candidatos a distribución
• Serie de puntos de control que reflejan mejoras
incrementales en la reducción de errores realizando una
comparación con la entrega libre de errores
– Entrega dorada
– Cierre de la fase
47
CONVERGENCIA DE ERRORES
– Es el punto en el cual el equipo resuelve más errores

de los que detecta.
– Normalmente se tratará de una tendencia más que de

un punto fijo.

SALTO A CERO ERRORES
– Es el momento en el que el equipo de desarrollo

resuelve todos los errores surgidos en las pruebas.
– Después del salto de cero errores pueden aparecer

errores si bien de forma ocasional
48
CANDIDATOS DE PUBLICACIÓN
– Después de alcanzar el primer salto de cero errores,

se generan sucesivos candidatos a publicación
PUBLICACIÓN DORADA
– Es la publicación preparada para pasar a producción.

Para seleccionar cuál será esta publicación se
emplean los datos de pruebas, los criterios de éxito y
el triángulo de compensación.

TIPO DE PRUEBAS
– Check-in tests
• Asegura que el código cumple con todos los requisitos de la
especificación funcional.
– Unit tests:
• Es una forma de pruebas automatizada sobre un pequeño
trozo de código aislado, que realiza quien ha desarrollado el
elemento
– Functional tests:
• Realizan pruebas automatizadas donde se evalúa el
resultado final de un proceso.
49
TIPO DE PRUEBAS
– Build verification tests:

• El objetivo es identificar errores durante la generación del
proyecto.
– Regrection tests:
• Es el proceso de repetir pruebas ya realizadas sobre
versiones anteriores del mismo componente para comprobar
que el problema detectado ya no está presente, que ha sido
completamente resuelto y si la forma de resolverlo puede
provocar otros problemas
– Configuration tests:
• Muchas aplicaciones pueden ser instaladas y configuradas de
diferentes formas. Estas pruebas aseguran que cualquier tipo
de configuración no afectará el buen funcionamiento de la
aplicación.

TIPO DE PRUEBAS
– Compatibility tests
• Se centran en la interoperabilidad de la aplicación
– Stress tests:
• Diseñados para identificar errores cuando el nivel de carga de
la aplicación aumenta considerablemente.
– Performance tests:
• Evalúan el nivel de rendimiento de la aplicación. Normalmente
se realizan junto con los stress tests
50
TIPO DE PRUEBAS
– Compatibility tests
• Se centran en la interoperabilidad de la aplicación
– Documentation and help file tests:

• Detectan posibles errores en la documentación de soporte o
en los archivos de ayuda
– Alpha and beta tests:

• En el modelo MSF se denomina código alfa al creado en la
fase de desarrollo, mientras que el código beta es el
producido tras la fase de estabilización.
– Paralell tests:
• Se trata de probar la solución actual y la nueva de forma
paralela.

PRUEBAS PILOTOS
– Una prueba piloto es una prueba de la solución en el

entorno de producción, incluyendo instalación, soporte
y finales.
– Los objetivos de la prueba piloto son demostrar que la

solución funciona en el entorno de producción y
permitir al equipo de despliegue probar y refinar sus
procesos.
51
PRUEBA PILOTO - PREPARACIÓN
– La prueba piloto debe cubrir todos los procesos de la

solución y no es necesario que el cliente la apruebe.
– Antes de realizar la prueba piloto prepararemos el

plan piloto que incluirá:
• Alcance y objetivos
• Participantes
• Plan de formación
• Plan de soporte
• Plan de comunicación
• Riesgos identificados y planes de contingencia
• Plan de vuelta atrás
• Calendario

PRUEBA PILOTO – EVALUACIÓN DE LOS RESULTADOS
– Al final de la prueba piloto habremos recogido

información mediante:
• Formularios web de recogida de datos
• Informes sobre problemas
• Puntos de vista de usuarias y usuarios finales
• Logs de la aplicación y el sistema
– Una vez recogida y analizada la información

tomaremos
• Preparar otro candidato a publicación
• Devolver la prueba piloto a la fase de preparación
• Suspender la prueba piloto
• Trasladar la prueba piloto a despliegue
52
CIERRE DE LA FASE DE ESTABILIZACIÓN
– El cierre de la fase de estabilización finaliza con la aprobación de

la “publicación preparada" y preparación de la versión para
despliegue, en este punto todos los involucrados en el proyecto
pueden evaluar la solución para comprobar si cumple con todas
las especificaciones.

ENTREGABLES
– Distribución final
– Notas de distribución
– Elementos de soporte del funcionamiento
– Resultado de las pruebas y herramientas de prueba
– Código fuente y archivos ejecutables
– Documentos del proyecto
– Análisis del punto de control
53
Fase Distribución Microsoft Solutions Framework
DESCRIPCIÓN
– Es la última fase de modelo.
– En la cual se instalan los componentes, se estabiliza

el proyecto y se obtiene la aprobación por parte del
cliente.
54
– Realimentación del cliente
– Valoración, cierre

– Comparación alcance / Solución
– Gestión de la estabilización

• Desarrollo
– Resolución problemas
– Soporte de escalabilidad
• Pruebas
– Pruebas de rendimiento
– Resolución de problemas
55
– Gestión de despliegue
– Aprobación de cambios

– Formación.
– Gestión de los calendarios de formación.

TAREAS A REALIZAR
• Sistemas de información de operaciones y soporte

• Procedimientos y procesos
• Base de conocimientos
• Almacén de todas las versiones de los
documentos, configuraciones, scripts y código
• Informes de cierre de proyecto
56
PUNTOS DE CONTROL
– Componentes principales distribuidos

• Mientras se estabilizan otras partes de la solución, los
componentes principales deben ser distribuidos antes o
conjuntamente con toda la solución.
– Distribución in-situ completada

• Todos los usuarios deben ser capaces de acceder a la
aplicación

PUNTOS DE CONTROL
– Distribución estable
• El cliente y el equipo están de acuerdo en que el producto
funciona satisfactoriamente. Pueden surgir algunos
imprevistos que se anotan y resuelven.
• El tiempo entre este punto de control y el siguiente se llama
período de silencio. Aunque el equipo no está activo, se
responde a los eventos que el cliente les presente.
– Distribución completada
• Culminación de la fase de distribución.
• El cliente debe estar obteniendo resultados claros de la
solución implantada.
57
DESPLIEGUE EN EL ENTORNO DE PRODUCCION
El equipo revisará la siguiente documentación

• Diagramas de despliegue
• Plan de pruebas
• Plan de seguridad
• Plan de copia de seguridad
• Plan de análisis de rendimiento
• Plan de recuperación de desastres

PERIODO DE SILENCIO
– Una vez instalado el aplicativo se establece un

período de silencio, en el cual se le pasa la
responsabilidad al equipo de soporte.
– Cualquier error se le pasa al equipo de desarrollo.
58
FINALIZACION
– Cuando se realiza la aprobación por parte del cliente

se realiza la tareas de cierres del proyecto
– Tareas
• Encuesta de satisfacción del cliente
• Informe de cierre
• Aprobación del cliente.

ENTREGABLES
– Sistemas de operación y soporte

• Procedimientos y procesos
• Base de conocimientos, informes y libros de recogida de
sucesos
– Repositorio de documentos de todas las versiones de los

documentos y del código desarrollado
– Plan de entrenamiento
– Informe de finalización del proyecto

• Versiones finales de todos los documentos
• Datos de satisfacción del cliente
• Definición de los próximos pasos
59
60

MSFMartin Luis Req

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MSFMartin Luis Req

Uploaded by

Copyright:

Available Formats

Microsoft Solutions Framework

Contenido Microsoft Solutions Framework

• Un modelo de proceso dirige el orden de las actividades

Introducción Microsoft Solutions Framework

– El fracaso de la industria del software es la

– Se utiliza en proyectos con requerimientos bien

Introducción Microsoft Solutions Framework

– Puede ocurrir el riesgo que no se defina bien los

Introducción Microsoft Solutions Framework

– MSF es un proceso para el manejo de proyecto, el

Introducción Microsoft Solutions Framework

Introducción Microsoft Solutions Framework

“Dada lo que el cliente ha fijado en: ___________________ seleccionamos

– Es la primera fase de modelo MSF

– Se pretende dar una visión general del proyecto

– Identifica las tareas y los entregables que permiten al

– Esta fase culmina con el punto de control

Fase Visionado Microsoft Solutions Framework

• Gestión del proyecto

Fase Visionado Microsoft Solutions Framework

• Experiencia del usuario.

• Definir las estructura de proyecto

- Definir objetivos de negocio

Fase Visionado Microsoft Solutions Framework

- Crear la sentencia de visión y definir el alcance

- Definir los requerimientos y perfiles de usuario

- Cerrar la fase de visionado

– Equipo principal organizado

– Creada el documento visión/alcance

Fase Visionado Microsoft Solutions Framework

– Para crearlo, el equipo realizará entrevistas con los

– Recuerde que se continuará recogiendo información

– Sentencia del problema

Fase Visionado Microsoft Solutions Framework

– Define lo que hará el equipo para gestionar y

– Los componentes primarios en el documento de

Fase Visionado Microsoft Solutions Framework

– Un riesgo puede definirse como un suceso no

– MSF recomienda evaluar los riesgos durante todo

Fase Visionado Microsoft Solutions Framework

– Planes de contingencia y los disparadores

– Propiedad del riesgo

Fase Visionado Microsoft Solutions Framework

– Estructura del proyecto

– Planteamiento de los riesgos

Fase Visionado Microsoft Solutions Framework

– En esta fase se realiza la preparación de la

– Implica la recogida y el análisis de los requerimientos

Fase Planificación Microsoft Solutions Framework

Fase Planificación Microsoft Solutions Framework

– Una especificación funcional es un repositorio virtual

– Los procesos son dependientes y paralelos, por

Fase Planificación Microsoft Solutions Framework

– Este es el proceso de recoger, analizar y priorizar las

– Para crear diseños conceptuales usables y precisos,

• Comprender el problema de negocio a resolver

Fase Planificación Microsoft Solutions Framework

• Pasos a seguir en el diseño conceptual

Fase Planificación Microsoft Solutions Framework

Fase Planificación Microsoft Solutions Framework

– El análisis del diseño lógico se basa en las siguientes

– se refinan las tecnologías candidatas identificadas en

Fase Planificación Microsoft Solutions Framework