Download - Análisis de Requerimientos
© Copyright 2013 HITSS 2
Taxonomía de pruebas de software Reglas del Curso
Tiempo del curso
Asistencia
Break
Celulares y Laptops
Preguntas
Evaluación
© Copyright 2013 HITSS 3
Agenda
Creando Requerimientos Eficaces
Contexto Del Negocio
¿Que son Requerimientos?
Definiciones
Tres Niveles de Requerimientos
Componentes de Ingeniería de Requerimientos
Características de Requerimientos Eficaces
Escribiendo Requerimientos Eficaces
Mejores Prácticas Para Desarrollo de Requerimientos
Mejores Prácticas Para Manejo de Requerimientos
Riesgos en la Creación de los Requerimientos y Cómo Evitarlos
Análisis de Ambigüedades Proceso de Pruebas Basadas en Requerimientos (RBT)
Revisión de Ambigüedad
Ejercicio Práctico
© Copyright 2013 HITSS 4
Objetivo
Proporcionar a los participantes los conceptos del Proceso de
Administración de Requerimientos, tomando en cuenta Requirements &
Testing
Describir los detalles del proceso para desarrollar un conjunto de
requerimientos claros y entendibles
Proporcionar una aplicación práctica a través de ejemplos
© Copyright 2013 HITSS 5
Contexto del Negocio:
Razones Claves de los Fracasos de Proyectos
Indefinición de la visión 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 través de la vida del proyecto
Desorden en el seguimiento de los procesos
© Copyright 2013 HITSS 6
Contexto del Negocio:
Distribución Típica de Defectos
Requirements56%
Design27%
Other10%Code
7%Source: James Martin
Diseño
Requerimientos
Codificación
Otros
© Copyright 2013 HITSS 7
Contexto del Negocio:
Esfuerzo Típico para Encontrar y Corregir Defectos
Requirements82%
Design13%
Other4%Code
1%
Requerimientos
Diseño
Codificación
Otros
Source: James Martin
© Copyright 2013 HITSS 8
Que es un Requerimiento? - Perspectiva del Cliente
WEBSTER’S 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 condición 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 condición o capacidad que debe alcanzar o poseer un sistema … para satisfacer un contrato, estándar, especificación o un documento impuesto formalmente”
© Copyright 2013 HITSS 9
¿Qué es un Requerimiento Efectivo?
“Los Requerimientos son … las especificaciones de lo que debe ser
implementado. Una descripción de cómo el sistema, producto o servicio
debe comportarse con sus propiedades y atributos. Inclusive considerando
también las restricciones y premisas para el proceso de desarrollo.”
Deben Describir QUÉ es lo que hará
el sistema, NO el CÓMO lo hará.
© Copyright 2013 HITSS 10
Tres Niveles de Requerimientos
Requerimientos de Negocio
Documento de Visión y Alcance
Requerimientos de Usuario
Documento de Casos de Uso
Requerimientos Funcionales
Especificación de Requerimientos de Software (SRS)
Restricciones
Interfaces Externas
Requerimientos del Sistema
Reglas de Negocio
Atributos de Calidad
= Entrada
= Documento Formal
Matriz de Administración de Requerimientos
© Copyright 2013 HITSS 11
Componentes de Ingeniería de Requerimientos
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Manejo de Requerimientos
Obtención Análisis (Entender)
Especificación Verificación
clarificar re-escribir
re-evaluar corregir y cerrar
diferencias
© Copyright 2013 HITSS 12
Revisión de la ingeniería de Requerimientos:
Los Tres niveles de Requerimientos
Requerimiento de Negocio
Están ligados a los objetivos de alto nivel de una organización, proyecto o
cliente, requiriendo un producto, servicio o sistema.
Son contenidos en el documento que describe la visión y alcance de un
proyecto.
Un Objetivo del Proyecto se convertirá en un Requerimiento de Negocio.
© Copyright 2013 HITSS 13
Revisión de la ingeniería de Requerimientos:
Los Tres niveles de Requerimientos
Requerimiento de Usuario
Describe las tareas y procesos que se deben realizar para llevar a buen
término 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 14
Revisión de la ingeniería 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
técnico, ni incluir partes de la solución técnica, sólo deben avocarse a
lenguaje de negocio.
© Copyright 2013 HITSS 15
Desarrollo y Manejo de Requerimientos
Desarrollo 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
implementación
Traduzca las necesidades del usuario a
especificaciones y a modelos escritos
Revise los documentos de los
requerimientos
Manejo de 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 través 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 16
Características de Requerimientos Eficaces
1.Correcto
2.Viable
3.Necesario
4.Priorizado
5.Inequívoco
6.Verificable
7.Completo
8.Consistente
9.Modificable
10.Fácil de Seguir
© Copyright 2013 HITSS 17
Características 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 límites 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 18
Características 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 estándar
Algo asignado o derivado de un requisito del sistema
Una regulación del gobierno
Priorizado
Alto = Debe ser incluido en la siguiente liberación
Mediano = Puede esperar a una liberación futura si es
necesario
Bajo = Seria bueno tener algún día
© Copyright 2013 HITSS 19
Características de Requerimientos Eficaces cont..
Inequívoco Cada lector obtiene solamente una interpretación del requerimiento
Múltiples lectores llegan la misma interpretación
Escrito en un lenguaje simple, claro y conciso del área de la aplicación
Verificable Se puede verificar la implementación correcta a través:
Pruebas
Inspección
Demostración
No se puede verificar si es ambiguo, inconsistente, incorrecto o no viable
© Copyright 2013 HITSS 20
Características de Requerimientos Eficaces cont..
Completo
¡No faltan requerimientos o información esencial!
Use TBD (A Ser Determinado) para señalar lo que esta incompleto
Documentar como los TBDs serán resueltos
¡Continúe con el diseño y el desarrollo a su propio riesgo!
Lo completo también 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 21
Características de Requerimientos Eficaces cont..
Modificable
Cada requerimiento tiene un identificador único
Los requerimientos son expresados individualmente/singularmente
Los requerimientos no contienen redundancias
Fácil de Seguir
Cada requerimiento tiene un identificador único
Todos los requerimientos son escritos con un alto grado de detalle
No contiene listas en viñetas (Bullets) ni párrafos largos
© Copyright 2013 HITSS 22
Escribiendo Requerimientos Eficaces - 1
Evalúe desde la perspectiva del desarrollador
Documente en una forma jerárquica y estructurada
Incluya comportamientos esperados y condiciones de excepción
No restrinja las opciones de diseño
Mantenga cortas las frases y párrafos
Utilice gramática, ortografía y puntuación apropiada
Utilice los términos consistentemente
Defina los términos en un glosario
Evite requerimientos redundantes
Evite requerimientos contradictorios
© Copyright 2013 HITSS 23
Escribiendo Requerimientos Eficaces - 2
Escriba los requerimientos a un alto grado de detalle. Evite los párrafos largos Tenga cuidado con el uso de "y" y "o", que sugieren que hay requerimientos múltiples combinados Evite listas en viñetas (Bullets) Identifique cada requerimiento Organice en tablas los requerimientos similares Sea preciso y específico. Use “debería” o “debe”, no use “podría,” “pudo,” “pueda” Evite palabras ambiguas: minimizar, maximizar, optimizar, rápido, de uso amigable, fácil, simple, intuitivo, robusto, avanzado, mejorado, eficiente, flexible, opcionalmente, suficiente, razonable
ESCRIBA LOS REQUERIMIENTOS NO SOLO PARA USTED.
© Copyright 2013 HITSS 24
Elementos Complementarios a un Requerimiento
Además de la Definición 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 Organización
• Están alineadas a las políticas de la Organización
• Pueden aplicar a un solo requerimiento o son generales a un proceso, aplicando
a varios requerimientos.
• Las Reglas de Negocio son Dinámicas, ya que dan movimiento a la
Organización
© Copyright 2013 HITSS 25
Reglas de Negocio
Ejemplos:
• Cuando un cliente desea cancelar una tarjeta de crédito 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 algún producto o servicio
asociado.
• Forma en que se calcula una comisión.
© Copyright 2013 HITSS 26
Validaciones
• A nivel de requerimientos, son las condiciones específicas que deben ser
consideradas para cumplir con él.
• La diferencia con una Regla de Negocio, radica en que la Regla describe la
forma de operación del negocio, mientras que las validaciones son
características específicas que deben cumplir un componente de software.
• Son aquellas preferencias que se tengan en la operación del requerimiento.
• Normalmente las validaciones ayudan a que se cumplan las reglas de negocio.
© Copyright 2013 HITSS 27
Validaciones
Ejemplos:
• Verificar que en una pantalla de captura de información, se haya introducido
primero el número del cliente antes de seleccionar un producto asociado.
• Verificar que el número de cliente contenga todos los dígitos necesarios ó sea
un número válido.
• Que algún archivo cumpla con cierto layout antes de cargarlo.
• Si se introduce el número de teléfono, que se inhabilite la captura del correo
electrónico.
© Copyright 2013 HITSS 28
Mejores prácticas para Obtener Requerimientos
Identifique a los dueños 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 descripción de las tareas
Deriva casos de prueba temprano en el proyecto
© Copyright 2013 HITSS 29
Mejores prácticas para Obtener Requerimientos cont..
Empiece por definir la visión 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
Reúna información de los dueños del producto
Escriba para ser cuantitativo y comprobable
© Copyright 2013 HITSS 30
Mejores prácticas para Análisis de Requerimientos
Modelos de análisis ofrecen mejor panorama de los requerimientos
ningún panorama dice todo lo que necesitas saber
diagrama de contexto, diagrama de flujo de datos, diagramas de estado-
transición (antes-después), mapas de dialogo, modelos de análisis de
objeto
utilice casos de prueba para verificar los modelos
Priorice los requerimientos en términos de valor y riesgo
valor = beneficio al cliente + consecuencia si falta
contra = costo relativo + riesgo relativo
prioridad = Valor %
costo % + riesgo %
© Copyright 2013 HITSS 31
Mejores prácticas para Análisis de Requerimientos cont…
Crear prototipos
Parcial o posible implementación 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 evaluación de prototipos
Crear un diccionario de datos
Los elementos y las estructuras de datos del cliente
Elementos y estructuras de interfaces de datos
Descripción, tipos de datos, longitud, valores mínimos y máximos, valores
permitidos, valores automáticos
Utilice un glosario para definir los términos del cliente
© Copyright 2013 HITSS 32
Mejores prácticas para Documentos de Requerimientos
Utilice plantillas estándar de requerimientos
Requerimientos de Negocios: Documento de Visión y Alcance
Requerimientos de Usuarios: Documento de Casos de Uso
Requerimientos Funcionales: Especificaciones de Requerimientos de
Software (SRS)
Identifique distintivamente cada requerimiento
Los hace fácil de seguir y modificables
Es mejor no utilizar numeración jerárquica
© Copyright 2013 HITSS 33
Lineamientos de Identificadores
Utilice una convención simple, consistente Utilice abreviaciones alfabéticas para categorizar por tipo (por ejem. BR para “Business Requirements”) Combine el identificador de categoría alfabético con un numero único Numere en incrementos de por lo menos 10 para permitir la inserción 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 + número único Requerimientos de Usuarios UR + número único Requerimientos de Sistema SR + número único Diseño de Arquitectura AD + número único Diseño Detallado DD + número único Componente de Aplicación AC + número único Caso de Prueba: Prueba de Aceptación de Usuario UAT + número único Prueba de Aceptación Operacional OAT + número único Prueba de Desempeño PT + número único Prueba de Sistema ST + número único
© Copyright 2013 HITSS 34
Descomposición de Requerimientos
Proyecto:
CM/BE001
RU001 RU002 RU003
RF0001 RF0002 RF0003
•Cambios Organizacionales
•Equipo
•Infraestructura de Negocio
•Procesos y Procedimientos
•Pruebas
•Productos y Servicios
•Red
•Recursos Humanos
•Seguridad
•Sistemas
© Copyright 2013 HITSS 35
Mejores prácticas para Verificación de Requerimientos
Inspección formal de documentos de requerimientos
Mucho mas barato encontrar y corregir defectos en la etapa de
requerimientos
Incluir a los clientes, diseñadores, probadores
Utilice listas de comprobación 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 visión de comportamiento esperado
Revise los casos de prueba contra los requerimientos y modelos
© Copyright 2013 HITSS 36
Mejores prácticas 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 requisición de cambios y un modelo estado-
transición (antes-después)
Establezca un Consejo de Control de Cambios para tomar decisiones y
que haga cumplir el proceso de control de cambios
Análisis de impacto de cambios de requerimientos
Involucre al usuario, diseñador, probador
Identifique los componentes del sistema afectados por el cambio
Identifique las tareas que se tendrían que efectuar
Estime el esfuerzo, costo, otros impactos
© Copyright 2013 HITSS 37
Mejores prácticas para Manejo de Requerimientos cont…
Matriz de seguimiento de requerimientos
Ligar requerimientos a su origen
Ligar requerimientos a diseño, código, casos de prueba
Ayuda a evitar pasar por alto requerimientos durante la construcción
Facilita el mantenimiento y análisis 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 39
¿Ha experimentado cualesquiera de las siguientes
situaciones?
La visión y el alcance del proyecto nunca son claramente definidos. Los clientes están 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 críticos, así que no les dan prioridad. Los desarrolladores encuentran ambigüedades e información faltante al codificar, así que suponen muchas cosas. Éstos son síntomas que resultan al caer en los Riesgos de los requerimientos que usted puede y debe evitar.
© Copyright 2013 HITSS 40
Riesgo #1: Confusión 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 todavía no saben qué construir. Los requerimientos se enfocan solo en funcionalidad, y descuidan otras categorías de requerimientos.
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 41
Riesgo #1: Confusión Sobre “Requerimientos”
Soluciones
Adopte plantillas para los tres tipos de requerimientos
Requerimientos de Negocios (Documento de Visión y Alcance)
Requerimientos de Usuario (Documento de Requerimiento de Usuario y
Documento de Casos de Uso)
Requerimientos de Software (Especificación de Requerimientos de
Software)
Clasifique los requerimientos funcionales de los requerimientos no-
funcionales, atributos de calidad, restricciones, requerimientos de
interfases externas, reglas del negocio
Clasifique la información proporcionada por el usuario en las diferentes
categorías
Identifique las ideas de solución de los requerimientos
© Copyright 2013 HITSS 42
Riesgo #2: Involucramiento Inadecuado Del Usuario
Síntomas
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 de
requerimientos
Los usuarios rechazan el producto cuando lo ven por primera vez
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 43
Riesgo #2: Involucramiento Inadecuado Del Usuario
Soluciones
Identifique y defina todas las clases de usuarios
Identifique a los dueños del producto como un representante de
usuarios
Convoque a grupos de enfoque
Identifique al personal autorizado para hacer decisiones e involúcrelos
Haga que los usuarios evalúen los prototipos
Haga que los representantes de usuarios revisen a fondo los
documentos de requerimientos
© Copyright 2013 HITSS 44
Riesgo #3: Requerimientos Vagos y Ambiguos
Síntomas
Los lectores interpretan un requerimiento de diversas maneras
Falta información en los requerimientos que los desarrolladores necesitan
Los requerimientos no son verificables (es decir., falta información 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 45
Riesgo #3: Requerimientos Vagos y Ambiguos
Soluciones
Revise formalmente los documentos de requerimientos para ambigüedad
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 términos en un glosario
Evite palabras ambiguas: minimizar, maximizar, optimizar, rápido, de uso
fácil, simple, intuitivo, robusto, avanzado, mejorada, eficiente, varios, y/o,
etc., incluya, apoye, adecuado
© Copyright 2013 HITSS 46
Riesgo #4: Requerimientos Sin Priorizar
Síntomas
Todos los requerimientos se clasifican como críticos
Los diferentes interesados (stakeholders) interpretan alta prioridad de
diferente manera
Después de priorizar, 95% de los requerimientos todavía son altos
Los desarrolladores no quieren admitir que no pueden hacerlo todo
No está claro cuales requerimientos diferir si “reducción de alcance" llega
a ser necesaria
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 47
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 categorías de prioridad sin ambigüedades
Asigne requerimientos o características a las liberaciones
Priorice analíticamente los requerimientos
© Copyright 2013 HITSS 48
Riesgo #5: Creando Funcionalidad Que Nadie Usa
Síntomas
Los usuarios exigen ciertas características, después nadie las usa
La funcionalidad propuesta no está relacionada con las tareas del negocio
Los desarrolladores agregan una función porque “a los usuarios les
gustará”
Los usuarios no distinguen lo “trivial" de lo “importante“
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 49
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 beneficiarán con cada
característica
Analíticamente priorice los requerimientos, casos de uso, o características
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 50
Riesgo #6: Parálisis de Análisis
Síntomas
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 múltiples formas
Diseño y codificación no empiezan hasta que el documento de
requerimientos esta perfecto
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 51
Riesgo #6: Parálisis de Análisis
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 diseños finales de interfase de usuarios en la definición de requerimientos
© Copyright 2013 HITSS 52
Riesgo #7: Incremento no Controlado del Alcance
Síntomas
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 atrás
Los problemas del alcance se discuten durante las revisiones del
documento de definición de requerimientos
La firma final es solo un ejercicio intelectual
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 53
Riesgo #7: Incremento no Controlado del Alcance
Soluciones
Determine las causas raíz del incremento no controlado del alcance
Documente la visión y alcance del producto
Defina los límites del sistema y las interfaces
Siga el proceso del control del cambio para todos los cambios
Mejore los métodos de obtención de requerimientos
Siga un proceso significativo de formalización de requerimientos
Renegocie los compromisos cuando los requerimientos cambian
© Copyright 2013 HITSS 54
Riesgo #8: Proceso Inadecuado de Control de Cambios
Síntomas No se ha definido ningún 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 ejecución de las pruebas Estatus confusos sobre la requisición de cambios No se comunican los cambios a todos los afectados No está claro quién hace las decisiones sobre los cambios
¿Puede sugerir algunas soluciones?
© Copyright 2013 HITSS 55
Riesgo #8: Proceso Inadecuado de Control de Cambios
Soluciones
Defina un proceso práctico 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 políticas de control de cambios
Compare las prioridades contra los requerimientos restantes.
© Copyright 2013 HITSS 56
Riesgo #9: Insuficiente Análisis de Impacto Para los
Cambios Propuestos
Síntomas
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 técnicamente 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 57
Riesgo #9: Insuficiente Análisis de Impacto Para los
Cambios Propuestos
Soluciones
Analice sistemáticamente 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 información 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 58
Riesgo #10: Control de Versión Inadecuada
Síntomas
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 idénticos tienen diferentes identificadores
La gente trabaja de diferentes versiones de requerimientos
los desarrolladores implementan características 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 59
Riesgo #10: Control de Versión 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 61
¿Que es un Requerimiento que se Puede Poner a Prueba?
1.Predecible
2.Inequívoco
3.Correcto
4.Completo
5.No-redundante
6.Se presta para control de cambios
7.Se puede ligar
8.Se puede leer por todos los interesados (stakeholders)
9.Escrito en un estilo consistente
10.Utiliza reglas de proceso que reflejan estándares consistentes
11.Explicito
12.De lógica consistente
13.Se presta a ser re-usado
14.Conciso y preciso
15.Priorizado
16.Viable
Un requerimiento que se puede poner a prueba tiene las siguientes características:
© Copyright 2013 HITSS 62
Definición 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 serán los resultados
Probar = comparar un resultado esperado con un resultado observado
© Copyright 2013 HITSS 63
Proceso RBT:
¿Que es Pruebas Basadas en Requerimientos?
Desarrollado por Richard Bender
Un enfoque sistemático para:
Verificar requerimientos como entradas a diseño, codificación y pruebas
Establecer seguimiento a los requerimientos
Proveer una cobertura máxima de pruebas con el mínimo numero de casos de
prueba
Validad la conformidad del sistema con los requerimientos
© Copyright 2013 HITSS 64
Proceso RBT
Crear
Procedimientos
de Prueba
Identificar
Casos de
Prueba
Desarrollar
Escenarios de
Prueba
Preparar la
Estrategia
de Pruebas
Documentos
de Diseño
Documentos
de Diseño
Especificaciones
Funcionales
Documento de
Requerimientos
Definir
Requerimientos
Análisis del
Diseño
Funcional
Diseño de
Arquitectura
Diseño Técnico
Detallado
Construcción
Pruebas de
Desempeño y
Aprobacion
Pruebas de
Sistema
Prueba de
Sanidad Pruebas de
Integración
Pruebas
Unitarias
Control de
Liberación
Pla
neació
n d
e P
ruebas e
Inic
io
D
esarro
llo d
e C
asos d
e P
rueba
Tiempo
Verificación (Pruebas Estáticas)
Validación (Pruebas Dinámicas) C
asos d
e P
rueba/D
ato
s
Desarr
ollo
y E
jecució
n
Ambiente
Controlado
¿Construí Correctamente el Sistema?
¿Construí el Sistema Correcto?
© Copyright 2013 HITSS 65
Contexto del Negocio:
Proporciones Típicas de Descubrir Defectos
Prueba Unitaria 50%
Prueba de Integración 18%
Prueba de Sistema 12%
UAT 5%
Entregado al Cliente
15%
85%
(Bender & Associates)
Sin RBT
© Copyright 2013 HITSS 66
Contexto del Negocio:
Proporciones Típicas de Descubrir Defectos
Inspección
RBT
65 - 90%
Pruebas
10 - ~35%
Entregado al Cliente .015%
Aprox.
10-35%
Con RBT
© Copyright 2013 HITSS 67
Proceso RBT:
Pasos Básicos
1. Validar requerimientos
comparado con los objetivos
2. Aplicar casos de uso en base a
los requerimientos
3. Realizar un análisis inicial de
ambigüedad
4. Realizar una revisión de
contenido por especialistas en
la materia
5. Graficación de causa-efecto
6. Realizar revisiones de
consistencia lógica y diseño 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 revisión del diseño
11.Utilice los casos de prueba en la revisión del código
12.Valide el código con los casos de prueba derivados de los requerimientos y casos de uso
© Copyright 2013 HITSS 68
Proceso RBT:
Principales Técnicas Específicas Para Pruebas
Revisión de Ambigüedad
Utilizado en la fase de la determinación 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 inspección formal (es decir, componente de
Revisión de Productos de Trabajo [WPR])
Es el enfoque de esta sesión de entrenamiento
Graficación de Causa-Efecto
Una técnica de diseño de casos de prueba, utilizada una vez que los
requerimientos han sido revisados por ambigüedad y contenido
Obtenga el mínimo de casos de prueba para cubrir el 100% de los
requerimientos funcionales
Apoyado por la herramienta BenderRBT™
© Copyright 2013 HITSS 69
Proceso RBT:
Beneficio de las Técnicas RBT
Revisión de Ambigüedad
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 lógicas, consistentes y que se pueden
probar
Involucra y beneficia a todos los interesados (stakeholders) (es decir,
diseñadotes/arquitectos/DBAs, programadores, probadores)
Establece la plataforma para la revisión de productos de trabajo
posteriores y seguimiento de los requerimientos
© Copyright 2013 HITSS 70
Revisión de Ambigüedad:
Un Ejemplo Simple
La mitad de dos y dos = ??
¿Tiene la respuesta correcta?
© Copyright 2013 HITSS 71
Revisión de Ambigüedad:
Ejercicio de Practica #3
Requerimiento de Negocio Antes de la Revisión de
Ambigüedad
El Cajero Automático (ATM) enviará una alarma al
departamento de tecnología de la información (IT) cuando
el ATM se ha tratado de forzar. En caso que el ATM se
abra sin la llave y el código de seguridad, el ATM alertará
al departamento inmediatamente para que pueda tomar la
acción apropiada.
Identifique las Ambigüedades -- tiene 10 minutos.
© Copyright 2013 HITSS 72
Resumen
Claves para Requerimientos Excelentes
• Educar a los usuarios, desarrolladores, gerentes y probadores
• Una asociación de colaboración entre usuarios-consultores-desarrolladores-
probadores
• Reconocer que hay diversas clases de requerimientos
• Desarrollo iterativo, incremental de los requerimientos
• Plantillas estándares de documentos de requerimientos
• Revisiones formales e informales de requerimientos
• Escribir casos de prueba contra los requerimientos
• Priorizar los requerimientos analíticamente
• Control de cambios practico y eficaz