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
nr= nf+ nnf
Donde nf es el numero de requisitos funcionales y nnf 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:
Q1= nui/ nr
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 Q1 menor será la ambigüedad de la especificación.
La compleción de los requisitos funcionales pueden terminarse calculando la relación
Q2= nu/ (ni * ns)
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 Q2 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:
Q3= nc/ (nc * nnv)
donde nc es el número de requisitos que se han validados
como correctos y nnv 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:
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:
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
|
|