Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 1: Conceptos y Guía Introductoria MAYO 2009
Tabla de Contenidos 1. PREFACIO...5 1.1. ESPECIFICACIONES...5 1.2. PUBLICACIÓN...6 1.3. ESTRUCTURA DEL DOCUMENTO...6 2. PRINCIPIOS DE TRP...7 2.1. ORIENTADO A PEQUEÑAS Y MEDIANAS ORGANIZACIONES...7 2.2. ORIENTADO AL REUSO...7 2.3. ENFOQUE BASADO EN PROCESOS...7 2.4. ACORDE A LAS BUENAS PRÁCTICAS INTERNACIONALES...7 2.5. ENFOQUE ITERATIVO INCREMENTAL...8 2.6. ESTRATEGIA DE DESARROLLO...8 3. COMPONENTES DE TRP...9 3.1. TRP BÁSICO...10 3.2. TRP AVANZADO...10 3.3. FASES DE TRP...10 3.3.1. Concepción...11 3.3.2. Elaboración...11 3.3.3. Construcción...12 3.3.4. Transición...12 4. PATRÓN DE PROCESOS...14 4.1. ESPECIFICACIÓN...14 4.2. CONSIDERACIONES...15 4.3. CONVENCIONES DE ESCRITURA...16 5. DESCRIPCIÓN DE ROLES DE TRP...17 5.1. LISTADO DE ROLES...17 5.2. LISTADO DE SINÓNIMOS...19 6. DESCRIPCIÓN DE LOS ARTEFACTOS DE TRP...20 7. ARTEFACTOS Y ÁREAS DE PROCESO...26 8. RELACIÓN ENTRE TRP Y CMMI...29 8.1. MAPPING ALTO NIVEL...29 8.2. MAPPING BAJO NIVEL...30 iii
Lista de Figuras FIGURA 1. ESPECIFICACIONES DE TRP...6 FIGURA 2. PATRÓN DE PROCESOS DE TRP....14 FIGURA 3. MAPPING DE ALTO NIVEL ENTRE TRP Y CMMI....29 Lista de Tablas TABLA 1. ÁREAS DE PROCESOS, CATEGORÍAS Y PARTES....9 TABLA 2. VISTA GENERAL DE ARTEFACTOS Y ÁREAS DE PROCESOS....26 TABLA 3. MAPPING ENTRE TRP Y REQM....30 TABLA 4. MAPPING ENTRE TRP Y PP....31 TABLA 5. MAPPING ENTRE TRP Y PMC....32 TABLA 6. MAPPING ENTRE TRP Y SAM....33 TABLA 7. MAPPING ENTRE TRP Y MA...34 TABLA 8. MAPPING ENTRE TRP Y PPQA....35 TABLA 9. MAPPING ENTRE TRP Y CM...36 TABLA 10. MAPPING ENTRE TRP Y RD...37 TABLA 11. MAPPING ENTRE TRP Y TS...38 TABLA 12. MAPPING ENTRE TRP Y VER...39 TABLA 13. MAPPING ENTRE TRP Y VAL....40 TABLA 14. MAPPING ENTRE TRP Y PI...41 TABLA 15. MAPPING ENTRE TRP Y RSKM...42 TABLA 16. MAPPING ENTRE TRP Y DAR....43 TABLA 17. MAPPING ENTRE TRP E IPM...44 TABLA 18. MAPPING ENTRE TRP Y OPD....45 TABLA 19. MAPPING ENTRE TRP Y OPF...45 TABLA 20. MAPPING ENTRE TRP Y OT....46 iv
1. Prefacio TRP (Tutelkan Reference Process) ha sido desarrollado por la academia, el gobierno y la industria del software de Chile como parte del proyecto Tutelkán: Obtención de altos estándares de calidad para la industria del software 1. TRP contiene prácticas recomendadas para: gestión de proyectos, gestión de procesos, y desarrollo y mantención de software. Provee de un entorno común de trabajo a los equipos propios de una organización y a equipos conjuntos conformados con proveedores, usuarios y clientes, i.e., apoya el trabajo mancomunado de diversos grupos de personas que suelen trabajar bajo diferentes culturas, expectativas y ámbitos de conocimiento. TRP está pensado para pequeñas y medianas organizaciones y/o empresas (PyMEs), está diseñado para que sus contenidos puedan ser fácilmente reusados y adaptados, contiene prácticas que han sido probadas en proyectos reales de software, plantea un enfoque basado en procesos y en este aspecto está alineado con las mejores prácticas internacionales (CMMI 2, ISO 9001:2000 3 ), e incorpora un enfoque iterativo incremental para el desarrollo de proyectos de software. El proceso de referencia está separado en dos conjuntos de prácticas, denominados TRP Básico y TRP Avanzado. TRP Básico agrupa el conjunto de prácticas necesarias para que una organización pueda gestionar proyectos de software eficazmente. TRP Avanzado agrega a los contenidos de TRP Básico prácticas para gestión avanzada de proyectos de software, gestión de procesos, y desarrollo y mantención de software. 1.1. Especificaciones La especificación de TRP se encuentra dividida en 4 partes: TRP - Parte 1: Conceptos y Guía Introductoria. Contiene la descripción general del proceso de referencia, especifica sus principios de construcción, componentes, artefactos y roles, y su relación con CMMI e ISO 9001:2000. TRP - Parte 2: TRP Básico. Contiene la especificación de las áreas de proceso de gestión de proyectos de software. TRP - Parte 3: TRP Avanzado. Contiene la especificación de las áreas de procesos de desarrollo y mantención de software, gestión avanzada de proyectos y gestión de procesos. TRP - Plantillas y Guías. Conjunto de plantillas de artefactos y guías de ajuste de TRP. Estas partes han sido diseñadas para ser consultadas en conjunto. Adicionalmente descansan la definición de términos y conceptos importantes en el cuerpo: Tutelkán - Vocabulario: Terminología para los cuerpos TRP, TIP, TPF y TWP. Que contiene la definición unificada de términos para todos los elementos del proyecto Tutelkán. 1 www.tutelkan.org 2 Capability Maturity Model Integration, http://www.sei.cmu.edu/cmmi 3 Sistemas de gestión de la calidad - Requisitos, http://www.iso.org 5
La relación entre estas especificaciones se ilustra en la Figura 1. Figura 1. Especificaciones de TRP. 1.2. Publicación Las especificaciones de TRP se encuentran disponibles públicamente en 3 formatos: Como documentos descargables desde el sitio Web del proyecto Tutelkán, www.tutelkan.org En la plataforma Web del proyecto TWP, www.tutelkan.org/tutelkan Como plug-in de EPF 4 descargable en el sitio Web del proyecto Tutelkán, www.tutelkan.org 1.3. Estructura del Documento El capítulo 2 presenta los principios bajo los cuáles se desarrolló TRP. El capítulo 3 describe la estructura de TRP y sus principales componentes. El capítulo 4 especifica el patrón de procesos de TRP. El capítulo 5 presenta los roles de TRP. E capítulo 6 describe los artefactos de TRP. El capítulo 7 detalla la relación entre artefactos y áreas de proceso. El capítulo 8 presenta la relación entre TRP y CMMI. 4 Eclipse Process Framework, http://www.eclipse.org/epf 6
2. Principios de TRP 2.1. Orientado a Pequeñas y Medianas Organizaciones TRP ha sido pensado para ser usado por pequeñas y medianas organizaciones y/o empresas (PyMEs) productoras de software, siguiendo los principios de facilidad de uso y comprensión, y documentación mínima, es decir, permite definir la documentación necesaria y suficiente para cada tipo de proyecto a partir de un proceso definido. 2.2. Orientado al Reuso Define un proceso de software en particular, cuyas partes puedes ser reusadas y modificadas para crear otros procesos de software, permitiendo de esta manera que organizaciones puedan seleccionar elementos relevantes y adaptarlos a sus necesidades. 2.3. Enfoque Basado en Procesos Para que la producción y mantención de software se realice de forma eficaz y eficiente se debe identificar y gestionar numerosas actividades y tareas que son realizadas por equipos de trabajo. Una actividad que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados, se puede considerar como un proceso, y la identificación, implementación y gestión de estos procesos y sus interacciones puede denominarse enfoque de procesos 5. La ventaja de este enfoque es que permite formalizar las prácticas que se aplican en una organización, haciéndolas visibles y controlables, de esta manera se pueden medir, seguir y modificar, posibilitando el mejoramiento de procesos y por ende el mejoramiento de la capacidad de la organización para lograr sus objetivos de negocio (e.g., mejora de la calidad del software, satisfacción de los clientes, etc.). 2.4. Acorde a las Buenas Prácticas Internacionales TRP está alineado con las mejores prácticas internacionales. Considera las áreas de proceso de nivel de madurez 2 y 3 del modelo CMMI y las cláusulas de la norma internacional ISO 9001:2000. Esta relación se hace explicita a través de mapeos detallados entre actividades y tareas de TRP con objetivos y prácticas de CMMI y cláusulas de ISO 9001:2000. TRP incluye de esta manera prácticas para administrar proyectos eficientemente, definir procesos de software, desarrollar y mantener software, y gestionar sistemas de calidad. 5 ISO 9001:2000, Sistemas de gestión de la calidad - Requisitos, p. 6. 7
2.5. Enfoque Iterativo Incremental TRP incorpora elementos de RUP 6, lo que se ve reflejado en las fases e iteraciones del ciclo de vida de proyectos propuesta y en las plantillas de los artefactos que acompañan a la metodología. Estos elementos han sido adaptados para simplificarlos lo más posible. El enfoque también soporta la aceptación de cambios en los requerimientos y permite gestionarlos a lo largo del desarrollo. La clave radica en lograr evaluar, negociar y planificar efectivamente la incorporación de dichos cambios. 2.6. Estrategia de Desarrollo TRP tomó como línea base de desarrollo el proceso de software de la PyME chilena Kepler Technology 7, participante del proyecto Tutelkán. Esta empresa posee la certificación ISO 9001:2000 y está evaluada como CMMI Maturity Level 2 y 3. El proceso base ha sido elaborado y probado en la práctica a través de años de experiencia, siendo realimentado por usuarios y clientes en proyectos de software en Chile y Latinoamérica, e incorpora las mejores prácticas de la industria adaptas a una PyME. El proceso base fue sometido a un proceso de normalización por un grupo de expertos para que la terminología empleada en la descripción de contenidos sea entendible por cualquier organización. Dicho proceso dio como resultado la primera versión de TRP. Posteriormente se aplicaron ciclos de mejoramiento para analizar y mejorar su compatibilidad con los modelos CMMI nivel 2 y 3 e ISO 9001:2000, al mismo tiempo también fue implantado en PyMEs piloto participantes del proyecto Tutelkán para realimentar el proceso desde la práctica. Todo este trabajo da como resultado la versión 2.0 de TRP, presentada en esta especificación. 6 Kruchten, P. The Rational Unified Process: An Introduction. Addison Wesley, (1998). 7 http://www.kiteknology.com 8
3. Componentes de TRP TRP se compone de un total de 18 áreas de proceso, las que se agrupan en 3 categorías, denominadas: Gestión de Proyectos, Desarrollo y Mantención de Software, Gestión de Procesos, y Gestión Avanzada de Proyectos. La especificación de estas áreas de proceso se ha separado en 2 partes: TRP Básico, que contiene las áreas de procesos de Gestión de Proyectos, y TRP avanzado, que contiene a todas las restantes, como muestra la Tabla 1. Tabla 1. Áreas de procesos, categorías y partes. Parte Categoría Área de Procesos TRP Básico Gestión de Proyectos (GP) Administración de Requerimientos (AR) Planificación del Proyecto (PP) Monitoreo y Control del Proyecto (MCP) Administración de Acuerdos con Proveedores (AAP) Medición y Análisis (MA) Administración de Calidad de Procesos y Productos (ACPP) TRP Avanzado Desarrollo y Mantención de Software (DMSW) Gestión Avanzada de Proyectos (GAP) Gestión de Procesos (GProc) Administración de Configuraciones (AC) Desarrollo de Requerimientos (DR) Análisis y Diseño (AD) Programación (Pro) Pruebas (Pru) Instalación (Ins) Gestión de Riesgos (GR) Evaluación Formal de Decisiones (EFD) Administración Integrada del Proyecto (AIP) Definición de Procesos Organizacionales (DPO) Mejoramiento de Procesos Organizacionales (MPO) Entrenamiento Organizacional (EO) Se recomienda a las organizaciones que están dando sus primeros pasos en el campo de implementación de procesos de software, comenzar abordando las áreas de procesos de TRP Básico, pues abordan el establecimiento de prácticas básicas y efectivas de gestión de proyectos., y permiten a la organización incorporarse al uso de mejores prácticas internacionales de software de forma sencilla y con resultados más tempranos. TRP-Avanzado es super-conjunto de TRP Básico, es decir, lo contiene, y es absolutamente recomendable dominar las prácticas de TRP Básico antes de embarcarse con áreas de proceso de TRP-Avanzado. Para hacer posible la implementación de las prácticas de TRP Avanzado se asume que ya están implementadas y operando efectivamente las áreas de proceso de TRP Básico. 9
3.1. TRP Básico TRP Básico contiene prácticas recomendadas para asegurar que los proyectos de software de la organización sean gestionados eficazmente, es decir, para lograr que: Las actividades y tareas de los proyectos sean planificadas, ejecutadas y monitoreadas formalmente. Los productos de trabajo sean apropiadamente establecidos, controlados y mantenidos. Se identifiquen los riesgos del proyecto tempranamente. Se emplee personal apropiadamente capacitado. Se disponga de los recursos necesarios. Se comprometa a los involucrados relevantes. Se evalúe continuamente la calidad de los productos desarrollados y de los procesos desplegados. TRP Básico está alineado con las áreas de proceso de nivel de madurez 2 de CMMI. La especificación detallada de TRP Básico se encuentra en el documento: TRP - Parte 2: TRP Básico. 3.2. TRP Avanzado TRP Avanzado contiene prácticas recomendadas para asegurar que la organización disponga de un proceso de desarrollo de software definido, mantenido y mejorado continuamente, para lograr que: El proceso de la organización sea configurable/adaptable a las necesidades de cada tipo de proyecto que se aborda, asegurando consistencia y control de los procesos desplegados en toda la organización. Se mejore la calidad de los productos de software a través de la formalización de prácticas de ingeniería para desarrollo y mantención de software. La gestión de proyectos incorporé prácticas formales de gestión de riesgos y toma de decisiones. TRP Avanzado está alineado con las áreas de proceso de nivel de madurez 3 de CMMI. La especificación detallada de TRP Avanzado se encuentra en el documento: TRP - Parte 3: TRP Avanzado. 3.3. Fases de TRP TRP recomienda un ciclo de vida iterativo incremental basado en fases para los proyectos de software, dónde cada fase puede contener n iteraciones. Está definición de fases e iteraciones está 10
basada en la propuesta de RUP. Las fases se denominan: Concepción, Elaboración, Construcción e Instalación, como se describe en la siguiente sección. Este enfoque basado en fases e iteraciones está encarnado en la forma de planificación y monitoreo de proyectos de TRP, así como en las prácticas de desarrollo de productos de software, lo que se refleja en muchos de los artefactos y descripciones de áreas de procesos. 3.3.1. Concepción La fase de Concepción tiene por finalidad obtener la visión, es decir, identificar las necesidades del Cliente, especificar el problema y el contexto en el que se desarrolla el proyecto, y determinar el alcance y los objetivos o resultados a lograr. Esta fase captura, desde un punto de vista funcional, las características del producto, los principales requerimientos, el esfuerzo de desarrollo y el impacto en el negocio. Se exploran las áreas de alto riesgo del proyecto, comparando los esfuerzos involucrados con los beneficios en términos de negocio. Un punto clave de esta fase es la conformación del Equipo de proyecto y la identificación de todos los Involucrados, estos deberán acompañar el proyecto ejerciendo una fuerte influencia en la especificación de requerimientos, el seguimiento y control y la certificación. El grupo humano debe reconocerse como equipo de trabajo, comprender que el éxito del proyecto atañe a todos y por ende requiere del reconocimiento entre los individuos, y diferenciar entre el rol que un individuo debe cumplir en un proyecto en particular con el cargo que ocupa en la Organización. Así es posible, por ejemplo, encontrar un Jefe de proyecto que actúe como Arquitecto en algún proyecto (según se haya especificado en el artefacto Asignación de roles de ese proyecto en particular). En esta fase se definen también los artefactos a utilizar, la forma de documentar el proyecto, las interfaces de comunicación entre los involucrados, los mecanismos de aprobación de nuevos requerimientos y del producto final, las formalidades de entrega y todo aquello que se estime necesario para dar un marco formal y adecuado al proyecto. Se define y se avanza en la preparación del ambiente de trabajo, considerando servidores, estaciones de trabajo, instalación de software y otros; también se comienza con la planificación de las pruebas, su ambiente requerido y la selección de tipos de pruebas a efectuar. La fase de Concepción concluye con: el establecimiento de la visión del proyecto, su ámbito y límites funcionales, un análisis costo/beneficio, candidatos de arquitectura, requerimientos de infraestructura y la identificación de los principales riesgos que afectan al proyecto. Al final de esta fase, se decide dar inicio al proyecto o cancelar el mismo, entendiendo que la decisión de cancelar un proyecto inviable en esta fase tiene un costo mucho menor que en las fases siguientes. Al final de la fase de Concepción se deben repasar los objetivos de cada una de las áreas de procesos involucradas, para verificar su cumplimiento. 3.3.2. Elaboración La fase de Elaboración tiene como principal finalidad definir la arquitectura de la solución, siendo relevante la vista relacionada con la funcionalidad para poder realizar la implementación del producto de software en la siguiente fase, mitigando al mismo tiempo los principales riesgos. Al finalizar esta 11
fase se recomienda contar con la mayoría de los requerimientos especificados. Además es conveniente validar la arquitectura mediante la ejecución de una prueba de concepto, que idealmente involucre funcionalidades de alto grado de completitud y riesgo (se entiende por completitud que sea transversal a todas las funcionalidades). Desarrollo de requerimientos, análisis y diseño de la solución son las actividades centrales de esta fase. Los objetivos son: abordar los riesgos de arquitectura e implementación, establecer el ambiente de desarrollo y configurar (adaptar) el proceso de la Organización para las necesidades particulares del proyecto (a través del uso de guías y plantillas) y terminar de planificar las pruebas. Durante esta fase se desarrollan los componentes más riesgosos, se modela la base de datos, se solucionan problemas de comunicación y de ambientes. Es relevante trabajar en conjunto respetando las opiniones, todas las ideas deben analizarse antes de incluirlas o desecharlas. Al final de la fase de Elaboración se deben repasar los objetivos de cada una de las áreas de procesos involucradas, para verificar su cumplimiento. 3.3.3. Construcción La fase de Construcción tiene por objetivo el desarrollo de versiones del producto, generando nuevos componentes y/o reusando componentes obtenidos desde alguna biblioteca de componentes elaborados en anteriores proyectos, o inclusive elaborados en el que está en curso. El personal a cargo de la programación es responsable de realizar pruebas unitarias sobre el componente que está desarrollando. Es posible que se requieran varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso o funcionalidades, de acuerdo a los factores de riesgo del proyecto, comenzando por los de mayor riesgo, para que de esta forma se conozcan tempranamente aquellos que no se pueden mitigar o eliminar, y de lo aprendido, facilitar el resto del desarrollo. Este enfoque permite contar en forma temprana con versiones del sistema que satisfacen las principales funcionalidades. Los cambios en los requerimientos requerirán de un análisis para decidir su inclusión en la actual iteración o en posteriores iteraciones, dependiendo del impacto en el producto y en el proyecto. La consolidación de versiones entregables al final de cada iteración requiere realizar controles de calidad adecuados, a partir de la ejecución de pruebas, ya sean estas manuales o a través del uso de herramientas de testing. Al final de la fase de Construcción se deben repasar los objetivos de cada una de las áreas de procesos involucradas, para verificar su cumplimiento. 3.3.4. Transición La fase de Transición culmina con el producto operando en condiciones de régimen, para lo cual se requiere establecer el ambiente adecuado y controlar la integración. Se deberá entregar documentación sobre el uso e instalación del producto. 12
Como en el resto de las fases, surgirán propuestas de cambios en los requerimientos, en esta fase se recomienda que los cambios sean dejados para futuras versiones, salvo que los mismos claramente impidan el paso a producción. Al final de la fase de Transición se deben repasar los objetivos de cada una de las áreas de procesos involucradas, para verificar su cumplimiento. 13
4. Patrón de Procesos El patrón de procesos especifica los componentes que tiene cada área de procesos de TRP y sus relaciones. 4.1. Especificación El patrón de procesos incluye 3 macro-secciones como ilustra la Figura 2: Descripción General, Actividades y Tareas, y Artefactos y Roles. Figura 2. Patrón de procesos de TRP. 14
Cada área de procesos contiene: Descripción General Describe el dominio que abarca el área de procesos, sus objetivos e ilustra de forma general las actividades y tareas involucradas. Se compone de: Propósito: describe objetivos generales y resultados esperados de la aplicación efectiva del área de procesos. Objetivos: listado de objetivos específicos cuya finalidad es asegurar el cumplimiento del propósito del área de procesos. Notas Introductorias: descripción de conceptos generales importantes para entender el área de procesos. Diagrama General: diagrama de workflow que ilustra el flujo de actividades y tareas del área de procesos. Actividades y Tareas Especifica en detalle las actividades, tareas, roles, artefactos y flujos de trabajo que componen al área de procesos. Puede contener: Actividades: agrupaciones lógicas de tareas que tienen un objetivo común, también pueden contener sub-actividades. Cada actividad contiene: Descripción: descripción de conceptos generales importantes para entender la actividad. Diagrama de Workflow: ilustra el flujo de trabajo de las tareas que componen a la actividad. Tareas: unidades atómicas de realizar algún trabajo (todas las actividades se componen en un último nivel de descomposición de tareas). Estas contienen: Descripción: narrativa de la tarea a realizar. Entradas: nombres de los artefactos de entrada para realizar la tarea. Salidas: nombres de los artefactos de salida para realizar la tarea. Roles: nombres de los responsables de realizar la tarea. Artefactos y Roles Resumen de los artefactos y roles que son usados en el área de procesos y sus relaciones con cada actividad y tarea. 4.2. Consideraciones Se recomienda utilizar el patrón de procesos para elaborar nuevas áreas de procesos alineadas con TRP. Para lo que se dispone de una plantilla (denominada Plantilla patrón de procesos ) y se recomienda observar las siguientes consideraciones: 15
Para elaborar un área de proceso se recomienda utilizar la Plantilla patrón de procesos. Se recomienda utilizar los mismos roles y artefactos que ya estén incluidos en el proceso definido de la Organización. Solo en caso de que ninguno de los artefactos previamente definidos sirva como producto de entrada o salida de las tareas del área de procesos que se está desarrollando, entonces se recomienda crear uno nuevo. Solo en caso de que ninguno de los roles previamente definidos sirva como actor para realizar las tareas del área de procesos que se está desarrollando, entonces se recomienda crear uno nuevo. Un nuevo rol o artefacto puede ser una variación de uno ya existente. La creación de un artefacto nuevo implica crear una primera versión de una plantilla de ese artefacto que debe al menos incluir los contenidos necesarios para que satisfaga la tarea dónde se utiliza. La creación de un rol nuevo implica crear una descripción general de ese rol. 4.3. Convenciones de Escritura El la redacción de las áreas de procesos de TRP se han adoptado las siguientes convenciones de escritura. En los Títulos Áreas de procesos, actividades y tareas se escriben con mayúscula inicial en cada letra, e.g. la tarea Generar Propuesta del área de procesos Planificación de Proyecto. Los nombres de actividades y tareas siempre comienzan con infinitivo, e.g., Buscar, Generar, Diseñar. Roles se escriben con mayúscula inicial, e.g., Jefe de proyecto. Artefactos se escriben con mayúscula inicial, e.g., Plan de proyecto En el Texto Áreas de procesos, actividades y tareas se escriben con mayúscula inicial en cada letra y en cursiva, e.g., para más detalles sobre seguimiento de actividades refiérase a la tarea Seguir Actividades del área de procesos Monitoreo y Control del Proyecto. Roles se escriben con mayúscula inicial, e.g., Jefe de proyecto Artefactos se escriben con mayúscula inicial y comillas, e.g., Plan de proyecto. Cuando se menciona ítems o secciones de un artefacto también aplica la misma regla, e.g., la sección Plan de administración de riesgos del artefacto Plan de proyecto. 16
5. Descripción de Roles de TRP TRP incluye 22 roles en total. Debe tenerse en cuenta que la finalidad de los roles es definir responsabilidades para el proceso de software de la organización y para los proyectos, es decir, estos roles pueden ser distintos a los roles administrativos que puedan existir en la Organización (e.g., Gerente general, Gerente de operaciones, etc.). Además una persona puede jugar varios roles en diferentes proyectos y según sus otras responsabilidades en la Organización. 5.1. Listado de Roles Administrador de ambientes Encargado de la Organización de los ambientes del proyecto siendo responsable de la instalación y configuración de las herramientas de desarrollo y pruebas, e instalación y configuración de hardware, sistema operativo, software de base, productos y herramientas necesarias para el proyecto. Administrador de configuraciones Planifica y realiza las actividades de administración de configuración. Controla y autoriza todos los cambios en las líneas base. La administración del repositorio de líneas base es revisada y aprobada por este rol antes de tomar cualquier acción. Administración y finanzas Responsable de las compras necesarias para el proyecto y el control de las erogaciones del proyecto. Analista Responsable de coordinar el desarrollo de los requerimientos, estableciendo las características funcionales y no funcionales así como el alcance del sistema. Analista de calidad Planifica y actúa en actividades de Aseguramiento de calidad de procesos y productos y verifica que no se desvíen de los estándares. Es independiente de los grupos de Administración y Desarrollo. Realiza reportes directamente al Gerente de proyectos. Área comercial Responsable de la documentación y diseño de las propuestas comerciales a los Clientes y de los contratos con subcontratistas. Arquitecto Es el responsable del diseño del sistema. Define cómo se organiza el sistema estableciendo la estructura para cada vista arquitectónica, la descomposición de las vistas, la agrupación de elementos y las interfaces entre estas agrupaciones. Es el líder técnico y referente en este aspecto del equipo de desarrollo. Cliente Puede referirse a tres roles distintos que como mínimo debe definir la organización Cliente en un proyecto. Estos son: Gerente de proyectos, Jefe de proyectos y Representante de los usuarios. Es decir, el Cliente debe actuar como contraparte efectiva en el proyecto, gestionando recursos por parte del cliente (Jefe de proyectos), colaborando en la definición de los requerimientos, en la 17
validación/aceptación de los productos y/o servicios (Representante de los usuarios), y en el seguimiento y aprobación general del proyecto (Gerente de proyectos). Diseñador gráfico Responsable del diseño gráfico de interfaces usuarias. Documentador Produce material generalmente para la implantación y los usuarios finales, aunque eventualmente puede colaborar con la redacción de otros artefactos necesarios. Equipo de proyecto Está conformado por todos quienes participan en un proyecto por el lado de la Organización, por ej. Gerente de proyectos, Jefe de proyecto, Diseñador, etc. y también por la contraparte Cliente, por ej. Representante de los usuarios, Gerente de proyectos, etc. Gerente de proyectos Planifica y controla los recursos físicos, humanos, monetarios e informáticos que se le otorgan para lograr los resultados esperados de los distintos proyectos de desarrollo de su área. Grupo de ingeniería de procesos Trabaja en la mejora de calidad de los procesos, evalúa el estado actual, planifica e implementa mejoras y planifica las capacitaciones anuales de la empresa. Grupo de ingeniería de sistemas Responsable por la especificación de requerimientos, de asignar los requerimientos de hardware y software, de especificar las interfaces, y de controlar el diseño para mantener la consistencia de los componentes durante todo el ciclo de vida del proyecto. Grupo de ingeniería de software Trabaja en el desarrollo y mantención de software, lleva a cabo actividades como análisis, diseño, codificación, testing, documentación, y redacción de informes técnicos. Incluye a Arquitectos, Programadores, Diseñadores, Integradores, etc. Integrador de sistemas Aúna las diferentes piezas que le entregan los Programadores. Colabora con los Testeadores en las pruebas del sistema. Involucrado (Stakeholder) Entiéndase por Involucrado cualquier persona que va a participar en el proyecto y que espera algo de él y/o que tiene que entregarle algo. Por ejemplo los usuarios son Involucrados que esperan algo del producto de software final del proyecto y que entregan requerimientos a los Analistas, los Programadores son Involucrados que esperan requerimientos formalizados de los Analistas y entregan código funcionando a los Testeadores, etc. Jefe de proyecto Lidera y coordina al grupo de trabajo, verifica y revisa los productos, configura el proceso, decide y verifica el cumplimiento de las mejores prácticas, define, sigue y controla el plan del proyecto, define y sigue los riesgos, coordina y mantiene los contactos necesarios con los usuarios coordinando su interacción con el grupo de trabajo. Programador Codifica y realiza las pruebas unitarias de la pieza que construye. 18
Proveedor Ente externo que entrega productos y/o servicios a la Organización, para que esta pueda cumplir con sus obligaciones contraídas en un proyecto con un Cliente. Organización Es la entidad cuyo principal negocio es del desarrollo y mantención de software, puede referirse a una empresa, PyME, compañía, firma, institución, a una unidad de una empresa grande, a un departamento de una agencia gubernamental, etc. Testeador Responsable de diseñar el plan de pruebas, desarrollar los casos de prueba, preparar el ambiente de pruebas, los datos de prueba y ejecutar los ciclos de prueba. 5.2. Listado de Sinónimos En la siguiente tabla se presentan nombres de roles usados por otros modelos de procesos de software que son equivalentes a los roles de TRP. Nombre del Rol en TRP Administrador de configuraciones Analista Analista de calidad Área comercial Documentador Gerente de proyectos Grupo de ingeniería de sistemas Grupo de ingeniería de software Grupo de ingeniería de procesos Jefe de Proyecto Proveedor Testeador Nombre del Rol equivalente Configuration Managment (CM) Group Software Configuration Managment (SCM) Group Analista de sistemas Process and Product Quality Assurance (PPQA) Group Software Quality Assurance Group (SQA) Quality Assurance (QA) Group Evaluador Técnico Marketing & Sales (MS) Technical writer Senior Manager (SM) Chief Operating Officer (COO) Director de operaciones System Engineering Group (SG) Software Engineering Group (SE) Engineering Process Group (EPG) Software Engineering Process Group (SEPG) Project Manager (PM) Subcontratista Tester 19
6. Descripción de los Artefactos de TRP TRP contiene alrededor de 60 artefactos, muchos de los cuáles tienen plantillas listas para reusar y adaptar. A continuación se describe brevemente cada artefacto. Acta de entrega (Plantilla: ActaEntrega.doc) Documento en el que se especifican los productos, servicios y/o documentos entregados al Cliente como resultados finales y/o intermedios de un proyecto. Análisis de entrevistas a Involucrados (Plantilla: AnalisisEntrevistasInvolucrados.doc) Permite recopilar información relativa a las entrevistas realizadas a los principales Involucrados de un proyecto, resumiendo las expectativas, criterios de éxito y riesgos asociados. Análisis preliminar (Plantilla: AnalisisPreliminar.doc) Permite conocer en una primera instancia los modelos de situación actual y de propuestas de solución, y los distintos diagramas que sirven de base para análisis posteriores en un proyecto. Asignación de roles (Plantilla: AsignacionRoles.doc) Permite describir el equipo del un proyecto y establecer sus responsabilidades y roles. Carta Gantt de iteración (Plantilla: CartaGanttIteracion.mpp) Permite planificar las actividades de una iteración en específico dentro de alguna de las fases del ciclo de vida del proyecto (definidas en el artefacto "Carta Gantt de proyecto"). Carta Gantt de proyecto (Plantilla: CartaGanttProyecto.mpp) Permite planificar las actividades necesarias para realizar el proyecto. Define el ciclo de vida del proyecto y cómo las actividades se programan en él. Catálogo de recursos de entrenamiento (Plantilla: CatalogoRecursosEntrenamiento.doc) Registra los recursos tanto internos como externos que son necesarios para realizar el entrenamiento organizacional. Checklist de ambientes (Plantilla: ChecklistAmbientes.doc) Permite revisar el estado de los ambientes del proyecto, contra lo definido previamente en el documento Especificación de ambientes. Documento de evaluación producto-proveedor (No hay plantilla) Corresponde a un documento donde se especifica una lista de atributos que deben ser satisfechos por un Proveedor en relación a un producto y/o servicio dado. Este artefacto conforma la base para realizar la evaluación y selección de un Proveedor para adquirir dicho producto y/o servicio, por lo que debe considerar todos los aspectos relevantes para tomar la decisión. 20
Documento de evaluación de proveedor (No hay plantilla) Corresponde al documento que establece los criterios por los cuales será evaluado el Proveedor de acuerdo al cumplimiento de los acuerdos establecidos, para que la Organización pueda considerarlos al momento de una nueva adquisición de productos o servicios. Documento de resolución de coordinación (DocumentoResolucionCordinacion.doc) Permite documentar los resultados de resolución de asuntos de coordinación entre Involucrados en un proyecto, como por ejemplo, atrasos en compromisos y negociación de soluciones a problemas. Encuesta de satisfacción del cliente (Plantilla: EncuestaSatisfaccionCliente.doc) Permite conocer el grado de satisfacción del Cliente con los productos, servicios y procesos que le han sido entregados como parte de un proyecto. Permite obtener información para la mejora continua de la Organización. Es recomendable que esta encuesta acompañe al documento Acta de entrega. Entrevista a Involucrado (Plantilla: EntrevistaInvolucrado.doc) Permite capturar información de entrevistas realizadas a cada Involucrado relevante de un proyecto. Los ambientes que especifica, son revisados durante la ejecución de un proyecto con el artefacto "Checklist de ambientes". Especificación de ambientes (Plantilla: EspecificacionAmbientes.doc) Permite especificar los entornos de desarrollo, testing y de producción para el proyecto. Especificación de Requerimientos de Software (ERS) (Plantilla: ERS.doc) Permite capturar todos los requerimientos de software del sistema, o un subconjunto del sistema. Glosario (Plantilla: Glosario.doc) Permite definir los términos importantes utilizados en un proyecto y del dominio del problema que pretende abordar. Guía de ajuste de proceso a proyecto (Plantilla: GuiaAjusteProcesoProyecto.doc) Documenta las opciones de adaptación de ciclos de vida, roles y artefactos para cada tipo de proyecto. Guía de evaluaciones formales (Plantilla: GuiaEvaluacionesFormales.doc) Documenta guías para decidir cuándo realizar una evaluación formal y criterios de evaluación para seleccionar alternativas formalmente. Lista de necesidades de entrenamiento (Plantilla: ListaNecesidadesEntrenamiento.doc) Permite documentar las necesidades de entrenamiento que tiene la Organización. Lista de participantes de entrenamiento (Plantilla: ListaParticipantesEntrenamiento.doc) 21
Registra todos los participantes a una sesión de entrenamiento. Lista de propuestas (No hay plantillas) Registra la entrega de propuestas a la Organización por parte de Proveedores, al menos, identificador de la propuesta, Proveedor asociado y fecha. Lista de proveedores (No hay plantillas) Registra la lista de potenciales Proveedores para un determinado producto y/o servicio. Lista de proveedores preferenciales (No hay plantillas) Registra Proveedores que ya ha trabajado con la Organización, con quienes se han obtenido buenos resultados. Lista de riesgos (Plantilla: ListaRiesgos.doc) Permite conocer los riesgos identificados dentro del proyecto, su magnitud e impacto, asociándolos con acciones específicas de mitigación y contingencia. Manual de instalación (No hay plantillas) Permite especificar los detalles de la instalación de un sistema pedido por el Cliente o de uno entregado por un Proveedor. Minuta de reunión (Plantilla: MinutaReunion.doc) Permite documentar formalmente los temas correspondientes a reuniones realizadas a lo largo del proyecto. Modelo (No hay plantillas, pueden ser modelos UML) Se refiere a cualquier modelo que sirva para describir requerimientos, análisis, diseño, arquitecturas, interfaces, ambientes de pruebas, producción, desarrollo, etc. Modelo de análisis (No hay plantillas, pueden ser modelos UML) Permite identificar los principales objetos del sistema, los actores y las interfaces tanto del usuario como con otros sistemas. Puede contener varios diagramas, tales como: diagrama de secuencia, actividad, clases, estado, etc. Modelo de casos de uso (No hay plantillas, pueden ser modelos UML) Modelo de casos de uso, conteniendo descripciones, diagramas, actores, etc. Modelo de diseño (No hay plantillas, pueden ser modelos UML) Permite describir los objetos de sistema, componentes, actores e interfaces de la solución, además de los patrones de diseño que se aplicarán. Puede contener varios diagramas, tales como: diagrama de clases, estado, despliegue, base de datos, etc. 22
Orden de servicio (No hay plantillas) Registra, documenta y formaliza los compromisos sobre los requerimientos entre el Cliente y la Organización. Plan de administración de configuraciones (Plantilla: PlanAdministracionConfiguraciones.doc) Permite establecer un plan para administrar los productos de trabajo del proyecto, incluyendo tanto los entregables de software como la documentación del proyecto. Plan de aseguramiento de calidad de procesos y productos (Plantilla: PlanAseguramientoCalidadProcesosProductos.doc) Definir, planificar y documentar las actividades del área de procesos Aseguramiento de Calidad de Procesos y Productos para el proyecto. Plan de entrenamiento organizacional (Plantilla: PlanEntrenamientoOrganizacional.doc) Permite conocer las actividades relacionadas con entrenamiento para el personal de la Organización por el periodo de un año. Plan de mejoramiento de procesos (No hay plantilla) Permite documentar oportunidades de mejoramiento del proceso definido de la Organización, y planificar y monitoreas la implementación de las mejoras. Plan de proyecto (Plantilla: PlanProyecto.doc) Permite organizar, controlar y administrar la información necesaria para administrar el proyecto. Plan de proyecto de mantenimiento (Plantilla: PlanProyectoMantenimiento.doc) Plan para proyectos de mantención, donde el producto de software y el ambiente de producción son conocidos para la Organización. Plan de pruebas (Plantilla: PlanPruebas.doc) Permite establecer la definición de las metas y los objetivos del testing, su alcance en la iteración (o en el proyecto), los ítems a testear, la aproximación a tomar, los recursos requeridos y los entregables que serán producidos. Plan de revisiones (Plantilla: PlanRevisiones.doc) Permite establecer la definición de las metas y los objetivos de las revisiones, su alcance en el proyecto, los ítems a revisar, los recursos requeridos y los entregables que serán producidos. Planilla de administración de requerimientos (Plantilla: PlanillaAdminnistracionRequerimientos.xls) Permite administrar y mantener trazabilidad con los requerimientos del usuario. Planilla de casos de prueba (Plantilla: PlanillaCasosPrueba.xls) Permite especificar los casos de prueba necesarios según el artefacto Plan de pruebas. 23
Planilla de configuración de proceso (Plantilla: PlanillaConfiguracionProceso.xls) Permite establecer el proceso que se utilizará para un proyecto, mediante la definición de los artefactos a utilizar en las diferentes fases y los roles involucrados. Planilla de evaluación de estado (Plantilla: PlanillaEvaluacionEstado.xls) Permite la evaluación periódica del estado del proyecto para garantizar que las expectativas a través del ciclo de vida del proyecto son cumplidas, se encuentran sincronizadas y consistentes. Planilla de incidentes (Plantilla: PlanillaIncidentes.xls) Permite registrar los incidentes que le ocurran a los Clientes con el producto de software entregado por la Organización que impidan la normal operación de su negocio. Planilla de registro de horas (Plantilla: PlanillaRegistroHoras.doc) Permite registrar el esfuerzo de un Equipo de proyecto en horas, en la ejecución de un determinado proyecto. Planilla de Tiempo, Esfuerzo y Costo (TEC) (Plantilla: PlanillaTEC.xls) Durante la elaboración del presupuesto permite conocer el Tiempo, Esfuerzo y Costo necesario para la ejecución del proyecto. Planilla de verificación de proceso (Plantilla: PlanillaVerificacionProceso.xls) Permite conocer el nivel de cumplimiento del proceso planificado para el proyecto. Plantilla artefacto genérico (Plantilla: PlantillaArtefactoGenerico.doc) Especifica el formato genérico de todos los artefactos de TRP que son de tipo documento. Plantilla patrón de procesos (Plantilla: PlantillaPatronProcesos.doc) Permite especificar nuevas áreas de proceso utilizando el patrón de procesos de TRP. Presentación de cierre de proyecto (Plantilla: PresentacionCierreProyecto.ppt) Finalizado el proyecto permite conocer métricas y datos relevantes respecto al proceso y al producto para ser utilizado en la planificación futura y como acciones preventivas para nuevos proyectos. Presentación de estado de avance (Plantilla: PresentacionEstadoAvance.ppt) Permite presentar el estado de avance del proyecto. Presentación de lanzamiento de proyecto (Plantilla: PresentacionLanzamientoProyecto.ppt) Permite informar a los grupos e individuos afectados por el proyecto acerca del comienzo del mismo. Propuesta (No hay plantilla) 24
Documenta y formaliza una propuesta de proyecto de la Organización a un Cliente, o una propuesta de un Proveedor a la Organización. Registro de decisión formal (Plantilla: RegistroDecisionFormal.doc) Permite documentar información asociada a evaluaciones y toma de decisiones formales. Registro de resultados de entrenamiento (Plantilla: RegistroResultadosEntrenamiento.doc) Permite conocer los resultados finales de los entrenamientos ejecutados. Resultados de análisis post mortem (Plantilla: ResultadosAnalisisPostMortem.doc) Permite documentar los resultados del análisis post mortem de un proyecto para realimentar a los procesos definidos de la Organización. E.g., lecciones aprendidas, propuestas de mejora, potenciales nuevos artefactos, roles y/o tareas que se hayan generado en el proyecto. Solicitud de cotización (No tiene plantilla) Enviada por el Cliente a la Organización o por la Organización a los Proveedores, puede tomar la forma de RFP (Request for Proposal), licitación, e-mail, etc. Solicitud de requerimientos (Plantilla: SolicitudRequerimientos.doc) Permite documentar los ingresos de nuevos requerimientos a un proyecto. Sumario de la evaluación de pruebas (Plantilla: SumarioEvauacionPruebas.doc) Permite organizar y presentar un informe resumido de los resultados de las pruebas para su revisión y evaluación. Debe contener además, un estado relativo de la calidad y proveer recomendaciones para un futuro esfuerzo de testing. Visión del producto (Plantilla: VisionProducto.doc) Define la visión de los Involucrados acerca del producto a desarrollar, especificado en términos de sus necesidades. Proporciona la base contractual a partir de la cual se detallarán los aspectos técnicos de los requerimientos. 25
7. Artefactos y Áreas de Proceso Los artefactos son usados como entrada y generados como salida por las tareas. La Tabla 2 indica en cuáles áreas de procesos es usado como entrada y/o generado como salida cada artefacto de TRP. Los cuadros marcados con fondo de color plomo indican el área de procesos en que el artefacto se genera por primera vez. Tabla 2. Vista general de artefactos y áreas de procesos. TRP Básico TRP Avanzado GP DMSW GAP Gproc Artefacto AR PP MCP AAP MA ACPP AC DR AD Pro Pru Ins GR EFD AIP DPO MPO EO Acta de entrega Análisis de entrevistas a involucrados Análisis preliminar Asignación de roles Carta Gantt de iteración Carta Gantt de proyecto Catálogo de recursos de entrenamiento Checklist de ambientes Documento de evaluación productoproveedor Documento de evaluación de proveedor Documento de resolución de coordinación Encuesta de satisfacción del cliente Entrevista a involucrado Especificación de ambientes Especificación de Requerimientos de Software (ERS) Glosario Guía de ajuste de proceso a proyecto Guía de evaluaciones formales 26
TRP Básico TRP Avanzado GP DMSW GAP Gproc Artefacto AR PP MCP AAP MA ACPP AC DR AD Pro Pru Ins GR EFD AIP DPO MPO EO Lista de necesidades de entrenamiento Lista de participantes de entrenamiento Lista de propuestas Lista de proveedores Lista de proveedores preferenciales Lista de riesgos Manual de instalación Minuta de reunión Modelo Modelo de análisis Modelo de casos de uso Modelo de diseño Orden de servicio Plan de administración de configuraciones Plan de aseguramiento de calidad de procesos y productos Plan de entrenamiento organizacional Plan de mejoramiento de procesos Plan de proyecto 8 Plan de pruebas Plan de revisiones Planilla de administración de requerimientos Planilla de casos de prueba Planilla de configuración de proceso Planilla de evaluación de estado Planilla de registro de horas 8 Dependiendo el tipo de proyecto, pueden usarse sus variaciones: "Plan de proyecto de mantenimiento" o Planilla de incidentes. 27
TRP Básico TRP Avanzado GP DMSW GAP Gproc Artefacto AR PP MCP AAP MA ACPP AC DR AD Pro Pru Ins GR EFD AIP DPO MPO EO Planilla de Tiempo, Esfuerzo y Costo (TEC) Planilla de verificación de proceso Plantilla artefacto genérico Plantilla patrón de procesos Presentación de cierre de proyecto Presentación de estado de avance Presentación de lanzamiento de proyecto Propuesta Registro de decisión formal Registro de resultados de entrenamiento Resultados de análisis post mortem Solicitud de cotización Solicitud de requerimientos Sumario de la evaluación de pruebas Visión del producto 28
8. Relación entre TRP y CMMI TRP se mapea con las áreas de procesos, objetivos y prácticas de CMMI. Esta relación se muestra a través de dos vistas: una de alto nivel en que áreas de procesos de TRP son mapeadas a áreas de procesos y objetivos específicos de CMMI, y otra de bajo nivel dónde actividades y tareas de TRP se mapean a prácticas específicas de CMMI. 8.1. Mapping Alto Nivel El mapping de alto nivel, presentado en la Figura 3, muestra la relación entre las áreas de procesos de TRP y las áreas de procesos y objetivos específicos (SG, Specific Goal) de los niveles de madurez 2 y 3 (ML, Maturity Level) de CMMI. Como puede verse TRP Básico contiene las áreas de proceso que se mapean a las 7 áreas de proceso de ML 2 de CMMI y TRP Avanzado las que se mapean a las 11 áreas de proceso de ML3 de CMMI. Figura 3. Mapping de alto nivel entre TRP y CMMI. 29
8.2. Mapping Bajo Nivel El mapping de bajo nivel entre TRP y CMMI se muestra desde la Tabla 3 hasta la Tabla 20. Aquí actividades y tareas de TRP se mapean a prácticas específicas (SP, Specific Practice) de CMMI. Se presenta una tabla por cada área de procesos de CMMI ML 2 y ML 3. Cuando un mapping es a una actividad, indica que todas sus tareas y sub-actividades están involucradas, para recalcar este aspecto se marca el recuadro con fondo de color plomo. Tabla 3. Mapping entre TRP y REQM. 30
Tabla 4. Mapping entre TRP y PP. 31
Tabla 5. Mapping entre TRP y PMC. 32
Tabla 6. Mapping entre TRP y SAM. 33
Tabla 7. Mapping entre TRP y MA. 34
Tabla 8. Mapping entre TRP y PPQA. 35
Tabla 9. Mapping entre TRP y CM. 36
Tabla 10. Mapping entre TRP y RD. 37
Tabla 11. Mapping entre TRP y TS. 38
Tabla 12. Mapping entre TRP y VER. 39
Tabla 13. Mapping entre TRP y VAL. 40
Tabla 14. Mapping entre TRP y PI. 41
Tabla 15. Mapping entre TRP y RSKM. 42
Tabla 16. Mapping entre TRP y DAR. 43
Tabla 17. Mapping entre TRP e IPM. 44
Tabla 18. Mapping entre TRP y OPD. Tabla 19. Mapping entre TRP y OPF. 45
Tabla 20. Mapping entre TRP y OT. 46