Fundamentos del Análisis de Requerimientos
Enviado por ASADSFAADFS • 16 de Mayo de 2013 • Trabajo • 5.105 Palabras (21 Páginas) • 496 Visitas
1. Abstract
2. Fundamentos del Análisis de Requerimientos
3. Análisis de Requerimientos
4. Tareas del Análisis
5. Principios del Análisis
6. El dominio de la Información
7. Partición
8. Visiones Lógicas y Físicas
9. Construcción de Prototipos de Software
10. Un escenario para la contruccion de prototipos
11. Especificación
12. Principios de Especificación
13. Metodos de Análisis de Requerimientos
14. Metodologías de Análisis de Requerimientos
15. Métodos de Análisis Orientados al Flujo de Datos
16. Diagramas de Flujos de Datos
17. Diccionario de Datos
18. Descripciones Funcionales
19. Métodos Orientados a la Estructura de Datos
20. Desarrollo de Sistemas de Jackson
22. Características de las bases de datos
21. Requerimientos de las Bases de Datos
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 lacalidad 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
...