IR09 Administrando requisitos

8/20/2019 IR09 Administrando requisitos

1/66

Ingeniería de requerimientos

Ingeniería de Sistemas e Informática


2/66

Propósito de la sesión

• Describe el proceso de la

administración derequerimientos.

Contenido de la sesión

• Administración derequerimientos.

Propósito y contenido de la sesión


3/66

Recapitulando …


4/66

INTRODUCCIÓN A LA GERENCIA DE LOSREQUERIMIENTOS

Ingeniería de requerimientos


5/66

Según Dorfman y Thayer (1990)

la ingeniería de Requerimientos:

Es una capacidad delsoftware, que necesita elusuario para solucionar un

problema y alcanzar unobjetivo

Es una capacidad del

software, que debe poseer unsistema para satisfacer un

contrato o especificaciones uotra documentación

impuesta.

¿Que es un requisito?


6/66

¿Qué es la gerencia de los requerimientos?

Definiremos a gerencia de los

Requerimientos como:• Una propuesta sistemática de como obtener,

organizar, documentar los requerimientos delsistema.

• Un proceso que establece y mantiene un acuerdoentre el cliente y el equipo del proyecto con respectoa los requerimientos y cambios de los mismos.


7/66

Aplicación de las técnicas de administración de

Requerimientos

Tipos de Software deaplicación

Sistemas de Información(esta categoría es la base

para la industria de latecnología de información)

Software comercial (comoprocesadores de texto)

Software para dispositivoscomplejos como(aeroplanos, celulares)


8/66

El dominio del problema

Involucrarse en el Problema (hacer que elproblema sea nuestro), entender su contexto,

idioma, cultura, necesidades, etc.

Dentro del dominio del problema, utilizamos unsistema de habilidades, como mapa para

entender el problema a solucionar.

Mientras definimos el dominio del problema,necesitamos obtener una comprensión del

problema y de las necesidades.


9/66

Moviéndose hacia el dominio de la solución• En este espacio de la solución, nos centramos en definir una

solución al problema del usuario; éste es el reino de

computadoras, de la programación, de sistemas operativos, deredes y de nodos de procesamiento.

• Como requisito fundamental es comprender en el Dominio delProblema, sin la comprensión adecuada de esté, la soluciónpodría empeorar el problema.


10/66

Los Requerimientos del software• Una vez que hayamos establecido los requerimientos

conforme a lo establecido por el usuario, podemos empezar aestablecer los requerimientos mas específicos

• Si se desarrolla un sistema conforme a los requerimientosestablecidos, el producto final tendrá todas las capacidadessolicitadas por los usuarios.


11/66

Dominio y solución del problema


12/66

EL EQUIPO DE DESARROLLO DE SOFTWARE

Habilidades

12


13/66

Gerencia de los requerimientos• La gerencia de los Requerimientos “usa” a cada miembro del

equipo de diversas maneras.

•

La gerencia eficaz de los requerimientos se logra con unequipo eficaz

• Seis habilidades son necesarias en el equipo


14/66

Habilidades indispensables del equipo para la gerencia

eficaz de los requerimientos (1)

Habilidad 1

• Analizar elproblema

• Técnicas que elequipo utilizaparacomprender

adecuadamenteel problema.

Habilidad 2

• Entender lasnecesidades delusuario

• Técnicas que elequipo utilizapara extraer los

requerimientosde los usuariosdel sistema ystakeholders.

Habilidad 3

• Definiendo elSistema

• Definición inicialdel sistema queorientará esasnecesidades

(estructura,visión).


15/66


eficaz de los requerimientos (29

Habilidad 4

• Administrar el

alcance• Definir las

características aimplementar en elprimer lanzamiento(línea base y línea

de fondo)

Habilidad 5

• Refinar la definición

de Sistema• Organizar la

información de losrequerimientos

• Elaborar ladefinición del

sistema oredefinirla a unnivel convenientede diseño eimplementación

Habilidad 6

• Construir el sistema

correcto• Aseguramiento,

verificación,validación yadministración decambios

(trazabilidad)• Asegurar un

resultado decalidad


16/66


eficaz de los requerimientos

Habilidad 4

• Administrar el

alcance• Definir las

características aimplementar en elprimer lanzamiento(línea base y línea

de fondo)

Habilidad 5

• Refinar la definición

de Sistema• Organizar la

información de losrequerimientos

• Elaborar ladefinición del

sistema oredefinirla a unnivel convenientede diseño eimplementación

Habilidad 6

• Construir el sistema

correcto• Aseguramiento,

verificación,validación yadministración decambios

(trazabilidad)• Asegurar un

resultado decalidad


17/66

Diversas habilidades de los miembros del

equipoLos miembros del equipo tienendiversas habilidades:

• - Programación de Software.

• - Pruebas de Software.

• - Manejo de requerimientos con eficacia.

Los aspectos más importantesson el balance y la cobertura para

lograr un excelente equipo.


18/66

LOS CINCO PASOS EN EL ANÁLISIS DELPROBLEMA

Analizando el problema


19/66

Los cinco pasos en el análisis del problema

5. Identificar las restricciones a ser impuestas en la solución

4. Definir los límites del sistema

3. Identificar los stakeholders y los usuarios

2. Entender las causas raíz

1. Conseguir un acuerdo sobre la definición del problema


20/66

Formato para la declaración del problema


21/66

1. Conseguir un acuerdo sobre la definición del

problema

• Dedicar tiempo en conseguir acuerdo sobre el problema es unpequeño paso significativo.

•

Por ejemplo: – Un cliente, fabricantes de equipos industriales, estaba

comprometido con la actualización de sus TICs, la cual estarelacionada con su facturación y la generación de informes

financieros entre la compañía y sus distribuidores. – El tema para el nuevo software fue “mejorar la

comunicación con los distribuidores”.


22/66

Ejemplo: Conseguir un acuerdo sobre la definición del

problema

• Durante la discusión de la definición del problema: – La visión de la gerencia fue substancialmente diferente:

• La meta primaria del nuevo sistema es proporcionar transferencia de fondos

electrónicos que mejoraría el flujo de efectivo de la compañía.• Después de un arduo debate, los problemas se priorizaron:

1. Transferir fondos electrónicos,

2. Correo electrónico, y

3. Otras características de comunicación con los distribuidores

• Se reoriento sustancial los objetivos• La nueva definición del problema fue la transferencia de

fondos electrónicos, como el problema a ser resuelto


23/66

2. Entender las causas raíz

Una compañía se enfoco en los costos de los desechos.

• El diagrama de la espina de pescado nos ayuda a identificar losproblemas detrás del problema (Gestión de la calidad total, Total QualityManagement, TQM).

La compañía identificó muchas fuentes que causan

“desechos”.

Cada fuente se listo como uno de las “espinas" en el

diagrama.


24/66

Diagrama de la espina


25/66

Diagrama de la espina


26/66

Diagrama de Pareto de las causas raíz


27/66

Dirigiendo la Causa de la Raíz

Con los resultados obtenidos, el equipo

descubrió una sola causa de la raíz

80:20, separa los “pocos vitales” de

los “muchos triviales”

En un problema con muchas causas,podemos decir que el 20% de las

causas resuelven el 80% delproblema y el 80% de las causas solo

resuelven el 20% del problema.


28/66

Declaración del problema con respecto a la

orden de las ventas


29/66

3. Identificar a los stakeholders y los usuarios

Implica entrevistar a laspersonas que toman las

decisiones, los usuariospotenciales y otros interesados.

Stakeholders

• Alguien quien podría afectar laimplementación del nuevo sistema oaplicación


30/66

Usuarios y stakeholders del nuevo sistema


31/66

4. Definir el límite del sistema

El límite del sistema define la frontera entre la solucióny el mundo real que rodea la solución

La información, en forma de entradas y salidas, que sonllevados de un lado a otro del sistema, para que losusuarios que están fuera del sistema lo puedan usar

Todas las interacciones con el sistema ocurren víainterfaces entre el sistema y el mundo externo


32/66

La Relación Entrada / Sistema / Salida

• Así, dividimos el mundo en dos clases

1. Nuestro sistema

2. Cosas que interactúan con nuestro sistema


33/66

Límite del Sistema


34/66

5. Identificar las restricciones a ser impuestas en

la solución

Restringen nuestra habilidad para

entregar una solución como nosotros loprevemos

Cada restricción debe ser consideradocuidadosamente como parte del procesode la planificación


35/66

Restricciones potenciales del sistema

Fuente Restricciones potenciales

Económico • ¿Qué restricciones financieros opresupuestarios son aplicables?

• ¿Hay costos de ventas o cualquier

consideraciones de precio de los

productos?• ¿Hay algún problema de la autorización?

Técnico • ¿Tenemos restricciones tecnologías?

• ¿Tenemos limitaciones para trabajar dentro

de plataformas existentes o tecnologías?

• ¿Nos prohíben cualquier nueva tecnología?

• ¿Estamos limitados para usar paquetes del

software?


36/66

CARACTERÍSTICAS DEL SISTEMA

Features

36


37/66

Síndrome del usuario y desarrollador


38/66

Características del sistema

• Las características del sistema son expresiones de conducta dealto nivel del sistema deseado

• Las características del sistema deben limitarse de 25 a 99,

siendo de preferencia no mayor a 50• Los atributos del sistema proporcionan información adicional

sobre sus características del sistema


39/66

Características

• Los stakeholders no manifiestan su necesidad real. – Si no aumento la productividad del departamento, no conseguiré mi

paga extraordinaria a fin de año –

Debo reducir el tiempo de las transacciones de las ventas en mas del50% – El vehículo tendrá un sistema de mando de computarizado en cada

rueda – Necesito mejorar el control de producción


40/66

Ejemplo de características


41/66


42/66

Atributos de las características del producto

• Para administrar las características introducimos la noción deatributos de las características, o datos que proporcionaninformación adicional.

• Los atributos relacionan las características a otros tipos deinformación del proyecto. – Podemos usar los atributos para rastrear (identificador

único, estados, datos históricos, etc.), para priorizar ymanejar las características propuestas para la aplicación.

• Por ejemplo –

La prioridad del atributo podría usarse para capturar los resultados dela votación acumulativa en una sesión del brainstorming; – El número de versión de atributo podría usarse para una versión inicial

de un software específico en la que estamos pensando implementaruna característica específica.


43/66


44/66

EL ALCANCE DEL PROYECTO

Scope


45/66

Componentes del alcance del proyecto

• La funcionalidad que se debe entregar para resolver lasnecesidades del usuario

•

Los recursos disponibles para el proyecto• El tiempo disponible

Time line

Deadline

Scope

R e s o u r c e s

R e s o u r c e s


46/66

Requerimientos iníciales

• El propósito de la administración del alcance del proyecto estáen establecer un alto nivel de requerimientos para el proyecto.

• El punto de inicio es el listado detallado de características o

exigencias.• Este punto de partida debe ser reconocido tanto por el cliente

como por el equipo desarrollador.


47/66

• Debe ser al menos"aceptable" para el cliente.

• Tener una probabilidadrazonable de éxito (en laopinión del equipo).

Punto de partida

Característica 1

Característica 2

.

.

.

Etc.


48/66

Listado de características

• El listado de características representa la herramientaprimordial del proyecto que se usa antes de que se realiceninversiones significativas en el refinado de requerimientos,diseño, pruebas u otras actividades del proyecto.


49/66

Ejemplo: Proyecto de Software

Características

Característica 1: Soporte crítico de una base de datos relacional externa

Característica 4: Portabilidad a una nueva versión del Sistema Operativo

Característica 6: Importar data externaCaracterística 3: Capacidad de hacer una copia del proyecto

Característica 2: Seguridad Multiusuario

Característica 5: Asistente para un nuevo proyecto

Característica 7: Implementar herramientas de ayudaCaracterística 8: Integrar con el subsistema de administración de versiones


50/66

Escenario de prioridades

• Durante la priorización, es importante que los clientes yusuarios, administradores del producto (software) - no elequipo desarrollador- liste las prioridades.

• Esta priorización inicial debería ser hecha sin demasiadainfluencia de la comunidad técnica; de otra manera, elnivel de dificultad en la realización de las característicasinfluirá en las prioridades del cliente y el resultado delproceso será influenciado, así no se podrá encontrar las

verdaderas necesidades del cliente.• Habrá oportunidad adecuada para la asistencia técnica en

las fases posteriores del proceso de priorización.


51/66

Priorizando característicasCaracterísticas Prioridad

Característica 1: Soporte crítico de una base de datosrelacional externa

Crítico

Característica 4: Portabilidad a una nueva versión del SistemaOperativo

Crítico

Característica 6: Importar data externa Crítico

Característica 3: Capacidad de hacer una copia del proyecto Importante

Característica 2: Seguridad Multiusuario ImportanteCaracterística 5: Asistente para un nuevo proyecto Importante

Característica 7: Implementar herramientas de ayuda Útil

Característica 8: Integrar con el subsistema de administraciónde versiones

Útil


52/66

Determinación del esfuerzo• El siguiente paso está en establecer el nivel de esfuerzo

implicado por cada característica propuesta.

•

La priorización es sólo una parte del alcance. Después de todo,si nosotros podríamos hacer todo el trabajo, la priorizaciónsería innecesaria.


53/66

Esfuerzo para cada característica

Característica Prioridad Esfuerzo

C1: Soporte de una base de datos relacional externa Crítica Medio

C4: Portabilidad a una nueva versión del sistemaoperativo

Crítica Alto

C6: Importar data externa Crítica Bajo

C3: Capacidad para realizar una copia del proyecto Importante Alto

C2: Seguridad multiusuario. Importante Bajo

C5: Asistente de un nuevo proyecto Importante Bajo

C7: Implementar herramientas de ayuda Útil Bajo

C8: Integración con el subsistema de administración deversiones

Útil Alto


54/66

Agregando el elemento “riesgo”

• Otro aspecto de administrar el alcance del proyecto,es estimar el “riesgo” asociado con cada requisito. –

Consideraremos el riesgo como la probabilidad en que laimplementación de un característica o requisito causará un impactoadverso en el cronograma y el presupuesto.

• Una característica con alto riesgo tiene el potencial

de afectar negativamente al proyecto, aun si todas lasotras características pueden ser completadas dentrodel tiempo permitido.


55/66

Escala del riesgo

• El equipo de desarrollo establece el riesgo, usando la escala: – Bajo

– Medio

– Alto• La misma escala usada en la valoración de esfuerzo.


56/66

Lista de características con el riesgo agregadoRequisito Prioridad Esfuerzo Riesgo

Feature 1 Base de datos relacional externa Crítica Medio Bajo

Feature 4 Portabilidad a nueva versión de sistemaoperativo

Crítica Alto Medio

Feature 6 Importar datos externos Crítica Bajo Alto

Feature 3 Capacidad de hacer copia del proyecto Importante Alto Medio

Feature 2 Seguridad multiusuario Importante Bajo Alto

Feature 5 Asistente de nuevo proyecto Importante Bajo Bajo

Feature 7 Tool Tips ( consejos) Útil Bajo Alto

Feature 8 Subsistema de administración de versiones Útil Alto Bajo


57/66

Estrategias para reducir el riesgo

• Las estrategias para reducir el riesgo se diferenciandependiendo de cada proyecto.

– Para propósitos de gestión del alcance del proyecto, esadecuado establecer el riesgo asociado con cada rasgo orequisito, para tomar las mejores decisiones al inicio delproyecto.

– Por ejemplo, si un requisito tiene una:• Prioridad “crítica” y un riesgo“alto”

• Una estrategia de atenuación o reducción es obligatoria.Requisito Prioridad Esfuerzo Riesgo



58/66

Estrategias para reducir el riesgo

• Si un requisito tiene una:

– Prioridad “importante” y un riesgo“bajo”

– El requisito puede ser pospuesto o desarrollarlo “si hay tiempo

disponible”

– En este caso no hay problema, siempre que no se haya hecho algúncompromiso de incluirlo antes del lanzamiento del sistema

Requisito Prioridad Esfuerzo Riesgo



59/66

Reduciendo el alcance del proyecto• Hemos priorizado requisitos asociados con el esfuerzo y el

riesgo.

– Existe a menudo poca correlación entre la prioridad, el esfuerzo y elriesgo, esto puede ayudar al equipo en la priorización de losrequisitos. Por ejemplo,

– Puede ser candidato para su inmediata implementación.

Requisito Prioridad Esfuerzo Riesgo



60/66

Directivas para fijar las prioridades de desarrollo de

requisitos críticos

Características (requisitos) Considere

Prioridad: Crítico Esfuerzo: Alto Riesgo: Alto ¡Alarma! Establecer estrategia inmediata de reducción de riesgo;asignar recursos inmediatamente; enfocarse en la viabilidad conla arquitectura.

Prioridad: Crítica Esfuerzo: Alto Riesgo: Bajo Un rasgo probablemente limitado con recursos restringidos.Asignar recursos inmediatamente.

Prioridad: Crítica Esfuerzo: Bajo Riesgo: Bajo Recurso como con un hecho de seguridad. Diferir hasta después.


61/66

Línea base y línea de fondo

• Es suficiente en muchos proyectos del mundo real a sacar la“baseline” en los requisitos críticos, quizá incluyendo uno odos características que tengan la prioridad de “importante”

• Las características debajo de la línea de fondo soncaracterísticas futuras y se consideran en posterioreslanzamientos

• Algunas características no son independientes, convendrá

incluir un requisito debajo de la línea base junto con los queestán por encima de la línea base.

Lista de la que se fijó las prioridades de la característica


62/66

Características (Requisito) Prioridad Esfuerzo Riesgo


Feature 4 Portabilidad a nueva versión de sistema operativo Crítica Alto Medio


Feature 3 Capacidad de hacer una copia del proyecto Importante Alto Medio

Línea base (las características por encima de esta línea son características comprometidas)

Feature 2 Seguridad multiusuario Importante Bajo Alto


Feature 7 Tool Tips ( consejos) Útil Bajo Alto

Feature 8 Subsistema de administración de versiones Útil Alto Bajo


63/66

Preguntas


64/66

¿Qué hemos aprendido?


65/66

Reflexionemos


66/66

IR09 Administrando requisitos

Documents

Transcript of IR09 Administrando requisitos