CONTROL DE
REQUERIMIENTOS
Julio E. López Medina, Ph. D.
[email protected]
CONTENIDO
1.
2.
3.
4.
5.
6.
Introducción
Conceptos Básicos
Un Sistema de Control de Requerimientos
Alcance y Usos
Evaluación de la experiencia
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ásicos
Requerimiento:
• 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ásicos
Requerimiento:
• Descripción
• Prioridad
• Tipo / clasificación
• Especificación
–
–
–
–
–
–
Alcance
Restricciones
Casos especiales
Casos de prueba
Criterios de aceptación
...
• Estado
2. Conceptos Básicos
Administración y control de la configuración del
proyecto de software
Objetivo: 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ón
Objetivo: 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
Modelo del
Ciclo de vida
Registro de errores y
nuevas funcionalidades
Temas resueltos son
cerrados
Revisión y
asignación de
prioridades
Temas pendientes son
reabiertos
Control de calidad
verifica y certifica
Desarrollo corrige
y agrega nuevas
funcionalidades
Desarrollo genera
nueva versión
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 experiencia
Problemas 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 experiencia
Problemas 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 experiencia
Problemas 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 experiencia
Problemas 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 them
Sim 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
Descargar

CONTROL DE REQUERIMIENTOS