 |
||||
|
Unidad II Determinación de requerimientos 2.1 Identificación de requerimientos Un requerimiento es una característica necesaria que deberá poseer el nuevo sistema. Por otra parte, la determinación de requerimientos es el estudio de un sistema para comprender cómo trabaja y dónde es necesario efectuar mejoras. Ahora bien, existen tres formas (= actividades) de determinar de requerimientos, a saber • Anticipación de requerimientos: prever las características del nuevo sistema con base en experiencia previa. • Investigación de requerimientos: actividad más importante del análisis de sistemas. Es el estudio y documentación del sistema actual usando para ellos técnicas de para hallar hechos, análisis de flujo de datos y análisis de decisión. Es aquí donde aplicamos entrevistas, cuestionarios, observación y revisión de documentación entre otros. • Especificación de requerimientos: los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripción de las características del nuevo sistema. Preguntas clave: ¿ Que se esta haciendo? ¿Cómo se esta haciendo? ¿Qué tan bien se lleva a cabo la tarea? ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa principal? 2.2 Técnicas y medios para la recolección de requerimientos Entrevistas Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requerimientos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión. Forma de contrato En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requerimientos. En sistemas muy complejos éstos pueden tener centenares de páginas. Objetivos mensurables Los requerimientos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto. Prototipos Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Cuestionario’
Un cuestionario es un conjunto de preguntas que deben ser contestadas por escrito por una determinada población, generalmente esta población es amplia. Según el contenido de los cuestionarios podemos clasificarlos en los siguientes tipos: 1. Abiertos: Las respuestas no están delimitadas, esto permite mayor libertad de expresión. 2. Cerrados: Se fuerza a respuestas concretas. 2.3 Tipos de requerimientos Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. • Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidos utilizando el sistema. • Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer mas todas las restricciones sobre la funcionalidad. Requerimientos Funcionales • Describen la funcionalidad o los servicios que se espera proveerá el sistema. • Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. • Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Requerimientos No Funcionales • Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. • De forma alternativa, definen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en las interfaces del sistema. • Sin embargo, estos requerimientos no siempre se refieren al sistema de software a desarrollar. 2.4 Herramientas de software USO DE PROTOTIPOS. Un proceso interactivo del desarrollo de sistemas en el cual los requerimientos son convertidos en un sistema que trabaja, y que es continuamente revisado a través de un trabajo conjunto entre un analista y los usuarios. JOINT APPLICATION DESIGN (JAD). Un proceso estructurado en el cual los usuarios, gerentes y analistas, trabajan juntos varios días en una serie de reuniones intensivas para especificar o revisar requerimientos de sistemas. HERRAMIENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING). Uso de herramientas para la ingeniería de software asistida por computadora para aumentar la productividad, comunicarse más efectivamente con los usuarios e integrar el trabajo que realizan los analistas en el sistema, desde el principio hasta el fin del ciclo de vida. GROUPWARE. Software que está diseñado para ser usado en una red y servir a un grupo de usuarios que trabajan en un proyecto relacionado. Clases de Herramientas
Aplicaremos el término herramienta a un producto CASE que da soporte a una tarea concreta dentro de las actividades de desarrollo de software. Dicho soporte consistirá en una serie de servicios, cada uno de los cuales automatiza una operación individual. Podemos clasificar las herramientas según los servicios que ofrece y/o la tarea a la que da soporte. A continuación se describen algunas clases de herramientas o grupos de funciones que podemos encontrar en un entorno de programación:
Otras herramientas de desarrollo no incluidas en la relación anterior se salen del marco de lo que hemos denominado entorno de programación, y dan soporte a otras fases del ciclo de vida de desarrollo. Por ejemplo:
Edición y examen del código
Codificación
Verificación y validación
Gestión de configuración
Métricas
La herramientas de obtención de métricas son en realidad un caso particular de las de verificación y validación, aunque tienen entidad propia.
Otras herramientas
|
|
|||
 |
||||