Revista Tlatemoani. ISSN: 1989-9300

---

ACTIVIDADES PARA EL ASEGURAMIENTO DE LA CALIDAD EN LA ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

---

INTRODUCCIÓN
A lo largo del tiempo el concepto de calidad ha adquirido un carácter multidimensional, debido a que los diferentes autores lo han enfocado desde puntos de vistas diferentes, para alcanzarla se ha transitado por varias etapas, comenzando con la verificación y terminando en la calidad total, pasando por el control y el aseguramiento de la misma. El hecho de que el software constituye un producto de conocimiento de difícil estandarización, hace necesaria la aplicación de estándares de calidad: El Instituto de Ingenieros en Electricidad y Electrónica (Institute of Electrical and Electronics Engineers, IEEE), la Integración del Modelo de Madurez de las Capacidades (Capability Maturity Model Integration, CMMI), la Organización Internacional de Normalización (International Organization for Standardization, ISO), que garanticen lograr un producto final de total eficacia.
Hoy en día, ha aumentado la complejidad con la que se desarrollan sistemas de información para la industria, por lo que resulta difícil generar productos que cumplan cabalmente con las expectativas del cliente. En el transcurso de los años empresas cubanas de software han buscado diferentes vías para crear productos informáticos de comercialización o para uso estratégico dentro de las entidades.
La Industria Cubana del Software se ha convertido en un sector de vital importancia para la economía del país. A través de los años se han realizado numerosos estudios sobre las causas del fracaso de los proyectos, muchos de estos, tienen su raíz en malas prácticas de ingeniería y gestión de software durante el proceso de desarrollo, pero gracias a la disciplina conocida como Gestión de Configuración muchos de estos problemas han podido erradicarse.
El presente estudio surge como necesidad de estandarizar un procedimiento dirigido al control y aseguramiento de la calidad en la administración de la configuración durante la vida del software, lo que propició el  estudio   de las herramientas existentes que llevan a cabo el control de versiones durante la vida del  software y los procedimientos  utilizados en las empresas  productoras de software: la Casa de Software SIGTA-ETECSA, DESOFT, SOFTEL, Supervisión, Control y Adquisición de Datos (SCADA) 5  y a nivel internacional AMCIS, para lograr un mayor control y calidad en la administración de la configuración e incrementar el grado de éxito en los proyectos de desarrollo de software. Es por ello que el objetivo de la presente investigación radica en la propuesta de actividades para el procedimiento de la administración de la configuración y cambio del software que sirva de guía a los proyectos de desarrollo de software en la Universidad de las Ciencias Informáticas (UCI).

DESARROLLO
La Administración de la Configuración del Software (Software Configuration Management, SCM) nace como una de las disciplinas para el control y la administración de la evolución del software, debido a que el programa de computador cambia constantemente, por lo que es necesario mantener la integridad y consistencia del producto. Se asume el criterio de Ivar Jacobson que plantea: “Gestión de Configuración es el proceso de soporte cuyo propósito es identificar, definir y almacenar en una línea base los elementos de software, controlar los cambios, reportar y registrar el estado de los elementos y de las solicitudes de cambio; asegura la completitud, consistencia y corrección de los elementos; controla, almacena, maneja y libera los elementos asociados al producto de software”. Este concepto establece una estrecha relación entre las herramientas y técnicas (procesos o metodologías) que una organización utiliza para administrar las configuraciones de los componentes de software conservando la integridad de los componentes del producto de software, evaluando y controlando los cambios sobre ellos, así como facilitar la visibilidad del producto a todo el equipo de proyecto.
Se realizó  estudio detallado de los trabajos anteriores referente a la Gestión de Configuración del Software (GCS),   planteamientos del Instituto de Ingenieros de Software (Software Engineering Institute, SEI) y se aplicaron  entrevistas con el objetivo de obtener información, acerca del procedimiento y plantillas que emplean las instituciones de desarrollo de software y los proyectos dentro de la Universidad de las Ciencias Informáticas (UCI) para efectuar el control de la Administración de la Configuración y Cambio, así como preguntas relacionadas con las herramientas utilizadas por estas empresas y estos proyectos para el control de las distintas versiones por la que pasa el software durante todo el ciclo de vida.
Las actividades propuestas para el procedimiento reflejan  una guía  para controlar la Gestión de Configuración de Software (GCS) dentro del ciclo completo de desarrollo de software, así como los requerimientos mínimos que deben tener las herramientas de soporte asociadas a este proceso. El  procedimiento propuesto garantiza la utilización de herramientas adecuadas en el área de proceso clave asociado a la gestión de la configuración e indica a los desarrolladores de software  como llevar a cabo sus tareas.

Propuesta y descripción de las actividades propuestas para el procedimiento.

• Todo Elemento de Configuración (ECS) (documento o programa) que se encuentre en la librería dinámica 6 o de programación, se promoverá a la librería controlada o calidad cuando los desarrolladores hayan efectuado las pruebas unitarias y sus resultados hayan sido exitosos.
• Una vez que los ECS se encuentren almacenados en la librería de Calidad 7, el Grupo de Aseguramiento de la Calidad (GAC) realizará las revisiones técnicas formales correspondientes. En caso que se detecte un defecto en el software o código del producto ocurrirá un proceso de remoción hacia la librería de programación, hasta que el defecto sea corregido por parte de los desarrolladores y las pruebas unitarias  hayan sido exitosas. Luego el/los ECS se liberará de nuevo a la librería de calidad, en la cual se le harán las pruebas correspondientes (GAC).
• En caso que las pruebas realizadas a el/los ECS fueran exitosas, estos se liberarán a la librería de producción, iniciándose con esto el ingreso del ECS al proceso de Control de Configuración. Seguidamente el Responsable de Configuración del proyecto le comunicará al Comité de Control de Configuración que hubo un ingreso a configuración.
• Al iniciarse este proceso, existirá la plantilla de Ingreso a Configuración (IC) y la de Lista de Copias Autorizadas (LCA), la cuales serán actualizadas y controladas por el Comité de Control de Configuración.
• Una vez que el producto se encuentren en la librería Estática o de Producción 8, estará listo para el proceso de instalación por parte del cliente. En caso que el cliente después de haber probado el producto detecte algún error en el sistema o desee agregarle una nueva funcionalidad, esto implicará un cambio en el producto, por lo que deberá realizar una solicitud de cambio formal, el  que se documentará a través de una plantilla de Solicitud de Cambio (SC).

Los integrantes del grupo de desarrollo de un proyecto de una facultad, podrán realizar “Cambios Informales” a los ECS que ellos mismos hayan desarrollado antes que formen parte de una Línea Base y se hayan introducido a la base de datos del proyecto. Una vez que los desarrolladores de un proyecto realicen una solicitud de cambio a otro proyecto, porque estén trabajando en conjunto, esta se documentará a través de una plantilla de Solicitud de Cambio (SC).

• El cliente le entregará esta plantilla al Gerente de Proyecto a nivel de facultad, el cual estará encargado de entregar esta solicitud de cambio al Responsable del Producto sobre el cual se solicitó dicho cambio.
• El desarrollador o grupo de desarrolladores del proyecto que realizaron la solicitud de cambio le entregarán esta plantilla al Responsable del Producto sobre el cual se haya realizado la solicitud de cambio.
• El Responsable del Producto verificará el contenido de dicha plantilla y en caso de una no conformidad se la devolverá a su originador para su corrección. Una vez correcto todos los datos le entregará dicha solicitud al Responsable de Configuración, la cual registrará, asignará un número y un estado para su seguimiento y control.
• El Responsable de Configuración remitirá la solicitud de cambio al Comité de Control de Cambios, el cual analizará y evaluará la solicitud de cambio, aprobando, rechazando o postergando la implementación de los cambios teniendo en cuenta:
• Envergadura del cambio.
• Complejidad del cambio, en relación a los sistemas involucrados.
• Fecha en que se necesita implementarlo.
• Impacto en el trabajo actual y en el futuro.
• Criticidad del área involucrada.
• Cambios aprobados, actualmente en desarrollo.
• Requerimientos de pruebas para validar el cambio.
• Políticas.
• Líneas base afectadas.
• Las prioridades.
• La urgencia del cambio.
• La gravedad de la falla detectada.
• En caso de ser postergada o rechazada la solicitud de cambio, el Comité de Control de Cambio la devolverá al Responsable del Producto, explicándole la razón de la decisión tomada, las que se harán llegar a la persona que realizó la petición del cambio mediante el Gerente de Proyecto.

En caso de ser postergada o rechazada la solicitud de cambio, el Comité de Control de Cambio del proyecto sobre el cual se hizo la solicitud de cambio la devolverá al Responsable de Configuración, explicándole la razón de la decisión tomada, las que se harán llegar a los desarrolladores del proyecto que realizaron la solicitud de cambio mediante el Responsable del Producto.

• En caso de ser aprobada la solicitud de cambio por parte del Comité de Control de Cambio, esta será evaluada nuevamente por el Responsable del Producto para estimar el esfuerzo técnico que demandará su implementación, los costos asociados y los posibles efectos secundarios e impacto sobre otras funciones del sistema, el cual se le informará al originador de la solicitud de cambio, si está de acuerdo con los costos impuestos y el tiempo de desarrollo del cambio se procederá al proceso de implementación del cambio.
• Posteriormente las copias de seguridad de los ECS serán removidos desde la librería de producción hacia la librería de programación para el desarrollo del cambio. Seguidamente el Comité de Control de Configuración registrará en la plantilla de Listas de Copias Autorizadas (LCA) los desarrolladores que tienen autorización para efectuar copias de trabajo de el/los elementos de configuración a modificar.
•  Una vez actualizada dicha plantilla, el Responsable de Configuración informará a todos los incluidos en esta lista que tienen derecho a realizar cambios sobre el/los elementos de configuración registrados.
• El Responsable de Configuración además informará a los desarrolladores que la autorización a realizar copias de trabajo de el/los ECS podrán quedar obsoletas cuando el/los ECS se encuentren en estado cerrado. Le informará también que ya pueden comenzar con la implementación de los cambios solicitados. A partir de este momento se inmovilizará el/los ECS sobre el que se realizará los cambios y los ECS relacionados, con el objeto de evitar superposición de cambios.
•  El Comité de Control de Cambio será el responsable del seguimiento y control de la implementación de los cambios, en cuanto a cumplimiento de objetivos, metas y plazos; verificación y validación de las modificaciones.
•  Los desarrolladores luego de haber finalizado la implementación de los cambios y haber efectuado las pruebas unitarias correspondientes, si fueron exitosas, el/los ECS se promoverán a la librería de calidad, para que el GAC del proyecto realice las revisiones técnicas formales con el objetivo de certificar que el problema se ha corregido o se han satisfecho los nuevos requisitos. Si las pruebas fueron exitosas los desarrolladores actualizarán la plantilla Nota de Cambio, para certificar que el cambio fue realizado satisfactoriamente.
•  Dicha plantilla se le hará llegar al Comité de Control de Configuración, el cual verificará su contenido y en caso de una no conformidad se la devolverá a su originador para su corrección.
•  Una vez correcto los datos, el Comité de Control de Configuración le enviará dicha plantilla al Responsable de Configuración, el cual registrará, asignará un número y un estado. Posteriormente entregará dicha plantilla al Responsable del Producto para que tenga constancia que el cambio fue efectuado.
•  Luego de haber informado al Responsable del Producto, este verificará el/los ECS modificados, y si está de acuerdo con los cambios implementados, los ECS serán promovidos hacia la biblioteca de producción, donde se almacenará la nueva versión del producto con los errores corregidos. Seguidamente el Grupo de Aseguramiento de la Calidad a nivel de Facultad realizará las auditorías para verificar que todo el proceso de control de cambio se realizó de acuerdo al procedimiento establecido.
•  Si la auditoría no tuvo un resultado satisfactorio el Grupo de Aseguramiento de la Calidad a nivel de Facultad se lo comunicará al Responsable del Producto, el cual se lo devolverá al Responsable de Configuración, el cual tomará las medidas pertinentes para la corrección correspondiente.
•  Si la auditoría fue exitosa, el Grupo de Aseguramiento de la Calidad de la Facultad se lo comunicará al Responsable del Producto, el cual le hará llegar el producto al Gerente de Proyecto y almacenará en el Registro Histórico de Cambios de Proyectos (RHCP) la plantilla Nota de Cambio, para tener un registro de todos los cambios realizados en el proyecto.
• Si la auditoría fue exitosa el Responsable del Producto les comunicará a los integrantes del proyecto (desarrolladores) que realizaron la solicitud, que el cambio fue efectuado de forma exitosa y almacenará en el Registro Histórico de Cambios de Proyectos (RHCP) la plantilla Nota de Cambio, para tener un registro de todos los cambios realizados en el proyecto.
•  Una vez que el Gerente de Proyecto esté de acuerdo con el producto entregado, el Responsable de Configuración retirará de circulación y destruirá todas las copias autorizadas, y ahora obsoletas, del ítem modificado, asignándole el estado de cerrado y se reemplazará la versión anterior del producto, por la nueva versión/revisión.
•  Como resultado final el Gerente de Proyecto hará entrega del producto con los cambios efectuados al originador de la solicitud de cambio y el Responsable del Producto lo enviará  con los cambios efectuados a los desarrolladores del otro proyecto.

A continuación aparece la representación gráfica de las actividades a ejecutar en el procedimiento de control y aseguramiento de la calidad en la administración de la configuración.
Ejemplo:

• Se  elaborara  un sistema de software, el  elemento de configuración: modelo de datos, almacenado en  la librería dinámica o de programación,  después de haber realizado las pruebas unitarias y obtenido resultados exitosos por los desarrolladores (programadores), se promoverá a la librería de calidad donde, el GAC realizará las revisiones técnicas formales correspondientes,  si se detecta un defecto se reenviará a la librería dinámica nuevamente hasta estar correctamente implementado.

• El  ECS, modelo de datos, ya corregido,  en la librería de calidad se liberará a la  librería de producción, iniciándose con ello  el ingreso del ECS al proceso de Control de Configuración, seguidamente el Responsable de Configuración del software le comunicará al Comité de Control de Configuración que hubo un ingreso a configuración. Al iniciarse este proceso, existirá la plantilla de Ingreso a Configuración (IC) y la de Lista de Copias Autorizadas (LCA),  las cuales serán actualizadas y controladas por el Comité de Control de Configuración.

• Una vez que el sistema de software se encuentre en la librería de producción, estará listo para el proceso de instalación por parte del cliente. En caso que el cliente después de haber probado el producto detecte algún error en el sistema o desee agregarle una nueva funcionalidad, esto implicará un cambio en el producto, por lo que deberá realizar una solicitud de cambio formal, la que se documentará a través de una plantilla de Solicitud de Cambio (SC).
• El cliente le entregará esta plantilla al Gerente de Proyecto, el cual estará encargado de entregar esta solicitud de cambio al Responsable del Producto sobre el cual se solicitó dicho cambio.
• El Responsable del Producto verificará el contenido de dicha plantilla y en caso de una no conformidad se la devolverá a su originador para su corrección. Una vez correcto todos los datos le entregará dicha solicitud al Responsable de Configuración, la cual registrará, asignará un número y un estado para su seguimiento y control.

• En caso de ser postergada o rechazada la solicitud de cambio, el Comité de Control de Cambio la devolverá al Responsable del Producto.
• En caso de ser aprobada la solicitud de cambio por parte del Comité de Control de Cambio, esta será evaluada nuevamente por el Responsable del Producto.
• Posteriormente las copias de seguridad del ECS, modelo de datos, serán removidas desde la librería de producción hacia la librería de programación para el desarrollo del cambio.
• Una vez corregido el elemento de configuración, modelo de datos, y actualizado el sistema de software se realiza  la entrega al cliente del producto final para su instalación y  utilización.

CONCLUSIONES

Se realizó un estudio de las  actividades de referencia para el procedimiento de la administración de la configuración y cambio del software utilizado por instituciones productoras de software, con el propósito de estandarizar la utilización de las mismas.
Se constataron  las herramientas que han existido y otras que han surgido en los  últimos años, para solucionar situaciones que han provocado el fracaso en la  producción de software.
Se  establece una disciplina de trabajo en las tareas asociadas al control de cambios a través de las actividades para el procedimiento de la administración de la configuración y cambio del software.
Se evidenció el papel protagónico de  la Administración de la Configuración y Cambio (ACC) en  la  disciplina en el proceso de desarrollo de software.

RECOMENDACIONES

•  Aplicar  las  actividades para el procedimiento de la administración de la configuración y cambio del software en los proyectos de la Universidad de las Ciencias Informáticas y evaluar sus resultados.
• Enriquecer el estudio de las herramientas analizadas para la administración de la configuración y cambio para tener un conocimiento más profundo de cuáles de las herramientas existentes en el mercado mundial serían las propicias para solucionar muchos de los problemas en esta área de proceso clave.

BIBLIOGRAFÍA

• Angélica Antonio y col, (2010) La Gestión de la Configuración del Software. Volumen (59): pág. 1-59. [Disponible  en : http://ingenieriadesistemasuade.googlecode.com]
• Blanco Encinosa, Lázaro y col. (2008) Sistemas de Información para el economista y el contador. Ciudad de La Habana, Editorial Félix Varela.
• CMM Modelos de calidad, (2005). Carnegie Mellon Software Engineering Institute. [Disponible en: http://www.SEI.com], consultado septiembre .2012
• SOFTEL. (2010).  Documento Plan de Gestión de la Configuración del Software Empresa de desarrollo de software. La Habana. Cuba.
• SIGTA. (2009).Manual para la Gestión de la Configuración. Empresa de Telecomunicaciones de Cuba. Gerencia Casa de Software .Ciudad de la Habana. Cuba
• Ernesto Quiñones A. (2009). Modelos de Calidad de Software y Software Libre .Extraído el 5 de mayo del 2009 [Disponible en: http://www.apesol.org.pe]
• Gener Navarro, Enrique J et al. (2005) Elementos de informática básica. Ciudad de La Habana, Editorial pueblo y educación.
• DESOFT. (2009) Documento Plan de Gestión de la Configuración del Software. La Habana. Cuba.

5 SCADA, Supervisión, Control y Adquisición de Datos, es un concepto que se emplea para realizar un software para ordenadores que permite controlar y supervisar procesos industriales a distancia.
6 Librería dinámica o de programación conserva las entidades de software recientemente creadas y/o modificadas dentro de un proyecto.
7 Librería Controlada o de Calidad contiene todos los elementos de configuración ya desarrollados y probados.
8 Librería Estática o de Producción  almacena todos los elementos de producción ya listos para su liberación, además de llevar el control de todo el proceso de soporte al producto.

Recibido: 04/09/2017 Aceptado: 01/01/2018 Publicado: Abril de 2018

---

Nota Importante a Leer:
Los comentarios al artículo son responsabilidad exclusiva del remitente.
Si necesita algún tipo de información referente al articulo póngase en contacto con el email suministrado por el autor del articulo al principio del mismo.
Un comentario no es mas que un simple medio para comunicar su opinion a futuros lectores.
El autor del articulo no esta obligado a responder o leer comentarios referentes al articulo.
Al escribir un comentario, debe tener en cuenta que recibirá notificaciones cada vez que alguien escriba un nuevo comentario en este articulo.
Eumed.net se reserva el derecho de eliminar aquellos comentarios que tengan lenguaje inadecuado o agresivo.
Si usted considera que algún comentario de esta página es inadecuado o agresivo, por favor, escriba a lisette@eumed.net.

---