Breve revisin de trabajos sobre validacin de requerimientos de software. Validacin de Requerimientos a travs de Modelos Conceptuales.

En el trabajo titulado: "Validacin de Requerimientos a travs de Modelos Conceptuales", desarrollado por Marcelo Marciszack, Marina Crdenas, Claudia Castro y Ramiro Prez; publicado para 2012 en el XIV Workshop de Investigadores en Ciencias de la Computacin. El objetivo de este trabajo era implementar una herramienta que permita gestionar y validar requerimientos de software, que ayudar a definir los lmites del sistema al momento de formular los requerimientos, controlar y optimizar los procesos, y proveer al grupo de desarrollo una base para la estimacin del tiempo y costo del desarrollo de sistemas de software, permitiendo as conocer el estado del proyecto y el impacto de los cambios en caso de ser requeridos. Dos de los objetivos generales que se propusieron fueron: Establecer marco terico metodolgico de tcnicas para verificar y validar especificaciones de requerimientos de software. Construir e implementar una herramienta de software para la gestin de requerimientos, haciendo especial nfasis en la validacin de los mismos. En este artculo el Departamento de Ingeniera en Sistemas de Informacin de la Universidad Tecnolgica Nacional, Facultad Regional Crdoba manifiesta su intencin por dar solucin a uno de los principales problemas de la ingeniera en sistemas relacionado a la elicitacin y especificacin de requerimientos, que vincula las distintas etapas del proceso de desarrollo de software manteniendo la trazabilidad de estos requerimientos hasta la validacin e implementacin de los mismos. Se seala siguiendo a Jackson (1995) que para validar requerimientos se deben llevar a cabo verificaciones por requerimiento en el documento de Especificacin de Requerimientos del Software (SRS), que dichas verificaciones comprenden: 1. Verificaciones de validez. 2. Verificaciones de consistencia. 3. Verificaciones de integridad. 4. Verificaciones de realismo. 5. Verificabilidad. Sugieren que existen varias tcnicas de validacin (i.e. Revisiones de requerimientos, Construccin de prototipos, Generacin de casos de prueba y Anlisis automtico de consistencia), pero de acuerdo con Kotonya (1998), Insfrn, et. al. (2001) y Leonardi, et. al. (2001), en su trabajo se centraron en la construccin de modelos conceptuales basados en los requerimientos para poder realizar la validacin. Sus premisas requeridas para el proceso de validacin fueron: Contar con una especificacin formal de los requerimientos. Aseguramiento de la calidad del software fijando la atencin en prevencin de defectos en el proceso de desarrollo del software ms que en probar la calidad del cdigo del software despus que se escribe. Garantizar tiempo y esfuerzo para la validacin, que debe comenzar con anticipacin; es decir, durante la planificacin del diseo y desarrollo y el diseo de la entrada de datos.

Tener siempre a la mano el ciclo de vida del software, ya que contiene las tareas de ingeniera de software y la documentacin necesaria para soportar la validacin del software. Definicin y control de la validacin a travs de un plan. Realizar a travs del uso de procedimientos documentados. Validar los requerimientos de software despus de un cambio. El alcance de la validacin debe estar basado en la complejidad del software y en los riegos de seguridad; no en el tamao de la organizacin o la restriccin de los recursos. Las actividades de validacin deban ser conducidas cumpliendo el precepto bsico de gestin de la calidad sobre la "independencia de la revisin", ya que la autovalidacin es sumamente difcil. Flexibilidad y responsabilidad del desarrollador del software a la hora de escoger como aplicar estos principios de validacin, porque puede ser muy diferente de una aplicacin a otra; pero se debe demostrar que el software se ha validado. Validating Requirements (Validacin de requerimientos) Publicado por Karl Wiegers el Mi, 11 de julio 2012 Business Analysis & Requirements Management Blog http://blog.enfocussolutions.com/Powering_Requirements_Success/bid/146509/ Validating-Requirements En este artculo, Wiegers adapta de su libro "Software Requirements", 2nd Edition (Microsoft Press, 2003), para describir la importancia de la validacin de los requerimientos y algunas tcnicas valiosas que probar. Al no obtener la informacin necesaria, los desarrolladores tienen que hacer sus propias interpretaciones, que no siempre son correctas. Se requiere un esfuerzo sustancial de corregir los errores por requerimientos descubiertos despus de que ya se ha desarrollado con los requerimientos iniciales. Todas las medidas que puede tomar para detectar errores en las especificaciones de requerimientos ahorrarn mucho tiempo y dinero. Wiegers define "Validacin de requerimientos" como el cuarto componente (luego de elicitacin, anlisis, y especificacin de los requerimientos de desarrollo). Validacin equivale evaluar si un producto realmente satisface las necesidades de los clientes (hacer lo correcto). En contraste, la verificacin determina si el producto de una actividad de desarrollo cumple con los requerimientos establecidos para ello (otra dimensin diferente de hacer lo correcto). Sugiere que ambas actividades son vitales para el desarrollo de productos exitosos. La validacin de requerimientos garantiza: El SRS describe correctamente las capacidades previstas del sistema y caractersticas que satisfagan las necesidades de los distintos grupos de inters. Los requerimientos de software se obtuvieron correctamente de los requerimientos del sistema, reglas de negocio, o de otras fuentes. Los requerimientos estn completos y sean de alta calidad. Todos los requerimientos y sus representaciones son coherentes entre s. Los requerimientos proporcionan una base adecuada para proceder con el diseo y la construccin.

La validacin asegura que los requerimientos presentan caractersticas deseables de excelentes declaraciones requerimientos (completos, correctos, viables, necesarios, priorizados, sin ambigedades, y verificables) y de excelentes especificaciones de requerimientos (completos, coherentes, modificables, y trazables). Se pueden validar nicamente requerimientos que se han documentado, no requerimientos implcitos que slo existen en la mente de alguien. Se acerca ms a la realidad al escribir los detalles de los requerimientos en lugar de confiar en los recuerdos humanos imperfectos. Algunas de las actividades de validacin, tales como las revisiones adicionales del crecimiento del SRS, se enhebran a travs de las fases de elicitacin, anlisis y especificacin de los procesos iterativos. Otras actividades, como la inspeccin formal del SRS, ofrecen una puerta de calidad final antes de la lnea de base del SRS. Si bien las actividades de validacin requieren de la dedicacin de tiempo de calidad, reditan considerablemente en para acortar los calendarios de entrega, reduciendo el retrabajo necesario y acelerando la integracin de sistemas y pruebas. Mejores requerimientos conducen a una mayor calidad del producto y la satisfaccin del cliente, lo que reduce los costos del producto de por vida para el mantenimiento, la mejora y atencin al cliente. Invertir en calidad de requerimientos siempre ahorra ms dinero del que se gasta. No es conveniente pensar en las pruebas como algo de ltima etapa, ya que hay problemas relacionados a los requerimientos que con este pensamiento continan en el producto hasta que son revelados a travs de las pruebas o por el cliente. Por el contrario si se planean las pruebas y el desarrollo de casos de prueba a tiempo, se van a detectar muchos errores poco despus de que se introdujeron. Esto les impide hacer ms dao y reduce la fase de pruebas de integracin y el mantenimiento. Una buena prctica sera planear el comienzo de las actividades de prueba y el desarrollo de los casos preliminares de prueba durante la fase de del desarrollo correspondiente, durante el desarrollo de los requerimientos se pueden realizar los casos de prueba conceptual con base en los requerimientos (porque son independientes de la implementacin), esto revelar errores, ambigedades y omisiones en las especificaciones del SRS y los modelos de anlisis, mucho antes que el equipo escriba ningn cdigo. Se deben revisar los requerimientos, ya que en el momento de ser redactados pueden tener mucho sentido para quien los est escribiendo, pero pueden causar confusin en alguno de los stakeholders, es por eso que algunos representantes de los usuarios son especialmente adecuados para la validacin de la exactitud de cada requerimiento. Los desarrolladores y probadores pueden examinar los requerimientos para evaluar si comprenden cada uno lo suficientemente bien como para hacer su parte del trabajo del proyecto sobre la base de ese requerimiento. La tcnica estructurada y disciplinada de la inspeccin proporciona una forma para que varios revisores comparen sus interpretaciones y se aseguren de que entienden cada requerimiento de la misma manera. Esto es algo que simple, consiste en pasar los requerimientos a varios revisores y preguntar qu no les complace? Wiegers tambin sugiere en esta lectura que en un libro que escribi sobre la revisin entre pares Peer Reviews in Software: A Practical Guide (AddisonWesley, 2002), proporciona recomendaciones para sacar ms provecho a la revisin de requerimientos, as como en dos publicaciones anteriores de blog tituladas "Two Eyes Arent Enough" (Dos ojos no son suficientes), partes uno y dos.

Como la mayora de las personas tiene dificultades para imaginar cmo se ver y cmo se comportar un nuevo sistema a partir slo de la lectura de una especificacin de requerimiento (en texto), Wiegers sugiere que son los prototipos la manera de traerlos a la vida y hacerlos ms tangibles para solicitar a los usuarios sus comentarios. Un prototipo representa una forma parcial, preliminar, o posible para mostrar cmo se respondera a un requerimiento, o a un conjunto particular de estos. Los prototipos pueden ser estticos o dinmicos, ya sean electrnicos o en papel, evolutivos o desechables. Cuando se crea un prototipo, se est dando un paso provisional en el espacio de soluciones. Mientras no se confirme la construccin del software de una manera particular, un prototipo es una excelente herramienta para la validacin de requerimientos. Los usuarios pueden interactuar con prototipos, simulando as sus interacciones con el sistema definitivo, para ver si un sistema a partir de los requerimientos establecidos sera realmente satisfactorio de sus necesidades. Dado que los clientes realizan las pruebas de aceptacin para determinar si un sistema satisface sus criterios de aceptacin y que pagan por un producto desarrollado bajo contrato; las pruebas de aceptacin, deben evaluar si el producto cumple los requerimientos documentados y si es adecuado para su uso en el entorno operativo. Incluir entonces a los usuarios en el diseo de las pruebas de aceptacin es una estrategia efectiva y entre ms pronto se use, ms pronto empezarn a filtrar los defectos. Por tal motivo algunas metodologas de desarrollo de gil emplean pruebas de aceptacin del usuario, en lugar de escribir los requerimientos funcionales detallados. Las pruebas de aceptacin deben centrarse en los escenarios previstos representados en los Casos de Uso, los usuarios clave deben tener en cuenta los escenarios ms utilizados y ms importantes al momento de decidir la forma de evaluar la aceptabilidad del software. Las pruebas de aceptacin deben centrarse en los cursos normales de los casos de uso, y no en los cursos alternativos menos comunes o si el sistema se encarga de todas las condiciones de excepcin correctamente. Wiegers tambin seala que automatizar las pruebas de aceptacin siempre que sea posible hace que sean ms fcil para repetir cuando se realizan cambios y funcionalidad adicional se agrega en futuras versiones. Las pruebas de aceptacin tambin deben hacer frente a los requerimientos no funcionales. Deben asegurarse de que las metas de rendimiento se obtienen en todas las plataformas, que el sistema cumpla con los estndares de usabilidad, y que se cubren todas las necesidades de los usuarios comprometidos. Debe hacerse un cambio en la perspectiva del stakeholder "Qu es lo que tiene que hacer con el sistema?" a "Cmo juzgar si el sistema satisface las necesidades?". Si el cliente no puede expresar cmo iba a evaluar la satisfaccin de la demanda especfica del sistema, este requerimiento no se indica con suficiente claridad. Sin embargo, tenga en cuenta que las pruebas de aceptacin de los usuarios no sustituye las pruebas del sistema basado en los requerimientos integral, que abarca tanto los caminos normales y de excepcin y una amplia variedad de combinaciones de datos que los usuarios podran no pensar. Escribir requerimientos simplemente, no es suficiente, es necesario asegurar que son los adecuados y que son suficientemente buenos para servir de base del diseo, construccin, gestin del desarrollo y pruebas. Entonces las pruebas de aceptacin, la revisin por pares, la evaluacin de requerimientos en prototipos y la aplicacin de tcnicas eficientes de prueba, ayudan a construir software de mayor calidad, ms rpidamente y ms barato de lo que nunca antes se haba hecho, concluye Wiegers.

Verification & Validation: Am I building the thing right? Am I building the right thing? (Verificacin y Validacin: Estoy construyendo lo correcto? Lo estoy construyendo correcto?) En este documento John W. Marca expone los conceptos de verificacin de validacin en el proceso de desarrollo de software, dejando claro que la verificacin se hace sobre productos finales o de fase dadas las condiciones impuestas al inicio, de la fase por ejemplo; mientras que la validacin es un proceso de evaluacin durante y al final del proceso de desarrollo de software para determinar si se cumple con los requerimientos especificados y si estos son los adecuados. A medida que se avanza la lectura se recuperan las aseveraciones de la lectura anterior con lo que se refueza la importancia y riqueza del proceso de validacin. Las tcnicas de validacin que aqu se proponen con sus variantes y elementos son: Revisiones Tutorial Inspeccin Listas de verificacin

Pruebas Conceptuales Criterios de Aceptacin Modelo Tutorial

Prototipos La revisin tutorial es un proceso informal. Un grupo de colegas se renen. El documento de requerimientos se revisa con el grupo reunido y los comentarios se solicitan. Por lo general, el autor de cada requerimiento dirige la discusin en torno a ste. (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) La revisin por inspeccin puede ser una reunin informal o un proceso formal: Informal - requerimientos son inspeccionados despus de cada Grupo JAD / Focus. Formal - todo el documento de requerimientos es inspeccionado despus de haber sido escrito. Los equipos pequeos se reunieron para examinar los requerimientos, se debe incluir a los usuarios finales para asegurarse de que los requerimientos son verificables y pueden servir de base para el Usuario al disear sus Pruebas de aceptacin. Los miembros del equipo inspeccionan el documento antes de la reunin formal.

Cada requerimiento se lee en voz alta en una forma parafraseada, los defectos y los problemas potenciales son sealados por los participantes. Los defectos y los problemas se registran formalmente y se presentan a los requerimientos de autor. Roles en las reuniones: Autor Moderador Reader (un inspector) Grabadora Inspectores (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) La revisin por listas de verificacin se lleva a cabo mediante un desarroll al cliente, personalizado para el proyecto. Contendr las listas de caractersticas y funciones. Se indican todas las condiciones bajo las cuales se aplica un requerimiento. Cada requerimiento debe describir con precisin la funcionalidad que se construir. El requerimiento puede ser probado para asegurar que cumple con las medidas de xito. ste es atribuible a una meta establecida en un proyecto de iniciacin de documentos, tales como: Carta de Proyecto Caso de Negocio Alcance del Proyecto El requerimiento es necesario para permitir que la solucin cumpla con las metas y objetivos de negocio. El requerimiento se rastrea a un cliente o usuario especfico. El requerimiento, como se ha dicho, tiene una sola interpretacin. (Hass, Kathleen, et.al., 2008, Obtenga lo correcto: Requerimientos de Negocio, Tcnicas y Herramientas de Anlisis) Pruebas conceptuales, Karl Wiegers establece que, "Las pruebas y tienen una relacin sinrgica, ya que representan visiones complementarias del sistema". En el modelo en V las pruebas de aceptacin se asocian con los requerimientos para el desarrollo. El modelo V es un esquema de desarrollo de software que se basa en las relaciones entre cada fase del ciclo de vida de desarrollo, como se describe en un modelo de desarrollo de software de cascada tpico y sus fases estn asociadas a de las pruebas. Puede empezar a derivar los casos de prueba conceptuales a partir de: Casos de uso Requerimientos de: Negocio Usuario Funcionales Puede utilizar los casos de prueba para evaluar textualmente los requerimientos, con modelos de anlisis y por prototipos. (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) "Los criterios de aceptacin - y por lo tanto las pruebas de aceptacin beben evaluar si el producto cumple su requerimientos documentados y si es apto para su uso en el entorno operativo".

"Es un cambio en la perspectiva de los requerimientos de obtencin pregunta de Qu es lo que tiene que hacer con el sistema? a Cmo juzgar si el sistema satisface sus necesidades?" "Si el cliente no puede expresar cmo iban a evaluar la satisfaccin en el sistema de un requerimiento particular, este requerimiento no se indica con suficiente claridad (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) Para definir las condiciones para aceptar el sistema, los usuarios deben ser guas para describir de manera ms explcita la forma en que esperan que el software funcione. Para esto se deben identificar: Funciones (requerimientos funcionales), Atributos de calidad (requerimientos no funcionales), Los resultados esperados de un conjunto de entradas definido. Se debe pensar en la pregunta "Cmo va a juzgar si el sistema satisface sus necesidades?" La participacin de los usuarios es fundamental, los criterios se basan a menudo en: La capacidad del usuario para realizar tareas especficas y, La capacidad del sistema para satisfacer ciertos atributos de calidad. Cada criterio debe tener 1 o ms Casos de prueba de aceptacin. (Gottesdiener, Ellen, 2005, Los requerimientos de software entrenadores de la memoria) Las fuentes de las pruebas de aceptacin provienen de: Casos de uso, Requisitos de los modelos de anlisis: Uso de modelos de casos, Modelos de Procesos de Negocio, Modelos de flujo de datos. Centrarse en los escenarios de uso previstas. Considere el: Los casos de uso ms utilizados (flujo normal), Los casos de uso ms importantes. Restar importancia a Flujos Alternos, Manejo de Excepciones. (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) En el modelo tutorial se utiliza simulaciones de prueba para pasar por los modelos de anlisis. Se simula el funcionamiento del sistema sin tener que probar el cdigo. Para qu? Buscar etapas que faltan, Encontrar datos perdidos, Encontrar faltan reglas de negocio. Identificar y crear casos de prueba. Seleccione el modelo de anlisis a validar, trace los casos de prueba a travs del modelo de una manera paso a paso y corrija el modelo de requerimientos, segn sea necesario. (Gottesdiener, Ellen, 2005, Los requerimientos de software entrenadores de la memoria)

Los prototipos constituyen una maqueta del nuevo sistema, traen casos de uso a la vida. Cierran brechas en la comprensin de las necesidades y ayudan a las partes interesadas lleguen a un entendimiento comn de los requerimientos del sistema. (Wiegers, Karl E., 2003, Requerimientos de software, 2 ed.) Con los prototipos se evala la viabilidad de los atributos de calidad, se detecta las funcionalidades innecesarias. Se detecta los pasos que faltan, ejercitan las Interfaces y se revelan requerimientos faltantes, errneos y factibles. Hay que determinar qu requerimientos validar mediante el uso de un prototipo, luego desarrollar el prototipo y evaluar el prototipo. (Gottesdiener, Ellen, 2005, Los requerimientos de software entrenadores de la memoria)

Fuentes primarias:

Validacin de Requerimientos a travs de Modelos Conceptuales

by Marcelo Marciszack, et. al. http://sedici.unlp.edu.ar/bitstream/handle/10915/18966/Documento_completo.pdf?sequenc e=1

Validating Requirements
by Karl Wiegers on Wed, Jul 11, 2012 http://blog.enfocussolutions.com/Powering_Requirements_Success/bid/146509/ValidatingRequirements

Verification & Validation

by John W. Brand http://www.academia.edu/1306864/Verification_and_Validation

Fuentes secundarias: http://users.dsic.upv.es/~einsfran/papers/39-ideas2002.pdf http://cacic2001.info.unlp.edu.ar/Carreras/Magisters/Ingenieria_de_Software/Te sis/Leonardi_Maria.pdf