Resumen de Ingeniería de Requerimientos (Ingeniería I)

Ingeniería de Software

Definiciones

• Se ocupa de construir un producto de software de alta calidad lidiando con las múltiples restricciones.

• Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

• The discipline of software engineering encompasses knowledge, tools, and methods for defining software requirements, and performing software design, software construction, software testing, and software maintenance tasks. Software engineering also draws on knowledge from fields such as computer engineering, computer science, management, mathematics, project management, quality management, software ergonomics, and systems engineering.

Etapas

• Requerimientos
• Diseño
• Implementación
• Integración
• Validación
• Instalación

Ingeniería de Requerimientos

Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.

Los factores que más problemas causan a un proyecto es la falta de requerimientos, o la falta de claridad de los mismos. Un buen requerimiento además permite detectar problemas tempranamente cuando su costo de corrección es menor.

Las actividades relacionadas a IR implican una elicitación y modelado del problema a partir de los stakeholders, documentos y sistemas preexistentes, sobre lo que se generan modelos de requerimientos. Estos modelos son sujetos a análisis, validación y priorización; hasta que se obtiene una especificación de requerimientos.

Software Requirements Specification

Un SRS es un documento que resulta como producto del proceso de IR. Su propósito depende bastante del alcance del proyecto, dependiendo de su tamaño es la criticidad de un amplio SRS y la cantidad de grupos distintos que dependerán de él. Puede ser escrito por el contratante a modo de licitación, por el proveedor a modo de propuesta, por el desarrollador para expresar su entendimiento del problema o por un consultor independiente.

Debe abarcar:

• Funcionalidad. Qué es lo que el software hace.
• Interfases externas. Cómo debe interactuar con gente, con el hardware del sistema, con demás hardware y con demás software.
• Restricciones de diseño. Estándares a cumplir, lenguaje de programación, recursos, sistemas operativos, etc.
• Atributos de Calidad.
  • Cual es la velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación después de fallas, etc.
  • Consideraciones de portabilidad, correctitud, precisión, mantenibilidad, seguridad y mas.

Propósitos:

• Comunicar funcionalidades, capacidades y restricciones del sistema de forma precisa.
• Actúa como contrato.
• Base para estimación de tiempo y costo del proyecto.
• Base para evaluar (validar) el producto final y determinar si satisface los requerimientos.
• Base para control de cambios.

Lectores:

• Usuarios
• Clientes
• Analistas (de sistemas, de requerimientos)
• Desarrolladores (diseñadores, programadores, etc)
• Testers (V&Vers)
• Gerentes
• Equipo de mantenimiento
• Escritories de documentación
• Equipo de capacitación de usuario
• Legales
• Subcontratistas

Puntos de Inicio

Un proyecto se inicia típicamente con una declaración informal y ambigua. Inicialmente se debe entender el contexto y alcance del proyecto y decidir su factibilidad. Se necesita saber el tipo de proyecto y contexto organizacional, los objetivos principales, los mayores riesgos y los stakeholders involucrados.

• Cuál es el propósito?
• Quién quiere el sistema?
• Qué quieren lograr?
• Cuáles son las restricciones?
• Cuáles son los mayores riesgos?

Debe definirse también el alcance del proyecto, evitando que sea demasiado acotado o demasiado amplio (por ejemplo, no explorar la causa y quedarse con un síntoma). Deben tenerse en cuenta los objetivos, el costo, los riesgos, los stakeholders, etc.

Modelos

Un modelo es una descripción formal del problema cuyo fin es lograr un mayor entendimiento, precisa, abstracta, manipulable formalmente e interpretable en el mundo real; que permite ser sujeta a análisis.

Validación y Verificación

Validación es el proceso por el cual se incrementa la confianza en que una descripción formal (modelo) se corresponde con la realidad. Es el proceso más dificultoso por la subjetividad e intangibilidad del problema.

Verificación, en cambio, es un proceso formal por el cual se comparan dos modelos para determinar la correctitud de uno respecto del otro; por ejemplo, garantizar que la descripción del problema satisface la descripción de la solución.

Modelo de Jackson

Realiza una separación entre el mundo (la porción del mundo real afectada por la máquina) y la máquina (la porción del sistema a desarrollar); además de identificar la intersección entre ambos. La IR se ocupa de los fenómenos que ocurren en el mundo y los compartidos con la máquina, que son controlados por una de las dos partes y observados por la otra.

Sobre los fenómenos se realizan aserciones descriptivas, cosas que son o se presumen verdaderas acerca del mundo, y aserciones prescriptivas, cosas que se espera que sean verdaderas.

• Los objetivos (goals) son aserciones prescriptivas acerca de los fenómenos del mundo.
• Las presunciones son aserciones descriptivas sobre el mundo.
• Los requerimientos son aserciones prescriptivas sobre la interfaz.

Criterios de validación

• Tenemos todos los objetivos? Son todos válidos?
• Todos las propiedades del dominio son verdaderas?
• Todas las presunciones acerca del dominio son razonables?

Criterios de verificación

• Los requerimientos (R) de la máquina satisfacen los objetivos (G) dadas las suposiciones acerca del dominio (D). R, D |= G
• El programa (P) ejecutando sobre el hardware (C) satisface los requerimientos (R). P, C |= R

Completitud de Requerimientos

La ingeniería de requerimientos determina que los requerimientos son completos si se verifica R, D |= G, que los goals capturan las necesidades de todos los stakeholders y que las presunciones acerca del mundo son válidas.

Diagrama de contexto

• Estructura los fenómenos del mundo para lidiar con su complejidad
  • Muestra los agentes relevantes del mundo y sus interfases (con la máquina u otros agentes)
• Agente = entidad activa
  • Con capacidad de controlar/monitorear algún fenómeno del mundo
  • Puede ser humano, un dispositivo, software, etc...
• Un diagrama de contexto de sistema está compuesto por:
  • Un conjunto de agentes
  • Para cada agente, su interfaz: fenómenos controlados y monitoreados por el agente
• Problema: Normalmente, las entidades a incluir en el contexto y la división mundo - maquina son el resultado del proceso de IR y no el punto de partida.

Modelo de Objetivos

Los objetivos son aserciones prescriptivas formuladas respecto del mundo. Pueden diferenciarse en duros u objetivos de comportamiento (comprobables, prescriben el comportamiento esperado declarativamente) y en blandos (subjetivos, deben tener un criterio de aceptación).

También pueden dividirse en funcionales (servicios a prestar por el sistema) y no funcionales (restricciones acerca de cómo proveerlos). Puede haber objetivos que caigan en ambas categorías. Los objetivos no funcionales tienden a ser blandos en su inicio, pero es conveniente formalizarlos y convertirlos en duros. Independientemente de su dureza, debe haber un critero de medición.

Los objetivos pueden determinarse por elicitación temprana: buscando palabras prescriptivas en la declaración del problema o analizando el sistema actual. También puede construirse el modelo tanto top down como bottom up; es decir, partiendo de los objetivos de más alto nivel y refinándolos (determinando el cómo) o partiendo de bajo nivel y generalizando (determinando el por qué). El refinamiento debe realizarse hasta poder hacer la asignación a agentes, y la abstracción hasta cubrir el alcance del problema.

La idea es que todo el modelo esté conectado, y no haya fenómenos no relacionados con objetivos de alto nivel. Los objetivos son los que marcan el alcance del sistema.

Los objetivos se especifican indicando:

• Tipo de objetivo (lograr, mantener, evitar, soft goal)
• Nombre del objetivo
• Categoría (opcional)
• Definición en lenguaje natural
• Definición formal con lógica temporal (opcional)
• Referencia o fuente (opcional)

En el modelo, los objetivos duros se notan con cajas y los blandos con nubes. La relación por qué se nota con una flecha de más bajo hacia más alto nivel.

Relaciones

Las relaciones dentro de un modelo de objetivos son y/o-refinamientos, asignaciones de responsabilidades a agentes, conflictos y obstáculos. Hacia afuera, se tienen otras relaciones:

• Refiere a: diagramas de clases y objetos
• Operacionalización: casos de uso, pre/post condiciones
• Cubrimiento: escenarios y diagramas de secuencia

Y-Refinamientos

Vinculan objetivos de más alto con los de más bajo nivel. Un Y-Refinamiento de objetivos implica que para lograr el objetivo padre es necesario lograr todos los hijos. El refinamiento debe ser consistente, completo y mínimo; aunque hay notaciones que admiten no completitud o no minimalidad.

Un patrón frecuente de Y-Refinamiento es el de milestones, en el que se refina un objetivo en dos: en el primero se busca lograr un hito, y el segundo se parte de dicho hito y se logra el objetivo deseado. Formalmente, para refinar Actual implica en el futuro Esperada, se puede refinar en Actual implica en el futuro Hito e Hito implica en el futuro Esperada.

Otro patrón es el de refinamiento por casos (no confundir con O-Refinamientos). Separan el antecedente del objetivo a lograr en dos casos distintos, que se abren en dos objetivos hijos.

Un último patrón es el de asignabilidad, que descompone un objetivo sobre una condición incontrolable en una presunción acerca del dominio (que genera una condición monitoreable) y un requerimiento a lograr a partir de dicha condición.

O-Refinamientos

El O-Refinamiento aporta distintas maneras de lograr un mismo objetivo (no necesariamente excluyentes), vinculando al objetivo padre con distintos conjuntos de Y-Refinamientos.

Asignación a agentes

El refinamiento de objetivos debe realizarse hasta llegar al punto en que un objetivo puede ser resuelto por un único agente. Por agente se entiende el rol (no individuo) responsable de satisfacer un objetivo. En caso de que el agente asignado a un objetivo hoja sea el sistema, el objetivo se vuelve un requerimiento; si es parte del mundo, es una presunción acerca del mismo.

Análisis de Obstáculos

Los obstáculos son hechos consistentes con el dominio que implican la negación de alguno de los objetivos. Su resolución permite obtener un sistema más robusto que ataque objetivos más realistas, con requerimientos más completos.

El análisis de obstáculos es un proceso iterativo que consiste en:

• Identificación de obstáculos a partir de objetivos, utilizando heurísticas o patrones formales de obstrucción
• Evaluación de probabilidad y severidad de ocurrencia (símil riesgos)
• Generación de propuestas de resolución
• Selección de alternativa de solución, basada en el impacto de resolución sobre los objetivos
• Modificación o generación de objetivos

Para hallar un obstáculo, se parte de un objetivo hoja, se lo niega, y se aplican Y/O-Refinamientos sucesivos. Formalmente hablando, si se quiere [] CA implies CB, se lo niega obteniendo <> CA && !CD y se Y-refina en el obstáculo <> CA && !N y la propiedad de dominio CD implies N.

Hay heurísticas para hallar los obstáculos según la categoría del objetivo; por ejemplo, para presunciones del dominio, eventos por fuera del alcance del sistema; para agentes humanos, comportamiento imprevisible; para seguridad, peligros o amenazas; etc.

Transformaciones de objetivos

• Sustitución: Considerar un O-refinamiento alternativo de un objetivo de mas alto nivel para eliminar el objetivo obstruido.
• Debilitamiento: Debilitar la definición del objetivo para que permita los comportamientos cubiertos por el obstáculo y así eliminarlo; puede realizarse top-down debilitando un objetivo de alto nivel o bottom-up eliminando el objetivo obstruido y propagando.
• Prevención: Agregar un objetivo que sea evitar el obstáculo para contemplarlo y así eliminarlo.
• Restauración: Agregar un objetivo que se encargue de restaurar el objetivo violado ante la ocurrencia del obstáculo.
• Mitigación: Agregar un nuevo objetivo que si bien no elimine el obstáculo, mitigue sus consecuencias negativas.

Análisis de Conflictos

Un conflicto es una divergencia entre distintos objetivos $G_{1},...,G_{n}$ sii existe una condición de borde B tal que la condición, los goals y el dominio generan una inconsistencia, y que al remover cualquier objetivo $G_{i}$ dicha inconsistencia desaparece (es decir, el conjunto es minimal).

El proceso de análisis de conflictos es análogo al de obstáculos: se identifica una condición de borde, se la refina, se busca solucionarla y se regeneran los objetivos.

Una forma sencilla para obtener condiciones de borde es negar un goal e intentar refinar el resultado utilizando otro goal.

Técnicas de Selección

Puesto que la IR contempla muchas alternativas para satisfacer los mismos objetivos, es necesario utilizar técnicas de selección y priorización para decidirse entre ellas.

Razonamiento Cualitativo

Cada relación u opción del modelo (refinamiento, asignación, resolución de conflicto u obstáculo) tiene un impacto positivo o negativo (marcado con ++, +, -, --) sobre un determinado objetivo blando. Los objetivos blandos a su vez se abstraen utilizando refinamientos Y/O, y cada uno puede ayudar o dificultar a otro.

Las labels de impacto se propagan hacia arriba por Y-refinamientos tomando la menor de las etiquetas, y por O-refinamientos mediante la mayor. La relación de ayuda a genera un label igual, y dificulta a el opuesto. Así, se tienen cuatro labels: completamente/parcialmente satisfecho/violado.

Beneficios:

• Expone contribuciones positivas/negativas de opciones a objetivos blandos mediante afirmaciones validables
• El proceso de elaboración permite identificar objetivos nuevos, refinar o precisar objetivos e identificar nuevas opciones que contribuyen de mejor manera a objetivos existentes.

Limitaciones:

• Definición de Objetivos Blandos suele permanecer vaga
• Decisión sobre información cualitativa puede justificarse de manera débil.

Razonamiento Cuantitativo

En el razonamiento cuantitativo, se estima un puntaje para cada opción en función de cada soft goal, y a cada softgoal se le asigna un peso sobre su softgoal madre. Así, para cada goal se realiza un promedio ponderado del puntaje de sus hijas.

Hay dos vías para estimar puntajes. Una es mediante valores absolutos, en la que se asigna un valor de cero a uno para cada softgoal respecto de cada alternativa; aunque tiene el problema de que estos valores son poco significativos. La otra intenta resolver el problema mediante comparación de a pares, se determina cuántas veces mejor (de 1 a 9) es una alternativa que otra con respecto a una determinada soft goal, y de allí se derivan los valores numéricos.

Ventajas:

• Bajo costo, fácil de usar
• Output es un orden total de opciones
• Proceso de estimación cuantitativa puede generar discusiones y clarificaciones entre stakeholders

Desventajas:

• Juntar todos los criterios en un sólo valor (el puntaje global) tiende a esconder conflictos (en vez de exponerlos para lograr otras resoluciones).
• Definición de objetivos blandos sigue siendo vaga
• Parámetros son dificiles de validar porque no están expresados como cantidades medibles del dominio (es decir, contradice los principios fundamentales de IR: Objetivos deben ser precisos y medibles).

Medición de objetivos blandos

Se deben establecer criterios de medición para los objetivos blandos en conjunto con los stakeholders. Una posibilidad es definir funciones objetivo que dependan de variables de los goals. Así se les otorga un criterio de medición y de generalización bottom up: se define para las hojas una probabilidad y se utilizan ecuaciones de refinamiento de variables de calidad para generalizar hacia arriba.

Técnicas de priorización

Para priorizar qué implementar se realiza un análisis costo beneficio de cada una de las funcionalidades. Aquellas críticas o de mayor beneficio a menor costo serán las primeras en ser implementadas.

Al igual que en las técnicas de selección cuantitativas, hay dos enfoques, uno absoluto y otro relativo. En este caso el absoluto tiene sentido, sería el costo o beneficio en moneda de una determinada funcionalidad, pero requiere demasiado conocimiento del dominio. Para el relativo puede usarse nuevamente Analytic Hierarchy Process (AHP), que consiste en generar una tabla de n*n con todos los requerimientos y determinar cuánto más importante es uno que el otro, y luego normalizar los valores para generar un orden total. Otro enfoque más sencillo es comparar entre sí solamente los subobjetivos de un mismo nodo.

De todas maneras, el relativo se mantiene problemático por las incosistencias de los stakeholders, o la imposibilidad de comparar dos objetivos muy poco relacionados o demasiado dependientes.

Sea cual fuere el método que se elija, debe repetirse una vez para beneficio y otro para costo, y así generar el gráfico de Retorno de Inversion (ROI).