1. Abstract
En el siguiente trabajo se pretende desarrollar un tema bastante especial en el proceso de desarrollo de
software, el cual es la base para que todo proyecto –independientemente de cual sea su porte- se
realice de forma correcta y entendible.
El trabajo consta de tres grandes partes las cuales son: 1) Los fundamentos principales de una
especificación de requerimientos; 2) Las metodologías que se aplican hoy en día para su construcción y
3) Una tercera parte en donde se pretende conocer como se lleva a cabo dicho proceso en una empresa
de software de Uruguay.
2. Fundamentos del Análisis de Requerimientos
Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos
necesarios para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un problema o
alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer un contrato, un
estándar, una especificación u otro documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los
requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un
programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El ámbito del
programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan
y asignan a los distintos elementos de los programas las soluciones alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de
requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y comportamiento
de los programas en detalles concretos, El que desarrolla el software actúa como interrogador, consultor
y el que resuelve los problemas.
El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las
apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por
mala interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software
puede ser comprendido repitiendo la esentencia de un cliente anónimo: “Sé que crees que comprendes
lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir”.
3. Análisis de Requerimientos
El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y el
diseño de programas (Figura 1). El análisis de requerimientos facilita al ingeniero de sistemas
especificar la función y comportamiento de los programas, indicar la interfaz con otros elementos del
sistema y establecer las ligaduras de diseño que debe cumplir el programa. El análisis de requerimientos
permite al ingeniero refinar la asignación de software y representar el dominio de la información que será
tratada por el programa. El análisis de requerimientos de al diseñador la representación de la
información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental.
Finalmente, la especificación de requerimientos suministra al técnico y al cliente, los medios para valorar
la calidad de los programas, una vez que se haya construido.
4. Tareas del Análisis
El análisis de requerimientos puede dividirse en cuatro áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.
Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es
importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación
necesaria para el análisis, de forma que se asegure el reconocimiento del problema.
Las formas de comunicación requeridas para el análisis se ilustran en la Figura 2. El analista debe
establecer contacto con el equipo técnico y de gestión del usuario/cliente y con la empresa que vaya a
desarrollar el software. El gestor del programa puede servir como coordinador para facilitar el
establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos
básicos del programa tal como lo percibe el usuario/cliente.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del
análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las
funciones del programa, establecer las características de la interfase del sistema y descubrir las
ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que pueda
sintetizarse un enfoque o solución global.
Las tareas asociadas con el análisis y especificación existen para dar una representación del programa
que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente desarrolla una
especificación de requerimientos del software completamente por sí mismo. Esto se presenta raramente
en el mundo real. En el mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente
y el técnico.
Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interfase e información, se
especifican los criterios de validación para demostrar una comprensión de una correcta implementación
de los programas. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los
programas. Para definir las características y atributos del software se escribe una especificación de
requerimientos formal. Además, para los casos en los que se desarrolle un prototipo se realiza un
manual de usuario preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso de
desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar el punto de
vista del usuario del software. El manual permite al usuario / cliente revisar el software desde una
perspectiva de ingeniería humana y frecuentemente produce el comentario: “La idea es correcta pero
esta no es la forma en que pensé que se podría hacer esto”. Es mejor descubrir tales comentarios lo
mas tempranamente posible en el proceso.
Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven como base
para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casi siempre
produce modificaciones en la función, comportamiento, representación de la información, ligaduras o
criterios de validación. Además, se realiza una nueva apreciación del plan del proyecto de software para
determinar si las primeras estimaciones siguen siendo validas después del conocimiento adicional
obtenido durante el análisis.
5. Principios del Análisis
En la pasada década, se desarrollaron varios métodos de análisis y especificación del software. Los
investigadores han identificado los problemas y sus causas y desarrollando reglas y procedimientos para
resolverlos. Cada método de análisis tiene una única notación y punto de vista. Sin embargo, todos los
métodos de análisis están relacionados por un conjunto de principios fundamentales:
El dominio de la información, así como el dominio funcional de un problema debe ser representado y
comprendido.
El problema debe subdividirse de forma que se descubran los detalles de una manera progresiva (o
jerárquica)
Deben desarrollarse las representaciones lógicas y físicas del sistema.
Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se examina el dominio de
la información de forma que pueda comprenderse su función mas completamente. La partición se aplica
para reducir la complejidad. La visión lógica y física del software, es necesaria para acomodar las
ligaduras lógicas impuestas por los requerimientos de procesamiento, y las ligaduras físicas impuestas
por otros elementos del sistema.
6. El dominio de la Información
Todas las aplicaciones del software pueden colectivamente llamarse procesamiento de datos. Este
término contiene la clave de lo que entendemos por requerimientos del software. El software se
construye para procesar datos; para transformar datos de una forma a otra; esto es, para aceptar
entrada, manipularla de alguna forma y producir una salida. Este establecimiento fundamental de los
objetivos es verdad tanto si construimos software por lotes para un sistema de nominas, como software
empotrado en tiempo real para controlar el flujo de la gasolina de un motor de automóvil; el dominio de
la información contiene tres visiones diferentes de los datos que se procesan por los programas de
computadoras: 1) el flujo de información; 2) el contenido de la información y 3)la estructura de la
información. Para comprender completamente el dominio de la información, deben considerarse cada
una de estas tres partes.
El flujo de la información representa la manera en la que los datos cambian conforme pasan a través de
un sistema. Refiriéndonos a la Figura 3, la entrada se transforma en datos intermedios y más adelante
se transforma en la salida.
|
