Verificación de los requisitos no funcionales en el software

Artículo publicado por Forum Calidad (nº 142) - Junio 2003 - Año XV
Verificación de los requisitos
no funcionales en el software
crítico
El software se ha convertido en un elemento básico de los sistemas actuales, con una importancia
destacada en los sistemas críticos. Los fallos ocasionados por el software en estos sistemas críticos
pueden tener consecuencias catastróficas, como lo demuestran numerosos ejemplos en la
actualidad. Sin embargo, por sus propias características (complejidad, etc), resulta imposible tener
una confianza plena en estos sistemas una vez se ha desarrollado, siendo imposible garantizar la
ausencia total de errores en el software.
+
José Carlos Sánchez Domínguez
Responsable de Calidad
Patricia Rodríguez Dapena
Gerente
SoftWcare, S.L.
on todo, la verificación de los
requisitos no funcionales del software (seguridad, fiabilidad, robustez,
etc. también llamados características
del software), contribuye a mejorar la
confianza en estos sistemas críticos de
forma que, sin poder llegar a tener una
confianza plena, nos permita asegurar
la eliminación de numerosos fallos
potenciales con consecuencias catastróficas para el sistema y para las vidas
humanas dependientes del mismo.
Introducción
La seguridad (“safety”) y fiabilidad
del software en los sistemas críticos es
fundamental. Si hace unas décadas un
adecuado mantenimiento de los sistemas electromecánicos aseguraba el
buen funcionamiento de estos sistemas,
en la actualidad el software ocupa un
lugar destacado en sistemas médicos,
de aviónica, automoción o de control
de plantas nucleares sobre cuyo buen
funcionamiento descansa la vida de
miles o quizás millones de personas.
La explosión de una caldera en un
colegio en el estado de Texas en 1937
provocó la muerte de más de 300 escolares. Esta explosión se debió entonces
a un fallo mecánico. Actualmente, la
función en la que se originó el fallo es
controlada por software. Más recientemente, el fallo del software del sistema
de control de ferrys ocasionó más de
una docena de choques contra el muelle en el puerto de Seattle provocando
unas pérdidas de más de 7 millones de
dólares, aparte de los más de 3 millones de dólares empleados en volver al
sistema manual. [McConnell99]
Existen otros sistemas cuyos fallos,
aun sin provocar la pérdida de vidas
humanas, pueden afectar gravemente a
nuestro bienestar. Los fallos en las
redes de comunicaciones, sistemas
basados en transacciones a través de
internet, cajeros automáticos, etc. son
cada vez más apreciables en nuestra
vida cotidiana, como consecuencia de
la presencia creciente del software en
dichos sistemas.
En 1996, se produjo un fallo general
de los semáforos en Washington DC
FORUM CALIDAD 142/03 25
según se informó en el Washington
Post del 9 de mayo de ese mismo año.
Buena parte de los semáforos del centro de la ciudad se ajustaron al patrón
definido para el fin de semana (15
segundos para la luz verde), en vez de
seguir el patrón definido para las
horas punta (50 segundos para la luz
verde). Este problema se produjo en la
hora punta de la mañana y fue debido
según se informó a una nueva versión
del software instalado en el sistema
central de control semafórico. Como
resultado, se produjeron colas kilométricas y el lógico malestar de los conductores afectados. [Rodriguez02]
A pesar de todo, incluso en los sistemas más costosos, ampliamente probados y certificados de forma independiente, se producen fallos meses e
incluso años después de su puesta en
marcha.
El tamaño y la complejidad de los
productos software en sistemas críticos
suele ser tal que su verificación completa es inabarcable. En la industria de
la aviación, por ejemplo, cada dos
años se duplica el software utilizado
en los sistemas en vuelo. Con estas características, y con cada vez menores
plazos y costes para
su desarrollo, no es
posible tener una confianza plena en el sistema y debe aceptarse
la posibilidad de que
se produzcan errores
en el software.
La seguridad y la
fiabilidad de software
forman parte de lo
que se define como
requisitos no funcionales o características
del software. Sin
embargo, el “seguimiento” de los requi-
Figura 1. Ciclo de Deming
26 FORUM CALIDAD 142/03
sitos no funcionales del software
(entendiendo por ‘seguimiento’, la
definición, implementación y verificación de dichos requisitos) a lo largo del
ciclo de vida del desarrollo de un producto, aún no se está realizando de una
manera sistemática cuando se desarrolla un sistema. Una mayor atención a
este “seguimiento” contribuye a la
mejora de las confianza en el software,
incluyendo la mejora de algunas de sus
características de gran importancia
como la seguridad y la fiabilidad.
Seguimiento
de los requisitos no
funcionales del software
Los requisitos no funcionales del
software son difíciles de verificar y
validar. Por su naturaleza, existen limitaciones técnicas que reducen alcance
de la cobertura de pruebas a ser utilizada para su verificación y validación
(numerosos escenarios diferentes a ser
probados, multitud de combinaciones
posibles y diferenciadas tanto de las
entradas a las funciones como de las
características que deben verificarse,
simulaciones muy costosas de entornos anómalos, etc.) Todo ello obliga al
desarrollador a priorizar el conjunto
limitado de pruebas a realizar considerando las restricciones en tiempo y
presupuesto para cada proyecto.
Con todo, los estándares internacionales y la literatura todavía no proporcionan un proceso sistemático para
gestionar, verificar y validar estos
requisitos no funcionales. Los procesos definidos hoy en día están condicionados en exceso por el dominio de
aplicación y se consideran de forma
específica según el entorno del que se
trate en vez de seguir las pautas marcadas por un proceso más general (por
ejemplo, en aviónica es diferente al
dominio de defensa, o al de trenes).
A nivel internacional, el estándar
ISO/IEC12207 [ISO12207] define un
nuevo proceso (a ser realizado tanto
por el cliente en el proceso de adquisición como por el proveedor en el conjunto de procesos de desarrollo) denominado Evaluación del producto y que
pretende “contrastar la Calidad del
producto intermedio frente a una serie
de criterios bien definidos que propor-
Figura 2. Integración de características de alto nivel (criticidad) en el ciclo de vida
cionen el grado de cumplimiento respecto del rendimiento y la Calidad
deseados para el producto final”. Este
proceso incluiría la verificación y
validación de estos requisitos no funcionales o características a las que se
refiere este artículo. No obstante, el
propósito de este proceso está todavía
limitado por varios factores:
a)El proceso se define con el propósito de evaluar, pero no de desarrollar
las características de Calidad (incluyendo la seguridad).
b)Sólo se define para software y no
para sistemas.
c)Define la evaluación de la característica de seguridad a través de una
métrica, pero todavía se menciona
como un tema que requiere un mayor estudio.
d)Se presenta como un cálculo numérico sin existir todavía relación entre los
valores cuantitativos y las características finales de seguridad y fiabilidad.
e)Se presentan numerosas métricas de
forma detallada, adoleciendo aun así
de madurez, un rango limitado de
valores, etc. [Rodriguez02]
Con todo lo anterior se plantean las
siguientes preguntas:
a)¿Pueden aplicarse para las requisitos
no funcionales los mismos procesos
que ya se aplican para las requisitos
funcionales? y,
b)¿Cuál sería la mejor forma de proporcionar una definición, implementación y verificación adecuadas de
estos requisitos no funcionales desde el punto de vista de la gestión?
Integración
de los requisitos no
funcionales en el ciclo
de vida del desarrollo
del software
Los procesos de desarrollo de los requisitos no funcionales se pueden defi-
nir como una serie de actividades que
deberán ser aplicados en paralelo o
conjuntamente con los procesos de desarrollo de los requisitos funcionales.
Al igual que para los funcionales,
para el desarrollo de las requisitos no
funcionales se puede utilizar el conocido “ciclo de Deming” (ver Figura
1), donde cualquier proceso comienza
con la definición de un plan o estrategia para la realización de las actividades correspondientes a cada fase del
ciclo de vida (planificación). Una vez
se ha planificado, este deberá llevarse
a cabo mediante la realización de las
actividades de ingeniería del proceso.
Los resultados obtenidos se comprueban a través de las actividades de verificación específicas, llevándose a cabo
las acciones necesarias para corregir
las desviaciones, en cuyo caso el ciclo
se repite de nuevo (proceso de mejora). Si las actividades de ingeniería
proporcionaran los resultados deseados, se aplicarán las acciones corres-
FORUM CALIDAD 142/03 27
Figura 3. Integración de características internas o de bajo nivel (tiempo real) en el ciclo de vida
pondientes para consolidar estos resultados obteniendo así unos resultados
definitivos.
Este esquema debería facilitar la planificación de los procesos correspondientes al desarrollo de los requisitos
no funcionales en cada etapa del ciclo
de vida del desarrollo del software.
Para cada etapa del ciclo de desarrollo, siempre se deberán definir:
a)Los métodos, herramientas y técnicas utilizados tanto para la ingeniería como para la verificación del requisito en esa fase
b)Los recursos humanos, considerando los perfiles profesionales adecuados y el soporte necesario de la organización (equipos independientes,
laboratorios certificados, etc.)
c)Una planificación con los plazos
bien definidos.
d)Si fuera posible, el detalle de las
actividades de bajo nivel.
Aun siendo posible una integración
completa de los procesos de imple-
28 FORUM CALIDAD 142/03
mentación de los requisitos funcionales y no funcionales, la necesidad de
mantener una cierta independencia
tanto en las responsabilidades como
en las habilidades requeridas para su
realización, sugiere mantener una
cierta separación entre ellos. Esta
separación de una actividad o de un
proceso es asimismo una forma de
concederle una cierta entidad. Y es
que la ausencia de una delimitación
respecto a los requisitos no funcionales ha sido la causa de diversos accidentes catastróficos en el pasado. En
muchas ocasiones ya se exige que
haya un responsable específico para
la planificación y el desarrollo de
algún requisito no funcional (ej.
“safety”). [DEF-00-55], [ECSS],
[DO178B]
Una aproximación en paralelo al
ciclo de vida de desarrollo del software para el desarrollo de los requisitos
no funcionales podría ser beneficiosa
en un doble sentido, puesto que:
a)Reparte el esfuerzo de ingeniería y
verificación de forma más equilibrada (y por lo tanto mejor) a lo largo
del ciclo de vida y,
b)Ayuda a detectar problemas con mayor antelación en el ciclo de vida,
contribuyendo así mejor a su solución.
En todo caso, la definición de un
proceso en paralelo al ciclo de vida
del desarrollo para cada característica
no es realista ni abordable puesto que
complicaría enormemente la gestión.
Así pues, la separación y el paralelismo debería preservarse para las características con un mayor impacto en el
sistema, tales como la seguridad y la
fiabilidad [Rodriguez02].
Integración de los procesos
En la Figura 2 se muestra un ejemplo de interacción entre las actividades de ingeniería para las características de seguridad y fiabilidad (esto es,
la criticidad) y las etapas de desarrollo
de los requisitos funcionales, considerando el caso extremo en el que las
actividades de ingeniería y las de verificación se realizasen en paralelo.
Aunque este paralelismo podría hacer
pensar que hay una cierta duplicidad
del esfuerzo para cada característica,
hay que considerar que se trata de
enfocar específicamente en estos aspectos o características dentro del
desarrollo de un solo producto software. Así, la figura pretende destacar la
necesidad de planificar cuidadosamente las actividades de ingeniería para
cada característica que deba considerarse en el proyecto para cada fase de
desarrollo.
Como se ha indicado anteriormente,
el paralelismo en la aplicación de los
procesos respecto al ciclo de vida de
desarrollo del software se acepta de
forma generalizada para las características, tales como la seguridad y la fiabilidad, llamadas de alto nivel. Sin
embargo, esto no ocurre en el caso de
otras características (como, por ejemplo, el rendimiento, la portabilidad,
etc.) que son igualmente importantes
para el buen funcionamiento del sistema, pero que quizás no sean igualmente necesarias para ser definidas
por el propio usuario.
Así por ejemplo, podríamos considerar características de rendimiento en
tiempo real como pueda ser la “planificabilidad” de la concurrencia de las
tareas/transacciones paralelas a ejecutarse dentro de un producto software,
que está adquiriendo cada vez mayor
importancia en una gran variedad de
dominios de aplicación. Estas características no se definen exactamente al
inicio del desarrollo, ya que dependen
de la tecnología y la arquitectura del
software, pero deberían ser de gran
importancia para los desarrolladores
en las fases de implementación, puesto que la operatividad del software
depende de ellas.
En la Figura 3 se muestra un esquema de la integración del desarrollo de
estas características de rendimiento en
tiempo real en las actividades de ingeniería propias del desarrollo del software [Vardanega98] [ECSS]. Los procesos relacionados con los requisitos
no funcionales se muestran en paralelo
sólo por razones de planificación y de
claridad, puesto que pueden integrarse
en los procesos ‘nominales’ y con los
correspondientes a las otras características una vez que hayan sido planificados de forma detallada en el proyecto.
Figura 4. Integración de las técnicas de tratamiento de los fallos en el ciclo de vida
FORUM CALIDAD 142/03 29
Integración
de las técnicas de
tratamiento de fallos
en el ciclo de vida
Hasta ahora se han presentado las
diferentes fases del desarrollo, verificación y validación (llamado anteriormente “seguimiento”) de las características de seguridad y fiabilidad de
productos software. Como se ha mencionado anteriormente, para cada fase
hay que definir los métodos y las técnicas a ser utilizadas para este seguimiento. Existen diferentes técnicas
para el tratamiento de la seguridad y
la fiabilidad del software crítico. Las
técnicas de prevención, tolerancia y
eliminación de fallos del software se
integran de forma efectiva en el proceso de desarrollo del software según se
detalla a continuación (ver Figura 4):
• Las técnicas de tolerancia a fallos
del software afectan a la arquitectura del producto final a través del uso
de métodos y técnicas específicas
(como mecanismos de redundancia,
de votación, de encapsulamiento,
etc.). Como se observa en la Figura
4, las técnicas de tolerancia a fallos
afectan a las fases de diseño y codificación.
• Las técnicas de prevención de
fallos del software, utilizadas con el
objetivo de prevenir la existencia de
fallos software, incluyen una serie de
métodos y técnicas tales como
estándares de codificación, uso de
herramientas específicas que ayuden
a chequear interfaces, etc. Estas
técnicas se aplican a los procesos de
ingeniería, tal y como se muestra en
la Figura 4, ya que los métodos,
técnicas y herramientas utilizados
son para el propio desarrollo del
producto y no para su verificación.
• Las técnicas de eliminación de
fallos suponen el uso de métodos,
técnicas y herramientas en los
30 FORUM CALIDAD 142/03
Figura 5: Método SoftCare
procesos de verificación, razón por
la que afectan exclusivamente a las
actividades de verificación. Estas
técnicas ayudan el proceso de
desarrollo y verificación de la
seguridad y la fiabilidad de sistemas
de software crítico, así como para
mejorar el uso de otras técnicas de
fallos.
Ejemplo de técnicas
de eliminación de fallos
(verificación
y validación)
Este artículo se centra en las técnicas de verificación de la seguridad y
fiabilidad de software, o sea, las que
se refieren a la eliminación de fallos
de software. Los técnicas tradicionales para el análisis estático de la
seguridad y la fiabilidad de los sistemas, tales como SFMEA (Análisis de
los Modos de Fallo del Software y
sus Efectos) y SFTA (Análisis del
Árbol de Fallos del Software) ya se
aplican a nivel sistema paralelamente
a otras técnicas dinámicas, pero no a
nivel de los subsistemas software en
sistemas con un alto contenido en
software.
Su mayor ventaja, cuando se aplica
para analizar un producto software, se
obtiene cuando se utilizan conjuntamente: SFMEA se centra en la identificación de la severidad y la criticidad
de los fallos y SFTA en identificar las
causas de estos fallos, y en orden
inverso a su utilización normal a nivel
sistema [Rodriguez02].
La elección de estas técnicas viene
determinada por los siguientes factores:
• su uso desde las etapas iniciales del
proyecto, ayudando a descubrir y
eliminar fallos potenciales con una
mayor anticipación;
• su integración con las demostraciones de seguridad y fiabilidad a
nivel de sistema;
• ambas cuentan con una gran aceptación como técnicas de análisis de
seguridad y fiabilidad, como
demuestra su inclusión en los
estándares ([DEF-00-55], [ECSS],
etc) y, finalmente,
• no requieren de una infraestructura
especial para su aplicación.
Con todo, SFMEA y SFTA no son
una solución infalible, pero pueden
aplicarse de forma sencilla en el software, con ciertas adaptaciones que
deberán ser consideradas de forma
específica para cada etapa de desarro-
llo del software en las que se apliquen.
Entre las técnicas más importantes
para la verificación de las características de seguridad y fiabilidad están las
técnicas estáticas: SFMEA y SFTA.
Estas dos técnicas complementas la
limitada posibilidad de realizar el 100
por 100 de las pruebas (técnicas dinámicas) de software para tener una confianza plena de su robustez.
Estas dos técnicas aunque se exigen
ya en varios estándares internacionales, aún necesitan más experiencia
práctica en su utilización para evaluar
productos críticos de software. Son
técnicas que provienen del mundo del
hardware, por lo que hay que adaptarlas para su aplicación al software.
El método SoftCare(c) (ver Figura 5)
pretende identificar los fallos software
que pudieran tener consecuencias graves en un sistema (pérdida del propio
sistema o de vidas humanas, etc.), ayudando al aseguramiento de esta forma
de la seguridad y fiabilidad del sistema, mediante su aplicación en las diferentes fases de desarrollo del producto.
La definición del método se basa en
la idea de que a través de la comprobación sistemática y estática de los
fallos potenciales del software durante
el desarrollo de un producto de software crítico, es posible reducir drásticamente los riesgos de fallo del sistema debidos a problemas en el software, antes de su puesta en operación.
La combinación de las técnicas
SFMEA Y SFTA, así como las adaptaciones específicas necesarias para el
software, definen el método SoftCare,
donde:
• el análisis SFMEA identifica los
modos de fallo funcionales, analizando sus efectos e identificando las
causas potenciales y,
• el análisis SFTA identifica en detalle los fallos de software causantes
de los modos de fallo.
Tras la aplicación de SFMEA y
SFTA debe realizarse una evaluación
de resultados que incluya las recomendaciones necesarias para eliminar
los fallos del software que pudieran
ser potencialmente desastrosos para el
sistema.
Este método ya se está aplicando
con éxito en el análisis de software
crítico en sistemas en los dominios del
automóvil y de sistemas espaciales. Se
está planificando su utilización en
software para sistemas médicos, aviónica e incluso banca.
Conclusión
El tratamiento de los requisitos no
funcionales del software en sistemas
críticos (seguridad, fiabilidad, robustez, etc.) proporciona una mayor confianza en la utilización de estos sistemas, puesto que contribuye a reducir
los fallos potenciales del software con
consecuencias catastróficas durante el
desarrollo.
Los procesos definidos para el
seguimiento de los requisitos no funcionales deberán ser cuidadosamente
planificados, ejecutados según un plan
diseñado específicamente y los resultados obtenidos deberán ser verificados realizándose las correcciones
necesarias, de forma que a través de
un proceso iterativo se llegue a los
resultados definitivos.
Una buena aproximación para abordar el desarrollo de los requisitos no
funcionales consiste en la ejecución
de los procesos asociados a las características del software, en paralelo al
ciclo de vida de desarrollo del producto. Sin embargo, puesto que no sería
abordable la aplicación de un proceso
paralelo por cada característica, la
separación y el paralelismo deberían
preservarse para las características con
un mayor impacto en el sistema, tales
como la seguridad y la fiabilidad.
Las técnicas de prevención, tolerancia y eliminación de fallos del softwa-
re contribuyen a la mejora de sus
características. Así, mientras las técnicas de tolerancia se aplican al diseño y la codificación del software, las
de prevención se aplican a las actividades de ingeniería en el ciclo de
desarrollo y las de eliminación a las
de verificación.
El método SoftCareÓ contribuye a
la aplicación práctica de métodos estáticos que complementan las nunca
completas pruebas del sistema, dedicadas a la eliminación de fallos, como
parte de la verificación y la validación
de las características de seguridad y
fiabilidad del software.
G
Referencias
[ECSS]
• ECSS (European Cooperation for Space
Standardisation) series of standards
(http://www.ecss.nl)
• ECSS-E-40B Space engineering - software.
ECSS-E-40B, 29 May 2002, ESA.
• ECSS-Q-80B ECSS Product Assurance Software Product Assurance. 29 May 2002,
ESA.
[DEF-00-55]
• Defence Standard 00-55 (PART 1 and 2)/Issue
2. Requirements for safety related software
defence equipment. UK MoD. 1/08/97
(http://www.dstan.mod.uk/).
[DO178B]
• DO-178B/ED-12B Software Considerations in
Airborne Systems and Equipment Certification,
RTCA, EUROCAE, December 1992
[ISO12207]
• ISO/IEC 12207:1995/AMD 1:2002 - Information Technology - Software life cycle processes. ISO/IEC 2002.
[McConnell99]
• McConnell, S: After the Gold Rush. Microsoft
Press, 1999.
[Rodríguez02]
• Rodríguez-Dapena, P: Software Safety
Verification in Critical Software Intensive
Systems. Technische Universiteit Eindhoven,
2002.
[Rodríguez01]
• Rodríguez-Dapena, P; et al. ‘ Non functional
Requirements: the driving force of software
development’. Software Quality Professional.
ASQ Quarterly journal September 2001.
[Vardanega98]
• Vardanega. T. Development of on-board realtime systems: an engineering approach. PhD
Thesis. Technical University of Delft. 1998.
FORUM CALIDAD 142/03 31