Pruebas de software
Propuesta de Requisitos no funcionales para productos de DATAZUCAR a partir de las normas cubanas
RESUMEN
En la actual “era de la información”, el desarrollo de software se ha convertido en un sector esencial para la sociedad. Cuba no está exenta de esta realidad y ya existen varias empresas cuyo objeto social es precisamente el desarrollo de aplicaciones y sistemas informáticos. DATAZUCAR cuenta con un equipo de desarrollo de productos de alto valor agregado y prioriza la entrega a los clientes de productos conformes, minimizando la ocurrencia de errores a partir de la aplicación de pruebas tempranas. La definición de requisitos no funcionales (RNF) comunes que deben cumplir los softwares desarrollados es primordial desde los inicios del desarrollo para lograr la calidad deseada. En este trabajo se realiza una propuesta inicial de propiedades (RNF) a partir de lo definido en la Norma Ramal (NR) 2-1 Requisitos de la Calidad para Sistemas Informáticos y Productos de Software y lo establecido en el proyecto de Norma Cubana la ISO/IEC 25023:2016 Ingeniería de software y sistemas – Requisitos de la Calidad y Evaluación de Software y Sistemas (SQuaRE) – Medición de la calidad de producto de software y sistemas, ambas normas cubanas que homogenizan un modelo de calidad común para todas las entidades del país que desarrollen aplicaciones informáticas.
Palabras claves: Modelo de calidad, requisitos no funcionales, software.
INTRODUCCIÓN
En la actual era de la información, son cada vez más necesarios los productos de software y los sistemas informáticos en todas las esferas sociales como apoyo a su desarrollo. La alta calidad de estos es esencial para proporcionar valor y evitar posibles consecuencias negativas para las partes interesadas.
Teniendo en cuenta que los productos de software y los sistemas informáticos tienen muchas partes involucradas, incluyendo a los que desarrollan, adquieren, manejan o son clientes de las empresas que utilizan estos sistemas, se hace indispensable su especificación completa y la evaluación de la calidad. Esto puede lograrse mediante la definición de las características de la calidad necesarias y deseadas asociadas con las metas y objetivos de las partes interesadas.
Actualmente en Cuba se encuentra en un proceso de aprobación la NC-ISO/IEC 25010:2016 que contiene un modelo de la calidad donde se pueden identificar características de la calidad relevantes que pueden ser empleadas posteriormente para definir los requisitos, con sus medidas de satisfacción correspondientes.
La División DATAZUCAR cuenta con un prestigio entre las empresas de desarrollo de productos de alta calidad y valor agregado por lo que tiene como premisa prevenir la entrega no intencional de productos no conformes a sus clientes y para ello es indispensable garantizar la calidad antes, durante y después del proceso de desarrollo de productos de software y sistemas informáticos.
DESARROLLO
La calidad de un sistema es el grado en que el sistema satisface las necesidades declaradas o implícitas de varias partes interesadas, y por lo tanto proporciona valor. Para ello es necesario definir las características y sub-características que se van a cumplir como propiedades de la calidad.
Los Modelos de la Calidad propuestos por las Normas Internacionales presentan un modelo de la calidad detallado para los sistemas informáticos y productos de software, tanto para su uso mediante un modelo de la calidad, como para los productos mediante un modelo de la calidad del producto. Específicamente el modelo de la calidad del producto se divide en ocho características: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. Cada característica se compone de un conjunto de sub-características relacionadas.
Este modelo de la calidad del producto es útil para especificar los requisitos, establecer medidas y realizar evaluaciones de la calidad. Pueden utilizarse como una lista de control para garantizar un tratamiento integral de los requisitos de la calidad siendo una base para estimar el esfuerzo consecuente y actividades que serán necesarias durante el desarrollo de sistemas. Para su utilización deben ser adaptados según las necesidades de las partes interesadas, especificado las características y sub-características a medir, así como la forma en que serán medidas.
Actualmente en Cuba se cuenta con un Proyecto de norma, elaborado por CALISOFT, revisado y aprobado por el Sub-Comité 7 de Ingeniería de Software (SC7), a la espera de ser entregado al Ministerio de la Informática y las Comunicaciones (MINCOM) para su aprobación como Norma Ramal (NR) 2-1 Requisitos de la Calidad para Sistemas Informáticos y Productos de Software.
Además, se cuenta con un Proyecto de norma en revisión/elaboración por el SC7 para su adopción como Norma Cubana ISO/IEC 25010:2016 Ingeniería de software y sistemas – Requisitos de la Calidad y Evaluación de Software y Sistemas (SQuaRE) –Modelos de la calidad de software y sistemas.
Estas normas establecen características y sub-características mínimas a cumplir por un software o sistema que se desarrolle en Cuba a partir de las características de adecuación funcional, seguridad, usabilidad, eficacia de desempeño y fiabilidad. Teniendo en cuenta esta definición a nivel nacional se realiza esta propuesta para DATAZUCAR teniendo en cuenta las especificidades de la entidad.
Adecuación Funcional: Grado en que un producto o sistema proporciona las
funciones que cumplen las necesidades declaradas o implícitas cuando se utiliza en las condiciones especificadas.
a. Completitud funcional
i. Cada botón/vínculo de la aplicación hace una función.
ii. En el producto o sistema están desarrolladas todas las funcionalidades.
b. Corrección funcional
i. Cada funcionalidad arroja resultados correctos.
ii. Con todas las combinaciones posibles, cada campo está validado
correctamente.
c. Pertinencia funcional
i. El usuario puede completar una funcionalidad realizando el menor número
de pasos posibles.
2. Eficiencia de Desempeño: Desempeño referente a la cantidad de recursos
utilizados bajo determinadas condiciones.
a. Rendimiento
i. Se deben atender las peticiones a la aplicación en un tiempo menor a los 5 segundos.
ii. Se deben atender las peticiones a la BD en un tiempo inferior a los 3 segundos.
b. Utilización de los recursos
i. Se debe garantizar un consumo de CPU y RAM inferior al 80%.
c. Capacidad
i. Se debe asegurar que la cantidad mínima de usuarios conectados concurrentemente sea, en sistemas de alta concurrencia de 4000 usuarios, y en los de baja concurrencia de 500 usuarios.
3. Compatibilidad: Grado en que un producto, sistema o componente puede intercambiar información con otros productos, sistemas o componentes, y/o llevar a cabo sus funciones requeridas, cuando comparten el mismo entorno hardware o software.
a. Coexistencia
i. Grado en que un producto puede llevar a cabo sus funciones requeridas de manera eficiente mientras comparte un entorno común y recursos con otros productos, sin impacto perjudicial sobre estos.
b. Interoperabilidad
i. Grado en el cual dos o más sistemas, productos o componentes pueden intercambiar información y utilizar la información que se ha intercambiado.
4. Usabilidad: Grado en que un producto o sistema puede ser utilizado por usuarios específicos para lograr los objetivos definidos con eficacia, eficiencia y satisfacción en un contexto de uso especificado. a. Reconocibilidad
i. Grado en que un producto o sistema permite al usuario reconocer si el mismo es apropiado para sus necesidades.
b. Cognoscibilidad
i. Grado en que un producto o sistema puede ser utilizado por usuarios específicos para lograr los objetivos de aprendizaje definidos para utilizar el producto o sistema con eficacia, eficiencia, ausencia de riesgo y satisfacción en un contexto de uso especificado.
c. Operabilidad
i. Grado en que un producto o sistema tiene atributos que lo hacen fácil de operar y controlar.
d. Protección ante errores de usuarios
i. Grado en que un sistema protege a los usuarios de cometer errores.
e. Estética de interfaz de usuario
i. Grado en el que una interfaz de usuario permite la interacción agradable y satisfactoria para el usuario.
f. Accesibilidad
i. Grado en que un producto o sistema puede ser utilizado por personas con un amplio rango de características y capacidades para alcanzar un objetivo definido en un contexto de uso especificado.
5. Fiabilidad: Grado en que un sistema, producto o componente realiza funciones especificadas en las condiciones definidas por un período de tiempo determinado. a. Madurez
i. Grado en que un sistema, producto o componente cumple con la fiabilidad requerida en condiciones de operación normales.
b. Disponibilidad
i. Grado en que un sistema, producto o componente está operativo y accesible cuando sea necesario para su uso.
c. Tolerancia ante fallos
i. Grado en que un sistema, producto o componente opera según lo previsto independientemente de la presencia de fallos en el hardware o software.
d. Recuperabilidad
i. Grado en el cual un producto o sistema puede recuperar los datos directamente afectados y restablecer el estado deseado, cuando ocurre una interrupción o una falla.
6. Seguridad: Grado en que un producto o sistema protege la información y los datos para que otros productos o sistemas tengan la capacidad de acceso de datos apropiada según sus tipos y niveles de autorización. a. Confidencialidad
i. Grado en que un producto o sistema permite que los datos sean accesibles solo por las personas autorizadas.
b. Integridad
i. Grado en el que un sistema, producto o componente impide el acceso no autorizado, o la modificación de programas o datos.
c. No rechazo
i. Grado en el que las acciones o eventos pueden probarse que han tenido lugar para que posteriormente no sean negadas.
d. Responsabilidad
i. Grado en el que las acciones de una entidad pueden atribuirse únicamente a esta.
e. Autenticidad
i. Grado en el que la identidad de un sujeto o recursos pueden probar ser quien dicen ser.
7. Mantenibilidad: Grado de eficacia y eficiencia con que un producto o sistema puede ser modificado por los mantenedores destinados. a. Modularidad
i. Grado en el que un sistema o programa de computadora está integrado por componentes individuales de tal manera que un cambio en uno de estos tiene un impacto mínimo en los otros componentes.
b. Reusabilidad
i. Grado en que un activo puede utilizarse en más de un sistema o en la construcción de otros activos.
c. Analizabilidad
i. Grado de eficacia y eficiencia con el que es posible evaluar el impacto de un cambio intencionado sobre una o más de sus partes de un producto o sistema, o para diagnosticar deficiencias o causas de las fallas en un producto, o identificar las partes a modificarse.
d. Modificabilidad
i. Grado en que un producto o sistema puede ser modificado de forma eficaz y eficiente sin introducir defectos o degradar la calidad del producto existente.
e. Testabilidad
i. Grado de eficacia y eficiencia con la que los criterios de prueba se pueden establecer para un sistema, producto o componente y determinar si se han cumplido los criterios.
8. Portabilidad: Grado de eficacia y eficiencia con que un sistema, producto o componente pueden ser transferidos de un hardware, software o entorno (operativo o de uso) a otro.
a. Adaptabilidad
i. Grado en que un producto o sistema puede ser adaptado de forma eficaz y eficiente para diferentes hardware o software en evolución, u otros entornos operativos o de uso.
b. Instalabilidad
i. Grado de eficacia y eficiencia con la que un producto o sistema puede ser instalado y/o desinstalado con éxito en un entorno específico.
c. Reemplazabilidad
i. Grado en que un producto puede sustituir a otro producto de software específico para el mismo propósito en el mismo entorno.
1. Adecuación Funcional
1.1 Completitud funcional
R1.1.1 Garantizar que cada botón/vínculo de la aplicación haga una función. R1.1.2 Garantizar que en el producto o sistema estén desarrolladas todas las funcionalidades.
1.2 Corrección funcional
R1.2.1 Garantizar que cada funcionalidad arroje resultados correctos.
R1.2.2 Garantizar con todas las combinaciones posibles, que cada campo esté validado correctamente.
1.3 Pertinencia funcional
R1.3.1 Garantizar que el usuario sólo se presenta con los pasos necesarios para completar una tarea, con exclusión de los pasos innecesarios.
2. Eficiencia de Desempeño
2.1 Rendimiento
R2.1.1 Atender las peticiones en un tiempo menor a los 5 segundos.
R2.1.2 Atender las peticiones a la BD en un tiempo inferior a los 3 segundos.
2.2 Utilización de los recursos
R2.2.1 Garantizar un consumo de CPU y RAM inferior al 80%.
2.3 Capacidad
R2.3.1 Asegurar que la cantidad mínima de usuarios conectados concurrentemente sea, en sistemas de alta concurrencia de 4000 usuarios, y en los de baja concurrencia de 500 usuarios.
3. Compatibilidad
3.1 Coexistencia
R3.1.1 Coexistir compartiendo un entorno común y recursos con otros productos llevando a cabo sus funciones requeridas sin impactar perjudicialmente a estos.
3.2 Interoperabilidad
R3.2.1 Intercambiar información con otros sistemas, productos o componentes a través de protocolos de interoperabilidad y utilizar la información intercambiada.
4. Usabilidad
4.1 Reconocibilidad
R4.1.1 Emplear un lenguaje que sea más cercano al utilizado por el usuario final que al informático o técnico.
R4.1.2 Colocar títulos a las páginas, tablas, imágenes, etc. que sean descriptivos y distintivos.
R4.1.3 Establecer de manera clara quiénes son los responsables del sistema.
R4.1.4 Brindar información de contacto relacionada con el equipo de soporte. R4.1.5 Garantizar que los contenidos publicados se ajustan al perfil temático definido.
Productos o sistemas para la Web:
R4.1.6 Reflejar la identidad del producto, sistema, empresa (logo, compañía).
R4.1.7 Comenzar cada pantalla con un título que describa su contenido.
R4.1.8 Utilizar iconos que identifiquen claramente lo que representan.
R4.1.9 Proporcionar información sobre los autores, referencias, fecha de publicación, etc. en los artículos, noticias, etc. publicados.
4.2 Cognoscibilidad
R4.2.1 Ofrecer una navegación sencilla para que los usuarios sin mucha experiencia puedan hacer uso del sistema.
R4.2.2 Emplear nombres estandarizados para las categorías de la navegación y las funcionalidades.
R4.2.3 Mantener constante la distribución y ubicación de los elementos estructurales que contienen las páginas o ventanas.
R4.2.4 Mantener la información organizada con categorías lógicas, fácilmente memorizables por el usuario.
R4.2.5 Mantener similitud entre tareas, diálogos y formularios.
R4.2.6 Utilizar aceleradores o accesos rápidos a operaciones frecuentes.
R4.2.7 Utilizar nombres adecuados de los botones de los formularios dependiendo de la acción que realiza.
R4.2.8 Mostrar los mensajes de error en texto plano entendibles para los usuarios. R4.2.9 Utilizar nombres en los enlaces iguales que los títulos de las páginas a las que dirigen.
Productos o sistemas para la Web:
R4.2.10 Usar una URL, clara y fácil de recordar.
R4.2.11 Diferenciar de manera clara los enlaces internos de los externos.
4.3 Operabilidad
R4.3.1 Distinguir de manera clara en los formularios los campos “requeridos” y
“opcionales”.
R4.3.2 Establecer el tamaño de las cajas de texto para introducir información en función del tamaño del dato que se va a escribir.
R4.3.3 Establecer en cada página o ventana puntos de salida que permita al usuario abandonar la tarea actual que se encuentra realizando (utilización de opciones cancelar, cerrar, etc.).
R4.3.4 Brindar la posibilidad de volver a pasos anteriores para modificar los datos en un proceso que lo requiera.
R4.3.5 Mostrar un cambio visible cuando el cursor está apuntando a un elemento de acción.
R4.3.6 Utilizar tipos y tamaños de fuente legibles.
R4.3.7 Definir como máximo entre 80 y 100 caracteres para la longitud de línea de los bloques de texto.
R4.3.8 Dividir en párrafos de un máximo de entre 5 y 8 líneas de longitud los bloques de texto de gran tamaño.
R4.3.9 Resaltar los enlaces del menú cuando se seleccionan.
R4.3.10 Dejar espacio entre los elementos de acción.
R4.3.11 Posicionar el cursor en el primer campo donde se introduce dato. R4.3.12 Proporcionar información y pedir confirmación cuando una acción tiene consecuencias.
R4.3. 13 Proveer una clara retroalimentación cuando una tarea ha sido completada exitosamente.
R4.3.14 Señalar los campos que contienen datos inválidos y ofrecer información que ilustre el error cometido.
R4.3.15 No presentar enlaces internos rotos o que no lleven a ninguna ventana.
R4.3.16 No presentar enlaces externos que no existan.
R4.3.17 Implementar validaciones antes de que el usuario envíe información.
R4.3.18 Definir de manera correcta gráficos y tablas utilizando sus atributos.
Productos o sistemas para la Web:
R4.3.19 Mostrar accesos desde la página de inicio a las partes o secciones más importantes del sitio.
R4.3.20 Garantizar la compatibilidad con los navegadores: Mozilla Firefox, Google Chrome, Opera e Internet Explorer en los casos que sea necesario.
R4.3.21 Identificar los enlaces para que sean distinguibles sin necesidad de pasar el mouse por encima.
R4.3.22 Utilizar texto para los enlaces.
R4.3.23 Contar con un buscador que aparezca en una zona visible y en todas las páginas.
R4.3.24 Ubicar un acceso a la página de inicio en una zona visible, reconocible y en todas las páginas.
R4.3.25 Garantizar la visualización correcta los contenidos multimedia.
R4.3.26 Utilizar de manera moderada las animaciones y efectos en movimiento constantes.
R4.3.27 Permitir la navegación en el sitio sin necesidad del desplazamiento horizontal.
R4.3.28 Cumplir con estándares de código HTML y CSS, definido por el W3C.
R4.3.29 Utilizar un tamaño de fuente igual o superior a los 14 px para los contenidos.
R4.3.30 Definir los metadatos necesarios.
R4.3.31 Informar al usuario de los programas de software adicionales requeridos. R4.3.32 Permitir visualizar las páginas de impresión del contenido sin perder información.
R4.3.33 Informar en los mensajes de error cuáles son las acciones correctoras. R4.3.34 Garantizar una interfaz adaptable a los dispositivos para los que se haya desarrollado el sitio.
R4.3.35 Alinear el texto a la izquierda.
Para artefactos de tipo Sistemas de Gestión:
R4.3.36 Permitir que el usuario sepa en qué parte de la estructura se encuentra.
Para artefactos de tipo Aplicaciones de Escritorio:
R4.3.37 Mostrar la opción de ayuda ligada a las funciones que se ofrecen, durante la interacción con la aplicación.
R4.3.38 Garantizar que los elementos que componen la interfaz estén en el idioma seleccionado.
4.4 Protección ante errores de usuarios
R4.4.1 Mostrar indicaciones para completar los campos problemáticos en los formularios.
R4.4.2 Emplear opciones por defecto en los formularios, siempre que sea posible. R4.4.3 Brindar la posibilidad de seleccionar la información de una lista en situaciones donde se pueden producir errores de escritura.
R4.4.4 Informar al usuario cuando se intenta salir o cerrar una ventana en la que hay trabajo sin guardar.
4.5 Estética de interfaz de usuario
R4.5.1 Diferenciar un icono seleccionado de los no seleccionados.
R4.5.2 Utilizar íconos que sean conceptualmente distintos pero que mantengan la armonía entre ellos.
R4.5.3 Mantener una tipografía coherente en toda la aplicación.
R4.5.4 Establecer niveles de importancia de los contenidos.
R4.5.5 Utilizar los estilos (negritas, cursivas, etc.) con moderación.
R4.5.6 Mostrar los elementos del diseño correctamente alineados y agrupados.
R4.5.7 Mostrar el menú en un lugar destacado.
R4.5.8 Centrar o justificar a la izquierda los títulos del menú.
R4.5.9 Mantener la consistencia entre las etiquetas de los campos.
R4.5.10 Garantizar que las imágenes, gráficos, tablas, etc. utilizadas tengan buena resolución.
R4.5.11 Garantizar que no existan errores ortográficos.
Productos o sistemas para la Web:
R4.5.12 Personalizar las páginas de error.
R4.5.13 Mostrar el logo de la organización en el mismo lugar en todas las páginas del sitio.
R4.5.14 Mostrar sin problemas la presentación y composición de las páginas en los navegadores Mozilla Firefox, Google Chrome, Opera, Internet Explorer.
R4.5.15 Mostar sin problemas la presentación y composición de las páginas en las diferentes resoluciones de pantalla para las que fue concebido.
Para artefactos de tipo Aplicación de Escritorio:
R4.5.16 Contener un símbolo distinguible en la parte derecha de los elementos de los menús que llevan a abrir un submenú.
R4.5.17 Mantener el tamaño de las ventanas apropiado para los elementos que agrupa.
R4.5.18 Garantizar que no existan errores de redacción.
4.6 Accesibilidad
R4.6.1 Garantizar un correcto contraste de color entre el texto y el fondo.
R4.6.2 Disponer sin color la información que esté transmitida a través de colores. R4.6.3 Proporcionar textos aclaratorios sobre imágenes de forma que puedan ser comprendidas por cualquier persona independientemente de la discapacidad poseída.
R4.6.4 Identificar el cambio de idioma en los textos.
R4.6.5 Proporcionar texto alternativo para elementos no textuales.
R4.6.6 Subtitular los elementos multimedia en los sistemas diseñados para la web siempre que sea posible. Productos o sistemas para la Web:
R4.6.7 Declarar el atributo lenguaje de las páginas para mejorar la pronunciación de los lectores de pantalla.
5. Fiabilidad
5.1 Madurez
R5.1.1 Mostrar personalizados los mensajes provenientes de las excepciones y/o errores que puedan ocurrir.
R5.1.2 Controlar la introducción de valores inválidos.
R5.1.3 Informar y actuar ante la caducidad de sesiones por inactividad o por cambio de permiso.
5.2 Disponibilidad
R5.2.1 No permitir ataques de DoS (El fin de los ataques DoS es intentar bloquear sitios web e infiltrarse en ellos mediante la inundación del servidor de origen del sitio con solicitudes falsas, el tráfico de este ataque DoS puede producir resultados que van desde lentitud en la carga de las páginas hasta un bloqueo completo del tráfico legítimo al sitio).
R5.2.2 No presentar fallos de segmentación, o que se sobrescriban direcciones de memoria adyacentes. De igual manera validar el tamaño de entrada de los campos.
Para artefactos de tipo Portal Web y Sistema de Gestión R5.2.3 Realizar respaldo automático a las BBDD.
R5.2.4 Garantizar la ejecución automatizada de los servicios y aplicaciones necesarios para una ejecución satisfactoria.
5.3 Tolerancia ante fallos
R5.3.1 Contener los errores producidos en las BBDD.
R5.3.2 Proteger la información del sistema ante la pérdida de alimentación eléctrica o conexión de red, durante su procesamiento.
R5.3.3 Detectar la completitud de la réplica de las BBDD, en caso de que el sistema incluya la replicación de datos.
R5.3.4 Evitar un fallo total cuando la concurrencia de usuarios supera la capacidad de respuesta.
R5.3.5 Manejar los errores de manera tal que no afecten el funcionamiento general. 5.4 Recuperabilidad
R5.4.1 Existir mecanismos que posibiliten el regreso a un punto estable, después de la ocurrencia de un fallo de cualquier tipo.
6. Seguridad
6.1 Confidencialidad
R6.1.1 Proteger mediante protocolo seguro (SSL, TLS, etc.), o mediante mecanismos de encriptación, todas las conexiones autenticadas o que involucran funciones o datos sensibles, incluidas aquellas a otros componentes como los de backend.
R6.1.2 Proteger y preservar la información sensible (información personal privada, información propia del negocio).
R6.1.3 No mostrar mensajes con información que ayude a recopilar información sobre el producto o las configuraciones del servidor.
R6.1.4 No mostrar referencias hacia objetos internos de la aplicación.
R6.1.5 Controlar el receptor de escucha de las BBDD.
R6.1.6 No contener archivos innecesarios que sean creados como consecuencia de editar archivos de la aplicación, tras crear copias de seguridad, o al dejar en el árbol de directorio archivos antiguos o sin referencias.
R6.1.7 Habilitar solamente los métodos HTTP que sean necesarios, poseer la configuración más segura y evaluar la ausencia de configuración por defecto.
6.2 Integridad
R6.2.1 No permitir ataques XSS (Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web).
R6.2.2 No permitir ataques CSRF (Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, incluyendo la sesión del usuario y cualquier otra información incluida automáticamente a una aplicación web vulnerable. Esto le permite a un atacante generar peticiones sobre una aplicación vulnerable sin la autorización apropiada).
R6.2.3 No permitir inyecciones (SQL, LDAP, SSI, Xpath, NoSQL, etc.). (Las fallas de Inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete en ejecutar comandos no intencionados o acceder a datos no autorizados).
R6.2.4 No permitir subir archivos distintos al esperado, o en una ruta totalmente diferente.
6.3 No rechazo
R6.3.1 Garantizar la trazabilidad.
6.4 Responsabilidad
R6.4.1 Garantizar asignación a nivel de acciones.
6.5 Autenticidad
R6.5.1 Existir un mecanismo de autenticación personalizado para todos los usuarios del sistema, independientemente del rol que tengan.
R6.5.2 No usar cuentas suministradas por defecto.
R6.5.3 No permitir que se realicen ataques para recuperar cuentas de usuarios válidas (fuerza bruta).
R6.5.4 No permitir la creación de contraseñas débiles. Las contraseñas deben tener la combinación de letras, caracteres especiales y números sin un significado evidente, con una longitud mínima de 6 caracteres.
R6.5.5 Ofrecer la posibilidad de que el usuario pueda cambiar su contraseña. R6.5.6 Controlar el historial de las contraseñas con vistas a que el usuario no repita contraseñas utilizadas con anterioridad.
R6.5.7 Controlar el ciclo de vida de las contraseñas.
R6.5.8 Cerrar automáticamente la sesión de un usuario cuando ha estado inactivo durante un cierto lapso de tiempo.
R6.5.9 Destruir el ID de sesión luego de salir o cerrar el sistema.
R6.5.10 No exponer los identificadores de sesión, los mismos deben estar cifrados independientemente del tratamiento que se le dé al transporte de los datos. R6.5.11 Evitar la accesibilidad o control por usuarios sin autorización a los ficheros o directorios que se encuentran fuera del directorio web raíz.
R6.5.12 Evitar que un usuario estándar (no administrador) modifique sus privilegios en la aplicación o los de otro usuario con su mismo rol.
R6.5.13 Actualizar inmediatamente la gestión que se realice sobre los usuarios (incluyendo roles y permisos).
7. Mantenibilidad
7.1 Modularidad
R7.1.1 Desarrollar modularmente mediante el uso de componentes individuales.
7.2 Reusabilidad
R7.2.1 Desarrollar componentes reutilizables en varios sistemas o en otros componentes.
7.3 Analizabilidad
R7.3.1 Analizar el impacto de los cambios para diagnosticar deficiencias o causas de fallas, o identificar otras partes a modificarse.
7.4 Modificabilidad
R7.4.1 Modificar sin introducir defectos o degradar la calidad del producto existente.
7.5 Testabilidad
R7.5.1 Establecer criterios de prueba medibles.
R7.5.2 Verificar los criterios de prueba establecidos.
8. Portabilidad
8.1 Adaptabilidad
R8.1.1 Adaptar el producto o sistema para diferentes hardware o software u otros entornos operativos o de uso.
8.2 Instalabilidad
R8.2.1 Crear instaladores y desintaladores de los producto o sistema en un entorno específico establecido. R8.2.2 Reemplazabilidad
R8.3.1 Reemplazar a otro producto de software específico para el mismo propósito en el mismo entorno.
VALORACIÓN ECONÓMICA Y APORTE SOCIAL
Utilizando la propuesta de RNF de la calidad definidos en la presente investigación en el desarrollo de las aplicaciones informáticas de la entidad, se garantizaría, desde etapas tempranas de desarrollo, la mayoría de las propiedades de los modelos de calidad establecidos para esta actividad. Esta definición de RNF se puede emplear igualmente como lista de chequeo tanto para los desarrolladores como para los probadores, teniendo una guía de medición de las características y sub-características del modelo de calidad definido, ahorrando costes de tiempo para los equipos de desarrollo. Si los requisitos de la calidad del software no están claramente definidos, pueden verse, interpretarse, implementarse y evaluarse de manera diferente por distintas personas. Esto puede resultar en un software incompatible con las expectativas del usuario y de mala calidad; usuarios, clientes y desarrolladores insatisfechos y aumenta el tiempo y el costo al rehacer el software.
CONCLUSIONES
En un mundo como el actual, el desarrollo de productos de software de alta calidad es un tema de primera importancia, un software que no funciona correctamente puede dar lugar a muchos problemas, incluyendo pérdida de dinero, tiempo, daños personales o incluso la muerte.
Es por ello que el Software debe ser probado rigurosamente en la búsqueda de defectos desde etapas tempranas, mientras más se demore encontrar los mismos, pueden convertirse en un altísimo costo para las empresas desarrolladoras. Existen modelos de referencia que están enfocados a la calidad del producto, la norma NC ISO/IEC 25010:2016, define un modelo de calidad del producto compuesto por ocho características (que se subdividen en sub-características), que es aplicable tanto a sistemas informáticos como a productos de software. Así mismo, la NC ISO/IEC 25010:2016 define que existe relación de las características y sub-características con propiedades medibles que deben cumplir los sistemas informáticos y productos de software, las mismas, deben definirse para poder evaluar la calidad de los mismos.
Para empresas de desarrollo de software como lo es DATAZUCAR es imprescindible contar con la definición de las propiedades medibles a partir de las cuales podrán ser evaluados sus productos garantizando la calidad de los mismos desde los inicios de su desarrollo hasta la entrega a los clientes finales y su posterior mantenimiento en el tiempo.
RECOMENDACIONES
Al iniciar nuevos desarrollos es necesario contar con una guía de propiedades generales que debe cumplir todo producto de software basada en las normas vigentes en el país. Se recomienda utilizar este listado de requisitos no funcionales agrupados por características y sub- características del modelo de calidad vigente.
Medir, mediante la ejecución de pruebas, el cumplimiento y aplicación de estos requisitos en un determinado producto debe ser una prioridad, ya que su sola definición no garantiza su correcta implementación. Para futuras investigaciones se recomienda identificar herramientas automatizadas que se puedan utilizar para validar estas propiedades.
Se recomienda además continuar ajustando este listado de requisitos según las características de los nuevos proyectos y las nuevas tecnologías que se utilicen en el desarrollo de aplicaciones.
TÉRMINOS Y DEFINICIONES
Producto de software: Un conjunto de programas informáticos, procedimientos y, posiblemente, documentación y datos asociados.
Característica de la calidad del software: Categoría de los atributos que conlleva a la calidad del software.
Modelo de la calidad: Definido como un conjunto de características y las relaciones entre ellas, que proporciona un marco para la especificación de requisitos de la calidad y su evaluación.
Calidad del software: Grado en que un producto de software satisface las necesidades declaradas e implícitas cuando se utiliza en condiciones especificadas.
Requisito de la calidad del software: Requisito de que un atributo de la calidad del software esté presente en el software.
BIBLIOGRAFÍA
[1] NC ISO/IEC 25010:2016 Ingeniería de Software y Sistemas – Requisitos de la Calidad
y Evaluación de Software (SquaRe) – Modelos de la Calidad de Software y Sistemas.
[2] NRCM 2-1:2016 Requisitos de calidad para sistemas informáticos y productos de
software.
[3] NC ISO/IEC 25030:2017 Ingeniería de Software – Requisitos de la Calidad y Evaluación
de Productos de Software (SquaRe) – Requisitos de la Calidad.
