4.2.2.1 Perspectiva de contexto
Esta serie de subactividades anteriormente vista, se enfoca en dos grupos de componentes del contexto de un sistema, como lo son las fuentes de requisitos y los objetos del contexto. En las fuentes de requisitos encontramos como buena práctica, la identificación de los Stakeholders interesadas y se definen cuáles de ellas son fuentes de requisitos en cada una de las perspectivas; la documentación, en la cual se identifican los documentos y se definen cuáles de ellos son fuentes de requisitos en cada una de las perspectivas definidas; los sistemas, donde se busca identificar otros sistemas y se definen cuales son fuentes de requisitos para cada uno de las perspectivas. Como parte de los objetos de contexto, encontramos las personas, los procesos, objetos materiales y objetos inmateriales. Como personas se entiende que busca la identificación de los individuos que hacen uso del sistema y se definen cuales serán objetos del contexto para cada perspectiva, como procesos, se busca identificar dichos procedimientos o procesos que impactan el desarrollo del sistema, como lo son las normas o políticas, al igual que reglas de negocio. Para los objetos inmateriales o materiales, se busca la identificación de los objetos tangibles o intangibles que existen en el contexto de desarrollo de un sistema, tales como funciones matemáticas, procesos de negocios, leyes, o procesos de producción.
A continuación, en el anexo I, se encuentra un diagrama de dichas buenas prácticas para la perspectiva de contexto:
50
Anexo I, Contexto: Tabla de elementos del Contexto extraídos del framework de K. Pohl en el diseño de niveles
4.2.2.2 Educción
De la subactividad de identificación de fuentes relevantes de requisitos, se parte de las fuentes de requisitos identificadas en el área de contexto, se definen cuáles son las fuentes relevantes para lograr la obtención de dichos requisitos, de la subactividad de educción de requisitos existentes, se espera la realización la educción de requisitos a partir de las fuentes relevantes que se identifican en la subactividad anterior, y de la subactividad de desarrollar requisitos nuevos e innovadores, en la cual, basado en lo obtenido en la identificación de fuentes relevantes y la educción de requisitos, se logró -realizó- la identificación de requisitos nuevos y/o que generan innovación.
Para la realización de las subactividades anteriores, se desprende un siguiente nivel de detalle en el cual se utilizan prácticas y técnicas de asistencia para la educción de requisitos, estas técnicas pueden ser utilizadas para cualquiera de las subactividades, tales técnicas son, los grupos focales la cual permite identificar un tema foco como un proceso o módulo por medio de un estudio de las opiniones de un público, ideal para educir requisitos existentes y desarrollar Requisitos Nuevos e Innovadores, la observación también siendo una técnica, que se basa en la observación de los Stakeholders en la ejecución de los procesos y uso de los sistemas, al igual que se puede realizar lo que los Stakeholders hacen con estos procesos y sistemas, ideal para la educción de requisitos, la lectura basada en perspectivas se realiza cuando lectura de la documentación se lee bajo una perspectiva determinada (desarrollo, pruebas, etc.), ideal para educir requisitos existentes, los cuestionarios, se realizan cuando hay un gran número de Stakeholders a entrevistar, se incluyen preguntas abiertas y cerradas, esta técnica es ideal para identificar fuentes relevantes de requisitos al igual que educir requisitos existentes, las entrevistas, usada como técnica, se basa en formular preguntas (estructurada / no estructurada) claves para determinar requisitos subconscientes, ideal para identificar fuentes relevantes de requisitos, educir requisitos existentes y desarrollar requisitos nuevos e innovadores, la técnica de workshop, se realiza con la participación de personajes debidamente seleccionados, Los resultados son grupales no individuales, ideal para identificar fuentes relevantes, existentes y el desarrollo de nuevos e innovadores.
Para las anteriores técnicas, existen también técnicas de asistencia, que se puede acoplar como complemento en el desarrollo de las subactividades de identificación de fuentes, educción de requisitos existentes y desarrollar requisitos nuevos e innovadores. La utilización de listas de chequeo implica un número amplio de elementos que pueden ser preguntas u oraciones relacionadas con un tema complejo, los mapas mentales, al ser usados permite la representación sistemática de información sobre un asunto específico, las lluvias de ideas se basa en hacer unas preguntas, el resultado de estas preguntas se recolectan con cierto límite de tiempo, el método KJ, permite que cada participante escribe sus ideas en fichas,
51
estas ficha debe tener un único requisito y se muestra al grupo, el cual selecciona las mejoras ideas para ser detalladas después, y por último, se recomienda como técnica de asistencia, los prototipos, la cual se realiza cuando el Stakeholder tiene una visión vaga o entiende muy poco de cómo lo quiere.
En el siguiente anexo se presentan los niveles de la educción:
Anexo I, Educción: Tabla de elementos de la Educción extraídos del framework de K. Pohl en el diseño de niveles
4.2.2.3 Documentación
Como se han visto en los anteriores grupos de buenas prácticas, de este se derivan también subactividades que tienen el objetivo de dar profundidad a dos documentaciones, uno de estos es la documentación de en lenguaje natural, la cual permite que los Stakeholders no deben aprender nueva notación, estos documentos siguen una estructura común, y lo segundo es la documentación con modelos conceptuales, las cuales permiten tener Menor ambigüedad y se facilita la lectura cuando se conocen. Se representar objetos materiales e inmateriales al igual que es la representación abstracta del universo del discurso creado para un propósito o uso específico.
En la documentación en lenguaje natural se recomiendan la utilización de tipificación de la documentación, mediante la utilización de estándares como lo es de habla Inglesa ISO/IEC/IEEE 29148:2011, y de habla alemana Lastenheft/Pflichtenheft. Luego de definir un estándar para la documentación de los requisitos en lenguaje natural, la siguiente recomendación se basa en la documentación discriminada por los tipos de artefactos, teniendo en cuenta los objetivos, escenarios y orientados a la solución, a su vez, se recomienda la aplicación de la documentación en lenguaje natural de los componentes de software y hardware.
En lo referente a la documentación con modelos conceptuales, se desprende una serie de buenas prácticas basadas en los artefactos, como objetivo, escenarios y orientado a la solución. Para objetivos, se recomienda la utilización de plantilla para documentar objetivos, también realizar documentación de árboles y grafos, en la cual los requisitos por medio de una representación en forma de árbol o grafo, en el que dos vértices están conectados por exactamente un camino. Se recomienda la utilización del framework I-Star como documentación de objetivos, el cual busca integrar actores con diferentes competencias sobre el entorno del sistema. El énfasis debe estar en ayudar a los interesados a obtener una mejor comprensión de las diversas posibilidades de uso del sistema en su organización ofrecen una serie de niveles de análisis, en términos de capacidad, capacidad de trabajo, la viabilidad y credibilidad. Por último, para la documentación basada en modelos conceptuales, se recomienda el modelo KAOS, este modelo se basa en capturar los objetivos con enfoque en la ingeniería de requisitos, para el modelado de objetivos específicos, es otro I-Star, permite que los requisitos sean calculados mediante diagramas de objetivos.
Para la documentación de escenarios, basado en modelos conceptuales, se recomienda la utilización de los casos de uso, con el cual se logra una descripción
52
de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. La utilización de diagramas de secuencia también se relaciona como una buena práctica para la documentación de escenarios con modelos conceptuales, ya que se logra modelar la interacción entre objetos en un sistema. La utilización de diagramas BPMN se logra documentar escenarios con una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo. Finalmente, como buena práctica para la documentación de escenarios, se recomienda la utilización de diagramas de actividades con el que se logra una representación gráfica del proceso.
Las buenas prácticas para la documentación con modelos conceptuales orientados a la solución, se divide en tres grupos, los cuales son según una perspectiva, datos, funcional y de comportamiento. Para la perspectiva de datos, se recomiendo la documentación basada en modelo, entidad, relación y la utilización de diagrama de clases, con lo cual se logra describir la estructura de un sistema. Para la perspectiva funcional se recomienda la utilización de documentación basada en diagrama de flujos, matriz de gobierno de datos, con los cuales se logra una representación gráfica del flujo de datos a través de un sistema, y como los datos se integran al proceso del sistema. Por último, para la perspectiva de comportamiento, se recomienda la utilización de diagrama de estados como de diagrama de máquina de estados, donde se modela el comportamiento de un solo objeto, especificando la secuencia de eventos que un objeto atraviesa durante su tiempo de vida.
En el siguiente anexo se relaciona la distribución de buenas prácticas para la documentación:
Anexo I, Documentación: Tabla de elementos de la Documentación extraídos del framework de K. Pohl en el diseño de niveles
4.2.2.4 Negociación
Las buenas prácticas en la negociación de los requisitos en el framework, garantizan la gestión y manejo de los conflictos si los hay, los cuales son causados cuando las necesidades de los Stakeholders son contradictorias entre sí o hay necesidades o deseos que no pueden ser tenidas en cuenta. Se relacionan cinco grupos que encierran una serie de subactividades que buscan garantizar la ejecución de las buenas prácticas de la negociación, el primero se denomina identificación de conflictos, donde se realiza el hallazgo de los conflictos que se pueden dar durante cualquier actividad que se ejecuta en las fases de la ingeniería de requisitos, como técnica de asistencia para la identificación, se recomienda la utilización de grupos focales y workshop, con la idea de recopilar los conflictos entre un grupo de personas, que hace énfasis a un tema para tratar diferentes aspectos del sistema. El segundo grupo, el análisis de los conflictos ya identificados, donde se debe clasificar los conflictos como, datos, de intereses de las partes interesadas, conflictos de valor, conflictos de relaciones y conflicto de estructura. El tercer grupo, resolver los conflictos, luego del análisis, como técnica de asistencia, se recomienda la aplicación de soluciones creativas y toma de decisiones. El cuarto grupo, es la
53
documentación de las resoluciones de los conflictos donde se guarden las soluciones alcanzadas, principales argumentos y las revisiones. Por último, como técnica de negociación, se recomienda las técnicas de enfoque gana-gana o la matriz de interacción.
En este nivel, el anexo I muestra la de los elementos de la negociación extraídos del framework de K. Pohl en el diseño de niveles:
Anexo I, Negociación: Tabla de elementos de la Negociación extraídos del framework de K. Pohl en el diseño de niveles
4.2.2.5 Validación
Para esta área de buenas prácticas, se han determinado tres grandes grupos, que serán explicados cada uno, estos grupos son la validación de los artefactos creados, validación de la estructura de contexto y la validación de la ejecución de actividades. En el primer gran grupo, la validación de los artefactos creados, en la cual se basa en los requisitos ya documentados, valorando si están según lo esperado por el proceso, esta se debe realizar teniendo en cuenta el tipo de validación, ya sea de contenido, donde se realiza la revisión del contenido de los artefactos creados para la comprobación del cumplimiento esperado para el proceso, el tipo de validación de documentos, busca que la documentación de los artefactos creados cumpla lo esperado para el proceso, y por último, se recomienda la validación de los acuerdos, para que dicha revisión compruebe el cumplimiento esperado para el proceso. Como soporte o herramienta para el desarrollo de las actividades anteriores de la validación de documentación, se deben tener en cuenta ciertos criterios para cada actividad, el contenido debe tener en cuenta criterios como documentación y artefactos completados, requisitos completos, consistencia de los requisitos, exactitud de los requisitos, requisitos necesarios, no decisiones prematuras de diseño, capacidad de prueba y la trazabilidad de los requisitos. Los criterios a tener en cuenta en la validación de la documentación son el formato correcto de la documentación, comprensibilidad de la documentación, documentación sin ambigüedades, cumplimiento de las normas de documentación. Los criterios para la validación del contenido, se basan en los acuerdos con Stakeholders, los acuerdos después de la modificación, chequeo de los conflictos de los acuerdos y la resolución de estos.
Como paso siguiente, teniendo claro que hasta el momento, para la validación de artefactos creados, tenemos unos criterios para cada una de los tipos de validación (contenido, documentación, acuerdos), ahora existen también una serie de aspectos a tener en cuenta que denotan posibles errores, como lo son los requisitos sesgado por una solución específica, requisito faltante, trazabilidad de la información faltante, inconsistencia en los requisitos, requisito incorrecto, requisito no comprobado, requisitos innecesarios, requisitos incompletos, requisitos en documentación con formato incorrecto, carencia de compresión, requisitos documentados con ambigüedad, reglas rotas por documentación, requisitos no
54
acordados, requisitos no acordadas después de modificaciones, conflictos no resueltos, conflicto no eliminado.
Para la realización de la validación de los artefactos creados, se deben tener en cuenta principios tales como involucrar a los Stakeholders correctos, separar la detección de defectos de lo correcto, aprovechamiento de múltiples vistas independientes, creación de artefactos de desarrollo durante la validación y repetir validación si es necesario. Se recomienda emplear técnicas de asistencia para la validación de artefactos, tales como inspecciones, pruebas de escritorio, tutoriales, lectura basado en la perspectiva y prototipado.
A continuación, en el anexo I, se relaciona el orden en el que se constituye las buenas prácticas para la validación de artefactos creados:
Anexo I, Validación: Tabla de elementos de la Validación - artefactos creados extraídos del framework de K. Pohl en el diseño de niveles
Volviendo a hablar de los tres grandes grupos que encierra la validación, seguimos con la validación de la estructura de contexto, donde se basa en la validación de los requisitos ya documentados salientes de las actividades de la estructura de contexto, sabiendo que las perspectivas están compuestas por la perspectiva del objeto, uso, TI y desarrollo.
Como en el grupo anterior, se consideran varios aspectos a tener en cuenta por perspectiva, tales como para la perspectiva de objeto: todos los objetos relevantes han sido identificados y documentados que todos los objetos han sido identificados de manera correcta y completa, todos los requisitos de calidad para los objetos han sido identificados, todos los aspectos legales para los objetos han sido identificados, todas las fuentes de requisitos han sido incorporados; los factores para la perspectiva de uso son: las interacciones deseadas con el entorno han sido identificadas completa y correctamente, los requisitos de calidad para las interacciones deseadas con el entorno han sido identificadas completa y correctamente, los diferentes grupos de usuarios han sido tenidos en cuenta, los objetivos para el uso de los Stakeholders relevantes han sido identificados completa y correctamente; para la perspectiva de TI, los factores a tener en cuenta en la validación son: todas las propiedades relevantes de hardware y software han sido capturadas completa y correctamente, todas las interfaces y protocolos relevantes han sido documentadas completa y correctamente, han sido consideradas todas las estrategias de TI, han sido consideradas todas la políticas de TI; y los factores para la perspectiva de desarrollo son: todos los requisitos correspondientes a lenguajes y herramientas de desarrollo han sido capturados completa y correctamente, todos los requisitos para el proceso, reglas y guías de desarrollo han sido capturados completa y correctamente, todos los artefactos de desarrollo han sido facilitados entre el cliente y el proveedor, han sido identificados, la duración y costo del proyecto han sido chequeados después de que todos los requisitos han sido
55
acordados. Para todas las perspectivas en general, deben existir aspectos importantes al momento de validar, error en la información del contexto, falta de información en el contexto, fuentes de requisitos incompleto, insuficiente información para el contexto.
A continuación, en el anexo I, se relaciona el orden en el que se constituye las buenas prácticas para la validación de la estructura de contexto:
Anexo I, Validación: Tabla de elementos de la Validación - estructura del contexto extraído del framework de K. Pohl en el diseño de niveles Nuevamente vamos a los tres grupos de la validación, para darle paso a lo que encierra el último grupo, la validación de la ejecución de actividades, en donde se basa en comprobar si cada actividad de IR ha sido desarrollada y si cada actividad ha sido ejecutada de manera apropiada.
Lo anterior implica ejecutar ciertas actividades que garanticen la correcta validación, tales como, la ejecución de actividades ha sido documentada de la forma acordada, todas las entradas a las actividades han sido identificadas y documentadas en forma apropiada, han sido todas las actividades ejecutadas conforme al proceso y todas las salidas de las actividades han sido producidas y documentadas apropiadamente.
También en este grupo, se tienen aspectos importantes a tener en cuenta, para el momento de desarrollar el proceso de validación de las actividades, estos aspectos son incluir a todos los Stakeholders relevantes están involucrados, todas las actividades prescritas se realizaron, todas las salidas prescritas se realizaron, ejecución correcta de todas las actividades documentadas, todas las entradas relevantes se consideraron para cada actividad.
A continuación, en el anexo I, se relaciona el orden en el que se constituye las buenas prácticas para la validación de ejecución de actividades:
Anexo I, Validación: Tabla de elementos de la Validación - ejecución de las actividades extraídas del framework de K. Pohl en el diseño de niveles
4.2.2.6 Gestión
La gestión de los artefactos creados, consiste en la definición de un esquema de atributos para los requisitos, generar la trazabilidad de los requisitos, la gestión del cambio de los requisitos, gestión de la configuración de los requisitos y priorización de los requisitos. La definición del esquema de atributos se encuentra constituida por la siguiente estructura para los requisitos, iniciando por un id del requisito, nombre del requisito, tipo del requisito, versión del requisito, autor del requisito, estado del requisito, prioridad del requisito.
56
Con este esquema realizado, facilita la siguiente actividad, la trazabilidad del requisito, este seguimiento se puede realizar ya sea por condición, por contenido, por abstracción, por evolución, misceláneo, la utilización de ayudas en la documentación tales como las referencias en el texto, implementar Hipervínculos o modelos, contribuyen al desarrollo adecuado de la trazabilidad de los artefactos. El siguiente pasó a seguir, la priorización, con esta subactividad para la gestión de los artefactos creados, se genera la priorización de los requisitos por importancia o