Taller 5

“El más importante y principal negocio público es la buena educación de la juventud. Platón”

1. Desarrolle los diagramas de flujo de datos, el diccionario de datos y la especificación de procesos para el módulo de atención al usuario de la biblioteca especializada de la Carrera de Informática.

2. Construya los diagramas de flujo de datos, el diccionario de datos y la especificación de procesos para el módulo de asignación de aulas a las diferentes materias del plan de estudios de la Carrera de Informática, a principios de semestre.

3. Utilice la entrevista, el prototipo y los diagramas de flujo de datos, desarrollados en talleres anteriores, para la tienda de compra y venta de teléfonos celulares “Androide”. Con estos documentos realice un diccionario de datos que considere al menos los siguientes elementos: (a) cliente, (b) vendedor, (c) producto, (d) registro de cliente, (e) venta al contado, (f) venta al crédito.

4. Utilice la entrevista, el prototipo, los diagramas de flujo de datos y el diccionario de datos, desarrollados para la tienda de compra y venta de teléfonos celulares “Androide”. Con estos documentos realice una representación en lenguaje estructurado, una tabla de decisión y un árbol de decisión, según corresponda, para los siguientes procesos: (a) inventario de productos, (b) venta de celulares.

5. Escriba un resumen comentado utilizando el siguiente texto: “…Las especificación de procesos están vinculados a los diagrama de flujo y por consiguiente también a los diccionarios de datos. Este se debe registrar en un formulario especial. (1) Lenguaje estructurado. Este lenguaje es utilizado cuando la lógica del proceso involucra formula o interacciones o cuando las decisiones no son nada complejas. Esta técnica ayuda a analizar el proceso de decisiones, este se basa en lógica estructurada. Este utiliza instrucciones o palabras claves como son el IF, THEN, ELSE, DO, DO WHILE, DO UNTIL y PERFORM. Estas palabras claves son las únicas aceptadas por este lenguaje; y también es válido agregar sangrías, para así poder identificar la jerarquía de la estructura dependiendo del proceso de decisión. (2) Tabla de decisiones. Esta es una tabla como cualquier otra, ya que contiene filas y columnas, separas en cuatro cuadrantes. En las cuales se encuentran las condiciones, las reglas, sus acciones y las entradas de las acciones. Para determinar las acciones, la lógica se mueve en el sentido de las manecillas del reloj empezando por la parte izquierda. Para desarrollarla el analista tiene que determinar que tamaño tendrá la tabla, los pasos siguientes proporcionan al analista un método sistematizado: (a) Determine el número de condiciones que podrían afectar la decisión. (b) Determine el número de posibles acciones que se pueden realizar. (c) Determine el número de alternativas de condición para cada condición. (d) Calcule el número máximo de columnas en la tabla de decisión multiplicando el número de alternativas para cada condición. (e) Complete las alternativas de condición. (f) Complete la tabla insertando una X en donde las reglas indiquen ciertas acciones. (g) Combine las reglas en donde sea evidente que una alternativa no representa una diferencia en el resultado. (h) Verifique si la tabla contiene situaciones imposibles, contradicciones y redundancias. (i) Reorganice las condiciones y acciones (o incluso las reglas) si esto hace más comprensible la tabla de decisión. (3) Árbol de decisiones. Este es el último método, se utiliza también para el análisis de decisiones, está compuesto por nodos y ramas. Este tipo de método está asociado con el método anterior que son las tablas de decisiones. También son apropiados ya que ayudan cuando las acciones que se realizaron son de cierta forma secuencialmente.”

NOTA
Las respuestas a este taller deben ser enviadas en formato .doc a la dirección de correo electrónico: saguicas@yahoo.com.mx, en el asunto debe indicar Taller 5 ADS, en el cuerpo debe incluirse los nombres, apellidos, número de cedula de identidad y dirección de mail de cada uno de los integrantes de grupo. El documento de respuestas debe acompañarse como documento adjunto.

Diccionario de datos y especificaciones de procesos

DICCIONARIO DE DATOS
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

Ejemplo
Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-materno
Título = [ Sr Sra Dr Ing]
Primer-nombre = {caracter}
Apellido-paterno = {caracter}
Apellido-materno = {caracter}
caracter = [A-Za-z]

Contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

Razones para su utilización
1. Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas más chicos hay gran cantidad de datos. Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles. Por eso se registra la información, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseñados específicamente para el análisis y diseño de software.

2. Para asignarle un solo significado a cada uno de los elementos y actividades del sistema. Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema y registrando detalles adicionales relacionados con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez.

3. Para documentar las características del sistema, incluyendo partes o componentes así como los aspectos que los distinguen. También es necesario saber bajo qué circunstancias se lleva a cabo cada proceso y con qué frecuencia ocurren. Produciendo una comprensión más completa. Una vez que las características están articuladas y registradas, todos los participantes en el proyecto tendrán una fuente común de información con respecto al sistema.

4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema. Determina si son necesarias nuevas características o si están en orden los cambios de cualquier tipo. Se abordan las características:
• Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo mientras se emplea el sistema.
• Preguntas: solicitudes para la recuperación o procesamiento de información para generar una respuesta específica.
• Archivos y bases de datos: detalles de las transacciones y registros maestros que son de interés para la organización.
• Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar transacciones y datos

5. Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores.

Contenido de un registro del diccionario
El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los elementos datos y estructura de datos.

Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos.

Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno está identificado con: Un nombre: para distinguir un dato de otro. Descripción: indica lo que representa en el sistema. Alias: porque un dato puede recibir varios nombres, dependiendo de quién uso este dato. Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada dato. Valores de los datos: porque en algunos procesos solo son permitidos valores muy específicos para los datos. Si los valores de los datos están restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario.

Estructura de datos: es un grupo de datos que están relacionados con otros y que en conjunto describen un componente del sistema.

Descripción: Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjunción con alguna otra. Relación secuencial: define los componentes que siempre se incluyen en una estructura de datos. Relación de selección: (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. Relación de iteración: (repetitiva), define la repetición de un componente. Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteración.

DESCRIPCIÓN DE ESPECIFICACIONES DE PROCESO.
Una vez que el analista identifica los flujos de datos y comienza a construir el diccionario de datos es tiempo de pasar a las especificaciones de proceso y análisis de decisiones. Los tres métodos para el análisis de decisiones y la descripción de la lógica de proceso tratados en este capítulo son: lenguaje estructurado, tablas de decisión y árboles de decisión.

Las especificaciones de proceso (o miniespecificaciones) son creadas para los procesos primitivos en un diagrama de flujo de datos así como para algunos procesos de alto nivel que explotan a diagramas hijos. Estas especificaciones explican la lógica de toma de decisiones y las fórmulas que transformarán los datos de entrada al proceso en salida.

Los tres objetivos de la especificación de proceso son: reducir la ambigüedad de los procesos, obtener una descripción precisa de lo que se logra y validar el diseño de sistema. Una gran parte del trabajo del analista de sistemas involucrará decisiones estructuradas, esto es, decisiones que pueden ser automatizados si suceden condiciones identificadas. Para lograr esto, el analista necesita definir cuatro variables en la decisión que está siendo examinada: condiciones, alternativas de condición, acciones y reglas de acción.
La manera en que las especificaciones de proceso se relacionan con el diagrama de flujo de datos.

Una forma para describir las decisiones estructuradas es usar el método mencionado como lenguaje estructurado, donde la lógica es expresada en estructuras secuenciales, estructuras de decisión, estructuras de caso o iteraciones.

El lenguaje estructurado usa palabras reservadas aceptadas, tales como SI, ENTONCES, SINO, HACER, HACER MIENTRAS y HACER HASTA para describir la lógica usada y usa sangrías para indicar la estructura jerárquica del proceso de decisión.

Las tablas de decisión proporcionan otra forma para examinar, describir y documentar decisiones. Cuatro cuadrantes (vistos en sentido del reloj a partir de la esquina superior izquierda) son usados para: (1) describir las condiciones, (2) identificar alternativas de decisión posibles (tales como S o N), (3) indicar cuáles acciones deben ser ejecutadas y (4) describir las acciones. Las tablas de decisión son ventajosas, debido a que las reglas para desarrollar la tabla misma, así como las reglas para eliminar redundancia, contradicciones y situaciones imposibles son directas y manejables. El uso de tablas de decisión promueve la integridad y precisión en el análisis de decisión estructuradas.

El tercer método para el análisis de decisiones es el árbol de decisión que consiste de nodos (un cuadrado para acciones y un círculo para condiciones) y ramas. Los árboles de decisión son adecuados cuando se deben realizar acciones en una secuencia determinada. No hay requerimientos de que el árbol tenga que ser simétrico, por lo que solamente se encuentran en una rama particular aquellas condiciones y acciones que son críticas para las decisiones presentes.

Cada uno de los métodos de análisis de decisión tiene sus propias ventajas y debe ser usado de acuerdo con ellas. El lenguaje estructurado es útil cuando muchas acciones son repetidas y cuando es importante la comunicación con otros. Las tablas de decisión proporcionan análisis completo de situaciones complejas y a la vez limitan la necesidad por cambios atribuibles a situaciones imposibles, redundancias o contradicciones. Los árboles de decisión son importantes cuando es crítica la secuencia adecuada de condiciones y acciones y cuando cada condición no es relevante para cada acción.

Taller 4

“No pidáis a la juventud otra cosa que no sea amor y alegría. Franz Tamayo”

1. Utilizando su experiencia de matriculación como estudiante de la Carrera de Informática, desarrolle un diagrama de flujo de datos que represente de manera lógica y física el proceso de matriculación estudiantil.

2. Utilice la entrevista y el prototipo de pantallas desarrollados, en talleres anteriores, para la tienda de compra y venta de teléfonos celulares “Androide”. Con estos documentos realice un diagrama de flujo de datos lógico y físico que analice los siguientes módulos: (a) Administración del inventario de celulares. (b) Venta de celulares con posibilidades de emisión de reporte de recibo o factura.

3. Escriba un resumen comentado utilizando el siguiente texto: “…El desarrollo de un programa o de un conjunto de aplicaciones se basa en un concepto llamado ciclo de vida. Son una serie de etapas o fases que hay que seguir secuencialmente. Las fases o etapas son: (1) Análisis. En esta fase se establece el producto a desarrollar, siendo necesario especificar los procesos y estructuras de datos que se van a emplear. Debe existir una gran comunicación entre el usuario y el analista para conocer todas las necesidades que precisa la aplicación. En el caso de falta de información por parte del usuario se puede recurrir al desarrollo de prototipos para saber con más precisión sus requerimientos. En el análisis estructurado se pueden emplear varias técnicas como: (a) Diagramas de flujo de datos: Sirven para conocer el comportamiento del sistema mediante representaciones gráficas. (b) Modelos de datos: Sirven para conocer las estructuras de datos y sus características. (Entidad relación y formas normales) (c) Diccionario de datos: Sirven para describir todos los objetos utilizados en los gráficos, así como las estructuras de datos. (d) Definición de los interfaces de usuario: Sirven para determinar la información de entrada y salida de datos. Al final de esta fase se debe tener de manera clara las especificaciones de la aplicación. (2) Diseño. En esta fase se alcanza con mayor precisión una solución optima de la aplicación, teniendo en cuenta los recursos físicos del sistema (tipo de ordenador, periféricos, comunicaciones, etc…) y los recursos lógicos. (sistema operativo., programas de utilidad, bases de datos, etc…) En el diseño estructurado se pueden definir estas etapas: (a) Diseño externo: Se especifican los formatos de información de entrada y salida. (pantalla y listados) (b) Diseño de datos: Establece las estructuras de datos de acuerdo con su soporte físico y lógico. (estructuras en memoria, ficheros y hojas de datos) (c) Diseño modular: Es una técnica de representación en la que se refleja de forma descendente la división de la aplicación en módulos. Está basado en diagramas de flujo de datos obtenidos en el análisis. (d) Diseño procedimental: Establece las especificaciones para cada modulo, escribiendo el algoritmo necesario que permita posteriormente una rápida codificación. Se emplean técnicas de programación estructurada, normalmente ordinogramas y pseudocódigo. Al final de esta etapa se obtiene el denominado cuaderno de carga. (3) Codificación. Consiste en traducir los resultados obtenidos a un determinado lenguaje de programación, teniendo en cuenta las especificaciones obtenidas en el cuaderno de carga. Se deben de realizar las pruebas necesarias para comprobar la calidad y estabilidad del programa. Las pruebas se pueden clasificar en: (a) Pruebas unitarias: Sirven para comprobar que cada módulo realice bien su tarea. (b) Pruebas de interconexión: Sirven para comprobar en el programa el buen funcionamiento en conjunto de todos sus módulos. (c) Pruebas de integración: Sirven para comprobar el funcionamiento correcto del conjunto de programas que forman la aplicación. (el funcionamiento de todo el sistema) (4) Explotación. En esta fase se realiza la implantación de la aplicación en el sistema o sistemas físicos donde van a funcionar habitualmente y su puesta en marcha para comprobar el buen funcionamiento. Actividades a tener en cuenta: (a) Instalación de los programas. (b) Pruebas de aceptación al nuevo sistema. (c) Conversión de la información del antiguo sistema al nuevo (si hay una aplicación antigua) (d) Eliminación del sistema anterior. Al final de esta fase se debe de completar la información al usuario respecto al nuevo sistema y su uso. Así como facilitarle toda la documentación necesaria para una correcta explotación del sistema (manual de ayuda, manual de uso, guía de la aplicación, etc.) (5) Mantenimiento. Esta es la fase que completa el ciclo de vida y en ella nos encargaremos de solventar los posibles errores o deficiencias de la aplicación. Existe la posibilidad de que ciertas aplicaciones necesiten reiniciar el ciclo de vida. Los tipos de mantenimiento son: (a) Mantenimiento correctivo: Consiste en corregir errores no detectados en pruebas anteriores y que aparezcan con el uso normal de la aplicación. Este mantenimiento puede estar incluido en la garantía o mantenimiento de la aplicación. (b) Mantenimiento adaptativo: Consiste en modificar el programa a causa de cambio de entorno gráfico y lógico en el que estén implantados. (nuevas generaciones de ordenadores, nuevas versiones del sistema operativo, etc.) (c) Mantenimiento perfectivo: Consiste en una mejora sustancial de la aplicación al recibir por parte de los usuarios propuestas sobre nuevas posibilidades y modificaciones de las existentes. Los tipos de mantenimiento adaptativo y perfectivo reinician el ciclo de vida, debiendo proceder de nuevo al desarrollo de cada una de sus fases para obtener un nuevo producto.”

NOTA
Las respuestas a este taller deben ser enviadas en formato .doc a la dirección de correo electrónico: saguicas@yahoo.com.mx, en el asunto debe indicar Taller 4 ADS, en el cuerpo debe incluirse los nombres, apellidos, número de cedula de identidad y dirección de mail de cada uno de los integrantes de grupo. El documento de respuestas debe acompañarse como documento adjunto.

Diagramas de Flujo de Datos

1. ANÁLISIS DE SISTEMAS
El término análisis, aplicado a sistemas, significa descomponerlos en sus componentes, para estudiar cada uno de ellos, tanto como un ente aislado, como en interacción con el resto. Para ser útil, al análisis le debe seguir la síntesis, que consiste en unir los componentes del sistema para ver cómo funcionan en conjunto.”

El objetivo del análisis es obtener una especificación del software del sistema. Los medios para el logro de los objetivos del análisis son: (1) Técnicas gráficas y (2) Descripciones complementarias.

El análisis de requisitos es equivalente a la especificación del software. La especificación es un documento que define de forma completa, precisa y verificable los requisitos, el diseño, el comportamiento u otras características de un sistema o componente del mismo. En tanto que el software es el conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático. Por consiguiente el análisis de requerimientos hace referencia a la documentación completa y precisa qué debe realizar el sistema para cubrir los requisitos de usuario.

1.1. Principios de análisis
Los principios del análisis de requerimientos son los siguientes:
a)Dominio de la información. Comprende el contenido de la información y las relaciones, el flujo de la información y la estructura de la información.
b)Modelado. Consta de modelos gráficos y descripciones complementarias, las cuales representan por una parte la información y por otra las funciones o transformaciones.
c)Partición. Se refiere a la representación jerárquica de la información o de las funciones.
d)Visión lógica. Hace referencia a la visión esencial del sistema. Fundamentalmente responde a las siguientes preguntas: Qué hace. Qué información utiliza. Por su parte la visión física hace mención a la visión de implementación. Esta última responde a las siguientes cuestiones: Cómo se hace. Qué soporte y formatos utiliza.

2. DIAGRAMA DE FLUJO DE DATOS
El diagrama de flujo de datos es una técnica que se utiliza principalmente para el modelado de sistemas informáticos. Representa el flujo de la información, las transformaciones que se aplican y los datos que se mueven desde la entrada a la salida en un sistema informático. Para otros autores, un diagrama de flujo de datos es un modelo lógico-gráfico, que ayuda a representar el funcionamiento de un sistema, este permite incorporar opciones para el depurado de algoritmos, facilitando la localización de errores de ejecución y lógicos más habituales.

El diagrama de flujo de datos proporciona mecanismos para:
a)Representar el Dominio de la Información.
• Diagramas, que comprenden el flujo y las transformaciones.
• Diccionario, que comprende el contenido y la estructura.
• Especificación, que hace referencia a la descripción de las transformaciones.
b)Modelar los procesos informatizados y los datos.
c)Dividir de forma jerárquica los procesos.

2.1. Componentes de los diagramas de flujo de datos
a)Procesos. Representan las transformaciones de la Información. Cuentan con un nombre único y representativo (verbo + objeto). Un identificador asociado a una numeración jerárquica y una representación gráfica asociada.






b)Flujo de datos. Representan los bloques de información que se desplazan entre procesos y otro componente. Contienen un nombre significativo relacionado con la información que transportan. Cuentan con un identificador asociado a un número secuencial.




c) Almacenes de datos. Representan la información en reposo del sistema. Cuentan con un nombre único y representativo de la información. Tienen un identificador asociado a un número secuencial.







d)Entidades externas. Representan a las personas como también a entes generadores o receptores de información. Presentan un nombre único y representativo. Cuentan con una numeración secuencial como identificador.






e)Ampliaciones para sistemas en tiempo real. La ampliación propuesta por Ward y Mellor permite representar:
• Flujos de información que se producen o generan de forma continúa en el tiempo.
• Información y procesos de control.
• Estados de los sistemas.






2.2. Construcción de un diagrama de flujo de datos
Para la construcción de un diagrama de flujo de datos, de manera inicial, deben realizarse las siguientes interrogantes: (1) ¿Qué procesos deben integrar el sistema?, (2) ¿Qué datos emplea cada proceso del sistema?, (3) ¿Qué datos se almacenarán en cada proceso?, estas preguntas deben ser respondidas identificando los datos que se introducen y extraen de cada proceso. Esto se realiza tomando en cuenta los procesos de negocio de la empresa, existentes, revisados y futuros, y de la definición de los requisitos que es necesario que lleve a cabo el sistema informático para dar soporte al sistema de información.

Los pasos que se deben seguir para la construcción de un diagrama de flujo se encuentran clasificados en las siguientes dos técnicas:
(1) De arriba hacia abajo.
• Identificar las entidades externas involucradas.
• Identificar las entradas de datos que proporcionarán estas entidades
• Definir las salidas que se producirán.
• Dibujar el primer nivel.
• Realizar una primera explosión representando los procesos principales
• Conectar los flujos del primer nivel (conectados con entidades externas) con los procesos adecuados en cada caso.
• Identificar y representar los almacenes de datos y los flujos conectados a éstos.
• Mantener la consistencia.
• Repetir la subdivisión.

Se recomienda que la subdivisión de los procesos se realice en los siguientes casos:
• Cuando la especificación de la función pueda desarrollarse de forma adecuada y con un nivel de detalle conveniente al modelo.
• Cuando existan pocos flujos de entrada y salida.
• Cuando, si se descompone, se pierde el significado y se obtienen procesos excesivamente sencillos que no son representativos.

(2) De abajo hacia arriba
• Identificar transformaciones de datos de bajo nivel (Burbujas de bajo nivel.)
• Identificar la información de entrada y de salida (Flujos.)
• Identificar la información que debe almacenarse (Almacenes.)
• Identificar los productores y/o receptores de información (Entidades Externas.)
• Agrupar los procesos en otros que los contienen (Burbujas de nivel más alto.)
• Mantener la consistencia.

(3) Identificar los procesos de la empresa y cómo pueden ser informatizados. Los hechos del negocio son sucesos que se producen externamente al sistema, definiéndose los procesos informatizados asociados a cada uno de ellos. Para cada proceso se indica:
• Qué datos de entrada son necesarios.
• Quién o qué proporciona dichos datos.
• Qué información se produce.
• Cuál es su destino.

2.3 Evaluación del flujo de datos
Para la evaluación del flujo de datos se debe validar y verificar. Validar significa responder a la pregunta: ¿Se está diseñando el sistema correcto?. Verificar significa: ¿Se está diseñando el sistema de manera correcta?
• Todos los flujos, almacenes y procesos deben estar etiquetados.
• Todos los procesos tienen al menos un flujo de entrada y un flujo de salida.
• Los flujos que entran a un proceso deben ser los que necesita y sólo los que necesita.
• Los almacenes deben tener procesos que los actualicen y procesos que obtengan información de ellos (Salvo almacenes externos al proceso).
• Todos los flujos tienen al menos uno de sus extremos conectado con un proceso.
• Todos los almacenes y flujos deben estar descritos en el diccionario.
• Todos los procesos de más bajo nivel deben estar descritos convenientemente.
• Consideraciones gráficas sobre la presentación de los DFD: buena presentación, evitar que los flujos se crucen.

Taller 3

“Educación es lo que la mayoría recibe, muchos transmiten y pocos tienen. Karl Kraus”

1. Utilice la entrevista dirigida a los propietarios de la tienda de compra y venta de teléfonos celulares “Androide”, los señores Eduardo Flores y Julia Silva, para realizar un prototipo de pantallas que cubra los siguientes módulos: (a) Ingreso de celulares al inventario. (b) Administración del inventario de celulares. (c) Venta de celulares con posibilidades de emisión de reporte de recibo o factura.

2. Diseñe un prototipo de pantalla para aplicar, en una aplicación Web, la encuesta dirigida a los estudiantes de la Carrera de Informática, la misma debe servir para sentar las bases de un nuevo plan de estudios y el consiguiente sistema de seguimiento académico a dicho plan. Recuerde que la encuesta incluye el objetivo de la misma, preguntas de tipo abierto, cerrado y bipolares.

3. Escriba un resumen comentado utilizando el siguiente texto: “…En ingeniería del software, el modelo de prototipos pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado es posible iniciar el verdadero desarrollo del software. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Las etapas para el desarrollo de un prototipo son las siguientes (1) Plan rápido; (2) Modelado, diseño rápido; (3) Construcción del Prototipo; (4) Desarrollo, entrega y retroalimentación; (5) Comunicación. Entre las principales ventajas se puede mencionar que este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción hombre-máquina. La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto. Por su parte los inconvenientes en el desarrollo de prototipos se producen cuando el usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

NOTA
Las respuestas a este taller deben ser enviadas en formato .doc a la dirección de correo electrónico: saguicas@yahoo.com.mx, en el asunto debe indicar Taller 3 ADS, en el cuerpo debe incluirse los nombres, apellidos, número de cedula de identidad y dirección de mail de cada uno de los integrantes de grupo. El documento de respuestas debe acompañarse como documento adjunto.

8. Prototipos

Los prototipos constituyen una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información específica acerca de los requerimientos de información de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos.

Con la construcción de los prototipos, el analista se encuentra buscando las reacciones iniciales de los usuarios y de la administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisión que detallan la parte del sistema que necesita realizarse en primera instancia.

8.1. Tipos de información
Los tipos de información que busca el analista durante la elaboración de prototipos son los siguientes:
a) Reacciones. Son recopiladas por medio de observaciones, entrevista y formas de retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactúa con él. Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema.
b) Sugerencias. El analista también está interesado en las sugerencias de los usuarios y la administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo especifico. El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e interés en el proyecto de sistemas. Las sugerencias son el producto de la interacción de los usuarios con el prototipo. Estas sugerencias deben apuntar al analista hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios.
c) Innovaciones. Son parte de la información buscada por el equipo de análisis del sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo. Van más allá de las características prototípicas actuales añadiendo algo nuevo e innovador.
d) Plan de revisión. Ayuda a identificar prioridades para lo que se debe construir un prototipo. En situaciones donde están involucradas muchas ramas de la organización, los planes de revisión ayudan a determinar para quienes se debe construir un prototipo. La información recolectada, en la fase de reacciones del prototipo, permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de esfuerzo. La elaboración de prototipo y la planificación van mano a mano.

8.2. Tipos de prototipos
Según la clasificación proporcionada por Kendall & Kendall (2005) los prototipos se clasifican en los siguientes tipos:
a) Prototipo parchado. Es un sistema que tiene todas las características propuestas pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante.
b) Prototipo no operacional. La segunda concepción de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño. Este puede ser hecho cuando la codificación requerida por las aplicaciones es muy amplia y, sin embargo se puede obtener una idea útil del sistema por medio de la elaboración de prototipos de la entrada y salida solamente. Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podría no ser realizado, sin embargo se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo.
c) Prototipo primero de una serie. Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto. Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que se presente.
d) Prototipo de características seleccionadas. Un prototipo de características seleccionadas permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas posteriormente. Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final. Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta.

8.3. Desarrollo de prototipos
Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de problema está siendo resuelto y en qué forma el sistema presenta la solución.

Los lineamientos fundamentales para el desarrollo de prototipos son los siguientes:
a) Trabajar en módulos manejables. Es bueno que el analista trabaje en módulos manejables cuando se realiza el prototipo de algunas de las características de un sistema para obtener un modelo funcional. Un módulo manejable es aquel que permite la interacción con sus características principales, pero todavía puede ser construido por separado de otros módulos del sistema. Las características del módulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial.
b) Construcción rápida del prototipo. La velocidad es esencial para la elaboración satisfactoria de un prototipo en un sistema. El prototipo ayuda a acortar el tiempo de interacción del sistema con el usuario para que pueda empezar a experimentar con él. Se usan técnicas de recolección de información tradicional tales como: entrevistas, las observaciones e investigaciones de datos de archivo. La elaboración de un prototipo debe llevarse a cabo, a lo mas, en una semana; para construir un prototipo de manera tan rápida se deben de usar herramientas especiales tales como: Sistemas de administración de las base de datos y software, existente que permitan la entrada y salida generalizada. En esta etapa del ciclo de vida el analista sigue recopilando información acerca de lo que se necesita y quieren los usuarios del sistema. Poner un prototipo operacional rápidamente junto a las primeras etapas del ciclo de vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera en que se debe realizar el resto del proyecto. De este modo se va mostrando al usuario como actúan las partes del sistema.
c) Modificaciones del Prototipo. Un tercer lineamiento para el desarrollo del prototipo es que debe ser flexible para futura modificaciones. Esto significa crearlo en módulos que no sean muy interdependientes. Por lo general el prototipo es modificados varias veces pasando a través de varias interacciones. Los cambios al prototipo deben mover al sistema más cerca a lo que los usuarios dicen que es importante. Cada modificación necesita otras evaluaciones de los usuarios, estas modificaciones se deben realizar velozmente en uno o dos días, esto depende también del usuario y que tan rápida sea su evaluación.
d) Enfatizar la interfaz de usuario. La interfaz del usuario con el prototipo (y eventualmente con el sistema) es muy importante debido a que se trata de hacer que los usuarios muestren cada vez más sus requerimientos de información, debiendo ser capaz de interactuar fácilmente con el prototipo del sistema. El objetivo del analista es diseñar una interfaz que permita al usuario interactuar con el sistema con un mínimo de entrenamiento y que permita el máximo de control del usuario sobre las funciones representadas.

8.4. Ventajas y desventajas
Las desventajas de los prototipos asociados a los sistemas de información son las siguientes:
a) Puede ser bastante difícil manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema más grande.
b) Es que si un sistema es muy necesario y es bienvenido rápidamente, puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios. En este caso el prototipo no tendrá las funciones necesarias y eventualmente cuando se presenten las deficiencias se puede desarrollar un rechazo del usuario.

Por su parte las ventajas de los prototipos son las siguientes:
a) Cambio de un sistema en etapas tempranas de su desarrollo. La elaboración de prototipos satisfactoria depende de la retroalimentacion temprana y frecuente de los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta más ágil a las necesidades actuales. Los cambios tempranos son menos caros que los cambios hechos posteriormente en el desarrollo del proyecto.
b) Desechado de sistemas indeseables. Una segunda ventaja del uso de prototipos como una técnica para la recopilación de información es la posibilidad de desechar un sistema que no es lo que los usuarios y analistas esperaban.
c) Diseño de un sistema para las necesidades y expectativas de los usuarios. Una tercera ventaja de la elaboración de prototipos es que el sistema que está siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los usuarios. Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas más de cerca.

8.5. Rol del usuario en la construcción de prototipos
Hay tres formas principales en que un usuario puede ser de ayuda en la elaboración del prototipo.
a) Experimentando con el prototipo. Los usuarios deben tener libertad para experimentar con el prototipo, y no una simple lista de características del sistema, el prototipo permite a los usuarios la realidad de la interacción real. Los analistas deben estar presentes la mayor parte del tiempo en que se esté experimentando con el prototipo.
b) Reaccionar abiertamente ante el prototipo. Si los usuarios se sienten temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organización, es poco probable que se presenten reacciones abiertas ante el prototipo. Una forma para aislarlos de influencias organizacionales no deseada es proporcionar un periodo privado, para que los usuarios interactúen con y respondan al prototipo. El hacer que los usuarios se sientan lo suficientemente seguros para dar una reacción abierta es parte de la realización entre los analistas y usuarios que el equipo tiene que construir.
c) Sugerencias de cambios al prototipo. Un tercer aspecto del papel de los usuarios en la elaboración de los prototipos es sugerir adiciones o eliminaciones a las características que se están probando. El papel del analista es deducir tales sugerencias, asegurando a los usuarios que tal retroalimentación que proporciona es tomada en serio, observando a los usuarios mientras interactúan y realizando entrevistas cortas y específicas en relación con su experiencia con el prototipo.

Fuente: (Kendall & Kendall, 2005)

7. Observación estructurada

El método para la observación estructurada del ambiente es llamado STROBE, este método es sistemático debido a que:
(1) proporciona una metodología estándar y una clasificación estándar para el análisis de los elementos organizacionales que influencian la toma de decisiones,
(2) permite que otros analistas de sistemas apliquen el mismo marco de trabajo analítico a la misma organización,
(3) limita el análisis a la organización a como existe durante la etapa actual de su ciclo de vida.

7.1. Elementos observables
Existen siete elementos concretos que son fácilmente observables por el analista de sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo:
1. Ubicación de la oficina. Las oficinas accesibles tienden a incrementar la interacción y los mensajes informales. Las oficinas inaccesibles disminuyen la frecuencia de interacción e incrementan los mensajes orientados a la tarea. Las oficinas distribuidas dan como resultado la demora de reportes o memos en alguna de ellas, en cambio, los grupos de oficinas motivan que se comparta la información.
2. Ubicación del escritorio del tomador de decisiones. Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones.
3. Equipo de oficina fijo. Se conforma de archiveros, libreros, etc. Si no hay equipo, es probable que el tomador de decisiones guarde pocos conceptos de información personalmente. Si hay abundancia de equipo, es presumible que el tomador de decisiones almacene y valore mucha información.
4. Propiedades. Todo el equipo pequeño que se usa para procesar información calculadoras, pantallas de video, lápices, etc.)
5. Revistas y periódicos del negocio. Estas revelan si el tomador de decisiones busca información externa o se apoya más en información interna (reportes de la compañía, manuales de políticas, etc.)
6. Iluminación y color de la oficina. Nos indica la manera en que el tomador de decisiones recopila información. Un ejecutivo en una oficina iluminada cálidamente, recopilará más información informalmente y, en cambio, en una oficina brillantemente iluminada y coloreada se recolecta información mediante memorándums más formales y reportes oficiales.
7. Vestimenta usada por los tomadores de decisiones. El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes de la organización observando la vestimenta que usan en el trabajo. El traje formal de tres piezas para un hombre o el traje sastre para mujer, representan la máxima autoridad de acuerdo con algunos investigadores que han estudiado la percepción de la apariencia de los ejecutivos.

Mediante el uso de STROBE el analista de sistemas puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información.

7.2. Estrategias
Existen estrategias para llevar a cabo los pasos antes mencionados:
• Análisis de fotografías. Consiste en fotografiar el ambiente de los tomadores de decisiones y análisis posterior de las mismas sobre los elementos STROBE.
• Enfoque de las listas de verificación/escala LIKERT. Es menos estructurada. Son listas con escalas en relación con características del tomador de decisiones que fueron observables por medio de elementos físicos en los ambientes organizacionales de los tomadores de decisiones y existen rangos para la evaluación.
• Lista anecdótica con símbolos. Es menos estructurada. Consiste en usar analistas de verificación anecdótica con símbolos de abreviaturas significativas. Sirve para evaluar los elementos STROBE en comparación con la narración organizacional generada por medio de entrevistas. símbolos (es una lista con situaciones especificas y diversas respuestas que son dadas a través de símbolos)

7.3. Aplicación de STROBE
Existen varias alternativas para la aplicación de STROBE en una organización, algunas son las siguientes:
1. Determinar los temas organizacionales principales que se desprenden de las entrevistas.
2. Se construye una matriz, que liste las ideas principales a partir de la narrativa organizacional, acerca de la recopilación, procesamiento, almacenamiento y compartición de la información (los renglones) y elementos STROBE (columnas).
3. Se compara la narrativa y las acciones, se usa uno de los cinco símbolos adecuados para caracterizar la relación entre la narración y el elemento relevante.
4. El analista crea una tabla que primero documenta y luego ayuda en el análisis de las observaciones.

Fuente: (Kendall & Kendall, 2005)

Taller 2

1. Utilizando la población compuesta por los estudiantes de la materia INF 162 “Análisis y Diseño de Sistemas”, obtenga una muestra aleatoria simple de tamaño n=10, con la cual pueda determinar lo siguiente: (a) Porcentaje de varones que viven en la Ciudad de El Alto, (b) Porcentaje de mujeres que viven en la Ciudad de La Paz.

2. Utilizando la población compuesta por los estudiantes de la materia INF 162 “Análisis y Diseño de Sistemas”, obtenga una muestra aleatoria simple de tamaño n=12, con la cual pueda determinar lo siguiente: (a) Porcentaje de la cantidad de libros que leen los estudiantes que tienen computadora propia. (b) Porcentaje de la cantidad de libros que leen las estudiantes que no tienen computadora propia.

3. Diseñe una entrevista dirigida a los propietarios de la tienda de compra y venta de teléfonos celulares “Androide”, los señores Eduardo Flores y Julia Silva; la entrevista debe incluir preguntas abiertas y cerradas para determinar la mayor cantidad de información útil acerca de este rubro comercial.

4. Diseñe una encuesta dirigida a los estudiantes de la Carrera de Informática, la misma debe servir para sentar las bases de un nuevo plan de estudios y el consiguiente sistema de seguimiento académico a dicho plan. La encuesta debe incluir el objetivo de la misma, preguntas de tipo abierto, cerrado y bipolar.

5. Escriba un resumen comentado utilizando el siguiente texto: “…Las preguntas “cerradas” son fáciles de codificar y preparar para su análisis. Asimismo, estas preguntas requieren de un menor esfuerzo por parte de los respondientes. Éstos no tienen que escribir o verbalizar pensamientos, sino simplemente seleccionar la alternativa que describa mejor su respuesta. Responder a un cuestionario con preguntas cerradas toma menos tiempo que contestar a uno con preguntas abiertas. Si el cuestionario es enviado por correo, se tiene una mayor respuesta cuando es fácil de contestar y requiere menos tiempo completarlo. La principal desventaja de las preguntas “cerradas” reside en que limitan las respuestas de la muestra y —en ocasiones— ninguna de las categorías describe con exactitud lo que las personas tienen en mente, no siempre se captura lo que pasa por las cabezas de los sujetos. Para formular preguntas “cerradas” es necesario anticipar las posibles alternativas de respuesta. De no ser así es muy difícil plantearías. Asimismo, el investigador tiene que asegurarse que los sujetos a los cuales se les administrarán, conocen y comprenden las categorías de respuesta. Por ejemplo, si preguntamos qué canal de televisión es el preferido, determinar las opciones de respuesta y que los respondientes las comprendan es muy sencillo. Pero si preguntamos sobre las razones y motivos que provocan esa preferencia, determinar dichas opciones es algo bastante más complejo. Las preguntas “abiertas” son particularmente útiles cuando no tenemos infor­mación sobre las posibles respuestas de las personas o cuando esta información es insuficiente. También sirven en situaciones donde se desea profundizar una opinión o los motivos de un comportamiento. Su mayor desventaja es que son más difíciles de codificar, clasificar y preparar para su análisis. Además, pueden presentarse sesgos derivados de distintas fuentes: por ejemplo, quienes tienen dificultades para expresarse oralmente y por escrito pueden no responder con precisión lo que realmente desean o generar confusión en sus respuestas. El nivel educativo, la capacidad de manejo del lenguaje y otros factores pueden afectar la calidad de las respuestas. Asimismo, responder a preguntas “abiertas” requiere de un mayor esfuerzo y tiempo.

NOTA
Las respuestas a este taller deben ser enviadas en formato .doc a la dirección de correo electrónico: saguicas@yahoo.com.mx, en el asunto debe indicar Taller 2 ADS, en el cuerpo debe incluirse los nombres, apellidos, número de cédula de identidad y dirección de mail de cada uno de los integrantes de grupo. El documento de respuestas debe acompañarse como documento adjunto.

Análisis de Requerimientos de Información

2.1. MUESTREO E INVESTIGACIÓN DE DATOS IMPRESOS

El proceso de seleccionar sistemáticamente elementos representativos de una población es llamado muestreo. El objeto del muestreo es seleccionar v estudiar documentos, tales como facturas, reportes de ventas y memorándums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organización. El muestreo puede reducir costos, velocidad de recolección de datos, hacer potencialmente que el estudio sea más efectivo y posiblemente reducir la ascendencia en el estudio.

Tabla 2.1. Tipos principales de muestras que tiene el analista
No basadas en probabilidad ...... Basadas en probabilidad
Conveniencia .......................................... Aleatoria simple
Intencionada .......................................... Aleatoria compleja

Un analista de sistemas debe seguir cuatro pasos en el diseño de una buena muestra. Primero, se tiene la necesidad de determinar la población misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamaño de muestra. Por último, se deben planear los datos que necesitan ser recolectados o descritos.

2.1.1. Tipos de información buscada en la investigación

Los tipos de muestras útiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El último tipo incluye las subcategorías de muestreo sistemático y muestreo estratificado. Hay varios lineamientos a seguir para la determinación del tamaño de muestra. El analista de sistemas puede hacer una decisión subjetiva en relación con el estimado de intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamaño de muestra necesario.

El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorándums. Los datos relevantes muestran dónde ha estado la organización y hacia dónde creen sus miembros que están yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos. Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos también puede cambiar a la organización.

Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigación de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigación 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ó.

2.2. ENTREVISTAS

El proceso de las entrevistas es un método que usa el analista de sistemas para la recolección de datos sobre los requerimientos de información. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organización. También vende el sistema durante las entrevistas. Las entrevistas son diálogos de preguntas respuestas planeados por anticipado entre dos personas.

Hay cinco pasos que deben tomarse para la planeación previa de la entrevista:
1. Lectura de material de antecedentes
2. Establecimiento de objetivos de la entrevista
3. Decisión de a quién entrevistar
4. Preparación del entrevistado
5. Decisión sobre el tipo y estructura de las preguntas

Las preguntas tienen dos tipos básicos: abiertas y cerradas.

Tabla 2.2. Preguntas de entrevista cerradas
Grado de educación
1. Primaria
2. Bachillerato
3. Técnico
4. Universitario

Nivel socioeconómico
1. Alto
2. Medio
3. Bajo

Sexo
1. Masculino
2. Femenino

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 más detallada.

Tabla 2.3. Preguntas de entrevista abiertas
¿Cuál es su opinión del sistema computacional actual?
¿Cómo observa los objetivos de este departamento?
¿Cuáles son los problemas que experimenta para recibir la información a tiempo?
¿Cuáles son las fallas que se cometen en la captura de datos?
Describa el sistema computacional más frustrante con el que haya trabajado
¿Cuál es su opinión acerca del formato de informes mensuales del departamento?

Tabla 2.4. Preguntas de entrevista bipolares
¿Es usted propietario de una computadora personal?
¿Utiliza una computadora personal en su puesto de trabajo?
¿Está de acuerdo con las funciones de la secretaria de la oficina?
¿Desea recibir una impresión de su estado de cuenta cada mes?
¿Su departamento proporciona transferencias de fondos de los cheques para los empleados por horas?
¿Se encuentra este formulario completamente llenado?

2.3. USO DE CUESTIONARIOS.

Mediante el uso de cuestionarios los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y características de gentes importantes en la organización. Los cuestionarios son útiles sí: las personas de la organización están ampliamente dispersas, muchas gentes están involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilización 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 selección de la redacción es extremadamente importante y debe reflejar el lenguaje de los miembros de la organización. Idealmente, las preguntas deben ser simples, específicas, sin ascendencia, sin menosprecio, técnicamente precisas y dirigidas a aquellos que tienen el conocimiento.

La asignación de escalas es el proceso de asignar números u otros símbolos a un atributo o característica. Tal vez quiera el analista de sistemas usar escalas para medir las actitudes o las características de los interlocutores o para hacer que los interlocutores actúen como jueces sobre el tema del cuestionario.

Las cuatro formas de medición son escalas nominales, ordinales, de intervalo y de relación. La forma de medición es frecuentemente indicada por los datos, y el análisis de los datos es a su vez indicado en alguna medida por la forma de medición. Los analistas de sistemas necesitan tomar en consideración 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.

Fuente: (Kendall & Kendall, 2005)