Administración de requerimientos
2
3
Definición de requerimientos Definición
Los requerimientos son una especificación de lo que debe ser
implementado. Son descripciones acerca de cómo debe comportarse el
sistema o bien acerca de una propiedad o atributo del sistema.
Pueden ser una restricción en el proceso de desarrollo del
sistema.
4
Papel crítico de los requerimientos Frederick Brooks describe en su
ensayo clásico de 1987 "No Silver Bullet: Essence and Accidents of
Software Engineering":
La parte más difícil de construir un sistema de software es decidir
con exactitud qué construir. Ninguna otra parte del trabajo
conceptual es tán difícil como establecer los requerimientos
detallados que incluyen las interfaces con la gente, con máquinas o
con otros sistemas de software. Ninguna otra parte tiene tanto
impacto negativo en el sistema resultante si no se hace
correctamente. Ninguna otra parte es más difícil de corregir
posteriormente.
5
Motivante La mayor consecuencia de los problemas a nivel de los
requerimientos es la necesidad de rehacer las cosas
6
Beneficios Un buen proceso de administración de requerimientos
permite tener
Menos defectos de requerimientos Menos re-trabajo Menos
características innecesarias Menor costo para las mejoras Mayor
velocidad de desarrollo Menos malentendidos Menos explosión
incontrolada de alcances Menor caos en el proyecto Mejores
estimaciones con respecto a pruebas del proyecto Mayor satisfacción
de los miembros del equipo y de los clientes
7
8
Niveles de requerimientos Un sistema de software tiene 3 niveles de
requerimientos
Requerimientos de negocio
Requerimientos de usuario
9
Requerimientos de negocio Qué son?
Este tipo de requerimientos representan objetivos de alto nivel de
la organización o cliente que solicita un sistema.
Están fuera de la frontera de un sistema específico.
Describen por qué la organización está implementando el sistema, es
decir los objetivos que la organización busca alcanzar.
Estos requerimientos típicamente se almacenan en el documento de
visión y alcance del proyecto.
10
Requerimientos de usuario Qué son?
Los requerimientos de usuario describen objetivos o tareas que los
usuarios deben poder realizar con el producto
Se representan mediante casos de uso o descripciones de
escenarios
Documento de casos de uso
Ej. “Hacer una reservación”
Requerimientos funcionales Qué son?
Especifican las funcionalidades de software que los desarrolladores
deben incluir en el producto para permitir a los usuarios el
cumplir con sus tareas, y por ende satisfacer los requerimientos de
negocio.
Documento: SRS
Son descritos usando el verbo “debe” “El sistema debe
hacer...”
12
Requerimientos no-funcionales Qué son?
Estos requerimientos incluyen objetivos de desempeño y atributos de
calidad. Los atributos de calidad aumentan la descripción funcional
al describir las características del producto en varias dimensiones
importantes para los usuarios o desarrolladores
Usabilidad Portabilidad Eficiencia Robustez
Adicionalmente describen interfaces externas entre el sistema y el
mundo exterior e imponen restricciones de diseño e
implementación.
13
Detalles de diseño e implementación (excepto restricciones)
Información de planeación o de pruebas del proyecto
Existen requerimientos de proyecto y no de producto
Requerimientos del entorno de desarrollo De tiempo y dinero De
realizar un tutorial de ayuda etc...
15
16
Desarrollo y admin. de reqs. Sub-componentes del dominio de
ingeniería de requerimientos
Ingeniería de requerimientos
Captura Análisis Especificación Validación
17
Desarrollo y admin. de reqs. Sub-componentes del dominio de
ingeniería de requerimientos
Ingeniería de requerimientos
Captura Análisis Especificación Validación
Las sub-disciplinas del desarrollo de requerimientos cubren todas
las actividades relacionadas con la obtención, evaluación y
documentación de requerimientos.
Administración de requerimientos Representa el establecimiento y
mantenimiento de un acuerdo con el cliente con respecto a los
requerimientos del proyecto de desarrollo. Las actividades de esta
disciplina incluyen
Definir base de requerimientos Revisar cambios en requerimientos
Incorporar cambios Seguir planes de desarrollo con respecto a reqs.
Trazar requerimientos
19
Desarrollo y admin. de reqs. Sub-componentes del dominio de
ingeniería de requerimientos
Ingeniería de requerimientos
Captura Análisis Especificación Validación
Obtener los requerimientos del sistema de software
Actividades Definir y refinar un proceso de desarrollo de
requerimientos Escribir un documento de visión y alcances
Identificar clases de usuarios y sus características, escoger un
'campeón de producto' y observar a los usuarios realizar sus
labores Realizar juntas de obtención de requerimientos
21
Análisis de requerimientos Propósito
Involucra el refinamiento de los requerimientos capturados para
asegurar que todos los participantes los comprenden y que se
identifican errores y omisiones. El objetivo es desarrollar
requerimientos de suficiente calidad que permitan estimar tiempos y
proceder con el diseño construcción y pruebas
Actividades Realización de un diagrama de contexto Creación de un
diccionario de datos Modelado de requerimientos Creación de
prototipos Priorización de requerimientos
22
Una vez analizados, los requerimientos deben ser documentados de
forma consistente, accesible y deben poder ser revisados.
Actividades Documentación de reglas de negocio Adopción de un
templete SRS (System Requirements Specification) Especificar
atributos de calidad (requerimientos no-funcionales)
23
La validación permite asegurar que los requerimientos documentados
son correctos, que demuestran las características de calidad
deseadas y que satisfacen las necesidades de los clientes
Actividades Inspección de documentos de requerimientos Pruebas de
requerimientos Definición de criterios de aceptación
24
El proceso de desarrollo de reqs. Las etapas del proceso no se
llevan a cabo de forma secuencial
Es un proceso iterativo
25
Un ejemplo de proceso Según Wiegers, este proceso funciona para una
gama amplia de proyectos
26
Definir requerimientos de negocio Identificar involucrados y clases
de usuarios Obtener requerimientos Analizar requerimientos Escribir
especificaciones de requerimientos Modelar requerimientos Validar
requerimientos Priorizar requerimientos Administrar
requerimientos
27
Actividades del desarrollo de requerimientos Establecimiento de una
visión y alcances del producto
28
29
Visión y alcance Visión
La visión del producto alinea a todos los involucrados en una
dirección común. Describe de qué se trata el producto y en qué se
puede convertir eventualmente. Relativamente estática
Alcance El alcance del proyecto define qué porción de la visión a
largo plazo del producto se va a cubrir en el proyecto actual. El
alcance traza la frontera entre lo que queda dentro y fuera, es
decir define las limitaciones del proyecto. Dinámica, cambia a cada
proyecto
30
Documento de visión y alcance Propósito
El documento de visión y alcance colecta los requerimientos de
negocio en un sólo documento que abre el camino al trabajo de
desarrollo subsecuente.
Creación del documento El análista trabaja en conjunto con el dueño
de negocio para obtener la información relevante
31
Casos de negocio y casos de uso Relación entre ambos
Los casos de negocio permiten determinar los casos de uso que
pertenecen o no a la aplicación
Permiten influenciar la prioridad de implementación de los casos de
uso
Por ej. Un caso de negocio asociado a una universidad dará
prioridad a casos de uso relacionados con la inscripción de
alumnos
También influencian a los requerimientos funcionales
32
Ejemplo de templete 1. Requerimientos de negocio
1.1 Antecedentes 1.2 Oportunidad de negocio 1.3 Objetivos de
negocio y criterios de éxito 1.4 Necesidades del cliente o del
mercado 1.5 Riesgos de negocio
2. Visión de la solución 2.1 Frase de visión 2.2 Características
principales 2.3 Suposiciones y dependencias
3. Alcance y limitaciones 3.1 Alcance de la primer versión liberada
3.2 Alcance de versiones subsecuentes 3.3 Limitaciones y
exclusiones
4. Contexto de negocio 4.1 Perfil de involucrados 4.2 Prioridades
del proyecto 4.3 Entorno operativo
33
1. Requerimientos de negocio Describen los beneficios primarios que
el nuevo sistema proveerá a sus patrocinadores, compradores y
usuarios
1.1 Antecedentes Motivación y contexto del nuevo producto Decisión
que llevó a construir este producto
1.2 Oportunidad de negocio Describe oportunidad de mercado o,
Problema o proceso que se mejora Ventajas del sistema
Posicionamiento en el mercado
34
1. Requerimientos de negocio 1.3 Objetivos de negocio y criterios
de éxito
Describe beneficios del producto en forma cuantitativa
Ej: el proceso se acelerará de 1 día a 1 hora
1.4 Necesidades de mercado o de cliente Necesidades Problemáticas
actualmente enfrentadas que serán resueltas por el sistema
1.5 Riesgos de negocio Riesgos asociados con el desarrollo o no-
desarrollo del producto
35
2. Visión de la solución 2.1 Frase de visión
Visión concisa que resume el propósito a largo plazo y la intención
del producto
Para [cliente] Que [necesidad u oportunidad] El [nombre del
producto] Es un [categoría de producto] Que [beneficio principal,
razón de compra o uso] A diferencia de [alternativa competitiva]
Nuestro producto [diferenciador primario, ventajas del nuevo
producto]
Para los profesores de la UAM que necesitan automatizar sus
mecanismos de calificaciónes, el sistema UAMISYS es un portal de
administración de alumnos que permite llevar un control
centralizado de las calificaciones, a diferencia de que hoy en día
esto se hace manualmente...
36
2.3 Suposiciones y dependencias Suposiciones de participantes
cuando se concibió el proyecto
37
3. Alcance y limitaciones El alcance del proyecto define el
concepto y rango de la solución propuesta
3.1 Alcance de versión inicial Resumen de características que serán
incluidas en la versión inicial
3.2 Alcance se versiones subsecuentes Descripción de
características que serán realizadas posteriormente
3.3 Limitaciones y exclusiones Describir características que
participantes puedan esperar pero que quedarán fuera
38
4. Contexto de negocio 4.1 Perfil de involucrados
Describe las diferentes categorías de clientes y otros involucrados
claves para el proyecto Describir para cada involucrado
Beneficio que recibirá del producto Actitud con respecto al
producto Características que le interesan Restricciones que
impone
4.2 Prioridades del proyecto Se pueden categorizar a través de 5
dimensiones
Alcance, calidad, tiempo, costo y recursos humanos
39
Describe el entorno en el cual el sistema será utilizado y describe
requerimientos importantes en cuanto a disponibilidad,
confiabilidad, desempeño, y otros requerimientos no-
funcionales.
40
Diagrama de contexto La descripción de alcance establece la
frontera y conexiones entre el sistema y lo demás en el universo.
El diagrama de contexto lo ilustra de forma gráfica.
Sistema: se representa como un circulo en el centro Terminadores:
representan clases de usuarios, organizaciones u otros sistemas
Flechas: representan flujo de datos u otros elementos físicos entre
sistema y terminadores
41
Ejemplo
42
43
44
Acercamiento con el cliente El éxito en el desarrollo depende de la
comunicación entre clientes y desarrolladores Para facilitar
comunicación
Identificar distintas clases de usuarios Identificar fuentes de
requerimientos Seleccionar y trabajar con individuos que
representen a cada clase de usuarios y otros grupos de involucrados
Acordar en quiénes son los tomadores de decisiones para el
proyecto
El involucramiento del cliente es la única manera de evitar un
desfasamiento de expectativas
45
Entrevistas y discusiones con usuarios potenciales Documentos que
describen productos actuales o competidores Especificaciones de
requerimientos existentes Reportes de problemas y solicitudes de
mejoras Encuestas de mercadeo y cuestionarios de usuarios
Observación de usuarios en su trabajo Listas de eventos y
respuestas
46
Clases de usuarios Los usuarios de un producto difieren entre otras
cosas en los aspectos siguientes:
La frecuencia con que usan el producto Su experiencia en el dominio
de aplicación y en el uso de sistemas de computo Las
características que usan Las tareas que realizar para soportar sus
procesos de negocio El nivel de acceso que tienen
Se pueden agrupar usuarios en distintas clases basándose en estas
diferencias
47
Clases de usuario Diferencias entre clases de usuarios
Cada clase de usuarios tiene sus propios requerimientos con
respecto a las tareas que los miembros de la clase pueden realizar.
Pueden tener requerimientos no-funcionales distintos, tales como la
usabilidad, que guiarán criterios de diseño de la interfaz de
usuario.
Importancia Algunas clases de usuario son más importantes que
otras. Las clases “principales” de usuarios reciben trato
preferencial cuando se toman decisiones de priorización o cuando se
resuelven conflictos de requerimientos provenientes de clases
distintas
48
Representante de usuario Se trata de una persona que representa una
clase de usuarios
Los representantes deben estar involucrados a lo largo del ciclo de
vida de desarrollo, no sólo al inicio.
Campeón de producto Un representante de usuario que sirve de
interfaz entre el analista y los miembros de una clase de usuario
Colectan requerimientos de otros miembros de las clases de usuarios
que representan. El desarrollo de requerimientos es una
responsabilidad compartida entre los analistas y los clientes
elegidos, aunque el análista escribe los documentos de
requerimientos.
49
50
Captura (Elicitation) La captura de requerimientos es el proceso de
identificar las necesidades y restricciones impuestas por los
distintos involucrados de un sistema de software.
La captura se enfoca en descubrir los requerimientos de
software
Durante la captura se pueden identificar requerimientos que caben
dentro de distintas categorías
51
Categorías de requerimientos Requerimientos de negocio
Cualquier cosa que describe un beneficio de negocio que los
clientes o la organización desea ganar con el producto
“Aumentar las ganancias de X%” Casos de uso
Descripciones de objetivos de usuario o tareas de negocio que los
usuarios necesitan realizar
“Necesito imprimir una etiqueta para el empaque” Reglas de
negocio
Cuando el cliente dice que sólo ciertas clases de usuarios pueden
realizar una actividad bajo ciertas condiciones, está describiendo
una regla de negocio
“Debe cumplir con <alguna ley o pólitica corporativa>
52
Describen los comportamientos observables que el sistema exhibe
bajo ciertas condiciones
“Si la presión excede 40.0 psi, la luz de advertencia de alta
presión debe prenderse”
Atributos de calidad Afirmaciones que indican qué tan bien realiza
el sistema algún comportamiento.
Buscar palabras que describan características deseables del
sistema: “fácil, rápido, intuitivo, amigable, robusto”
Requerimientos de interfaces externas Describen las conexiones
entre el sistema y el resto del universo
"Debe leer señales de <algún dispositivo>"
53
Categorías de requerimientos Restricciones
Las restricciones de diseño e implementación limitan de forma
legítima las opciones para los desarrolladores
“La base de datos debe ser MySql” Definiciones de datos
Algunas definiciones de datos se pueden obtener desde un
principio
“El código postal consta de cinco dígitos y el default es
00000”
54
55
Reglas de negocio Toda organización opera de acuerdo a un conjunto
extensivo de políticas corporativas, leyes y estándares
industriales.
Industrias tales como la bancaria, aeronáutica y médicas deben
cumplir con grandes cantidades de reglas. Todas estas reglas se
conocen de forma colectiva como “reglas de negocio”
Una regla de negocio es una frase que define o limita algún aspecto
del negocio.
La intención de estas reglas es consolidar la estructura del
negocio o controlar (o influenciar) el comportamiento del
negocio.
56
Reglas de negocio (2) La mayor parte de las reglas se originan
fuera del contexto de cualquier aplicación específica
Las reglas de negocio son una fuente importante de requerimientos
funcionales pues dictan capacidades que el sistema debe exhibir
para conformarse a las reglas
En una empresa grande, sólo un sub-conjunto de las reglas de
negocio se incorporarán en una aplicación particular
Construir una colección de reglas permite al análista identificar
requerimientos no identificados a través de discusiones con
usuarios. Es útil tener un “repositorio” de reglas de
negocio.
57
Tipos de reglas de negocio Existen varios tipos de reglas de
negocio
Hechos: son cosas verdaderas acerca del negocio
“Cada contenedor químico tiene un código de barras único”
Restricciones: limitan las acciones que el sistema o sus usuarios
pueden realizar
“El contrato de un cliente menor de edad debe ser firmado por uno
de sus padres”
Eventos: una regla que dispara una actividad ante condiciones
específicas
“5 días antes de la fecha de caducidad, los alimentos deben ser
retirados de los estantes”
58
Tipos de reglas de negocio Cálculos
Ciertas reglas de negocio definen cálculos que son realizados
usando algoritmos o fórmulas matemáticas específicas
El precio total incluye el iva más 5 % de comisión
59
La documentación no es específica a un proyecto
Las reglas pueden ser estáticas (no tienden a cambiar) o
dinámicas
60
Reglas de negocio y requerimientos
Las reglas de negocio y los requerimientos funcionales son
parecidos, sin embargo las reglas de negocio provienen de fuera de
la frontera del sistema específico
Un analista debe decidir qué reglas de negocio pertenecen a la
aplicación y cuales deben ser obedecidas
En el documento de especificación de requerimientos no se deben
duplicar las reglas de negocio
Hacer referencia al catálogo
63
Casos de uso Qué son?
Un caso de uso describe una secuencia de interacciones entre el
sistema y un actor externo
Un actor es una persona, otro sistema de software o un dispositivo
de hardware que interactúa con el sistema para alcanzar un objetivo
útil Los actores son roles que los miembros de una o más clases de
usuarios pueden realizar en el sistema
Los casos de uso transladan la perspectiva del desarrollo de
requerimientos hacia la discusión de lo que los usuarios deben
lograr, en contraste a otras técnicas de captura que preguntan al
usuario qué quiere hacer
El objetivo del enfoque de casos de uso es describir todas las
tareas que los usuarios necesitan lograr con el sistema
64
Casos de uso Los participantes deben asegurarse que cada caso de
uso yace dentro de los alcances definidos del proyecto antes de
aceptarlo en la lista de requerimientos de base.
En teoría, el conjunto resultante de casos de uso cubrirá toda la
funcionalidad del sistema. En la práctica no se logra esto
completamente (en general), pero esta técnica permite acercarse
bastante
Los diagramas de casos de uso proveen una visión de alto nivel de
los requerimientos de usuario
65
System Gestor
Red
66
Use case diagram Diagrama de casos de uso similar a diagrama de
contexto
Casos de uso y escenarios de uso Un caso de uso representa una
actividad independiente y completa que un usuario puede realizar
para obtener alguna salida de valor Un escenario es una instancia
específica de un caso de uso
Un caso de uso es entonces una colección de casos de uso
relacionado: en general un caso de uso principal y sus
alternativas
67
Relaciones includes, extends y herencia
Relación includes Cuando varios casos de uso comparten conjuntos de
pasos, estos se pueden separar en un caso de uso a parte que es
incluido por los distintos casos de uso
Relación extends Ocurre cuando un caso de uso hace uso de otro
únicamente en ciertos escenarios
Relación de herencia Cuando un caso de uso tiene una variación
ligera en la secuencia de pasos de otro
68
Excepciones Condiciones que impiden que una tarea culmine de forma
exitosa
Frecuentemente las excepciones son vistas como cursos alternativos,
pero es mejor separarlas. Todos los cursos alternativos pueden no
ser implementados pero la implementación del manejo de excepciones
es imperativo.
69
Casos de uso esenciales Qué representan
Una descripción de una tarea o interacción simplificada,
generalizada, abstracta, independiente de tecnología y de
implementación que contiene el propósito o las intenciones que
sostienen una interacción Los casos de uso concretos discuten
acciones específicas que el usuario realiza para interactuar con el
sistema
Especifico: el usuario introduce el ID del producto químico
General: el usuario especifica el producto químico
La independencia de implementación permite hacer que los casos de
uso generales sean más reutilizables que los específicos
70
Templete
71
Casos de uso y reqs. funcionales En general los casos de uso
descritos de forma general no son adecuados para que los
desarrolladores puedan implementar el sistema.
Los desarrolladores requieren de descripciones de requerimientos
funcionales específicos que contienen información detallada.
72
A evitar... Demasiados casos de uso Casos de uso altamente
complejos Incluir diseño de IU en los casos de uso Incluir
definiciones de datos en los casos de uso Hacer casos de uso que
los usuarios no asocien con los procesos que realizan Casos de uso
que describen procesos inexistentes (aún no implementados) y que no
son familiares a los usuarios Uso excesivo de relaciones includes y
extends
73
74
Especificación de reqs. de Software (SRS)
El documento SRS especifica de forma precisa las funciones y
capacidades que un sistema de software debe proveer y las
limitaciones que debe respetar El SRS es la base para todo el
desarrollo subsecuente que incluye planeación y diseño,
codificación, así como la realización de pruebas y
documentación
El SRS no debe contener detalles de diseño, construcción, pruebas o
administración
76
Usuarios del SRS Los clientes, el departamento de mercadotecnia y
la gente de ventas deben saber qué producto va a ser entregado Con
él, los administradores de proyecto pueden basar sus estimaciones
de tiempo, esfuerzos y recursos El SRS le dice al equipo de
desarrollo qué se va a construir Los probadores usan el SRS para
desarrollar planes, casos y procedimientos de pruebas La
documentación y manuales de ayuda se basan en el SRS (y el diseño
de la IU) Los materiales de entrenamiento se basan en el SRS y la
documentación de usuario Con él, los abogados se pueden asegurar
que el software cumple con las leyes y regulaciones
77
SRS de base No es necesario escribir el SRS para el producto entero
antes de iniciar el desarrollo, pero es necesario capturar los
requerimientos para cada incremento antes de constuirlo
Sin embargo, cada proyecto debe tener un acuerdo de base para un
conjunto de requerimientos antes de iniciar su implementación. El
SRS de base es aquél que ha pasado de ser un documento en
desarrollo a un que ha sido revisado y aprobado
78
Identificación de los reqs. Para satisfacer los criterios de
calidad de trazabilidad y modificabilidad, cada requerimiento
funcional debe ser identificado de forma única y persistente.
Esto permite hacer referencia a requerimientos específicos en
peticiones de cambio, historicos de modificaciónes, referencias
cruzadas, etc...
Existen varios enfoques Número de secuencia único (UR-9 o SRS-43)
Numeración jerárquica
3.2, 3.2.1, 3.2.2 Marcas jerárquicas textuales
Impresión.confirmarNumeroCopias
79
Identificación de reqs (2) Sea cual sea el enfoque es importante
ser capaces de encontrar un requerimiento de forma efectiva
Requerimientos incompletos Algunas veces no se tiene una
información sobre un requerimiento específico
Usar la notación TBD (To be determined) para marcar estos puntos
Antes de implementar, se deben resolver todos los TBDs
80
Templete SRS Toda organización debe adoptar uno o más templetes SRS
para sus proyectos
Ejemplo está adaptado del estándar IEEE 830
81
1. Introducción La introducción presenta una vista general que
permite entender la organización del SRS
1.1 Propósito Identificar el producto o aplicación cuyos
requerimientos se especifican en el documento
1.2 Convenciones del documento Describir las convenciones
tipográficas
1.3 Audiencia y sugerencias de lectura A quién está dirigido el
SRS
1.4 Alcance del proyecto Descripción corta del software
especificado y su propósito
Eventualmente referenciar al documento de visión y alcance en vez
de duplicar información
1.5 Referencias
2. Descripción global Propósito
Esta sección presenta una visión de alto nivel del producto y el
entorno en que se usará, los usuarios del producto, limitaciones,
suposiciones, limitaciones y dependencias
2.1 Perspectiva del producto Describe el contexto del producto y su
origen
Es el próximo miembro de una familia de productos, un remplazo de
un sistema existente, etc...
2.2 Características del producto Lista de las principales
caracteristicas que el producto contiene y las funciones
principales que realiza
Resumen de alto nivel
2. Descripción global 2.3 Clases de usuarios y
características
Identificación de las clases de usuario que usarán el producto y
descripción de sus características
Identificar clases de usuario primarias 2.4 Entorno operativo
Descripción del entorno en el cual opera el software incluyendo
plataforma de software, sistema operativo y versiones.
2.5 Limitaciones de diseño e implementación Descripción de los
factores que restringirán las opciones disponibles para los
desarrolladores y las motivantes para estas
84
2. Descripción global 2.6 Documentación de usuarios
Lista de los componentes de documentación de usuario que serán
entregados junto con el software
2.7 Suposiciones y dependencias Una suposición es un hecho que se
piensa verdadero a falta de pruebas o conocimiento definitivo
Dependencias con respecto a factores externos y fuera del
control
Por ejemplo la fecha de liberación de la próxima versión del
sistema operativo en que se ejecutará la aplicación
85
3. Características del sistema 3.x Característica X
Describirla en pocas palabras "3.1 Corrección ortográfica"
3.x.1 Descripción y prioridad Descripción breve de la
caracteristica y si est de prioridad alta, media o baja.
3.x.2 Secuencias de estímulo / respuesta Lista de estímulos de
entrada (acciones de usuario, señales de dispositivos externos) y
las respuestas del sistema
3.x.3 Requerimientos funcionales Lista de los requerimientos
funcionales detallados
Identificados de forma única
4. Reqs. De interfaces externas
Esta sección provee información que permite asegurar que el sistema
comunique apropiadamente con componentes externos 4.1 Interfaces de
usuario
Describir caracteristícas lógicas de cada interfaz de usuario 4.2
Interfaces de Hardware
Describe las características de cada interfaz entre los componentes
de software y hardware del sistema.
4.3 Interfaces de Software Describe conexiones entre el producto y
otros componentes de software
4.4 Interfaces de comunicación Describe requerimientos de funciones
de comunicación del producto (red, mail, etc...)
87
5.1 Requerimientos de Desempeño Describir requerimientos de
desempeño específicos. Explicar su razón de ser.
Cuantificar lo más posible Ej: "95 percent of catalog database
queries shall be completed within 3 seconds on a single-user
1.1-GHz Intel Pentium 4 PC running Microsoft Windows XP with at
least 60 percent of the system resources free."
5.2 Requerimientos de seguridad 5.4 Atributos de calidad de
software
88
89
La priorización permite al administrador de proyecto el poder
resolver conflictos, planear entregas y hacer los compromisos
(trade-offs) necesarios.
90
Decisión del cliente Es complicado que un cliente decida cuáles
requerimientos son de máxima prioridad
Contribuir a la priorización es una de las responsabilidades de los
clientes
Los clientes tienden a poner 85% de los requerimientos como de alta
prioridad, 10% como mediana y 5% como baja.
Esto no es de mucha ayuda!
91
Preguntas Preguntas para facilitar priorización
¿ Existe alguna otra manera de satisfacer la necesidad cubierta por
este requerimiento ?
¿ Cuál sería la consecuencia de omitir o deferir este requerimiento
?
¿ Cuál sería el impacto en los objetivos de negocio del proyecto si
este requerimiento no fuese implementado de forma inmediata ?
¿ Por qué haría infeliz a un usuario infeliz el deferir este
requerimiento para una versión futura ?
92
Escala de priorización Escala más común
Baja, mediana y alta prioridad Escala subjetiva e imprecisa Se debe
llegar a un acuerdo que defina qué significa cada nivel
Importancia y urgencia Otra manera de priorizar considera dos
dimensiones distintas: importancia y urgencia
Importante: el usuario necesita la característica Urgente: la
necesita para la próxima versión
Cada requerimiento puede ser considerado ya sea importante o no
importante así como urgente o no urgente
93
Importancia y urgencia La combinación de importancia y urgencia
resulta en cuatro posibilidades distintas
Alta prioridad: Requerimiento importante y urgente Prioridad media:
Requerimiento importante pero no urgente
Puede ser implementado en la versión siguiente Baja prioridad:
Requerimiento no importante ni urgente Superfluos: Requerimiento de
alta prioridad pero sin importancia
No se debe perder tiempo con estos ya que no le agregan valor al
producto.
94
Granularidad de la prioridad La priorización se puede aplicar a
diferentes niveles de granularidad
Característica Puede ser útil hacer una priorización a nivel de
características de forma inicial
Caso de uso Algunos escenarios pueden tener mayor prioridad que
otros
Requerimiento funcional Un requerimiento funcional tiene la misma
prioridad que sus sub-componentes Cada sub-componente tiene
prioridad específica
En cualquier caso hay que especificarlo
95
96
Atributos de calidad De forma natural, los usuarios se enfocan en
la especificación de los requerimientos funcionales o de
comportamiento
Sin embargo, tienen también expectativas acerca de qué tan bien va
a funcionar el producto
Qué tan fácil es de usar, que tan rápido se ejecuta, que tan
frecuentemente falla, cómo supera las fallas
Los atributos de calidad son parte de los requerimientos
no-funcionales
La cobertura de requerimientos no-funcionales puede ser más
importante que la de los requerimientos funcionales con respecto a
la percepción que tiene el cliente del éxito o fracaso del
producto
97
Tipos de atributos Existen docenas de tipos de atributos de
calidad
La mayor parte de los proyectos solamente necesitan considerar un
sub-conjunto de ellos
2 categorías Importantes para los usuarios
Disponibilidad, eficiencia, flexibilidad, integridad,
interoperabilidad, confiabilidad, robustez, usabilidad
Importantes para los desarrolladores Mantenibilidad, portabilidad,
reusabilidad, verificabilidad
Alcance Algunos atributos de calidad pueden aplicarse al sistema
entero, mientras que otros pueden aplicarse a un requerimiento
funcional específico
98
Importantes para usuarios Disponibilidad
Es una medida del tiempo durante el cual se planea que el sistema
esté disponible para ser usado y completamente operacional
Tiempo promedio entre fallas (ej 99% disponible 365 días al
año)
Eficiencia Mide qué tan bien utiliza recursos el sistema
(procesador, espacio en disco, memoria, etc...)
Debe usar un máximo de 50 % del procesador durante un momento
pico
Flexibilidad Mide que tan fácil es agregar nuevas capacidades al
producto
Interoperabilidad Indica que tan fácilmente puede el sistema
intercambiar datos con otros sistemas
99
Importantes para usuarios Integridad
Está asociada al hecho de bloquear accesos no autorizados a
funciones del sistema, prevención de perdidas de información y
protección de la privacidad y de los datos introducidos.
Confiabilidad Probabilidad de que el sistema se ejecute sin fallas
durante un periodo específico de tiempo
Robustez (tolerancia a fallas) Grado en que un sistema continua
funcionando cuando se enfrenta a entradas inválidas, defectos en
hardware o condiciones operativas inesperadas.
Usabilidad Mide el esfuerzo requerido para preparar entradas,
operar e interpretar salidas del producto
100
Importantes para desarrolladores Mantenibilidad
Indica qué tan fácil es corregir un defecto o modificar el
software
Portabilidad El esfuerzo requerido para migrar el software de un
entorno operativo a otro Localización
Reusabilidad Indica el esfuerzo relativo involucrado en convertir
un componente de software para poderlo usar en otras
aplicaciones
Verificabilidad Se refiere a la facilidad con la cual los
componentes de software o el producto en su conjunto puede ser
probado contra defectos
101
Requerimientos de desempeño Qué definen ?
Definen qué tan bien o qué tan rápido el sistema debe realizar
ciertas funciones específicas. Estos requerimientos engloban
Velocidad (por ej. tiempo de respuesta de BD) Ancho de banda
(transacciones por segundo) Capacidad (usuarios concurrentes)
Temporización (requerimientos de tiempo real)
102
Obtención de info. de atributos Qué es inaceptable ?
Una forma de obtener atributos de calidad consiste en preguntar a
los usuarios qué cosas serian consideradas como inaceptables a
nivel de desempeño, usabilidad, disponibilidad, etc...
Al definir características inaceptables (requerimiento inverso) se
pueden concebir pruebas que permiten demostrar que el sistema
cumple con esas características
103
Documentación de atributos Plaguage
Desarrollado por Tom Gilb, es un lenguaje de planeación con un
conjunto rico de palabras clave que permite describir de forma
precisa atributos de calidad y otros objetivos de proyecto
http://www.gilb.com
104
105
Compromisos Las combinaciones de atributos conllevan
compromisos
Un signo más significa que incrementar el atributo en la fila tiene
un efecto positivo sobre los atributos en las columnas
106
Compromisos Las combinaciones de atributos conllevan
compromisos
Un signo menos significa que incrementar el atributo en la fila
tiene un efecto adverso sobre los atributos en las columnas
107
Compromisos Las combinaciones de atributos conllevan
compromisos
Si no hay signo, no existe mucha interacción entre los
atributos
108
Implementación de reqs. NF Traducción de atributos de calidad en
especificaciones técnicas
Tipo de atributo de calidad Implicación
Integridad, interoperabilidad, robustez, usabilidad, seguridad
Requerimiento funcional
Disponibilidad, eficiencia, flexibilidad, desempeño,
confiabilidad
Arquitectura del sistema
Guía (estándar) de diseño
Portabilidad Restricción de implementación
110
Modelado de requerimientos Un complemento y no un reemplazo
Los modelos de análisis deben aumentar (en vez de reemplazar) los
requerimientos descritos textuales
Modelos de análisis y de diseño Para el análisis, los modelos se
utilizan para modelar el dominio del problema o crear
representaciones conceptuales del sistema
Los conceptos Para el diseño, los modelos especifican cómo se
pretende implementar el sistema
Lo que se quiere construir No es necesario modelar todo el
sistema
En general las partes críticas
111
Tipos de diagramas El modelado se realiza a partir de varios
diagramas
Diagrama de flujo de datos Diagramas de entidad-relación Diagramas
de transición de estados Diagramas de navegación Diagramas de clase
Diagramas de decisión
112
Diagrama de flujo de datos Herramienta fundamental del análisis
estructurado
Identifica procesos de transformación de un sistema, los almacenes
de datos y los flujos de datos entre procesos, almacenes y el mundo
exterior
Diagrama de contexto es el diagrama de flujo de datos de más alto
nivel
Se va refinando
114
Diagrama entidad-relación Muestra las relaciones entre los datos
del sistema
Se puede usar durante el análisis aún sin usar una BD al momento de
implementar
Entidades Son entidades físicas o agregaciones de datos que son
importantes para el sistema
Nombres singulares mostrados como rectangulos Tiene varios
atributos (contenidos en diccionario datos)
Relaciones Identifican conexiones lógicas y numéricas entre pares
de entidades
Su nombre indica la naturaleza de la conexión Cardinalidad indica
aspecto numérico
115
Diagramas de estados Propósito
Muchos sistemas de información tienen que ver con objetos cuyos
ciclos de vida involucran una serie de estados.
Estos elementos pueden ser vistos como máquinas de estados
finitos
El diagrama de transición de estados provee una manera de
representar una máquina de estados
Diagramas Statechart son similares
118
Diagrama de navegación Una interfaz de usuario puede ser vista como
una máquina de estados finitos
Sólo un elemento gráfico está disponible en un momento dado para
recibir interacción El usuario puede navegar a otros elementos a
partir de la acción que realiza en el elemento activo
Representa Interfaz de Usuario a un alto nivel No muestra diseños
detallados
119
Diagramas de clase y objetos Programación orientada a objetos
Los objetos corresponden a entidades del mundo real en el dominio
de negocio o del problema. Representan instancias individuales
derivadas de un templete llamado clase
Los diagramas de clase y objetos permiten representar vistas
estáticas y dinámicas del sistema
Diagramas de clase Diagramas de colaboración Diagramas de
secuencia
121
Permiten representar resultado de combinaciones de
condiciones
Árboles o tablas
123
Validación de requerimientos La cuarta componente del desarrollo de
reqs.
Comprende Revisión de requerimientos Prueba de requerimientos
Definición de criterios de aceptación
Ingeniería de requerimientos
Captura Análisis Especificación Validación
Pruebas y sus bases Modelo en V
Las actividades de prueba inician en paralelo con actividades de
desarrollo
Muestra en qué están basadas las pruebas
125
Revisión de requerimientos Propósito
La revisión de documentos de requerimientos es una técnica que
permite identificar requerimientos ambiguos o no verificables, que
no están bien definidos y otros problemas
Revisión por pares
Revisión puede ser informal o formal Revisión informal
Por un colega o por varios colegas Revisión formal es llamada
inspección
Labor tediosa pero necesaria Análisis de riesgos permite escoger
requerimientos que deben ser revisados forzosamente Ver detalles de
proceso en libro
126
Prueba de requerimientos Durante desarrollo de requerimientos
Nos se pueden ejecutar pruebas pues no hay código, sin embargo se
pueden generar casos de prueba basados en requerimientos con el fin
de revelar problemas antes de escribir código Los casos de prueba
pueden cubrir el curso normal o los cursos alternativos de un caso
de uso así como las excepciones
Utilizar un escenario de caso de uso y ver si está cubierto por la
propuesta
127
Criterios de aceptación Propósito
Los clientes realizan pruebas de aceptación para determinar si un
sistema satisface los criterios de aceptación
Estos criterios evalúan si el producto satisface los requerimientos
documentados y si es adecuado para usarse en el entorno operativo
donde se pretende usarlo
Los usuarios clave deben decidir como evaluar la aceptación
Las pruebas de aceptación se basan en el curso principal de los
casos de uso Es recomendable automatizarlas También deben cubrir
requerimientos no-funcionales
128
Requerimientos adicionales no cubiertos en otra parte Ej:
internacionalización
Appendice A: Glosario Appendix B: Modelos de análisis
Ej: diagramas de flujo de datos, de clase, entidad- relación,
etc..
Appendix C: Lista de problemas (optional)
129
Ingeniería de requerimientos
Captura Análisis Especificación Validación
De desarrollo a administración A estas alturas se dispone de
Documento de visión y alcance
Documento de casos de uso
SRS
132
Control de cambios y actualización de planeación
133
tanto a nivel de requerimientos
individuales como de documentos
Seguimiento
135
Trazabilidad
136
Respuesta ante cambios de reqs. La introducción de un nuevo
requerimiento o un cambio en un requerimiento se puede
manejar
Relegando requerimientos de baja prioridad Obteniendo recursos
humanos adicionales Incrementando tiempo laboral (y paga) por un
corto plazo Reacomodando la planeación Dejando que decaiga la
calidad del producto con tal de entregar a tiempo
Frecuentemente es la reacción por default
Ninguna reacción es la más correcta Depende de prioridades
establecidas por los involucrados
137
Establecimiento de la línea de base
Procedimientos de administración
Control de cambios
Atributos de requerimientos
Seguimiento del estatus
138
Establecimiento de línea de base Línea de base (baseline)
El conjunto de requerimientos funcionales y no- funcionales que el
equipo de desarrollo se ha comprometido a implementar para una
entrega específica
Estos documentos han recibido aprobación
Una vez que se han establecido, los requerimientos deben ser
puestos bajo control de cambios
Únicamente debe contener requerimientos que se van a
implementar
Separarlos de requerimientos para versiones futuras
139
Procedimientos de administración Dentro de las actividades se
encuentran
Definir herramientas, técnicas y convenciones para controlar
versiones de los documentos de requerimientos y de requerimientos
individuales Definir la manera en que los requerimientos se
incluyen en la línea de base Los tipos de estatus de los
requerimientos y quién podrá cambiarlos Los procedimientos de
seguimiento de estatus La manera de proponer, procesar, negociar y
comunicar nuevos requerimientos y cambios La manera de analizar el
impacto de un cambio propuesto La manera de reflejar cambios en
requerimientos a nivel de los planes del proyecto
Debe existir un responsable de llevar a cabo estas actividades o
hay riesgo de que no se realicen
140
Control de versiones El control de versiones es un aspecto esencial
de la administración de especificaciones de requerimientos y otros
documentos
Identificar versiones de documentos Asegurar acceso a última
versión Sólo ciertos individuos deben poder hacer cambios en los
requerimientos Guardar histórico de revisiones
141
Atributos de requerimientos Además de la descripción textual, cada
requerimiento funcional debe tener información adicional, o
atributos, asociados.
Establecen un contexto y antecedentes para el requerimiento
Ejemplos
Fecha de creación Fecha de última modificación Autor Responsable
Estatus Versión del producto asociada Prioridad Estabilidad
Escoger un subconjunto de atributos manejable
142
Seguimiento del estatus Dificultad de evaluación
Es difícil preguntar a desarrolladores cúal es el estado de su
avance
90 % (?)
La asignación de un estatus específico a los requerimientos es más
útil para dar seguimiento, el estatus puede tomar alguno de los
valores siguientes
Propuesto Aprobado Implementado Verificado Borrado Rechazado
143
El requerimiento ha sido solicitado por una fuente confiable.
Aprobado
El requerimiento ha sido analizado, su impacto estimado y ha sido
asignado a una versión del producto. Los involucrados están de
acuerdo en su implementación.
Implementado El código que implementa el requerimiento ha sido
diseñado, escrito y probado de forma unitaria.
Verificado Se ha comprobado el funcionamiento correcto de la
implementación del requerimiento. Se considera completo.
Borrado El requerimiento ha sido borrado de la línea de base
(incluir explicación y responsable).
Rechazado El requerimiento fue propuesto pero no se planea
implementarlo en una versión futura (explicación y resp.).
144
Seguimiento de estatus Gráfica de distribución de
requerimientos
Se termina una etapa cuando todos los requerimientos están
verificados o borrados
145
Medición de esfuerzo Beneficio
Si se mide el esfuerzo dedicado a la administración de
requerimientos se puede evaluar si es poco, suficiente o demasiado
y se pueden ajustar los procesos de acuerdo a ello.
Se puede medir esfuerzo dedicado a las siguientes actividades
Propuestas de cambios y de nuevos requerimientos Evaluación de
propuestas incluyendo análisis de impacto Actividades de comité de
control de cambios Actualización de base de datos de requerimientos
Comunicación de cambios a grupos afectados Trazado y reporte de
estatus de requerimientos Colecta de información de
trazabilidad
146
Cambio Administración de la explosión de requerimientos Proceso de
control de cambios Comité de control de cambios Midiendo la
actividad de cambio Análisis de impacto
147
Cambio El cambio sin control es fuente de caos La administración de
requerimientos seria debe asegurar que
Los cambios propuestos son evaluados con cuidado antes de ser
aceptados Los individuos apropiados toman decisiones informadas
acerca de los cambios Los cambios aprobados son comunicados a todos
los participantes El proyecto incorpora cambios de forma
consistente
Se debe cuidar de mantener en sincronía el código y la
documentación cuando ocurran cambios
148
Explosión de requerimientos El problema no es que los
requerimientos cambien sino que los cambios tienen un fuerte
impacto en el trabajo previamente realizado
Si todo cambio es aprobado hay riesgo de nunca terminar La
evolución es inevitable, y hasta puede ser ventajosa
La explosión incontrolada de requerimientos es problemática, para
evitarla
Cada requerimiento debe ser evaluado con respecto a los objetivos
de negocio, visión del producto y alcances del proyecto, Hacer
prototipos Saber decir NO
149
Proceso de control de cambios Objetivo
Permite a los lideres del proyecto tomar decisiones informadas que
tienen el mayor valor para los clientes y para el negocio mientras
que los costos de desarrollo se mantienen bajo control
Se recomienda implantar políticas de cambio Todo cambio debe seguir
el proceso o será ignorado El único trabajo que puede ser realizado
sin aprobación es trabajo exploratorio Someter un cambio no
garantiza que será aceptado La base de datos de cambios debe ser
visible para todos El texto de la petición no debe ser modificado o
borrado Un análisis de impacto debe ser realizado para todo cambio
Todo requerimiento incorporado debe ser trazable a una petición El
motivo de aceptación o rechazo debe ser guardado
150
Describe propósito del proceso Identifica productos que son
cubiertos por proceso
2. Roles y responsabilidades Identifica roles que participan en las
actividades de control de cambios
CCB chair, CCB, evaluador, modificador, originador,
verificador
152
Ciclo de vida de petición de cambio
153
Templete para proceso 4. Criterio de entrada
Describe los pasos a seguir para poder someter una petición de
cambio
“Las peticiones de cambio se someten a través de la página de
JIRA”
5. Tareas Las distintas tareas involucradas en el proceso, el rol
responsable para cada tarea y los participantes en la tarea
6. Verificación Describe los pasos que se siguen para verificar que
las tareas fueron completadas correctamente
154
Templete para proceso 7. Criterio de salida
Se deben satisfacer los siguientes criterios de salida para
completar la ejecución del proceso
El estatus de la petición es Rechazado, Cerrado o Cancelado Los
productos de trabajo modificados están instalado en los
emplazamientos correctos Los participantes han sido notificados de
los detalles de cambio y del estatus de la solicitud La matriz de
trazabilidad ha sido actualizada
8. Reporte de control de cambios Identifica gráficas y reportes que
se usarán para resumir contenido de BD de cambios.
155
Consejo de control de cambios Qué es?
El consejo de control de cambios es un individuo o un grupo de
gente que deciden que propuestas de cambios en características y
nuevas características se aceptan para ser incluidas en el
producto.
Dependiendo del tamaño del proyecto, el CCC puede tener hasta
varios niveles
También decide que defectos reportados deben ser corregidos y
cuando corregirlos.
El CCC no tiene que ser sinónimo de burocracia Debe ser efectivo,
considerar de forma oportuna las solicitudes de cambio y darles
seguimiento.
156
Herramientas de control de cambios
Características deseables en una herramienta Permite definir los
datos que deben ser incluidos en una petición de cambio Permite
definir un modelo de transición de estados para el ciclo de vida de
las solicitudes Obedece al modelo de tal forma que sólo usuarios
autorizados pueden hacer cambios de estatus Registra la fecha de
cambios en el estatus así como la identidad del autor Permite
definir quién recibe notificaciones (por ej. vía e-mail) cuando se
somete una nueva solicitud o cuando se actualiza un estatus Produce
reportes y gráficas
157
Medición de actividad de cambios Realizar medición de la actividad
de cambios es una manera de evaluar la estabilidad de los
requerimientos.
También permite mejorar proceso Las métricas se pueden realizar
sobre
El numero de solicitudes de cambio recibidas, abiertas y cerradas
El numero acumulado de cambios realizados, incluyendo los
requerimientos agregados, borrados y modificados (por ej. % del
total) El numero de solicitudes que se originan de cada fuente El
numero de cambios propuestos y realizados a cada requerimiento
desde que se estableció en la línea de base El esfuerzo total
dedicado a procesar e implementar solicitudes de cambio El numero
de ciclos en el proceso que tomo implementar de forma correcta cada
cambio aprobado
158
Medición de actividad de cambios No es necesario realizar una
medición detallada desde el principio
Seguir un enfoque gradual Ejemplos de representaciones
gráficas
159
Análisis de impacto El análisis de impacto es una aspecto clave de
la administración de riesgos responsable
Provee comprensión de las implicaciones de un cambio propuesto lo
cual facilita la toma de decisiones El análisis examina el cambio
propuesto para identificar componentes que tengan que ser creados,
modificados o desechados y para estimar el esfuerzo de implementar
el cambio.
Antes de aceptar un cambio, es necesario hacer un análisis de
impacto.
160
Análisis de impacto El análisis de impactos tiene tres
aspectos
1. Comprender las implicaciones de la realización del cambio.
Un cambio puede tener un efecto domino.
2. Identificar todos los archivos, modelos y documentos que tengan
que ser modificados si el equipo incorpora el cambio
solicitado
3. Identificar las tareas necesarias para implementar el cambio y
estimar el esfuerzo necesario para completarlas
161
Comprensión de implicaciones Preguntas que ayudan a comprender las
implicaciones de aceptar un cambio
Existe algún conflicto entre el cambio propuesto y los
requerimientos aceptados? Existen cambios pendientes que entren en
conflicto con el cambio propuesto? Cuáles son las consecuencias
técnicas o de negocio si se decide no hacer el cambio? Cuales son
los efectos secundarios u otros riesgos si se realiza el cambio?
Afectará el cambio algún atributo de calidad? Es factible realizar
el cambio con los recursos humanos disponibles? Es necesario
adquirir herramientas nuevas para implementar y probar el cambio?
Cómo afectará el cambio al plan de proyecto? Qué tipo de entrada
será necesaria para verificar el cambio propuesto? Cuanto esfuerzo
que ya se ha invertido en el proyecto se perderá si el cambio es
aceptado? Aumentará el cambio el costo unitario del producto?
162
Elementos afectados por cambio Lista de elementos potencialmente
afectados por un cambio
Identificar cambios, añadiduras o eliminación de elementos en la
interfaz de usuario Identificar cambios en reportes, BDs o archivos
Identificar componentes de diseño que deban ser creados,
modificados o borrados Identificar código fuente que deba ser
creado, modificado o borrado Identificar cambios en buildfiles
Identificar cambios en casos de pruebas Estimar los nuevos casos de
prueba requeridos Identificar la documentación que deba ser creada
o modificada Identificar otras aplicaciones, librerías o
componentes de hardware afectados por el cambio Identificar
software que tiene que ser adquirido Identificar impacto en los
planes
163
Proceso para evaluar impacto Basarse en listas anteriores para
identificación Usar una hoja de estimación de esfuerzo
164
Proceso para evaluar impacto Calcular el total de esfuerzo
requerido Identificar secuencia de tareas a realizar y cómo se
entretejen con las tareas existentes Determinar si el cambio está
en el camino crítico del proyecto. En caso positivo, la fecha de
entrega se verá impactada. Estimar impacto en costo y planeación
del proyecto Evaluar prioridad del cambio Reportar resultado del
análisis de impacto al CCC para ayudarlos a decidir si se aprueba o
no el cambio
165
Templete de reporte de análisis El uso de este tipo de templetes le
facilita la tarea al CCC
166
Requerimientos de software y administración de riesgos
167
Motivación de trazabilidad Impacto de cambios de
requerimientos
Cambios simples de requerimientos pueden tener impactos grandes que
requieren cambios en muchas partes del producto. Puede ser difícil
encontrar todos los componentes que se ven afectados por un cambio
en los requerimientos.
Necesidad de trazabilidad La trazabilidad documenta las
dependencias y relaciones lógicas entre los requerimientos y otros
elementos del sistema.
Otros requerimientos, componentes de diseño, módulos de código
fuente, archivos de ayuda...
168
Ligas de trazabilidad Bi-direccionalidad
La trazabilidad permite seguir “la vida” de un requerimiento hacia
adelante y hacia atrás
Del origen a la implementación Para permitir realizar la
trazabilidad, cada requerimiento debe ser identificado de forma
única para poder hacer referencia a él sin ambigüedades a lo largo
del proyecto.
169
Relación necesidad - producto Relaciones de trazabilidad entre
necesidades y productos
Relaciones entre necesidades de cliente y requerimientos permiten
ver que la especificación de requerimiento cubre todas las
necesidades del cliente
Relaciones entre requerimientos y productos permiten saber que se
han cubierto todos los requerimientos y por ende todas las
necesidades del cliente
170
Ejemplos de relaciones Las siguientes relaciones son susceptibles
de ser trazadas
No es necesario tener trazabilidad en todas las relaciones
Se debe decidir qué relaciones son pertinentes para el
proyecto
171
Análisis de impacto de cambios Facilita mantenimiento Apoya
seguimiento del proyecto
Relaciones faltantes pueden significar requerimientos no
implementados
Reutilización Disminución de riesgo Facilita pruebas
Beneficios a largo plazo Implican aumento en costo de
desarrollo
172
Ejemplo
173
Cardinalidad Las relaciones de trazabilidad pueden tener
cardinalidades 1..1, 1..n, n..m
Relaciones n..m son difíciles de manejar Ejemplo de tabla que
permite mostrar cardinalidades
174
Soporte de herramientas La trazabilidad manual no es factible más
que para aplicaciones pequeñas
Una hoja de calculo puede usarse para unos 200 requerimientos Más
requerimientos necesitan del uso de herramientas
No es posible automatizar la trazabilidad de forma completa
La información de las relaciones se tiene que introducir
manualmente Una vez introducida ya se puede administrar a través de
herramientas
Ej. Cambio en caso de uso muestra en donde puede haber impactos
potenciales.
175
Realización Pasos a seguir para realizar trazabilidad
1. Escoger relaciones que interesan 2. Escoger tipo de matriz de
trazabilidad 3. Identificar partes del producto para las cuales
se
desea tener información de trazabilidad 4. Modificar procedimiento
de desarrollo para incluir
actualización en relaciones 5. Definir convenciones de
identificación 6. Identificar proveedores de información y
coordinador de actividades de trazabilidad 7. Educar al equipo
sobre trazabilidad 8. Recabar información de trazabilida de
forma
continua 9. Revisar información de forma periódica
176
Requerimientos de software y administración de riesgos
177
Mejora de procesos En esencia, la mejora de procesos consiste en
usar más de los enfoques que funcionan bien para nosotros y menos
de aquellos que no.
El objetivo final de la mejora de procesos de software es la
reducción del costo de crear y mantener software. Esto se puede
lograr de diversas formas
Corrigiendo problemas que surgieron en proyectos anteriores o
actuales y resultantes de limitantes en los procesos Anticipando y
previniendo problemas que podrían ocurrir en proyectos futuros
Adoptando prácticas más eficientes que las que se usan en la
actualidad
178
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
179
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
Los requerimientos son la fundación del proceso de planeación. Los
administradores seleccionan un ciclo de vida de desarrollo y
estiman recursos y tiempos basandose en los requerimientos.
180
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
El seguimiento del proyecto incluye el monitoreo del estado de cada
requerimiento lo cual permite al administrador de saber si la
construcción y la verificación se hacen de forma adecuada.
181
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
Una vez que un conjunto de requerimientos han sido establecidos en
la línea de base, todos los cambios subsecuentes deben realizarse a
través de un proceso de control de cambios bien definido.
182
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
Los requerimientos de usaurio y los requerimientos funcionales son
fundamentales para la realización de pruebas. Requerimientos mal
definidos harán la vida difícil al equipo de pruebas.
183
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
Los requerimientos son la base para el trabajo de diseño e
implementación.
184
Requerimientos y otros procesos Relación entre los requerimientos y
otros procesos dentro del desarrollo
Los requerimientos están a la entrada del proceso de desarrollo de
documentación para usuarios. Requerimientos de mala calidad
resultarán en documentación pobre.
185
Principios de mejora de procesos 4 principios de mejora de
procesos
La mejora de procesos debe ser evolutiva, continua y cíclica.
No querer cambiar todo de un golpe La gente y las organizaciones
cambian únicamente cuando hay incentivos para hacerlo
Ej. descontento con resultados anteriores El cambio en los procesos
debe ser orientado a objetivos
Qué se quiere mejorar exactamente? Dar seguimiento a actividades de
mejora como si fueran mini-proyectos.
186
187
Curva de aprendizaje Es una parte inevitable de la mejora de
procesos
188
Bienes de proceso Para facilitar el desempeño de los distintos
procesos de la ingeniería de requerimientos, toda organización
necesita una colección de bienes de proceso
Los bienes ayudan a los involucrados a entender los pasos a seguir
y los productos a crear.
Ejemplos de bienes en general Listas de chequeo Ejemplos Planes
Políticas Procedimientos Descripciones de procesos Templetes
189
Bienes de proceso Para desarrollo de requerimientos
Proceso de desarrollo de requerimientos Procedimiento de
priorización de requerimientos Templete de visión y alcance
Templete de caso de uso Templete de SRS
Para administración de requerimientos Proceso de administración de
requerimientos Proceso de control de cambios Procedimiento de
seguimiento de estado Procedimiento de trazabilidad Directivas de
comité de control de cambios Templete de impacto de cambios
190
Mapa de ruta Es conveniente desarrollar un mapa de ruta para la
implantación de mejoras de proceso
191
Mapa de ruta Es conveniente desarrollar un mapa de ruta para la
implantación de mejoras de proceso
Objetivos de negocio
192
Mapa de ruta Es conveniente desarrollar un mapa de ruta para la
implantación de mejoras de proceso
Actividades de mejora
193
Mapa de ruta Es conveniente desarrollar un mapa de ruta para la
implantación de mejoras de proceso
Alcances
194
Requerimientos de software y administración de riesgos
195
Puntos susceptibles de introducir riesgos durante la captura de
requerimientos
Desarrollo de visión y alcance Establecimiento de un tiempo
dedicado al desarrollo de requerimientos Requerimientos incompletos
Capturan de requerimientos no-funcionales Acuerdo entre
involucrados relativo a los requerimientos entre los involucrados
Comunicación (mala) de los requerimientos
196
Puntos susceptibles de introducir riesgos durante el análisis de
requerimientos
Priorización de los riesgos Herramientas, métodos, lenguaje o
hardware no familiares
197
Puntos susceptibles de introducir riesgos durante el diseño de
requerimientos
Especificación y comprensión de requerimientos TBD's no completados
Terminología ambigua Detalles de diseño incluidos en SRS
Puntos susceptibles de introducir riesgos durante la validación de
requerimientos
Validación de requerimientos Mala inspección de
requerimientos
198
Puntos susceptibles de introducir riesgos durante la administración
de requerimientos
Cambios excesivo en los requerimientos Proceso de control de cambio
inefectivo Requerimientos no implementados Alcance del proyecto
cambiante
Página 1
Página 2
Página 3
Página 4
Página 5
Página 6
Página 7
Página 8
Página 9
Página 10
Página 11
Página 12
Página 13
Página 14
Página 15
Página 16
Página 17
Página 18
Página 19
Página 20
Página 21
Página 22
Página 23
Página 24
Página 25
Página 26
Página 27
Página 28
Página 29
Página 30
Página 31
Página 32
Página 33
Página 34
Página 35
Página 36
Página 37
Página 38
Página 39
Página 40
Página 41
Página 42
Página 43
Página 44
Página 45
Página 46
Página 47
Página 48
Página 49
Página 50
Página 51
Página 52
Página 53
Página 54
Página 55
Página 56
Página 57
Página 58
Página 59
Página 60
Página 61
Página 62
Página 63
Página 64
Página 65
Página 66
Página 67
Página 68
Página 69
Página 70
Página 71
Página 72
Página 73
Página 74
Página 75
Página 76
Página 77
Página 78
Página 79
Página 80
Página 81
Página 82
Página 83
Página 84
Página 85
Página 86
Página 87
Página 88
Página 89
Página 90
Página 91
Página 92
Página 93
Página 94
Página 95
Página 96
Página 97
Página 98
Página 99
Página 100
Página 101
Página 102
Página 103
Página 104
Página 105
Página 106
Página 107
Página 108
Página 109
Página 110
Página 111
Página 112
Página 113
Página 114
Página 115
Página 116
Página 117
Página 118
Página 119
Página 120
Página 121
Página 122
Página 123
Página 124
Página 125
Página 126
Página 127
Página 128
Página 129
Página 130
Página 131
Página 132
Página 133
Página 134
Página 135
Página 136
Página 137
Página 138
Página 139
Página 140
Página 141
Página 142
Página 143
Página 144
Página 145
Página 146
Página 147
Página 148
Página 149
Página 150
Página 151
Página 152
Página 153
Página 154
Página 155
Página 156
Página 157
Página 158
Página 159
Página 160
Página 161
Página 162
Página 163
Página 164
Página 165
Página 166
Página 167
Página 168
Página 169
Página 170
Página 171
Página 172
Página 173
Página 174
Página 175
Página 176
Página 177
Página 178
Página 179
Página 180
Página 181
Página 182
Página 183
Página 184
Página 185
Página 186
Página 187
Página 188
Página 189
Página 190
Página 191
Página 192
Página 193
Página 194
Página 195
Página 196
Página 197
Página 198