tecnicas para modelar requisitos

Company Logo

www.themegallery.com

Company

LOGO

TECNICAS PARA MODELAR REQUISITOS

INTRODUCCION

Hoy en día para modelar los requisitos dentro de la ingeniería de software es muy complicado para el analista de ingeniería de software, es problemático y dificultoso obtener los requisitos del cliente. Se obtiene problemas al comprender la información adquirida. Con frecuencia, registramos los requisitos de una manera desorganizada e invertimos muy poco en verificar lo que registramos.

De esta manera los analistas utilizan técnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entre éstos se incluyen la entrevista, el cuestionario, la revisión de los registros (en el sitio donde se encuentran estos) y la observación. En general los analistas emplean más de una de estas técnicas para estar seguros de llevar a cabo una investigación amplia y exacta.

INGENIERIA DE REQUISITOS

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”. (Pressman, 2006: 155).

“La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”. (Sommerville, 2005: 82).

IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS

Permite gestionar las necesidades del proyecto en forma estructurada

Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados

Disminuye los costos y retrasos del proyecto

Mejora la calidad del software

Mejora la comunicación entre equipos

Evita rechazos de usuarios finales

¿QUE ES REQUERIMIENTO EN SOFTWARE?

Un requerimiento de software es una especificación de lo que se debería implementar. Existen básicamente dos tipos de requisitos (funcionales y no funcionales). Son una declaración de lo que debería hacer un sistema y no como lo debería hacer.

Es un conjunto de condiciones o capacidades que pueden ser esenciales, necesarias o deseadas y que es satisfecha por un sistema de software o componente con la finalidad de satisfacer un contrato u otro documento formal.

Los requisitos deben ser INEQUIVOCOS, CONSISTENTES Y COMPROBABLES

TIPOS DE REQUERIMIENTOS

Funcionales

Definen las funciones que el sistema será capaz de realizar.

REQUERIMIENTOS

No Funcionales

Tienen que ver con características que de una u otra forma puedan limitar el sistema.

CARACTERISTICAS

Verificable

Consistente

Completo

Conciso

Necesario

DIFICULTADES PARA DEFINIR LOS REQUISITOS

Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de

detalle. La cantidad de requerimientos en un proyecto puede ser difícil de

manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más

importantes o más estables que otros. Los requerimientos están relacionados unos con otros, y a su vez

se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas

funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de

requerimientos es particular para cada proyecto.


ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

Validacion

ExtracciónAnálisis

Especificación

Verificación

REQUERIMIENTOS

ACTIVIDADES

TÉCNICAS PARA RECOPILAR REQUISITOS

Entrevista:

Los analistas emplean una entrevista para reunir información proveniente de personas o de grupos. Por lo común, los entrevistados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, los entrevistados son gerentes o empleados que proporcionan los datos para el sistema propuesto por qué serán afectados por él. Aunque algunos analistas prefieren la entrevista sobre otras técnicas, esta no siempre es la mejor fuente de datos sobre la aplicación. Dado que la entrevista requiere de tiempo, es necesario utilizar otros métodos para obtener la información necesaria para conducir una investigación.


Taller:

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.


Cuestionario:

Esta técnica permite los analistas reunir información proveniente relacionada con varios aspectos de un sistema de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos más confiables que otras técnicas; por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas más honestas. Sin embargo, este método no permita al analista observar las expresiones correcciones de los encuestados. Así misma, la respuesta puede ser limitada ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario.

El alto costo asociado con el desarrollo y distribución de cuestionarios demanda del analista la consideración cuidadosa del objetivo de estos así como de la estructura que será más útil para el estudio y más fácil de entender para los encuestados. Así mismo, es necesario realizar pruebas con el cuestionario y, si es necesario, modificarlos antes de su impresión y distribución.


Forma de contrato:

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles:

Los requisitos 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.


Revisión de registro:

Varios tipos de reportes y de registros pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la información asentada en ellos relacionada con el sistema y los usuarios. La revisión puede efectuarse el comienzo del estudio, como introducción o después, esto sirve para comparar las operaciones actuales, por lo tanto los registros pueden indicar que está sucediendo.

Los registros incluyen manuales de políticas, reglamentos y procedimientos estándares de operación utilizados por la mayor parte de las organizaciones como guías. Los registros no indican la forma en la que se desarrollan las actividades, donde se encuentra todo el poder en la toma de decisiones, o como se realizan todas las tareas.


Análisis estructurado:

Esta fase es donde el analista que examina una situación en forma independiente sin lineamientos o herramientas o técnicas recopilan información para describir el sistema.

El objetivo del análisis estructurado es el de organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión exacta de una situación dada.

Para el análisis estructurado se utilizan varios componentes para la observación y obtener datos importantes para el desarrollo del sistema, como lo puede ser el examinar símbolos gráficos, diccionarios de datos, descripción de procesos y procedimientos y las reglas.


La observación :

Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica. Los sociólogos, sicólogos e ingenieros industriales utilizan extensamente ésta técnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organización. El propósito de la organización es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dónde se hace y por qué se hace.

"¡Ver es creer! Observar las operaciones la proporciona el analista hechos que no podría obtener de otra forma.


Lluvia de ideas (Brainstorm):

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc.


Las reglas básicas a seguir son:

Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.

Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque si no se crea un ambiente hostil que no alienta la generación de ideas.

Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.

A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.

Escribir las ideas sin censura.


Prototipos:

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.

Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.



El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las

salidas). El diseño rápido lleva a la construcción de un prototipo. Los prototipos pueden ser: diagramas, aplicaciones operativas con

funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.


Casos de uso

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales.


Esta técnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz d usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

PERSONAL INVOLUCRADO EN LA INGENIERÍA DE REQUERIMIENTOS

Personal Involucradas

en la IR

B

E

C

D

AUsuario final

Usuario Líder

Personal de Mantenimiento

Personal de pruebas

Analistas y programadores


Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.

Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema.

Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.


Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.

Company Logo


MUCHAS GRACIAS

tecnicas para modelar requisitos

Documents