Servicios personalizados
Español (pdf)
Articulo en XML
Referencias del artículo
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
La producción de software es una actividad económica cada vez más relevante, capaz de crear empleos calificados y generar divisas (Olortegui y Llontop, 2020; Tigre y Marques, 2009). Como parte indisoluble del desarrollo científico tecnológico, el desarrollo de software representa un pilar fundamental en la industria empresarial y en la sociedad. Mientras mejores sean los softwares desarrollados, más beneficios económicos y sociales traen consigo. Por ello, un objetivo claro es la mejora de la calidad, que viene estrechamente ligada al proceso de desarrollo. Autores como De la Villa, Ruiz y Ramos (2004) y Humphrey (1989) aseveran que según el movimiento TQMi “La calidad de un sistema software se rige por la calidad del proceso usado para desarrollarlo”.
Según (Pressman y Maxim, 2019), un proceso de desarrollo de software se debe regir por guías, modelos, enfoques o normas de calidad. Por lo que se puede afirmar que una de las condiciones necesarias para garantizar un software de y con calidad, es asegurar la calidad desde su proceso de construcción, y, que una vía para lograrlo es realizar una correcta ingeniería de software, aplicando una selección adecuada de enfoques, modelos y metodologías.
Otra vía para asegurar la calidad de los productos es mediante la mejora del proceso que les permita acreditar el cumplimiento de alguno de los modelos o estándares para la evaluación y mejora de procesos que en la actualidad están disponibles en el mercado (Garzás et al., 2013; Anacona et al., 2020). Al mejorar el PDS, se intenta optimizar y aumentar la calidad de un producto, proceso o servicio a través de la evolución de los procesos. Gracias a su implementación continuada, se puede mejorar de forma incremental la calidad y eficiencia de los procesos y actividades (Mencia, 2015).
Los modelos de calidad establecen objetivos generales, prácticas y metas que sirven de guía a la organización y que, a su vez, ofrecen evidencias de que se tiene un proceso disciplinado y repetitivo (Londoño, Anaya y Tabares, 2008). Según (Suarez y Leon, 2019), los más utilizados para la implementación de mejoras de procesos en pequeñas y medianas empresas (Pymes) en Latinoamérica son ISO/IEC 29110, MoProSoft, MPS.BR, Competisoft y CMMI, siendo esta última la más popular.
Los modelos CMMI® (Capability Maturity Model® Integration) son colecciones de buenas prácticas que ayudan a las organizaciones a mejorar sus procesos. Estos modelos son desarrollados por equipos de producto con miembros procedentes de la industria, del gobierno y del Software Engineering Institute (SEI). El modelo denominado CMMI para Desarrollo (CMMI-DEV), proporciona un conjunto completo e integrado de guías para desarrollar productos y servicios (CMMI, 2010). La Tabla 1 muestra los elementos que componen el modelo y un conjunto de componentes cuya finalidad es señalar requerimientos a ser cumplidos y guiar en el cumplimiento de los mismos ( Guevara Lora y Guerrero Vera, 2019; Pazmiño y Xavier, 2019). La relación entre estos elementos se muestra en la Fig. 1.
Tabla 1 - Elementos y componentes del modelo CMMI-DEV.
|
|
Conjunto de prácticas vinculadas en un área, que, realizadas conjuntamente, satisface un conjunto de metas estimadas relevantes para alcanzar mejoras en dicha área. |
| Describe los conceptos principales cubiertos por el área de proceso. | |
| Enumera las referencias a las áreas de procesos relacionadas y refleja las relaciones de alto nivel entre ellas. | |
|
|
Especifica las características que se deben presentar para institucionalizar los procesos que implementan un PA. |
|
|
Describe una característica única que debe ser implementado para satisfacer el área de proceso. |
|
|
Descripción de una actividad que es considerada importante para alcanzar la meta genérica asociada. |
|
|
Describe las actividades que se esperan resulten en el logro de una meta genérica de un área de proceso. |
| Elementos esenciales para la mejora de procesos en un área dada, a su vez son SGs y GGs cuya satisfacción se utilizará para evaluar un PA. | |
| Describen actividades que son necesarias para lograr un componente requerido, orientando en la implementación de mejora y en la realización de evaluaciones. | |
| Ayudan a los usuarios a entender los componentes requeridos y esperados, pudiendo ser ejemplos en un recuadro, explicaciones, notas, referencias, fuentes, títulos de metas, y prácticas. Este tipo de componente no se lo puede ignorar, debido a que proporciona la información necesaria para lograr una correcta comprensión de las metas y prácticas. |
CMMI-DEV define 5 niveles de madurez (en lo adelante niveles) por los que van pasando las empresas que se certifican con este modelo. Un nivel de madurez (en lo adelante nivel) es una plataforma evolutiva definida para la mejora de procesos de la organización. Cada nivel de madurez desarrolla un subconjunto importante de procesos de la organización, preparándola para pasar al siguiente nivel de madurez. Los niveles se miden mediante el logro de las metas específicas y genéricas asociadas con cada conjunto predefinido de áreas de procesos. Los cinco niveles, cada uno de ellos una base para la mejora de proceso en curso, se denominan por los números del 1 al 5 (1-Inicial, 2-Gestionado, 3-Definido, 4-Gestionado cuantitativamente y 5-En optimización. Para cada uno de estos niveles CMMI-DEV define un conjunto de áreas de proceso (Tirado, 2021; Bayona-Oré, 2020; CMMI, 2010).
Dentro del nivel 3 se definen 11 áreas de proceso, que se agrupan en las categorías Soporte, Gestión de proyecto, Gestión de proceso e Ingeniería. Dentro de la categoría de Ingeniería se ubica el área de proceso Desarrollo de requisito (RD) que tiene como propósito fundamental educir, analizar y establecer los requisitos de cliente, de producto y de componente de producto. Esta área de proceso describe tres tipos de requisitos: de cliente, de producto y de componente de producto. El desarrollo de los requisitos incluye las siguientes, metas y prácticas específicas:
Tabla 2 - Metas y prácticas específicas del área de proceso Desarrollo de requisitos.
| SG 1 Desarrollar los requisitos de cliente | |
|---|---|
| SP1.1 Educir las necesidades. | SP1.2 Trasformar las necesidades de las partes interesadas en requisitos de cliente |
| SG 2 Desarrollar los requisitos del producto. | |
| SP2.1Establecer los requisitos de producto y de componente de producto. |
SP2.2 Asignar los requisitos de componente de producto. SP2.3 Identificar los requisitos de interfaz. |
| SG 3 Analizar y validar los requisitos. | |
|
3.1 Establecer los conceptos y los escenarios de operación. 3.2 Establecer una definición de la funcionalidad y de los atributos de calidad requeridos. |
3.3 Analizar los requisitos. 3.4 Analizar los requisitos para conseguir un equilibrio. 3.5 Validar los requisitos |
El modelo propone además subprácticas por cada práctica específica, ejemplos de productos de trabajos que son resultados de estas actividades, técnicas para identificar los requisitos y fuentes para obtenerlos. Sin embargo, aunque en algunas explicaciones asociadas a las prácticas hace mención de roles, de manera específica no se definen los roles y responsabilidades que deben tenerse en cuenta para la obtención de las necesidades del cliente y su posterior transformación en requisitos del cliente y el producto. CMMI-DEV describe buenas prácticas para cumplir con sus áreas de proceso en forma de componentes requeridos, esperados e informativos, pero no describe explícitamente cómo deben realizarse las actividades. Esto resulta en algunas ocasiones un obstáculo para las empresas que desean adoptar este modelo.
El presente artículo tiene como objetivo describir cómo se realizan estas actividades, que responden al cumplimiento de las SGs 1 Desarrollar los requisitos del cliente y 2 Desarrollar los requisitos de producto, en el proceso productivo de la Universidad de las Ciencias Informáticas (UCI), entidad que tiene certificado su actividad productiva con el nivel de madurez 2 de CMMI-DEV y fue sometida al SCAMPI con vista a la certificación del nivel 3.
Métodos o Metodología Computacional
Para la realización de la presente investigación, se emplearon métodos científicos teóricos y empíricos. Dentro de los primeros el Analítico - sintético para realizar un análisis de los fundamentos teóricos existentes referentes al desarrollo de requisitos en el desarrollo de software y resumir los principales elementos que justifican la propuesta de solución. El Sistémico para organizar y estudiar toda la información encontrada sobre el proceso desarrollo de requisitos en los modelos y estándares existentes, a fin de encontrar procederes de cómo realizar el proceso. La Modelación: para representar gráficamente la estructura y las relaciones existentes entre los diferentes elementos que conforman los procesos objetos de esta investigación. Dentro de los empíricos la Observación participante para conocer la realidad que se estudia mediante la percepción directa.
Resultados y discusión
El proceso de Ingeniería de Requisitos de la actividad productiva de la UCI tiene como base las buenas prácticas que define el modelo CMMI-DEV en su versión 1.3. Para su ejecución fueron definidos subprocesos que dan cumplimiento a cada una de las SGs que son requeridas en el modelo para las áreas de proceso Administración de Requisitos (nivel 2) y Desarrollo de Requisitos (nivel 3). Para dar cumplimiento a las SGs objetos de este artículo se diseñaron los subprocesos Gestión de requisitos del cliente y Gestión de requisitos del producto. Para definir los subprocesos se estudiaron además de CMMI, los modelos MoProSoft (Darias Gonzalez, 2020; Oktaba et al., 2005), CompetiSoft (López et al., 2012; Piattini et al., 2008; CYTED, [sin fecha]), MPS.Br (SOFTEX, 2012) y MCDAI (NC, 2021), obteniéndose de estos buenas prácticas para realizar las actividades del proceso. Para complementar el resto de los componentes que no son establecidos por CMMI, se utilizaron los elementos definidos en AUP en su variante para la UCIii, metodología institucionalizada en la universidad para la certificación del nivel 2.
Como resultado se obtuvieron la definición de los subprocesos, los roles, productos de trabajo y herramientas asociadas para ejecutar el proceso de Requisitos en la actividad productiva de la UCI. A continuación se listan los roles que intervienen en la ejecución de los subprocesos.
Tabla 3 - Roles y responsabilidades para la ejecución de las actividades.
| Rol | Responsabilidades | |
|---|---|---|
| Analista |
Identificar las fuentes de obtención de requisitos. Determinar las técnicas de recopilación de información. Determinar los proveedores válidos de requisito. Capturar las necesidades de los clientes. Transformar las necesidades del cliente en requisitos del cliente y del producto. |
Diseñar los casos de pruebas. Crear y actualizar las Matrices de Trazabilidad. Elaborar el Manual de usuario. Elaborar el Glosario de Términos. Participar en las pruebas de aceptación con el cliente. Obtener, documentar, validar y gestionar los requisitos. |
| Arquitecto de información |
Identificar la visión, misión y objetivos del producto, equilibrando las necesidades de la organización patrocinadora y la de su público. Realizar auditoría de información identificando las entidades de recursos de información conociéndose como: servicios, fuentes, sistema, contenidos. |
Realizar la organización y representación de los contenidos a través de: definición de la taxonomía, diseño del sistema de navegación y diseño del sistema de etiquetado para el sistema de navegación. Realizar el estudio de homólogos para conocer el estado del arte del producto que se quiere desarrollar. |
| Arquitecto de software |
Definir todos los elementos bases de la arquitectura. Identificar todos los posibles escenarios de despliegue de la aplicación. Identificar componentes horizontales de la aplicación. Determinar de conjunto con los diseñadores las interfaces de integración tanto internas como externas. Elaborar el documento de arquitectura de software. |
Definir las herramientas y otros componentes que permitan acelerar y mejorar el trabajo del proyecto. Definir de conjunto con el jefe de proyecto el flujo de desarrollo basado en las herramientas identificadas. Velar por el cumplimiento de los requisitos de hardware. Responsable de la integración de los componentes del sistema. |
| Administrador de la calidad | Validar la calidad de los productos generados. | Registrar las revisiones de inconsistencia. |
| Administrador de la configuración |
Identificar los elementos del proceso que forman parte de las líneas Base. Analizar el impacto de una solicitud de cambio. |
Gestionar las solicitudes de cambio en los requisitos. Informar a los interesados acerca del estado de la Solicitud de cambio de mejora. |
| Cliente | Proveer el catálogo de proveedores de requisitos. | Realizar pruebas de aceptación. |
| Desarrollador | Implementar la solución | |
| Experto (RTF y RCU) | Realizar la Revisión Técnica Formal (RTF) de requisitos. | Realizar la revisión de adherencia a proceso y producto (PPQA) al proceso de requisitos. |
| Jefe de proyecto |
Participar en la fase de estudio preliminar. Elaborar el Plan de desarrollo de software. Elaborar el apta de aceptación del rol. Aprobar la tecnología a usar en el desarrollo. Administrar recursos. |
Monitorear la adherencia a procesos. Participar en las revisiones de los entregables con el cliente. Participar en las revisiones con la alta gerencia. Participar en las pruebas de aceptación. |
| Planificador | Planificar las tareas del proceso. | |
| Proveedor de requisitos |
Proveer necesidades a los miembros del proyecto. Proveer la documentación necesaria identificada como fuente de obtención de requisitos. Participar en los encuentros coordinados por los miembros del proyecto. |
Validar y aceptar la especificación de requisitos de software (canal de comunicación). Participa en la definición de las prioridades, costo, tiempo y alcance de los requisitos de software. Realizar las pruebas de aceptación de la solución. |
Proceso Gestión de requisitos del cliente.
El proceso Gestión de requisitos del cliente tiene como objetivo transformar las necesidades del cliente en requisitos del cliente. A continuación se describe gráfica y textualmente como se ejecuta el proceso.
Proceso Gestión de requisitos del producto
El proceso Gestión de requisitos del producto tiene como objetivo transformar los requisitos del cliente en requisitos del producto y de componente de producto. A continuación se describe gráfica y textualmente como se ejecuta el proceso.
Conclusiones
La implantación y ejecución de modelos, normas o estándares para guiar un proceso de desarrollo de software es una actividad compleja. Esto sumado al hecho de que, en algunos casos estas definen el que hacer, pero no como hacerlo, representan las causas que dieron motivo a esta investigación. Una vez finalizada, se arriba a las siguientes conclusiones.
El análisis realizado sobre las buenas prácticas para desarrollar los requisitos del cliente y del producto propuestas por CMMI-DEV en su Nivel 3, permitió identificar los elementos necesarios para desarrollar los requisitos, desde su obtención como necesidades hasta su implementación en la actividad productiva de la UCI.
El análisis de otros modelos permitió definir elementos que completan los componentes requeridos, esperados e informativos que estipula CMMI-DEV v1.3.
La investigación desarrollada sentó las bases que permitieron aplicar las buenas prácticas que define CMMI para cumplir con las SGs 1 y 2 del área de procesos Desarrollo de requisitos en los proyectos productivos de la UCI.
