1. INTRODUCCIÓN
Para el éxito en el desarrollo del software es fundamental la comprensión de los requisitos necesarios para la construcción del producto software. Muchas veces es irrelevante lo bien diseñado o codificado que pueda estar un programa si es que no cuenta con una etapa de análisis previa. La tarea del análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refina en detalle el ámbito del software, inicialmente establecida por el ingeniero de sistemas y refinada durante la planificación temporal del proyecto de software. Se crean modelos de los requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan soluciones alternativas y se asignan a diferentes elementos del software.
2. ANÁLISIS DE REQUISITOS
Es una tarea de la ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite refinar la definición del software y construir los modelos de los dominios de datos, funcional y de comportamiento a ser considerados en el producto software. El análisis de requisitos proporciona al diseñador del software los siguientes modelos: de datos, arquitectónico, de interfaz y procedimental. La especificación de requisitos proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha construido el software. El análisis de requisitos del software puede dividirse en las siguientes cinco actividades de esfuerzo:
• Reconocimiento del problema. Reconocer los elementos básicos del problema, tal y como los percibe el usuario o el cliente.
• Evaluación y síntesis. Definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información y elaborar todas las funciones del software. Esta actividad continua hasta que el analista y el cliente se sienten seguros de que se puede especificar adecuadamente el software para las fases posteriores de desarrollo.
• Modelado. Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional, el comportamiento operativo y el contenido de la información.
• Especificación. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.
• Revisión. Consiste en llevar adelante la actividad de revisar las especificaciones del software para considerar las mas adecuadas.
3. TÉCNICAS DE COMUNICACIÓN
El análisis de requisitos del software siempre comienza con la comunicación entre dos o mas partes. Normalmente un cliente tiene un problema que pretende sea resuelto con un resultado producido por un programa computacional. Un desarrollador responde a la solicitud de ayuda del cliente. En este paso la comunicación comienza, pero es común comprobar que el camino de la comunicación al entendimiento está a menudo lleno de baches.
3.1 Inicio del proceso
La técnica de análisis más utilizada para empezar el proceso de comunicación es llevar a cabo una reunión o entrevista preliminar. Gause y Weinberg sugieren que el analista comience preguntando cuestiones de contexto libre, enfocados sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo se debería preguntar:
a. ¿Quién está detrás de la solicitud de este trabajo?
b. ¿Quién utilizará la solución?
c. ¿Cuál será el beneficio económico del éxito de una solución?
d. ¿Existe alguna otra alternativa necesaria para la solución?
El segundo conjunto de preguntas permite al analista obtener un entendimiento mejor del problema y al cliente comentar sus opiniones sobre la solución, estas preguntas son:
a. ¿Cómo caracterizaría un buen resultado generado por una buena solución?
b. ¿A que tipo de problema o problemas está dirigida la solución?
c. ¿Podría mostrarme el entorno en que se utilizará la solución?
d. ¿Existen aspectos o restricciones especiales de rendimiento que afecten a la manera de enfocar la solución?
El último conjunto de preguntas se concentra en la eficacia de la reunión, estas se denominan meta - preguntas y proponen la siguiente lista:
a. ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son oficiales?
b. ¿Son adecuadas mis preguntas para el problema que tiene?
c. ¿Estoy preguntando demasiado?
d. ¿Hay alguien más que pueda proporcionar información adicional?
e. ¿Hay algo mas que debería preguntarle?
3.2 Técnica para facilitar especificaciones de una aplicación (TFEA)
Este enfoque es partidario de la creación de un equipo de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución.
Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variación en las siguientes directrices básicas:
a. La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores.
b. Se establecen normas de preparación y participación.
c. Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas.
d. Se elige un coordinador que controle la reunión.
e. Se utiliza un mecanismo de definición (hojas de trabajo, gráficos, carteles, pizarra, etc.)
f. El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución.
3.3 Despliegue de la función de calidad (DFC)
Es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software. DFC se concentra en maximizar la satisfacción del cliente, haciendo énfasis en entender lo que resulta valioso para el cliente y luego desplegar estos valores a lo largo del proceso de ingeniería. DFC identifica tres tipos de requisitos:
a. Requisitos normales. Son requisitos básicos asociados a objetivos y metas para un producto software, si estos están presentes el cliente quedará satisfecho.
b. Requisitos esperados. Son implícitos al producto y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia puede ser motivo de una insatisfacción significativa.
c. Requisitos innovadores. Van más allá de las expectativas del cliente y suelen ser muy satisfactorias como valor agregado al producto.
4. PRINCIPIOS DEL ANÁLISIS
Todos los métodos de análisis se relacionan a través del siguiente conjunto de principios operativos:
a. La representación y el entendimiento del dominio de información de un problema. Requiere el examen del dominio de la información. Este dominio contiene tres visiones diferentes de los datos y del control: (1) contenido de la información y relaciones, (2) flujo de la información y (3) estructura de la información. El contenido es definido por los atributos necesarios para crearlo. El flujo representa como cambian los datos y el control a medida que se mueven dentro de un sistema. La estructura representa la organización interna de los elementos de datos o de control.
b. La definición de funciones que debe realizar el software. Los modelos se crean para entender de mejor manera la entidad que se va construir como solución aun problema. Para transformar la información el software debe realizar al menos tres funciones genéricas: entrada, procesamiento y salida.
c. La representación del comportamiento del software. La característica estimulo respuesta forma la base del modelo de comportamiento. Un programa de computadora siempre está en un estado, en un modo de comportamiento observable exteriormente (imprimiendo, calculando, etc.).
d. La división de los modelos que representan información, función y comportamiento de manera que se puedan descubrir los detalles por capas, para que las partes puedan entenderse fácilmente y establecer luego las interacciones entre las mismas de manera que se pueda conseguir la función global.
e. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación. Una visión esencial de los requisitos del software presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación. La visión de implementación de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información.
5. CREACIÓN DE PROTOTIPOS
El análisis normalmente se realiza independientemente del paradigma de ingeniería del software que se aplique. Hay circunstancias que requieren la construcción de un prototipo al principio del análisis, debido a que el modelo es el único medio a través del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona después hacia la producción del software.
El paradigma para la creación de prototipos puede ser:
a. Enfoque cerrado. Se denomina a menudo prototipo desechable. Sirve únicamente para una basta demostración de los requisitos, después se desecha y se hace la ingeniería del software con un paradigma diferente.
b. Enfoque abierto. Denominado prototipo evolutivo. Emplea el prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la construcción
6. ESPECIFICACION
El modo de especificación tiene mucho que ver con la calidad de la solución. La especificación puede verse como un proceso de representación. Los requisitos se representan de manera que como fin ultimo lleven al éxito de la implementación del software.
Los siguientes principios de especificación son adaptados del trabajo de Balzer y Goldman:
1. Separar la funcionalidad de la implementación.
2. Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno.
3. Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él.
4. Definir el entorno en que operara el sistema.
5. Crear un modelo intuitivo en lugar de un diseño o modelo de implementación.
6. Reconocer que la especificación debe ser tolerante a un posible crecimiento.
7. Establecer el contenido y la estructura de una especificación de manera que acepte cambios.
Para representar una especificación de requisitos debe seguirse el siguiente grupo de directrices.
a. El formato de representación y el contenido deben estar relacionados con el problema.
b. La información contenida dentro de la especificación debe estar escalonada.
c. La numeración de párrafos y diagramas debe indicar el nivel de detalle que se muestra.
d. Los diagramas y otras formas de notación deben restringirse en numero y ser consistentes en su empleo.
e. La representación debe permitir revisiones.
Finalmente un esquema para la especificación de los requisitos del software, señalado por Pressman es la siguiente:
I. Introducción
A. Referencia del sistema
B. Descripción general
C. Restricciones del proyecto de software
II. Descripción de la información
A. Representación del contenido de la información
B. Representación del flujo de la información
1. Flujo de datos
2. Flujo de control
III. Descripción funcional
A. Partición funcional
B. Descripción funcional
1. Descripción del procesamiento
2. Restricciones / limitaciones
3. Requisitos de rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
C. Descripción del control
1. Especificación del control
2. Restricciones de diseño
IV. Descripción del comportamiento
A. Estados del sistema
B. Eventos y acciones
V. Criterios de validación
A. Limites del rendimiento
B. Clases de pruebas
C. Respuesta esperada del software
D. Consideraciones especiales
VI. Bibliografía
VII. Apéndice
PRACTICA
1. Estudie su percepción de formación y currículo ideal de un analista de sistemas.
2. Describa al "cliente" desde el punto de vista de los desarrolladores de sistemas de información, de los constructores de productos basados en computadoras y de los constructores de sistemas.
3. Construya una tabla para la selección del enfoque apropiado de creación de prototipos.
4. Investigue la técnica de componentes reutilizables como enfoque para el desarrollo de prototipos.
No hay comentarios:
Publicar un comentario