INTRODUCCIÓN
La comprensión de los requisitos y la importancia de su correcta y precisa especificación se incrementa cada día dado la complejidad que adquieren los sistemas software al tener que responder a exigencias que van más a allá de las funcionalidades tales como interoperabilidad, seguridad, eficiencia, confiabilidad entre otras (Doerr et al. 2005). El éxito o fallo de un software depende casi siempre de cómo se hayan capturado, entendido y usado los requisitos como base para el desarrollo (Hinojosa et al. 2015).
La ingeniería de requisitos constituye la piedra angular en el desarrollo de software (Sommerville 2011), ya que se enfoca en definir lo que se debe producir para cumplir con las necesidades y expectativas del cliente. El modelo CMMI para Desarrollo (CMMI-DEV, del inglés Capability Maturity Model Integration for Development) en su más reciente versión CMMI Development V2.0 (2018), define un Área de Prácticas: Desarrollo de requisitos y administración (RDM, por sus siglas en ingles), siendo las actividades más comunes que involucra el desarrollo de requisitos: Eicitación u Obtención, Análisis, Especificación, Verificación y Validación.
Un requisito, o también denominado requerimiento, es definido por el glosario de la IEEE como una condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto. (Sommerville, 2011) distingue dos niveles de requisitos: Requisitos de usuario y Requisitos del sistema/software, estos últimos son clasificados en dos grandes tipos, como Requisitos Funcionales (RF) y Requisitos No Funcionales (RNF).
Existen diversos criterios y definiciones de RNF, en la bibliografía consultada se utilizan indistintamente los términos: restricciones, propiedades, características, atributos y cualidades que el producto o sistema debe tener. Las autoras de la presenten investigación asumen la definición dada por Cysneiros y Yu (2004) en la que se plantea que los RNF son “requerimientos de calidad, que representan restricciones o las cualidades que el sistema debe tener tales como: precisión, usabilidad, seguridad, rendimiento, confiabilidad, performance entre otras. Estos requisitos poseen una naturaleza abstracta e intangible en comparación con los RF y esto hace que sean más difíciles de especificar o documentar formalmente (Hadad, Doorn y Kaplan 2009). No alteran la funcionalidad del sistema, pero pueden añadir nuevos RF. Sommerville (2011) clasifica los RNF en: Requisitos de producto (por ejemplo, usabilidad, seguridad, eficiencia) Requisitos organizacionales y Requisitos externos.
Las actividades enfocadas en los RNF involucran especialistas con diferentes competencias, perfiles y visiones acerca del sistema que debe construirse. De no especificarse correctamente, es decir si la especificación de estos requisitos no es completa y no se define en términos cuantificables o medibles resulta difícil establecer criterios para la ejecución de pruebas que permitan verificar su cumplimiento una vez que el software es desarrollado.
En Cuba, a partir de la voluntad política del país por acercar cada vez más las nuevas tecnologías a la población, refrendado en los Lineamientos de la Política Económica y Social del Partido y la Revolución se definen entre las políticas de informatización potenciar el uso masivo de las Nuevas Tecnologías de la Información y las Comunicaciones (NTIC) a favor del desarrollo de la economía nacional, la sociedad y el servicio al ciudadano. La Universidad de las Ciencias Informáticas (UCI), con el objetivo de impulsar el desarrollo de software en el país, ha definido como estrategia la creación de Centros de desarrollo de software dedicados fundamentalmente a fortalecer la labor productiva de la misma entre los cuales se encuentra el Centro de Informática Médica (CESIM); dedicado al desarrollo de productos, sistemas, servicios y soluciones integrales para la salud, cuya misión es la de convertirse en un Centro de excelencia en el desarrollo de estos productos con creatividad e innovación pero además lograr la calidad requerida para alcanzar un prestigio en el mercado internacional.
De acuerdo con la Organización Panamericana de la Salud (OPS) la implementación de sistemas y tecnología de información para atención de salud se ha vuelto crucial para prestar una asistencia de buena calidad. Según IMDRF SaMD Working Group (2015) “el objetivo es diseñar un sistema que: a) mantenga la seguridad del paciente y la confidencialidad, disponibilidad e integridad de las funciones y datos críticos; b) es resistente contra amenazas intencionales e involuntarias; y c) es tolerante a fallas y recuperable a un estado seguro en presencia de un ataque”.
El desarrollo para la salud es complejo. Estos sistemas además de lograr integrar las complejas operaciones clínicas requieren un flujo continuo de información, incluso entre diferentes sistemas, garantizando la disponibilidad y seguridad de la misma, así como el acceso inmediato a esta de modo que contribuya a mejorar la eficiencia de estos procesos, facilitando el trabajo cotidiano y logrando la satisfacción de los usuarios. Los RNF son especialmente importantes en este tipo de sistemas cuyos fallos causan un daño significativo que puede llegar a repercutir en la salud de las personas.
Con frecuencia estos requisitos son ignorados o subestimados, para muchos proyectos estos implican una cantidad considerable de trabajo y esfuerzos. Generalmente se confiere mayor atención a la definición y uso de métodos, técnicas y notaciones para definir RF y no se especifican detalles acerca de cómo tratar los RNF, los cuales resultan ser más complejos y requieren un mayor nivel de conocimiento, así como métodos específicos. Este ambiente motiva la búsqueda de estrategias para garantizar que estos requisitos sean descubiertos con precisión y que además sean expresados de una forma correcta, sin ambigüedad y especificados cuantitativamente, siempre que sea posible, de manera que se puedan establecer criterios para la ejecución de pruebas que permitan verificar su cumplimiento una vez el software es desarrollado y de esta manera garantizar la calidad del producto final.
El presente artículo describe una estrategia de desarrollo de RNF de software en aplicaciones para la salud, la cual permite guiar estas actividades al proponer acciones, métodos y técnicas cuya finalidad es lograr especificaciones de RNF de mayor calidad de manera que se incremente la calidad de los sistemas software desarrollados en el CESIM.
MATERIALES Y MÉTODOS
Para el desarrollo de la estrategia se tomaron como base los requisitos definidos por la norma NC ISO/IEC 25030: 2017 SQuaRE - Requisitos de calidad y el modelo de calidad del producto definido en la norma NC ISO/IEC 25010 SQuaRE - Modelos de la Calidad de software. Además, se tiene en cuenta la norma ISO/IEC 25023 - Medidas de calidad del producto para la identificación de las métricas a utilizar durante la especificación de estos requisitos, así como las buenas prácticas para el desarrollo de requisitos definidas en el modelo de procesos CMMI para Desarrollo y los procesos definidos en la UCI con vistas a certificar el nivel 3 de este modelo.
También se consideran y se proponen emplear algunas técnicas que permitan la gestión del conocimiento como son: la realización de auditorías del conocimiento que permita identificar el conocimiento existente o ausente (Guitián, Pérez, & Porra, 2015), la utilización de mapas de conocimiento como un instrumento de visualización del conocimiento existente (García & Dante, 2014) y el uso de listas de chequeo como una técnica de asistencia para la elicitación de estos requisitos que permite transferir el conocimiento de expertos a una gran cantidad de miembros de la organización (Simbaña Saransig & Simbaña Quinsasamín, 2015) (Silva et al., 2016).
Para el desarrollo de la estrategia, se toman en cuenta los aspectos definidos en (Ramírez y Lima 2011): Diagnóstico, Planteamiento del objetivo general, Planeación estratégica, Instrumentación y Evaluación. Con el objetivo de caracterizar el estado actual del proceso de desarrollo de los RNF en el CESIM se realizó un diagnóstico, a partir del cual se determinaron las potencialidades que proporcionarían a la institución las condiciones para llegar a un nivel superior y las deficiencias o aspectos negativos que caracterizan la misma, a partir de lo cual se identifica el objetivo general de la estrategia propuesta, se realiza la planeación estratégica y posteriormente se describe la instrumentación donde se explica cómo se aplicará, bajo qué condiciones, durante qué tiempo y los responsables; por último se describe la forma de evaluación donde se realiza una valoración de la aproximación lograda al estado deseado.
RESULTADOS Y DISCUSIÓN
La estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud tiene como objetivo: contribuir a elevar la calidad de la especificación de requisitos de software de las aplicaciones para la salud desarrolladas en el CESIM a partir del desarrollo de los requisitos no funcionales de estos productos. La propuesta se concibe teniendo en cuenta las condiciones actuales identificadas mediante un diagnóstico realizado, las recomendaciones y sugerencias realizadas por los expertos durante el proceso de validación.
Planeación estratégica
Como parte de la planeación estratégica, se definen objetivos a corto y mediano plazos que permiten la transformación del objeto desde su estado real hasta el estado deseado y la planificación por etapas de las acciones, métodos y técnicas que corresponden a estos objetivos. Se definen 4 etapas relacionadas con objetivos definidos y planificación de acciones de orientación, ejecución y control. Estas se complementan entre sí, de manera similar a un proceso, por lo no pueden ser concebidas de forma independiente una de la otra tal como se representa en la Figura 1.
Preparación del entorno: esta etapa tiene como principal objetivo preparar los elementos necesarios que permitan la ejecución exitosa del resto de las etapas definidas. Para lograr este objetivo se ejecutan las siguientes acciones:
Se identifican los interesados relevantes, es decir todos los que de una forma u otra esperan algo o intervienen en el proceso de desarrollo y deben involucrarse en las actividades de desarrollo de RNF (arquitecto, analista, desarrollador, probador, jefe de proyecto, clientes). Posteriormente se identifican las fuentes de conocimientos, para lo cual se propone la realización de una auditoria del conocimiento cuyos resultados deberán ser representados en un mapa de conocimiento de esta manera es posible identificar, las competencias y conocimiento existente, así como quien puede transferir o mejorar su nivel de apropiación de un conocimiento determinado, de esta manera se podrán definir acciones que refuercen el conocimiento disponible.
Se crea el Grupo de ingeniería de RNF (GiRNF), el cual será el encargado de definir los RNF del proyecto en cuestión y se constituye teniendo en cuenta los interesados relevantes y haciendo uso del mapa de conocimientos elaborado; debe estar constituido por especialistas con diferentes competencias, perfiles y visiones acerca del sistema que debe construirse por lo que se propone formen parte del mismo los roles: analista, arquitecto, desarrollador, probador, especialista en ciberseguridad y jefe de proyecto. Las principales competencias requeridas son: capacidad de abstracción, creatividad, liderazgo, comunicación oral y escrita, interpretación de normativas, capacidades lógicas, analíticas y de investigación, capacidad de trabajo en equipo. Conocimientos en: diseño de base de datos, técnicas de programación, arquitectura de software, ingeniería de software; metodología, estándares y normas a aplicar en la construcción de software, prácticas de testing, criptografía, análisis y detección de amenazas de seguridad y desarrollo de técnicas de prevención.
Se realizan actividades de capacitación, en las cuales se debe abarcar temas relacionados con las acciones a ejecutar como parte de la estrategia y el modelo de calidad definido en la ISO 25010, estas actividades deben ser recogidas en un plan de capacitación. A continuación, se obtiene información sobre el dominio del problema, se identifican fuentes de información que pueden ser consultadas o utilizadas como soporte a la identificación de los RNF como pueden ser: sistemas existentes, estándares, regulaciones o normas, entre otras.
Se revisa la lista de chequeo propuesta para la asistencia durante la identificación de los RNF. De ser necesario se incluyen nuevos aspectos, lo cual contribuirá a enriquecer los elementos contenidos en la misma. Como parte de la investigación se definió una lista de chequeo, la cual se estructura atendiendo al modelo de calidad de producto definido en la NC ISO/IEC 25010, teniendo en cuenta todas las características y subcaracterísticas definidas en el mismo. A estas características de asocia un conjunto de preguntas/afirmaciones determinadas a partir de las fuentes de información identificadas entre las que se citan (López, Barreras y Orozco 2014), (Henarejos et al. 2014), (IMDRF SaMD Working Group 2015), (Organización Panamericana de la Salud 2016), (CALISOFT 2017). Cada uno de estos elementos conduce a la identificación del RNF correspondiente. En la Tabla 1 se muestra un ejemplo correspondiente a la característica de calidad: eficiencia.
Identificación y análisis de RNF: esta etapa tiene como objetivo fundamental identificar los requisitos no funcionales aplicando métodos y técnicas que facilitan estas actividades. Para lo cual se ejecutan las siguientes acciones: en primer lugar, se deberán identificar requisitos de calidad de los clientes para lo cual se propone realizar entrevistas a los proveedores de requisitos, a partir de una guía de preguntas preconcebidas que indaguen en los requisitos de calidad, cuyos resultados deben quedar reflejados en el producto de trabajo Necesidades del cliente. Se deberá establecer un peso o importancia (Alto, Medio, Bajo, No Aplica) relativa de las características de la calidad, teniendo en cuenta las características del sistema a desarrollar, propósito, y uso previsto.
Se identifican los RNF del producto para lo cual se propone la realización de talleres (Durand 2017), donde participan los expertos designados que forman el GiRNF. En el mismo se analizan las necesidades del cliente identificadas y haciendo uso de la lista de chequeo elaborada para la asistencia durante la identificación de RNF se podrá garantizar la cobertura de todos los aspectos de calidad y se elabora el listado preliminar de RNF. Se deben identificar conflictos entre requisitos para lo cual se propone la utilización de matrices de interacción que permitirán el análisis e identificación de las relaciones que causan conflictos. Se define la prioridad de los RNF, basado en la importancia y urgencia (Wiegers y Beatty 2013). Se evalúa el impacto de los requisitos de los atributos de calidad significativos para la arquitectura y en los costes. Además, se realiza una evaluación de riesgos sobre estos requisitos.
Especificación de RNF: esta etapa tiene como propósito documentar los RNF identificados, para lo cual se ejecutan las siguientes acciones: se describen los RNF identificados especificando la característica de calidad y teniendo en cuenta un conjunto de recomendaciones para su redacción (IREB e.V. 2015), se identifica la métrica de calidad para cuantificar el RNF siempre que sea posible haciendo uso de una lista de métricas, la cual se elaboró tomando como referencia la norma ISO/IEC 25023:2016 - Medidas de calidad del producto software, la Tabla 2 muestra un ejemplo de las métricas asociadas a la característica Eficiencia. Deberá especificarse, además, la relación entre el requisito descrito con el o los requisitos adicionales necesarios para su cumplimiento.
Verificación y validación de RNF: esta etapa tiene como objetivo garantizar el cumplimiento de los atributos de calidad de la especificación de RNF así como su correspondencia con las necesidades de los interesados. Se ejecutan las actividades de verificación y validación según se define en el Proceso para las actividades de calidad, específicamente los procesos: Ejecutar Revisión Técnica Formal de Requisitos y Ejecutar validación, definidos en la UCI. Los expertos ejecutan las Revisiones técnicas formales de Requisitos a partir de una lista de chequeo, donde se comprueban mediante un grupo de indicadores, los atributos de calidad de las especificaciones. Con el propósito de garantizar una revisión más exhaustiva de los RNF, se adiciona a la lista de chequeo (definida como parte del proceso, en la UCI) elementos de comprobación asociados a la completitud, no ambigüedad, verificabilidad, modificabilidad y clasificación de requisitos, debido a que no se enfatizaba en algunas particularidades de los requisitos no funcionales. Los requisitos no funcionales serán validados y aprobados para lo cual se ejecuta el proceso Ejecutar validación. Deberá documentarse quién ha validado y aprobado los requisitos no funcionales.
Formas de implementación
La estrategia propuesta se aplica durante la fase de Ejecución del ciclo de vida de desarrollo. Las acciones descritas se ejecutan durante las disciplinas correspondientes al Modelado de negocio, Requisitos y Análisis y diseño (en esta última se refinan y puede surgir nuevos RNF). Puede ser ejecutada durante un nuevo desarrollo, mejora o modificación del sistema existente. Se debe incluir, en el cronograma de ejecución del proyecto, las actividades que forman parte de esta estrategia con el objetivo de que su ejecución no afecte los tiempos pactados y se ejecuten de manera natural como parte del proceso de desarrollo. La Tabla 3 muestra la relación entre las acciones que se describen anteriormente y los responsables de su ejecución.
Formas de evaluación
Se propone realizar una evaluación o valoración de la aproximación lograda al estado deseado, con el propósito de identificar los cambios cualitativos una vez implementada la estrategia a partir de sus resultados. Esta evaluación se realiza por medio de la aplicación de encuestas al personal de la institución y la revisión documental a la Especificación de requisitos (teniendo en cuenta los resultados de la etapa Verificación y validación de RNF). Se analizan los criterios emitidos por los especialistas, así como el comportamiento de indicadores de calidad de las especificaciones; identificados a partir de los atributos definidos en la ISO/IEC/IEEE 29148:2011 Systems and software engineering - Life cycle processes - Requirements engineering (ver Tabla 4). Se registran los resultados alcanzados, lecciones aprendidas y se dejan sentadas las bases para un replanteamiento de las acciones para acometer la implementación del cambio que se propone.
Análisis de la satisfacción de usuarios
Para analizar el grado de satisfacción de los usuarios con la propuesta descrita se realizó una encuesta a 14 especialistas del CESIM con la finalidad de determinar el índice de satisfacción personal y grupal a partir de la aplicación de la Técnica de Iadov. El análisis de las respuestas se realizó mediante el "Cuadro lógico de Iadov", el cual expresa una relación de las posibles respuestas a las tres preguntas cerradas.
De esta forma, para cada especialista se puede determinar en qué lugar de la siguiente escala se encuentra:
Clara satisfacción
Más satisfecho que insatisfecho
No definida
Más insatisfecho que satisfecho
Clara insatisfacción
Contradictoria
Luego de aplicado el instrumento, se determinó el nivel de satisfacción individual de los usuarios con la estrategia; el 57% de los especialistas encuestados mostraron clara satisfacción, el 28% manifestaron que se encontraban más satisfechos que insatisfechos y en el 14% de los casos no se encuentra definida.
Para obtener el índice de satisfacción grupal (ISG) se trabaja con los diferentes niveles de satisfacción que se expresan en la siguiente escala numérica:
(+1) Máximo de satisfacción.
(+0,5) Más satisfecho que insatisfecho.
(0) No definido y contradictorio.
(-0,5) Más insatisfecho que satisfecho.
(-1) Máxima insatisfacción.
Este índice de satisfacción grupal se calculó según la fórmula:
Donde A, B, C, D y E son el número de especialistas con las categorías 1; 2; 3 ó 6; 4 y 5 de satisfacción personal, y N la cantidad total de especialistas encuestados. El cálculo del ISG arrojó como resultado 0.71 el cual evidencia que los especialistas del CESIM están satisfechos con la estrategia propuesta.
CONCLUSIONES
Los resultados obtenidos durante el desarrollo de la investigación permiten arribar a las siguientes conclusiones:
La estrategia diseñada permite guiar el desarrollo de los RNF, al proponer métodos y técnicas a utilizar durante estas actividades; lo cual tendrá una repercusión positiva en la calidad de estas especificaciones y por consiguiente del producto final.
La aplicación de la técnica de Iadov evidenció la satisfacción de los usuarios con la estrategia diseñada demostrando las posibilidades de su implantación en el CESIM.