Evaluar Desempeño de los Proyectos / productos o servicios brindados TI

Uno de los factores de exito de todo proyecto en marcha que haya estado planificado, es el seguimiento y control sobre las actividades y entregables del proyecto.  Es por ello que debemos medir en cada uno de sus elementos las siguientes consideraciones:

  1. En cuanto a Cronograma de Progreso:

a. Hitos

Medición Descripción
Fechas de hitos Fechas de comienzo y fin (planificado y actual) para actividades, eventos y productos de trabajo/ entregables. Esta medición provee visibilidad sobre las actividades y eventos planificados. La comparación de fechas de hitos planificados contra actuales provee una comprensión de los cambios en la planificación a nivel de actividades.

 

b. Progreso de las Unidades de Trabajo

Medición Descripción
Estado de requerimientos Requerimientos en cada estado del proceso de desarrollo (análisis, diseño, construcción, prueba)
Estado de reporte de problemas Cuenta el nro. de problemas reportados y resueltos. Esta tasa indica también la calidad del proceso de resolución de problemas, basado en el promedio de problemas reportados y el tiempo promedio para resolverlos.
Estado de revisiones Cantidad de revisiones de producto y auditorias de procesos, planificadas y reales
Estado de requerimientos de cambio Cuenta el nro. total de requerimientos de cambio que afectan el producto. Provee un indicador de la cantidad de retrabajo que ha sido realizado o que es requerido.  La medición solo identifica el nro. de cambios; no el impacto funcional de los cambios, o el esfuerzo requerido para implementarlos.
Estado de componentes Componentes en cada estado del proceso de desarrollo (análisis., diseño, construcción, prueba)
Estado de Pruebas Mide el nro. de casos de prueba que han sido planificados contra el nro. que ha sido completado exitosamente.

2. En Cuanto a Recursos y Costos

a. Personal

Medición Descripción
Esfuerzo Esfuerzo en hs./persona, planificado y actual, por fase, etapa o entregable, y por rol
Experiencia del personal Cuenta la cantidad de personal experimentado en cada división o área. Permite determinar si se cuenta con suficiente personal experimentado. La experiencia es especialmente medida en años.
Rotación de personal Mide la cantidad de personal Ganado y perdido. Excesiva rotación impacta en curvas de aprendizaje, productividad, y la capacidad para implementar un sistema con los recursos provistos dentro del cronograma y costos. Esta medición es más efectiva cuando es usada en conjunto con Experiencia de personal. La pérdida de personal clave y experimentado es crítica.

b. Performance Financiero

Medición Descripción
Valor Agregado Compara el costo del trabajo realizado, al presupuestado. Presentado en $ o U$S presupuestados por cada componente de la WBS (Work Breakdown Structure). También identifica, tempranamente, sobrecostos de un proyecto.
Costos Mide los costos presupuestados y gastados en un proyecto. Provee información acerca de la cantidad de dinero gastado, en un proyecto o producto, comparado con los presupuestos.
Rentabilidad Mide la rentabilidad planificada y real en un proyecto. Provee información acerca de la cantidad de dinero ganado en un proyecto, en relación a los gastos incurridos.

3. Tamaño de producto y estabilidad

a. Tamaño físico y estabilidad

Medición Descripción
Líneas de Código Cantidad de líneas de código fuente que ha sido desarrollada para el proyecto o producto. También pueden contarse LOC agregadas, eliminadas o modificadas. Es una medición bien conocida que ayuda a estimar duración, esfuerzo, costo y productividad de proyectos. Esta medición se encuentra estrictamente relacionada al lenguaje de programación usado.

4. Tamaño de producto y estabilidad

a. Tamaño físico y estabilidad

Medición Descripción
Líneas de Código Cantidad de líneas de código fuente que ha sido desarrollada para el proyecto o producto. También pueden contarse LOC agregadas, eliminadas o modificadas. Es una medición bien conocida que ayuda a estimar duración, esfuerzo, costo y productividad de proyectos. Esta medición se encuentra estrictamente relacionada al lenguaje de programación usado.

5. Calidad de producto

a. Tamaño funcional y estabilidad

Medición Descripción
Requerimientos

 

Cantidad de Requerimientos por tamaño/ complejidad

b. Correctivos funcional

Medición Descripción
Defectos Califica el número, estado, y prioridad de los defectos reportados. El nro. de defectos indica la madurez del producto. Dar seguimiento al tiempo en que los defectos permanecen abiertos puede ser usado para determinar si se está progresando en la corrección de defectos, o si el retrabajo está siendo diferido.
Densidad de defectos Cantidad de defectos por tamaño del producto, o miles de líneas de código. Puede identificar componentes con mayor concentración de defectos.
Performance técnica Es una combinación de otras mediciones que son definidas por los requerimientos técnicos y funcionales del sistema. Estos requerimientos apuntan a características funcionales que pueden ser cualitativamente definidas y demostradas. Pueden medirse requerimientos como funciones de usuario, interoperabilidad de componentes, características de seguridad, tiempos de respuesta, etc. Estas mediciones proveen un indicador de la capacidad del sistema de satisfacer los requerimientos funcionales del usuario.

c. Mantenibilidad

Medición Descripción
Tiempo de restauración Mide el tiempo que se debe esperar para la recuperación a partir de una falla del sistema. Puede incluir dos tareas: restauración inmediata de la capacidad operacional, y corrección de la causa original del problema.

Una medición comprensiva incluye el tiempo transcurrido, esfuerzo, y recursos necesarios para restaurar el problema y resolver el problema.

Acciones de mantenimiento Cuenta el nro. e impacto de acciones de mantenimiento que son realizadas sobre el sistema. Esta medición es  mas efectiva cuando las acciones son agregadas con el tipo de acción realizada. Por ejemplo, preventiva/ no programada, diferida, tipo de componentes impactados, prioridad, impacto en el servicio al usuario, o tamaño relativo (hs. de trabajo o costo).

d. Eficiencia

Medición Descripción
Tiempo de respuesta Cantidad de tiempo requerido para llevar a cabo una función, tal como completar una tarea o procesar un pedido. Cuenta el tiempo entre el inicio y la conclusión de un evento. Indica si el componente responde de manera oportuna.

e. Portabilidad

Medición Descripción
Compatibilidad con estándares Mide la portabilidad e interoperabilidad de una arquitectura y sus componentes individuales. La medición ayuda a asegurar interfaces consistentes e identificar adherencia a los estándares documentados.

f. Usabilidad

Medición Descripción
Errores de operación Mide la facilidad de uso y confiabilidad del sistema en el ambiente operacional. Esta medición permite conocer fallas

g. Confiabilidad

Medición Descripción
Fallas Esta medición esta basada en la cantidad, criticidad, e intervalo de tiempo entre fallas. Una falla es la incapacidad de un componente del sistema para realizar una función requerida bajo ciertas condiciones en un tiempo especificado. Esta medición es usada para indicar la confiabilidad a través del tiempo promedio entre fallas.
Tolerancia a fallas Mide la capacidad de un sistema para continuar realizando sus funciones a pesar de fallas en sus componentes. La medición determina si el sistema puede operar dentro de los requerimientos de confiabilidad, mantenibilidad, disponibilidad, y seguridad después de ocurrida una falla. Es frecuentemente alcanzada a través de redundancia de componentes u otras características de diseño que permiten la recuperación funcional. Debe ser monitoreada en la fases de operación y mantenimiento.

6. Performance del proceso

a. Compatibilidad del proceso

Medición Descripción
Nivel de madurez Nivel de madurez del proyecto
Observaciones de auditorías de procesos Cantidad de requerimientos para cada área clave de proceso por estado (satisfecho, parcialmente satisfecho, y no satisfecho). Esto se mide para cada proyecto/ división.

b.Eficiencia

Medición Descripción
Productividad Compara la cantidad de productos completados en la cantidad de esfuerzo insumido.

c. Eficacia

Medición Descripción
Defectos encontrados Esta medición identifica defectos que fueron insertados durante un proceso y capturados dentro del proceso, o sus actividades de revisión independientes. Indica cuan bien es realizado el proceso de revisión. La cantidad de defectos encontrados está relacionada a la cantidad de esfuerzo, recursos y herramientas aplicadas.
Retrabajo Cantidad de horas de trabajo insumidas en retrabajo. O sea, esfuerzo dedicado a tareas que si se hubieran hecho bien desde el principio, no hubiera

7. Efectividad de la tecnología

a. Performance técnica

Medición Descripción
Cumplimiento técnico a los requerimientos Es una combinación de otras mediciones que son definidas por los requerimientos técnicos y funcionales del sistema. Estos requerimientos apuntan a características funcionales que pueden ser cualitativamente definidas y demostradas. Pueden medirse requerimientos como funciones de usuario, interoperabilidad de componentes, características de seguridad, tiempos de respuesta, etc. Estas mediciones proveen un indicador de la capacidad del sistema de satisfacer los requerimientos funcionales del usuario.

b. Impacto de la tecnología

Medición Descripción
Impacto de la nueva tecnología en  reducción del ciclo de   desarrollo Mide los cambios al proyecto o sistema, que son atribuidos a una tecnología específica. Estos cambios pueden ser positivos o negativos. Esta medición puede ser usada para apoyar decisiones tendientes a adoptar una tecnología particular o a mitigar los efectos negativos de la incorporación de cierta tecnología.
Cambios de línea base Monitorea la cantidad de veces que un producto cambia a través del tiempo.

Indica la estabilidad de una determinada tecnología o la estabilidad de un producto implementado en esa tecnología. Provee una visión acerca de la frecuencia con la cual la tecnología probablemente cambiará.

8. Satisfacción del Cliente

a. Feedback del cliente

Medición Descripción
Resultado de encuestas Muestra la calificación del cliente, respecto de los productos/ servicios que proveemos. Indica si las necesidades y expectativas del cliente están siendo satisfechas.

b. Soporte al Cliente

Medición Descripción
Requerimientos de soporte Mide la cantidad, tipo, estado, y prioridad de las llamadas del cliente para soporte del producto. Esta medición provee información sobre defectos del producto o problemas de usabilidad encontrados en el campo. El número de defectos descubiertos indica la calidad del producto entregado. El estado de los requerimientos de soporte (cantidad de abiertos y cerrados) refleja la capacidad de soportar el producto luego de la entrega.
Tiempo de soporte Mide el tiempo insumido para responder, resolver, o satisfacer los requerimientos de soporte de un cliente. Seguir la duración de los problemas no resueltos puede determinar el nivel de satisfacción, del cliente, alcanzado por la actividad de soporte del producto.

Plantillas Microsoft Solution Framework

El presente post tiene como finalidad presentar documentos ejemplos y plantillas que nos van a servir de apoyo para las diversas fases que hemos venido estudiando sobre Microsoft Solution Framework, algunos documentos son tomados de proyectos en los que he trabajado, otros simplemente plantillas tipo formatos que nos pueden guiar en su momento.

Ejmplo Vision y Alcance Sistema Avicola Modulo de Cria-levante

Especificacion De Requerimientos InAgro Modulo Inventario

Ejemplo Maestro Producto

Ejemplo Maestro CuentaContable

Plantilla Evaluacion de Riesgos

Plantilla Reporte de Riesgos

Plantilla Auditoria & Tracking

Plantilla Especificaciones de Pruebas

Plantilla Firma de Entrega

Plantilla Pruebas y Reporte de Bugs

Plantilla Revision Piloto

Plantilla Reportes de Avance

Espero poder aportar productividad, hasta la proxima entrega 😉

Proceso de Pruebas MSF

Esta ves no he desarrollado el tema, encontre este punto muy bueno y me permiti compartirlo.  Tomado de:  http://equiposige.blogspot.es/

Este proceso comienza desde la etapa de Visión y Alcance, por tanto cruza horizontalmente el desarrollo desde las especificaciones inicial hasta la puesta en marcha, dichas actividades generan un registro y evidencia luego de la ejecución de los casos de prueba, los que son medidos por medio de métricas de calidad en donde se obtiene estadísticas de las fallas y errores encontrados.

Consideraciones de Pruebas

Al preparar el plan de pruebas, los miembros del grupo de trabajo de pruebas deben tener en cuenta varios aspectos del proceso de implementación, entre los que se incluyen:

  • Los tipos de pruebas que son necesarios para las diferentes etapas de la implementación de la solución y, específicamente, las responsabilidades del grupo de trabajo de pruebas en cada tipo de prueba.
  • La estrategia usada para la prueba en cada tipo de prueba.
  • Las distintas funciones de equipo para los miembros del grupo de trabajo de pruebas.
  • Las actividades de requisitos previos necesarias para cada miembro del equipo.

Tipos de pruebas

 

Dentro del proyecto se considera la preparación varios tipos de pruebas. Cada tipo tiene sus propios requisitos y estrategia de prueba. La solución se va perfeccionando conforme se avanza de un tipo de prueba a otro, hasta que se ha probado por completo y está lista para su introducción en el entorno de producción.

 

Entre los tipos de pruebas recomendados para este proyecto se incluyen los siguientes:

 

Prueba de unidad.

 

El primer tipo de prueba se centra en el análisis de un solo componente o funcionalidad de la solución. En este momento, a menudo instalan estos componentes en entornos aislados para validar las capacidades de los componentes. Este tipo de prueba a menudo la realizan individuos en un solo módulo o componente del desarrollo.

 

Prueba funcional.

 

Después de las pruebas de unidad se pasa a la prueba funcional: la validación de que los productos y los componentes funcionan de la manera diseñada. La orientación para este tipo de prueba se deriva de las especificaciones funcionales del proyecto general.

 

Prueba de integración.

 

El siguiente tipo de prueba integra cada uno de los distintos componentes que componen la solución como un todo coherente. Esta prueba se lleva a cabo simulando el ambiente de desarrollo final.

 

Prueba de producción y piloto

 La etapa final de prueba implica a menudo ejecutar los mismos componentes usados en la producción. En esta etapa se implementara la solución en un entorno de producción real, comienzan con una implementación piloto, dirigida a una pequeña población representativa de usuarios en el entorno de producción para realizar una validación final de todos los procedimientos y estrategias de implementación antes de implementar la aplicación en el entorno de producción completo. El proyecto piloto está vinculado a la producción porque, si todo va bien, las tecnologías y los componentes agregados para el programa piloto pasan a ser los componentes usados en la producción completa

MSF Process Model. Fase III Desarrollo

 

En la fase de planificación se define las funcionalidades de la aplicación y se plasma una propuesta con un orden incremental de desarrollo; esto debe contemplar desde lo más básico hasta los procesos más complejos. 

Comienza la Fase de Desarrollo desde el momento que comenzamos la construcción del código de la aplicación.  MSF recomienda iniciar a construir código a partir de las funcionalidades mas bases  e ir haciendo entrega de cada funcionalidad desarrollada para someterse a pruebas unitarias, y evaluaciones de experiencia de usuario.

Cada vez que hacemos una entrega de una funcionalidad, estamos entregando una nueva versión del desarrollo. El equipo debe comprobar si todas las tareas identificadas durante las fases de ideación y planificación se han completado en cada versión que se esté entregando. It also verifies solution concepts from the designs within a live environment close to that of a production environment, and develops a testing infrastructure in which test cases are created.

Esta fase se hacen entregas parciales del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus módulos o partes están sincronizados y pueden integrarse. La fase culmina con el hito Alcance completo.

Los Entregables para esta fase son:

  • Código fuente y ejecutables (resguardados y etiquetados en VSS)
  • Actas de aceptación de entregas parciales
  • Plan de Pruebas
  • Manual de Instalación y Operación
  • Documento de Arquitectura
  • Actas de control de cambios aprobadas (que justifican el ajuste al alcance, tiempo y/o costo del proyecto, de existir)

Una solución con éxito requiere del desarrollo de la infraestructura que requiere, el código de la aplicación, la documentación que se genera para los usuarios, y los resultados de las pruebas que se han ejecutado sobre cada funcionalidad.

Ejemplo de un Plan de Desarrollo tomado de un Proyecto de la Empresa donde laboro.

Resumen

El presente documento establece los estándares de desarrollo propuestos por Noixno los cuales garantizan el empleo de las mejores prácticas de diseño y desarrollo, también se menciona brevemente las herramientas que intervienen en esta fase del proyecto junto con su debida justificación.

 Objetivos de Desarrollo

         Se desea tener una comunicación directa, en tiempo real con el servidor de la empresa TDAT, por parte del personal dedicado a la supervisión de ventas, haciendo uso de recepción y transmisión de datos por parte de la empresa OTROPROVEEDOR.

 El uso de éste mecanismo lo justifica el hecho de la necesidad de sólo acceder a un sector de la data almacenada en el servidor de la empresa TDAT, por ello la incorporación de un sistema basado en un repositorio SQL Server 2005, por medio del uso del servicio web TDAT_XMLMobil.

  1.  Desarrollar modulo de administración y control de eventos ocurridos en las transacciones de datos
  2. Proporcionar interfaz de control, agenda de transacciones, administración de usuarios y roles del sistema.
  3. Crear procesos de extracción, consumo, e inserción de datos transaccionales
  4. Proveer modulo de administración de respaldos.

 Estrategia General de Entrega

Se utilizará un modelo de publicación incremental, es decir, se irán cargando en un directorio estándar, todas aquellas versiones que ya hayan sido probadas y validadas por parte de TDAT, tomando en cuenta que se hará una revisión previa por cada entregable que sea terminado.

 La validación referida consiste en una evaluación basada en umbrales de aceptación (próxima sección), esto consiste en asignar a cada entregable un valor que debe estar comprendido en un intervalo, con un límite inferior y uno superior como calificaciones posibles. Este proceso debe realizarse hasta terminar con el desarrollo de todos los entregables, al final, cuando se hace una prueba de todo el sistema, el criterio de evaluación puede ser un tope mínimo, o un promedio que se debe satisfacer para que la solución entregada pueda pasar al entorno productivo. (Extraído del documento de Visión/Alcance).

 Puntos Claves del diseño

En esta sección se identifican las metas claves en el diseño de la aplicación y su prioridad.

  1. Organizar la propuesta de desarrollo bajo el modelo SOA (Service Oriented Arquitecture).
  2. Desarrollar capa de datos basada en stored procedures.
  3. Crear modulo de extracción de datos de los repositorios Radar y Datamart haciendo uso de vistas indexadas.
  4. Establecimiento de XML como estándar abierto de comunicación el cual permite a los servicios una comunicación neutral, independientemente de la plataforma de hardware, del sistema operativo y del lenguaje de programación en los que se implemente el servicio

 Entorno de desarrollo

En esta sección se ilustran los componentes que conforman la solución, los proyectos que serán implementados, y las herramientas con las cuales serán desarrollados.

  •  Capa de Presentación: se creará un proyecto de tipo Aplicación Web Asp.Net, el nombre del mismo será XML_Mobil.Core.Interface, el lenguaje de programación será Visual C# 2.0
  • Capa de Servicios: será implementada con un proyecto de tipo Class Library, con Visual C# 2.0, esta es la encargada de servir de puente entre la capa de datos y la capa de presentación, el proyecto a cargo de llevarla a cabo será XML_Mobil.Core.EntityService.
  • Capa de Servicios (Entidades): al igual que los servicios, la implementación consistirá en un proyecto de tipo Class Library con Visual C# 2.0, entendiéndose por entidad, una clase que represente una tabla de la base de datos, publicando cada uno de los campos por medio de propiedades.
  • Capa de Datos: el motor de base de datos donde residirá la data manejada por el repositorio propuesto será SQL Server 2005 Enterprise Edition, y las consultas serán implementadas por medio de procedimientos almacenados.

 Con respecto a las herramientas que implementarán los proyectos mencionados, por el lado del desarrollo se utilizará Visual Studio 2005 Professional Edition, y para administrar todo lo correspondiente a SQL Server 2005, la herramienta será SQL Server Management Studio.

 Guías y Estándares

En esta sección se proveen los estándares que Noixno, propone para llevar a cabo el desarrollo del proyecto, en primer lugar se encuentra la sección de nombramiento, es ahí donde se especifican los nombres que se deben asignar a las clases y a los objetos, luego aparece la sección de codificación, que es donde se muestran los nombres que se le deben proveer a los métodos, propiedades, enumeraciones y otros objetos.

Nombramiento

  • Para objetos de base de datos:
    • Stored Procedures: sp_operacion_tabla, ejemplo: sp_insercion_estvisitas.
    • Tablas: no aplica, porque se mantendrá el diccionario de datos que ha entregado TDAT.
    • Vistas: no aplica, porque se mantendrá el diccionario de datos que ha entregado TDAT
    • Triggers: trg_operacion_tabla, ejemplo: trg_actualizacion_estvisita

Codificación

  • Para objetos de código:
    • Clases: se nombraran de acuerdo al propósito para el cual estén creadas, por ejemplo, si representan una tabla, llevarán el mismo nombre de la tabla (ejemplo: CTR_TRA).
    • Objetos: se nombraran con m_ seguido del nombre de la clase al cual pertenezcan, ejemplo, si la clase se llama Prueba, el objeto será m_Prueba. Si para nombrar un objeto adecuadamente se necesitan dos o más palabras, se recomienda utilizar la primera letra de la primera palabra en minúscula al igual que el resto, seguido de la primera letra de la segunda palabra en mayúscula, y así sucesivamente, por ejemplo, envioCorreoElectronico.
    • Métodos: su nombre debe comenzar con letra mayúscula y deben ser expresados en verbos infinitivos en la medida de lo posible, ya que estos implementan una acción, por ejemplo: InsertarRegistro( parámetros )
    • Parámetros: se nombran con el prefijo p_ seguido del nombre, por ejemplo si un parámetro es FEC_TRN, será declarado en el método como p_FEC_TRN
    • Elementos de Formulario: en este caso, es necesario basarse en prefijos, los elementos más comunes son:
      • Text Box: txtNombre
      • Botón: btnNombre
      • Radio Button: rbtNombre, Radio Button List: rblNombre
      • Check Box: chkNombre, Check Box List: chlNombre
      • Drop Down List: ddlNombre
      • Grid Views: grvNombre

 Versionamiento y control de fuentes

Actualmente no se cuenta con un software controlador de versiones sin embargo, es conveniente resaltar lo que ya se ha escrito en el documento de estructura del proyecto, y es lo siguiente:

 “La administración de Versiones se manejará de forma incremental, es decir, se irán guardando en la carpeta del proyecto solamente aquellas versiones, que ya hayan sido probadas y validadas por el personal de TDAT.

 Para diferenciar las versiones entregadas a lo largo del desarrollo, se propone utilizar un estándar de nombramiento, que lleve consigo, el nombre del proyecto, seguido del número de la versión y la fecha de entrega, un ejemplo de este puede ser: TDAT_XMLMobil v1 26-02-2010.”

 Proceso diario de Compilación

Esta especificación provee las reglas de publicación, no de fuentes sino de releases, es decir, archivos ejecutables, y la única restricción que se asume, es el hecho de no subir a la carpeta compartida en el servidor archivos que no estén completamente operativos, y validados por TDAT

Orden de entrega

            Esta sección provee las fechas estimadas para las cuales se plantea entregar los componentes que conforman la aplicación a desarrollar.

Componente Descripción Fechas Críticas A cargo de
Diseño Arquitectónico Arquitectura del proyecto estableciendo las capas que conforma la propuesta 10/03/2010 Consultor Asignado
Desarrollo Codificación de todos los módulos que conforman el sistema propuesto. 24/03/2010 Consultor Asignado
Ajustes Entrega de las modificaciones necesarias a la propuesta de forma que cumpla con lo que se pide 27/03/2010 Consultor Asignado
Reporte de Cierre y Análisis Post-Proyecto Se provee un informe final sobre el estado en el que se deja la aplicación, y las “lecciones aprendidas” a lo largo del desarrollo 30/04/2010 Consultor Asignado

Componentes

Descripción de Componentes

  1. Diseño Arquitectónico: esto simplemente es representar con elementos de software la arquitectura ilustrada en el documento de Visión/Alcance y Estructura del Proyecto.
  2. Desarrollo: En esta sección simplemente se nombran los proyectos que conforman la solución, integrando todas las capas:
    1. Capa de Presentación: XMLMobil.Core.Interface (ASP.Net 2.0)
    2. Capa de Servicios:
      1. XMLMobil.Core.Entities (Class Library)
      2. XMLMobil.Core.EntityService (Class Library)
  1. Capa de Datos:
    1. XMLMobil.Core.DataLoad (Sql Server Views)
    2. XMLMobil.Core.Query (Sql Scripts Project)

Ajustes: La Herramienta de pruebas a utilizar es Visual Studio Team Suite, pero los ajustes necesarios deberán hacerse con las herramientas que hayan sido asignadas a un determinado componente en el desarrollo original.

Reporte de Cierre y Análisis Post-Proyecto: Este componente forma parte de la documentación, y únicamente expresa el estado en el que se deja el sistema desarrollado al momento de entregarse, y el Análisis Post-Proyecto, es un conjunto de experiencias vividas a lo largo del desarrollo que se deben guardar a manera de documento, para que las mismas sirvan de guía en futuros desarrollos, relacionados con el repositorio propuesto para la aplicación, o con un proyecto vinculado a operaciones de intercambio de datos XML.

Adquisición de Componentes y desarrollo

No aplica, TDAT Centro cuenta con la infraestructura, y el software necesario para llevar a cabo el desarrollo de la nueva propuesta.

Calidad de Componentes Desarrollados

Este tópico consiste en dar una definición del método utilizado para evaluar la calidad del software, sin embargo, es conveniente acotar que implícitamente este trabajo se cumple por medio de los umbrales de aceptación, y dichos umbrales son los siguientes:

  • El valor mínimo para asignar a la evaluación de un entregable es cero (0) puntos.
  • El valor máximo para asignar a la evaluación de un entregable es diez (10) puntos.
  • El tope mínimo de aceptación de un entregable es ocho (8) puntos.
  • El tope mínimo para la aceptación de la solución es un promedio de 9 puntos, promedio que debe calcularse utilizando la ecuación de Media Ponderada.

NOTA Los umbrales de aceptación vienen del documento de Visión y Alcance

 Herramientas de Desarrollo

  Microsoft Internet Explorer Microsoft Internet Information Server .Net Framework 2.0 Microsoft SQL Server
Componentes de Capa de Presentación Herramientas: Visual Studio 2005, Visual C# 2.0Tecnología:  HTML Herramientas: Visual Studio 2005Tecnología:  ASP.Net No Aplica No Aplica
Componentes de Capa de Negocios Herramientas: Visual C# 2.0Tecnología: Class Library No Aplica Herramientas: Visual C# 2.0Tecnología: ActiveX Data Objects (ADO) No Aplica
Componentes de Capa de Datos No Aplica No Aplica Herramientas: Visual C# 2.0Tecnología: ActiveX Data Objects (ADO) Herramientas: SQL Server Management StudioTecnología: SQL, Stored Procedures, Triggers, Views
Herramientas de Deployment No Aplica No Aplica No Aplica No Aplica
Herramientas de Testing Visual Studio Team System Visual Studio Team System Visual Studio Team System No Aplica

 

Reutilización

No aplica

Patrones de diseño

Los patrones de diseño son provistos por el Noixno Code Generator, herramienta que fue desarrollada por la división de Software Factory de Noixno, y con respecto a la arquitectura, Visual Studio 2005 provee patrones nativos que serán utilizados en el desarrollo del proyecto.

 Entrenamiento al equipo de desarrollo

Se está consciente de que los analistas de sistemas que actualmente laboran en TDAT, se caracterizan en su mayoría por desarrollar sus aplicaciones en el lenguaje Visual Basic, por tratarse de Visual C# 2.0 el lenguaje de programación, Noixno ha tomado la decisión de dictar un curso dirigido hacia el personal previamente nombrado.

Soporte al equipo de desarrollo

Noixno proveerá manuales técnicos que proporcionaran las explicaciones necesarias para manipular la codificación de cada uno de  los módulos del sistema, adicionalmente se podrá observar comentarios descriptivos concernientes a las funciones de cada método desarrollado.

MSF Process Model. Fase II Planificación

La segunda Fase que MSF nos presenta es la Planificación del Proyecto, donde  el equipo trabaja en articular una imagen más clara de la solución planteada.  Se desarrolla una planificación en base al objetivo del proyecto y la arquitectura de la solución plasmada en la primera fase Visión y Alcance.  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.

Esta fase es una actividad repetitiva, donde se reúnen los requisitos iníciales y el uso de escenarios desde un punto de vista de alto nivel ejecutivo, de lo que puede ser la solución, que se utiliza como punto de inicio para la planificación. El proceso de diseño en este punto del proyecto, se utiliza para aportar claridad y especificidad del concepto de la solución generando un diseño lógico y un diseño físico.

Con el diseño inicial de la solución debemos validar los requerimientos en cuanto a plataforma tecnológica para divisar viabilidad del proyecto, si se detecta alguna necesidad de actualización, compra o debilidad debe plasmarse en los requerimientos y plan de riesgos para hacer correctivos en el momento oportuno durante la ejecución del proyecto.

Tanto el diseño lógico como el diseño físico del proyecto desarrollado inicialmente se valida y depura con las necesidades detectadas con los usuarios funcionales, hay que considerar también las sugerencias aportadas por patrocinadores empresariales  y el grupo de trabajo.

 Creando el Plan Maestro del proyecto:

El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Cada miembro del equipo aportara su enfoque a la planificación.

Funciones y responsabilidades durante la fase de planificación

Función Enfoque
Administración de productos
  • Análisis de requisitos empresariales
  • Plan de comunicaciones
  • Diseño conceptual
Administración de programas
  • Presupuesto
  • Diseño lógico y conceptual
  • Especificación funcional
  • Plan y programación del proyecto
Desarrollo
  • Establecimiento de prioridades y revisión del inventario de aplicaciones
  • Establecimiento del laboratorio
Experiencia de usuario
  • Requisitos de localización y accesibilidad
  • Programaciones
  • Planes de aprendizaje
  • Escenarios de uso y casos de uso
  • Documentación de usuario
  • Requisitos de usuario
Prueba
  • Programación y plan de pruebas
  • Definición de los requisitos de prueba
Administración de lanzamientos
  • Inventario de hardware y aplicaciones
  • Evaluación del diseño
  • Detección de redes
  • Requisitos de operaciones
  • Programación y plan de implementación piloto
  • Trabajo con operaciones de TI y el grupo de trabajo de seguridad

 

  • Prueba de producción y piloto. La etapa final de prueba implica a menudo los mismos componentes usados en la producción. Cuando los equipos implementan la solución en un entorno de producción real, comienzan con una implementación piloto, dirigida a una pequeña población representativa de usuarios en el entorno de producción para realizar una validación final de todos los procedimientos y estrategias de implementación antes de implementar el sistema en el entorno de producción completo. Este tipo de prueba se centra más en las estrategias de aprendizaje, comunicaciones y soporte técnico que en estrategias tecnológicas reales, aunque estas también reciben validación. El proyecto piloto está vinculado a la producción porque, si todo va bien, las tecnologías y los componentes agregados para el programa piloto pasan a ser los componentes usados en la producción completa.

 

Los requisitos mínimos que debemos considerar a la hora de Planificar:

  1. Un plan de implementación, donde evaluaremos los recursos requeridos para implementar la solución y los planes de contingencia.
  2. Plan piloto para probar los procesos de backup y recuperación.
  3. Plan de Compras y Servicios que incluyen consideraciones de hardware y software.
  4. El plan de pruebas que describe la estrategia que el equipo utilizará para probar la solución. Se incluye los tipos específicos de pruebas que se utilizan, las áreas específicas de la prueba, criterios de prueba de éxito, y la información sobre los recursos (tanto hardware como
    personas) necesarios para la actividad.
  5. Plan de Adiestramiento para los diversos actores que estarán interactuando con la aplicación desde el punto de vista Administrador, Usuario Final, u otro.
  6. Plan de comunicaciones para crear conciencia de los clientes y usuarios de lo que está sucediendo, lo que les ayudara a
    prepararse para responder adecuadamente ante la nueva implementación.
  7. El plan de capacidad para evaluar la capacidad de crecimiento, escalabilidad y performance de la aplicación con la plataforma que se tiene en la organización.

 Importante Considerar el plan de pruebas

Al preparar el plan de pruebas, los miembros del grupo de trabajo de pruebas deben tener en cuenta varios aspectos del proceso de implementación, entre los que se incluyen:

  • Los tipos de pruebas que son necesarios para las diferentes etapas de la implementación de la solución y, específicamente, las responsabilidades del grupo de trabajo de pruebas en cada tipo de prueba.
  • La estrategia usada para la prueba en cada tipo de prueba.
  • Las distintas funciones de equipo para los miembros del grupo de trabajo de pruebas.
  • Las actividades de requisitos previos necesarias para cada miembro del equipo.

Tipos de pruebas

La preparación de complejas soluciones tecnológicas implica varios tipos de pruebas. Cada tipo tiene sus propios requisitos y estrategia de prueba. La solución se va perfeccionando conforme se avanza de un tipo de prueba a otro, hasta que se ha probado por completo y está lista para su introducción en el entorno de producción.

  • Prueba de unidad. El primer tipo de prueba se centra en el análisis de un solo componente de la solución. Cuando se preparan para crear la solución general, los miembros del equipo de cada grupo de trabajo empiezan a analizar los componentes de los que son responsables. En este momento, a menudo instalan estos componentes en entornos aislados para validar las capacidades de los componentes. Este tipo de prueba a menudo la realizan individuos en un solo equipo.
  • Prueba funcional. Después que los equipos individuales se han familiarizado con los componentes tecnológicos de los que son responsables, pasan a la prueba funcional: la validación de que los productos y los componentes funcionan de la manera diseñada. La orientación para este tipo de prueba se deriva de las especificaciones funcionales del proyecto general.
  • Prueba de integración. El siguiente tipo de prueba integra cada uno de los distintos componentes que componen la solución como un todo coherente. Esta prueba se lleva a cabo en el laboratorio de integración o de pruebas y está al cargo del propio grupo de trabajo de pruebas.
  • Prueba de ensayo. La prueba de operación provisional o de ensayo es un tipo de prueba opcional que ofrece una validación final para los procedimientos usados en la implementación de la solución. Aunque es posible que haya un margen de error en los tipos de pruebas anteriores, aquí no debe haber ninguno. Cuando se agrega una solución al entorno de producción, debe estar completamente libre de errores para garantizar su longevidad y su compatibilidad a largo plazo.

MSF Process Model. Fase I Visión

La primera fase es definitivamente la piedra angular del proyecto, de esta depende su éxito o fracaso, es como cuando construimos una casa, sus bases, las columnas de la construcción son vitales para garantizar una obra de calidad.

En la fase de Visión debemos identificar  en primer lugar el propósito del proyecto, ¿qué vamos a realizar?, tomando en cuenta los objetivos específicos, estos deben ser medibles, alcanzables, relevantes con un tiempo determinado. Continuamos estableciendo los entregables, como vamos a ir entregando y los criterios de aprobación del cliente.

En este mismo orden es importante resaltar los requerimientos que van ligados a la calidad en cuanto al resultado final y satisfacción del cliente, en otras palabras debemos buscar satisfacer necesidades, desde la percepción del usuario.

En esta fase tenemos la oportunidad de relacionarnos con los stakeholders (actores) conocido en MSF como los Miembros del Equipo, para validar la aceptación de la propuesta.

¿Cómo construir el documento de Visión y Alcance?

El Problema

Es importante efectuar un levantamiento de información mediante la observación del proceso, las encuestas y entrevistas con las personas involucradas, las investigaciones previas sobre lo que estamos analizando, de forma tal que hagamos un análisis certero, preciso de la problemática actual.

Debemos detectar las necesidades actuales, para obtener tanto las ventajas y beneficios que nos daría poner en marcha el proyecto, como los objetivos que deberíamos alcanzar con la propuesta que vamos a desarrollar.

Declaración de Oportunidad

La oportunidad establece la motivación para iniciar el proyecto, las direcciones de por qué quiere hacerlo y lo que quieres hacer.  Se centra en un nivel de negocio. Puede incluir información adicional pertinente, tales como datos de mercado, análisis de la competencia, de los usuarios.

Declaración de Visión

Definir el objetivo de la  propuesta, debemos establecer los requerimientos que se deben cubrir con el diseño e implementación de nuestra solución, donde se le dé un enfoque general de lo que deseamos alcanzar.  En resumen es indicar propósito y objetivos del proyecto.

Análisis de Beneficios

Es importante determinar la conveniencia de la ejecución del proyecto, mediante la enumeración y valoración posterior en términos monetarios de todos los costes y beneficios derivados directa e indirectamente de dicho proyecto.

Concepto de Solución

  • Metas: representa el destino, o el estado al que se quiere llegar por medio de la propuesta.
  • Objetivos: consisten en desglosar las metas en componentes, con el fin de obtener el verdadero nivel de detalles de los fines que se persiguen con las propuesta, y lo que se debe hacer para llegar a ellos.
  • Supuestos: son aquellos factores, que se pueden expresar como elementos que esperan validación por parte de un tercero.

Requerimientos

Requerimientos de Negocio

  • Se debe especificar que debe hacer el sistema a desarrollar sin explicar cómo hacerlo.

Requerimientos de Usuario

  • Cuáles son las expectativas del usuario en cuanto a lo que desea alcanzar con la implementación del proyecto.
     

Alcance
Debemos tener claros cuales son los límites del proyecto, hasta donde vamos a llegar con él, y si surgen nuevos requerimientos en medio de desarrollo del proyecto, teniendo claro este punto se convertirían enparte de un nuevo proyecto, una nueva versión que se debe negociar para desarrollar más adelante.

Estrategia de Entrega de Versiones.  Fijar claramente cómo vamos a ir entregando el proyecto, en fases, en tiempo, en alcance para cada fase.

Por último establecer los Criterios de Aceptación del cliente, cuando podemos decir, fase cerrada con éxito, como nos vamos a medir.

Estableciendo Ciclo de Vida del Proyecto con MSF

Con el ciclo de vida del proyecto buscamos establecer el orden en el cual se deben realizar las actividades. El  modelo de proceso MSF, aplica una estrategia iterativa que suministra una imagen clara del estado del proyecto en cada etapa sucesiva. De esta manera el equipo puede identificar con mayor facilidad el impacto de cualquier cambio y administrarlo efectivamente.

Este modelo consiste en cinco fases distintas (Visión, Planificación, Desarrollo, Estabilización e Implementación). Cada fase del proceso culmina con un hito visible, tal como se describe a continuación:

 Vision 

Obtener la visión y el alcance del proyecto, el cual debe estar compartido, comunicado, entendido y alineado con los objetivos del negocio. En esta fase el equipo y el cliente integran el proyecto y definen los requerimientos funcionales, sus alcances y restricciones, identifican los beneficios del proyecto y también los riesgos del proceso. La fase culmina con el hito Visión y Alcance aprobados.

Entregables

  • Documento de Visión y Alcance
  • Matriz de Identificación de riesgos

 

Planificación:

El equipo del proyecto creará un borrador del plan maestro del proyecto, además de la especificación funcional del proyecto y un cronograma que identifica puntos de control específicos. Esta fase culmina con el hito Plan del Proyecto (Especificaciones y Cronograma) aprobado.

Entregables:

  • Minuta de reunión de Kick-off del proyecto
  • Documento de Especificaciones
  • Cronograma del proyecto (establecimiento de línea base)
  • Documentos de proceso de licitación aprobados (de acuerdo a la Norma Operativa vigente

Desarrollo:

Involucrar la serie de releases internos o entregas parciales del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus módulos o partes están sincronizados y pueden integrarse. La fase culmina con el hito Alcance completo.

Entregables:

  • Código fuente y ejecutables (resguardados y etiquetados en VSS)
  • Actas de aceptación de entregas parciales
  • Plan de Pruebas
  • Manual de Instalación y Operación
  • Documento de Arquitectura
  • Actas de control de cambios aprobadas (que justifican el ajuste al alcance, tiempo y/o costo del proyecto, de existir)

Estabilización

Centrarnos en probar el producto. El proceso de prueba hace énfasis en el uso y el funcionamiento del producto en las condiciones del ambiente real. La fase culmina con el hito Aceptación de Pruebas.

Entregables:

  • Acta de Aceptación de Pruebas
  • Acta de capacitación a usuarios y Mesa de Servicios
  • Acta de Entrega (comité de proyectos)

 

Implantación

En esta fase el equipo implanta la tecnología y los componentes utilizados por la solución, apoya el funcionamiento y la transición del proyecto, y obtiene la aprobación final del cliente.

En ocasiones en esta fase se ejecutan planes piloto de implementación

La fase termina con el hito Cierre de la Entrega.

Entregables:

  • Acta de Implantación
  • Encuesta de satisfacción del cliente
  • Acta de Cierre de proyecto

En seis pasos: Administración de Riesgos en MSF

Identificar

El primer paso que debe considerar el Gerente de Proyectos como el responsable general de la Administración de Riesgos es identificar durante el proceso de planificación del proyecto, aquellas actividades que tengan mayor probabilidad de no ejecución o con mas variables requeridas para una ejecución exitosa.

Durante la Planificación del Proyecto, cada miembro del equipo de MSF debe evaluar sus actividades, las variables asociadas a una exitosa ejecución como tiempo, recurso humano, alcance, capacidades técnicas y de conocimientos, clientes, proveedores, en fin, todo lo que interviene en cada actividad para que esta se ejecute.

Cada miembro colabora en la construcción de la lista de riesgos, como equipo se llega a consensos para poder continuar con la planificación del proyecto.

Durante la actividad de identificación de los riesgos en la fase de planificación del proyecto, es importantísimo el intercambio de ideas entre los miembros del equipo del proyecto, las reuniones e incluso talleres formales para la percepción real de los riesgos del proyecto.

A continuación las fuentes que pueden estimular la detección del riesgo:

  1. Personas: Habilidades y destrezas, políticas de comunicación. Se evalúan Clientes, usuarios finales, proveedores, interesados en el proyecto, ejecutores.
  2. Procesos: Presupuestos, horarios, costos, requerimientos del proyecto, diseño, construcción y pruebas.
  3. Tecnología: Seguridad, desarrollo, entornos de prueba, herramientas de implementación.
  4. Entorno: Leyes del país, reglamentos de la organización, el ambiente de negocios en la organización.

 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, una estrategia de negociación, entre otras.

Independientemente de la técnica que se utilice para cuantificar la probabilidad de riesgos, es importante reflejarlo al organizar el orden de prioridades de los riesgos, cada riesgo y su valoración de probabilidad de que ocurra debe ser validado en consenso por los miembros del equipo.

Debemos considerar también el impacto del riesgo, cuales son los costos asociados, efectos adversos.

Podemos construir una matriz de riesgos, reflejando la probabilidad y el impacto que tendría sobre el proyecto.

Planificar y programar

Unas ves construidas la matriz de riesgo, su impacto y la probabilidad de que ocurra, debemos diseñar el plan de acción, se considera que es la tarea con mayor esfuerzo dentro de la administración del riesgo.  Es desarrollar una lista de acciones y actividades a ejecutar para cada riesgo identificado.  Este plan de acción se incluye en el cronograma del proyecto, se deben asignar responsables para su ejecución.

Es importante que el equipo entienda que las actividades de control de riesgos es una parte esperada del proyecto y no un conjunto adicional de las responsabilidades que podría hacerse en forma voluntaria. Todas las actividades de riesgo deben tenerse en cuenta en la programación de proyectos y el estado de presentación de informes

Seguimiento y presentación de informes de estado de riesgo

 Se considera que este es un punto fundamental en la administración del riesgo, hacer seguimiento para poder ejecutar los planes de manera eficaz. El seguimiento nos asegura que se ejecuten los planes de contingencia desarrollados para cada riesgo en el momento oportuno.

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

  1. Plan general de Riesgo, con sus estados de avance de ejecución del proyecto, que actividad se ejecuto exitosamente, cuales son los próximos riesgos a considerar según el estatus de ejecución del proyecto, cuales se activaron y como se solucionaron, es un informe gerencial y se presenta en juntas de proyecto.
  2. Plan de Riesgo a miembros del equipo, riesgos activados, quien esta ejecutando plan de acción, impacto 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. Es un informe más operativo.

Control

Debemos hacer constante monitoreo constante de las tareas identificar, analizar, priorizar, hacer seguimiento.  Como administradores del riesgo nos comprometemos a 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.
  • Responder a los factores desencadenantes

Los resultados y las lecciones aprendidas de la ejecución de los planes de contingencia deben incorporarse al  informe final del proyecto para que la información pase a formar parte del proyecto y la base de conocimiento de riesgos empresariales.

Aprender

Aprender es la sexta estrategia de la administración del riesgo con MSF.  Aprender nos va a fortalecer como equipo, el aprendizaje es continuo nos va a ir alertando de acciones a tomar para resolver con éxito cualquier evento que se nos presente.

Debemos promover el aprendizaje fomentando un ambiente que motive a la gente a aprender, valorando su conocimiento adquirido, nuevas ideas y nuevas relaciones como aspectos vitales de la creatividad que eso conduce a la innovacion, de igual forma incluyendo y acentuando aprender en planes estrategicos

Se centra en los siguientes objetivos fundamentales:

  • Trabajo en equipo, valorando el aprendizaje por experiencias y lecciones
  • Los planes se construyen para aprender en las practicas de la administracion del riesgo del proyecto.
  • Los resultados de la administración del riesgo se evaluan para apoyar la innovacion y la mejora continua del aprendizaje.
  • Las experiencias y las mejores practicas se comparten.

MSF resalta especialmente:

  • Proporcionar control de calidad sobre las actividades actuales de gestión de riesgo para que el equipo puede obtener información periódica
  • La captura de las lecciones aprendidas, especialmente alrededor de la identificación de riesgos y estrategias exitosas de mitigación, en beneficio de otros equipos, lo que contribuirá a la base de conocimiento sobre los riesgos
  • Mejorar el proceso de gestión de riesgos mediante la captura de comentarios por parte del equipo

Principios Fundamentales Aplicados a la Administración de Riesgos en MSF

Definición de Riesgo y Administración del Riesgo

Antes de comenzar a desarrollar el tema sobre la administración del riesgo con MSF, es importante hacer una definición de riesgo, en este sentido cabe destacar que el riesgo es una situación de probabilidad de ocurrencia de un evento, una vulnerabilidad, una amenaza. Subrayo probabilidad porque así debemos enfocarlo, no es una certeza, en otras palabras la probabilidad de ocurrencia no puede ser 0 ni puede ser 1, ¿Por qué? Si es 0 es porque estamos seguros de que un evento jamás va a ocurrir entonces no hay riesgo y si es 1 es un evento seguro de que ocurrirá y allí estaríamos más bien preparados para el hecho.

Basándonos en la definición estricta del riesgo y analizando el momento que planificamos las actividades de un proyecto, observaremos que no estamos seguros de que todas las actividades puedan ejecutarse, sin embargo no podríamos decir que todas las actividades del proyecto  son un riesgo, ¿Por qué en la vida practica NO consideramos todas las actividades como un riesgo?, sencillo sabemos que existen actividades que tienen mayor probabilidad de ocurrencia que otras.

Continuando con el párrafo anterior, dentro del manejo de riesgo del proyecto ponemos aquellas actividades que tengan una probabilidad de afectar a nuestro proyecto en tiempo, costo y alcance más alta que otras.

Un riesgo es un evento que nos pueda afectar en tiempo, costo, alcance y calidad al proyecto.  Es aquí donde surge la importancia de la Administración del Riesgo.

La Administración del Riesgo aumenta la probabilidad de éxito en un proyecto, minimizando el potencial para el fracaso.

La Administración del Riesgo puede definirse como una forma de abordar un problema desde un punto de vista gerencial para disminuir los riesgos inherentes al proyecto La administración del riesgo pretende identificar, estudiar y eliminar las fuentes de riesgo antes de que comiencen a amenazar el éxito o la finalización exitosa de un proyecto

Principios Fundamentales Aplicados a la Administración de Riesgos en MSF

1 Mantenernos Alertas y preparados para el cambio.

Como administradores del riesgo debemos desarrollar habilidades básicas para mantenernos alertas, habilidades que nos permitan ejecutar un buen papel frente a los cambios que podemos estar haciendo durante todo el ciclo de vida del proyecto, producto del análisis de riesgos del mismo. Estas habilidades son:

  1. Identificar: Tenemos que tomar estándares o guías, que pueden ser propios del proyecto, del cliente, de la empresa donde laboramos, para aprender y visualizar que es un riesgo y que no.
  2. Analizar: Es la habilidad más importante porque el análisis arroja sobre una actividad de riesgo su impacto en costo, tiempo y calidad.
  3. Planear: Acciones concretas para contener el riesgo, poner en blanco y negro que hacer para que los riesgos se minimicen.
  4. Controlar, administrar y monitorear los riesgos con todas las actualizaciones.  A menudo puede pasar que un riesgo que planeamos no se convierte en un evento, sin embargo el riesgo una vez que transcurre el proyecto desaparece y aparecen otros  nuevos, es un proceso constante de identificación, análisis, evaluación y monitoreo de los riesgos, es importante estar pendiente hacia todos los riesgos que puedan ocurrir al principio del proyecto y durante todo el ciclo de vida.

Producto del constante monitoreo sobre los riesgos durante el ciclo de vida del proyecto puede originar cambios en las actividades del proyecto en momentos determinados con la finalidad de minimizar amenazas y aumentar la probabilidad de éxito.

Un enfoque proactivo permite al equipo aceptar el cambio y convertirlo en una oportunidad, y con ello evitar que el cambio pueda  convertirse en una fuerza perturbadora, en algo negativo.

2  Promover una Comunicación Abierta en el Modelo de equipo de trabajo MSF

MSF alienta una actitud de comunicación abierta hacia debatir los riesgos, tanto con los miembros de equipo de trabajo como con los principales interesados externos del  proyecto. Todos los miembros del equipo deben participar en la identificación de riesgos y en el análisis de los mismos.

Los jefes de equipo y la administración de riesgos deben apoyar y fomentar el desarrollo de una cultura de no culpar a ningún miembro del proyecto sobre la probabilidad de que ocurra un riesgo, al contrario, se debe promover una discusión franca y abierta de los riesgos del proyecto con todos los afectados por ese riesgo, para conducirnos a una mayor precisión en la evaluación del estado del proyecto y una mejor toma de decisiones, tanto dentro del equipo como en la dirección ejecutiva y los patrocinadores.

3 Cuentas Claras, Responsabilidad Compartida.

Como describimos en un artículo publicado anteriormente sobre el El Modelo de equipo MSF, este modelo se basa en la premisa de que cada función presenta una perspectiva única en el proyecto y que ninguna persona por sí misma puede representar de una manera satisfactoria todos los objetivos de calidad de todas las funciones. Sin embargo, el cliente necesita una sola fuente de información que cuente con autoridad sobre el estado del proyecto, las acciones y los problemas actuales. Para resolver este dilema, el equipo de compañeros debe combinar una línea clara de responsabilidad hacia el cliente con la responsabilidad compartida con el fin de lograr el éxito en general.

Dentro del equipo, cada función es responsable de todas las actividades que son necesarias para lograr su propio objetivo de calidad.  Cada miembro del equipo es responsable del éxito general del proyecto y de la calidad de la solución y se espera que contribuya con ideas y observaciones que se deriven de su conocimiento incluso en áreas en las que no es responsable de una manera personal.

En concreto, las funciones del equipo MSF comparten responsabilidad en muchos aspectos de la administración del proyecto, por ejemplo, la administración del riesgo, la administración del tiempo, la administración de la calidad, el planeamiento, la programación, la selección de los miembros del equipo y la administración de los recursos humanos.

 Bajo esta premisa, no hay una sola persona que administre el riesgo dentro de MSF, cada integrante del equipo debe rendir  cuentas claras sobre sus actividades actividades y la administración de riesgos.

Sin embargo es el área de Gerencia de Proyectos quien lidere en general la administración del riesgo.  Es el Gerente de Proyecto el responsable general de la Administración del Riesgo.

4. Aprender de Todas las Experiencias

En todas las disciplinas, y dentro de la vida misma el aprendizaje continuo sobre las experiencias o hechos nos dan la condición de mejorar perennemente.

MSF nos invita a analizar constantemente las actividades del proyecto, los factores de éxito, los factores de riesgo, el conocimiento acumulado de un proyecto puede disminuir la incertidumbre en torno a la toma de decisiones.

Documentar las versiones del proyecto, los cambios efectuados, como se abordaron las situaciones de riesgos, es colocar conocimiento disponible para que otros puedan aprovechar en el próximo proyecto.

Tareas, responsabilidades y áreas funcionales del Modelo de Equipo de Trabajo MSF

Tareas, responsabilidades y áreas funcionales del Modelo de Equipo de Trabajo MSF

Este modelo de equipo MSF no es rígido y puede ser escalado dependiendo del tamaño de los proyectos y de las personas disponibles. Cada papel que se presenta a continuación contiene varias áreas funcionales estrechamente relacionados que apoyan el objetivo del rol que se este desempeñando.

 

 

 

 

 

 

 

 

El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o más personas, la estructura circular del modelo, con óvalos del mismo tamaño para todos los roles, muestra que no es un modelo jerárquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.

La comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y es esencial para el funcionamiento del mismo 

¿Como están estructurados los roles?

  • Seis funciones principales, donde cada funcion refleja sus areas funcionales.
  • Cada area funcional tiene responsabilidades especificas asociadas importantes para alcanzar el exito del proyecto.
  • A su vez, cada responsabilidad puede ser dividida en varias tareas necesarias para llevarla a cabo.
  • Si una funcion especifica es muy amplia para ser ejecutada por una sola persona, se permite dividir la funcion en varias personas especificando responsabilidades.

Ejemplo de como estructuramos los roles (tareas, responsabilidades y areas funcionales):

A continuación una breve descripcion de la funcion de cada integrante del modelo y sus areas funcionales:

1. Gerente del Proyecto:

Es responsable de entregar la solución dentro de las restricciones del proyecto (Tiempo, Alcance, Costos).

Áreas funcionales:

  • Administración del proyecto:  las responsabilidades son el seguimiento y control del presupuesto del proyecto asi como la visión general del proyecto y el gantt general; conducir la gestión de riesgos, asignar tareas , recursos a los miembros del equipo, facilitar la comunicación dentro del equipo, seguimiento de progreso del proyecto, gestionar informenes de estado.
  • Arquitectura de la solución:  Velar por la arquitectura de la solucion se visualice, desarrolle e implemente a cabalidad, en algunos equipos de proyecto el Gerente de Proyecto es la misma persona que trabaja como Arquitecto de Soluciones, en otros proyectos son personas diferentes donde el Arquitecto de Soluciones es el lider del equipo de desarrollo de software.  Esta responsabilidad tambien gestiona el alcance de la solucion.
  • Aseguramiento del proceso:  Velar por la calidad del desarrollo, definir y recomendar mejoras.
  • Servicios administrativos : Implementación de procesos y equipo de soporte.
  • 

Gerente del Producto

Representa a los interesados (skateholders) del proyecto. Debe garantizar la Satisfacción a los clientes.

Áreas funcionales:

  • Identificar el Valor de negocio:  definición de Metricas para medir el valor del negocio y definir la justificación del proyecto y el impacto sobre la organización.
  • Marketing: Promocion de la solución entre los miembros del equipo del proyecto resaltando el para que se esta ejecutando el proyecto.
  • Abogado del cliente: Maneja y comunica las expectativas del cliente, mantiene la comunicación entre el cliente y el equipo del proyecto.
  • Planeamiento del producto (roadmap) :  Recoger, analizar y priorizar las necesidades del cliente y del negocio.  Determinar métricas de negocio y criterios de éxito. Identificar cuando ir liberando las versiones del producto segun el equipo de proyecto vaya entregando avances.

Desarrollador

Construye la solución de acuerdo con las especificaciones.

Áreas funcionales:

  • Consultoría tecnológica: El desarrollador tiene la responsabilidad de ejercer el rol de consultor tecnologico, participa activamente en los requerimientos funcionales.
  • Diseño e implementación de la arquitectura:  Mapea la arquitectura diseñada para la aplicación, implementa respetando el diseño fisico de la solución.
  • Desarrollo de la aplicación: Codifica segun el diseño logico que le es entregado. Depura el codigo y presta soporte.
  • Desarrollo de la infraestructura:  Desarrollo de documentación de implementación, los scripts para el despliegue automatizado, realización de revisiones de código, la realización de las pruebas unitarias.
  • 

Pruebas

Responsable de aprobar la versión solo luego de que todos los defectos de calidad son identificados y resueltos.

Áreas funcionales:

  • Planificación de pruebas: Elaborar diseño y especificaciones del plan de pruebas.
  • Reportes de pruebas: Seguimiento de errores y comunicaciones, la finalidad es estar seguros de que todas las correcciones se han efectuado antes de liberar una versión.

Puesta en operación

Planifica y ejecuta una puesta en operación sin tropiezos. Dar soporte a las operaciones.

Áreas funcionales:

  • Planificación de la Infraestructura:  Gestión de hardware y adquisición de software, crear normas, politicas y procedimientos para la infraestructura empresarial.
  • Soporte: Servicio de soporte técnico al cliente, establece niveles de atencion y registra las incidencias.
  • Logística:  Administración de cuentas de usuario, logistica de operación.
  • Custodia y Administración de versiones.
  • 

Experiencia de Usuario:

Mejora la efectividad del usuario.

 Áreas funcionales:

Generar material para entrenamiento y soporte, Investigación y pruebas de “usabilidad”, Colaboración en definir el diseño de la interfaz de usuario, Abogado del usuario final.