Download - Levantamiento De Requerimiento

30/04/2015

1

Ingeniera de SoftwareLevantamiento de Requisitos

Vicky Latorre C.

Levantamiento de Requisitos

EntrevistaOtras Tcnicas

Anexos

Puedes Leer la Mente?

Entrevistas y Levantamiento de Requisitos

Si la respuesta es NO entonces


La Ingeniera de Requisitos es aquel conjunto de tcnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarn.

Cul es el corazn de la Ingeniera de Requisitos? Un conjunto de tareas gua.

A que conduce ese conjunto de tareas?

Cul ser el impacto del software sobre el negocio.

Qu es lo que el cliente quiere.

Cmo interactuarn los usuarios finales con el software.

Roger S. Pressman

30/04/2015

2


Porque es importante?

Programas elegantes

resolviendo

Los problemas

incorrectos.

Primero hay que

entender

Exactamente lo que el cliente

quiere antes de

comenzar a disear.

Y cmo se aplica?

Siguiendo una serie de pasos, tareas o fases.

Comenzando por una fase de inicio

y terminando con la coincidencia entre la

concepcin del problema que tiene el ingeniero de software

y la percepcin del cliente.


Cliente-Usuario lo que digo no es realmente lo que quiero

decirTu peor pesadilla

Y el problema es que

El dinero es quizs lo ms importante en el desarrollo de proyectos informticos

El dinero esta en peligro, adems no olvidemos que la reputacin esta en juego


Ralph Young

Otro detalle importante

Se pierde el tiempo con la Ingeniera de requisitos?

NO se pierde! Es realmente un punto importante que no debe omitirse.

Roger S. PressmanRalph Young

Gestin de

Requisitos en

CMMI(www.sei.cmu.edu/cmmi/models/)

30/04/2015

3


Que Hacer?

identificar y delimitar el problema a resolver.

Todo aporta... Las entrevistas son una parte importante de esto.

Tambin hay otros recursos complementarios: formularios, sistemas legados, etc.

1.-Inicio

Entrevistas: Introduccin


Sirven

para:1. Conocer, clarificar, o limitar el problema a

resolver.

2. Identificar a los actores involucrados.

3. Construir la confianza del cliente.

4. Establecer los requisitos del sistema sinambigedades.

5. Validar el trabajo ya hecho.

Las entrevistas son el primer paso, en el desarrollo de un proyecto de software.


ConsideracionesPrimera

entrevista abierta (como para abordar

el tema) y revisarla (si es

posible en grupo).

Segunda entrevista focalizada,

diseada para sacarle el resto de la

informacin al cliente.

Se pueden hacer ms

entrevistas si es necesario.

Haga la MENOR

CANTIDAD POSIBLE de entrevistas.

Graben las entrevistas.


1.-Inicio


Consideraciones

Revisar los tems ms

importantes (respecto a

los requisitos) con el cliente

(se debe obtener un

OK).

Validen con los usuarios, los requisitos entregados

por el cliente.

Usuarios y clientes deben

estar alineados.

Usuarios y Clientes deben

sentirse parte del proceso.

Trabajen rpido y

focalizados.

Traigan y analicen todos los

recursos que puedan:

formularios, sistemas legados,

manuales de procesos, etc.


1.-Inicio

30/04/2015

4

1.-Inicio

Una conversacin informal

Necesidad de negocios

Se descubre un nuevo mercado



Preguntas libres de contexto

Comprensin bsica del problema en cuestin

Objetivo principal

1.-Inicio



Entre 30 y 1 hora.

Vestirse igual (o similar) al cliente.

Dos entrevistadores (mximo).

Slo uno pregunta, el otro toma nota.

Llevar una pauta, con las preguntas.

1.-Inicio


Detalles sobre Entrevistas

Grabar cada entrevista (audio).

Obtener copia de todos los formularios involucrados en el proceso.

Trigase el modelo de datos actual (detallado), en caso de existir sistemas legados.

Llevar lpiz y papel, aunque no lo use (podra necesitarlo).

No use jerga computacional, ni regionalismos.

Trate al cliente con respeto SIEMPRE !!!

No trate de demostrar cunto sabe usted de esto: la estrella es el Cliente !!!

Escuche las opiniones del cliente, aunque sean descabelladas.

No repita las preguntas, siempre primero revise la cinta de sesiones anteriores.

1.-Inicio



Demustrele al cliente que ha comprendido su problema.

No critique las falencias de los actuales sistemas, ni las del personal que lo construy o que lo opera.

Si va a pedir algo que requiere un esfuerzo importante del cliente y/o usuario, entrgueles algo a cambio.

Ganarse a la secretaria del cliente, es casi tan importante como ganarse al cliente.

30/04/2015

5

Todo lo anterior.

Entrevista abierta (guiada por el cliente).

Que el cliente diga todo lo que tenga que decir.

Seamos Positivos, hasta conocer ms el problema

1.-Inicio

Primera Entrevista


No prometamos nada hasta analizar elproblema en detalle. CONTENGMONOS!

La primera entrevista se usa para tener unaidea aproximada del problema a resolver.

Normalmente se obtiene mucha basura, por loque hay que separar la paja, del trigo

Traigmonos toda la documentacin que podamos, para poder analizar mejor el problema a resolver, determinar su alcance e implicancias sobre otros sistemas.

formularios actuales,

modelo de datos,

cantidad y tipo de usuarios del sistema,

recursos de hardware y software que forman parte del ambiente operacional,

restricciones del desarrollo (plazos, leng. de desarrollo o BD a utilizar, Browsers usados para Front-End, etc.)

Entre la informacin que debemos traer de la 1 entrevista (dentro de lo posible) est:

1.-Inicio

Primera Entrevista


1.-Inicio

Primera Entrevista


Preguntar si hubo gente que intent hacer esto antes?

En caso afirmativo -> Qu pas?

En caso Negativo - > Veamos si se hizo algo de este tipo, y cmo les fue?

Trate de ver (con cuidado) cules son riesgos de este proyecto.

Establezca claramente el nivel compromiso y dedicacin que el Cliente/Usuario deber tener con el proyecto

Segunda/Tercera Entrevista

Casi todo lo anterior.....

Entrevista focalizada (guiada por el entrevistador).

Se utiliza para completar la informacin relevada y clarificar aspectos oscuros.

El cliente debe mantenerse en la lnea de lo que es relevante.

Sea Realista, cueste lo que cueste.


30/04/2015

6

Entrevistas de Validacin

Validar los requisitos conflictivos (al menos una vez).

Validar todo lo que usted considere necesario, ... pero con cuidado...

Validar el avance del proyecto, a travs de prototipos (buenos prototipos !!!).

Valide slo lo que est escrito en los requisitos.... Cualquier otra cosa est fuera de lo que usted debe realizar.

El tiempo del cliente tambin vale ....


Sea efectivo y directo en las entrevistas.

Instlele el software (prototipo) al cliente, si esnecesario, y asegrese de que los prototipos seanvalidados.

El cliente/usuario debe tener una manera fcil dereportar lo que le gusta y lo que no.

El uso de prototipos involucra una etapa de entrenamiento queusted debe ofrecer, e incluir en el presupuesto.

El cliente/usuario debe estar consciente de sucompromiso/dedicacin al proyecto.

Entrevistas de Validacin


Qu debe hacer el sistema?,

Determinacin de los servicios del

sistema

Quines y cuntos son los usuarios?,

Qu debera hacer cada uno con el

sistema?

Determinacin de los Usuarios del

sistema.

Qu calidad se espera que tenga el

software?.

Determinacin de los req. de calidad

del software.

Cules son los formularios que

actualmente contienen la

informacin a procesar por el

sistema?

Determinacin de datos y servicios

bsicos a manejar por el sistema.

Qu Cosas Preguntar (por ej.)?


Cul es el escenario en el que funcionar

el sistema?.

Determinacin del Ambiente Operacional.

Qu datos estn

involucrados en el sistema?.

Determinacin del mbito del

sistema.

Existen restricciones a

cerca del funcionamiento o del proceso de

desarrollo del sistema?

Determinacin de Restricciones.

... Cada una de estas preguntas

pueden ser desglosadas en

varias ...

Qu Cosas Preguntar (por ej.)?


30/04/2015

7

Las entrevistas sirven para construir confianza / acuerdos entre el proveedor y los clientes/usuarios.... aprovchelas!!!

Preprese MUY BIEN para cada entrevista... Su imagen y la de su empresa depende en gran medida de ello.

Demuestre que usted es serio, y que sabe hacer su trabajo.

Demuestre compromiso con el proyecto.

Aclare y limite el problema (junto con el cliente)... Y luego pngalo por escrito (docum. de requisitos), y que el cliente lo firme!!!

Conclusiones


Sea cuidadoso al consultar, ... pero no se quede con ninguna duda.

Sea efectivo en su trabajo

No pierda tiempo, ni improvise.

Documente todos los acuerdos, y ojal que stos sean pblicos (para clientes/usuarios y desarrolladores).

Genere y mantenga una visin compartida del proyecto.

No a las justificaciones

No a las crticas.

Conclusiones


Tcnicas de elicitacin grupalReuniones

Extensiones de entrevista. Muy activas. De corta duracin e intensas con un determinado foco

- Braisntorm: lluvia de ideas

- Workshop de requisitos: existe un moderador - JAD(Join application design): se avanza en un principio de construccin, ms organizado

y racional con generacin de documentos, compromisos, fechas.

Favorecen la aparicin de mltiples opiniones, creacin, feedback y consenso colectivo.

Puede haber dispersin, incomodidad en el grupo, pensamiento generado a nivel de grupo. Altos costos.

Otras Tcnicas de Levantamiento de Requisitos

Tcnicas de recoleccin

Prototipacin

se puede usar cuando hay un alto grado de incertidumbre en cuanto a los requisitos o cuando se necesitan un temprano feedback de los stakeholders.

Se puede combinar con otras tcnicas, por ejemplo usar un prototipo para provocar una discusin y feedback en una tcnica de elicitacin grupal o ser la base para un cuestionario anlisis de protocolo.

Otras Tcnicas de Levantamiento de Requisitos

30/04/2015

8


Tcnicas guiadas por modelos

proveen un modelo especfico del tipo de informacin que se va a recolectar y usan ese modelo para dirigir la actividad de elicitacin. Ej.: mtodos orientados a objetivos como KAOS, o mtodos basados en escenarios como CREWS.

Otras Tcnicas de Levantamiento de Requisitos Tcnicas cognitivas

Tcnicas originalmente desarrolladas para la adquisicin de conocimiento para sistemas basados en conocimiento.

Anlisis de protocolo

se analiza al experto mientras este describe como hace su tarea. Se intenta captar la racionalizacin utilizada en la ejecucin de una tarea.

Ventajas: obtiene una directa verbalizacin de las tareas cognitivas. Embebida en el contexto de trabajo, bueno para revelar problemas de interaccin con sistemas existentes.

Desventajas: se enfoca solo en la performance, desconociendo aspectos sociales, se basa en lo que dice y no lo que hace.

Card Sorting

se pide a expertos que ordenen cartas (con descripciones de objetos de un dominio) y expliquen el porqu de ese orden

til para la clasificacin del conocimiento pero presupone un conocimiento de las entidades de un dominio.

Otras Tcnicas de


Observacin

El ingeniero se convierte en espectador del proceso.

Ventajas: revela detalles obviados por otras tcnicas, fcil de ejecutar

Desventajas: depende de la visin del espectador. Gran consumo de tiempo. La rica descripcin que se obtiene es difcil de procesar.


Otras Tcnicas de


Enfoque antropolgico (Tcnicas de etnografa)

se integra con el medio ambiente, el analista se convierte en el cliente..

Ventajas: visin de dentro para afuera, muy contextualizada

Desventajas: consume mucho tiempo, poca sistematizacin.

Tipos de Tcnicas de recoleccin

Otras Tcnicas de


30/04/2015

9

Tcnicas sociales

enfocndose en los aspectos sociales y no en la tecnologa, demanda muchos recursos y tiempo.

Buena en el largo plazo,

Ej. anlisis de conversacin que identifica patrones en las conversaciones e interacciones


Otras Tcnicas de


Ingeniera reversa

Requiere que haya un sistema existente con documentacin (o cdigo) disponible.

Desventajas: no refleja la actualizacin de la informacin, informacin muy detallada ( a un bajo nivel)


Otras Tcnicas de


Reuso

Debe haber componentes reutilizables disponibles, se debe definir lo que se va a reutilizar, necesita de mecanismos de recuperacin.

Anlisis de dominio

Si bien favorece la calidad y la productividad, no siempre es fcil de lograr en la realidad.


Otras Tcnicas de


Tcnicas de Elicitacin

Que tcnicas usar?

Depende de la situacin, clientes,

recursos.

Se debe analizar el contexto y respetar

limitaciones Integracin

Tcnicas de Levantamiento

de Requisitos

30/04/2015

10

Resumen de lo visto

Antes que llevemos a cabo las actividades de diseo y construccin de un sistema basado en computadora, es

necesario entender, formular, determinar, negociar y validar los

requisitos.

Es como querer empezar a levantar paredes, colocar el techo de una casa

que construyamos sin haber levantado los cimientos adecuados, pues si esto se olvida, la casa se vendr abajo; lo

mismo ocurre con un proyecto de software cuyos requisitos no estn bien

hechos.

Para establecer requisitos adecuados en un proyecto, debemos llevar a cabo de forma paralela varias actividades. Para ello empezamos escuchando lo

que el cliente quiere, o por ese momento, lo que el cliente cree querer, as como establecer las

restricciones del proyecto

Extras

Muy importante: Es lo mismo?

Son iguales?

Ingeniera de Requisitos

Anlisis de Requisitos

Extras Ingeniera de Requisitos

Es aquel conjunto de tcnicas que ayuda a

los ingenieros de software a entender mejor

el problema en el que trabajarn.

Anlisis de Requisitos

Es aquel que genera la especificacin de caractersticas operacionales de software

; Indica la interfaz del software con otros elementos del sistema, y establece las

restricciones que debe tener el software.

El Ing. de Software se extiende sobre requisitos bsicos establecidos en la Inge-

nieria de requisitos.

Extras

30/04/2015

11

41

Caso de la vida real 1.

Cliente con poco tiempo.

Cliente mentiroso.

Desarrolladores cmodos.

Mala relacin con el cliente

El cliente ha amenazado conacciones legales.

El proyecto ha cambiadomucho.

El cliente se tomo las cosaspersonales.

El proyecto se ha vuelto undesafi

Consecuencias de no aplicar la Ingeniera de requisitos adecuadamente.

Extras

42

Caso de la vida real 2.

Cliente abusador.

Cliente paranoico.

Desarrolladorestemperamentales.

Mala relacin con el cliente.

El cliente no nos dejo respirar.

Reciba de 7 a 15 emails diarios yde 5 a 6 llamadas diarias.

El cliente cambio de parecermuchas veces.

El cliente llamaba a las 10/11 dela noche al celular.

Consecuencias de no aplicar la Ingeniera de requisitos adecuadamente.

Extras

43

Requisitos del softwareImportancia de los requisitos

Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.

Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el proyecto que el sistema no era lo que se peda.

Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su validacin.

Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su peticin no est documentada y validada por l.

Base objetiva para la estimacin de recursos (coste, personal en nmero y competencias, equipos y tiempo)

Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un margen de error; por esta razn disponer de la mayor informacin posible reduce el error.

Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.)

Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento.

Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y malentendidos.

Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de partes ya desarrolladas, etc.

Beneficios de los buenos requisitos.

Extras

44

Requisitos del softwarePropiedades de los buenos requisitos

Cada requisito debe poder implementarse dentro de las capacidades ylimitaciones conocidas del sistema y su entorno. El director tcnico debercomprobar la viabilidad de los requisitos antes de comprobar el documento.

Posibles

Un requisito es necesario si es algo:

que el cliente realmente necesita

requerido para la conformidad con un requisito

requerido para la conformidad con un interfaz, externo o estndar.

Para evitar requisitos innecesarios, el cliente debe valorar cada funcionalidad y como afectar al sistema si est o no.

Necesarios

Extras

30/04/2015

12

45


Sus defectos repercuten en todas las fases

REQUISITOS

Estimacin Planificacin Diseo Construccin V & V

Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute en todas las fases del proyecto.

Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar algo que no seconoce.

Planificacin: No se puede confiar en la planificacin para el desarrollo de algo que no se sabe biencomo es.

Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en restricciones ofuturas evoluciones, producen arquitecturas que ms tarde se confirmarn como errneas y sernmodificadas.

Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y error quederrochan horas y paciencia de programacin sobre patrones de recodificacin continua yprogramacin heroica.

Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen errores debulto, o peor an, no estn reflejadas en una especificacin de requisitos, no ser posible validar elproducto con el cliente.

Extras

46


Los defectos comunes en los requisitos y sus consecuencias.

Implicacin insuficiente

del cliente

Requisitos crecientes

y cambiantes

Requisitos ambiguos

Requisitos

innecesarios

Requisitos mnimos

(insuficientes)

Requisitos mnimos

(insuficientes)

Omisin de las necesidades

de grupos de usuarios

Problemas en la validacin

del producto obtenido

Degradacin de la estructura

y arquitectura del producto

Prdida de tiempo en

re-codificacin

Trabajo innecesario

Problemas en la validacin

del producto obtenido

Error en la estimacin

y planificacin

Usuarios insatisfechos

Extras

47



Algunos clientes no comprenden la importancia detrabajar con rigor en la obtencin de los requisitos, paragarantizar la calidad de los resultados.

Tambin es frecuente que los desarrolladores prefierancomenzar a trabajar en la construccin del sistema,porque les resulta ms atractivo que reunirse con elcliente.

Hay situaciones en las que resulta difcil encontrarrepresentantes del cliente que conozcan a fondo elproblema, o que por tratarse de un sistema o negocionuevo, nadie en el entorno del cliente tenga claras todaslas funcionalidades que se necesitan.

Implicacin insuficiente del cliente

Extras

48



Requisitos crecientes y cambiantes

Independientemente del punto del ciclo de vida en que nos encontremos, el sistema cambiar y la

tendencia al cambio persistir a lo largo de todo el ciclo de vida Software Configuration Management,

Prentice-Hall, 1980.

Es normal que los requisitos evolucionen durante el desarrollo del sistema, pero los cambios deben partir de una descripcin inicial correcta, y gestionarse convenientemente, midiendo su

impacto en la planificacin del proyecto, y consensundolo con todos los participantes.

La evolucin de los requisitos durante el desarrollo de los proyectos puede incrementar o modificar funcionalidades ya implementadas, desbordando los

costes y agendas planificados.

Extras

30/04/2015

13

49



Requisitos crecientes y cambiantes

Partir de una especificacin de requisitos incompleta incrementar el nmerode modificaciones que sufrir el proyecto durante el desarrollo.

Si los desarrolladores han diseado un sistema que no corresponde con lasexpectativas del cliente, la introduccin sistemtica (generalmente con agendasapretadas, o sin modificar las agendas iniciales), generar parches deprogramacin, con insercin de cdigo adicional que puede trastocar principiosbsicos de diseo y degradar la arquitectura del sistema obteniendo finalmenteun producto con serias deficiencias tcnicas.

[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.

Extras

50



Requisitos ambiguosLa ambigedad es un defecto habitual de las descripciones de requisitos.Si lectores diferentes obtienen interpretaciones diferentes, o si un lector puedeinterpretar los requisitos de formas diferentes, stos son ambiguos.La ambigedad crea expectativas diferentes entre las partes del proyecto, y hace que losdesarrolladores programen funcionalidades que no se ajustan a lo que los usuariosnecesitan.

La consecuencia inevitable de este problema es la re-programacinLa reprogramacin puede consumir ms del 40% del coste total de un desarrollo y se haestimado que hasta un 85% de las revisiones pueden deberse a errores en los requisitos[1]

.Para evitarla hay que confirmar que se comparte la visin obtenida con la que tienen lasdiferentes fuentes de requisitos, y que los distintos participantes obtienen la mismainterpretacin de la documentacin de requisitos.

[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.

Extras

51



Requisitos innecesariosEs frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que nofiguran en la especificacin de requisitos, con la suposicin de que los usuarios loagradecern. Muchas veces los usuarios no les encuentran utilidad y quedan finalmenteprogramadas pero sin uso, suponiendo un coste de desarrollo innecesario.Las sugerencias y posibilidades aportadas por el equipo de desarrollo pueden descubrirmejoras importantes para el cliente o los usuarios, pero no deben implementarse sinconsultarlas y validarlas previamente.

Desde el punto de vista del equipo de desarrollo la mejor perspectiva es respetar lasencillez y funcionalidad, y no ir ms all de los requisitos, sin la aprobacin del cliente.Tambin es frecuente que el cliente pida funcionalidades que a primera vista puedenparecer necesarias, pero que en realidad no aaden funcionalidad al producto, y que sinembargo suponen un esfuerzo importante de desarrollo. Identificar estas funcionalidades,y pensar dos veces si realmente se necesitan puede ahorrar trabajo innecesario

Extras

52



Requisitos insuficientes (mnimos)

Muchas veces el cliente tiene tan slo el concepto general del producto que desea, y no comprende por qu es tan importante detallar los requisitos.

La tentacin en estos casos es partir de una descripcin mnima, o incluso de una explicacin verbal, e ir preguntando y revisando a los programadores conforme el desarrollo avanza.

Esta forma de trabajo puede resultar apropiada slo para la construccin de sistemas experimentales o prototipos, pero en general suele terminar con la frustracin de los desarrolladores y el desconcierto y desesperacin del cliente.

Este planteamiento tambin genera la situacin muy frecuente de contar a los desarrolladores la idea general de un nuevo producto, para pedirles una estimacin del tiempo necesario para desarrollarlo.

Extras

30/04/2015

14

53



Omisin de las necesidades de algunos

grupos de usuariosEntre los usuarios de un sistema es

frecuente que se incluyan grupos de personas con necesidades diferentes, que empleen

funcionalidades distintas, e incluso que presenten diversos perfiles de

experiencia y conocimientos.

Al identificar las posibles fuentes de requisitos hay que localizar todos los posibles usuarios y obtener informacin de sus

caractersticas, necesidades y expectativas.

Extras

1.- Inicio

2- Obtencin

3.-Elaboracin

4.- Negociacin

5.-Especificacin 6.-Validacin

7.-Gestion de requisitos

Ingeniera de Requisitos PASOS, TAREAS O FASES

Extras

Download - Levantamiento De Requerimiento

Top Related