Administración de Requerimientos...documentar, coordinar y mantener los requerimientos. “La clave...
Transcript of Administración de Requerimientos...documentar, coordinar y mantener los requerimientos. “La clave...
1
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Análisis de Sistemas – 2do año
Prof. Gustavo J. Sabio
AdministraciAdministración de ón de RequerimientosRequerimientos
UNIVERSIDAD DE CONGRESOUNIVERSIDAD DE CONGRESO
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Introducción al RUPIntroducción al RUP
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
2
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Dificultades al manejar requerimientos
Clientes no siempre conocen lo que quieren
Los requerimientos no siempre son obvios
Los requerimientos pueden provenir de muchas fuentes
Es díficil mantener la relación entre los requerimientos
A veces es díficil expresarlos en palabras
Los requerimientos cambian
El uso de lenguaje técnico limita la expresión de los usuarios
Si son muchos requerimientos, se torna inmanejable e incontrolable
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Requerimientos de SoftwareRequerimientos de Software
Escencia de la Adm. de Req.
característicascaracterísticas
NecesidadesNecesidades
Procedimientos de TestProcedimientos de TestDiseñoDiseño
Documentos para usuarioDocumentos para usuario
problema
El El sistema sistema
a a construirconstruir
3
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Introducción al RUPIntroducción al RUP
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
Ir a …Ir a …
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
Introducción al RUPIntroducción al RUP
4
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Introducción al RUPIntroducción al RUP
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
Introducción a la AR
Modelando Casos de Uso
Analizar el Problema
Entender necesidades stakeholders
Definir el Sistema
Administrar el alcance
Redefinir el sistema
Administrar el cambio
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Introducción a la Administración de Requerimientos
• Definir conceptos claves de la Disciplina• Entender los beneficios
Objetivos:
5
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Definiciones
RequerimientoDescribe una condición/ capacidad de cómo el sistema debe comportarse…
…provienen de las necesidades de los usuarios, deun contrato, de estándares o de un documento de especificaciones . (RUP)
Característica deseada, propiedad o comportamiento del sistema. (UML)
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
¿Qué es la administración de requerimientos?
Es un enfoque sistémico para Encontrar, organizar , documentar, coordinar y mantener los requerimientos.
“La clave para una administración de requerimientos efectiva, esmantener una clara definición de los requerimientos mediante sus
atributos y la trazabilidad”
Permite establecer u mantener el acuerdo entre el cliente/usuario y el equipo del proyecto sobre los cambios en los requerimientos.
Definiciones
6
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
AR- Niveles de los Requerimientos
••Necesidades deNecesidades delos interesadoslos interesados Qué
Cómo
••CaracterísticasCaracterísticasdel sistemadel sistema
Qué
Cómo
••Especificación deEspecificación derequerimientos derequerimientos deSoftware (CU)Software (CU) Qué
Cómo
•• Especificaciones de diseñoEspecificaciones de diseño•• Procedimientos de pruebaProcedimientos de prueba•• DocumentaciónDocumentación
Requisitosstakeholders
Definidas en Vision.doc
Modelo CU yEspecif compl
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• El requerimiento establece el ‘qué’ más que el cómo’, aunque existen diferentes niveles de ‘qués’ y de ‘cómos’
• Existen muchos niveles de requerimientos. Dependiendo de la perspectiva generada, una especificación puede ser un requerimiento (qué) o un diseño (cómo).
Por ej: la necesidad de un stakeholder es un requerimiento para el analista. Este analista debe producir una lista de características que son requerimientos para el Especificador de casos de uso. Los CU describen que debe hacer el sistema para implementar estas características. El Especificador de CU debe producir unos cuantos casos de uso que son requerimientos para los diseñadores.
AR- Niveles de los Requerimientos
Explicación del dibujo anterior…
7
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
AR- tipos de req. y trazabilidad
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Cualidades de los requerimientos
•• VerificableVerificable•• Jerarquizable según su importanciaJerarquizable según su importancia•• Jerarquizable según su estabilidadJerarquizable según su estabilidad•• ModificableModificable•• TrazableTrazable•• EntendibleEntendible•• CorrectoCorrecto•• CompletoCompleto•• ConsistenteConsistente•• No ambiguoNo ambiguo
Cualidades de un SRSPropuestas por
RUP y IEEE
8
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Tipos de requerimientos
Clasificación Tipo
Funcionalidad Características, capacidades
Usabilidad Factores humanos, estética, localización geográfica y de recursos, ayudas
Confiabilidad Frecuencia de fallas, recuperabilidad, disponibilidad, integridad, consistencia
Performance Velocidad, eficiencia, uso de recursos
Soportabilidad Prueba, extensibilidad, adaptabilidad, mantenibilidad, compatibilidad
Precisión Precisión numérica, oportunidad de la información
Restricciones Del dominio, de la tecnología, operativas, físicas
Seguridad Accesos, políticas, ubicación de los datos, políticas
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Origen de los errores en el software
Análisis56%
Diseño27%
Programación7%
Otros10%
9
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Caracterización de los errores
Requerimientoscorrectos
Requerimientosincorrectos
Análisiscorrecto
Diseñocorrecto
Programacorrecto
Análisisincorrecto
Análisis s/req.incorrectos
Diseñoincorrecto
Diseño s/análisisincorrecto
Diseño s/análisiss/req. incorrectos
Programa nocorregible
Programacon errores
Programa conerrores ocultos
Programa conerrores ocultos
Catarata de errores de Mizuno
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Costo de corrección de errores
Costo
Etapas del ciclo de desarrollo
Incremento de100 a 1000 veces
10
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Incremento del costo de los errores
Captura de requerimientos
Mantenimiento
Prueba de aceptación
Prueba unitaria
Codificación
Análisis y diseño
1
2,5
5
10
25
100
Boehm, 1988
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Toma de requerimientos: Involucrar a todo el equipo
• Desarrolladores, testers y documentadores
¿es conveniente incluir a todo el equipo en los requerimientos?
•El equipo logra un mayor entendimientos de los requerimientos y el por qué ellos son importantes para el cliente
•Se logran más recomendaciones para estandarizar el proceso de desarrollo. Una recomendación hecha por todos provoca un fuerte involucramiento.- CMM y Constructabilidad -
11
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Factores de éxito del proyecto
• En 1998 el Standish Group relevó 365 compañías y 8000 proyectos y presentó los resultados en su informe de 1999
• Mejora en el éxito de los proyectos: 16% en 1994 vs. 26% en 1998 además de reducción de costos y tiempos
• Causas: participación de usuarios, soporte ejecutivo, claro establecimiento de los objetivos del negocio, administración de proyectos, entregables permanentes, requerimientos firmes, menor tamaño y duración del proyecto, etc.
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Éxito del proyecto según su tamaño
0
10
20
30
40
50
60
hasta $750m$750m a $1.5M$1.5M a $3M$3M a $6M$6M a $10Mmás de $10M
Standish Group, 1999
Porcentaje deéxito (%)
Tamaño del proyecto ($)
12
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Introducción al RUPIntroducción al RUP
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
Introducción
Modelando Casos de Uso
Analizar el Problema
Entender necesidades stakeholders
Definir el Sistema
Administrar el alcance
Redefinir el sistema
Administrar el cambio
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
¿En qué parte de los Requerimientos estamos?
13
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
• ¿Qué es?– Es el proceso de entender los problemas reales, las
necesidades de los usuarios y de proponer soluciones para ellas.
• ¿Cuáles son los objetivos?– Intentar un mejor entendimiento antes de comenzar con el
desarrollo– Identificar las causas (raíz de los problemas)– Ayudar a formular los requerimientos de negocio– Ayudar a encontrar la solución correcta
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
14
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Lograr el acuerdo en la definición del sistema
• Para comenzar analizar cualquier problema se debe estar seguro, de que todos los involucrados coinciden en cuál es el problema que intentan solucionar con el sistema
• ¿Cuál es el problema?– Entender la perspectiva de los clientes– Documentos del cliente– Intentar el acuerdo (no solo con el cliente,
también dentro del propio equipo de desarrollo)
RequisitosRequisitosStakeholdersStakeholders
Desarrollar Desarrollar GlosarioGlosario
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• “Un problema es la diferencia entre...
...lo percibido...
... y lo deseado”
Problema
Se debe trabajarsobre la percepción
Se debe trabajarsobre lo deseado
Se debe trabajarsobre la brecha
Gause & Weinberg
Definición de problema
Definir el problema que se debe resolver
15
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Definición del problema
Para el problema: (describir el problema)
que afecta a: (lista de interesados afectados)
y cuyo impacto es: (describir cuál es el impacto del problema)
Una solución adecuada debería proveer:
(lista de los principales beneficios de negocio claves)
VisiónVisión
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
16
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
¿Para qué sirve el Glosario?
Para definir un vocabulario común que puede ser usado en toda descripción textual del sistema, especialmente en la descripción de los casos de uso.
Definir los términos usados en el proyecto
Prevenir desentendimientos
Capturar un vocabulario común
Pasos que propone la actividad: Desarrollar la Vision
Encontrar términos comunes
Evaluar sus resultadosGlosarioGlosario
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
17
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• ¿Cuál es el problema, realmente?– Buscar el problema tras el problema– No aceptar la primer definición de un problema.
Continuar preguntando: ¿por qué?
VisiónVisión
EntenderEntenderel el problemaproblema
EncontrarEncontrarStakeholdersStakeholders
PotencialesPotencialesactoresactores
VisiónVisiónmodelo de CU
Identificar las causas del problema
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Herramientas a aplicar:
•Espina de pescado
•Pareto
Identificar las causas
18
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• Formular los requerimientos de negocio
3. Definir Requerimientos de Negocio4. Identificar la/s solución/es correcta/s
•Los requerimientos de negocio deberían partir de las causas identificadas
•Se debe especificar la situación actual
•Se debe especificar la situación de negocios deseada
19
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• Identificar soluciones de negocio
•Analizar los requerimientos de negocio
•Identificar un conjunto de soluciones• técnicas / no-técnicas / ambas
• Escoger la (s) mejor que cumpla con los requerimientos de negocio
•Iniciar un proyecto para implementar la solución
3. Definir Requerimientos de Negocio4. Identificar la/s solución/es correcta/s
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
• Modelo de CU de Negocio
3. Definir Requerimientos de Negocio4. Identificar la/s solución/es correcta/s
20
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
VisiónVisión
Identificar los stakeholders
· ¿Quiénes son los usuarios del sistema?· ¿Quién es el cliente para el sistema?· ¿A quiénes afectará el rendimiento del sistema ?· ¿Quién evaluará y aprobará el sistema cuándo este se entregue y se implemente?· ¿Hay cualquier otro usuario, interno o externo del sistema, cuyas necesidades deban contemplarse?· ¿Quién mantendrá el nuevo sistema?· ¿Hay alguien más?· De acuerdo, ¿hay alguien más?
Elaborar los perfiles de los potenciales (o actuales) actores
Documentar en la VISION lo que se tenga sobre los usuarios y su entorno
Un Un StakeholderStakeholder es cualquiera que esté afectado es cualquiera que esté afectado (materialmente) por la llegada del sistema(materialmente) por la llegada del sistema
21
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Es muy eficaz usar actores para definir y describir los límites Es muy eficaz usar actores para definir y describir los límites del sistema.del sistema.
Definir los límites del sistema
En otros términos, el límite del sistema se describe como una burbuja en donde se contiene la solución del sistema.
El límite del sistema define la frontera entre la solución y el mundo real que rodea la solución
Los actores están fuera del sistema a desarrollar
Encontrar Encontrar actores yCUactores yCU
VisiónVisión
22
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Definir los límites del sistema
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definiciLograr el acuerdo en la definición del problemaón del problema
Identificar las causas (Identificar las causas (problemaproblema tras el tras el problemaproblema))
Definir los requerimientos de negocioDefinir los requerimientos de negocio
Identificar la solución correcta (s)Identificar la solución correcta (s)
Identificar los stakeholdersIdentificar los stakeholders
Definir límites del sistema propuestoDefinir límites del sistema propuesto
Identificar restricciones del sistema/proyectoIdentificar restricciones del sistema/proyecto
Capturar un Vocabulario comúnCapturar un Vocabulario común
23
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Identificar Restricciones del sistema
VisiónVisión
DesarrolloDesarrollo
políticapolítica
económicaeconómica
TécnicaTécnicasistemasistema
factibilidadfactibilidad
Reglas deReglas deNegocioNegocio
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Contenido
IntroducciónIntroducción
Buenas PrácticasBuenas Prácticas
Introducción al RUPIntroducción al RUP
Disciplina RequerimientosDisciplina Requerimientos
ConclusionesConclusiones
Introducción
Modelando Casos de Uso
Analizar el Problema
Entender necesidades stakeholders
Definir el Sistema
Administrar el alcance
Redefinir el sistema
Administrar el cambio
CONCLUSIONESCONCLUSIONES
24
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Foco en la Vision
RequisitosRequisitosStakeholdersStakeholders
DeseosStakeholders
NecesidadesStakeholders
Características+
RequerimientosDe Software
VisionVision
EspecifEspecif..ComplemComplem..
Modelo CUModelo CU
SRS
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Artefacto: Vision
Para qué sirve el Para qué sirve el documento Vision?documento Vision?
Permite la comunicación entre los administradores, vendedoresy el equipo completo del proyecto
Le brinda al cliente el primer feedback
Capta el entendimiento general del producto
Establece alcance y prioridad de las características a un nivel macro
Para que todas las partes entiendan para qué están trabajando Describe el “qué” y el “porqué” del producto o aplicación
Se focaliza en: las necesidades de los usuarios, metas, objetivos ycaracterísticas del producto
VisiónVisión
25
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Visión
1. Historia de cambios 12. Descripción de participantes2. Tabla de contenidos 13. Lista de necesidades3. Introducción 14. Descripción del producto4. Aprobaciones 15. Restricciones y supuestos5. Audiencia 16. Requisitos de calidad6. Propósito 17. Prioridades7. Alcance 18. Productos a entregar8. Antecedentes 19. Otros requerimientos9. Oportunidad de negocios 20. Estimación económoca y temporal10. Definición del problema 21. Análisis de riesgos preliminar11. Objetivos del proyecto
Estructura del documento Visión
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Visión1. Introducción2. Descripción de los stakeholders3. Generalidades del Producto4. Características del Producto5. Entregables6. Restricciones7. Requisitos de Calidad8. Prioridades9. Otros requerimientos del producto10. Anexo – Atributos de las características
Estructura del documento Visión
26
Prof. Gustavo J. Sabiohttp://www.ucongreso.edu.ar
Analizar el Problema
Lograr el acuerdo en la definición del problema
Identificar las causas
Definir los requerimientos de negocio
Identificar la solución correcta (s)
Identificar los stakeholders
Definir límites del sistema propuesto
Identificar restricciones del sistema/proyecto
Capturar un Vocabulario común
Herram Artefacto
brainstorming
GlosarioGlosario
BrainstormingEspina de pescadoPareto
Modelo Modelo NegocioNegocio
Modelo CUModelo CU
VisiónVisión
EntrevistasWorkshopBrainstorming
WorkshopBrainstorming
WorkshopBrainstorming
VisiónVisión
VisiónVisión
VisiónVisión