Firmado digitalmente por Universidad Tecnológica de Querétaro Nombre de reconocimiento (DN): cn=Universidad Tecnológica de Querétaro, o=Universidad Tecnológica de Querétaro, ou, [email protected], c=MX Fecha: 2012.05.24 15:02:35 -05'00' Universidad Tecnológica de Querétaro UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto: Creación de una Metodología en CMMI Empresa: Universidad Tecnológica de Querétaro Memoria Que como parte de los requisitos para obtener el título de Ingeniero en Tecnologías de la Información y Comunicación __________________________ Presenta Ana Karen Rodríguez Trejo ____________________ Contreras Álvarez Adriana Yazmín Asesor de la UTEQ Alvarado de la Vega Jorge Ramiro Asesor de la Empresa Santiago de Querétaro, Querétaro Mayo 2012 RESUMEN Las organizaciones actualmente requieren de un marco de trabajo que proporcione calidad a sus proyectos, el modelo CMMI proporciona un marco de mejora que puede ayudar a una compañía en la mejora de sus procesos y su habilidad para desarrollar, obtener y mantener productos y servicios. Esta memoria es un reporte de actividades realizadas para la Universidad Tecnológica de Querétaro, la Célula de Innovación y Desarrollo genera proyectos de tecnologías de la información y automatización, esta célula necesita crear y diseñar una metodología fundamentada en CMMI que le permita llevar a cabo el desarrollo e implementación de los proyectos e iniciar el proceso de certificación de la misma. ABSTRACT The organizations nowadays require a framework that provides quality projects, the CMMI model provides a framework that can help the company in the process improvement and its skill to develop, obtain and maintain products and services. This memory is a report of activities for the Universidad Tecnológica de Querétaro, the Célula de Innovación y Desarrollo project creates information technology and automation, this Célula need to create and design a methodology based on CMMI that permit to makes the development and implementation of projects and initiate the certification process. INDICE Página RESUMEN ABSTRACT I. INTRODUCCIÓN ............................................................................................................................. 1 II. ANTECEDENTES ........................................................................................................................... 2 III. JUSTIFICACIÓN ............................................................................................................................ 2 IV. OBJETIVOS ................................................................................................................................... 3 V. ALCANCES ..................................................................................................................................... 3 VI. JUSTIFICACIÓN TEÓRICA ........................................................................................................... 3 VII. PLAN DE ACTIVIDADES.............................................................................................................. 4 VIII. RECURSOS MATERIALES Y HUMANOS .................................................................................. 5 IX. DESARROLLO DEL PROYECTO ................................................................................................. 6 INVESTIGACIÓN INGENIERÍA DE SOFTWARE ........................................................................... 7 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) .......................................................... 16 IV. RESULTADOS OBTENIDOS ...................................................................................................... 26 XI. ANÁLISIS DE RIESGO ................................................................................................................ 26 XII. CONCLUSIONES ....................................................................................................................... 27 XIII. RECOMENDACIONES .............................................................................................................. 27 XIV. REFERENCIAS BIBLIOGRÁFICAS .......................................................................................... 28 I. INTRODUCCIÓN En el presente reporte de estadía se documenta el desarrollo del proyecto Metodología para certificación en CMMI, así como el manual de procesos y manual organizacional para la CELULA DE INNOVACION Y DESARROLLO, esto para automatizar la administración de los proyectos que se realizan dentro de la empresa. Esta metodología tiene como objetivo plasmar procedimientos para el desarrollo de los proyectos que se desarrollan en la empresa, así como buenas practicas para las personas que están a cargo de cada uno de los proyectos, esto es para desarrollar software de calidad y en dado caso poder detectar deficiencias a tiempo dentro de los proyectos. La empresa Célula de Innovación y Desarrollo de la Universidad Tecnológica de Querétaro no tiene ningún control de los proyectos que desarrolla por lo que consecuentemente tienen retrasos en los mismos, tampoco no se contaba con ningún procedimiento a seguir por lo que simplemente se desarrollaba software sin ningún tipo de documentación que indicara información acerca de los proyectos. En el siguiente documento se describe el proceso de una metodología que ayuda a desarrollar proyectos de calidad desde su planeación hasta la entrega del mismo. 1 II. ANTECEDENTES La empresa Célula de Innovación y Desarrollo se dedica al desarrollo de proyectos de tecnologías de la información, por lo que tiene diferentes proyectos en desarrollo y futuros. La empresa no cuenta con ningún tipo de metodología que indique los procedimientos necesarios para desarrollar los proyectos con calidad. No se tiene formatos de la documentación requerida donde se validen puntos importantes de los proyectos que se desarrollan tales como la planeación, errores, pruebas o alcances de los mismos. III. JUSTIFICACIÓN Siempre se ha considerado que tener una buena organización de la información que se maneja dentro de una empresa crea una buena calidad en cada uno de los productos que la empresa genera, así como un ambiente administrativo mas limpio. Desarrollando esta metodología basada en las buenas practicas de CMMI se busca lograr una serie de procedimientos, reglas y documentos que permitan el desarrollo integro de cada uno de los proyectos, un control absoluto de las personas y de los proyectos que desarrollan así como un control de los accesos a los mismos. Por lo que ayudara a tener una administración mas eficiente y evitara perdidas de tiempo y lograr detectar deficiencias en los proyectos incluso evitar las mismas en los software que se desarrolla. Se decidió por CMMI ya que proporciona a la industria de software un modelo de procesos basado en las mejores prácticas internacionales con los siguientes beneficios: 1. Mejora la visibilidad sobre los Proyectos 2. Mejora la comunicación 2 3. Mejora la planificación 4. Reduce el Re-trabajo 5. Mejora la calidad del producto 6. Proporciona mayor conocimiento de la organización 7. Mejora el ambiente de trabajo 8. Se genera una Base de Conocimiento 9. Se tiene una visión compartida 10. Se tiene un cliente más informado IV. OBJETIVOS El objetivo prioritario de la Metodología basada en CMMI es tener una herramienta que nos indique y nos guíe durante todo el desarrollo del software desde su planeación hasta el cierre del mismo y que nos permita documentar de una manera correcta todas las fases por las que paso el proyecto. Esto para tener una justificación o información de los productos que se desarrollan. V. ALCANCES Diseñar y crear una metodología de trabajo que establezca procedimientos, técnicas, herramientas y procesos certificados por CMMI para el desarrollo de software y desarrollo de proyectos en tecnologías de la información. VI. JUSTIFICACIÓN TEÓRICA El modelo de procesos CMMI está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software. 3 Las organizaciones, que no cuenten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo a sus necesidades, mientras que las organizaciones que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir. Uno de los objetivos principales es proporcionar a la industria de software un modelo que se base en las mejores prácticas internacionales el cuál sea fácil de aplicar y produzca servicios y productos de alta calidad. VII. PLAN DE ACTIVIDADES En este capítulo se presenta una grafica de Gantt con las etapas y actividades programadas para lograr los objetivos del proyecto. 4 VIII. RECURSOS MATERIALES Y HUMANOS Se presentan a continuación los recursos necesarios para el desarrollo del proyecto, incluye los recursos humanos y el equipo que se requiere para garantizar los resultados programados. RECURSOS MATERIALES Equipos Portátiles Sistema Operativo Windows (XP, HUMANOS 3 Ingenieros en Tecnologías de la Información y Comunicación. Competencias específicas: Vista o Seven) Requerimientos mínimos: Creación de proyectos de de Disco Duro, al menos 10GB tecnologías información, libres mediante procesos y modelos de calidad. Procesador mínimo 500 MHz 256 MB de RAM Integración e implementación de metodologías para auditoria de Sistemas en las Organizaciones. Comunicación de ideas y propuestas en forma óptima y con pensamiento crítico. Proponer la implementación de nuevas tecnologías, para atender áreas de oportunidad e innovación en las software de organizaciones. 5 Desarrollo de sistemas de información Capacidad de trabajo en equipo. Capacidad trabajar en equipo. Conocimiento en Metodologías para desarrollo de Software IX. DESARROLLO DEL PROYECTO La creación de la Metodología para la empresa Célula de Innovación y Desarrollo se realizo dentro de la Universidad Tecnológica de Querétaro, ubicada en Av. Pie de la Cuesta 2501 C.P. 76148, la cual trabaja en varios proyectos de tecnologías de la información, tal como software a la medida, implementación de redes y proyectos de automatización, para lo cual se requiere tener una base de trabajo que proporcione al equipo el respaldo necesario para generar proyectos con alto nivel de calidad. Al definir los requerimientos de la metodología la empresa solicita está sirva como base para desarrollar todos los proyectos llevados a cabo en la Célula de Innovación y Desarrollo, es decir no solamente basándose en la generación de software como la mayoría de las metodologías lo hace, por lo que se genero una investigación para poder llevar a cabo dicha solicitud. En la investigación que se había llevado a cabo anteriormente se encontraron las siguientes metodologías: 6 INVESTIGACIÓN INGENIERÍA DE SOFTWARE FUNDAMENTOS. Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería. Surge a partir de la necesidad de tener una mejor administración en cuanto al desarrollo de software en una organización, al implementar la ingeniería de software se desarrollan proyectos con éxito, los proyectos son más fácil de modificar e incluso más fácil de utilizar y rápido de construir. Los procesos del ciclo de vida de desarrollo de software. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso que se deben establecer para la entrega efectiva de la ingeniería de software. El ciclo de vida es el conjunto de fases por las que pasa el software que se está desarrollando desde que surge la idea inicial hasta que es retirado o remplazado. En el ciclo de vida de desarrollo de software existen procesos principales, de apoyo y organizativos determinados por la norma ISO 12207, la cuál define las actividades que pueden llevarse a cabo durante el ciclo de vida del software. Procesos principales, dan servicio a las partes principales durante el ciclo de vida del software. Una parte principal es la que inicia o lleva a cabo el desarrollo, operación y mantenimiento de productos software. 7 Proceso de adquisición Proceso de suministro Proceso de desarrollo Proceso de operación Proceso de mantenimiento Procesos de apoyo, apoyan a otros procesos como parte esencial de los mismos, con un propósito bien definido, y contribuyen al éxito y calidad del proyecto software. Proceso de documentación Proceso de gestión de la configuración Proceso de verificación Proceso de validación Proceso de revisiones conjuntas Proceso de auditoría Proceso de solución de problemas, se emplean por una organización para establecer e implementar una infraestructura construida por procesos y personal asociado al ciclo de vida, y para mejorar continuamente esta estructura y procesos. Proceso de gestión Proceso de infraestructura Proceso de mejora Proceso de formación Etapas del ciclo de vida de desarrollo de software: Análisis de Requisitos/ Requerimientos 8 La primera etapa para crear un producto de software es extraer los requisitos, en esta etapa la participación del cliente es importante ya que ellos deciden lo que el software tiene que hacer, sin embargo se requiere habilidad y experiencia para reconocer los requisitos que realmente el software debe cumplir. Se debe usar el documento Especificación de Requisitos para mostrar el resultado del análisis de requisitos con el cliente, también debe definirse un diagrama entidad/relación para indicar las principales entidades en el desarrollo de software. La captura, análisis y especificación de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de requerimientos. Especificación Describe detalladamente el software que se va a desarrollar, esta etapa del ciclo de vida es más importante para las interfaces externas que son las que deben permanecer estables. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software. Diseño y arquitectura La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. 9 El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software. La arquitectura de software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas. Programación El diseño se implementa a código, no necesariamente es la que requiere mayor trabajo, la complejidad y duración depende de los lenguajes de programación utilizados y el diseño realizado con anterioridad. Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado. Prueba Esta etapa consiste en comprobar que el software realice las tareas indicadas en la especificación del problema. 10 Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. Mantenimiento Es la etapa donde se implementan mejoras al software para solucionar errores descubiertos y tratar con nuevos requisitos. En esta fase del ciclo de vida existen cuatro tipos de mantenimiento: Perfectivo (mejora la calidad interna de los sistemas) Evolutivo (incorporaciones, modificaciones y eliminaciones necesarias en un producto de software para cubrir la expansión o cambio en las necesidades del usuario) Adaptativo (modificaciones que afectan a los entornos en los que el sistema opera, un ejemplo son los cambios de configuración del hardware, software, gestores de base de datos) 11 Correctivo (corrección de errores) LA NECESIDAD DE UNA METODOLOGÍA DE DESARROLLO. Las metodologías de desarrollo surgen a partir de la necesidad de completar una serie de tareas para construir un proyecto de software. Una metodología es un conjunto integrado de técnicas y métodos que permiten empezar cada una de las actividades del ciclo de vida de un proyecto de desarrollo de software, estas definen roles y actividades. Una metodología está formada por: Fases, tareas que se realizan en cada etapa. Productos de cada fase. Procedimientos y herramientas, sirven de apoyo para la realización de cada tarea. Criterios de evaluación del proceso y del producto, sirven para saber si se han logrados los objetivos. EVOLUCIÓN DE LAS METODOLOGÍAS DE DESARROLLO. Clasificación de las metodologías. Se clasifican en dos grupos; tradicionales que son las que se basan en una fuerte planificación durante todo el desarrollo y las metodologías ágiles en las que el desarrollo de software es incremental, cooperativo, sencillo y adaptado. Metodologías tradicionales. Estas metodologías se centran en llevar una documentación íntegra de todo el proyecto y son denominadas como metodologías pesadas. Metodologías ágiles. 12 Nace en respuesta a los problemas que llegan a ocasionar las metodologías tradicionales, se basa en atrasar las decisiones y la planificación adaptativa. Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. Metodología de desarrollo rápido de aplicaciones (RAD) Se desarrollo para responder a la necesidad de entregar sistemas muy rápido, sin embargo no es apropiado para todos los proyectos, el éxito de un proyecto basado en RAD lo determina el alcance, tamaño y circunstancias del mismo. El método RAD tiene una lista de tareas y una estructura de desglose de trabajo diseñada para la rapidez, comprende el desarrollo iterativo, construcción de prototipos y el uso de utilidades CASE. El método RAD es una fusión de varias técnicas estructuradas, especialmente la ingeniería de información orientada a datos con técnicas de prototipos para acelerar su desarrollo de proyectos. RAD hace uso interactivo de técnicas estructuradas y prototipos para definir los requisitos de usuario y diseñar el sistema final, el desarrollador construye primero modelos de datos y procesos de negocio preliminares de los requisitos, los prototipos ayudan al analista y los usuarios a verificar requisitos y refinar formalmente los modelos de datos y procesos. Metodología de proceso unificado Rational (RUP) Es un marco de trabajo de proceso de desarrollo de software iterativo, incluye una base de conocimiento con ejemplos y descripciones detalladas para 13 diferentes tipos de actividades, este es los resultados de la combinación de varias metodologías y está influenciado por el modelo en espiral. Metodología Scrum Scrum es un proceso incremental iterativo para desarrollar cualquier producto o gestionar cualquier trabajo. Se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales, estaba previsto que fuera para la gestión de proyectos de desarrollo de software, se puede usar también para la ejecución de equipos de mantenimiento de software o como un enfoque de gestión de programas. Metodología Extreme Programming (XP) En esta metodología se considera que se puede ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto, se cree que es más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después de controlar los cambios en los requisitos. Se considera la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinámica durante todo el ciclo de vida. Está metodología se centra en la retroalimentación continua con el cliente y el equipo de desarrollo. Los roles propuestos para esta metodología son: Programador: escribe las pruebas unitarias y produce el código del sistema Cliente: escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide 14 cuáles se implementan en cada iteración centrándose en apoyar mayor valor al negocio. Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas. Encargado de seguimiento (tracker): proporciona realimentación al equipo, Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. Entrenador (coach): es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. Gestor (bigboss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. Metodología Proceso Ágil Unificado (Agile UnifiedProcess - AUP) Describe un enfoque simple, fácil de entender, del desarrollo de software de aplicación de negocios usando técnicas y conceptos ágiles. AUP aplica técnicas ágiles incluyendo desarrollo orientado a pruebas, modelado ágil, gestión de cambios ágil y refactorización de bases de datos para mejorar la productividad. AUP se presenta en cuatro fases: 15 Inicio: el objetivo es identificar el alcance inicial del proyecto, una arquitectura potencial para el sistema y obtener fondos y aceptación por parte de las personas involucradas en el negocio. Elaboración: el objetivo es probar la arquitectura del sistema. Construcción: el objetivo es construir software operativo de forma incremental que cumpla con las necesidades de prioridad más altas de las personas involucradas en el negocio. Transición: el objetivo es validar y desplegar el sistema en el entorno de producción. CMMI (CAPABILITY MATURITY MODEL INTEGRATION) Integración de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios. La versión actual de CMMI es la versión 1.3 la cual corresponde a CMMISVC, liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versión 1.2 disponible: CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios. 16 CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria. CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios. Dentro de la constelación CMMI-DEV, existen dos modelos: CMMI-DEV CMMI-DEV + IPPD (Integrated Product and Process Development) Independientemente de la constelación\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio. Las organizaciones no pueden ser certificadas CMMI, una organización es evaluada, usando un método de evaluación, recibe una calificación de nivel 1-5 si sigue los niveles de madurez. En caso de que quiera la organización, puede escoger áreas de proceso y en vez de por niveles de madurez podrá obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización. AREAS DE PROCESO DE NIVEL 2. Estas ideas se materializan en las siguientes áreas de proceso: Gestión de Requisitos Planificación de proyectos Monitorización y Control de proyectos Medición y Análisis 17 Aseguramiento de la calidad Gestión de la configuración Pasaremos a explicar cada una de las áreas de proceso con un poco más de detalle: CMM-CMMI: GESTIÓN DE REQUISITOS O REQUERIMIENTOS El objetivo de la gestión de requisitos es gestionar los requisitos de los elementos del proyecto y sus componentes e identificar inconsistencias entre estos requisitos, el plan de proyectos y los elementos de trabajo. En este proceso se deben de gestionar todos los requisitos del proyecto, tanto los requisitos técnicos como los requisitos no técnicos. Estos requisitos han de ser revisados conjuntamente con la fuente de los mismos así como con las personas que se encargarán del desarrollo posterior. CMM-CMMI: PLANIFICACIÓN DE PROYECTOS El objetivo de la planificación de proyectos es establecer y mantener planes que define las actividades del proyecto. Las tareas que conlleva la planificación de proyectos son: Desarrollar un plan inicial del proyecto Establecer una relación adecuada con todas las personas involucradas en el proyecto Obtener compromiso con el plan Mantener el plan durante el desarrollo del proyecto 18 El plan incluye estimación de los elementos de trabajo y tareas, recursos necesarios, negociación de compromisos, establecimiento de un calendario, e identificación y análisis de los posibles riesgos que pueda tener el proyecto. El plan de proyectos es un herramienta de trabajo viva que se debe de actualizar con mucha frecuencia ya que los requisitos cambiarán, habrá que estimar, habrá riesgos que desaparezcan y otros nuevos, habrá que tomar acciones correctivas. CMM-CMMI: MONITORIZACIÓN Y CONTROL DE PROYECTOS El objetivo de la monitorización y control de proyectos es proporcionar una compresión del estado del proyecto para que se puedan tomar acciones correctivas cuando la ejecución de proyecto se desvíe del plan. El documento del plan de proyecto es la base para monitorizar las actividades, comunicar el estado y tomar acciones correctivas. El progreso se determina comparando los actuales elementos de trabajo: tareas, horas realizadas, coste y calendario actual, con los estimados en el plan de proyecto. Una apropiada visibilidad nos permitirá tomar acciones correctivas antes de que el trabajo real se desvíe mucho del plan. Estas acciones que tomaremos, harán que tengamos que rehacer/ajustar nuestro plan de proyectos. CMM-CMMI: MEDICIÓN Y ANÁLISIS El objetivo de la medición y el análisis es desarrollar y sostener una capacidad de medición que sea usada para ayudar a las necesidades de información de la gerencia. Los datos tomados para la medición deben estar alineados con los objetivos de la empresa para proporcionar información útil a la misma. 19 Se ha de implantar un mecanismo de recogida de datos, almacenamiento y análisis de los mismos de forma que las decisiones que se tomen puedan estar basadas en estos datos. Este sistema tiene que permitir además: Planificación y estimación objetiva Comparar el rendimiento actual contra el rendimiento esperado en el plan Identificar y resolver problemas relacionados con los procesos Proporcionar una base para añadir métricas en procesos futuros CMM-CMMI: ASEGURAMIENTO DE LA CALIDAD El objetivo del aseguramiento de la calidad es proporcionar personas y gestión con el objetivo de que los procesos y los elementos de trabajo cumplan los procesos. Esto se consigue mediante: Evaluar objetivamente la ejecución de los procesos, los elementos de trabajo y servicios contra las descripciones de procesos, estándares y procedimientos. Identificar y documentar los elementos no conformes. Proporcionar información a las personas que están usando los procesos y a los gestores, de los resultados de las actividades del aseguramiento de la calidad. Asegurar de que los elementos no conformes son arreglados. Esta es un área de proceso clave, que a veces no se le da la suficiente importancia, pero que sin ella no será posible implanta un modelo de calidad. CMM-CMMI: GESTIÓN DE LA CONFIGURACIÓN 20 El objetivo de la gestión de la configuración es establecer y mantener la integridad de los elementos de trabajo identificando, controlando y auditando dichos elementos. Más concretamente mediante: La identificación de los elementos de trabajo que componen una línea base. Controlando los cambios de dichos elementos Proporcionando formas de construir los elementos de trabajo a partir del sistema de control de la configuración Mantener la integridad de las líneas base Proporcionar información precisa de los datos de la configuración a desarrolladores y clientes. Esto quiere decir que es necesario tener un sistema de control y gestión de versiones 21 FASE DESARROLLO Establecimiento aéreas y roles Para crear la metodología lo primero que se tuvo que realizar es establecer las áreas donde se aplicara y los roles que esto conlleva por lo que se realizo el Manual organizacional, Manual de procedimientos de áreas y el cronograma del CID-TAI, así también el Manual de Perfiles donde se define cada rol que estará participando el las áreas y en la metodología desarrollada. A continuación en la figura 1 se muestra el organigrama del CID-TAI y los roles que se propusieron. Coordinación General Área comercial Soporte Admón. de Calidad Finanzas Compras y Almacén Medida y Análisis Recursos Humanos Desarrollo de Proyectos Figura 1. Organigrama Organizacional 22 Los roles propuestos para la metodología son: ROL Administrador de Proyectos RESPONSABILIDADES Planificar, coordinar y dirigir las actividades de desarrollo de sistemas así también negociación con clientes. Analista Analizar, sistemas desarrollar de y mantener información y automatización Líder de Proyectos Asistir en el desarrollo de los sistemas de información Su misión es la de dirigir y coordinar los proyectos de desarrollo y mantenimiento de las aplicaciones de un área de la empresa, supervisando las funciones y los recursos de análisis funcional, técnico y programación, con el fin de satisfacer las necesidades de los usuarios y asegurando la adecuada explotación de las aplicaciones. Programador Asistir en el desarrollo de sistemas de información y Automatización Gerente calidad Crear metodología y procesos para asegurar el desarrollo de proyectos con calidad, crear documentación de los mismos y hacer los cambios según las necesidades del centro, verificar que se implemente 23 correctamente la metodología y asegurar su buen funcionamiento. Creación de fase Iniciación Para entrar en materia después de toda una investigación y establecimiento de áreas y roles que participaran, tomando siempre en cuenta los lineamientos de CMMI y RUP como Ingeniería de Software se crea la fase de iniciación para la metodología que se implementara en el CID-TAI. A continuación se presenta el procedimiento general para la Fase de Iniciación. 1. Cliente solicita proyecto 2. Gerente comercial se entrevista con cliente para identificar requerimientos 3. Gerente comercial genera el formato ESPECIFICACION DE REQUERIMIENTOS y se genera FORMATO PROTOTIPO 4. Cliente acepta requerimientos y prototipo 5. Gerente solicita colaboradores de equipo de trabajo con el documento SOLICITUD DE PERFIL. 6. Se asigna equipo de trabajo 7. Gerente comercial y líder de proyecto analiza requerimientos y crean PROPUESTA TÉCNICA 8. Líder de proyecto analiza los riesgos y genera PROCEDIMIENTO GESTION DE RIESGOS. 9. Gerente comercial y área ECONÓMICA. 24 financiera crean PROPUESTA 10. Gerente comercial envía propuestas y riesgos a cliente y obtiene aceptación y se firma contrato (generar formato CONTRATO) y CASO DE NEGOCIO. 11. Gerente comercial solicita Auditorias al área de Administración de calidad de la empresa. 12. Líder de proyecto genera PLAN DE TRABAJO, CRONOGRAMA y GESTION DE RIESGOS 13. Líder de proyecto con el equipo asignado generan un modelo inicial plasmándolo en el FORMATO CASOS DE USO. Productos generados: Especificación de Requerimientos Formato Prototipo Solicitud de Perfil Propuesta Técnica Propuesta Económica Contrato Plan Desarrollo Proyecto WBS Cronograma Casos de Uso PROCEDIMIENTO Gestión de Riesgos 25 Formato Gestión de Riesgos Formato Reporte de Riesgos IV. RESULTADOS OBTENIDOS Actualmente se entregaron los procedimientos y los formatos que la empresa (Universidad Tecnológica del Estado de Querétaro) necesita para llevar a cabo su certificación basándose en CMMI nivel 2. Se realizaron de una forma sencilla pero completa para que el personal que va trabajar con estos documentos no tenga inconvenientes al utilizarlos. Es importante aclarar que el proyecto fue modificado a casi un mes y medio de terminar la estadía profesional se había mencionado anteriormente trabajar con Moprosoft y se modificó a CMMI por ello se llegó a un acuerdo tanto con los profesores que nos tutoraban y se coincidió en que solo sería el nivel 2 de CMMI. XI. ANÁLISIS DE RIESGO En este caso el riesgo más contundente fue que se modificó el proyecto a poco tiempo de terminar la estadía profesional y que los avances generados eran con la metodología anteriormente solicitada. Con el proyecto los riesgos pueden ser esperados o inesperados, lo más grave sería que la empresa no estuviera preparada para poder salir de este tipo de inconvenientes. 26 Riesgo Nivel del Riesgo Cambio de Requerimientos Alto Enfermedad de programador Media Incumplimiento de contrato Alto Mal uso de información Alto XII. CONCLUSIONES Se entregó a la Universidad Tecnológica del Estado de Querétaro una metodología basada en CMMI, acompañada de técnicas, procedimientos y procesos certificados con los cuales van a poder realizar software con la tranquilidad de que sus productos van a contar con la calidad que se necesita para estar al nivel de grandes industrias. XIII. RECOMENDACIONES 1. Se recomienda tener un plan de contingencia de riesgos 2. Respaldo de formatos, procedimientos y proyectos. 3. Mesa de trabajo. 4. Juntas Efectivas (cliente-empresa) 5. Dejar claros los requerimientos con el cliente desde un inicio para que al transcurso del tiempo no se generen inconvenientes que afecten el factor del tiempo. 6. Personal asignado para manejo de información confidencial. 27 XIV. REFERENCIAS BIBLIOGRÁFICAS (García, 2001) García Romero, Claudia. “El Modelo de Capacidad de Madurez y su aplicación en Empresas Mexicanas de Software”. Tesis de Maestría en Sistemas Computacionales. Universidad de las Américas-Puebla. Mayo 2001. (Moreno, 2004) Moreno Álvarez, José Luis. “Aplicación de un Sistema Experto para el desarrollo de Sistema Evaluador del modelo Capability Maturity Model (CMM) niveles dos y tres.” Tesis de Maestría en Sistemas Computacionales. Universidad de las Américas-Puebla. Mayo 2004 (Royce, 2002). Royce, Walker. “CMM vs CMMI: From Conventional to Modern Software Management”. Rational Software, 2002. Carnegie Mellon Software Engineering Institute, CMMi® for Development Version 1.2, CMMi-DEV, V 1.2, CMU/SEI-2006-TR-008 Project Management Institute, A Guide to the Project Management Body of Knowledge 4th Edition, 2004. Morales, Mauricio F., Diplomado en Gerencia de ProyectosSobre la Base Metodológica del PMBOK®, 2001 – 2009, U-Mynd Ltda. Sherer, Wayne. Contrasting CMMi and the PMBOK®, CMMi Technology Conference and User Group, Noviembre 2005. Sherer, Wayne / Thrasher, Sandy. CMMi and PMBOK® Mappings, 2005. 28