Index
Plan o Programa de estudios - Syllabus
- IQBBA
- ¿Por qué IQBBA?
- Problemática de los requerimientos
- International Software Testing Qualifications Board
- Áreas de conocimiento del análisis de negocio
- ¿Quién es el analista de negocio?
- Principales actividades de un BA
- Objetivos comunes del análisis de negocio
- Requirement (IEEE)
- Requirements elicitation (obtención de requerimientos)
- Traceability (trazabilidad)
- Artefactos
- Stakeholders - Identificación de las partes interesadas
- Análisis empresarial
- Procesos de negocios
- Identificación del proceso actual
- Metas de negocio
- SMART
- Necesidad comercial o de negocio
- Caso de negocio
- Alcance de la solución
- Técnicas para determinar el alcance de la solución
- Planificación de procesos de análisis empresarial
- Entregables del análisis de negocio
- ¿Qué factores considerar en la planificación de la comunicación?
- Proceso de gestión de requerimientos
- Herramienta de gestión de requerimientos
- Métodos de almacenamiento de seguimiento y actualización de requerimientos
Business Analyst
IQBBA
IQBBA proporciona un esquema de certificación que permite reunir los conocimientos y habilidades necesarios para mejorar su negocio.
IQBBA proporciona las siguientes habilidades:
- Análisis empresarial: comprenda los procesos comerciales realizados dentro de una organización, identifique el cambio necesario y prepare estudios de viabilidad junto con el análisis de riesgos.
- Análisis de negocio: identifique las necesidades de negocio y determine soluciones a los problemas comerciales.
- Mejora de procesos: optimiza el desempeño de una organización.
- Innovación, diseño y cliente: aplique técnicas modernas de innovación y diseño creativo para producir productos nuevos y competitivos.
¿Por qué IQBBA?
Al principio de cada proyecto de TI siempre existe una necesidad empresarial.
Mejorar o automatizar los procesos comerciales, extender la funcionalidad del sistema de software, abrir nuevos canales de acceso para los clientes: estos son ejemplos de varias necesidades comerciales que crean los cimientos de un proyecto de TI.
Cada necesidad empresarial debe explorarse, analizarse y convertirse en una solución.
Este es el campo para un analista de negocios. El éxito del proyecto depende de las habilidades y la experiencia del analista de negocios: para recopilar requerimientos concretos y modelar una solución, se necesitan competencias específicas.
Problemática de los requerimientos
Cuando el levantamineto de requerimientos no se hace de manera correcta, se genera una Problemática, la cual puede estar formada por varios de los siguientes problemas:
- Requerimientos de negocio ambiguos, poco claros, imposibles o contradictorios.
- Requerimientos inestables que cambian con frecuencia.
- Objetivos poco claros.
- No traducir correctamente los objetivos de negocio.
- Problemas de comunicación.
- Las barreras del idioma.
- Redacción vaga.
- Redundancia.
- Participación insuficiente del usuario.
- Grupos de usuarios desatendidos.
- Presión del tiempo.
- Enfoque exclusivo en resultados rápidos.
- Fijación exclusiva de costes.
- La documentación como coste, no como valor añadido
- No se conocen o no se comprenden los procesos de negocio:
- Requerimientos imprecisos
- Requerimientos ambiguos
- Requerimientos contradictorios
- Requerimientos que no cumplen los criterios acordados
- Requerimientos faltantes
- Los procesos y artefactos de negocio no están cubiertos por los requerimientos o se describen de manera incompleta.
- No todas las partes interesadas están identificadas.
Las soluciones podrían ser:
- Desarrollo de sistemas de software
- Desarrollo de componentes de software
- Extensiones de software existente
- Mejoras en el proceso empresarial
- Cambios en la organización
International Software Testing Qualifications Board
El Comité Internacional de Certificaciones de Pruebas de Software es una organización internacional sin fines de lucro, creada en noviembre de
2002,
en Edimburgo, y registrada legalmente en Bélgica,
basada en el trabajo voluntario de cientos de expertos en pruebas de software a nivel mundial.
Es responsable del esquema internacional de certificación profesional denominado "ISTQB Certified Tester" (Probador de Software Certificado del ISTQB).
Áreas de conocimiento del análisis de negocio
Un área de conocimiento es un grupo o conjunto de tareas, técnicas y mejores prácticas relacionadas.
Áreas de conocimiento del análisis de negocio:
- Análisis empresarial.
- Planificación y gestión de requerimientos.
- Obtención de requerimientos (identificación)
- Comunicación de requerimientos.
- Análisis y documentación de requerimientos.
- Evaluación y validación de soluciones
- Gestión de proyectos
- Alcance del proyecto
- Gestión del tiempo del proyecto
- Diseño
- Determina la arquitectura empresarial requerida
- Alcance de la solución
- Desarrollo
- Detemine las especificaciones de requerimientos detalladas utiliza el análisis comercial para determinar qué se debe implementar
- Pruebas y otras actividades de garantía de calidad
- Proporcionar el banco de pruebas con el que nos referimos a la base para las pruebas, la especificación de requerimientos es una base para la preparación y ejecución de casos de prueba, la especificación de requerimientos debe probarse para verificar su coherencia, integridad y cumplimiento de las normas.
¿Quién es el analista de negocio?
El Analista de Negocio o BA (Business Analyst) es la persona responsable de:
- Identificar las necesidades comerciales del cliente externo o interno
- Identificar partes interesadas (stakeholders)
- Determinar Soluciones a los problemas comerciales.
- Identificar, analizar, desarrollar y gestionar los requerimientos.
- Punto de contacto entre el cliente y otras partes interesadas.
- Identificar, negociar y consensuar las necesidades de los distintos individuos y grupos representativos.
- No es responsable de determinar la implementación de la solución
(crear el diseño del producto).
Ya que la solución se deriva de la información proporcionada por el trabajo de análisis empresarial que el analista de negocio realiza.
El rol del analista de negocios es:
- Ser un enlace entre las partes interesadas,
- Ser el responsable de la identificación, análisis, comunicación y validación de los requerimientos
Diferencias entre analista de negocios y analista de sistemas
El analista de sistemas esta más involucrado en la definición técnica de la solución.
El analista de negocio es responsable de documentar y recopilar los requerimientos de negocio.
El analista de negocio proporciona la información al analista de sistemas, quien es responsable de redactar los requerimientos técnicos a partir de los requerimientos comerciales, por lo que el rol del analista de sistemas es proveer un puente entre los requerimientos de negocio y la definición técnica de la solución de Tecnología de Información.
El analista de sistemas puede estar familiarizado con tecnologías de programación y debería tener conocimiento de la infraestructura de Tecnología de Información existente para poder adaptar la solución planificada al contexto.
El analista de sistemas es la persona que está involucrada en un análisis y diseño más técnico que realiza dicho trabajo en función de la información sobre los requerimientos comerciales proporcionada por el BA.
Los dos roles son complementarios y ambos roles son necesarios para un proyecto de Tecnología de Información exitoso.
Principales actividades de un BA
Las actividades principales de un analista de negocio son:
- Obtención de requerimientos.
- Análisis y modelización de requerimientos.
- Planificación de realización de requerimientos.
- Comunicación de requerimientos.
- Documentación de requerimientos.
- Validación de requerimientos.
- Gestión de la configuración de requerimientos.
- Propuesta de solución empresarial.
Objetivos comunes del análisis de negocio.
- Recopilar y documentar los requerimientos a nivel de negocio.
- Diseñar una solución comercial para resolver los problemas comerciales.
- Ayudar en la finalización oportuna del proyecto proporcionando requerimientos precisos, identificación y análisis.
- Mejorar la eficiencia aumentando la calidad de requerimientos, identificación y análisis y, por lo tanto, reduciendo la necesidad de reprocesos y arreglos en las etapas posteriores del proyecto.
- Fase de análisis.
- Fase de especificación.
- Fase de desarrollo.
- Fase de prueba.
- Identificación y evaluación los procesos comerciales actuales en una organización (as is).
- Recopilación de los requerimientos iniciales para la solución empresarial necesaria (to be)
- Creación y análisis del caso de negocio.
- Realización de un estudio de viabilidad.
- Preparación de ideas para la solución empresarial.
Lado del proveedor. El análisis empresarial suele iniciarse mediante el establecimiento de un presupuesto, acuerdo, asignación o proyecto.
Responsabilidades de BA durante la fase de especificación
- Identificar y documentar los requerimientos comerciales a un nivel más detallado.
- Apoyar al analista de sistemas en la preparación de las especificaciones detalladas del sistema.
- Validando, propuso el diseño de software con el cliente y otros stakeholders.
- Gestionar los cambios de requerimientos.
- Apoyar al equipo de desarrollo durante la implementación.
- Validar la solución en evolución de acuerdo con los requerimientos y necesidades previstos.
- Apoyar a los probadores en la preparación de casos de prueba y scripts de prueba a nivel empresarial y validar los productos de trabajo resultantes.
- Gestionar los cambios necesarios en los requerimientos.
- El rol de BA puede limitarse a verificar los resultados de las pruebas y resolver problemas relacionados con defectos o brechas en los requerimientos.
- Debería aumentarse el esfuerzo de BA.
- Participar en la preparación de casos de prueba para pruebas de aceptación de usuarios.
- Apoyar a los probadores de aceptación respondiendo preguntas durante la ejecución de la prueba.
Niveles de prueba que involucran al cliente.
El rol del analista de negocio en las diferentes fases será:
- Apoyar el trabajo de implementación.
- Pruebas de soporte.
- Analizar y documentar las solicitudes de cambio de los requerimientos.
- Tramitación de nuevos requerimientos.
- Tramitar las solicitudes para atender nuevas necesidades solicitadas por el cliente o usuario
Requirement (IEEE)
Requirement:
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2) [IEEE 610] .
(2) Una condición o capacidad que debe ser cumplida o poseída por un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otros documentos impuestos formalmente.
(3) Una representación documentada de una condición o capacidad como en (1) o (2) [IEEE 610]
Los requerimientos pueden ser:
- Obligatorios funcionalidad requerida o restricciones que debe tener
- Esenciales para que el software realice sus funciones
- Satisfacer las expectativas y necesidades de las partes interesadas previstas
- Requerimientos de negocio
- Requerimientos de usuario
- Requerimientos funcionales
- Requerimientos no funcionales
- Proporcionar una base para la evaluación, planificación, ejecución y seguimiento de las actividades del proyecto.
- Definir las expectativas del cliente.
- Servir como componente de acuerdos, pedidos, planes de proyectos.
- Establecer los límites del sistema, el alcance de la entrega y la clasificación de servicios de los requerimientos.
- Requerimientos de proceso. Describir las necesidades y limitaciones del proceso empresarial.
- Requerimientos del producto. Consiste en requerimientos de productos funcionales y no funcionales. Ambos pueden ser considerados desde el punto de vista del cliente (externo) y desde el punto de vista del equipo de proveedores (interno).
- Requerimientos del cliente (requerimientos comerciales)
- Requerimientos de la solución o del sistema
- Reajustes de productos o componentes
Requirements elicitation (obtención de requerimientos)
La obtención de requerimientos es la recopilación de actividades, enfoques, herramientas y técnicas para capturar los requerimientos de un sistema de software planificado (u otra solución comercial) de las partes interesadas.
Traceability (trazabilidad)
La trazabilidad es una asociación que existe entre diferentes tipos de requerimientos:
- Requerimientos de nivel superior a los requerimientos más detallados
- Requerimientos detallados para diseñar modelos
- Requerimientos detallados para probar casos (prueba del sistema)
- Requerimientos de alto nivel para casos de prueba (prueba de aceptación)
- Requerimientos para liberar / rama de código / versión
Para garantizar que se hayan cumplido todos los requerimientos comerciales.
Asegura que se haya alcanzado la cobertura de los requerimientos
Para determinar el impacto de un cambio en el sistema o proceso.
Artefactos
Los artefactos son productos de trabajo finales o intermedios que se producen y utilizan durante un proyecto.
Describen la función, arquitectura y diseño de software.
Se preocupan por el proceso de desarrollo en sí, como planes de proyecto, casos de negocio y evaluaciones de riesgos.
Los artefactos importantes para el proyecto deben estar bajo control de versiones y rastreados directamente hasta su origen.
Los fundamentos del analista de negocios se centran en las definiciones de los términos clave, como el análisis de negocios y un analista de negocios.
Stakeholders - Identificación de las partes interesadas
Una actividad principal o clave a ser completada es la identificación y análisis de las partes interesadas o stakeholders para la solución de negocio.
Es por ello que un analista de negocio debería conocer todos las personas y organizaciones que son afectadas o que tienen una relación directa o indirecta por la solución de negocio.
Stakeholder
Es cualquier persona involucrada o interesada en el proyecto.
Pueden ser individuos y organizaciones involucradas activamente en el proyecto o aquellos cuyos intereses pueden ser afectados como el resultado de la ejecución del proyecto o finalización del proyecto.
Las partes interesadas también pueden influir en los objetivos y resultados del proyecto.
Por ejemplo del lado de proveedor de soluciones podemos tener todo un equipo de personas involucradas en la creación y diseño de la solución, desde: Gerentes de proyecto, Analistas de negocio, Analistas de sistemas, Desarrolladores y Arquitectos, Diseñadores de bases de datos, Diseñadores de la Interfaz gráfica de usuario, Escritores técnicos, Testers, Personal de aseguramiento de calidad y hasta Personal de instalación y operaciones.
Por lo tanto tenemos personas involucradas en un proyecto.
Por el lado del Cliente tenemos: Representantes del negocio, Patrocinador de proyecto, Usuarios finales, Personal de instalación y operaciones.
Del lado de los partes interesadas externas podemos encontrar: Usuarios finales que son Clientes del cliente y otras organizaciones (como entidades regulatorias en banca por ejemplo).
Por lo que también tenemos personas afectadas por el proyecto.
¿Cómo identificar un Stakeholder?
Conociendo el proyecto. No avence mucho si no conoce, retroceda para poder avanzar.
Continuar sin entender genera problemas a medida que avanza el proyecto.
La identificación de las partes involucradas, interesadas o afectadas es importante, porque cada una tiene necesidades y limitaciones propias en relación a la solución de negocio.
La identificación de stakeholders es crítica para determinar el ámbito y alcance de los requerimientos de la solución.
Técnicas para la identificación de partes interesadas
Conozca el proyecto. Verifique que esta entendiendo el negocio, vuelva a preguntar si es necesario.
- Investigar el dominio del negocio (entender el proyecto) , conocer y consultar a los expertos en la materia (SME).
- Identificar a los propietarios de los procesos de negocio afectados por la solución (conocer los procesos afectados)
- Analizar la estructura de la organización del cliente, jerarquía, roles y personas en estos roles (conocer del organigrama donde se ubica el proyecto ).
- Conocer el mercado objetivo de la organización del cliente, es decir saber quienes son sus clientes.
- Analizar relaciones con organizaciones externas, con el fin de identificar stakeholders externos, como proveedores.
Problemas para la identificación de partes interesadas
Algunas de las causas por las cuales no se identifican stakeholders son:
- No estar entendiendo los procesos de la organizacion, es por eso que se debe contar y auxiliar de un diagrama de modelado de procesos de negocio.
- No contar con una definición clara de responsabilidades dentro de la organización del cliente
- Excluir a las partes interesadas que no están clara y directamente relacionadas con el proceso.
- Análisis incompletos que resultan en procesos y actividades faltantes y las partes interesadas relacionadas.
Ser empático con las necesidades y expectativas de las partes interesadas
-
Las partes interesadas pueden tener diferencias con respecto a la solución planificada.
Asegurese de justificar muy bien sus propuestas y recuerde que el Cliente es quien decide. -
Las funciones a implementar no deben entrar en conflicto con los requerimientos de otras partes interesadas.
Asegurese de conocer lo suficiente otros proyectos relacionados, siendo vital una buena comunicación. - Una actividad clave en el análisis empresarial es determinar el alcance inicial y requerimientos del proyecto.
- Esto a menudo se omite o se realiza solo parcialmente, lo que generalmente genera problemas a medida que avanza el proyecto.
- Ser capaz de explicar quién puede ser parte interesada en un proyecto.
- Explicar con ejemplos cómo se pueden identificar las partes interesadas.
- Describir cómo las necesidades de las diferentes partes interesadas pueden afectar el producto.
Análisis empresarial
Es la parte estratégica del ciclo de vida del proyecto y la fase inicial de Business Analyst.
Captura la visión futura del negocio para proporcionar contexto a los requerimientos del proyecto y al diseño de la solución.
Actividades de análisis empresarial.
- Determinar oportunidades de negocio.
- Desarrollar metas estratégicas.
- Comprender y desarrollar la arquitectura empresarial.
- Determinar la ruta óptima de inversión del proyecto.
- Elección de los enfoques de solución más adecuados para proyectos.
- Iniciar proyectos que aporten valor a las partes interesadas.
Es importante, ya que el Analista de Negocio debe tener un completo entendimiento de las metas estrategicas del cliente y las organizaciones del cliente y para garantizar que las nuevas iniciativas encajen en su estrategia o misión a largo plazo.
El Analista de Negocio debe tener conocimiento sobre los objetivos de la organización.
En grandes y complejas Organizaciones el Análisis Empresarial puede realizarse como un proyecto independiente.
En grandes y complejas Organizaciones el Análisis Empresarial, lo puede llevar a cabo la organización del cliente antes de involucrar al proveedor, y los resultados se proporcionan al proveedor como parte de los requerimientos iniciales.
O no se realiza en absoluto, si el objetivo del proyecto es claro y está definido de forma mensurable.
El Objetivo del Análisis Empresarial
Es identificar y describir a un alto nivel como objetivos comerciales, necesidades y expectativas de la organización, para las inversiones futuras.
Tareas del Análisis Empresarial
- Identificar los procesos de negocio realizados en la Organización
- Crear y mantener la Arquitectura de negocio
- Realizar estudios de viabilidad para determinar la solución empresarial óptima.
- Definir el alcance de la nueva oportunidad de negocio
- Preparar el Caso de negocio
- Realizar de la evaluación de riesgos inicial
- Preparar el paquete de decisiones
Procesos de negocios
Es un conjunto de actividades destinadas a producir un producto específico para un mercado de clientes en particular.
Se basa en como se hará el trabajo, actividades, relaciones y dependencias entre estas, para la Organización.
Un proceso puede ser considerado como el orden de actividades de trabajo a través del tiempo y lugar de inicio a fin y definir claramente las salidas, entregables o productos resultantes del trabajo que se va realizado.
Características de un proceso de negocio
Tienen: un objetivo, entradas específicas, salidas específicas y usa recursos.
Tienen un número ordenado de actividades, afecta al menos una unidad organizacional para crear un valor para el cliente.
Identificación del proceso actual
Identificar el proceso actual permite al Analista de Negocio entender las metas organizacionales.
Determinar las actividades y el flujo requerido para lograr los objetivos estratégicos y comerciales planificados para el futuro.
Ayudar a encontrar posibles desperdicios y partes ineficaces del proceso, que luego se puede mejorar mediante la optimización del proceso.
Si los procesos de negocio no están establecidos y comprendidos, entonces la organización puede tener un bajo nivel de madurez, lo que dificulta mucho medir y confrontar los procesos.
Metas de negocio
Una meta comercial es un objetivo a corto o largo plazo de una organización.
Se caracterizan por las siguientes cualidades:
- Especificidad
- Optimismo
- Realismo
- Alcance tanto a corto como a largo plazo
Para tener una visión de lo que la organización quiere realizar, para tener metas claramente establecidas y para establecer períodos en los cuales necesitan ser alcanzadas.
Para tener una imagen clara de lo que la organización esta tratando de hacer con el negocio y ayuda a enfocar la motivación.
Las metas permiten a la organización comprender y mantener un compromiso con los principales objetivos del negocio.
Proporcionan una métrica con la que medir el progreso de la organización.
Las metas pueden reflejar cambios que la organización quiere lograr o las condiciones actuales que la organización busca mantener.
Las metas tienden a ser declaraciones cualitativas de un estado o condición que la organización busca establecer o mantener.
Los objetivos de alto nivel se pueden descomponer para dividir una estrategia general en distintos puntos de enfoque que pueden conducir a los resultados deseados, como una mayor satisfacción del cliente, excelencia operativa o crecimiento empresarial.
Los verbos empleados en el establecimiento de metas suelen ser acciones a realizar como: crear, mejorar, incrementar, cumplir, reducir, etc. para
SMART
SMART es un sistema y herramienta usada para establacer metas y definir objetivos de calidad
El significado del acrónimo es:
- Specific. Específica, debe ser clara, no debe ser general
- Measurable. Mensurable, debe ser medible
- Attainable. Alcanzable, debe ser viable y poder lograrse
- Relevant. Relevante, debe ser adecuada
- Timely. Oportuna, debe realizarse en circunstancias o un buen momento para producir el efecto deseado.
Necesidad comercial o de negocio
Describe el problema u oportunidad de negocio que el Analista de negocio debe entender y analizar para recomendar soluciones adecuadas
Como Analista de negocio asegure que la Necesidad comercial y Caso de negocio sean definidas.
Estas definiciones deben hacerse para garantizar la selección adecuada de proyectos y para establecer las prioridades adecuadas para los proyectos que ayudan a la organización a alcanzar su visión, metas estratégicas y objetivos comerciales.
¿Quién debería definir las necesidades comerciales?
La persona o grupo que solicita el proyecto, pudiendo ser:
- Patrocinador
- Comité Directivo
- Órgano regulador o de cumplimiento
- Experto en la materia de alto nivel
Valor para las partes interesadas
Valor es el beneficio que creemos que obtenemos de algo.
Determinar el valor para los stakeholders es uno de los factores clase para el éxito del proyecto.
La meta principal de un proyecto siempre debería ser lograr el beneficio para los stakeholders.
Caso de negocio
Proporciona el razonamiento para iniciar un proyecto.
Describe una justificación para el proyecto en términos del valor agregado versus el costo de desarrollar la nueva solución.
El análisis de costo-beneficio del caso de negocio compara los costos de implementar una solución con los beneficios que se obtendrán con esa solución.
El caso de negocio se puede presentar en forma de documento estructurado. Sin embargo, también puede expresarse como un breve argumento o presentación.
¿Qué puede cubrir el Caso de negocio?
- Información sobre la oportunidad o problema
- Beneficios cuantitativos y cualitativa
- Estimaciones de costo y tiempo
- Expectativas de beneficios
- Seguimiento de oportunidades
- Flujo de efectivo de la acción a lo largo del tiempo
- El impacto del proyecto propuesto en las operaciones o procesos comerciales.
- El impacto del proyecto propuesto en tecnología o infraestructura
- Restricciones asociadas con el proyecto propuesto
- Costo estimado
- Alineación con las prioridades establecidas
Atributos de calidad de un Caso de negocio
- Adaptable, se ajusta al tamaño y riesgo de la propuesta
- Consistente, cada proyecto aborda los mismos problemas comerciales básicos
- Orientado al negocio, debe centrarse en las capacidades y el impacto del negocio.
- Integral, considera todos los factores relevantes para una evaluación completa.
- Comprensible, el contenido del caso de negocio debe ser claro y lógico.
- Mensurable, los aspectos clave se pueden cuantificar.
- Transparente, los elementos clave se pueden justificar.
- Responsable, los compromisos para la entrega de beneficios y la gestión de costos son muy claros.
- Identifica y cuantificar los beneficios
- Identificar y cuantificar los costos.
- Preparar el caso de negocio.
- Definir los procedimientos que se utilizarán para medir los costos y beneficios.
- Permite a la organización comprender y aplicar una forma de pensar que permite a los tomadores de decisiones analizar el valor de riesgo y la prioridad de una propuesta de proyecto.
- Justifica el valor de las propuestas para la organización y ayuda a rechazar cualquier propuesta que no tenga un valor comprobado y medible.
- Decidir si la propuesta es de valor para el negocio y se puede lograr en comparación con propuestas alternativas.
- Seguimiento y medición del progreso y los logros del caso de negocio.
- Asegurar que los proyectos con interdependencias se lleven a cabo en la secuencia óptima.
- Resumen Ejecutivo
- Introducción
- Enfoque
- Criterios de selección clave
- Descripción de la alternativa preferida
- Plan de gestión de Riesgos
- Conclusión y Recomendaciones
Alcance de la solución
Conjunto de capacidades que una solución debe ofrecer para satisfacer las necesidades comerciales.
¿Por qué es necesario conocer el alcance?
Definir el alcance de la solución es una base para establecer el alcance del proyecto (planificación del proyecto) y para el desarrollo de requerimientos detallados adicionales.
El alcance de la solución significa el trabajo que debe realizarse para entregar un producto, servicio o resultado con las características y funciones especificadas.
Definición y planeación del alcance de la solución
El alcance de la solución define las capacidades que la solución debe ofrecer para abordar la necesidad empresarial.
Si bien el alcance del proyecto define el trabajo a realizar para entregar las funciones o servicios especificados, parte de la definición del alcance del proyecto es estimar el costo y el tiempo.
El costo y tiempo usualmente es determinado por el Gerente de proyecto.
No planear bien el alcance del proyecto incrementa el riesgo del fracaso del mismo ocasionando: retrasos, exceso de presupuesto o entrega incompleta.
Técnicas para determinar el alcance de la solución
Work breakdown structure - WBS
Estructura de desglose del trabajo, es la descomposición del trabajo que se requiere para completar un proyecto y lograr los objetivos comerciales.
Product breakdown structure - PBS
Estructura de desglose del producto, es la descomposición de los componentes del producto
Análisis de la interfaz del sistema
Es una definición del trabajo necesario para integrar la nueva solución en los entornos comerciales y técnicos existentes.
El alcance de la solución define lo que se debe entregar para satisfacer las necesidades comerciales.
Esto puede incluir las principales características y funciones que se incluirán, lo que se excluye del alcance.
El alcance de la solución generalmente se presenta como una descomposición de los componentes requeridos para que funcione y todas las interacciones e integraciones involucradas.
Planificación de procesos de análisis empresarial
El análisis empresarial es el punto de partida para diseñar e implementar una solución a una necesidad empresarial.
Cada uno de los entregable del análisis de negocio son entradas a otras fases y procesos del proyecto, los cuales establecen la Arquitectura del Sistema, los cuales permiten:
- Establecer los objetivos comerciales.
- Crear especificaciones detalladas funcionales y complementarias (no funcionales) del sistema.
- Planificar y ejecutar actividades de QA quality assurance ( aseguramiento de la calidad).
- Gestión del proyecto, en cuanto planeación del alcance, calendarización o Planificación, estimación de desarrollo y pruebas (Rol: Gerente de proyecto).
- Análisis de sistemas (Rol: analistas de sistemas, Programadores)
- Diseño, especificación y arquitectura del sistema (Rol: Arquitectos de sistemas)
- Implementación (Rol: DevOps) y
- Pruebas (Rol: Testers)
Entregables del análisis de negocio
Un entregable es cualquier producto de trabajo que debe entregarse a alguien que no sea el autor de los productos de trabajo.
Ejemplos de entregables importantes son:
- Requerimientos de negocio. Descripción de metas y objetivos comerciales, así como resultados que describen por qué se ha iniciado un cambio y cómo se evaluará el éxito.
- Listado de stakaholders del proyecto (involucrados o con un interes en el proyecto)
- Limitaciones y supuestos. Una suposición es cualquier factor de influencia que se cree que es cierto pero que no se ha confirmado que sea exacto o que podría ser cierto ahora pero que puede no seguir siendo cierto en el futuro.
- Definición de flujo de proceso empresarial
- Definición de productos de procesos de negocio
- Definir cómo recibir, distribuir, acceder, actualizar y escalar información hacia y desde las partes interesadas del proyecto.
- Definir cómo organizar el cronograma y la estructura de la comunicación dentro del proyecto.
- Las actividades y los productos finales del análisis empresarial se pueden comunicar de forma formal e informal.
- Talleres (workshops)
- Presentaciones, que pueden ser formales o informales
- Revisiones, formales o informales
¿Qué factores considerar en la planificación de la comunicación?
- Tipo de proyecto. No es lo mismo, el tipo de proyecto indica diferentes procesos y entregables
- Formalidad de comunicación. No es la misma formalidad en todos los proyectos, fases y stakeholders por ejemplo será más formal en un proyecto grande, complejo, critico, estrategico o es dependiente de la legislación, estandares del sector o acuerdos. Tal vez simplemente algunos stakeholders exijan una comunicación formal sin importar el tipo de proyecto.
- Frecuencia de comunicación. Es distinta entre las partes interesadas para cada forma de comunicación.
- Localización geográfica. Tener en cuenta la zona horaria y su complejidad al poder impactar las estimaciones de actividades y tareas.
- Cultura. Puede encontrar barreras como el lenguaje y forma de conducirse
Proceso de gestión de requerimientos
La gestión de requerimientos es un proceso continuo de documentación, análisis y seguimiento.
Priorizar la comunicación, acordar los requerimientos y gestionar los cambios.
Es necesario tener procesos para el control de cambios, definición de atributos y trazabilidad de los requerimientos.
¿Qué hace el Analista de negocio en el Proceso de gestión de requerimientos?
Planifica todo el proceso de gestión de requerimientos, desde la ingeniería de requerimientos hasta el control de cambios y aseguramiento de calidad.
El proceso comienza con la definición de la estrategia de ingeniería de requerimientos adecuada, incluida la planificación y la estimación del trabajo para un proyecto u organización específicos, la estrategia determina las principales actividades y roles utilizados en el proceso.
¿Qué implica el Proceso de gestión de requerimientos
- La planificación, la ejecución, el seguimiento y el control de todo o parte del trabajo asociado con la obtención de requerimientos
- La colaboración, el análisis y el diseño de los requerimientos.
- La gestión del ciclo de vida de los requerimientos.
El plan del proceso de gestión de requerimientos es un subconjunto del Plan de análisis empresarial para un proyecto específico.
Describe herramientas, actividades, roles y responsabilidades específicos que se utilizarán en el proyecto para gestionar los requerimientos.
Herramienta de gestión de requerimientos
El plan de gestión de requerimientos puede incluir la selección de una herramienta de gestión de requerimientos tales como herramientas software de propósito especial para proporcionar soporte para cualquier combinación de las siguientes actividades de gestión de requerimientos:
- Obtención y colaboración
- Modelado y / o especificación de requerimientos.
- Trazabilidad de requerimientos.
- Control de versiones y líneas de base
- Definición de atributos para seguimiento y monitoreo
- Control de cambios de requerimientos.
- Identificación de requerimientos donde se registran
- Análisis de requerimientos donde se especifican
- Especificación de requerimientos donde se documentan
- Cambios de requerimientos donde se rastrean y actualizan
- Aseguramiento de la calidad de requerimientos donde se asegura la adherencia al proceso.
- Enfoque de análisis empresarial, cuales son los procesos de análisis y gestión de requerimientos
- Plan de análisis empresarial, define los entregables
- Activos del Procesos organizacionales, conjunto de plantillas estándar o pautas para los procesos existentes en la organización. Pueden ser útiles para definir el enfoque de análisis ya que incluyen: Metodologías para el proceso de cambio o desarrollo de software. Herramientas o técnicas estandares, plantillas para entregables, etc.
Métodos de almacenamiento, seguimiento y actualización de requerimientos
La gestión de requerimientos es un proceso continuo de documentación, análisis, seguimiento, priorización, comunicación, acuerdo sobre requerimientos y gestión de cambios de requerimientos.
Así como establecer métodos de almacenamiento, seguimiento y actualización de requerimientos.
- Esto es con un repositorio de requerimientos que debe usarse para almacenar todos los requerimientos y su estado respectivo.
- El estado (en pogreso, en revisión, modificado o aprobado) de cada requisito debe registrarse en el repositorio.
- El repositorio puede ser una sola herramienta o un conjunto de herramientas.
- Será eficaz, el repositorio que tenga un flujo de trabajo adecuado para los requerimientos a medida que avanzan en el ciclo de vida. Por lo que las partes interesadas autorizadas deberían poder agregar, actualizar y eliminar requerimientos.
- Definir un proceso para rastrear o dar seguimiento a los requerimientos
- El proceso de seguimiento debe adaptarse a la complejidad del dominio del proyecto, las necesidades de las partes interesadas, los riesgos potenciales y los recursos disponibles.
- A cada requerimiento se le deben asignar atributos (valor de la funcionalidad para el cliente, tamaño, dificultad, etc.). Los atributos de requerimientos personalizados permiten que el BA incluya información de clasificación más detallada para los requerimientos, permitiendo informes y análisis basados en estos atributos.
- Los atributos deben planificarse y definirse en la fase de obtención o solicitud de requerimientos.
- No todos los requisitos tienen la misma importancia para las partes interesadas y no tienen el mismo valor para el éxito del proyecto.
- La prioridad como factor de importancia e impacto debe ser determinada por el BA y las partes interesadas adecuadas durante la fase de obtención de requerimientos, esta prioridad puede actualizarse a lo largo de la vida del proyecto.
¿Qué hace el analista de negocio?
Ws esencial para que las partes interesadas tengan un entendimiento común de los requerimientos.
Se puede realizar de diversas formas, incluso mediante conversaciones, notas, documentos, presentaciones y debates.
La comunicación efectiva apropiada y concisa requiere que el BA posea un conjunto significativo de habilidades o competencias.
¿Qué factores afectan las actividades de comunicación de requerimientos?
- Cultura organizacional. Las creencias, valores y normas compartidas por los miembros de las organizaciones, pueden variar ampliamente en cuán formales o informales son, lo cual es un desafío para el BA si la información es demasiado informal amenazando el éxito del proyecto y es posible que los acuerdos sobre esos requerimientos no se documenten adecuadamente o no se comuniquen bien, pero también una comunicación demasiado formal puede impedir el flujo eficiente de información.
- Estándares organizacionales. Es posible que existan pautas vigentes, especialmente si se trata de una organización más grande o más madura que tiene experiencia en proyectos anteriores.
- Preferencias de los stakeholders.
Algunas partes interesadas requieren más y algunas partes interesadas requieren menos formalidad.
Será necesario recomendar el enfoque más apropiado para manejar los requerimientos y señalar los riesgos e impactos según sea necesario para negociar un enfoque apropiado para manejar los requerimientos. - Complejidad.
La complejidad del proyecto o la complejidad de los productos o servicios
que se están desarrollando es más probable que los procesos sean formales.
Los productos que se construyen con muchos componentes o subcomponentes tendrán interfaces más complejas y es posible que también tenga complejidad con productos o servicios que son utilizados por un gran número o una gran variedad de partes interesadas. - Madurez organizacional.
Una organización menos madura
no va a querer gastar tiempo y dinero en la creación de un proceso de requerimientos
e incluso puede ser una resistencia absoluta a tener un proceso formal para definir
y gestionar los requerimientos.
La cultura organizacional debe tenerse en cuenta al determinar la formalidad de la comunicación, el BA debe determinar si los requerimientos se entregarán como documentación formal o mediante una comunicación más informal con las partes interesadas así como el nivel apropiado de detalle que debe estar contenido en cualquier documento.