RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS

4.11    RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS   

Existen métodos que nos permiten tener acceso, a la recopilación de información necesaria para saber o identificar problemas dentro de una organización.

4.11.1        ENTREVISTAS

Una entrevista es utilizada para recabar información, se necesita obtener las opiniones de los entrevistados y su parecer acerca del estado actual del sistema, metas organizacionales y personales y procedimientos informales.

Hay cinco pasos para poder preparar una entrevista

ü  Leer los antecedentes

ü  Establecer los objetivos de la entrevista

ü  Decidir a quién entrevistar

ü  Preparar al entrevistado

ü  Decidir el tipo de preguntas y la estructura

4.11.2        TIPOS DE PREGUNTAS

Existen diversidad de tipos de preguntas y cada una es usada de acuerdo a las necesidades o que tanto de información es requerida y es importante aplicar el método que vamos a usar para realizar dichas preguntas de acuerdo a su tipo.

·         Preguntas abiertas

Estas preguntas incluyen aquellas como "¿Qué piensa de poner a todos los gerentes en una intranet?" y "Explique por favor cómo toma una decisión de programación de producción.

En realidad, "abiertas" describe las opciones del entrevistado para responder.

·         Preguntas cerradas

Tales preguntas son de la forma básica: "¿Cuántos subordinados tiene?" Las respuestas posibles se cierran al entrevistado, debido a que sólo puede contestar con un número finito como "Ninguno", "Uno" o "Quince". Una pregunta cerrada limita la respuesta disponible para el entrevistado.

A más de eso, para la aplicación de las preguntas, el responsable puede optar por las siguientes técnicas y métodos para realizar su entrevista:

·         Uso de una estructura de pirámide

Con base en esta forma, el entrevistador empieza con preguntas, a menudo cerradas, muy detalladas. Posteriormente, el entrevistador extiende los temas permitiendo preguntas abiertas y respuestas más generalizadas.

Debe utilizar una estructura de pirámide si cree que su entrevistado necesita motivación para profundizar en el tema. También es conveniente utilizar una estructura de pirámide para la secuencia de las preguntas cuando desea una opinión concluyente del tema.

·         Uso de una estructura de embudo

En el segundo tipo de estructura, el entrevistador adopta un método deductivo al iniciar con preguntas generales y abiertas, y luego limitar las posibles respuestas utilizando preguntas cerradas.

·         Uso de una estructura de diamante

Es la combinación de las dos estructuras anteriores. Esta estructura implica empezar de una manera muy específica, después se examinan los aspectos generales y finalmente se termina con una conclusión muy específica. La estructura de diamante combina las fortalezas de los otros dos métodos, pero tiene la desventaja de tomar mucho más tiempo que cualquiera de las otras estructuras.

RECOPILACIÓN DE INFORMACIÓN: MÉTODOS NO INTRUSIVOS

4.12     RECOPILACIÓN DE INFORMACIÓN: MÉTODOS NO INTRUSIVOS

4.12.1        MUESTREO

Es el proceso consistente en seleccionar sistemáticamente elementos representativos de una población. Cuando dichos elementos se examinan con cuidado, se da por hecho que el análisis revelará información útil de la población en general.

4.12.1.1      LA NECESIDAD DE MUESTREO

Hay muchas razones por las cuales un analista de sistemas tendría que seleccionar una muestra representativa de datos para examinarla o personas representativas para entrevistarlas, aplicarles un cuestionario u observarlas. Entre estas razones se incluyen:

·           Reducir costos.

·           Acelerar la recopilación de datos.

·           Mejorar la efectividad.

·           Reducir la parcialidad.

4.12.1.2      DISEÑO DEL MUESTREO

Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra:

1.    Determinar qué datos van a ser recopilados o descritos.

2.    Determinar de qué población se van a tomar muestras.

3.    Escoger el tipo de muestra.

4.    Decidir el tamaño de la muestra.

4.12.2        ANÁLISIS DE DOCUMENTOS CUANTITATIVOS

En todas las empresas existen muchos documentos cuantitativos disponibles para su interpretación, y entre ellos se incluyen informes usados para la toma de decisiones, informes de desempeño, registros y una variedad de formularios. Todos estos documentos tienen un propósito y un público específicos a los cuales van dirigidos.

Tales informes ayudan al tomador de decisiones a identificar fácilmente las tendencias.

4.12.3        ANÁLISIS DE LOS DOCUMENTOS CUALITATIVOS

Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, carteles en los tableros de anuncios y en las áreas de trabajo, páginas Web, manuales de procedimientos y manuales de políticas. Hay razón para ello. Algunos lineamientos pueden ayudar a los analistas a seguir un enfoque sistemático en esta clase de análisis:

1.    Examine los documentos en busca de metáforas clave u orientadoras.

2.    Busque una mentalidad de internos contra externos o de "nosotros contra ellos".

3.    Liste los términos que caractericen lo bueno o lo malo y que aparezcan repetidamente en los documentos.

4.    Busque mensajes y gráficos significativos colocados en áreas comunes o en páginas Web.

5.    Identifique el sentido del humor, si lo hay.

ELABORACIÓN DE PROTOTIPOS RAD Y PROGRAMACIÓN EXTREMA

4.13 ELABORACIÓN DE PROTOTIPOS RAD Y PROGRAMACIÓN EXTREMA

Cuando el analista de sistemas presenta un prototipo del sistema de información, se interesa en las reacciones de los usuarios y los directivos de la organización hacia el prototipo. Las reacciones se recopilan a través de la observación, las entrevistas y las hojas de retroalimentación diseñados para obtener la opinión de cada persona sobre el prototipo después de que interactúan con él.

4.13.1        CLASES DE PROTOTIPOS

Entre estos tenemos

·         Prototipo corregido

La primera clase de elaboración de prototipos tiene que ver con la construcción de un sistema que funciona pero se corrige simultáneamente.

·         Prototipo no funcional

El segundo tipo de prototipo es un modelo no funcional a escala configurado para probar ciertos aspectos del diseño.

·         Primer prototipo de una serie

Involucra la creación de un primer modelo a escala completa de un sistema, con frecuencia llamado piloto. El prototipo es completamente funcional y es una materialización de lo que el diseñador espera será una serie de aviones con características idénticas. Este tipo de elaboración de prototipos es útil cuando se planean muchas instalaciones del mismo sistema de información.

·         Prototipo de características seleccionadas

Involucra la creación de un modelo funcional que incluya algunas, pero no todas, de las características que tendrá el sistema final.

4.13.2        LINEAMIENTOS PARA DESARROLLAR UN PROTOTIPO

Una vez que se ha tomado la decisión de elaborar un prototipo, se deben observar cuatro lineamientos principales al integrar la elaboración de prototipos con la fase de determinación de requerimientos del SDLC:

1.    Trabajar en módulos manejables

2.    Construir rápidamente el prototipo

3.    Modificar el prototipo en iteraciones sucesivas

4.    Poner énfasis en la interfaz de usuario

4.13.3        DESVENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS

·         Puede ser bastante difícil manejar la elaboración de prototipos como un proyecto en el esfuerzo de sistemas más grandes.

·         Los usuarios y los analistas podrían adoptar un prototipo como si fuera un sistema final cuando de hecho es deficiente y su propósito nunca fue el de servir como sistema terminado.

4.14.4        VENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS

·         Posibilidad de modificar el sistema en las primeras etapas del desarrollo.

·         Oportunidad de suspender el desarrollo de un sistema que no sea funcional y:

·         Posibilidad de desarrollar un sistema que se acerque más a satisfacer las necesidades y expectativas de los usuarios.

La elaboración exitosa de prototipos depende de una retroalimentación del usuario frecuente y oportuna, lo que sirve para modificar el sistema y hacerlo más receptivo a las necesidades reales, ya que; los cambios oportunos son menos costosos que los cambios que se hacen más tarde en el desarrollo del proyecto.

4.13.5        INTERACCIÓN CON EL PROTOTIPO

Hay tres formas principales en las que un usuario puede ayudar en la elaboración de prototipos:

1.    Experimentando con el prototipo.

2.    Dando reacciones sinceras sobre el prototipo.

3.    Sugiriendo adiciones o eliminaciones al prototipo.

4.13.6        DESARROLLO RÁPIDO DE APLICACIONES

El desarrollo rápido de aplicaciones (RAD) es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo así como también herramientas de software. El RAD y la elaboración de prototipos se enfocan en satisfacer más de cerca los requerimientos cambiantes de los negocios, se puede considerar como una implementación específica de la elaboración de prototipos.

4.13.6.1      FASES DEL RAD

Hay tres fases amplias del RAD que vinculan a usuarios y analistas en la evaluación, diseño e implementación.

·         Fase de planeación de requerimientos

En esta fase, usuarios y analistas se reúnen para identificar los objetivos de la aplicación o sistema y para identificar los requerimientos de información que surgen de dichos objetivos.

·         Taller de diseño del RAD

El proceso de diseñar y refinar los prototipos se puede representar mejor como un taller. Cuando imagina un taller, sabe que la participación es intensa, no pasiva, y que generalmente se hace con las manos.

·         Fase de implementación

Tan pronto como sean convenidos estos aspectos y los sistemas sean construidos y se refinen, los nuevos sistemas, o parte de ellos, son probados e introducidos en la organización. Debido a que el RAD se puede usar para crear las nuevas aplicaciones de comercio electrónico para las cuales no hay ningún sistema viejo, por lo general no se necesita ejecutar los sistemas viejos y nuevos en paralelo antes de la implementación.

4.13.7        PROGRAMACIÓN EXTREMA

La programación extrema (XP) es un enfoque de desarrollo de software que adopta lo que generalmente designamos como prácticas de desarrollo de software aceptable y las lleva al extremo. Por ejemplo, la retroalimentación es importante para los programadores, analistas, diseñadores, usuarios y computadoras.

La administración de proyectos es importante, de tal manera que la programación extrema intenta definir rápidamente un plan global del sistema, desarrollar y liberar rápidamente el software y posteriormente revisarlo continuamente para incorporarle características adicionales. Pero la programación extrema no sólo se basa en los resultados. Se basa en los valores, principios y prácticas. Ahora examinaremos cómo los valores y principios de XP dan forma al desarrollo de sistemas extremos.

4.13.7.1      VALORES Y PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA

Para la programación extrema es importante que se declaren los valores y principios que crean el contexto para la colaboración entre programadores y clientes. Para considerarse analista de XP, se debe apegar a los siguientes valores y principios desarrollados por Beck.

Cuatro valores de XP Hay cuatro valores que crean un entorno en el cual se pueden servir adecuadamente diseñadores y negocios.

·         Comunicación,

·         Sencillez,

·         Retroalimentación y;

·         Valentía.

USO DE DIAGRAMAS DE FLUJO

4.14     USO DE DIAGRAMAS DE FLUJO

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica para la maceta del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.

Un diagrama de flujo de datos gráfico lógico del plan de trabajo que se ejecutara para la solución de un determinado problema. A través de él, se planifica la solución del problema independiente del lenguaje de computación a usar. De esta manera se separa las instrucciones de un lenguaje determinado con todas las reglas.

Las capacidades humanas necesarias para elaborar un diagrama de flujo correcto son: Lógico, Prácticas, y Atención. El empleo de la maquina en las funciones del procediendo de datos han hecho necesario un flujo ordenado de la información. La secuencia en que deberán ejecutarse las operaciones tendrá que definirse claramente, y cuando se combine con los datos a los que debe aplicarse, esa secuencia creara el flujo de información.

4.14.1        OBJETIVOS DE UN DIAGRAMA DE FLUJO

·         Estructura la solución del problema independiente del lenguaje a utilizar.

·         Separar la solución lógica de programación de la parte de reglas y sintaxis de codificación con esta división del trabajo se obtiene mayor eficiencia.

·         Dar una visión completa del problema al programador ya que pierde en un programa ya codificado.

·         Permitir una compresión más rápida del programa a otros programadores.

Un diagrama de flujo, puede tener tipos de errores diferentes:

·         De forma

Se genera por no seguir las reglas establecidas, puede hacer el diagrama difícil interpretación, confundir el diagrama y hasta convertirlo en errado en cuanto ser lógica.

·         De lógica

Son errores de estructura del diagrama en cuanto al orden puede ser de distinta gravedad, desde dejar de mostrar el resultado. O falta un cálculo hasta un error que determine que un programa nunca llegue a su fin.

·         De objetivo

Es cuando un diagrama de flujo esta correcto en cuanto a su estructura y forma pero no soluciona el problema propuesto sino otro.

4.14.2        REGLAS PARA LA CREACIÓN DE DIAGRAMAS

1.    Los diagramas de flujo deben escribirse de arriba hacia abajo y/o de Izquierda a derecha.

2.    Los símbolos se unen con líneas, las cuales tienen en la punta una flecha que indica su dirección que fluye la información procesos, se deben utilizar solamente líneas de flujo horizontal o vertical.

3.    Se debe evitar el cruce de líneas, para lo cual se quisiera separar el flujo del diagrama a un sitio distinto, se pudiera realizar utilizando los conectores.

4.    No deben quedar líneas de flujo sin conectar.

5.    Todo texto escrito dentro de un símbolo debe ser legible, preciso, evitando el uso de muchas palabras.

6.    Todos los símbolos pueden tener más de una línea de entrada, a excepto del símbolo final.

7.    Solo los símbolos de decisión pueden y deben tener más de una línea de flujo de salida.

4.14.3        CARACTERÍSTICAS DE LOS DIAGRAMAS DE FLUJO DE DATOS

·         Muestran que debe hacer el sistema sin referencias.

·         Son diagramas explícitos y comprensibles.

·         Dan la posibilidad de representan el sistema a diferentes niveles de complejidad, desde lo más global a lo más detallado solo requieren de 4 símbolos.

·         Son fáciles de mantenimiento, pues los cambios afectan solo algunos de sus elementos y no al todo.

4.14.4        VENTAJAS DE LOS DIAGRAMAS DE FLUJO DE DATOS

·         Fácil lectura, con esto se constituye en un instrumento de mucha versatilidad.

Facilitan la interacción Usuario-Analista

ANALISIS DE SISTEMAS MEDIANTE DICCIONARIO DE DATOS

4.15     ANALISIS DE SISTEMAS MEDIANTE DICCIONARIO DE DATOS

El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados como referencia en la vida cotidiana. El diccionario de datos es una obra de consulta con información acerca de los datos (es decir, metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y coordina términos de datos específicos y confirma lo que cada término significa para las diferentes personas en la organización.

4.15.1        NECESIDAD DE ENTENDER EL DICCIONARIO DE DATOS

Muchos sistemas de administración de base de datos están equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser complejos o sencillos. Algunos diccionarios de datos computarizados catalogan automáticamente los elementos de datos cuando se hace la programación; otros simplemente proporcionan una plantilla para motivar a la persona que llene el diccionario a que lo haga de una manera uniforme para cada entrada.

4.15.2        ESTRUCTURAS DE DATOS LÓGICAS Y FÍSICAS

Cuando las estructuras de datos se definen primero, sólo se incluyen los elementos de datos que el usuario vería, tal como un nombre, dirección y saldo a pagar. Esta fase es el diseño lógico, el cual muestra qué datos necesita el negocio para sus operaciones diarias.

4.15.3        ALMACENES DE DATOS

Todos los elementos base se deben almacenar en el sistema. También los elementos derivados se podrían almacenar en el sistema, tal como, para un empleado, el sueldo bruto acumulado a la fecha. Los almacenes de datos se crean para cada entidad de datos diferente que se almacenará. Es decir, cuando los elementos base de un flujo de datos se agrupan para formar un registro estructural, se crea un almacén de datos para cada registro estructural único.

4.15.4        CREACIÓN DEL DICCIONARIO DE DATOS

Las entradas del diccionario de datos se podrían crear después de completar el diagrama de flujo de datos, o se podrían construir conforme se desarrolle el diagrama de flujo de datos.

El uso de notación algebraica y registros estructurales permite al analista desarrollar el diccionario de datos y los diagramas de flujo de datos mediante un enfoque jerárquico de arriba hacia abajo.

Por ejemplo, el analista podría crear un flujo de datos de un Diagrama 0 después de las primeras entrevistas y, al mismo tiempo, hacer las entradas preliminares del diccionario de datos. Típicamente, estas entradas consisten en los nombres de los flujos de datos encontrados en el diagrama de flujo de datos y sus estructuras de datos correspondientes

DESCRIPCIÓN DE LAS ESPECIFICACIONES DE PROCESOS Y DESICIONES ESTRUCTURADAS

4.16     DESCRIPCIÓN DE LAS ESPECIFICACIONES DE PROCESOS Y DESICIONES ESTRUCTURADAS

El analista de sistemas que aborda las especificaciones de procesos y las decisiones y tiene muchas opciones para documentarlas y analizarlas.

4.16.1        FORMATO DE LA ESPECIFICACIÓN DE PROCESOS

Las especificaciones de procesos vinculan el proceso al diagrama de flujo de datos y, por consiguiente, al diccionario de datos.

4.16.1.1      TABLA DE DECISIONES

Las tablas de decisión proporcionan otra forma de examinar, describir y documentar decisiones. Cuatro cuadrantes se usan para:

1.    Describir las condiciones

2.    Identificar las posibles alternativas de decisión

3.    Indicar qué acciones se deben realizar, y;

4.    Describir las acciones.

4.16.2        PANORAMA GENERAL DE LAS ESPECIFICACIONES DE PROCESOS

Para determinar los requerimientos de información de una estrategia de análisis de decisión, el analista de sistemas debe determinar primero los objetivos organizacionales mediante un enfoque de jerarquización de arriba hacia abajo. El analista de sistemas debe entender los principios organizacionales y debe contar con experiencia en las técnicas de recopilación de datos.

4.16.3        METAS PARA PRODUCIR ESPECIFICACIONES DE PROCESOS

1.    Reducir la ambigüedad del proceso. Obliga al analista a aprender los detalles acerca del funcionamiento de un proceso. Es necesario detectar, anotar e integrar las áreas indefinidas de todas las especificaciones de procesos. Estas observaciones constituyen una base y proporcionan las preguntas para las entrevistas de seguimiento con la comunidad de usuarios.

2.    Obtener una descripción precisa de lo que se está realizando, lo cual normalmente se incluye en un paquete de especificaciones para el programador.

3.    Validar el diseño del sistema. Esta meta incluye garantizar que un proceso tenga todo el flujo de datos de entrada necesario para producir la salida. Además, todas las entradas y salidas deben representarse en el diagrama de flujo de datos.

PREPARACIÓN DE LA PROPUESTA DEL SISTEMA

4.17     PREPARACIÓN DE LA PROPUESTA DEL SISTEMA

Este tema hace referencia a cómo elaborar la preparación de la propuesta de sistemas. Debemos saber valorar e inventar el hardware y software actuales y propuestos del sistema, también evaluar el software tomando en cuenta los pros y contras entre crear un software personalizado y entre un software comercial; pronosticar los costos tangibles e intangibles y realizar un análisis de costos y beneficios utilizando diferentes métodos.

En si la propuesta de sistemas es todo lo que el analista ha aprendido acerca de una empresa o una organización y lo que necesita para mejorar su desempeño y satisfacer adecuadamente a todos los requerimientos de información que proporciona. El analista debe de usar diferentes métodos el cual le ayude a preparar el sistema.

El analista debe tomar muy en cuenta que hardware y software va a utilizar para implementar el sistema ya que son los usuarios que van a tener acceso al sistema, por eso el analista debe trabajar con los usuarios para así saber que hardware y software utilizarían.

Pero para eso deben de crear un pronóstico de todos los análisis de costos y beneficios que tendría el software y hardware.

El software y hardware es muy importante ya que es lo principal para crear el sistema ya sin esas cosas pues obviamente no hay sistema por eso hay que evaluar muy bien que todo el software y hardware de computo trabajen perfectamente, los principales responsables de revisar o realizar la evaluación son los analistas ya que son ellos que se preocupan por las mejoras del negocio.

Como conclusión del tema podríamos decir que para la preparación de la propuesta del sistema se deben tomar en cuenta 3 aspectos:

Ø  Viabilidad: El presupuesto para el sistema

Ø  Fiabilidad: Los recursos disponibles y por haber para el sistema

Ø  Probabilidad: El tiempo pronosticado para la elaboración e implantación total del sistema.