I. CONTEXTO

Esta propuesta está contextualizada en el trabajo colaborativo entre dos grupos de investigación: Los integrantes del Laboratorio de Calidad e Ingeniería de Software (LaCIS) – Facultad de Ciencias Físico-Matemáticas y Naturales, Universidad Nacional de San Luis; y, por otra parte, el grupo de Investigación, Grupo de I+D Calidad de Software de la Universidad Tecnológica Nacional, Facultad Regional San Francisco.

Parte de las actividades se desarrollan en el marco del Proyecto de investigación denominado “Gestión de Proyectos de Software: Los Modelos de Calidad como Soporte a los Procesos y Productos Software” (Código TOIANSF0004895). Este proyecto fue homologado y es financiado por la Universidad Tecnológica Nacional.

El trabajo colaborativo entre las Universidades aporta dimensiones analíticas prácticas, condición indispensable para integrar y comparar la información obtenida a partir de los proyectos que genere cada grupo.

II. INTRODUCCIÓN

La modernización del Estado es un proceso continuo en el tiempo que presenta acciones concretas y específicas que buscan mejorar el funcionamiento de las organizaciones públicas. En tal sentido, resulta necesario aumentar la calidad de los servicios provistos por el Estado incorporando Tecnologías de la Información y de las Comunicaciones, simplificando procedimientos, propiciando reingenierías de procesos y ofreciendo al ciudadano la posibilidad de mejorar el acceso por medios electrónicos a información personalizada, coherente e integral [1].

Para la incorporación de Tecnologías de la Información y de las Comunicaciones en los Organismos que pertenecen a la Administración Pública (OAP), el Plan de modernización del Estado [1] define los Estándares Tecnológicos para la Administración Pública (ETAP) [2]. Éstos son instrumentos que contienen los lineamientos generales, modelos de pliegos y las especificaciones técnicas de los equipos y/o dispositivos a incorporar en el ámbito de Administración Pública Nacional (APN).

Esta modernización del Estado implica que todo OAP vaya incorporando tecnología para lograr los objetivos propuestos. Dentro de las tecnologías a incorporar es innegable que el software tendrá un papel preponderante, según lo expresado en [3], es imposible operar el mundo moderno sin software. Las infraestructuras nacionales y los servicios públicos se controlan mediante sistemas basados en computadoras.

El software es una de las herramientas de mayor utilidad en la optimización de procesos en las organizaciones, con el propósito de contar y ofrecer optimización, eficiencia y satisfacción de necesidades, razón por la cual el software debe contar con criterios que garanticen su calidad [4].

Por ende, todo software a incorporar deberá contar con un determinado nivel de calidad.

Al hablar de calidad, debemos entender qué es calidad en el contexto del software. Así, en la literatura podemos encontrar varias definiciones sobre calidad del software. Entre estas definiciones se puede citar la propuesta en IEEE [5], en donde se expresa que “La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.

También se observa que, en ISO/IEC 25010 [6], se la define como el grado en que el producto software satisface las necesidades expresadas o implícitas, cuando es usado bajo condiciones determinadas.

En R. Pressman [7] se la define como el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamente documentados, y de las características implícitas que se espera de todo software desarrollado profesionalmente.

Si bien parece no haber una definición única y aceptada universalmente al respecto, se puede observar que todas ellas mencionan que la calidad del software debería ser el cumplimiento y/o grado de satisfacción respecto de determinadas necesidades y/o requisitos dados, los cuales pueden ser explícitos y/o implícitos, entre otros.

Estas necesidades o requisitos explícitos y/o implícitos de la calidad se pueden especificar para el desarrollo de un software o bien para evaluar un producto de software ya construido [8].

A la hora de evaluar y asegurar la calidad del software, una herramienta ampliamente utilizada y difundida son los Modelos de Calidad (MC). Según se expresa en [9], los MC son aplicados para apoyar la especificación y la evaluación de la calidad del software, también en [10] se plantea que los MC permiten la definición estructurada de criterios de evaluación, la especificación de requerimientos, la descripción de componentes en relación a ellos y la identificación de desajustes de manera sistemática facilitando el proceso de evaluación y selección del software.

En este sentido, en [11] se detalla que existen diferentes enfoques para estos MC ya sea para calidad de procesos, calidad de productos y calidad en uso.

Si bien el propósito de este trabajo no está centrado en la construcción de modelos de calidad, se considera que estos son un elemento se suma importancia a la hora de determinar y definir los requisitos de la calidad del software desde el enfoque de la calidad de productos de software.

En [12] se expresa que la Norma ISO/IEC 25030 [8] aporta un esquema para abordar la especificación de los requisitos de calidad, con lo cual se arriba a la definición del MC, y en un sentido más amplio también se describe que la especificación de requisitos de calidad y la evaluación de productos de software son dos procesos que por su inherente complejidad pueden beneficiarse del proceso que regule su realización.

Para llevar a cabo la incorporación de software en el ámbito de la APN será de importancia entonces tener en cuenta los aspectos relacionados con la calidad de esos productos. De manera concreta será necesario que los OAP puedan contar con algún sistema o método que les permita identificar y definir cuáles serán esos requisitos de calidad que se pretende para el software a adquirir.

Como se especifica en [14], los ETAP cuentan con una serie de instrumentos, dentro de los cuales existe un Pliego licitatorio, el cual le posibilita a un OAP poder especificar una contratación o adquisición de software, éste es el Modelo de Pliego 14.

También en el mencionado trabajo se evidencia que el Modelo de Pliego 14 presenta una cobertura metodológica para especificar y evaluar los aspectos funcionales de un software, no así para especificar y evaluar los requisitos de calidad que un organismo pretenda incluir para la contratación o adquisición de software. Y se concluye que, desde la perspectiva de calidad de productos de software, específicamente desde SQuaRE [13] se pueden realizar estos aportes, tanto para el proceso de especificación como para el de evaluación.

Deja también planteados aspectos que se deberían profundizar con el fin de desarrollar métodos y/o herramientas específicas que permitan ir validando el modelo general establecido.

Por todo lo expresado previamente, en el presente trabajo se presenta una propuesta que permitirá a los OAP identificar y definir los requisitos de calidad de software de las partes interesadas a la hora de adquirir software. Para ello, se propone una técnica para la recolección y análisis de información que permite conducir el proceso de definición de los requisitos de calidad de las partes interesadas planteado en ISO/IEC 25030 [8]. Así mismo, se presenta el desarrollo de un sistema en base a la técnica definida y que da soporte al proceso de definición de requisitos de calidad de las partes interesadas y su aplicación en un caso de estudio.

En lo sucesivo, este trabajo está organizado de la siguiente manera: en la sección IV se analiza la Norma ISO/IEC 25030 [8] en el contexto de ISO/IEC 25000 (SQuaRE) [13], en la sección V se presentan los principales aportes a la temática realizado en un trabajo anterior y como se pretende seguir con el desarrollo del mismo. Mientras que en VI se propone el desarrollo de una técnica de relevamiento como apoyo a la definición de los requisitos de calidad de las partes interesadas, en la sección VII se presenta el sistema desarrollado a los fines de implementar la técnica de relevamiento y el proceso de definición de requisitos, en VIII se puede observar un caso de estudio llevado a cabo con el fin de validar la implementación del sistema según el proceso definido por la Norma ISO/IEC 25030 [8]. En tanto en IX se exponen los principales resultados y en la sección X se plantea la discusión y trabajos futuros, en tanto que en XI se detallan las conclusiones.

III. MÉTODOS

Este trabajo es parte de una investigación aplicada basada en un enfoque cualitativo, principalmente el estudio que se lleva a cabo está sustentado en la revisión bibliográfica y de descubrimientos previos en el campo de la calidad del software y la especificación de requisitos en tal sentido. El análisis y síntesis del material encontrado sirvió de base para elaborar nuevas propuestas que realicen aportes al campo de la especificación de calidad de software, las cual se podrán materializar a través de un modelo, una metodología, técnica y/o artefacto que luego se aplicarán en casos de estudios en el ámbito de las organizaciones que desarrollan software, con el fin de obtener resultados concretos que permitan arribar a conclusiones.

Dentro del campo de la calidad del software se hizo foco en lo que respecta a calidad de productos de software, esta es una decisión que se toma en torno a los resultados de un trabajo previo [14]. En este sentido uno de los principales marcos de trabajo que se utilizó es el propuesto por SQuaRE [13].

IV. ANÁLISIS DE LA NORMA ISO/IEC 25030 EN EL CONTEXTO DE SQUARE

En esta sección se profundiza en el estudio la Norma ISO/IEC 25030 [8] con el fin de determinar, cuáles son los procesos más importantes en la misma, el ámbito de aplicación y las relaciones existentes entre ésta norma y el resto que conforman la serie de normas SQuaRE.

SQuaRE, es una serie organizada lógicamente, enriquecida y unificada que cubre dos procesos principales: especificación de requisitos de calidad de software y evaluación de la calidad del software, apoyados por un proceso de medición de la calidad de software.

El propósito de SQuaRE es ayudar al desarrollo y adquisición del producto de software con la especificación y evaluación de los requisitos de calidad. Establece criterios para la especificación de requisitos de calidad del producto de software, su medición y evaluación. Incluye, además, un MC para la alineación de las definiciones de calidad del cliente con atributos del proceso de desarrollo.

Además, la serie proporciona medidas recomendadas de los atributos de calidad del producto de software que pueden ser utilizadas por desarrolladores, adquirientes y evaluadores [13]. La serie SQuaRE [13] está organizada según se muestra en la Fig. 1.

Fig. 1 - Divisiones ISO/IEC 25000 (Adaptado de [13])

La norma ISO/IEC 25030 [8] permite llevar a cabo el proceso de Especificación de Requisitos de calidad de software, que, junto al proceso de Evaluación, constituyen los principales pilares de SQuaRE [13].

Según se expresa en ISO/IEC 25030 [8], los requisitos de calidad del software, así como todos los demás requisitos no pueden ser vistos en forma aislada, deben considerarse en un contexto más amplio.

Vemos en la Fig.2 (para los fines prácticos es tomada de IRAM ISO/IEC 25030:2019 [26]) que existen dos procesos que intervienen para llegar a los requisitos de calidad del software: El proceso de definición y el Proceso de análisis.

Fig. 2 - Definición y análisis de los requisitos de la calidad del software - IRAM ISO/IEC 25030:2019 [26]

La definición de estos dos procesos conlleva a la relación con otras normas pertenecientes a SQuaRE:

ISO/IEC 25010 [6]: es útil para definir los requisitos de la calidad de las partes interesadas a través del modelo de calidad definido.

Por su parte ISO/IEC 25022, ISO/IEC 25023 e ISO/IEC 25024 [15]: son útiles para la formalización de los requisitos de calidad del software de las partes interesadas a través de las medidas de calidad definidas en estas normas.

Visto el esquema propuesto por ISO/IEC 25030 [8] respecto de la definición y análisis de los requisitos de calidad del software, es claro que, para el proceso de definición de requisitos es trascedente la intervención de las partes interesadas.

También se menciona que los requisitos de calidad del software deben tener en cuenta todos los requisitos de calidad de las partes interesadas pertinentes.

El término de partes interesadas es definido en ISO/IEC 25000 [13], como una persona o grupo que tiene un interés en el desempeño o éxito de la organización (por ejemplo, clientes, propietarios, personal de la organización, proveedores, banqueros, asociaciones gremiales, socios o la sociedad).

Las partes interesadas incluyen, pero no se limitan a, usuarios finales, organizaciones usuarias finales, quienes dan soporte, desarrolladores, fabricantes, instructores, quienes mantienen, quienes se encargan de la disposición final, adquirientes, organizaciones proveedoras y organismos reguladores.

Estas partes interesadas incluyen distintos tres tipos distintos de usuarios, según se explicita en ISO/IEC 25010 [6].

1. Usuario principal: persona que interactúa con el sistema para alcanzar las metas primarias.

2. Usuarios secundarios: proporcionan apoyo, por ejemplo.

a) proveedor de contenido, administrador/gestor del sistema, administrador de seguridad;

b) quien mantiene, quien analiza, quien realiza la portabilidad, quien instala.

3. Usuario indirecto: persona que recibe los elementos de salida, pero que no interactúa con el sistema.

Otro aspecto importante que señala la Norma ISO/IEC 25030 [8], es que cada requisito de calidad de las partes interesadas debe identificarse unívocamente y debe existir una trazabilidad entre cada requisito de la calidad de las partes interesadas y las partes interesadas individuales o sus clases.

También los requisitos de calidad del software deben asociarse con las características de la calidad (o subcaracterísticas) definidas en el MC aplicado, el cual puede utilizarse como una lista de verificación para garantizar la cobertura de todos los aspectos de calidad.

Aquí también se observa la relación entre ISO/IEC 25030 [8] e ISO/25010 [6] a través del MC propuesto en esta norma.

V. TRABAJO ANTERIOR RELACIONADO

En esta sección se presenta de manera resumida los resultados y conclusiones que se obtuvieron en [14].

En ese trabajo se destaca que, en el marco de los ETAP [2], existe el Pliego Modelo 14, el cual es un importante instrumento con el que pueden contar los OAP a la hora de licitar software.

Este modelo de pliego contiene recomendaciones explicitas para especificar y evaluar los aspectos funcionales de un software, no así para especificar y evaluar los requisitos de calidad de software. Esto último es el resultado de haber encontrado las relaciones existentes entre el Pliego Modelo 14 con el concepto de propiedades de software.

La definición de un marco para la especificación y evaluación de requisitos de calidad de software como una mejora para el Pliego Modelo 14, es el resultado de las relaciones que se establecieron entre el Pliego Modelo 14 y los estándares de SQuaRE [13].

La obtención del marco antes mencionado permitió construir un modelo conceptual que represente esas relaciones.

Este modelo, luego, fue instanciado a través del desarrollo de un caso concreto. Como resultado de ello, se pudo obtener una especificación de los requisitos de calidad de software, los cuales pasan a ser un anexo a incorporar en el Pliego Modelo 14. También se pudo llevar a cabo el proceso de evaluación y selección propuesto, hasta concluir con un informe que también pasa a formar parte de la documentación del Pliego Modelo 14.

También se destaca la importancia de que la Administración Pública Nacional cuente con un Plan de Modernización del Estado y que, a través de éste, se definieron los Estándares Tecnológicos para guiar a los Organismos a la hora de realizar licitaciones de software.

En estos estándares, las licitaciones de software se realizan a través del Pliego Modelo 14, en los cuales se observa que las propiedades de calidad no estaban presentes de manera clara, formal y tampoco se referencian anexos o procedimientos a los cuales los organismos puedan acceder para especificarlas. Lo mismo ocurre al momento de la evaluación y selección de las ofertas.

Por ello es que esa propuesta realiza un aporte desde la perspectiva de la calidad de productos de software, utilizando una serie de estándares de reconocimiento internacional como SQuaRE [13]

Deja también planteados aspectos que se deberían profundizar con el fin de desarrollar métodos y/o herramientas específicas que permitan ir validando el modelo general establecido.

VI. TÉCNICA PARA RELEVAMIENTO DE LAS NECESIDADES DE CALIDAD DE LAS PARTES INTERESADAS

En esta sección del trabajo se propone la implementación de una técnica de relevamiento como apoyo al proceso de definición de los requisitos de calidad de las partes interesadas, específicamente se propone la construcción de una serie de cuestionarios basados en los conceptos y definiciones del MC de ISO/IEC 25010 [6] e ISO/IEC 25023 [15], los cuales podrán ser utilizados como soporte y guía en la definición de las necesidades de calidad de las partes interesadas.

Es oportuno mencionar algunos antecedentes respecto del desarrollo e implementación de técnicas de relevamiento a través de cuestionarios en el campo relacionado a la calidad de productos de software y que fueran validadas a través de distintos trabajos.

En ese sentido se observa, que MyFEPS [16, 17] FrameWork de Calidad de Software (Modelo, Proceso y Herramientas), cuenta con una serie de herramientas y métodos entre los cuales se despliegan los cuestionarios destinados a los stakeholders con el fin de inferir la importancia relativa de cada ítem de calidad en el proceso de evaluación de productos de software.

También, este FrameWork presenta un MC propio denominado QSAT, el mismo se puede apreciar en [18] y su construcción en [19]. En éste último trabajo, también se menciona que MyFEPS [16, 17] fue validado en tres proyectos y se desarrolla un nuevo caso de estudio, en el cual se puede ver la implementación de los cuestionarios cerrados realizados a los stakeholders para establecer la importancia relativa a cada ítem de calidad.

En [20] se menciona la intercambiabilidad del MC QSAT [18, 19] con los Modelos de calidad (ISO/IEC 9126 e, ISO/IEC 25010). Además, se plantea que se ha establecido un método de evaluación basado en los procesos de evaluación de software (ISO/IEC 14598 e ISO/IEC 25040), pero incorporando actividades en la evaluación que permitiesen incorporar objetivos de evaluación de diferentes stakeholders.

Por lo antes mencionado, se observa que MyFEPS [16, 17] es un marco de trabajo basado en normas internacionales y con una marcada trayectoria en el campo de la evaluación y determinación del grado de calidad de productos de software, implementando un MC propio QSAT [18, 19] y también con el MC de ISO/IEC 25010, como se puede ver en dos tesinas de grado [21, 22]. Además, en [23], se especifica la utilización de una técnica de cuestionarios cerrados a stakeholders como instrumento válido para establecer la importancia relativa a cada ítem de calidad.

Si bien, en el marco de MyFEPS [16, 17] y con el MC QSAT [18, 19], la técnica de cuestionarios cerrados ha sido validada en los procesos de evaluación de productos de software, en este trabajo se pretende demostrar el aporte de esta técnica como apoyo al proceso de definición de los requisitos de calidad de las partes interesadas, integrado a un proceso licitatorio y siguiendo lo establecido en ISO/IEC 25030 [8] y el MC definido en ISO/IEC 25010 [6].

En la Norma ISO/IEC 25030 [16] se explicitan dos procesos que intervienen para llegar a los requisitos de calidad del software:

1- El proceso de definición

2 - Proceso de análisis.

Dado los objetivos que se pretenden cumplir en el presente trabajo, es que el foco estará puesto en el Proceso de definición para arribar a los requisitos de -calidad de las partes interesadas, según se resalta en la Fig. 2.

En las secciones anteriores se observa la cobertura de ISO/IEC 25030[8] para llegar a la definición de los requisitos de calidad del software y también las relaciones y las contribuciones que existen entre las normas pertenecientes a SQuaRE [13] para llevar a cabo ese proceso.

Para obtener los requisitos de calidad de las partes interesadas vemos que una de las relaciones más importantes es la que se estable entre ISO/IEC 25030 [8] e ISO/IEC 25010 [6]. También la Norma ISO/25023 [15] aporta información de interés, sobre todo para aquellas subcaracterísticas que están asociadas con varias métricas, si bien este trabajo no se enfoca en el proceso de análisis, se considera que es importante que forme parte de la propuesta, dado que luego lo resultante del proceso de definición será la entrada para el proceso de análisis.

Para ISO/IEC 25030 [8], el modelo de referencia de calidad es ISO/IEC 25010 [6], este modelo cumple una función esencial en el proceso de definición de los requisitos de calidad, y se menciona que el mismo puede utilizarse como una lista de verificación para garantizar la cobertura de todos los aspectos de la calidad.

Si bien el MC propuesto en ISO/IEC 25010 [6] contiene información detallada y conceptos bien desarrollados respecto de lo que significa cada característica y subcaracterística de calidad, en la mayoría de los casos es difícil solo utilizar el modelo como una lista de verificación directamente con los usuarios, esto último está asociado a una cuestión netamente de comprensión del lenguaje técnico que se utiliza [14].

Por ello, y visto el análisis llevado a cabo y de la experiencia recogida en [14], se pudo observar, entre otros, algunos aspectos relacionados con: los usuarios no contaban con información y/o formación técnica para poder discernir entre las distintas características y subcaracteríscas que le presentaba el modelo, los grupos de usuarios tenían necesidades y/o expectativas diferentes y por ende se debía incorporar alguna técnica que pudiera recoger la información de una manera homogénea y que luego ésta pudiera procesarse a través de algún método que permitiese llegar a algún tipo de resultado y que, si bien en ISO/IEC 25030 [8] se plantean los procesos y relaciones entre las normas, no se explicitan técnicas y/o herramientas específicas que den soporte a los procesos tanto de definición como de análisis.

Visto lo anterior, subyace la necesidad de contar con alguna técnica que permita indagar sobre la opinión de los usuarios pertenecientes a las partes interesadas respecto de los aspectos de calidad de un determinado software.

Luego estas opiniones deberán ser analizadas a través de algún método que permita ponderarlas y así lograr la identificación y clasificación de las características y subcaracterísticas de calidad, a través del nivel de importancia que cada usuario les ha asignado a los aspectos de calidad sobre los que se lo ha consultado.

Para llevar a cabo lo planteado se utilizó uno de los métodos que se plantea a través de la teoría de la construcción de escalas de actitudes [24].

Según se puede observar en [24], para la construcción de estas escalas de actitudes existen distintos métodos, los cuales tienen característica y complejidades que determinan su aplicación respecto de lo que lo se pretenda obtener.

Analizado lo anterior y vista la necesidad planteada, obtener y analizar la opinión de las partes interesadas respecto de los aspectos de calidad, es que se escoge el método que propone la construcción de escalas de Likert [25].

Este método se basa en escalas de calificaciones sumadas, en donde los sujetos (usuarios) señalarán su calificación de los ítems (pregunta) de acuerdo a cinco categorías.

Dichas categorías, están clasificadas en escalas para determinar acuerdo, frecuencia, importancia y probabilidad.

Dado el perfil del trabajo a desarrollar se propone trabajar con la escala de cinco categorías de importancia que se muestra en la Fig. 3.

Fig. 3 - Representación gráfica de la escala de Likert [25]

Dado este marco y vistas las necesidades planteadas en [14], es que se propone el desarrollo de una guía de preguntas que permitan recoger las opiniones de los usuarios pertenecientes a las partes interesadas respecto de los aspectos de calidad para las funcionalidades de un determinado software en un ámbito específico de aplicación.

Para la elaboración de estas preguntas se utilizaron los siguientes elementos:

- Norma ISO/IEC 25030 [8]

- Norma ISO/IEC 25010 [6]

- Norma ISO/IEC 25023 [15]

- Escala de Likert [25]

- Recomendaciones para recoger opiniones [24]

Estas preguntas están relacionadas con las características y subcaracterísticas del MC de ISO/IEC 25010 [6] y las métricas definidas en ISO/IEC 25023 [15] y tienen la finalidad de que los distintos tipos de usuarios (principales, secundarios e indirectos) puedan responderlas de manera autónoma teniendo en cuenta el software o sistema objeto de análisis y el ámbito de aplicación del mismo. Las respuestas se dan en una escala de cinco niveles de importancia de Likert [25].

Las preguntas están redactadas preferentemente en lenguaje no técnico, siguiendo las recomendaciones descriptas en [24].

La elaboración de esta guía arrojó como resultado un total de 84 preguntas. Estas preguntas abarcan la totalidad de las características y subcaracterísticas del MC de ISO/IEC 25010 [6].

Dado que, al existir distintos tipos de usuarios, éstos cuentan con necesidades y/o expectativas diferentes, por ello, es que se conformaron tres tipos de cuestionarios que contienen un subconjunto de las 84 preguntas cada uno.

A continuación, se da un ejemplo de cómo quedaron redactadas las preguntas y su asociación con las características y subcaracterpisticas de calidad en base al modelo de calidad externo de ISO/IEC 25010 [6] y la asociación con las métricas correspondientes a ISO/IEC 25023 [15]

Característica: Usabilidad

Subcracteristica: Operatividad

Métrica Asociada: Soporte de dispositivos de entrada

Pregunta: ¿Qué importancia tiene para usted que el sistema pueda realizar las tareas mediante todas las modalidades de entrada apropiadas, como el teclado, el ratón o la voz? (Ej: en determinados casos el uso del teclado hace las tareas más sencillas, el uso de lectores de código de barras, etc.)

Respuesta

Si bien estos cuestionarios fueron validados por usuarios y revisado por colegas, a medida que se vayan recogiendo más experiencias, se podrán ir refinando y mejorando. Para probar y ajustar esta técnica de relevamiento y proceso de información de las partes interesadas se identificó a un grupo de usuarios, los cuales luego participaron del caso de estudio que se plantea en la sección VIII.

Los cuestionarios elaborados se enviaron a estos usuarios vía correo electrónico en formato .doc. Las respuestas consignadas fueron transcriptas a una planilla de cálculo especialmente diseñada, para luego realizar los cálculos propuesto por el método Likert [25].

A través de este ensayo se pudo determinar la utilidad de contar con un instrumento de relevamiento que oriente el proceso de definición de los requisitos de calidad de las partes interesadas.

También se pudo observar que los usuarios interpretaron bien las consignas de los cuestionarios y en ningún caso quedaron preguntas sin responder.

De la experiencia realizada se recogieron una serie de recomendaciones, comentarios y sugerencias, los que se documentaron como requisitos para mejoras de la técnica desarrollada, éstas se enumeran a continuación:

- Actualizar y mejorar algunos aspectos referidos al lenguaje y redacción de las preguntas.

- Configurar nuevos cuestionarios según el perfil de usuarios (principales, secundarios e indirectos).

- Ampliar a otros modelos de calidad (por ejemplo: Calidad en Uso).

- Mejorar la identificación y trazabilidad de los requisitos de calidad de las partes interesadas.

- Pensar la implementación para múltiples Organismos.

- Contar con un proceso automatizado de carga de respuestas y procesamiento de la información.

- Automatizar el proceso de envío y recepción de cuestionarios.

Si bien lo obtenido en este ensayo no se puede generalizar, sí se observa que esta técnica realiza un aporte para la implementación del proceso de definición de los requisitos de la calidad de las partes interesadas según lo establece ISO/IEC 25030[8].

En las secciones siguientes se pretende evolucionar esta propuesta de la técnica, tomando como punto de partida lo desarrollado hasta aquí.

VII. SISTEMA PARA LA DEFINICIÓN DE LOS REQUISITOS DE LAS PARTES INTERESADAS (SISRCPI)

En esta sección se presenta el sistema desarrollado, denominado Sistema para la Definición de Requisitos de Calidad de las Partes Interesadas (SisRCPI).

Este sistema fue específicamente diseñado con el objetivo de que los OAP cuenten con un instrumento que les permita, de manera autónoma y flexible, poder especificar los requisitos de calidad para incluir en un pliego licitatorio de software, en el marco de los ETAP y la serie de normas SQuaRE [13].

Las funcionalidades con las que cuenta SisRCPI están básicamente orientas a:

- Procesos de creación y actualización de las preguntas.

- Creación, modificación, envío y procesamiento de cuestionarios.

- Registro de los OAP, partes interesadas, usuarios, pliegos licitatorios, detalles del software involucrado en las licitaciones.

- Emisión de informe sobre el resultado del proceso de definición de requisitos de la calidad de las partes interesadas.

El informe que emite el sistema, como resultado del procesamiento de los cuestionarios contestados por los usuarios, cuenta con el detalle de las características y subcaracterísticas que representan los requisitos de calidad de las partes interesadas.

Todos esos requisitos cuentan con trazabilidad hacia las partes interesadas que los originaron y hacia el MC de referencia.

El informe emitido podrá ser tomado sin modificaciones por el OAP y ser incluido en el Pliego Modelo 14, o bien el mismo podrá ser modificado a criterio y bajo la responsabilidad del OAP interviniente. Si hubiese modificación del informe, la misma se graba como una nueva versión, quedando registrado el histórico de versiones.

VIII. CASO DE ESTUDIO

El desarrollo del presente caso de estudio tiene como objetivo brindar un ejemplo de aplicación o instanciación del sistema SisRCPI en el proceso de definición planteado en ISO/IEC 25030 [8] (ver Figura 2), con el fin de incorporar en el Pliego Licitatorio los requisitos de calidad de las partes interesadas.

El caso se basa en un OAP perteneciente al sistema público de educación superior. Este organismo necesita incorporar un software para la gestión de la organización de eventos, su calendario y recursos asociados.

El software a incorporar deberá cubrir, entre otros, los siguientes procesos: carga de evento en calendario, la asignación de recursos (tecnológicos, mobiliario, didácticos, etc.) y ambientes necesarios (verificando disponibilidad de los mismos para las fechas y horarios elegidos), funcionalidad de comunicación de alertas de cambios para los involucrados (responsables de áreas, profesores, participantes, alumnos, etc.), emisión de informes de ocupación de ambientes, recursos y novedades en general.

A continuación, en el punto A se describe como lleva a cabo la carga de los datos iniciales sobre el MC de referencia que se utilizará y el conjunto de preguntas asociadas a este modelo. Luego en punto B, se desarrolla el caso de estudio aplicando SisRCPI.

A. Precarga de SisRCPI

1. Carga inicial del Modelo de Calidad

Este menú cuenta con la posibilidad de cargar las vistas de calidad, en este caso se establece la carga según lo propuesto en ISO/IEC 25010 [6] (Vista interna, externa y en uso).

Luego se deben cargar los elementos que conformarán el MC a través de la especificación de las características, subcaracterísticas y métricas, según corresponda a la vista de calidad a la que pertenezca el modelo.

Dado el marco del presente trabajo, se utilizará vista de calidad externa para la carga del modelo y sus métricas según lo establecido en ISO/IEC 25010[6] e ISO/IEC 25023 [15].

Este modelo es un parámetro del sistema y podrá ser utilizado por todos los OAP que lo necesiten.

2 Carga inicial de las Preguntas

A través del menú correspondiente del sistema, se realiza la carga de todas las preguntas, cada una de ellas se asocia a una característica, subcaracterística y métrica de calidad, ya establecida en el MC en el paso 1.

Como resultado de lo desarrollado en la Sección VI de este trabajo, el conjunto de preguntas redactadas inicialmente asciende a 84.

Este conjunto de preguntas estará disponible para todos los OAP, luego cada organismo tendrá la libertad de realizar modificaciones sobre las mismas y sobre las asignaciones por tipo de usuario.

B. Desarrollo del caso puntual

A continuación, se describen todos los pasos por los cuales se fue cargando la información correspondiente al sistema.

1 Carga particular del OAP

A través del menú Organizaciones, se procede a dar de alta al OAP, las partes interesadas, los usuarios, el tipo de software, tipo de adquisición, software y especificación del pliego.

- Organización: El organismo que se da de alta para el caso de estudio es un Organismo perteneciente al sistema público de educación superior.

- Partes interesadas: se define para este caso que la clasificación general de las partes interesadas es la de Adquirente.

- Usuarios: se cargan los usuarios con sus respectivos datos filiatorios y se asocia al tipo de usuario según corresponda (principal, secundario e indirecto).

Para este caso existen 8 usuarios principales (usuarios pertenecientes a las áreas de extensión universitaria y departamento de alumno) y 3 usuarios para la clasificación de secundarios e indirectos (usuarios pertenecientes al área de TIC´s).

2 Tipo de software: este es un parámetro del sistema para identificar si el software a licitar será: un producto listo para usar, un producto a medida o modificaciones de un producto existente.

3 Tipo adquisición: este es un parámetro del sistema para identificar uno de los objetivos de la licitación. Las opciones son: Reemplazo total o parcial de un producto existente o Implementación de un nuevo producto.

4 Software: Aquí se detalla un nombre y una descripción del software que se pretende adquirir y se debe especificar el Tipo de software y el Tipo de adquisición.

También se deben especificar las principales funcionalidades que el software deberá tener para cubrir las necesidades de los distintos tipos de usuarios (principales, secundarios e indirectos)

Para este caso en particular la carga se realiza con los siguientes datos:

- Software: software de gestión para la organización de eventos, su calendario y recursos asociados. A continuación se describen las principales funcionalidades asociadas a los tipos de usuarios.

Usuarios Principales:

Estos usuarios cuentan con la necesidad de realizar la carga de eventos y poder calendarizarlos. Para ello, será necesario que el software pueda crear un evento pudiendo asignar su dependencia institucional, en qué ambiente se va a desarrollar, con qué recursos tecnológicos de mobiliario y/o didácticos se debe contar, verificando para la fecha y hora estipulada la disponibilidad de los recursos necesarios. También es necesario poder comunicar a todas las partes intervinientes en el evento el estado del mismo y los cambios que existen.

Usuarios secundarios e indirectos:

Estos usuarios cuentan con la necesidad de que el software a implementar cumpla con las pautas técnicas y de calidad establecidas por la institución, y que a partir de su implementación se cuente con información centralizada y actualizada con el fin de gestionar de manera eficiente los recursos involucrados.

- Tipo de software: Producto listo para usar.

- Tipo de Adquisición: Implementación de un nuevo producto.

5 Pliego: en esta opción se debe detallar la identificación del pliego para el cual se llevará a cabo el proceso licitatorio de software, se selecciona el software objeto a ser licitado, este último trae asociado, el tipo de software y adquisición, lo que configura parte del objetivo del pliego. Para este caso queda expresado de esta manera:

Nombre del Pliego: Pliego SW_SFCO0002

Objetivo Adquisición: Adquisición e implementación de un producto de software listo para usar.

Producto Software: Software para la gestión de organización de eventos, su calendario y recursos asociados.

6 Creación, relación y envío de Cuestionarios

A través del menú Cuestionarios se accede a la opción Gestionar y se realizan las siguientes tareas:

- Crear los cuestionarios para cada tipo de Usuario (principal, secundario e indirecto). Para el caso en desarrollo se crean dos tipos de cuestionarios.

- Cuestionario usuarios principales

- Cuestionario usuarios secundarios e indirectos

Para cada tipo de cuestionario (principal, secundario e indirecto), se le asignan las preguntas correspondientes a través de la selección de las mismas del conjunto de preguntas ya cargadas. Para el caso en desarrollo la asignación de preguntas quedó de la siguiente forma:

- Cuestionario usuarios principales: 14 preguntas.

- Cuestionario usuarios secundarios e indirectos: 84 preguntas.

- Una vez completado cada tipo de cuestionario con sus preguntas, se le asigna los usuarios que deberán responderlas. De la misma forma, se muestra la lista de usuarios ya cargados y preclasificados para que se puedan seleccionar y relacionar al cuestionario correspondiente según la tipificación de usuario (principal, secundario e indirecto).

Para el caso en desarrollo la asignación queda planteada de la siguiente manera:

- Cuestionario usuarios principales: 8 usuarios asignados.

- Cuestionario usuarios secundarios e indirectos: 3 usuarios asignados.

- Con los pasos anteriores realizados se procede al envío de los cuestionarios. Este proceso lo realiza el sistema a través del envío automático de un correo electrónico a cada usuario. En el mismo correo se encuentra el link de acceso al cuestionario, este link redirige a los usuarios al sitio donde se encuentra el cuestionario a contestar.

7 Respuesta de los Usuarios

Los usuarios recibirán un correo electrónico, según se explica en 6. Para ingresar y responder el cuestionario, el usuario lo hará a través del link dispuesto en el correo.

En la Fig. 4 se ejemplifica con una captura de pantalla correspondiente a una pregunta.

Fig. 4. - Pregunta del cuestionario (SisRCPI)

Una vez que el usuario completa el cuestionario, solo debe presionar el botón grabar para concluir con el proceso de carga.

Los datos son grabados directamente en la base de datos de SisRCPI, si el proceso se realiza con éxito el usuario recibe un correo con la confirmación de que su cuestionario fue almacenado correctamente.

A través del proceso de respuesta de cada uno de los usuarios quedan establecidas las necesidades de calidad de cada uno de ellos.

7 Procesamiento de los cuestionarios

El resultado de este proceso será la determinación de los requisitos de calidad de las partes interesadas de acuerdo al proceso descripto por ISO/IEC 25030 [8].

Para lograr ese resultado, el sistema agrupa los cuestionarios contestados por tipo de usuario, para luego realizar los cálculos previstos por el método Likert [25], e implementados en el sistema a través de un algoritmo programado para tal fin.

Lo que el sistema obtiene es una lista con las preguntas ponderas por el método de Likert [25] ordenadas de mayor a menor según el porcentaje que cada categoría de preguntas haya obtenido.

Lo que se debe establecer es el criterio de aceptación, desde que porcentaje en adelante se aceptará para que esas preguntas luego sean transformadas en características y subcaracterísticas de calidad.

Este criterio tendrá que ver con cuestiones legales, institucionales, técnicas y de preferencia que los responsables del OAP deberán tomar para incluir más o menos requisitos de calidad en el pliego licitatorio.

Luego de esto, el sistema estará en condiciones de emitir un informe con los resultados obtenidos, a modo de propuesta de requisitos de calidad a ser incluidos en el pliego licitatorio. Este informe, a criterio y bajo responsabilidad del OAP, podrá ser modificado y generar una nueva versión del informe de requisitos de calidad.

A continuación, se da un ejemplo, a través del caso de estudio desarrollado, de cómo quedan ponderadas las preguntas y luego transformadas en características y subcaracterísticas de calidad, logrando de esta manera obtener los requisitos de calidad de las partes interesadas, las cuales formarán parte del informe a ser incluido en el Pliego Licitatorio.

La Fig. 5 muestra una captura parcial de los datos, en donde se puede ver cómo quedan ponderadas las preguntas.

Fig. 5 - Vista parcial de las preguntas ponderadas

El criterio de aceptación para este caso fue para aquellas preguntas que hayan superado el 50% y corresponden a las partes interesadas pertenecientes a los Usuarios principales.

Dado el paso anterior, el sistema realiza la trazabilidad de las preguntas para determinar a qué característica y subcaracterística corresponde esa pregunta y le asocia la/s métricas correspondientes, ver Fig. 6. Esto último surge como una necesidad, dado que hay muchas subcaracterísticas que son medidas por varias métricas.

Fig. 6 - Vista parcial de la trazabilidad

Dado que lo anterior se ejecuta para cada grupo de usuarios pertenecientes a las distintas partes interesadas, SisRCPI obtendrá como máximo tres informes como propuestas de requisitos de calidad por cada grupo de usuarios (principales, secundarios e indirectos) de las partes interesadas.

Para el caso de estudio desarrollado, se obtuvieron dos informes de propuestas de requisitos de calidad, uno para usuarios principales y otro que incluye a los usuarios secundarios e indirectos.

Dado que el informe propuesto de las partes interesadas que incluye a los usuarios secundarios e indirectos es más amplio que el de usuarios principales, el sistema toma como prioritarias aquellas características y subcaracterísticas que aparecen priorizadas en los dos informes y luego completa el informe con el resto.

En la Fig. 7 se ejemplifica lo dicho, las tres primeras columnas se dejan en este ejemplo a los fines de mostrar la priorización hecha por cada conjunto de usuarios y el ID de pregunta que realiza la trazabilidad hacia el MC tomado como referencia. Se puede observar que las primeras 5 filas corresponden a las coincidencias priorizadas derivadas de los informes de Usuarios principales y el de los Usuarios secundarios e indirectos.

Fig. 7 - Informe ensamblado

Como último paso SisRCPI emitirá el informe preliminar, éste se muestra de manera parcial a través de la Fig. 8.

Fig. 8 - Informe de Requisitos de calidad de las partes interesadas

- Este informe, como se mencionó anteriormente podrá ser modificado por el OAP bajo su responsabilidad.

De esta forma quedan definidos los requisitos de calidad de las partes interesadas a ser incluidos en el Pliego Licitatorio Modelo 14, respecto de un software específico y que será utilizado en condiciones establecidas.

IX. RESULTADOS Y OBJETIVOS

El objetivo general del presente trabajo fue desarrollar una propuesta como aporte al proceso de definición de requisitos de calidad de software, con el fin de que los Organismos pertenecientes a la APN tuvieran un instrumento que les de soporte para poder definir esos requisitos e incluirlos en los pliegos licitatorios de software. Todo ello en el marco de lo propuesto en los ETAP [2] y la serie de normas ISO/IEC 25000 [13].

También es oportuno mencionar que este trabajo es la continuidad del trabajo desarrollado en [14]. En éste, se pone en evidencia que en el Pliego Modelo 14, perteneciente a los ETAP, no se establecían de manera explícitas mecanismos para especificar los requisitos de calidad que un determinado OAP quisiera incluir para la adquisición de un software.

Por ende, este trabajo desarrolla inicialmente una técnica que posibilita la recolección y procesamiento de las necesidades de calidad de las partes interesadas como apoyo al proceso de definición de requisitos de calidad de las partes interesadas en el marco propuesto por ISO/IEC 25030[8].

Los resultados de aplicar esa técnica demostraron que la misma fue de utilidad y a su vez se pudieron documentar recomendaciones que luego serían utilizadas para mejorar la técnica propuesta.

También se pudieron determinar de manera específica las relaciones y aportes que cada norma perteneciente a la serie de ISO/IEC 25000 [13] podían realizar al proceso de definición de requisitos de calidad de las partes interesadas. En particular se explicitaron las principales relaciones y aportes de las normas ISO/IEC 25010[6], 25041[19] y 25023[15] en relación a ISO/IEC 25030 [8].

Como parte del proceso de validación de este sistema, fue fundamental el desarrollo de un caso de estudio, el cual permitió implementar el proceso de definición de requisitos de calidad de las partes interesadas según ISO/IEC 25030[8] a través de SisRCPI.

A través del uso del sistema, el OAP que formó parte del caso de estudio logró obtener la definición de los requisitos de calidad a ser incorporados al Pliego Modelo 14, para la adquisición de un software en el maro de los ETAP [2] y la serie de normas ISO/IEC 25000 [13].

X. DISCUSIÓN

El Pliego Modelo 14 es uno de los instrumentos que forman parte del Proceso Licitatorio, definido en los ETAP [2], en el cual se identificó la falta de métodos o técnicas que permitiesen a un OAP incorporar al pliego los aspectos relacionados con la calidad del software a adquirir.

En el trabajo presentado en [14] se demostró que la serie de normas ISO/IEC 25000[13] realiza un aporte para la especificación y evaluación de calidad de software en el marco del Pliego Modelo 14. Dejando también planteada la necesidad del desarrollo de técnicas y/o métodos que pudieran dar soporte a estos dos procesos.

Este trabajo toma esas necesidades y propone, para el proceso de definición de requisitos de calidad de las partes interesadas, el desarrollo de una técnica para recolección y procesamiento de las necesidades de calidad de las partes interesadas, lo que luego se transforma en un sistema que permite la automatización del proceso definido en ISO/IEC 25030 [8].

Cabe destacar que, si bien, tanto la técnica como el sistema posibilitan trabajar con distintas vistas de calidad y partes interesadas, para este trabajo sólo se tomó la vista externa y desde la perspectiva del adquirente. En este sentido, se está trabajando en la realización de otros casos de estudio con vistas de calidad y partes interesadas distintas, en pos de seguir validando la técnica y el sistema propuesto.

XI. CONCLUSIONES

Las tecnologías de última generación en informática y comunicaciones, constituyen una herramienta esencial en el proceso de modernización y transformación del Estado Argentino. A través del Plan de Modernización del Estado se impulsa a que todos los Organismos pertenecientes a la Administración Pública Nacional (APN) vayan incorporando tecnología para hacer más eficientes sus principales procesos administrativos y de gestión.

Visto el mencionado Plan, se pudo observar que los Organismos pertenecientes a la APN cuentan con una serie de instrumentos técnicos y legales, entre los cuales se encuentran los Estándares Tecnológicos para la Administración Pública (ETAPs), los cuales tienen como fin asistir en el proceso de contratación de soluciones tecnológicas, tanto a nivel técnico y funcional, como así también a nivel formal para llevar a cabo los procesos de licitación.

Dentro de este marco, en el presente trabajo se desarrolló una propuesta con el fin de realizar aportes desde la perspectiva de la calidad de productos de software, específicamente como soporte al proceso de licitación de software incluido en los ETAPS, y guiado por el denominado Pliego Modelo 14.

La propuesta estuvo centrada en el desarrollo de una técnica que permita la recolección y procesamiento de las necesidades de calidad de las partes interesadas, lo que luego se transforma en un sistema que permite la automatización del proceso, que forma parte del pliego licitatorio para la adquisición de software.

A lo largo del desarrollo del trabajo se pudo ver la utilidad a nivel conceptual que aporta el marco de referencia de ISO/IEC 25030 [8] centrado en las partes interesadas o stakeholders, también se puso en evidencia la necesidad de poder contar con estrategias y herramientas que den soporte a lo planteado en la mencionada norma.

Los métodos basados en la teoría de la construcción de escalas de actitudes [24], fueron un aporte significativo para la estrategia desarrollada, específicamente el método de Likert [25], lo cual permitió contar, no solo, con un marco para estructurar las preguntas y las respuestas respecto de una escala de importancia, sino que también se pudo probar su utilidad en el ámbito de aplicación.

Los cuestionarios específicamente diseñados a partir de las preguntas elaboradas en función de un modelo de calidad de referencia, para este trabajo el modelo de calidad propuesto por ISO/IEC 25010 [6], fueron un instrumento indispensable para recabar la opinión de los usuarios, que conforman las distintas partes interesadas.

A través de las recomendaciones, comentarios y sugerencias que se pudieron registrar de la prueba de concepto realizada y el modelo conceptual elaborado, es que se pudo diseñar y codificar la aplicación SisRCPI.

Se pudo evidenciar la importancia de poder llevar a cabo el agrupamiento y tratamiento de los distintos tipos de usuarios como principales, secundarios e indirectos los cuales pudieron reflejar sus necesidades y expectativas a través de las respuestas a las preguntas que formaron parte de los cuestionarios específicos para cada tipo de usuario. Eso posibilitó, por ejemplo, que los cuestionarios fueran contestados por los distintos tipos de usuarios sin mayores inconvenientes.

También es importante destacar que la aplicación de la técnica y la utilización de la aplicación SisRCPI, permitió al organismo involucrado contar con información cuantitativa al momento de obtener la especificación de requisitos de calidad para el software que era objeto de la licitación.

De manera general se observa que esta propuesta constituye un aporte al campo de la calidad del software, en lo que concierne a la especificación de requisitos de calidad para productos de software. En este sentido, se observa que también se está contribuyendo a través de una aplicación que da soporte operativo al propio proceso definido por ISO/IEC 25030 [8]

Todas las contribuciones antes mencionadas no solo realizan un aporte al área del conocimiento, sino que también realizan aportes que contribuirán para lograr los objetivos del Plan de Modernización del Estado y cooperar con la implementación y utilización de los ETAPs.

XII. REFERENCIAS Y BIBLIOGRAFÍA

[1] Decreto 434/2016 Plan de Modernización del Estado de la República Argentina

[2] Estándares Tecnológicos para la Administración Pública (ETAP) Recuperado en 2018: https://www.argentina.gob.ar/estandares-tecnologicos

[3] Sommerville, Ian., Ingeniería de Software. 9ª edición: PEARSON EDUCACIÓN, México, 2011.

[4] CALLEJAS-CUERVO, Mauro; ALARCÓN-ALDANA, Andrea Catherine; ÁLVAREZ-CARREÑO, Ana María. Modelos de calidad del software, un estado del arte. En: Entramado. Enero - Junio, 2017. Vol. 13, no. 1, p. 236-250, http://dx.doi.org/10.18041/entramado.2017v13n1.25125

[5] IEEE Standard 610.Institute of Electrical and Electronics Engineers Computer dictionary. Compilation of IEEE Standard Computer Glossaries.1990

[6] ISO/IEC 25010 Systems and software engineering-Systems and software Quality Requirements and Evaluation (SQuaRE)-System and software quality models. ISO, 2011

[7] R. Pressman, Ingeniería de Software. 6ª Ed: Mcgraw-Hill, 2005.

[8] ISO/IEC 25030: Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements. ISO, 2007

[9] ISO/IEC 25010: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality Models

[10] A. Villalta, J.P. Carvallo “Modelos de calidad de software: Una revisión sistemática de la literatura” en Maskana, CEDIA 2015.

[11] CALLEJAS-CUERVO, Mauro; ALARCÓN-ALDANA, Andrea Catherine; ÁLVAREZ-CARREÑO, Ana María. Modelos de calidad del software, un estado del arte. En: Entramado. Enero - Junio, 2017. vol. 13, no. 1, p. 236-250, http://dx.doi.org/10.18041/entramado.2017v13n1.25125

[12] Estayno, Marcelo; Dapozo, Gladys; Cuenca Pletch Liliana, Greiner. Modelos y métricas para evaluar calidad de software Recuperado en 2019: http://sedici.unlp.edu.ar/bitstream/handle/10915/19762/2397-Estayno_UNNE_UTN.pdf?sequence=1

[13] ISO/IEC 25000 Systems and software engineering-Systems and software Quality Requirements and Evaluation (SQuaRE)- Guide to SQuaRE, ISO, 2014.

[14] Saldarini J., Carrizo C., Armando S., Trasmontana J., Salgado C, Sanchez A., Peralta M. La serie SQuaRE como un aporte a los procesos licitatorios de Software en el Estado Argentino. 6° Edición CONAIISI 2018

[15] ISO/IEC 25023: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of system and software product quality. ISO, 2016(E)

[16] Sorgen, A., Angeleri, P., "El Modelo de Evaluación del Proyecto MyFEPS", 40JAIIO - ASSE 2011 - ISSN: 1850-2792, 2011, pp. 180-191.

[17] Sitio Oficial MyFEPS Recuperado en 2019: https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/portada

[18] Modelo de Calidad QSAT Recuperado en 2019: https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/qsat-1.

[19] Angeleri, P., Oliveros A., Sorgen, A., Titiosky R., “Modelo de calidad de productos de software”, CoNaIISI 2014 - ISSN: 2346-9927, 2014, pp. 1043-1051

[20] Angeleri, P., Titiosky R., Ceballos J.: Framework de Evaluación de Productos Software, XVIII Workshop de Investigadores en Ciencias de la Computación 2016.

[21] Tesina Agustin Ventura.V13.docx (Proyecto de evaluación MyFEPS) (https://biblioteca.ub.edu.ar/cgi-bin/koha/opac-detail.pl?biblionumber=49601)

[22] Tesina Martin Santi - Eval Usabilidad SW Comercio Electrónico con MyFEPS v2014-09-25.pdf (https://biblioteca.ub.edu.ar/cgi-bin/koha/opac-detail.pl?biblionumber=49786#)

[23]. Angeleri P., Titiosky R.., Ceballos J., Maspero Ch., Sánchez A., Menal M., Vinjoy M., “Certificación de producto software (Software Product Certification)”. CACIDI 2016. Paper 55

[24] N. Cortada de Kohan, Teoría y Métodos para la construcción de Escalas de Actitudes. 1ª Ed: Lugar Editorial SA, Buenos Aires 2004.

[25] Likert, RA, A mewthod of constructing an acttitude scale. GM Maranell. Chicago 1974

[26] IRAM ISO/IEC 25030:2019: Ingeniería de Software – Requisitos de la calidad del producto de software (SQuaRE) – Requisitos de Calidad. IRAM 2019

Recibido: 2020-07-30

Aprobado: 2020-08-05

Hipervínculo Permanente: http://www.reddi.unlam.edu.ar

Datos de edición: Vol. 5-Nro. 1-Art. 6

Fecha de edición: 2020-08-15