administración del proceso de software

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
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
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
Un signo menos significa que incrementar el atributo en la fila tiene un efecto adverso sobre los atributos en las columnas
107
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
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
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
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
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
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
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
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
Los requerimientos son la base para el trabajo de diseño e implementación.
184
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
Objetivos de negocio
192
Actividades de mejora
193
Alcances
194
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

administración del proceso de software

Documents