SELECCIÓN DEL AMBIENTE OPERATIVO Y LENGUAJE DE DESARROLLO

El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que puedan llevar a cabo la construcción del sistema de información. Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, base de datos o ficheros de prueba, entre otros.

Las características del entorno de construcción y sus requisitos de operación y seguridad, a si como las especificaciones de construcción de la estructura física de datos, se establece en la actividad generación de especificaciones de construcción y constituyendo el punto de partida para la relación de esta actividad.

ELABORACIÓN DE PROGRAMAS

1. Especificación del programa 2. Diseño del programa 3. Codificación del programa 4. Prueba 5. Documentación 6. Mantenimiento

1. Especificación del programa: Se conoce también como definición del problema o análisis del programa. En este paso se determinan la información inicial para la elaboración del programa. Es donde se determina qué es lo que debe resolverse con el computador, de qué presupuestos se debe partir… en definitiva, el planteamiento del problema.

Se requieren cinco tareas:

a. Determinación de objetivos del programa. Debe definirse claramente los problemas particulares que deberán ser resueltos o las tareas que hay que realizar, esto nos permitirá saber qué es lo que se pretende solucionar y nos proporcionará información útil para el planeamiento de la solución.

b. Determinación de la salida deseada. Los datos seleccionados deben ser arreglados en una forma ordenada para producir información. Esta salida podría ser una salida de impresión o de presentación en el monitor.

c. Determinación de los datos de entrada. Una vez identificada la salida que se desea, se pueden determinar los datos de entrada y la fuente de estos datos. Los datos deben ser recolectados y analizados.

d. Determinación de los requerimientos de procesamiento. Aquí se definen las tareas de procesamiento que deben desempeñarse para que los datos de entrada se conviertan en una salida.

e. Documentación de las especificaciones del programa. Es importante disponer de documentación permanente. Deben registrarse todos los datos necesarios para el procesamiento requerido. Esto conduce al siguiente paso del diseño del programa.

2. Diseño del programa: Es diseñar cualquier sistema nuevo o las aplicaciones que se requieren para satisfacer las necesidades. Esta actividad se debe dividir en: Operaciones de entrada/salida, Cálculos - Lógica/ comparación, Almacenamiento/ consulta En este paso se genera una solución con técnicas de programación como diseño descendente de programas, pseudocódigos, flujo gramas y estructuras lógicas.

En este paso se genera una solución con técnicas de programación como diseño descendente de programas, pseudocódigos, flujo gramas y estructuras lógicas.

3. Codificación del programa: Es la generación real del programa con un lenguaje de programación. En esta etapa se hace uso de la lógica que desarrolló en el paso del diseño del programa para efectivamente generar un programa. Se debe seleccionar el lenguaje apropiado para resolver el problema.

4. Prueba y depuración del programa: Depurar es correr el programa en una computadora y corregir las partes que no funcionan. En esta fase se comprueba el funcionamiento de cada programa y esto se hace con datos reales o ficticios. Cuando los programas están depurados, se prueban. Cuando los programas se depuran, se pueden encontrar los siguientes errores:

a) Errores de sintaxis o de compilación b) Errores de ejecución c) Errores de lógica d) Errores de especificación.

a) Errores de sintaxis o de compilación. Es una violación de las reglas del lenguaje de programación. Son más fáciles de corregir, ya que son detectados por el compilador (posible error de escritura), el cual dará información sobre el lugar donde está y la naturaleza de cada uno de ellos mediante un mensaje de error.

b) Errores de Ejecución. Se deben generalmente a operaciones no permitidas como dividir por cero, leer un dato no numérico en una variable numérica, exceder un rango de valores permitidos, etc. Se detectan porque se produce una parada anormal del programa durante su ejecución.

c) Errores de Lógica. Corresponden a la obtención de resultados que no son correctos y la única manera de detectarlos es realizando suficientes pruebas del programa. Son los más difíciles de corregir, no sólo por la dificultad de detectarlos, sino porque se deben a la propia concepción y diseño del programa.

d) Errores de Especificación. Es el peor tipo de error y el más difícil de corregir. Se deben a mal diseño del programa posiblemente por mala comunicación usuario programador y se detectan cuando ya se ha concluido el diseño e instalación del programa, lo cual puede implicar repetir gran parte del trabajo realizado.

5. Documentación del programa: Consiste en describir por escrito a nivel técnico los procedimientos relacionados con el programa y su modo de uso. También se debe documentar el programa para que sea más entendible. ¿Para quiénes son la documentación? Usuarios (Digitadores), Operadores, Programadores, Analistas de sistemas Documentos que se elaboran: Manual de Usuario y Manual del Analista. A los usuarios se les elabora un manual de referencia para que aprendan a utilizar el programa.

Esto se hace a través de capacitaciones y revisión de la documentación del manual de usuario. El manual del usuario no está escrito a nivel técnico sino al de los distintos usuarios previstos y explica en detalle cómo usar el programa: descripción de las tareas que realiza el programa, instrucciones necesarias para su instalación puesta en marcha y funcionamiento, recomendaciones de uso, menús de opciones, método de entrada y salida de datos, mensajes de error, recuperación de errores, etc. A los operadores por si se presentan mensajes de error, sepan cómo responder a ellos. Además que se encargan de darle soporte técnico al programa.

A los programadores a través del manual del analista para que recuerden aspectos de la elaboración del programa o en caso que otras personas puedan actualizarlo o modificarlo (darle mantenimiento) y no son necesariamente las personas que lo diseñaron. Es por ello, que la documentación debe contener algoritmos y flujo gramas de los diferentes módulos que lo constituyen y las relaciones que se establecen entre ellos; listados del programa, corridas, descripción de variables que se emplean en cada módulo, cuáles son comunes a diferentes módulos y cuáles locales; descripción de los ficheros de cada módulo y todo lo que sea de importancia para un programador. A los analistas de sistemas que son las personas que deberán proporcionar toda la información al programador. Estos se encargan de hacer una investigación previa de cómo realizar el programa y documentar con las herramientas necesarias para que el programador pueda desarrollar el sistema en algún lenguaje de programación adecuado.

6. Mantenimiento del programa: Es el paso final del desarrollo del software. Alrededor del 75% del costo total del ciclo de vida de un programa se destina al mantenimiento. El propósito del mantenimiento es garantizar que los programas en uso estén libres de errores de operación y sean eficientes y efectivos.

IMPLEMENTACIÓN

Un equipo de cuentas experimentado será responsable de la implementación de programas, el servicio diario, la estrategia clínica, la estrategia comercial y la satisfacción general. Personas pertenecientes a otras áreas funcionales, como el área de admisiones y de servicio al cliente, también formarán parte de su equipo de apoyo del programa. Estas personas trabajarán juntas para administrar su programa en forma efectiva.

MÉTRICAS PARA EVALUAR EL SOFTWARE

La medición permite que gestores y desarrolladores mejoren el proceso de software, ayuden en la planificación, seguimiento y control de un proyecto de software, y evalúen la calidad del producto que se produce. Las medidas de los atributos específicos del proceso, del proyecto mayor profundidad de la efectividad de un proceso de software. Las métricas del proyecto son tácticas. Estas permiten que un gestor de proyectos adapte el enfoque a flujos de trabajos del proyecto y a proyectos técnicos en tiempo real.

Las métricas orientadas tanto al tamaño como a la función se utilizan en toda la industria. Las métricas orientadas al tamaño hacen usos a la línea de código como factor de normalización para otras medidas como persona-mes o defectos. El punto de función viene de proviene de las medidas del dominio de información y de una evaluación subjetivo de la complejidad del problema.

Las métricas de la calidad del software, como métricas de productividad, se centra en el proceso, en el proyecto, en el producto. Desarrollando y analizando una línea a base de métricas para la calidad, una organización puede actuar con objeto de corregir esas. Se utilizan para calcular las métricas de software.

Estas métricas se pueden analizar para proporcionar indicadores que guían acciones de acción y técnicas.

Las métricas de proceso permiten que una organización tome una visión estratégica proporcionando áreas de proceso de software que son las causas de los defectos del software.

Las métricas tiene significado solo si han sido examinadas para una valides estadística el grafico de control es un método sencillo para realizar esto y al mismo tiempo examinar la variación y la localización de los resultados de las métricas.

Para aplicar el sistema de calidad al ciclo de vida es necesario la utilización de métricas adecuadas que permitan medir la calidad del proyecto (en realidad, comparamos los parámetros de calidad de éste con estimaciones realizadas mediante el uso de estándares o datos que aporta la experiencia en otros proyectos). En el contexto en que no encontramos, atenderemos principalmente a las métricas de productividad y de calidad.

Las métricas se utilizan para evaluar y controlar el proceso de desarrollo del software, de forma que permitan:

Indicar la calidad del producto. Evaluar la productividad de los desarrolladores.

Evaluar los beneficios (en cuanto a calidad y productividad)

derivados del uso de nuevos métodos y herramientas de ingeniería del software.

Establecer una línea base para la estimación.

Justificar el uso de nuevas herramientas o de formación adicional.

Pero es necesario utilizar las métricas más adecuadas para conseguir el control, seguimiento y mejora de la calidad, y para ello es necesario determinar los factores de calidad más importantes dentro del proyecto.

PRUEBA DE PROGRAMAS Y DEL SISTEMA

Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final. Esto significa sacar a la luz problemas no conocidos y no demostrar la perfección de programas manuales o equipo.

Aunque el probar es aburrido, es una serie esencial de pasos que ayuda a asegurar la calidad del sistema eventual. La prueba se realiza en subsistemas o módulos de programa conforme el trabajo avanza. La prueba se hace en muchos niveles diferentes y a diversos intervalos. Antes de que el sistema sea puesto en

producción, todos los programas deben ser probados en el escritorio, revisados con datos de prueba y revisados para ver si los módulos los trabajan juntos entre ellos, tal como se planeo.

También debe ser probado el sistema trabajando con un todo. Esto incluye probar las interfaces entre subsistemas, la corrección de la salida y la utilidad y comprensibilidad de la documentación de la salida del sistema. Los programadores, analistas, operadores y usuarios juegan papeles diferentes en los diversos aspectos de la prueba.

Prueba de Programas con Datos de Prueba.

En esta etapa, los programadores primero probaran sus programas en escritorio para verificar la forma en que el sistema trabajará. En la prueba de escritorio el programador sigue cada paso del programa en papel para revisar si la rutina trabaja como fue escrita.

Luego los programadores deben crear datos de prueba válidos e inválidos. Luego, estos datos son ejecutados para ver si trabajan las rutinas básicas y también para atrapar errores. Si la salida de los módulos principales es satisfactoria, se pueden añadir más datos de prueba para revisar otros módulos. Los datos de prueba creados deben probar los valores mínimo y máximo posibles, así como también todas las variaciones posibles de formatos y códigos. Se debe revisar cuidadosamente se debe revisar cuidadosamente los archivos de salida de los datos de prueba. Nunca se debe suponer que los datos contenidos en un archivo son correctos simplemente debido a que el archivo fue creado y accesado.

A lo largo de este proceso el analista de sistemas revisa la salida buscando errores, dando consejos al programador sobre cualquier corrección necesaria. Por lo general, el analista recomendara o creará datos de prueba para la prueba de programas, pero puede resaltar al programador omisiones de tipos de datos que deban ser añadidos en pruebas posteriores.

Prueba de Enlace con Datos de Prueba.

También se le conoce como prueba en cadena. La prueba de enlace revisa para ver si los programas que son interdependientes trabajan, de hecho, como se planeo.

Una pequeña cantidad de datos de prueba, para probar las especificaciones del sistema, así como los programas, se usan para la prueba de enlace. La prueba de todas las combinaciones puede llevarse varios pasos a través del sistema, debido a que es mucho muy difícil describir los problemas si se trata de probar todo en una sola vez.

El analista crea datos de prueba especiales que cubren una diversidad de situaciones de procesamiento para la prueba de enlace. Primero, se procesan datos de prueba típicos para ver si el sistema puede trabajar las transacciones normales, aquellas que conformarán la mayor parte de su carga.

Si el sistema trabaja con las transacciones normales, luego se añaden variaciones, incluyendo los datos inválidos usados para asegurarse de que el sistema pueda detectar errores adecuadamente.

Prueba Completa del Sistema con Datos de Prueba.

En esta etapa, los operadores y usuarios finales llegan a estar activamente involucrados en la prueba. Se usan datos de prueba creado por el equipo de análisis de sistemas para el propósito específico de probar los objetivos del sistema.

Factores a considerar cuando se prueba el sistema con datos de prueba:

1. Examinar si los operadores tienen documentación adecuada en los manuales de procedimientos para lograr la operación correcta y eficiente.

2. Revisar si los manuales de procedimientos son lo suficientemente claros para comunicar como deben ser preparados los datos para su entrada.

3. Asegurarse si el flujo de trabajo que necesita el sistema nuevo o modificado de hecho fluye.

4. Determinar si la salida es correcta y si los usuarios comprenden que esta es, en todos los sentidos, la forma en que la salida se verá en su forma final.

Esta prueba incluye la reafirmación de los estándares de calidad para el desempeño del sistema, que fueron puestos cuando se establecieron las especificaciones iníciales del sistema. Todos los involucrados deben nuevamente estar de acuerdo con la manera de determinar si el sistema está haciendo lo que se supone que debe hacer. Esto incluirá mediciones de error, oportunidad, facilidad de uso, ordenamiento adecuado de transacciones, aceptable tiempo caído, manuales de procedimientos comprensibles, etc.

Prueba Completa del Sistema con Datos Reales.

Este paso permite una comparación precisa de la salida del nuevo sistema con a que s sabe que es salida correctamente procesada, así como una buena sensación de cómo serán manejados los datos reales.

El de prueba es un periodo importante para valorar cómo interactúan, de hecho, los usuarios finales y operadores del sistema. No es suficiente entrevistar a los usuarios acerca de cómo están interactuando con el sistema, sino que se les debe observar de primera mano.

Los conceptos de observar son la facilidad de aprendizaje del sistema, el ajuste a factores ergonómicos y la reacción del usuario a la retroalimentación del sistema, incluyendo lo que sucede cuando se recibe un mensaje de error y lo que sucede cuando al usuario se le informa que el sistema está ejecutando sus comandos. Escuche lo que los usuarios dicen acerca del sistema con relación a cómo lo encuentran. Cualquier problema real debe ser resuelto antes de que el sistema sea puesto en producción, y no sólo superficialmente como ajustes al sistema que los usuarios y operadores "debieran" hacer por sí mismos.

También se necesitan ser probados los manuales de procedimientos. La única forma real de probarlos es hacer que lo usuarios y operadores los usen, de ser preferible durante la prueba completa del sistema con datos reales.

Es difícil comunicar los procedimientos con precisión. Los manuales necesitan estar organizados en formas diferentes para los usuarios que interactuarán con el sistema en innumerable maneras.

Demasiada información, o muy poca, será obstáculo para el uso del sistema. El uso de hipertexto para manuales en línea puede ayudar en este aspecto. Considere e incorpore las sugerencias de usuarios y operadores en la versión final de los manuales y en otras formas de documentación.

IMPLEMENTACIÓN

El objetivo de las pruebas de integración es verificar si los componentes o subsistemas interactúan correctamente a través de su interfaces, tanto internas, como externas, cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las verificaciones correspondientes.

La estrategia a seguir en las pruebas de integración se establecen en el plan de pruebas, donde se abra tenido en cuenta el plan de integración del sistema de información, siempre y cuando se haya especificado en la tarea definición de componentes y subsistemas de construcción.

Esta actividad se realiza en el paralelo a las actividades generación del código de los componentes y procedimientos y ejecución de pruebas unitarias. Sin embargo, es necesario que los componentes objetos de las pruebas de integración se hayan verificado de manera unitaria.Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlo.

Existen varios enfoques de Implementación:

1. Es darle responsabilidad a los grupos. 2. Uso de diferentes estrategias para el entrenamiento de los usuarios. 3. El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea

adecuado para la organización. 4. El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios. 5. Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado.

En la preparación de la Implantación, aunque el Sistema este bien diseñado y desarrollado correctamente su éxito dependerá de su implantación y ejecución por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento

DOCUMENTACIÓN

La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen.

La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar

para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operados como hacerlo funcionar.

Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la de usuarios en forma general la naturaleza y capacidades del sistema y cómo usarlo.

Muchas organizaciones tienen lo que se conoce como un “programa de documentación”, el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas. Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes elementos:

Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento.

1. El diseño del sistema de información administrativo. 2. Procedimientos para instalar el sistema de información administrativo.

3. Procedimientos para operar el sistema de información administrativo.

4. Procedimientos para mantener el sistema de información administrativo.

Importancia de la Documentación de Sistemas

La importancia de la documentación bien podría ser comparada con la importancia de la existencia de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza de Seguros está o no vigente.

La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.

Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará involucrado y no podrá moverse a otra asignación.

ELABORACIÓN DEL MANUAL DE USUARIO

El objetivo de esta tarea la documentación del usuario, tanto de usuario final como de explotación, de acuerdo a los requisitos (documentación) establecidos en la tarea de especificación de requisitos de documentación de usuario y requisitos en el catalogo de requisitos.

Esta parte se divide en dos manuales distintos, uno por cada aplicación cliente. Se explicará todas las posibles opciones que puede realizar el usuario con estas aplicaciones de manera detallada, y mediante el uso de capturas de pantalla.

Este documento está dirigido al usuario final.

Pasos del manual del usuario:

1. Portada: De que se trata el documento y quien lo elaboro? 2. Introducción: Describe el uso del documento (para qué sirve?) y de que habla?, Análisis y requerimientos del sistema (¿que se ocupa para poder instalarlo y usarlo?) 3. Explicación del funcionamiento: Debes de poner paso a paso y con pantallas bien explicadas cómo funciona el programa.4. Glosario

1. Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor dificultad posible.

2. Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el programa.

3. Especificar los alcances y las limitaciones que tiene el programa.

Un buen punto de partida para un manual de usuario, es hacer de cuenta que las personas que lo van a leer no tienen el más mínimo conocimiento sobre computadores.

ELABORACIÓN DEL MANUAL DE ADMINISTRACIÓN

Recabados los elementos preliminares para llevar a cabo el manual, se debe preparar el documento de partida para concretarlo, el cual debe quedar integrado por:

Propuesta técnica, (que debe de incluir):

Antecedentes: recuento de todos los manuales o esfuerzos análogos preparados con anterioridad.

Naturaleza: tipo de manual que se pretende realizar.

Justificación: demostración de la necesidad de efectuarlo en función de las ventajas que ello reportará a la organización.

Objetivos: logros que se pretenden alcanzar.

Acciones: iniciativas o actividades necesarias para su consecución.

Resultados: beneficios que se esperan obtener en cuanto a mejorar el funcionamiento de la organización, sus productos y/ o servicios, clima organizacional y relaciones con el entorno.

Alcance: área de aplicación que cubre el estudio en términos de ubicación en la estructura orgánica y/ o territorial.

Recursos: requerimientos humanos, materiales y tecnológicos necesarios para desarrollarlo.

Costo: estimación global y específica de recursos financieros que demanda su ejecución.

Estrategia: ruta fundamental necesaria para orientar los recursos de acción y asignación de recursos. Información complementaria: material e investigaciones que pueden servir como elementos de apoyo.

A) Programa de Trabajo

Identificación: nombre del manual. Responsable(s): unidad o grupo que tendrá a su cargo la implantación del manual. Área(s): universo bajo estudio. Clave: número progresivo de las actividades estimadas. Actividades: pasos específicos que tienen que darse para captar la información. Fases: definición del orden secuencial para realizar las actividades. Calendario: fechas asignadas para el inicio y terminación de cada fase. Representación gráfica: descripción del programa en cuadros e imágenes.Formato: presentación y resguardo del programa de trabajo. Reportes de avance: seguimiento de las acciones. Periodicidad: espacio de tiempo dispuesto para informar avances.

B) Presentación del Proyecto a las Autoridades Competentes

a) Participantes Para depurar el contenido del proyecto, afinar sus parámetros y determinar su viabilidad operativa, es recomendable presentarlo a:

Área (s) que intervendrá directamente en su aplicación, por lo cual tienen la obligación de conocer el proyecto en forma detallada.

Áreas afectadas por la implantación del proyecto, ya que tendrán que cambiar o adecuarse.

Área responsable del manejo de los recursos económicos, para cuantificar el costo del proyecto en forma más específica.

b) Responsable de su autorización

Asimismo, el proyecto debe presentarse al titular de la organización o de la unidad administrativa responsable de su ejecución, para su aprobación.

Una vez autorizado, el responsable debe hacer del conocimiento de todos los niveles jerárquicos la intención que tiene la organización de elaborar el manual, resaltando los beneficios que de este esfuerzo se obtendrán,

a fin de que todos brinden su apoyo durante el desarrollo del trabajo. Sin este requisito, la labor de integración del manual se vería seriamente dificultada.

C) Capacitación de la Información

Como primer paso de esta etapa se debe obtener una lista del personal que va a participar en el levantamiento de la misma, considerando la magnitud y especificaciones del trabajo. a) Capacitación del personal Una vez integrado el grupo de trabajo, se debe capacitarlo, no sólo en lo que respecta al manejo de medios de investigación que se utilizarán para el levantamiento de la información, sino también en todo el proceso que se seguirá para preparar el manual. Por ello, se debe dar a conocer a los participantes el objetivo que se persigue, así como los métodos de trabajo adoptados, calendarización de actividades, documentos que se emplearán. (Cuestionarios, formatos, etcétera), responsables del proyecto, unidades administrativas involucradas, inventario de información a captar y distribución del trabajo a cada persona.

Cuando el grupo de trabajo sea numeroso, puede resultar conveniente formar subgrupos, coordinados cada uno por un responsable, quien debe encargarse de revisar y homogeneizar la información.

Es recomendable efectuar un estudio en un área piloto, para luego comparar y evaluar los resultados obtenidos.

b) Levantamiento de la información

Los esfuerzos de recopilación deben enfocarse en el registro de hechos que permitan conocer y analizar información específica y verdaderamente útil para el manual, pues de lo contrario se puede incurrir en interpretaciones erróneas, lo cual genera retraso y desperdicio de recursos.

Asimismo, debe aplicarse un criterio de discriminación, basado en el objetivo del estudio, y proceder continuamente a su revisión y evaluación para mantener una línea de acción uniforme.

Esta actividad exige mantener una relación constante con las fuentes internas emisoras de la información, así como con las áreas u organizaciones con otra ubicación física.

Para recabar la información en forma ágil y ordenada se puede utilizar alguna o una combinación de las siguientes técnicas de recopilación:

Investigación documental:

Esta técnica permite la selección y análisis de aquellos escritos que contienen datos de interés relacionados con el manual. Para ello se estudian documentos tales como bases jurídico-administrativas, diarios oficiales, actas de reuniones, circulares, oficios y todos aquellos que contengan información relevante para el estudio.

Acceso a sistemas computacionales que contienen información y recursos de apoyo para estructurar el manual. Este mecanismo permite recabar información interna y/o de sistemas externos a la organización enlazados a través de redes.

Encuesta:

Este método implica la realización de entrevistas personales con base en una guía de preguntas elaborada con anticipación. También se puede utilizar un cuestionario, a fin de que las entrevistas tengan un contenido homogéneo.

Esta técnica se considera de gran utilidad para reunir información preliminar al análisis o para efecto de plantear cambios o modificaciones a la estructura actual de la información. La encuesta puede realizarse en forma individual o reuniendo a directivos y empleados de una misma área o que intervienen en la misma clase de tareas.

También se puede recabar información de clientes y/o usuarios, prestadores de servicios y proveedores que interactúan con la organización. Los cuestionarios que se utilizan en la encuesta, y que sirven para obtener la información deseada, están constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por capítulos o temática específicos.

Este medio permite ahorrar recursos y tiempo; sin embargo, la calidad de la información que se obtiene depende de su estructuración y forma de presentación.

En términos generales, todo cuestionario debe expresar el motivo de su preparación, procurar que las preguntas sean claras y concisas, con un orden lógico, redacción comprensible, facilidad de respuesta y evitar demasiadas preguntas. Asimismo, se puede incluir un instructivo de llenado para indicar cómo contestarlo.

La entrevista consiste básicamente en celebrar reuniones individuales o grupales en las cuales se cuestiona orientadamente a los participantes para obtener información. Este medio es posiblemente el más usado y el que puede brindar información más completa y precisa, puesto que el entrevistador, al tener contacto con el entrevistado, además de obtener respuestas, puede percibir actitudes y recibir comentarios.

Para que una entrevista se desarrolle positivamente, es conveniente observar estos aspectos:

Tener claro el objetivo: para cubrir este aspecto, se recomienda preparar previamente un cuestionario o guía de entrevista que contenga los principales puntos que se desea captar. Esta guía puede operar a manera de marco de trabajo para que, al término de la misma, se pueda verificar si se ha obtenido la información requerida.

Establecer anticipadamente la distribución del trabajo: esta etapa consiste en asignar responsabilidades y determinar las áreas a investigar. Concretar previamente la cita: es importante que el entrevistado esté preparado para proporcionar la información con el tiempo y tranquilidad necesarios para disminuir el margen de error y evitar interrupciones.

Clasificar la información que se obtenga: esta fase implica diferenciar la situación real de la relativa a sugerencias para mejorarla, procurando no confundir ambos aspectos.

ELABORACIÓN DEL MANUAL TÉCNICO

Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.

Su extensión depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas técnicas en donde se describe en cada una las características de cada recurso.

Consideraciones Generales para la Documentación de el Desarrollo de Aplicaciones Informáticas:

1. Toda documentación que se genere para un proyecto específico, que haya sido revisada y aprobada, debe poseer lo siguiente:

A) Identificación del documento

Este documento debe incorporar la siguiente información:

• Logotipo de la organización. • Nombre oficial de la organización. • Denominación y extensión. De corresponder a una unidad en particular debe anotarse el nombre de la misma. • Lugar y fecha de elaboración. • Número de revisión (en su caso). • Unidades responsables de su elaboración, revisión y/o autorización. • Clave de la forma. En primer término, las siglas de la organización, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último, el número de la forma. Entre las siglas y el número debe colocarse un guión o diagonal.

B) Estructura del documento.

2. Por cada documento final deberá entregarse copias al personal involucrado en el proyecto.

3. Una vez concluido el desarrollo de un sistema, considerando para esto los posibles cambios que se efectúen durante la etapa de garantía de que lo cubre (si así fuera el caso), el usuario final del sistema debe recibir una versión actualizada final del documento manual técnico.

Estructura del documento manual técnico:

Índice

Relación de los capítulos y páginas correspondientes que forman parte del documento

Introducción.

Se debe presentar una breve descripción del sistema desarrollado, que contemple el ámbito abarcado, cual es su función principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.

Objetivo general del sistema

Se debe de describir el objetivo general del sistema.

Objetivos específicos

Se deben describir brevemente los objetivos específicos que se cumplieron con el desarrollo del sistema.

Contenido técnico Definición de reglas del negocio implementadas en el sistema desarrollado.

Diagramas de flujo de datos, junto con su respectivo diccionario de datos.

Controles de auditoría implementados en el sistema.

Descripción de campos requeridos por pantalla con presentación de pantallas.

Diagrama de navegación del sistema.

Requerimientos de interface con otros sistemas.

Modelo lógico de datos, diagrama entidad-relación.

Modelo de datos físico, junto con su respectivo diccionario de datos.

Matriz de procesos versus organización.

Matriz de programas versus entidades.

Plataforma de usuario. Aquí se describen los requerimientos mínimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).

Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren los procedimientos

Responsables.

Para iniciar los trabajos que conducen a la integración de un manual, es indispensable prever que no queda diluida la responsabilidad de la conducción de las acciones en diversas personas, sino que debe designarse a un coordinador, auxiliado por un equipo técnico, al que se le debe encomendar la conducción del proyecto en sus fases de diseño, implantación y actualización.

De esta manera se logra homogeneidad en el contenido y presentación de la información. Por lo que respecta a las características del equipo técnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organización en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organización puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular del área específica. Asimismo, puede contratar los servicios de consultores externos.