La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

CONTROL DE REQUERIMIENTOS Julio E. López Medina, Ph. D.

Presentaciones similares


Presentación del tema: "CONTROL DE REQUERIMIENTOS Julio E. López Medina, Ph. D."— Transcripción de la presentación:

1 CONTROL DE REQUERIMIENTOS Julio E. López Medina, Ph. D.

2 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

3 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

4 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

5 2. Conceptos Básicos Requerimientos Del negocio / usuario / externos Funcionales / no funcionales Software / comunicaciones / presentación De calidad / seguridad / soporte Restricciones Necesidad

6 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)

7 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.

8 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

9 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

10 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

11 3. Un sistema de control de requerimientos Repositorio de requerimientos Atributos Tipo Estado Soporte a la historia Informes de control

12 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

13

14

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 6. Conclusiones Método simple para asegurar la construcción del software adecuado Requirements management made easy, Alan Davis, Ed Yourdon, Ann Zweig, 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 ppt "CONTROL DE REQUERIMIENTOS Julio E. López Medina, Ph. D."

Presentaciones similares


Anuncios Google