Artículo publicado por Forum Calidad (nº 142) - Junio 2003 - Año XV




 Verificación de los requisitos
 no funcionales en...
según se informó en el Washington           sitos no funcionales del software           características que deben verifica...
Figura 2. Integración de características de alto nivel (criticidad) en el ciclo de vida


 cionen el grado de cumplimiento...
Figura 3. Integración de características internas o de bajo nivel (tiempo real) en el ciclo de vida


 pondientes para con...
de los requisitos funcionales, conside-             forma generalizada para las caracterís-    inicio del desarrollo, ya q...
Integración
de las técnicas de
tratamiento de fallos
en el ciclo de vida
  Hasta ahora se han presentado las
diferentes fa...
llo del software en las que se apliquen.    de resultados que incluya las reco-        re contribuyen a la mejora de sus
 ...
Próxima SlideShare
Cargando en…5
×

Softwcare Article - How to verify software quality

860 visualizaciones

Publicado el

Verificación de los requisitos no funcionales (seguridad,fiabilidad, robustez,...) en el software crítico.

Publicado en: Tecnología
1 comentario
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
860
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
16
Comentarios
1
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Softwcare Article - How to verify software quality

  1. 1. 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. + on todo, la verificación de los requisitos no funcionales del soft- ware (seguridad, fiabilidad, robustez, La explosión de una caldera en un colegio en el estado de Texas en 1937 provocó la muerte de más de 300 esco- etc. también llamados características lares. Esta explosión se debió entonces José Carlos Sánchez Domínguez del software), contribuye a mejorar la a un fallo mecánico. Actualmente, la Responsable de Calidad confianza en estos sistemas críticos de función en la que se originó el fallo es forma que, sin poder llegar a tener una controlada por software. Más reciente- Patricia Rodríguez Dapena confianza plena, nos permita asegurar mente, el fallo del software del sistema Gerente la eliminación de numerosos fallos de control de ferrys ocasionó más de potenciales con consecuencias catas- una docena de choques contra el mue- SoftWcare, S.L. tróficas para el sistema y para las vidas lle en el puerto de Seattle provocando humanas dependientes del mismo. unas pérdidas de más de 7 millones de dólares, aparte de los más de 3 millo- nes de dólares empleados en volver al Introducción sistema manual. [McConnell99] Existen otros sistemas cuyos fallos, La seguridad (“safety”) y fiabilidad aun sin provocar la pérdida de vidas del software en los sistemas críticos es humanas, pueden afectar gravemente a fundamental. Si hace unas décadas un nuestro bienestar. Los fallos en las adecuado mantenimiento de los siste- redes de comunicaciones, sistemas mas electromecánicos aseguraba el basados en transacciones a través de buen funcionamiento de estos sistemas, internet, cajeros automáticos, etc. son en la actualidad el software ocupa un cada vez más apreciables en nuestra lugar destacado en sistemas médicos, vida cotidiana, como consecuencia de de aviónica, automoción o de control la presencia creciente del software en de plantas nucleares sobre cuyo buen dichos sistemas. funcionamiento descansa la vida de En 1996, se produjo un fallo general miles o quizás millones de personas. de los semáforos en Washington DC FORUM CALIDAD 142/03 25
  2. 2. según se informó en el Washington sitos no funcionales del software características que deben verificarse, Post del 9 de mayo de ese mismo año. (entendiendo por ‘seguimiento’, la simulaciones muy costosas de entor- Buena parte de los semáforos del cen- definición, implementación y verifica- nos anómalos, etc.) Todo ello obliga al tro de la ciudad se ajustaron al patrón ción de dichos requisitos) a lo largo del desarrollador a priorizar el conjunto definido para el fin de semana (15 ciclo de vida del desarrollo de un pro- limitado de pruebas a realizar conside- segundos para la luz verde), en vez de ducto, aún no se está realizando de una rando las restricciones en tiempo y seguir el patrón definido para las manera sistemática cuando se desarro- presupuesto para cada proyecto. horas punta (50 segundos para la luz lla un sistema. Una mayor atención a Con todo, los estándares internacio- verde). Este problema se produjo en la este “seguimiento” contribuye a la nales y la literatura todavía no propor- hora punta de la mañana y fue debido mejora de las confianza en el software, cionan un proceso sistemático para según se informó a una nueva versión incluyendo la mejora de algunas de sus gestionar, verificar y validar estos del software instalado en el sistema características de gran importancia requisitos no funcionales. Los proce- central de control semafórico. Como como la seguridad y la fiabilidad. sos definidos hoy en día están condi- resultado, se produjeron colas kilomé- cionados en exceso por el dominio de tricas y el lógico malestar de los con- aplicación y se consideran de forma ductores afectados. [Rodriguez02] Seguimiento específica según el entorno del que se A pesar de todo, incluso en los siste- trate en vez de seguir las pautas mar- mas más costosos, ampliamente pro- de los requisitos no cadas por un proceso más general (por bados y certificados de forma inde- funcionales del software ejemplo, en aviónica es diferente al pendiente, se producen fallos meses e dominio de defensa, o al de trenes). incluso años después de su puesta en Los requisitos no funcionales del A nivel internacional, el estándar marcha. software son difíciles de verificar y ISO/IEC12207 [ISO12207] define un El tamaño y la complejidad de los validar. Por su naturaleza, existen limi- nuevo proceso (a ser realizado tanto productos software en sistemas críticos taciones técnicas que reducen alcance por el cliente en el proceso de adquisi- suele ser tal que su verificación com- de la cobertura de pruebas a ser utiliza- ción como por el proveedor en el con- pleta es inabarcable. En la industria de da para su verificación y validación junto de procesos de desarrollo) deno- la aviación, por ejemplo, cada dos (numerosos escenarios diferentes a ser minado Evaluación del producto y que años se duplica el software utilizado probados, multitud de combinaciones pretende “contrastar la Calidad del en los sistemas en vuelo. Con estas ca- posibles y diferenciadas tanto de las producto intermedio frente a una serie racterísticas, y con cada vez menores entradas a las funciones como de las de criterios bien definidos que propor- plazos y costes para su desarrollo, no es posible tener una con- fianza plena en el sis- tema 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 funcio- nales o características del software. Sin embargo, el “segui- miento” de los requi- Figura 1. Ciclo de Deming 26 FORUM CALIDAD 142/03
  3. 3. Figura 2. Integración de características de alto nivel (criticidad) en el ciclo de vida cionen el grado de cumplimiento res- forma detallada, adoleciendo aun así nir como una serie de actividades que pecto del rendimiento y la Calidad de madurez, un rango limitado de deberán ser aplicados en paralelo o deseados para el producto final”. Este valores, etc. [Rodriguez02] conjuntamente con los procesos de de- proceso incluiría la verificación y Con todo lo anterior se plantean las sarrollo de los requisitos funcionales. validación de estos requisitos no fun- siguientes preguntas: Al igual que para los funcionales, cionales o características a las que se a)¿Pueden aplicarse para las requisitos para el desarrollo de las requisitos no refiere este artículo. No obstante, el no funcionales los mismos procesos funcionales se puede utilizar el cono- propósito de este proceso está todavía que ya se aplican para las requisitos cido “ciclo de Deming” (ver Figura limitado por varios factores: funcionales? y, 1), donde cualquier proceso comienza a)El proceso se define con el propósi- b)¿Cuál sería la mejor forma de pro- con la definición de un plan o estrate- to de evaluar, pero no de desarrollar porcionar una definición, implemen- gia para la realización de las activida- las características de Calidad (inclu- tación y verificación adecuadas de des correspondientes a cada fase del yendo la seguridad). estos requisitos no funcionales des- ciclo de vida (planificación). Una vez b)Sólo se define para software y no de el punto de vista de la gestión? se ha planificado, este deberá llevarse para sistemas. a cabo mediante la realización de las c)Define la evaluación de la caracte- actividades de ingeniería del proceso. rística de seguridad a través de una Integración Los resultados obtenidos se comprue- métrica, pero todavía se menciona ban a través de las actividades de veri- como un tema que requiere un ma- de los requisitos no ficación específicas, llevándose a cabo yor estudio. funcionales en el ciclo las acciones necesarias para corregir d)Se presenta como un cálculo numéri- de vida del desarrollo las desviaciones, en cuyo caso el ciclo co sin existir todavía relación entre los del software se repite de nuevo (proceso de mejo- valores cuantitativos y las caracterís- ra). Si las actividades de ingeniería ticas finales de seguridad y fiabilidad. Los procesos de desarrollo de los re- proporcionaran los resultados desea- e)Se presentan numerosas métricas de quisitos no funcionales se pueden defi- dos, se aplicarán las acciones corres- FORUM CALIDAD 142/03 27
  4. 4. Figura 3. Integración de características internas o de bajo nivel (tiempo real) en el ciclo de vida pondientes para consolidar estos resul- mentación de los requisitos funciona- a)Reparte el esfuerzo de ingeniería y tados obteniendo así unos resultados les y no funcionales, la necesidad de verificación de forma más equilibra- definitivos. mantener una cierta independencia da (y por lo tanto mejor) a lo largo Este esquema debería facilitar la pla- tanto en las responsabilidades como del ciclo de vida y, nificación de los procesos correspon- en las habilidades requeridas para su b)Ayuda a detectar problemas con ma- dientes al desarrollo de los requisitos realización, sugiere mantener una yor antelación en el ciclo de vida, no funcionales en cada etapa del ciclo cierta separación entre ellos. Esta contribuyendo así mejor a su solución. de vida del desarrollo del software. separación de una actividad o de un En todo caso, la definición de un Para cada etapa del ciclo de desarro- proceso es asimismo una forma de proceso en paralelo al ciclo de vida llo, siempre se deberán definir: concederle una cierta entidad. Y es del desarrollo para cada característica a)Los métodos, herramientas y técni- que la ausencia de una delimitación no es realista ni abordable puesto que cas utilizados tanto para la ingenie- respecto a los requisitos no funciona- complicaría enormemente la gestión. ría como para la verificación del re- les ha sido la causa de diversos acci- Así pues, la separación y el paralelis- quisito en esa fase dentes catastróficos en el pasado. En mo debería preservarse para las carac- b)Los recursos humanos, consideran- muchas ocasiones ya se exige que terísticas con un mayor impacto en el do los perfiles profesionales adecua- haya un responsable específico para sistema, tales como la seguridad y la dos y el soporte necesario de la or- la planificación y el desarrollo de fiabilidad [Rodriguez02]. ganización (equipos independientes, algún requisito no funcional (ej. laboratorios certificados, etc.) “safety”). [DEF-00-55], [ECSS], Integración de los procesos c)Una planificación con los plazos [DO178B] bien definidos. Una aproximación en paralelo al En la Figura 2 se muestra un ejem- d)Si fuera posible, el detalle de las ciclo de vida de desarrollo del softwa- plo de interacción entre las activida- actividades de bajo nivel. re para el desarrollo de los requisitos des de ingeniería para las característi- Aun siendo posible una integración no funcionales podría ser beneficiosa cas de seguridad y fiabilidad (esto es, completa de los procesos de imple- en un doble sentido, puesto que: la criticidad) y las etapas de desarrollo 28 FORUM CALIDAD 142/03
  5. 5. de los requisitos funcionales, conside- forma generalizada para las caracterís- inicio del desarrollo, ya que dependen rando el caso extremo en el que las ticas, tales como la seguridad y la fia- de la tecnología y la arquitectura del actividades de ingeniería y las de veri- bilidad, llamadas de alto nivel. Sin software, pero deberían ser de gran ficación se realizasen en paralelo. embargo, esto no ocurre en el caso de importancia para los desarrolladores Aunque este paralelismo podría hacer otras características (como, por ejem- en las fases de implementación, pues- pensar que hay una cierta duplicidad plo, el rendimiento, la portabilidad, to que la operatividad del software del esfuerzo para cada característica, etc.) que son igualmente importantes depende de ellas. hay que considerar que se trata de para el buen funcionamiento del siste- En la Figura 3 se muestra un esque- enfocar específicamente en estos as- ma, pero que quizás no sean igual- ma de la integración del desarrollo de pectos o características dentro del mente necesarias para ser definidas estas características de rendimiento en desarrollo de un solo producto softwa- por el propio usuario. tiempo real en las actividades de inge- re. Así, la figura pretende destacar la Así por ejemplo, podríamos consi- niería propias del desarrollo del soft- necesidad de planificar cuidadosamen- derar características de rendimiento en ware [Vardanega98] [ECSS]. Los pro- te las actividades de ingeniería para tiempo real como pueda ser la “plani- cesos relacionados con los requisitos cada característica que deba conside- ficabilidad” de la concurrencia de las no funcionales se muestran en paralelo rarse en el proyecto para cada fase de tareas/transacciones paralelas a ejecu- sólo por razones de planificación y de desarrollo. tarse dentro de un producto software, claridad, puesto que pueden integrarse Como se ha indicado anteriormente, que está adquiriendo cada vez mayor en los procesos ‘nominales’ y con los el paralelismo en la aplicación de los importancia en una gran variedad de correspondientes a las otras caracterís- procesos respecto al ciclo de vida de dominios de aplicación. Estas caracte- ticas una vez que hayan sido planifica- desarrollo del software se acepta de rísticas no se definen exactamente al dos 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
  6. 6. 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, verifi- cación y validación (llamado anterior- mente “seguimiento”) de las caracte- rísticas de seguridad y fiabilidad de productos software. Como se ha men- cionado anteriormente, para cada fase hay que definir los métodos y las téc- nicas a ser utilizadas para este segui- Figura 5: Método SoftCare miento. Existen diferentes técnicas para el tratamiento de la seguridad y la fiabilidad del software crítico. Las procesos de verificación, razón por Su mayor ventaja, cuando se aplica técnicas de prevención, tolerancia y la que afectan exclusivamente a las para analizar un producto software, se eliminación de fallos del software se actividades de verificación. Estas obtiene cuando se utilizan conjunta- integran de forma efectiva en el proce- técnicas ayudan el proceso de mente: SFMEA se centra en la identi- so de desarrollo del software según se desarrollo y verificación de la ficación de la severidad y la criticidad detalla a continuación (ver Figura 4): seguridad y la fiabilidad de sistemas de los fallos y SFTA en identificar las • Las técnicas de tolerancia a fallos de software crítico, así como para causas de estos fallos, y en orden del software afectan a la arquitectu- mejorar el uso de otras técnicas de inverso a su utilización normal a nivel ra del producto final a través del uso fallos. sistema [Rodriguez02]. de métodos y técnicas específicas La elección de estas técnicas viene (como mecanismos de redundancia, determinada por los siguientes facto- de votación, de encapsulamiento, Ejemplo de técnicas res: etc.). Como se observa en la Figura • su uso desde las etapas iniciales del 4, las técnicas de tolerancia a fallos de eliminación de fallos proyecto, ayudando a descubrir y afectan a las fases de diseño y codi- (verificación eliminar fallos potenciales con una ficación. y validación) mayor anticipación; • Las técnicas de prevención de • su integración con las demostra- fallos del software, utilizadas con el Este artículo se centra en las técni- ciones de seguridad y fiabilidad a objetivo de prevenir la existencia de cas de verificación de la seguridad y nivel de sistema; fallos software, incluyen una serie de fiabilidad de software, o sea, las que • ambas cuentan con una gran acepta- métodos y técnicas tales como se refieren a la eliminación de fallos ción como técnicas de análisis de estándares de codificación, uso de de software. Los técnicas tradiciona- seguridad y fiabilidad, como herramientas específicas que ayuden les para el análisis estático de la demuestra su inclusión en los a chequear interfaces, etc. Estas seguridad y la fiabilidad de los siste- estándares ([DEF-00-55], [ECSS], técnicas se aplican a los procesos de mas, tales como SFMEA (Análisis de etc) y, finalmente, ingeniería, tal y como se muestra en los Modos de Fallo del Software y • no requieren de una infraestructura la Figura 4, ya que los métodos, sus Efectos) y SFTA (Análisis del especial para su aplicación. técnicas y herramientas utilizados Árbol de Fallos del Software) ya se Con todo, SFMEA y SFTA no son son para el propio desarrollo del aplican a nivel sistema paralelamente una solución infalible, pero pueden producto y no para su verificación. a otras técnicas dinámicas, pero no a aplicarse de forma sencilla en el soft- • Las técnicas de eliminación de nivel de los subsistemas software en ware, con ciertas adaptaciones que fallos suponen el uso de métodos, sistemas con un alto contenido en deberán ser consideradas de forma técnicas y herramientas en los software. específica para cada etapa de desarro- 30 FORUM CALIDAD 142/03
  7. 7. llo del software en las que se apliquen. de resultados que incluya las reco- re contribuyen a la mejora de sus Entre las técnicas más importantes mendaciones necesarias para eliminar características. Así, mientras las téc- para la verificación de las característi- los fallos del software que pudieran nicas de tolerancia se aplican al dise- cas de seguridad y fiabilidad están las ser potencialmente desastrosos para el ño y la codificación del software, las técnicas estáticas: SFMEA y SFTA. sistema. de prevención se aplican a las activi- Estas dos técnicas complementas la Este método ya se está aplicando dades de ingeniería en el ciclo de limitada posibilidad de realizar el 100 con éxito en el análisis de software desarrollo y las de eliminación a las por 100 de las pruebas (técnicas diná- crítico en sistemas en los dominios del de verificación. micas) de software para tener una con- automóvil y de sistemas espaciales. Se El método SoftCareÓ contribuye a fianza plena de su robustez. está planificando su utilización en la aplicación práctica de métodos está- Estas dos técnicas aunque se exigen software para sistemas médicos, avió- ticos que complementan las nunca ya en varios estándares internaciona- nica e incluso banca. completas pruebas del sistema, dedi- les, aún necesitan más experiencia cadas a la eliminación de fallos, como práctica en su utilización para evaluar parte de la verificación y la validación productos críticos de software. Son Conclusión de las características de seguridad y técnicas que provienen del mundo del fiabilidad del software. G hardware, por lo que hay que adaptar- El tratamiento de los requisitos no las para su aplicación al software. funcionales del software en sistemas El método SoftCare(c) (ver Figura 5) críticos (seguridad, fiabilidad, robus- Referencias pretende identificar los fallos software tez, etc.) proporciona una mayor con- [ECSS] que pudieran tener consecuencias gra- fianza en la utilización de estos siste- • ECSS (European Cooperation for Space Standardisation) series of standards ves en un sistema (pérdida del propio mas, puesto que contribuye a reducir (http://www.ecss.nl) sistema o de vidas humanas, etc.), ayu- los fallos potenciales del software con • ECSS-E-40B Space engineering - software. dando al aseguramiento de esta forma consecuencias catastróficas durante el ECSS-E-40B, 29 May 2002, ESA. de la seguridad y fiabilidad del siste- desarrollo. • ECSS-Q-80B ECSS Product Assurance - Software Product Assurance. 29 May 2002, ma, mediante su aplicación en las dife- Los procesos definidos para el ESA. rentes fases de desarrollo del producto. seguimiento de los requisitos no fun- [DEF-00-55] La definición del método se basa en cionales deberán ser cuidadosamente • Defence Standard 00-55 (PART 1 and 2)/Issue 2. Requirements for safety related software la idea de que a través de la compro- planificados, ejecutados según un plan defence equipment. UK MoD. 1/08/97 bación sistemática y estática de los diseñado específicamente y los resul- (http://www.dstan.mod.uk/). fallos potenciales del software durante tados obtenidos deberán ser verifica- [DO178B] • DO-178B/ED-12B Software Considerations in el desarrollo de un producto de soft- dos realizándose las correcciones Airborne Systems and Equipment Certification, ware crítico, es posible reducir drásti- necesarias, de forma que a través de RTCA, EUROCAE, December 1992 camente los riesgos de fallo del siste- un proceso iterativo se llegue a los [ISO12207] ma debidos a problemas en el softwa- resultados definitivos. • ISO/IEC 12207:1995/AMD 1:2002 - Informa- tion Technology - Software life cycle proces- re, antes de su puesta en operación. Una buena aproximación para abor- ses. ISO/IEC 2002. La combinación de las técnicas dar el desarrollo de los requisitos no [McConnell99] SFMEA Y SFTA, así como las adap- funcionales consiste en la ejecución • McConnell, S: After the Gold Rush. Microsoft Press, 1999. taciones específicas necesarias para el de los procesos asociados a las carac- [Rodríguez02] software, definen el método SoftCare, terísticas del software, en paralelo al • Rodríguez-Dapena, P: Software Safety donde: ciclo de vida de desarrollo del produc- Verification in Critical Software Intensive Systems. Technische Universiteit Eindhoven, • el análisis SFMEA identifica los to. Sin embargo, puesto que no sería 2002. modos de fallo funcionales, anali- abordable la aplicación de un proceso [Rodríguez01] zando sus efectos e identificando las paralelo por cada característica, la • Rodríguez-Dapena, P; et al. ‘ Non functional causas potenciales y, separación y el paralelismo deberían Requirements: the driving force of software development’. Software Quality Professional. • el análisis SFTA identifica en deta- preservarse para las características con ASQ Quarterly journal September 2001. lle los fallos de software causantes un mayor impacto en el sistema, tales [Vardanega98] de los modos de fallo. como la seguridad y la fiabilidad. • Vardanega. T. Development of on-board real- time systems: an engineering approach. PhD Tras la aplicación de SFMEA y Las técnicas de prevención, toleran- Thesis. Technical University of Delft. 1998. SFTA debe realizarse una evaluación cia y eliminación de fallos del softwa- FORUM CALIDAD 142/03 31

×