Según Presuman, en su libro “Ingeniería de Software, un enfoque practico” (1998)”
“La inspección también es conocida como revisión técnica formal, y es el punto de vista mas efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los ingenieros de software u otras personas. Para los ingenieros la inspección es un medio efectivo para descubrir errores y mejorar la calidad del software” (p.165)
VALIDACIÓN
Es el proceso de control que asegura que el software cumple con su especificación y satisface las necesidades del usuario Muchas veces se confunde “verificación” con validación”. Boehm (1979) puso en claro con pocas palabras la diferencia: • Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto satisface los requerimientos del usuario • Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que el producto conforma su especificación inicial.
En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.
No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.
Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:
- ¿Están incluidas todas las funciones requeridas por el cliente? (completa)
- ¿Existen conflictos en los requerimientos? (consistencia)
- ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
- ¿Está cada requerimiento claramente representado? (entendible)
- ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible)
- ¿Está la SRS escrita en un lenguaje apropiado? (clara)
- ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
- ¿Está claramente definido el origen de cada requisito? (rastreable)
- ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)
DETECCION DE CONFLICTOS
La detección de conflictos es una herramienta analítica que automatiza el proceso de detección de conflictos. ProjectWise Schedule Simulation permite identificar grupos de elementos comerciales o gráficos y detectar conflictos geométricos entres este grupo de elementos objeto. Después puede revisar interactiva y gráficamente estos conflictos. Las reglas de supresión se pueden aplicar para identificar conflictos que no deben ser informados. Los ajustes asociados con los conflictos de ejecución se administran y siguen como un trabajo de conflicto. Un trabajo es un contenedor de criterios, de reglas y resultados, que se configuran y guardan en el archivo activo para su reutilización. Un trabajo se pueden almacenar en una biblioteca DGN. Un trabajo se puede definir y procesar en archivo sólo de lectura, pero la definición y los resultados del trabajo
no pueden ser almacenados.DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE
Es la declaración oficial de lo que es requerido para que el sistema sea desarrollado. Incluye la definición y especificación de requerimientos. No es un documento de diseño. Tanto como sea
posible, es un conjunto de lo que es el sistema y como lo hará.
- CREACIÓN USOS E IMPORTANCIA
El proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (por ejemplo, la resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño (líneas de código) o costo: de «pequeño», «mediano» y «gran porte». Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula y provee una aproximación de todos los costos de producción en un «proyecto software» (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.).
Considerando los de gran porte, es necesario realizar complejas tareas, tanto técnicas como de gerencia, una fuerte gestión y análisis diversos (entre otras cosas), la complejidad de ello ha llevado a que desarrolle una ingeniería específica para tratar su estudio y realización: es conocida como Ingeniería de Software.
A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras.
Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.
