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
El éxito o fracaso de un software depende casi siempre de cómo se hayan capturado, entendido y usado los requisitos como base para el desarrollo 1. La ingeniería de requisitos constituye la piedra angular en el desarrollo de software, ya que se enfoca en definir lo que se debe producir para cumplir con las necesidades y expectativas del cliente 2. 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 3, define un Área de Prácticas: Desarrollo de requisitos y administración (RDM, por sus siglas en inglés), siendo las actividades más comunes que involucra el desarrollo de requisitos: Obtención, Análisis, Especificación, Verificación y Validación.
Se distinguen 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) 2. 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. A los efectos de la presente investigación se asumen 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” 4. Lograr la calidad de la especificación de RNF también evita que se introduzcan defectos que después de implementado el sistema son más costosos de resolver.
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.
El desarrollo de aplicaciones 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 ésta de modo que contribuya a mejorar la eficiencia de estos procesos, facilitando el trabajo cotidiano y logrando la satisfacción de los usuarios; “…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” 5.
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. Este tipo de software requiere requisitos precisos, analizados y especificados, utilizando múltiples fuentes de datos además de una alta participación de expertos en dominio y conocimiento especializado. Con frecuencia estos requisitos son ignorados o subestimados, para muchos proyectos estos implican una cantidad considerable de trabajo y esfuerzos.
Se han determinado un conjunto de normas o estándares internacionales que aunque no definen un procedimiento exacto de cómo desarrollar los requisitos no funcionales de software, ayudan a orientar por ejemplo, en la identificación de requisitos de sistemas y en la elaboración del documento de Especificación de Requisitos de Software (ERS o SRS por sus siglas en inglés), muchos de los cuales surgen para crear modelos, métricas, procesos y herramientas de evaluación de calidad del software como producto, por medio de la especificación de requisitos. Sin embargo los estándares internacionales proporcionan guías y modelos de calidad para temas muy generales y no suelen estar pensadas para ofrecer soluciones en temas muy concretos. Es por ello que se torna complejo entender e interpretar los mismos a un contexto determinado.
Durante el análisis bibliográfico realizado fueron identificadas varias contribuciones al tema en cuestión, pero estas en su mayoría se enfocan en actividades específicas como la identificación o especificación, como es el caso de los estudios 4,6,7; otros se especializan en una característica de calidad determinada, como son las propuestas 8,9,10. De manera general estos estudios no ofrecen una propuesta detallada que abarque un conjunto integrado de acciones y técnicas que incluyan todas las actividades del desarrollo de los RNF; tampoco abarcan todas las características de calidad definidas en el modelo de calidad del producto propuesto en la norma NC ISO/IEC 25010.
Esta situación motiva la búsqueda de mecanismos para garantizar que los RNF sean descubiertos con precisión para de esta manera contribuir a la calidad del producto final.
El presente artículo describe una estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud, que 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.
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. Estas son normas reconocidas por el CECMED para la demostración de los requisitos esenciales de seguridad, eficacia y efectividad de Equipos y Dispositivos Médicos 11. Además se tiene en cuenta la norma ISO/IEC 25023: 2016 - 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 12, la utilización de mapas de conocimiento como un instrumento de visualización del conocimiento existente 13) 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 7.
Resultados
La estrategia para el desarrollo de requisitos no funcionales se define teniendo en cuenta cuatro momentos fundamentales 14: primeramente se realiza el diagnóstico que indica el estado real del objeto, a partir del cual se realiza la planeación estratégica, posteriormente se define la instrumentación (explica cómo se aplicará bajo qué condiciones, durante qué tiempo, responsables, participantes) y un último momento de evaluación donde se realiza una valoración de la aproximación lograda al estado deseado (figura 1).
Fig. 1 Representación gráfica de la estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud
Como resultado del diagnóstico realizado al proceso de desarrollo de los RNF en el CESIM se identificaron entre las principales fortalezas: el interés por la superación en temáticas afines con el proceso de desarrollo de los RNF, la especialización y mejora continua a los productos, así como el compromiso de la alta gerencia. Entre las principales debilidades destacan: inexistencia de guías para orientar las actividades de desarrollo de RNF, personal con poca experiencia y la insuficiente gestión del conocimiento.
A partir de las condiciones actuales identificadas en el diagnóstico realizado se define como objetivo de la estrategia propuesta: 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. Como parte de la Planeación estratégica se definen cuatro etapas con objetivos a corto o mediano plazo y una planificación de acciones de orientación, métodos y técnicas que corresponden al cumplimiento de estos objetivos. Estas etapas se complementan entre sí, de manera similar a un proceso. A continuación se describen cada una de estas.
Etapa 1: Preparación del entorno
Esta etapa tiene como principal objetivo preparar las condiciones necesarias 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 conocimiento, para lo cual se propone la realización de una auditoría 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, lo cual permitirá definir acciones que refuercen el conocimiento disponible.
El análisis de estos resultados permite conformar el grupo encargado de la identificación de los RNF, teniendo en cuenta que la obtención de estos requisitos involucra a diferentes personas, roles y conocimientos. 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 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.
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 propone además el uso de una lista de chequeo, o también llamadas de verificación, la cual constituye una técnica de asistencia para la elicitación, es por ello que durante esta etapa se debe revisar la lista de chequeo elaborada como parte de la presente investigación y de ser necesario se incluyen nuevos aspectos, lo cual contribuirá a enriquecer los elementos contenidos en la misma. Esta 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 fuentes de información como artículos científicos, estándares sobre informática médica 15,16, la Norma ramal - requisitos de la calidad para sistemas informáticos y productos de software 17, así como experiencias en desarrollos previos. Cada uno de estos elementos conduce a la identificación del RNF correspondiente. En la Tabla 1 se muestra un ejemplo asociado a las características: eficiencia, usabilidad, seguridad, compatibilidad y fiabilidad.
Tabla 1 Lista de Chequeo para la asistencia durante la elicitación. Fuente: elaboración propia.
| Eficiencia | |||
| Subcaracterísticas | Cuestionario | Métrica | RNF |
| Rendimiento | ¿Qué tiempo de respuesta al usuario y a eventos? | Tiempo de respuesta al usuario y a eventos | Toda funcionalidad del sistema y transacción debe responder al usuario en menos de 5 segundos |
| Usabilidad | |||
| Operabilidad | ¿Se concibe la internacionalización del sistema? | Adecuación a idiomas soportados | El sistema debe permitir configuraciones de lenguajes: español, inglés y portugués |
| Seguridad | |||
| No rechazo | ¿Se define algún método de auditoría? | Capacidad de auditoría de acceso | El sistema debe registrar el 100 % de las acciones que se realizan, proporcionando un registro de actividades (bitácora) de cada usuario |
| Compatibilidad | |||
| Interoperabilidad | ¿Con cuales sistemas se debe establecer intercambio de información? | Grado de interoperabilidad | El sistema debe establecer el intercambio exitoso de información con los sistemas X y Y, |
| Fiabilidad | |||
| Disponibilidad | ¿Cuál debe ser el grado de disponibilidad del sistema? | Disponibilidad | El sistema debe tener una disponibilidad del 99,999% del tiempo |
Etapa 2: 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. En primer lugar se deberán identificar los 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.
Posteriormente se identifican los RNF del producto para lo cual se propone la realización de talleres 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. Se elabora una lista preliminar con los RNF identificados. 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, se realiza una evaluación de riesgos sobre los requisitos de calidad y del impacto de estos requisitos para la arquitectura en el producto.
Etapa 3: Especificación de RNF
Esta etapa tiene como propósito documentar formalmente los RNF identificados. Para lo cual ejecutan las siguientes acciones: se describen los RNF identificados teniendo en cuenta un conjunto de recomendaciones para su redacción y una plantilla definida que permite organizar los elementos necesarios para su comprensión y posterior implementación. Se clasifican acorde al modelo de calidad definido por la NC ISO/IEC 25010, asociados a las características de calidad que define el modelo.
Se identifican, siempre que sea posible, las métricas que permiten cuantificar los RNF especificados, para lo cual se propone una lista de métricas a ser utilizadas durante la especificación de estos requisitos, permitiendo que los requisitos no funcionales sean redactados de manera cuantitativa, siempre que sea posible. Se toman como referencia las métricas propuestas por la ISO/IEC 25023:2016 - Medidas de calidad del producto software. Se especifica el valor objetivo para la medida, es decir el valor aceptable para cumplir con el requisito, pueden ser un solo valor o un rango de valores, teniendo en cuenta que de aplicarse el mismo conjunto de medidas para diferentes proyectos es posible crear una base de experiencia. La Tabla 1 muestra algunas de las métricas propuestas. Deberá además especificarse la relación entre el requisito descrito con el o los requisitos adicionales necesarios para su cumplimiento, lo cual facilita su comprobación.
Etapa 4: 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 los procesos definidos en la institución (IPP-2016 Proceso para las actividades de calidad (PPQA, VER & VAL)). Durante esta etapa se ejecuta el proceso: Ejecutar Revisiones Técnicas Formales (RTF) de requisitos (IPP-2014 Ejecutar Revisiones Técnicas Formales a nivel de proyecto). Los expertos ejecutan las revisiones a partir de las listas 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, que permiten enfatizar en algunas particularidades de estos requisitos. Se ejecuta además el proceso Ejecutar validación (IPP-2016 Ejecutar Validación) donde se revisan y aprueban los RNF con los clientes, quedando documentado quién ha validado y aprobado los RNF.
Formas de implementación
La estrategia propuesta será ejecutada 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, Levantamiento de Requisitos y Análisis y diseño (en esta última se refinan y puede surgir nuevos RNF). Puede ser un nuevo desarrollo, mejora del sistema existente o modificación del sistema existente. Se deben 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. Los roles responsables de ejecutar las acciones antes descritas son: jefe de proyecto, analista, grupo de ingeniería de RNF, revisor y cliente.
Formas de evaluación
Una vez ejecutadas las acciones anteriormente descritas se debe 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 Verificar y Validar los 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 2). 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.
Tabla 2 Indicadores de calidad de las especificaciones. Fuente: elaboración propia
| Indicador/Métrica | Descripción |
|---|---|
| Completitud de la Especificación de RNF | Cantidad de RNF asociados a las características de calidad y cantidad de características de calidad abarcadas |
| Especificidad de los RNF | Porciento de requisitos cuya interpretación por diferentes especialistas es igual (Nii) |
| Verificabilidad de los RNF | Porciento de RNF cuantificados |
| Clasificación de los RNF | Porciento de RNF asignados a una característica de calidad correctamente |
Discusión
Para la validación de la estrategia propuesta se utilizó el método criterio de expertos basado en la escala psicométrica de Likert de 5 puntos, con el objetivo de determinar la conformidad de los expertos con respecto a los elementos que componen la estrategia, su aplicabilidad e influencia en el desarrollo de requisitos no funcionales en aplicaciones para la salud. Para ello fueron seleccionados 13 expertos por su coeficiente de competencias, los cuales tienen amplios conocimientos y/o experiencias en ingeniería de requisitos y desarrollo de requisitos no funcionales. El 62% son Doctor en Ciencias, el 30% son Máster y el 8% son ingenieros en Ciencias Informáticas, estos últimos fueron seleccionados por su experiencia en el área del conocimiento que aborda la presente investigación. Todos tienen más de 5 años de experiencias ya sea vinculados al desarrollo de software como en la impartición de asignaturas de la disciplina Ingeniería de software.
Luego de presentada la propuesta los expertos respondieron un cuestionario tipo escala de Likert donde evaluaron cinco planteamientos de acuerdo a las siguientes opciones: muy de acuerdo, bastante de acuerdo, ni de acuerdo ni en desacuerdo, en desacuerdo y completamente en desacuerdo. Con esta técnica se calcularon los porcientos de concordancia de los expertos con cada una de las posibles respuestas para los planteamientos formulados. Luego se calculó un índice porcentual (IP) que integra en un solo valor la aceptación de cada planteamiento por los evaluadores, resultando que el IP en todos los casos es mayor que 89. Lo cual evidencia la alta valoración por los expertos sobre la claridad y síntesis de la propuesta; posibilidad de su uso en el desarrollo de aplicaciones para la salud según sus elementos y adherencia a las buenas prácticas de consenso internacional. Se identificaron además sugerencias y recomendaciones por parte de los expertos, las cuales fueron tenidas en cuenta para el perfeccionamiento de la propuesta.
Como parte de la validación fue realizado además un estudio de caso con el objetivo de verificar que la ejecución de la estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud aumente la calidad de la especificación de requisitos de software de los sistemas desarrollados en el CESIM. Para lo cual se tomó como unidad de análisis uno de los proyectos que se ejecutan en dicho centro.
Resultados
Se comparó la Especificación de Requisitos de Software (ERS) definida en el proyecto sin la aplicación de la estrategia y después de aplicada la estrategia, a partir del análisis del comportamiento de los indicadores: completitud de la especificación de RNF, clasificación de los RNF, verificabilidad de los RNF y especificidad (no ambigüedad) de los RNF. Se realizaron las mediciones:
a) Indicadores de calidad de la ERS sin la estrategia
b) Indicadores de calidad de la ERS con la estrategia
Los resultados del análisis del indicador completitud de la especificación de RNF se muestran en la Figura 2, donde se evidencian las características de calidad abarcadas y la cantidad de requisitos especificados por cada una de estas características.
Fig. 2 Resultados de las mediciones del indicador completitud de la especificación de RNF. Fuente: elaboración propia
Se especificaron un total de 51 RNF, de estos 36 son nuevos RNF, lo cual representa un incremento en el 70.6 % con respecto a los especificados en la versión anterior. Se definieron requisitos asociados a las características de calidad compatibilidad, fiabilidad y adecuación funcional que no habían sido contempladas en la versión anterior de la ERS, permitiendo una mayor cobertura al modelo de calidad.
Los resultados de los indicadores clasificación de RNF, verificabilidad de los RNF, especificidad de los RNF se muestran en la Figura 3.
Fig. 3 Resultados de las mediciones de los indicadores clasificación de RNF, verificabilidad de RNF y especificidad de RNF. Fuente: Elaboración propia
De manera general se evidencia un incremento en todos los indicadores, lo cual denota el impacto positivo que tuvo la utilización de la estrategia en el desarrollo de los RNF del sistema contribuyendo al incremento de la calidad de la especificación de requisitos, con lo cual se da cumplimiento al objetivo definido.
Conclusiones
Los resultados obtenidos durante el desarrollo de la investigación permiten arribar a las siguientes conclusiones:
La estrategia diseñada se sustenta en los requisitos definidos en la norma ISO/IEC 25030:2007, el modelo de calidad del producto definido en la norma NC ISO/IEC 25010:2016, las buenas prácticas para el desarrollo de requisitos definidas en CMMI, así como tendencias y estudios que se refieren a las actividades de desarrollo de los RNF.
La propuesta fue valorada positivamente por los expertos, refinándose a partir de mejoras sugeridas por los mismos.
El estudio de caso, cuyos resultados fueron favorables, evidenció la posibilidad de aplicación de la estrategia en un proyecto real, abarcando todas las actividades del desarrollo de los RNF y características de calidad, con lo cual se incrementan los indicadores de calidad de la especificación de requisitos del proyecto en cuestión.
