MAPA MENTAL UNIDAD IV

MAPA DE LA UNIDAD III

El siguiente es la descripción de un problema encontrado en un proceso en su estado actual y de su propuesta de cambio y solución.

EJEMPLO:          

DESCRIPCIÓN	SISTEMA EXISTENTE	SISTEMA PROPUESTO
TAREA	Cada bimestre se entrega por correo al director de la sección un reporte de entrevistas, por cada uno de los profesores que entrevistan a alumnos.	Hoja de Excel en línea.  Google docs.
MÉTODO	El profesor hace un reporte no unificado que puede estar en Excel, Word o programa de preferencia, el cuál entrega impreso o por correo al director, quien tiene que volver a capturar en su formato.	Llenar un archivo en Excel en línea donde cada profesor reporte al director de la sección sus entrevistas.  El cuál se actualizará automáticamente y tanto el director como el profesor podrán consultarlo y modificarlo cuantas veces sea necesario.
PERSONAL	Profesor entrevistador y Director de Sección	Profesor entrevistador y Director de Sección
CUÁNDO Y CÓMO	Bimestralmente	Bimestralmente
REQUERIMIENTOS DE TIEMPO HUMANO	Promedio  2 horas	Promedio ½ hora
REQUERIMIENTOS DE TIEMPO COMPUTADORA	Promedio  2 horas	Promedio ½ hora

Mapa de la Unidad II

PRINCIPALES TÉCNICAS DE RECOGIDA DE INFORMACIÓN

La investigación de mercados se ha basado tradicionalmente en soportes cuantitativos independientemente del medio utilizado (personal, telefónico, postal, panel, Internet, etc.). La encuesta estadística estructurada es su máximo exponente y su objetivo es reflejar a través de una muestra estadísticamente representativa la realidad social o económica que sustenta a un mercado concreto.

A efectos metodológicos, las técnicas cuantitativas se basan en agrupar y medir a los individuos muestrales en categorías, en función de variables preestablecidas, tales como pautas de consumo, rasgos sociodemográficos, ejes lógicos de segmentación, etc.

Por tanto, los resultados obtenidos a partir de técnicas cuantitativas se validan exclusivamente con criterios estadísticos, por lo que no son adecuadas para reconstruir las relaciones sociales que subyacen a la medición concreta. En el mejor de los casos, se limitan a describirla. Es decir, no descubren procesos, simplemente los cuantifican.

Ya en los años 70, pero sobre todo en la década de los 80, se empezaron a desarrollar en la investigación social, y específicamente en la de mercados, otro tipo de técnicas complementarias que en ningún caso compiten, o así debería ser, con las cuantitativas, puesto que implican perspectivas diferentes. Se trataría de diversas maneras de observar la misma realidad. La investigación cualitativa extrae las variables motivacionales que configuran los ejes valorativos y de actuación. Por su parte, el análisis cuantitativo mide tales ejes, así como las categorías surgidas y las relaciones entre ellas. En sentido figurado, la investigación cuantitativa mide la parte visible de la luna y la cualitativa explica por qué una parte es visible y la otra no. Explicación y descripción son dos caras del mismo fenómeno. La visibilidad de la luna no implica necesariamente la imposibilidad del estudio de su cara oculta.

GRÁFICO 2. PRINCIPALES TÉCNICAS DE RECOGIDA DE INFORMACIÓN

http://www.marketing-xxi.com/principales-tecnicas-de-recogida-de-informacion-27.htm

CLASIFICACIÓN    SEGÚN LA ESTRUCTURACIÓN

·         Entrevista estructurada

·         Técnica Delphi

·         Grupo nominal

·         Estudio de caso

·         Entrevista semiestructurada

·         Grupo focal

·         Lluvia de ideas (“Brainstorming”)

·         Grupo de discusión

·         Entrevista de profundidad

o   Historia de vida

·         Información

FORMAS DE RECOGER INFORMACIÓN

Análisis de documentos

                Tipos de documentos

·         Actas, circulares

·         Informes, programas

·         Políticas, leyes

·         Cartas, diarios, discursos

·         Periódicos, revistas

·         Películas, fotografías

Análisis de contenido

·         Cualitativo

·         Cuantitativo

Ventajas

·         Técnica no intrusiva

·         Los datos tienen forma permanente

·         Información longitudinal de bajo costo

Desventajas

·         Disposición de documentos limitada

·         Escritos con otro propósito

Observación

1.       Según el papel del investigador / a

a.       No participante

b.      Participante

2.       Según el instrumento

a.       No estructurado

b.      Semi-estructurado

3.       Según la transparencia

a.       Abierta

b.      Oculta

Entrevistas

·         Individuales

o   Sin estructurar

o   Semi-estructuradas

·         Grupo

o   Sin estructurar: grupo de discusión

o   Semi-estructuradas:

§  Grupo focal

§  Entrevistas en grupo

o   Entrevistas especiales

§  Historias de vida

Entrevistas cualitativas:  recogen información sobre

·         Actitudes, valores, opiniones (funcionamiento del sistema)

·         Temas delicados (relaciones de poder)

·         Datos históricos (adultos mayores)

·         Estilos de vida (en jóvenes)

·          

Técnicas participativas / interactivas

·         Lluvia de ideas (brainstorming)

·         Interpretación de imágenes

·         Elaboración de carteles o mapas

·         Técnicas de priorización o de consenso

o   Diagramas

o   Grupo Nominal

Las técnicas participativas sirven para:

·         Generar ideas

·         Facilitar la expresión de sentimientos

·         Estimular una discusión

·         Ayudar a expresar opiniones sobre otras personas

·         Valorar y priorizar problemas y opiniones

·         Generar el interés por un problema o un programa

http://www.slideshare.net/rcofinof/4-tecnicas-de-recogida-de-informacion-en-investigacion-cualitativa

TIPOS DE MANUALES

MANUAL TÉCNICO

Un Manual técnico es un documento que se hace con la finalidad de dejar documentado, es decir, explicado todo el trabajo que se ha realizado al desarrollar un sistema o proyecto, como la estructura de datos que se utilizó, cada función o procedimiento, cada variable, metodologías, etc. y puede ser un documento impreso o digital.

Ejemplo de un Manual Técnico:

http://dda.mty.itesm.mx/dcde/khub/Guia_del_Colaborador.pdf

MANUAL ADMINISTRATIVO

Son documentos que sirven como medios de comunicación y coordinación que permiten registrar y transmitir en forma ordenada y sistemática, información de una organización (antecedentes, legislación, estructura, objetivos, políticas, sistemas, procedimientos, etc.). Así como las instrucciones y lineamientos que se consideren necesarios para el mejor desempeño de sus tareas.

Ejemplo de un Manual Administrativo:

http://www.ccee.edu.uy/ensenian/catoym/material/2009-05-Los%20Manuales%20Administrativos%20Hoy.pdf

MANUAL DE USUARIO

El manual de usuario es un documento técnico de un determinado sistema que intenta dar asistencia a los usuarios. Generalmente son de dispositivos electrónicos, hardware de computadora y aplicaciones. El manual de usuario puede venir tanto en forma de libro como en forma de documento digital, e incluso poder ser consultado por internet.

En general, un manual de usuario debería poder ser entendido por cualquier usuario principiante, como así también serle útil a usuarios avanzados.

Ejemplos de Manual de Usuario

http://sabus.usal.es/pdf/manual_ref.pdf
http://ec.europa.eu/internal_market/imi-net/docs/user_handbook_es.pdf

CICLO DE VIDA DEL DESARROLLO DE SISTEMAS

Es un proceso que se lleva a cabo en 7 fases, las cuales permiten el perfecto desarrollo y larga vida de un proyecto, en el cuál se toman en cuenta los diversos problemas que se van presentando en cada etapa y la mejor forma de llevar a término un proyecto.

El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario.

Aquí hemos dividido el ciclo en siete fases. A pesar de que cada fase se explica por separado, nunca se realiza como un paso aislado. Más bien, es posible que varias actividades ocurran de manera simultánea, y algunas de ellas podrían repetirse. Es más práctico considerar que el SDLC se realiza por fases (con actividades en pleno apogeo que se traslapan con otras hasta terminarse por completo) y no en pasos aislados.

IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era el que se debía resolver. Se requiere que el analista observe objetivamente lo que sucede en un negocio. A continuación, en conjunto con otros miembros de la organización, el analista determina con precisión cuáles son los problemas. Con frecuencia los problemas son detectados por alguien más, y ésta es la razón de la llamada inicial al analista. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados. El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja competitiva o establecer un estándar para la industria.

En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continuación, podrá determinar si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos.

Las actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A continuación, la administración debe decidir si se sigue adelante con el proyecto propuesto.

 DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN

Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de amplio alcance como la elaboración de prototipos.

Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos. En ocasiones sólo realizan las dos primeras fases del ciclo de vida del desarrollo de sistemas. El analista de sistemas necesita conocer los detalles de las funciones del sistema actual: el quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. A continuación el analista debe preguntar la razón por la cual se utiliza el sistema actual. Podría haber buenas razones para realizar los negocios con los métodos actuales, y es importante tomarlas en cuenta al diseñar un nuevo sistema. La reingeniería de procesos de negocios podría ser útil para conceptualizar el negocio de una manera creativa. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

 ANÁLISIS DE LAS NECESIDADES DEL SISTEMA

De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas especificaciones.

 Durante esta fase el analista de sistemas analiza también las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condición, las acciones y las reglas de acción.

Existen tres métodos principales para el análisis de decisiones estructuradas: español estructurado, tablas y árboles de decisión.

En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la administración de la empresa considera factible alguna de las recomendaciones, el analista sigue adelante. Cada problema de sistemas es único, y nunca existe sólo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista.

DISEÑO DEL SISTEMA RECOMENDADO

En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información.

El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos. Además, el analista facilita la entrada eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante.

La fase de diseño también incluye el diseño de archivos o bases de datos que almacenarán gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización. Una base de datos bien organizada es el cimiento de cualquier sistema de información.

En esta fase el analista también interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos.

Finalmente, el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento; también podría incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo de sistema, y los nombres y funciones de cualquier rutina de código previamente escrita.

 DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE

En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructura, los diagramas de Nassi-Shneiderman y el pseudocódigo. El analista se vale de una o más de estas herramientas para comunicar al programador lo que se requiere programar.

Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios Web que incluyan respuestas a preguntas frecuentes (FAQ, Frequently Asked Questions) en archivos "Léame" que se integrarán en el nuevo software.

PRUEBA Y MANTENIMIENTO DEL SISTEMA

Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realiza una serie de pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan a cabo de manera rutinaria durante toda su vida útil. Gran parte del trabajo habitual del programador consiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en esta actividad.

EMPLEMENTACEÓN Y EVALUACIÓN DEL SISTEMA

Ésta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. Además, el analista tiene que planear una conversión gradual del sistema anterior al actual. Este proceso incluye la conversión de archivos de formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipo y la puesta en producción del nuevo sistema.

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el sistema lo están utilizando realmente.

Debe hacerse hincapié en que, con frecuencia, el trabajo de sistemas es cíclico. Cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar al analista a regresar a la fase previa y modificar el trabajo realizado.

Este ciclo de vida lleva de la mano al analista desde la identificación de problemas, oportunidades y objetivos hasta la implementación de un nuevo sistema con un mantenimiento que se llevará de por vida, además de las actualización que requiera con el avance de la empresa y sus necesidades. Es un programa excelentemente estructurado en fases para su creación.

BIBLIOGRAFÍA

Kendall & Kendall. Ed. P.H. AYDS. Ciclo de Vida del desarrollo de un sistema P. 10