Maira Alejandra Bedoya Núñez. Universidad Francisco de Paula Santander Av. Gran Colombia No. 12E-96 Colsag. Cúcuta Norte de Santander ,

Transcripción

1 Procesos necesarios para alcanzar el Nivel 2 de CMMI, en el área de Administración de Configuraciones de Software, para empresas pequeñas desarrolladoras de software. Judith del Pilar Rodríguez Tenjo Universidad Francisco de Paula Santander, Directora GIDIS Av. Gran Colombia No. 12E-96 Colsag. Cúcuta Norte de Santander , judithdelpilarrt@ufps.edu.co Maira Alejandra Bedoya Núñez Universidad Francisco de Paula Santander Av. Gran Colombia No. 12E-96 Colsag. Cúcuta Norte de Santander , alejandrabn@gmail.com ABSTRACT The purpose of this article is to provide a robust document in which clearly the concepts and activities of the Area Management software configurations, Level 2 of the Model Quality CMMI, primarily detailing the processes, procedures and formats, which describe how to carry out the Software Configuration Management, CMMI specified, by reference to the goals, practices and sub-practice area selected for this process. Categoría D.3.3 [Ingeniería del Software]: Ingeniería del Software Palabras Claves: Configuración, Software, Cambio, Administración, CMMI, 1. INTRODUCCION El modelo CMMI se ha convertido en un estándar en la calidad de la industria internacional de producción de software, cada vez más empresas desarrolladoras de software, se plantean la necesidad de adoptar el modelo, lo que se inicia enfocando sus investigaciones e intereses en alcanzar el Nivel 2; pero para lograrlo existen varios inconvenientes. Uno de estos inconvenientes es la falta de información completa y veraz a cerca de las actividades que deben llevarse a cabo, en este caso para desarrollar cada una de las áreas de proceso del nivel 2, ya que CMMI dice el Qué? debe hacerse, pero no dice Cómo? debe hacerse. Para la realización de este artículo, se enfocará en el área de Administración de Configuraciones de software, la cual es fundamental en la implantación del modelo; y en su desarrollo se presenta una caracterización de los procesos, procedimientos y formatos, que explican el Cómo? Se lleva a cabo la aplicación de las metas, prácticas y sub-prácticas, que describe el modelo CMMI, en ésta área del nivel 2. A través del desarrollo de las actividades de la administración de configuración; como son la identificación de elementos, el control de cambios, el control de versiones, la generación de informes de estado y las auditorias, se logra dar una visión menos complicada de lo que es la implantación de gestión de configuración en un proyecto [1],[8], [9]. 1. CMMI CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. CMMI propone 5 distintos modelos de madurez de las organizaciones [1]: 1.1 Inicial o Nivel 1 CMMI. Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los individuos. Los procedimientos son inexistentes o localizados a áreas concretas y no existen plantillas definidas a nivel corporativo. Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, no hay control sobre el estado del proyecto, el

2 desarrollo del proyecto es completamente opaco, no se sabe lo que pasa en él [1]. alcanzar el Nivel de Maduración 2 establecido por el Software Engineering Institute. 1.2 Repetible o Nivel 2 CMMI gestionado Se normalizan las buenas prácticas en el desarrollo de proyectos (en base a la experiencia y al método). En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés. Están definidos los productos a realizar. Se definen hitos para la revisión de los productos. Quiere decir que el éxito de los resultados obtenidos se puede repetir [2]. 1.3 Definido o Nivel 3 CMMI La organización entera participa en el proceso eficiente de proyecto software. Se conoce de antemano los procesos de construcción de software. Existen métodos y plantillas bien definidas y documentados. Los procesos no solo afectan a los equipos de desarrollo sino a toda la organización relacionada. Los proyectos se pueden definir cualitativamente. 1.4 Cuantitativamente Gestionado o Nivel 4 Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización. Se puede seguir con indicadores numéricos (estadísticos) la evolución de los proyectos. Las estadísticas son almacenadas para aprovechar su aportación en siguientes proyectos. Los proyectos se pueden pedir cuantitativamente. 2.1 Configuración de Software Durante el ciclo de vida de un producto software se genera información de diferente naturaleza, que abarca desde las especificaciones del sistema hasta el plan de retiro e incluye documentación, archivos, bases de datos, cursos, etc. Todo este conjunto de información producida durante el desarrollo del proyecto recibe el nombre de configuración del Software. 2.2 Elemento de Configuración del Software (Ecs) Un elemento de la configuración del software es la información creada como parte del proceso de ingeniería un ECS (elemento de configuración de software) es un documento, un conjunto completo de casos de prueba o un componente de un programa dado. 2.3 Líneas Base Las Líneas Base pueden ser vistas como hitos en el proceso de desarrollo que se constituyen en función de la aprobación de uno o varios ECS mediante la ejecución de revisiones técnicas formales, ver figura Optimizado o Nivel 5 Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica. Con base a criterios cuantitativos se pueden determinar las desviaciones más comunes y optimizar procesos. 2. ADMINISTRACIÓN DE CONFIGURACIÓN DE SOFTWARE La Administración de Configuración de software se puede definir como el área de la Ingeniería de Software cuya misión es controlar la evolución de un producto desarrollado, involucrando un conjunto de técnicas para gestionar con eficiencia los cambios que se realicen sobre ese producto a lo largo de su ciclo de vida [2]. La Administración de Configuración de Software es una de las actividades claves para que una organización de desarrollo pueda Figura 1. Líneas Base Practico. Roger S. Pressman 2.4 Actividades de la administración de la configuración. De acuerdo a lo especificado por la IEEE, la Gestión de configuración contempla las siguientes actividades. [2], [3]: Identificación de la configuración:

3 Consiste en identificar la estructura del producto, sus componentes y tipo, haciéndolos únicos y accesibles mediante algún procedimiento Control de cambios en la configuración Consiste en controlar los cambios que se producen sobre un producto a lo largo de su ciclo de vida Control de versiones cambios en la configuración. Implica la identificación y seguimiento de diferentes versiones y releases del sistema Generación de Informes de Estado. Consiste en la producción de informes sobre el estado de los ECS de un producto y de las solicitudes de cambio realizadas sobre ellos Auditoria de configuración Consiste en la validación de la integridad de un producto, manteniendo la consistencia entre sus componentes [3]. 3. IDENTIFICACIÓN DE METAS, PRÁCTICAS Y SUBPRÁCTICAS. La Administración de Configuración de Software (SCM) es una disciplina de la Ingeniería de Software que se preocupa de: Identificar y documentar las características funcionales y físicas de los elementos de configuración. Controlar los cambios a tales características. Reportar el proceso de tales cambios y su estado de implantación. Una vez identificados los antecedentes y la estructura del CMMI, además de las definiciones pertinentes del área de administración de configuraciones de software del nivel 2; y siguiendo lo descrito en CMMI, es necesario tener presente las metas, prácticas y subprácticas, para la ejecución de las actividades necesarias en la realización de administración de configuraciones de software; en el ítem siguiente se identifican las mismas de manera detallada, incluyendo los procedimientos, plantillas y formatos asociados [8]. 3.1 procesos y procedimientos: Metas, prácticas y subprácticas 2.5 Equipo Administración de la Configuración del Software. Las diferentes actividades de administración de Configuración, delegan responsabilidades sobre los integrantes del Equipo de Administración de Configuración [8], [9], los cuales se organizan en la figura 2, de la siguiente forma: 3.1 Meta 1: Establecer las líneas de base para identificar los productos Práctica Identificar los ítems de configuración ADMINISTRADOR DE CONFIGURACIONES Para controlar y gestionar los elementos de la configuración se debe identificar cada uno de forma única y organizarlos mediante un enfoque orientado a objetos [9]. La asignación de identificadores se lleva a cabo mediante el siguiente procedimiento: RESPONSABLE DE CONTROL DE CAMBIOS SECCIÓN DE CONTROL DE CONFIGURACIÓN JEFE DE PRUEBAS PROGRAMADOR a) Darle un identificador b) Asignarle un nombre c) Describir en Elemento de Configuración d) Definir información e) Definición de las relaciones del ECS Figura 2. Equipo de administración de configuraciones Cada uno de estos roles ejercen un conjunto de responsabilidades, además de las habilidades, la educación, la experiencia y la formación que exige cada uno de los roles debe ser documentados Práctica Establecer un sistema de administración de configuraciones Durante la realización de las distintas actividades, los productos, en función de su naturaleza, van pasando por los controles de estado que establece su ciclo de vida, lo que debe ser registrado en un sistema de gestión de la configuración [6].

4 En la creación del sistema de administración de la configuración se deben especificar los contenidos a registrar en dicho sistema, el cual deberá de los mismos proporcionar información a cerca del estado del producto Práctica Crear las líneas base En el contexto de la ingeniería del software definimos una línea base como un punto de referencia en el desarrollo del software y que queda marcado por el envío de uno o más elementos de configuración del software (ECS) y la aprobación de ECS obtenido mediante una revisión técnica formal, ver figura 3. las líneas base, a lo largo del desarrollo del software, es decir en todo su ciclo de vida se debe llevar el seguimiento de cada uno de los ítems de configuración que componen las líneas base, por medio de los registros y archivos de la biblioteca (Base de Datos),la cual guarda el historial de toda la información, cambios etc., que tiene un ítem de configuración durante el ciclo de vida del producto, ver Figura 4. Figura 4. Control de Cambios Práctico. Roger Pressman. Figura 3. Creación de líneas base Práctico. Roger S. Pressman. 3.2 Meta 2: Hacer un seguimiento y controlar los cambios en los productos que están bajo la administración de la configuración Práctica Hacer un seguimiento de los requerimientos de cambio de los ítems de configuración. El inicio del proceso de control de cambios es la presentación de la solicitud de cambio, una vez recibida, la solicitud de cambio es dada de alta en un registro de cambios (o Base de Datos) donde se le asigna un código de clasificación para permitir su rápida ubicación y rastreo, con el fin de hacer un posterior seguimiento [4] Práctica Controlar los cambios a los ítems de configuración El control es mantenido sobre la configuración de las líneas base del producto; este control incluye el seguimiento de la configuración de cada uno de los elementos de configuración, aprobando una nueva configuración si es necesario y actualizando 3.3 Meta 3: Establecer la integridad de las líneas base Práctica Establecer registros de la administración de la configuración. Para poder tener el control correcto de la configuración del sistema en todo momento es necesario que se tenga una documentación ordenada y completa de todas las modificaciones que se hacen al producto de manera global y de manera particular a las líneas base y elementos de configuración, con el fin de que se pueda hacer el seguimiento y control de los mismos y además que se pueda obtener la información completa, actualizada y pertinente en un momento determinado [4], [5], [/] Practica Realizar auditorias a la configuración El proceso de auditoria consiste en asegurar que el producto construido implementa su especificación, y verificar su completitud y coherencia basados en los reportes de pruebas y en la documentación [3], [4], [7]. Esta actividad tiene lugar en las fases finales del ciclo de vida previamente a la liberación del producto, ver Figura 5. Una vez se han efectuado y aprobado las auditorias, el administrador de configuración procede a crear la línea base, la

5 cual será almacenada en el depósito de desarrollo. Sobre la línea base creada se procede a ejecutar el conjunto de todas las pruebas, si alguna prueba falla se reinicia el proceso, si todas las pruebas son superadas, se almacena la línea base en el depósito de producción y se pone la versión a disposición de los usuarios. formatos a seguir, para quienes deseen, alcanzar el nivel 2 de CMMI. Se pueden apreciar procesos tales como: el proceso de identificación de ítems, el proceso de solicitud de cambios, proceso de control de cambios, proceso de control de versiones, proceso de auditoria; igualmente se pueden verificar características, como en el caso de las responsabilidades y conformación del grupo de Administración de Configuraciones de Software, en las que se describen las habilidades, grado de educación y experiencia que debe tener cada rol propuesto y las responsabilidades de cada uno de los mismos. Por otra parte se obtuvo un esquema que enmarca el contenido previsto para el plan de administración de configuraciones de software, al igual que su propósito. Figura 5. Proceso Auditoria de Configuraciones. Practico. Roger Pressman Control de Versiones en la Configuración. La finalización de procesos de cambio y/o modificaciones normalmente ocasionará un cambio de versión del producto software [2,6,7], ver Figura 6. En relación a los formatos se generaron formatos para: desviaciones en los documentos, desviaciones en actividades, formulario de solicitud de cambios, detalle de la solicitud de cambios, formulario de informe de cambio, formulario de orden de cambio e informe de cambio aprobado-desaprobado. Cabe resaltar que el material aquí dispuesto, es de gran valor para una futura implementación de una herramienta automática para la administración de configuraciones, la cual permita agilizar dicho proceso. 5. CONCLUSIONES Al llegar al final de esta investigación, se puede denotar principalmente la importancia del modelo CMMI en el desarrollo de software, ya que sus niveles permiten a las empresas conocer la madurez de los procesos que se ejecutan, mejorando evolutivamente las buenas prácticas en el desarrollo de proyectos. La administración de configuraciones es un aspecto de la ingeniería del software que permite identificar los elementos de un proyecto, proporcionando el control de los mismos y la documentación pertinente de su estado, al mismo tiempo consigue claridad de gestión, mediante la delegación de responsabilidades al personal encargado de las actividades de control [9]. 4. RESULTADOS Y DISCUSIÓN Los resultados obtenidos en la realización de este artículo, son producto del trabajo de grado que involucraron una serie de consultas e investigaciones bibliográficas, que permitieron caracterizar los procesos, procedimientos, características y Figura 6. Evolución de versiones de un producto software. Practico. Roger Pressman. El modelo CMMI en el nivel 2 para el área de administración de configuraciones de software, presenta una serie de Metas a alcanzar, prácticas y subpráticas a ejecutar, ellas engloban una grupo de procesos y procedimientos, que se deben realizar para que la configuración del software sea administrada correctamente, contando así con una gestión de procesos, en donde los cambios se controlan, se documentan y se puede conocer la configuración del software en todo momento. Finalmente puede decirse que la administración de configuraciones de software dota al proyecto de un alto grado de robustez al ahora de consultar el estado del producto y aún más importante a la hora de realizar un cambio, tarea que es muy delicada ya que existen elementos que requieren de especial atención cuando van a ser modificados.

6 6. AGRADECIMIENTOS A Dios todopoderoso, al Grupo de Investigación de Desarrollo de Ingeniería del Software de la Universidad Francisco de Paula Santander GIDIS, por permitir llevar a cabo este proyecto y poder aplicarlo en una empresa pequeña de software. 7. REFERENCIAS [1] Software Engineering Institute. CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI- SE/SW/IPPD/SS, V1.1) Staged Representation. CMU/SEI TR-012 ESC-TR [2] Roger S. Pressman. Ingeniería del Software. Un Enfoque Práctico. Sexta Edición. Mc Graw Hill Capítulo 27: Gestión del Cambio [3] Joaquin Gracia 14 de Agosto de 2005 CMM - CMMI_ Calidad_ Ingeniería del Software.htm consultado el [4] Antonio Jiménez A. Gestión de Configuración - Apuntes del Master de Ingeniería de Software UPM. [5] Roberto Canales Mora Calidad en el desarrollo de Software. CMMI consultado el [6] Stephen R. Schach. Sexta Edición. Mc. Graw Hill Capítulo 5: las herramientas de Oficio, página127 a 132. [7] Roger S. Pressman. Ingeniería del Software. Un Enfoque Práctico. Quinta Edición. Mc. Graw Hill Capítulo 9: Gestión de la Configuración del Software. [8] Judith del Pilar Rodríguez Tenjo. Trabajo Tesis Maestría, Propuesta para implantar el nivel 2 CMMI en la División de Sistemas de la Universidad Francisco de Paula Santander, Cúcuta Norte de Santander, Colombia, 30 mayo [9] Maira Alejandra Bedoya Nuñez, Tesis de Grado Caracterización de los procesos que son necesarios en el desarrollo de software para alcanzar el Nivel 2 de calidad de CMMI, en el área de administración de Configuraciones de Software para Empresas desarrolladoras de Software. Universidad Francisco de Paula Santander. Cúcuta Norte de Santander, Diciembre 2008.