Completitud Ingenieria de Requisitos
Páginas: 6 (1297 palabras)
Publicado: 17 de mayo de 2016
Completitud en la Ingeniería de Requisitos
Cuando proyectos de software de gran envergadura fracasan (ver cuadro), habitualmente se llevan a cabo estudios posteriores para identificar las causas de dichos fracasos. Algunos de estos estudios son realizados por The Standish Group con sus denominados reportes CHAOS, por U.S. Government Accountability Office (GAO) de los Estados Unidos y pormuchos investigadores en el área de la ingeniería de software [Faulk 92] [Lutz 93] [Leveson 95] [Finkelstein 96] [Breitman 99]. Una de las principales causas detectadas a través de estos estudios han sido problemas en los requisitos: requisitos inadecuados, cambios en los requisitos durante el ciclo de vida, requisitos no bien comprendidos o comprendidos tardíamente y requisitos incompletos.
Laincompletitud es uno de los graves problemas que se afronta en la fase de producción de requisitos [Kotonya 98] [Loucopoulos 95] [Firesmith 05], lo que inevitablemente se arrastra a las siguientes fases del proceso de desarrollo de software si no es atendida oportunamente. No es una tarea trivial detectar información faltante. Procurar la completitud de los requisitos, es por un lado un aspecto decalidad y por otro requiere una comprensión acabada del problema bajo estudio.
Entendamos qué es la incompletitud de los requisitos
El problema de la incompletitud reside básicamente en la dificultad en establecer si se ha elicitado y modelado toda la información requerida para desarrollar un sistema de software que cubra las expectativas y necesidades de los clientes y usuarios. Es decir, esteproblema se vincula directamente con un tipo específico de defecto: las omisiones. En un estudio realizado por Basili y Weiss [Basili 81] se presentó que el 31% de los errores en los requisitos provenían de omisiones.
Kotonya y Sommerville [Kotonya 98] entienden que la completitud significa que ningún servicio o restricción necesarios han sido omitidos. Loucopoulos y Karakostas [Loucopoulos95] amplían este concepto cuando mencionan que un modelo de requisitos está completo cuando no se omite información esencial acerca del dominio de la aplicación.
El estándar internacional IEEE Std 830 [IEEE Std 830-1998] menciona a la completitud como una de las características necesarias de un buen documento de definición de requisitos.
El estándar indica que un documento de requisitos escompleto si y solo si incluye los siguientes elementos:
a. Todos los requisitos significativos, ya sea relacionados con funcionalidad, rendimiento, limitaciones de diseño, atributos o interfaces externas.
b. Definición de las respuestas del sistema a todas los tipos posibles de entradas en todo tipo de situaciones posibles. Es importante especificar las respuestas tanto a valores de entrada válidos einválidos.
c. Referencias completas a todas las figuras, tablas y diagramas en el documento de requisitos, y definición de todos los términos y unidades de medida.
Donald Firesmith distingue entre la completitud del modelo de requisitos y la completitud individual de los requisitos [Firesmith 05]. El primero se refiere a la omisión total de uno o varios requisitos, mientras que el segundo serefiere a la falta de información necesaria para que el requisito no sea ambiguo y se pueda implementar sin requerir información adicional. Ambos tipos de completitud deberían ser tratados con el mismo nivel de importancia.
Cómo hacer frente a la incompletitud
No es esperable alcanzar la completitud de los requisitos, como menciona Julio Leite: «El proceso de definir requisitos es inherentementeincompleto, teniendo en vista la gran complejidad del mundo real. Es obvio, por lo tanto, que siempre estaremos procurando tener requisitos lo más completos posible.» [Leite 01]
Un potencial camino es poder decidir si ya se ha realizado una elicitación y un modelado suficiente para construir un software de calidad, concepto conocido como “reglas de parada” (stopping rules), referidas a los...
Cuando proyectos de software de gran envergadura fracasan (ver cuadro), habitualmente se llevan a cabo estudios posteriores para identificar las causas de dichos fracasos. Algunos de estos estudios son realizados por The Standish Group con sus denominados reportes CHAOS, por U.S. Government Accountability Office (GAO) de los Estados Unidos y pormuchos investigadores en el área de la ingeniería de software [Faulk 92] [Lutz 93] [Leveson 95] [Finkelstein 96] [Breitman 99]. Una de las principales causas detectadas a través de estos estudios han sido problemas en los requisitos: requisitos inadecuados, cambios en los requisitos durante el ciclo de vida, requisitos no bien comprendidos o comprendidos tardíamente y requisitos incompletos.
Laincompletitud es uno de los graves problemas que se afronta en la fase de producción de requisitos [Kotonya 98] [Loucopoulos 95] [Firesmith 05], lo que inevitablemente se arrastra a las siguientes fases del proceso de desarrollo de software si no es atendida oportunamente. No es una tarea trivial detectar información faltante. Procurar la completitud de los requisitos, es por un lado un aspecto decalidad y por otro requiere una comprensión acabada del problema bajo estudio.
Entendamos qué es la incompletitud de los requisitos
El problema de la incompletitud reside básicamente en la dificultad en establecer si se ha elicitado y modelado toda la información requerida para desarrollar un sistema de software que cubra las expectativas y necesidades de los clientes y usuarios. Es decir, esteproblema se vincula directamente con un tipo específico de defecto: las omisiones. En un estudio realizado por Basili y Weiss [Basili 81] se presentó que el 31% de los errores en los requisitos provenían de omisiones.
Kotonya y Sommerville [Kotonya 98] entienden que la completitud significa que ningún servicio o restricción necesarios han sido omitidos. Loucopoulos y Karakostas [Loucopoulos95] amplían este concepto cuando mencionan que un modelo de requisitos está completo cuando no se omite información esencial acerca del dominio de la aplicación.
El estándar internacional IEEE Std 830 [IEEE Std 830-1998] menciona a la completitud como una de las características necesarias de un buen documento de definición de requisitos.
El estándar indica que un documento de requisitos escompleto si y solo si incluye los siguientes elementos:
a. Todos los requisitos significativos, ya sea relacionados con funcionalidad, rendimiento, limitaciones de diseño, atributos o interfaces externas.
b. Definición de las respuestas del sistema a todas los tipos posibles de entradas en todo tipo de situaciones posibles. Es importante especificar las respuestas tanto a valores de entrada válidos einválidos.
c. Referencias completas a todas las figuras, tablas y diagramas en el documento de requisitos, y definición de todos los términos y unidades de medida.
Donald Firesmith distingue entre la completitud del modelo de requisitos y la completitud individual de los requisitos [Firesmith 05]. El primero se refiere a la omisión total de uno o varios requisitos, mientras que el segundo serefiere a la falta de información necesaria para que el requisito no sea ambiguo y se pueda implementar sin requerir información adicional. Ambos tipos de completitud deberían ser tratados con el mismo nivel de importancia.
Cómo hacer frente a la incompletitud
No es esperable alcanzar la completitud de los requisitos, como menciona Julio Leite: «El proceso de definir requisitos es inherentementeincompleto, teniendo en vista la gran complejidad del mundo real. Es obvio, por lo tanto, que siempre estaremos procurando tener requisitos lo más completos posible.» [Leite 01]
Un potencial camino es poder decidir si ya se ha realizado una elicitación y un modelado suficiente para construir un software de calidad, concepto conocido como “reglas de parada” (stopping rules), referidas a los...
Leer documento completo
Regístrate para leer el documento completo.