CONTROL DE REQUERIMIENTOS Julio E. López Medina, Ph. D. juliolopez@cable.net.co

CONTROL DE REQUERIMIENTOS

Julio E. López Medina, Ph. D.

juliolopez@cable.net.co

CONTENIDO

1. Introducción

2. Conceptos Básicos

3. Un Sistema de Control de Requerimientos

4. Alcance y Usos

5. Evaluación de la experiencia

6. Conclusiones

1. Introducción• Nivel 2 de CMM: “repetible”

– Control de requerimientos

– Planeación de proyectos

– Seguimiento de proyectos

– Administración de la configuración

– Aseguramiento de calidad

• Nivel 3 de CMM: definida– Administración de software íntegra

– Definición de procesos

• Nivel 4 de CMM: administrada– Control de la calidad

– Administración cuantitativa de procesos

• Nivel 5 de CMM: optimizable– Control de cambios

– Prevención de defectos

2. Conceptos Básicos

• Proyectos de software– Desarrollo de una primera versión

– Mantenimiento y nuevas entregas

– Implantación

– Administración

• Requerimiento• Administración de la configuración• Cambio• Control de cambios

2. Conceptos Básicos

Requerimientos

• Del negocio / usuario / externos

• Funcionales / no funcionales

• Software / comunicaciones / presentación

• De calidad / seguridad / soporte

• Restricciones

Necesidad

2. Conceptos Básicos

Requerimiento:• Una condición o funcionalidad necesitada por un

usuario para resolver un problema o alcanzar un objetivo

• Una condición o funcionalidad que debe ser satisfecha o poseída por un sistema o por alguno de sus componentes para satisfacer un contrato, un estándar u otro documento

• Una representación documentada de cualquiera de los anteriores

IEEE Standard glossary of software engineering terminology (1997)

2. Conceptos BásicosRequerimiento:• Atómico e individual• Realizable • Verificable• Preciso, especifico y completo• No conflictivo / compatible / consistente• No traslapado • No repetido• Controlable

“Requirements management primer and capability overview”, Beaver Computer Consultants Ltd.

2. Conceptos BásicosRequerimiento:• Descripción• Prioridad • Tipo / clasificación• Especificación

– Alcance– Restricciones– Casos especiales– Casos de prueba– Criterios de aceptación– . . .

• Estado

2. Conceptos BásicosAdministración y control de la configuración del

proyecto de softwareObjetivo: Identificar en todo momento el avance del

proyecto de software• Resultados: conjunto de requerimientos a entregar• Esfuerzo estimado• Recursos requeridos• Plan detallado• Items controlados• Avance de todas las tareas• Control de versiones• CAMBIOS A LA PLANEACION

2. Conceptos Básicos

Control de Cambios a la PlaneaciónObjetivo: Mantener en todo momento el control a la

configuración del proyecto de software• Solicitud• Análisis de impacto en todas las etapas del

proyecto• Alternativas y selección• Nuevo plan

• Comité de control de cambios

3. Un sistema de control de requerimientos

Repositorio de requerimientos

• Atributos

• Tipo

• Estado

• Soporte a la historia

• Informes de control

Desarrollo genera nueva versión

Revisión y asignación de prioridades

Desarrollo corrige y agrega nuevas funcionalidades

Control de calidad verifica y certifica

Temas resueltos son cerrados

Temas pendientes son reabiertos

Registro de errores y nuevas funcionalidades

Modelo del Ciclo de vida

http://www.beaverco.dircon.co.uk/RequirementsProcess.htm

4. Alcance y usos• Identificación de necesidades

• Planeación

• Especificación

• Desarrollo

• Pruebas técnicas

• Certificación de calidad

• Entrega al cliente

• Implantación

4. Alcance y usos

• Administración cuantitativa– Número y clasificación de requerimientos

planeados / incluidos / atendidos– Uso del tiempo– Control de la configuración del proyecto de

software• Avance

• Retraso

• Resultados

– Reporte de entrega

5. Evaluación de la experienciaProblemas comunes

• “El usuario no sabe lo que realmente quiere”– Cierto– No toda necesidad es un requerimiento– No todo requerimiento debe hacerse de una sola manera– ANALISIS

• “Defina usted mis requerimientos”– Por más experimentado que sea el analista, el dueño del

negocio es quien debe definirlo

• “No tenemos tiempo ni presupuesto para definir requerimientos”– Es más costoso desarrollar sin una especificación – Es imposible probar sin una especificación

5. Evaluación de la experienciaProblemas comunes

• “Necesitamos el sistema para dentro de dos meses”– La mejor definición de alcance está en los requerimientos

incluidos– Aseguramos el plan con el mejor estimado de lo incluido

• “Esto es tan novedoso que no se puede especificar”– Si no se puede especificar, tampoco se puede construir

• “Los usuarios no están de acuerdo sobre lo que necesitan. Cada uno desea algo diferente.”– Es más costoso revisar un desarrollo o un prototipo que una

especificación

• “Eso suena muy académico y no estamos en una universidad. Somos una empresa de desarrollo.” – La especificación se concentra en la necesidad del usuario

5. Evaluación de la experienciaProblemas comunes

• “Los usuarios no tiene tiempo para revisar la especificación”– La revisión de todas las versiones de software les tomará

aún más tiempo

– Como asegurar que sus necesidades están incluidas?

• “En lugar de definir y analizar requerimientos, hagamos un prototipo”– ¿Y sobre que bases hacemos el prototipo?

– Si el prototipo es completo en funcionalidad, servirá de base para la evaluación de su arquitectura

5. Evaluación de la experienciaProblemas comunes

• “Los ingenieros se toman mucho tiempo registrando en el sistema los requerimientos”– En algún lado debemos registrar lo que hacemos– Los usuarios deben iniciar el proceso

Referencias:Deborah Mayhew's tutorial on the Usability Engineering

Lifecycle presented at CHI'99 in Pittsburgh

13 common objections against user requirements analysis, and why you should not believe themSim D'Hertefelt, 9 June 2000, InteractionArchitect.com

6. Conclusiones• Herramienta de apoyo durante todo el ciclo de

vida de los proyectos• Metodología flexible adaptable a cada tipo de

requerimiento• Herramienta independiente de la metodología de

desarrollo• Autocontrol vs control externo para los

desarrolladores• Repositorio de Lecciones Aprendidas

6. Conclusiones• Método simple para asegurar la construcción del software adecuado

“Requirements management made easy”, Alan Davis, Ed Yourdon, Ann Zweig, 2000. Omni-Vista, Inc.

IEEE Standard glossary of software engineering terminology (1997)“Requirements management primer and capability overview”, Beaver Computer Consultants

Ltd.Deborah Mayhew's tutorial on the Usability Engineering Lifecycle presented at CHI'99 in

Pittsburgh “Instilling Quality Improvement “, Joshua Klein, Yigal Cohen, NDS Technologies, Israel“13 common objections against user requirements analysis, and why you should not believe

them”, Sim D'Hertefelt, 9 June 2000, InteractionArchitect.com