Por Edson Calle

INTRODUCCIÓN

El objetivo primordial de la ingeniería de software es producir un sistema, aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros del software deben aplicar métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo de software. Además un buen ingeniero de software debe medir si la alta calidad se lleva a cabo. [PRES98]
 

La calidad de un sistema, aplicación o producto es tan bueno como los requisitos que describen el problema, el diseño que modela la solución, el código que conduce a un programa ejecutable y las pruebas que ejercitan el software para detectar errores. Un buen ingeniero de software utiliza mediciones que evalúan la calidad del análisis y los modelos del diseño, el código fuente y los casos de prueba que se han creado al aplicar la ingeniería del software. Para lograr esta evaluación de calidad, el ingeniero debe utilizar medidas técnicas que evalúan la calidad con objetividad, no con subjetividad.
 
 

La mayoría de los desarrolladores de software todavía no miden, por desgracia, la mayoría no desean ni comenzar. El problema es cultural. En un intento por recopilar medidas en donde no se haya recopilado nada anteriormente, a menudo se opone resistencia: “¿Por qué necesitamos hacer esto?”, se pregunta un gestor de proyectos agobiado. “No entiendo por qué”, se queja un profesional saturado de trabajo.
 

¿Por qué es tan importante medir el proceso de ingeniería de software y el producto (software) que produce? La respuesta es relativamente obvia. Si no se mide no hay una forma real de determinar si se está mejorando. Y si no se está mejorando se está perdido.
 
 

CALIDAD

El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto existen distintas respuestas, tales como se muestra a continuación:
El American Heritage Dictionary [PRES98] define la calidad como “Una característica o atributo de algo.”
La definición estándar de calidad en ISO-8402 es “La totalidad de rasgos y características de un producto, proceso o servicio que sostiene la habilidad de satisfacer estados o necesidades implícitas”

“Concordar explícitamente al estado funcional y a los requerimientos del funcionamiento, explícitamente a los estándares de documentación de desarrollo, e implícitamente características que son expectativas de todos los desarrolladores profesionales de software”.
 

En el desarrollo del software, la calidad de diseño acompaña a los requisitos, especificaciones, y el diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación. Si la implementación sigue al diseño, y el sistema resultante cumple los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
 
 

GARANTÍA (ASEGURAMIENTO) DE CALIDAD DE SOFTWARE

La garantía de calidad del software (SQA, de Software Quality Assurance) es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software.
Pressman [PRES98] define la calidad de software como:
Concordancia con los requisitos funcionales y el 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.
 

Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
Existe un conjunto de requisitos implícitos que a menudo no se mencionan (p. ej.: el deseo de un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pera falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.
 

MÉTRICAS DE LA CALIDAD DE ESPECIFICACIÓN

Davis y sus colegas proponen una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: Especificidad (ausencia de ambigüedad, corrección, compleción, comprensión, capacidad de verificación, consistencia externa e interna, capacidad de logro, concisión, traza habilidad, capacidad de modificación, exactitud y capacidad de reutilización. Además apuntan que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle.

Aunque muchas de las características anteriores pueden ser de naturaleza cuantitativa, Davis sugiere que todas puedan representarse usando una o más métricas. Por ejemplo asumimos que hay nrrequisitos en una especificación, tal como

Donde n_f es el numero de requisitos funcionales y n_nf es el número de requisitos no funcionales ( por ejemplo, rendimiento).

Para determinar la especificidad de los requisitos, Davis [PRES98] sugiere una métrica basada en la consistencia de la interpretación de los revisores para cada requisito:

Donde nui es el numero de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q₁ menor será la ambigüedad de la especificación.

La compleción de los requisitos funcionales pueden terminarse calculando la relación

donde nu es el número de requisitos de función únicos, nies el número de entradas (estímulos) definidos o implicados por la especificación y nses el número de estados especificados. La relación Q₂ mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no trata los requisitos no funciónales. Para incorporarlos a una métrica global completa, debemos considerar el grado de validación de los requisitos:

donde n_c es el número de requisitos que se han validados como correctos y n_nv el número de requisitos que no se han validado todavía.
 
 

CARACTERÍSTICAS DESEABLES DE UNA ERS

Una ERS de calidad debería poseer las siguientes características:

• No ambigua: La ERS es no ambigua si todo requisito posee una sóla interpretación
• Completa: Una ERS es completa si todo lo que se supone que el software debe hacer está incluído en la ERS. Por completitud, deberían describirse todas las posibles respuestas a todas las posibles entradas y en todas las situaciones posibles. Además, la ERS no contendrá secciones de tipo “por determinar...”
• Correcta: Todo requisito de la ERS contribuye a satisfacer una necesidad real.
• Comprensible: Todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de pruebas, gestores, etc.) entienden la ERS.
• Verificable: Si para cada requisito expresado en la ERS existe un procedimiento de prueba finito y no costoso para demostrar que el futuro sistema lo satisface.
• Internamente Consistente: No existen subconjuntos de requisitos contradictorios.
• Externamente Consistente: Ninguno de los requisitos está en contradicción con lo expresado en documentos de nivel superior. Por ejemplo, en un sistema (hardware+software), los requisitos del software no pueden contradecir los requisitos del sistema.
• Realizable: Si, dados los actuales recursos, la ERS es implementable
• Concisa: La ERS debe ser lo más breve posible, sin que esto afecte al resto de atributos de calidad
• Independiente del diseño: Existen más de un diseño e implementación que realizan la ERS. Para ello la ERS debería limitarse a describir el comportamiento externo del sistema.
• Trazable: Cada requisito se puede referenciar de forma unívoca. Es fundamental para precisar qué requisitos son implementados por qué componente del diseño, lo cual es imprescindible a la hora de realizar las pruebas de dicho componente
• Modificable: Los cambios son fáciles de introducir.
• Electrónicamente almacenada: Se encuentra en un archivo de texto, en una base de datos o, mejor aún, ha sido creada con una herramienta de gestión de requisitos (RequisitePro, Doors, etc.)
• Ejecutable/Interpretable/Prototipable/Animable: Si existe una herramienta software que, recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan sólo a ciertas notaciones como las notaciones formales o los diagramas de transición de estados.
• Anotada por importancia relativa: Si los requisitos se clasifican según su importancia. Como mínimo un requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sirve para no asignar demasiados recursos a la implementación de requisitos no esenciales.
• Anotada por estabilidad relativa: Los requisitos son, en general, inestables y volátiles. A cada requisito se le asigna una probabilidad de cambio (p.ej. “Alta, Media o Baja”). Esto ayudará a los diseñadores a diferenciar los componentes más flexibles de los más estables.
• Anotada por versión: Si un lector de la ERS puede determinar qué requisitos serán satisfechos por qué versión del producto.
• No redundante: Cada requisito se expresa en un solo lugar de la ERS. La redundancia, de todas formas, no es del todo mala si aumenta la legibilidad.
• Al nivel adecuado de abstracción: Ni demasiado detallada ni demasiado vaga.
• Precisa: Una ERS es precisa si hace uso de valores numéricos para precisar las características del sistema. La precisión es aplicable, ante todo, a los requisitos no funcionales. Por ejemplo, no es útil decir “El tiempo de respuesta será más bien rápido”, sino “El tiempo de respuesta será menor que dos segundos”. OJO: en la práctica diaria, este atributo es dificilísimo de conseguir pues es fuertemente dependiente de la tecnología disponible, lo cual no siempre se conoce al principio de un proyecto.
• Reutilizable: Si ciertas secciones de la ERS se pueden reutilizar
• Trazada: Si está claro el orígen de cada requisito (quién o qué lo pide)
• Organizada: Si el lector puede fácilmente encontrar la información buscada.
• Con referencias cruzadas: Si se utilizan referencias entre requisitosrelacionados (trazabilidad intra-ERS) o entre secciones relacionadas.

EL ESTÁNDAR ISO 9001

ISO 9001 es el estándar de garantía de calidad que se aplica a la ingeniería del software. El estándar contiene 20 requisitos que deben estar presentes en un sistema de garantía de calidad efectiva. Como el estándar ISO 9001 es aplicable a todas las disciplinas de ingeniería de software, se ha desarrollado un conjunto especial de directrices ISO (ISO 9000-3) para ayudar a interpretar el estándar para su uso en el proceso de software.
Los 20 requisitos descritos por ISO 9001 se encuentran con los temas siguientes:

1. Responsabilidad de la gestión.
2. Sistema de calidad.
3. Revisión de contrato.
4. Control de diseño.
5. Control de datos y documentos.
6. Compras.
7. Control del producto suministrado por el cliente.
8. Identificación y posibilidad de seguimiento del producto.
9. Control del proceso.
10. Inspección y prueba.
11. Control de inspección, medición y equipo de pruebas.
12. Inspección y estado de prueba.
13. Control de producto no aceptado.
14. Acción correctora y preventiva.
15. Tratamiento, almacenamiento, empaquetamiento, preservación y entrega.
16. Control de registros de calidad.
17. Auditorias internas de calidad.
18. Formación.
19. Servicios.
20. Técnicas estadísticas.

REFERENCIAS

[PRES98] Pressman Roger, “Ingeniería del software, un enfoque práctico”
www.deakin.edu.au/mis/pages/staff/pswatman/pdf/C_FowlerAndSwatman_ASWEC99.pdf
http://lml.ls.fi.upm.es/doctorado/Asignaturas/IngReq.html
www.ls.fi.upm.es/udis/docencia/is2/remkt.pdf
www.ls.fi.upm.es/udis/docencia/is2/ej01a.pdf
http://mailweb.udlap.mx/~tesis/gonzalez_d_h/capitulo4.pdf
www.uanl.mx/publicaciones/ingenierias/5/pdf/5_Edgar_Dominguez_et_al_Ensenanza_de.pdf
http://mailweb.udlap.mx/~tesis/gonzalez_d_h/capitulo8.pdf
www.westinghouse.com/wec-qms-v4.pdf
 
 

 
 

Comentarios, sugerencias