lunes, 6 de marzo de 2017

Software Architecture in Practice: Parte 2-2: Disponibilidad (Availability)

Esta entrada nace como un aproximación a la asignatura de Arquitectura de Software de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

El objetivo de esta entrada dar a conocer apartes, síntesis y opiniones acerca del libro Software Architecture in Practice.


Parte 2-2: Disponibilidad (Availability)

Definición.
La disponibilidad de un sistema de información se puede definir como la propiedad que exhibe un sistema para estar siempre listo para desempeñar sus funcionalidades, en el momento que se le necesite. Especialmente, después que se hayan manifestado fallos.

Este atributo de calidad esta fuertemente relacionado con la Confiabilidad (Reliability) y con la Recuperabilidad (Recoverabilityde un sistema.

De hecho, la disponibilidad se puede definir como:


Disponibilidad = Confiabilidad + Recuperabilidad

En esencia, la disponibilidad de un sistema consiste en la implementación de mecanismos que permitan minimizar el tiempo fuera de servicio de un sistema, mediante la mitigación de fallos.

El objetivo es lograr tiempos de disponibilidad similares a los mostrados en la siguiente tabla:



Estos fallos pueden ser prevenidos, tolerados, eliminados, etc. Estos fallos deben ser identificados por el sistema con el fin de que este pueda reaccionar de alguna manera. La reacción deseada dependerá de la criticidad del sistema.


Escenarios de Calidad.
Los escenarios de calidad para la Disponibilidad se definen así:
  • Fuente del Estimulo: Pueden ser interno o externos.
  • Estimulo: Es un fallo de alguna de estas categorías:
    • Omisión: Un componente no responde a una entrada.
    • CrashUn componente sufre repetidas veces fallos de omisión.
    • Sincronización: Un componente responde a una entrada correctamente, pero lo hace en un tiempo muy temprano o muy tarde.
    • Respuesta: Un componente responde a una entrada de forma errónea.
  • Ambiente: El estado del sistema cuando el fallo ocurre, condiciona la respuesta esperada del escenario. No es lo mismo reaccionar cuando sucede el primer fallo, que cuando el sistema ya esta operando en modo degradado.
  • Artefacto: Especifica el recurso o componente del cual se requiere la disponibilidad. 
  • Respuesta: Reacciones al fallo en el sistema:
    • El fallo debe ser identificado y correlacionado.
    • El sistema debe poder recuperarse del fallo.
      • Registrar el fallo
      • Notificaciones a usuarios especiales
      • Limitar el uso de funciones o capacidad
  • Medida de la Respuesta: Las medidas disponibles son:
    • Porcentaje de Disponibilidad
    • Tiempo para detectar la falla
    • Tiempo para reparar la falla
    • etc

Ejemplo de un escenario de calidad:



Tácticas para la Disponibilidad.
Las tácticas para la Disponibilidad se categorizan en:
  • Detección de Fallos: Estas tácticas, básicamente buscan detectar señales de vida de los diferentes componentes críticos del sistema. Aquellos componentes cuyo mal funcionamiento implica directamente el mal funcionamiento del sistema, son los objetivos de estas tácticas.
  • Recuperación de Fallos: Estas tácticas combinan los mecanismos para reintentar la operación y/o el mantener lógica y datos redundantes.
  • Prevención de Fallos: Estas tácticas dependen de mecanismos para remover los elementos con fallo de servicio o de mecanismos para limitar el alcance de los fallos.

El listado de tácticas de cada una de estas categorías, se pueden ver en el siguiente árbol:


Todas estas tácticas de Disponibilidad son Tácticas de Coordinación de Elementos. Esto implica que la forma en la cual el sistema de información es construido (implantado y/o desarrollado) facilitara o no la implementan de estas tácticas.










    lunes, 12 de octubre de 2015

    Software Architecture in Practice: Parte 2-1: Atributos de Calidad

    Esta entrada nace como un aproximación a la asignatura de Arquitectura de Software de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

    El objetivo de esta entrada dar a conocer apartes, síntesis y opiniones acerca del libro Software Architecture in Practice.


    Parte 2-1: Atributos de Calidad

    La Arquitectura y los Requerimientos.
    Sin importar la fuente, todos los requerimientos se pueden tipificar en:

    • Requerimientos Funcionales: Definen lo que el sistema debe hacer; y como debe comportarse o reaccionar ante estímulos durante el tiempo de ejecución.
    • Atributos de Calidad: Son el nivel de calidad (medible o testeable) que debe presentar un requerimiento funcional.
    • Restricciones: Son decisiones de diseño con ningún grado de libertad. Es una decisión de diseño que ya ha sido tomada.

    La Arquitectura responde a cada uno de estos tipos de requerimientos así:

    • Requerimientos Funcionales: La Arquitectura satisface estos requerimientos al asignar las responsabilidades apropiadas a cada elemento de arquitectura.
    • Atributos de Calidad: La Arquitectura satisface estos requerimientos diseñar las diferentes estructuras, comportamientos y elementos de arquitectura.
    • Restricciones: La Arquitectura satisface estos requerimientos al aceptar las decisiones de diseño ya tomadas; e incorporarlas al diseño y asignación de responsabilidades de las diferentes estructuras, comportamientos y elementos de dicha arquitectura.


    Definición de Atributos de Calidad.
    Un Atributo de Calidad es una propiedad medible o testeable de un sistema, que es usado para indicar el nivel de satisfacción que el sistema tiene, respecto a las necesidades de los stakeholders.

    Los atributos de calidad se pueden dividir en aquellos que describen una propiedad del sistema en tiempo de ejecución (desempeño, disponibilidad, etc) y aquellos que describen una propiedad del desarrollo de dicho sistema (modificabilidad y testeabilidad).

    Escenarios de Calidad.
    Los atributos de calidad se especifican mediante Escenarios de Calidad (o Escenarios de Atributos de Calidad). Un escenario de calidad consta de 6 partes:

    • Fuente del Estimulo: Entidad que genera el estimulo. Ej: Un Usuario o Un Sistema de Información.
    • Estimulo: Condición que requiere de una respuesta cuando este llega al sistema.
    • Ambiente: Contexto (u condiciones) bajo los cuales ocurren los estímulos. Ej: Sistema sobrecargado u operación normal, etc.
    • Artefacto: Componente o componentes, que son afectados por el estimulo.
    • Respuesta: Actividad que nace como resultado del estimulo llega al sistema.
    • Medida de la Respuesta: Medida contra la cual se evaluara y testeara la respuesta al estimulo.

    Tácticas de Arquitectura.
    Una Táctica de Arquitectura es una decisión de diseño que afecta la respuesta de un atributo de calidad. Una táctica se focaliza en una única respuesta de atributo de calidad.

    Un Patrón de Arquitectura puede ser considerado como un conjunto de Tácticas de Arquitectura que afectan las respuestas de diferentes Atributos de Calidad.

    Las tácticas de arquitectura de puede clasificar así:

    • Tácticas de Asignación de Responsabilidades. Por ejemplo:
      • Identificar las responsabilidades mas importantes.
      • Determinar como estas responsabilidades serán asignadas a elementos en tiempo de ejecución (módulos, componentes, conectores, etc); y cuales serán asignadas a elementos de infraestructura (servidores, bases de datos, etc).
    • Tácticas de Coordinación de Elementos. Por ejemplo:
      • Identificar los elementos de arquitectura que deberán coordinarse; y cuales no deberán coordinarse.
      • Determinar las características de la coordinación: Concurrencia, tiempos, consistencia, etc.
    • Tácticas de Modelado de Datos. Por ejemplo:
      • Selección de las abstracciones para los datos mas relevantes; sus operaciones y propiedades. Se debe determinar como los datos serán creados, inicializados, accedidos, almacenados, actualizados, transformados y eliminados.
      • Definición de la metadata necesaria para la correcta interpretación de los datos.
      • Organización de los datos en una base de datos relacional, no relacional y/o sistema de archivos.
    • Tácticas de Gestión de Recursos. Por ejemplo:
      • Identificar los recursos (CPU, RAM, Disco Duro, Pool de Conexiones, Pool de Hilos, etc) que deben ser gestionados; y determinar los limites de cada uno.
      • Determinar que elementos del sistema gestionara cada recurso.
      • Determinar como los recursos serán compartidos.
      • Determinar el impacto en el sistema cuando los recursos estén saturados.
    • Tácticas de Mapeado de los Elementos de Arquitectura. Por ejemplo:
      • Mapear los módulos y los componentes (y conectores) entre si. Es decir, determinar que componentes son creados en que modulo.
      • Mapear los componentes (y conectores) al hardware que los procesara.
      • Mapear los datos y el modelo de datos, a lo repositorios de almacenamiento de datos.
      • Mapear los módulos y componentes (y conectores) a las unidades de despliegue.
    • Tácticas de Asignación de Atributos*. Por ejemplo: [Pendiente].
    • Tácticas de Selección de Tecnologías. Por ejemplo:
      • Determinar que tecnologías están disponibles para satisfaces las decisiones tomadas en las otras tácticas.
      • Determinar si que herramientas están disponibles para soportar las tecnologías seleccionadas.
      • Determinar los efectos secundarios de las tecnologías seleccionadas.
      • Determinar si las tecnologías seleccionadas son compatibles entre si y con las restricciones de diseño.


    jueves, 8 de octubre de 2015

    Software Architecture in Practice: Parte 1: Introducción

    Esta entrada nace como un aproximación a la asignatura de Arquitectura de Software de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

    El objetivo de esta entrada dar a conocer apartes, síntesis y opiniones acerca del libro Software Architecture in Practice.


    Parte 1: Introducción

    Definición de Arquitectura de Software.
    La definición de arquitectura de software que maneja el libro es:
    La arquitectura de software de un sistema es un conjunto de estructuras requeridas para razonar o entender acerca del sistema, las cuales comprenden elementos de software, las relaciones entre ellos, y las propiedades de las dos (los elementos y las relaciones).
    Estructuras y Vistas.
    Para razonar o entender la arquitectura de un sistema de software, se hacen uso de los conceptos de estructuras y vistas.
    • Una estructura es el conjunto de elementos de software, las relaciones entre ellos, y las propiedades de las dos (los elementos y las relaciones).
    • Una vista es la representación coherente (comprensible) de un conjunto de estructuras de software acorde aun conjunto (o subconjunto) de stakeholders. 


    El libro define 3 tipos de estructuras de software, así:
    • Estructuras de Módulos: muestran como un sistema esta estructurado en función de un conjunto de unidades de código y/o datos.
      • Estructura de Descomposición: Se muestra la descomposición de cada módulo en submódulos.
      • Estructura de Uso: Se muestra la relación de uso entre los módulos.
      • Estructura por Capas: Aquí los módulos son llamados Capas. Una capa provee de una serie de servicios a través de una interfaz claramente definida. Se muestra la relación de los módulos mediante una estructura por capas.
      • Estructura de Generalización/Especialización: Aquí los módulos son llamadas Clases. Se muestra la relación de herencia e implementación entre clases e interfaces.
      • Estructura de Datos: Aquí se muestra las estructuras estáticas de los datos en términos de entidades de datos y sus relaciones.

    • Estructuras de Componentes y Conectores: muestran como el sistema esta estructurado en función de los elementos que tienen un comportamiento en tiempo de ejecución (componentes) y sus relaciones (conectores).
      • Estructura de Servicios:  Aquí los componentes son llamados Servicios. Se muestra la interoperabilidad entre los servicios mediante mecanismos de coreografía y/o orquestación.
      • Estructura de Concurrencia: Aquí los conectores son llamados Mecanismos de Comunicación. Se muestra los detalles de procesamiento en paralelo de los componentes y los mecanismos de comunicación entre estos para su coordinación.

    • Estructuras de Asignación: muestran como el sistema se relaciona con su ambiente (servidores, redes, equipos de desarrollo, etc). 
      • Estructura de Despliegue: Se muestra como los componentes de software están asignados elementos puntuales de hardware de procesamiento y comunicación.
      • Estructura de Implementación: Se muestra como los módulos son mapeados a la estructura de archivos (o carpetas) en los ambientes de desarrollo, pruebas y producción.
      • Estructura de Asignación de Trabajo: Se muestran la distribución y asignación de trabajo de los módulos al equipo de trabajo.


    Patrones de Arquitectura.
    Un Elemento de Arquitectura se puede definir como un Modulo o como un Componente o como un Conector, dependiendo del tipo de estructura del que estemos hablando.

    Tomando en cuenta esto, se define un Patrón de Arquitectura a un composición puntual de elementos de arquitectura que soluciona un problema en particular y que dicha composición ha resultado ser útil y valida a través del tiempo.

    Un Patrón de Arquitectura define los tipos de elementos de arquitectura que se usaran y la forma en que se ínter-relacionaran entre si para resolver el problema que pretender solucionar.

    Ejemplos de Patrones para las Estructuras de Módulos:
    • Patrón por Capas: En este patrón la relación de uso entre los elementos de arquitectura es estrictamente unidireccional. En una estructura estricta por capas, una capa solo puede hacer uso de los servicios expuestos por la capa inmediatamente inferior. Nunca una capa podrá hacer uso de los servicios expuestos por capas superiores.

    Ejemplos de Patrones para las Estructuras de Componentes y Conectores:
    • Patrón de Repositorio de Datos: Este patrón contempla componentes y conectores que pueden crear, almacenar y acceder datos persistentes.
    • Patrón Cliente Servidor: En este patrón los componentes son los clientes y los servidores; y los conectores son los protocolos de comunicación y mensajes entre estos.

    Ejemplos de Patrones para las Estructuras de Asignación:
    • Patrón Multinivel: En este patrón se describe como se distribuyen y se asignan los componentes de un sistema en subconjuntos de hardware y software; conectados mediante algún mecanismo de comunicación.


    Importancia de la Arquitectura de Software.

    La arquitectura de software es importante por una variedad de razones tanto técnicas como no técnicas. Algunas de ellas son:
    1. Una Arquitectura habilitara o deshabilitara atributos de calidad específicos para un sistema.
    2. Las decisiones realizadas por la Arquitectura permiten que se razone (entender) acerca del sistema y manejar el cambio que este deberá tener en el tiempo.
    3. En análisis de una Arquitectura permite la predicción temprana de los atributos de calidad de un sistema.
    4. Una Arquitectura documentada mejora la comunicación entre los stakeholders.
    5. La Arquitectura se encarga de definir y tomar, de manera temprana, las decisiones de diseño mas difíciles de cambiar en el tiempo.
    6. La Arquitectura restringe el diseño y el desarrollo del sistema.
    7. La Arquitectura define la organización del equipo de trabajo y viceversa.
    8. La Arquitectura provee las bases para el prototipado evolutivo.
    9. La Arquitectura provee de los artefactos clave para la definición del costo y cronograma del proyecto.
    10. Una Arquitectura puede ser reutilizada de tal forma que se convierte en la base de las lineas de productos.
    11. La Arquitectura canaliza y restringe la creatividad de los desarrolladores, y la complejidad del diseño.
    12. La Arquitectura es la base para el entrenamiento de nuevos miembros del equipo de desarrollo y del proyecto.

    Los Contextos que influencian la Arquitectura de Software.
    Acorde al libro los contextos en los que esta enmarcada la Arquitectura de Software son:
    • Contexto Técnico: Cual es el rol técnico que juega la Arquitectura en el sistema o sistemas en los que hace parte? El rol técnico que juega la Arquitectura se puede simplificar en:
      • La Arquitectura habilitara o deshabilitara atributos de calidad específicos para un sistema.
      • La Arquitectura estará limitada por el ambiente técnico que exista en la organización al momento en el cual estará siendo diseñada.

    • Contexto del Ciclo de Vida del Proyecto: Como la Arquitectura de Software se relaciona con las fases del ciclo de vida del desarrollo de software, del proyecto y del producto?. Sin importar de la metodología de desarrollo de software que se este usando (Cascada, Iterativo, Agile, Model Driven Development), el Arquitectuoa debe definir:
      • La justificación técnica de la Arquitectura del proyecto en base a los requerimientos de negocio.
      • Identificar los Requerimientos de Negocio Arquitecturalmente significativos.
      • Crear y/o seleccionar la Arquitectura, documentarla y comunicarla.
      • Analizar o Evaluar la Arquitectura.
      • Implementar y Probar el sistema en base a la Arquitectura.
      • Asegurarse que la implementación se adhiera a la Arquitectura.

    • Contexto del Negocio: Como la Arquitectura de Software afecta el modelo de negocio y operativo de la organización? El sistema creado por la Arquitectura deberá:
      • Satisfacer los objetivos y requerimientos de negocio de los stakeholder.
      • Adherirse a la estructura organizacional de la organización.

    • Contexto Profesional: Cual es el rol del Arquitecto de Software dentro de la organización y dentro del proyecto? El arquitecto deberá tener las siguientes habilidades desarrolladas para tener éxito:
      • Habilidades de Liderazgo y Comunicación: 
        • ComunicaciónComunicar efectivamente las ideas, conceptos, problemas y soluciones a los stakeholders.
        • Colaboración: Lograr el involucramiento de los stakeholder en el proceso de arquitectura.
        • Claridad: Articular la Arquitectura en una manera clara y concisa en los términos mas apropiados para cada tipo de stakeholder.
        • Traducción: Lograr traducir los requerimientos de negocio, en requerimientos arquitecturalmente significativos y atributos de calidad.
      • Conocimiento Técnico:
        • Technical Depth: Aquello que se sabe y se domina.
        • Technical Breadth: Aquello que se sabe que existe, pero no se domina.
      • Conocimiento del Negocio.
        • Mejora la comunicación con las áreas de negocio.
        • Permite entender mejor los objetivos, problemas y tendencias del negocio.
        • Lograr confianza con las áreas de negocio.
        • Diseñar la Arquitectura de una manera que permita manejar futuros cambios.
        • Ayuda a determinar de mejor forma los patrones de arquitectura.
      • Dominio de las Metodologías y Pensamiento Estratégico (sistemico).
        • Proceso de Desarrollo en Cascada (Watefall).
        • Proceso de Desarrollo Iterativos e Incremental (RUP).
        • Proceso de Desarrollo basados en Extremme Programming (XP).
        • Proceso de Desarrollo basados en Agile (Scrum).
        • Proceso de Desarrollo basados en Lean Sofrtware Development.
        • Practicas de Diseño basados en Test Driven Development (y ATDD y BDD).
        • Practicas de Diseño basados en Domain Driven Development (DDD).
        • Practicas de Diseño basados en Model Driven Development (MDD).
        • Practicas de Diseño basados en Feature Driven Development (FDD).
        • Tener la sabiduría para identificar cuando se aplican y cuando no se aplican estos procesos y practicas.

    lunes, 24 de agosto de 2015

    Ingeniería de Requisitos y el Agilismo.

    Esta entrada nace como parte del trabajo final de la asignatura de Ingeniería de Requisitos de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

    El objetivo de esta entrada es analizar el Proceso de Requisitos de Software que se esta llevando en mi organización desde el punto de vista de la Ingeniería de Requisitos propuesta por Klaus Pohl.

    Contexto del Proceso de Requisitos de Software.

    La Organización.
    La organización para la que trabajo es una de las empresas de software más grande de Colombia, cuyo propósito de negocio es transformar la forma de hacer negocios de sus clientes, a través de sus servicios de Consultoría en Tecnologías de la Información y Fabrica de Software.


    La información aquí expuesta, no viola ningún acuerdo de confidencialidad puesto que esta información se encuentra en el Portal Web de la organización a la cual me refiero.


    Esta organización tiene casi 20 años de experiencia en el mercado nacional e internacional; cuenta cerca del 1500 empleados, y tiene presencia en cerca de 9 países.

    El perfil de los clientes, se puede resumir en dos palabras: GRANDES y RELEVANTES. Estos clientes, son las empresas más relevantes en sus respectivos sectores de mercado en cada uno de los países donde la organización tiene presencia. 

    Debido a lo anterior y a la necesidad de diferenciarse de la competencia, la organización ha aplicado las mejores prácticas y metodologías que han surgido durante los años. Como resultado de esto, la organización esta certificada en ISO 20000 y valorada en CMMI-DEV Nivel 5; y pone en practica los lineamientos de estándares internacionales como COBIT, ITIL, PMI, entre otros. 

    Actualmente, la organización esta en un proceso de adopción e institucionalización de las metodologías Ágiles; esto con el fin adaptarse a las exigencias actuales del mercado. 


    Antecedentes del Proceso de Desarrollo de Software.
    El proceso de desarrollo de software que se lleva a cabo en la organización esta basado en la metodología Scrum con unos ligeros toques de Disciplined Agile Delivery.



    Scrum, al ser una metodología Ágil se encuentra fuertemente inspirada y adherida a los valores y principios del Manifiesto Ágil. Adicionalmente, es común aplicar los principios y practicas recomendadas por otras metodologías ágiles como Extreme Programming y Lean Software Development.

    De estos principios y valores, los que se relacionan más estrechamente con la Ingeniería de Requisitos son:

    De los Valores del Manifiesto Ágil
    1. Valorar más a los individuos y su interacción que a los procesos y las herramientas
    2. Valorar más el software que funciona que la documentación exhaustiva
    3. Valorar más la colaboración con el cliente que la negociación contractual
    4. Valorar más la respuesta al cambio que el seguimiento de un plan
    De los Principios del Manifiesto Ágil
    • Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
    • Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
    • Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
    • El software que funciona es la principal medida del progreso.
    • La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
    De los Principios de Lean Software Development
    • Eliminar el Desperdicio
    • Decidir lo importante e irreversible lo mas tarde posible

    Estos principios y valores limitan y fortalecen la Ingeniería de Requisitos, haciendo que se concentren sus actividades únicamente en aquellas cosas que generen valor al negocio.


    El Proceso de Requisitos de Software.
    El proceso de desarrollo de software que se lleva a cabo en la organización plantea varias actividades relacionadas con la Ingeniería de Requisitos. Así el Proceso de Requisitos de Software que se realiza constaría de:
    • Durante cada Sprint, del trabajo constantemente en la expansión, reducción y refinamiento del Product Backlog
    • Durante cada Sprint, del trabajo realizado en el Sprint Planning con el cliente.
    • Durante cada Sprint, del trabajo realizado en el Sprint Review con el cliente.

    El papel del Product Owner.
    Dentro del Proceso de Requisitos de la organización, el Product Owner es el líder del producto a construir. Es el principal interlocutor entre el equipo de desarrollo y los stakeholder; y tiene toda la responsabilidad del éxito del producto que se esta construyendo. Es la única autoridad que indica que características y que funcionalidades se van a construir; y en que orden. 


    El Product Owner es una voz unificada de los stakeholders de cara al equipo de desarrollo.

    Los requisitos son manifestados, principalmente, por medio de Historias de Usuario. Estas historias son apiladas en un artefacto denominado Product Backlog. Esta pila de historias son ordenadas acorde a diversos criterios definidos por el Product Owner


    Los criterios de priorización pueden variar, pero principalmente se toma el concepto de Valor de Negocio, como el criterio de diferenciación y priorización de las historias. Se colocan las historias con mayor Valor de Negocio en la parte superior de la pila, y las de menor valor en la parte inferior.


    Así las historias de usuario se van construyendo siguiendo este orden y priorización. Este orden podrá cambiar en cada Sprint, pero la idea general se mantiene.

    El Product Owner es un rol que trabaja diariamente en el desarrollo, recopilación y priorización de las Historias de Usuario. Mantiene una comunicación constante con el equipo de desarrollo, proporcionándoles retroalimentación constante acerca del trabajo realizado y por realizar.

    El problema del Product Owner.
    A pesar de las ventajas del rol de Product Owner dentro del Proceso de Requisitos de la organización, este rol presenta varios retos a tener en cuenta:
    • La persona asignada a este rol tiende a estar del lado del cliente: En el contexto de la organización, el Product Owner siempre estará del lado del cliente. Esto hace que siempre se deba hacer un esfuerzo de capacitación constante en el rol de Product Owner a la persona seleccionada.
    • La persona asignada a este rol tiende a ser alguien que conoce a fondo el negocio del cliente: El Product Owner siempre será alguien que conoce a fondo el negocio del cliente. Será una persona que tiene la visión clara de lo que el producto será y no será. Sin embargo, esta persona siempre desconocerá las restricciones en políticas, procesos y tecnologías del área de TI.
    • La persona asignada a este rol se puede convertir en un cuello de botella: El Product Owner será la persona que marcará el ritmo del proyecto. Si el Product Owner esta dedicado al 100% al proyecto, siempre tendrá Historias de Usuario listas para ser estimadas y desarrolladas. De lo contrario se corre el riesgo que la velocidad de trabajo del equipo de desarrollo sea superior a la velocidad de trabajo del Product Owner, haciendo que el equipo se quede sin Historias de Usuario para estimas y desarrollar.
    • La persona asignada a este rol se convierte automáticamente en un factor critico de éxito: El desempeño del Product Owner determinará si el producto tiene éxito o no. Al esta la persona que tiene la visión clara de lo que el producto será y no será; la ausencia de esta persona será un impedimento significativo en el proyecto.
    • La persona asignada a este rol tiende a no representar a todos los stakeholder: El Product Owner siempre sera alguien del lado del cliente que conoce a fondo el negocio. Sin embargo, puede pasar por alto las necesidades de negocio de otras áreas de negocio que podrían estar involucradas indirectamente en el proyecto.

    Todos estos retos se pueden resumir en el siguiente: La persona asignada a este rol no está capacitada en la Ingeniería de Requisitos. Dada la naturaleza de negocio del Product Owner, siempre se correrá el riesgo que pase por alto practicas, actividades, técnicas y artefactos de la Ingeniería de Requisitos. 



    Comparación del Proceso de Requisitos Vs. el Framework de Ingeniería de Requisitos de K. Pohl.

    Al comparar el Proceso de Requisitos que se maneja en la organización con el Framework de Ingeniería de Requisitos propuesto por K. Pohl, se evidencia lo siguiente:

    Desde el punto de vista de las metodologías Ágiles, el Proceso de Requisitos cubre perfectamente las perspectivas de Uso del Contexto y Sujeto del Contexto. Los requisitos de estas perspectivas son manejados por el Product Owner

    Dentro de cada una de estas, las actividades se cubren así:
    • Educción de Requisitos: Dada la naturaleza del Product Owner, este tiene todo el conocimiento y habilidades para educir satisfactoriamente los requisitos.
    • Documentación de Requisitos: El Product Owner convierte los requisitos en Historias de Usuario. De esta forma se esta aplicando un Patrón Sintáctico para reducir la ambigüedad de los requisitos.
    • Negociación de Requisitos: Por definición, toda Historia de Usuario debe ser negociable. Así mismo, el proceso de desarrollo de software determina si la historia es implementable o no. En caso de no serlo se realiza un refinamiento a fondo de esta historia.
    • Validación de Requisitos: Por proceso de desarrollo de software, periódicamente (al menos 1 vez por Sprint) se refinan las Historias de Usuario con el fin de disminuir su ambigüedad. De aquí se realizan lecturas basadas en perspectivas para crear los Casos de Prueba y la actualización de la Definición de la Arquitectura. También se realizan validaciones por medio de prototipos en el Sprint Review
    • Gestión de Requisitos: Por proceso de desarrollo de software, el Product Owner es el responsable de la gestión del Product Backlog. Adicionalmente, el Product Owner es responsable por el constante contacto con los stakeholder y el equipo de desarrollo; sincronizando la información que viaja entre estos.

    Por otro lado, el Proceso de Requisitos también cubre parcialmente las perspectivas de TI del Contexto y la perspectiva de Desarrollo de Software del Contexto. Se presenta el caso en que los requisitos de estas perspectivas no son manejados por el Product Owner, sino por el Arquitecto de Software

    Al ser estas perspectivas y actividades parcialmente cubiertas, es aquí en donde se presentan las oportunidades de mejora para estas perspectivas.

    Es así que dentro de cada una de estas perspectivas las actividades se cubre de la siguiente manera:
    • Educción de RequisitosDada la naturaleza del Arquitecto de Software, este tiene todo el conocimiento y habilidades para educir satisfactoriamente estos requisitos de los stakeholder pertenecientes a estas dos perspectivas. Así mismo, se analizan las Historias de Usuario arquitecturalmente significativas. Sin embargo, hace falta un formalismo mas explicito para la educción de restricciones y atributos de calidad.
    • Documentación de Requisitos: Las restricciones de Arquitectura y Tecnología y los Atributos de Calidad, con sus respectivos escenarios, son documentados en el documento de Definición de Arquitectura. Los mecanismos para lograr que estos escenarios se cumplan no se escriben como Historias de Usuario. Adicionalmente hacen falta mecanismos que permitan guiar el diseño del sistema.
    • Negociación de Requisitos: Estos requisitos al no estar escritas como Historias de Usuario, no se consideran negociables dentro de la metodología. Estos requisitos restringen la forma en que hará el desarrollo.
    • Validación de Requisitos: Estos requisitos se validan de forma estática por parte el Comité de Arquitectura de la organización; y por el Arquitecto de Software del lado del cliente.
    • Gestión de Requisitos: Debido a que estos requisitos no forman parte como tal del proceso (al no ser Historias de Usuario), no se hace evidente su gestión directa, o al menos la necesidad de gestionarlos directamente. Se gestionan a partir del análisis de las Historias de Usuario arquitecturalmente significativas.


    Ingeniería de Requisitos acorde a K. Pohl.

    Klaus Pohl propone un framework para la Ingeniería de Requisitos, el cual consiste en dividir el contexto del sistema que se piensa construir en 4 perspectivas; así:
    • Perspectiva de Uso del contexto: Todos los aspectos que se refieren al uso del sistema por las personas u otros sistemas.
    • Perspectiva de Sujeto del contextoObjetos y eventos que deben ser representados en el sistema; de los que el sistema va a procesar y almacenar información.
    • Perspectiva de TI del contexto: Todos los aspectos referentes a plataformas (Hardware y Software), redes de comunicaciones, periféricos, componentes ya existentes, otros sistemas. Estrategias y Políticas de TI.
    • Perspectiva de Desarrollo:Todos los aspectos que se refieren a proceso de desarrollo, herramientas, modelos de madurez, métodos de aseguramiento de calidad.

    Framework para la Ingeniería de Requisitos según K. Pohl.
    Para cada una de estas perspectivas, se plantean las siguientes actividades:
    • Educción de Requisitos: Mejorar el entendimiento y establecer el alcance de los Requisitos.
    • Documentación de Requisitos: Documentar y Especificar los Requisitos.
    • Negociación de Requisitos: Evidenciar los conflictos, contradicciones y limitaciones de los Requisitos, así como la negociación y resolución de estos problemas con los stakeholders.
    También se establecen dos actividades transversales a las 4 perspectivas así:
    • Validación de Requisitos: Validación de Artefactos de Requisitos, Validación de Actividades de Requisitos y Validación del Contexto del Sistema.
    • Gestión de los Requisitos: Gestión de Artefactos de Requisitos, Gestión de Actividades de Requisitos y Observación del Contexto del Sistema.
    Y finalmente, se establecen 3 categorías de artefactos a tener en cuenta durante la puesta en marcha del framework aquí descrito:
    • Requisitos Orientados a Objetivos: Documentación de los Objetivos de Negocio que los stakeholders tienen planteados y definidos para el sistema.
    • Requisitos Orientados a Escenarios: Documentación de los Escenarios que se plantean y/o descubren para el cumplimiento o no de los Objetivos de Negocio.
    • Requisitos Orientados a la Solución: Documentación de los datos, las funcionalidades, las restricciones  y los atributos de calidad del sistema.