1. INTRODUCCIÓN

En la actualidad, el acceso a herramientas que usen software para el desempeño de actividades específicas es rutinario, por ello el aseguramiento de la calidad es una tarea de control para poder asegurar que exista una homogeneidad en base a estándares internacionales que evite el fracaso del aplicativo por cuestiones meramente técnicas.

La presente investigación precisamente trata sobre listar esos criterios que deben satisfacerse para garantizar un éxito en el uso cotidiano del software, por lo que se analizaron fuentes relativas al tema principal para luego llegar a un consenso de lo esencial que pueda garantizar que, el sistema de información desarrollado cumpla con los requerimientos necesarios de calidad especificados.

La Calidad de Datos o Calidad de Información, depende directamente de su consideración como entrada en y del sistema de información que la procesa y, por tanto, es un factor importante de considerar en la producción. Efectivamente, la calidad de los datos suele definirse como "datos apropiados para el usó", es decir, datos que sean de utilidad para los consumidores/usuarios en un contexto de uso específico. Considerando todo lo anterior, en esta propuesta genere el instrumento para evaluar la calidad del software también se toma en consideración la calidad de los datos, y la forma en la que debe ser abordada desde que comienza el desarrollo del software que la generará. (Caro et al. 2013).

2. OBJETIVOS

2.1.General

Proponer un instrumento para evaluación de calidad en software, desarrollado con el estándar internacional Métrica versión 3 y de la información procesada por el mismo.

2.2. Específicos

1. 1. 1.- Definir el proceso de inspección de software y de qué manera se desarrollan.

   2.- Definir conceptos y fundamentos de calidad de software.

   3.- Definir las variables e indicadores en las que se fundamenta la investigación y la construcción del instrumento.

   4.- Construcción y definición de los contextos del instrumento para la evaluación del software y la información que este generará.

3. METODOLOGÍA

Se realizó una búsqueda exhaustiva de bibliografía existente para la elaboración de este trabajo, se recolectó información acerca de investigaciones y modelos que se usan en la actualidad para evaluar la calidad de los productos de software existentes (sin importar la finalidad de los mismos).

Se adquirió información sobre las tendencias de calidad que han venido surgiendo con el paso del tiempo, así mismo, la aplicación de las mismas, evaluando modelos y normas cuya finalidad es producir software de calidad tomándolas como base para plasmar una serie de procesos en un instrumento que pretende realizar la evaluación de la calidad de un sistema de información y de la información que de éste se obtiene.

Marco conceptual

Fundamentos de calidad y aspectos de importancia.

Diversas investigaciones abordan la calidad de la información con un aspecto muy relevante en el desarrollo de un sistema de información, algunas asumen la existencia de un proceso de generación de datos o de información, el cual entrega productos que deben ser evaluados y mejorados como parte de un proceso permanente dentro de una organización.

Calidad puede definirse, como afirma el Sr. Alfonzo “La calidad es una propiedad inherente de cualquier entidad que permite que ésta sea comparada con cualquier otra de su misma especie. Es un conjunto de propiedades inherentes a un objeto que le confieren capacidad para satisfacer necesidades implícitas o explícitas. Es la percepción que el cliente tiene de un producto o servicio, es una fijación mental del consumidor que asume conformidad con dicho producto o servicio y la capacidad del mismo para satisfacer sus necesidades”, de igual manera, existen otras definiciones que también es importante tomarlas en cuenta, entre las que se mencionan:

“Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas”.

“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”.

“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

“Es 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” (Pedro Luis Alfonzo 2012) .

“La calidad de la interacción influye de manera decisiva en que los usuarios se decanten por un sistema u otro” (González, et al. 2012) .

Proceso de inspección de software

El proceso de auditar un sistema de información no es nuevo, existen múltiples trabajos que se enfocan en plantear soluciones a este tipo de problemas, incluso hay muchos estándares internacionales que platean modelos precisos para auditar en su totalidad un software.

Modelos y estándares de calidad

Como menciona el Sr. Aguilar “Existen dentro de ISO una familia de estándares que se dedican aseguramiento de calidad de Software. Estos son los ISO 9100, incluido en esto “El estándar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en términos de una o más de seis características básicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las cuales se detalla a través de un conjunto de sub características que permiten profundizar en la evaluación de la calidad de productos de software”. Estándares en los cuales plantean una serie de criterios para lograr la calidad de un producto de software y resulta de importancia evaluar cada uno de ellos generando preguntas centrales como punto de partida en la evaluación. (Aguilar, M, Torres, B., 2014) .

Tabla No. 1

Características de calidad según la ISO 9126

(Aguilar M., Torres, B., 2014)

La calidad de un sistema de información tiene múltiples visiones y su logro supone un esfuerzo y un reto en la aplicación de técnicas, metodologías y recursos. Desde este punto de vista, la calidad de un sistema es la conformidad de requisitos funcionales y no funcionales documentados explícitamente, así como las características implícitas que se espera que todo software desarrollado profesionalmente debe cumplir. (González, et al. 2012).

La definición anterior pone de manifiesto la necesidad de caracterizar en base a requisitos y características los atributos deseables explícita o implícitamente de un sistema. Es ahí donde surge la necesidad de descomponer la calidad en un conjunto de características.

Dichas características serían de orden inferior y progresivamente deberían ser más fáciles de estimar o evaluar. Es muy fácil revisar códigos, pero muy difícil detectar los defectos. Por este problema los investigadores han estudiado métodos formales para la verificación correcta de los sistemas. La mayoría de veces los desarrolladores carecen de tiempo para realizar las pruebas pertinentes antes de la utilización o comercialización del producto; en cambio, deberán disponer de tiempo para atender quejas y demandas en etapas posteriores (Espinosa 2006). Es crucial y de gran importancia auditar un software para que, a su vez, genere datos de calidad. Actualmente la exigencia de información de calidad es mayor, por lo tanto, el disponer de herramientas que promocionen dicha ventaja nos da competitividad en el mercado.

Al desarrollar un producto se hacen múltiples pruebas e inspecciones que llevan a perfeccionar y mejorar la calidad del mismo, pero al hacerlas hay múltiples aspectos que tomar en cuenta, como señala la Srta. Espinosa, “Los métodos de inspección pueden ser más efectivos que una revisión formal y requieren menos esfuerzo que las pruebas formales, pero su éxito depende de tener un seguro y sistemático procedimiento para conducir la inspección.”, por tanto debemos estructurar buenos procesos que permitan que el producto final sea de calidad.

También, se puede mencionar que para llevar a cabo estos procesos se necesita de personas capaces y con el conocimiento necesario para realizarlos, he aquí que se debe conformar un equipo de inspección donde cada participante posea uno o varios roles bien definidos por sus características, habilidades y conocimientos desempeñando papeles como: director, moderador, productor, registrador, revisor y lector.

Estos roles varían en dependencia del modelo de proceso y esto se debe a la existencia de empresas con características y personal muy diferentes. Al disponer de un equipo con sus respectivos roles asignados, permite definir etapas de inspección en el desarrollo del producto y son: planeación, una vista previa, preparación, reunión, corrección y seguimiento (Espinosa 2006).

A medida se desarrolla un sistema de información se puede ir estableciendo criterios de calidad que posteriormente proporcionan un producto de mejor calidad, la pruebas generalmente hacen resaltar las deficiencias y fortalezas en un sistema de información, por ello cabe mencionar que un aspecto crucial en el control de calidad del desarrollo de software son las pruebas y, dentro de estas, las pruebas funcionales, en las cuales se hace una verificación dinámica del comportamiento de un sistema, basada en la observación de un conjunto seleccionado de ejecuciones controladas o casos de prueba.

Para hacer pruebas funcionales se requiere una planificación que consiste en definir los procesos y la forma de verificar su correcto funcionamiento, punto en el cual adquieren sentido los casos de prueba en las inspecciones y pruebas pilotos de los sistemas de información. (González, P., 2009).

Figura No. 1
Modelo de Inspección con Listas de Comprobación
(Espinosa 2006)

Un ejemplo bastante claro de cómo realizar una inspección y que cabe mencionar es haciendo uso del Modelo de Inspección con Listas de Comprobación (MILCO), el cual se divide en tres etapas, entre ellas: Planificación- donde se definen las tareas, documentos y personas que participaran, es la etapa más importante donde se define toda la información que guiará a todo el proceso de inspección, así también, la preparación de la misma que la hace el jefe de aseguramiento de calidad en conjunto con el desarrollador.

Otra de las etapas es la Verificación- donde se aplican las listas de comprobación para obtener una valoración, mediante una inspección síncrona o asíncrona dependiendo de las características del software y se obtiene la lista de defectos y/o cambios a realizar los cuales se clasifican de acuerdo con su gravedad o importancia y así mismo se planifica su solución.

La última de dichas etapas es la de Resultados y Conclusiones- donde se hace un resumen de defectos y cambios a resolver, se aplican las soluciones, también se establece una planificación de seguimiento y se llega a la obtención de resultados. Ver figura #1. (Espinosa 2006) .

Una aseveración general sobre las inspecciones de software puede ser que son una manera para encontrar métodos más efectivos y precisos de desarrollar procesos que a su vez proporcionaran una información o producto de calidad, y a su vez también, que son una herramienta que beneficia al momento del desarrollo de un sistema de información y que garantiza que el producto cumpla con los requisitos y exigencias requeridas.

La garantía de calidad del software es una actividad de protección que se debe aplicar a lo largo de todo el proceso de desarrollo sobre incorporar aspectos de calidad de datos en las fases tempranas del desarrollo, esto permite generar un producto de calidad que, a su vez, suple las necesidades de información de calidad y expectativas del usuario final.

Los modelos y estándares de calidad de software han sido tema de discusión para gran cantidad de autores, dada la trascendencia del tema y el gran despliegue que ha tenido a lo largo de los años. El modelo que aquí se construye recoge amplitud de perspectivas que diversos autores toman con respecto a la valoración de calidad. Aunque hay muchos más, se tratan éstos en particular porque son los de mayor acogida en gran parte de los autores consultados y que cumplen con los criterios de elegibilidad requeridos para el estudio (Caro et al. 2013) .

Los Sres. Moreno, Bolaños y Navia plantean que: “Existen muchos criterios que un modelo de evaluación de calidad debe englobar/contener, y son los que fortalecen cada área al momento del desarrollo de un sistema de información, entre los cuales se puede mencionar los siguientes:

• Disponibilidad: grado en que es posible acceder a la información existente. Se refiere a la facilidad de obtener la información.

1. 1. 1. La información no se encuentra disponible al público en general.

   2. Hay disponibilidad de algunos documentos, pero es limitado el acceso.

   3. Se encuentra información suficiente disponible para ser usada.

• Claridad: Grado en que el modelo es presentado y si posee mecanismos explicativos sobre su uso. Se refiere a que tan sencillo puede ser entender el modelo, influyen factores como: estructura, idioma y presentación del modelo.

1. 1. 1. El modelo no es claro o se dificulta su entendimiento, no posee mecanismos de ayuda sobre el modo de emplearlo.

   2. El modelo es presentado en forma clara, sin embargo, no posee mecanismos de ayuda sobre el modo de emplearlo.

   3. El modelo presenta es presentado en forma clara, posee mecanismos explicativos acerca de su modo de empleo.

• Adaptabilidad: Grado en el que el modelo posee la capacidad de adaptarse a distintas situaciones dependiendo del producto al que se va aplicar.

1. 1. 1. El modelo no es adaptable. Se presenta de forma rígida para su uso.

   2. El modelo puede ser adaptado, pero exige ciertas reglas a seguir.

   3. El modelo permite ser adaptado.

• Completitud: Grado en el que el modelo describe todas sus partes en su totalidad sin dejar por fuera información importante. Un modelo completo se considera que posee descripción de atributos, métricas y mecanismos de ayuda para llegar a la medición.

1. 1. 1. El modelo no menciona toda la información necesaria. Se encuentra incompleto

   2. El modelo describe medianamente sus componentes, sin embargo, deja algunos elementos por fuera. Está incompleto.

   3. El modelo describe todas sus partes. Está completo.

• Área de aplicación: aplicabilidad del modelo a las diferentes áreas de calidad del software.

1. 1. 1. Modelo de proceso, metodología o estándar.

   2. Puede ser modelo de proceso y producto al mismo tiempo.

   3. Modelo para producto software.”

Los criterios antes mencionados hacen referencia a potenciar la calidad en la mayor parte de las áreas de desarrollo y generar un producto que cumpla con los requerimientos necesarios, pero existen otros aspectos que es muy necesario tomar en cuenta, por ejemplo, entre otros, la usabilidad y fiabilidad que, vienen a completar el modelo y a generar información más completa.

Si se considera esto, es necesario crear un modelo que permita evaluar todas las etapas, pre, durante y post desarrollo del sistema de información, por lo que evaluarlo desde su interior y exterior es primordial, obtener la percepción de los usuarios, evaluar los aspectos técnicos desde el punto de vista de los desarrolladores, entre otros aspectos más.

Figura No. 2
Modelo para evaluar la calidad interna y externa
(MORENO et al. 2010)

En modelos como la ISO 9126 se enfatiza realizar dichas evaluaciones, para lo que proponen modelos como el modelo de evaluación de calidad externa-interna (ver fig. No. 2), y un modelo de evaluación de calidad de uso (ver fig. No. 3), (MORENO et al. 2010).

Figura No. 3
Modelo para evaluar la calidad de uso (perspectiva de usuarios)
(MORENO et al. 2010)

Por lo general los modelos existentes presentan dependencias de modelos anteriores y al mismo tiempo influye en los contemporáneos y sucesores. Por lo que, los modelos más actuales tienden a contener a los anteriores por que las áreas de aplicación son finitas, pero la mejora continua de sus atributos genera mejores resultados. Además, la calidad de un producto software está principalmente ligada a la calidad del proceso de desarrollo del mismo.

La calidad del software no se logrará si no existe una garantía en el cumplimiento de las fases o etapas que se han concretado previamente y sin una observación permanente de todo el ciclo de vida del proyecto, lo cual puede lograrse a través de una continua evaluación de la calidad alcanzada en cada etapa del proceso antes de continuar examinándose el grado de cumplimiento de los procedimientos, lineamientos y disposiciones establecidas para un buen proceso de desarrollo. Esta evaluación de la calidad permite realizar las rectificaciones necesarias a cualquier falla encontrada durante el proceso de desarrollo a fin de determinar posibles áreas de mejora. (Acosta-Molina et al. 2011).

Propuesta del instrumento orientado a la evaluación de calidad del software

Métrica V3 propone, en su sitio web, metodologías y guías que permiten la planificación, desarrollo y mantenimiento de sistemas de información, además, una serie de interfaces, técnicas y participantes que se ven involucrados en el desarrollo de un producto de software.

Para el interés y finalidad del artículo se enfatiza en la interfaz “aseguramiento de la calidad”. En esta etapa se proponen procesos para conseguir el desarrollo de un plan de aseguramiento de calidad específico, que se aplicará durante la planificación, desarrollo, implantación y mantenimiento del proyecto haciendo uso de las revisiones periódicas debido a que permiten eliminar defectos lo más pronto posible (cuando son menos costosos de corregir). (Ministerio de Hacienda y secretaría de Estado de Administraciones Públicas 2016) .

A continuación, se plantea una serie de criterios y sus especificaciones que se deben auditar en un sistema de información, para así, “alargar” su vida útil y a su adaptabilidad a las necesidades que genera el día a día.

Para asegurar una calidad completa de un sistema de información no solamente hay que hacer mantenimientos rutinarios post implantación, pues el aseguramiento de la calidad va un poco más allá y para conseguirlo hay que hacer una evaluación en los siguientes criterios propuestos por la ISO 9126-1 (Pedro Luis Alfonzo 2012) :

a) Calidad interna y externa

1: Usabilidad: Capacidad del producto software de ser entendido, aprendido y usado por los usuarios bajo condiciones específicas.

• a) Inteligibilidad: La capacidad que tiene el software para permitir al usuario entender si es adecuado, y dé una manera fácil como ser utilizado para las tareas y las condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la documentación y de las ayudas que el software entrega.

  b) Facilidad de aprendizaje: La forma como el software permite al usuario aprender su uso. También es importante considerar la documentación.

  c) Operabilidad: La manera como el software permite al usuario operarlo y controlarlo.

  d) Atractividad: La presentación del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño gráfico.

  e) Cumplimiento de usabilidad: La capacidad del software de cumplir los estándares o normas relacionadas a su usabilidad.

2: Funcionalidad: Capacidad del producto o software de proporcionar funciones que ejecuten las necesidades explícitas e implícitas de los usuarios cuando el software es usado bajo condiciones específicas.

• a) Precisión: La capacidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada.

  b) Idoneidad: La capacidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario.

  c) Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos.

  d) Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados.

  e) Cumplimiento de funcionabilidad: La capacidad del software de cumplir los estándares referentes a la funcionalidad.

3: Fiabilidad: Capacidad del producto software de mantener un nivel especificado de rendimiento cuando es usado bajo condiciones específicas.

• a) Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra errores. Ejemplo, la forma como el software advierte al usuario cuando realiza operaciones en la unidad de disco vacía, o cuando no encuentra espacio suficiente el disco duro donde esta almacenando los datos, etc.

  b) Tolerancia a fallos: La capacidad que tiene el software para mantener un nivel de funcionamiento en caso de errores.

  c) Capacidad de recuperación: La capacidad que tiene el software para restablecer su funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.

  d) Cumplimiento de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.

4: Eficiencia: Representa la relación entre el grado de rendimiento del sitio y la cantidad de recursos (tiempo, espacio, entre otros) usados bajo ciertas condiciones.

• a) Utilización de los recursos: La capacidad del software para utilizar cantidades y tipos adecuados de recursos cuando este funciona bajo requerimientos o condiciones establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.

  b) Comportamiento en el tiempo: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar el procedimiento más complejo del software y esperar su tiempo de respuesta, realizar la misma función, pero con más cantidad de registros.

  c) Cumplimiento de la eficiencia: La capacidad que tiene el software para cumplir con los estándares o convenciones relacionados a la eficiencia.

5: Mantenimiento: Capacidad del producto software de ser modificado y probado.

• a) Estabilidad: La forma como el software evita efectos inesperados para modificaciones del mismo.

  b) Pruebabilidad: La forma como el software permite realizar pruebas a las modificaciones sin poner el riesgo los datos.

  c) Cambiabilidad: La capacidad del software para que la implementación de una modificación se pueda realizar, incluye también codificación, diseño y documentación de cambios.

  d) Analizabilidad: La forma como el software permite diagnósticos de deficiencias o causas de fallas, o la identificación de partes modificadas.

  e) Cumplimiento de mantenibilidad: La capacidad que tiene el software para cumplir con los estándares de facilidad de mantenimiento.

6: Portabilidad: Capacidad del producto software de ser transferido de un ambiente a otro

• a) Adaptabilidad: Es como el software se adapta a diferentes entornos especificados (hardware o sistemas operativos) sin que implique reacciones negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).

  b) Facilidad de instalación: La facilidad del software para ser instalado en un entorno específico o por el usuario final.

  c) Coexistencia: La capacidad que tiene el software para coexistir con otro o varios softwares, la forma de compartir recursos comunes con otro software o dispositivo.

  d) Intercambiabilidad: La capacidad que tiene el software para ser remplazado por otro software del mismo tipo, y para el mismo objetivo. Ejemplo, el cambio de una nueva versión es importante para el usuario, la propiedad de poder migrar los datos a otro software de diferente proveedor.

  e) Cumplimiento de la portabilidad: La capacidad que tiene el software para cumplir con los estándares relacionados a la portabilidad. (Pedro Luis Alfonzo 2012).

b) Calidad de la información obtenida del sistema de información.

Según lo planteado por las Srtas. Caro, Fuentes y Soto, quienes nos presentan un modelo genérico de calidad de datos, nos plantean que la gestión y mejora de los datos es importante para abordar situaciones como:

• · Adquisición de datos en organizaciones donde la calidad del proceso de producción de datos es desconocido o débil.

  · Existencia de datos defectuosos que contribuyen a generar información insuficiente, que provoca resultados inutilizabas y clientes insatisfechos.

  · Dispersión de datos entre varios propietarios y usuarios. Lo que puede implicar la falta de una visión coherente e integrada, necesaria para garantizar la interoperabilidad y la cooperación.

  · La coexistencia de sistemas heredados con sistemas modernos.

Estas situaciones procedentes de un sistema de información donde los datos cambian con frecuencia y su integración con otros datos es irrelevante, son muy frecuentes ya que muchos aplicativos no son tan flexibles como esperamos por razones como esta es que se plantean una serie de características que toda información obtenida de un sistema de información debe tener, por tanto, dicha información debe ser sometida a pruebas de calidad enfocándose en las siguientes características:

1. 1. 1: Exactitud: El grado en el cual el dato tiene atributos que representan el valor correcto de un concepto o evento en un contexto específico de uso.

   2: Completitud: El grado en el cual el dato asociado a una entidad tiene valores para todos los atributos esperados e instancias de entidad relacionadas, de acuerdo a un contexto específico de uso.

   3: Consistencia: El grado en el cual el dato tiene atributos libres de contradicción y son coherentes con otros datos en un contexto específico de uso.

   4: Credibilidad: El grado en el cual el dato tiene atributos considerados como verdaderos y creíbles por usuarios en un contexto específico de uso.

   5: Actualidad: El grado en el cual el dato tiene los atributos que son del período correcto en un contexto específico de uso.

   6: Accesibilidad: El grado en el cual se puede acceder al dato en un contexto específico de uso.

   7: Conformidad: El grado en el cual el dato tiene atributos que se adhieren a normas, convenciones o regulaciones vigentes y reglas relacionadas con la calidad de datos en un contexto específico de uso.

   8: Confidencialidad: El grado en el cual el dato tiene los atributos que aseguran que éste es sólo accesible e interpretable por usuarios autorizados en un contexto específico de uso.

   9: Eficiencia: El grado en el cual el dato tiene los atributos que pueden ser procesados y proporciona los niveles esperados de funcionamiento (desempeño) usando las cantidades y los tipos de recursos apropiados en un contexto específico de uso.

   10: Precisión: El grado en el cual el dato tiene atributos que son exactos o que proporcionan su discriminación en un contexto específico de uso.

   11: Trazabilidad: El grado en el cual el dato tiene atributos que proporcionan un rastro de auditoría de acceso a los datos y de cualquier cambio hecho a los datos en un contexto específico de uso.

   12: Comprensibilidad: El grado en el cual el dato tiene atributos que le permiten ser leído e interpretado por usuarios, y es expresado en lenguajes apropiados, símbolos y unidades en un contexto específico de uso.

   13: Disponibilidad: El grado en el cual el dato tiene atributos que le permiten ser recuperados por usuarios autorizados y/o aplicaciones en un contexto específico de uso.

   14: Portabilidad: El grado en el cual los datos tienen atributos que les permiten ser instalados, substituidos o movidos de un sistema a otro conservando la calidad existente, en un contexto específico de uso.

   15: Recuperabilidad: El grado en el cual el dato tiene atributos que le permiten mantener y conservar un nivel especificado de operaciones y calidad, aún en caso de falla, en un contexto específico de uso.(Caro et al. 2013).

Para la construcción de las herramientas de medición se consideraron los aspectos mencionados anteriormente, con ellos construimos instrumentos que evalúan perspectivas de acorde a la interacción con el sistema de información, la primera y de mayor importancia es la de los usuarios;

también evaluamos la perspectiva de los desarrolladores y los encargados del mantenimiento y así, poder obtener información más completa acerca de las múltiples perspectivas hacia el sistema de información, su funcionalidad y si cumple los requerimientos para los que fueron creados.

Para poder medir calidad del sistema de información (con los actores ya descritos) decidimos utilizar escalas likert dispuestas de la siguiente forma para cada uno de los criterios mencionados:

Se decidió, evaluar los criterios y agruparlos de acuerdo con las funciones que desempeñan los usuarios y su interacción con el sistema de información de la siguiente manera:

- De los usuarios evaluamos:

• o Usabilidad

  o Funcionalidad

  o Portabilidad

  o Calidad de la información

- De los administradores y encargados de mantenimiento evaluamos:

• o Fiabilidad

  o Eficiencia

  o Mantenimiento

  o Calidad de la información

De manera similar, para la medición de la calidad de la información se dispusieron las siguientes escalas:

Tras unificar las escalas por criterio la tarea pendiente quedó en ponderar cada uno de los elementos que diese respuesta al criterio evaluado, esta ponderación se estimó a través de un panel de expertos a los cuales se les facilitó la bibliografía tomada como base y se solicitó considerar además su experiencia en el campo.

En cuanto al uso de las escalas presentadas (teniendo como objetivo cuestionar a los usuarios, desarrolladores y encargados de mantenimiento) algunos autores consideran el uso de las mismas como evaluaciones subjetivas que conllevan a la obtención de información no precisa (por estar ponderadas con base a criterios personales) sin embargo, muchos otros por el contrario hacen uso de ellas por haberse demostrado fidedignas para adquirir información proveniente de usuarios (y no basarse en pruebas de sistemas de información), quienes por lo general comprenderán de una mejor manera el uso de lenguajes naturales y no el uso de lenguajes técnicos y son quienes hacen uso de los sistemas y de la información por estos generada.

El desarrollo de modelos de calidad aplicables a sistemas de información puede tratarse desde diversas perspectivas. Algunas propuestas existentes abordan generalidades aplicables a diversos dominios, mientras que otras están dirigidas a dominios específicos, como, por ejemplo, a software dirigido a funcionar en la web, otros de forma “empaquetada”, para dispositivos móviles, etc. En fin, cualquier software que se construya sigue líneas y estándares de planificación, desarrollo y mantenimiento, pero en su mayoría presentan problemas de calidad ya sea del software propiamente dicho o de la información que este genera. Estos problemas por concepción general son: la definición de un conjunto de propiedades que indique su calidad; la medición del grado de cumplimiento; y, la utilización de la información disponible respecto al mismo para mejorar su calidad a lo largo del ciclo de vida y así, poder crear software adaptable y que supla las necesidades del medio. (Pedro Luis Alfonzo 2012).

4. RESULTADOS

Instrumento propuesto

Usuarios

Instrumento de medición de la calidad de un sistema de información construido con métrica V3, perspectiva de USUARIOS.

Objetivo: El siguiente instrumento tiene como finalidad obtener la percepción del usuario del sistema de información, y de qué manera éste cumple con las necesidades y requerimientos para los que fue creado.

Instrucciones: Marque con una “X”, en la casilla que lo requiere y llene los espacios en blanco de forma clara, precisa y concisa.

OBSERVACIONES Y SUGERENCIAS: _________________________________________________________________________________

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

NOTA: Toda la información aquí recabada se usará con el único fin de evaluar la calidad del sistema de información y de la información que este proporciona al usuario final, en ningún momento se expondrá la persona que respondió este instrumento.

¡MUCHAS GRACIAS POR

¡SU COLABORACIÓN!

Instrumento propuesto II

Administradores y encargados de mantenimiento del sistema

Instrumento de medición de la calidad de un sistema de información construido con métrica V3, perspectiva administrativa.

Objetivo: El siguiente instrumento tiene como finalidad obtener la percepción del administrador del sistema y del personal encargado de dar mantenimiento al sistema de información, y de qué manera éste cumple con las necesidades y requerimientos para los que fue creado.

Instrucciones: Marque con una “X”, en la casilla que lo requiere y llene los espacios en blanco de forma clara y precisa y concisa.

OBSERVACIONES Y SUGERENCIAS: _____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

NOTA: Toda la información aquí recabada se usará con el único fin de evaluar la calidad del sistema y de la información que este proporciona, en ningún momento se expondrá la persona que respondió este instrumento.

¡MUCHAS GRACIAS POR SU COLABORACIÓN!

Referencias

Aguilar Marvin, Torres Belinda (2014): Criterios Técnicos para Evaluación de la Calidad en Software para m-Learning., noviembre 2014. Disponible en línea en http://ceat-unah.org/archivos/ceat2014/135.pdf.

Caro, Angélica; Fuentes, Alejandra; Soto, M. Antonieta (2013): Desarrollando sistemas de información centrados en la calidad de datos. (Spanish). En: INGENIARE - Revista Chilena de Ingeniería 21 (1), pág. 54–69.

Espinosa, Bexy Alfonso (2006): CONSIDERACIONES RELACIONADAS CON LAS INSPECCIONES DE SOFTWARE. (Spanish). En: Ingenieria Industrial 27 (1), pág. 44–47.

González Palacio, Liliana (2009): MÉTODO PARA GENERAR CASOS DE PRUEBA FUNCIONAL EN EL DESARROLLO DE SOFTWARE. (Spanish). En: Revista Ingenierías Universidad de Medellin 8 (15), pág. 29–36.

González-Sánchez, José-Luis; Montero-Simarro, Francisco; Gutiérrez-Vela, Francisco-Luis (2012): Evolución del concepto de usabilidad como indicador de calidad del software. En: El Profesional de la Informacion 21 (5), pág. 529–536. DOI: 10.3145/epi.2012.sep.13.

Ministerio de Hacienda y secretaría de Estado de Administraciones Públicas (2016): Métrica V3. Interface: Aseguramiento de la calidad. Disponible en línea en http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html#.V-lFvvDhCM8.

MORENO, JORGE JAIR; BOLAÑOS, LILIAM PAOLA; NAVIA, MANUEL ALEJANDRO (2010): EXPLORACIÓN DE MODELOS Y ESTÁNDARES DE CALIDAD PARA EL PRODUCTO SOFTWARE. (Spanish). En: UIS Ingenierías 9 (1), pág. 39–53.

Pedro Luis Alfonzo (2012): Revisión de modelos para evaluar la calidad de productos Web. Experimentación en portales bancarios del NEA. Universidad Nacional de La Plata, Argentina. Disponible en línea en http://sedici.unlp.edu.ar/bitstream/handle/10915/19878/Documento_completo.pdf?sequence=1