TEMA 1 EL ENFOQUE PROYECTO EN LA INGENIERIA DEL SOFTWARE PARTE I.1.1.- El enfoque proyecto,

1-1

1.2.- El ciclo de vida de las aplicaciones informáticas.,

1-3

1.2.1.- El modelo en cascada.,

1-4

1.2.2.- El modelo prototipos.,

1-7

1.2.3.- Modelo de desarrollo en versiones sucesivas.,

1 - 10

1.2.4.- Modelo de transformación.,

1 - 11

1.2.5.- El modelo en espiral,

1 - 12

PARTE II 1.3.- Introducción a la gestión de requisitos.

1 - 15

1.4.- El proceso de la ingeniería de requisitos

1 - 18

1.5.- Estándares en la especificación de requisitos de un sistema software (ERS)

1 - 22

1.5.1.- Naturaleza de las ERS

1 - 23

1.5.2.- Caracteristicas de las ERS

1 - 24

1.6.- Especificación formal de los requisitos

1 - 32

1.7.- Lenguajes gráficos para la definición de requisitos. El diagrama de flujo de datos

1 - 33

1.7.1.- Descomposición por niveles

1 - 34

1.7.2.- Notación

1 - 38

1.7.3.- Consistencia de los diagramas de flujo de datos

1 - 40

i

PARTE I.El presente Tema, que es el primero del curso de Proyectos Informáticos, pretende formalizar el enfoque de la realización de los Proyectos Informáticos, para lo cual se ha descompuesto en dos partes que, a nuestro entender, son fundamentales:

- Parte I: El ciclo de vida, en el que se estudian las abstracciones que permiten realizar un Proyecto Informático de una manera u otra, siguiendo unas u otras fases o actividades, y encadenando una u otras etapas. Parte II: Estudio de los requisitos que debe satisfacer un sistema software. Este apartado tiene como objetivo la correcta definición de qué es lo que se pretende resolver con un Proyecto Informático

Es evidente para los autores del presente curso que estas dos partes definen lo verdaderamente importante de un Proyecto Informático.

1.1.- El enfoque proyecto Un proyecto es un conjunto de tareas y actividades, limitadas en el tiempo, encaminadas a alcanzar un objetivo bien definido, en un plazo determinado y con unos recursos dados (humanos, materiales, presupuestarios, etc...). Un proyecto se caracteriza por tanto por un conjunto de factores: •

Concreción: objetivo definido

•

Unicidad: responde a una demanda o necesidad puntual.

•

Dominio de aplicación.

•

Flexibilidad en la asignación de recursos.

•

Duración limitada: los objetivos, los plazos, los recursos y el coste están íntimamente relacionados.

Cada proyecto tendría pues un objetivo bien definido y se subdividirá en fases y/o tareas, utilizará un determinado número de recursos: personas, horas-máquina, subcontrataciones, etc ..., y será dotado de un presupuesto que incluya el costo de los recursos, con una duración determinada o plazo de ejecución.

1-1

En la medida en que hay que asignar recursos a un objetivo un proyecto debe ser gestionado, y la gestión del mismo permite controlar a que finalidad va dirigido (objetivo), como enfocarlo (planificación de tareas y recursos) y seguirlo para saber en todo momento su estado (seguimiento). La gestión de proyectos, en general, sigue un ciclo que comprende cuatro grandes etapas: 1.- Iniciación del proyecto: Da origen al proyecto y fija los objetivos que ha de alcanzar así como el plazo de ejecución. 2.- Calificación del proyecto: permite evaluar globalmente la carga de trabajo necesaria para la realización del proyecto. Esta etapa puede subdividirse en otras tres: 2.1.- Estimación de cargas y coste. 2.2.- Estimación de riesgos. 2.3.- Decisión o rechazo de emprender el proyecto. 3.- Desarrollo del proyecto: o más exactamente realización y control del desarrollo del proyecto, que comprende a su vez cuatro actividades. 3.1.- Planificación y descomposición en fases o tareas. 3.2.- Lanzamiento del proyecto: Ejecución y desarrollo. 3.3.- Seguimiento y control del proyecto. 3.4.- Cierre de fases. 4.- Cierre del proyecto.

Estas consideraciones que son válidas con carácter general, lo son también para los proyectos informáticos. Un proyecto informático no es más que un proyecto cuyo objetivo está enmarcado en el plan general informático de la empresa (conocido como plan de sistemas o esquema director). Por tanto nace dentro de un plan más amplio y en relación con el sistema de información de la empresa. La peculiaridad más específica de todo proyecto informático se deriva de la división en fases y de los procesos de evaluación de cargas y riesgos.

1-2

La aplicación de los métodos de la ingeniería a los proyectos informáticos es lo que ha dado lugar al conjunto coherente de técnicas conocidas como Ingeniería del Software. Una definición posible es: la ingeniería del software es la aplicación práctica del conocimiento científico al diseño y construcción de programas, y la documentación necesaria para el desarrollo, operación y mantenimiento de los mismos. La definición anterior, de Barry W. Boehm (en Software Engineering, IEEE Transactions on Computers, Diciembre 76) centra la ingeniería del software en la construcción de programas, como si sólo ésta fuese la actividad de los informáticos lo que no puede mantenerse hoy, pero a los efectos de nuestra materia continua siendo válida. Tres cuestiones resaltan de la definición de B.W. Boehm: - la necesidad de considerar en sentido amplio el concepto de diseño que cubre la actividad de especificaciones y requerimientos del software, y la ingeniería asociada. - la definición se aplica y debe cubrir la totalidad del ciclo de vida del software (que se tratará en detalle en el punto 1.2.), incluyendo aquellas actividades de rediseño y modificaciones, conocidas como mantenimiento del software. - finalmente hay que resaltar que lo que se pretende como "conocimiento científico" es más bien escaso para pretender construir sobre él toda una disciplina ingenieril, en el ámbito d proyectos informáticos.

Con estas particularidades un proyecto informático se compone, al igual que un proyecto en general, de cuatro fases principales específicas: - Definición: especificaciones y requerimientos. - Diseño: preliminar, detallado y técnico. - Desarrollo: codificaciones y pruebas. - Integración: implementación, operación y mantenimiento que son las que se tomaran como referencia en este tema, y en las que hay un acuerdo generalizado entre todos los profesionales (el que las diez funciones descritas se agrupen en estas cuatro fases o en otras no tiene importancia aquí).

1.2.- El ciclo de vida de las aplicaciones informáticas.

1-3

Una aplicación informática es un conjunto de programas que pretenden dar respuesta a una necesidad o problema expresado, y cuya solución es objeto de desarrollo generando un proyecto de desarrollo informático. Las unidades elementales de la aplicación que se consideran aquí son los programas, si bien pueden ser consideradas como tales, entidades de menor nivel como : funciones, módulos reutilizables, rutinas, etc. Independiente del tamaño o complejidad en el desarrollo de todo programa hay dos pasos fundamentales: el análisis y la codificación (aunque hay otros pasos importantes en el ciclo del software, ninguno de ellos contribuye tan directamente al producto final como éstos), que en el caso de proyectos elementales son casi las únicas que se consideran.

ANÁLISIS

CODIFICACIÓN

Fig. 1. Fases para la implantación de un programa pequeño. No obstante si la función que se quiere resolver es compleja una división en estas fases es demasiado elemental: en las aplicaciones informáticas se sigue un ciclo más completo, como refleja la figura 1.2, formando una sucesión de fases conocidas como ciclo de vida del software o ciclo de vida de las aplicaciones informáticas.

1.2.1.- El modelo en cascada. La figura 1.2. describe la sucesión de etapas en un proyecto informático. Esta sucesión implica un encadenamiento entre ellas, y según el modo en que se produzcan da lugar a diferentes modelos de ciclos de vida, algunos de los cuales serán estudiados : cascada prototipos, espiral, etc... Hay otros modelos que no se tratan aquí como, por ejemplo, el de desarrollo evolutivo que supone, una evolución positiva en la reducción del impacto que los errores en una fase del ciclo de vida tiene sobre las posteriores. En el artículo de B.W. Boehm en que presentó el modelo en espiral (IEEE Transactions on Software Engineering, de Mayo 88) son analizados estos modelos del ciclo de vida. Básicamente se considerarán cinco modelos: en cascada, prototipos, versiones sucesivas, de transformación y en espiral.

1-4

Antes de estudiar cada uno de ellos se describen el contenido y alcance de cada fase o etapa.

SISTEMA

REQUERIMIENTOS DEFINICIÓN

SOFTWARE

ANÁLISIS

ESPECIFICACIÓN DISEÑO

DISEÑO PROGRAMAS CODIFICACIÓN DESARROLLO PRUEBAS INTEGRACIÓN OPERACIÓN

IMPLEMENTACIÓN

Fig. 2. Ciclo de vida del Software El primer estado en el ciclo de vida del software es la correcta comprensión del problema a resolver y los requerimientos que ha de cumplir la solución adoptada. Estos requerimientos pueden haber sido dados por el usuario final o, si el proyecto software está incluido en otro proyecto más amplio, pueden derivarse del sistema final a construir como un subconjunto. Los requerimientos incluyen el contexto en que ha de encontrarse el problema a resolver, las funcionalidades que se espera resuelva el sistema a desarrollar, y las restricciones o condiciones de uso. En la fase de especificaciones los especialistas software intentan comprender los requerimientos y definir las especificaciones que los satisfacen. Estas especificaciones describen la conducta externa del sistema: lo que se supone que debe hacer, no cómo lo hace. Deben

ser

verificados

para

asegurar

que

las

especificaciones

concuerden

con

los

requerimientos: sin omisiones, inconsistencias o ambigüedades. Estas especificaciones son el punto de partida para el diseño, cuya finalidad es describir cómo el sistema a construir va a implantar o desarrollar las especificaciones.

1-5

Dado que el sistema total final puede ser muy complejo, el objetivo del diseño es la descomposición: el sistema es dividido en módulos e interacciones entre módulos. Estos módulos pueden a su vez ser subdivididos en submodulos, tareas y procedimientos, hasta que cada unidad final sea lo bastante elemental como para ser implementada (es decir: desarrollada, verificada y puesta en funcionamiento) fácilmente. Ello da lugar a la descomposición en programas. Durante la fase de desarrollo o codificación cada módulo, programa, es codificado en el lenguaje de programación adecuado. Se incluye en esta fase las pautas necesarias para verificar el correcto funcionamiento de cada módulo por separado. Una vez cada módulo ha sido desarrollado y probado se procede a la última fase: integración, implementación y operación del sistema construido. En esta fase se prueba el sistema en su integridad poniendo especial énfasis en las interacciones y encadenamiento entre programas, se pone en funcionamiento (implementa) el sistema y se elabora la documentación necesaria para la operación o uso del sistema. Hay que tener en cuenta que un sistema software es una entidad que sufre modificaciones dinámicamente, lo que obliga a realizar un previsión de mantenimiento del sistema o aplicación para asegurar que continúa satisfaciendo los requerimientos cuando éstos cambian. Con el paso del tiempo y el uso de la aplicación esta función de mantenimiento es la que más recursos consume de todo el ciclo de vida. Este modelo de ciclo de vida puede verse como una serie de etapas que se siguen unas a otras en "cascada", tal como se observa en la figura adjunta.

1-6

REQUERIMIENTOS ESPECIFICACIONES DISEÑO CODIFICACIÓN PROGRAMAS PRUEBA PROGRAMAS INTEGRACIÓN OPERACIÓN MANTENIMIENTO

Fig. 3.: El ciclo de vida: modelo en cascada

1.2.2.- El modelo prototipos. El principal problema que presenta el modelo de ciclo en cascada es que hasta la fase de integración pueden aparecer errores que obligan a una vuelta atrás hasta la fase de diseño en muchos casos, ya que un error de especificación y/o diseño no se detecta hasta el final, en la integración. Este modo de proceder ha puesto en cuestión este modelo de ciclo de vida, dando lugar a variantes, una de las cuales es conocida como prototipos. Un prototipo es un modelo a escala reducida de la solución final y sirve para verificar que las especificaciones han sido construidas de acuerdo a los requerimientos del sistemas. La función de un prototipo es obtener un modelo del sistema que se va a desarrollar. Este modelo simula el comportamiento externo, aquél al que se enfrentará el usuario, del nuevo sistema. Es por ello que el prototipo se desarrolla siguiendo fielmente las indicaciones del usuario final y es el complemento de los requerimientos. La principal ventaja obtenida de usar este tipo de elementos es que se dispone en una fase muy temprana de unos requerimientos completos, y de un modelo que facilita la construcción del sistema, al menos en lo que respecta a la interface con el usuario.

1-7

Los principales inconvenientes del uso de este modelo proceden de la tentación de considerar al prototipo como una primera versión del software en desarrollo, y en consecuencia, tomarlo como base del desarrollo posterior. El prototipo, construido habitualmente en un lenguaje interpretado, o con alguna herramienta especialmente dedicada a este propósito, sólo puede ser aprovechado en su aspecto externo como base para el trabajo posterior. Los aspectos funcionales de un prototipo o son muy reducidos o carecen de estructura adecuada.

1-8

En

este

caso

el

ciclo

de

vida

asociado

queda

siguiente:

REQUERIMIENTOS

ESPECIFICACIONES

PROTOTIPO

EVALUACIÓN USUARIO Fase A

DISEÑO

CODIFICACIÓN PROGRAMAS

PRUEBAS

INTEGRACIÓN

OPERACIÓN Fase B

Fig. 4. Ciclo de vida prototipo Este modelo divide el ciclo de vida en dos grandes fases: Fase A: diseño, construcción y evaluación de un prototipo.

1-9

del

modo

Fase B: diseño, desarrollo y prueba de programas, e integración del sistema total. El objetivo de la fase A es verificar la adecuación del sistema que se va a desarrollar a los requerimientos expresados por el usuario. Exige una evaluación por parte de éste: una vez el prototipo aceptado ya se tiene un modelo a escala del sistema completo que hay que construir. El punto de entrada en la fase B es el prototipo construido y aceptado en el que se han detallado los diseños de pantalla y listados, los encadenamientos de módulos y los flujos de datos. Con estas informaciones contrastadas ya se tiene la descomposición en programas, con lo que este modelo de ciclo de vida en la fase B se ocupa del desarrollo y prueba de los programas y de la integración de los mismos en la solución final. La principal ventaja de este modelo es su mayor productividad ya que al poder detectar errores de especificaciones en el prototipo no hay que esperar a la fase de integración (en la que todo el sistema ya ha sido construido) con lo que la vuelta a a atrás (si procede) es mucho más temprana y menos costosa. A la mayor productividad contribuye asimismo la aparición de lenguajes y facilidades para la construcción de prototipos que hacen que su construcción sea muy rápida.

1.2.3.- Modelo de desarrollo en versiones sucesivas. Este modelo de ciclo de vida pretende resolver uno de los problemas del modelo en cascada: la tardía aparición de un modelo funcional del sistema en desarrollo. Para ello se realiza una serie de iteraciones sobre el propio modelo en cascada. En la primera se obtiene una primera versión del sistema. En cada una de las demás iteraciones el modelo se refina hasta alcanzar una versión definitiva que satisfaga plenamente los requerimientos de usuario. En cada iteración, se reelaboran los requerimientos según se encuentren carencias o inexactitudes con la idea original del usuario. Los nuevos requerimientos se someten a análisis, se modifican los diseños, y se procede a las modificaciones pertinentes del código. Finalmente se procede a probar la nueva versión del modelo. Si el resultado obtenido se ajusta a los deseos del usuario, el proceso finaliza, en caso contrario se procede a una nueva iteración.

1 - 10

Fig. 5. Modelo de costes del desarrollo Las versiones obtenidas pueden obedecer también a un único plan inalterable. En este caso lo que se hace es realizar una implementación gradual de los requerimientos, en la que se pasa de un esbozo funcional a versiones cada vez más refinadas y cercanas a las especificaciones. En esta forma se denomina modelo evolutivo. Los principales inconvenientes de este paradigma están en las tareas de modificación de código, que resultan complejas y sujetas a errores salvo que se haga uso de herramientas automáticas o lenguajes de cuarta generación. Otro problema es que las posibles incorrecciones, o los "parches" incorporados a una versión, permanecen en ella y se convierten en la base para el código posterior. De esta forma, una mala estructuración, arquitectura defectuosa o soluciones parciales que sirven para hacer operativamente correcta una versión, degradan el trabajo invertido en la construcción de las siguientes.

1.2.4.- Modelo de transformación.

1 - 11

Este modelo trata de resolver los problemas asociados a la dificultad de modificar el código en paradigmas como el de versiones sucesivas. Para ello parte de la premisa de la existencia de un sistema que pueda convertir fácilmente los requerimientos en código. Los pasos seguidos en este modelo son: •

Una especificación formal del sistema.

•

Una transformación automática (o asistida) de las especificaciones a código.

•

Una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.

•

Prueba general del resultado.

•

Iteraciones para ajustar el resultado a las especificaciones. Si se realiza alguna modificación sobre éstas se repite el proceso hasta que requerimientos y código final sean válidos.

La principal dificultad para la aplicación de este modelo de desarrollo está en la falta de un sistema adecuado para transformar los requerimientos en código. Esta transformación puede ser llevada a cabo en pequeños proyectos dedicados a tareas específicas, pero no es posible generalizar su aplicación.

1.2.5.- El modelo en espiral El modelo en espiral se basa en una serie de iteraciones en las que se cumplen unos objetivos definidos previamente. Una de estas iteraciones puede estar dedicada a la elaboración de un estudio de viabilidad, de los requerimientos, al trabajo de diseño, a la obtención de prototipos funcionales, a la depuración, a la ampliación de los resultados,... La figura siguiente refleja el modelo del ciclo de vida en espiral.

1 - 12

DEFINICIÓN DE REQUERIMIENTOS Identificar y resolver riesgos

Determinar objetivos, alternativas y restricciones

Evaluar alternativas Definición de requerimientos

Análisis y negociación de requerimientos Prototipo operativo

INICIO DOCUMENT. REQUERIM. E INFORME VALIDAC.

REQUERIM. ACORDADOS

Validación de requerimientos

Documentación de requerimientos

BORRADOR DOC. REQUERIMIENTOS

Fig. 6. Modelo en espiral. Lo que distingue fundamentalmente este modelo de los anteriores, es su consideración del riesgo, y de los aspectos económicos del desarrollo. Mientras otros modelos atienden fundamentalmente a la elaboración de unos requerimientos adecuados, o a favorecer el mantenimiento, o simplemente a completar satisfactoriamente la construcción de un sistema software, el modelo de Boehm pretende atender también al coste de estas actividades, que muchas veces actúa como la restricción más poderosa en los procesos de elaboración del software. El modelo espiral se basa en el ciclo de desarrollo en cascada, pero en vez de ser una concepción lineal del proceso de construcción del software, lo ve como un proceso iterativo en el que los avances se hacen gradualmente y en el que se prepara rigurosamente cada paso.

Cada ciclo de la espiral comienza con la identificación de ciertos elementos fundamentales para el trabajo posterior: •

Los objetivos del producto que va a ser construido: funcionalidad, y de rendimiento.

•

Alternativas para el desarrollo: otros diseños, reuso de elementos ya conocidos.

1 - 13

•

Las limitaciones impuestas a la aplicación de las alternativas.

El siguiente paso es la evaluación de las alternativas fijando la atención en los objetivos y las limitaciones establecidos. Durante este proceso se suelen identificar las fuentes de incertidumbre para el desarrollo. El siguiente paso es la identificación de estas incertidumbres, y la formulación de estrategias para resolver problemas asociados a ellas. Cuando se han evaluado los riesgos para el desarrollo, las acciones siguientes están determinadas por los resultados obtenidos. Si se presenta la oportunidad de elaborar un prototipo del sistema de una forma económica y robusta, se procede a ello. Mientras este prototipo no se ajuste al resultado esperado se sucederá el ciclo de elaboración. Cuando el prototipo (en realidad el interface de usuario) es satisfactorio, el proceso se orienta a la obtención de aspectos funcionales del sistema. Las sucesivas versiones del sistema incrementan sus capacidades en cada ciclo de acuerdo con los objetivos marcados y las limitaciones impuestas, y respetando las condiciones para evitar la materialización de los riesgos identificados. Antes de cada nueva iteración se procede a evaluar la anterior. Se valora hasta qué punto se han alcanzado los objetivos marcados y se han respetado las limitaciones impuestas. También se revisan los planes elaborados para el próximo ciclo y los riesgos detectados. Aumentando el control se pretende reducir los posibles inconvenientes que pudieran surgir durante cada ciclo. La monitorización del proceso sirve también para identificar el momento en que la espiral debe terminar. Aunque las condiciones de cada ciclo llevan implícitas los objetivos finales del proceso, es necesaria una evaluación continua para asegurar el cumplimiento de las condiciones de finalización del trabajo. Según Boehm, las ventajas obtenidas de emplear este modelo frente a otros se resumen en que dada la gran cantidad de opciones disponibles se puede obtener un trabajo que haga uso de los mejores elementos de los restantes modelos de desarrollo, y gracias a la continua evaluación de riesgos, se evita caer en los problemas de estos modelos. Indica también que potencia la reusabilidad, la incorporación de mecanismos de calidad, la preparación del mantenimiento, la consideración igualitaria de este proceso y del desarrollo, la eliminación temprana de errores y alternativas poco atractivas, y constituye un marco en el que se integra el desarrollo de hardware y software. Por contra, estima que precisa todavía algunos refinamientos antes de presentarse como una sola solución para la construcción del software para usuarios externos a la

1 - 14

organización de desarrollo. También cree Boehm que depende en exceso de la habilidad personal para identificar los factores de riesgo del desarrollo, y que hay un exceso de trabajo adicional en la elaboración de los nuevos pasos.

1 - 15

PARTE II.1.3.- INTRODUCCION A LA GESTION DE REQUISITOS.Uno de los principales problemas asociados a la producción y desarrollo de productos software es el relacionado con la exacta definición de qué es lo que tiene que realizar el software, en qué condiciones debe utilizarse, es decir: la especificación de los requisitos que dicho software debe satisfacer, así como la gestión de los requisitos del cliente que lo demanda. Los requisitos son especificaciones de los servicios / funciones que el sistema debe proporcionar a quienes lo utilizan, de las restricciones y condiciones de uso del mismo y de la información que se precisa para su desarrollo. Asociado a los requisitos se viene desarrollando lo que se denomina ingeniería de requisitos que se puede definir como el proceso sistemático de definición, comprensión, análisis y documentación de dichos requisitos. Como su propio nombre indica los requisitos de un sistema definen lo que se le requiere a dicho sistema y las circunstancias bajo las que se espera funcione. En otras palabras los requisitos definen los servicios que el sistema debe proporcionar a los usuarios y las restricciones y condiciones de uso del mismo. Algunos ejemplos de requisitos serian los siguientes: 1.-El sistema debe mantener registro de todos los libros, revistas, informes, colecciones de transparencias, CD-ROMs, etc.,, 2.-El sistema debe permitir recuperar una información por titulo, autor o ISBN. 3.-El sistema debe soportar, como mínimo, 20 usuarios, y ofrecer un tiempo de respuesta no mayor de 8 segundos. 4.-La interfaz de usuario del sistema debe ser compatible con un navegador Web. .. Estas informaciones son, evidentemente, incompletas, y deben ser complementadas con una más detallada especificación del sistema. En el caso anterior se ve que los requisitos pueden ser de diferentes tipos: Requisitos de carácter general, caso 1, que pueden ser vistos en términos amplios como lo que el sistema debe hacer. Requisitos funcionales, caso 2, que definen las funcionalidades del sistema. 1 Requisitos de rendimiento, caso 3. Requisitos de implementación, caso 4. Dado que los requisitos son de muy diferentes tipos no es posible definir un único procedimiento estándar de especificación de los mismos. Depende del cliente que expresa sus necesidades, del técnico que escribe los requisitos, de quien es previsible que los lea, de las prácticas de documentación usuales en la organización, del dominio de aplicación al que se refiere el sistema software en estudio, etc,.. Como los requisitos son expresión de lo que se le requiere al sistema, la descripción de los mismos puede incluir otros tipo de informaciones que deben ser incorporadas en la implementación del sistema, pero que no están expresados en términos de servicios o 1

La distinción entre requisitos funcionales y no funcionales se refiere a que los primeros describen lo que el sistema debería hacer; mientras que los no-funcionales sitúan las restricciones de cómo estos requisitos funcionales son implementados. Por ejemplo: un requisito funcional podría ser la exigencia de autenticación de los usuarios; un requisito no-funcional establecería que esta autenticación debería completarse (por ejemplo) en 4 segundos o menos.

1 - 16

restricciones del mismo. Suelen ser informaciones relativas al tipo de sistema que esta siendo implementado, sobre los estándares que deben ser observados, sobre otros sistemas que deben interactuar con nuestro sistema, etc,..Existen también requisitos que pueden considerarse implícitos, es decir que el cliente no nos los dice expresamente, pero que el estado del arte del dominio los considera imprescindibles, por ejemplo: interfaces con productos Ofimáticos de uso generalizado, tiempos de respuesta no excesivos, utilización de estándares cuando sea posible, etc,.. Muchos de los problemas que aparecen en los sistemas software una vez en utilización se derivan de problemas aparecidos, o no detectados, en la fase de análisis y/o especificación de los requisitos. Así, problemas comunes son: Los requisitos no reflejan las necesidades reales del cliente del sistema software. Los requisitos son inconsistentes y/o incompletos. Es difícil introducir cambios en los requisitos una vez estos han sido consensuados entre cliente y desarrollador. Hay una falta de entendimiento entre clientes y aquellos que desarrollan el sistema software . … Se puede aclarar esto con el ejemplo antes descrito. Uno de los requisitos expresados es: poder recuperar una información por titulo, autor o ISBN. En el caso de que el soporte sea una colección de transparencias, puede tener un titulo, y autor, pero, desde luego, carece de ISBN. Este es un requisito que se aplica solo a libros, pero no a revistas (que tienen un ISSN) o a otros soportes. Si este requisito no se amplia o corrige los desarrolladores deberán decidir qué decisiones tomar para la recuperación de documentos en otros soportes distintos a los libros. De acuerdo con los diferentes modelos del ciclo de vida estudiados en la Parte I de este Tema, los requisitos constituyen una fase temprana en el ciclo de vida. En el caso del modelo en cascada seria el reflejado en la figura 1 adjunta.

1 - 17

Requisitos

Diseño

Codificación

Integración

Operación

Fig. 1.- El modelo del ciclo de vida en cascada.

La fase de requisitos incluye el análisis del problema software en estudio y concluye con una especificación2 completa del comportamiento externo (es decir, lo que el sistema debe hacer sin especificar cómo lo hace) deseado del sistema software a construir.

Los requisitos son, pues, definidos durante las fases iniciales del desarrollo del sistema como una especificación de lo que debe ser realizado e implementado. Debe haber descripciones de cómo debe comportarse el sistema, de las condiciones de operación del mismo, de alguna propiedad o característica del mismo, e, incluso, en ocasiones existen restricciones sobre el proceso de desarrollo. Un requisito debe describir: -

-

Una facilidad para el usuario del sistema software; por ejemplo: documentación en línea. Una propiedad del sistema; por ejemplo: controlar los usuarios que acceden al sistema. Una restricción especifica del sistema; por ejemplo: se precisa que el tiempo de respuesta sea inferior a 10 segundos.. Cómo realizar un cálculo determinado; por ejemplo: cómo proceder al cálculo de totales y redondeo en una factura. O el formato de una salida: por ejemplo: una factura o un pedido o listado solicitado Cómo debe realizarse el desarrollo: por ejemplo utilizar tal o cual lenguaje de programación, o metodología de desarrollo, o herramienta CASE3

2

Las especificaciones son un documento que describe de manera clara y precisa cada uno de los requisitos básicos del sistema, sean estos funcionales, de rendimiento, de diseño, de calidad, de adecuación a estándares, etc,.. 3 Las herramientas CASE son útiles para el proceso de desarrollo. CASE: Computer Aided Software Engineering.

1 - 18

Por ello, los requisitos se refieren a un conjunto de problemas, conductas del sistema, forma de desarrollarlo, restricciones de utilización, etc,.., que precisan de un modo de enfocarlos sistemático y estructurado conocido como ingeniería de requisitos. Con esta denominación se pretende cubrir todas las activi dades implicadas en el análisis, documentación y mantenimiento del conjunto de requisitos que un sistema software debe satisfacer. El uso del término ‘ingeniería’ implica que se emplean técnicas sistemáticas y repetibles para asegurar que los requisitos son 4: completos, consistentes, relevantes, … Estas actividades deberían incluir: información sobre lo que el sistema debe realizar y cómo, análisis y negociación de los requisitos, y validación de los mismos realizada conjuntamente por el desarrollador del sistema y el cliente. La descripción completa del proceso debiera, asimismo, incluir el detalle de qué actividades se realizan, la planificación de las mismas, quien es responsable de cada una de ellas, las entradas / salidas de cada actividad y los útiles usados en el proceso de ingeniería de requisitos.. Muy pocas organizaciones tienen estandarizado y bien definido el proceso de obtención de los requisitos, dejando, generalmente, a la responsabilidad de los técnicos implicados la definición de decidir qué hacer y cómo, qué información y qué útiles se usaran, etc,..Se trata por tanto de una fase del ciclo de vida que esta muy poco ‘tecnificada’ , a pesar que los informes y estudios existentes estiman que el coste de esta fase llega a suponer en torno al 15 % del presupuesto total5 de desarrollo e implantación de un nuevo sistema software.

1.4.- EL PROCESO DE LA INGENIERIA DE REQUISITOS.Un proceso, y la definición y acuerdo sobre los requisitos que debe satisfacer un sistema software es un proceso, es un conjunto organizado de actividades que transforman entradas en salidas. En el caso de un sistema software la definición del proceso aparece tal como se detalla en la figura siguiente.

4

No debería confundirse el término ingeniería de requisitos con el de ‘análisis de sistemas’, ya que este esta más enfocado al problema de negocio, que al resto de aspectos aquí enunciados. 5 Estimación de Kotonya, G; Sommerville, I. Requirements Engineering. John Wiley& Sons, 1997

1 - 19

Información existente Necesidades cliente Estándares organización

PROCESO DE INGENIERIA DE

Legislación

Requisitos acordados

REQUISITOS

Información sobre dominio

Especificación sistema Modelo sistema

Fig. 8.- Entradas y Salidas del proceso de ingeniería de requisitos.

El significado que tienen cada una de las casillas de dicha figura es el siguiente. Información existente: Se trata de información relativa a la funcionalidad de los sistemas que deben ser sustituidos por el sistema software en desarrollo. Necesidades del cliente: Descripción de lo que los usuarios del sistema en estudio necesitan como soporte de su trabajo. Estándares de la organización: Son los estándares utilizados en la organización relativas a las prácticas de desarrollo, de aseguramiento de la calidad, de controles, etc,.. con lo que el sistema en estudio debe ser conforme. Legislación: Se trata de las regulaciones que pueden afectar al sistema, como puede ser de seguridad, de ergonomía, sanitarias, etc,..que deben ser contempladas por el sistema. Información sobre el dominio: Información general sobre el dominio de aplicación del sistema. Requisitos acordados: Una descripción de los requisitos del sistema, escrita de modo comprensible por el cliente, y que han sido acordados con él. Especificación del sistema:; Es una descripción más detallada de las funcionalidades del sistema. No es necesaria en todos los casos, pero es un complemento o ampliación que puede ser producido en algunas ocasiones. Modelo del sistema: Un conjunto de modelos, tales como diagramas de flujos de datos, modelos de casos de uso, modelos de procesos, etc,.. que describen el sistema desde diferentes perspectivas. La realización de este conjunto de actividades suele agruparse en diferentes fases, tal como se describe en la figura adjunta.

1 - 20

Definic. Requisitos

Necesidades usuario, información dominio, regulaciones, estándares,..

An.y Neg. Requisitos

Docum. Requisitos

Validac. Requisitos

Documento requisitos Especificaciones sistema

Requisitos acordados

Fig. 3.- Modelo de actividades del proceso de ingeniería de requisitos.

Las actividades contemplan las funciones siguientes. Definición de requisitos: Los requisitos del sistema se descubren a través dialogo con el cliente, de consulta de la documentación existente, del conocimiento del dominio de aplicación o negocio y de estudios de mercado. Análisis y negociación de requisitos: Los requisitos son analizados en detalle, y se establece un dialogo y negociación con el cliente (o con los diferentes clientes: quien encarga el sistema, quien lo va a utilizar, quien es el responsable de su implantación, etc,..) para decidir qué requisitos se aceptan finalmente y cuales no. Este proceso es necesario, ya que pueden aparecer conflictos entre los diferentes implicados en el sistema, así como entre los requisitos según fuentes y documentación consultada, a causa de la incompleta información (que requiera hacer hipótesis), o por problemas de presupuesto o plazo para el desarrollo y puesta en operación del sistema. Documentación de los requisitos: Los requisitos acordados con el cliente deben ser documentados a un adecuado nivel de detalle. En general es preciso producir una documentación comprensible por todos los implicados en la negociación de los requisitos, aunque puedan completarse con documentación adicional: diagramas, modelos, etc.. Validación de requisitos. Los requisitos han de ser objeto de un cuidadoso análisis para verificar que con completos y consistentes. La validación pretende detectar problemas en los requisitos antes de que esta documentación sea utilizada como base del diseño y desarrollo del sistema. La figura siguiente pretende situar en el modelo del ciclo de vida en cascada el lugar y momento en que se estudian y documentan cada uno de los requisitos del sistema.

1 - 21

Requerim. Sistema

Especificación de requerimientos del sistema Especificación de requerimientos software

Requerim. Software Diseño Software

Especificación de diseño software

Codificac. y Pruebas

Integración

Operación Fig. 10. Los requerimientos y el modelo del ciclo de vida en cascada.

En la figura anterior se observa cómo en el paso de una fase a otra del ciclo de vida se produce la elaboración de un documento de requisitos. La figura siguiente detalla para el caso especifico del modelo del ciclo de vida en espiral donde se produce cada una de las actividades del proceso de ingeniería de requisitos.

1 - 22

DEFINICIÓN DE REQUERIMIENTOS Identificar y resolver riesgos

Determinar objetivos, alternativas y restricciones

Evaluar alternativas Definición de requerimientos

Análisis y negociación de requerimientos Prototipo operativo

INICIO DOCUMENT. REQUERIM. E INFORME VALIDAC.

REQUERIM. ACORDADOS

Validación de requerimientos

Documentación de requerimientos

BORRADOR DOC. REQUERIMIENTOS

Fig. 11.- Modelo de ciclo de vida en espiral Por resumir la figura adjunta refleja el proceso de ingeniería de requisitos con relación a cada una de las actividades implicadas.

Requerimientos del sistema

Análisis de requerimientos del sistema Requerimientos hardware

Diseño hardware

Requerimientos software

Diseño software

Requerimientos Comunicacs.

Diseño Communics.

Fig. 6.- De los requerimientos sistema al diseño

1 - 23

1.5.- ESTANDARES EN LA ESPECIFICACIÓN DE REQUISITOS DE UN SISTEMA SOFTWARE.El proceso de ingeniería de requisitos es un conjunto estructurado de actividades que son realizadas para: obtener, acordar, validar y mantener un documento de requisitos del sistema. El producto final de la fase de requisitos del ciclo de vida es el denominado d ‘ ocumento de requisitos’ . Este documento es la posición oficial del equipo responsable del desarrollo sobre los requisitos del sistema para clientes, usuarios finales y el propio equipo de desarrollo. Dependiendo del tipo de organización, este documento puede tener diferentes nombres: Especificación funcional; definición de requisitos; especificación de requisitos software, etc,.. Para sistemas que son básicamente software los requisitos debieran incluir una descripción del hardware o plataforma técnica sobre la que el sistema software debiera ejecutarse, así como una visión general del sistema y una descripción de las necesidades de negocio que intenta resolver. En muchos casos es interesante añadir un glosario para un mejor entendimiento entre usuarios técnicos y clientes. Si bien, como se ha dicho, no hay tipo estándar de documento de requisitos, por lo que es normal que cada organización defina el suyo propio, si que hay un conjunto de normas definidas por algunas organizaciones como el Departamento de Defensa de USA y el IEEE que han definido estándares para el documento de requisitos. Uno de estos estándares, IEEE / ANSI 830-1993 sugiere la siguiente estructura para los documentos de requisitos: 1.- Introducción. Objetivo del documento de requisitos. Alcance del producto. Definiciones, acrónimos y abreviaturas. Referencias Visión general del documento. 2.- Descripción general. Perspectiva del producto. Funciones del producto. Características usuario. Restricciones generales. Asunciones y dependencias. Aplazamiento de requisitos. 3.- Requisitos específicos. Interfaces externas Funcionalidad Requisitos de rendimiento. Requisitos de la base de datos Restricciones de diseño. Características de calidad y atributos del sistema. 4.- Anexos. 5.- Glosario. Este contenido si bien es genérico se ajusta bien a cualquier caso concreto y cualquier organización. No obstante IEEE presenta hasta cuatro alternativas diferentes de organizar el documento de requisitos. Sin entrar al detalle de los contenidos de cada una de ellas vamos a desglosar el apartado de requisitos específicos, tal como es contemplado en la alternativa IV relativa a sistemas software complejos. 3.- Requisitos específicos.

1 - 24

3.1.- Requisitos funcionales 1.3.1.1.- Introducción. 3.1.2.- Entradas. 3.1.3.- Proceso. 3.1.4.- Salidas. 3.1.5.- Interfaces externas. 3.1.5.1.- Interfaces de usuario. 3.1.5.2.- Interfaces hardware. 3.1.5.3.- Interfaces software. 3.1.5.4.- Interfaces de comunicaciones. 3.1.6.- Requisitos de rendimiento. 3.1.7.- Restricciones de diseño. 3.1.7.1.- Conformidad a estándares. 3.1.7.2.- Restricciones hardware. ….. 3.1.8.- Atributos. 3.1.8.1.- Disponibilidad del sistema. 3.1.8.2.- Seguridad. 3.1.8.3.- Mantenibilidad. …. 3.1.9.- Otros requisitos. 3.1.9.1.- Base de datos. 3.1.9.2.- Operación. 3.1.9.3.- Instalación …. 3.2.- Requisitos funcionales 2.3.3.- Requisitos funcionales 3.Sobre el significado asociado a cada uno de estos apartados nos extenderemos en los párrafos siguientes de esta Unidad Didáctica y veremos en detalle los conceptos básicos asociados y cómo son definidos en los estándares internacionales al respecto. 6 Las prácticas recomendadas 7 describen cómo proceder a la especificación de los requisitos software de modo no ambiguo y completo. El seguimiento de estas prácticas debiera ayudar: -

A los clientes / usuarios del sistema software a describir adecuadamente lo que esperan obtener. Al equipo de desarrollo a entender exactamente lo que el cliente necesita / desea.

El modelo propuesto por IEEE detalla las ventajas que se derivan de esta estandarización de la documentación de las especificaciones de los requisitos software (ERS en lo sucesivo) : - Establecer un principio de acuerdo entre cliente y equipo de desarrollo sobre lo que el sistema software debe hacer - Reducir el esfuerzo de desarrollo - Proporcionar una base para estimar coste y plazo de desarrollo - Proporcionar una base de acuerdo para verificación y validación de las ERS. 6

En particular los IEEE Std 830-1998 e IEEE / EIA 12207.1-1997.

IEEE Recommended Practice for Software Requirements Specifications. IEEE Press, 1998 7

1 - 25

- Servir de base para futuras modificaciones / ampliaciones

1.5.1.- Naturaleza de las ERS: Las ERS son una especificación detallada y completa de los requisitos para un producto software particular, para un programa o para un conjunto de programas que deben realizar determinadas funciones en un entorno y dominio especifico, y deben satisfacer determinadas características básicas: Funcionalidad: los que el software a desarrollar debe hacer. Interfaces externas: ¿Cómo interactúa el software con los usuarios, con el sistema físico y / o con otro software? Rendimiento: Tiempo de respuesta, fiabilidad, disponibilidad, etc,.. Atributos: Portabilidad, consideraciones de seguridad, etc,.. Restricciones de: Lenguaje de programación, SGBD, sistema operativo, etc.,.. Etc., Es importante considerar que las ERS son una parte del proyecto total (que es analizado en el estándar IEEE Std 610.12.1990. El software puede contener todas las funcionalidades del proyecto o bien constituir tan solo una parte de un proyecto más amplio. En este último caso las ERS deben definir las interfaces entre el sistema software total y la parte del mismo contemplado en las ERS. -

Dado el papel importante que tienen las ERS en el proceso de desarrollo de todo sistema software, es importante que al escribirlas se tenga en cuenta: - Deben definir correctamente los requisitos software. Se entiende que los requisitos pueden derivarse de la naturaleza de la función que desarrolla el sistema en desarrollo o de las características especificas del proyecto. - No deben contemplar detalles de diseño o de implementación. Estos deben incluirse en fases posteriores del ciclo de vida del proceso software. - No debe imponer restricciones adicionales. Por ejemplo: las características derivadas de un adecuado aseguramiento de la calidad deben ser incluidas en otros documentos, tales como Plan para el Aseguramiento de la Calidad.

1.5.2.- Características de la ERS: La ERS deben ser: Correctas No ambiguas Completas Consistentes Clasificadas por su relevancia o importancia Verificables Modificables Trazables

Correctas: Una ERS es correcta si, y solo si, cada requisito definido debe ser satisfecho por el sistema software.

1 - 26

No hay ningún útil o herramienta que asegure la corrección de las ERS, por lo que debe ser verificable en una instancia superior de los mismos requisitos, o con la documentación del proyecto, con otros estándares aplicables, para verificar que es conforme con los mismos. Alternativamente el cliente o usuario debe poder determinar si las ERS reflejan correctamente las necesidades reales. No ambiguas: Una ERS es no ambigua si, y solo si, cada requisito definido en la misma tiene una sola interpretación. Como mínimo, ello exige que cada característica del producto final sea descrita utilizando un único término. En los casos en que el término usado en un contexto particular pueda tener múltiples significados, el término debe ser incluido en un glosario en donde se aclare su significado especifico. Dado que las ERS son una parte importante del proceso de requisitos, y son utilizadas en las fases del ciclo de vida diseño, implementación, verificación, validación, etc.,.. deben ser no ambiguas tanto para quien las crea como para quien las utiliza. Debe, por tanto, huirse de especificaciones de requisitos demasiado orientadas al equipo de desarrollo que pueden inducir una mala comprensión por los usuarios, y viceversa. Las ERS son escritas normalmente en lenguaje natural, y este, aún correctamente utilizado, puede ser ambiguo. Una vía para resolver esta ambigüedad es escribir las ERS en un lenguaje de especificación de requisitos. Los procesadores de estos lenguajes detectan automáticamente muchos de los errores léxicos, sintácticos y semánticos habitualmente cometidos. En general, los lenguajes y métodos de requisitos disponen de herramientas automáticas que los soportan, y que suelen agruparse en tres categorías: Orientación objetos: organizan los requisitos en términos de objetos del mundo real, sus atributos y los servicios que realizan dichos objetos. Orientación procesos: organizan los requisitos en jerarquías de funciones que comunican entre sí vía flujos de datos. (Más adelante estudiaremos uno de estos lenguajes: DFD). Orientación conducta: Describen los requisitos en términos de la conducta externa del sistema, utilizando para ello algunos conceptos con cierto nivel de abstracción: cálculo de predicados, máquinas de estados, funciones matemáticas, etc.,.. El grado en que tales útiles y métodos pueden ser adecuados para la preparación de las ERS depende en cada caso del tamaño y complejidad del sistema. Pero hay que tener presente que escribir las ERS en tales lenguajes aleja su comprensión por parte de los clientes y usuarios del mismo. Completas: Una ERS es completa si, y solo si, incluye los siguientes elementos: -

-

Todos los requisitos significativos, sean relativos a funcionalidad, rendimiento, restricciones de diseño o interfaces externas. Definición de la respuesta del sistema software s todas a l s clases y tipos de entradas de datos en cualquier situación que pueda presentarse. Hay que tener presente que esto supone que deben especificarse tanto las respuestas a entradas válidas como las que no lo son. Referencia de todas las figuras, diagramas, tablas, etc.,.. y definición de todos los términos y unidades de medida.

Si una ERS incluye términos del tipo ‘A definir posteriormente’ (TBD: to be defined) no es una ERS completa. No obstante en algunos casos puede ser imprescindible el uso de TBD, en cuyo caso debe ir acompañado de:

1 - 27

-

Una descripción de la condición que causa la TBD (por ejemplo: una respuesta no conocida) Una descripción de lo qué debe hacerse para eliminar esta situación, quien debe resolverla y cuando.

Consistentes: La consistencia se refiere a la conformidad de las ERS con documentos de más alto nivel. Si no hay esta conformidad es que las ERS no son consistentes. Hay, generalmente, tres tipos de problemas de consistencia, que son: Puede haber conflicto entre las características de los objetos del mundo real. Por ejemplo: una salida del sistema puede ser descrita en un documento como tabla y en otro como texto. O que un mensaje de error debe aparecer en color rojo, y en otro documento anterior especificar que todos los mensajes de error deben ser en vídeo inverso. Puede haber conflicto lógico o temporal entre determinadas acciones a realizar por el sistema software. . Por ejemplo en un lugar dice que determinado cálculo se hace sumando dos entradas, y en otro lugar que multiplicando, o definiendo procedimientos de redondeo diferentes en distintos apartados. O bien, especificar que el estado B debe seguir siempre al A, y en otro requerir la ocurrencia simultánea de A y B. Dos o más requisitos pueden describir el mismo objeto del mundo real usando diferentes términos para el mismo. Por ejemplo en unos casos se puede utilizar la expresión ‘formulario’ y en otro ‘plantilla de documento’, que no son sinónimos. La consistencia, en este caso, se asegura a través del glosario de términos.

Las ERS deben estar clasificadas por su relevancia o importancia Los requisitos relativos a los sistemas software no son todos igualmente importantes. Algunos pueden ser imprescindibles (especialmente en aplicaciones de naturaleza crítica), otros pueden ser deseables. Cada requisito en las ERS debe ser identificado para clarificar estas diferencias y hacerlas explícitas. Una posible clasificación se refiere, por ejemplo, al grado de necesidad: -

Esencial: Imprescindible Condicional: Pueden darse condiciones para que dicho requisito este o no presente. Opcional: Implica una clase de requisitos que pueden o no existir.

Otra posible clasificación a este respecto podría venir dada por la estabilidad del requisito, expresada en términos de cambios esperados en el mismo en función de la organización, funciones soportadas, personas, etc,.. Verificables: Una especificación de requisitos es verificable si y solo sí cada uno de los requisitos definidos es verificable. A su vez, un requisito es verificable si, y solo si, existe algún procedimiento por el que una persona o máquina puede chequear que el producto software cumple los requisitos. En general un requisito ambiguo es no verificable. Requisitos no verificable incluyen expresiones del tipo: ‘trabaja bien’, ‘buena interfaz’, ‘ocurre usualmente’, etc,. Estos requisitos no pueden ser verificados porque es imposible definir términos como ‘bueno’, ‘bien’, ‘usualmente’. Otro tipo de requisitos son no verificables. Es el caso de aquellos que incluyen expresiones como ‘el sistema software no debe caer nunca en un bucle infinito’, ya que la verificación de esta condición es teóricamente imposible.

1 - 28

Un ejemplo de requisito verificable es: ‘La respuesta del sistema debe producirse antes de 20 segundos en el 60% de los casos, y debe producirse en menos de 30 segundos en el 100% de las ocasiones’. Esta expresión es verificable porque utiliza términos concretos y cantidades o magnitudes medibles. Si un método no puede ser analizado para determinar cuando el sistema software cumple un requisito particular, entonces dicho requisito debe ser eliminado o revisado. Modificable: Una ERS es modificable si, y solo sí, su estructura y estilo son tales que cualquier cambio de los requisitos puede hacerse fácil, completa y consistentemente manteniendo la misma estructura y estilo. La modificabilidad requiere que las ERS: Estén organizadas de manera coherente y fácil de usar, con una tabla de contenidos, un índice, referencias cruzadas, etc,.. No sean redundantes, es decir el mismo requisito no debe aparecer más de una vez. Expresen cada requisito separadamente. Trazables: Las ERS son trazables si el origen de cada requisito es claro y si facilita la referencia del mismo para futuros desarrollos o modificaciones. Son recomendables dos tipos de trazabilidad: Hacia atrás: Cuando cada requisito referencia explícitamente su fuente u origen en documentos anteriores. Hacia delante: Implica que cada requisito tienen un único nombre o número de referencia. La trazabilidad es especialmente importante cuando el producto software entra en las fases de operación y mantenimiento. En la medida en que los códigos y documentos de diseño pueden ser modificados es importante ser capaces de identificar el conjunto de requisitos que pueden verse afectados por dichas modificaciones.

1.5.3.- Estructura de un documento ERS.En páginas anteriores se ha detallado la estructura que establece el estándar IEEE / ANSI 8301993 para el documento de especificación de requisitos, que resumido es: 1.- Introducción 2.- Descripción general. 3.- Requisitos específicos. 4.- Apéndices. 5.- Glosario. Contiene por tanto cinco secciones.

1 - 29

Sección 1: Introducción: La introducción de documento ERS debe proporcionar una visión general del documento completo ERS. Y debe incluir las siguientes subsecciones: Objetivo del documento de requisitos. Definición del objetivo, especificar la población a la que va dirigido el mismo Alcance del producto. Identificar el producto software a producir dándole nombre. Explicar lo que dicho producto hará y lo que no hará. Describir los beneficios que se derivaran de su uso. Definiciones, acrónimos y abreviaturas. Definición de todos aquellos términos, abreviaturas, etc, que son precisos para interpretar adecuadamente el ERS. Referencias Lista completa de todos los documentos referenciados en cualquier parte de las ERS. Identificar cada documento por titulo, número de informe, fecha, organización que lo publica, etc,.. Visión general del documento. Descripción del contenido del resto del documento ERS, explicar cómo esta organizada las ERS. Sección 2: Descripción general. Esta sección de las ERS debe describir los factores generales que afectan al producto y sus requisitos. En esta sección no deben definirse los requisitos, si no proporcionar el fundamento de los mismos, que se analizan en detalle en la sección 3 de ERS (Requisitos específicos). Usualmente esta segunda sección de los ERS contiene seis subsecciones: a) Perspectiva del producto: Esta subsección pone el producto en relación con otros productos. Si el producto es independiente y totalmente auto-contenido debe ser definido así en esta subsección. Si ERS define un producto que es un componente de un sistema más amplio, entonces esta subsección debe relacionar los requisitos del sistema global a la funcionalidad de la componente software a desarrollar, y debe especificar las interfaces entre sistema y componente. Esta subsección también debería describir cómo el software opera con sus restricciones, así debería incluir : § § § § § § § §

Interfaces sistema Interfaces usuario Interfaces hardware Interfaces software Interfaces comunicaciones Memoria Operatoria Requisitos de instalaciones

Sin ánimo de agotar las explicaciones que puede requerir esta subsección veamos qué deberían especificar las interfaces de usuario : a) Las características lógicas de cada interfaz entre el producto software y los usuarios del mismo, como podrían ser formatos de pantalla, descripción de

1 - 30

menús, ejemplo de listados, disponibilidad de teclas de función, etc,.. necesarias para adecuarse a los requisitos. b) Todos los aspectos de optimización de la interfaz con la persona que debe usar el sistema, especificando cómo el sistema se presenta al usuario.

b) Funciones del producto: Esta subsección debe proporcionar un sumario de las funciones principales que el sistema software debe realizar. Estas funciones deben estar organizadas de modo que sean comprensibles por los clientes / usuarios. Deben utilizarse métodos textuales o gráficos para mostrar las diferentes funciones y sus relaciones. c) Características del usuario: Si existen algunos requisitos que deben satisfacer los usuarios deben detallarse aquí: experiencia en el dominio, conocimientos técnicos, etc,.. d) Restricciones: En esta subsección deben detallarse aquellas restricciones que pueden limitar las opciones de desarrollo: -

Limitaciones hardware Auditoria Consideraciones de privacidad y seguridad Nivel crítico del sistema Interfaz con otras aplicaciones Criticidad de las aplicaciones Etc..

e) Asunciones y dependencias: En esta subsección se deben especificar cada todos y cada uno de los factores que afectan a los requisitos definidos en las ERS. Por ejemplo: el sistema operativo sobre el que debe funcionar. Si, de hecho, el sistema operativo no esta disponible sobre esa plataforma hardware debe cambiarse la ERS en consecuencia.

f) Aplazamiento de requisitos: Esta Subsección de las ERS debe identificar aquellos requisitos o aspectos del sistema software que son aplazados hasta futuras versiones del mismo.

Sección 3: Requisitos específicos. Esta sección de las ERS debe contener todos los requisitos software a un nivel de detalle suficiente para permitir que el equipo de desarrollo realice el diseño satisfaciendo todos esos requisitos. En esta sección es donde cada requisito especificado debe ser externamente comprobable por los usuarios, operadores u otros sistemas externos.

1 - 31

Estos requisitos específicos deben incluir, como mínimo, una descripción de cada entrada al sistema, cada salida (respuesta) del sistema, y todas las funciones realizadas por el sistema en respuesta a una entrada o como soporte de cada salida. Esta parte de los requisitos es con mucho la más importante de las ERS, y deben aplicarse los siguientes principios: -

-

Los requerimientos específicos deben detallarse de conformidad con las características apuntadas antes: corrección, no ambigüedad, completos, consistentes, etc.,.. Los requisitos específicos deben contener unas referencias cruzadas a los documentos anteriores que referencien. Los requisitos deben ser perfectamente identificables. Deben estar especificados de forma clara y legible.

Interfaces externas. Deben ser una descripción detallada de todas las entradas y salidas del software del sistema en desarrollo. Debe complementarse con la descripción de las interfaces del sistema antes descritas., y no deben repetir informaciones. Su formato y contenido debería contemplar: -

Nombre de cada ítem. Descripción Origen de la entrada o destino si salida. Rango de validez y tolerancia. Unidad de medida. Relación con otros inputs o salidas. Organización y formato de las pantallas. Id. Ventanas. Formato de datos. Formato de comandos. Mensajes.

Funciones. Los requisitos funcionales deben definir las acciones fundamentales que debe realizar el software al aceptar y procesar los inputs y al procesar y generar las salidas (deberían entenderse como: ‘El sistema debe...’) Incluyen: -

Controles de validez de los inputs. Secuencia exacta de operaciones. Respuesta a situaciones anómalas. Efecto de los parámetros Relación de las salidas a los inputs, incluyendo: o Secuencias input-output. o Fórmulas para convertir los inputs en salidas.

Puede ser interesante distribuir los requisitos funcionales en subprocesos o subfunciones, sin que ello implique que el diseño del software sea particionado de la misma manera.

1 - 32

Requisitos de rendimiento.Esta subsección debe especificar tanto los requisitos numéricos estáticos como dinámicos exigidos al software o a la interacción humana con el software como un todo. Los requisitos estáticos numéricos pueden incluir los siguientes: -

El numero de puestos de trabajo a soportar El número de usuarios simultáneos a soportar. Cantidad y tipo de la información a manejar.

Estos requisitos son, a veces, identificados en un documento separado bajo el titulo de ‘Capacidad’ Los requisitos dinámicos numéricos pueden incluir, por ejemplo, el número de transacciones y tareas y la cantidad de datos a ser procesados en un determinado periodo de tiempo, tanto en periodos normales de trabajo como en los picos de carga, y deben ser detallados en forma medible: por ejemplo: el 95 % de las transacciones debe completarse en menos de 1 segundo, y no en expresiones del tipo: el operador no debe esperar para que se complete la transacción.

Requisitos lógicos de la base de datos. En este apartado se debe especificar los requisitos lógicos para cualquier información a incluir en la base de datos. Por ejemplo: -

Tipos de información que utilizan las diferentes incluidas en el sistema Frecuencia de uso Posibilidades de acceso Entidades de datos y sus relaciones Restricciones de integridad Etc..

Restricciones de diseño..Son las que puedan ser impuestas por los estándares, limitaciones hardware, etc.,.. Conformidad con estándares. En esta subsección deben especificarse los requisitos derivados de los estándares aceptados o regulaciones. Pueden ser del tipo siguiente: Formato de los informes Nombre de los datos Procedimientos de ‘accounting’ Huellas para auditoria Etc.,, Atributos del sistema software.Hay ciertos atributos del sistema que actúan como requisitos; son, por ejemplo: -

Integridad Disponibilidad Seguridad Facilidad de mantenimiento Portabilidad

1 - 33

-

Etc.,,

Secciones 4 y 5.-Información de soporte.Finalmente en las ERS deben incluirse un cierto tipo de informaciones que faciliten el uso de los requisitos, como son: -

Tabla de contenidos Indice Apéndices Glosario

1.6.- ESPECIFICACIÓN FORMAL DE LOS REQUISITOS.-8 Al hablar de métodos formales se incluyen varias actividades diferentes: la especificación formal del sistema, el análisis y prueba de la especificación, la verificación formal de programas, etc.,, Todas estas actividades dependen de la ‘especificación formal del software’. Esta es una especificación expresada en un lenguaje cuyo vocabulario, sintaxis y semántica están9 formalmente definidos. Esta necesidad de definición formal significa que los lenguajes de especificación se deben basar en conceptos matemáticos cuyas propiedades se hayan verificado. En términos generales la especificación formal de un sistema se ubica en algún lugar entre las ERS y el diseño del software. Tal como se ve en la figura siguiente.

DISEÑO

ESPECIFICACIÓN

DEFINICIÓN DE REQUISITOS DE USUARIO

ESPECIFICACIÓN DE REQUISITOS DE SISTEMA

DISEÑO ARQUITECTURA DEL SISTEMA

ESPECIFICACIÓN FORMAL

DISEÑO GLOBAL DEL SISTEMA

Fig. 7 Especificación y diseño. 8

El alcance de este curso excede al estudio de las especificaciones formales, no obstante se incluye una referencia los mismos para que el alumno conozca de su existencia. 9 La rama de la matemática que se utiliza es la matemática discreta, y los conceptos utilizados provienen de la teoría de conjuntos, la lógica y el álgebra.

1 - 34

En las etapas iniciales del proceso de especificación es esencial que la especificación esté orientada al usuario. Se debe escribir de modo que el cliente la comprenda y no debe incluir referencias al diseño del software. Sin embargo en las etapas finales de especificación esta dirigida al técnico responsable del diseño del sistema, y ha de servir como base al diseño y a la posterior implementación del mismo. Esta especificación precisa es formal. Crear una especificación formal en un lenguaje especifico al respecto obliga a un análisis detallado del sistema que, por lo general, conduce al descubrimiento de errores e inconsistencias en la especificación previa, informal de los requisitos. Esta detección de errores es la que dota de robustez a la especificación formal, y los errores detectados deben conducir a cambios en la especificación de requisitos (mientras se esta en la fase de especificación de los mismos), Existen dos enfoques para la especificación formal: -

Un enfoque algebraico en el que el sistema se describe en términos de operaciones y sus relaciones. UN enfoque basado en modelos, en el que se construye un modelo del sistema utilizando elementos matemáticos como conjuntos y relaciones, y las operaciones del sistema se definen teniendo en cuenta cómo modifican el estado del sistema.

En cada uno de estos enfoques se han desarrollado diferentes lenguajes que permiten especificar sistemas software tanto en entornos de programación secuencial como concurrente: CSP (de Hoare, para programación concurrente) y Z (de Spivey para programación secuencial) son los más difundidos. La especificación en Z se estructura como un conjunto de esquemas, siendo un esquema una especificación formal equivalente a una subrutina o el procedimiento en un lenguaje de programación convencional. Del mismo modo que la subrutina y los procedimientos se utilizan para estructurar un sistema, los esquemas se utilizan para estructurar una especificación formal. Existe también ya una especificación basada en Z denominada Object Z, que permite su utilización en el paradigma de programación orientada a objetos, y que permite la inclusión de las funciones de herencia e instanciación. Pero ambos lenguajes están basados en la noción de estado: una colección de datos que se ven afectados por operaciones definidas por expresiones escritas mediante el cálculo de predicados.

1.7- LENGUAJES GRÁFICOS PARA LA DEFINICIÓN DE REQUISITOS. EL DIAGRAMA DE FLUJO DE DATOS.-

Lo usual es que el documento de requisitos este escrito en lenguaje natural, no obstante como hemos visto se han desarrollado lenguajes orientados a la especificación de requisitos, algunos de ellos de tipo gráfico, por lo que vamos a estudiar en detalle uno de ellos: el Diagrama de Flujo de Datos.. El objetivo del diagrama de flujo de datos es la obtención de un modelo lógico de procesos que represente el sistema, con independencia de las restricciones físicas del entorno. Así se facilita su comprensión por los usuarios y los miembros del equipo de desarrollo.

1 - 35

El sistema se divide en distintos niveles de detalle, con el objetivo de: • •

Simplificar la complejidad del sistema, representando los diferentes procesos de que consta. Facilitar el mantenimiento del sistema.

Descripción Un diagrama de flujo de datos es una técnica muy apropiada para reflejar de una forma clara y precisa los procesos que conforman el sistema de información. Permite representar gráficamente los límites del sistema y la lógica de los procesos, estableciendo qué funciones hay que desarrollar. Además, muestra el flujo o movimiento de los datos a través del sistema y sus transformaciones como resultado de la ejecución de los procesos. Esta técnica consiste en la descomposición sucesiva de los procesos, desde un nivel general, hasta llegar al nivel de detalle necesario para reflejar toda la semántica que debe soportar el sistema en estudio. El diagrama de flujo de datos se compone de los siguientes elementos: •

Entidad externa: representa un ente ajeno al sistema que proporciona o recibe información del mismo. Puede hacer referencia a departamentos, personas, máquinas, recursos u otros sistemas. El estudio de las relaciones entre entidades externas no forma parte del modelo. Puede aparecer varias veces en un mismo diagrama, así como en los distintos niveles del DFD para mejorar la claridad del diagrama.

•

Proceso: representa una funcionalidad que tiene que llevar a cabo el sistema para transformar o manipular datos. El proceso debe ser capaz de generar los flujos de datos de salida a partir de los de entrada, más una información constante o variable al proceso. El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de datos de entrada en varios de salida y siempre es necesario como intermediario entre una entidad externa y un almacén de datos.

•

Almacén de datos: representa la información en reposo utilizada por el sistema independientemente del sistema de gestión de datos (por ejemplo un. fichero, base de datos, archivador, etc.). Contiene la información necesaria para la ejecución del proceso. El almacén no puede crear, transformar o destruir datos, no puede estar comunicado con otro almacén o entidad externa y aparecerá por primera vez en aquel nivel en que dos o más procesos accedan a él.

•

Flujo de datos: representa el movimiento de los datos, y establece la comunicación entre los procesos y los almacenes de datos o las entidades externas. Un flujo de datos entre dos procesos sólo es posible cuando la información es síncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza su función. Los flujos de datos que comunican procesos con almacenes pueden ser de los siguientes tipos: •

De consulta: representan la utilización de los valores de uno o más campos de un almacén o la comprobación de que los valores de los campos seleccionados cumplen unos criterios determinados.

1 - 36

• •

De actualización: representan la alteración de los datos de un almacén como consecuencia de la creación de un nuevo elemento, por eliminación o modificación de otros ya existentes. De diálogo: es un flujo entre un proceso y un almacén que representa una consulta y una actualización.

1.7.1.- Descomposición por niveles Los diagramas de flujo de datos han de representar el sistema de la forma más clara posible, por ello su construcción se basa en el principio de descomposición o explosión en distintos niveles de detalle. La descomposición por niveles se realiza de arriba abajo (top-down), es decir, se comienza en el nivel más general y se termina en el más detallado, pasando por los niveles intermedios necesarios. De este modo se dispondrá de un conjunto de particiones del sistema que facilitarán su estudio y su desarrollo. La explosión de cada proceso de un DFD origina otro DFD y es necesario comprobar que se mantiene la consistencia de información entre ellos, es decir, que la información de entrada y de salida de un proceso cualquiera se corresponde con la información de entrada y de salida del diagrama de flujo de datos en el que se descompone. En cualquiera de las explosiones puede aparecer un proceso que no necesite descomposición. A éste se le denomina Proceso primitivo y sólo se detalla en él su entrada y su salida, además de una descripción de lo que realiza. En la construcción hay que evitar en lo posible la descomposición desigual, es decir, que un nivel contenga un proceso primitivo, y otro que necesite ser particionado en uno o varios niveles más. El modelo de procesos deberá contener: • • • • •

Un diagrama de contexto (Nivel 0). Un diagrama 0 (Nivel 1). Tantos diagramas 1, 2, 3,... n como funciones haya en el diagrama 0 (Nivel 2). Tantos niveles intermedios como sea necesario. Varios DFD en el último nivel de detalle.

El diagrama de contexto tiene como objetivo delimitar el ámbito del sistema con el mundo exterior definiendo sus interfaces. En este diagrama se representa un único proceso que corresponde al sistema en estudio, un conjunto de entidades externas que representan la procedencia y destino de la información y un conjunto de flujos de datos que representan los caminos por los que fluye dicha información. A continuación, este proceso se descompone en otro DFD, en el que se representan los procesos principales o subsistemas. Un subsistema es un conjunto de procesos cuyas funcionalidades tienen algo en común. Éstos deberán ser identificados en base a determinados criterios, como por ejemplo: funciones organizativas o administrativas propias del sistema, funciones homogéneas de los procesos, localización geográfica de los mismos, procesos que actualicen los mismos almacenes de datos, etc. Cada uno de los procesos principales se descompone a su vez en otros que representan funciones más simples y se sigue descomponiendo hasta que los procesos estén suficientemente detallados y tengan una funcionalidad concreta, es decir, sean procesos primitivos.

1 - 37

Como resultado se obtiene un modelo de procesos del sistema de información que consta de un conjunto de diagramas de flujo de datos de diferentes niveles de abstracción, de modo que cada uno proporciona una visión más detallada de una parte definida en el nivel anterior. Además de los diagramas de flujo de datos, el modelo de procesos incluye la especificación de los flujos de datos, de los almacenes de datos y la especificación detallada de los procesos que no precisan descomposición, es decir los procesos de último nivel o primitivos. En la especificación de un proceso primitivo se debe describir, de una manera más o menos formal, cómo se obtienen los flujos de datos de salida a partir de los flujos de datos de entrada y características propias del proceso. Dependiendo del tipo de proceso se puede describir el procedimiento asociado utilizando un lenguaje estructurado o un pseudocódigo, apoyándose en tablas de decisión o árboles de decisión. A continuación se muestra un ejemplo gráfico que representa la de descomposición jerárquica de los diagramas de flujo de datos.

Diagrama de Contexto (Nivel 0) SISTEMA

Diagrama 0 (Nivel 1)

Diagrama 1 (Nivel 2)

Diagrama 2 (Nivel 2)

Diagrama intermedi o

1 - 38 Procesos Primitivos

1.7.2.- Notación

Entidad externa: Se representa mediante una elipse con un identificador y un nombre significativo en su interior

A1 CLIENTE A1 CLIENTE

Si la entidad externa aparece varias veces en un mismo diagrama, se representa con una línea inclinada en el ángulo superior izquierdo. Proceso Se representa por un rectángulo subdividido en tres casillas donde se indica el nombre del proceso, un número identificativo y la localización.

ID

Localización

NOMBRE PROCESO

DEL

Si el proceso es de último nivel, se representa con un asterisco en el ángulo inferior derecho separado con una línea inclinada. ID

Localización

NOMBRE PROCESO

DEL *

El nombre del proceso debe ser lo más representativo posible. Normalmente estará constituido por un verbo más un sustantivo. El número identificativo se representa en la parte superior izquierda e indica el nivel del DFD en que se está. Hay que resaltar que el número no indica orden de ejecución alguno entre los procesos ya que en un DFD no se representa una secuencia en el tratamiento de los datos. El número que identifica el proceso es único en el sistema y debe seguir el siguiente estándar de notación: • • •

El proceso del diagrama de contexto se numera como cero. Los procesos del siguiente nivel se enumeran desde 1 y de forma creciente hasta completar el número de procesos del diagrama. En los niveles inferiores se forma con el número del proceso en el que está incluido seguido de un número que lo identifica en ese contexto.

1 - 39

La localización expresa el nombre del proceso origen de la descomposición que se esté tratando. Almacén de datos Se representa por dos líneas paralelas cerradas en un extremo y una línea vertical que las une. En la parte derecha se indica el nombre del almacén de datos y en la parte izquierda el identificador de dicho almacén en el DFD. ID

NOMBRE

Si un almacén aparece repetido dentro un DFD se puede representar de la siguiente forma: ID

NOMBRE

Flujo de datos Se representa por una flecha que indica la dirección de los datos, y que se etiqueta con un nombre representativo. Nombre del flujo de datos La representación de los flujos de datos entre procesos y almacenes es la siguiente:

A1

ALMACÉN

FLUJO DE CONSULTA

A2

ALMACÉN

FLUJO DE ACTUALIZACIÓ

A3

ALMACÉN

FLUJO DE DIÁLOGO

Ejemplo. La figura es un diagrama de flujos de un Sistema Gestor de Pedidos. En él están representados todos los elementos que pueden intervenir en una Diagrama de Flujo de Datos.

1 - 40

1 PEDIDO

GEST. PEDIDOS VALIDAR PEDIDO

A2

PEDIDOS PDTES

CLIENTE PEDIDO VALIDO A1

STOCK PEDIDO COMPLETADO

3

2

GEST. PEDIDOS

GEST. PEDIDOS COMPONER PEDIDOS

EMITIR FACTURA ALBARÁN ENTREGA ORDEN DE COMPRA PROVEEDOR

1.7.3.- Consistencia de los diagramas de flujo de datos Una vez construidos los diagramas de flujo de datos que componen el modelo de procesos del sistema de información, es necesario comprobar y asegurar su validez. Para ello, se debe estudiar cada diagrama comprobando que es legible, de poca complejidad y si los nombres asignados a sus elementos ayudan a su comprensión sin ambigüedades. Además, los diagramas deben ser consistentes. En los diagramas hay que comprobar que en un DFD resultado de una explosión: • • •

No falten flujos de datos de entrada o salida que acompañaban al proceso del nivel superior. No aparezca algún flujo que no estuviese ya asociado al proceso de nivel superior. Todos los elementos del DFD resultante deben estar conectados directa o indirectamente con los flujos del proceso origen.

A continuación se incluyen ejemplos de la consistencia o inconsistencia de los diagramas de flujo de datos. Sea el diagrama de contexto de la figura. Los flujos A, C y D, entran al sistema, y el flujo B sale de él.

1 - 41

DIAGRAMA DE CONTEXTO D

E2

A

E1

0 B

SISTEMA E3

C

Ejemplo de consistencia de diagramas de flujo de datos En la explosión del sistema en el diagrama de nivel 1, aparecen todos los flujos, y en su sentido correcto: A y C entran al subsistema o proceso 1, B sale del proceso 2, y D entra en el proceso 3. Se observa que el proceso 3, origina dos flujos de salida: E que va a al proceso 1, y F al proceso 2.

2

A1

A

1

B

F A2

D

C

3 E DIAGRAMA DE NIVEL 1

La descomposición del proceso 1, muestra los flujos A, C y E correctamente, como entradas a las funciones del diagrama.

A1 A2

A

1.1 1.2 C E E

DIAGRAMA DEL PROCESO 1

1 - 42

Los demás flujos están enlazados con los almacenes Al y A2 del mismo modo que en el diagrama anterior. Ejemplo de inconsistencia de diagramas de flujo de datos Partiendo del mismo diagrama de contexto utilizado en el anterior ejemplo, los flujos A, C y D, que entran al sistema, y el flujo B, que sale de él, deben aparecer en la primera descomposición, el diagrama de nivel 1. En la figura se aprecia que falta el flujo D, y hay un flujo G que o bien falta en el nivel anterior, sobra en este. Por otro lado, en el proceso 3 no entra ningún flujo, no es posible por tanto que transforme datos saliendo los flujos E y F y además está desconectado del nivel anterior.

2

A1

A

B G

1

F

A2 C

3

E DIAGRAMA DE NIVEL 1

En el siguiente paso, la inconsistencia más clara es la falta del flujo C, que entra al proceso 1, y sin embargo no aparece en su explosión.

A1 A2

A

1.1 1.2

E E

DIAGRAMA DEL PROCESO 1

Además, hay otra inconsistencia respecto al almacén Al: en el diagrama del nivel anterior, el proceso 1 se conectaba con un flujo de entrada-salida este almacén, cosa que no se refleja en el diagrama de este proceso, en el que sólo aparece uno de entrada. Ejemplo de construcción

1 - 43

El caso en estudio es un modelo de procesos de un sistema de información de Conocimientos de técnicos. Según estos conocimientos, los técnicos podrán ser asignados a determinados proyectos de la organización. El sistema recogerá la información referente a los técnicos, procedente de la Dirección técnica de la organización y de los proyectos, procedente de cualquier sección o Unidad de Negocio en las que está dividida dicha organización. Las entidades externas son pues Dirección Técnica y Unidad de Negocio, que introducen los datos al sistema y hacen peticiones de consultas e informes sobre los técnicos y sus conocimientos. El diagrama de contexto será el siguiente:

DIRECCIÓN TÉCNICA

DATOS TÉCNICOS

0

INFORMACIÓN TÉCNICOS

CONSULTAS UNIDAD

CONOCIMIENTOS UNIDAD DE NEGOCIO DATOS

Los flujos de entrada son: Datos Técnicos, con datos de los técnicos introducidos por la Dirección Técnica, así como posibles peticiones de información sobre ellos; y Datos Unidad, que proviene de la Unidad de Negocio, conteniendo datos referentes a la unidad, de proyectos y clientes, así como posibles peticiones de consultas sobre los mismos. Los flujos de salida son: Información Técnicos, que contendrá datos de técnicos, de consulta o informes, para uso de la Dirección Técnica y Consultas Unidad, con datos requeridos por la Unidad de Negocio. El sistema de Conocimientos se descompone en el diagrama de nivel 1, conteniendo dos subsistemas. El subsistema 1 recogerá las funciones a realizar con los datos de los técnicos de la organización (actualizaciones, consultas, informes, etc.), por lo que se denomina Tratar Técnicos. El subsistema 2 contendrá las funciones asociadas al procesamiento de datos de proyectos, por lo que se le da el nombre Tratar Proyectos.

1 - 44

DIRECCIÓN TÉCNICA INFORMACIÓN TÉCNICOS

1

DATOS TÉCNICOS

CONOCIMIENTO

TRATAR TÉCNICOS

A1 A2

A3

CONOCIMIENTOS

PROYECTOS

TÉCNICOS

2

CONOCIMIENTO

TRATAR PROYECTOS

A4

CLIENTES

CONSULTAS UNIDAD

DATOS UNIDAD

UNIDAD DE NEGOCIO

En el diagrama se encuentran cuatro almacenes, tres de los cuales son accedidos por funciones de los dos subsistemas: A1 Conocimientos, A2 Proyectos y A3 Técnicos. El cuarto, A4 Clientes, sólo es accedido por el subsistema Tratar Proyectos. Los flujos sin nombre indican que hay entrada y/o salida de todos los datos del almacén. En este diagrama siguen apareciendo las entidades externas para la mayor comprensión del mismo. A partir de ahora, se centrará el ejemplo en la descomposición del subsistema 1 Tratar Técnicos, hasta llegar a su nivel más detallado. En el diagrama resultado de la explosión de Tratar Técnicos, se incluyen cuatro procesos o funciones para el tratamiento completo de éstos. El flujo de entrada Datos Técnicos se compone tanto de los datos profesionales de los técnicos, como de datos de peticiones de información sobre los mismos, por lo cual se ha dividido en dos: Datos Profesionales, que es entrada del proceso 1.1 Validar datos Técnicos y Peticiones Información Técnicos, que entra en la función 1.4 Informar.

1 - 45

DATOS PROFESIONALES

A3

1.1

TÉCNICOS

1.2

TRAT. TÉCNICOS VALIDAR DATOS TÉCNICOS

ACTUALIZAR ALMACENES TÉCNICOS

DATOS TÉCNICOS CORRECTOS

DATOS TÉCNICOS PARA PROYECTOS

1.3

TRAT. TÉCNICOS

TRAT. TÉCNICOS

A1

CONOCIMIENTOS

ASIGNAR PROYECTOS

1.4

TRAT. TÉCNICOS

PETICIÓN INFORMACIÓN TÉCNICOS

INFORMAR

A2

PROYECTOS

A3

TÉCNICOS

INFORMACIÓN TÉCNICOS

Para la validación, el proceso 1.1 Validar Datos Técnicos obtiene información del almacén A3 Técnicos y genera una salida, el flujo Datos Técnicos Correctos, que lleva los datos válidos a la función 1.2 Actualizar Almacenes Técnicos. Esta función se encarga de actualizar los almacenes A3 Técnicos y A1 Conocimientos, pero también emite un flujo al proceso 1.3 Asignar a Proyectos. Éste se encarga de hacer asignaciones de técnicos en el almacén A2 Proyectos. La función 1.4 Informar, recibe las peticiones de información sobre técnicos, las procesa utilizando los almacenes necesarios y genera el flujo Información Técnicos que irá a la entidad Dirección Técnica, según muestran los primeros diagramas. Obsérvese que para mayor claridad no se ha incluido ya ninguna entidad externa, y además, se ha repetido el almacén A3 Técnicos, evitando que el cruce de flujos oscurezca la lectura del diagrama. En este momento, todos los procesos se consideran primitivos, excepto el proceso 1.4 Informar, del que se obtiene su descomposición. Sus funciones han de obtener Informes Técnicos y Consultas Técnicos, flujos que componen Información Técnicos que aparecía en el nivel anterior.

1 - 46

PETICIONES CONSULTAS TÉCNICOS

PETICIONES INFORMES TÉCNICOS CONSULTAS TÉCNICOS

1.1

1.2

INFORMAR VALIDAR DATOS TÉCNICOS

INFORMES TÉCNICOS

INFORMAR

ACTUALIZAR ALMACENES TÉCNICOS

A3

CONOCIMIENTOS

A2

PROYECTOS

A3

TÉCNICOS

Por otro lado, también aparece dividido el flujo de entrada Peticiones Información Técnicos, diferenciando la entrada al proceso de consultas o al de emisión de informes. Por último, se puede apreciar que los almacenes son los mismos que se conectaban con el proceso en el nivel anterior y los flujos son de entrada a las funciones.

1 - 47