Traba ajo Final Especialización en e Ingenie ería de S Software
Tema:
PSM M Dash hboard Pan nel de Contro ol para a el mo onitore eo de Proyecto os de Desarr D rollo de e Softw ware Autorr: Pablo Chocrón C Tutor: Alejandro o Bianchii
Pontifiicia Unive ersidad Católica C A Argentina Faccultad de Cienciass Fisicomatemática as e Inge eniería Carrera de Especializ E zación en n Ingenierría de So oftware C Curso: 20 006
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Tabla de Contenidos 1
2
3
Introducción .............................................................................................. 4 1.1
Alcance del trabajo ................................................................................. 5
1.2
Organización del trabajo ........................................................................... 5
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
Estándares aplicables al producto PSM Dashboard ................................................12 3.1
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
4
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
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
5
PSM: Practical Software and System Measurement .........................................12
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
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 2
UCA, Trabajo Final Especialización en Ingeniería de Software 6
PSM Dashboard
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 3
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 4
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 PSM Dashboard, basada en las recomendaciones del estándar IEEE-830. especificación de PSM Dashboard no está incluida en este documento, sino que presenta separadamente en el documento (PSM Dashboard, Especificación Requisitos del Producto)
de La se de
El trabajo se completa con las Conclusiones, que son detalladas en el capítulo 9
Página 5
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 6
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 7
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 8
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 mediciones 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 9
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 10
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 11
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 12
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.1.1
PSM Dashboard
Visión general del proceso de mediciones
La describe el proceso de mediciones establecido por PSM
Procesos técnicos y de gestión
Necesidades de información
Realimentación de los Usuarios Análisis de los resultados
Núcleo del proceso de Mediciones
Implementar el Proceso
Adaptar las mediciones
Acciones de Mejora
Plan de Mediciones
Nuevos Issues
Evaluar las mediciones
Aplicar las mediciones
Análisis de resultados y mediciones de desempeño
Alcance de 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 PSMDashboard.
•
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.
Página 13
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 14
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 15
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 16
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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
Issues Empresarios y Organizacionales
Issues del Proyecto IssuesA d Proyecto B Issues Proyecto B
Requerimientos Empresarios y Organizacionales
Requerimientos Recurrentes de Proyectos
Mediciones Integradas del Proyecto A Proyecto B Proyecto C
Requerimientos Específicos del Proyecto A Proyecto B Proyecto C
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 o
o
Proyectos individuales Grupos de proyectos (Por ejemplo los proyectos del dominio “entretenimiento”, los proyectos de “misión crítica” o “desarrollos para eventos”) 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 o o
Indicadores exclusivos de un proyecto. Indicadores correspondientes a una clase de proyecto. Indicadores correspondientes a todo el programa de proyectos.
Página 17
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.2
PSM Dashboard
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. Planes de gestión de riesgo y de gestión financiera
Características del Proyecto Necesidades de Información Acciones de Mejora
Identificar y Priorizar Issues del Proyecto
Nuevos Issues
Cambios Propuestos
Seleccionar y especificar mediciones del proyecto Cambios Propuestos
Características del Proceso
Integrar en los procesos técnicos y de gestión
Plan de Mediciones
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.
Página 18
UCA, Trabajo Final Especialización en Ingeniería de Software •
PSM Dashboard
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 19
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 proyecto
y
especificar
las
mediciones
del
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 20
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Proceso de selección de mediciones: PSM facilita la selección de mediciones mediante el siguiente proceso de asociación:
Issues Específicos
Áreas de Issues Comunes
Categorías de Mediciones
Mediciones
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.
Página 21
UCA, Trabajo Final Especialización en Ingeniería de Software Área de Issue
Cronograma y progreso
Recursos y Costo
Tamaño y estabilidad del producto
Calidad del producto
Desempeño del proceso
Efectividad de la tecnología Satisfacción del cliente
PSM Dashboard
Categoría de medición
Preguntas típicas
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?
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 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?
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?
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?
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?
Feedback del cliente
¿Se cumplen las expectativas del cliente?
Soporte al cliente
¿Con que frecuencia los clientes requieren soporte? Tabla 1
Página 22
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 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?
conjunto
de
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 23
UCA, Trabajo Final Especialización en Ingeniería de Software • •
•
PSM Dashboard
Í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 24
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.2.4
PSM Dashboard
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 25
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 # 2
9
6
6.3
Medición # 3
6
10
6.0
Medición # 4
4
8
3.2 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 26
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
• 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 27
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 resolverlo mediante Workflows).
(En
PSM
Dashboard
está
previsto
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 28
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 29
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.3
PSM Dashboard
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 30
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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
Desempeño del proceso
Portabilidad
Cumplimiento de Estándares
Usabilidad
Errores de operación
Dependabilidad, Confiabilidad
Fallas Tolerancia a fallas
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
Satisfacción del Cliente
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
Realimentación del Cliente
Resultado de encuestas
Soporte al Cliente
Pedidos de soporte
Calificación del desempeño Tiempo de soporte
Tabla 4 , continuación
Página 31
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 32
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
•
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 33
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 34
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 3.1.4.1
Parte 4: Aplicación De Las Mediciones 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.
Plan de Mediciones
Recolectar y Procesar Datos
Medición de desempeño del proceso de medición Datos
Nuevos Issues Características del Proyecto
Analizar Issues Información Preguntas
Realizar Recomendaciones
Gestión de Riesgos y Desempeño Financiero
Resultados del Análisis
Figura 5 Página 35
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.4.2
PSM Dashboard
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 36
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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
2
3
Extensión de los datos: •
¿Los datos corresponden al proyecto en cuestión?
•
¿Los datos corresponden al cronograma?
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?.
Unidades de medición •
4
5
6
7
¿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?
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.
Completitud de los datos •
¿Se cuenta con la información para cada issue?
•
¿Hay datos faltantes?
•
¿Los datos recolectados son los previstos?
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?
¿Los datos se ven demasiado uniformes? Tabla 5
Página 37
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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
3.1.4.3
Conversión aritmética: Meses hombre
<-
Conversión nominal: Requisitos
Especificación
<-
Horas Hombre / 160
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 Datos y características del Proyecto Datos del Proyecto Datos históricos
Estimación
Estimaciones Falta de Información
Planes Valores Reales
Planes
Análisis de factibilidad Riesgos Alternativas
Análisis de Desempeño Estado del Proyecto Problemas
Información y nuevos Issues Figura 6
Página 38
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 39
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 40
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 Efectividad de la Tecnología
Desempeño del Proceso
Tamaño y estabilidad del Producto Recursos y Costo Cronograma y Progreso Satisfacción del Cliente
Calidad del Producto 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.
Página 41
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Modelo de análisis estructurado (MAE) a nivel de Categorías de Medición Efectividad de la Tecnología
Desempeño del Proceso
Adecuación de la tecnología
Cumplimiento del proceso Eficiencia del proceso
Tamaño del producto y estabilidad Tamaño funcional y estabilidad
1
2
Tamaño físico y estabilidad
Recursos y costo
Efectividad del proceso
Impacto
3
4
Personal (Esfuerzo)
9 Desempeño Financiero
5
Ambiente y soporte
Cumplimiento de hitos
10 Soporte al Cliente
8
Confiabilidad
Capacidad Incremental
Cronograma y progreso
Feedback del cliente
6
10
Satisfacción del cliente Eficiencia
4
Progreso de unidades de trabajo
10
7
4
Usabilidad
Portabilidad
Correctitud Funcional
Soportabilidad Mantenibilidad
Calidad del Producto 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
Página 42
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 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.
indicadores
se
encuentran
dentro
de
valores
Página 43
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Se podrá visualizar el MAE para un rango de fechas, PSMD presentará la evolución de los semáforos, por ejemplo: 04/07
05/07
06/07
07/07
08/07
Recursos y Costos 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
Efectividad de la Tecnología
Desempeño del Proceso
Tamaño y estabilidad del Producto
Recursos y Costos
Cronograma y Progreso
Satisfacción del Cliente
Calidad del Producto
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).
Página 44
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 Efectividad de la Tecnología Adecuación de la tecnología
Desempeño del Proceso Cumplimiento del proceso Eficiencia del proceso
Tamaño del producto y estabilidad Impacto
Tamaño funcional
Efectividad del proceso
Tamaño físico y estabilidad
Recursos y costo
Personal (Esfuerzo) Desempeño Financiero
Ambiente y soporte
Cumplimiento de hitos Progreso de unidades de
Soporte al Cliente
Capacidad Incremental
Feedback del cliente
Cronograma y progreso
Satisfacción del cliente
Eficiencia
Confiabilidad
Usabilidad
Portabilidad
Correctitud Funcional
Soportabilidad Mantenibilidad
Calidad del Producto 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.
Página 45
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 “Cumplimiento 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 46
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 47
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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:
Tamaño funcional y estabilidad Tamaño físico y estabilidad
Personal (Esfuerzo) Desempeño Financiero
Ambiente y soporte
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.
Página 48
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 49
UCA, Trabajo Final Especialización en Ingeniería de Software -
Basados en tendencias.
-
Indicadores que incorporan umbrales
PSM Dashboard
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 50
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 desempeño de proyectos, para esto podrá:
para
el
monitoreo
de
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 51
UCA, Trabajo Final Especialización en Ingeniería de Software
•
PSM Dashboard
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:
Esfuerzo
1400
Horas Hombre
1200 1000 800 600 Planeado
400
Real
200
Proyecto: PSM Dashboard
Ene‐08
Dic‐07
Nov‐07
Oct‐07
Sep‐07
Ago‐07
Jul‐07
Jun‐07
May‐07
Abr‐07
Mar‐07
Feb‐07
Ene‐07
0
Datos al 06 / 11 / 2007
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
Página 52
UCA,, Trabajo Fin nal Especializzación en Ing geniería de Software S
PSM Da ashboard
•
ón de problemas específicos, ries sgos y falta a de informa ación. Identificació
•
Recomendaciones R
•
P Potenciales nuevos issues
El re eporte y la revisión de e las medic ciones debe en estar inttegrados co on el día a día del proyecto, los reportes r ad demás deb ben ser em mpleados co omo “inputt” para rev visiones perió ódicas del estado e del proyecto. p Los reportes de eben ser re evisados in nicialmente e por el ana alista de m mediciones , quien comp partirá los resultados s con el eq quipo de proyecto, es sta revisión n puede de escubrir nuev vos eventos s e informa ación cualittativa que ayudan a interpretarr y explicar mejor los datos, d Los niveles n de decisión d ne ecesitan con nocer como o se llegó a los resulta ados del an nálisis y a las s recomendaciones incluidas en el inform me, por es so, es imp portante qu ue esta inforrmación tam mbién se en ncuentre de ebidamente e documenttada. Además de la gen neración de d reportes s, PSMD co ontará con n la capaciidad de documen ntar los re esultados del análisiis de las mediciones s como no otas de análisis asociadas s a los Indicadores I s, a los Dashboard ds (Conjun ntos de indicado ores) o a las aérea as o categ gorías del MAE (Mo odelo de Análisis A Estructu urado) Estas no otas incluirá án: F Fecha de la revisión N Nombre de los revisore es Is ssues invollucrados D Descripción del análisis s R Recomendac ciones M Mecanismo de reporte El mecanismo de reporte r serrá controla ado por un workflow y consistirrá en la generaciión automá ática de da ahboards y luego el an nálisis por parte del analista a de mediiciones. La periodicida ad de estas s actividad des está de eterminada por los program mas (schedu ules). El analis sta de me ediciones recibe r una solicitu de d análisis generada por el workflow w, realiza el e análisis e incluye su us comenta arios en los s Dashboard ds y los identifica a mediante e el ícono
.
Mediante e este sisttema se lo ogra que el e resultad do del anállisis se encuentre publicad do en forma a on line co on los indica adores, das shboards o panel MAE E, y que los repo ortes se ge eneren auttomáticame ente media ante el barrrido de to odas las notas as sociadas. Es muy importante que e el workflo ow de repo orte incluya a en sus primeros s pasos la participaciión del equ uipo de des sarrollo y lluego una fase de aprobaciión la aprob bación. Cada ve ez que se incluye i una a nota de análisis a se identifica mediante el e ícono que permite una u presenttación conttextual de estos come entarios, como c se ura 19. Med diante la se elección del ícono observa en la Figu la inform mación corrrespondientte al análisiis.
se accede e a toda
Página 53
UCA,, Trabajo Fin nal Especializzación en Ing geniería de Software S
PSM Da ashboard
Anotació ón de come entarios en PSM Dashb board:
Esfuerrzo
14 400
Horas Hombre
1200 1000 800 600 Plane eado
400
Real
200
Proyectto: PSM Dash hboard
Ene‐08
Dic‐07
Nov‐07
Oct‐07
Sep‐07
Ago‐07
Jul‐07
Jun‐07
May 07 May‐07
Abr‐07
Mar‐07
Feb‐07
Ene‐07
0
Datos al 06 / 11 / 20 007 Figura 19
3.1 1.5 3.1.5.1
Parte 5: Ejemplo E os de In ndicado ores G Generac ción de Indicado I ores
Un indicador es una medición m o una com mbinación de d medicio ones que provee comp prensión so obre un tem ma o concep pto. La mayoría m de los indicadores compa aran los va alores reale es con línea as de base (Planes u objetivos). Lo os indicado ores pueden n ser repre esentados gráficament g te para facilitar su análiisis. Cuan ndo se dise eñan prese entaciones de indicad dores, es necesario n a asegurarse que la prese entación se ea clara y exacta. e Dos tareas son necesarias s para defin nir un indica ador: 1 Identific 1. car las mediciones esp pecíficas y los ítems de e datos a m mostrar 2 Definir el 2. e formato para p la pres sentación de d estos íte ems de dato os. Los indicadores s pueden representar r rse de muchas forma as, desde simples tablas de datos, hasta representacio ones gráfica as. Las representac r ciones gráfficas en general funcio onan mejor cuando se comparan datos reale es con línea as de base e, los gráfic cos muestrran tenden ncias, variancias y relaciones más claramente e que las ta ablas con números. n PSMD in ncluirá el re egistro de múltiples m lín neas de bas se para los valores pla aneados. Los indic cadores podrán repres sentar, ade emás de los valores rreales de lo os datos de la me edición, cua alquier com mbinación de d líneas de base de da atos planea ados.
Página 54
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 55
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 56
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 características:
de
PSM
Dashboard
cumplirán
con
las
siguientes
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 57
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 58
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 necesidades específicas, o crear nuevos indicadores
adaptándolos
a
sus
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 los publicados en [PSM et al. 07], 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 59
UCA, Trabajo Final Especialización en Ingeniería de Software
3.1.6
PSM Dashboard
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.
Obtener Soporte organizacional
Definir Responsabilidades
Proveer Recursos 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 responsabilidades:
los
siguientes
mecanismos
para
la
asignación
de
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)
Página 60
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 61
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 62
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 63
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 64
UCA, Trabajo Final Especialización en Ingeniería de Software
3.2.4
PSM Dashboard
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 Nivel de Madurez (1 a 5)
Área Áreade deProceso Proceso
Objetivos Objetivos Específicos Específicos
Objetivos Objetivos Genéricos Genéricos
Prácticas Objetivos Objetivos Específicas Específicos Específicos
Prácticas Objetivos Objetivos Genéricas Genéricos Genéricos
Productos de trabajo típicos
Subprácticas 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.
Página 65
UCA, Trabajo Final Especialización en Ingeniería de Software
3.2.5
PSM Dashboard
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 66
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 67
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 68
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 69
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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, considerado una Organización diferente.
cada
proveedor
será
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 70
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 71
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 Aseguramiento de la Calidad como por ejemplo:
el
-
Variación entre las evaluaciones de procesos planeadas y realizadas
-
Variación entre las evaluaciones de procesos planeadas y realizadas.
proceso
de
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 72
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 configuración.
y
mantener
un
sistema
de
administración
de
la
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 configuración.
y mantener registros describiendo cada iteración de la
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 73
UCA, Trabajo Final Especialización en Ingeniería de Software
3.2.6.2
PSM Dashboard
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 74
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 GP 2.8 Monitoreo y control del proceso -
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 75
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 GP 2.8 Monitoreo y Control del proceso 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 76
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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” GP 2.8 Monitoreo y Control del proceso 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. GP 2.8 Monitoreo y Control del proceso 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 77
UCA, Trabajo Final Especialización en Ingeniería de Software -
PSM Dashboard
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. GP 2.8 Monitoreo y Control del proceso 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 GP 2.8 Monitoreo y Control del proceso 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 78
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 GP 2.8 Monitoreo y control del proceso 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 79
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 GP 2.8 Monitoreo y control del proceso 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 80
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
SP 2.3. Revisar los acuerdos y relaciones con los proveedores GP 2.8 Monitoreo y control del proceso 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. GP 2.8 Monitoreo y control del proceso 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. GP 2.8 Monitoreo y control del proceso No agrega nuevos requisitos a PSMD Resumen del nivel de madurez 3 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 81
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
-
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 82
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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. GP 2.8 Monitoreo y control del proceso 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. Resumen del nivel de madurez 4 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 83
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
-
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 subprocesos gestionados estadísticamente vs. Cantidad planeada)
-
Cantidad de causas especiales de variación identificadas.
3.2.6.4
cantidad
de
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 84
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
GP 2.8 Monitoreo y control del proceso 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. GP 2.8 Monitoreo y control del proceso 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. Resumen del nivel de madurez 5 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 85
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 Nivel CMMI
Medición Número de revisiones sufridas en el plan de proyecto, incluyendo mediciones de variaciones de costo, plazo y esfuerzo por revisión del plan.
Área de Proceso
Área de Issue Categoría de Mediciones PSM Tamaño y Estabilidad
2
PP
2
PCM
3
RSKM
3
RSKM
2
SAM
Proveedores (*)
Incluir Atributo: Retrabajo en las mediciones de costo, cronograma y esfuerzo.
3
RD
Cronograma y Progreso Recursos y Costo
Tamaño de la documentación generada en el proyecto, por ejemplo número de páginas
3
TS
Exposición a riesgos Cantidad de Riesgos por Ocurrencia de riesgos no previstos
estado
Cantidad de cambios realizados a los requisitos para el proveedor Variación de costo y cronograma por acuerdo con los proveedores.
Estabilidad de Documentos (*)
Riesgos (*)
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 verificaciones planeadas y realizadas)
3
VER
3
VAL
de
Perfil de la validación (Cantidad de actividades de validación planeadas y realizadas) 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
Desempeño del Proceso Cumplimiento del proceso
Desempeño del Proceso Cumplimiento del proceso
Página 86
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Cantidad de causas especiales de variación identificadas. Mejoras realizadas / Mejoras previstas
5
OID
5
CAR
Cantidad de causas raíz eliminadas Cambios en la calidad o en el desempeño de los procesos por instancias de CAR
Desempeño del Proceso Cumplimiento del proceso
Mediciones derivadas relacionadas con el modelo CMMI Nivel CMMI
Medición
Área de Proceso
Categoría de Mediciones PSM
RD, TS
Calidad del producto Correctitud Funcional
Densidad de Defectos 3 Tabla 6 (*) Áreas de Issue o Categorias nuevas.
Página 87
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 88
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 89
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 90
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
•
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 desarrollados separadamente funcionen correctamente juntos.
que
fueron
Página 91
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 92
UCA, Trabajo Final Especialización en Ingeniería de Software
4.2.2
PSM Dashboard
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
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.
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 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. 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.
Modificabilidad : Es fácil actualizar el software agregando nuevos filtros 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.
Desventajas Desempeño: Los procesos tienden a ser por lotes (batch) lo que es inadecuado para sistemas interactivos. 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.
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
Cada capa puede ser considerada como un nivel de abstracción
No siempre es posible estructurar el sistema en capas
Testeabilidad; La dependencia del contexto y secuencia de los eventos hacen muy difícil probar el sistema
Los diseñadores pueden descomponer el problema en una secuencia de pasos mas abstractos.
El desempeño del sistema puede degradarse por la necesidad de coordinación entre capas y la necesidad de atravesar varias capas.
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.
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 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 93
UCA, Trabajo Final Especialización en Ingeniería de Software
4.2.3
PSM Dashboard
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,
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
- 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 Drivers del Negocio
Atributos de Calidad
Escenarios Análisis
Arquitectura de Software
Enfoques de
Desiciones de
Arquitectura
Arquitectura Compromisos Puntos Sensibles No Riesgos
Grupos de Riesgos
Riesgos
Figura 27
Página 95
UCA, Trabajo Final Especialización en Ingeniería de Software
4.2.4
PSM Dashboard
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 96
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 97
UCA, Trabajo Final Especialización en Ingeniería de Software
Colección de datos de diversas fuentes
Interoperabilidad
Colección de datos de nuevas fuentes
Mínimo impacto sobre las fuentes
Generación de Dashboards Utilidad
Usabilidad
Generación de Workflows
Aprendibilidad Integración con Productos de BI de Know Edge Integrabilidad Integración con Sharepoint
Reusabilidad
Reuso de los colectores de los Productos de BI de Know Edge
Desempeño
Acceso a Dashboards
PSM Dashboard (M, H) 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. (H, H) Datos no disponibles o desactualizados: Workflow alternativo para definir datos en menos de 8 horas. (M, L) Desarrollar en menos de 4 meses hombre la herramienta Collect It para el desarrollo por el cliente de nuevos colectores. (M, L) Mediante la herramienta Collect It será posible desarrollar un nuevo colector en menos de 10 horas. (M, H) Los procesos ETL (Extracción, Transformación y Carga) no modificarán los datos de las fuentes. (M, L) 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. (M, L) El administrador de PSMD o un analista de mediciones podrá generar un nuevo Dashboard en menos de una hora. (H, M) 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, M) Cualquier usuario aprenderá a usar el sistema mediante una capacitación de 16 horas. (H, M) El producto tendrá una arquitectura de Business Intelligence similar a la de los actuales productos de BI de Know Edge. (M, L) Los Dashboards podrán publicarse como Web Parts de manera de facilitar su publicación en portales colaborativos de Sharepoint 2003 y 2007. (M, L) 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. (H, M) Se podrá acceder a cualquier Dashboard en menos de 5 segundos
Figura 28 Arbol de utilidad de PSM Dashboard
Página 98
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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: Atributo: Ambiente: Respuesta:
S11 (Extracción de datos faltantes, repetidos, inconsistentes o desactualizados) Integrabilidad Extracción y Transformación de datos sin la calidad suficiente. Un workflow alternativo permitirá completar el proceso ETL en menos de 8 horas
Decisiones Arquitecturales Evaluación automática de Calidad de Datos de Fuentes
Riesgo
Sensibilidad
Solución de Compromiso
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:
Escalamiento
Calidad Insuficiente
Extracción de Datos
Evaluación de Calidad de Datos
Verificación y Corrección Manual
Calidad Suficiente
Calidad Insuficiente
Formateo y Carga de Datos
Verificación y Corrección Automática
Página 99
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 100
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
•
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 101
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 102
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 103
UCA, Trabajo Final Especialización en Ingeniería de Software
5
Extracción de datos
Transformaciones de Datos Limpieza de Datos
Carga de Datos
6
PSM Dashboard
3.1.4.2.1 Recolección de datos , PSM recomienda la recolección automática 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. 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 104
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 105
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 106
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 107
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
OLAP: Online Analytical Processing: Las herramientas OLAP permiten extraer rápidamente 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.
Página 108
UCA,, Trabajo Fin nal Especializzación en Ing geniería de Software S
6.1 1.1
PSM Da ashboard
Arq quitectura de produc ctos de Business Inte elligence e
Como se explic có en 4.3.2 2 (Caracterrísticas de un framew work de BI, relación con PSM Dash hboard.), re esulta conv veniente adoptar para PSM Dashboard una arquitecturra de BI que se integre con otros productos p d Know Edge. de En esta sección n se realiza un breve análisis a de la arquitecttura de tres s productos s de BI: Cogn nos, MicroS Strategy y Microsoftt, como antecedente a e para la definición de la arquitectura a adoptarse a p para el prod ducto PSM Dashboard d.
6.1.1.1
A Arquitec ctura de e Busine ess Intellligence e de Cog gnos
La arrquitectura de las solu uciones de Business In ntelligence de Cognos s se resume e en la Figurra 33 y con nsta de tres s capas: La capa c de datos d que incluye el e acceso a diversa as fuentes s de datos y el alma acenamientto, una cap pa de aplica ación que in ncluye todo os los servicios provis stos por la solución, s y una capa a de prese entación qu ue incluye la integración con portales p colab borativos, la presenttación de reportes, dashboards s y scorec cards entre e otras funciiones.
Figura 33
Página 109
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 110
UCA, Trabajo Final Especialización en Ingeniería de Software
6.1.1.3
PSM Dashboard
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 111
UCA, Trabajo Final Especialización en Ingeniería de Software
6.1.2
PSM Dashboard
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 112
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Arquitectura del producto PSM Dashboard
PSM Dashboard Presentación Integración con Portales
Dashboards
Reportes
Análisis
Interfaz Excel
Alertas
Aplicación
Generación de reportes
Scheduling
Gestión de Alertas
Elaboración y presentación de Indicadores
Planificación de Mediciones
Workflows
Procesamiento de Mediciones
Especificación de Mediciones
Datos
Planes de Mediciones
Repositorio de Mediciones
Biblioteca de Mediciones
ETL Fuentes de Datos
CM
Defect Tracking
SW Modeling
QA Problems, Customer Satisfaction
Project Mngmnt, Timesheet
ERP
CRM
Figura 36
Página 113
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 114
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 115
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 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.
estratégica,
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 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.
e
indicadores
aseguran
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 116
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
•
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 117
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 118
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 119
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 120
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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. Distributive Data Drill
Telelogic Dashboard
PSM Dashboard
Si
Si
Si
Si (Balanced Scorecard)
No
Si (Dashboards integrados, BI)
Repositorio de Mediciones centralizado
Si
Si
Si
Arquitectura de BI
No
No
Si
Si
Si
Si, basada en PSM y CMMI
Compatibilidad con PSM
Parcial
Parcial
Total
Compatibilidad con CMMI
Parcial
Parcial
Total
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 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
Aspecto Características generales Dashboard para mediciones en proyectos de Software Integración con Sistemas de Gestión del negocio
Estándares y mejores prácticas Librería de Mediciones
Planificación de mediciones
Recolección de datos y repositorio
Página 121
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Distributive Data Drill
Telelogic Dashboard
PSM Dashboard
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
Si
Si
Si
Si
Si
Si
Aspecto Presentación y análisis
Interfase Interfase WEB Seguridad Seguridad por roles
Página 122
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
Página 123
UCA, Trabajo Final Especialización en Ingeniería de Software
8
PSM Dashboard
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
Negociación
Realización de Cambios
Comunicación
Especificación Almacenamiento 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 124
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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.
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
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.
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 125
UCA, Trabajo Final Especialización en Ingeniería de Software
8.2 Especificación Dashboard
de
los
PSM Dashboard
requisitos
de
PSM
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 requisitos fuerza a todos los grupos involucrados en considerar rigurosamente los requisitos antes de evitando de esta manera posteriores rediseños, re
•
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.<
de la especificación de el proceso de desarrollo a comenzar con el diseño, codificación y re testing.
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 126
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 127
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 128
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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 129
UCA, Trabajo Final Especialización en Ingeniería de Software
10
PSM Dashboard
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 130
UCA, Trabajo Final Especialización en Ingeniería de Software
11
PSM Dashboard
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 131
UCA, Trabajo Final Especialización en Ingeniería de Software
PSM Dashboard
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. 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.
Workflow
Página 132