Anlisis y Diseo de Sistemas

Anlisis de Requisitos
Determinar los objetivos y lmites del sistema a analizar, caracterizar su estructura y funcionamiento, marcar las directrices que permiten alcanzar los objetivos propuestos y evaluar sus consecuencias.

Identificacin de necesidades
El analista se rene con el cliente y/o usuario, e identifican las metas globales , se analizan las perspectivas, necesidades y requerimientos del cliente, las lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto.

Identificacin de necesidades

Reconocimiento del problema Evaluacin y sntesis Modelado Especificacin Revisin

Problemas de la Identificacin de necesidades

Los especialistas no saben realmente lo que quieren. stos expresan requerimientos en sus trminos propios. Diferentes especialistas pueden tener requerimientos en conflicto. Los factores polticos y organizacionales pueden influir en los requerimientos del sistema. Los requerimientos cambian durante el proceso de anlisis. Y pueden surgir nuevos especialistas.

Actividades del proceso

Desde un punto de vista conceptual, las actividades son de cinco clases. Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo.

Actividades del proceso

Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin. Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

Tcnicas principales Entrevistas

Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema.

Tcnicas principales 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 seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin.

Tcnicas principales 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 pginas.

Tcnicas principales 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 crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto.

Tcnicas principales Prototipos

Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Tcnicas principales Casos de uso

Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin 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.

Peligros Potenciales Casos de uso

Esta tcnica 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 diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez.

Peligros Potenciales Casos de uso

Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.