1.1 REQUERIMIENTOS DE PROCESO

PROCESO: proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un número de conjuntos de tareas –cada uno es una colección de tareas de trabajo de ingeniería del software, hitos de proyectos, productos de trabajo, y puntos de garantía de calidad que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección tales como garantía de calidad del software, gestión de configuración del software y medición abarcan el modelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

1.1.1 INGENIERIA DE REQUISITOS

La consecuencia del proceso de ingeniería de sistemas es la especificación de un sistema o producto basado en computadora que se describe genéricamente, en diferentes niveles en la Figura 10.1. Pero el desafío de la ingeniería del sistema (y de los ingenieros del software) es importante: ¿Cómo podemos asegurar que hemosespecificado un sistema que recoge las necesidades del cliente y satisface sus expectativas? No hay una respuesta segura a esta difícil pregunta, pero un sólido proceso de ingeniería de requisitos es la mejor solución de que disponemos actualmente.

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociandouna solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional [THA97]. El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos [SOM97]: Identificación de Requisitos, Análisis de Requisitos y Negociación, Especificación de Requisitos, Modelizado del Sistema, Validación de Requisitos y Gestión de Requisitos.

1.1.2 IDENTIFICACIÓN DE REQUISITOS

Antes que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a través de un proceso de obtención. Un cliente tiene un problemaque pretende sea resuelto con una solución basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. La comunicación ha empezado. Pero como ya hemos señalado, el camino de la comunicación al entendimiento está a menudo lleno de baches.

En principio, parece bastante simple -preguntar al cliente, a los usuarios y a los que están involucrados en los objetivos del sistema o producto y sean expertos,investigar cómo los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cómo el sistema o producto va a ser utilizado en el día a día-. Esto

que parece simple, es muy complicado.

Christel y Kang [CRI92] identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.

problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir

más que clarificar los objetivos del sistema.

problemas de comprensión. Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y

limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información o por considerar que es «obvia», especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables.

Problemas de volatilidad. Los requisitos cambian con el tiempo.

Para ayudar a solucionar estos problemas, los ingenieros de sistemas deben aproximarse de una manera organizada a través de reuniones para definirrequisitos.

Sommerville y Sawyer [SOM97] sugieren un conjunto de actuaciones para la obtención de requisitos, que están descritos en las tareas siguientes:

Valorar el impacto en el negocio y la viabilidad técnica del sistema propuesto;

Identificar las personas que ayudarán a especificar requisitos y contrastar su papel en la organización;

Definir el entorno técnico (arquitectura de computación, sistema operativo, necesidades de telecomunicaciones) en el sistema o producto a desarrollar eintegrar;

Identificar «restricciones de dominio» (características específicas del entorno de negocio en el dominio de la aplicación) que limiten la funcionalidad y rendimientos del sistema o producto a construir;

Definir uno o más métodos de obtención de requisitos (entrevistas, grupos de trabajo, equipos de discusión);

Solicitar la participación de muchas personas para que los requisitos se definan desde diferentes puntos de vista, asegurarse de identificar lo fundamental decada requisito registrado;

Identificar requisitos ambiguos como candidatos para el prototipado, y crear escenarios de uso para ayudar a los clientes/usuarios a identificar mejor los requisitos fundamentales.

El resultado alcanzado como consecuencia de la identificación de requisitos variará dependiendo del tamaño del sistema o producto a construir. Para grandes sistemas, el producto obtenido debe incluir:

Una relación de necesidades y características;

Un informe conciso del alcance del sistema o producto;

Una lista de clientes, usuarios y otros intervinientes que deben participar en la actividad de obtención de requisitos;

Una descripción del entorno técnico del sistema;

Una relación de requisitos (perfectamente agrupados por funcionalidad) y las restricciones del dominio aplicables a cada uno;

Un conjunto de escenarios que permiten profundizar en el uso del sistema o producto bajo diferentes condiciones operativas, y cualquier prototipo desarrollado para definir mejor los requisitos.

Cada uno de los productos obtenidos debe ser revisado por las personas que hayan participado en la obtención de sus requisitos.

1.1.3 ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan ensubconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.

Al iniciarse la actividad del análisis de requisitos se plantean las siguientes cuestiones:

¿Cada requisito es consistente con los objetivos generales del sistema/producto?

¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? Es decir, ¿algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa?

¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema?

¿Cada requisito está delimitado y sin ambigüedad?

Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o específico) conocido para cada requisito?

¿Existen requisitos incompatibles con otros requisitos?

¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto?

¿Se puede probar el requisito una vez implementado?

Es corriente en clientes y usuarios solicitar mas de lo que realizarse, consumiendo recursos de negocio limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que su versión es “esencial por necesidades especiales”.

El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificarsus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan ”estimaciones" del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando unprocedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.

1.1.3.1 INICIO DEL PROCESO

La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes): los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito. Sin embargo, hay que empezar la comunicación. Gause y Weinberg [GAU89] sugieren que el analista empiece preguntando cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarán a un entendimiento básico del problema, qué solución busca, la naturaleza de la solución que se desea y la efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría preguntar:

¿Quién está detrás de la solicitud de este trabajo?¿Quién utilizará la solución? ¿Cuál será el beneficio económico del éxito de una solución?¿Hay alguna otra alternativa para la solución que necesita?

Estas preguntas ayudan a identificar todos los participantes que tienen un interés en el software a construir. Además, las preguntas identifican los beneficios mediblesen una implementación correcta de posibles alternativas para un desarrollo normal del software. El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución:

¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena solución? ¿A qué tipo de problema(s) va dirigida esta solución? ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución? El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg [GAU89] las denominan «meta-preguntas» y proponen la siguiente lista (abreviada):

¿Es usted la persona adecuada para responder a estas preguntas?¿Sus respuestas son «oficiales»? ¿Estoy preguntando demasiado?¿Hay alguien más que pueda proporcionar información adicional?¿Hay algo más que debería preguntarle?

Estas preguntas (y otras) ayudarán a «romper el hielo » e iniciar la comunicación tan esencial para el éxito del análisis. Pero el formato de reunión tipo «pregunta y respuesta» no es un enfoque que haya tenido mucho éxito. De hecho, esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituirse después por una modalidad que combine elementos de resolución del

problema, negociación y especificación. En la siguiente sección se presenta un enfoque a reuniones de este tipo.

1.1.4 ESPECIFICACIÓN DE REQUISITOS

En el contexto de un sistema basado en computadoras (y software), el término especificación significa distintas cosas para diferentes personas. Una especificaciónpuede ser un documento escrito, un modelo gráfico, un modelo matemático formal, una colección de escenarios de uso, un prototipo o una combinación de lo anteriormente citado.

Algunos sugieren que debe desarrollarse una «plantilla estándar» [SOM97] y usarse en la especificación del sistema, argumentando que así se conseguirían requisitosque sean presentados de una forma más consistente y más comprensible. No obstante, en muchas ocasiones es necesario buscar la flexibilidad cuando unaespecificación va a ser desarrollada. Para grandes sistemas, un documento escrito, combinado con descripciones en lenguajes natural y modelos gráficos puede ser la mejor alternativa. En cualquier caso, los escenarios a utilizar pueden ser tanto los requeridos para productos de tamaño pequeño o los de sistemas que residan en entornos técnicos bien conocidos.

La Especificación del Sistema es el producto final sobre los requisitos del sistema obtenido por el ingeniero. Sirve como fundamento para la ingeniería del hardware,ingeniería del software, la ingeniería de bases de datos y la ingeniería humana. Describe la función y características de un sistema de computación y las restricciones que gobiernan su desarrollo. La especificación delimita cada elemento del sistema. La especificación del sistema describe la información (datos y control) que entra y sale del sistema.

1.1.5 MODELADO DEL SISTEMA

Considere por un momento que a usted se le ha requerido para especificar los requisitos para la construcción de una cocina. Se conocen las dimensiones del lugar, la localización de las puertas y ventanas y el espacio de pared disponible. Debes especificar todos los armarios y electrodomésticos e indicar dónde colocarlos. ¿Será una especificación válida?

La respuesta es obvia. Para especificar completamente lo que vamos a desarrollar, necesitamos un modelo de la cocina con toda su información, esto es, un anteproyecto o una representación en tres dimensiones que muestre las posiciones de los armarios y electrodomésticos, y sus relaciones. Con el modelo será relativamente fácil asegurar la eficiencia del trabajo (un requisito de todas las cocinas), la estética «visual» de la sala (es un requisito personal, aunque muy importante).

Se construyen modelos del sistema por la misma razón que desarrollamos para una cocina un anteproyecto o una representación en 3D. Es importante evaluarlos componentes del sistema y sus relaciones entre sí; determinar cómo están reflejados los requisitos, y valorar como se ha concebido la «estética» en el sistema.

MODELADO

Los modelos se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo físico (un edificio, un avión, una máquina), podemos construir unmodelo idéntico en forma, pero más pequeño. Sin embargo, cuando la entidad que se va a construir es software, nuestro modelo debe tomar una forma diferente. Debeser capaz de modelar la información que transforma el software, las funciones (y subfunciones) que permiten que ocurran las transformaciones y el comportamientodel sistema cuando ocurren estas transformaciones.

Modelo del proceso en cascada.

El modelo clásico del proceso de desarrollo de software es el modelo en cascada. Este es una secuencia de actividades (o etapas) que consiste en el análisis de requerimientos, el diseño, la implementación, la integración y las pruebas, como se ilustra en la figura 1.2.

Figura 1.2 Modelo en cascada.

El análisis de requerimientos consiste en reunir las necesidades del producto y casi siempre su salida es texto.

El diseño describe la estructura interna del producto y suele representarse con diagramas de texto.

Implementación significa programación. El producto de esta etapa es el código en cualquier nivel, incluido el producido por sistemas de generación automática de código, lenguajes de cuarta generación u otros.

La integración es el proceso de ensamblar las partes para completar el producto.

Estas etapas en realidad no se ejecutan en una secuencia estricta, ya que existe cierto traslape en entre las partes del proceso. La razón de este traslape es que suele ser poco practico completar totalmente una de estas etapas antes de comenzar la siguiente las etapas que muestra la figura 1.10 a menudo se aumentan con etapas adicionales como las siguientes:

Figura 1.3 Modelo en cascada mas detallado.

Análisis conceptual, al principio del proceso, donde se define la filosofía global del proyecto.

Análisis orientado a objetos entre el análisis de requerimientos y de diseño, donde se identifican las clases importantes.

Pruebas unitarias y del sistema, que marcan la distinción entre probar las partes de una aplicación y el todo.

Mantenimiento al final del proceso, donde se repara y modifica la aplicación para que continúe siendo útil.

En la figura 1.3 se muestra una versión completa del proceso en cascada, muy rara vez se realiza un proceso en cascada puro como el que se ilustra, excepto tal vez en proyectos pequeños. De cualquier manera, el proceso en cascada es la base o punto de referencia para la mayoría de los procesos y siempre debe considerarse como un proceso alternativo factible. Los procesos que emplea el diagrama en cascada repetidas veces se llaman iterativos, no es necesario aplicar todos los pasos de la cascada en cada iteración. A continuación se explican los procesos iterativos en espiral y por incrementos.

Modelo del proceso en espiral.

El proceso en espiral reconoce la necesidad de pasar por la secuencia análisis de requerimientos, diseño, implementación, pruebas mas de una vez. Existen varia razones una importante es la necesidad de eliminar los riesgos. Otra razón es construir una versión parcial preliminar del producto que se pueda mostrar al cliente para obtener retroalimentación; una razón mas es evitar la integración de una base de código grande todo ala ves, como lo pide el modelo del proceso en cascada, la idea es construir cada versión sobre el resultado de la anterior, este proceso repetitivo forma una especie de trayectoria en espiral, como se ilustra en la figura 1.4.

Figura 1.4 Desarrollo en espiral.

El proceso en espiral se ajusta al avance de los proyectos típicos, sin embargo, requiere una administración mucho más cuidadosa que la sencilla cascada, este cuidado adicional se debe al echo de que la documentación debe ser consistente siempre que el proceso termina una iteración completa. En particular, el código debe corresponder al diseño documentado y debe satisfacer los requerimientos documentados. Además con el propósito de optimizar la productividad del equipo, con frecuencia es necesario comenzar una nueva iteración antes de que la anterior haya terminado. Esto coloca una carga especial en la coordinación de la documentación.¿Cuántas iteraciones de la espiral son necesarias?Depende de la situación. Un proyecto típico de tres personas-mes con duración de cuatro meses tal vez requiere de dos o tres iteraciones

Modelo del proceso de incrementos.

En ocasiones es posible avanzar un proyecto con proceso casi continuo. Este modelo de proceso es en particular viable en las ultimas etapas del proyecto, cuando el producto esta en mantenimiento, o cuando el producto propuesto es muy similar al producto desarrollado antes. Por ejemplo, Cucumano y Selby informan acerca del proceso usado en partes de Microsoft Corporation, en el que las actualizaciones de código y documentación se entregaron a una hora fija cada día para su integración y prueba durante la noche. Otras organizaciones reportan programaciones semanales. A fin de manejar este grado de desarrollo por incrementos, la arquitectura debe haberse establecido con claridad y el sistema de documentación debe estar muy bien sincronizado. Para realizar un desarrollo por incrementos, lo normal es elegir un intervalo, digamos una semana. Todo el proyecto (documentación, pruebas, código, etcétera) se actualiza cada intervalo. En teoría, los incrementos pueden trabajarse en paralelo, pero es difícil coordinarlos. El desarrollo por incrementos funciona mejor si el incremento n+1 inicia mas o menos después que se determina la base del incremento n, y funciona peor si la preparación de las partes requiere mucho mas tiempo que el intervalo seleccionado. Para entender por que esto último es cierto, imagine que debe trabajar en el modulo 789, que depende de siete partes: 890,23 489, 991,7 653, 2 134 y2 314. Si el trabajo requiere nueve semanas, entonces el modulo 789 debe construirse según el estado pronosticado de las siete partes al final de las nueve semanas. Es muy fácil coordinar esto, por que cada una de las siete partes puede haber cambiado hasta nueve veces (una vez cada semana) y cada cambio puede depender del examen de la efectividad de los cambios anteriores.

Figura 1.5 Desarrollo por incrementos.

1.1.6 VALIDACIÓN DE REQUISITOS

El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidaden la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.

El primer mecanismo para la validación de los requisitos es la revisión técnica formal (Capítulo 8). El equipo de revisión incluye ingenieros del sistema, clientes, usuarios, y otros intervinientes que examinan la especificación del sistema5 buscando errores en el contenido o en la interpretación, áreas donde se necesitan aclaraciones, información incompleta, inconsistencias (es un problema importante), requisitos contradictorios, o requisitos imposibles o inalcanzables.

Aunque la validación de requisitos puede guiarse de manera que se descubran errores, es útil chequear cada requisito con un cuestionario. Las siguientes cuestiones representan un pequeño subconjunto de las preguntas que pueden plantearse:

¿Está el requisito claramente definido? ¿Puede interpretarse mal?

¿Está identificado el origen del requisito (por ejemplo: persona, norma, documento)? ¿El planteamiento final del requisito ha sido contrastado con la fuente original?

¿El requisito está delimitado en términos cuantitativos?

¿Qué otros requisitos hacen referencia al requisito estudiado? ¿Están claramente identificados por medio de una matriz de referencias cruzadas o por cualquier otro mecanismo?

¿El requisito incumple alguna restricción definida?

¿El requisito es verificable? Si es así, ¿podemos efectuar pruebas (algunas veces llamadas criterios de validación) para verificar el requisito?

¿Se puede seguir el requisito en el modelo del sistema que hemos desarrollado?

¿Se puede localizar el requisito en el conjunto de objetivos del sistema/producto?

¿Está el requisito asociado con los rendimientos del sistema o con su comportamiento y han sido establecidas claramente sus características operacionales? ¿El requisito está implícitamente definido?

Las preguntas planteadas en la lista de comprobación ayudan a asegurar que el equipo de validación dispone de lo necesario para realizar una revisión completade cada requisito.

1.1.7 GESTIÓN DE REQUISITOS

En el capítulo anterior se advertía que los requisitos del sistema cambian y que el deseo de cambiar los requisitos persiste a lo largo de la vida del sistema. La gestiónde requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.

Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza con la actividad de identificación. A cada requisito se le asigna un Único identificador, que puede tomar la forma:

<tipo de requisito><requisito n.' >

El tipo de requisito toma alguno de los siguientes valores: F = requisito funcional, D = requisito de datos, C =requisito de comportamiento, Z = requisito de interfaz,y S = requisito de salida. De esta forma, un requisito identificado como F09 indica que se trata de un requisito funcional y que tiene asignado el número 9 dentro de los citados requisitos.

Una vez los requisitos han sido identificados, se desarrollarán un conjunto de matrices para su seguimiento. En la Figura 10.4 se muestra de forma esquemática este planteamiento. Cada matriz de seguimiento identifica los requisitos relacionados con uno o más aspectos del sistema o su entorno.

Entre las posibles matrices de seguimiento citamos las siguientes:

Matriz de seguimiento de características. Muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto.

Matriz de seguimiento de orígenes. Identifica el origen de cada requisito.

Matriz de seguimiento de dependencias. Indica cómo se relacionan los requisitos entre sí.

Matriz de Seguimiento de subsistemas. Vincula los requisitos a los subsistemas que los manejan.

Matriz de seguimiento de interfaces. Muestra como los requisitos están vinculados a las interfaces externas o internas del sistema.

En muchos casos, las matrices de seguimiento se incorporan como parte de un requisito de base de datos y se utiliza para buscar rápidamente los diferentes aspectos del sistema a construir afectados por el cambio de requisito.