Sunteți pe pagina 1din 74

ANLISIS DE REQUERIMIENTOS

Taxonoma de pruebas de software


Reglas del Curso

Celulares y
Laptops

Tiempo del
curso
Asistencia

Preguntas

Break

Evaluacin

Copyright 2013 HITSS

Agenda
Creando Requerimientos Eficaces

Contexto Del Negocio


Que son Requerimientos?
Definiciones
Tres Niveles de Requerimientos
Componentes de Ingeniera de Requerimientos
Caractersticas de Requerimientos Eficaces
Escribiendo Requerimientos Eficaces
Mejores Prcticas Para Desarrollo de Requerimientos
Mejores Prcticas Para Manejo de Requerimientos
Riesgos en la Creacin de los Requerimientos y Cmo Evitarlos

Anlisis de Ambigedades
Proceso de Pruebas Basadas en Requerimientos (RBT)
Revisin de Ambigedad
Ejercicio Prctico

Copyright 2013 HITSS

Objetivo
Proporcionar a los participantes los conceptos del Proceso de
Administracin de Requerimientos, tomando en cuenta Requirements &
Testing
Describir los detalles del proceso para desarrollar un conjunto de
requerimientos claros y entendibles
Proporcionar una aplicacin prctica a travs de ejemplos

Copyright 2013 HITSS

Contexto del Negocio:

Razones Claves de los Fracasos de Proyectos

Indefinicin de la visin y alcance del proyecto


Desorden en las prioridades entre los clientes y
proveedores
Requerimientos
vagos,
ambiguos,
incorrectos,
inconsistentes, y/o incompletos
No se involucra al usuario, el usuario no participa y no
acepta los resultados
Muchos cambios a travs de la vida del proyecto
Desorden en el seguimiento de los procesos

Copyright 2013 HITSS

Contexto del Negocio:

Distribucin Tpica de Defectos

Requirements
Requerimientos
56%

Diseo
Design
27%

Codificacin
Code

Otros
Other
10%

7%
Source: James Martin

Copyright 2013 HITSS

Contexto del Negocio:

Esfuerzo Tpico para Encontrar y Corregir Defectos

Requerimientos
Requirements
82%
Diseo
Design
13%

Otros
Other
Codificacin
Code
4%
1%
Source: James Martin

Copyright 2013 HITSS

Que es un Requerimiento? - Perspectiva del Cliente


WEBSTERS DICTIONARY:

Something wanted or needed

Algo deseado o necesario

IEEE STD. 610.12-1990, GLOSSARY OF SOFTWARE ENGINEERING


TERMINOLOGY:
(1) A condition or capability needed by a user to solve a problem or achieve an
objective;
Una condicin o capacidad necesaria por un usuario para resolver un
problema o alcanzar un objetivo
(2) A condition or capability that must be met or possessed by a system ... to
satisfy a contract, standard, specification, or other formally imposed document.
Una condicin o capacidad que debe alcanzar o poseer un sistema
para satisfacer un contrato, estndar, especificacin o un documento impuesto
formalmente

Copyright 2013 HITSS

Qu es un Requerimiento Efectivo?

Los Requerimientos son las especificaciones de lo que debe ser


implementado. Una descripcin de cmo el sistema, producto o servicio
debe comportarse con sus propiedades y atributos. Inclusive considerando
tambin las restricciones y premisas para el proceso de desarrollo.

Deben Describir QU es lo que har


el sistema, NO el CMO lo har.

Copyright 2013 HITSS

Tres Niveles de Requerimientos


= Entrada

Requerimientos
de Negocio

= Documento Formal
Documento de Visin y Alcance
Reglas de
Negocio

Requerimientos
de Usuario

Atributos de
Calidad

Documento de Casos de Uso


Requerimientos
del Sistema

Requerimientos
Funcionales

Interfaces
Externas
Restricciones

Especificacin de Requerimientos de Software (SRS)


Matriz de Administracin de Requerimientos
Copyright 2013 HITSS

10

Componentes de Ingeniera de Requerimientos

Ingeniera de Requerimientos

Manejo de
Requerimientos

Desarrollo de
Requerimientos

Obtencin

Anlisis
(Entender)

clarificar

Especificacin

Verificacin

re-escribir
re-evaluar
corregir y cerrar
diferencias

Copyright 2013 HITSS

11

Revisin de la ingeniera de Requerimientos:


Los Tres niveles de Requerimientos
Requerimiento de Negocio
Estn ligados a los objetivos de alto nivel de una organizacin, proyecto o
cliente, requiriendo un producto, servicio o sistema.
Son contenidos en el documento que describe la visin y alcance de un
proyecto.
Un Objetivo del Proyecto se convertir en un Requerimiento de Negocio.

Copyright 2013 HITSS

12

Revisin de la ingeniera de Requerimientos:


Los Tres niveles de Requerimientos
Requerimiento de Usuario
Describe las tareas y procesos que se deben realizar para llevar a buen
trmino el producto o servicio
Ejemplo: Puede haber un Requerimiento de Usuario de tipo
Cambio Organizacional, de Sistemas, de Procesos y Procedimientos,
etc

Copyright 2013 HITSS

13

Revisin de la ingeniera de Requerimientos:


Los Tres niveles de Requerimientos
Requerimiento Funcional
Define la funcionalidad detallada del sistema que los desarrolladores o
reas deben construir o elaborar en el producto o servicio, que habiliten al
usuario para llevar a cabo sus tareas y de este modo satisfacer las
necesidades del requerimiento de usuario y de negocio en consecuencia
Los Requerimientos Funcionales deben escribirse sin utilizar lenguaje
tcnico, ni incluir partes de la solucin tcnica, slo deben avocarse a
lenguaje de negocio.

Copyright 2013 HITSS

14

Desarrollo y Manejo de Requerimientos

Desarrollo de Requerimientos

Manejo de Requerimientos

Recabe las necesidades de los


usuarios que representan todas las
clases de usuario
Entienda las tareas y los objetivos del
usuario
Entienda la importancia relativa de la
calidad de los atributos
Negocie
las
prioridades
de
implementacin
Traduzca las necesidades del usuario a
especificaciones y a modelos escritos
Revise los documentos de los
requerimientos

Establezca y mantenga un acuerdo con


el cliente sobre los requerimientos
Controle los requerimientos formales
del software
Procese los cambios de requerimientos
propuestos a travs de un control de
cambios formal
Mantenga los planes y productos
consistentes con los requerimientos
cambiantes
Negocie nuevos compromisos basados
en el impacto de los cambios

Copyright 2013 HITSS

15

Caractersticas de Requerimientos Eficaces


1.Correcto
2.Viable
3.Necesario
4.Priorizado
5.Inequvoco
6.Verificable
7.Completo
8.Consistente
9.Modificable

10.Fcil de Seguir

Copyright 2013 HITSS

16

Caractersticas de Requerimientos Eficaces


Correcto
Describe exactamente la funcionalidad que debe ser construida
El origen es una necesidad del usuario
Los usuarios deben participar en las revisiones de los requerimientos
Viable
Debe poderse implementar dentro de los lmites y restricciones
Basados en acuerdo entre los desarrolladores y los analistas del
negocio
Provee un chequeo de realidad en viabilidad y costo

Copyright 2013 HITSS

17

Caractersticas de Requerimientos Eficaces cont..


Necesario
Originados de una autoridad conocida para especificar los requerimientos,
basados en:
Algo que los usuarios realmente necesitan
En conformidad a un estndar
Algo asignado o derivado de un requisito del sistema
Una regulacin del gobierno
Priorizado
Alto
=
Debe ser incluido en la siguiente liberacin
Mediano
=
Puede esperar a una liberacin futura si es
necesario
Bajo
=
Seria bueno tener algn da

Copyright 2013 HITSS

18

Caractersticas de Requerimientos Eficaces cont..

Inequvoco
Cada lector obtiene solamente una interpretacin del requerimiento
Mltiples lectores llegan la misma interpretacin
Escrito en un lenguaje simple, claro y conciso del rea de la aplicacin

Verificable
Se puede verificar la implementacin correcta a travs:
Pruebas
Inspeccin
Demostracin
No se puede verificar si es ambiguo, inconsistente, incorrecto o no viable

Copyright 2013 HITSS

19

Caractersticas de Requerimientos Eficaces cont..

Completo
No faltan requerimientos o informacin esencial!
Use TBD (A Ser Determinado) para sealar lo que esta incompleto
Documentar como los TBDs sern resueltos
Contine con el diseo y el desarrollo a su propio riesgo!
Lo completo tambin se aplica a los requerimientos individuales (por
ejemplo un requerimiento funcional especifica lo que debe y no debe
hacer el sistema)
Consistentes
No existe conflicto con requerimientos de alto nivel
No existe conflicto con otros requerimientos funcionales

Copyright 2013 HITSS

20

Caractersticas de Requerimientos Eficaces cont..

Modificable
Cada requerimiento tiene un identificador nico
Los requerimientos son expresados individualmente/singularmente
Los requerimientos no contienen redundancias
Fcil de Seguir
Cada requerimiento tiene un identificador nico
Todos los requerimientos son escritos con un alto grado de detalle
No contiene listas en vietas (Bullets) ni prrafos largos

Copyright 2013 HITSS

21

Escribiendo Requerimientos Eficaces - 1

Evale desde la perspectiva del desarrollador


Documente en una forma jerrquica y estructurada
Incluya comportamientos esperados y condiciones de excepcin
No restrinja las opciones de diseo
Mantenga cortas las frases y prrafos
Utilice gramtica, ortografa y puntuacin apropiada
Utilice los trminos consistentemente
Defina los trminos en un glosario
Evite requerimientos redundantes
Evite requerimientos contradictorios

Copyright 2013 HITSS

22

Escribiendo Requerimientos Eficaces - 2


Escriba los requerimientos a un alto grado de detalle.
Evite los prrafos largos
Tenga cuidado con el uso de "y" y "o", que sugieren que hay requerimientos
mltiples combinados
Evite listas en vietas (Bullets)
Identifique cada requerimiento
Organice en tablas los requerimientos similares
Sea preciso y especfico.
Use debera o debe, no use podra, pudo, pueda
Evite palabras ambiguas: minimizar, maximizar,
optimizar, rpido, de uso amigable, fcil, simple,
intuitivo, robusto, avanzado, mejorado,
eficiente, flexible, opcionalmente, suficiente, razonable

ESCRIBA LOS REQUERIMIENTOS NO SOLO PARA USTED.

Copyright 2013 HITSS

23

Elementos Complementarios a un Requerimiento


Adems de la Definicin de un Buen Requerimiento, existen otros elementos a
considerar que lo afectan o lo complementan, y son importantes para el
entendimiento del requerimiento.
Estos elementos son:

Reglas de Negocio

Validaciones

Una Regla de Negocio describe o define el comportamiento de una Organizacin

Estn alineadas a las polticas de la Organizacin


Pueden aplicar a un solo requerimiento o son generales a un proceso, aplicando
a varios requerimientos.
Las Reglas de Negocio son Dinmicas, ya que dan movimiento a la
Organizacin

Copyright 2013 HITSS

24

Reglas de Negocio

Ejemplos:
Cuando un cliente desea cancelar una tarjeta de crdito se requiere verificar que
no exista saldo pendiente en la tarjeta a cancelar. Si la tarjeta a cancelar no
presenta saldo pendiente proceder a cancelar la tarjeta; en caso contrario, se le
notifica al cliente que tiene un adeudo y no se puede cancelar su tarjeta.
No se puede dar de alta un cliente si no tiene algn producto o servicio
asociado.

Forma en que se calcula una comisin.

Copyright 2013 HITSS

25

Validaciones
A nivel de requerimientos, son las condiciones especficas que deben ser
consideradas para cumplir con l.
La diferencia con una Regla de Negocio, radica en que la Regla describe la
forma de operacin del negocio, mientras que las validaciones son
caractersticas especficas que deben cumplir un componente de software.
Son aquellas preferencias que se tengan en la operacin del requerimiento.
Normalmente las validaciones ayudan a que se cumplan las reglas de negocio.

Copyright 2013 HITSS

26

Validaciones

Ejemplos:
Verificar que en una pantalla de captura de informacin, se haya introducido
primero el nmero del cliente antes de seleccionar un producto asociado.
Verificar que el nmero de cliente contenga todos los dgitos necesarios sea
un nmero vlido.
Que algn archivo cumpla con cierto layout antes de cargarlo.
Si se introduce el nmero de telfono, que se inhabilite la captura del correo
electrnico.

Copyright 2013 HITSS

27

Mejores prcticas para Obtener Requerimientos

Identifique a los dueos del producto como representantes claves del


cliente
Debe representar a usuarios reales, no sustitutos
Sirve como la voz del cliente para una clase especifica de usuarios
Provee requerimientos, resuelve conflictos, define atributos
Debe estar autorizado apropiadamente

Desarrolle historias del usuario para obtener requerimientos


Define requerimientos de usuarios
Se enfoca en las tareas del usuario
Deriva requerimientos funcionales de la descripcin de las tareas
Deriva casos de prueba temprano en el proyecto

Copyright 2013 HITSS

28

Mejores prcticas para Obtener Requerimientos cont..

Empiece por definir la visin del producto y el alcance del proyecto


Define los requerimientos del negocio
Proporciona el origen de los requerimientos de usuario y del sistema
propuestos
Controla el incremento no controlado del alcance
Fija prioridades del proyecto
Documente los atributos de calidad en el DRN
Visible para los usuarios e importante para los desarrolladores
Rena informacin de los dueos del producto
Escriba para ser cuantitativo y comprobable

Copyright 2013 HITSS

29

Mejores prcticas para Anlisis de Requerimientos

Modelos de anlisis ofrecen mejor panorama de los requerimientos


ningn panorama dice todo lo que necesitas saber
diagrama de contexto, diagrama de flujo de datos, diagramas de estadotransicin (antes-despus), mapas de dialogo, modelos de anlisis de
objeto
utilice casos de prueba para verificar los modelos
Priorice los requerimientos en trminos de valor y riesgo
valor = beneficio al cliente + consecuencia si falta
contra = costo relativo + riesgo relativo
prioridad =

Valor %
costo % + riesgo %
Copyright 2013 HITSS

30

Mejores prcticas para Anlisis de Requerimientos cont


Crear prototipos
Parcial o posible implementacin para clarificar los requerimientos
Crear una maqueta para la interfase del usuario, prueba de concepto para
arquitectura
Puede ser un prototipo desechable o evolutivo
Utilice programas utilitarios estructurados para evaluacin de prototipos
Crear un diccionario de datos
Los elementos y las estructuras de datos del cliente
Elementos y estructuras de interfaces de datos
Descripcin, tipos de datos, longitud, valores mnimos y mximos, valores
permitidos, valores automticos
Utilice un glosario para definir los trminos del cliente

Copyright 2013 HITSS

31

Mejores prcticas para Documentos de Requerimientos

Utilice plantillas estndar de requerimientos


Requerimientos de Negocios:
Documento de Visin y Alcance
Requerimientos de Usuarios:
Documento de Casos de Uso
Requerimientos Funcionales:
Especificaciones de Requerimientos de
Software (SRS)
Identifique distintivamente cada requerimiento
Los hace fcil de seguir y modificables
Es mejor no utilizar numeracin jerrquica

Copyright 2013 HITSS

32

Lineamientos de Identificadores
Utilice una convencin simple, consistente
Utilice abreviaciones alfabticas para categorizar por tipo (por ejem. BR para Business
Requirements)
Combine el identificador de categora alfabtico con un numero nico
Numere en incrementos de por lo menos 10 para permitir la insercin de nuevos
requerimientos y elementos de rastreo subsecuentes resultado de requisiciones de
cambio durante el proyecto o mejoras en subsecuentes liberaciones de mantenimiento
(por ejem., BR010, BR020, BR030)
Ejemplo de Esquema de Identificadores

Requerimientos de Negocios BR + nmero nico


Requerimientos de Usuarios
UR + nmero nico
Requerimientos de Sistema
SR + nmero nico
Diseo de Arquitectura
AD + nmero nico
Diseo Detallado
DD + nmero nico
Componente de Aplicacin
AC + nmero nico
Caso de Prueba:
Prueba de Aceptacin de Usuario
UAT + nmero nico
Prueba de Aceptacin Operacional
OAT + nmero nico
Prueba de Desempeo
PT + nmero nico
Prueba de Sistema
ST + nmero nico

Copyright 2013 HITSS

33

Descomposicin de Requerimientos
Cambios Organizacionales
Equipo
Infraestructura de Negocio
Procesos y Procedimientos
Pruebas
Productos y Servicios
Red
Recursos Humanos
Seguridad
Sistemas

RF0001

Proyecto:
CM/BE001

RU001

RU002

RF0002

RF0003

Copyright 2013 HITSS

RU003

34

Mejores prcticas para Verificacin de Requerimientos

Inspeccin formal de documentos de requerimientos


Mucho mas barato encontrar y corregir defectos en la etapa de
requerimientos
Incluir a los clientes, diseadores, probadores
Utilice listas de comprobacin de los errores comunes de
requerimientos
Pruebas basadas en requerimientos
Derive los casos de prueba de los casos de uso y requerimientos
funcionales
Los casos de prueba cristalizan una visin de comportamiento esperado
Revise los casos de prueba contra los requerimientos y modelos

Copyright 2013 HITSS

35

Mejores prcticas para Manejo de Requerimientos


Maneje las Versiones de los documentos de requerimientos

Adopte y haga cumplir un Proceso de control de cambios de


requerimientos
Defina el procedimiento para proponer, evaluar, decidir sobre cambios
Apoye el procedimiento con una herramienta de seguimiento de defectos
Defina el estatus de una requisicin de cambios y un modelo estadotransicin (antes-despus)
Establezca un Consejo de Control de Cambios para tomar decisiones y
que haga cumplir el proceso de control de cambios
Anlisis de impacto de cambios de requerimientos
Involucre al usuario, diseador, probador
Identifique los componentes del sistema afectados por el cambio
Identifique las tareas que se tendran que efectuar
Estime el esfuerzo, costo, otros impactos

Copyright 2013 HITSS

36

Mejores prcticas para Manejo de Requerimientos cont


Matriz de seguimiento de requerimientos
Ligar requerimientos a su origen
Ligar requerimientos a diseo, cdigo, casos de prueba
Ayuda a evitar pasar por alto requerimientos durante la construccin
Facilita el mantenimiento y anlisis de impacto

Seguimiento de estatus de requerimientos


Propuestos, aprobados, implementados, verificados, suprimidos
Permite un mas preciso seguimiento de estatus del proyecto
Utilice una herramienta de manejo de requerimientos
Guarde los requerimientos y sus atributos en una base de datos
Defina ligas de seguimiento, formalice los requerimientos, de
seguimiento de estatus

Copyright 2013 HITSS

37

Ejemplo de Requirements Traceability Matrix

Copyright 2013 HITSS

38

Ha experimentado cualesquiera de las siguientes


situaciones?

La visin y el alcance del proyecto nunca son claramente definidos.


Los clientes estn demasiado ocupados para trabajar con los analistas o
los desarrolladores en los requerimientos.
Los sustitutos del usuario (por ejemplo: gerentes o mercadotecnia)
afirman hablar por los usuarios, pero realmente no lo hacen.
Los usuarios afirman que todos los requerimientos son crticos, as que no
les dan prioridad.
Los desarrolladores encuentran ambigedades e informacin faltante al
codificar, as que suponen muchas cosas.
stos son sntomas que resultan al caer en los Riesgos de los
requerimientos que usted puede y debe evitar.

Copyright 2013 HITSS

39

Riesgo #1: Confusin Sobre Requerimientos

Sintomas
Los interesados (stakeholders) discuten requerimientos" sin adjetivo
calificativo.
El patrocinador de proyecto presenta un concepto de alto nivel como "los
requerimientos.
Las pantallas de interfase de usuario son vistas como los
requerimientos.
Los usuarios proporcionan requerimientos, pero los desarrolladores
todava no saben qu construir.
Los requerimientos se enfocan solo en funcionalidad, y descuidan otras
categoras de requerimientos.
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

40

Riesgo #1: Confusin Sobre Requerimientos


Soluciones
Adopte plantillas para los tres tipos de requerimientos
Requerimientos de Negocios (Documento de Visin y Alcance)
Requerimientos de Usuario (Documento de Requerimiento de Usuario y
Documento de Casos de Uso)
Requerimientos de Software (Especificacin de Requerimientos de
Software)
Clasifique los requerimientos funcionales de los requerimientos nofuncionales, atributos de calidad, restricciones, requerimientos de
interfases externas, reglas del negocio
Clasifique la informacin proporcionada por el usuario en las diferentes
categoras
Identifique las ideas de solucin de los requerimientos

Copyright 2013 HITSS

41

Riesgo #2: Involucramiento Inadecuado Del Usuario

Sntomas
Algunas clases de usuario se pasan por alto
Algunas clases de usuario no tienen voz
Sustitutos de usuarios tratan de hablar por ellos, por ejemplo:
gerentes de los usuarios
mercadotecnia
desarrolladores
Los desarrolladores tienes que hacer muchas decisiones
requerimientos
Los usuarios rechazan el producto cuando lo ven por primera vez

de

Puede sugerir algunas soluciones?

Copyright 2013 HITSS

42

Riesgo #2: Involucramiento Inadecuado Del Usuario

Soluciones
Identifique y defina todas las clases de usuarios
Identifique a los dueos del producto como un representante de
usuarios
Convoque a grupos de enfoque
Identifique al personal autorizado para hacer decisiones e involcrelos
Haga que los usuarios evalen los prototipos
Haga que los representantes de usuarios revisen a fondo los
documentos de requerimientos

Copyright 2013 HITSS

43

Riesgo #3: Requerimientos Vagos y Ambiguos

Sntomas
Los lectores interpretan un requerimiento de diversas maneras
Falta informacin en los requerimientos que los desarrolladores necesitan
Los requerimientos no son verificables (es decir., falta informacin que los
probadores necesitan)
Los desarrolladores/probadores tienen que hacer muchas preguntas
Los desarrolladores/probadores tienen que suponer muchas cosas

Puede sugerir algunas soluciones?

Copyright 2013 HITSS

44

Riesgo #3: Requerimientos Vagos y Ambiguos


Soluciones
Revise formalmente los documentos de requerimientos para ambigedad
antes de revisar el contenido
Escriba casos de prueba conceptuales contra los requerimientos (es decir,
entradas, salidas)
Modele los requerimientos para encontrar diferencias de conocimiento
Utilice prototipos para hacer los requerimientos mas tangibles
Defina los trminos en un glosario
Evite palabras ambiguas: minimizar, maximizar, optimizar, rpido, de uso
fcil, simple, intuitivo, robusto, avanzado, mejorada, eficiente, varios, y/o,
etc., incluya, apoye, adecuado

Copyright 2013 HITSS

45

Riesgo #4: Requerimientos Sin Priorizar


Sntomas
Todos los requerimientos se clasifican como crticos
Los diferentes interesados (stakeholders) interpretan alta prioridad de
diferente manera
Despus de priorizar, 95% de los requerimientos todava son altos
Los desarrolladores no quieren admitir que no pueden hacerlo todo
No est claro cuales requerimientos diferir si reduccin de alcance" llega
a ser necesaria
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

46

Riesgo #4: Requerimientos Sin Priorizar

Soluciones
Alinee los requerimientos funcionales con los requerimientos del negocio
Alinee los requerimientos funcionales con los requerimientos de
usuario/casos de uso prioritarios, basados en:
Frecuencia de uso
Procesos de negocio medulares
Cumplimiento de regulaciones obligatorias
Defina categoras de prioridad sin ambigedades
Asigne requerimientos o caractersticas a las liberaciones
Priorice analticamente los requerimientos

Copyright 2013 HITSS

47

Riesgo #5: Creando Funcionalidad Que Nadie Usa

Sntomas
Los usuarios exigen ciertas caractersticas, despus nadie las usa
La funcionalidad propuesta no est relacionada con las tareas del negocio
Los desarrolladores agregan una funcin porque a los usuarios les
gustar
Los usuarios no distinguen lo trivial" de lo importante
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

48

Riesgo #5: Creando Funcionalidad Que Nadie Usa

Soluciones
Derive los requerimientos funcionales de los casos de uso
Ligue cada requerimiento funcional a su origen en una tarea de negocio
Identifique las clases de usuarios que se beneficiarn con cada
caracterstica
Analticamente priorice los requerimientos, casos de uso, o caractersticas
Haga que los clientes estimen el valor (Beneficio o Consecuencia)
Haga que los desarrolladores estimen el costo y riesgo
Evite los requerimientos de alto costo y bajo valor
Recuerde que lo est bien hecho es porque se hace bien

Copyright 2013 HITSS

49

Riesgo #6: Parlisis de Anlisis

Sntomas
El desarrollo de requerimientos parece nunca acabar
Se liberan continuamente nuevas versiones de los requerimientos
Los requerimientos nunca son formalizados
Todos los requerimientos se modelan repetidamente, en mltiples formas
Diseo y codificacin no empiezan hasta que el documento de
requerimientos esta perfecto
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

50

Riesgo #6: Parlisis de Anlisis


Soluciones

Recuerde: el producto es software, no un documento de requerimientos


Seleccione un ciclo de vida de desarrollo apropiado
liberaciones progresivas que sean iterativas e incrementales
crear prototipos evolutivos
poner limite de tiempo
Decida cuando los requerimientos son bastante aceptables
riesgo aceptable para proceder con el desarrollo
Revisado por los interesados (stakeholders) del proyecto, incluyendo
analistas, desarrolladores, probadores y usuarios
Modele solo las partes complejas o inciertas del sistema
No incluya diseos finales de interfase de usuarios en la definicin de
requerimientos

Copyright 2013 HITSS

51

Riesgo #7: Incremento no Controlado del Alcance


Sntomas
Se agregan nuevos requerimientos continuamente
El programa no cambia
No se provee recursos adicionales
El alcance del producto nunca se define claramente
Los requerimientos propuestos, vienen, y van, y regresan
Los cambios a los requerimientos se hacen furtivamente, entran por la
puerta de atrs
Los problemas del alcance se discuten durante las revisiones del
documento de definicin de requerimientos
La firma final es solo un ejercicio intelectual
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

52

Riesgo #7: Incremento no Controlado del Alcance


Soluciones

Determine las causas raz del incremento no controlado del alcance


Documente la visin y alcance del producto
Defina los lmites del sistema y las interfaces
Siga el proceso del control del cambio para todos los cambios
Mejore los mtodos de obtencin de requerimientos
Siga un proceso significativo de formalizacin de requerimientos
Renegocie los compromisos cuando los requerimientos cambian

Copyright 2013 HITSS

53

Riesgo #8: Proceso Inadecuado de Control de Cambios


Sntomas

No se ha definido ningn proceso de control de cambios


Algunas personas pasan por alto el proceso de control de cambios y les
permiten hacerlo
Negocian tratos con amigos
Trabajan en cambios propuestos antes de que sean aprobados
Implementan cambios rechazados
No implementan cambios aprobados
Se descubre nueva funcionalidad durante la ejecucin de las pruebas
Estatus confusos sobre la requisicin de cambios
No se comunican los cambios a todos los afectados
No est claro quin hace las decisiones sobre los cambios
Puede sugerir algunas soluciones?

Copyright 2013 HITSS

54

Riesgo #8: Proceso Inadecuado de Control de Cambios

Soluciones
Defina un proceso prctico de control de cambios
Establezca un Consejo de Control de Cambios
Grupo diverso
Hacen decisiones de cambios que comprometen
Utilice una herramienta para recabar, darle seguimiento, y comunicar los
cambios
Una herramienta de seguimiento de problemas que trabaje bien
Una herramienta no es un proceso!
Establezca y haga cumplir las polticas de control de cambios
Compare las prioridades contra los requerimientos restantes.

Copyright 2013 HITSS

55

Riesgo #9: Insuficiente Anlisis de Impacto Para los


Cambios Propuestos

Sntomas
La gente acuerda precipitadamente en hacer cambios
Un cambio es mas complejo que lo anticipado
Un cambio lleva mas tiempo de lo prometido
Un cambio no es tcnicamente viable
Un cambio causa retrasos en el proyecto
Los desarrolladores encuentran mas componentes del sistema afectados
por el cambio
Los probadores siguen encontrando mas pruebas afectadas por el cambio

Puede sugerir algunas soluciones?

Copyright 2013 HITSS

56

Riesgo #9: Insuficiente Anlisis de Impacto Para los


Cambios Propuestos

Soluciones
Analice sistemticamente el impacto de cada cambio propuesto
identifique todas las tareas posibles (cambiantes o nuevas)
considere otras implicaciones de aceptar el cambio
estime el esfuerzo y el impacto al programa
Utilice informacin de seguimiento de los requerimientos para identificar
todos los componentes del sistema y casos de prueba afectados
Estime los costos y beneficios antes de hacer compromisos

Copyright 2013 HITSS

57

Riesgo #10: Control de Versin Inadecuada

Sntomas
No se incorporan los cambios aceptados en los documentos apropiados de
requerimientos
No puede distinguir las diferentes versiones de los documentos de
requerimientos
diferentes versiones tienen el mismo identificador
documentos idnticos tienen diferentes identificadores
La gente trabaja de diferentes versiones de requerimientos
los desarrolladores implementan caractersticas canceladas
los probadores hacen pruebas en requerimientos equivocados
Se pierde la historia de cambios y versiones de documentos anteriores

Puede sugerir algunas soluciones?

Copyright 2013 HITSS

58

Riesgo #10: Control de Versin Inadecuada

Soluciones
Incorpore los cambios en los documentos de requerimientos apropiados
Adopte un esquema de versiones para los documentos
Ponga los documentos de requerimientos bajo un control de versiones
Restringa el acceso de leer/escribir
Haga las versiones actuales inalterables a todos los miembros del
proyecto
Comunique las revisiones a todos los afectados
Guarde los requerimientos en un deposito de requerimientos
Registre la historia completa de cada cambio del requerimiento

Copyright 2013 HITSS

59

ANLISIS DE AMBIGEDADES

Copyright 2013 HITSS

60

Que es un Requerimiento que se Puede Poner a Prueba?


Un requerimiento que se puede poner a prueba tiene las siguientes
caractersticas:
1.Predecible

9.Escrito en un estilo consistente

2.Inequvoco

10.Utiliza reglas de proceso que reflejan


estndares consistentes

3.Correcto

11.Explicito

4.Completo

12.De lgica consistente

5.No-redundante

13.Se presta a ser re-usado

6.Se presta para control de cambios

14.Conciso y preciso

7.Se puede ligar


8.Se puede leer por todos los interesados
(stakeholders)

15.Priorizado
16.Viable

Copyright 2013 HITSS

61

Definicin de Habilidad de ser Probado

Los resultados se pueden medir/predecibles


Dado un estado inicial del sistema y una serie de condiciones, es
posible predecir exactamente cuales sern los resultados
Probar = comparar un resultado esperado con un resultado observado

Copyright 2013 HITSS

62

Proceso RBT:
Que es Pruebas Basadas en Requerimientos?

Desarrollado por Richard Bender


Un enfoque sistemtico para:
Verificar requerimientos como entradas a diseo, codificacin y pruebas
Establecer seguimiento a los requerimientos
Proveer una cobertura mxima de pruebas con el mnimo numero de casos de
prueba
Validad la conformidad del sistema con los requerimientos

Copyright 2013 HITSS

63

Proceso RBT
Definir
Requerimientos
Documento de
Requerimientos
Constru Correctamente el Sistema?

Pruebas de
Sistema
Control de
Liberacin

Especificaciones
Funcionales

Diseo de
Arquitectura

Pruebas de
Integracin
Documentos
de Diseo

Identificar
Casos de
Prueba

Diseo Tcnico
Detallado
Crear
Procedimientos
de Prueba

Pruebas
Unitarias
Documentos
de Diseo

Construccin

Verificacin
(Pruebas Estticas)

Tiempo

Validacin
(Pruebas Dinmicas)

Copyright 2013 HITSS

Prueba de
Sanidad

Desarrollo y Ejecucin

Planeacin de Pruebas e Inicio


Desarrollo de Casos de Prueba

Desarrollar
Escenarios de
Prueba

Anlisis del
Diseo
Funcional

Ambiente
Controlado

Casos de Prueba/Datos

Preparar la
Estrategia
de Pruebas

Pruebas de
Desempeo y
Aprobacion

Constru el Sistema Correcto?

64

Contexto del Negocio:

Proporciones Tpicas de Descubrir Defectos

Prueba Unitaria 50%


85%
Prueba de Integracin 18%

Sin RBT

Prueba de Sistema 12%

UAT

5%

Entregado
al Cliente
15%

Copyright 2013 HITSS

(Bender & Associates)

65

Contexto del Negocio:

Proporciones Tpicas de Descubrir Defectos

Inspeccin
RBT
65 - 90%
Con RBT

Aprox.
10-35%

Pruebas
10 - ~35%

Entregado al Cliente
.015%

Copyright 2013 HITSS

66

Proceso RBT:
Pasos Bsicos
1. Validar requerimientos
comparado con los objetivos
2. Aplicar casos de uso en base a
los requerimientos
3. Realizar un anlisis inicial de
ambigedad
4. Realizar una revisin de
contenido por especialistas en
la materia
5. Graficacin de causa-efecto
6. Realizar revisiones de
consistencia lgica y diseo de
casos de pruebas

7. Verificar los casos de pruebas


con los autores de los
requerimientos
8. Verificar los casos de prueba
con los usuarios/expertos en la
materia
9. Verificar los casos de prueba
con los desarrolladores
10.Utilice los casos de prueba en la
revisin del diseo
11.Utilice los casos de prueba en la
revisin del cdigo
12.Valide el cdigo con los casos
de prueba derivados de los
requerimientos y casos de uso

Copyright 2013 HITSS

67

Proceso RBT:
Principales Tcnicas Especficas Para Pruebas
Revisin de Ambigedad
Utilizado en la fase de la determinacin de los requerimientos de un
proyecto para identificar cualquier cosa que sea confusa, ambigua,
inconsistente o incompleta en los requerimientos, con el objetivo de
mejorar su calidad
Llevada a cabo con una inspeccin formal (es decir, componente de
Revisin de Productos de Trabajo [WPR])
Es el enfoque de esta sesin de entrenamiento
Graficacin de Causa-Efecto
Una tcnica de diseo de casos de prueba, utilizada una vez que los
requerimientos han sido revisados por ambigedad y contenido
Obtenga el mnimo de casos de prueba para cubrir el 100% de los
requerimientos funcionales
Apoyado por la herramienta BenderRBT

Copyright 2013 HITSS

68

Proceso RBT:

Beneficio de las Tcnicas RBT


Revisin de Ambigedad

Aplica a los requerimientos funcionales y a los no-funcionales


Puede ser utilizado con requerimientos y especificaciones
documentados
Proporciona requerimientos y especificaciones que son claras, precisas,
predecibles, correctamente lgicas, consistentes y que se pueden
probar
Involucra y beneficia a todos los interesados (stakeholders) (es decir,
diseadotes/arquitectos/DBAs, programadores, probadores)
Establece la plataforma para la revisin de productos de trabajo
posteriores y seguimiento de los requerimientos

Copyright 2013 HITSS

69

Revisin de Ambigedad:

Un Ejemplo Simple

La mitad de dos y dos = ??

Tiene la respuesta correcta?

Copyright 2013 HITSS

70

Revisin de Ambigedad:

Ejercicio de Practica #3
Requerimiento de Negocio Antes de la Revisin de
Ambigedad
El Cajero Automtico (ATM) enviar una alarma al
departamento de tecnologa de la informacin (IT) cuando
el ATM se ha tratado de forzar. En caso que el ATM se
abra sin la llave y el cdigo de seguridad, el ATM alertar
al departamento inmediatamente para que pueda tomar la
accin apropiada.

Identifique las Ambigedades -- tiene 10 minutos.

Copyright 2013 HITSS

71

Resumen
Claves para Requerimientos Excelentes

Educar a los usuarios, desarrolladores, gerentes y probadores


Una asociacin de colaboracin entre usuarios-consultores-desarrolladoresprobadores
Reconocer que hay diversas clases de requerimientos
Desarrollo iterativo, incremental de los requerimientos
Plantillas estndares de documentos de requerimientos
Revisiones formales e informales de requerimientos
Escribir casos de prueba contra los requerimientos
Priorizar los requerimientos analticamente
Control de cambios practico y eficaz

Copyright 2013 HITSS

72

La meta fundamental es

NO
SORPRESAS!

Copyright 2013 HITSS

73

GRACIAS