La calidad del software: ¿cómo se determinan los requisitos?

Su cliente quiere una nueva aplicación de software y usted ha anotado todos los requisitos funcionales. Ya sabes lo que debe hacer la aplicación. Pero, ¿sabe también qué tan precisa debe ser la aplicación y qué espera su cliente en términos de facilidad de aprendizaje e instalación? También se deben documentar los requisitos no funcionales, de lo contrario surgen malentendidos. Una guía útil es la norma ISO 9126 para la calidad del software.

Cuando hable con su cliente, probablemente prestará mayor atención a los requisitos funcionales; así suele ser. Pero el cliente también tiene ciertas expectativas en otros ámbitos. Es mejor preguntar explícitamente sobre esto, de lo contrario quedarán deseos tácitos. Si después resulta que la aplicación no cumple con las expectativas implícitas del cliente, se produce una pelea. Ambas partes se benefician de requisitos claros, explícitos, inequívocos y mensurables.

ISO (Organización Internacional de Normalización) es una organización no gubernamental que reúne institutos de normalización de 158 países. La secretaría central está ubicada en Ginebra, Suiza. La norma ISO 9126 describe atributos generales de calidad que los fabricantes de software deben tener en cuenta. El estándar no dice cuál es el nivel que debe alcanzar el software para esos diversos atributos, pero forma una lista de verificación útil. Tampoco existe ningún certificado para esta norma.

El estándar consta de cuatro partes: modelo de calidad, métricas externas, métricas internas y métricas de calidad en uso. La Parte 1 de esta norma (ISO 9126-1) describe un modelo de calidad que se puede aplicar a productos de software. Este modelo de calidad define una serie de cualidades, o atributos de calidad, divididos en seis categorías.

– funcionalidad (funcionalidad)
– fiabilidad
– usabilidad
– eficiencia (eficiencia)
– mantenibilidad
– portabilidad
Los miramos uno por uno.

FUNCIONALIDAD
La aplicación debe hacer todo lo que el usuario necesita. ¿Pero qué es todo? ¿Qué características debe contener la aplicación? ¿Cómo debería funcionar exactamente?

El futuro usuario con el que está hablando se basa en su experiencia personal con el software. Por ejemplo, si trabajó con una aplicación de software que validaba cada número de IVA ingresado, cree que esto es una parte estándar de la “inteligencia” de las computadoras y es posible que no lo indique explícitamente como un requisito para la nueva aplicación.

Otras preguntas. ¿Qué tan precisa debe ser la solicitud? ¿Debería interactuar con otras aplicaciones? ¿Qué se necesita para eso? ¿Existen ciertos acuerdos de convenciones, estándares, regulaciones, leyes, etc. que deben cumplirse?

No debe ser posible que una persona no autorizada utilice el software o los datos. ¿Cuáles son los requisitos de seguridad?

FIABILIDAD
La aplicación nunca debería fallar. Bueno, sí, pero no por mucho tiempo. ¿Cuánto tiempo puede estar fuera de uso antes de que su cliente sufra un inconveniente?

Si se trata de una aplicación de facturación, puede que no sea un problema si está fuera de servicio durante dos días. Sin embargo, si se trata de una aplicación que forma parte de una cadena de producción de periódicos, una interrupción de menos de una hora puede significar que el plazo de la imprenta no se cumpla: un desastre.

¿Qué debería pasar después del reinicio? ¿Es necesario recuperar datos? Si alguien comete un error, el software fallará. ¿O eso no está permitido? ¿Qué errores se deben detectar? ¿Qué pasa si una parte del software falla?

USABILIDAD
El software debe ser fácil de usar. ¿Qué tan fácil de usar? ¿Qué esperan los usuarios de este software a ese respecto?

Algunos usuarios escriben muchos datos. Odian tener que soltar el teclado y verse obligados a usar el mouse. En ese caso, es mejor proporcionar un comando alternativo en la interfaz de usuario para cada comando del mouse que se da con el teclado.

El software debe ser fácil de aprender. ¿Pero qué es fácil? ¿Sin manuales? ¿Con manual, pero sin curso? Lo mejor es especificar esto. El software también se construyó sobre la base de ciertos conceptos. El futuro usuario debe poder entenderlo. ¿Cómo debería hacerse eso?

El usuario debe poder manejar la aplicación fácilmente. Si sabe lo que quiere, debería poder poner su idea en práctica rápidamente. ¿Qué tan suavemente?

EFICIENCIA
El software debe ser eficiente. ¿Pero qué tan eficiente? Dependiendo del entorno, los requisitos pueden variar ampliamente. ¿Qué tan rápido debe responder el programa a la entrada del usuario? ¿Cuánto tiempo debería tardar el procesamiento por lotes? ¿Qué es bueno, qué es aceptable y qué es malo? Si el cliente no lo especifica, hay que adivinar.

Si el usuario de la aplicación tiene un cliente en la línea, o frente a él en la tienda, tanto el cliente como el personal pierden tiempo esperando una respuesta de la aplicación. Si la aplicación funciona con servicios, lo mejor es acordar el rendimiento esperado de forma mensurable. Porque la arquitectura tiene que adaptarse a las necesidades, lo que repercute en el coste del proyecto.

¿Qué espera su cliente en términos de comportamiento de los recursos? ¿Qué debería poder manejar la base de datos, la memoria y el disco?

MANTENIMIENTO
Su cliente planea utilizar el software durante mucho tiempo. Los requisitos cambiarán, por lo que la aplicación debe poder cambiar. ¿Cuáles son los requisitos de mantenibilidad? Si hay un problema en el futuro, el programador actual debería poder encontrar el lugar en la aplicación donde salió mal; la depuración debe ser posible, los mensajes de error deben ser posibles. Un pequeño cambio puede requerir sólo un pequeño esfuerzo.

Si un cambio cuesta demasiado tiempo y por tanto dinero, ya no merece la pena el esfuerzo. Y también debe ser posible realizar pruebas. Si el programa no ha sido probado, no funcionará.

El ejemplo más claro en este ámbito es el problema del año 2000. Los programadores buscaban los campos de fecha en los programas para modificarlos. Si no los encontraban, no podían cambiar los programas y toda la aplicación tuvo que ser descartada porque no era mantenible.

Este problema se puede evitar utilizando estándares de programación, reglas para la estructura de los programas y el nombre de las variables.

PORTABILIDAD / PORTABILIDAD
Quizás la aplicación termine en una plataforma diferente en el futuro. Eso debería ser posible. ¿O no? Si su gente desarrolla en Java, espera poder transferir la aplicación terminada a otro entorno sin mucho esfuerzo. Se supone que la máquina virtual Java maneja las diferencias. Sin embargo, esto no siempre es tan sencillo.

¿Cuánto esfuerzo debería llevar instalar el software en un entorno particular? ¿Existen requisitos estrictos en esta área? ¿Existen estándares, convenciones o acuerdos con respecto a la portabilidad del software que deban cumplirse? ¿Qué tan reemplazable debería ser su software? Es posible que la interfaz de su aplicación deba cumplir ciertos estándares. ¿Cuál es la adaptabilidad de su software? ¿Su cliente espera una aplicación que pueda personalizarse mediante el establecimiento de parámetros? ¿Su cliente quiere que sus programadores modifiquen la aplicación?

DIFERENTE ENTORNO, DIFERENTES REQUISITOS
Diferentes clientes tienen diferentes expectativas; diferentes sectores tienen diferentes estándares. Algunos ejemplos:

– La precisión y el comportamiento en el tiempo son decisivos para el software de cálculo y simulación. Este también es el caso de muchas máquinas.
horas.

– En las aplicaciones integradas para consumidores, además de la usabilidad, son importantes aspectos como la recuperabilidad y la eficiencia. Dado que estos productos a menudo tienen que conformarse con una potencia informática y una capacidad energética limitadas, el comportamiento en relación con los recursos utilizados recibe especial atención.

– Los desarrolladores de un terminal bancario prestarán mucha atención a los aspectos de fiabilidad y usabilidad. La legislación nacional también puede exigir el cumplimiento de determinadas directrices, normas y leyes.

– La precisión es de gran importancia para los sistemas críticos para el negocio, pero también lo son la estabilidad y el comportamiento temporal. El software utilizado en un centro de llamadas debe permitir al operador manejar tantas llamadas como sea posible. Un error como un orden de pestañas incorrecto en la interfaz de usuario puede causar pérdida de tiempo y costar dinero. Por eso la usabilidad también es un factor importante aquí.

– Una aplicación B2B ofrece una o más interfaces con las que las aplicaciones externas pueden interactuar con la aplicación B2B. Dado que esas aplicaciones son creadas por diferentes proveedores, el cumplimiento de los estándares de interfaz, la interoperabilidad y la resistencia a errores desempeñarán un papel importante.

Si se quiere tener un cliente satisfecho al final del proceso de desarrollo, lo mejor es prestar suficiente atención a todos los requisitos, no sólo a los funcionales, sino también a los no funcionales. Es necesario determinar qué aspectos de calidad son importantes para su aplicación de software y qué tan estrictos son los requisitos de su cliente. Dadas las implicaciones del tiempo de desarrollo y el precio, no pase por alto esto.

Christiane Vandepitte es consultora independiente.
Este artículo se basa en gran medida en artículos que aparecieron en Agoria Online y en WTCM.
Tecnilina.