Semana 11

FORMULACIÓN DE PROYECTOS
 Definir y
Planificación Crear y analizar
Elaborar
Final del Curso modelos
Requerimientos

Definir Criterios Verificar

de Aceptación Requerimientos
Planificación Final Curso
▪07/01/2019 Análisis
▪09/01/2019 Análisis
▪14/01/2019 Análisis (Riesgos y Enfoque de Proyectos)
▪16/01/2019 Práctica de Análisis
▪21/01/2019 Trazabilidad y seguimiento.
▪23/01/2019 Práctica de EVM
▪28/01/2019 Evaluación de la solución
▪30/01/2019 Práctica de Trazabilidad y seguimiento y Evaluación de la solución
▪04/02/2019 Exposición Trabajo Integrador
▪06/02/2019 Exposición Trabajo Integrador
▪11/02/2019 Exposición Trabajo Integrador
▪13/02/2019 Exposición Trabajo Integrador
7 Análisis
▪El análisis incluye los procesos para examinar y
documentar la información del producto con suficiente
detalle para garantizar que refleje las necesidades de las
partes interesadas, se alinee con sus objetivos y metas
comerciales, y permita la identificación de diseños de
soluciones viables.
7 Análisis
▪El análisis es el proceso de examinar, desglosar, sintetizar y
aclarar información para comprenderla mejor, completarla
y mejorarla.
▪El análisis es una de las actividades principales realizadas
en cualquier portafolio, programa o proyecto, y
generalmente garantiza el compromiso de una cantidad
significativa de esfuerzo.
7 Análisis
▪Además de analizar, modelar y documentar la información
del producto, el análisis completa el conjunto de
información del producto asegurándose de que sea
correcta, se ajuste a los estándares, se pueda rastrear a los
objetivos, se identifiquen los riesgos inherentes y se pueda
convertir en el diseño del producto.
7 Análisis
1. Determinar el enfoque de análisis
2. Crear y analizar modelos
3. Definir y elaborar requisitos.
4. Definir los criterios de aceptación
5. Verificar los requisitos
6. Validar los requisitos
7. Priorizar requisitos y otra información del producto
8. Identificar y analizar los riesgos del producto
9. Evaluar las opciones de diseño de productos
7.2 Crear y analizar modelos
▪Proceso de crear representaciones estructuradas, como diagramas,
tablas o texto estructurado, de cualquier información del producto
para facilitar un análisis más detallado al identificar brechas en la
información o al descubrir información extraña.
▪El beneficio clave de este proceso es que ayuda a transmitir
información de una manera organizada que proporciona claridad y
ayuda a lograr la exactitud y la integridad.
7.2 Crear y analizar modelos
▪Crear y Analizar Modelos incluyen:
▪La definición y elaboración de requerimientos.
▪Se construye un entendimiento compartido de la información.
▪Mapeo de las relaciones y dependencias dentro y entre portafolios,
programas y proyectos
▪Encontrar vacíos de información que requieran una obtención adicional
▪Identificar partes interesadas que no se incluyeron anteriormente
▪Facilitar la comprensión de la información por parte de los
interesados durante la obtención o revisión
7.2 Crear y analizar modelos
▪Crear y Analizar Modelos incluyen:
▪Evaluar las brechas de capacidad entre los estados actuales y futuros
de un producto
▪Analizar los cambios para identificar qué áreas de un producto se ven
afectadas
▪Entender lo que es de valor para los usuarios
▪Priorizar la información del producto o proyectos en una cartera.
7.2 Crear y analizar modelos
7.2 Crear y analizar modelos
Categoría Definición Modelos
Modelado del alcance Modelos que estructuran y organizan las características, funciones y Diagramas de contexto
límites del dominio empresarial que se está analizando. Mapa de ecosistemas
Lista de eventos
Modelo de características
Metas y Objetivos del modelo de negocio
Organigrama
Diagramas de casos de uso
Modelado de Procesos Modelos que describen los procesos de negocios y las formas en que Flujo del proceso
los interesados ​interactúan con esos procesos Caso de uso
Historia del usuario
Modelado de Reglas Modelos de conceptos y comportamientos que definen o restringen Catálogo de Reglas de negocio.
aspectos de una empresa para hacer cumplir las políticas Tablas de decisiones
comerciales establecidas. Árbol de decisión
Modelado de Datos Modelos que documentan los datos utilizados en un proceso o Diccionario de datos
sistema y su ciclo de vida Diagrama de flujo de datos
Diagrama de entidad relación
Diagrama de estado
Tabla de estado
Modelado de Interfaces Modelos que ayudan a comprender sistemas específicos y sus Modelo de visualización-acción-respuesta
relaciones dentro de una solución y con los usuarios. Prototipo
Tabla de informes
Tabla de interfaz del sistema
Flujo de interfaz de usuario
Wireframe
7.2 Crear y analizar modelos Entradas
▪Enfoque de análisis
▪Resultados de elicitación confirmados
▪Requisitos y otra información del producto
7.2 Crear y analizar modelos H/T
▪Diagrama de contexto
▪Es un modelo de alcance que muestra todas las interfaces humanas y
del sistema directo a los sistemas dentro de una solución.
▪Un diagrama de contexto describe claramente los sistemas dentro del
alcance y cualquier entrada o salida, incluidos los sistemas o actores
que los proporcionan o los reciben.
7.2 Crear y analizar
modelos H/T
▪Diagrama de contexto
▪Describe el alcance de
los sistemas
▪Incluye entradas o
salidas, sistemas o
actores que los
proporcionan o los
reciben.
7.2 Crear y analizar modelos H/T
▪Diccionario de datos
▪Es un modelo de datos que enumera los campos de datos y los
atributos de esos campos para un objeto de datos.
▪Los campos de datos son detalles adicionales para los objetos de datos
en un diagrama de relación de entidad.
7.2 Crear y analizar
modelos H/T
▪Diccionario de Datos
7.2 Crear y analizar modelos H/T
▪Diagrama de flujo de datos
▪Es un modelo de datos que se utiliza para describir el movimiento de
datos entre entidades externas, almacenes de datos y procesos.
▪Las entidades externas pueden ser actores o sistemas.
▪Los diagramas de flujo de datos muestran las entradas y salidas de datos
para cada proceso.
7.2 Crear y analizar
modelos H/T
▪Diagrama de flujo de datos
7.2 Crear y analizar modelos H/T
▪Árboles de decisiones y tablas de decisiones
▪Son modelos de reglas que muestran una serie de decisiones y los
resultados a los que conducen las decisiones.
▪Los árboles de decisión y las tablas se utilizan a menudo para modelar
reglas de negocios.
▪Los dos modelos de decisión se utilizan de diferentes maneras, y ambos
podrían ser necesarios.
7.2 Crear y analizar
modelos H/T
▪Árboles de decisión
▪Muestran visualmente el flujo de
decisiones y elecciones que
conducen a un resultado y pueden
mostrar decisiones ordenadas.
▪Nodos de Decisión
▪Nodos de Probabilidad
7.2 Crear y analizar
modelos H/T
▪Tablas de decisiones
▪Son útiles para asegurar que el
analista de negocios haya
considerado todas las
combinaciones posibles de
escenarios de decisión y
resultados relacionados.
7.2 Crear y analizar modelos H/T
▪Mapa de ecosistemas
▪Es un modelo de alcance que muestra todos los sistemas relevantes,
las relaciones entre sistemas y, opcionalmente, cualquier objeto de
datos que se pase entre ellos.
▪Los mapas de ecosistemas son más útiles cuando se crean al comienzo
de los proyectos para comprender todos los sistemas que pueden verse
afectados o que afectarán a los sistemas dentro del alcance.
7.2 Crear y analizar
modelos H/T
▪ Mapa de Ecosistemas
▪Los sistemas son sistemas lógicos
(vista empresarial); por lo tanto,
es posible que no coincidan con
los sistemas físicos (vista de
implementación) en los diagramas
arquitectónicos.
7.2 Crear y analizar modelos H/T
▪El diagrama de entidad relación (DER)
▪También denominado diagrama de datos comerciales, es un modelo de
datos que muestra los objetos de datos comerciales o piezas de
información de interés en un producto y la relación de cardinalidad
entre esos objetos.
▪La cardinalidad es el número de veces que ocurre una entidad en
relación con la otra entidad en la relación, y si la relación es
obligatoria u opcional
7.2 Crear y analizar
modelos H/T
▪ Diagrama Entidad Relación
▪Normalmente se crean en un
análisis relativamente temprano
para comprender el alcance de los
datos que se analizarán. Este
modelo también ayuda a
identificar cualquier proceso que
pueda crear, consumir o manipular
los datos, así como las reglas
comerciales sobre los datos.
7.2 Crear y analizar modelos H/T
▪Lista de eventos
▪Es un modelo de alcance que describe los eventos externos que
desencadenan el comportamiento de la solución.
▪Las listas de eventos ayudan a definir los eventos dentro del alcance a
los que la solución debe reaccionar o manejar.
▪Una tabla de respuesta a eventos es un modelo relacionado que
extiende la lista de eventos para describir la respuesta del sistema a
cualquier desencadenante de eventos.
7.2 Crear y analizar
modelos H/T
▪ Lista de Eventos
▪Las listas de eventos se crean con
anticipación para garantizar que el
alcance del trabajo esté definido y
pueda actualizarse a medida que
el trabajo continúe y se
identifiquen los nuevos eventos.
▪Las tablas de respuesta a eventos
se crean para ayudar a identificar
casos de uso probables, historias
de usuarios o flujos del sistema.
7.2 Crear y analizar modelos H/T
▪Modelo de características
▪Es un modelo de alcance que representa visualmente todas las
características de una solución organizada en un árbol o estructura
jerárquica.
▪La mayoría de los proyectos tienen características en diferentes niveles;
las funciones de nivel superior se denominan funciones de nivel 1 (L1),
seguidas de las funciones de nivel 2 (L2), etc.
▪Los modelos de características son útiles para mostrar cómo se agrupan
las características y qué características son subcaracterísticas de otras.
▪Los modelos de funciones son útiles porque pueden mostrar fácilmente
muchas funciones en diferentes niveles en una sola página.
 7.2 Crear y analizar
modelos H/T
▪ Modelo de Características
▪Este modelo generalmente se emplea al
comienzo de un proyecto para mostrar
todas las características que están
dentro del alcance de un programa o
proyecto, y se actualiza a medida que se
identifican las características adicionales
durante la obtención y el análisis.
▪En proyectos adaptables, las
características se pueden etiquetar para
su inclusión en diferentes iteraciones
para facilitar la planificación de la
versión..
7.2 Crear y analizar modelos H/T
▪Modelo de metas y modelo de objetivos de negocios
▪Son modelos de alcance que organizan y reflejan los objetivos y
objetivos de negocios en relación con otra información del producto.
▪Los modelos de metas suelen mostrar los objetivos de las partes
interesadas para una solución, con cualquier relación de objetivo
compatible o conflictiva indicada.
▪Los modelos de objetivos de negocios relacionan los problemas de
negocios, los objetivos de negocios y las características de nivel superior
7.2 Crear y analizar
modelos H/T
▪ Modelo de metas y modelo de
objetivos de negocios
▪En los modelos de objetivos de
negocios, los problemas de negocios
y los objetivos de negocios
descomponen las estrategias de
negocios de alto nivel en problemas
de menor nivel y los objetivos de
negocios para representar
visualmente el valor del portafolio,
el programa o el proyecto y cómo la
solución logrará los objetivos de
negocios
7.2 Crear y analizar modelos H/T
▪Elaboración de modelos
▪Es una técnica que utiliza la colección de modelos para identificar
vacíos, inconsistencias o redundancias en la información del producto.
▪La arquitectura de requisitos, tal como se define en el enfoque de
análisis, ayudará a determinar qué modelos son los mejores para usar
juntos.
▪Los modelos pueden usarse colectivamente para ayudar a completar
uno al otro.
7.2 Crear y analizar
modelos H/T
▪ Matriz de trazabilidad
▪Es una tabla que rastrea enlaces
entre elementos.
▪Comúnmente, los analistas de
negocios usan matrices de
trazabilidad para rastrear los
requisitos hacia atrás hasta las
características y los objetivos del
negocio o hacia el código u otros
artefactos de desarrollo o casos de
prueba.
7.2 Crear y analizar
modelos H/T
▪ Matriz de interacción.
▪Una matriz de interacción es una
versión ligera de una matriz de
trazabilidad que se utiliza para
determinar si los requisitos son lo
suficientemente detallados o si
falta alguna entidad.
▪La principal diferencia entre los
dos tipos de matrices de
trazabilidad es que una matriz de
interacción representa un punto
específico en el tiempo
7.2 Crear y analizar
modelos H/T
▪ Matriz CRUD.
▪Definido como crear (C), leer (R),
actualizar (U) y eliminar (D),
representa las operaciones que se
pueden aplicar a los datos u
objetos.
▪Las matrices CRUD describen
quién o qué tiene permiso para
realizar cada una de las
operaciones de CRUD en
elementos, como datos o pantallas
de interfaz de usuario.
7.2 Crear y analizar
modelos H/T
▪ Organigrama
▪Es un modelo de alcance que
muestra la estructura de informes
dentro de una organización o
dentro de una parte de una
organización. Los organigramas
utilizados durante el análisis
pueden variar de los utilizados en
el análisis de las partes
interesadas.
7.2 Crear y analizar
modelos H/T
▪ Flujo de Procesos
▪Se utilizan para documentar
visualmente los pasos o tareas que
las personas realizan en sus
trabajos o cuando interactúan con
una solución. Normalmente, los
flujos de proceso describen los
pasos que toman las personas,
aunque pueden describir los pasos
del sistema y podrían
denominarse flujos de sistema.
7.2 Crear y analizar
modelos H/T
▪Prototipos, Esquemas, modelos
de pantalla de acción y respuesta
▪Son todos modelos de interfaz. Un
prototipo es una representación
de la solución esperada antes de
que se construya. Los prototipos
pueden ser de baja fidelidad,
como un boceto de un diseño de
pantalla, o de alta fidelidad, como
una interfaz de usuario interactiva.
7.2 Crear y analizar
modelos H/T
▪Tabla de Informes
▪Modelo de interfaz que describe los requisitos
detallados para un solo informe.
▪Las tablas de informes contienen tanto
información sobre el informe como un todo,
como el nombre del informe o las decisiones
tomadas a partir del informe, e información a
nivel de campo, como los campos de datos que
se muestran y los cálculos.
7.2 Crear y analizar
modelos H/T
▪Tabla de estados y Diagrama de
estados
▪Son modelos de datos que
muestran los estados válidos de
un objeto y las transiciones
permitidas entre esos estados.
▪Los objetos pueden ser elementos
de datos comerciales o cualquier
información de interés al analizar
una solución.
7.2 Crear y analizar
modelos H/T
▪Mapeo de historias
▪Técnica que se usa para
secuenciar historias de usuarios,
según su valor comercial y el
orden en el que los usuarios
suelen realizarlas, para que los
equipos puedan llegar a un
entendimiento compartido de lo
que se construirá.
 7.2 Crear y analizar
modelos H/T
▪Tabla de interfaz del sistema
▪Modelo de interfaz que captura todos
los requisitos de nivel detallados para
una única interfaz de sistema.
▪Las tablas de interfaz del sistema se
crean para cada sistema que se
interconecta con el sistema de solución.
▪Las tablas de la interfaz del sistema
incluyen información como los campos
de datos que pasan de un sistema a otro,
la frecuencia y el volumen.
7.2 Crear y analizar
modelos H/T
▪Diagrama de casos de uso
▪Modelo de alcance que muestra
todos los casos de uso dentro del
alcance de una solución.
▪La creación de diagramas de casos
de uso implica identificar una lista
de los usuarios de la solución y los
posibles escenarios de cómo cada
usuario usará la solución.
7.2 Crear y analizar
modelos H/T
▪Flujo de interfaz de usuario
▪Modelo de interfaz que muestra
interfaces de usuario específicas y
pantallas de uso común dentro de
un diseño funcional y muestra
cómo navegar entre ellas.
▪Pueden acompañar flujos de
procesos o casos de uso para
ayudar a mostrar visualmente las
interacciones de los usuarios con
el sistema para un escenario.
7.2 Crear y analizar modelos Salidas
Modelos de análisis
▪Son representaciones visuales de la información del
producto.
▪Los modelos de análisis pueden ser borradores o modelos
completos.
▪Pueden ser representaciones de alta fidelidad,
semánticamente correctas o bocetos de baja fidelidad.
▪No todos los tipos de modelos serán necesarios en una
iniciativa.
7.3 Definir y Elaborar Requerimientos
▪Proceso de refinación y documentación de requisitos y
otros tipos de información de productos con el nivel
apropiado de detalle, formato y nivel de formalidad
requerido para las distintas audiencias.
▪Los beneficios clave de este proceso son que (a) ayuda a
aclarar los detalles sobre la información del producto para
que el equipo pueda trabajar en forma efectiva, y (b)
almacena la información del producto de manera que todas
las partes interesadas puedan acceder a ella y procesarla.
7.3 Definir y Elaborar Requerimientos
▪Incluye lo siguiente:
▪Suposiciones.- Cualquier factor sobre los problemas
comerciales, los objetivos comerciales, los requisitos, el diseño
o la solución que se consideren verdaderos sin prueba ni
demostración.
▪Restricciones.- Factores limitantes que afectan la ejecución de
un portafolio, programa, proyecto o proceso. En el análisis de
negocios, las restricciones son factores que afectan el
desarrollo o la implementación de la solución.
7.3 Definir y Elaborar Requerimientos
▪Incluye lo siguiente:
▪Dependencias. Cualquier información del producto que los
requisitos estén supeditadas o controladas.
▪Cuestiones (issues). Temas en cuestión o en discusión sobre
los requisitos u otra información del producto. Los problemas
se documentan y se rastrean hasta su resolución, que a
menudo se requiere antes de que se completen los requisitos.
▪Riesgos del producto. Eventos inciertos o condiciones que, si
ocurren, tienen efectos positivos o negativos en el producto.
7.3 Definir y Elaborar Requerimientos
7.3 Definir y Elaborar Requerimientos
Entradas
▪Enfoque del análisis
▪Modelos de análisis
▪Resultados de elicitación confirmados
▪Relaciones y dependencias
▪Enfoque de compromiso y comunicación de los
stakeholders
7.3 Definir y Elaborar Requerimientos
H/T
▪Catálogo de reglas de negocios.- es una tabla de reglas de negocios
y atributos relacionados. Las reglas de negocios no son procesos o
procedimientos; más bien, describen cómo restringir o apoyar los
comportamientos dentro de las operaciones del negocio.
▪Definición de listo.- Es una serie de condiciones que todo el equipo
acuerda completar antes de que una historia de usuario se considere
lo suficientemente entendida como para que el trabajo pueda
comenzar a construirla.
▪Glosario.- lista de todas las definiciones de términos y acrónimos de
un producto.
7.3 Definir y Elaborar Requerimientos
H/T
▪Herramienta de gestión de requisitos.- permite que los requisitos y otra
información del producto se capturen y almacenen en un repositorio. Al
definir y elaborar requisitos, los requisitos a menudo se almacenan en una
herramienta de administración de requisitos, incluido un estado, cualquier
valor de atributo conocido y modelos relacionados.
▪Elaboración de historia.- La elaboración de historias es el proceso
mediante el cual las historias de usuarios se detallan más con información
adicional hasta que están listas para su desarrollo. La elaboración de la
historia se conoce como refinamiento de cartera. En los enfoques
adaptativos, las historias de usuario se encuentran en un nivel de detalle
más alto que los requisitos funcionales y no funcionales
7.3 Definir y Elaborar Requerimientos
H/T
▪División de historias es una técnica que se utiliza para dividir épicas o
historias de usuarios desde un nivel superior a un nivel inferior. Una
historia épica, una historia de usuario o un requisito podrían dividirse de
varias maneras, incluso por tipo de interfaz, usuario o persona,
funcionalidad, datos, reglas de negocios, restricciones o cualquier
combinación de ellas.
▪Caso de uso es un modelo de proceso que utiliza una narrativa textual
para describir las interacciones entre el sistema y el usuario para lograr el
logro exitoso de una meta.
7.3 Definir y Elaborar Requerimientos
H/T
▪Historias de usuarios
▪Son un método para documentar los requisitos de las partes interesadas
desde el punto de vista de los usuarios con un enfoque en el valor o
beneficio alcanzado por el usuario con la finalización de esa historia. Las
historias de usuario ayudan a pasar de los requisitos comerciales a los
requisitos de solución
▪Las historias de usuario se pueden usar para asignar requisitos o criterios
de aceptación a modelos de proceso que reflejen las tareas generales de
los usuarios de negocios.
7.3 Definir y Elaborar Requerimientos
H/T
▪Historias de usuarios
▪En los enfoques adaptativos, las historias de usuario son comúnmente el
método utilizado para representar los requisitos. Una historia de usuario
puede contener muchos requisitos.
▪Como <actor>, quiero poder <función>, de modo que pueda <razón
comercial>
▪Dada <condición previa (es)>, cuando <acción>, entonces <publicar
condiciones>
7.3 Definir y Elaborar Requerimientos
H/T
▪Cartera, Pila del producto (product backlog)
▪Es la lista de todos los elementos del producto, generalmente historias de
usuarios, requisitos o características, que deben entregarse para una
solución.
▪En la mayoría de los casos, los elementos de un trabajo acumulado se
escriben como historias de usuario y describen la funcionalidad que la
empresa o el cliente desean ver en el producto final.
7.3 Definir y Elaborar Requerimientos
H/T
▪Cartera, Pila del producto (product backlog)
▪El acrónimo DEEP (detallado adecuadamente, estimado, emergente y
priorizado) describe las características de un producto backlog
▪ Detallado adecuadamente. El nivel de detalle para describir una historia de usuario depende
de la prioridad de la historia. Cuanto más alta sea la prioridad, más detallada debe ser la
historia.
▪ Estimado. Los ítems de mayor prioridad deben tener estimaciones más precisas que los ítems
de menor prioridad.
▪ Emergente. Los trabajos pendientes son una lista en constante cambio de los elementos del
producto backlog. A medida que cambian las entradas, se descubre nueva información, o
cambian las prioridades, los elementos del producto backlog pueden agregarse, ajustarse,
eliminarse o reorganizarse.
▪ Priorizado Todos los elementos del producto backlog deben ser priorizados reflejando el valor
al negocio de la historia de usuario
7.3 Definir y Elaborar Requerimientos
Salidas
▪Requisitos y otra información del producto
▪Estos requisitos pueden ser de cualquier tipo: negocios, partes
interesadas, solución o transición. Los requisitos se pueden almacenar en
cualquier tipo de repositorio, como un trabajo pendiente, un documento
o una herramienta de administración de requisitos.
▪Además de los requisitos, otra información del producto que se
documenta como parte de este proceso incluye suposiciones,
dependencias, restricciones, problemas y riesgos.
7.4 Definir Criterios de Aceptación
▪Proceso de obtener un acuerdo sobre lo que constituiría
una prueba de que uno o más aspectos de una solución se
han desarrollado con éxito.
▪El beneficio clave de este proceso es que proporciona
información complementaria que puede ayudar a refinar los
requisitos al tiempo que proporciona la base de una
comprensión compartida de lo que se debe entregar.
7.4 Definir Criterios de Aceptación
▪Los criterios de aceptación son las condiciones que deben
cumplirse antes de que se acepte una solución.
▪Los criterios de aceptación se pueden crear en diferentes
niveles, incluidos los niveles de requisitos, iteración,
lanzamiento y producto.
7.4 Definir Criterios de Aceptación
7.4 Definir Criterios de Aceptación
Entradas
▪Enfoque de análisis
▪Modelos de análisis
▪Requisitos y otra información del producto
▪Enfoque de la evaluación de la solución.
7.4 Definir Criterios de Aceptación H/T
▪Desarrollo dirigido por el comportamiento (BDD)
▪Es un enfoque que sugiere que el equipo debe comenzar
por entender cómo el usuario usará un producto (su
comportamiento), escribir pruebas para ese
comportamiento y luego construir soluciones
▪Los criterios de aceptación generalmente se escriben como
"Dadas <las condiciones previas>, cuando <el usuario hace
algo dentro del producto>, entonces <la reacción del
producto>".
7.4 Definir Criterios de Aceptación H/T
▪Definición de "hecho" (DoD)
▪Es una serie de condiciones que todo el equipo se
compromete a completar antes de que un elemento se
considere lo suficientemente desarrollado como para ser
aceptado por las partes interesadas del negocio.
▪La definición de hecho para una historia o iteración de
usuario ayuda al equipo del proyecto a saber que el trabajo
está completo para que el equipo pueda pasar a la siguiente
historia o iteración del usuario.
7.4 Definir Criterios de Aceptación H/T
▪Definición de "hecho" (DoD)
▪Podría incluir elementos tales como:
▪Se cumplen los criterios de aceptación;
▪Los estándares de desarrollo, prueba y defecto están
conformes a
▪Se cumplen los requisitos no funcionales y de usabilidad
de alto nivel.
7.4 Definir Criterios de Aceptación H/T
▪Elaboración de historias
▪Proceso mediante el cual las historias de los usuarios se
complementan con información adicional de las
conversaciones con las partes interesadas de la empresa,
hasta que están lo suficientemente detalladas para que el
desarrollo del producto comience a funcionar.
7.4 Definir Criterios de Aceptación
Salidas
▪Criterios de aceptación
▪Son condiciones concretas y demostrables sobre un
elemento que deben cumplirse para que las partes
interesadas o los clientes comerciales acepten el elemento.
▪Esta salida puede tomar la forma de listas de criterios de
aceptación para cada historia de usuario en un enfoque
adaptativo, o puede ser una lista de criterios de aceptación
de nivel superior para una versión o solución en un enfoque
predictivo.
7.5 Verificar Requerimientos
▪Proceso de verificar que los requisitos son de suficiente
calidad.
▪El beneficio clave de este proceso es que aumenta la
probabilidad de que los requisitos se establezcan y/o se
comprendan de una manera que cumpla con los estándares
definidos para la organización, lo que, a su vez, permite la
comunicación de los requisitos a todas las partes
interesadas y contribuye a La calidad del producto final.
7.5 Verificar Requerimientos
7.5 Verificar Requerimientos Entradas
▪Enfoque de análisis.
▪Estándares organizativos de análisis de negocio.- Describa
cualquier característica de calidad esperada, reglas de formato,
reglas de sintaxis y estructura de requisitos impuestas por la
organización en todos los entregables de análisis de negocios.
▪Cumplimiento o normas reglamentarias.- son impuestas por
organizaciones externas, generalmente por razones relacionadas con
la seguridad, la protección de la información personal, las
consideraciones legales o las razones de seguridad. La mayoría de las
veces, son regulaciones del gobierno o de la industria.
▪Requisitos y otra información del producto
7.5 Verificar Requerimientos H/T
▪INVEST es un acrónimo de independiente, negociable, valioso,
estimable, pequeño y comprobable:
▪Independiente. La característica que rompe tantas dependencias entre
las historias de usuario como sea posible para que cualquier historia de
usuario pueda ser construida por sí misma en cualquier orden por el
equipo de desarrollo.
▪Negociable. La característica de las metodologías de adaptación que
garantiza que no se capture demasiada información por adelantado, ya
que todas las historias de usuario y los detalles que las rodean deben
ser negociables entre el equipo de desarrollo y las partes interesadas
del negocio hasta que se acepte una historia para el desarrollo.
7.5 Verificar Requerimientos H/T
▪Valioso.- Una característica en la que cada historia tiene valor para la
empresa o el cliente y la acumulación se clasifica según ese valor.
▪Estimable.- La característica que se compara con la característica
negociable para garantizar que las historias de los usuarios tengan
suficientes detalles para que el equipo de desarrollo proporcione una
estimación aproximada del tamaño.
▪Pequeña.- En el sentido adaptativo, pequeño significa que la historia es
lo suficientemente pequeña como para que el equipo de desarrollo la
complete dentro de una única iteración de caja de tiempo.
▪Comprobable.- La característica que determina si una historia puede ser
probada de manera definitiva por un equipo de prueba y si el cliente
entiende cómo aceptar el requisito final como está hecho.
7.5 Verificar Requerimientos H/T
▪Revisiones por pares
▪Implican a uno o más compañeros de trabajo que revisan el trabajo
realizado por el analista de negocios. Comúnmente, el par que
realiza la revisión es otro analista de negocios, líder de equipo o
miembro del equipo de control de calidad.
▪Tres tipos comunes de revisiones por pares, en orden de menor a
más formal, son los siguientes:
7.5 Verificar Requerimientos H/T
▪Revisiones por pares
▪Verificación de escritorio de compañeros. La comprobación de
escritorio es una forma de revisar cualquier lógica en un conjunto de
requisitos, modelos de análisis u otra información del producto y, a
menudo, implica trabajar a través de un ejemplo para verificar la
lógica.
▪Tutorial. Una revisión por pares en la que el autor de los materiales
guía a los revisores a través de la información del autor. Estas
revisiones a menudo se llevan a cabo utilizando una técnica de taller
de elicitación.
7.5 Verificar Requerimientos H/T
▪Revisiones por pares
▪Inspección. Una enfoque formal y riguroso de revisión en la que los
profesionales cercanos al trabajo (generalmente otros analistas de
negocios, desarrolladores, miembros del equipo de prueba o
miembros del equipo de calidad) inspeccionan el trabajo para
verificar que esté completo, sea coherente y se ajuste a los
estándares internos y externos. una lista de verificación
7.5 Verificar Requerimientos Salidas
▪Requisitos verificados y otra información sobre el producto
▪Incluyen información del producto que se ha evaluado para garantizar
que esté libre de errores y que aborda los estándares de calidad para los
que se guardará la información.
▪Los requisitos verificados no son una garantía de que esos mismos
requisitos aborden las necesidades comerciales. Los requisitos también
deben ser validados, priorizados y aprobados.
Bibliografía
▪Guide to Business Analysis. | PMI 2017