Creando requerimientos eficaces
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Creando requerimientos eficaces

on

  • 408 views

Creando requerimientos eficaces

Creando requerimientos eficaces

Statistics

Views

Total Views
408
Views on SlideShare
408
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Creando requerimientos eficaces Presentation Transcript

  • 1. Análisis de Ambigüedad Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Creando   Requerimientos   E1icaces   Presentación de Entrenamiento. 1
  • 2. Creando Requerimientos Eficaces – Contexto Del Negocio – ¿Que es un Requerimiento? – Definiciones – Tres Niveles de Requerimientos – Componentes de Ingeniería de Requerimientos – Características de Requerimientos Eficaces – Escribiendo Requerimientos Eficaces – Mejores Prácticas Para Documentar Requerimientos Análisis de Ambigüedades – Proceso de Pruebas Basadas en Requerimientos (RBT) – Revisión de Ambigüedad Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Agenda   2
  • 3. Contexto del Negocio – 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Razones Claves de los Fracasos de Proyectos 3
  • 4. Contexto del Negocio Requirements 82% Design 13% OTHER 4% CODE 1% Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Esfuerzo Típico para Encontrar y Corregir Defectos 4
  • 5. ¿Que es un Requerimiento? Perspectiva del Cliente 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” Creando Requerimientos Eficaces/ Análisis de Ambigüedad... WEBSTER’S DICTIONARY: “Something wanted or needed” “Algo deseado o necesario ” 5
  • 6. Definiciones “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.” Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Qué es un Requerimiento Efectivo? 6
  • 7. Tres Niveles de Requerimientos = Entrada Requerimientos de Negocio = Documento Formal Requerimientos de Usuario Atributos de Calidad Documento de Visión y Alcance Requerimientos del Sistema Reglas de Negocio Requerimientos Funcionales Interfaces Externas Restricciones Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Documento de Visión y Alcance 7 Especificación de Requerimientos de Software (SRS)
  • 8. Tres Niveles de Requerimientos •  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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Requerimiento de Negocio 8
  • 9. Tres Niveles de Requerimientos •  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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Requerimiento de Usuario 9
  • 10. Tres Niveles de Requerimientos • 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. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Requerimiento Funcional 10
  • 11. Componentes de Ingeniería de Requerimientos Ingeniería de Requerimientos Desarrollo de Requerimientos Obtención Manejo de Requerimientos Análisis (Entender) Especificación re-escribir clarificar Verificación Creando Requerimientos Eficaces/ Análisis de Ambigüedad...           re-evaluar corregir y cerrar diferencias 11
  • 12. Componentes de Ingeniería 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 La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Desarrollo de Requerimientos 12
  • 13. 1. Correcto 2. Viable 3. Necesario 4. Priorizado 5. Inequívoco 6. Verificable 7. Completo 8. Consistente 9. Modificable 10.Fácil de Seguir Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Características de Requerimientos Eficaces 13
  • 14. • 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 contradictorio Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Escribiendo Requerimientos Eficaces -1 14
  • 15. • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Escribiendo Requerimientos Eficaces -2 15
  • 16. • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Mejores Prácticas para Documentar Requerimientos 16
  • 17. Mejores Prácticas para Documentar Requerimientos • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Lineamientos de Identificadores 17
  • 18. • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Mejores Prácticas para Documentar Requerimientos 18
  • 19. Mejores Prácticas para Documentar 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 impactosejores Creando Requerimientos Eficaces/ Análisis de Ambigüedad... • Maneje las Versiones de los documentos de requerimientos 19
  • 20. Mejores Prácticas para Manejo de Requerimientos • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... • 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 20
  • 21. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... ANÁLISIS DE AMBIGÜEDADES 21
  • 22. Proceso de Pruebas Basadas en Requerimientos (RBT) Definición de Habilidad de ser Probado • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... • Los resultados se pueden medir/predecibles 22
  • 23. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Definir Requerimiento 23
  • 24. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Proceso de Pruebas Basadas en Requerimientos (RBT) 24
  • 25. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Proceso de Pruebas Basadas en Requerimientos (RBT) 25
  • 26. Proceso de Pruebas Basadas en Requerimientos (RBT) 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Proceso RBT: Pasos Básicos 26
  • 27. Proceso de Pruebas Basadas en Requerimientos (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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Beneficio de las Técnicas RBT 27
  • 28. Revisión de Ambigüedad ¿Tiene la respuesta correcta? Revisión Creando Requerimientos Eficaces/ Análisis de Ambigüedad... La mitad de dos y dos = ?? 28
  • 29. Revisión de Ambigüedad • Imagine un coche que ha sido diseñado para que “se maneje a si mismo”. • Lo que sigue representa uno de los requerimientos para este coche – ¿o no? • Anote todas las ambigüedades que usted pueda pensar - tiene 10 minutos. “Si la luz es roja, entonces pare.” Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Ejercicio de Practica #1 29
  • 30. Revisión de Ambigüedad Ejercicio de Practica #2 El Cajero Automático (ATM) enviará una alarma al epartamento de tecnología de la información (IT) cuando el ATM se ha tratado de forzar. En caso que el ATM seabra sin la llave y el código de seguridad, el ATM alertará al departamento inmediatamente para que pueda tomar la acción apropiada. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Requerimiento de Negocio Antes de la Revisión de Ambigüedad Identifique las Ambigüedades -- tiene 10 minutos. 30
  • 31. Revisión de Ambigüedad Ejercicio de Practica #2 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. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Ambigüedades Descubiertas Durante la Revisión de Ambigüedades 31
  • 32. Revisión de Ambigüedad Ejercicio de Practica #2 • Un Cajero Automático (ATM) enviará una alarma electrónica al Oficial de Seguridad enguardia al departamento de IT cuando el ATM se ha tratado de forzar, es decir, abierto sin el uso de una llave física, seguido por el código de seguridad válido. – Caso 1: (1) Si un operador autorizado de servicio inserta la llave física en la ranura de el ATM, entonces mostrara el siguiente mensaje en la consola del ATM: "introduzca por favor el código válido de seguridad." (2) Si el operador del servicio introduce el código válido de seguridad, entonces la puerta del ATM se abre. – Caso 2: Después de insertar la llave en el ATM, si el operador del servicio introduce un código de seguridad incorrecto, entonces (1) se muestra el siguiente mensaje en la consola del ATM: “Código de Seguridad inválido. Intente de nuevo por favor." (2) el operador del servicio ahora tiene tres intentos para introducir el código válido de seguridad. Si un código válido de seguridad se introduce en menos que o igual a tres intentos, entonces la puerta del ATM se abre. Después de cada uno de los primeros tres intentos con un código de seguridad inválido, el siguiente mensaje se mostrará en la consola del ATM: “Código de Seguridad Inválido. Intente de nuevo por favor." – Caso 3: Si un código válido de seguridad no ha sido introducido al tercer intento, entonces (1) el siguiente mensaje se mostrará en la consola del ATM: “Código de seguridad inválido. La oficina de seguridad será notificada." (2) El ATM envía una alarma a la Oficina de Seguridad inmediatamente. – Caso 4: En caso que el ATM se abra sin la llave y el código de seguridad válido, entonces el ATM envía una alarma al departamento de Seguridad inmediatamente que el ATM has sido forzado. Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Requerimiento de Negocio Corregido después de la Revisión de Ambigüedades 32
  • 33. Revisión de Ambigüedad • Un “de otro modo” pendiente • Ambigüedad de referencia • Alcance de la acción • Omisiones – Causas sin efectos – Efectos faltantes – Efectos sin causas – Omisiones completas – Causas faltantes • Operadores lógicos ambiguos – O, Y, Ni, Y No – Conectores implícitos – Operadores compuestos • Negación – Alcance de la negación – Negación innecesaria – Doble negación • Declaraciones ambiguas – Verbos, adverbios, adjetivos – Variables, Seudónimos innecesarios – Abreviaciones y acrónimos • Organización aleatoria – Causas y efectos mixtos – Secuencia de casos al azar • Supuestos integrados – Conocimiento funcional/de ambiente • Relación de precedencia ambigua • Casos implícitos • Etcétera. • Es Decir (i.e.) vs. Por Ejemplo (E.G.) • Ambigüedad temporal • Limite de la ambigüedad • Palabras y frases ambiguas Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Lista de Comprobación De la Revisión De Ambigüedad 33
  • 34. Revisión de Ambigüedad Ejemplo con ambigüedad: “El código debe ser cualesquiera A, B, o C.” ¿Entonces? ¿Una condición de error? Ejemplo sin ambigüedad: Si el CLIENTE es un CLIENTE-CORPORATIVO Entonces FUNCION_1 De Otro Modo (CLIENTE es un CLIENTE-MINORISTA) NO_ACCION fin. Revisión Creando Requerimientos Eficaces/ Análisis de Ambigüedad... “De Otro Modo” pendientes 34
  • 35. Revisión de Ambigüedad • “Para la transacción 1, actualizar el registro del cliente, imprimir el estado de cuenta del cliente, etcétera.” • “La cantidad total debe de ser pagada para miembros plenos, miembros asociados, etcétera.” Revisión Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Etcétera 35
  • 36. Revisión de Ambigüedad Sumar el INTERES-GANADO al BALANCE-DE-CUENTA. Si es mas de $1,000 entonces pasar el CLIENTE a LISTA-CUENTAS-CLAVES. VERSUS Sumar el INTERES-GANADO al BALANCE-DE-CUENTA. Si el INTERES-GANADO es mas de $1,000 entonces pasar el CLIENTE a LISTA-CUENTAS-CLAVES. Revisión Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Nombres Explícitos de Variables 36
  • 37. Revisión de Ambigüedad De un libreto de seguridad de una línea aérea (encontrado en el bolsillo del asiento): “Si usted está sentado en una fila de salida y usted no puede leer esta tarjeta ni puede ver lo suficientemente bien para seguir estas instrucciones, dígale por favor a un miembro de la tripulación." Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Descuidos 37
  • 38. Revisión de Ambigüedad • Todas las ambigüedades eliminadas • Procesos descritos a un nivel predecible/que se pueda probar • Todas las reglas son explícitas • Todas las reglas son lógicamente consistentes • Se aplican consistentemente los estándares de proceso • Escritos en un estilo que es: – consistente – que todas las audiencias pueden leer • Optimizado la probabilidad de re-uso • Da apoyo al seguimiento Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Características a Buscar 38
  • 39. Revisión de Ambigüedad • Educar a los usuarios, desarrolladores, gerentes y probadores • Una asociación de colaboración entre usuarios-consultoresdesarrolladoresprobadores • 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 Creando Requerimientos Eficaces/ Análisis de Ambigüedad... Cllaves para Requeriimiientos Excellentes 39