02 desarrollo de requisitos

1

Ingeniería de Requisitos

Tema 2: Desarrollo de Requisitos(Dr. Ricardo Quintero)

2

Temas

La Visión del Producto y el Alcance del Proyecto

Clasificación de los Usuarios Levantamiento de Requisitos Entendiendo los Requisitos de Usuario Las Reglas del Negocio Documentando los Requisitos Modelos y Diagramas para diversos Requisitos Requisitos No Funcionales Validación de Requisitos

La Visión del Producto y el Alcance del Proyecto

Historia verdadera:

“Cuando mi colega Karen introdujo en su compañía la inspección del documento de requisitos, observó que muchos de los aspectos que los inspectores detectaron pertenecía al alcance del proyecto. Los inspectores frecuentemente tenían un entendimiento diferente sobre el alcance y objetivos del proyecto. En consecuencia, tuvieron dificultad para determinar que RF pertenecían al DERS”

3

Introducción

Los RN representan el nivel de abstracción más alto en la cadena de requisitos.

Definen la Visión y el Alcance para el sistema software.

Los RU y los RF deben alinearse al contexto y objetivos que los RN establecen.

4

Introducción

Proyectos que no tienen bien definida y comunicada la dirección invitan al desastre: los stakeholders nunca se ponen de acuerdo en los requisitos si carecen de un entendimiento común de los RN para el producto.

5

Introducción

Un síntoma común de que los RN no están suficientemente definidos se refleja en la inclusión, borrado y agregado continuo de características.

La Visión y el Alcance se deben resolver antes que se detallen los RF.

Esta Visión y Alcance ofrece el marco de referencia adecuado para la toma de decisiones sobre cambios y extensiones en requisitos.

6

La Visión del Producto

Def.- Describe lo que es el producto actual y lo que eventualmente llegará a ser.

La VP alinea a todos los stakeholders en una dirección común.

7

El Alcance del Proyecto

Def.- Identifica que porción de la visión a largo plazo del producto manejará el proyecto actual.

El AP pone límites a lo que estará dentro o fuera. Define los límites del proyecto.

Los detalles del AP se representan mediante la línea base de requisitos que el equipo define para el proyecto.

8

Visión del Producto y Alcance del Proyecto

La Visión aplica al Producto como un todo. Cambiará lentamente ante la evolución de los objetivos del negocio.

El Alcance pertenece a un proyecto específico o iteración que implementará el siguiente incremento de la funcionalidad del producto. Más dinámico que la visión, el líder de proyecto la ajusta en función de tiempo, presupuesto, recursos, calidad.

9

Visión del Producto y Alcance del Proyecto-Gráficamente

10

El documento de Visión y Alcance

El documento de Visión y Alcance recolecta los RN en un solo documento que pone la base para el trabajo subsecuente.

El propietario de este documento es el patrocinador ejecutivo del proyecto (o alguien similar).

El analista puede trabajar con el propietario para escribir el documento.

11

El documento de Visión y Alcance

La entrada a los RN debe provenir de los individuos que tienen un claro sentido del porqué del proyecto.

12

Plantilla básica para el documento de visión

Puede basarse en esta plantilla

13

Ejemplos…

Oportunidad de Negocio: “Explotar el registro pobre de seguridad de un producto de la competencia”.

Objetivo de Negocio: “Capturar el 80% del mercado por ser reconocido como el producto más seguro en el mercado a través de revisiones de revistas y encuestas de consumidores”.

Necesidad del cliente: “Un producto más seguro”.

Característica: “Un motor de seguridad nuevo, robusto”.

14

El Diagrama de Contexto

La descripción del Alcance establece los límites y conexiones entre el sistema y el resto del universo.

El Diagrama de Contexto ilustra gráficamente estos límites.

Incluye: Terminadores: que interactúan con el

sistema. Datos y control. Flujo

15

El Diagrama de Contexto

Se puede incluir en el documento de Visión y Alcance o como un apéndice del DERS.

16

Ejemplo de Diagrama de Contexto

17

18

Temas

La Visión del Producto y el Alcance del Proyecto Clasificación de los Usuarios Levantamiento de Requisitos Entendiendo los Requisitos de Usuario Las Reglas del Negocio Documentando los Requisitos Modelos y Diagramas para diversos Requisitos Requisitos No Funcionales Validación de Requisitos

Clasificación de los Usuarios

La participación del cliente es un factor crítico para el éxito de los proyectos.

El éxito en los requisitos software, y por tanto en el desarrollo de software, depende en obtener la voz del cliente cerca del oído del desarrollador.

Es importante identificar representantes de clientes al proyecto.

19

Pasos para buscar la voz del cliente

1. Identificar las diferentes clases de usuarios para el producto.

2. Identificar las fuentes de RU.3. Seleccionar y trabajar con individuos

que representen cada clase de usuario y otros grupos de stakeholders.

4. Acordar quienes serán los tomadores de decisiones de requisitos de tus proyectos.

20

Fuentes de Requisitos

Los orígenes de los Requisitos Software dependerán de la naturaleza del producto y tu ambiente de desarrollo.

21

Típicas Fuentes de Requisitos

Entrevistas y discusiones con usuarios potenciales.

Documentos que describen el producto actual o de la competencia.

Problemas reportados y solicitudes de extensión al sistema actual.

Encuestas de mercado y cuestionarios de usuarios.

Observando usuarios en su trabajo. Análisis de escenarios (CU). Eventos y respuestas (sistemas de tiempo real).

22

Clases de Usuarios

Los usuarios difieren en los siguientes aspectos: Su experiencia en el dominio y su

expertise en computación. Las características que ellos usan. Las tareas que realizan en soporte a

sus procesos de negocio. Sus privilegios de acceso o niveles de

seguridad.

23

Clases de Usuarios

Basados en los aspectos anteriores se pueden agrupar los usuarios en diferentes clases de usuarios.

24

Clases de Usuarios

Usuarios favorecidos: reciben trato preferencial cuando se toman decisiones de prioridad o se resuelven conflictos entre requisitos.

Usuarios desfavorecidos: aquellos que se espera que no usen el producto (por razones legales, seguridad)

25

Clases de Usuarios

Usuarios ignorados y otras clases de usuarios: otros usuarios que no se consideran como parte de la clasificación.

26

Importancia de la clasificación de usuarios

Cada clase de usuario tendrá sus propios requisitos para las tareas que desempeñan

Tendrán diferentes requisitos no funcionales (usabilidad) que conducirá las decisiones de diseño de la IU.

Muy importante: cada tipo de usuario será la fuente básica de levantamiento de requisitos.

Considere, además, un catálogo de usuarios para todos los sistemas. Podrá reutilizarlo sistema a sistema.

27

Clases de Usuarios y el DERS

Documenta las clases de usuarios y sus características, responsabilidades y localizaciones físicas en el DERS.

Incluye toda la información pertinente de cada clase de usuario, su tamaño relativo o absoluto y cuales clases son favorecidas, esto ayudará a priorizar las peticiones de cambios y conducir la evaluación de impacto posteriormente.

28

Ejemplo de Clases de Usuarios

Químicos (Favorecidos)

Aproximadamente 1000 químicos localizados en 6 edificios utilizarán el sistema para solicitar químicos de vendedores y del almacén. Cada químico utilizará el sistema varias veces al día, necesitan buscar en catálogos de vendedores.

Compradores Conocen poco de química y necesitan ayudas de consulta para los catálogos de vendedores. Utilizarán el sistema unas 20 veces al día

29

Un usuario ejemplo

Es posible crear 1 usuario representativo de cada clase, como sigue:“Alfredo, de 41 años, ha sido químico en Contoso Farmaceutica desde que se graduó hace 14 años. No tiene mucha paciencia con las computadoras.

Trabaja en 2 proyectos a la vez …” Conforme exploras los requisitos del químico, piensa

en Alfredo como el Arquetipo de esta clase de usuario y pregúntate: ¿Qué necesitará hacer Alfredo?

30

Buscando Representativos de Usuarios

Todo tipo de proyecto necesita usuarios representativos que provean la voz del cliente.

Estos usuarios representativos deberían estar involucrados a través de todo el ciclo de vida, no sólo en la fase aislada de requisitos al inicio.

Una estrategia útil también es crear grupos enfocados de usuarios que incluyan expertos y novatos.

31

Rutas de comunicación entre Usuarios y Desarrolladores

32

El Campeón del Producto (Product Champion)

Cada Campeón de Producto es la interfase principal entre miembros de una clase de usuario y el analista de proyectos.

Los Campeones deben ser usuarios actuales, no representantes de patrocinadores, gerentes o desarrolladores de software que pretenden ser usuarios.

33

El Campeón del Producto (Product Champion)

Los mejores Campeones de Producto tienen una clara visión del nuevo sistema y son entusiastas acerca de él porque ven el próximo beneficio para él y sus compañeros.

Deben ser comunicadores efectivos, respetados por sus colegas.

Deben tener entendimiento pleno del dominio del problema.

Debe estar completamente empoderado para tomar decisiones sobre sus representados.

34

Expectativas de los Campeones de Productos

35

Categoría Actividades

Planeación

•Refinar el alcance y limitaciones del producto.•Definir las interfases a otros sistemas.•Evaluar el impacto de nuevos sistemas sobre operaciones del negocio.•Definir la ruta de transición a partir de las aplicaciones actuales

Requisitos •Recolectar requisitos de otros usuarios•Desarrollar los escenarios en los CU•Resolver conflictos entre requisitos propuestos

Expectativas de los Campeones de Productos

36

Categoría Actividades

Validación&Verificación

•Inspeccionar los documentos de requisitos•Definir el criterio de aceptación•Desarrollar los casos de prueba a partir de los escenarios de los CU•Proveer los conjuntos de datos de pruebas•Realizar las pruebas beta

Ayuda a usuarios

•Escribir porciones de manuales de usuarios y ayuda•Preparar material para entrenamiento•Presentar demostraciones de productos a compañeros

Gestión de Cambios

•Evalúa y prioriza las correcciones de defectos•Evalúa y prioriza peticiones de extensión•Evalúa el impacto de cambios propuestos de requisitos en usuarios y procesos de negocio•Participa en las decisiones de cambios

“Vendiendo” la idea del Campeón de Producto

Espera oposición a la propuesta del Campeón del Producto: “Los usuarios están muy ocupados”, “La gerencia quiere tomar las decisiones”, “Nos va a demorar”, “Es muy caro”, “No se lo que voy a hacer como Campeón de Producto”.

Recuerda la importancia del involucramiento del usuario.

37

38

Temas


Introducción

Lea la siguiente Historia. ¿Le ha sucedido algo similar al

levantar requisitos? Comente.

39

Introducción

El corazón de la IR es la Elicitación de Requisitos (o levantamiento de requisitos).

La ER es el proceso de identificar las necesidades y restricciones de los diferentes stakeholders del sistema software.

40

Introducción

La ER se centra en los RU: las tareas que los usuarios deben realizar con el sistema y las expectativas de rendimiento, usabilidad y otros atributos de calidad del usuario.

El analista debe cambiar la pregunta : ¿Qué deseas? por ¿Qué necesitas hacer?

41

Introducción

El resultado de la ER es un acuerdo general de las necesidades.

Una vez que se encuentran estas necesidades, los desarrolladores pueden explorar soluciones alternativas para atender las necesidades.

Los participantes de la ER deben resistir la tentación de diseñar el sistema hasta que entiendan el problema, de otra forma se arriesgan a hacer considerable tarea de rediseño posteriormente.

42

Introducción

El énfasis principal es en las tareas en lugar de la IU y en enfocarse en las necesidades básicas más que en deseos. Esto mantiene al equipo enfocado y evita el desvío prematuro hacia detalles de diseño.

43

Planeación de la Elicitación de Requisitos

Empieza por planear las actividades de la Elicitación de Requisitos.

Aún un plan simple de acciones incrementa la posibilidad de éxito y ofrece expectativas reales a los stakeholders.

44

Elementos a incluir en la planeación de la ER

Objetivos (explorar CU, desarrollar los RF, etc.) Estrategias y procesos (encuestas, talleres,

visitas al cliente, entrevistas individuales o a grupos) Productos (lista de CU, el DERS, análisis de

encuestas o especificaciones de atributos de calidad)

Estimación de tiempos y recursos (identificando clientes y analistas en las actividades, estimaciones de esfuerzo y tiempo)

Riesgos (factores que pueden impedir la ER, severidad de cada riesgo y como mitigar o controlar el riesgo)

45

Elicitación de Requisitos

La ER tiene éxito cuando se establece una relación colaborativa entre clientes y los desarrolladores de requisitos.

La comunicación se facilita cuando se usa el vocabulario del dominio y se evita la “jerga” computacional. Use glosarios.

Cuando la discusión se empieza a tornar hacia el “espacio de la solución” la pregunta ¿Porqué? puede devolverla al “espacio del problema”

46

Elicitación de Requisitos

En lugar de sólo transcribir lo que los usuarios dicen, un analista creativo sugiere ideas y alternativas a los usuarios durante la elicitación.

Cuando los usuarios no pueden expresar lo que ellos necesitan, quizá puedas observar su trabajo (o incluso hacerlo) y sugerir formas de automatizar el mismo.

Después de cada entrevista, documenta los aspectos discutidos y pide a los entrevistados que revisen la lista y hagan correcciones.

47

Talleres de Elicitación

Los talleres de requisitos son una técnica altamente efectiva para vincular usuarios y desarrolladores (de requisitos).

El facilitador debe planear el taller, seleccionar los participantes y guiar a los participantes a un resultado exitoso.

48

Tips para conducir sesiones exitosas en talleres de requisitos

Establecer reglas claras: Iniciar y finalizar a tiempo. Regresar rápido de los “breaks”. Sólo uno comenta a la vez. Todos deben contribuir. Enfocar comentarios en aspectos, no en

individuos.

49


Mantenerse en el alcance: Usar el documento de visión y alcance

para confirmar si los RU propuestos caen dentro del alcance del proyecto.

Enfocarse en las tareas del usuario y no en detalles de diseño de IU (que vendrá después).

50


Usar “parking lots” para registrar elementos para posterior consideración: Múltiple información surgirá en el taller

(atributos de calidad, reglas de negocio, ideas de IU, restricciones, etc.). Usar hojas de rotafolio como “Parking lots” para no perderlas, mostrar respeto a quien las brinda y usarlas después.

51


Discusiones “Timebox”: Asignar una periodo fijo de tiempo para

discutir cada tópico (ej. 30 min. Por cada CU). Evitar invertir más tiempo que el necesario para evitar enfrentar otros tópicos.

52


Mantener el equipo pequeño e incluir los participantes correctos. Grupos mayores a 5 o 6 participantes avanzarán

más lento. Incluya al Campeón del Producto y otros

representantes de usuarios, un analista de requisitos y un desarrollador. Considere “experiencia”, “conocimiento” y “autoridad para tomar decisiones” como calificadores para participar en el taller.

Mantenga a todos participando en el taller.

53

Clasificando la entrada de los clientes

El analista debe clasificar la entrada de los clientes:

54

Requisitos del Negocio

Cualquiera que describa los beneficios económicos, de mercado o del negocio que los clientes o la organización desea ganar a partir del producto. “Incremento del mercado en un X%” “Ahorro de $Y por año en electricidad gastado

ahora por unidades ineficientes” “Ahorro de $Z en costos de mantenimiento

consumidos por el sistema legado W”

55

Casos de Uso o Escenarios

Oraciones sobre objetivos de usuario o tareas del negocio que el usuario necesita realizar. “Necesito imprimir una etiqueta para

cada paquete” “Necesito gestionar una cola de

muestras químicas esperando ser analizadas”

“Necesito calibrar el controlador de la bomba”

56

Reglas de Negocio (RN)

Cuando el cliente dice que sólo ciertas clases de usuarios pueden realizar una actividad bajo condiciones específicas.

Se pueden derivar RF para forzar las reglas.

Las RN no son RF. “Debemos cumplir con cierta ley o política corporativa” “Se debe conformar algún a un cierto estándar” “Si alguna condición es verdad, entonces algo sucede” “Debe ser calculado de acuerdo a cierta fórmula”

57

Requisitos Funcionales (RF)

Describen comportamientos observables que el sistema exhibirá bajo ciertas condiciones y las acciones que permitirá a los usuarios tomar.

Se derivan de los RU, RN y el DERS. “Si la presión excede 40 psi, la luz de precaución

se encederá” “El usuario será capaz de ordenar la lista del

proyecto en orden alfabético ascendente y descendente”

“El Sistema enviará un e-mail al Coordinador de Ideas cuando alguien genere una nueva idea”

58

Atributos de Calidad

Oraciones que indican que tan bien el sistema desempeñará algún comportamiento o permitirá a los usuarios tomar alguna acción. Rápido, fácil, intuitivo, amigable con el

usuario, robusto, confiable, seguro, eficiente. (Todos éstos se deben definir de forma precisa con el usuario).

59

Requisitos de Interfases Externas

Describen conexiones entre tu sistema y el resto del universo.

El DERS debe incluir secciones para interfases con usuarios, hardware y otros sistemas software. “Debe leer señales de un dispositivo” “Debe enviar mensajes a otro sistema” “Debe ser capaz de leer (o escribir) archivos en

algún formato” “Debe controlar una pieza de hardware” “Los elementos de la IU deben conformarse a un

estilo estándar de IU”

60

Restricciones

Restricciones de diseño e implementación que acotan legítimamente las opciones disponibles al desarrollador. “Los archivos enviados electrónicamente no

deben exceder 10 MB de tamaño” “Debe ser escrito en Java” “No debe requerir más de 1 Gb de RAM” “Debe operar idénticamente a otro sistema” “Debe usar un control de IU específico”

61

Definiciones de Datos

Cuando el usuario describe el formato, tipo de dato, valores permitidos o valores por default para un elemento de datos o la composición de una estructura de datos compleja. “El código postal consiste de cinco dígitos,

seguido por un guión opcional, el valor por default es 0000”

Recolecte estos en un diccionario de datos, una referencia maestra que el equipo puede utilizar a lo largo de todo el desarrollo del producto y su mantenimiento.

62

Ideas solución

Mucho de lo que los usuarios presentan como requisitos caen en la categoría de ideas solución.

Alguien que describe una forma específica de interactuar con el sistema para realizar cierta acción está presentando una solución sugerida.

El analista debe “sumergirse” debajo de la Idea Solución para obtener el verdadero requisito.

La clave: preguntar ¿Porqué?

63

¿Cómo saber cuando terminar?

Si el usuario no puede pensar en más CU, quizá terminaste.

Si el usuario propone nuevos CU, cuyos RF ya fueron derivados, quizá terminaste.

Si los usuarios repiten aspectos cubiertos en previas discusiones, quizá terminaste.

64

¿Cómo saber cuando terminar?

Si sugiere nuevas características, RU o RF fuera de alcance.

Si los requisitos propuestos son de baja prioridad.

Si los usuarios están proponiendo capacidades que serán incluidas “algún día en la vida del producto” en lugar de “ahora”.

65

66

Temas


Introducción

Lea la siguiente Historia. ¿Cómo conduce usted los talleres

de requisitos para obtener los CU?

67

Introducción

Las personas utilizan los sistemas software para alcanzar objetivos y la industria del software busca crear software útil.

Un prerrequisito necesario para diseñar software útil es conocer lo que los usuarios intentarán hacer con él.

68

Introducción

Por muchos años, los analistas han utilizado escenarios para obtener los requisitos de usuarios.

Un escenario es una descripción de una sola instancia de uso del sistema.

Ivar Jacobson, Larry Constantine y Lucy Locwood, así como Alistair Cockburn han formalizado esto en los Casos de Uso.

69

El enfoque de Casos de Uso

Un Caso de Uso describe una secuencia de interacciones entre el sistema y un actor externo.

Aunque nacen en el mundo OO, pueden utilizarse para cualquier paradigma de desarrollo.

Los CU cambian la perspectiva de desarrollo de requisitos para discutir lo que los usuarios necesitan lograr en contraste al enfoque tradicional de preguntar a los usuarios lo que desean que el sistema haga.

70

Diagramas de CU Proveen una representación visual de alto

nivel de los RU.

71

Casos de Uso y Escenarios

Un CU es una actividad única que un actor realiza para lograr algo de valor.

Un CU es una colección de escenarios relacionados.

Los escenarios pueden ser normales o alternativos.

72

Elementos esenciales de la descripción de un CU

Un identificador único Un nombre que de forma breve establezca la

tarea del usuario “verbo+objeto” Una descripción textual escrita en lenguaje

natural Una lista de precondiciones Una lista de poscondiciones Una lista numerada de pasos que muestren los

pasos de la secuencia de diálogo entre actor y sistema

73

Cursos Normal y Alternativos en un CU

74

CU que comparten un conjunto común de pasos-<<include>>

75

CU con granuralidad mayor

76

Identificando Casos de Uso

Se pueden identificar en varias formas: Identifica los actores primero y

después los procesos de negocio en los cuales participan.

Identifica los eventos externos a los cuales el sistema debe responder y después relaciona estos eventos a actores participantes y CU especificos.

77

Identificando Casos de Uso

Se pueden identificar en varias formas: Expresar procesos de negocio en

términos de escenarios específicos, generalizar los escenarios a CU e identificar los actores involucrados en cada CU.

Derivar los CU a partir de RF. Si algunos requisitos no trazan a CU alguno, considere si realmente se necesitan.

78

Documentando los CU

En esta etapa de exploración, los participantes deben pensar en CU esenciales: simplificados, generalizados, abstractos, libres de tecnología e independientes de implementación.

El foco debe ser el objetivo que el usuario trata de alcanzar y las responsabilidades del sistema.

79

Documentando los CU

Los CU esenciales están a un nivel de abstracción más alto que los CU concretos. Estilo concreto: capturar el número ID

del químico. Estilo esencial: especificar el químico

deseado.

80

Ejemplo de CU

Este es un ejemplo de CU

81

CU y Casos de Prueba

Así como los CU esenciales también se pueden crear Casos de Prueba conceptuales (independientes de teconología).

Estos Casos de Prueba ayudan al equipo a tener un claro entendimiento de cómo el sistema se comportará en escenarios específicos.

82

CU y RF

Los desarrolladores software no implementan RN o CU, ellos implementan RF: “bits” específicos de comportamiento de sistema que permiten a los usuarios ejecutar los CU y lograr sus objetivos.

Es necesario que el analista traduzca la visión de requisitos del usuario (expresada en el CU) a la visión del desarrollador.

83

Formas de documentar los RF obtenidos a partir de los CU

Sólo CU: incluir los RF directo en la descripción del CU.

CU y DERS: escribir descripciones simples directas del CU y documentar los RF derivados en el DERS. Se debe establecer la trazabilidad entre ambos.

84

Formas de documentar los RF obtenidos a partir de los CU

Sólo DERS: organizar el DERS por CU o por característica e incluir ambos, CU y RF, en el DERS.

85

Errores a evitar

Muchos CU: quizá porque no se estén escribiendo al nivel de abstracción adecuado. Típicamente se deben tener más CU que RN y características, pero menos que los RF.

86

Errores a evitar

Incluir diseño de IU en los CU: los CU se deberían enfocar en lo que los usuarios necesitan lograr con la ayuda del sistema, no en como se deberían ver las pantallas. Enfatiza las interacciones conceptuales entre actores y sistema y difiere la IU específica a la etapa de diseño.

87

Errores a evitar

Incluir definiciones de datos en los CU. Manejarlo en un diccionario de datos separado.

CU que los usuarios no entienden. Si los usuarios no pueden relacionar la descripción del CU a sus procesos de negocio o tareas, hay problemas con el CU.

Uso excesivo de relaciones include y extends.

88

89

Temas


Introducción

Toda organización opera de acuerdo a un conjunto extenso de políticas corporativas, leyes y estándares industriales.

Tales principios controladores se les conoce colectivamente como Reglas de Negocio.

90

Introducción

Las Aplicaciones Software frecuentemente forzan las RN, en otros casos son controladas humanamente mediante políticas y procedimientos.

Muchas RN se originan fuera del contexto de toda aplicación software, aunque suelen ser la fuente mayor de RF porque dictan capacidades que el sistema debe poseer para conformar con las reglas.

Aún Requisitos del Negocio de alto nivel podrían conducirse a partir de RN (cumplir con alguna regulación gubernamental).

91

Introducción

Las RN se deben tratar como un Activo Importante.

Si no se documentan o manejan apropiadamente existirán sólo en la “mente” de los individuos: se entenderán de forma distinta, se manejarán inconsistentemente.

Si se conoce donde y como cada aplicación implementa sus RN, será mucho más fácil cambiar las aplicaciones cuando la regla cambie.

Tener un Repositorio Maestro de RN facilitará a todas las aplicaciones afectadas su implementación consistente.

92

Taxonomía de las RN

Se han propuesta diferentes taxonomías (clasificaciones) para organizar las RN.

Veremos una taxonomía simple que incluye cinco tipos de RN que trabajan para muchas situaciones.

93

Taxonomía de las RN

94

Una sexta categoría podría incluir términos, palabras definidas, frases y

abreviaciones que son importantes para el negocio.

(Un Glosario es un lugar conveniente para definir términos)

Hechos (Facts)

Los Hechos son estatutos simples que son verdad a lo largo de todo el negocio. Son llamados invariantes (verdades inmutables de entidades y atributos).

Describen asociaciones o relaciones entre términos importantes del negocio.

Otras RN podrían referenciar ciertos Hechos, pero los Hechos en sí mismos generalmente no se traducen en RF software.

95

Ejemplos de Hechos (Facts)

“Cada contenedor químico tiene un identificador único en código de barras”

“Cada orden deberán tener un cargo de embarque”

“Cada línea de producto en una orden representa una combinación específica de químico, grado, tamaño de contenedor y número de contenedores”

“Boletos no reembolsables generan un cargo cuando el comprador cambia el itinerario”

“El impuesto de ventas no se calcula sobre cargos de embarque”

96

Restricciones (Constraints)

Los Constraints acotan las acciones que el Sistema o sus usuarios pueden realizar.

Algunas palabras y frases que sugieren una RN “Restricción”: debe, no debe, podría, solamente.

97

Ejemplos de Restricciones (Constraints)

“Un solicitante menor de 18 años debe tener un padre o tutor como aval del préstamo.”

“Un usuario puede solicitar un químico en nivel 1 solamente si tiene entrenamiento en químicos de uso rudo en los pasados 12 meses.”

“La correspondencia podría no desplegar más de 4 dígitos del número del IMSS.”

“La tripulación de una línea aerea debe recibir al menos 8 Hrs. De descanso continuo en cada periodo de 24 Hrs.”

98

Hay muchas restricciones

Pueden existir restricciones a nivel de proyecto o diseño o implementación.

Muchas RN imponen restricciones sobre la forma en la que el negocio opera: donde se reflejen en los RF software, la restricción es la justificación del RF.

En el acceso al sistema también hay restricciones (manejo de Passwords).

99

Habilitadores de Acción (Action Enablers)

Una regla que dispara alguna actividad bajo condiciones específicas es un Habilitador de Acción.

La condición podría ser una combinación compleja de valores falso y verdaderos para múltiples condiciones individuales.

100

Habilitadores de Acción (Action Enablers)

Forma general:“Si <alguna condición es verdadera o sucede algún evento> entonces <algo

sucede>” Se pueden documentar como

Tablas de decisión (se verán después).

101

Habilitadores de Acción (Action Enablers) Ejemplos

“Si el almacén de químicos tiene contenedores de un cierto químico, entonces ofrece contenedores al solicitante”

“El último día del cuatrimestre, genera el reporte EP sobre manejo de químicos”

“Si el cliente ordenó un libro para autor que ha escrito múltiples libros, entonces ofrece los otros libros del autor antes de aceptar la orden”

102

Inferencias (Inferences)

Es una regla que establece nuevo conocimiento basado en la veracidad de ciertas condiciones.

También se le conoce como conocimiento inferido.

La inferencia crea un nuevo hecho a partir de otros hechos o a partir de computaciones.

103

Inferencias (Inferences)

También utilizan la forma “Si/Entonces”, pero la clausula “Entonces” implica un Hecho o Pieza de Información, no una acción a realizar.

104

Inferencias (Inferences) Ejemplos

“Si un pago no se recibe dentro de 30 días de calendario o la fecha está vencida, entonces la cuenta es reportada”

“Si el vendedor no puede embarcar un producto de la orden dentro de cinco días a partir de la recepción de la orden, entonces el producto es devuelto”

“Químicos con toxicidad LD50 menor a 5 mg/Kg son consideradores peligrosos”

105

Computaciones (Computations)

Cálculos realizados usando fórmulas matemáticas específicas o algoritmos.

Muchas computaciones siguen reglas que son externas a la compañía (como el cálculo de impuestos).

106

Computaciones (Computations)

“El precio unitario se reduce un 10% para ordenes de 6 a 10 unidades, 20% para órdenes de 11 a 20 unidades y 35% para órdenes mayores a 20 unidades”

“El cargo por envío terrestre para una orden que pesa más de 2 Kg. Es $4.75 más $0.12 por fracción”

“El precio total de una orden se calcula como la suma del precio de los productos, menos los descuentos, más lo impuestos, más el cargo de embarque y seguro”

107

Documentando las RN

Dado que las RN pueden influir múltiples aplicaciones, la organización debería manejarlas como un activo a nivel empresarial (no a nivel de proyecto).

En principio un catálogo simple es suficiente, en casos mayores se podría manejar una base de datos (con todo, busque siempre la simplicidad).

Trate de definir una plantilla para la documentación.

108

Ejemplo de plantilla para documentar las RN

109

ID Definición de la Regla

Tipo de Regla

Estática/Dinámica

Fuente

ORDER-15

Un usuario puede solicitar un químico a nivel 1 solamente si tiene entrenamiento en los 12 meses anteriores

Restricción Estática Política corporativa

DISC-13 El descuento a la orden se calcula basado en el tamaño de la orden actual

Computación Dinámica Política corporativa

Reglas del Negocio y Requisitos

Simplemente preguntar al usuario: “¿Cuáles son tus RN?” Suele no ayudar para su descubrimiento.

Dependiendo de la aplicación, algunas veces tendrás que inventar la RN conforme avances en el análisis y otras las descubrirás durante las discusiones de requisitos.

110

Reglas del Negocio y Requisitos

Durante el taller de Elicitación de Requisitos el analista tendrá que hacer preguntas sobre las razones de ciertos requisitos y restricciones que los usuarios presenten.

Estos discusiones provocan el surgimiento de RN como justificaciones.

111

Fuentes de RN y preguntas posibles que las obtienen

112

RN descubiertas y su implementación

Después de identificar y documentar la RN, determine cuales se deben implementar en el software.

Algunas RN conducirán a CU (y por tanto a Requisitos Funcionales que forzarán la regla).

113

RN descubiertas y su implementación-Ejemplo

Regla #1 (Habilitador de Acción) “Si la fecha de expiración para el contenedor químico se ha alcanzado, entonces notifique a la persona que posee actualmente el contenedor”

Regla #2 (Inferencia) “Un contenedor de un químico que puede formar un producto explosivo se considera expirado 1 año después de su fecha de manufactura”

Regla #3 (Hecho) “El Éter puede formar espontáneamente peróxidos explosivos”

114

RN descubiertas y su implementación-Ejemplo

Estas reglas dieron origen al CU “Notificar el propietario químico de expiración”

Un RF para este CU es “El sistema enviará una notificación por e-mail al propietario del contenedor químico en la fecha en la que el contenedor expire”

115

Trazabilidad entre RF y sus Reglas de Negocio padre

Use un atributo en el requisito llamado “Origen” e indique la regla que originó el RF

Defina enlaces de trazabilidad entre el RF y la(s) RN(s) pertinentes en la Matriz de Trazabilidad.

116

Recomendación Final

Para prevenir redundancia, no dupliques reglas del catálogo de RN en el DERS.

En su lugar, el DERS debería referenciar hacia reglas específicas como fuente, digamos, de algoritmos.

117

Siguientes pasos…

Lista todas las RN que pienses pertenecen al proyecto en el que estás trabajando. Empieza poblando un catálogo de RN. Clasifícalas de acuerdo a la taxonomía propuesta y discute el origen de cada regla.

Identifica la justificación detrás de tus requisitos funcionales para descubrir otras RN.

118

Siguientes pasos…

Construye una matriz de trazabilidad para indicar cuales RF o elementos de la base de datos implementan cada RN que has identificado.

119

120

Temas


Introducción

El resultado del Desarrollo de Requisitos es un acuerdo entre clientes y desarrolladores sobre el producto a construir.

El documento de Visión y Alcance contiene los RN.

Los Requisitos de Usuario se capturan en los CU.

Los RF y RNF detallados residen en el Documento de la Especificación de Requisitos Software (DERS).

121

Introducción

A menos que todos los requisitos se escriban en un formato legible y los stakeholders clave los revisen, la gente no tendrá seguridad de lo que se está acordando.

122

Introducción

Los requisitos software se pueden representar de diversas formas: Documentos que usan lenguaje natural

estructurado y bien escrito. Modelos gráficos ilustrando procesos,

estados del sistema y sus cambios, relaciones de datos, etc.

Especificaciones formales matemáticas. La forma más práctica: documentos

textuales+modelos gráficos.

123

La Especificación de Requisitos Software

La ERS establece de forma precisa las Funciones y Capacidades que el sistema software debe proveer y las Restricciones que debe respetar.

Es la base para la posterior planeación, diseño y codificación (las cuales no deberían incluirse ahí).

124

ERS: completa y correcta

La ERS es el repositorio último para los requisitos del producto, por lo que se espera que sea completa.

Ni desarrolladores, ni clientes deberían hacer supuestos: si una cierta capacidad o calidad no aparece ahí, no se debe esperar que aparezca en el producto.

125

ERS: evolutiva e iterativa

No se debería esperar escribir el DERS completo desde el inicio.

Pero si se necesita capturar en él los requisitos de cada incremento, antes de construir tal incremento.

Antes de iniciar cada iteración se deberían fijar (obtener su línea base).

La línea base es el resultado de la revisión y aprobación de la ERS.

126

Organizando la ERS: Etiqueta los Requisitos

Para satisfacer el criterio de trazabilidad y modificabilidad cada RF se debe etiquetar.

Numéralos secuencialmente: RF-39, RNF-40.

En caso de duda en algún requisito, señálalo de alguna manera: TBD (To be determined).

127

ERS e Interfases de Usuario

Imágenes de pantallas o arquitecturas de IU describen soluciones (diseños), no requisitos.

El diseño de pantallas podría retardar el establecimiento de la línea base de los requisitos.

Incluir diseño de IU en requisitos puede resultar en un diseño visual conduciendo los requisitos, lo cual puede llevar a vacíos funcionales.

128

ERS e Interfases de Usuario

Un balance adecuado podría ser incluir imágenes conceptuales (esquemas) de pantallas seleccionadas en la ERS sin demandar la implementación precisa siguiendo esos modelos.

Esto podría mejorar la comunicación sin motivar a los desarrolladores con restricciones innecesarias.

Debería ilustrar la intención subyacente, nada más.

129

Plantilla para la ERS (basada en el estándar IEEE 830)

No hay necesidad de inventar un nuevo documento de ERS.

Puede utilizar esta plantilla, basada en el estándar IEEE 830.

Un Ejemplo.

130

131

Temas

La Visión del Producto y el Alcance del Proyecto Clasificación de los Usuarios Levantamiento de Requisitos Entendiendo los Requisitos de Usuario Las Reglas del Negocio Documentando los Requisitos Modelos y Diagramas para diversos

Requisitos Requisitos No Funcionales Validación de Requisitos

Introducción

Lea esta Historia Con relación a su experiencia,

¿Cuáles son los Diagramas que utiliza para la especificación de requisitos?.

132

Introducción

De acuerdo a Alan Davis (1995) no existe una sola vista de los requisitos que provea un entendimiento completo.

Se necesita una combinación de representaciones textuales y visuales para dibujar la imagen completa del sistema.

133

Introducción

Las vistas incluyen: Listas y tablas de RF. Modelos gráficos de análisis Prototipos de IU Casos de uso Casos de prueba Árboles de decisión Tablas de decisión, etc.

134

Introducción

Los analistas podrían escribir los RF y dibujar algunos modelos.

Los diseñadores de IU construyen prototipos.

Los “testers” conducen la escritura de los casos de prueba.

135

Introducción

Comparando las diversas representaciones creadas a través de diversas personas, con diversos procesos de pensamiento revelará inconsistencias, ambigüedades, supuestos y omisiones difíciles de detectar a partir de una única vista.

136

De la Voz del Cliente a Modelos de Análisis

Escuchando cuidadosamente como presentan los clientes sus requisitos, el analista puede seleccionar palabras que se correspondan con elementos de modelado.

137

De la Voz del Cliente a Modelos de Análisis-Ejemplo

138

Tipo de Palabra Ejemplos Componentes de Modelos de Análisis

Sustantivo Personas, organizaciones, sistemas software, datos u objetos que existan

Terminadores o datos (DFD)Actores (CU)Entidades o sus atributos (DER)Clases o sus atributos (DC)

Verbo Acciones, cosas que el usuario puede hacer, eventos que pueden suceder

Procesos (DFD)CURelaciones (DER)Transiciones (DTE)Actividades (DA)

Diagrama de Flujo de Datos (DFD)

Identifica los procesos transformacionales del sistema, las colecciones (almacenes) de datos o materiales que el sistema manipula y los flujos de datos o materiales entre procesos, almacenes y el mundo exterior.

Se puede elaborar el Diagrama de Contexto en el nivel 0 del DFD dividiendo el sistema en sus procesos mayores.

139

Diagrama de Flujo de Datos (DFD)-Ejemplo

140

Diagrama Entidad-Relación

Muestra las relaciones entre los datos del sistema.

Si el Diagrama ER se utiliza desde la perspectiva del analista entonces mostrará grupos lógicos de información del dominio del problema.

141

Diagrama Entidad-Relación-Ejemplo

142

Máquinas de Estado que modelan IU: el Mapa de Diálogo

El comportamiento de una IU se puede modelar mediante una Máquina de Estado.

En un momento en el tiempo un solo elemento de diálogo (menú, workspace, caja de diálogo, prompt, etc.) está disponible para entrada del usuario.

El usuario navega a un cierto elemento de diálogo basado en acciones que realiza desde el mismo.

Esta Máquina de estados se le llama Mapa de Diálogo (Wasserman y Wiegers)

143


El Mapa de Diálogo representa la IU a un nivel de abstracción alto.

Muestra los elementos de diálogo en el sistema y los enlaces de navegación entre los mismos, sin mostrar detalles de diseño de pantallas.

El Mapa de Diálogo permite que puedas explorar conceptos de la IU basado en el entendimiento que se tiene de los requisitos (puede complementar los CU).

Usuarios y desarrolladores pueden estudiar el Mapa de Diálogo para consensar una visión común de cómo el usuario interactuaría con el sistema para realizar una cierta tarea.

144


Los usuarios pueden recorrer el Mapa de Diálogo para buscar transiciones innecesarias, incorrectas, perdidas y por tanto requisitos perdidos, incorrectos o innecesarios.

Importante: el Mapa de Diálogo conceptual que se formula como parte del análisis sirve como guía durante el diseñado detallado de la IU.

145

Del Mapa de Diálogo a la Máquina de Estados

Cada Elemento de Diálogo se corresponde con un estado de una Máquina de Estados.

Cada opción de Navegación se corresponde con una transición (flecha) entre estados.

El evento que dispara una navegación de IU se muestra sobre la flecha de transición.

146

Del Mapa de Diálogo a la Máquina de Estados

Eventos: Acción de usuario: presionar una tecla de

función, clic sobre un hyperlink o presionar un botón.

Valor de datos: entrada de usuario inválida que dispara un mensaje de error.

Condición de sistema: detectar que una impresora no tiene papel.

Alguna combinación de las anteriores: teclear una opción de menú y presionar la tecla Enter.

147

Ejemplo de Mapa de Diálogo

148

Elemento de diálogo

Acción

stm Solicitud de químico-IU DTE

Lista de Solicitudes Actuales

Captura químico de solicitud

Despliega Mensaje de Error

Lista de Vendedores para el químico

Lista de contenedores almacén

Confirmar que la solicitud se acepta

Histórico del Contenedor

Pide colocar una solicitud Cancela la solicitud

borrar químico de la l ista

solicitar otro químicocancelar laadición denuevo químico

quimico invalido

OK

solicitar químico desde almacen solicitar un químico diferente

solicitar un químico de un vendedor

solicitar un químico diferente

cancelar la adicion de un nuevo químico

seleccionar vendedor y agregarlo a la l ista

introducir solicitud para un número > 0 de químicos

solicitar químico de un vendedor

solicitar ver el Histórico del Contenedor Return

OK; salir de función de solicitud

seleccionar contenedor y agregarlo a la l ista

cancelar la adición de nuevos químicos

Diagramas de Clases

Un Diagrama de Clases en el cual las clases se corresponden a entidades del dominio o negocio y donde además se muestran las relaciones entre las clases.

149

Diagrama de Clases-Ejemplo

150

Tablas de Decisión y Árboles de Decisión

Son 2 técnicas alternativas para representar lo que el sistema debe hacer cuando entran en juego decisiones de lógica compleja.

La Tabla de Decisión lista los diferentes valores para todos los factores que influyen un cierto comportamiento e indica la acción esperada del sistema en respuesta a una combinación de factores.

151

Tabla de decisión-Ejemplo

152

Número de Requisito

Condición 1 2 3 4 5

Usuario autorizado

F V V V V

Químico disponible

- F V V V

Químico peligroso

- - F V V

Solicitante entrenado

- - - F V

Aceptar solicitud

X X

Rechazar solicitud

X X X

Árbol de decisión

Es una forma alternativa de representar gráficamente lógica compleja y acciones del sistema.

Selecciona sólo 1 representación: tabla de decisión o árbol de decisión

153

Árbol de decisión-Ejemplo

154

Recomendaciones finales …

Cada técnica de modelado vista tiene sus ventajas y limitaciones.

Algunas se sobreponen a otras (D. E-R, D. de clases, por ej.) por lo que no trates de crear todos los modelos para tu proyecto.

Toma en cuenta que los modelos de análisis se crean para ofrecer entendimiento y comunicación que vaya más allá de la especificación textual o de una única vista que un requisito pueda proveer.

Usa lo que realmente necesitas para explicar mejor tus requisitos.

155

156

Temas


Introducción

Lea la siguiente Historia. Discuta la relación que existe

entre el éxito de un proyecto software y sus Requisitos No Funcionales.

157

Introducción

El éxito de un sistema software dependen no sólo de que ofrezca la funcionalidad esperada.

Depende, también, de que logre las expectativas de que tan bien trabajará.

Es decir: ¿Qué tan fácil de utilizar será? ¿Qué tan rápido correrá? ¿Qué tan frecuente fallará? ¿Cómo manejará situaciones inesperadas?

158

Introducción

Los Atributos de Calidad distinguen a un producto que solamente hace lo que se supone debe hacer de otro que “deleita” a sus clientes.

Un producto software excelente refleja un óptimo balance de las características de calidad competentes.

159

Introducción

Si no exploras las expectativas de calidad durante el levantamiento de requisitos, serás afortunado si el producto los satisface.

Desde el punto de vista técnico, los Atributos de Calidad conducen las decisiones arquitectónicas y de diseño (dividir las funciones del sistema en varias computadoras para alcanzar objetivos de desempeño o integridad)

160

Introducción

Generalmente los clientes no presentan sus expectativas de calidad explícitamente, sólo a través de su información podemos encontrar pistas al respecto.

La calidad, en sus muchas dimensiones, debe definirse tanto por clientes como por aquellos que construirán, probarán y mantendrán el software.

161

Atributos de Calidad

Existen varias clasificaciones para los Atributos de Calidad.

Si los desarrolladores conocen cuales son más cruciales para el éxito de su proyecto, podrán seleccionar el mejor enfoque para la arquitectura, diseño y programación que logre alcanzar los objetivos de calidad.

Se muestra una posible clasificación.

162

Clasificación-Atributos de Calidad

163

Importantes para los Usuarios

Importantes para los Desarrolladores

Disponibilidad Capacidad de Mantenimiento (Maintainability)

Eficiencia Portabilidad

Flexibilidad Reusabilidad

Integridad Capacidad de Pruebas (Testability)

Interoperabilidad

Confiabilidad

Robustez

Usabilidad

El Mundo Ideal …

En un Mundo Ideal todo sistema debería exhibir el máximo valor posible para todos sus atributos: estar disponible todo el tiempo, nunca fallar, ofrecer resultados instantáneos y correctos y ser intuitivo de utilizar.

Como esto no siempre es posible, tu debes aprender cuales atributos son los más importantes para el éxito de tu proyecto.

Después definir los objetivos del usuario y desarrollador en términos de los atributos esenciales de tal forma que los diseñadores tomen las decisiones apropiadas.

164

Definiendo los Atributos de Calidad

Se deben definir preguntas apropiadas para obtener del usuario los Atributos de Calidad del Sistema.

El analista debe trabajar con los usuarios para crear requisitos específicos, medibles y verificables.

Considera, además, preguntar a los usuarios lo que sería un desempeño, usabilidad, integridad o confiabilidad inaceptable (requisitos inversos).

165

Atributos importantes para los usuarios-Disponibilidad

La medida planeada de tiempo en la que el sistema estará disponible para su uso completamente operacional.

Disponibilidad= Tiempo Medio entre Fallas del Sistema/Tiempo promedio de reparación entre fallas

Pregunta al usuario que porcentaje real de tiempo requieren disponibilidad y si hay momento para los cuales es imperativo para lograr objetivos del negocio o seguridad.

166

Atributos importantes para los usuarios-Disponibilidad

Ejemplo: DI-1 El sistema debería estar

disponible al menos 99.5% en miércoles entre 6:00 am y media noche, y al menos 99.95% en miércoles entre 4:00 pm y 6:00 pm hora local.

Ten cuidado con especificar 100% en los atributos de calidad porqué será imposible y costoso de alcanzar.

167

Atributos importantes para los usuarios-Eficiencia

La medida de que tan bien el sistema utiliza la capacidad del CPU, espacio en disco, memoria o ancho de banda.

La Eficiencia está relacionada con el desempeño: si el sistema consume muchos de los recursos disponibles, los usuarios encontrarán baja en el desempeño.

Considera configuraciones mínimas de hardware cuando defines objetivos de eficiencia, capacidad y desempeño.

168

Atributos importantes para los usuarios-Eficiencia

Ejemplo: EF-1: Al menos 25% de la capacidad

del CPU y RAM disponible a la aplicación deberían estar sin usar en las condiciones planeadas de carga pico.

169

Atributos importantes para los usuarios-Flexibilidad

Mide que tan fácil es el sistema para agregarle capacidades.

Se le conoce también como: extensibilidad, aumentabilidad, expandibilidad.

Si los desarrolladores anticipan muchas extensiones, deberían seleccionar enfoques de diseño que maximicen la flexibilidad del software.

170

Atributos importantes para los usuarios-Flexibilidad

Ejemplo: FL-1: Un programador con al menos 6

meses de experiencia soportando este producto debería ser capaz integrarle una nueva capacidad de impresión al producto, incluyendo modificaciones al código y pruebas, en no más de 1 hr. de trabajo.

171

Atributos importantes para los usuarios-Integridad

El cual abarca seguridad, tiene que ver con el bloqueo de acceso no autorizado a las funciones del sistema, prevenir pérdida de información, asegurar que el software está protegido contra virus y proteger la privacidad y seguridad de los datos introducidos al sistema.

172


Establece los requisitos de integridad en término no ambiguos: verificación de identidad de usuario, niveles de privilegio de usuarios, restricciones de acceso o datos precisos que se deben proteger.

173


Ejemplo: IN-1: Sólo los usuarios que tengan

privilegios de Auditor estarán autorizados para ver el histórico de movimientos del cliente.

Muchos de los requisitos de Integridad son también Reglas de Negocio. Esto sugiere establecer trazabilidad entre los mismos.

174

Atributos importantes para los usuarios-Interoperabilidad

Qué tan fácil puede intercambiar datos o servicios el sistema con otros sistemas.

Para evaluar interoperabilidad, necesitas conocer con cuales otras aplicaciones se integrarán los datos y servicios de la aplicación actual.

Está relacionada con los requisitos de interfases externas.

175

Atributos importantes para los usuarios-Interoperabilidad

Ejemplo: IO-1. El Sistema deberá ser capaz de

importar cualquier estructura química del sistema ChemiDraw (versión 2.3 o anterior) y Chem-Struct (versión 5 o anterior).

176

Atributos importantes para los usuarios-Confiabilidad

La probabilidad de que el software se ejecute sin fallas por un periodo específico de tiempo.

La Robustez es también considerado un aspecto de confiabilidad.

Medida: porcentaje de las operaciones que se completan correctamente y tiempo promedio en el que el sistema corre antes de fallar.

177

Atributos importantes para los usuarios-Confiabilidad

Ejemplo: CO-1. No más de 5 experimentos de

1000 se deberían perder por fallas en el software.

178

Atributos importantes para los usuarios-Robustez

O Tolerancia a Fallas: grado al cual un sistema continua funcionando apropiadamente cuando se enfrenta a entradas inválidas, defectos en componentes software y hardware o condiciones no esperadas de operación.

Pregunte al usuario sobre condiciones de error que el sistema podría encontrar y la forma en la que debería reaccionar.

179

Atributos importantes para los usuarios-Robustez

Ejemplo: RO-1. Si el editor falla antes de que el

usuario guarde el archivo, el editor debería ser capaz de recuperar todos los cambios hechos en el archivo que está siendo editado, hasta antes de 1 minuto antes de la falla. Esto estará disponible la próxima vez que el usuario inicie el programa.

180

Atributos importantes para los usuarios-Usabilidad

Incluye los factores que hace que los usuarios perciban al sistema amigable con el usuario.

También se le conoce como facilidad de uso, ingeniería humano-computadora.

Discusiones sobre usabilidad pueden incluir preguntas tipo: ¿Qué tan importante es que seas capaz de solicitar químicos de forma rápida y simple?¿Que tanto tiempo debería tomar completar una solicitud de un químico?

181

Atributos importantes para los usuarios-Usabilidad

Ejemplos: US-1. Un usuario entrenado debería ser capaz de

introducir una solicitud completa en un promedio de cuatro a máximo seis minutos.

US-2. Todas las funciones del menú Archivo deberán contar con teclas “shortcut” (Ctrl-X). Los comandos del Menú deberán ser semejantes a Microsoft Word.

US-3. Un usuario que nunca hubiera utilizado el sistema deberá ser capaz de hacer una solicitud con no más de 30 minutos de orientación.

182

Atributos importantes para los Desarrolladores-Mantenibilidad

Indica que tan fácil es corregir un defecto o modificar el software.

Depende de que tan fácil es de entender, cambiar y probar el software. Está relacionado con la flexibilidad y capacidad de prueba.

Se mide en términos del tiempo promedio para arreglar un problema y el porcentaje de reparaciones correctas.

183

Atributos importantes para los Desarrolladores-Mantenibilidad

Ejemplo: MA-1. Un programador de

mantenimiento deberá ser capaz de modificar los reportes existentes con 20 horas de trabajo o menos de esfuerzo de desarrollo.

MA-2. Las llamadas a funciones no deberán anidarse en más de 2 niveles de profundidad.

184

Atributos importantes para los Desarrolladores-Portabilidad

El esfuerzo requerido para migrar una pieza de software de un ambiente operativo a otro.

Algunos incluyen también la habilidad de internacionalizar y localizar un producto.

Los desarrolladores seleccionar aproximaciones de diseño y codificación que facilitarán la portabilidad del producto apropiadamente.

185

Atributos importantes para los Desarrolladores- Reusabilidad

El esfuerzo relativo para convertir un componente software y utilizarlo en otra aplicación.

Desarrollar un componente reutilizable tiene un costo mayor que uno que sólo se utilizará en 1 sola aplicación.

Un software reutilizable debe ser: Modular Bien documentado Independiente de aplicación específica y ambiente

operativo Genérico en capacidad.

186

Atributos importantes para los Desarrolladores- Reusabilidad

Ejemplo: RU-1: Las funciones de entrada se

diseñarán para ser reutilizables a nivel de código objeto en otras aplicaciones que utilizan representaciones internacionales de estructuras químicas.

187

Atributos importantes para los Desarrolladores- “Testability”

Conocida también como verificabilidad. Se refiere a la facilidad con la cual los componentes software o el producto integrado se pueden probar para la búsqueda de defectos.

El diseño para verificabilidad es crítico si: El producto tiene algoritmos y lógica compleja. Contiene interrelaciones complejas de

funcionalidad. Será modificado frecuentemente (y tendrán que

requerirse múltiples pruebas de regresión).

188

Atributos importantes para los Desarrolladores- “Testability”

Ejemplo: TE-1: La complejidad ciclomática

(McCabe 1982) máxima de un módulo no deberá exceder a 20.

Complejidad ciclomática: medida del número de ramificaciones lógicas en el código fuente: entre más ramificaciones y ciclos tenga tenderá a ser más difícil de probar, entender y mantener.

189

Atributos importantes para los Desarrolladores- Desempeño

Que tan bien o que tan rápido debe desempeñar funciones específicas el sistema.

Incluye: velocidad, througput (transacciones por segundo), capacidad (carga concurrente) y tiempo (alta demanda en tiempo real).

Los requisitos de desempeño restringen seriamente las estrategias de diseño, por lo que es importante establecer claramente sus objetivos.

190

Atributos importantes para los Desarrolladores- Desempeño

Ejemplo: DE-1. El intérprete debe realizar el

análisis sintáctico a velocidad de 500 estatutos por minuto.

DE-2. Cada página Web se descargará en 15 segs O menos sobre una conexión por modem de 50 Kbps

DE-3. La autorización de un retiro en el cajero automático no deberá tomar más de 10 seg.

191

Definiendo RNF usando Planguage

Algunos de los RNF se han definido de forma incompleta o no precisa.

No se puede evaluar un producto si no se definen los RNF de forma precisa.

Para abordar el problema de la ambigüedad e incompletitud de RNF Tom Gilb ha desarrollado Planguage.

192


Ejemplo - Definir el RNF en Planguage:“95% de las consultas a la base de datos del

catálogo deben completarse dentro de 3 segs. con un usuario que utiliza una PC Intel Pentium 4 de 1.1 Ghz corriendo Windows XP con al menos 60% de los recursos del sistema libres”

193


TAG Desempeño. ConsultaTiempoDeRespuesta (Etiqueta)

AMBITION Tiempo de respuesta rápido para consultas de base de datos sobre la plataforma del usuario (propósito del RNF)

ESCALA Segundos de tiempo entre presionar la tecla Enter (o clic Ok) para introducir la consulta y empezar el despliegue de resultados (unidad de medida)

194


MÉTRICA Pruebas Stopwatch realizadas sobre 250 consultas de prueba que representan un perfil de uso operacional (forma precisa de hacer las mediciones)

DEBE No más de 10 segs. Para el 98% de las consultas (nivel mínimo aceptable)

PLAN No más de 3 segs. por cada categoría de consulta, 8 seg. Para todas las consultas (objetivo nominal)

195


DESEO No más de 2 segundos para todas las consultas. (resultado ideal)

DEFINICIÓN de plataforma base Procesador Intel Pentium 1.1 Ghz, 128 Mb RAM, Windows XP, corriendo QueryGen 3.3 con al menos 60% de recursos libres. Ninguna otra aplicación corriendo.

Más detalles: http://www.gilb.com

196

Compensación de atributos (Trade-off)

Ciertas combinaciones de atributos presentan compensaciones mutuas.

Usuarios y desarrolladores deben decidir cuales atributos son más importantes que otros y respetar estas decisiones consistentemente al tomar decisiones.

197

Tabla de Compensación de atributos (Trade-off)

La siguiente tabla muestra las compensación entre atributos. Utiliza los siguientes convencionalismos para su interpretación: Un sigo “+/-” en el renglón indica que

incrementar el atributo del renglón tiene un efecto positivo/negativo en el atributo de la columna.

Una celda en blanco indica poco/ningún efecto en el atributo de la columna.

198

Tabla de Compensación de atributos (Trade-off)

199

Implementando los RNF

Aunque los Atributos de Calidad son RNF, ellos pueden conducir a RF, líneas guía de diseño u otra información técnica que producirán los atributos de calidad deseados.

200

De los Atributos de Calidad (RNF) a Especificaciones Técnicas

201

Tipo de Atributo de Calidad Probable Categoría de Información Técnica

Integridad, Interoperabilidad, Robustez, Usabilidad, Seguridad

Requisitos Funcionales

Disponibilidad, Flexibilidad, Eficiencia, Desempeño, Confiabilidad

Arquitectura del Sistema

Interoperabilidad, Usabilidad Restricciones de Diseño

Flexibilidad, mantenibilidad, portabilidad, confiabilidad, reusabilidad, verificabilidad, usabilidad

Línea guía de diseño

Portabilidad Restricción de Implementación

202

Temas


Introducción

Lea la siguiente Historia. ¿Ha tenido alguna experiencia de

“ambigüedad” en la especificación de sus requisitos? Comente

203

Introducción

Si un desarrollador software tiene que implementar un requisito ambiguo o incompleto tendrá que hacer sus propias interpretaciones, las cuales no siempre son correctas.

Se requiere un esfuerzo substancial para arreglar errores de requisitos después de que se ha completado el trabajo basado en estos requisitos.

204

Introducción

Estudios han demostrado que puede costar aproximadamente 100 veces más corregir un defecto en un requisito que corregir un error encontrado durante el desarrollo de requisitos.

Cualquier medida que se pueda tomar para detectar errores en las especificaciones de requisitos ahorrará tiempo y dinero substancial.

205

Las Pruebas y el Desarrollo de Requisitos

Si se inicia la planeación de las pruebas y el desarrollo de Casos de Prueba pronto, detectarás muchos errores antes de que se introduzcan.

Esto previene daños futuros y reduce los tiempos de mantenimiento y costos.

206

Modelo V de Desarrollo de Software con diseño/planeación de Pruebas

207

Modelo V de Desarrollo de Software con diseño/planeación de Pruebas

Planea las actividades de pruebas e inicia el desarrollo de Casos de Prueba preliminar durante la fase correspondiente de desarrollo.

Aunque aún no se ejecuten las pruebas (no hay código todavía) los Casos de Prueba conceptuales revelarán errores, ambigüedades y omisiones en la ERS y en los modelos de análisis antes de que el equipo escriba el software.

208

Validación de Requisitos

La VR es el cuarto componente (junto con elicitación, análisis y especificación del desarrollo de requisitos).

209


La VR intenta asegurar que: La ERS describe correctamente las

capacidades y características del sistema que satisfacerán las necesidades de los stakeholders.

Los requisitos software se derivaron correctamente de los requisitos del sistema, reglas del negocio u otras fuentes.

Los requisitos son completos y de alta calidad.

210


La VR intenta asegurar que: Todas las representaciones de requisitos son

consistentes unas con otras. Los requisitos proveen una base adecuada para

proceder con el diseño y construcción. Sólo se pueden validar requisitos que

han sido documentados no los que están en la mente de alguien.

La VR debe ser un proceso iterativo, no un paso final antes de fijar los requisitos en la línea base.

211

Validación & Verificación

Algunos llaman a esta etapa Verificación. La Verificación determina si un producto satisface los requisitos establecidos por el (do the thing right).

Validación evalúa si el producto satisface las necesidades del cliente (do the right thing).

212

Revisión Formal de Requisitos

Una Revisión por Parejas es aquella en la que alguien externo al autor del producto examina problemas en el mismo.

Ésta es una técnica importante para identificar requisitos ambiguos o no verificables, que no fueron definidos claramente para diseño y otros problemas.

La RxP es un proceso formal, bien definido (en contraste con “Revisiones Informales”).

213

Revisión Formal de Requisitos

El mejor tipo de Revisión Formal es llamada Inspección.

La Inspección de documentos de Requisitos es la técnica de mayor calidad software.

Si se desea maximizar la calidad del software, el equipo inspeccionará cada documento de requisitos que crea.

Inicia la inspección cuando tengas un 10% de la ERS: es la mejor técnica para prevenir –no sólo encontrar- defectos.

214

El proceso de Inspección

Michael Fagan desarrolló el proceso de inspección en IBM a la mitad de los 70s y otros lo han extendido o modificado con sus métodos.

Cualquier artefacto puede ser inspeccionado (requisitos, diseño, código fuente, pruebas, planes de proyectos, etc.)

215

El proceso de Inspección

La Inspección es un proceso multietapas bien definido.

Involucra un pequeño equipo de participantes entrenados que cuidadosamente inspeccionan un producto de trabajo buscando defectos y oportunidades de mejora.

216

Participantes en un proceso de Inspección

Deben representar 4 perspectivas:1. El autor del producto de trabajo y

quizá compañeros del autor. El analista provee esta perspectiva.

2. El autor de cualquier producto de trabajo o especificación predecesora para el producto inspeccionado. Un arquitecto de sistemas (o cliente) que asegure que la ERS detalla apropiadamente la especificación del sistema.

217


Deben representar 4 perspectivas:3. Gente que hará el trabajo basado en

el producto siendo inspeccionado. Desarrollador, tester, líder de proyecto y escritor de la documentación del usuario.

4. Gente responsable del trabajo del producto que interactuará con el producto inspeccionado. Buscarán problemas con los requisitos de interfases externas.

218


Limita el equipo a 6 o menos inspectores.

Esto significa que algunas perspectivas no serán representadas en cada inspección.

219

Roles de la inspección-Autor

Autor: es el analista que obtuvo los requisitos de usuario y escribió la especificación. Toma un papel pasivo en la inspección. No puede asumir ningún otro papel. Escucha los comentarios de otros inspectores, responde (no debate) a sus preguntas y piensa. Puede detectar errores que los otros inspectores no ven.

220

Roles de la inspección-Moderador

Moderador: o líder de inspección; planea la inspección con el autor, coordina actividades y facilita las reuniones de inspección. Distribuye los materiales a ser inspeccionados por los participantes, varios días antes de la reunión de inspección. Inicia la reunión a tiempo, motiva la participación y mantiene enfocada la reunión a encontrar defectos más que resolver problemas. Da seguimiento, junto con el autor, a la correcta corrección de defectos.

221

Roles de la inspección-Lector

Lector: parafrasea la ERS un requisito a la vez. Los otros participantes señalan defectos potenciales. Estableciendo los requisitos en sus propias palabras, el lector provee una interpretación que puede diferir de la de otros inspectores. Esto es una buena forma de revelar una ambigüedad, un posible defecto o un supuesto.

222

Roles de la inspección-Escritor

Escritor: usa formatos estándar para documentar lo que surja y los defectos encontrados durante la reunión de inspección. Debe enunciar en voz alta lo que escribió para confirmar exactitud. Los otros inspectores deben ayudar al escritor a capturar la esencia de lo que surge en una forma que claramente comunica al autor la localización y naturaleza de lo surgido.

223

Criterios de Inicio de la Inspección

Los prerrequisitos que se deben satisfacer antes de inspeccionar el documento de requisitos son: El documento está conforme la plantilla estándar. Se ha revisado la ortografía del documento. El autor ha revisado visualmente el documento por

errores de diseño. Están disponibles los documentos de referencia que

los inspectores requerirán para examinar el documento.

Los temas abiertos están señalados como TBD. El moderador no encontró más de 3 defectos en una

examen de 10 minutos de una muestra representativa del documento.

224

Etapas de Inspección

225

Etapas de la Inspección-Planeación (Planning)

El Autor y el Moderador planean juntos la inspección.

Determinan: Quien participará Que materiales recibirán los inspectores

antes de iniciar. Cuantas reuniones de inspección se

necesitarán para cubrir el material. La Tasa de Inspección (número de páginas

por hora).

226

Etapas de la Inspección-Planeación (Planning)-La Tasa de Inspección y el No. de Defectos encontrados

227

Etapas de la Inspección-Introducción (Overview meeting)

Durante la Introducción, el Autor describe los antecedentes del material que el equipo está inspeccionando, sus supuestos y los objetivos específicos de la inspección.

Si todos son familiares con el documento, se puede omitir esta etapa.

228

Etapas de la Inspección-Preparación (Preparation)

Cada inspector examina el producto para identificar posibles defectos, usando checklist de típicos defectos. Hasta 75% de los defectos encontrados se descubren en esta etapa. No omitas este paso.

Considera pedir a cada desarrollador que revisará la ERS calificar cada requisito en términos de que tan bien lo entienden (1=no se entiende; 5=claro, completo y no ambiguo)

229

Etapas de la Inspección-Reunión de Inspección (Inspection Meeting)

El Lector lee a los otros inspectores a través del DERS, describiendo 1 requisito a la vez en sus propias palabras.

Conforme los inspectores encuentran posibles defectos (u otros aspectos), el Escritor los captura en una forma que viene a ser la lista de acciones para el autor de los requisitos.

Las reuniones de inspección no deberían tomar más de 2 hrs. Si se necesita más tiempo, reprograma otra reunión.

230

Etapas de la Inspección-Reunión de Inspección (Inspection Meeting)

Al final de la reunión el equipo decide aceptar el DERS tal como está, aceptar con revisiones menores o indicar si se requiere mayor revisión (esto indica problemas con el proceso de desarrollo de requisitos).

Considera una retrospectiva para explorar como se pueden mejorar los procesos antes de la siguiente actividad de especificación.

231

Etapas de la Inspección- Retrabajo (Rework)

El Autor debe planear invertir algo de tiempo re-trabajando los requisitos que siguen a la reunión de inspección.

Es el momento de resolver ambigüedades, eliminar puntos no claros y establecer la base para el desarrollo exitoso del proyecto.

232

Etapas de la Inspección- Seguimiento (Follow-up)

Paso final de la inspección. El Moderador o un individuo designado trabaja con el Autor para asegurarse que todos los aspectos abiertos fueron resueltos y que los errores fueron corregidos apropiadamente.

Esta etapa brinda el cierre de la inspección y habilita al moderador para determinar si el criterio de terminación se ha satisfecho.

233

Criterios de Cierre de la Inspección

Las Postcondiciones que se deben satisfacer antes de que el moderador declare la inspección completa son: Todos los aspectos encontrados han sido

atendidos. Cualquier cambio hecho al documento y

productos de trabajo relacionados fueron hechos correctamente.

Se ha revisado la ortografía del documento. Todos los TBD se han resuelto. El documento se ha incluido en el Sistema de

Configuración del Sistema.

234

Checklists de defectos

Para ayudar a los inspectores a localizar típicos errores en los productos que inspeccionan es bueno desarrollar un checklist para cada tipo de documento de requisitos crea la organización.

235

Ejemplo Checklist de defectos-CU

¿El CU es un Proceso elemental de negocio? ¿Es claro el objetivo del CU? ¿Está escrito el CU a nivel esencial, libre de

detalles de diseño e implementación? ¿Están documentados todos los cursos

alternativos? ¿Hay secuencias de acción comunes que se

pueden factorizar en CU separados? ¿Las precondiciones y postcondiciones

enmarcan apropiadamente el CU?

236

Checklist para DERS

También se puede hacer un checklist para inspeccionar el DERS.

237

Probando los Requisitos-Casos de Prueba conceptuales

Se puede iniciar derivando los Casos de Prueba conceptuales muy temprano en el proceso de desarrollo.

Se pueden utilizar los Casos de Prueba para evaluar requisitos textuales, modelos de análisis y prototipos.

Los Casos de Prueba son independientes de implementación.

238

Probando los Requisitos-Casos de Prueba conceptuales

239

Definiendo el Criterio de Aceptación

No es suficiente la correcta implementación de los requisitos, se requiere también que la acepte el usuario final.

Los cliente deben definir el Criterio de Aceptación que determina si el sistema realmente satisface sus necesidades.

240


La pregunta clave a responder por el usuario es: ¿Cómo juzgaría si el sistema satisface sus necesidades?

Si el cliente no puede expresar como evaluaría la satisfacción del sistema de un requisito particular, tal requisito no se ha establecido de forma suficientemente clara.

241


No es suficiente escribir los requisitos. Se necesita asegurar que son los correctos y que son suficientemente buenos para servir de base al diseño, construcción, pruebas y gestión del proyecto.

242

Documents

02 desarrollo de requisitos