Administración de Requerimientos - Universidad de … · establecimiento de los objetivos del negocio, administración de proyectos, entregables permanentes, requerimientos firmes,

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


Contenido

IntroducciónIntroducción

Buenas PrácticasBuenas Prácticas

Introducción al RUPIntroducción al RUP

Disciplina RequerimientosDisciplina Requerimientos

ConclusionesConclusiones

2


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


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


Contenido






Ir a …Ir a …


Contenido






4


Contenido






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


Introducción a la Administración de Requerimientos

• Definir conceptos claves de la Disciplina• Entender los beneficios

Objetivos:

5


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)


¿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


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


• 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


AR- tipos de req. y trazabilidad


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


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


Origen de los errores en el software

Análisis56%

Diseño27%

Programación7%

Otros10%

9


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


Costo de corrección de errores

Costo

Etapas del ciclo de desarrollo

Incremento de100 a 1000 veces

10


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


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


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.


É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


Contenido






Introducción




Definir el Sistema





¿En qué parte de los Requerimientos estamos?

13



• ¿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



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


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


• “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


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











16


¿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











17


• ¿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


Herramientas a aplicar:

•Espina de pescado

•Pareto

Identificar las causas

18












• 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


• 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



• Modelo de CU de Negocio


20












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












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


Definir los límites del sistema











23


Identificar Restricciones del sistema

VisiónVisión

DesarrolloDesarrollo

políticapolítica

económicaeconómica

TécnicaTécnicasistemasistema

factibilidadfactibilidad

Reglas deReglas deNegocioNegocio


Contenido






Introducción




Definir el Sistema




CONCLUSIONESCONCLUSIONES

24


Foco en la Vision

RequisitosRequisitosStakeholdersStakeholders

DeseosStakeholders

NecesidadesStakeholders

Características+

RequerimientosDe Software

VisionVision

EspecifEspecif..ComplemComplem..

Modelo CUModelo CU

SRS


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


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


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



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

Documents

Administración de Requerimientos - Universidad de … · establecimiento de los objetivos del negocio, administración de proyectos, entregables permanentes, requerimientos firmes,