Universidad Nacional Experimental de los Llanos Occidentales LA … · 2018. 5. 28. · Universidad...

Universidad Nacional Experimental de los Llanos Occidentales

“Ezequiel Zamora” Barinas, Estado Barinas

LA UNIVERSIDAD QUE SIEMBRA

Estudiantes:Quintero Jesús D. C.I.22.114.321Ramos Carlos C.I.22.983.208Carrera: Ing. en Informática.Semestre:VII.Sección: 01D.

Prof. Darjeling Silva

Barinas, marzo de 2.014

Microsoft Solutions Framework (MSF) es una

metodología desarrollada por Microsoft Consulting Services

que define un marco de trabajo de referencia para construir

e implantar sistemas empresariales distribuidos basados en

herramientas y tecnologías de Microsoft para cualquier

plataforma (Linux, Citrix, Microsoft, Unix).

MSF 1.0: 1993 MSF fue introducido por primera vez por

Microsoft como la versión 1.0.

MSF 3.0: 2002 Vio el lanzamiento de la versión 3.0 de MSF.

MSF 4.0: 2005 Este lanzamiento introdujo actualizaciones

importantes en el modelo de proceso (ahora llamado el

Modelo de Gobierno) y en el modelo de equipo.

MSF 1.0

Fortalecer el equipo brindándoles capacitación

Asignación de responsabilidades y autoridad

MSF 3.0

Promover comunicaciones abiertas.

Trabajar para una visión compartida.

MSF 4.0

Siempre crear productos entregables.

Vinculación con los clientes

http://www.itsystems.com.uy/Pages/Company/Metodology.aspx?id=2

Ventajas

Crea una disciplina de análisis de riesgos que ayuda y

evoluciona con el proyecto.

Vinculación con el cliente como también orientado al trabajo en

equipo.

Tiene facilidad de soporte y mantenimiento.

Es adaptable, se puede utilizar para proyectos de cualquier

magnitud.

Desventajas

Al estar basado en tecnología Microsoft, trata de obligar a

usar sus propias herramientas.

Solicita demasiada documentación en sus fases.

En el modelo MSF, un proyecto es planeado e implementado

por un equipo de colegas. Cada miembro es responsable de un área

funcional del proyecto, pero la responsabilidad total del proyecto

recae en el equipo como uno solo.

Administración del programa.

Administración de productos:

Desarrollo

Pruebas

Experiencia del usuario

Administración de versiones

Microsoft menciona tres conceptos fundamentales

que caracterizan el modelado de procesos:

Administración de los factores que se deben considerar.

Enfoque orientado a hitos.

Enfoque iterativo

Define una aplicación como una red lógica de servicios

distribuibles y reutilizables que cooperan en tareas comunes.

Contempla tres categorías de servicios:

Servicios de usuario.

Reglas de negocio.

Servicio de datos.

Este modelo abarca cuatro perspectivas:

Perspectiva de Negocios.

Perspectiva de Aplicación.

Perspectiva de Información.

Perspectiva de la Tecnología.

Es la piedra angular del

proyecto

Identificar los beneficios que

trae el proyecto

¿Qué vamos a realizar?

Restricciones y alcances

Documentos a entregar

Se desarrolla la planificación

Arquitectura de la solución plasmada y

Alcance

Generara la lista de actividades

Preparamos al proyecto para

alcanzar el éxito

Detectamos en forma temprana

los riesgos


Inicia a escribir el código

MSF recomiendaHacer entrega de

cada funcionalidad

Someterse pruebas unitarias,

y evaluaciones

Ajustes de cronograma necesarios


Versión final del producto

Ajustada y aprobada


Registro de Pruebas

Acta de Versión

Aprobada

Entregar (instalar)

Producto finalizado


Archivos para su instalación

Acta de Entrega y

finalización

Garantía en un tiempo

estipulado

Registrando los reportes

Ajustes que estén dentro de la Fase de Vida


Reportes de soporte y

ajustes hechos

• Fue elaborada por el comité técnico denormalización de ingeniería de software y sistemasde información

• En los meses de enero a marzo del año 2006.

Origen

• ISO/IEC 12207:1995. Primera publicación.

• ISO/IEC 12207:1995/Amd 1:2002. Primera modificación.

• ISO/IEC 12207:1995/Amd 2:2004. Segunda modificación.

• ISO/IEC 12207:1995/Amd 3:2008. Tercera modificación.

Versiones

• Proporcionar una estructura común para que las personas involucradas directamente con el software utilicen un lenguaje en común.

• Transportar a los clientes o socios la seguridad de que la empresa utiliza los procesos

Objetivos

http://es.scribd.com/doc/131847881/NORMA-ISO-12207-pdf#download

• Procesos del ciclo de vida del software.

• procesos, actividades y tareas para aplicardurante el suministro, desarrollo, operación ymantenimiento de productos software.

Alcances

• Una organización de software.

• Un proyecto.

• Un comprador o proveedor.

• Asesores.

Campo de Aplicación

• Esta norma no realiza un detalle completo de los procesos.

• No presenta documentación detallada en términos de nombre.

• Esta norma nos indica que debemos hacer en la empresa para encaminarse a la calidad, pero no nos indica cómo hay que hacerlo.

Limitaciones

LA UNIVERSIDAD QUE SIEMBRA

Universidad Nacional Experimental

De los Llanos Occidentales

“Ezequiel Zamora”

Barinas, Estado Barinas

Metodología MSF (Módulo III)

Metodología del Software

Estudiantes:

Quintero Jesús D. C.I.22.114.321

Ramos Carlos C.I.22.983.208

Carrera: Ing. en Informática.

Semestre: VII.

Sección: 01D.

Barinas, marzo de 2.014

ÍNDICE.

Introducción………………………………………………………………… 1

Metodología MSF…………………………………………………………... 2

Línea de Tiempo……………………………………………………………. 2

Ventajas y Desventajas……………………………………………………... 6

Modelo de Equipos…………………………………………………………. 6

Modelado de Procesos……………………………………………………… 9

Modelo de Aplicación………………………………………………………. 9

Modelo Diseño de Componentes…………………………………………… 11

Modelo de Arquitectura de la Empresa…………………………………….. 13

Modelo de Gestión de Riesgo………………………………………………. 16

Modelo de Proceso………………………………………………………….. 18

Normas ISO/IEC 12207…………………………………………………….. 22

Conclusiones………………………………………………………………... 28

Referencias Bibliográficas………………………………………………….. 29

Índice de Figuras.

Figura 1: Disciplinas de la Metodología………………………………….... 4

Figura 1: Modelo de equipo de trabajo……………………………………... 5

Figura 3: Actividades que realizan los actores……………………………… 8

Figura 4: Perspectivas del Modelo de Arquitectura de la Empresa………… 14

Figura 5: Pasos del Modelo de Gestión del Riesgo…………………………. 16

Figura 6: Ciclo de vida del proyecto en MSF………………………………. 19

Índice de Tablas.

Tabla 1: Tareas y roles……………………………………………………… 5

INTRODUCCIÓN.

El tema central a abordar en el siguiente trabajo de investigación se basa en la

Metodología MSF, que por muy simple que parezca, representa una gran importancia

en el mundo de la informática, la investigación científica, la investigación educativa,

la ingeniería y en otros campos de aplicación.

Otros aspectos que se tratarán en el tema son: las fases de la Metodología

MSF, el ciclo de vida de la Metodología MSF, ventajas y desventajas, la norma de

calidad por la cual se rige, entre otros temas; todos estos puntos serán mencionados y

algunos ejemplificados a continuación. Se espera con ello, aportar, al menos, un

grano de arena más respecto al tema objeto de investigación y así contribuir con el

proceso de enseñanza y aprendizaje que ameritan estos temas por parte de los

estudiantes en el área y, en los diversos niveles o instituciones educativas.

2 | P á g i n a

Metodología MSF

Microsoft Solutions Framework (MSF) es una metodología desarrollada por

Microsoft Consulting Services que define un marco de trabajo de referencia para

construir e implantar sistemas empresariales distribuidos basados en herramientas y

tecnologías de Microsoft para cualquier plataforma (Linux, Citrix, Microsoft, Unix).

La metodología MSF es del tipo de metodologías agiles, está enfocada a

dirigir proyectos o soluciones de innovación, en ella no se detalla ni se hace énfasis

de la organización ni el tamaño del equipo de desarrollo, esta mas bien centrada en la

gestión y administración del proyecto para lograr el impacto deseado.

MSF provee un conjunto de principios, modelos, disciplinas, conceptos y

lineamientos para la entrega de tecnología de la información utilizando soluciones

Microsoft, no se limita sólo al desarrollo de aplicaciones, también es aplicable a otros

proyectos de TI como proyectos de implementación de redes o infraestructura, no

obliga al desarrollador a utilizar una determinada metodología (Waterfall, Agile),

pero les permite decidir qué método utilizar. Involucra indudablemente la calidad ya

que prevé liberar una solución si esta aun tiene fallos o desperfectos para ello propone

seleccionar un grupo de prueba piloto el cual es una VERSION BETA y cumplido un

tiempo de prueba ya es liberada la versión formal o VERSION ALFA en la cual está

garantizada la calidad.

Línea de Tiempo

MSF 1.0: 1993 MSF fue introducido por primera vez por Microsoft como la

versión 1.0.

MSF 3.0: 2002 Vio el lanzamiento de la versión 3.0 de MSF.

3 | P á g i n a

MSF 4.0: 2005 Este lanzamiento introdujo actualizaciones importantes en el

modelo de proceso (ahora llamado el Modelo de Gobierno) y en el modelo de

equipo.

Principios de la versión MSF 1.0

Los principios en que se fundamenta “El modelo de equipo de trabajo” propuesto

por MSF se basa en:

Fortalecer el equipo brindándoles capacitación

Asignación de responsabilidades y autoridad

Comunicaciones abiertas

Agregar valor

Calidad

Principios de la versión MSF 3.0

Promover comunicaciones abiertas.

Trabajar para una visión compartida.

Fortalecer los miembros del equipo.

Establecer responsabilidades claras y compartidas.

Focalizarse en agregar valor al negocio.

Permanecer ágil, y esperar los cambios.

Invertir en calidad.

Aprender de todas las experiencias.

4 | P á g i n a

MSF 4.0 (posee 2 principios más)

Principios MSF v. 3.0

Siempre crear productos entregables.

Vinculación con los clientes

Figura 1: Disciplinas de la Metodología.

5 | P á g i n a

Figura 2: Modelo de equipo de trabajo.

Rol Objetivo

Gerente de Programa Entrega dentro de las restricciones del proyecto

Gerente de Producto Cliente satisfecho

Desarrollador Entrega en función de especificaciones

Pruebas Aseguramiento de funcionalidad

Educación a usuarios Máximo Aprovechamiento del producto por el usuario

Gerente de Logística Asegurar el desplegado de la solución

Tabla 2: Tareas y roles

6 | P á g i n a

Ventajas

Crea una disciplina de análisis de riesgos que ayuda y evoluciona con el

proyecto.

Vinculación con el cliente como también orientado al trabajo en equipo.

Tiene facilidad de soporte y mantenimiento.

Es adaptable, se puede utilizar para proyectos de cualquier magnitud.

El modelo tiene facilidad de manejo por ser de una empresa conocida.

Aplica mucho e incentiva al trabajo en equipo y a la colaboración.

Permite la reutilización de componentes ya desarrollados en ciclos anteriores.

Es un modelo enfocado a los requerimientos del usuario.

Es una metodología que se puede ajustar a equipos de trabajo compuestas por

3 o más personas.

Desventajas

Al estar basado en tecnología Microsoft, trata de obligar a usar sus propias

herramientas.

Solicita demasiada documentación en sus fases.

Si el análisis de riesgos se hace muy exhaustivo puede retardar el proyecto.

Los precios de licencias, capacitación y soporte de Microsoft son caros.

Alto grado de dependencias de tecnologías propietarias.

Modelo de equipos

En el modelo MSF, un proyecto es planeado e implementado por un equipo de

colegas. Cada miembro es responsable de un área funcional del proyecto, pero la

responsabilidad total del proyecto recae en el equipo como uno solo. La definición

del equipo del proyecto del documento de Visión y alcance identifica las áreas

7 | P á g i n a

funcionales en las que van a trabajar los miembros del equipo y asigna roles

individuales y responsabilidades. En proyectos mayores, un equipo por separado

podría ser asignado a cada área funcional.

El Modelo de Equipos de Trabajo de MSF facilita la estructuración de equipos

para construir o implantar soluciones eficientes y oportunas, y con proyección de

mejoramiento continuo. Para esto se crea un equipo interdisciplinario donde cada

miembro tiene un rol específico con actividades definidas y sé que se complementa

entre sí.

Este modelo se caracteriza por ser no jerarquizado y sus integrantes trabajan

en seis roles interdependientes y cooperativos. Los líderes de cada equipo son

responsables por la administración, guía y coordinación; los miembros del equipo se

enfocan en llevar a cabo sus misiones.

En el modelo de Equipos el cumplimiento de una meta está vinculado a las

características de cada miembro del equipo. Innova Empresarial SRL en su proyecto

Metodologías para el Desarrollo (mayo, 2005) indica que para asignar estas metas de

calidad en el que se basa el equipo de trabajo es de acuerdo al rol o actor que

interviene en el proceso:

Las actividades que realizan los actores para llevar a cabo el proceso son

clasificadas de la siguiente manera:

Administración del programa: la función del recurso o actor es administrar las

funciones del proyecto, para esto actúa como un arquitecto principal, evaluando

riesgos y facilitando la negociación entre el equipo, además es el encargado

coordinar la toma de decisiones de acuerdo con el programa, sus características y

los recursos que le son asignados.

8 | P á g i n a

Administración de productos: este actor funciona de enlace con el cliente, es

encargado de velar por que sus requisitos se cumplan y estén enmarcados en la

visión y alcance del proyecto, desarrolla y mantiene la situación de negocios y

dirige las decisiones sopesando las características del proyecto.

Desarrollo: el recurso de esta función específica las características del diseño de

la solución, estima el tiempo y el esfuerzo necesario para completar cada

característica y crea o supervisa la creación de la solución.

Pruebas: el recurso de esta función comprueba la funcionalidad de la operación y

garantiza que todos los problemas conocidos están documentos.

Experiencia del usuario: el recurso de esta función actúa de defensor del

usuario, administra los requisitos de los usuarios, dirige la toma de decisiones

sopesando la facilidad de uso y el rendimiento y desarrolla y proporciona cursos a

los usuarios.

Administración de versiones: el recurso de esta función actúa de defensor de los

canales de operaciones, soporte técnico y entrega, administra el

aprovisionamiento, coordina la implementación de la solución y dirige la toma de

decisión sopesando la capacidad de administración y la compatibilidad.

Figura 3: Actividades que realizan los actores.

9 | P á g i n a

Modelado de procesos.

El Modelado de Procesos de la MSF provee una estructura para el desarrollo

de las aplicaciones, es una de las herramientas que Microsoft ha utilizado y

optimizado a partir de sus propias experiencias en la coordinación de proyectos de

implementación de aplicaciones e infraestructuras a gran escala.

Microsoft menciona tres conceptos fundamentales que caracterizan el

modelado de procesos.

Administración de los factores que se deben considerar: la existencia de los

recursos debe estar en equilibrio, la modificación de uno de ellos implica una

modificación necesaria en todos los demás.

Enfoque orientado a hitos: los hitos constituyen un tema clave en MSF. Se

utilizan para planear y supervisar el progreso del proyecto y sirven de puntos

intermedios en el proyecto. Se utilizan para medir el progreso, garantizar la

sincronización con las expectativas del cliente, coordinar los componentes con

otros miembros del equipo y hablar con los participantes o patrocinadores en

relación con el progreso y la dirección del proyecto.

Enfoque iterativo: MSF recomienda que las soluciones se desarrollen mediante

la creación, prueba e implementación de la funcionalidad básica en primer lugar

y, posteriormente, agregar periódicamente conjuntos de características. Este

enfoque se basa en documentos “vivos” que se actualizan periódicamente a

medida que se agregan nuevos conjuntos de características.

Modelo de aplicación.

Este modelo contempla un diseño lógico en tres capas para el diseño de

aplicaciones (soluciones) distribuidas multicapas. Define una aplicación como una

red lógica de servicios distribuibles y reutilizables que cooperan en tareas comunes.

10 | P á g i n a

Contempla tres categorías de servicios:

Servicios de usuario

Reglas de negocio

Servicio de datos

1. Servicios para el Usuario

Servicios de usuario son la lógica que ofrece una aplicación con una interfaz

de usuario. La interfaz de usuario no necesariamente se transmite visualmente, puede

ser programática, ya que el usuario puede ser una persona u otra aplicación. Servicios

de usuario tratar de ocultar o aislar puntos de vista de la información de la estructura

de la aplicación de interfaz de usuario.

2. Servicios de Negocios

Servicios de negocios son la lógica que controla la secuenciación y la

aplicación de reglas de negocio. Estos servicios proporcionan la integridad

transaccional, así como transformar los datos en información mediante la aplicación

de reglas de negocio.

3. Los servicios de datos

Los servicios de datos son la lógica que proporciona el nivel más bajo visible

de detalles que se usan para manipular datos. Servicios de búsqueda de datos para

mantener los datos consistentes de aplicación, así como el diseño independiente de la

aplicación y puesta en práctica de la ubicación y la estructura del almacén de datos.

La mayoría de los servicios de datos proporcionan la capacidad para definir, crear,

leer, actualizar y eliminar datos.

11 | P á g i n a

El modelo de aplicaciones de MSF establece las definiciones, normas y

relaciones que forman la estructura real de una aplicación. Está diseñado para influir

en el enfoque del equipo necesario para que la creación de aplicaciones.

Gracias al seguimiento de este modelo, los desarrollos pueden ser reutilizables

y diseñados de manera modular. Ello permite que una solución crezca y sea escalable

al permitir fácilmente que algún módulo existente se modifique sin afectar los demás

componentes, ó que se agregue un nuevo módulo encargado de nueva funcionalidad.

Este modelo consiste en cinco fases distintas, cuyos nombres dependen del tipo del

proyecto en el que se aplica. Cada fase del proceso de desarrollo culmina con un hito

visible, tal como se describe a continuación:

Características.

Establece definiciones, reglas y relaciones. Un modelo de aplicación establece las

definiciones, reglas y relaciones que construirán la estructura de la aplicación.

Sirve como base para el intercambio de ideas durante el diseño lógico de una

aplicación. El Modelo de Aplicaciones MSF muestra como se estructura la

aplicación, no como será implementada.

Hace consistente la relación entre el diseño de la aplicación y el desarrollo de la

misma.

Utiliza un diseño de componentes basados en servicios. Una organización puede

utilizar más de un modelo de aplicación para adecuar los diferentes tipos de

aplicaciones que se desarrollen.

Modelo diseño de componentes

El Desarrollo Basado en Componentes (DBC) permite la construcción y el

mantenimiento de sistemas a bajo costo, de entrega más rápida y de calidad, ya que el

diseño de nuevos sistemas se basa en componentes implementados y probados en

otros sistemas. El Desarrollo Basado en Componentes (DBC) es un enfoque en donde

12 | P á g i n a

los sistemas son un activo para las organizaciones y la reutilización de estos activos

es esencial para incrementar el retorno de los costos de desarrollo. El DBC permite la

construcción y el mantenimiento de sistemas a bajo costo, de entrega más rápida y de

calidad.

La estructura de este modelo provee un continuo para las actividades del

proyecto relacionadas con el diseño, a través del diseño conceptual, el diseño lógico y

el diseño físico, de la aplicación que se está construyendo. Las fases y los

documentos del diseño conceptual, lógico y físico, proveen tres perspectivas

diferentes para cada una de las 3 audiencias: los usuarios, el equipo y los

desarrolladores. Por lo tanto, el uso de este modelo ayuda a garantizar que una

aplicación no se desarrolle sólo para satisfacer una necesidad tecnológica sino

también para cubrir las necesidades del negocio y de los usuarios. Este modelo se

relaciona con el Modelo de Proceso MSF en la Fase 2 Planeación, ya que las fases del

diseño de componentes ocurren en la Planeación como parte del desarrollo de la

especificación funcional de la aplicación. De esta manera, este modelo provee la base

para el cronograma y el plan de la Fase 3 – Desarrollo, del Modelo de Proceso MSF.

La Figura muestra la relación entre ambos modelos; es decir, cómo se van ejecutando

las actividades de diseño conceptual, lógico y físico, del Modelo de Desarrollo de

Componentes, dentro del Modelo de Proceso.

Diseño Conceptual: El objetivo de esta actividad es comenzar a originar el

concepto de la solución propuesta en el documento de Visión Aprobada. Se

propone que el diseño conceptual esté compuesto por los artefactos indicados en

la Tabla.

Diseño Lógico: Para esta actividad de diseño se establece la estructura y la

comunicación de los elementos de la solución. El conjunto de artefactos

propuestos para esta actividad son descritos en la Tabla. En esta etapa no

13 | P á g i n a

interesan los detalles de implementación física, lo importante es entender las

partes que van a conformar el sistema y la interacción entre ellas.

Diseño Físico: En esta actividad de diseño se aplicaron las restricciones de la

tecnología al Diseño Lógico de la solución. El conjunto de artefactos propuestos

para esta actividad son descritos en la Tabla.

Características.

El modelo de desarrollo basado en componentes incorpora muchas de las

características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque

interactivo para la creación del software. Sin embargo, el modelo de desarrollo

basado en componentes configura aplicaciones desde componentes preparados de

software (clases).

El modelo de desarrollo basado en componentes conduce ala reutilización del

software, y la reutilización proporciona beneficios a los ingenieros de software.

Modelo de Arquitectura de la Empresa

Este modelo define las pautas para construir proyectos empresariales. Se

planifica la infraestructura tecnológica del negocio, los recursos, operaciones,

personal y los procesos que serán utilizados por la organización para el intercambio

de información. Este modelo abarca cuatro perspectivas:

Perspectiva de Negocios.

Perspectiva de Aplicación.

Perspectiva de Información.

Perspectiva de la Tecnología.

14 | P á g i n a

Figura 4: Perspectivas del Modelo de Arquitectura de la Empresa

Perspectiva de Negocios. Incluye las estrategias generales de negocio como lo son:

La organización de alto nivel, las metas y objetivos.

La organización de los productos y servicios.

Los procesos de negocio que incorporan las funciones y las actividades multi-

funcionales realizadas por la organización.

Principales estructuras organizativas.

La interacción de todos estos elementos.

Perspectiva de Aplicación. Se define la cartera de aplicaciones de la empresa e

incluye:

15 | P á g i n a

Las descripciones de los servicios automatizados que soportan los procesos de

negocio que se presentan en la arquitectura del negocio.

Descripciones de la interacción y las interdependencias de los sistemas de

aplicación de la organización.

Prioridades para el desarrollo de nuevas aplicaciones y la revisión de viejas

aplicaciones basadas directamente en la arquitectura del negocio.

Perspectiva de Información. Describe lo que la organización necesita saber para

ejecutar sus procesos de negocio y operaciones. Incluye:

Modelos de datos estándar.

Políticas de gestión de datos.

Las descripciones de los patrones de consumo de información y de la producción

en la organización.

Perspectiva de la Tecnología. Se define el conjunto de estándares de tecnología y

servicios necesarios para ejecutar la misión empresarial. Incluye:

Hardware del servidor y de escritorio.

Los sistemas operativos.

Los componentes de conectividad de red.

Impresoras.

Conectividad a Internet.

16 | P á g i n a

Modelo de Gestión de Riesgo

Este modelo está diseñado para ayudar al equipo a identificar las prioridades,

tomar las decisiones estratégicas correctas y controlar las emergencias que puedan

surgir. Este modelo consta de 6 pasos:

Identificar

Analizar y Priorizar.

Planificar y programar

Seguimiento y presentación de informes de estado de riesgo.

Control

Aprender

Figura 5: Pasos del Modelo de Gestión del Riesgo

17 | P á g i n a

Identificar. El Gerente de Proyectos debe identificar las actividades con mayor

probabilidad de no ejecución o con más variables requeridas para una ejecución

exitosa. Cada miembro del equipo debe evaluar sus actividades, es decir,

considerar todo lo que interviene en cada actividad para que esta se ejecute y

colaborar en la construcción de la lista de riesgos y como equipo se llega a

consensos para poder continuar con la planificación del proyecto.

Analizar y Priorizar. El responsable de la Administración del riesgo, debe tomar

la lista construida entre todos, analizar los elementos de riesgo y darle prioridad

para la acción, tomando en cuenta que riesgos comprometen por ejemplo recursos

para su ejecución. Se puede construir una matriz de riesgos, reflejando la

probabilidad y el impacto que tendría sobre el proyecto.

Planificar y programar. A partir de la matriz de riesgo, se diseña el plan de

acción y se desarrolla una lista de acciones y actividades a ejecutar para cada

riesgo identificado. Este plan de acción se incluye en el cronograma del proyecto,

asignando responsables para su ejecución.

Seguimiento y presentación de informes de estado de riesgo. Se debe hacer

seguimiento para asegurar que se ejecuten los planes de contingencia,

correspondientes a cada riesgo, oportunamente.

La presentación de informes de estado de riesgo se presenta en dos niveles:

1. Plan general de Riesgo. Consiste en un informe gerencial, el cual se presenta en

juntas de proyecto. Este informe contiene estados de avance de ejecución del

proyecto, las actividad que se ejecutaron exitosamente, los próximos riesgos a

considerar según el estatus de ejecución del proyecto, cuales riesgos se activaron y

como se solucionaron.

2. Plan de Riesgo a miembros del equipo. Consiste en un informe más operativo

que contiene los riesgos activados, quien está ejecutando plan de acción, impacto

18 | P á g i n a

sobre el proyecto, cuales son los riesgos que entran en estado de alerta o en

probabilidades de ocurrir para emitir comunicados necesarios y preparar al equipo de

trabajo a ejecutar los planes de acción si los riesgos ocurren.

Control. Se debe hacer un monitoreo constante de las tareas, es decir, supervisar

y evaluar el progreso en forma constante tomando en cuenta: el control de los

planes de acción de riesgo, corregir las variaciones de los planes y responder a los

factores desencadenantes

Aprender. Por la experiencia obtenida continuamente, el aprendizaje nos va a

permitir estar alerta en cuanto a las acciones a tomar para resolver con éxito

cualquier evento que se nos presente. Debe haber trabajo en equipo, pues las

experiencias individuales y mejoras prácticas se comparten.

Modelo de Proceso

El Modelo de Proceso de MSF se compone de 5 fases o etapas iterativas, en

dónde al final de cada fase se logran alcances específicos (definidos por hitos) y se

logran entregables específicos que agregan valor al proyecto.

Visión

Planeación

Desarrollo

Estabilización

Despliegue e Implementación

19 | P á g i n a

Figura 6: Ciclo de vida del proyecto en MSF.

Visión

Obtener una visión clara del proyecto compartida con los objetivos del

negocio. Se necesitan Identificar los beneficios que trae el proyecto como también sus

restricciones y alcances. Esta Fase es la piedra angular del proyecto, de esta depende

su éxito o su fracaso.


20 | P á g i n a

En ésta fase se debe identificar primeramente el propósito del proyecto, es

decir, ¿Qué vamos a realizar?; tomando en cuenta los objetivos específicos, los que

deben ser claros, medibles y alcanzables en un tiempo determinado y ciclo.

Documentos a entregar:

Documento Visión

Documento Detalle de la Visión

Documento de Requerimientos Funcionales

Documento Matriz de Riesgos

Acta de Aprobación de Visión

Planeación

En esta fase se desarrolla la planificación en base al objetivo del proyecto y la

arquitectura de la solución plasmada en la fase de Visión y Alcance, ajustada a un

cronograma de trabajo que cumpla con lo especificado.

Esta planificación generara la lista de actividades que se deberán ejecutar, los

recursos asociados (humanos, técnicos, entre otros), responsabilidades y los costos.

Con la planificación preparamos al proyecto para alcanzar el éxito, detectamos en

forma temprana los riesgos, tomamos medidas para enfrentarlos buscando siempre la

solución óptima.


Documento de cronograma

Acta de aprobación de cronograma

21 | P á g i n a

Desarrollo.

Esta Fase comienza desde el momento en que iniciamos a escribir el código

de la aplicación. MSF recomienda iniciar a construir código a partir de las

funcionalidades más bases e ir haciendo entrega de cada funcionalidad desarrollada

para someterse a pruebas unitarias, y evaluaciones de experiencia de usuario. Esto

incluye ajustes de cronograma necesarios.


Fuentes y ejecutables

Documentos, manuales, entre otros

Acta de finalización de desarrollo

Estabilización.

Versión final del producto probada, ajustada y aprobada en su totalidad.


Documento Registro de Pruebas

Acta de Aprobación de Versión Aprobada

Implantación.

Entregar (instalar) al cliente el producto finalizado en su totalidad.

22 | P á g i n a


Conjunto de archivos (Ejecutables, directorios, base de datos, scripts,

instaladores, manuales, licencias, entre otros) que permitan su instalación y

correcto funcionamiento.

Acta de Entrega y finalización de proyecto

Soporte.

Brindar garantía al producto durante un tiempo estipulado en el contrato,

registrando los reportes de soporte y mantenimiento recibidos así como ajustes que

estén dentro de lo escrito en los documentos de la fase de Visión.


Documento de registro de reportes de soporte y mantenimiento y ajustes

hechos.

Normas ISO/IEC 12207

Origen

La Norma Técnica 12207 fue elaborada por el comité técnico de

normalización de ingeniería de software y sistemas de información, mediante el

antecedente de la norma ISO/IEC 12207 durante los meses de enero a marzo del año

2006.

Versiones

ISO/IEC 12207:1995. Primera publicación.

ISO/IEC 12207:1995/Amd 1:2002. Primera modificación.

ISO/IEC 12207:1995/Amd 2:2004. Segunda modificación.

ISO/IEC 12207:1995/Amd 3:2008. Tercera modificación.

23 | P á g i n a

ISO/IEC 12207:2008 Este conjunto de normas se desarrollaron a partir de

trabajos realizados por el Departamento de Defensa con sus estándares de elaboración

de la norma MIL-STD-498. El Institute of Electrical and Electronics Engineers

(IEEE) y la Electronics Industry Association (EIA) también jugaron un papel

importante en la construcción de la fundación con su estándar ANSI 016 Conjunto.

La 12207:2008 fusionó la sabiduría de estas organizaciones.

Objetivos

El objetivo más importante de esta norma es proporcionar una estructura

común para que los compradores, proveedores, desarrolladores, personal de

mantenimiento, operadores, gestores y técnicos involucrados en el desarrollo de

software utilicen un lenguaje en común.

Los objetivos de una empresa que busca la certificación con la norma

ISO/IEC 12207:2008 son transportar a los clientes o socios la seguridad de que la

empresa utiliza los procesos en relación con las prácticas de confianza de la industria.

Además, los principios promovidos dentro de estas normas darán una plataforma

sólida para administrar una solución de software desde sus inicios.

CARACTERISTICAS DE LA ISO/IEC 12207 DE LA


24 | P á g i n a

Alcances

El alcance de la norma es establecer un marco de referencia común para los

procesos del ciclo de vida del software. Contiene procesos, actividades y tareas para

aplicar durante el suministro, desarrollo, operación y mantenimiento de productos

software. Los procesos son descritos en términos de lograr los propósitos y salidas.

La norma no define cómo o en qué orden se lograrán los propósitos y salidas

de los procesos. Los resultados serán alcanzados en una organización siguiendo

prácticas detalladas para generar productos de trabajo. Estas prácticas realizadas y las

características de los productos de trabajo son indicadores que demuestran si los

propósitos específicos están siendo logrados. Además la norma permite a una

organización definir “como” un proceso será ejecutado conservando de esta forma la

flexibilidad necesaria para que los países o las organizaciones la implementen de

acuerdo a la cultura local o a la tecnología disponible.

Campo de Aplicación (F.J. PINO, 2006).

Es aplicable a la adquisición de sistemas, productos y servicios software, al

suministro, desarrollo, operación y mantenimiento de productos software.

Esta norma además esta creada para ser utilizada tanto por personas adquirientes de

sistemas, productos y servicios de software, como para desarrolladores, operadores,

responsables de mantenimiento, administradores, responsables de aseguramiento de

calidad y usuarios finales.

Esta norma puede ser utilizada por:

Una organización de software: Con el fin de ayudar a establecer un entorno de

trabajo.

Un proyecto: Con el fin de ayudar a seleccionar una infraestructura y emplear

todos los elementos que conforman un ciclo de vida de software establecido.

25 | P á g i n a

Un comprador o proveedor: Para ayudar a desarrollar un acuerdo sobre los

procesos y actividades que se vayan a manejar.

Asesores: Con el fin de realizar evaluaciones que puedan servir de apoyo para

mejorar los procesos de la organización.

La norma ISO 12207 no está dirigida a productos de software preelaborados a

menos de que formen parte de un producto entregable.

Fases y Procesos de la Norma ISO 12207 (ISO/IEC, 2013)

Esta norma agrupa las actividades que pueden llevarse a cabo durante el ciclo

de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro

procesos organizativos.


26 | P á g i n a

Certificación

Sudáfrica constituye el único país que hasta ahora ofrece certificación oficial

ISO 12207:2008. Este servicio eventualmente se expandirá a otros países. Las

empresas, sin embargo, ponen en práctica la filosofía de la ISO 12207 en previsión de

necesidades futuras para cumplir con estas normas. Además, la certificación de la

norma ISO 9001, que representa un conjunto de normas de gestión de calidad bien

adoptadas en el mundo, introduce algunos de los requisitos de ISO 12207.

Para cumplir con la norma ISO 12207, es necesario demostrar que tienes un

documento de requerimientos que captura las expectativas del cliente. Luego, el plan

del proyecto debe demostrar que se inició con una arquitectura de alto nivel,

dividiendo el proyecto en módulos independientes. Siguiendo la escritura y

depuración del código, tu equipo debe participar en pruebas de integración que

combinen varios módulos juntos. El último requisito exige una verificación del

sistema que compara el software en su entorno final para cada elemento del

documento de requerimientos.

Conformidad

La aplicación de esta norma en general, consiste en seleccionar un conjunto de

procesos con el fin de adecuarlos en una organización, ya que puede no ser necesaria

la inclusión de todos los procesos de la norma. Las declaraciones de conformidad

pueden ser citadas de las siguientes formas:

Conformidad completa: esta se da cuando se demuestra que todos los

procesos establecidos por la norma, han sido resueltos obteniendo los

resultados como evidencia de esto.

Conformidad medida: Se cumple cuando esta norma utiliza como base un

conjunto de procesos específicos, y se logran resultados eficientes.

27 | P á g i n a

Limitaciones

Esta norma no realiza un detalle completo de los procesos, en términos de

métodos o procedimientos necesarios para el cumplimiento de los requisitos y

resultados de un proceso.

No presenta documentación detallada en términos de nombre, formato,

contenido explícito y medio de grabación, puede requerir de elaboración de

diversos documentos de características semejantes a la norma para su

complementación.

Esta norma nos indica que debemos hacer en la empresa para encaminarse a la

calidad, pero no nos indica cómo hay que hacerlo.

Recomendaciones de la Norma ISO/IEC: 2008

La norma recomienda un marco común para los procesos de los ciclos de vida

del software, que nace de una idea o una necesidad, que puede ser satisfecha

en parte o en su totalidad por el software y que culmina con la jubilación del

mismo.

Esta norma, no requiere la implementación de un modelo de ciclo de vida de

software, pero recomienda que para cada proyecto se defina el modelo de

ciclo de vida apropiado, de manera preferencial, un modelo que haya sido

establecido por la organización para manejar diversos proyectos

Esta norma, no requiere un conjunto de etapas determinadas, por ejemplo en

una fase de ciclo de un sistema interviene: concepto, desarrollo, producción,

utilización, apoyo y jubilación, o el caso de un ciclo de vida de un productos

de software: desarrollo, operación y mantenimiento.

28 | P á g i n a

CONCLUSIONES.

La Metodología MSF, es una metodología de desarrollo de software muy

dinámica que se ajusta de forma fácil al tamaño del producto de software y a la

cantidad de integrantes del equipo encargado del desarrollo, y cabe destacar que se

recomienda contar con tres (3) miembros o más.

MSF garantiza la realización y entrega de un producto de software al cliente

tomando en cuenta las restricciones definidas en la fase de la visión. Este modelo

requiere practicar la disciplina en cada una de las fases de desarrollo del producto,

para así asegurar el alcance de los objetivos que se trazan en la visión, para cada uno

de los hitos que componen un ciclo.

Cada metodología de desarrollo está diseñada para cumplir una función

específica, es decir no todas tienen la misma funcionalidad, por esta razón que la

Metodología MSF es un modelo estándar orientado a empresas pequeñas que estén en

proceso de expansión.

29 | P á g i n a

REFERENCIAS BIBLIOGRÁFICAS.

Figueroa, R. G., Solís, C. J., & Cabrera, A. A. Metodologías Tradicionales vs.

Metodologías Ágiles. Universidad Técnica Particular de Loja, Escuela de Ciencias

en Computación.(En línea), Disponible en: http://adonisnet. files. wordpress.

com/2008/06/articulo-metodologia-de-sw-formato. doc.

Lory, G., Director, G. T. D., Carter, J., MSFmentor, U. S., Rief, J. M., & West, T.

(2003). Microsoft Solutions Framework Version 3.0 Overview. M icrosoft, Jun.

F.J. PINO, F. G. (2006). Adaptación de las normas ISO/IEC 12207 para la evaluación

de la madurez de procesos de software en países de desarrollo. IEEE XPLORE.

Obtenido de http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01642455.

ISO/IEC. (21 de 03 de 2013). http://www.math.unipd.it/. Obtenido de

http://www.math.unipd.it/~tullio/IS-1/2009/Approfondimenti/ISO_12207-

2008.pdf.

Universidad Nacional Experimental de los Llanos Occidentales LA … · 2018. 5. 28. · Universidad...

Documents

Transcript of Universidad Nacional Experimental de los Llanos Occidentales LA … · 2018. 5. 28. · Universidad...