Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0"

Transcripción

1 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 1: Conceptos y Guía Introductoria MAYO 2009

2

3 Tabla de Contenidos 1. PREFACIO ESPECIFICACIONES PUBLICACIÓN ESTRUCTURA DEL DOCUMENTO PRINCIPIOS DE TRP ORIENTADO A PEQUEÑAS Y MEDIANAS ORGANIZACIONES ORIENTADO AL REUSO ENFOQUE BASADO EN PROCESOS ACORDE A LAS BUENAS PRÁCTICAS INTERNACIONALES ENFOQUE ITERATIVO INCREMENTAL ESTRATEGIA DE DESARROLLO COMPONENTES DE TRP TRP BÁSICO TRP AVANZADO FASES DE TRP Concepción Elaboración Construcción Transición PATRÓN DE PROCESOS ESPECIFICACIÓN CONSIDERACIONES CONVENCIONES DE ESCRITURA DESCRIPCIÓN DE ROLES DE TRP LISTADO DE ROLES LISTADO DE SINÓNIMOS DESCRIPCIÓN DE LOS ARTEFACTOS DE TRP ARTEFACTOS Y ÁREAS DE PROCESO RELACIÓN ENTRE TRP Y CMMI MAPPING ALTO NIVEL MAPPING BAJO NIVEL...30 iii

4 Lista de Figuras FIGURA 1. ESPECIFICACIONES DE TRP...6 FIGURA 2. PATRÓN DE PROCESOS DE TRP FIGURA 3. MAPPING DE ALTO NIVEL ENTRE TRP Y CMMI Lista de Tablas TABLA 1. ÁREAS DE PROCESOS, CATEGORÍAS Y PARTES....9 TABLA 2. VISTA GENERAL DE ARTEFACTOS Y ÁREAS DE PROCESOS TABLA 3. MAPPING ENTRE TRP Y REQM TABLA 4. MAPPING ENTRE TRP Y PP TABLA 5. MAPPING ENTRE TRP Y PMC TABLA 6. MAPPING ENTRE TRP Y SAM TABLA 7. MAPPING ENTRE TRP Y MA...34 TABLA 8. MAPPING ENTRE TRP Y PPQA 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 TABLA 14. MAPPING ENTRE TRP Y PI...41 TABLA 15. MAPPING ENTRE TRP Y RSKM...42 TABLA 16. MAPPING ENTRE TRP Y DAR 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 iv

5 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: ), 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 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 Capability Maturity Model Integration, 3 Sistemas de gestión de la calidad - Requisitos, 5

6 La relación entre estas especificaciones se ilustra en la Figura 1. Figura 1. Especificaciones de TRP 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, En la plataforma Web del proyecto TWP, Como plug-in de EPF 4 descargable en el sitio Web del proyecto Tutelkán, 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, 6

7 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 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 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.) 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

8 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 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)

9 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

10 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 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 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

11 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 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 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

12 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 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 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

13 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

14 4. Patrón de Procesos El patrón de procesos especifica los componentes que tiene cada área de procesos de TRP y sus relaciones 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

15 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 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

16 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 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

17 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 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

18 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

19 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 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

20 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

21 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

22 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

23 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

24 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

25 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, , 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

26 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

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 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

28 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

29 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 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

30 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

31 Tabla 4. Mapping entre TRP y PP. 31

32 Tabla 5. Mapping entre TRP y PMC. 32

33 Tabla 6. Mapping entre TRP y SAM. 33

34 Tabla 7. Mapping entre TRP y MA. 34

35 Tabla 8. Mapping entre TRP y PPQA. 35

36 Tabla 9. Mapping entre TRP y CM. 36

37 Tabla 10. Mapping entre TRP y RD. 37

38 Tabla 11. Mapping entre TRP y TS. 38

39 Tabla 12. Mapping entre TRP y VER. 39

40 Tabla 13. Mapping entre TRP y VAL. 40

41 Tabla 14. Mapping entre TRP y PI. 41

42 Tabla 15. Mapping entre TRP y RSKM. 42

43 Tabla 16. Mapping entre TRP y DAR. 43

44 Tabla 17. Mapping entre TRP e IPM. 44

45 Tabla 18. Mapping entre TRP y OPD. Tabla 19. Mapping entre TRP y OPF. 45

46 Tabla 20. Mapping entre TRP y OT. 46

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Proyecto Tutelkán Tutelkán - Descripción General del Proyecto

Proyecto Tutelkán Tutelkán - Descripción General del Proyecto Tutelkán - Descripción General del Proyecto Introducción al Enfoque de Mejoramiento de Procesos de Tutelkán MAYO 2009 Tabla de Contenidos 1. INTRODUCCIÓN...5 1.1. CONTEXTO...5 1.2. PROPÓSITO...5 1.3.

Más detalles

CMMI : mejora del proceso en Fábricas de Software

CMMI : mejora del proceso en Fábricas de Software CMMI : mejora del proceso en Fábricas de Software Cecilia Rigoni Brualla Caelum, Information & Quality Technologies Introducción Introducción Idea / Necesidad Investigación Diseño Inversión PRODUCTO Introducción

Más detalles

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

Proyecto Tutelkán. Tutelkan Web Platform (TWP) - Manual de Usuario

Proyecto Tutelkán. Tutelkan Web Platform (TWP) - Manual de Usuario Proyecto Tutelkán Tutelkan Web Platform (TWP) - Manual de Usuario MARZO 2009 Tabla de Contenidos 1. INTRODUCCIÓN...4 2. DEFINICIONES IMPORTANTES...5 3. VISTA GENERAL DE TUTELKAN WEB PLATFORM...6 3.1.

Más detalles

Capítulo 3. Áreas de Proceso

Capítulo 3. Áreas de Proceso Capítulo 3. Áreas de Proceso Tal como lo vimos en el capitulo anterior, las áreas de proceso son un grupo de prácticas que se realizan colectivamente con el fin de alcanzar determinadas metas. Existen

Más detalles

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION HERRAMIENTA DE GESTION CUANTITATIVA DE PROYECTOS DE SOFTWARE ORIENTADA POR UN PROCESO DE DESARROLLO

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

Tecnología de la Información. Administración de Recursos Informáticos

Tecnología de la Información. Administración de Recursos Informáticos Tecnología de la Información Administración de Recursos Informáticos 1. Recursos informáticos: Roles y Responsabilidades 2. Áreas dentro del Departamento de Sistemas 3. Conceptos asociados a proyectos

Más detalles

Mejora de procesos desde el ámbito de la innovación. Santiago, 20 de agosto 2014

Mejora de procesos desde el ámbito de la innovación. Santiago, 20 de agosto 2014 Mejora de procesos desde el ámbito de la innovación Santiago, 20 de agosto 2014 Presentación Paulina Dixiana Valenzuela Sánchez, PMP, Mg. Banco Falabella Jefe de Gestión de Proyectos, Calidad de Software

Más detalles

Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs

Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs del Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs Jose A. Calvo-Manzano, UPM I. García y M. Arcilla, UPM y UNED Introducción: Fracaso de los Proyectos Crisis del

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

Taller de Fundamentos de Mejora de Procesos

Taller de Fundamentos de Mejora de Procesos Taller de Fundamentos de Mejora de Procesos Capability Maturity Model, CMM and CMMI are registered in the U.S. Patent and Trademark Office Process Consulting - 22052009 Módulo 01 Diapositiva 1 Expectativas

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Definición de un Proceso de Implantación de Sistemas

Definición de un Proceso de Implantación de Sistemas Definición de un Proceso de Implantación de Sistemas Alicia Mon, Marcelo Estayno, Fernando López Gil, Eduardo De María 1 1 Grupo de Ingeniería de Software (G.I.S.) / Departamento de Sistemas / Universidad

Más detalles

Gestión de proyectos siguiendo practicas del PMI.

Gestión de proyectos siguiendo practicas del PMI. Gestión de proyectos siguiendo practicas del PMI. Identificación de las mejores prácticas aplicadas a la gestión de proyectos. Proceso de Desarrollo de Software de Codes S.A. alineado a CMMI Nivel 3 en

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Programa de Desarrollo Profesional en Mejora del Proceso de Software

Programa de Desarrollo Profesional en Mejora del Proceso de Software Programa de Desarrollo Profesional en Mejora del Proceso de Software - Inicio: 3 de Mayo - El Programa de Desarrollo Profesional (PDP) propone soluciones concretas a los problemas de definición de procesos,

Más detalles

ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez

ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo

Más detalles

Capability Maturity Model Integration CMMI - Overview I

Capability Maturity Model Integration CMMI - Overview I Capability Maturity Model Integration CMMI - Overview I CAPIS Centro de Ingeniería del Software e Ingeniería del Conocimiento Junio 2004 Objetivo de la presentación Brindar una visión general del CMMI

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Caso de Desarrollo Universidad Técnica del

Más detalles

LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA CMMI.

LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA CMMI. LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA. Grupo de Investigación y Desarrollo de Ingeniería del Software. Departamento de Sistemas e Informática, Universidad Francisco de

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software CMMI SERVICIOS María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software AGENDA 1.- Qué es CMMI servicios? 2.- En qué nos puede ayudar

Más detalles

Uso de la representación continua de CMMI para la Mejora de Negocio

Uso de la representación continua de CMMI para la Mejora de Negocio Uso de la representación continua de CMMI para la Mejora de Negocio III Semana del CMMI Casimiro Hernández Parro 1 de Marzo 2007 Capability Maturity Model and CMMI are registered in the U.S. Patent and

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Método WATCH UNEFA NUCLEO ZULIA SIM 6B 2010

Método WATCH UNEFA NUCLEO ZULIA SIM 6B 2010 Método WATCH UNEFA NUCLEO ZULIA SIM 6B 2010 METODO WATCH Es un marco metodológico que describe técnicos, gerenciales y de soporte que deben emplear los grupos de desarrollo de aplicaciones empresariales.

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

Análisis Comparativo de Modelos de Calidad

Análisis Comparativo de Modelos de Calidad Análisis Comparativo de Modelos de Calidad Identificación de Mejores Prácticas para la Gestión de Calidad en Pequeños Entornos Vianca Vega Zepeda Departamento de Ingeniería de Sistemas y Computación Universidad

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

Pasando de ISO 9001:2008 a ISO 9001:2015

Pasando de ISO 9001:2008 a ISO 9001:2015 ISO 9001 Transition guide Revisiones ISO Pasando de ISO 9001:2008 a ISO 9001:2015 El nuevo estándar internacional para los sistemas de gestión de la calidad ISO 9001 Sistemas de Gestión de Calidad- Guía

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

White Paper 2006. Una Introducción a CMMI

White Paper 2006. Una Introducción a CMMI White Paper 2006 Una Introducción a CMMI White Paper 2006 Contenidos INTRODUCCIÓN... 4 NIVELES DE MADUREZ Y ÁREAS DE PROCESO...4 UN MODELO DE REFERENCIA NO ES LA DESCRIPCIÓN DE UN PROCESO...7 PROCESOS

Más detalles

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

Catálogo de Formación SEI

Catálogo de Formación SEI Catálogo de Formación SEI ESI lleva 15 años ofreciendo servicios de formación en diferentes tecnologías. En este tiempo ha formado a más de 4.000 profesionales de más de 800 organizaciones, en más de 30

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

PROCESOS Y PROCEDIMIENTO METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC S.A.

PROCESOS Y PROCEDIMIENTO METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC S.A. 214 CORPORACIÓN PERUANA DE AEROPUERTOS Y AVIACIÓN COMERCIAL SA METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC SA Área de Organización y Métodos CORPORACIÓN PERUANA DE AEROPUERTOS Y AVIACIÓN

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

Relación de ITIL con los procesos de aseguramiento de la Calidad del Software.

Relación de ITIL con los procesos de aseguramiento de la Calidad del Software. Relación de ITIL con los procesos de aseguramiento de la Calidad del Software. Introducción. Desde 1996 IECI ha venido desarrollando actividades de prueba, muy orientadas al negocio que desarrolla. En

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO Programa de Gobierno en Línea Oficina de Coordinación de Investigación, Política y Evaluación. RESUMEN La seguridad de la información

Más detalles

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad Robin Alberto Castro Gil rcastro@icesi.edu.co Geovany Trejos Salas gtrejos@icesi.edu.co Monitoreo y control de proyectos

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

Proyecto Tutelkán. Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo

Proyecto Tutelkán. Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo Proyecto Tutelkán Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo MARZO 2009 Tabla de Contenidos 1. INTRODUCCIÓN...4 2. ESTADO DEL ARTE...5 3. ESTRATEGIA DE DESARROLLO DE TPF...5 3.1. SELECCIÓN

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Manual de la Calidad MC-SGC

Manual de la Calidad MC-SGC MC-SGC Elaborado por: Revisado por: Aprobado por: Nombre Cargo Firma Fecha Encargado Alejandro Jara la 10-12-2008 calidad Claudia Ramírez Mariana Schkolnik Representante de la Dirección Directora 10-12-2008

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El CMMI El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo.

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW >

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación CMMI DEV Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación Cecilia Rigoni Gerente de Caelum, Information & Quality Technologies. Vocal del Comité CSTIC de la AEC El modelo CMMI DEV,

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

COBIT - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012

COBIT - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012 - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012 Antecedentes Ante la necesidad de crear y fortalecer el ambiente

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución

Más detalles

MANUAL DE CALIDAD ISO 9001:2008

MANUAL DE CALIDAD ISO 9001:2008 Página 1 de 21 MANUAL DE CALIDAD ISO 9001:2008 EMPRESA DE DISTRIBUCION DE ALUMINIO Y VIDRIO ELABORADO POR: APROBADO POR: REPRESENTANTE DE LA ALTA DIRECCIÓN GERENTE PROPIETARIO Página 2 de 21 CONTENIDO

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

MEJORA SISTEMÁTICA DEL PROCESO DE DESARROLLO DE SOFTWARE DE LA DIVISIÓN DE AUTOSERVICIO DE DTS

MEJORA SISTEMÁTICA DEL PROCESO DE DESARROLLO DE SOFTWARE DE LA DIVISIÓN DE AUTOSERVICIO DE DTS UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN MEJORA SISTEMÁTICA DEL PROCESO DE DESARROLLO DE SOFTWARE DE LA DIVISIÓN DE AUTOSERVICIO DE DTS

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES Tabla de contenido INTRODUCCIÓN AL MODELO... 4 OBJETO DE ESTA GUÍA... 7 1.

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Cuarta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

K2BIM Plan de Configuración Versión 0.9

K2BIM Plan de Configuración Versión 0.9 K2BIM Plan de Configuración Versión 0.9 Historia de revisiones Fecha VersiónDescripción Autor 21/08/2009 0.1 Modificado el punto 2.2 Yasim Zeballos 23/08/2009 0.9 Completados la mayoría de los puntos.

Más detalles

Resumen del Contenido del Examen PMP

Resumen del Contenido del Examen PMP Resumen del Contenido del Examen PMP Tareas Dominio I Inicio del Proyecto - 13 % Realizar una valoración del proyecto basada en la información disponible, mediante reuniones con el patrocinador, el cliente,

Más detalles

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración Seguridad del documento La clasificación de seguridad de la información de este documento, se ha establecido como bajo. Se ha creado y organizado con la expectativa de que esté a disposición de las unidades

Más detalles

Consideraciones para la implementación de SOA en el desarrollo de productos. Septiembre, 2006

Consideraciones para la implementación de SOA en el desarrollo de productos. Septiembre, 2006 Consideraciones para la implementación de SOA en el desarrollo de productos Septiembre, 2006 Consideraciones para la implementación de SOA en el desarrollo de productos Las nuevas exigencias de los mercados

Más detalles

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA con destino a GORE DE ATACAMA ELIMCO SISTEMAS Alfredo Barros Errázuriz 1954

Más detalles

Metodología de Gestión de Proyectos

Metodología de Gestión de Proyectos Metodología de Gestión de Proyectos Rodolfo Azzam PMP PMO y Calidad Banco Central de Chile GERENCIA DE INFORMATICA BANCO CENTRAL DE CHILE 1 Introducción La motivación por desarrollar un proyecto tecnológico

Más detalles

RUP: Disciplina de Manejo de Cambios y Configuraciones

RUP: Disciplina de Manejo de Cambios y Configuraciones RUP: Disciplina de Preparado por: Amelia Soriano Mayo 2005 Tomado de: Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational

Más detalles

Presentación de Web Method. Productos y Servicios para la Gestión de Proyectos y la PMO

Presentación de Web Method. Productos y Servicios para la Gestión de Proyectos y la PMO Presentación de Web Method Productos y Servicios para la Gestión de Proyectos y la PMO 1 Productos y Servicios Visión ejecutiva -2- Cartera de productos y servicios Metodología para gestión de PMO, proyectos,

Más detalles

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 : 05 Marzo 2015 MANUAL DE ORGANIZACIÓN Y FUNCIONES DEPARTAMENTO DE INFORMÁTICA Aprobado mediante Resolución de Gerencia General EF/92.2000 N 020-2014, de fecha

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

ISO 9000 ISO 9001 (2015) ISO 9001 (2015) Requisitos para los Sistemas de Gestión de la Calidad

ISO 9000 ISO 9001 (2015) ISO 9001 (2015) Requisitos para los Sistemas de Gestión de la Calidad «N o m b r e _ O r g a n i z a c i ó n _ C O M P L E T O» ISO 9001 (2015) ISO 9000 ISO 9001 (2015) Requisitos para los Sistemas de Gestión de la Calidad Interpretación libre de ISO/DIS 9001:2015 Tabla

Más detalles

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2 UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA GESTIÓN DE SOFTWARE INFORME SOBRE Evaluación de Productos Grupo 2 Marcelo Caponi 3.825.139-0 Daniel De Vera 4.120.602-3 José Luis Ibarra 4.347.596-3

Más detalles

configurándola para ser usada dentro del área de QA de una fábrica de software.

configurándola para ser usada dentro del área de QA de una fábrica de software. Capítulo 6 - Caso de estudio En esta sección vamos a mostrar la funcionalidad de la herramienta desarrollada configurándola para ser usada dentro del área de QA de una fábrica de software. 6.1 Definición

Más detalles

Ges3ón de Proyectos So9ware

Ges3ón de Proyectos So9ware Ges3ón de Proyectos So9ware Tema 2.1 Integración Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Ampliar los conocimientos básicos

Más detalles

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP...2 2.1 WORKFLOWS ESENCIALES DEL RUP...2

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

CATALOGO DE SERVICIOS

CATALOGO DE SERVICIOS Quiénes Somos Applies Chile es una consultora que provee servicios involucrados en la Gestión de Procesos de Negocios, Ingeniería de Software, Nuevas Tecnologías de Información y Comunicaciones (TIC),

Más detalles

BPMS ESCM CMMI COBIT EFQM ISO IT MARK ITIL PMI TOGAF TSP. Arquitectura empresarial Integrado. del sector TIC. de Información Tecnologías relacionadas

BPMS ESCM CMMI COBIT EFQM ISO IT MARK ITIL PMI TOGAF TSP. Arquitectura empresarial Integrado. del sector TIC. de Información Tecnologías relacionadas MATRIZ CONCEPTUAL BPMS ESCM CMMI COBIT EFQM ISO IT MARK ITIL PMI TOGAF TSP NOMBRE COMPLETO Business Process Management o esourcing Capability Mode o Capability Maturity Model Control Objectives for European

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

ISO 9001,9002,9003,9004

ISO 9001,9002,9003,9004 Capitulo 06 ISO 9001,9002,9003,9004 Que es ISO 9001? Es una de las normas para la gestión y el aseguramiento de la calidad. Esta norma forma parte de un conjunto de tres normas sobre los sistemas de la

Más detalles

Integración del PMBOK al RUP para proyectos de Desarrollo de Software

Integración del PMBOK al RUP para proyectos de Desarrollo de Software Integración del PMBOK al RUP para proyectos de Desarrollo de Software Fernando Torres UPG-FISI, Universidad Nacional Mayor de San Marcos (UNMSM), Av. German Amezaga s/n, Ciudad Universitaria, Lima, Perú

Más detalles

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión Alfredo Zayas 0 Alfredo Zayas 1. ISO/IEC 20000 Consultant por ITSMf 2. Auditor interno de ISO 9001:2000 por INLAC 3. Certified Information

Más detalles

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones Sistema de Administración de Farmacias Plan de SQA Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 29/08/2014 1.0 Realización del documento Resp. SQA Plan de SQA Página 1 de 15 ÍNDICE

Más detalles

Evolución de los modelos CMMI

Evolución de los modelos CMMI Evolución de los modelos CMMI Enrique Morey Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University ESI 2009 1 Pregunta Qué entendemos como

Más detalles

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA Aprobando mediante Resolución de Gerencia General N 052-2015 de fecha 26 Junio 2015 ELABORADO POR: APROBADO POR: 1 de 82 ÍNDICE 1 INTRODUCCIÓN...

Más detalles

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 RESUMEN EJECUTIVO Herramientas y Metodologías Herramientas de Desarrollo o Desarrollo de aplicaciones Oracle Designer Oracle Software Configuration Manager (SCM) Oracle

Más detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT PC0901 - Proceso de control de cambios en software de aplicación provisto por Organismos Gobierno de la Ciudad Autónoma de Buenos Aires PC0901 - Proceso de control de cambios en software

Más detalles

Objeto del trabajo. Introducción

Objeto del trabajo. Introducción Título del trabajo: Gestión de programas y proyectos de mejora continua Autor: Kanterewicz, Pablo Mario Dirección de correo electrónico: pkant@pka-consult.com.ar Objeto del trabajo Este artículo tiene

Más detalles