Download - Presentación del Trabajo Final PSM Dashboard

Traba

PanPr

FacCar

ajo Final

nel de oyecto

Pontificultad de rera de E

Especial

PSM

Controos de D

AutorTutor:

icia UniveCiencias

EspecializC

ización e

Tema:

M Dash

ol paraDesarr

r: Pablo CAlejandro

ersidad Cs Fisicomzación enCurso: 20

en Ingenie

hboard

a el morollo de

Chocróno Bianchi

Católica Aatemática

n Ingenier006

ería de S

onitoree Softw

i

Argentina as e Ingería de So

Software

eo de ware

eniería oftware

UCA, Trabajo Final Especialización en Ingeniería de Software PSM Dashboard

Página 2

Tabla de Contenidos 1 Introducción .............................................................................................. 4

1.1 Alcance del trabajo ................................................................................. 5

1.2 Organización del trabajo ........................................................................... 5

2 Contexto del proyecto ................................................................................. 7

2.1 Know Edge .......................................................................................... 7

2.2 Características de los clientes .................................................................... 8 2.3 Metrix ................................................................................................. 9 2.4 Soft Star .............................................................................................. 9 2.5 Requisitos relacionados con el contexto del proyecto. ....................................... 10

3 Estándares aplicables al producto PSM Dashboard ................................................ 12

3.1 PSM: Practical Software and System Measurement ......................................... 12

3.1.1 Parte 1: El Proceso De Medición .......................................................... 12

3.1.2 Parte 2: Adaptación de las Mediciones ............................................. 18

3.1.3 Parte 3: Selección y especificación de mediciones ............................. 30

3.1.4 Parte 4: Aplicación De Las Mediciones ............................................. 35

3.1.5 Parte 5: Ejemplos de Indicadores ................................................... 54

3.1.6 Parte 6: Implementación Del Proceso .............................................. 60

3.2 CMMI: Capability Maturity Model Integrated ........................................... 64

3.2.1 PSM Dashboard y CMMI ................................................................ 64

3.2.2 Que es CMMI? .............................................................................. 64

3.2.3 Foco en los procesos ..................................................................... 64

3.2.4 Organización del modelo CMMI ....................................................... 65

3.2.5 Niveles de madurez ...................................................................... 66

3.2.6 Requisitos de mediciones de cada nivel de madurez. ......................... 68

3.2.7 Resumen de las mediciones derivadas de modelo CMMI ..................... 86

4 Arquitectura ............................................................................................. 89

4.1 Definición de arquitectura y factores determinantes. ............................... 89

4.2 Selección de la Arquitectura ................................................................. 91

4.2.1 Atributos de Calidad ..................................................................... 91

4.2.2 Patrones Arquitectónicos ............................................................... 93

4.2.3 Evaluación de Arquitecturas: ATAM ................................................. 94

4.2.4 Evaluación de arquitectura de PSM Dashboard .................................. 96

4.3 Business Intelligence ........................................................................ 101

4.3.1 Que es Business Intelligence? ...................................................... 101

4.3.2 Características de un framework de BI, relación con PSM Dashboard. 102

4.3.3 Arquitectura de productos de Business Intelligence ......................... 109

4.3.4 Arquitectura adoptada para PSM Dashboard ................................... 112

5 Análisis de productos existentes ................................................................ 115

5.1 Distributive Management: Data Drill .................................................... 115

5.2 Telelogic Dashboard .......................................................................... 119

5.3 Comparación de productos ................................................................. 121


Página 3

6 Requisitos del producto ............................................................................ 124

6.1 Ingenieria de requisitos de PSM Dashboard .......................................... 124

6.2 Especificación de los requisitos de PSM Dashboard ................................ 126

6.3 Introducción al estándar IEEE 830 ...................................................... 126

7 Conclusiones .......................................................................................... 128

8 Referencias ............................................................................................ 130

9 Glosario ................................................................................................. 131


Página 4

1 Introducción En sus comienzos, el desarrollo de software fue una actividad artesanal donde los proyectos eran realizados por equipos reducidos o incluso unipersonales, pero la complejidad de los proyectos de software se ha incrementado por los diferentes motivos:

- Los productos de software son cada vez más complejos: el desarrollo de las más diversas transacciones mediante Internet es un ejemplo de esta complejidad creciente.

- Se ha incrementado la participación de los componentes de software, como medios para proveer las funcionalidades requeridas en los productos de dominios más diversos, por ejemplo en la industria automotriz, muchas funcionalidades que en otros tiempos fueran realizadas por medios mecánicos o electrónicos, son hoy realizadas mediante aplicaciones de software.

Además de esta complejidad creciente, el contexto en el que se desarrollan estos productos, es más dinámico y cambiante, por lo que el gerenciamiento de proyectos de desarrollo de software es un desafío cada vez mayor, tanto para los gerentes de proyecto, como para los gerentes técnicos, quienes deben contar con las herramientas que les provean la información puntual y precisa, necesaria para tomar las decisiones que les permitan alcanzar los objetivos de calidad, plazos, costos y desempeño previstos en cada proyecto. Surge entonces, en el desarrollo de software la necesidad de contar con sistemas de mediciones eficaces, tal como ocurre en otras áreas de la Ingeniería.

La Organización Practical Software and System Measurement (PSM) ha definido un sistema de mediciones para proyectos de desarrollo de software y sistemas basado en las mejoras prácticas probadas extensivamente en proyectos corporativos y gubernamentales. El objetivo del sistema de mediciones PSM es brindar a los gerentes técnicos y de proyecto la información cuantitativa necesaria para poder tomar, basándose en datos objetivos, las decisiones necesarias que impactarán en el logro de los resultados del proyecto.

En este trabajo la empresa hipotética “Know Edge”, especializada en sistemas de monitoreo de gestión empresarial, consistentes en paneles de control (Dashboards) basados principalmente en los conceptos de Business Intelligence, decide lanzar un nuevo producto: “PSM Dashboard” para atender las necesidades de un número creciente de clientes que desarrollan software, y requieren un producto específico para el monitoreo de sus proyectos.

El objetivo del producto “PSM Dashboard” es facilitar la implementación de un programa de mediciones basado en la metodología establecida por PSM (Practical Software and System Measurement) y en los requisitos del modelo CMMI.

La actividad central de Know Edge es la provisión de soluciones de gestión basadas en los productos mencionados, y de todos los servicios de consultoría y capacitación necesarios para asegurar el éxito de los proyectos. Know Edge no realiza actividades de desarrollo, sino que las subcontrata habitualmente a la empresa Soft Star (CMMI nivel 4), quien también en este caso, se ocupará del desarrollo del nuevo producto.


Página 5

1.1 Alcance del trabajo Es la intención de Know Edge formalizar mediante un contrato con Soft Star el desarrollo del producto PSM Dashboard. Este contrato debe incluir una Especificación de Requisitos de Software (SRS) en el que se documentan los requisitos del el producto

Antes de contratar el desarrollo, Know Edge contrata para la elaboración de la SRS a la consultora Metrix, especializada en la implementación de programas de mediciones basados en PSM en organizaciones que realizan desarrollo de software o integración de sistemas.

El objetivo de este trabajo elaborar la Especificación de Requisitos de Software del producto PSM Dashboard, incluyendo todos los trabajos de análisis previos necesarios para poder elaborar la SRS.

1.2 Organización del trabajo Se ha organizado el trabajo en las siguientes secciones:

En el capítulo 2, (Contexto del proyecto) se describen las características de la empresa Know Edge, y sus motivaciones para el desarrollo del producto PSM Dashboard, también se hace una breve referencia a la empresa Subcontratista Soft Star y la consultora Metrix.

En el mismo capítulo se realiza una descripción de los clientes de Know Edge, y de los motivos por los que surge la necesidad de contar con este nuevo producto.

El capítulo 3 (Estándares aplicables al producto PSM Dashboard) incluye un análisis de las características que debe tener el producto al estar basado en los estándares PSM y CMMI.

En el capítulo 4 (Arquitectura) se analizan los criterios empleados para la selección de la arquitectura de PSM Dashboard, teniendo en cuenta los atributos de calidad previstos para el sistema. En el mismo capítulo se analiza la tecnología y arquitectura de las soluciones de Business Intelligence, y se propone una arquitectura para PSM Dashboard.

En el capítulo 7 (Análisis de productos existentes) se analizan las características de productos disponibles en el mercado que compiten con PSM Dashboard, con el propósito de especificar los requisitos de PSM Dashboard asegurando que cuente con ventajas competitivas que lo diferencien de sus competidores.

En el capítulo 8 (Requisitos del producto) se describe la especificación de requisitos de PSM Dashboard, basada en las recomendaciones del estándar IEEE-830. La especificación de PSM Dashboard no está incluida en este documento, sino que se presenta separadamente en el documento (PSM Dashboard, Especificación de Requisitos del Producto)

El trabajo se completa con las Conclusiones, que son detalladas en el capítulo 9


Página 6


Página 7

2 Contexto del proyecto

2.1 Know Edge Know Edge se especializa en la provisión de espacios de trabajo colaborativos para empresas distribuidas geográficamente, sistemas de ingeniería concurrente y Dashboards (Paneles de Control) para la gestión integral del negocio basados en el concepto Inteligencia de Negocios (Business Intelligence).

Si bien Know Edge cuenta con su propia línea de productos, y en los últimos años se ha focalizado en soluciones basadas en su producto de BI “Know Edge Business Dashboard”, su principal actividad es la consultoría, que consiste en un intenso trabajo con sus clientes para analizar sus necesidades y proponer soluciones que incluyen la provisión, instalación, adaptación y configuración del software, la capacitación y concientización a todo el personal involucrado y el coaching necesario para asegurar resultados exitosos una vez que los sistemas se encuentran en operación. Este es un trabajo complejo, considerando que los clientes de Know Edge son empresas multinacionales con unidades operativas distribuidas en diferentes regiones.

Los clientes de Know Edge son empresas globales del área tecnológica que encontraron en las soluciones basadas en sus sistemas de colaboración, ingeniería concurrente y gestión integral, y en su producto “Know Edge Business Dashboard” una solución que permite el trabajo colaborativo y logra una visión compartida en equipos geográficamente.

Muchos de estos clientes centran su actividad en el desarrollo y comercialización de diferentes tipos de productos. Las actividades de desarrollo combinan tareas de integración, desarrollo de hardware y de software, pero la tendencia registrada en los últimos años es que este último aspecto cobró una importancia central, ya que la mayoría de las funcionalidades se resuelven mediante algoritmos de software por lo que el foco de las actividades de desarrollo se orientaron a este aspecto. Además, en los últimos años Know Edge ha sumado nuevos clientes dedicados exclusivamente al desarrollo de software, y es la estrategia de Know Edge fortalecer su presencia en este segmento creciente.

La necesidad de los clientes de Know Edge de contar con herramientas de información para el monitoreo de proyectos, motivó el desarrollo del producto PSM Dashboard consistente en un sistema de mediciones para proyectos de desarrollo de sofware adecuado para equipos geográficamente distribuidos, capaz de integrarse con los Portales Colaborativos y con los Sistemas de BI (Business Intelligence) para la Gestión Integral del Negocio que Know Edge ya provee.

En la incorporación de PSM Dashboard a su línea de productos, Know Edge aprovecha su experiencia en la colección de datos de las fuentes más variadas, su procesamiento y presentación mediante paneles de control (dashboards) y su publicación mediante portales colaborativos. En otros términos, en el nuevo producto PSM Dashboard, Know Edge aplica su experiencia en soluciones de Business Intelligence a los procesos de mediciones en proyectos de desarrollo de software.


Página 8

2.2 Características de los clientes Entre los clientes actuales de Know Edge se cuentan empresas globales de tecnología cuyos productos incluyen componentes de software en diferentes medidas:

• Empresas que desarrollan software exclusivamente, por ejemplo aquellas especializadas en e-commerce.

• Empresas que desarrollan productos que incluyen software, por ejemplo dedicadas al desarrollo de equipamiento de electromedicina, entretenimiento o instrumentos para telecomunicaciones.

• Empresas que no desarrollan software, por ejemplo dedicadas a Obras de Ingeniería Civil.

Un factor común de los clientes de Know Edge es que su operación se encuentra dispersa geográficamente, y se ha notado en los últimos años grandes esfuerzos para lograr sinergia entre distintas localizaciones, por ejemplo mediante la formación de equipos virtuales, en los que participan especialistas de diferentes regiones. Esta modalidad de trabajo colaborativo virtual, se presenta tanto en actividades estratégicas, de marketing, comerciales, como también en los proyectos de desarrollo de productos.

Los clientes de Know Edge son en su mayoría empresas multinacionales que adoptan los más altos estándares de procesos y de calidad aceptados internacionalmente, por lo que en general sus procesos de desarrollo de software están basados en el modelo CMMI.

Por este motivo Know Edge decidió que PSM Dashboard sea un producto de clase mundial, conforme con los más elevados estándares, tales como CMMI, y más específicamente basado en la metodología para mediciones en proyectos de desarrollo establecida por la organización Practical Software & System Measurement (PSM)

Los clientes de Know Edge tienen implementadas soluciones de Business Intelligence en su mayoría mediante el producto “Know Edge Business Dashboard” que consiste en mediante Paneles de Control (Dashboards) publicados en portales colaborativos para que toda la organización pueda tener una visión compartida de los principales indicadores, y tomar decisiones en base a datos objetivos. Estos Dashboard son elaborados a partir de abundante cantidad de información que se encuentra en los repositorios de diversos sistemas de la empresa (Sistemas de gestión comercial, ERP, CRMs, Timesheets, etc.). Un factor muy apreciado por los clientes de Know Edge es la claridad de sus paneles de control, basados en la aplicación de las mejores prácticas de diseño de Dashboards.

Algunos clientes han adoptado últimamente el producto SharePoint de Microsoft como plataforma para sus portales corporativos, estos clientes, sin embargo, continúan empleando los paneles de control de Know Edge, dado que los mismos se integran con SharePoint.

Si bien el producto PSM Dashboard presentará a los gerentes de proyecto y los líderes de equipos de desarrollo una visión completa del estado de los proyectos de desarrollo bajo su responsabilidad, los directores querrán tener una vista integrada del estado de los proyectos de desarrollo y de otros aspectos del negocio (comerciales, marketing, financieros, recursos humanos y otros), por lo que el producto PSM Dashboard debe tener la capacidad de integrarse con los otros sistemas de monitoreo de gestión empresaria ya provistos por Know Edge.


Página 9

2.3 Metrix Además de contratar especialistas en Ingeniería de Software, Know Edge contrató a la consultora Metrix para definir los requisitos del producto PSM Dashboard, y para capacitar a sus ingenieros en aspectos de mediciones en software y PSM.

La consultora Metrix se especializa en la implementación de programas de mediciones, capacitación y consultoría para empresas dedicadas al desarrollo de software. Metrix cuenta con una vasta experiencia en la aplicación de las mejores prácticas de medi-ciones en software basadas en los procesos definidos por la organización Practical Software and System Measurement (PSM) y el modelo CMMI.

2.4 Soft Star Dado que las actividades de Know Edge se orientan primordialmente a un intenso trabajo con sus clientes, la empresa ha decidido tercerizar las actividades de desarrollo de software, esta subcontratación se realiza en forma casi exclusiva a la empresa Soft Star (CMMI nivel 4) quien ha desarrollado la totalidad de los productos que Know Edge comercializa.

Know Edge y Soft Star mantienen una alianza estratégica para el desarrollo de aplicaciones prácticamente desde el comienzo de las operaciones de Know Edge.

Luego de haber incursionado en diferentes dominios y tecnologías, Soft Star se especializa en el desarrollo de Dashboards, Portales Colaborativos y tecnologías de Business Intelligence incluyendo la extracción de datos de diversas fuentes, y su almacenamiento en repositorios centralizados (Data Warehouse).

Actualmente las actividades de desarrollo de Soft Star se basan en la plataforma .NET y en la base de datos Microsoft SQL Server, si bien el personal de Soft Star tiene una vasta experiencia en las plataformas y lenguajes más diversos.

La relación entre Know Edge y Soft Star ha alcanzado un alto nivel de madurez y profesionalismo y se basa en una fuerte confianza, una comunicación fluida durante todo el ciclo de vida de los proyectos de desarrollo, y al mismo tiempo un alto grado de formalidad en todas sus fases, desde la contratación hasta la aceptación del producto.

El alto nivel de formalidad en esta relación no incluye actividades burocráticas, sino que por el contrario, se han establecido mecanismos simples y efectivos para asegurar el resultado exitoso de los proyectos, y lograr productos de la más alta calidad. Entre estas actividades se incluyen:

• Documentación de los requisitos del producto mediante las recomendaciones de estándar IEEE 830 (esta actividad es responsabilidad de Know Edge y establece el marco contractual).

• Planificación del proyecto.

• Validación de requisitos detallados modelados mediante casos de uso y otros diagramas UML.

• Validación de prototipos y sketchs de pantallas.

• Planificación de las pruebas.

• Validación de resultados de pruebas.

• Validación de productos mediante demos, walkthroughs, trials y pilotos.


Página 10

Además de la realización formal de estas actividades, los canales de comunicación informal son muy fluidos, y es muy habitual encontrar personal de Know Edge trabajando en Soft Star y viceversa.

La especificación los requisitos del producto mediante especificaciones formales basadas en el Estándar IEEE 830 ha sido un factor de éxito en proyectos anteriores, por lo que esta práctica se ha establecido como norma en las contrataciones de desarrollo de nuevos productos.

2.5 Requisitos relacionados con el contexto del proyecto. De los aspectos relacionados con el contexto del proyecto que se mencionan precedentemente, y mas específicamente del perfil de los clientes de Know Edge, pueden derivarse algunos primeros requisitos del producto, muy generales, que serán refinados más adelante en este trabajo

Requisitos del producto:

PSMD podrá funcionar como una aplicación autónoma para atender a las necesidades de los Project Managers, Líderes de desarrollo, Equipos de desarrollo y stakeholders del proyecto.

Los dashboard seleccionados podrán presentarse en forma integrada con los siguientes productos:

• Know Edge Business Dashboard: Paneles de control para la gestión integral del negocio de Know Edge, publicados mediante portales colaborativos

• Sharepoint 2003 y 2007, mediante Web Parts o URLs.

PSMD contará con las interfases necesarias para colectar datos de las fuentes de información necesarias para obtener los datos mencionados en el estándar PSM.

Estándares aplicables

PSM: Practical Software and System Measurement.

Capability Maturity Model® Integration, del SEI.


Página 11


Página 12

3 Estándares aplicables al producto PSM Dashboard En esta sección se realiza un análisis más detallado de los estándares aplicables al producto PSM Dashboard con el objeto de derivar de estos estándares, los requisitos del producto PSM Dashboard, los Estándares aplicables son PSM y el Modelo CMMI.

3.1 PSM: Practical Software and System Measurement Practical Software and System Measurement (PSM), presenta un enfoque probado para definir e implementar un proceso de mediciones efectivo para proyectos de desarrollo de software e integración de sistemas. El objetivo de PSM es proveer a los Gerentes de proyecto y técnicos la información cuantitativa requerida para tomar decisiones objetiva que impactarán en los objetivos de costo, plazos, y desempeño técnico.

El proceso propuesto por PSM está basado en un conjunto de prácticas probadas en numerosos proyectos, tanto en el área gubernamental como corporativo.

En esta sección se realiza una síntesis de los aspectos incluidos en el documento “Practical Software and Systems Measurement, versión 4.0” que impactan en la definición de los requisitos del producto PSM Dashboard. Considerando la extensión del documento, y para ordenar los conceptos, se realiza un resumen de aspectos por cada capítulo de la guía.

Los comentarios sobre la aplicabilidad o el impacto de cada concepto están escritos en itálica, para diferenciarlos de la información incluida en la Guía PSM.

Se empleará la sigla PSMD como acrónimo de PSM Dashboard

3.1.1 Parte 1: El Proceso De Medición Esta sección explica la importancia de contar con un sistema flexible de mediciones para poder tomar decisiones a partir de información objetiva, en un contexto en el que la complejidad de los sistemas es cada vez más elevada.

Las mediciones han probado ser una herramienta efectiva en la gestión de proyectos tanto en el área gubernamental como corporativa. Las mediciones, cuando están integradas al proceso general de gestión, ayuda al Gerente de Proyecto en la identificación de riesgos, el seguimiento de los problemas y permite evaluar el impacto de estos problemas en el logro de los objetivos del proyecto.

Las mediciones ayudan al gerente de proyecto a realizar planes más realistas, y a monitorear el progreso de los proyectos en relación a los planes establecidos. Las mediciones proveen información para tomar decisiones clave y tomar las acciones apropiadas. Los beneficios de contar con un programa de medición efectivo se resumen a continuación:

• Lograr una comunicación efectiva a través de la organización del proyecto

• Identificación y corrección de problemas en fases mas tempranas

• Adoptar soluciones de compromiso

• Controlar el logro de los objetivos del proyecto

• Defender y justificar las decisiones


Página 13

3.1.1.1 Visión general del proceso de mediciones La describe el proceso de mediciones establecido por PSM

Figura 1

Este proceso está compuesto por las siguientes actividades:

• Implementación del Proceso: Comprende las actividades de implementación del sistema de Mediciones en la Organización. Se relaciona mas con las actividades de consultoría de Know Edge que con requisitos del PSM-Dashboard.

• Adaptación y Aplicación de las mediciones: Estas actividades constituyen el núcleo del proceso de mediciones e incluyen la planificación y la ejecución de las mediciones. Estas actividades definen los aspectos principales del PSM Dashboard.

• Procesos técnicos y de gestión: Estos procesos están fuera del alcance del PSM-Dashboard.

• Evaluar Mediciones: Este proceso es externo al PSM-Dashboard y se encuadra en las actividades de mejora continua definidas por ISO-9001 y el modelo CMMI

3.1.1.2 Principios de mediciones El proceso PSM define nueve principios, se analiza en cómo pueden ser considerados en la determinación de los requisitos del producto.

1) Defina los requisitos de las mediciones basándose en Issues y Objetivos.

La identificación de los issues (problemas y riesgos que amenazan el logro de los objetivos) debe realizarse al comienzo del proyecto. PSMD proveerá los medios para documentar esta evaluación en la fase inicial, y realizar las actualizaciones necesarias.

Procesos técnicos y de gestión

Implementar el Proceso

Adaptar las mediciones

Aplicar las mediciones

Evaluar las mediciones

Realimentación de los Usuarios

Análisis de los resultados Necesidades de información

Acciones de Mejora

Análisis de resultados y

mediciones de desempeño

Plan de Mediciones

Nuevos Issues

Alcance de PSM

Núcleo del proceso de Mediciones


Página 14

2) Defina y colecte las mediciones basándose en los procesos técnicos y de gestión. Este principio sugiere que se tengan en cuenta los procesos existentes para definir la colección de datos de forma más efectiva y económica.

PSMD contará con las interfases necesarias (colectores) para recolectar datos en forma automática de las fuentes mas populares de información, como por ejemplo timesheets, ERPs, Software de gestión de proyecto o Application Lifecycle Management (ALM).

3) Colecte y analice los datos a un nivel de detalle suficiente para identificar y aislar problemas.

El proceso PSM depende de la recolección periódica, el procesamiento y el análisis de los datos. El nivel de detalle dependerá de la granularidad del producto (definida en su estructura) o de las actividades del proyecto (definido en la WBS, work breakdown structure)

PSMD proveerá los medios para registrar la estructura del producto y del trabajo (WBS), esta información podrá obtenerse de otros aplicativos de gestión de producto (por ejemplo Configuration Management) o de proyectos (MS Project)

4) Implementar una capacidad de análisis independiente.

Para lograr objetividad, el análisis de las mediciones debe ser realizada por un grupo independiente del que produce los datos, esta actividad puede ser realizada por Control de Calidad, u otro equipo independiente de verificación.

Para permitir el análisis independiente, PSMD incluirá un rol de analista de mediciones que contará con los permisos correspondientes, se evaluará la conveniencia de establecer Workflows.

5) Use un proceso de análisis sistemático para correlacionar las mediciones con las decisiones.

PSMD incluirá el Modelo de Análisis Estructurado para sistematizar análisis. Los mecanismos de anotaciones en Dashboards y Reportes permiten registrar la trazabilidad entre las mediciones y las decisiones.

6) Interprete los resultados de las mediciones en el contexto de otros proyectos PSMD permitirá la comparación de los valores reales de proyectos en curso con los planificados y con los resultados de otros proyectos concluidos. También permitirá registrar información de contexto no cuantitativa, que permita realizar un mejor análisis de las mediciones

7) Integre las mediciones en el proceso de gestión de proyectos, a través de su ciclo de vida.

Los resultados de las mediciones deben ser provistos a los gerentes como una parte integral de la información de soporte para la toma de decisiones, y no en forma separada. El proceso de mediciones aplica a todo el ciclo de vida del proyecto, que se compone de tres fases principales: Planeamiento del proyecto, Desarrollo y Operación y Mantenimiento. Las mediciones realizadas en cada fase tienen consecuencias en la siguiente.

PSMD asociará las mediciones con la fase del proyecto durante su ciclo de vida. También permitirá explorar fases anteriores del mismo proyecto (por ejemplo evaluar los indicadores correspondientes a la fase de planeamiento en un proyecto que se encuentra en ejecución)


Página 15

8) Emplee el proceso de mediciones como la base de una comunicación efectiva Las actividades de mediciones no deben realizarse en forma aislada, tanto la definición de las mediciones como los resultados y el análisis de las mismas deben ser comunicadas efectivamente a todo el equipo de proyecto. Es muy importante asegurar que todos empleen los mismos datos y tengan un entendimiento común de sus definiciones.

PSMD se integrará en los portales colaborativos de Know Edge y en otros portales basados en la plataforma Sharepoint de Microsoft.

La planificación de las comunicaciones se realizarán mediante los siguientes mecanismos.

• Scheduling de la colección, elaboración de indicadores, análisis y distribución

• Workflow selectivo de distribución por roles y equipo

• Alertas programables.

9) Focalice inicialmente en un análisis a nivel de proyecto

PSMD asociará cada registro de análisis con el proyecto y la fase correspondientes, y permitirá consultar todos los registros de análisis realizados durante el ciclo de vida del proyecto, separado por fase, o compararlos resultados de múltiples proyectos.

3.1.1.3 Aplicación al ciclo de vida de los proyectos El proceso PSM aplica a todas las fases del proyecto: Planeamiento, Desarrollo, Operación y Mantenimiento. Los procesos de gerenciamiento de proyectos se ejecutan en forma paralela en estas fases.

Dado que en diferentes fases se emplean diferentes mediciones, PSMD tendrá un registro de esta relación, y presentará a los usuarios las mediciones mas adecuadas para cada fase.

PSMD presentará a los usuarios las mediciones más adecuadas para cada fase (biblioteca de mediciones). Las fases pueden ser simultaneas dentro del mismo proyecto (por ejemplo mientras un equipo realiza la operación y requiere mediciones de disponibilidad, otro equipo realiza el mantenimiento y requiere información de cantidad de cambios pendientes y costo por cambio)

Se analiza a continuación los aspectos del proceso de mediciones que se relacionan con cada fase, y los requisitos de PSM Dashboard asociados:

• Planeamiento de proyectos:

En esta fase se estima la magnitud del proyecto en términos de tamaño, costo, esfuerzo y cronograma. Se desarrollan los requisitos que satisfacen las necesidades del cliente.

En esta fase se verifica la factibilidad de las estimaciones a partir de los datos históricos, PSMD proveerá los medios para realizar estimaciones a partir de mediciones históricas.

También es importante en esta fase la evaluación de la factibilidad de los planes.

PSMD permitirá realizar verificaciones de factibilidad de planes de proyectos mediante la comparación de los datos del plan con las mediciones históricas disponibles para proyectos comparables.

• Desarrollo


Página 16

En esta fase el foco se orienta a evaluar si el desempeño es el previsto en los planes.

La fase de desarrollo se divide en cuatro actividades: Análisis de requisitos, diseño, implementación e Integración y prueba.

o Análisis de requisitos: en esta actividad los temas de mayor importancia son el tamaño y la estabilidad del producto. Es importante planificar y realizar revisiones técnicas con el objeto de asegurar la calidad de los requisitos.

o En las fases de diseño e implementación el foco está en el progreso del cronograma, calidad del producto y efectividad de la tecnología. Es importante continuar con la medición del tamaño y la estabilidad del producto. La posibilidad de realizar mediciones en esta fase depende de la definición de actividades discretas de diseño e implementación.

o Durante la integración y las pruebas, el foco del proyecto está la condición del producto para su liberación (readiness) y la satisfacción del cliente. Estas actividades se realizan en intervalos de tiempo cortos, por lo que es necesario ajustar la frecuencia de colección de datos en consecuencia.

PSM permitirá ajustar la frecuencia de colección para cada medición permitiendo establecer una frecuencia mayor en fases de corta duración como el testing.

• Operación y Mantenimiento

En esta fase continua el foco en el aspecto de Calidad del Producto. Las actividades de operación y mantenimiento pueden ser realizadas por la misma empresa que desarrollo el producto, o pueden ser subcontratadas.

PSMD soportará la operación multi-compañía, lo que permitirá su empleo en un contexto de outsourcing, por ejemplo en los casos de subcontratación de testing o actividades de operación y mantenimiento realizadas por subcontratistas.

o Operación: En esta actividad las mediciones relevantes se refieren a la disponibilidad y el rendimiento técnico.

o Mantenimiento: En esta actividad las mediciones relevantes se refieren a la disponibilidad y el rendimiento técnico.

Se diferencian dos tipos de actividades de mantenimiento:

o Mejoras mayores: Adaptación del producto a cambios tecnológicos o estratégicos. Estos cambios son generalmente manejados como nuevos proyectos de desarrollo, incluyendo todas las fases de análisis de requisitos, diseño, implementación, e integración y pruebas

o Mantenimiento básico: Pequeñas mejoras y solución de problemas, en esta fase los pedidos de cambio y resolución de problemas son tratados en forma independiente, a diferencia del desarrollo, donde son agrupados mediante la planificación.

Por este motivo los objetivos y mediciones necesarias son substancialmente diferentes. En el mantenimiento básico un indicador importante es la cantidad de cambios o problemas sin resolver, con relación al esfuerzo mientras que en el desarrollo es importante relacionar el esfuerzo con el progreso del análisis de requisitos, diseño e implementación, en el mantenimiento el esfuerzo se asocia a los pedidos de cambio y solución de problemas.


Página 17

Típicamente el ciclo de vida de las actividades de mantenimiento incluye tres fases: análisis, planificación del release e implementación, que comprende tareas de diseño, codificación y test.

3.1.1.4 Contexto organizacional y empresario Es habitual que múltiples proyectos tengan características similares, y por lo tanto necesidades de información similares. Si bien PSM focaliza en proyectos específicos, pueden lograrse importantes reducciones de costos cuando el sistema de mediciones se aplica a grupos de proyectos o a todo el programa de proyectos.

Además, la aplicación de las mediciones a grupos de proyecto, o a la totalidad del programa, permite la elaboración de mediciones e indicadores globales, de mayor utilidad para realizar un análisis a nivel organizacional.

Como se observa en la Figura 2 existen issues que son propios de la organización y por lo tanto aplican a todos los proyectos, también hay issues que aplican a grupos o clases de proyectos, en último lugar existen issues que son particulares de cada proyecto.

Issues Organizacionales y de Proyectos

Figura 2

De cada uno de estos tres niveles de issues se derivan diferentes requisitos de mediciones, que aplican en forma selectiva a cada proyecto.

PSMD permitirá la agrupación de proyectos, y su tratamiento en tres niveles

o Proyectos individuales o Grupos de proyectos (Por ejemplo los proyectos del dominio

“entretenimiento”, los proyectos de “misión crítica” o “desarrollos para eventos”)

o Programa de proyectos, incluyendo todos los proyectos en curso.

También permitirá la asignación de Issues y requisito de mediciones a los tres niveles de agrupación de proyectos mencionados.

PSMD permitirá la elaboración de indicadores para los tres niveles de agrupamiento mencionados:

o Indicadores exclusivos de un proyecto. o Indicadores correspondientes a una clase de proyecto. o Indicadores correspondientes a todo el programa de proyectos.

Proyecto C

Proyecto B

Issues Proyecto B

Issues d Proyecto B

Issues Empresarios y

Organizacionales

Issues del Proyecto A

Requerimientos Empresarios y

Organizacionales

Requerimientos Recurrentes de

Proyectos

Requerimientos Específicos del

Proyecto A

Proyecto C

Proyecto B

Mediciones Integradas del

Proyecto A


Página 18

3.1.2 Parte 2: Adaptación de las Mediciones

3.1.2.1 Visión general de la adaptación El objetivo de la adaptación es definir un conjunto de mediciones que provean la mayor comprensión de los issues del proyecto al menor costo. Un plan de mediciones documenta los resultados de esta actividad.

En PSM se definen los Issues como obstáculos conocidos o potenciales que pueden afectar el logro de los objetivos del proyecto. En 3.1.2.2.1 (Identificación de Issues) se definen los Issues con mayor detalle.

Los Issues son factores determinantes para todo el proceso de medición, a partir de estos Issues de determina que mediciones seleccionar, y que decisiones los gerentes deben tomar.

PSM provee un método sistemático para identificar los issues de cada proyecto, seleccionar y especificar mediciones específicas e integrarlas a los procesos técnicos y de gestión del proyecto que se describe en la Figura 3.

Figura 3

El proceso consta de 3 actividades:

• Identificación y priorización de issues específicos del proyecto:

Los issues son derivados de información de contexto del proyecto, experiencia de la gerencia, y resultados de actividades de evaluación de riesgos.

• Selección y especificación de las mediciones adecuadas para tratar los issues específicos del proyecto:

Para realizar esta medición se emplea un framework definido por PSM que mapea los issues del proyecto con áreas comunes de issues, categorías de mediciones y mediciones.

Identificar y Priorizar

Issues del Proyecto

Características del Proyecto

Necesidades de Información

Acciones de Mejora

Seleccionar y especificar mediciones del proyecto

Integrar en los procesos técnicos y de gestión

Planes de gestión de riesgo y de gestión financiera

Nuevos Issues

Características del Proceso

Cambios Propuestos

Cambios Propuestos

Plan de Mediciones


Página 19

• Integración de las mediciones los procesos técnicos y de gestión:

Luego de evaluar la adecuación y el impacto de las mediciones en los proyectos, se elabora un plan de mediciones, este plan puede ser informal o formal, y puede ser un documento autónomo o integrarse a otros planes tales como el Plan de Proyecto o el Plan de desarrollo de Software. Este proceso es iterativo, y es una buena práctica revisar el plan de mediciones cuando la prioridad de los issues cambie significativamente, o cuando se presenten nuevos issues de relevancia.

A continuación se describen cada una de estas actividades y se derivan los requisitos de PSM Dashboard su propósito de facilitar la implementación de un programa de mediciones basado en PSM.

3.1.2.2 Identificar y Priorizar los Issues del proyecto Un proceso de mediciones efectivo ayuda al gerente de proyecto a identificar riesgos o problemas que pueden impactar negativamente en los resultados del proyecto.

Este proceso consta de tres actividades:

• Identificar Issues

• Mapear Issues

• Priorizar Issues

3.1.2.2.1 Identificación de Issues Las evaluaciones de riesgo de los proyectos son actividades claves para la identificación de Issues.º

La mayoría de los proyectos cuentan desde su comienzo con objetivos, estos pueden ser definidos por la dirección de la empresa o definidos por el gerente de proyecto a partir de los requisitos de los diferentes stakeholders y del contexto del negocio, estos objetivos se expresan generalmente en términos de restricciones presupuestarias, cumplimiento de hitos críticos, niveles de calidad, desempeño general esperado. El éxito del proyecto depende del cumplimiento de estos objetivos.

PSMD permitirá registrar los objetivos de cada proyecto.

Los Issues del proyecto son áreas de preocupación que pueden impactar el logro de los objetivos del proyecto, estos Issues pueden clasificarse como sigue:

• Problemas: Un evento existente, o con certeza de su próxima ocurrencia que puede afectar negativamente en los objetivos del proyecto.

• Riesgos: Eventos potenciales cuya ocurrencia puede afectar negativamente en los objetivos del proyecto.

• Falta de información: Un área donde la información disponible es inadecuada o incompleta, y no permite predecir el éxito el cumplimiento de los objetivos del proyecto.

PSMD permitirá registrar los issues asociados a cada proyecto, se podrná asociar los issues con los objetivos del proyecto. Los riesgos y problemas podrán cargarse manualmente, o mediante la vinculación con los registros de riesgos y problemas de las herramientas de gestión de proyectos.

Análisis de riesgos:

La gestión de riesgos del proyecto incluye su identificación, análisis, priorización, y la previsión de acciones de mitigación y contingencia.


Página 20

El análisis de riesgos permite determinar la probabilidad, impacto y exposición asociados de ocurrencia de cada riesgo.

Probabilidad: Que tan probable es que el riesgo resulte un problema

Impacto: Si el problema ocurre, qué impacto tendrá sobre los resultados del proyecto?

Exposición: Se calcula como el producto de la probabilidad por el impacto, y es la magnitud que se emplea para priorizar los riesgos.

PSMD asociará a cada riesgo los siguientes atributos: probabilidad, impacto y exposición, calculada como el producto de la probabilidad por el impacto . Los valores de estas magnitudes pueden ser cargados manualmente, o mediante la vinculación con los registros de riesgos del sistema de gestión de proyectos.

PSMD asumirá por defecto una escala de 0 a 1.0 para la probabilidad y de 1 a 10 para el impacto. Mediante el menú de administración se podrán modificar estas escalas (por ejemplo probabilidad e impacto de 0.1 a 1.0, de 1 a 5, de 1 a 10, ó de 1% a 100%) PSMD realizará la conversión de las escalas de probabilidad e impacto del sistema de gestión de proyectos al de PSMD

Consolidación de issues:

Dado que los issues se componen de riesgos y problemas, es necesario establecer una magnitud que permita consolidarlos y priorizarlos en forma conjunta. PSM propone darle a los problemas una probabilidad igual a uno, con lo que su exposición es igual al impacto del problema.

PSMD permitirá asignar a cada problema un valor de impacto de acuerdo a lo definido en el párrafo anterior. Para los problemas el valor de probabilidad será igual a uno, y el valor de exposición será igual al impacto.

PSMD generará una lista de issues mediante la consolidación de los riesgos y problemas mencionados.

Priorización de issues

Dado que los proyectos de software y sistemas presentan numerosos issues, estos deben ser priorizados para asegurar que el proceso de mediciones focaliza en aquellos de mayor impacto en el logro de los objetivos del proyecto.

Mediante la consolidación de los riesgos y problemas del proyecto y el ordenamiento de esta lista de acuerdo a valores decrecientes del valor de la exposición, es posible realizar la priorización de los issues, de manera de focalizar en los mas importantes.

PSMD ordenará la lista de issues de acuerdo al valor de la exposición, en forma decreciente, y contará con las siguientes herramientas para focalizar en los issues mas importantes, por ejemplo mostrando solo los N principales issues (por ejemplo los principales 5 o 10 issues) o aquellos que superen un umbral exposición predeterminado (por ejemplo exposición > 5.0). Se podrá marcar los Issues que serán considerados (issues activos) en forma automatica (usando los criterios mencionados anteriormente) o en forma manual.

3.1.2.3 Seleccionar y especificar las mediciones del proyecto

Este proceso consiste en seleccionar las mejores mediciones para tratar los issues del proyecto identificados, y consta de tres actividades:

• Identificar la categoría de medición

• Seleccionar las mediciones aplicables

• Especificar las mediciones


Página 21

Proceso de selección de mediciones:

PSM facilita la selección de mediciones mediante el siguiente proceso de asociación:

Figura 4

Áreas de Issue Comunes: PSM define siete áreas de issue (áreas de preocupación) comunes, los issues específicos del proyecto son correlacionados (mapeados) con las áreas de issue comunes al comienzo de la tarea de selección de mediciones.

Categorías de mediciones: Las categorías de mediciones conforman grupos de mediciones correlacionadas. Las mediciones que pertenecen a una categoría proveen información similar, y responden preguntas similares.

Mediciones: Se dispone de varias mediciones para cada issue específico de un proyecto, una medición es la cuantificación de una característica de un producto o un proceso, en 3.1.3 (Selección y especificación de mediciones) se detalla el proceso de selección de mediciones.

Una vez identificados los issues (3.1.2.2.1, Identificación de Issues), el primer paso es determinar cuál es el área de issues que mejor se asocia a cada issue.

El paso siguiente es seleccionar una de las categorías de mediciones correspondientes al área de issue elegida. Una forma de elegir la categoría de medición es considerar cuales son las preguntas que la medición debe responder, la Tabla 1 provee las preguntas típicas que son respondidas por cada categoría de medición y permite elegir las categorías de mediciones que mejor se alinean con los issues específicos del proyecto.

En “3.1.3 Selección y especificación de mediciones” se describen especificaciones detalladas de cada categoría de medición, para disponer de toda la información necesaria para decidir la categoría de medición a elegir.

Issues Específicos

Áreas de Issues

Comunes

Categorías de

Mediciones Mediciones


Página 22

Área de Issue

Categoría de medición

Preguntas típicas

Crono-grama y progreso

Desempeño de hitos ¿El proyecto está cumpliendo con los hitos planificados? ¿Hay desplazamientos en las fechas programadas?

Progreso de unidades de trabajo

¿Como están progresando las actividades y los productos?

Capacidad incremental

¿La capacidad esta siendo entregada en la forma programada, mediante builds y releases incrementales?

Recursos y Costo

Personal ¿El esfuerzo se está realizando de acuerdo al plan?

Desempeño financiero

¿Los gastos del proyecto cumplen con los objetivos del presupuesto y del cronograma?

Recursos de soporte y ambientes

¿Están las facilidades necesarias, equipos y materiales disponibles?

Tamaño y estabilidad del producto

Tamaño físico y estabilidad

¿En qué medida están cambiando el tamaño del producto, su contenido, características físicas o interfases?

Tamaño funcional y estabilidad

¿En que medida están cambiando los requisitos y su funcionalidad asociada?

Calidad del producto

Correctitud funcional ¿Es el producto suficientemente bueno para ser entregado al cliente? ¿Están identificados los problemas sin resolver?

Mantenibilidad, Soportabilidad

¿Cuánto mantenimiento requiere el sistema? ¿Que tan difícil es mantenerlo?

Eficiencia ¿El sistema realiza un uso eficiente de los recursos?

Portabilidad ¿En que medida se puede re instalar las funcionalidades en diferentes plataformas?

Usabilidad ¿Es la interfase de usuario adecuada y apropiada para su operación? ¿Los errores que cometen los usuarios se encuentran dentro de los límites aceptables?

Fiabilidad ¿Con que frecuencia se interrumpe el servicio? ¿Las tasas de fallas se encuentran de límites tolerables?

Desempeño del proceso

Cumplimiento del proceso

¿Que tan consistentemente el proyecto implementa los procesos definidos?

Eficiencia del proceso ¿Son los procesos suficientemente eficientes para cumplir con los compromisos actuales y los objetivos planificados?

Efectividad del proceso

¿Cuanto esfuerzo adicional hay que realizar para actividades de retrabajo?

Efectividad de la tecnología

Adecuación de la tecnología

¿Permite la tecnología empleada satisfacer los requisitos, o se requiere el empleo de tecnología adicional?

Impacto ¿Se logró el impacto esperado de la tecnología empleada?

Volatilidad de la tecnología

¿Nuevas tecnologías empleadas tienen riesgos de cambios demasiado frecuentes?

Satisfacción del cliente

Feedback del cliente ¿Se cumplen las expectativas del cliente? Soporte al cliente ¿Con que frecuencia los clientes requieren soporte?

Tabla 1


Página 23

PSMD permitirá realizar la asociación de issues del proyecto con areas de issues y categorías de medición (Tabla 1) de acuerdo con el siguiente proceso:

Establecer Issues activos, esta activación puede realizarse en forma automática, mediante los criterios prioridad explicados anteriormente, manualmente, o en forma mixta.

Asignar un Área de Issue correspondiente a cada Issue

Elegir la categoría de medición aplicable de acuerdo con la Figura 5, PSMD mostrará las categorías de medición aplicables a cada Issue y las preguntas respondidas por cada categoría.

Selección de mediciones aplicables:

Una vez determinada la categoría de medición correspondiente a cada issue del proyecto, se seleccionan las mediciones que se emplearán durante el proyecto.

Es importante limitar la cantidad de mediciones a emplear y seleccionar el mejor grupo de mediciones considerando los siguientes criterios:

• Efectividad de la medición: ¿Que tan efectiva es la medición para lograr la comprensión deseada? ¿Es una medición directa del proceso o del producto? ¿La medición provee comprensión de más de un issue?

• Características del dominio: ¿Es la mejor medición para el dominio en cuestión?

• Prácticas de gerenciamiento de proyectos: ¿Es posible aprovechar prácticas de gerenciamiento de proyectos existentes para soportar el proceso de medición? Por ejemplo la existencia de un sistema de manejo de cronogramas, o los requisitos de información de un modelo de estimaciones.

• Costo y disponibilidad: ¿Que datos están disponibles?, ¿Cuál es el esfuerzo necesario para extraer y consolidar los datos para su análisis? La colección automática de datos usualmente es menos costosa que la colección manual.

• Cobertura del ciclo de vida: ¿La medición aplica a la fase bajo consideración? ¿La medición aplica a múltiples fases?

• Requisitos externos: ¿la organización ha establecido un conjunto de mediciones aplicables en forma estándar a todos los proyectos?

• Tamaño del proyecto o del producto desarrollado: ¿El tamaño del proyecto justifica una mayor inversión en mediciones?

La selección es en general un compromiso entre diferentes criterios

PSMD incluirá un Help Contextual con los criterios a emplear para seleccionar mediciones.

PSMD permitirá asignar una o más mediciones a cada issue activo

Especificación de mediciones

Una vez que las mediciones fueron seleccionadas, una cantidad de detalles para cada medición debe ser especificada.

Las especificaciones de las mediciones pueden formar parte de un contrato o acuerdo en un contexto de cliente - subcontratista de desarrollo.

En todos los casos una correcta especificación de las mediciones contribuye a una comunicación eficaz entre todos los involucrados.

Las especificaciones se documentan mediante las Tablas de Especificación explicadas en 3.1.3

Los ítems incluidos en las especificaciones son los siguientes:


Página 24

• Ítems de Datos: El primer paso para la especificación de una medición es definir los ítems de datos a recolectar.

• Atributos: Los atributos son propiedades o características de de las entidades que están siendo medidas. Por ejemplo la versión del sistema medido o la prioridad de un problema. Los atributos son útiles para ordenar y correlacionar ítems de datos.

• Estructura de Agregación: Los datos son en general recolectados a un nivel de detalle bajo dentro del proyecto, para poder obtener información significativa es necesario consolidar esta información mediante diferentes criterios de agrupamiento que definen la estructura de agregación. Estos criterios de agregación pueden ser: o Estructuras de agregación basada en componentes: Estas estructuras

consideran la relación entre los componentes de un sistema y su arquitectura. Ejemplos: cálculo del tamaño de un sistema a partir del tamaño de sus componentes.

o Estructuras de agregación basada en funcionalidades: Consisten en una descomposición funcional de los requisitos del sistema. Ejemplo: Número de requisitos probados.

o Estructuras de agregación basada en actividades: Este criterio se relaciona con la estructura de actividades del proyecto, por ejemplo las horas empleadas en las actividades de análisis de requisitos, diseño, implementación, etc. Esta estructura se define en general en la WBS del proyecto (Work Breakdown Structure).

Los atributos y la estructura de agregación deben corresponderse.

• Nivel de recolección: El nivel de detalle al que se recolecta la información debe ser el necesario para poder aislar y entender problemas.

La determinación del nivel de detalle es un compromiso entre el costo de la recolección de los datos, y la información brindada por los mismos para lograr una adecuada comprensión de los issues del proyecto.

• Criterio de conteo: Para cada medición debe establecerse cuando un ítem de dato es contado.

Por ejemplo si se cuenta la cantidad de requisitos aprobados, “aprobado” puede definirse mediante la aprobación de QC en el workflow de test.

PSMD incluirá los siguientes campos, necesarios para la especificación de las mediciones:

Ítems de Datos

Atributos

Estructura de Agregación

Nivel de recolección

Colectores aplicables: Para obtener los datos de las fuentes

Workflows aplicable: Para cumplir con el “Criterio de conteo”

Schedules aplicables: Para definir la periodicidad

Sin bien PSM establece una secuencia estructurada para adaptar el programa de mediciones a las características y necesidades de información de cada proyecto. En los de proyectos existentes, se debe prestar una atención especial a la identificación de oportunidades de medición existentes. La documentación y especificación de mediciones debe realizarse a partir de la identificación de estas oportunidades existentes.


Página 25

3.1.2.4 Integración en los procesos técnicos y de gestión La integración del proceso de medición con los procesos técnicos y de gestión representan el cómo implementar un proceso de mediciones

La integración consta de 3 actividades:

• Caracterización del ambiente.

• Identificación de oportunidades de mediciones.

• Especificación de requisitos de la implementación de mediciones.

El resultado de este proceso es el Plan de Mediciones, que documenta el enfoque previsto para la realización de las mediciones.

Caracterización del Ambiente

La decisión sobre el conjunto de mediciones a adoptar no puede basarse únicamente en las necesidades de información, sino que también deben considerarse los procesos técnicos y de gestión, ya que estos determinan que datos pueden ser recolectados y de qué manera se realizará la recolección.

Se mencionan algunos factores a considerar:

• El ciclo de vida del proyecto o la estructura de actividades empleada.

• La estructura del producto final, incluyendo incrementos definidos y trabajos de terceros.

• Actividades de medición existentes empleadas.

• Tecnología de software y de sistemas, incluyendo técnicas de diseño, lenguajes de programación y herramientas usadas.

• Origen de componentes de software y hardware, tales como enlatados, software nuevo o reusado.

• Prácticas de gerenciamiento, coordinación, revisiones, test e inspección.

• Estándares de ingeniería y gerenciamiento a ser aplicados.

• Madurez de los procesos de la organización.

• Organización de los proyectos y estructura de los equipos.

Siempre que sea posible se deben emplear las prácticas y los mecanismos de recolección de datos existentes, minimizando los requisitos de nuevas mediciones.

3.1.2.4.1 Identificar Oportunidades de Medición Es importante priorizar la identificación y el aprovechamiento de los mecanismos de medición en uso, esto aumentará las posibilidades de éxito del programa de mediciones, considerando las ventajas de la familiaridad y los menores costos que este aprovechamiento significa.

Los datos de las mediciones pueden provenir potencialmente de diversas fuentes, se debe prestar especial atención a las bases de datos y herramientas que soportan el Gerenciamiento de Proyecto, el aseguramiento de calidad, el testing y la gestión de la configuración.

Tres formas primarias de datos son:

• Datos históricos: provenientes de proyectos pasados.

• Datos de planificación: presupuestos y cronogramas previstos.

• Datos del desempeño actual: por ejemplo problemas, defectos, horas incurridas, requisitos completados, cambios y avance.


Página 26

PSMD incluirá los medios necesarios para evaluar la facilidad / dificultad de obtener los datos necesarios para las mediciones elegidas, esta evaluación se realizará considerando los siguientes criterios:

Medición en uso?

Ítems de datos

- Posibilidad de recolección automática?

- Calidad y disponibilidad de los datos?

Estos aspectos serán valorados en una escala de 1 a 10, y se obtendrá un score de ambiente, calculada como promedio de los criterios mencionados. Por ejemplo

Medición en

uso Recolección. Automática

Calidad y Disponibilidad

de datos

Score de ambiente

Medición # 1 10 0 5 5

Medición # 2 10 10 7 9

Medición # 3 0 8 10 6

Medición # 4 0 6 6 4

Tabla 2

Para decidir que mediciones serán incluidas en el plan de mediciones, PSMD presentará un listado de mediciones incluyendo el valor de exposición del issue, tal como se mencionó en 3.1.2.2.1, y un score de la medición que considera el ambiente y la importancia del issue, por ejemplo:

Score de ambiente

Prioridad del issue

Score medición

Medición # 1 5 9 4.5


Medición # 3 6 10 6.0


Tabla 3

De este análisis puede surgir la decisión de incluir las mediciones 2 y 3, y eliminar la 1 y la 4, siguiendo de esta forma un criterio difieren del que se hubiera empleado si solamente se priorizara según la exposición de los issues.

Estas priorización es en todos los casos una guía que ayuda a tomar la decisión sin olvidar aspectos importantes, pero en todos los casos la selección del conjunto de mediciones será una decisión de los gerentes de proyecto y técnicos.

PSMD Permitirá seleccionar las mediciones que integran el programa de mediciones, se incluirá un campo para registrar los criterios empleados para decidir la inclusión o exclusión de mediciones en el programa, por ejemplo:

• No se incluye la medicion#1 debido al elevado costo del proceso manual de recolección de datos.

• La medición # 3 se incluye porque brinda la información necesaria para realizar un seguimiento del issue “i”, si bien esta medición no se está realizando, se dispone con datos de calidad, y se puede establecer fácilmente un mecanismo de recolección automática.


Página 27

• La medición # 4 se incluye porque esta información es importante para evitar multas previstas en el contrato.

• La medición # 7 se incluye porque la normativa de la casa central establece que un indicador basado en esta medición se incluya en los reportes mensuales.

3.1.2.4.2 Especificación de los requisitos de las mediciones Para completar la actividad de adaptación, y antes de comenzar con la implementación del programa de mediciones, es necesario documentar los procedimientos para recolectar y procesar los datos.

Esta definición focaliza en los siguientes ítems:

• Definición de las mediciones: Se documenta la especificación de las mediciones como se explicó en 3.1.2.3.

• Alcance de las mediciones: Si bien algunas mediciones se aplican en todas las actividades (por ejemplo el esfuerzo), la mayoría tiene un alcance limitado. Se debe documentar a que actividades, fases del ciclo de vida y sectores aplica la medición.

• Recolección de datos:

o Fuente de información

o Proceso de extracción de la medición

o Repositorio para almacenar la información extraída

o Responsabilidad para realizar la medición

o Periodicidad

o Herramientas y Bases de Datos Involucradas

• Análisis de datos

o Indicadores generados a partir de la medición

o Proceso para generar los indicadores

o Periodicidad y responsabilidad para realizar el análisis

o Reporte de resultados

o Descripción de los reportes a ser generados

o Responsabilidad para la emisión de reportes

o Formato

o Audiencia de cada reporte

Evaluación de las mediciones

El proceso de mediciones y las mediciones mismas deben ser evaluados periódicamente. Habitualmente esta revisión se realiza con una periodicidad anual o trimestral.

PSMD Incluirá las siguientes funciones para la especificación de las mediciones:

• Definición de las mediciones, incluyendo todas las características descriptas en 3.1.2.4.2

• Flujo de trabajo (Workflow) para establecer secuencias de recolección de mediciones, elaboración de indicadores, análisis y reporte. Los workflows incluirán tanto tareas automáticas (como la extracción de datos y almacenamiento en un repositorio de mediciones), como tareas manuales tales como el análisis. Para la realización de estas últimas el workflow emitirá mails o asignará tareas, y permitirá establecer


Página 28

timeouts con escalamiento para limitar el tiempo de las tareas manuales.

Los workflows podrán iniciarse mediante por los siguientes métodos:

• Manualmente

• Por eventos: Por ejemplo cuando una medición supera un umbral

• En forma programada, mediante el Scheduler

Plan de Mediciones

Las especificaciones de las mediciones son documentadas mediante un plan de mediciones. Este plan puede ser formal o informal. Se muestra un ejemplo del contenido de un plan de mediciones típico:

Parte 1 – Introducción:

Propósito y alcance.

Parte 2 – Descripción del proyecto:

Características técnicas y de gerenciamiento del proyecto.

Parte 3 – Roles de mediciones, Responsabilidades y Comunicación:

Integración del plan de mediciones con los procesos técnicos y de gerenciamiento del proyecto. (3.1.2.4.1, Identificar Oportunidades de Medición).

Puntos de contacto relacionados con las mediciones (Cliente, Proveedor, Subcontratistas).

Responsabilidades de Mediciones (En PSM Dashboard está previsto resolverlo mediante Workflows).

Comunicaciones e Interfaces Organizativas (Workflow).

Herramientas y Bases de Datos.

Implementación en fases.

Criterios de Evaluación.

Parte 4 – Descripción de los Issues del proyecto:

Objetivos e Issues de la Organización.

Lista de Issues y Objetivos priorizados.

Parte 5 – Especificación de las mediciones.

Incluir para cada medición:

Nombre de la medición.

Issue especifico del proyecto con el que mapea la medición.

Ítems de datos.

Atributos.

Estructuras de Agregación.

Criterio de conteo.

Definición de los datos.

Metodología de estimación, Modelos y Datos Históricos.

Mecanismos de recolección y reporte.

Origen de los datos.

Periodicidad de recolección y reporte.

Fases y Actividades aplicables.


Página 29

Parte 6 – Estructuras de agregación del proyecto

Estructuras de agregación por componentes: Ítems de configuración, Unidades.

Estructura de agregación por actividades, tales como requisitos, análisis, diseño, implementación y integración y prueba.

Estructura de agregación funcional.

Parte 7 – Indicadores iniciales:

Incluir para cada indicador:

Nombre del indicador.

Issue específico del proyecto al que mapea el indicador.

Mediciones empleadas para construir el indicador.

Formato de muestra.

Interpretación y decisiones relacionadas con el indicador.

Parte 8 – Mecanismos de reporte y periodicidad:

PSMD elaborará el plan de mediciones a partir de las definiciones realizadas para cada proyecto, grupo o programa de proyectos, el plan tiene en cuenta todas las definiciones realizadas para para las mediciones, indicadores, dashboards, workflows y schedules.

El plan de mediciones podrá ser consultado en pantalla con el formato mostrado en esta sección, o exportado a formatos RTF o PDF empleando una plantilla con el formato definido en esta sección, o empleando plantillas definidas por el usuario.

Requisitos del Plan de Mediciones:

Capacidad de establecer versiones del plan de mediciones mediante versiones que registran todas las definiciones que conforman el plan (Líneas de Base).

Capacidad de exportar versiones del plan de mediciones a formatos de documentos RTF y PDF.

Empleo de plantillas: PSM Dashboard contará con un conjunto de plantillas estándar y permitirá al usuario crear nuevas, tanto para

Planes de medición autónomos como para planes de medición que se integran en otros planes (por ejemplo el Plan de Proyecto)

Los planes de proyecto podrán ser revisados formalmente, en estas revisiones se incrementará la versión del plan, se registrarán los nombres de los revisores y se ejecutará un workflow de aprobación.


Página 30

3.1.3 Parte 3: Selección y especificación de mediciones

3.1.3.1 Uso de las Tablas de Medición Las tablas de selección y especificación de mediciones de PSM establecen relaciones directas entre issues del proyecto, necesidades de información, y las mediciones que brindan la información necesaria.

PSM documenta esta relación mediante la tabla mostrada en la Tabla 4 la relación entre Áreas de Issue comunes y sus mediciones relacionadas agrupadas por categoría de medición.

La estructura de las tablas de medición descriptas en el capítulo 3 de PSM sigue el criterio de la Tabla I-C-M mostrada en la Figura 8.

Tabla I-C-M

Mapeo Issue – Categoría – Medición

Área de Issue Categoría de Medición Medición

Cronograma y Progreso

Desempeño de Hitos Fechas de Hitos

Desempeño del Camino Crítico

Progreso de las unidades de trabajo

Estado de los Requisitos

Estado de la resolución de Problemas

Estado de revisiones

Estado de los pedidos de cambio

Estado de los componentes

Estado de las pruebas

Estado de los ítems de acción

Capacidad Incremental Contenido Incremental: Componentes

Contenido Incremental: Funciones

Recursos y Costo Personal Esfuerzo

Experiencia del Personal

Rotación del personal

Desempeño Financiero Valor Ganado

Costo

Recursos de ambiente y soporte

Disponibilidad de Recursos

Utilización de Recursos

Tabla 4


Página 31

Tabla I-C-M, Continuación

Mapeo Issue – Categoría – Medición

Tamaño y Estabilidad del Producto

Tamaño y Estabilidad Física

Tamaño de la Base de Datos

Componentes

Interfases

Lineas de Código

Dimensiones Físicas

Tamaño y Estabilidad Funcional

Requisitos

Carga de Trabajo por Cambios Funcionales

Puntos de Función

Calidad del Producto

Correctitud Funcional Defectos

Desempeño técnico

Soportabilidad, Mantenibilidad

Tiempo de recuperación

Complejidad Ciclomática

Acciones de Mantenimiento

Eficiencia Utilización

Rendimiento

Temporización

Portabilidad Cumplimiento de Estándares

Usabilidad Errores de operación

Dependabilidad, Confiabilidad

Fallas

Tolerancia a fallas

Desempeño del proceso

Conformidad del proceso Clasificación del Modelo de Referencia

Hallazgos de Auditorías

Eficiencia del proceso Productividad

Tiempo de Ciclo

Efectividad del proceso Contención de defectos

Retrabado

Efectividad de la tecnología

Adecuación de la Tecnología

Cobertura de requisitos

Impacto Impacto de la Tecnología

Volatilidad de la tecnología

Cambios en la Línea de Base

Satisfacción del Cliente

Realimentación del Cliente

Resultado de encuestas

Calificación del desempeño

Soporte al Cliente Pedidos de soporte

Tiempo de soporte

Tabla 4 , continuación


Página 32

PSMD incluirá una tabla incluyendo las relaciones entre Área de Issue, Categoría de Mediciones y Mediciones detalladas en la Tabla 4

3.1.3.1.1 Especificación de categorías de mediciones La especificación de categorías de mediciones se realiza mediante la definición de los siguientes aspectos:

• Categoría de Medición y área de issue correspondiente.

• Definición y descripción: Descripción de los tipos de mediciones incluidos en la categoría y uso de la información que estas mediciones proveen.

• Proyectos de aplicación: Información de los tipos de proyectos a los que la categoría de medición aplica, incluyendo tamaños de proyectos y dominios.

• Mediciones incluidas en la categoría.

• Limitaciones.

• Categorías de medición relacionadas: Referencia a otras categorías de medición de PSM que pueden ser usadas conjuntamente con las mediciones de esta categoría para poder realizar un análisis más completo.

• Información adicional.

• Ejemplos de indicadores: Ejemplos de indicadores específicos detallados en la parte 5 de PSM, estos indicadores estarán relacionados con las mediciones incluidas en las categorías.

PSMD incluirá tablas para definición de categorías de mediciones con la estructura de datos descripta en esta sección, se incluirán las descripciones de campos detalladas como ayudas contextuales.

3.1.3.1.2 Tablas de especificación de mediciones Las tablas de especificación de mediciones incluyen dos tipos de información: la guía de selección que se emplea para determinar si la medición va a tratar efectivamente los issues en cuestión, y la guía de especificación que detalla los datos específicos necesarios para implementar la medición.

Se detalla la información que contienen las especificaciones de mediciones en ambas secciones.

Guía de Selección:

• Proyectos de aplicación: Esta información ayuda a determinar los tipos de proyectos a los que la medición aplica, incluyendo el dominio funcional, tamaño, tipo y origen (Software nuevo, reusado o enlatado). También se considera si se trata de aplicaciones en tiempo real, transaccionales o con empleo intensivo de datos. También se identifica el uso de la medición en aplicaciones de gobierno e industria.

• Integración del proceso: Esta sección ayuda a determinar la aplicabilidad de la medición a los procesos de gestión del proyecto y gestión técnica. La sección considera la disponibilidad y costo de obtención de los datos y otras características del proceso. Se incluyen consideraciones de Ingeniería de Software o Ingeniería de Sistemas.

• Usualmente aplicado durante: Esta información define la aplicabilidad de la medición a los procesos y actividades del proyecto incluyendo la planificación, el análisis de requisitos, la integración y pruebas, y finalmente la operación y el mantenimiento.

Guía de especificación


Página 33

• Esta información permite establecer los requisitos para la implementación de la medición:

• Ítems de datos típicos: Los datos que usualmente son medidos y recolectados, son los valores fundamentales para realizar la medición, por ejemplo la medición de esfuerzo incluye el ítem de datos “Cantidad de Horas de Trabajo”.

• Atributos típicos: Información relativa a los ítems de datos empleada para ordenar y correlacionar los datos del proyecto, por ejemplo la cantidad de horas de trabajo tiene como atributos el sector, el tipo de actividad o el incremento.

• Estructura de agregación típica: Estructura mediante la cual los datos son organizados y acumulados a un nivel de proyecto. Las estructuras de agregación pueden basarse en:

o Actividades: tales como análisis de requisitos, diseño, etc.

o Ítems de Configuración

o Funciones

• Típicamente recolectado por cada… : El nivel de actividad o de componente al que típicamente se recolectan los ítems de tatos correspondientes a la medición. Este aspecto es un nivel específico de recolección en relación con la la estructura de agregación definida. Por ejemplo si se establece una estructura de agregación por componentes, los datos pueden ser recolectados para cada componente.

• Ítems de datos, información adicional (opcional): En esta parte se incluye mayor información para especificar los ítems de datos para la medición.

• Contar valores reales basados en: Actividades o criterios de salida típicos para considerar los componentes de datos, por ejemplo “Los requisitos se consideran completados cuando han concluido el test exitosamente, e ingresan en el control de la configuración”

• Esta medición responde preguntas tales como: Preguntas típicas que la medición puede responder.

PSMD incluirá tablas para definición de mediciones con la estructura de datos descripta en esta sección, se incluirán las descripciones de campos detalladas como ayudas contextuales

3.1.3.2 Selección detallada de mediciones

3.1.3.2.1 Especificación general de mediciones Los requisitos que se detallan son aplicables a todas las mediciones:

Tipos de datos: Definición si los datos corresponden a planes, planes modificados o valores reales. Los planes y las estimaciones deben ser actualizados regularmente.

PSMD almacenará datos reales del proyecto, y datos correspondiente a la planificación, para poder diferenciar los datos correspondientes a diferentes planificaciones, PSMD incluirá un esquema de versionado de planes mediante Lineas de base (LB1, LB2,….).

Fechas de los datos: Para cada medición debe registrarse la fecha en que los datos son recolectados y la fecha en que son reportados.

PSMD Asociará a cada dato la fecha de recolección de las mediciones.

Organización: Si más de una organización está involucrada en el proyecto, es necesario identificar la fuente de cada medición.


Página 34

PSMD Asociará a cada dato la Organización de origen

Fase del proyecto: Se debe registrar la fase del ciclo de vida del proyecto que corresponde a cada medición: incluyendo planeamiento, desarrollo, y operación y mantenimiento.

PSMD Asociará a cada dato la Fase del Ciclo de Vida del Proyecto.

Periodicidad de recolección: La recolección debe realizarse periódicamente, (no en base a eventos) La mayoría de los proyectos recolectan los datos mensualmente, pero la frecuencia puede variarse para adaptarse a las restricciones y características de cada proyecto.

PSMD permitirá definir la frecuencia de medición de cada medición mediante un programa (schedule), PSMD realizará la recolección con la frecuencia prevista en el programa.

Reporte de datos: Identificar los mecanismos de reporte de datos para entregar los datos a la Oficina de Proyectos. Se deberán realizar esfuerzos para que los datos sean reportados electrónicamente en forma periódica.

PSMD reportará las mediciones electrónicamente y en forma periódica

3.1.3.2.2 Especificación de mediciones y categorías. La parte 2 del capitulo 3 de la guia PSM incluye una librería con la especificación de las Categorías de mediciones y de las mediciones listadas la Tabla 4 (tabla ICM).

PSMD incluirá una librería de las categorías de mediciones y mediciones incluidas en la tabla ICM, basada en las definiciones incluidas en el capítulo 3, parte 2 de la guía PSM versión 4.0b

3.1.3.3 Adaptación de Áreas de Issue, Categorías y mediciones. Las categorías de mediciones y las mediciones incluidas en la tabla ICM se han elaborado a partir de una experiencia muy extensa en áreas de gobierno e industria, y cubren las necesidades de información que de la mayoría de los proyectos.

De todas maneras, la tabla ICM es un punto de partida, y durante el proceso de adaptación pueden ser necesarias otras mediciones.

El proceso PSM admite la modificación de la tabla ICM y la definición de nuevas mediciones, o las modificaciones de las definiciones de las mediciones especificadas por el proceso PSM. Estos cambios pueden ser necesarios en las siguientes situaciones:

• El enfoque PSM se está aplicando fuera de su alcance previsto (Software e Ingeniería de Sistemas) o para propósitos diferentes que la gestión de proyectos.

• El dominio, la tecnología, o los issues específicos del proyecto hacen necesario el desarrollo de nuevas mediciones.

• Patrones recurrentes de issues comunes, categorías y mediciones son reconocidas y la organización decide formalizarlas.

PSMD permitirá la adaptación de la librería de mediciones de PSM a las necesidades de la empresa mediante las siguientes acciones:

Agregado de nuevas Áreas de Issues

Agregado de nuevas categorías de mediciones (en este caso se especificará de acuerdo a lo detallado en 3.1.3.1.1). La nueva categoría se vinculará a un área de issue existente o agregada.


Página 35

Agregado de nuevas mediciones, La nueva medición se vinculará a una categoría existente o agregada.

Modificación de la especificación de mediciones existentes en PSM.

3.1.4 Parte 4: Aplicación De Las Mediciones

3.1.4.1 Visión general de la aplicación de las mediciones El proceso de medición debe responder rápidamente a las necesidades de información de los gerentes de proyecto, incluyendo las siguientes preguntas:

• ¿Puedo confiar en los datos?

• ¿Realmente hay un problema?

• ¿Qué tan grande es el riesgo?

• ¿Cuál es el alcance del problema?

• ¿Qué es lo que causa este problema?

• ¿Hay otros riesgos relacionados?

• ¿Cuáles son las alternativas?

• ¿Cuál es la mejor solución?

• ¿Cuándo se puede esperar ver los resultados?

La actividad “Aplicar Mediciones” debe generar respuestas a estas preguntas

Cuando el análisis sigue un procedimiento definido y repetible es más probable que los resultados sean creíbles, completos y confiables.

PSM presenta la actividad de análisis bajo tres perspectivas:

1. Un modelo de relaciones entre issues que guía el análisis. 2. Indicadores que presentan información de mediciones acerca de los issues para su

mejor análisis. 3. los tres tipos de análisis que pueden realizarse: Estimación, factibilidad y

desempeño.

La actividad “Aplicar Mediciones” convierte los datos de las mediciones en información que se relaciona directamente con los issues del proyecto. La Figura 6muestra sus tres principales tareas: Recolección, procesamiento y análisis de las mediciones.

Figura 5

Recolectar y Procesar Datos

Plan de Mediciones

Analizar Issues

Realizar Recomen-daciones

Medición de desempeño del proceso de medición

Información

Preguntas

Resultados del Análisis

Datos

Gestión de Riesgos y Desempeño Financiero

Nuevos Issues

Características del Proyecto


Página 36

3.1.4.2 Recolección y procesamiento de datos La recolección de datos válidos es el fundamento de todo el proceso de medición, esta actividad se subdivide en tres partes:

• Recolectar datos

• Verificar datos

• Normalizar datos

3.1.4.2.1 Recolección de datos La especificación de la recolección de datos se realiza durante la fase de adaptación y se documenta por medio del plan de mediciones.

El plan incluye también información sobre el acceso a los datos, su disponibilidad y su formato y su origen (por medios electrónicos o fuentes convencionales)

El acceso a los datos puede darse por medio de los siguientes mecanismos:

• Acceso compartido y directo: El analista de mediciones accede directamente a la información

• Copias electrónicas de archivos o bases de datos: El equipo de proyecto realiza regularmente copias de la información y se las entrega al analista de mediciones. El analista de mediciones debe contar con las herramientas necesarias para leer e interpretar estos archivos.

• Exportaciones de datos: Cada período de reporte el equipo de proyecto exporta datos de cada fuente de datos en un formato estándar (por ejemplo ASCII) El analista de mediciones importa los datos.

• Copias en papel: En cada periodo de reporte el analista de mediciones importa los datos en papel y los ingresa manualmente en el sistema de mediciones

El acceso compartido y directo es el mecanismo de acceso preferido.

PSMD se basa en el acceso directo a información compartida, para esto contará con colectores para poder extraer datos de las fuentes mas populares de información, proveerá además las herramientas para desarrollar colectores para extraer datos de cualquier fuente de información

En PSMD el proceso de recolección de datos es automático, sin requerirse la participación del analista de mediciones en esta tarea, pero permitirá la carga manual para situaciones extraordinarias, y para los valores planeados, en los casos en que estos no estén disponibles.

El equipo de proyecto puede recolectar los datos con una frecuencia superior a la que el analista de mediciones realiza el análisis. La frecuencia más habitual es la mensual para las actividades de requisitos, diseño e implementación, y semanal para las actividades de integración y test. En proyectos cortos con enfoques incrementales se adopta también un esquema semanal. Además cuando se aproxima un hito clave, puede ser necesario un reporte más frecuente.

Para poder realizar la verificación es muy importante que cada dato esté acompañado por la siguiente información de contexto:

• Fecha.

• Sistema de origen.

• Organización o sector.

• Unidad de medición (por ejemplo horas, días o meses).


Página 37

PSMD incluirá un programador (scheduler) que permitirá programar (entre otras) las tareas de recolección automatica de datos. La programación se relizará con los siguientes criterios:

Frecuencia: Por ejemplo semanal, mensual

Criterios: Por ejemplo entre el comienzo y el fin del testing, o desde el comienzo de la elaboración de requisitos hasta la aceptación por el cliente.

Combinación de frecuencia y criterios: Por ejemplo semanalmente durante el diseño.

3.1.4.2.2 Verificación de datos Los datos deben ser verificados para asegurar su exactitud, ya que todo el proceso de mediciones depende de su calidad.

La siguiente tabla incluye un check list con algunos criterios de verificación.

Check List de verificación de datos

1 Extensión de los datos:

• ¿Los datos corresponden al proyecto en cuestión?

• ¿Los datos corresponden al cronograma?

2 Estructuras de agregación y atributos

• ¿Son valores en los campos consistentes en diferentes registros? (por ejemplo clasificación de defectos, identificadores de componentes, identificadores de ítems de configuración, etc.)

• ¿Son los valores consistentes a través de diferentes equipos, sectores u organizaciones?.

3 Unidades de medición

• ¿Se emplean las mismas unidades de medición a través de diferentes equipos u organizaciones, por ejemplo horas versus días de trabajo, o SLOC versus KSLOC?

4 Contenido de los ítems de datos

• ¿Están los valores fuera de límites aceptables?

• ¿Es el formato incorrecto?, por ejemplo el tipo de dato o la cantidad de decimales.

5 Completitud de los datos

• ¿Se cuenta con la información para cada issue?

• ¿Hay datos faltantes?

• ¿Los datos recolectados son los previstos?

6 Cambios a los datos existentes

• ¿Los planes han cambiado en forma imprevista?

• ¿Los cambios a los valores planeados representan una re planificación mayor?

• ¿Los valores reales cambiaron en forma imprevista?

7 ¿Los datos se ven demasiado uniformes?

Tabla 5


Página 38

Mediante la herramienta de workflow de PSMD se establecerá la verificación de los datos posterior a su recolección, esta verificación podrá realizarse en forma automática o con intervención del analista de mediciones.

Verificación automática: Mediante un generador de reglas de verificación PSMD verificará automáticamente la calidad de los datos, las reglas pueden establecerse a partir del check list de la Tabla 5, o mediante verificaciones agregadas resultantes de Lecciones Aprendidas en mediciones anteriores. Un ejemplo de una regla es “La cantidad de horas trabajada por cada persona no puede ser inferior a 8hs” para el personal efectivo ni menor que 6 horas para los pasantes.

Verificación asistida: el workflow de verificación incluye un paso en el que se solicita al analista de mediciones la verificación de un conjunto de datos, este requisito puede realizarse después de la verificación automática e incluir sus resultados, para agilizar la tarea de verificación asistida.

3.1.4.2.3 Normalización de datos Antes de que los datos puedan ser analizados es necesaria su normalización, para que lograr la uniformidad de unidades que permita su comparación o combinación con otros datos, por ejemplo:

• Convertir el esfuerzo de un equipo de horas a meses para que pueda ser sumado al esfuerzo de otro equipo contado en meses.

• Convertir las actividades del ciclo de vida de un subcontratista para que sean coherentes con las del contratista principal y poder combinar o comprar el esfuerzo por actividad.

PSMD incluirá tablas de conversión de unidades, esta conversión podrá ser aritmética o nominal

Conversión aritmética: Meses hombre <- Horas Hombre / 160

Conversión nominal: Requisitos <- Especificación

3.1.4.3 Análisis de Issues Durante la tarea Analizar Issues, los datos son convertidos en información que es empleada por los gerentes para tomar decisiones. El foco del análisis cambia en la medida que el proyecto evoluciona, la Figura 6 muestra los diferentes tipos de análisis que pueden realizarse con sus inputs y outputs

Figura 6

Datos y características del Proyecto

Información y nuevos Issues

Estimación Análisis de factibilidad

Datos del Proyecto Datos históricos

Estimaciones Falta de Información

Planes

RiesgosAlternativas

Planes Valores Reales

Análisis de Desempeño

Estado del ProyectoProblemas


Página 39

Al comienzo del proyecto el foco se coloca en la estimación como soporte a la planificación. La estimación establece valores objetivos para el tamaño, el esfuerzo y el cronograma. La estimación se basa en datos históricos y en suposiciones sobre el proyecto y los productos. En la estimación también se identifican incertidumbres por falta de información que dan origen a nuevos issues. La estimación debe realizarse al comienzo de la planificación, y en cada re planificación.

Cuando se completa la planificación el foco se desplaza al análisis de factibilidad. Este tipo de análisis determina si el plan de proyecto y sus objetivos son realistas y se pueden lograr. El análisis de factibilidad emplea información histórica, experiencia, y pruebas de consistencia para la evaluación del plan de proyecto. Los riesgos identificados durante el análisis se incluyen en la gestión de riesgos del proyecto. El análisis de factibilidad también debe realizarse cuando se re planifica el proyecto.

Una vez que el proyecto comenzó, el análisis de desempeño es la principal preocupación. El análisis de desempeño verifica si los valores reales del proyecto cumplen con los planes, suposiciones y objetivos. Las entradas para este análisis son los datos planificados y los datos reales. En este análisis se identifican riesgos, problemas, y acciones correctivas. El análisis de desempeño debe realizase regularmente.

PSMD permitirá programar los diferentes análisis que serán realizados durante el proyecto, mediante su programador (scheduler) y el generador de workflows

3.1.4.3.1 Conceptos generales del análisis Los indicadores son los componentes principales del análisis de las mediciones, en PSM un indicador se define como una medición o un conjunto de mediciones que provee(n) comprensión sobre un aspecto o issue del proyecto.

Los indicadores son en general representados en forma de gráficos o tablas. Los issues importantes son tratados en general por múltiples indicadores y en muchos casos los indicadores están basados en múltiples mediciones.

El enfoque de PSM enfatiza en que la recolección de datos se realice a bajo nivel, de esta manera se podrán elaborar muchos indicadores útiles a partir de estos datos.

El analista de mediciones puede combinar y presentar los datos medidos en muchas formas diferentes, dependiendo de lo que la situación que el proyecto requiera. Esto permite mayor flexibilidad en el análisis de issues críticos, y en la adaptación del sistema de mediciones para analizar los nuevos issues que vayan surgiendo durante el proyecto. Un sistema basado en la entrega periódica de gráficos predefinidos no contaría con esta flexibilidad.

Estos conceptos de recolección de datos a bajo nivel de agregación (alto nivel de detalles) y flexibilidad para realizar mediciones que permitan atender diferentes necesidades de información a lo largo del proyecto, fundamentan la implementación de PSM Dashboard como un sistema de Business Intelligence

Los Dashboards de PSMD pueden ser configurados para atender las necesidades de información y los issues de cada proyecto o grupo de proyectos.

Conceptos básicos sobre indicadores

Para ser efectivos los indicadores deben presentar los datos en un formato que facilite una clara interpretación de los datos, los indicadores deben estar diseñados para:

• Proveer la información necesaria

• Soportar el tipo de análisis necesario (Estimación, factibilidad y desempeño)

• Proveer el nivel de detalle apropiado

• Proveer información puntual para tomar decisiones y realizar acciones.


Página 40

En la mayoría de los casos los datos reales son comparados con los datos esperados, es decir, los valores previstos durante la estimación

PSMD permitirá la carga de los datos de planificación del proyecto mediante los siguientes métodos:

Carga manual de valores planificados

Extracción de datos de sistemas de planificación de proyectos.

Además, es necesario contar con criterios para poder decidir si la diferencia entre los valores reales y planificados es significativa

PSMD permitirá definir para cada indicador criterios para definir colores de semáforos a partir de la comparación de los valores reales con los valores planeados.

Los criterios para determinar los colores de los semáforos pueden basarse en técnicas estadísticas como por ejemplo las definidas por el control estadístico de procesos (SPC)

Se contará con una presentación del color del semáforo en el Dashboard principal para la fecha actual o para una fecha pasada.

Los indicadores incluirán en la parte superior una barra que mostrará la evolución del color del semáforo.

Se podrá disparar una alerta a partir del estado de un semáforo de un indicador para, por ejemplo, notificar mediante un e-mail al gerente de proyecto y al líder técnico si el cumplimiento de hitos está en color rojo.

Por lo tanto los indicadores de PSM se componen de las siguientes partes:

• Un valor real de la medición, o combinación de mediciones.

• El valor planeado para la medición.

• El criterio de decisión.

La Figura 7 muestra un ejemplo de indicador, en la que se incluye la evolución de un semáforo generado a partir de criterios predefinidos

Figura 7


Página 41

Modelo de Análisis estructurado (MAE)

Los indicadores ayudan a comprender los issues de los proyectos. Es importante notar que los issues no son independientes unos de otros. Con el objeto de definir las relaciones existentes entre issues individuales, PSM establece el Modelo de Análisis estructurado mostrado en la Figura 8. Este modelo establece las relaciones entre las aéreas de issue comunes de PSM y establece un escenario para definir indicadores de mediciones adecuadas para actividades de análisis.

Modelo de análisis estructurado (MAE) a nivel de issues

Figura 8

Cada una de las flechas de la figura representa una relación causal entre áreas de issues, por ejemplo si cambia el tamaño de un producto, esto tendrá impacto sobre el esfuerzo necesario.

Las flechas hacia abajo muestran relaciones de causa-consecuencia, es decir, si se observa un problema en indicadores que están más arriba (por ejemplo tamaño) es una alerta temprana de futuros problemas en indicadores que se encuentran más abajo (por ejemplo esfuerzo). Las decisiones que se tomen para mejorar los indicadores que se encuentran mas arriba (causa) tendrán también efectos positivos sobre los indicadores que están más abajo (consecuencia)

La Figura 9muestra una versión más detallada del modelo de análisis en la que cada área de issues se subdivide en categorías de mediciones.

Efectividad de la Tecnología

Desempeño del Proceso

Tamaño y esta-bilidad del Producto

Recursos y Costo





Página 42

Modelo de análisis estructurado (MAE) a nivel de Categorías de Medición

Figura 9

Las relaciones mostradas en el modelo de la Figura 9 fueron identificadas con círculos numerados:

1. El tamaño funcional representa la cantidad de funcionalidad que un sistema debe proveer. Esto es usualmente determinado por los requisitos. El tamaño funcional es el principal determinante del tamaño físico (La cantidad de software que será desarrollado y mantenido)

2. El impacto y la volatilidad de cualquier nueva tecnología también influye en el tamaño. Las tecnologías más innovadoras tienden a minimizar la cantidad de nuevos productos que deben ser implementados para una función determinada, pero si la nueva tecnología adoptada no brinda las soluciones previstas, su impacto será negativo, ya que será necesario implementar más de lo planeado.

3. El incremento en el tamaño del producto habitualmente requiere mayor personal y esfuerzo



Impacto

Cronograma y progreso

Cumplimiento de hitos

Progreso de uni-dades de trabajo

Capacidad Incremental

Tamaño del producto y estabilidad



1 2

Desempeño Financiero

Ambiente y soporte

Personal (Esfuerzo)

3 4

Recursos y costo

9

5

4


Soporte al Cliente

Feedback del cliente

10

10

Eficiencia Confiabilidad Usabilidad Portabilidad Correctitud Funcional

Soportabilidad Mantenibilidad


6

4

10

7

8



Eficiencia del proceso



Página 43

4. El desempeño del proceso afecta la necesidad de recursos, e influye sobre el cronograma de desarrollo y la calidad del producto. Una organización con mayor nivel de capacidad conseguirá mejores realizaciones, considerando que los otros factores se mantienen constantes.

5. El agregado de más personal influye en el cronograma y en el progreso del proyecto, si se incorpora en una fase temprana personal adecuadamente entrenado, se lograrán acortar los plazos, pero si se incorporan en forma tardía recursos sin la preparación necesaria, esto producirá mayores retrasos, dado que parte del esfuerzo del equipo de trabajo se derivará en su preparación.

6. Las dificultades en el cumplimiento del cronograma causan problemas de calidad ya que habitualmente, con el objetivo de cumplir con los plazos en un proyecto atrasado, se recorta el esfuerzo de testing. Los defectos de mayor prioridad se resuelven, mientras que los otros permanecen en el producto.

7. Los problemas latentes de calidad requieren mayor cantidad de desarrollo para la corrección, o para preparar nuevas liberaciones aceptables para los usuarios.

8. El retrabajo para corrección de defectos, o para preparar nuevas liberaciones, hace que el esfuerzo dedicado al proyecto sea superior al planificado.

9. En la mayoría de los proyectos en los que el desarrollo de software es un componente principal, el esfuerzo empleado es el principal determinante del costo del proyecto.

10. La cantidad de recursos, el cumplimiento del cronograma y la calidad del producto impactan en la satisfacción del cliente.

PSMD permitirá la inclusión, para cada proyecto, grupo de proyectos o para todo el programa de proyectos, del indicador MAE (Modelo de Análisis Estructurado) para representar gráficamente el estado y la relación causal de las diferentes áreas de Issue comunes y categorías de mediciones de un proyecto

El MAE presentará a cada área de issue con un color diferente, dependiendo del estado de los indicadores relacionados con las mediciones correspondientes a esta área, a partir de los criterios definidos para estos indicadores, como se explicó en “Conceptos básicos sobre indicadores”

El código de colores adoptado para mostrar el estado de cada área es:

• Celeste:1) En el Plan de Mediciones no se incluyeron mediciones sobre esta área o 2) Las mediciones fueron planificadas, pero corresponden a una fase futura (por ejemplo Satisfacción del Cliente durante la planificación)

• Verde: Los indicadores se encuentran dentro de valores aceptables

• Amarillo: Los indicadores no se encuentran dentro de valores aceptables y al menos un indicador correspondiente al área se encuentra en estado amarillo de acuerdo con los criterios establecidos para dicho indicador.

• Rojo: Los indicadores no se encuentran dentro de valores aceptables y al menos un indicador correspondiente al área se encuentra en estado rojo de acuerdo con los criterios establecidos para dicho indicador.


Página 44

Se podrá visualizar el MAE para un rango de fechas, PSMD presentará la evolución de los semáforos, por ejemplo:

En la Figura 10 se muestra un ejemplo del MAE de issues con semáforos que permiten identificar el estado de un proyecto:

Presentación de semáforos en el MAE de áreas

Figura 10

En este ejemplo no se mide la efectividad de la tecnología porque se emplean la misma tecnología y lenguajes de programación que en proyectos anteriores.

Tampoco se presentan indicadores sobre Calidad del Producto ni Satisfacción del Cliente porque el proyecto se encuentra promediando la fase de Desarrollo, y si bien estas mediciones se encuentran planificadas, No se prevé en el plan incluir estas mediciones en esta fase, ya que no se registran datos para estas áreas.

El ejemplo muestra que se ha detectado una alarma mayor en el desempeño del proceso y una media en Recursos y Costos, mas adelante se continuará con este ejemplo para mostrar de que manera PSM Dashboard brinda toda la información para realizar el análisis necesario para detectar las causas de los problemas, y tomar oportunamente las acciones correctivas necesarias para su resolución mediante la profundización del análisis (Drill Down).

04/07 05/07 06/07 07/07 08/07

Recursos y Costos




Tamaño y estabilidad del Producto

Recursos y Costos




Página 45

PSMD permitirá ampliar el nivel de detalle sobre el estado de un proyecto, mediante el “Modelo de análisis estructurado a nivel de Categorías de Medición (MAE de categorías)”

MAE de categorías

Figura 11

Figura 11 brinda información mas específica para el análisis del proceso y permite apreciar que si bien los procesos definidos han demostrado ser efectivos y eficiente, se ha observado que el personal incorporado mas recientemente, si bien ha recibido debida capacitación, aun no logra cumplir con los procesos ni utilizar efectivamente herramientas que simplifican su trabajo, lo que implica mayores esfuerzos y por lo tanto mayores costos, si bien hasta la fecha ha sido posible cumplir con los hitos del proyecto.



Impacto



Eficiencia del proceso


Cronograma y progreso

Cumplimiento de hitos

Progreso de unidades de

Capacidad Incremental

Tamaño del producto y estabilidad

Tamaño funcional



Ambiente y soporte

Personal (Esfuerzo) Recursos

y costo


Soporte al Cliente

Feedback del cliente


Eficiencia Confiabilidad Usabilidad Portabilidad Correctitud Funcional

Soportabilidad Mantenibilidad


Página 46

Para contar con la información al mayor nivel de detalle PSMD presentará en los diagramas MAE de áreas o MAE de categorías links a los indicadores mediante el ícono:

Por ejemplo:

Figura 12

Seleccionando con el puntero del Mouse el ícono de la categoría “Cumpli-miento del proceso” del Modelo de Análisis Estructurado (MAE), se accede al indicador “Hallazgos de Auditorías” que presenta mayor detalle sobre esta medición.

Lo mismo ocurre con el indicador de esfuerzo mostrado a continuación.

Figura 13

En el caso en que haya más de un indicador para una determinada categoría, PSMD permitirá seleccionar el o los indicadores que se presentarán.

El acceso a los indicadores mediante el Modelo de Análisis Estructurado es una forma de acceder a la visualización del conjunto de indicadores gestionados por PSM Dashboard. El acceso mediante el MAE ofrece las ventajas de partir de una visión global de los procesos, e ir aumentando el nivel de detalle en la medida que sea necesario (Drill down), otra ventaja es que presenta una interrelación causal entre los diferentes procesos, lo que significa una gran ayuda para comprender la causa de los desvíos, y lo que es aun mas importante, poder prevenir futuros desvíos mediante acciones oportunas.


Página 47

PSM Dashboard permitirá realizar modificaciones y agregados en la definición de areas de issue y categorías de mediciones, como se explicó en 3.1.3.3 (Adaptación de Áreas de Issue, Categorías y mediciones)

Al agregarse áreas y categorías, se definirán las relaciones causales con las demás áreas y categorías, de esta manera PSMD pueda presentar el Modelo de Análisis Estructurado (MAE) de áreas e issues modificado, incluyendo la representación de las relaciones causales de estas modificaciones.

3.1.4.3.2 Estimación La estimación es un tipo de análisis de mediciones usado para establecer valores objetivos o expectativas numéricas que permiten predecir actividades de proyectos que están por realizarse, a partir de datos históricos disponibles.

PSMD almacenará datos de mediciones históricas de proyectos para y presentará esta información en forma gráfica para asistir el proceso de estimación.

Las estimaciones típicamente producen proyecciones de tamaño de productos, esfuerzo y plazos para completar un proyecto. Las estimaciones pueden también producir proyecciones de calidad del producto.

Estas estimaciones forman la base de de proyecciones para realizar los planes del proyecto y subsecuentes re planificaciones.

El proceso de estimación es de una importancia fundamental, ya que justifica la realización de un proyecto, su financiación y la posibilidad de comprometerse a completar el trabajo en determinadas fechas.

Las estimaciones realizadas en fases muy tempranas del proyecto son en general imprecisas debido a la falta de información, por lo que este proceso debe ser repetido en la medida que se cuente con mas y mejor información.

Las estimaciones pobres o la falta de comprensión sobre la importancia del proceso de estimación llevan en general a proyectos fallidos o cancelados, pérdidas económicas e incumplimientos de plazos.

Las estimaciones pobres se deben en general a los siguientes factores:

• Falta de datos históricos.

• Falta de experiencia en la realización de estimaciones.

• Falta de un proceso sistemático de estimaciones, y de técnicas y modelos de estimación adecuados.

• Expectativas o suposiciones no realistas

• Fallas en el tratamiento de la incertidumbre inherente a las estimaciones en proyectos.

El modelo de análisis estructurado (MAE) descrito anteriormente, puede emplearse efectivamente para realizar estimaciones si se lo emplea con suficiente cantidad de información histórica relevante.

Estimadores:

El objeto de una estimación es predecir el valor de una medición a partir de otra. En la estimación se emplean tipos especiales de indicadores llamados Estimadores, los estimadores muestran una relación histórica entre dos mediciones, y esta correlación se emplea con fines predictivos. Por ejemplo un estimador puede relacionar el tamaño de una aplicación con el esfuerzo necesario para su desarrollo. En general los estimadores son válidos dentro de un determinado dominio o para una determinada tecnología.


Página 48

Ejemplos de estimadores:

• Tamaño funcional para predecir el tamaño físico

• Tamaño funcional para predecir el esfuerzo

• Tamaño físico para predecir el esfuerzo

• Esfuerzo para predecir plazos

• Esfuerzo para predecir costos

• Tamaño del producto para predecir cantidad de problemas (defectos)

PSMD permitirá la elaboración de estimadores que permitan predecir una medición a partir de otra.

PSMD contará con un grupo de estimadores predefinidos en el párrafo anterior, y permitirá la elaboración de otros estimadores

Los estimadores presentarán información histórica de proyectos empleando los siguientes filtros:

Tecnología (Java, .NET, lenguajes de 4ª generación)

Dominio

Tipo de proyecto

Se podrá acceder a los estimadores desde los diagramas MAE, por medio del

icono , por ejemplo:

Figura 14

Estimaciones: la guía PSM realiza en la última parte de la sección 3.2 del capítulo 4 (Estimation Task) y en las secciones 3.2.1, 3.2.2, 3.2.3 y 3.2.4 una descripción muy completa del proceso de estimaciones propuesta por PSM.

No se incluyen entre los requisitos de PSMD funcionalidades relacionadas con el proceso de estimación, ya que se encuentra fuera de su alcance (PSMD no es una herramienta de estimación). Pero si se incluyen las funcionalidades mencionadas anteriormente (estimadores), ya que siendo PSMD el principal repositorio de mediciones históricas de proyectos de desarrollo, la capacidad de presentar gráficamente esta información mediante los estimadores mencionados, hace de PSMD un recurso de suma utilidad durante el proceso de estimación.




Ambiente y soporte

Personal (Esfuerzo)


Página 49

3.1.4.3.3 Análisis de factibilidad El análisis de factibilidad evalúa el realismo de los planes. Las estimaciones se emplean para producir un plan, el análisis de factibilidad se emplea para confirmar este plan o para producir planes alternativos.

Para que un plan sea factible sus elementos particulares deben ser técnicamente realistas, logrables y consistentes unos con otros. La Figura 15 muestra un cronograma (diagrama de Gantt) que muestra una inconsistencia entre la demanda de esfuerzos mostrada en el cronograma (mayor entre Enero y Junio de 2009) y la disponibilidad de personal (decreciente a partir de febrero de 2009)

Figura 15

Cuando se realiza la evaluación de factibilidad de un proyecto, se debe focalizar en los issues de mayor importancia, PSM detalla algunos criterios para realizar la evaluación:

- ¿El solapamiento entre actividades es razonable a lo largo del cronograma?

- ¿La pendiente del progreso es razonable?

- ¿El desempeño previsto es consistente con el desempeño observado en proyectos pasados?

El análisis de factibilidad debe realizarse durante la planificación inicial y durante las siguientes circunstancias:

- El alcance ha cambiado.

- Las suposiciones tecnológicas u organizacionales han cambiado.

- El análisis de desempeño muestra que el plan no se cumple.

Indicadores de factibilidad:

En el análisis de factibilidad es importante la comparación entre:

- Diferentes aspectos de un plan.

- Valores de un plan vs. Datos históricos.

Se emplean dos tipos de indicadores para el análisis de factibilidad:


Página 50

- Basados en tendencias.

- Indicadores que incorporan umbrales

Las tendencias pueden representarse de dos formas:

- Valores acumulados.

- Perfil de valores (valores de cada momento o intervalo)

Los indicadores de PSMD permitirán la realización de análisis de factibilidad mediante las siguientes características:

Se podrán definir indicadores múltiples

Los indicadores permitirán la comparación de valores planificados de diferentes aspectos de un plan

Los indicadores permitirán comparar valores históricos con los valores planificados para un mismo aspecto, los valores históricos podrán ser filtrados por dominio o por tipo de proyecto para que la información sea comparable.

PSM incluirá indicadores acumulativos y de perfil de valores

Los indicadores pueden incluir umbrales u objetivos.

3.1.4.3.4 Análisis de desempeño Los indicadores de desempeño se clasifican en dos grupos, basados en como son graficados y analizados:

- Basados en tendencias.

- Indicadores que incorporan umbrales

La diferencia fundamental para el empleo de estos indicadores es si la expectativa se mantiene constante o cambia a través del tiempo

Los indicadores basados en tendencias se emplean cuando las expectativas cambian a lo largo del tiempo como se observa en la Figura 16, en donde la expectativa planeada para la cantidad de componentes terminados cambia cada semana, de acuerdo con el plan de proyecto.

Figura 16

En estos gráficos los valores reales son graficados conjuntamente con los valores planeados

El análisis de desempeño se realiza comparando los valores reales con los planeados.


Página 51

Los indicadores de desempeño basados en umbrales u objetivos se usan cuando los valores esperados permanecen aproximadamente constantes durante el proyecto, por ejemplo en la Figura 17 se muestra un indicador de desempeño cuyo umbral permanece constante, dado que es un objetivo del diseño. En la medida que el valor no supere el objetivo establecido por contrato, el desempeño es el adecuado.

Figura 17

Los límites pueden representar normas, valores esperados o restricciones del proyecto. En muchos casos estos umbrales constituyen Requisitos No Funcionales. Estos límites a menudo representan cantidad de defectos, tiempos de respuesta, niveles de utilización de recursos de la computadora (por ejemplo memoria) u objetivos de productividad.

PSMD orientará sus indicadores especialmente para el monitoreo de desempeño de proyectos, para esto podrá:

Presentar simultáneamente valores planeados y reales

Emplear indicadores basados en tendencias y en umbrales

Permitir el ingreso de los valores planeados correspondientes a las mediciones, estos valores planeados podrán ser:

1) Series temporales, que podrán ingresarse manualmente o mediante conectores con otros sistema de planificación

2) Umbrales u objetivos, en este caso se podrán establecer dos límites:

• Transición verde-amarillo

• Transición amarillo-rojo

Los criterios se establecerán límites en la diferencia entre el valor real y el planificado (serie o umbral fijo)

Los colores del indicador se emplearán para Establecer indicadores visuales con la evolución del indicador:

• Establecer semáforos con el estado del indicador

• Establecer el color de la categoría o área correspondiente en el diagrama MAE (modelo de análisis estructurado)


Página 52

• Disparar alertas o workflows de información para los indicadores mas críticos (Gestión por excepción)

Ejemplo de semáforos para representar el estado del indicador:

Figura 18

3.1.4.4 Realizar recomendaciones El propósito de las mediciones es ayudar a los gerentes de proyectos a tomar mejores decisiones.

La última tarea del proceso de Aplicación de Mediciones es reportar los resultados del análisis de las mediciones, conjuntamente con las correspondientes recomendaciones y la evaluación de alternativas.

El resultado de la análisis se resume en un ”Reporte de estado”, este reporte es parte del sistema de Gerenciamiento de Proyectos y en general incluye el estado de las mediciones, así como también el análisis de los issues y riesgos del proyecto.

PSMD con dos medios para informar el estado de las mediciones:

1) Dashboards con Indicadores, PSMD incluirá templates de uso frecuente

2) Reportes generados a partir de los dashboards. Los reportes podrán generarse como un documento independiente que resuma el estado de las mediciones y su correspondiente análisis, o como una parte del sistema de reportes de los proyectos. PSMD brindará templates para ambos casos.

Reporte de resultados

Los resultados del análisis deben ser comunicados regularmente al gerente de proyecto como un resumen, o mediante mensajes on line. El mecanismo de reporte debe establecer una interacción regular y una comunicación objetiva entre todos los participantes.

La comunicación debe incluir:

• Evaluación general del proyecto

0

200

400

600

800

1000

1200

1400

Ene‐07

Feb‐07

Mar‐07

Abr‐07

May‐07

Jun‐07

Jul‐0

7

Ago

‐07

Sep‐07

Oct‐07

Nov‐07

Dic‐07

Ene‐08

Horas Hom

bre

Esfuerzo

Planeado

Real

Proyecto: PSM Dashboard Datos al 06 / 11 / 2007

UCA,

• I

• R

• P

El reproyperió

Los compnuevlos d

Los na lasinfor

, Trabajo Fin

dentificació

Recomenda

Potenciales

eporte y la ecto, los ródicas del e

reportes departirá los vos eventosdatos,

niveles de ds recomenrmación tam

Ademásdocumenanálisis indicadoEstructu

Estas no

F

N

Is

D

R

M

El mecageneracide mediprogram

El analisworkflow

identifica

Mediantepublicadlos reponotas asprimerosaprobaci

Cada ve

que

observa la inform

nal Especializ

ón de probl

ciones

nuevos iss

revisión dereportes adestado del p

eben ser re resultadoss e informa

decisión nedaciones i

mbién se en

de la genntar los re

asociadasores) o a urado)

otas incluirá

Fecha de la

Nombre de

ssues invol

Descripción

Recomendac

Mecanismo

nismo de rión automáiciones. La

mas (schedu

sta de mew, realiza e

a mediante

e este sistdo en formaortes se gesociadas. Ess pasos la ión la aprob

ez que se i

permite u

en la Figumación corr

zación en Ing

emas espe

ues

e las medicdemás debproyecto.

evisados ins con el eqación cualit

ecesitan conncluidas encuentre de

neración desultados s a los I las aérea

án:

revisión

los revisore

lucrados

del análisis

ciones

de reporte

reporte serática de da periodicidaules).

ediciones rel análisis e

e el ícono

tema se loa on line coeneren aut

Es muy imp participacibación.

incluye una

una present

ura 19. Medrespondient

geniería de S

cíficos, ries

ciones debeben ser em

nicialmentequipo de ptativa que

nocer comon el informebidamente

de reportesdel análisi

Indicadoresas o categ

es

s

rá controlaahboards y ad de estas

recibe unae incluye su

.

ogra que eon los indicatomáticameortante queión del equ

a nota de a

tación cont

diante la sete al análisi

Software

sgos y falta

en estar intmpleados co

e por el anaroyecto, es ayudan a

o se llegó ame, por ese document

s, PSMD cois de las s, a los gorías del

ado por un luego el ans actividad

solicitu dus comenta

el resultadadores, dasente mediae el workflouipo de des

análisis se

textual de

elección deis.

a de informa

tegrados coomo “input

alista de msta revisióninterpretar

a los resultaso, es imptada.

ontará conmedicionesDashboard MAE (Mo

workflow nálisis por

des está de

de análisis arios en los

do del análshboards oante el barow de reposarrollo y l

identifica

estos come

l ícono

PSM Da

Págin

ación.

on el día at” para rev

mediciones n puede der y explica

ados del anportante qu

n la capacis como no

ds (Conjunodelo de A

y consistir parte del aeterminada

generada s Dashboard

lisis se en panel MAE

rrido de toorte incluyaluego una

mediante e

entarios, c

se accede

ashboard

a 53

día del visiones

, quien escubrir r mejor

nálisis y ue esta

idad de otas de ntos de Análisis

rá en la analista por los

por el ds y los

cuentre E, y que odas las a en sus fase de

el ícono

como se

e a toda

UCA,

3.1

3.1Un comp

La mu obanáli

Cuanprese

Dos

1

2

Los dato

Las rrealemás

, Trabajo Fin

Anotació

1.5 Pa

.5.1 Gindicador prensión so

mayoría de jetivos). Loisis.

ndo se diseentación se

tareas son

1. Identific

2. Definir e

indicadoress, hasta re

representaces con línea claramente

PSMD inLos indicde la me

2

4

6

8

10

12

14Horas Hom

bre

Proyect

nal Especializ

ón de come

rte 5: E

Generaces una m

obre un tem

los indicados indicado

eñan preseea clara y e

necesarias

car las med

el formato p

s pueden rpresentacio

ciones gráfas de basee que las ta

ncluirá el recadores poedición, cua

0

00

00

00

00

00

00

400

Ene‐07

Feb‐07

to: PSM Dash

zación en Ing

entarios en

Ejemplo

ción de Imedición oma o concep

ores compaores pueden

entaciones exacta.

s para defin

iciones esp

para la pres

representarones gráfica

ficas en gee, los gráficablas con n

egistro de mdrán represalquier com

Mar‐07

Abr‐07

May

07

hboard

geniería de S

PSM Dashb

Figura 1

os de In

Indicado una compto.

aran los van ser repre

de indicad

nir un indica

pecíficas y l

sentación d

rse de muas.

neral funciocos muestr

números.

múltiples línsentar, ade

mbinación d

May‐07

Jun‐07

Jul‐0

7

Esfuer

Software

board:

9

ndicado

ores mbinación d

alores realeesentados g

dores, es n

ador:

os ítems de

de estos íte

chas forma

onan mejoran tenden

neas de basemás de lo

de líneas de

Ago

‐07

Sep‐07

Oct‐07

rzo

ores

de medicio

es con líneagráficament

necesario a

e datos a m

ems de dato

as, desde

r cuando sncias, varia

se para los s valores r base de da

Nov‐07

Dic‐07

Ene‐08

Datos al

PSM Da

Págin

ones que

as de base te para fac

asegurarse

mostrar

os.

simples ta

e comparancias y rel

valores plareales de loatos planea

Plane

Real

06 / 11 / 20

ashboard

a 54

provee

(Planes ilitar su

que la

blas de

n datos aciones

aneados. os datos ados.

eado

007


Página 55

3.1.5.1.1 Técnicas de representación gráfica La selección de la técnica de representación gráfica adecuada es muy importante para representar de la manera más eficaz y pertinente los datos de las mediciones.

Existen múltiples técnicas de representación, pero las tres más frecuentemente usadas son los gráficos de líneas, los de barras y los de dispersión, los que se describen a continuación:

Gráficos de líneas:

Los gráficos de líneas representan series de datos mediciones a lo largo del tiempo, Estas series pueden contener los valores reales y los esperados. Cada valor en la serie es reportado para un instante de tiempo específico. Los valores son mostrados como puntos en el gráfico que son conectados mediante líneas que muestran progreso o tendencia. En el ejemplo de la Figura 20 se muestra un gráfico de líneas que muestra los valores acumulados reales y planificados del progreso de implementación de un desarrollo.

Figura 20

Gráficos de barras:

Los diagramas de barras representan la cuenta o frecuencia de un conjunto de indicadores o eventos, cada barra incluye información relativa a un grupo o clase..

Por ejemplo, el diagrama de la Figura 21 muestra la cantidad de hallazgos en auditoria por tipo.

Figura 21


Página 56

Gráficos de dispersión:

Estos diagramas se emplean para representar la interrelación entre dos factores mediante una serie de puntos.

El ejemplo de la Figura 22 muestra la relación entre el tamaño y el plazo para el la ejecución de proyectos de desarrollo. Se incluye una línea que representa la regresión lineal entre ambas variables.

Figura 22

Semáforos:

Se emplean para resumir el estado de una o múltiples mediciones simultáneas, el color representa el estado.

Los colores representan el desempeño en relación a un plan o criterio.

En el ejemplo de la Figura 23 el estado es indicado mediante el color de los semáforos:

• Una luz verde indica que el subsistema ha sido aceptado por el cliente

• Una luz amarilla indica no ha sido aun aceptado por el cliente, y no se anticipan problemas, o se cuenta con soluciones alternativas para los problemas conocidos.

• Una luz roja indica que el subsistema tiene problemas, o una alta probabilidad de que tenga problemas.

Figura 23


Página 57

PSMD incluirá indicadores consistentes en tablas, gráficos de líneas, de barras, de dispersión y de semáforos tal como se describe en la descripción precedente

Uso de indicadores como estimadores

Un estimador es un tipo especial de indicador que compara dos mediciones diferentes. Los valores de una medición se emplean para predecir los valores de la otra medición.

Los estimadores de PSM incluyen en general tres factores:

• El valor conocido es tomado como variable independiente (horizontal)

• El valor estimado o a predecir es la variable independiente (vertical)

• La incertidumbre asociada con la medición es una indicación del grado de confianza de la relación.

La Figura 24 muestra un estimador que en el que el tamaño del producto (eje horizontal) es empleado para predecir el esfuerzo necesario (eje vertical)

La linea de tendencia (diagonal en color negro) muestra la relación entre el tamaño y el esfuerzo. Se observa que hay un límite de confianza del 50% alrededor de esta línea, esto significa que el 95% de las veces, las relaciones entre el tamaño y el esfuerzo estarán dentro de este intervalo delimitado por las dos diagonales rojas.

Figura 24

PSMD Incluirá los estimadores definidos en la guía PSM y permitirá la elaboración de otros. También permitirá la delimitación gráfica de intervalos de confianza mediante el procesamiento estadístico del conjunto de valores del estimador.

Comunicación de información en indicadores

PSM Define una serie de recomendaciones para la elaboración de indicadores bien diseñados. Estas recomendaciones se derivan en requisitos de PSM Dashboard.

Los Indicadores de PSM Dashboard cumplirán con las siguientes características:

Inclusión de un título descriptivo para identificar el nombre del indicador, tipo de dato y componente (si aplicara) representado por el indicador.

Inclusión del nombre del proyecto o identificador único


Página 58

Los ejes deben incluir el nombre de las variables y las marcas, tales como fechas o valores.

Para gráficos que muestren tendencias temporales, incluir los principales hitos o eventos significativos que ocurren en el intervalo de tiempo presentado.

Limitar la cantidad de información mostrada en un único gráfico.

Incluir la fecha a la que corresponden los datos mediante una frase “Datos a…”

Identificar el origen de los datos

Identificar los ítems y tendencias significativos en los datos.

Otras recomendaciones para la elaboración de gráficos:

Para mostrar tendencias emplear tramos de rectas que unen puntos, mejor que ajuste de curvas.

Si es posible, rotular las líneas, barras y puntos directamente en el gráfico. En caso contrario emplee una clave que asocie los rótulos diferentes estilos de línea, barras o puntos.

Emplear las mismas convenciones para todos los gráficos, por ejemplo el mismo estilo para los valores reales de todos los gráficos, y otro estilo para los valores planeados de todos los gráficos.

Definir la finalización de los ejes para mostrar los rangos de datos esperados.

Al comparar dos indicadores en un gráfico, usar las mismas escalas en ambos gráficos.

3.1.5.2 Ejemplos de Indicadores En el capítulo 2 de la parte 5 de la guía PSM se describen ejemplos de indicadores correspondientes a las mediciones descriptas en los capítulos precedentes

Para la definición de estos indicadores se define la siguiente información:

• Nombre de la medición: El título del indicador correspondiente a la medición cuyos datos se emplean para elaborar el indicador.

• Categoría: La categoría de mediciones de PSM que mejor de relaciona con la necesidad de información

• Aplicabilidad: Si es apropiado para software o sistemas, o el tipo de proyectos a los que aplica.

• Guía de análisis y ejemplos: Si el indicador es empleado durante estimaciones, para analizar la factibilidad de un plan o el desempeño de un proyecto.

• Análisis adicional: Otros factores a tener en cuenta al usar estos indicadores.

• Lecciones Aprendidas: Experiencia de la industria en el uso del indicador y la medición asociada.

PSM mantendrá una librería de indicadores basada en los ejemplos de la Guía de PSM.

La guía PSM incluye en este capítulo una tabla con un conjunto de (Figura 5-11, Índice de ejemplos de indicadores) que menciona un conjunto de 67 indicadores correspondientes a 33 mediciones, en el resto del capítulo se describe mediante ejemplos por lo menos un indicador de cada una de estas mediciones. Se explica que este conjunto de indicadores no es definitivo y que pueden definirse otros dependiendo de las características de la empresa o de los proyectos


Página 59

Dentro del marco de PSM existen otras publicaciones que definen nuevos indicadores como el documento Systems Engineering Leading Indicators Guide [PSM et al. 07], este documento define un conjunto completo de indicadores para Ingeniería de sistemas

También, en el sitio http://www.psmsc.com/SampleMeasures.asp PSM especifica una cantidad de mediciones con sus correspondientes indicadores.

El producto PSMD incluirá una librería incluyendo los 67 indicadores definidos en la Figura 5-11 de la guia PSM

Los usuarios podrán modificar estos indicadores adaptándolos a sus necesidades específicas, o crear nuevos indicadores

Know Edge mantendrá un portal en los que se publicarán nuevos indicadores, tales como los que se incluyen en el documento Systems Engineering Leading Indicators Guide [PSM et al. 07], los publicados en http://www.psmsc.com/SampleMeasures.asp, o aquellos nuevos indicadores que se definan en publicaciones vinculadas con las actividades realizadas por miembros de PSM. Estos indicadores estarán clasificados como se detalló al comienzo de esta sección. Los usuarios del producto PSMD podrán bajar estos indicadores a su aplicación desde el portal de Know Edge, con el objeto de actualizar la aplicación y disponer de los indicadores que mas se adecuan a sus necesidades

3.1.5.3 Ejemplos de Indicadores Integrados Para el análisis de determinadas situaciones o escenarios, puede ser necesario incluir en un gráfico mas de una medicion.

La Figura 5-45 incluye un índice de indicadores integrados

La tabla de indicadores definida en 3.1.5.2 incluirá los indicadores múltiples definidos en la tabla de la figura 5-45 de la guía PSM. PSMD permitirá asignar mas de una medición a un indicador como un método para la definición de los escenarios correspondientes a los indicadores múltiples.

La librería de indicadores de PSMD incluirá 24 los 67 indicadores integrados definidos en la Figura 5-11 de la guía PSM


Página 60

3.1.6 Parte 6: Implementación Del Proceso En este capítulo se describen las actividades necesarias para una implementación efectiva de un programa de mediciones basado en PSM. Los aspectos a considerar son similares a los que se deben considerar en la implementación de cualquier iniciativa

3.1.6.1 Visión general del proceso Los aspectos a considerar son similares a los que se deben considerar en la implementación de cualquier iniciativa, e incluye los pasos mostrados en la Figura 25.

Figura 25

El objetivo de la primer tarea, obtener soporte organizacional, es desarrollar el soporte necesario en todos los niveles de la organización. Es necesario que todos los niveles de la organización comprendan como las mediciones beneficiarán directamente sus proyectos y sus propios procesos.

Si bien el soporte organizacional no se relaciona directamente con requisitos del producto PSM Dashboard, es de importancia vital para lograr una implementación exitosa del producto PSMD y de un programa de mediciones.

La segunda tarea es definir responsabilidades, todos los participantes deben contar con una clara comprensión dentro del programa de mediciones, y de su disponibilidad para realizar las tareas asignadas. Las responsabilidades pueden asignarse mediante políticas, planes y definiciones. Las responsabilidades pueden referirse a la generación de datos, al establecimiento y mantenimiento de la base de datos de mediciones y a las funciones de análisis y reporte

PSMD cuenta con los siguientes mecanismos para la asignación de responsabilidades:

Definición de roles

Asignación de personas a roles a nivel organizacional y a nivel de cada proyecto

Definición de responsabilidades mediante el Plan de Mediciones ver 3.1.2.4.2 Especificación de los requisitos de las mediciones (Plan de Mediciones)

Obtener Soporte or-ganizacional

Definir Responsa-bilidades

Proveer Recursos


Página 61

PSMD incluye un Workflow para todas las actividades de recolección, almacenamiento, normalización de datos, análisis y reporte que llevan a la práctica las tareas de acuerdo a la asignación de roles planificada.

Para la implementación del proceso es necesario que se provean los recursos requeridos, lo que comprende tanto el personal como las herramientas necesarias.

3.1.6.2 Obtención de soporte organizacional La implementación de un programa de mediciones representa un cambio cultural significativo y puede causar ansiedad entre los participante, pueden existir temores sobre el fin que se les dará a los resultados, o la preocupación de que algunos problemas ocultos queden a la vista. El involucramiento y el liderazgo de la gerencia es fundamental para el éxito de la implementación, este soporte debe darse mediante el establecimiento de políticas, la provisión de recursos, la comunicación de objetivos y la revisión periódica de las mediciones mediante. Con un liderazgo efectivo toda la organización comprenderá la importancia de las mediciones y soportará activamente el proceso.

El soporte organizacional es importante para una implementación exitosa del producto PSMD y de un programa de mediciones.

En la definición de los planes y workflows de revisión es importante incorporar una participación activa de la Dirección de la empresa en los procesos de revisión de las mediciones y en la realimentación a los sectores de ejecución.

3.1.6.3 Definición de responsabilidades La asignación de responsabilidades en el proceso de mediciones depende mucho del tamaño y estructura de cada organización. La cantidad de personas involucradas, y la forma en que se asignan las actividades varía considerablemente entre una organización y otra. En algunos casos la asignación es part time y en otros es full time

Pero independientemente de estas diferencias cualquiera de las personas involucradas en el proceso de mediciones, estará involucrada en alguna de estas actividades

- Políticas de Medición, planes y definiciones

- Generación de datos

- Base de datos de mediciones

- Análisis y reportes

Políticas de Medición, planes y definiciones

Las organizaciones en general establecen políticas y procedimientos para ayudar a la institucionalización del proceso de mediciones.

PSDM se orienta a la presentación de indicadores en forma de Dashboard. Las políticas y otros documentos de gestión de alto nivel están fuera del alcance de PSMD

Estas políticas y procedimientos guían la elaboración de planes específicos para cada proyecto.

La capacidad de PSMD para gestionar planes de mediciones fueron descriptas en 3.1.2.4.2 “Especificación de los requisitos de las mediciones”

Generación de datos

El plan de mediciones establece las responsabilidades para la generación de datos.

La generación de datos debe integrarse a las actividades normales del equipo de proyecto tanto como sea posible. Diferentes personas contribuyen en el suministro de


Página 62

los datos correspondientes a las mediciones. Los datos deben ser suministrados en forma exacta y puntual

PSMD prioriza la recolección automática de datos con el objeto de agilizar el proceso de mediciones.

Las responsabilidades en la generación de datos y las fechas previstas para su recolección se definen mediante las funcionalidades de Workflow y Schedulling de PSMD.

Base de datos de mediciones

Los datos deben ser almacenados en una base de tatos organizacional

Independientemente del diseño adoptado para la base de datos, los siguientes aspectos deben ser considerados:

- ¿Quien diseña la base de datos, provee seguridad, selecciona las herramientas apropiadas y controla los programas?

- ¿Quien tiene acceso a la base de datos?

- ¿Quién asegura que los datos son normalizados, validados y editados antes de ser ingresados en la base de datos.

La comprensión de estos aspectos y una apropiada asignación de responsabilidades aseguran la calidad de los datos correspondientes a las mediciones.

PSMD basa su Arquitectura de Base de Datos en los conceptos de Business Intelligence que se describen en la sección 4.3

PSMD cuenta con funcionalidad de control de acceso a los datos, y a todas las funcionalidades del aplicativo, basadas en Roles

Con el objeto de asegurar la integridad de los datos PSMD cuenta con reglas de verificación y autocorrección de datos, estas reglas se incluyen como pasos de workflow existiendo tres alternativas:

Los datos no presentan errores (cumplen con las reglas definidas) por lo que no se requiere una verificación de los mismos.

Los datos presentan errores que son corregidos automáticamente, no se requiere verificación manual, pero opcionalmente se emite un reporte con las correcciones realizadas.

Los datos presentan errores que no pueden ser corregidos automáticamente, por lo que se realiza una tarea de verificación y corrección manual, prevista en el Workflow.

Análisis y reporte

El plan de mediciones establece las responsabilidades para el análisis y reporte de los resultados de las mediciones.

Por ejemplo en proyectos pequeños estas actividades pueden ser realizadas por el Gerente de Proyecto, mientras que en proyectos mayores esta función puede ser realizada por Aseguramiento de calidad o por un analista de mediciones especialmente dedicado a esta función.

El análisis debe realizarse con el nivel de detalle suficiente para permitir la toma de decisiones.

En PSMD la asignación de responsabilidades de análisis y reporte se realiza mediante workflows.

PSMD cuenta con los siguientes reportes:

Dashboards por proyectos


Página 63

Paneles MAE por proyecto, grupo de proyectos o para todo el programa de proyectos.

Reportes periódicos por proyecto.

El mecanismo de reporte de PSMD es el siguiente:

1. Cuando se ejecuta el paso de análisis del workflow, PSMD genera en forma automática los dashboards previstos y envía al analista de mediciones una solicitud de análisis. El analista de mediciones documenta los resultados del análisis mediante notas asociadas a indicadores incluidos en los Dashboards o en el Modelo de Análisis estructurado (MAE).

2. Cuando se ejecuta el paso de reporte del workflow, se generan automáticamente los reporte a partir de la información incluidas en los dashboards correspondientes al proyecto, incluyendo los anotaciones incluidas por el analista de mediciones.

3. El workflow solicita al analista la revisión del reporte.

4. El workflow solicita la aprobación del reporte

5. El worklow hace que el reporte llegue a los destinatarios previstos, esto puede hacerse por dos métodos:

a. Envío de mails con el reporte adjunto

b. Publicación del reporte en un portal colaborativo, y notificación a los destinatarios.

Este procesos está resumido en un diagrama de flujo en el documento “Requisitos PSM Dashboard”, sección 3.2.4, análisis y reporte de mediciones.


Página 64

3.2 CMMI: Capability Maturity Model Integrated

3.2.1 PSM Dashboard y CMMI Como se describió en la sección 2.2, los clientes de Know Edge son empresas que basan sus procesos de desarrollo de software en el modelo CMMI. Por este motivo PSMD debe proveerles las herramientas de mediciones necesarias para la implementación efectiva de un programa de mediciones que sea adecuado para cualquiera de los niveles de madurez del modelo CMMI.

En este capítulo se evalúan las características de cada uno de los niveles de madurez establecidos por CMMI, y los requisitos de PSMD para satisfacer exitosamente la implementación de los procesos mencionados.

3.2.2 Que es CMMI? CMMI (Capability Maturity Model® Integration) es un modelo que provee a las organizaciones los elementos esenciales de los procesos efectivos. El modelo puede ser usado para guiar en la mejora de procesos en un proyecto, en un sector de la empresa, o en toda la organización.

CMMI ayuda a integrar funciones que tradicionalmente se encuentran separadas, establece objetivos y prioridades de mejora, provee guía para establecer procesos de calidad y brinda un marco de referencia para la evaluación de los procesos actuales. (SEI CMMI Web)

3.2.3 Foco en los procesos (CMMI Tutorial)

Si bien contar con personal altamente capacitado y motivado es de gran importancia para el éxito de cualquier proyecto de desarrollo, aún el mejor equipo no podrá desempeñarse de la mejor manera si los procesos no son comprendidos y no están operando de la mejor manera

Los procesos son los principales determinantes de los costos de los productos, los plazos de entrega y la calidad.

Los procesos son conjuntos de prácticas realizadas para lograr un determinado propósito, puede incluir herramientas, métodos, materiales y gente.

Si bien los procesos pueden ser considerados como uno de los vértices de la tríada Procesos – Personal – Tecnología, también pueden ser considerados como el pegamento que unifica los otros aspectos.

El concepto de focalizar en los procesos proviene de los principios del Total Quality Management establecidos por referentes como Shewhart, Juran, Deming y Humphrey:

“La Calidad de un producto está principalmente determinada por la calidad de los procesos empleados para desarrollarlo y mantenerlo”


Página 65

3.2.4 Organización del modelo CMMI (CMMI Chrissis)

El modelo CMMI incluye una descripción de procesos basado en las mejores prácticas de eficacia probada por la experiencia de empresas líderes dedicadas al desarrollo de software y de sistemas.

El modelo CMMI establece 5 niveles de madurez en su representación por etapas, y organiza estas mejores prácticas en 25 áreas de proceso, cada una de ellas asociada con un nivel de madurez. La Figura 26 describe la Organización del modelo CMMI

Figura 26

A cada uno de los 5 niveles de madurez establecidos en el modelo se asocian un grupo de áreas de proceso. Cada área de proceso incluye un conjunto de Objetivos Específicos, que son propios del Área de Proceso, y Objetivos Genéricos, que son transversales a todas las Áreas de Proceso. El cumplimiento de estos objetivos determina el cumplimiento del Área de Procesos correspondiente.

El modelo describe cuales son las Prácticas que se deben realizar para alcanzar los Objetivos, tanto para el caso de los específicos como para los genéricos.

También se presentan ejemplos de Productos de trabajos típicos y subprácticas habituales relacionadas con las Prácticas Específicas.

Objetivos Específicos

Objetivos Genéricos

Área de Proceso







Prácticas Específicas

Prácticas Genéricas

Productos de trabajo típicos

Subprácticas

Nivel de Madurez (1 a 5)

Área de Proceso


Página 66

3.2.5 Niveles de madurez Es un objetivo que producto PSM Dashboard resuelva todos los aspectos relacionados con las mediciones en cualquier organización que emplee el modelo CMMI para la definición de sus procesos, en cualquiera de sus niveles.

En este capítulo se analiza cuales son los requisitos de PSMD para poder soportar todas las necesidades relativas a la aplicación del modelo CMMI.

Él modelo CMMI establece 5 niveles de madurez en su representación por etapas

Un nivel de madurez consiste en un conjunto de prácticas genéricas y específicas, correspondientes a un conjunto preestablecido de áreas de proceso que mejoran el desempeño general de la organización.

Nivel de Madurez 1: Inicial

En el nivel de madurez 1 los procesos son generalmente ad hoc y caóticos. La organización habitualmente no provee un ambiente estable para soportar sus procesos. El éxito en estas organizaciones depende de la competencia y el heroísmo de la gente de la organización y no del empleo de procesos probados.

A pesar del caos, las organizaciones del nivel de madurez 1 frecuentemente proporcionan productos que funcionan, sin embargo, frecuentemente exceden sus presupuestos y no cumplen con los plazos.

Las organizaciones del nivel de madurez 1 tienen a comprometerse en exceso, abandonan sus procesos en tiempos de crisis, y no son capaces de repetir sus logros.

Nivel de Madurez 2: Gestionado

En el nivel de madurez 2, los proyectos de la organización han asegurado que los requisitos son gestionados y que los procesos están planificados, realizados, medidos y controlados. La disciplina de procesos existente en las organizaciones de nivel 2 ayuda a asegurar que las prácticas existentes se mantienen en tiempos de crisis. Cuando estas prácticas están vigentes, los proyectos se ejecutan de acuerdo con lo planeado.

En el nivel de madurez 2, el estado de los productos de trabajo y la provisión de servicios son visibles en determinados puntos definidos (por ejemplo en los principales hitos, o al completar las principales tareas). Se establece el compromiso entre los principales stakeholders y se revisa en la medida de lo necesario. Los productos de trabajo son apropiadamente controlados. Los productos de trabajo y los servicios provistos satisfacen sus descripciones de procesos especificadas, estándares y procedimientos.

Nivel de Madurez 3: Definido

En el nivel de madurez 3 los procesos están bien caracterizados y comprendidos, y son descriptos mediante estándares, procedimientos, herramientas y métodos. El conjunto estándar de procesos de la organización, que es la base del nivel de madurez 3, fue establecido y es actualizada a lo largo del tiempo. Estos procesos estándar se emplean para establecer consistencia a través de toda la organización. Los proyectos establecen sus procesos mediante adaptaciones (tailoring) del conjunto de procesos estándar de la organización, de acuerdo con las guías de adaptación.

Una diferencia crítica entre los niveles 2 y 3 es el alcance de las definiciones de los procesos, en el nivel de madurez 2 los estándares, descripciones de procesos y procedimientos pueden ser muy diferentes entre un proyecto y otro, mientras que en


Página 67

el nivel de madurez 3 los procesos de cada proyectos son adaptaciones del conjunto estándar de procesos de la empresa, para lograr la mejor adecuación a las necesidades del proyecto.

Otra diferencia es que en el nivel 3 los procesos son típicamente descriptos en forma más rigurosa que en el nivel 2. Un proceso definido detalla conceptos tales como el propósito, entradas, criterios de entrada, actividades, roles, mediciones, verificaciones, salidas y criterios de salida. En el nivel de madurez 3 los procesos son gestionados más proactivamente mediante la comprensión de la interrelación entre las distintas áreas de proceso.

Nivel de Madurez 4: Gestionado Cuantitativamente

En el nivel de madurez 4 la organización y los proyectos establecen objetivos cuantitativos para la calidad y el desempeño de los procesos, y los emplea como criterios en la gestión de los procesos. Los objetivos cuantitativos se basan en las necesidades de los clientes, usuarios finales, la organización y quienes están implementando el proceso. La calidad y el desempeño de los procesos son entendidos en términos estadísticos, y son gestionados a lo largo del ciclo de vida de todo el proyecto.

Para los subprocesos seleccionados, se recolectan mediciones detalladas y se analizan estadísticamente. Las mediciones de calidad y desempeño del proceso son incorporadas al repositorio de mediciones de la organización para dar soporte a la toma de decisiones basada en datos. Las causas especiales de variaciones son identificadas y cuando es necesario se toman las acciones correctivas para prevenir futuras ocurrencias.

Una diferencia crítica entre los niveles de madurez 3 y 4 es que el grado de predecibilidad de los procesos, en el nivel de madurez 4 el desempeño de los procesos es controlado empleando técnicas estadísticas y otras técnicas cuantitativas, mientras que en el nivel 3 los procesos son típicamente solo predecibles a nivel cualitativo.

Nivel de Madurez 5: Mejora continua

El nivel de madurez 5 se enfoca en la mejora continua de los procesos por medio de mejoras incrementales o innovaciones de procesos o de tecnología. Se establecen objetivos cuantitativos de mejora de procesos para la organización, estos objetivos son revisados para reflejar los cambios en los objetivos del negocio, y empleados como criterios para gestionar la mejora en los procesos.

Los efectos del despliegue de los procesos mejorados son medidos y evaluados contra los objetivos de mejora cuantitativos previstos, tanto los procesos definidos como el conjunto estándar de procesos de la organización son objeto de actividades de mejora medibles.

Una diferencia crítica entre los niveles 4 y 5 es el tipo de variación de procesos que se trata: En el nivel 4, la organización está preocupada por el tratamiento de las causas especiales de variación de procesos y proveyendo predictibilidad a los procesos. Aunque los resultados puedan ser predecibles, estos pueden ser insuficientes para lograr los objetivos establecidos.

En el nivel de madurez 5, la organización está preocupada por el tratamiento de las causas comunes de variación de los procesos y también por cambiar los procesos con el objeto de desplazar su valor medio o reducir el nivel de variación, para mejorar el desempeño del proceso y lograr los objetivos cualitativos de mejora de proceso previstos.


Página 68

3.2.6 Requisitos de mediciones de cada nivel de madurez. En esta sección se analiza cada área de procesos del modelo CMMI, y se analiza si para la implementación de las prácticas correspondientes, es necesario agregar al producto PSM Dashboard nuevos requisitos de mediciones, mas allá de los derivados del estándar PSM, y que fueron analizadas en la sección 3.1.

El análisis de los requisitos se realiza en itálica. Solo se incluyen los objetivos y prácticas que derivan nuevos requisitos.

3.2.6.1 Requisitos del nivel de madurez 2 Este nivel, en la representación por etapas incluye las siguientes áreas de procesos

Gestión de Requisitos (REQM)

El propósito de este proceso es gestionar los requisitos de los productos del proyecto y sus componentes e identificar inconsistencias entre estos requisitos y los planes del proyecto y productos de trabajo.

SG1. Gestionar Requisitos

SP 1.1 Obtener un entendimiento de los requisitos

SP 1.2 Obtener compromiso con los requisitos

SP 1.3 Gestionar los cambios a los requisitos

SP 1.4 Mantener trazabilidad bidireccional de los requisitos.

SP 1.5 Identificar inconsistencias entre los productos del proyecto y los requisitos

GP 2.8 Monitoreo y control del proyecto

GP 2.8 hace una mención a la medición de requisitos (por ejemplo volatilidad de requisitos= % de requisitos cambiados), no agrega nuevos requisitos a PSM, ya que esta medición, y otras relacionadas con la gestión de requisitos están previstas en PSM (Capítulo 3 de la guía PSM, Requirement Status, Change Request Status, Requirements)

Gestión de Proyectos (PP)

El objetivo de este proceso es establecer y mantener planes que definan las actividades a realizar en el proyecto, y en base a las mismas, establecer el presupuesto y los cronogramas del proyecto.

SG 1. Establecer estimaciones. Para ello hay que:

SP 1.1. Estimar el alcance del proyecto (relación de tareas).

SP 1.2. Realizar estimaciones de los productos de trabajo y atributos de las tareas (Esfuerzo, costo y cronograma).

Como se detalló en 3.1.4.3 PSMD almacenará datos de mediciones históricas de proyectos y presentará esta información en forma gráfica para asistir el proceso de estimación.

SP 1.3. Definir el ciclo de vida del proyecto (diferentes fases del proyecto).

SP 1.4. Realizar estimaciones de esfuerzo y costo.

SG 2. Desarrollar el plan de proyecto – un documento formal que se utilizará para manejar y controlar la ejecución del proyecto. Este documento estará basado en los requisitos del proyecto y en las estimaciones anteriores.

SP 2.1. Establecer el presupuesto y cronograma del proyecto.

SP 2.2. Identificar los riesgos del proyecto.


Página 69

SP 2.3. Definir un plan para administrar los datos, entendiendo por datos cualquier documentación requerida para soportar un programa en cualquiera de sus facetas (administración, control de cambios, logística, etc)

SP 2.4. Definir un plan para administrar los recursos.

SP 2.5. Definir un plan para administrar los conocimientos y habilidades.

SP 2.6. Definir un plan para involucrar a los interesados.

SP 2.7. Establecer el Plan General del proyecto.

SG 3. Obtener el compromiso para la realización del plan – Se establecen y mantienen compromisos con todos los stakeholders en el proyecto con las actividades definidas en el Plan de Proyecto.

SP 3.1. Revisar los planes que afectan al proyecto (con los stakeholders).

SP 3.2. Reconciliar el trabajo y el nivel de los recursos.

SP 3.3. Conseguir el compromiso de los stakeholders con el Plan de proyecto.

GP 2.8 Monitor and control the process

PSMD incluirá mediciones del número de revisiones sufridas en el plan de proyecto, incluyendo mediciones de variaciones de costo, plazo y esfuerzo por revisión del plan.

Monitoreo y control de proyectos (PMC)

SG 1. Monitorear el proyecto de acuerdo con el Plan.

SP 1.1. Monitorear los parámetros del Plan de proyecto (% de avance, fechas reales vs. fechas estimadas, número de requisitos implementados vs. los planeados, etc.)

En relación al monitoreo de los parámetros del plan de proyecto: Progreso, Esfuerzo, Atributos del producto, Recursos Planeados y Usados. Todas estas mediciones ya están incluidas en PSMD, ver la tabla ICM en 3.1.3.1.

Monitoreo del conocimiento y las habilidades del personal del proyecto: PSMD Incluye la medición experiencia del personal. Ver la tabla ICM en 3.1.3.1.

SP 1.2. Monitorear los compromisos.

SP 1.3. Monitorear los riesgos.

Para realizar un monitoreo efectivo de los riesgos se incluirá en PSMD una medición de exposición de riesgos.

SP 1.4. Monitorear el plan de administración de datos (que los datos existan y estén almacenados en el lugar correcto).

SP 1.5. Monitorear el involucramiento de los interesados.

SP 1.6. Realizar revisiones del avance del proyecto.

SP 1.7. Realizar revisiones de los hitos del proyecto.

SG 2 Gestionar las acciones correctivas ante desvíos significativos.

SP 2.1 Analizar los problemas

SP 2.2 Tomar acciones correctivas.

SP 2.3 Gestionar las acciones correctivas

GP 2.8 Monitoreo y control del proceso


Página 70

No se incluyen nuevos requisitos ya que PSM, y por lo tanto PSM Dashboard incluye las mediciones necesarias para controlar este proceso:

- Cantidad de problemas abiertos y cerrados

- Fechas de hitos (Reales vs. Planeadas)

- Revisiones realizadas (ICM: Estado de revisiones)

- Revisión del cronograma (ICM: Estado de revisiones)

Gestión de acuerdos con proveedores (SAM)

El objetivo de este proceso es controlar la adquisición de productos proporcionados por los proveedores con los cuales existe un acuerdo formal. Este proceso se cumple si se cumplen las siguientes prácticas:

SG 1. Establecer acuerdos con proveedores. Para ello hay que:

SP 1.1. Determinar el tipo de adquisición.

SP 1.2. Seleccionar proveedores.

SP 1.3. Establecer acuerdos con proveedores.

SG 2. Satisfacer los acuerdos con proveedores. Para ello hay que:

SP 2.1. Revisar los productos comerciales ya hechos (COTS Products, Commercial On The Self Products, en contraposición a productos realizados a medida).

SP 2.2. Ejecutar los acuerdos con los proveedores.

SP 2.2 Subpráctica 4, Revisiones técnicas a proveedores

PSMD Maneja múltiples Organizaciones, cada proveedor será considerado una Organización diferente.

PSMD incluye en su librería de mediciones la Calificación de desempeño que satisface los requisitos de esta práctica.

SP 2.3. Aceptar el productor adquirido.

SP 2.4. Efectuar la transición de productos.

GP 2.8 Monitorear y controlar el proceso

Las mediciones incluidas en la tabla ICM no incluyen aspectos relacionados con los proveedores, agregar un área de Issue y categorías de mediciones relacionadas con este aspecto, y mediciones tales como las mencionadas en el modelo CMMI:

- Cantidad de cambios realizados a los requisitos para el proveedor

- Variación de costo y cronograma por acuerdo con los proveedores.


Página 71

Mediciones y análisis (MA)

El propósito de este proceso es desarrollar y mantener la capacidad de tomar mediciones para atender las necesidades de información de cómo va el proyecto. Se cumple con este proceso si se cumple con las siguientes prácticas:

SG 1. Alinear actividades de medición y análisis con los objetivos y las necesidades de información. Para ello hay que:

SP 1.1. Establecer los objetivos de la medición.

Este aspecto se satisface mediante la identificación de los Objetivos del proyecto y la posterior identificación de los Issues (áreas de preocupación del proyecto) a partir de los problemas conocidos, riesgos y falta de información como se detalló en 3.1.2.2.1 (Identificación de Issues).

Este análisis puede realizarse a tres niveles, como se explicó en 3.1.1.4 Contexto organizacional y empresario:

• Organizacional

• Recurrentes en grupos de proyectos, o en todos los proyectos

• Correspondientes a un determinado proyecto

SP 1.2. Especificar mediciones (métricas básicas, número de requisitos, esfuerzo esperado en la corrección de errores).

SP 1.3. Establecer procedimientos de recolección de datos y almacenamiento de los mismos.

SP 1.4. Establecer el procedimiento de análisis.

Cubierto por PSM y especificado para PSMD en 3.1.2.4.2 (Especificación de los requisitos de las mediciones)

SG 2. Proporcionar resultados de las mediciones

SP 2.1. Guardar las mediciones.

Cubierto por PSM y especificado para PSMD

SP 2.2. Analizar las mediciones (para ver si los datos obtenidos son correctos).

Cubierto por PSM y especificado para PSMD en 3.1.4.3

Inclusión de paso de análisis en el workflow

Inclusión de anotaciones del analista de mediciones en los dashboards

SP 2.3. Almacenar los datos y resultados obtenidos (métricas básicas y calculadas).

PSMD es el repositorio donde se almacenan los planes de medición, las especificaciones de las mediciones, los conjuntos de datos recolectados y los reportes con los resultados del análisis.

SP 2.4. Comunicar los resultados del proceso a los stakeholders.

Cubierto por PSM y especificado para PSMD en 3.1.4.3

La comunicación de los resultados del análisis puede realizarse en PSMD mediante uno de los siguientes métodos:

• Publicación on-line en el Modelo de Análisis Estructurado (MAE)

• Publicación de Dashboards

• Workflow de reportes como se especificó en 3.1.4.4 (Realizar recomendaciones)


Página 72

GP 2.8 Monitoreo y Control del Proceso:

Es posible medir el grado de implementación del programa de mediciones mediante la medición “Clasificación del Modelo de Referencia” prevista en PSM e incluida en PSMD.

Aseguramiento de calidad de Productos y Procesos (PPQA)

El objetivo de este proceso es proporcionar al personal y a la dirección de comprensión objetiva sobre el estado de los procesos y productos.

SG 1. Evaluar objetivamente procesos y productos de trabajo

SP 1.1. Evaluar objetivamente los procesos.

Las categorías de mediciones Conformidad del proceso, Eficiencia del proceso, Efectividad del proceso incluyen las mediciones necesarias para controlar la evaluación de procesos realizada, por ejemplo, mediante auditorías de procesos.

SP 1.2. Evaluar objetivamente los productos de trabajo y servicios.

Las categorías de mediciones de PSM

• Correctitud Funcional

• Soportabilidad, Mantenibilidad

• Eficiencia

• Portabilidad

• Usabilidad

• Dependabilidad, Confiabilidad

Permiten controlar las evaluaciones realizadas sobre los productos.

SG 2. Proporcionar comunicación interna objetiva.

SP 2.1. Comunicar las no conformidades y asegurar su resolución.

SP 2.2. Establecer y mantener registro de actividades.

Estas actividades se resuelven mediante los sistemas de Calidad y Project Management y están fuera del alcance de PSMD

GP 2.8 Monitorear y controlar el proceso

Incluir mediciones que permitan monitorear el proceso de Aseguramiento de la Calidad como por ejemplo:

- Variación entre las evaluaciones de procesos planeadas y realizadas

- Variación entre las evaluaciones de procesos planeadas y realizadas.

Gestión de la Configuración (CM)

El propósito de este proceso es establecer y mantener la integridad de los productos de trabajo manteniendo un control de sus versiones, lo que implica mantener una identificación, control y auditoria de cada versión. Se cumple con este proceso si se cumple con las siguientes prácticas:

SG 1. Establecer líneas base. Para ello hay que:

SP 1.1. Identificar cada componente susceptible de ser versionado.

PSMD emplea los ítems de configuración como estructuras de agregación que permiten realizar un análisis de las mediciones separando cada Ítem de Configuración.


Página 73

El registro de los Ítems de Configuración en general se realiza mediante un sistema específico de Gestión de la Configuración.

PSMD incluirá las interfaces necesarias para tomar del sistema de Gestión de la Configuración la lista de Ítems de Configuración, y la empleará como una de las posibles estructuras de agregación.

SP 1.2. Establecer y mantener un sistema de administración de la configuración.

SP 1.3. Crear líneas base (para uso interno o para entregar al cliente).

PSMD contará con la capacidad de mostrar información correspondiente a múltiples líneas de base, por lo que contará con las interfases necesarias para obtener de los sistemas de Gestión de Configuración y Gestión del Proyecto la información necesaria sobre las distintas líneas de base.

SG 2. Seguimiento y control de cambios. Para cumplir con esta meta hay que:

SP 2.1. Monitorear los requisitos de cambio.

Si bien esta actividad se realiza mediante las herramientas de control de cambios de los sistemas de Gestión de la Configuración y Gestión del Proyecto, PSMD cuenta con una medición de Estado de los pedidos de cambio, lo que permite controlar este proceso.

SP 2.2. Controlar los componentes que han cambiado.

SG 3. Establecer la integridad

SP 3.1. Establecer y mantener registros describiendo cada iteración de la configuración.

SP 3.2. Ejecutar auditorias a la configuración para mantener la integridad.

PSMD cuenta con mediciones para cuantificar los hallazgos de las auditorias

GP 2.8 Monitoreo y Control del proceso de Gestión de la Configuración

PSMD incluye mediciones como “Estado de los pedidos de cambio” que permiten tener este proceso bajo control.

Resumen del nivel de madurez 2

En general el estándar PSM y su implementación mediante el producto PSM Dashboard satisfacen las necesidades de mediciones de las áreas de proceso correspondientes al nivel 2 de CMMI, Se derivaron requisitos menores que serán considerados en la especificación del producto relacionados con los siguientes aspectos:

- Gestión de proveedores y subcontratistas (SAM)

- Exposición del riesgo (PMC)

- Mediciones relacionadas con el objetivo genérico GP 2.8 (monitoreo y control del proceso) de las áreas de proceso analizadas.


Página 74

3.2.6.2 Requisitos del nivel de madurez 3 Desarrollo de requisitos (RD)

El propósito de esta área de proceso es producir y analizar los requisitos del cliente, del producto y de sus componentes.

SG 1. Desarrollar los requisitos del cliente.

SP 1.1. Elicitar las necesidades de los stakeholders.

SP 1.2. Desarrollar los requisitos de los clientes.

SG 2. Desarrollar los requisitos del Producto. Para ello hay que:

SP 2.1. Establecer los requisitos del producto y componentes que integran el producto.

SP 2.2. Asignar los requisitos a cada componente.

SP 2.3. Identificar los requisitos de interfaces.

SG 3. Analizar y validar los requisitos. Para ello hay que:

SP 3.1. Establecer y mantener los conceptos operacionales y escenarios asociados.

SP 3.2. Establecer y mantener una definición de la funcionalidad requerida.

SP 3.3. Analizar los requisitos.

SP 3.4. Analizar los requisitos para lograr su balance.

SP 3.5. Validar los requisitos con métodos que sean entendibles.

De las prácticas específicas del área de procesos RD no se derivan requisitos para PSM Dashboard

GP 2.8 Monitoreo y Control del proceso

Las mediciones empleadas típicamente para monitorear este proceso son:

- Indicadores de costo, cronograma y esfuerzo empleado para el retrabajo

- Densidad de defectos

PSM incluye mediciones de costo, cronograma y esfuerzo, pero el retrabajo no es un atributo incluido en la definición: Incluir el retrabajo como atributo en las mediciones de costo, cronograma y esfuerzo

Incluir en la librería de mediciones de PSMD la densidad de defectos como medición derivada del esfuerzo y el tamaño


Página 75

Solución técnica (TS)

El propósito de este proceso es diseñar, desarrollar e implementar soluciones a los requisitos. Las soluciones, diseños e implementaciones abarcan productos, componentes del producto y procesos relacionados al ciclo de vida asociados al producto.

SG 1. Seleccionar soluciones para los componentes del producto

SP 1.1. Desarrollar alternativas detalladas y criterios de selección (costos, rendimiento técnico, complejidad, limitaciones tecnológicas, riesgos, facilidad de uso, etc).

SP 1.2. Evolucionar conceptos operacionales y escenarios (modo de operación, estado de la operación para cada componente).

SP 1.3. Seleccionar soluciones para los componentes del producto.

SG 2. Crear el diseño.

SP 2.1. Diseñar el producto o los componentes del producto (diseño detallado).

SP 2.2. Establecer un paquete de datos técnicos (conjunto de especificaciones).

SP 2.3. Diseñar interfaces utilizando criterios.

SP 2.4. Realizar los análisis de construcción, compra o reuso.

SG 3. Implementar el diseño del producto. Para ello hay que:

SP 3.1. Implementar el diseño (codificación, re-usabilidad de código, pruebas unitarias).

A la SP 3.1 aplican mediciones de tamaño físico como la cantidad de líneas de programa, estas mediciones están incluidas en PSM y por lo tanto en las librerías de PSMD

SP 3.2. Desarrollar la documentación de soporte del producto.

A SP 3.2 aplican mediciones de tamaño físico como el número de páginas de la documentación, Incluir esta medición en la librería de PSMD


- Indicadores de costo, cronograma y esfuerzo empleado para el retrabajo: Analizado en RD

- Porcentaje de Requisitos tratados en el diseño: Incluir en la librería de PSMD

- Tamaño y complejidad del producto: Incluido en PSM y por lo tanto en las librerías de PSMD

- Densidad de defectos: Analizado en RD

Integración del producto (PI)

El propósito es integrar el producto a partir de sus componentes, asegurar que el producto integrado funciona correctamente, y entregar el producto.

SG 1. Preparar la integración del producto:

SP 1.1. Determinar la secuencia de integración.

SP 1.2. Establecer el ambiente para la integración del producto.

SP 1.3. Establecer los criterios y procedimientos de integración del producto.

SG 2. Asegurar la compatibilidad de las interfaces:

SP 2.1. Revisar la completitud de las descripciones de las interfaces.

SP 2.2. Administrar las interfaces.

SG 3. Integrar los componentes del producto y entregar el producto:


Página 76

SP 3.1. Confirmar que los componentes del producto están listos para la integración.

SP 3.2. Integrar los componentes del producto.

SP 3.3. Evaluar la integración de los componentes del producto.

SP 3.4. Empaquetar y entregar el producto o componente.

No se derivan nuevos requisitos para PSMD a partir de las prácticas del área de proceso PI.

GP 2.8 Monitoreo y control del proceso:

PSMD incluye mediciones de cantidad y antigüedad de problemas, que puede ser aplicado para controlar el proceso de integración del producto.

Verificación (VER)

El propósito de esta área de procesos es asegurar que los productos de trabajo seleccionados cumplen con los requisitos especificados.

SG 1. Preparar la verificación

SP 1.1. Seleccionar los productos de trabajo para la verificación

SP 1.2. Establecer el ambiente de verificación.

SP 1.3. Establecer los procedimientos y criterios de verificación.

SG 2. Realizar revisiones por pares

SP 2.1. Preparar revisiones por pares.

SP 2.2. Realizar revisiones por pares.

SP 2.3. Analizar resultados de revisiones por pares.

SG 3 Verificar los productos de trabajo seleccionados

SP 3.1. Realizar la verificación.

SP 3.2. Analizar los resultados de la verificación e identificar las acciones correctivas.

PSM, y su implementación mediante PSMD incluye mediciones de Correctitud Funcional (Defectos) que son aplicables a esta Área de Procesos


En esta prácticas se sugieren las siguientes mediciones para el control del proceso:

- Perfil de la verificación (Cantidad de verificaciones planeadas y realizadas) Incluir en la especificación de PSM Dashboard

- Cantidad de defectos detectados por categoría de defectos. Disponible en PSMD

- Tendencia de los problemas de verificación (Disponible en PSMD)

- Estado de los problemas de verificación (Disponible en PSMD)


Página 77

Validación (VAL)

El propósito de esta área de proceso es demostrar que un producto o componente satisface su uso previsto cuando se emplea en el ambiente planeado

SG 1. Preparar la validación.

SP 1.1. Seleccionar los productos a validar.

SP 1.2. Establecer el ambiente de validación.

SP 1.3. Establecer los procedimientos y criterios de validación.

SG 2. Validar los productos o componentes de los productos.

SP 2.1. Realizar la validación.

SP 2.2. Analizar los resultados de la validación.

PSM, y su implementación mediante PSMD incluye las mediciones sobre Status de Problemas (Problem Report Status) que aplica a esta área de procesos.

Los hallazgos de las validaciones también pueden ser registrados como defectos, en este caso se cuenta con el indicador de Correctitud Funcional “Defectos”


En esta práctica se sugieren las siguientes mediciones para el control del proceso:

- Cantidad de actividades de validación planeadas y realizadas: Incluir en la especificación de PSM Dashboard

- Tendencia de los problemas de validación (Disponible en PSMD)

- Antigüedad de los problemas de validación (Disponible en PSMD)

Foco en el proceso (OPF)

El propósito de esta área de procesos es planificar e implementar mejoras en los procesos de la organización basadas en la comprensión de las fortalezas y debilidades de los procesos y de los activos de procesos.

SG 1. Determinar las oportunidades de mejora del proceso.

SP 1.1. Establecer las necesidades de los procesos de la organización.

SP 1.2. Evaluar los procesos de la organización.

SP 1.3. Identificar mejoras en los procesos de la organización.

SG 2. Planificar e implementar las actividades de mejora de los procesos.

SP 2.1. Establecer los planes de acción para los procesos.

SP 2.2. Implementar los planes de acción para los procesos.

SP 2.3. Desplegar recursos organizacionales para el proceso.

SP 2.4. Incluir experiencias relacionadas con el proceso organizacional.

PSMD es una herramienta de utilidad para esta práctica, ya que la comparación de mediciones antes y después de las mejoras es una evidencia de la efectividad de las acciones de mejora implementadas sobre los procesos.


En esta práctica se sugieren las siguientes mediciones para el control del proceso:

- Cantidad de actividades de mejora propuestas e implementadas: Incluir en la especificación de PSM Dashboard


Página 78

- CMMI maturity level or capability level (Disponible en PSMD: Reference Model Rating)

Definición del proceso de la organización (OPD)

El objetivo de este proceso es establecer y mantener un conjunto utilizable de activos de procesos de la organización.

SG 1. Establecer los recursos organizacionales del proceso.

SP 1.1. Establecer procesos estándar.

SP 1.2. Establecer descripciones del modelo de ciclo de vida.

SP 1.3. Establecer criterios y guías para la adaptación de los procesos.

SP 1.4. Establecer un repositorio de mediciones de la organización.

PSMD resuelve los requisitos de esta práctica, ya que constituye el repositorio de las mediciones de la organización.

SP 1.5. Establecer la librería de activos de procesos a nivel organizacional.


Mediante la medición de densidad de defectos, analizada en RD es posible evaluar los activos de procesos.

Entrenamiento de la organización (OT)

El propósito de este proceso es desarrollar las habilidades y conocimientos de las personas para que puedan desarrollar sus roles de forma eficiente.

SG 1. Habilitar a la organización para formar a su personal.

SP 1.1. Establecer las necesidades estratégicas de entrenamiento.

SP 1.2. Determinar qué necesidades de entrenamiento son responsabilidad de la organización.

SP 1.3. Establecer un plan táctico de entrenamiento para la organización.

SP 1.4. Establecer la capacidad de entrenamiento.

SG 2. Proporcionar la formación necesaria.

SP 2.1. Proveer el entrenamiento

SP 2.2. Establecer registros del entrenamiento.

SP 2.3. Determinar la efectividad del entrenamiento.

Para el control de la efectividad del entrenamiento es conveniente agregar a las librerías de PSMD mediciones que permitan evaluar:

Resultado de las encuestas de fin de curso

Resultado de las evaluaciones realizadas por los entrenadores

Asistencia a los cursos

Calificaciones obtenidas en los cursos


Para monitorear este proceso es conveniente agregar a las librerías de PSMD las siguientes mediciones:

Grado de aplicación de los conocimientos adquiridos

Cantidad de cursos realizados


Página 79

Gestión integrada de proyectos (IPM)

El propósito de esta área de procesos es establecer y administrar el proyecto y la participación de los stakeholders relevantes de acuerdo con procesos definidos que son adaptaciones del conjunto estándar de procesos de la organización.

SG 1. Usar los procesos definidos para el proyecto

SP 1.1. Establecer los procesos definidos para el proyecto.

SP 1.2. Emplear los Activos de Procesos de la Organización para planificar las actividades del proyecto.

SP 1.3. Integrar los planes.

SP 1.4 Administrar los proyectos usando los planes integrados.

La subpráctica 2 menciona el empleo de umbrales en las mediciones, que disparen acciones correctivas: PSMD permitirá programar workflows asociados con umbrales definidos para las mediciones, si una medición supera el umbral, se dispara un workflow consistente en la notificación mediante e-mails a los stakeholders afectados.

SP 1.5 Contribuir con los Activos de Procesos de la Organización.

SG 2. Coordinar y colaborar con los Stakeholders relevantes

SP 2.1. Administrar el involucramiento de los stakeholders.

SP 2.2. Administrar las dependencias.

Sp 2.3 Resolver problemas de coordinación


No agrega nuevos requisitos a PSMD

Gestión de riesgos

El objetivo de la gestión de riesgos es identificar problemas potenciales antes de que ocurran, de forma que las actividades asociadas a ese manejo de riesgos se puedan planificar y realizar según se necesiten a lo largo de la vida del producto o proyecto para mitigar impactos adversos para la consecución de los objetivos.

SG 1. Preparar la gestión de riesgos

SP 1.1. Determinar las fuentes de riesgos, y sus categorías.

SP 1.2. Definir los parámetros de los riesgos.

Los parámetros de los riesgos incluyen la probabilidad, el impacto y el umbral de una o mas mediciones. Es importante, como se mencionó anteriormente, que PSMD cuente con la capacidad de disparar workflows cuando una medición supera el umbral establecido.

SP 1.3. Establecer una estrategia de gestión de riesgos.

SG 2. Identificar y analizar los riesgos

SP 2.1. Identificar riesgos.

SP 2.2. Evaluar, categorizar y priorizar riesgos.

La subpráctica 1 menciona la conveniencia de contar con una medición derivada: La exposición al riesgo, esta medición será incluida en la librería de de mediciones de PSMD, como se mencionó anteriormente.

SG 3. Mitigar riesgos

SP 3.1. Desarrollar planes para reducir los riesgos.

SP 3.2. Implementar los planes de reducción de riesgos.


Página 80

GP 2.8

Para monitorear y controlar el proceso de gestión de riesgos, además de la medición de la exposición, el modelo CMMI sugiere las siguientes mediciones, que serán incluidas en la librería de mediciones de PSMD:

Cantidad de riesgos por estado

Ocurrencia de riesgos no previstos

Gestión integrada de equipos de trabajo (IT)

El propósito de esta área de procesos es formar y mantener un equipo integrado para el desarrollo de los productos de trabajo.

SG 1. Establecer la composición del equipo

SP 1.1. Identificar las tareas del equipo.

SP 1.2. Identificar los conocimientos y habilidades necesarias.

Para el desarrollo de esta práctica es de utilidad contar con mediciones de las habilidades y conocimientos del personal que integra los equipos de desarrollo, incluir estas mediciones en la librería de PSM Dashboard

SP 1.3. Asignar los miembros apropiados al equipo.

SG 2. Conducir la operación del equipo

SP 2.1. Establecer una visión compartida

SP 2.2. Documentar los compromisos del equipo

SP 2.3. Definir roles y responsabilidades

SP 2.4. Establecer procedimientos operativos

SP 2.5. Lograr colaboración entre equipos que se comunican


No agrega requisitos a PSM Dashboard

Gestión integrada de subcontratistas (ISM)

El propósito de esta área de procesos es identificar proactivamente proveedores de productos que pueden ser usados para satisfacer los requerimientos del proyecto y gestionar los proveedores seleccionados manteniendo una relación cooperativa ellos y el proyecto.

SG 1. Analizar y seleccionar potenciales proveedores de productos

SP 1.1. Analizar potenciales proveedores de productos.

SP 1.2. Evaluar y seleccionar proveedores de productos.

SG 2. Coordinar el trabajo con los proveedores

SP 2.1. Monitorear los procesos de los proveedores seleccionados

Para la realización de esta práctica se pueden emplear las mediciones definidas en el Área de Issue “Desempeño del proceso” ya incluidas en PSM y su implementación mediante PSM Dashboard

SP 2.2. Evaluar los productos seleccionados de los proveedores

Para la realización de esta práctica se pueden emplear las mediciones definidas en el Área de Issue “Calidad del producto” ya incluidas en PSM y su implementación mediante PSM Dashboard


Página 81

SP 2.3. Revisar los acuerdos y relaciones con los proveedores


No agrega requisitos a PSM Dashboard

Análisis de decisiones y resolución (DAR)

El objetivo del análisis de decisiones y la resolución es analizar las posibles decisiones utilizando un proceso formal de evaluación que evalúe las alternativas identificadas en base a criterios establecidos.

SG 1. Evaluar alternativas

SP 1.1. Establecer guías para el análisis de decisiones.

SP 1.2. Establecer criterios de evaluación.

SP 1.3. Identificar soluciones alternativas.

SP 1.4. Seleccionar métodos de evaluación.

SP 1.5. Evaluar alternativas.

SP 1.6. Seleccionar soluciones.


Esta área de proceso no agrega requisitos a PSM Dashboard

Ambiente Organizacional para la Integración (OEI)

El propósito de esta área de proceso es proveer la infraestructura necesaria para el desarrollo integrado de productos y procesos (IPPD)

SG 1. Proveer la infraestructura necesaria para el desarrollo integrado de productos y procesos (IPPD)

SP 1.1.Establecer una visión compartida de la Organización.

SP 1.2.Establecer un ambiente de trabajo integrado.

SP 1.3.Identificar los requisitos de habilidades únicas para IPPD.

SG 2. Gestionar el personal para la integración

SP 2.1.Establecer mecanismos de liderazgo.

SP 2.2.Establecer incentivos para la integración.

SP 2.3.Establecer mecanismos para balancear las responsabilidades de los equipos y de la organización base.


No agrega nuevos requisitos a PSMD


Al igual que en el nivel 2, se observa que el estándar PSM y su implementación mediante el producto PSM Dashboard satisfacen las necesidades de mediciones de las áreas de proceso correspondientes al nivel 3 de CMMI, Se derivaron requisitos menores que serán considerados en la especificación del producto relacionados con los siguientes aspectos:

- Medición del retrabajo

- Medición de la densidad de defectos

- Medición del tamaño de la documentación

- Medición del perfil de la verificación y la validación (Realizado vs. Planeado)


Página 82

- Medición de la cantidad de propuestas de mejora

- Mediciones de efectividad del entrenamiento

- Disparo de Workflows por umbrales (IPM)

- Medición de la exposición al riesgo, cantidad de riesgos por estado, ocurrencia de riesgos no previstos

- Medición de las habilidades y conocimientos disponibles (IT)

3.2.6.3 Requisitos del nivel de madurez 4 Desempeño de los Procesos de la Organización (OPP)

El propósito de esta área de proceso es establecer y mantener una comprensión cuantitativa del desempeño del conjunto estándar de procesos de la organización en el soporte de los objetivos de calidad y desempeño, y proveer los datos, líneas de base y modelos de desempeño del proceso para gestionar cuantitativamente los proyectos de la organización.

Esta Área de proceso considera el tratamiento estadístico de los procesos, por lo que agrega a PSM Dashboard el requisito de poder brindar a las mediciones tal tratamiento estadístico empleando técnicas de Control Estadístico de Procesos (SPC).

SG 1. Establecer líneas de base y modelos

SP 1.1. Seleccionar procesos.

SP 1.2. Establecer mediciones de desempeño de los procesos.

Esta Subpráctica recomienda la selección de mediciones para el monitoreo del desempeño de los procesos y de la calidad, en relación con los objetivos de la Organización. PSM Dashboard, con las inclusiones de las mediciones relacionadas con la GP 2.8 de cada AP a sus librerías, provee todas las mediciones necesarias.

SP 1.3. Establecer objetivos de calidad y desempeño de los procesos.

PSMD permitirá el establecimiento de Objetivos para cualquiera de sus mediciones

SP 1.4. Establecer líneas de base del desempeño de los procesos.

PSMD permitirá el establecimiento de líneas de base para cualquiera de sus mediciones. Estas líneas de base serán generadas a partir del análisis de mediciones realizadas.

SP 1.5. Establecer modelos de desempeño de los procesos.

Los modelos de desempeño se registran en PSM Dashboard en forma de estimadores, que relacionan diferentes mediciones, por ejemplo Tamaño funcional para predecir el tamaño físico, ver detalles en 3.1.4.3.2 Estimación

Gestión cuantitativa de los proyectos (QPM)

El propósito de esta área de procesos es gestionar cuantitativamente los procesos definidos del proyecto para lograr los objetivos de calidad y de desempeño de los procesos del proyecto.

Esta Área de proceso también considera el tratamiento estadístico de los procesos, y menciona el empleo de herramientas estadísticas como gráficos de control, intervalos de confianza y prueba de hipótesis. PSM Dashboard incluirá


Página 83

el tratamiento estadístico empleando técnicas de Control Estadístico de Procesos (SPC).

SG 1. Gestionar cuantitativamente el proyecto

SP 1.1. Establecer los objetivos del proyecto.

PSM Dashboard permitirá establecer objetivos para todas sus mediciones

SP 1.2. Componer el proceso definido.

SP 1.3. Seleccionar los procesos que serán gestionados estadísticamente.

SP 1.4. Gestionar el desempeño del proyecto.

SG 2. Gestionar estadísticamente el desempeño de los subprocesos

SP 2.1. Seleccionar las mediciones y las técnicas analíticas a ser usadas en la gestión estadística de los subprocesos seleccionados.

Las definiciones de las mediciones, los mecanismos de recolección, la trazabilidad con los objetivos y la recolección automática son soportados por PSM Dashboard.

La identificación de las técnicas estadísticas apropiada requiere de PSM Dashboard la capacidad de aplicar las técnicas estadísticas mas empleadas, por lo que se adopta el Control estadístico de procesos (SPC)

SP 2.2. Aplicar métodos estadísticos para la comprensión de la variación.

Esta práctica describe el uso de técnicas estadísticas para la comprensión de las causas de las variaciones, incluyendo las acciones correctivas. Las herramientas de control estadístico y las herramientas de análisis y reporte de PSM Dashboard permiten cubrir todos los requisitos de mediciones de esta práctica.

SP 2.3.Monitorear el desempeño de los subprocesos seleccionados.

PSM Dashboard debe incluir las herramientas necesarias para realizar en forma estadística el monitoreo del desempeño de los procesos, por ejemplo, debe ser posible determinar la probabilidad de que el proceso cumpla con los objetivos de desempeño previstos.

SP 2.4.Registrar los datos de gestión estadísticos.

PSM Dashboard contará con la capacidad de almacenar los datos estadísticos en el repositorio de mediciones, asociado con los valores de la medición correspondiente.


Incluir en la librería de PSM Dashboard, mediciones que permitan controlar el proceso QPM, por ejemplo:

Perfil de subprocesos bajo gestión estadística (por ejemplo cantidad de subprocesos gestionados estadísticamente vs. Cantidad planeada)

Cantidad de causas especiales de variación identificadas.


En el nivel 4 requiere de PSM Dashboard la capacidad de procesar mediante métodos estadísticos los datos de las mediciones:

- Empleo de técnicas de Control Estadístico de Procesos (SPC)

- Monitoreo estadístico del desempeño de los procesos, por ejemplo, debe ser posible determinar la probabilidad de que el proceso cumpla con los objetivos de desempeño previstos.


Página 84

- Establecimiento de objetivos para todas las mediciones.

- Establecimiento de líneas de base para todas las mediciones.

- Almacenamiento de los datos estadísticos en el repositorio de mediciones, asociado con los valores de la medición correspondiente

Además PSMD debe permitir el monitoreo de los procesos del nivel 4, para los cual se incluirán las siguientes mediciones:

- Perfil de subprocesos bajo gestión estadística (por ejemplo cantidad de subprocesos gestionados estadísticamente vs. Cantidad planeada)

- Cantidad de causas especiales de variación identificadas.

3.2.6.4 Requisitos del nivel de madurez 5 Innovación Organizacional y despliegue (OID)

El propósito de esta área de proceso es seleccionar y desplegar mejoras innovadoras que en forma mensurable mejoran los procesos y la tecnología de la organización. Las mejoras soportan los objetivos de calidad y desempeño de los procesos que se derivan de los objetivos de negocios de la organización.

SG 1. Seleccionar las mejoras

SP 1.1. Recolectar y analizar propuestas de mejora.

En esta práctica, PSM Dashboard brinda la información necesaria para decidir que procesos mejorar y realizar análisis de costo beneficio

SP 1.2. Identificar y analizar innovaciones.

SP 1.3. Realizar pilotos de las mejoras.

SP 1.4 Seleccionar las mejoras que serán desplegadas

SG 2. Desplegar las mejoras

SP 2.1. Planear el despliegue.

SP 2.2. Gestionar el despliegue.

SP 2.3. Medir el efecto de las mejoras.

PSMD debe permitir la realización de mediciones del costo, esfuerzo y plazo empleados en cada mejora, de la misma forma que se realizan para los proyectos. Para esto PSMD manejará la entidad “Mejora”, de manera de poder realizar mediciones asociadas con cada una de las mejoras en curso y poder presentar indicadores y realizar análisis de la misma forma que se procede con los proyectos.

PSMD debe permitir la comparación de estas mediciones antes y después de la mejora.

PSMD incluirá vistas especiales para evaluación de mejoras que incluirán, como mínimo, la siguiente información:

Indicadores relacionados con la implementación de la mejora:

Esfuerzo para la implementación

Costo de implementación

Plazo de implementación

Indicadores relacionados con la efectividad de la mejora:

Mediciones de los aspectos a mejorar antes de la mejora.

Mediciones de los aspectos a mejorar después de la mejora.


Página 85


Agregar a la librería de PSMD las siguientes mediciones:

Cambios en el desempeño de los procesos

Cambios en la calidad

Análisis Causal y Resolución (CAR)

El propósito del análisis causal y resolución es identificar causas de defectos y otros problemas y tomar acciones para prevenir su ocurrencia en el futuro.

SG 1. Determinar la causa de los defectos.

SP 1.1. Seleccionar los datos para el análisis.

SP 1.2. Analizar las causas.

SG 2. Tratar las causas de los defectos

SP 2.1. Implementar las acciones propuestas.

SP 2.2. Evaluar el efecto de los cambios.

Al igual que en OID, PSMD debe permitir la evaluación del efecto de los cambios realizados mediante el empleo de medios estadísticos.

SP 2.3. Registrar los datos.

Todos los datos relacionados con el proceso de análisis causal y resolución son almacenados en el sistema de gestión de calidad de la organización, por lo que están fuera del alcance de PSMD, con excepción de las mediciones del cambio en el desempeño de los procesos, que son registrados en el repositorio de mediciones de PSMD.


Se agregará a la librería de PSM las siguientes mediciones:

Cantidad de causas raíz eliminadas.

Cambios en la calidad o en el desempeño de los procesos por instancias de CAR.


El nivel 5 requiere de PSM Dashboard la capacidad de evaluar el costo y el beneficio de las mejoras implementadas, para lo que se requiere:

- Manejo de la entidad “Mejora”, equivalente a “Proyecto” para la agrupación de las mediciones

- Evaluación del costo de las mejoras (Esfuerzo, Costo, Plazo)

- Evaluación del beneficio de las mejoras (Valor de los indicadores antes y después de las mejoras)

- Vistas de indicadores integrados por mejora que permitan evaluar el costo y el beneficio de la mejora.

Además PSMD debe permitir el monitoreo de los procesos mediante las siguientes mediciones:

- Cambios en el desempeño de los procesos.

- Cambios en la calidad.

- Cantidad de causas raíz eliminadas.

- Cambios en la calidad o en el desempeño de los procesos por instancias de CAR.


Página 86

3.2.7 Resumen de las mediciones derivadas de modelo CMMI

Al conjunto de mediciones previsto por PSM se adicionan a PSM Dashboard las siguientes mediciones derivadas del análisis del modelo CMMI (Tabla 6):

Mediciones básicas relacionadas con el modelo CMMI

Medición Nivel CMMI

Área de Proceso

Área de Issue Categoría de

Mediciones PSM

Número de revisiones sufridas en el plan de proyecto, incluyendo mediciones de variaciones de costo, plazo y esfuerzo por revisión del plan. 2 PP

Tamaño y Estabilidad

Estabilidad de Documentos (*)

Exposición a riesgos 2 PCM

Riesgos (*) 3 RSKM

Cantidad de Riesgos por estado Ocurrencia de riesgos no previstos

3 RSKM

Cantidad de cambios realizados a los requisitos para el proveedor Variación de costo y cronograma por acuerdo con los proveedores.

2 SAM Proveedores (*)

Incluir Atributo: Retrabajo en las mediciones de costo, cronograma y esfuerzo. 3 RD


Recursos y Costo

Tamaño de la documentación generada en el proyecto, por ejemplo número de páginas 3 TS

Tamaño y Estabilidad

Tamaño Físico

Variación entre las evaluaciones de procesos planeadas y realizadas

2 PPQA



Perfil de la verificación (Cantidad de verificaciones planeadas y realizadas)

3 VER

Perfil de la validación (Cantidad de actividades de validación planeadas y realizadas)

3 VAL

Mediciones para evaluar la efectividad del entrenamiento: • Evaluaciones de Fin de Curso • Calificaciones de los asistentes • Nivel de asistencia a los cursos • Grado de aplicación • Cantidad de cursos realizados

3 OT

Cantidad de actividades de mejora propuestas e implementadas

3 OPF

Perfil de subprocesos bajo gestión estadística (por ejemplo cantidad de subprocesos gestionados estadísticamente vs. Cantidad planeada)

4 QPM




Página 87

Cantidad de causas especiales de variación identificadas.

Mejoras realizadas / Mejoras previstas 5 OID Desempeño del

Proceso


Cantidad de causas raíz eliminadas

Cambios en la calidad o en el desempeño de los procesos por instancias de CAR

5 CAR

Mediciones derivadas relacionadas con el modelo CMMI

Medición Nivel CMMI

Área de Proceso

Categoría de Mediciones PSM

Densidad de Defectos

3 RD, TS

Calidad del producto

Correctitud Funcional

Tabla 6

(*) Áreas de Issue o Categorias nuevas.


Página 88


Página 89

4 Arquitectura En este capítulo se analiza la Arquitectura del producto PSM Dashboard.

En 4.1 se define el concepto de Arquitectura y se explica la importancia de la definición y documentación de la arquitectura del sistema en las fases más tempranas de su desarrollo, en la misma sección se enumeran los factores que determinan la adopción de una determinada arquitectura.

En 0 se describen los atributos de calidad de los sistemas de software qu determinan en gran medida su arquitectura, se describen patrones arquitectónicos empleados con frecuencia en la industria del software, y describe como la aplicación de métodos como el ATAM contribuye a la selección de la arquitectura del sistema, a partir de sus atributos de calidad. La aplicación de estos métodos a PSM Dashboard concluye en la adopción de una arquitectura de Business Intelligence (BI)

En la sección 4.3 se analiza el concepto de Business Intelligence y su aplicación al producto PSM Dashboard.

4.1 Definición de arquitectura y factores determinantes. De acuerdo con la definición Base, Clements and Kazman Sw_Arch_Prac la arquitectura de un sistema es su estructura (o estructuras), las que comprenden los componentes de software, sus propiedades visibles de estos componentes, y sus interrelaciones.

La decisión sobre la adopción de una determinada arquitectura para el software y su documentación, en las fases más tempranas del desarrollo, es de gran importancia por los siguientes motivos:

• La arquitectura determina cumplimiento de los atributos de Calidad: La capacidad de un sistema de exhibir los atributos de calidad previstos, está substancialmente determinado por su arquitectura. Si un sistema requiere alto desempeño, es necesario manejar el comportamiento temporal de sus componentes y la forma en que se va a realizar la comunicación entre elementos. Si la modificabilidad es importante, es necesario asignar responsabilidades a diferentes elementos de manera que los cambios futuros tengan el menor impacto posible. Si la seguridad es importante va a ser necesario proteger la comunicación inter-elementos. Estas decisiones arquitectónicas impactan sobre diferentes atributos de calidad, muchas veces mejorando algunos aspectos en detrimento de otros (por ejemplo el encriptado de la comunicación mejora la seguridad pero hace al sistema mas lento). La definición de la arquitectura permite predecir cuales serán los atributos de calidad de un aplicativo o sistema.

• Define en una fase temprana las decisiones sobre el sistema: Estas decisiones tendrán un impacto profundo sobre todas las actividades de ingeniería subsecuentes, y en última instancia, determinarán el éxito del sistema como una entidad operacional.

• Facilita la comunicación entre Stakeholders: Permite que todas la partes involucradas en el desarrollo (Stakeholders) logren una visión compartida que permite un entendimiento mutuo, facilitando la negociación, el consenso y la comunicación.

• Define las restricciones en la implementación: La arquitectura divide el sistema en elementos que van a interactuar mutuamente para lograr el funcionamiento previsto. Esta separación permite tomar decisiones que permitan la mejor asignación de recursos durante la implementación, restringiendo la participación


Página 90

de cada especialista a los elementos en los que tenga mayor habilidad y experiencia.

• Determina la estructura de la organización: El método habitual de abordar el desarrollo de un sistema es dividir las actividades en tareas más pequeñas (WBS: Work Breakdown Structure) dedicadas al desarrollo de cada una de las partes en que el sistema se divide. Como esta subdivisión del sistema en partes menores está dada por la su arquitectura, esta define la WBS y, finalmente, la organización del equipo de trabajo.

• Mejora la gestión de los cambios: Es conocido que gran parte del costo del costo de un sistema de software (aproximadamente un 80%), ocurre después de finalizada la primera implementación. Una vez desplegado el sistema, los cambios subsecuentes pueden clasificarse en Locales, no Locales o Arquitecturales. Un cambio local requiere modificaciones en un único elemento, un cambio no local requiere cambios en múltiples elementos, mientras que uno Arquitectural afecta aspectos fundamentales relacionados con la estructura del sistema. Obviamente los cambios locales son los más deseable y es el resultado de una buena arquitectura lograr que los cambios sean de este tipo.

• Facilita la evolución de prototipos: Una vez que la arquitectura ha sido definida es posible construir un prototipo con el esqueleto del sistema, y esto puede hacerse en fases muy tempranas del ciclo de vida del desarrollo. A este esqueleto pueden agregarse en fases tempranas versiones preliminares de funcionalidad, cuya temprana validación reduce los riesgos del proyecto.

• Permite la realización de estimaciones de costo y plazo más exactas: Las estimaciones son un aspecto fundamental para la planificación de proyectos y para el posterior monitoreo y control de proyectos. Las estimaciones basadas en un claro entendimiento de las partes que conforman el sistema son, inherentemente, mas exactas que aquellas realizadas solamente con un conocimiento global del sistema a desarrollar, ya que cada equipo focalizará en la estima de los elementos que les corresponderá desarrollar.

• Facilita el re-uso de los componentes de una aplicación: La definición formal de la separación de las funcionalidades en módulos permite el empleo de algunos de estos módulos para desarrollar nuevas aplicaciones, reduciendo costos y plazos de desarrollo. Este es un concepto básico para la definición de líneas de productos.

• Los sistemas pueden ser construidos empleando componentes desarrollados externamente: El análisis de la arquitectura del sistema, permite analizar alternativas de integración que no necesariamente impliquen que todas las funcionalidades serán programadas. El empleo de componentes externos existentes (COTS: Commercial of the shelf software) puede significar importantes ahorros de tiempo y esfuerzo de desarrollo.

Es también importante comprender cuales son los factores que influyen en la determinación de la arquitectura de un sistema:

En su libro “Software Architecture in Practice” Base, Clements and Kazman mencionan los siguientes factores como determinantes de la selección de la arquitectura:

• La arquitectura está determinada por los stakeholders: Muchas personas en la Organización están involucradas en el desarrollo de un nuevo producto y tienen diferentes expectativas e intereses, en la sección 4.2.4 se analizan los atributos de calidad que pueden derivarse de los diferentes Stakeholders involucrados en el desarrollo del producto PSM Dashboard.


Página 91

• La arquitectura está determinada por la organización que realiza el desarrollo: La estructura y naturaleza de la organización, las áreas de tecnología en las que posee mayor experiencia, la disponibilidad de recursos (incluyendo componentes y herramientas disponibles), y las restricciones de tiempos y plazos son factores que influyen en la arquitectura del producto a desarrollar.

• La arquitectura está influenciada por la experiencia y conocimientos de los arquitectos: Si un arquitecto ha obtenido muy buenos resultados en proyectos anteriores empleando una determinada arquitectura (por ejemplo Objetos Distribuidos o Invocación Implícita), es muy probable que en nuevos proyectos de naturaleza similar tienda a emplear el mismo enfoque.

4.2 Selección de la Arquitectura Como se explicó anteriormente los atributos de calidad determinan la elección de la arquitectura para el desarrollo de un producto de software. Para realizar esta selección existen métodos estructurados como ATAM y QAM, si bien la realización formal del proceso de selección se encuentra fuera del alcance de este trabajo se describen los principales aspectos para la selección de la Arquitectura:

• Atributos de Calidad (4.2.1)

• Patrones Arquitectónicos (4.2.2)

• Evaluación de Arquitecturas (4.2.3)

• Arquitectura seleccionada para PSM Dashboard (4.2.4)

4.2.1 Atributos de Calidad Los atributos de calidad de un sistema se derivan en general de las expectativas de los diferentes stakeholders que participan en el desarrollo, y determinan en gran medida la arquitectura a adoptar.

En esta sección se listan los atributos de calidad que aplican a cualquier sistema

Atributos de calidad relacionados con la ejecución

Desempeño: El tiempo de respuesta, la utilización y el rendimiento del sistema.

Seguridad: Es una medida de la capacidad del sistema de resistir accesos no autorizados.

Disponibilidad: Es la medida del tiempo en que el sistema está funcionando correctamente, que se relaciona con la cantidad de tiempo entre fallas y el tiempo necesario para recuperar al sistema de una falla.

Usabilidad: La facilidad de uso del entrenamiento a los usuarios finales del sistema.

Interoperabilidad: La capacidad de dos o mas sistemas de cooperar en tiempo de ejecución.

Atributos de calidad no relacionados con la ejecución

Modificabilidad: La facilidad para realizar cambios en el software.

Portabilidad: La capacidad de un sistema de funcionar en diferentes ambientes computacionales.

Reusabilidad: La capacidad de emplear el software existente en futuras aplicaciones.

Integrabilidad: La habilidad de hacer que componentes que fueron desarrollados separadamente funcionen correctamente juntos.


Página 92

Testeabilidad: La facilidad con la cual se puede hacer que el software sea probado para detectar sus fallas.

Atributos de calidad relacionados con el Negocio

Costo y Plazo: El costo de desarrollo del Software y el tiempo necesario para que el producto esté disponible para desplegarlo comercialmente (time to market)

Marketabilidad: La capacidad de diferenciar el producto frente a otras opciones disponibles en el Mercado.

Adecuación para la Organización: Adecuación del software para los Recursos Humanos de una Organización, considerando so preparación y alineamiento.


Página 93

4.2.2 Patrones Arquitectónicos Existen virtualmente infinitas formas de combinar elementos para integrar un producto de Software. De la misma forma que en otras disciplinas de Ingeniería mas maduras, en la Ingeniería de Software se busca estandarizar un conjunto de arquitecturas probadas que sean adecuadas para dar solución a la mayoría de los problemas planteados. La Tabla 7 resume los estilos Arquitectónicos de uso mas frecuentes.

Estilo Arquitectónico Ventajas Desventajas

Pipes and filters (cañerías y filtros): Este patrón se compone de flujos de datos (cañerías) y elementos que realizan transformaciones sobre estos datos (cañerías)

Reuso: los filtros son fácilmente reusables en otras aplicaciones.

Modificabilidad : Es fácil actualizar el software agregando nuevos filtros

Desempeño: Los procesos tienden a ser por lotes (batch) lo que es inadecuado para sistemas interactivos.

Diseño Orienta a Objetos: Los requisitos y el diseño se organizan por objetos y sus tipos abstractos. Los objetos ocultan sus métodos y datos (encapsulamiento)

La comunicación entre objetos se realiza mediante mensajes

Ocultamiento de los detalles de implementación permite que el objeto sea afectar a sus clientes.

Herencia: los objetos heredan los métodos de clases mas abstractas.

Reuso: Se promueve la separación de preocupaciones.

Para que un objeto interactúe con otro es necesario conocer su identidad.

Si se cambia el ID de un objeto no va a ser reconocido por otros objetos que lo invocan.

Invocación implícita: Un componente anuncia que uno o más eventos ha tenido lugar, otros componentes pueden asociar un procedimiento con aquellos eventos (registrando el procedimiento) y el sistema invoca a todos los procedimientos registrados.

Reuso: es fácil reusar componentes de otros sistemas porque cualquier componente puede registrarse a un evento. Un componente puede ser agregado y registrado, en forma independiente de otros componentes.

No existe seguridad de que algún componente vaya a responder a un evento

Testeabilidad; La dependencia del contexto y secuencia de los eventos hacen muy difícil probar el sistema

Organización en Capas: Cada capa provee servicios a la capa exterior y es cliente de la capa interior.

El diseño incluye protocolos que explican cómo cada par de capas interactúa.

Cada capa puede ser considerada como un nivel de abstracción

Los diseñadores pueden descomponer el problema en una secuencia de pasos mas abstractos.

No siempre es posible estructurar el sistema en capas

El desempeño del sistema puede degradarse por la necesidad de coordinación entre capas y la necesidad de atravesar varias capas.

Repositorio Blackboard:

Componentes:

Estructura de datos central (Repositorio)

Colección de componentes independientes: Fuentes de conocimiento

La invocación de la fuente de conocim iento es determinada por el estado del blackboard

Apertura: La representación de los datos está disponible para todas las Fuentes.

Los datos compartidos deben estar en un formato reconocible para todas las fuentes.

Cliente – Servidor:

El servidor contiene el procesamiento y los recursos de datos requeridos por el cliente

Fuerte soporte del reuso

Soporta operación simultanea

Complejidad Desempeño por transmisión de Datos Seguridad

Tabla 7


Página 94

4.2.3 Evaluación de Arquitecturas: ATAM Si bien el desarrollo de una evaluación formal de la arquitectura de PSM Dashboard se encuentra fuera del alcance de este trabajo, los métodos aplicables como el ATAM, son válidos para esta decisión en una implementación comercial del producto, por lo que se incluye una breve descripción del método mencionado.

En la medida que el tamaño de la aplicación aumenta, la evaluación de su arquitectura se vuelve más complicada, en primer lugar porque la complejidad de su arquitectura también se incrementa, y en segundo término porque es necesaria la participación de un mayor número su stakeholders, cuyas necesidades y opiniones, deben ser consideradas. Estos requerimientos son muchas veces contradictorios por lo que es necesario acercar las posiciones mediante la elaboración de soluciones de compromiso (tradeoffs) hasta lograr una propuesta consensuada.

ATAM (Architecture Tradeoff Analysis Method) es un procedimiento estructurado para elicitar los objetivos de calidad de un sistema y su arquitectura, y promover la participación de los Stakeholders para focalizar en los aspectos de la arquitectura que son centrales para el cumplimiento de dichos objetivos.

El concepto básico del ATAM es que los estilos arquitectónicos elegidos serán determinantes en el cumplimiento de los objetivos de calidad del sistema.

En forma resumida el ATAM se desarrolla mediante los siguientes pasos: Fases del ATAM - Presentación

1. Presentación del ATAM. El método es explicado a los stakeholders (típicamente representantes del cliente, el arquitecto o equipo de arquitectura, <representantes de los usuarios, representante del equipo de mantenimientos, administradores, gerentes, testers, integradores, etc.)

2. Presentación de los drivers del negocio. El gerente del proyecto explica cuales objetivos del negocio motivan desarrollo y por lo tanto cuales serán los principales drivers arquitecturales. (Por ejemplo la Alta Disponibilidad, el tiempo para que el producto esté en el mercado, o la alta seguridad).

3. Presentación de la Arquitectura. El Arquitecto describe la arquitectura propuesta, focalizado en la forma en que esta arquitectura trata a los drivers del negocio.

- Investigación y Análisis

4. Identificación de las propuestas arquitectónicas. Los enfoques arquitectónicos son identificados por el arquitecto, pero no son analizados.

5. Generación del árbol de utilidad de los atributos de calidad. Los factores de calidad que representan la utilidad del sistema (desempeño, disponibilidad, seguridad, Modificabilidad, etc.) son elicitados, especificados a un nivel de escenarios, registrados con la inclusión de estímulos y respuestas, y priorizados. Estos aspectos se documentan mediante el árbol de utilidad de los atributos de calidad.

6. Análisis de los enfoques arquitectónicos. A partir de los factores de más alta prioridad identificados en el paso 5, se elicitan y analizan los enfoques arquitectónicos que tratan estos factores.

(Por ejemplo, en un enfoque Arquitectónico que apunta a cumplir con los objetivos de desempeño se analiza que tan bien satisface este requisito). Durante este paso se relevan los riesgos arquitectónicos, los puntos sensibles, y se identifican las soluciones de compromiso.


Página 95

- Testing

7. Brainstorm y priorización de escenarios. Tomando como base los escenarios definidos en el árbol de utilidad de los atributos de calidad (paso 5) se elicita un conjunto mayor de escenarios con la participación de todos los Stakeholders. Este conjunto de escenarios es priorizado mediante un proceso de votación que involucra a todo el grupo de stakeholders.

8. Análisis de los enfoques arquitecturales. Este paso reitera al 6, pero en este caso los escenarios priorizados en el paso 7 son considerados como casos de prueba para el análisis de los enfoques arquitecturales propuestos. En esta actividad pueden surgir enfoques de arquitecturas adicionales, riesgos, puntos sensibles y puntos de compromiso que deben ser documentados.

- Reporte

9. Presentación de resultados. En base a la información recolectada durante el desarrollo del ATAM (estilos, escenarios, atributos, el árbol de utilidad, riesgos, puntos sensible y soluciones de compromiso) el equipo de ATAM presenta un informe que incluye los hallazgos y las estrategias de mitigación propuestas.

Outputs del ATAM Los resultados de la actividad de ATAM son los siguientes:

• Una presentación concisa y comprensible de la arquitectura • Articulación de los objetivos del negocio • Requisitos de calidad en términos de una colección de escenarios • Mapeo de los requisitos de calidad con los requisitos de calidad • Un conjunto de puntos sensibles y de compromiso • Un conjunto de riesgos y no riesgos • Un conjunto de temas de riesgos

Flujo conceptual del proceso ATAM

Figura 27

Drivers del Negocio

Atributos de Calidad

Escenarios

Arquitectura de Software

Enfoques de Arquitectura

Desiciones de Arquitectura

Análisis

Grupos de Riesgos

Riesgos

No Riesgos

Puntos Sensibles

Compromisos


Página 96

4.2.4 Evaluación de arquitectura de PSM Dashboard Sin incluir dentro en el alcance de este trabajo el desarrollo formal del proceso de ATAM, se describen algunos aspectos de su aplicación.

1. Presentación del ATAM

Se realiza una presentación del proceso ATAM a los participantes:

Know Edge : Gerente de Ingeniería, Gerente de Marketing

Soft Star : Arquitecto, Gerente de Proyecto, Gerente de Desarrollo

Representantes de los clientes de Know Edge

Representantes de los Usuarios.

Metrix : Consultor Líder

2. Presentación de los drivers del negocio

El gerente de proyecto expone los objetivos del proyecto, descriptos en la sección “2” (Contexto del proyecto) de este trabajo. En esta actividad pueden listarse los objetivos y atributos de calidad, que pueden derivarse de los intereses de los diferentes stakeholders, que en el caso de PSM Dashboard se resumen en la siguiente lista:

• Gerente de Marketing de Know Edge: Que PSMD aventaje a productos de la competencia en costos y funcionalidades, que cuenten con una estética atractiva, que logre un rápido time to market y que se integre con otros productos de BI, especialmente sistemas de información provistos por Know Edge.

• Gerente de Despliegue de Know Edge: Facilidad en la instalación y en el mantenimiento, actualización automática.

• Clientes de Know Edge: Bajo costo, rápida entrega, Integración con otros productos de BI.

• Usuarios finales: Facilidad de aprendizaje, desempeño, seguridad, confiabilidad, concurrencia.

• Gerente de desarrollo de Soft Star: Empleo de tecnologías conocidas, ocupación del personal disponible, bajo costo de desarrollo.

Las necesidades mencionadas anteriormente permiten derivar los atributos de calidad del producto, y estos deben ser considerados y priorizados con el objeto de definir la arquitectura más apropiada.

3. Presentación de la Arquitectura. El Arquitecto describe la arquitectura propuesta, focalizado en la forma en que esta arquitectura trata a los drivers del negocio.

En el caso de PSM Dashboard el Arquitecto ha elegido, considerando la naturaleza centrada en datos del producto un Repositorio Blackboard entre los estilos Arquitectónicos mencionados en la Tabla 7.

Esta propuesta de Arquitectura se basa fundamentalmente en los fuertes requisitos de interoperabilidad del proyecto.

En esta fase es importante restringir la presentación del Arquitecto a una hora de duración.

4. Identificación de las propuestas arquitectónicas

En esta actividad se presentan enfoques arquitectónicos alternativos.


Página 97

5. Generación del árbol de utilidad de los atributos de calidad

Los arboles de utilidad, como el que se describe en la Figura 28 para el caso de PSM Dashboard, provee un mecanismo directo y efectivo de traducir los drivers del negocio en escenarios concretos para evaluar los atributos de calidad del sistema. Antes de evaluar la arquitectura es importante describir estos objetivos de la forma más específica y concreta. Además, es necesario comprender la importancia relativa de cada uno de estos objetivos en comparación con otros atributos de calidad, ya que en la mayoría de los casos se presentan conflictos entre diferentes atributos de calidad y es necesario contar con criterios objetivos para tomar las mejores soluciones de compromiso.

El árbol de utilidad de la contiene como raíz la utilidad del sistema como nodo raíz. El árbol es una expresión de las “bondades” del sistema. Los atributos nodos de más alto nivel son los atributos de calidad del sistema, en el caso de PSM Dashboard, los que se presentan como de mayor interés a los stakeholders son: Interoperabilidad, Usabilidad, Integrabilidad, Reusabilidad y desempeño, si bien otros como disponibilidad y seguridad podrían ser agregados en un análisis mas detallado.

El siguiente nivel en el árbol consiste en abrir cada uno de estos factores de calidad en sub-factores, por ejemplo la Interoperabilidad se descompone en “Colección de datos de diversas fuentes”, “Colección de datos de nuevas fuentes” y “Mínimo impacto sobre las fuentes” este paso tiene por objeto bajar el nivel de detalle desde una enunciación general a temas más concretos.

Estos subfactores son priorizados empleando ranking Bajo (L), Medio (M) o alto en dos aspectos: La importancia de cada subfactor y el riesgo que implica en el logro de los objetivos. (Por ejemplo: (M,H) es Importancia mediana y riesgo Alto).

El refinamiento del arbol de utilidad lleva a resultados a veces inesperados, por ejemplo, en la mayoria de los proyectos los aspectos de Seguridad y Desempeño suelen considerarse centrales para el éxito del proyecto, en PSM Dashboard, si bien estos aspectos son importantes, La Interoperabilidad y la Integtrabilidad aparecen, luego de la elicitacion y el refinamiento de los requisitos de calidad, como atributos centrales del sistema.

El Output del Árbol de Utilidad es un conjunto priorizado de escenarios que sirve para planificar las actividades del ATAM en un tiempo limitado.

El Árbol de Utilidad guía también a los evaluadores en el análisis de loe enfoques arquitectónicos, focalizando en los temas de mayor prioridad.

Además el Arbol de Utilidades sirve para especificar de modo más concreto los atributos de calidad del sistema, en su especificación de requisitos.


Página 98

Figura 28

Arbol de utilidad de PSM Dashboard

Utilidad

Interoperabilidad

Colección de datos

de diversas fuentes

Imposibilidad acceso a la fuente por cambios en políticas de acceso: Un workflow alternativo permitirá completar el proceso ETL en menos de 8 horas.

Datos no disponibles o desactualizados: Workflow alternativo para definir datos en menos de 8 horas.

Colección de datos

de nuevas fuentes

Desarrollar en menos de 4 meses hombre la herramienta Collect It para el desarrollo por el cliente de nuevos colectores.

Usabilidad Generación de

Workflows

Generación de Dashboards

Mediante la herramienta Collect It será posible desarrollar un nuevo colector en menos de 10 horas.

El administrador de PSMD o un analista de mediciones podrá generar un nuevo Dashboard en menos de una hora.

Mediante una herramienta gráfica basada en conectores e íconos que representan tareas, el administrador de PSMD o un analista de mediciones podrá generar un nuevo workflow en menos de 4 horas.

Mínimo impacto sobre las fuentes

Los procesos ETL (Extracción, Transformación y Carga) no modificarán los datos de las fuentes.

Los procesos ETL se programarán para que la extracción se realice en horarios elegidos para no degradar el desempeño de las fuentes.

Aprendibilidad Cualquier usuario aprenderá a usar el sistema mediante una capacitación de 16 horas.

Integrabilidad

Integración con Productos de BI de

Know Edge

Integración con Sharepoint

El producto tendrá una arquitectura de Business Intelligence similar a la de los actuales productos de BI de Know Edge.

Los Dashboards podrán publicarse como Web Parts de manera de facilitar su publicación en portales colaborativos de Sharepoint 2003 y 2007.

Reusabilidad

Reuso de los colectores de los Productos de BI de Know Edge

Los colectores ya desarrollados para los productos de BI de Know Edge (Por ejemplo colectores de ERPs y Bases de Datos) podrán ser empleados en PSM Dashboard sin modificaciones.

Desempeño Acceso a

Dashboards Se podrá acceder a cualquier Dashboard en menos

de 5 segundos

(H, H)

(M, L)

(M, L)

(M, H)

(M, L)

(M, L)

(H, M)

(M, M)

(H, M)

(M, L)

(M, L)

(H, M)

(M, H)


Página 99

6. Análisis de los enfoques arquitectónicos

La función principal de este paso es asociar los enfoques arquitectónicos vistos en el paso 4 con los atributos de calidad identificados en el paso 5 y analizar de qué manera los enfoques arquitectónicos prometen lograr los objetivos de calidad establecidos en el Árbol de Utilidad.

El equipo de evaluación trata cada enfoque mediante preguntas que apuntan a evaluar como cada enfoque arquitectónico resuelve los atributos de calidad.

Las preguntas son un punto de partida para la identificación de riesgos, no-riesgos, puntos sensibles y soluciones de compromiso.

Los principales outputs de esta fase son:

• Una lista de enfoques o estilos arquitectónicos, las preguntas asociadas con ellos y la respuesta del arquitecto a estas preguntas.

• Una lista de riesgos, puntos sensibles y soluciones de compromiso, cada uno de ellos asociados con los subfactores registrados en el Árbol de Utilidad.

Se incluye un ejemplo de evaluación de enfoques arquitectónicos relacionado con PSMD

Escenario: S11 (Extracción de datos faltantes, repetidos, inconsistentes o desactualizados) Atributo: Integrabilidad Ambiente: Extracción y Transformación de datos sin la calidad suficiente. Respuesta: Un workflow alternativo permitirá completar el proceso ETL en menos de 8 horas

Decisiones Arquitecturales Riesgo Sensibilidad Solución de Compromiso

Evaluación automática de Calidad de Datos de Fuentes R8 S2 T4

Decisión de Verificación Automática o manual S3

Workflow de Verificación y corrección automática de datos. S4

Workflow de Verificación y corrección manual de datos. R10 S5 T7

Razonamiento:

- El Colector se comunica con la fuente de datos y el proceso ETL realiza una evaluación de completitud, integridad, actualización y formato de los datos extraídos.

- El Proceso ETL decide si los problemas encontrados pueden ser resueltos en forma automática, o si es necesario disparar un workflow de revisión manual.

- Se establece un Workflow de verificación, formateo y corrección automático, basado en reglas.

- Se establece un Workflow de verificación, formateo y corrección manual, basado en mails al analista de mediciones designado para cada proyecto mediante la instanciación del workflow genérico.

- El workflow incluye un mecanismo de escalamiento si el Analista de Mediciones no resuelve el problema de Calidad de Datos dentro de las 8 horas (R10).

Diagrama de Arquitectura:

Extracción de Datos

Evaluación de Calidad de

Datos

Formateo y Carga de

Datos

Verificación y Corrección Automática

Verificación y Corrección

Manual Calidad

Insuficiente

Calidad Insuficiente

Calidad Suficiente

Escalamiento


Página 100

7. Brainstorm y priorización de escenarios

Una vez desarrollados todos los escenarios de la forma ejemplificada en el paso anterior se procede a la priorización de los escenarios, se elabora una lista con todos los escenarios y mediante un proceso de votación (típicamente se asigna a cada stakeholder una cantidad de votos igual al 30% del total de escenarios, por lo que si hay 18 escenarios podrá votar a 6)

Esta lista para PSM Dashboard podría tener los siguientes escenarios:

Escenario Votos

Integración con Productos de BI existentes de Know Edge 12

Reuso de Colectores de Productos de BI de Know Edge 10

Generación de Dashboards 10

Extracción de datos de calidad insuficiente 8

Generación de Workfows 8

Impacto sobre las fuentes 6

Integración con Sharepoint 4

Desarrollo de nuevos colectores por el cliente 4

8. Analizar enfoques arquitecturales

Una vez que los escenarios han sido recolectados y analizados, el arquitecto realice la tarea de mapear los escenarios de mayor ranking con las descripciones arquitecturales presentadas.

9. Presentar resultados

Finalmente la información recolectada debe resumida y presentada a los stakeholders.

En general esta presentación es verbal y acompañada con diapositivas, pero puede incluir también estar acompañada de un informe escrito más completo.

Se recapitulan los pasos del ATAM y se presentan y describen los resultados del ATAM:

Documento con los estilos o enfoques arquitectónicos adoptados.

Conjunto de escenarios y su priorización

Conjunto de preguntas basadas en atributos de calidad

El árbol de utilidad

Riesgos y no-riesgos

Puntos sensibles y soluciones de compromiso

En el caso de PSM Dashboard, y teniendo en cuenta la priorización realizada en el paso 7, los enfoques arquitectónicos se basarán en los siguientes conceptos:

• Adoptar para el repositorio de datos una arquitectura de repositorio blackboard.

• Adoptar para la aplicación PSM Dashboard una arquitectura de Business Intelligence que permita la integración con productos de Know Edge existentes. la Arquitectura adoptada se describe en 6.1.2 Arquitectura adoptada para PSM Dashboard.


Página 101

• Basar todas las transacciones del proceso de medición en Workflows, este aspecto se describe en el documento “PSM Dashboard, Especificación de Requisitos”

• Diseñar el proceso ETL en workflows alternativos para asegurar la calidad de los datos a incorporar en el repositorio de mediciones, aún en los casos en que la calidad de los datos de las fuentes sea insuficiente.

Dado que, como se analizó, la arquitectura de PSM Dashboard se apoya en los conceptos de Business Intelligence, en la sección siguiente se estudia este concepto.

4.3 Business Intelligence Como se detalla en 2.2, la mayoría de los clientes e Know Edge ya cuentan con implementaciones de Business Intelligence (BI) mediante Paneles de Control (Dashboards) publicados en portales colaborativos para que toda la organización pueda tener una visión compartida de los principales indicadores, y tomar decisiones en base a datos objetivos.

Como resultado de la evaluación de la Arquitectura para PSM Dashboard (0) surge la decisión de adoptar para el producto una arquitectura de Business Intelligence que permita la integración con productos de Know Edge existentes, de esta manera se simplifica la integración y se logra que puedan diseñarse paneles de control que combinen mediciones del proceso de desarrollo (PSMD) y otras mediciones corporativas. Por ejemplo, un Director puede estar interesado en monitorear el share de ventas de un determinado producto, y el costo de desarrollo de la última versión de este producto, o la evolución de la venta de servicios en relación con la calidad del producto en el campo.

4.3.1 Que es Business Intelligence? El término Business Intelligence (BI) incorpora el concepto de obtener información útil a partir de los datos de la organización y se refiere a una variedad de productos de software empleados para la realización de análisis a partir de datos obtenidos de diversas fuentes de datos disponibles en la organización.

Los sistemas de BI proveen a los responsables de tomar decisiones las herramientas necesarias para acceder fácilmente a los datos relevantes y realizar análisis (tales como análisis de tendencias y comparativos) de los datos a varios niveles de granularidad; por ejemplo para ver los detalles o para entender la interrelaciones entre los datos.

Mediante las herramientas actuales de BI, el personal de áreas no técnicas puede realizar análisis de datos sin la necesidad de solicitar complejos reportes al área de sistemas. Esta democratización de la información permite tomar decisiones de negocio a partir de información objetiva, en lugar de “feelings” o apreciaciones subjetivas.


Página 102

4.3.2 Características de un framework de BI, relación con PSM Dashboard.

Referencia: MS_BI

El framework que se describe es conceptual, independiente de la tecnología empleada, y cubre las principales fases, características y funcionalidades requeridas para implementar efectivamente una solución de Business Intelligence. La arquitectura conceptual de BI de la Figura 29 se compone de cinco áreas principales, y un conjunto de aspectos transversales.

Figura 29

Fuentes de Datos

Uno de los desafíos en la implementación de soluciones de BI, es que los datos provienen de diferentes sistemas. Para poder extraer datos de diversas fuentes es necesario resolver los siguientes problemas que se presentan habitualmente:

Diferentes estructuras, formatos de datos y esquemas de nombres.

Diferentes Sistemas y Bases de Datos (por ejemplo Oracle y MS SQL)

Restricciones de acceso a los datos

Volatilidad de los datos

Impacto en el desempeño de las fuentes de datos

En el Caso de PSM Dashboard el acceso a diferentes fuentes de datos es un requisito básico, ya que PSMD debe obtener datos de otros sistemas tales como:

Sistemas de Configuration Management

Sistemas de Seguimiento de Defectos

Sistemas de Control de Proyectos (Cumplimiento de hitos, etc.)

Timesheets (Para métricas de esfuerzo)

ERPs (Para obtener información de costos)

Sistemas de gestión de Calidad (Estado de resolución de problemas)


Página 103

Integración de Datos

La integración de los datos fragmentados provenientes de fuentes diversas se realiza mediante procesos ETL (Extracción, Transformación y Carga), e incluye los siguientes aspectos:

Determinación del perfil de las datos: Una vez identificada la fuente, y antes de la extracción es necesario analizar los datos de la fuente para detectar y corregir anomalías, datos aislados (outliers), datos redundantes y otras inconsistencias. Este análisis habitualmente se divide en tres análisis:

Análisis de atributos: Completitud, formato, tipo, tamaño y frecuencia de los datos.

Análisis de dependencias (o referencial): relaciones, Integridad y dependencias de acuerdo con las reglas de negocio.

Análisis de redundancia: Identificación de datos duplicados

Extracción de datos: Una vez realizado el análisis se procede a la extracción de datos significativos de las fuentes.

Almacenamiento temporal de datos: Antes de cargar los datos en el Almacén (Data Warehouse) es conveniente contar con un almacenamiento temporal, de esta forma se pueden realizar las transformaciones necesarias sin necesidad de tener que modificar los datos en las fuente (condición generalmente prohibida) y poder transferir los datos al almacén solo cuando las transformaciones y limpieza ya fueron realizadas

Transformaciones de Datos: Las transformaciones incluyen acciones tales como ordenamientos, divisiones, combinaciones, cambios de unidades, búsquedas, etc..

Limpieza de Datos: Solución a problemas frecuentes relacionados con la calidad de datos tales como: datos faltantes, valores inconsistentes, valores duplicados, violación de reglas del negocio. Durante el procesos de limpieza de datos estos problemas son identificados y corregidos.

Carga de Datos: Una vez realizadas las transformaciones y limpieza de los datos, estos se cargan en el almacén (Data Warehouse). Esta carga se realiza en forma periódica.

En el Caso de PSM Dashboard los conceptos detallados para la actividad de Integración son totalmente aplicables a PSM Dashboard, que ya fueron explicados en

3.1.4.2 (Recolección y procesamiento de datos)

Business Intelligence PSM Dashboard


Página 104

5 Extracción de datos 6 3.1.4.2.1 Recolección de datos , PSM recomienda la recolección automática de datos

Transformaciones de Datos

Limpieza de Datos

3.1.4.2.2 Verificación de datos 3.1.4.2.3 Normalización de datos Los datos deben ser verificados ya que todo el proceso de mediciones depende de su calidad. Mediante un generador de reglas de verificación PSMD verificará automáticamente la calidad de los datos.

Carga de Datos PSM Dashboard incluye el repositorio de mediciones de la organización

Almacenamiento de datos

Los datos almacenados en un almacén de datos (data warehouse) son típicamente cargados mediante el proceso ETL (Extract, Transform, Load).

El esquema para almacenar información en un almacén de datos es diferente del empleado en un sistema transaccional.

En grandes almacenes de datos, con millones de filas es habitual dividir grandes tablas y sus índices en segmentos llamados particiones.

Indexado: Una estrategia de indexado adecuada que considere el esquema de diseño, los tipos de columnas y las necesidades de almacenamiento son importantes para una operación eficiente.

Una función importante de PSM Dashboard es el almacenamiento histórico de todas las mediciones de la organización, por este motivo los conceptos y buenas prácticas descriptas en Business Intelligence para sus almacenes de datos son también aplicables para PSM Dashboard.

Análisis y presentación de datos

La capa superior de una solución de business intelligence permite a los usuarios extraer información útil a partir de los datos almacenados en el Almacén de datos (Data Warehouse)

Las soluciones de BI incluyen múltiples consultas para el análisis de estos datos que se detallan a continuación:

Análisis avanzado: Es la capacidad de procesar la información mediante algoritmos matemáticos y medios estadísticos, con el objeto de establecer patrones y poder realizar correlaciones y predicciones. Incluye también la capacidad del sistema de BI de poder explorar los datos explorando diferentes variables o cambiando la granularidad del análisis de un indicador o un conjunto de indicadores, por ejemplo:

Dashboard y Scorecards

Originalmente el término Dashboard proviene del tablero de control mediante el cual es posible visualizar rápidamente el valor de las principales variables de un vehículo (velocidad, temperatura, etc.). Este origen es importante ya que determina las principales características de cualquier Dashboard: Información actualizada (on line), simplicidad, claridad y exactitud.

En el ámbito de los negocios, el Dashboard es una herramienta de gestión empleada para evaluar visualmente el estado de los indicadores clave de la


Página 105

gestión de la organización. Los Dashboard son actualmente herramientas elaboradas por medios informáticas consistentes en cuadros que representan un conjunto de indicadores (KPI: Key Performance Indexes en Business Intelligence) mediante valores, tablas, semáforos, gráficos, tendencias, alertas u otros recursos. Las características de los Dashboards empleados en vehículos también aplican a los Dashboards usados para representar indicadores de negocios o técnicos, y su diseño de permitir que el usuario pueda, de un vistazo, obtener la información necesaria para comprender es estado de la situación y tomar las decisiones necesarias.

La herramienta Dashboard es adecuada para la representación de los indicadores relacionados con proyectos de desarrollo de software, y constituye la interface con el usuario en el producto PSM Dashboard.

En la Figura 30 se muestra un ejemplo de Dashboard

(fuente: http://www.valleyspeak.com)

Figura 30

Sorecard

Los scorecards son cuadros que muestran los objetivos estratégicos de la organización y el progreso obtenido en el logro de estos objetivos, expresado mediante mediciones que son representadas mediante semáforos.


Página 106

Los scorecards emplean escalas de tiempo mensuales o anuales (semanales en algunos casos), esta es la principal diferencia con los Dashboard, cuyo objetivo es presentar información on line de los indicadores claves (KPIs).

Un modelo muy conocido de scorecard es el Balanced Scorecard (BSC), propuesto por Norton y Kaplan, que estructura los objetivos y las mediciones en cuatro áreas:

Financiera

La perspectiva Financiera no tiene relación con las mediciones definidas en PSM, ya que el BSC establece objetivos financieros a largo plazo, mientras que PSM evalúa, a nivel de detalle, el costo incurrido en cada proyecto.

Cliente

La perspectiva del Cliente se relaciona con las mediciones de satisfacción incluidas en PSM.

Procesos de Negocios Internos

La perspectiva de los Procesos de Negocios Internos se relaciona con la mayoría de las mediciones detalladas en PSM, mediante las cuales se mide el desempeño de los procesos de desarrollo y la calidad de los productos.

Aprendizaje y Crecimiento

La perspectiva de Aprendizaje y Desarrollo se vincula con las mediciones de Personal definidas en PSM: Experiencia y Rotación del Personal

De lo expuesto surge que si bien BSC tiene claramente una orientación económica – financiera y una escala de tiempo de largo plazo, PSM Dashboard es una fuente de información útil para elaborar los indicadores de BSC, por este motivo, si bien no está prevista una integración de BSC con PSM Dashboard, este último contará con las interfaces necesarias para que cualquier producto de BSC pueda extraer de PSM Dashboard la información requerida.

En la Figura 31 se muestra un ejemplo de Balanced Scorecard.

Figura 31


Página 107


Página 108

OLAP:

Online Analytical Processing: Las herramientas OLAP permiten extraer rápida-mente información a partir de grandes cantidades de datos de naturaleza multidimensionales.

Las bases de datos configuradas para OLAP emplean modelos dimensionales, los que permite realizar consultas en tiempos muy breves.

Estas consultas se realizan mediante cubos OLAP, que permiten , basadas en cubos multidimencionales que son básicamente tablas pívot que permiten asociar cada una de las dimensiones de los datos con filas y columnas de la tabla.

Figura 32 Ejemplo de cubo OLAP

El análisis multidimensional de datos mediante cubos o tablas pívot, es también aplicable a mediciones en proyectos de desarrollo de software, por lo que se considerará la inclusión de esta funcionalidad de PSM, con lo que además, se logra una mejor integración con otras soluciones de BI existentes en la organización, permitiendo por ejemplo realizar análisis que combinen dimensiones técnicas y comerciales, por ejemplo la vinculación entre la calidad de los productos, la satisfacción de los clientes y el nivel de ventas a través del tiempo.

Conclusión del Mapeo BI – PSM Dashboard:

Se concluye que los conceptos y componentes de una arquitectura de BI son aplicables al producto PSM Dashboard.

Adoptar para PSM Dashboard una arquitectura de BI, permite que el producto se integre con otros sistemas de BI de Know Edge, ofreciendo a los usuarios una visión integrada del desempeño de sus proyectos de desarrollo de software, y otros aspectos del negocio.

UCA,

6.1ComDashque

En eCognarqu

6.1La ar

Figur

La calmala scolabfunci

, Trabajo Fin

1.1 Arqo se explic

hboard.), rese integre

sta secciónnos, MicroSitectura a a

.1.1 Arquitectura

ra 33 y con

capa de dacenamientsolución, yborativos, iones.

nal Especializ

quitectcó en 4.3.2esulta convcon otros p

n se realizaStrategy yadoptarse p

Arquitec de las solu

nsta de tres

datos queto, una capy una capala present

zación en Ing

ura de 2 (Caracterveniente adproductos d

un breve ay Microsoftpara el prod

ctura deuciones de

s capas:

incluye epa de aplicaa de presetación de

geniería de S

producrísticas de optar para

de Know Ed

análisis de t, como aducto PSM

e BusineBusiness In

el acceso ación que inentación qureportes,

Figura 3

Software

ctos de un framew PSM Dashge.

la arquitectantecedente Dashboard

ess Intelntelligence

a diversancluye todoue incluye dashboards

3

Businework de BI,board una

tura de trese para la d.

lligence de Cognos

as fuentesos los serv la integras y scorec

PSM Da

Página

ss Inte relación carquitectur

s productos definición

e de Cogs se resume

s de datoicios provisción con pcards entre

ashboard

109

elligenceon PSM ra de BI

s de BI: de la

gnos e en la

s y el stos por portales e otras

e


Página 110

6.1.1.2 Arquitectura de Business Intelligence de Micro Strategy

El producto de MicroStrategy incluye en su capa inferior la capacidad de extracción de datos de diferentes fuentes, tales como ERPs y CRMs, estos datos son integrados en un “Bus” (integrated BackPlane).

En las capas superiores se incluyen Servicios tales como Dashboards, Scorecards, reportes, cubos OLAP, herramientas de análisis y un servicio de Alertas y Notificaciones. El acceso se realiza mediante navegadores Web o programas de Office tales como Excel u otros.

La

Figura 34 resume la Arquitectura de la Solución de MicroStrategy para Business Intelligence.

Figura 34


Página 111

6.1.1.3 Arquitectura de Business Intelligence de Microsoft Microsoft propone la arquitectura de tres capas de la Figura 35

La capa inferior (BI Platform) se basa en la base de datos SQL de MS e incluye la integración de datos de diversas fuentes (por ejemplo ERPs), el almacenamiento y herramientas de reporte y análisis.

La capa intermedia incluye, como herramientas de análisis, servicios excel y el servidor Performance Point.

La capa de presentación incluye Reportes, Dashboards, Scorecards, vistas analíticas y la interfase con planillas excel. Se incluye también una herramienta de planeamiento, que se emplea para definir la línea de base con la que serán comparados los valores reales.

Figura 35


Página 112

6.1.2 Arquitectura adoptada para PSM Dashboard En la sección 4.2.4 (Evaluación de arquitectura de PSM Dashboard) se presentaron los motivos por los que resulta conveniente adoptar una arquitectura de BI para el producto PSM Dashboard.

En la sección 4.3.2 (Características de un framework de BI, relación con PSM Dashboard.) se verificó que todos los conceptos incluidos en una solución genérica de BI son aplicables a un sistema de mediciones para gestionar proyectos de desarrollo como PSM Dashboard.

En 6.1.1 (Arquitectura de productos de Business Intelligence) se analiza la arquitectura de tres productos existentes de BI.

En la Figura 36 se propone una arquitectura para el producto PSM Dashboard.

Se observa un primer nivel, externo al producto PSM Dashboard, formado por todas las fuentes de datos, que proveen a PSM Dashboard los ítems de datos correspondientes a todas las mediciones.

El producto PSM Dashboard está formado por tres capas:

La Capa de Datos incluye una base de datos con los diferentes planes de mediciones y un repositorio de mediciones estructurado como Data Warehouse. La integración de datos se realiza mediante procesos ETL (Extracción, Transformación y Carga), como se explicó en la sección 4.3.2.

La Capa de Aplicación provee todas las funcionalidades del producto, tales como la planificación de las mediciones, el procesamiento de mediciones e indicadores, la generación de reportes y el manejo de alertas. También se incluyen servicios de Scheduling y Workfows.

La Capa de Presentación incluye, al igual que otros productos de BI, diversos recursos que permiten al usuario obtener del sistema la información necesaria, siendo de especial importancia el Dashboard (Tablero de Control) y los reportes. Se incluye también la capacidad de presentar la información mediante planillas de cálculo.

En esta capa se incluye la integración de PSM Dashboard con Portales Colaborativos, esto simplifica la integración de la Interfase de Usuario de PSM Dashboard con la de otros sistemas de gestión de la organización.


Página 113

Arquitectura del producto PSM Dashboard

Fuentes de Datos

Figura 36

PSM Dashboard

Datos

Repositorio de Mediciones

ETL

Presentación

Aplicación

Elaboración y presentación

de Indicadores

Generación de reportes

Planificación de

Mediciones

Planes de Mediciones

Procesamiento de

Mediciones

Especificación de Mediciones

Gestión de Alertas

Scheduling

Workflows

Biblioteca de Mediciones

Dashboards Reportes Análisis Alertas Interfaz Excel

Integracióncon

Portales

CM Defect Tracking

QA Problems, Customer Satisfaction

Project Mngmnt,

Timesheet

SW Modeling

ERP CRM


Página 114


Página 115

7 Análisis de productos existentes En este capítulo se realiza una evaluación de productos de Software como parte del proceso de definición de requisitos de PSM Dashboard, y también para realizar un comparación que permita apreciar de que manera PSM Dashboard se diferencia de otros productos del mercado.

Los productos evaluados son:

Data Drill (Distributive Management)

Telelogic Dashboard (Telelogic)

7.1 Distributive Management: Data Drill Distributive Management se especializa en sistemas de mediciones para la gestión de proyectos de desarrollo de software, la empresa cuenta con dos productos: Data Drill Express, pensado para desplegar rápidamente un sistema de mediciones, y Data Drill Integrated, versión con mayores prestaciones, que es evaluado en este trabajo.

Se resumen las funcionalidades del producto Data Drill Integrated:

Scorecard Integrado

Colaboración y Comunicación basada en la estrategia.

• Los objetivos son visibles mediante el Balanced Scorecard para tomar las mejores decisiones.

• Presentación de una única versión de la verdad.

• Comunicación de resultados y progreso en forma consistente y objetiva.

• Asignación de responsabilidades


Página 116

Monitoreo del desempeño y el progreso.

• Acceso instantáneo a información confiable y actualizada para tomar las mejores decisiones.

• Customización de vistas para presentar la información estratégica, atendiendo a diferentes necesidades de información.

• Creación de planes y monitoreo del desempeño real contra las metas establecidas

• Resaltado mediante códigos de colores de los problemas y de los indicadores de progreso.

• Fácil acceso a los detalles e información relacionada, asi como a datos históricos.

Repositorio centralizado de desempeño

• Construcción de métricas a partir de diversas fuentes de datos y aplicaciones.

• Establecimiento de un repositorio para análisis de datos de mediciones operacionales y empresariales.

• La definición centralizada de mediciones e indicadores aseguran consistencia e integridad de la información.

• Seguridad basada en roles provee un control simple y seguro de la información

• Interface web fácil de usar para todos los usuarios, basada en técnicas de Balanced Scorecard.

Balanced Scorecard

• Uso de mediciones para describir y gestionar la estrategia organizacional.

• Mapas estratégicos presentan una representación de la relación entre causas y efectos

• Vinculación de objetivos y necesidades de información para lograr la estrategia organizacional.

• Comunicación de los objetivos clave y los resultados a todos los niveles de la organización.

Dashboards Integrados

Visualización de datos intuitiva e interactiva

• Conversión de datos “crudos” en datos bien organizados visualmente para permitir una rápida comprensión.

• Empleo de colores, alarmas e indicadores para remarcar tendencias, excepciones y cambios de estado.

• Empleo de representaciones visuales desde diagramas de torta y gráficos de barra, hasta ítems de acción vinculados a fechas y cuadros de texto.

Dashboard y gráficos accesibles y fáciles de compartir.

• Interfaz gráfica flexible permite focalizar en lo que es importante para cada usuario, evitando distracciones innecesarias

• La inclusión de comentarios en los gráficos proveen una respuesta inmediata a cada pregunta


Página 117

• Intercambio de información y colaboración fluidas entre departamentos.

• Empleo de un simple navegador Web para acceder y gestionar dashboards interactivos y métricas.

Organización de datos y análisis.

• Consolidación de datos para la extracción de información clave.

• Resumen de la información y presentación en gráficos de fácil visualización.

• Acceso a información más detallada en múltiples niveles.

• Fácil integración de información proveniente de diversas bases de datos y aplicaciones.

• Substancial reducción del trabajo manual de recolección de información y preparación de reportes.

• Presentación de vistas personalizadas ajustadas de acuerdo al rol, desde el CEO hasta los clientes.

Mediciones de desempeño integradas

Centralización del proceso de medición.

• Rápido despliegue de un proceso de medición centralizado.

• Los datos “crudos” son recolectados de diversas fuentes.

• El Software basado en Web actualiza gráficos, alarmas y el análisis en cualquier lugar, en forma instantánea.

• Integración con los procesos de gestión existentes.

Recursos para organizar y compartir las mediciones.

• Las mediciones se estructuran y filtran de acuerdo con las necesidades de cada usuario.

• Facilidad para compartir reportes y alertas empleando software basado en Web.

• Seguimiento de los últimos progresos y monitoreo de los principales indicadores.

• Facilidad para crear y compartir vistas individuales y empresarias.

• Acceso directo a detalles y análisis.

• Seguridad basada en roles.

Capacidad de comunicación mediante indicadores

• Posibilidad de elección entre una gran variedad de estilos de gráficos.

• Capacidad de formatear todos los aspectos de los gráficos, como color y estilo.

Pronósticos objetivos y análisis cuantitativo

• Alarmas definidas por el usuario

• Filtros de datos basados en reglas

• Alarmas codificadas mediante colores

• Resumen y agregación definidas por el usuario


Página 118

Recolección de datos integrados

Fácil extracción de datos.

• Ahorro de tiempo automatizando el proceso de de recolección

• La recolección programada elimina los problemas típicos en la preparación ad hoc de reportes: apuros en la recolección de datos y retrasos en la entrega de los reportes.

• La eliminación de las tareas manuales minimizan las posibilidades de errores humanos.

• Capacidad ilimitada de hacer disponible cualquier dato crítico para la toma de decisiones, a partir de cualquier fuente.

Datos centralizados y estandarizados

• Almacenamiento de datos críticos en una ubicación centralizada y segura, de forma de que todos puedan acceder a los mismos resultados.

• Reglas de recolección definidas en forma centralizada

• El acceso a información histórica permite extraer lecciones aprendidas y planificar futuros proyectos.

• La estandarización de los reportes facilita la comparación.

Combinación y comparación de datos para obtener una imagen global

• Toma de decisiones basadas en información completa provenientes de diferentes fuentes de datos.

• Mejor comprensión de las soluciones de compromiso y alternativas mediante la evaluación de opciones.


Página 119

7.2 Telelogic Dashboard Telelogic es una empresa especializada en el desarrollo de software para la gestión del ciclo de vida del desarrollo de software (Application Lifecycle Management, ALM).

Si bien su Suite incluye productos para gestionar todos los aspectos involucrados en el proceso de desarrollo de productos, Telelogic es especialmente famosa por su producto para gestión de requisitos: Telelogic Doors

Dentro de la suite para gestión del ciclo de vida del desarrollo de aplicaciones de software (ALM), Telelogic ha incluido un Dashboard con el objeto de monitorear el desempeño de los proyectos de desarrollo. Este Dashboard muestra el estado de las mediciones del proyecto a partir de datos extraídos de los diferentes productos que componen la Suite de Telelogic, o a partir de datos extraídos de otras fuentes.

Telelogic Dashboard fue diseñado para ser desplegado rápidamente, e incluye librerías con las mejores prácticas de mediciones de desempeño y cumplimiento, incluye alertas y emplea códigos de colores para facilitar la visualización del estado de los indicadores.

Telelogic Dashboard Incluye recolectores de datos para productos de la suite de Telelogic tales como Telelogic Change, Synergy y Doors, y también cuenta con interfaces genéricas para extraer información de otras aplicaciones tales como Microsoft Project y Mercury Quality Center y otras fuentes de datos.

Se resumen las funcionalidades del producto Telelogic Dashboard

Planificación del proceso de medición

Telelogic Dashboard ayuda en el proceso de la planificación de las mediciones. Permitiendo establecer los objetivos de medición, definir las mediciones, definir los procedimientos de recolección, así como los procedimientos para el reporte de las mediciones.

Dashboards con acceso a información detallada (Data Drill)

Telelogic Dashboard provee las métricas del proyecto mediante paneles de indicadores que incluyen el estado de las mediciones del proyecto y las tendencias, en todos los casos es posible acceder desde la información general hacia información más detallada.

Gestión por excepción

Cuenta con la capacidad de gestionar por excepción, presentando la información mediante alertas y alarmas solo en aquellos casos en los que sea necesario tomar una acción. Esto mejora la productividad ya que permite a los gerentes focalizar en las áreas de problema y tomar oportunamente las decisiones necesarias.

Mejores prácticas y adherencia a estándares

Telelogic Dashboard (TD) provee una librería de métricas, políticas, guías y muestras de mediciones e indicadores que permiten concretar las iniciativas de mejora de procesos. Esto permite automatizar las actividades de mediciones desde el establecimiento de objetivos, la especificación de las mediciones y procedimientos para almacenar, analizar y comunicar resultados. TD permite realizar un seguimiento del cumplimiento de las prácticas adoptadas, permitiendo la adaptación flexible y configurable de las mejores prácticas al contexto de cada organización. Estas características ayudan a mejorar la calidad y la satisfacción de los clientes y permiten verificar la adherencia a estándares (CMMI, ITIL, etc).


Página 120

Recolección y reportes automáticos

Telelogic Dashboard (TD) automatiza el proceso de recolección de datos y de generación de reportes, esto hace que los recursos del equipo de desarrollo no deban dedicar tiempo a tareas tales como recolectar información, realizar cálculos, formatear los datos, etc., y puedan focalizar su esfuerzo en actividades de desarrollo que agregan mayor valor.

Recolección de datos de múltiple fuentes

Telelogic Dashboard está diseñado para extraer información de Telelogic Change, Telelogic Synergy, y DOORS y finalmente de toda la suite ALM de Telelogic.

También puede extraer datos de fuentes de datos de terceras partes tales como aplicaciones basadas en Bases de Datos Oracle, SQL, CSV, ODBC, XML, Excel, MS Project y Mercury Quality Center.

Los colectores de datos disponibles en la versión 3.0 de Telelogic Dashboard son:

• Telelogic Change

• Telelogic DOORS

• Telelogic Synergy (CM)

• SQL, Oracle, ODBC, CSV

• Microsoft Access

• Microsoft Excel

• Microsoft Project

• Microsoft XML (ADO.Net)

• Mercury Quality Center

Interfase Web adaptable

La interfaz Web de Telelogic Dashboard facilita su despliegue del sistema a los largo de toda la organización. La interfaz provee vistas por fases que permiten focalizar en la información más relevante para cada fase del proyecto: Análisis de requerimientos, implementación, testing y despliegue

Seguridad

Es posible configurar detalladamente quien puede accede a cada aspecto de las mediciones. Esta definición puede realizarse mediante roles.


Página 121

7.3 Comparación de productos En esta sección se realiza una breve comparación de los dos productos evaluados y PSM Dashboard. La comparación se basa en la información disponible de cada producto, se limita a características generales y tiene por objetivo plantear la necesidad de comprender las características de los productos existentes en el mercado antes de establecer las especificaciones de un nuevo producto.

Del análisis realizado surge que esta actividad debería realizarse con mayor profundidad mediante la adquisición, instalación y prueba de los productos a comparar, ya que la información publicada tiene un sesgo fuertemente comercial, y no permite comprender con detalle las características de los productos, ya que los aspectos técnicos son presentados superficialmente.

De todas formas se realiza una comparación con la información disponible, a modo de práctica sobre este aspecto importante para la definición de un nuevo producto.

Aspecto Distributive Data Drill

Telelogic Dashboard

PSM Dashboard

Características generales

Dashboard para mediciones en proyectos de Software

Si Si Si

Integración con Sistemas de Gestión del negocio

Si (Balanced Scorecard)

No Si (Dashboards integrados, BI)

Repositorio de Mediciones centralizado

Si Si Si

Arquitectura de BI No No Si

Estándares y mejores prácticas

Librería de Mediciones Si Si

Si, basada en PSM y CMMI

Compatibilidad con PSM Parcial Parcial Total

Compatibilidad con CMMI Parcial Parcial Total

Planificación de mediciones

Selección de mediciones por proyecto

Si Si Si

Elaboración del documento “Plan de Mediciones”

No No Si

Planificación basada en objetivos Si Si Si

Planificación basada en riesgos e Issues

No No Si

Recolección de datos y repositorio

Recolección de datos automática Si Si Si

Limpieza y formateo de datos Si Si Si

Repositorio único de mediciones Si Si Si

Repositorio estructurado como Data Warehouse

No No Si


Página 122

Aspecto Distributive Data Drill

Telelogic Dashboard

PSM Dashboard

Presentación y análisis

Dashboards configurables por roles y personas

Si Si Si

Gestión por excepción: Presentación de indicadores según reglas

Si Si Si

Alarmas configurables Si Si Si

Generación automática de reportes Si Si Si

Scheduling para emisión de reportes

Si Si Si

Modelo de análisis estructurado para análisis causal.

No No Si

Análisis mediante cubos OLAP No No Si

Workflow para análisis y aprobaciones.

No No Si

Interfase

Interfase WEB Si Si Si

Seguridad

Seguridad por roles Si Si Si


Página 123


Página 124

8 Requisitos del producto

8.1 Ingenieria de requisitos de PSM Dashboard Este documento contiene el marco conceptual y teórico, y las actividades de investigación y análisis necesarias para el establecimiento de la Especificación de Requisitos del producto PSM Dashboard. Por este motivo, las actividades relacionadas con la elaboración de este documento y la documentación de la especificación de requisitos del producto se encuentran en el marco de la Ingeniería de Requisitos.

El proceso de Ingeniería de Requisitos incluye las siguientes actividades:

• Elicitación: Es un proceso de descubrimiento que tiene por objeto obtener la máxima información para el conocimiento de los requisitos del producto a desarrollar.

• Modelado: Es la actividad de representación de los requisitos del sistema a desarrollar y su documentación.

• Análisis: Incluye principalmente actividades de verificación y validación.

• Gestión de Requisitos: Dado que los requisitos se modifican a través del tiempo es importante gestionar estos cambios en forma efectiva.

Estas actividades incluyen las tareas que se resumen en el siguiente cuadro:

Elicitación Modelado Análisis Gestión

Identificación de fuentes de

Información Representación Verificación

Identificación de Cambios

Recolección de Hechos

Organización Validación Análisis de Cambios

Comunicación Especificación

Almacenamiento Negociación

Realización de Cambios

Tabla 8

Las actividades de este trabajo focalizaron en las dos primeras actividades: Elicitación y Modelado.

Se realiza un breve análisis del desarrollo de estas tareas en el caso del producto PSM Dashboard.


Página 125

Elicitación de requisitos de PSM Dashboard

Fuentes de Información:

Las fuentes de información identificadas y empleadas para la elicitación de los requisitos de PSM Dashboard se resumen en la Tabla xxxx

Fuente de Información

Elicitación PSM Dashboard

Personas: clientes, usuarios, expertos de dominio, otros actores

Como se mencionó en la sección 2.3 de este documento, se contrató a la empresa Metrix, expertos en la Implementación de Programas de Mediciones.

Se convocó a los principales Stakeholders, incluyendo clientes y usuarios para validar la Arquitectura y establecer los requisitos no funcionales del producto mediante una sesión de ATAM, ver capítulo 4 de este documento.

Documentos externos al Macrosistema

Se realizó un análisis de los requisitos derivados de la guía establecida por PSM (sección 3.1) y del Modelo CMMI (sección 3.2)

Software interno Dado que los clientes cuentan con el producto Know Edge Panel, se considera la capacidad de PSM Dashboard para que pueda integrarse con este sistema (capítulo 4)

Software externo En el capítulo 0 se evalúan dos productos de la competencia, para lograr una mejor comprensión del estado del arte, y asegurar la diferenciación de PSM Dashboard

Modelado de requisitos de PSM Dashboard

Las técnicas de modelado empleadas en este trabajo fueron:

Modelos UML de Casos de Uso (ver documento PSM Dashboard, Especificación de Requisitos del Producto)

Diagramas de Arquitectura

Especificaciones en lenguaje natural

La especificación de los requisitos se realizó empleando el formato de especificación sugerido por la IEEE en su estándar 830, como se detalla en la próxima sección.


Página 126

8.2 Especificación de los requisitos de PSM Dashboard

En el documento “PSM Dashboard, Especificación de Requisitos del Producto” se detallan las características del producto. Esta especificación es el documento que permitirá a Know Edge subcontratar a Soft Star el desarrollo del producto.

Como se explicó anteriormente la interrelación entre Know Edge y Soft Star se basa en la definición formal de los artefactos empleados para la realización exitosa del proceso de desarrollo. En el caso de la especificación de requisitos de productos de software, ambas empresas han adoptado el formato de especificación sugerido por la IEEE en su estándar 830.

Contar con una buena especificación de requisitos brinda los siguientes beneficios:

• El establecimiento de una base de acuerdo entre clientes y proveedores sobre las funcionalidades del software. La descripción completa de las funcionalidades del software permite a los futuros usuarios determinar si el software va a satisfacer sus necesidades.

• Reduce el tiempo de desarrollo. La preparación de la especificación de requisitos fuerza a todos los grupos involucrados en el proceso de desarrollo a considerar rigurosamente los requisitos antes de comenzar con el diseño, evitando de esta manera posteriores rediseños, re codificación y re testing.

• Provee una base realista para la estimación de costos y plazos.

• Provee una base para la verificación y la validación.

• Provee una base para el crecimiento futuro del producto.<

8.3 Introducción al estándar IEEE 830 El estándar IEEE 830 establece las pautas para documentar una especificación de requisitos de productos de software y describe el contenido y los atributos que debe poseer una buena especificación.

El estándar IEEE 830 incluye las definiciones de los términos Contrato, Cliente, Proveedor y Usuario, cuyo significado es importante en el proceso de definición de requisitos de software.

El contenido previsto por la IEEE-830 para la especificación de requisitos incluye:

Funcionalidades: ¿Que es lo que se prevé que el software haga?

Interfaces externas: ¿Cómo va el software a interactuar con las personas, el hardware del sistema y con otras aplicaciones?

Desempeño: ¿Cual es la velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación, y otras consideraciones?

Atributos: ¿Cual es la portabilidad, correctitud, mantenibilidad, seguridad y otras consideraciones?

Restricciones de diseño: Estándares que deben aplicarse, lenguajes de implementación, políticas para integridad de la base de datos, limitaciones de recursos, ambiente de operación, etc.

La IEEE 830 establece las siguientes características de una buena especificación de requisitos de software:

Correctitud: La validación de la especificación por parte del cliente y los usuarios contribuye a la correctitud de los requisitos. La consistencia con otros


Página 127

documentos (por ejemplo documentos del proyecto) también asegura la que la especificación sea correcta.

No ambigüedad: Cada requisito especificado debe tener una sola interpretación, y los términos empleados deben, también, tener una única interpretación. Para esto es importante contar con un glosario de términos que permita comprender su significado sin ambigüedades.

Completitud: Todos los requisitos del producto deben estar incluidos en la especificación.

Consistencia: No debe haber contradicciones ni inconsistencias entre diferentes requisitos de la especificación.

Verificabilidad: Todos los requisitos deben estar definidos de forma que sean verificable, esto es especialmente importante en la forma de especificar los Requisitos No Funcionales (RNF), evitando definiciones como “interfaz amigable” o “rápida respuesta”, y eligiendo definiciones concretas como “ El sistema responderá a cualquier entrada en menos de 5 segundos” o “En menos de una semana un usuario con experiencia en herramientas de oficinas empleará el sistema con una productividad de digitalización e indexación de 100 documentos por día”

Modificabilidad: La especificación debe permitir su evolución, para esto contará con una estructura bien organizada que incluirá una tabla de contenidos, un índice y las referencias cruzadas necesarias. Se evitarán las redundancias, que hacen al documento inconsistente cuando se modifica un requisito repetido, y contará con un mecanismo formal de control de cambios, que permitirá contar con un registro de los cambios realizados sobre cada requisito.

Trazabilidad: La especificación de requisitos contará con los mecanismos que permitan reconocer el origen de cada documento (Trazabilidad anterior) y su relación con los documentos subsecuentes en el ciclo de vida del proyecto (Trazabilidad Posterior)

La IEEE 830 permite también incluir requisitos mandatorios que restringen en forma severa el diseño del sistema, en muchos casos relacionados con la seguridad, tales como la separación de módulos, o las restricciones de acceso.

La estructura propuesta por la IEEE-830 para una Especificación de Requisitos de Software es la siguiente:

Tabla de Contenidos

1. Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones, Acrónimos y abreviaturas 1.4 Visión General

2 Descripción general 2.1 Perspectiva del producto 2.2 Funciones del Producto 2.3 Características de los usuarios 2.4 Restricciones 2.5 Supuestos y dependencias

3 Requisitos específicos

Apéndices

Índice.


Página 128

9 Conclusiones

En el planteo de este trabajo se ha propuesto el desarrollo de un nuevo producto: PSM Dashboard, cuya finalidad es facilitar el establecimiento de un programa de mediciones en organizaciones dedicadas a proyectos de software.

El proceso de desarrollo de un producto de software como PSM Dashboard incluye las fases de definición de requisitos, definición de la arquitectura del sistema, diseño detallado, programación y testing. En este trabajo se estableció como alcance la definición de los requisitos del producto, los que fueron documentados en “PSM Dashboard, Especificación de Requisitos del Producto”.

A partir de un análisis de las necesidades de los clientes se estableció como objetivo el cumplimiento de todos los requisitos de un sistema de mediciones conforme con los procesos definidos por PSM, y por el modelo CMMI. En las secciones 3.1 y 3.2 de este trabajo se realizó un análisis detallado de estos estándares, derivando requisitos del producto PSM Dashboard, que fueron incluidos en su especificación.

En el capítulo 4 se analiza la arquitectura de PSM Dashboard, de este estudio se extraen las siguientes conclusiones:

Los drivers del negocio y los intereses de los diferentes stakeholders permiten definir los atributos de calidad del producto, y estos son factores determinantes en la elección de su arquitectura. ATAM constituye un método ordenado y eficaz para decidir la arquitectura de un producto a partir de los drivers e intereses mencionados.

El árbol de utilidad, herramienta del método ATAM, es un recurso de gran utilidad para relacionar lo drivers del negocio y los intereses de los stakeholders con los atributos de calidad del sistema. El empleo del árbol de utilidad favorece la definición concreta y mensurable de los requisitos no funcionales en la especificación del producto. La interrelación entre ATAM y la Ingeniería de requisitos es un concepto que puede ser profundizado en futuras investigaciones.

El empleo de workflows que coordinen procesos realizados por el sistema con actividades realizadas por los usuarios es un recurso de mucha utilidad para el producto PSM Dashboard. Un análisis más detallado de las aplicaciones de los workflows puede ser objeto de futuros trabajos.

La arquitectura empleada en productos de Data Warehouse y Business Intelligence es la opción adoptada para PSM Dashboard, ya que el problema que se plantea a un sistema de mediciones en proyectos de desarrollo es similar al planteado para cualquier sistema de BI: Convertir datos crudos y dispersos provenientes de diversas fuentes, en información útil para la toma de decisiones basadas en datos objetivos y actualizados, por parte de personal no técnico.

La adopción de una arquitectura de BI permite la integración de PSM Dashboard con otros sistemas, permitiendo a sus usuarios contar con una visión integrada de todos los aspectos del negocio.

En el capítulo 7 se analizan productos similares a PSM Dashboard existentes en el mercado, este análisis permite derivar requisitos del producto y asegurar que este se diferencie en prestaciones. Se encontraron las limitaciones de un análisis basado solo en documentación del producto, y la conveniencia de la realización de evaluaciones prácticas, que no fueron incluidas en este trabajo.


Página 129

En el capítulo 8 se estudia el empleo del estándar IEEE-830 para la especificación del producto. El posterior empleo de este estándar para la documentación de los requisitos de PSM Dashboard demuestra la adecuación y vigencia de esta norma.

Finalmente se documentaron los requisitos del producto, quedando demostrada la factibilidad de definir un producto con las características de PSM Dashboard. Queda, como desafío para próximas investigaciones, la posibilidad de avanzar en las siguientes fases del desarrollo.

g


Página 130

10 Referencias [PSM03] Department of Defense and US Army, Practical Software and Systems Measurement, A Foundation for Objective Project Management, Version 4.0c, March 2003.

[UCA REQ 07]Contenidos de la Materia “Ingeniería de Requisitos”, Postgrado Especialización en Ingeniería de Software, UCA 2006

[IEEE 830] IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications

[PSM et al. 07] Systems Engineering Leading Indicators Guide, Editors Garry Roedler, Donna H. Rhodes, Developed and Published by Members of The Massachusetts Institute of Technology, INCOSE, and PSM, (June 2007, Version 1.0)

[PSM Smpl Meas] PSM, Sample Measurement Specifications, http://www.psmsc.com/SampleMeasures.asp

[SEI CMMI Web] Software Engineering Institute, Carnegie Mellon University, http://www.sei.cmu.edu/cmmi/general/index.html

[CMMI Tutorial] CMMI V1.1 and Appraisal Tutorial, Mike Phillips, CMMI Program Manager, Sponsored by the U.S. Department of defense, 2004, Carnegie Mellon University.

[CMMI Chrissis] CMMI, Guidelines for Process Integration and Product Improvement, Mary Beth Chrissis, Mike Konrad, Sandy Shrum, SEI series, Adison-Wesley. 2005

[MS BI] Business Intelligence Guidelines Conceptual Framework, Microsoft Corporation, 2006

[PC BI] Essential Guide to Analytic Dashboards, Aaron Solomon, Pro Clarity, 2005.

[Distributive Broch] Brochures descriptivos del product Data Drill Express de Distributive Management.

[Distributive CMMI] Measurement for Maturity and Process Improvement Using Data Drill Express, Distributive Management. 2006.

[Distributive Mngm] Management Overview of Data Drill Express.

[Telelogic Dashboard] Telelogic Dashboard Playbook Version 3.0, Sasha Mostofi, Telelogic, 2007.

[Sw Arch Pract] Software Architecture in Practice, By Len Bass, Paul Clements, Rick Kazman, Addison Wesley, 2003.

[Sw Arch Styles] Software Architectural Styles, David Calvert, 1996 http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html

[ATAM] ATAM: Method for Architecture Evaluation, Rick Kazman, Mark Klein, Paul Clements, CMU/SEI, 2000.


Página 131

11 Glosario

Término, Abreviatura o Acronimo

Definición

ABM Altas Bajas y Modificaciones

ALM (Application Lifecycle Managemente)

Software para gestión del ciclo de vida de la aplicación incluyendo gestión de requerimientos, de la configuración, de la calidad y todos los aspectos involucrados en un desarrollo.

Area de Issue comunes

Agrupamiento de Issues comunes de naturaleza similar, PSM establece siete Áreas.

BI Business Intelligence, Inteligencia de Negocios: Concepto que se aplica a la obtención de información útil para la toma de decisiones, a partir de los datos disponibles en la organización.

Chng Mng Gestión de Cambios

CI (Configuration Items)

Ítems de Configuración: Una agregación de productos tratados como entidades simples en la gestión de la configuración.

Cliente Es la persona o personas que pagan por el producto, y usualmente (pero no necesariamente), deciden los requisitos

CM Configuration Management

CMMI Capability Maturity Model Integration: Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software

Colectores Programas para la recolección de datos de diferentes fuentes, por ejemplo: Colector para Microsoft™ Project

Collect-It Herramienta para el desarrollo de colectores

Contrato Es un documento que establece un vínculo legal acordado entre el proveedor y el cliente. Incluye requisitos técnicos, organizacionales, de costos y de plazos para la provisión de un determinado producto

COTS Commercial off the shelf software: Software enlatado

Dashboard Panel de Control: Herramienta de gestión empleada para evaluar visualmente el estado de los indicadores clave de la gestión de la organización.

Drill Down Profundización en la comprensión de un tema mediante la obtención de mayor grado de detalle en la información de sus aspectos.

Issue Riesgos, problemas o falta de información que obstaculizan o pueden obstaculizar el logro de los objetivos de un proyecto.

Issues comunes Issues que habitualmente ocurren en actividades de desarrollo de software e integración de sistemas

Outliers Observación o medición numéricamente distante del resto de los datos. Es generalmente excluido para no provocar distorsiones en las estadísticas.

Proveedor la persona, o personas que producen un producto para el


Página 132

cliente

PSM Practical Software and System Measurement

PSM Proceso de mediciones basado para gestión de proyectos de desarrollo de software y sistemas.

PSM Dashboard Panel de control basado en PSM

PSMD Abreviatura de PSM Dashboard

Qty Mng Gestión de calidad de productos, seguimiento de defectos

RAM (Resource allocation matrix)

Matriz de alocación de recursos: definición de los roles que cada miembro del equipo va a desempeñar en cada proyecto.

SharePoint Plataforma basada en Web de colaboración y gestión de documentos de Microsoft™

SPC (Statistical Process Control)

Control estadístico de procesos: Análisis basado en técnicas estadísticas de las mediciones de desempeño de un proceso, con el objeto de identificar la causas especiales de variaciones, y mantener el desempeño del proceso dentro de los límites previstos.

Usuario Es la persona, o personas quienes operan o interactúan con directamente con el producto

WBS (Work Breakdown structure)

Desglose de un proyecto en un conjunto de actividades elementales. La WBS posee una estructura en niveles con diferente grado de detalle.

Workflow La automatización de un proceso de negocios, en su totalidad o en parte, durante la cual los documentos, información o tareas son pasadas de un participante a otro para realizar acciones, de acuerdo con un conjunto de reglas procedurales.

Download - Presentación del Trabajo Final PSM Dashboard

Top Related