Sunteți pe pagina 1din 11

Anlisis de Requerimientos

MUESTREO E INVESTIGACIN DE DATOS IMPRESOS. El proceso de seleccionar sistemticamente elementos representativos de una poblacin es llamado muestreo. El objeto del muestreo es seleccionar y estudiar documentos, tales como facturas, reportes de ventas y memorndums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organizacin. El muestreo puede reducir costos, velocidad de recoleccin de datos, hacer potencialmente que el estudio sea ms efectivo y posiblemente reducir la ascendencia en el estudio. Cuatro tipos principales de muestras que tiene el analista. Un analista de sistemas debe seguir cuatro pasos en el diseo de una buena muestra. Primero, se tiene la necesidad de determinar la poblacin misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamao de muestra. Por ltimo, se deben planear los datos que necesitan ser recolectados o descritos. Tipos de informacin buscada en la investigacin Los tipos de muestras tiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El ltimo tipo incluye las subcategoras de muestreo sistemtico y muestreo estratificado. Hay varios lineamientos a seguir para la determinacin del tamao de muestra. El analista de sistemas puede hacer una decisin subjetiva en relacin con el estimado de intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamao de muestra necesario. El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorndums. Los datos relevantes muestran dnde ha estado la organizacin y hacia dnde creen sus miembros que estn yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos. Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos tambin puede cambiar a la organizacin. Las consignas que se colocan revelan la cultura oficial de la organizacin Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigacin de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigacin de archivos. Una de las desventajas del uso de datos archivados es que los datos pueden ser importantes solamente para aquel que originalmente los guard. ENTREVISTAS. El proceso de las entrevistas es un mtodo que usa el analista de sistemas para la recoleccin de datos sobre los requerimientos de informacin. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organizacin. Tambin vende el sistema durante las entrevistas. Las entrevistas son dilogos de preguntas respuestas planeados por anticipado entre dos personas.

Hay cinco pasos que deben tomarse para la planeacin previa de la entrevista: 1. Lectura de material de fondo 2. Establecimiento de objetivos de la entrevista 3. Decisin de a quin entrevistar 4. Preparacin del entrevistado 5. Decisin sobre el tipo y estructura de las preguntas Las preguntas tienen dos tipos bsicos: abiertas y cerradas. Las preguntas abiertas dejan abiertas todas las opciones de respuesta para el entrevistado, Las preguntas cerradas limitan las opciones posibles de la respuesta. Las averiguaciones pueden ser abiertas o cerradas, pero le solicitan al interlocutor una respuesta ms detallada. Las entrevistas pueden estar estructuradas en tres formas bsicas, estructura de pirmide, de embudo o de rombo. Lasestructuras piramidales comienzan con preguntas cerradas y detalladas y se amplan a preguntas ms generales. Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas ms especficas. Las estructuras de rombo combinan las fuerzas de las otras dos estructuras pero se llevan ms tiempo para realizarse. Hay compromisos involucrados sobre la decisin de cmo estructurar para realizar las preguntas y secuencias de preguntas de la entrevista. Las entrevistas deben ser grabadas por medio de grabadoras de cinta o la toma de notas. Despus de la entrevista, el entrevistador debe escribir un reporte que liste los puntos principales que se proporcionaron, as como opiniones acerca de lo que fue dicho. Es extremadamente importante documentar la entrevista lo ms pronto posible despus de que haya sido realizada. Para reducir tanto el tiempo como el costo de las entrevistas personales, los analistas pueden considerar el diseo conjunto de aplicaciones (JAD) como una alternativa. Mediante el uso del JAD los analistas logran tanto el anlisis de requerimientos como el diseo de la interfaz de usuario con los usuarios en un lugar de reunin de grupo. La valoracin cuidadosa del lugar de reunin para la organizacin ayudar a juzgar al analista si el JAD es una alternativa adecuada. USO DE CUESTIONARIOS. Mediante el uso de cuestionarios los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y caractersticas de gentes importantes en la organizacin. Los cuestionarios son tiles s: las personas de la organizacin estn ampliamente dispersas, muchas gentes estn involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilizacin del problema antes de que se realicen entrevistas. Una vez que han sido articulados los objetivos del cuestionario, el analista puede comenzar a escribir preguntas abiertas o cerradas. La seleccin de la redaccin es extremadamente importante y debe reflejar el lenguaje de los miembros de la organizacin. Idealmente, las preguntas deben ser simples, especficas, sin ascendencia, sin menosprecio, tcnicamente precisas y dirigidas a aquellos que tienen el conocimiento. La asignacin de

escalas es el proceso de asignar nmeros u otros smbolos a un atributo o caracterstica. Tal vez quiera el analista de sistemas usar escalas para medir las actitudes o las caractersticas de los interlocutores o para hacer que los interlocutores acten como jueces sobre el tema del cuestionario. Las cuatro formas de medicin son escalas nominales, ordinales, de intervalo y de relacin. La forma de medicin es frecuentemente indicada por los datos, y el anlisis de los datos es a su vez indicado en alguna medida por la forma de medicin. Los analistas de sistemas necesitan tomar en consideracin la validez y la confiabilidad. La validez significa que el cuestionario mide lo que el analista de sistemas pretendi medir. La confiabilidad significa que los resultados son consistentes. Los analistas deben ser cuidadosos para evitar problemas como lenidad, tendencia central y el efecto de halo cuando construyen escalas. El control consistente del formato y estilo del cuestionario puede dar como resultado una mejor tasa de respuesta. Adicionalmente, el ordenamiento y agrupamiento significativo de las preguntas es importante para ayudar a que los interlocutores comprendan el cuestionario. OBSERVACIN DEL COMPORTAMIENTO DE DECISIONES Y EL AMBIENTE DE OFICINA. LOS TOMADORES DE

Los analistas usan la observacin como una tcnica de recopilacin de ir, formacin. Por medio de la observacin obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organizacin, comprenden la influencia del ambiente fsico de ste, interpretan los mensajes enviados por el tomador por medio de su vestimenta y el acomodo de su oficina y comprenden la influencia del tomador de decisiones con respecto a los dems. Usando el muestreo de tiempos o eventos, el analista observa las actividades tpicas del tomador de decisiones y su lenguaje corporal. Hay varios sistemas para registrar tales observaciones, incluyendo sistemas di categoras, listas de verificacin, escalas, notas de campo y guiones. Adems de la observacin del comportamiento del tomador de decisiones, el analista de sistemas debe observar tambin lo que le rodea. Un mtodo para la observacin estructurado del ambiente es llamado STROBE, Un analista de sistemas usa STROBE en la misma forma que un crtico de cine usa un mtodo llamado mise-en-scne para analizar una toma de una pelcula Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicacin de la oficina, (2) la ubicacin del escritorio del tomador de decisiones, (3) el equipo de oficina fijo, (4) las propiedades, tales como calculadoras y pantallas, (5) revistas del negocio y peridicos,

(6) iluminacin y color de la oficina (7) la vestimenta usada por el tomador de decisiones. Se puede usar STROBE para obtener una mejor comprensin sobre la manera en que los tomadores de decisiones actualmente recopilan, procesan, guardan y comparten informacin, Hay varias alternativas para la aplicacin de STROBE en una organizacin. Estas incluyen el anlisis de fotografas, el uso de una lista de verificacin con base en laescala Likert, la adopcin de una lista anecdtica con smbolos y la simple escritura de una comparacin de observacin/narrativa, Cada mtodo tiene determinadas ventajas, as como desventajas, que el analista debe sopesar cuando seleccione una alternativa sobre la otra. PROTOTIPOS. La elaboracin de prototipos es una tcnica de recopilacin de informacin til para complementar el ciclo de vida de desarrollo de un sistematradicional. Cuando el analista de sistemas usa prototipos est buscando reacciones, sugerencias, innovaciones y planes de revisin del usuario para hacer mejoras al prototipo y, por lo tanto, modificar los planes del sistema con un mnimo de gastos y trastornos. Los sistemas que apoyan la toma de decisiones semiestructuradas (tal como lo hacen los sistemas de apoyo a decisiones) son buenos candidatos para la elaboracin de prototipos. El trmino prototipo tiene diferentes significados, de los cuales son comnmente usados cuatro de ellos. La primera definicin de la elaboracin de prototipos es la de construccin de un prototipo parchado. Una segunda definicin es un prototipo no operacional que es usado para probar determinadas caractersticas del diseo. Un tercer concepto es la creacin de un prototipo primero de la serie que es completamente operacional. Este tipo de prototipo es til cuando estn planeadas muchas instalaciones del mismo sistema de informacin (bajo condiciones similares). El cuarto tipo es un prototipo con caractersticas seleccionadas que tiene algunas, pero no todas, de las caractersticas esenciales del sistema. Usa mdulos auto contenidos como bloques de construccin, para que si las caractersticas prototpicas son satisfactorias puedan ser conservadas e incorporadas en el sistema terminado mucho ms grande. Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en mdulos manejables, (2) construir el prototipo rpidamente, (3) modificar el prototipo (4) enfatizar la interfaz de usuario. Una desventaja de los prototipos es que el manejo del proceso de elaboracin del prototipo es difcil, debido a la rapidez del proceso y a sus muchas iteraciones. Una segunda desventaja es que puede haber presiones para que sea puesto en servicio un prototipo incompleto, como si fuera un sistema completo. Aunque la

elaboracin de prototipos no es siempre necesaria o deseable, debe hacerse notar que hay tres ventajas principales interrelacionadas de su uso: (1) el potencial para cambiar el sistema en etapas tempranas de su desarrollo, (2) la oportunidad de detener el desarrollo de un sistema que no es funcional (3) la posibilidad de desarrollar un sistema que satisfaga en mejor forma las necesidades y expectativas de los usuarios. Los usuarios tienen un papel distinguido en el proceso de elaboracin de prototipos. Su primer inters debe ser interactuar con el prototipo mediante experimentacin. Los analistas de sistemas deben trabajar sistemticamente para obtener y evaluar las reacciones de los usuarios ante el prototipo, y luego trabajar para incorporar las sugerencias e innovaciones de los usuarios que valgan la pena en las modificaciones subsecuentes. En esta etapa se logra la claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solucin que esta buscando Actividades tcnicas 1. 2. 3. 4. 5. Identificar casos de uso del sistema Dar detalle a los casos de uso descritos Definir una interfaz inicial del sistema (si es aplicable) Desarrollar el modelo del mundo Validar los modelos

Documentos entregables 1. Casos de uso iniciales 2. Borradores de interfaz 3. Modelo del mundo inicial

Actividades Tcnicas
1. Identificar Casos de Uso del sistema Esta informacin se representa en un diagrama de casos de uso Cmo encontrar un actor ?

Identifique los usuarios del sistema o Porqu se disea el sistema? o Cules son los actores que el sistema va a beneficiar? o Qu actores van a interactuar directamente con el sistema? (actores primarios) o Qu actores van a supervisar, mantener, recibir informacin del sistema? (actores secundarios) Identifique los roles que juegan esos usuarios desde el punto de vista del

sistema Identifique otros sistemas con los cuales exista comunicacin

Cmo encontrar un caso de uso? Identifique las operaciones importantes del sistema a construir Cules son las principales tareas de un actor? Qu informacin tiene el actor que consultar, actualizar, modificar? Cmo? Qu cambios del exterior debe informar el actor al sistema? Qu informacin debe informrsele al actor, con respecto a los cambios del sistema? Cmo encontrar relaciones entre actores y casos de uso? Identifique los casos de uso en los cuales se v implicado un actor Busque relaciones extends entre casos de uso Qu casos de uso son similares, diferencindose en la forma en la cual hacen algunas operaciones? Qu caso de uso redefine la forma en la cual se realiza una transaccin dentro de otro caso de uso? Busque relaciones uses entre casos de uso Que casos de uso son usados como transacciones de otros? 2. Dar detalle a los casos de uso descritos Describir la informacin de entrada y salida de cada caso de uso Descripcin detallada del caso de uso

Descripcin textual de su objetivo Variantes posibles para realizar este caso de uso. Diagramas de interaccin de detalle (de secuencia o colaboracin) Errores y excepciones posibles en el caso de uso

Relacionar el caso de uso con la interfaz a usuario que lo representa Especificar el dilogo que da solucin al caso de uso (ver definicin de interfaz)

3. Definir una interfaz inicial del sistema (si es aplicable) Dibujar las pantallas de interaccin para los distintos actores-usuarios Copiar el modelo mental del usuario Revisar los elementos del modelo del mundo interesantes para el actor-usuario (Ver Modelo del Mundo) Visualizacin tpica de los elementos del modelo del mundo Informacin relevante para el actor Metforas de interaccin vlidas Especificar el dilogo que da solucin a cada caso de uso que se soluciona con la interaccin con esta interfaz. Puede especificarse este dilogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se sugiere escoger el mnimo nivel de detalle posible, para dar ms libertad de diseo en las etapas posteriores): 1. Por medio de una descripcin textual de su funcionamiento 2. Por medio de diagramas de interaccin que muestren la secuencia de operaciones entre los objetos de interfaz y los actores involucrados 3. Por medio de diagramas de estados, donde se muestre claramente los estados de la interfaz Por medio de un prototipo funcional, en trminos de la interaccin con el usuario Definir restricciones para la comunicacin con actores y sistemas Describir en el detalle del actor o de la relacin con el caso de uso particular

4. Desarrollar el modelo del mundo

Esta informacin se representa en un diagrama de estructura esttica de clases Identificar Clases


Elementos fsicos y lgicos dentro del sistema a modelar Top-down: Comenzar por la clase del objeto ms general (el mundo). Encontrar sus componentes hasta llegar a clases de tipos bsicos Identificar los sustantivos del enunciado del problema y determinar si son clases del modelo del mundo Identificar clases desde el punto de vista de la informacin o Identifique los elementos del espacio del problema o Identifique otros sistemas relacionados como objetos externos o Identifique dispositivos relacionados o Identifique los eventos que el sistema debe recordar y manipular o Identifique los roles de los elementos del mundo o Identifique sitios

o Identifique unidades organizacionales importantes en el problema Identificar clases desde el punto de vista funcional (casos de uso) o Identifique los objetos que participan en un caso de uso particular o Continue con los mensajes de cada objeto, dejando para el final los atributos. Identificar clases desde el punto de vista de sus estados o En qu estados est en sistema? Cules objetos determinan estos estados? o Cmo es el ciclo de vida de estos objetos?

Posibles errores:

Una clase HACE en vez de una clase ES Solo se requiere un objeto de la clase Dificultad para encontrar atributos Objetos con iniciativa propia Es un objeto y un usuario a la vez Solo se encuentra un servicio Varias clases tienen los mismos atributos o servicios Solo tienen informacin o mensajes no relevantes para el problema Vista Funcional: Dividir un sistema de la manera clsica

Identificar atributos y asociaciones.


Cules son las caractersticas determinantes del objeto en el dominio del problema? Con qu objetos esta relacionado? Con qu objetos debe estar relacionado para realizar sus mensajes? Identificar el nombre, los roles y cardinalidad de las asociaciones Qu asociaciones hay de tipo partes y un todo (composicin)? Qu informacin se requiere en una clase para realizar su comportamiento?

Posibles errores

Identificar atributos o relaciones no relevantes a los casos de uso identificados Las relaciones no reflejan directamente la realidad

Identificar mensajes

Punto de vista funcional o Qu mensajes debe tener un objeto para colaborar en un caso de uso? Punto de vista de comportamiento o Qu comportamiento se espera de un objeto dado en el modelo del mundo?

o o o

Qu mensajes se requieren para manipular la informacin que contienen? Qu mensajes requieren para manipular las relaciones que tiene? Qu mensajes hacen que el objeto cambie de un estado a otro?

Posibles errores

Identificar servicios no relevantes a los casos de uso identificados Identificar servicios que no puede realizar la clase por falta de informacin

Identificar relaciones de herencia


Qu clases son abstracciones naturales de clases ya existentes? Qu clases comparten atributos o servicios? Qu clases extienden atributos o servicios de otras?

Posibles Errores

No tener una relacin Es Un entre las clases

Identificar restricciones del modelo


Identificar valores posibles y no posibles de los atributos. Describirlos como restricciones de las clases Identificar valores permitidos para las asociaciones. Describirlos como restricciones de la asociacin Identificar restricciones que relaciones dos o ms atributos o relaciones. Describirlas dentro de la clase correspondiente

Posibles errores

Hay estados en el modelo imposibles en el mundo real Hay estados en el mundo real no considerados en el modelo

Identificar paquetes

Qu subdivisiones lgicas pueden tener las clases identificadas? Que subconjunto de clases y casos de uso pueden ser reutilizados en otros dominios? Combinar clases fuertemente relacionadas en un paquete Combinar clases que tienen que ver con los mismos casos de uso en un paquete

Consideraciones de reutilizacin

Reutilizar modelos de dominio existentes Identificar posibles variantes en el futuro tenerlas en cuenta para diseo (patrones)

5. Validar los modelos Validar las restricciones descritas para las clases

Para cada clase evaluar la completitud de las restricciones Desarrollar objetos ejemplo que cumplan con las restricciones y que no sean vlidos en el mundo real

Validar atributos y mensajes


La clase tiene toda la informacin necesaria para desarrollar la tarea? La clase tiene las relaciones necesarias para propagar el mensaje y cumplir con la tarea? Los mensajes si son utilizados dentro del contexto del problema? Los mensajes obligan la conservacin de las restricciones del modelo?

Desarrollar diagramas de interaccin (diagramas de secuencia o de colaboracin) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes.

Escoger la opcin por defecto de cada caso de uso Identificar los objetos involucrados Desarrollar el diagrama de secuencia o el de colaboracin para la interaccin

Validar los diagramas de Interaccin


Todo mensaje de un objeto a otro implica una asociacin y un rol en el diagrama de clases Todo mensaje est definido en su correspondiente clase Opcional: Completar el diagrama de clases con asociaciones de dependencia a las clases de los argumentos de los mensajes

Validar con un experto del dominio


Validar estructura del mundo Validar funcionalidad esperada del sistema Validar los diagramas de interaccin descritos como detalle de los casos de uso

Validar con un usuario representativo de cada actor

Validar la funcionalidad esperada para el actor en particular: completitud, relevancia

Validar los diagramas de interaccin descritos como detalle de los casos de uso del actor Validar la interfaz diseada y el dilogo descrito

Iterar si es necesaria ms informacin

Documentos Entregables
Casos de Uso iniciales Borradores de Interfaz Modelo del mundo Requerimientos ms importantes del sistema Usuarios y sistemas externos en comunicacin Especificacin de requerimientos Presentaciones iniciales para los distintos usuarios de la forma de solucionar sus requerimientos Clases, relaciones entre clases y especificaciones

Bibliografa

http://webdocs.cs.ualberta.ca/~pfiguero/soo/metod/requerimientos.html http://www.monografias.com/trabajos55/analisis-sistemas-informacion/analisis-sistemasinformacion2.shtml

S-ar putea să vă placă și