Ingeniería de Software IV: Requerimientos

Transcripción

1 Ingeniería de Software IV: Requerimientos Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María <hernan at inf.utfsm.cl>

2 Instructor Hernán Astudillo Oficina: F.1.18 Alternado con Marcello Visconti Horario & materiales Lu 15/mar-Vi 25/jun; Ma 7-8 y 9-10; sala C.2.40 Presentación Lecturas: capítulos de textos (para fotocopiar) Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 2

3 Administrivia Viaje el 6/abril Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 3

4 Introducción Proceso y ciclo de vida Manejo de proyectos Análisis de Requerimientos Arquitectura y Diseño Contenidos hasta ahora Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 4

5 IV: Requerimientos Introducción y Motivación Proceso Levantamiento Especificaciones Tipos y Características Técnicas de Descripción Estáticas, Dinámicas, O.O., otras Prototipos Documentación Participantes Validación Métricas Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 5

6 Introducción Ideas-fuerza Hay que saber lo que hay que hacer antes de ponerse a hacerlo Conocer el problema antes de inventar la solución Propósito: Reducir el riesgo de construcción Efectividad: riesgo de hacer algo inútil Eficiencia: riesgo de sub-/sobre-estimar recursos Problema: Parálisis de análisis Querer saberlo todo antes de hacer nada Ideas revolucionarias? U obvias? Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 6

7 Revolucionario u obvio? Estudio de 8000 proyectos en EUU En plazo y costo: 9%-16% Retrasados/excedidos: 53%-60% Cancelados (abortados): 31% Porqué fueron cancelados? Requerimientos incompletos: 13% Falta de participación del usuario: 12% Falta de recursos: 11% Expectativas descontroladas: 10% Falta de apoyo gerencial: 9% Requerimientos inestables: 9% Falta de planificación: 8% Obsolescencia pre-parto: 7% Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 7

8 Más argumentos Cuantificación de Impacto Costo de reparar errores en los requerimientos Detectado durante análisis: $X Detectado durante diseño: $5X Detectado durante construcción: $10X Detectado durante prueba: $20X Detectado después de entregado: $100X-$200X Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 8

9 Requerimientos y riesgo Para qué estudiamos requerimientos? Para reducir el riesgo de construcción (R1) Efectividad: riesgo de hacer algo inútil (R2) Eficiencia: riesgo de sub-/sobre-estimar recursos Clasifiquemos las causas de cancelación Requerimientos incompletos: 13% (R1) Falta de participación del usuario: 12% (R1) Falta de recursos: 11% (R2) Expectativas descontroladas: 10% Falta de apoyo gerencial: 9% Requerimientos inestables: 9% Falta de planificación: 8% (R2) Obsolescencia pre-parto: 7% (R1) Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 9

10 Proceso Requerimiento : atributo del sistema Algo que el sistema debe ser capaz de hacer para cumplir su propósito Tipos clásicos de requerimientos Funcionales : describen tareas específicas que el sistema debe ser capaz de hacer p.ej.: imprimir cheques de sueldos No-funcionales (restricciones): limitan nuestras opciones para construir una solución p.ej.: generar cheques máx. 4 hrs después de recibir listados de contabilidad Analogía Requisitos funcionales: los verbos (Xear) Requisitos no-funcionales: los adverbios (Xmente) Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 10

11 Proceso [2] 1. Levantamiento y análisis Análisis del problema Hemos capturado todas las necesidades del usuario? Descripción del problema Estamos usando las técnicas apropiadas? Prototipo y prueba Es esta solución factible? 2. Definición y especificación de requerimientos Documentación y validación Hemos capturado lo que el usuario espera? Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 11

12 Levantamiento y análisis Idea: determinar lo que el cliente realmente quiere OJO: determinar QUÉ hacer, no CÓMO hacerlo (aún) Un enfoque: identificar gente, procesos y recursos que apoyan el sistema actual (socio-técnico) documentar sus relaciones e interacciones Priorizar requerimientos 1. Esenciales (deben ser cumplidos) 2. Deseables pero no esenciales 3. Opcionales pero eliminables Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 12

13 Fuentes de requerimientos Modelos de situación actual Modelos de dominio Necesidades y deseos de los clientes y usuarios Organización y sistemas actuales Documentos existentes Tipos sugeridos de requerimientos (plantillas) Requerimientos reusables (bibliotecas de reuso) Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 13

14 Formas de elicitar requerimientos Revisar situación actual Examinar documentación existente (incluso mala) Identificar estructuras y patrones comunes Trabajar en el ambiente del usuario Entrevistas usuarios actuales y potenciales Hacer brainstorm con usuarios y/o clientes etc. ( técnicas creativas!!) Sesión 01 [2004/iii/30] Ingeniería de Software - H.Astudillo 14