Post on 29-Jun-2015
CA
M
ARREEN I
M.E. Ju
ERA INF
Desa
Diseñ
Ela
uan Car
A DEORM
APM
arrollode
Suar Sist
borado
rlos Ga
Pla
E TÉMÁT
PUN
Modulo de sisinform
ubmódtemas
o por:
alván M
antel R
ÉCNTICA
NTE
lo III stemamación
dulo Ide Inf
Martín
Rincón
NICOA ES s básin
I forma
nez
de Tam
Mayo
O
cos
ación
mayo
o 2009
2
MENSAJE A LOS ALUMNOS
La Importancia De Tus Apuntes
Tomar apuntes es una técnica fundamental para facilitarse la tarea de aprender y
estudiar. La integración de varias habilidades lleva tiempo, pero con la práctica se
logran.
Tomar apuntes ayuda a que desarrollemos la capacidad de concentración. Si no
aprendemos a concentrarnos, la vida puede acabar siendo profundamente aburrida
porque no podrías aprender más que cosas mecánicas...
Aprender a concentrarte también te sirve para aprender a escuchar. Así que hay que
proponerse aprender a tomar apuntes, porque aunque pueda resultar difícil al
principio, es una actividad llena de ventajas.
Aquí están unos consejos para poder tener unos apuntes bien hechos:
‐ Entender lo importante de lo que no lo es. El profesor cuando dice algo importante lo
resalta repitiéndolo varias veces, así es que alerta cuando el profe repita algo, toma
nota.
‐ Capta la idea y escríbela sin repetirla.
‐ Utiliza las abreviaturas, de esta manera, la velocidad de escritura será mejor y no
perderás el hilo de lo que el profesor dice.
‐ Utiliza títulos, flechas, guiones, asteriscos y todos aquellos elementos que te ayuden a
estudiar. De esta manera podrás identificar los puntos clave de tus apuntes.
‐ No escribas muy junto, es mejor separar tu escritura, de esa manera podrás agregar
algunas ideas tuyas o de tus compañeros. La ventaja es que con un buen orden
estudiarás mejor.
i
3
INFORMACIÓN GENERAL
El presenta trabajo está dirigido a los alumnos de la CARRERA DE TÉCNICO EN
INFORMÁTICA. El modulo del cual se desarrolla los apuntes son del MÓDULO III:
Desarrollo de Sistemas Básicos de Información en el submódulo II: Diseñar
Sistemas de Información que tiene una duración de 80 horas en el semestre.
Para mayor referencia a continuación se presenta la estructura curricular del
bachillerato tecnológico, donde se contempla la ubicación del Modulo III y el semestre
donde se ubica.
Las competencias se encuentran colocadas como capítulos para su manejo dentro de
los apuntes. En cada uno de los capítulos se localiza la información necesaria para
consultar dicha competencia. Se anexa un pequeño apartado al final de algunos
capítulos llamados SITUACIÓN el cual se identifica dentro de un recuadro para
ejemplificar lo dicho en dicho capítulo.
ii
4
INTRODUCCIÓN
El desarrollo de los apuntes del submódulo Diseñar Sistemas de Información de 4to
semestre, es el reflejo de años de dedicación e impartición de esta materia, a su vez
representa una útil y práctica herramienta para los profesores que imparten la
materia y de apoyo para los alumnos que cursan la carrera de Técnico en Informática.
Haciendo un breve recuento de la materia. En sus inicios su nombre se denominaba
Base de Datos I y II, que posteriormente fue y es Diseñar Sistemas de Información.
Esto se debió al cambio de la nueva reforma del bachillerato en su estructura
curricular de la cual se presentó la carrera de Técnico en Informática.
Sin importar los cambios y los nuevos nombres de esta asignatura, los conceptos
claves no han cambiado mucho, por tanto estos apuntes son el esfuerzo de años de
dedicación para agilizar y obtener mejoras en la forma de dar los contenidos.
Los apuntes son una herramienta importante, y con los trabajos sobre competencias
es indispensable tener a la mano los conceptos y guías sobre la materia para planificar
actividades orientadas a un aprendizaje significativo y con base en esto, tomar
prácticas para generar una Zona de Desarrollo Próximo como Vigotsky menciona.
Los apuntes son una ayuda en la asignatura, más no es el único elemento que se debe
utilizar para su impartición, con esto se busca mostrar varios caminos al tomar este
trabajo como base para generar en los alumnos actividades que representen interés y
generen aprendizaje por sí mismos como Ausubel describe en su aprendizaje
significativo.
iii
5
ÍNDICE
MENSAJE A LOS ALUMNOS INFORMACIÓN GENERAL INTRODUCCIÓN
iiiiii
CAPÍTULO I: APLICAR EL ANÁLISIS DE SISTEMAS DE ACUERDO A LAS NECESIDADES Y REQUERIMIENTOS DE LOS USUARIOS
1
1.1. Investigación preliminar 1.2. Propuesta de solución. 1.3. Estudio de factibilidad 1.4. Toma de decisiones 1.5. Requerimientos de un sistema 1.6. Obtener los datos del sistema empleando herramientas analíticas 1.7. Diagrama de Flujo
234691015
CAPÍTULO II: DETERMINAR LOS ELEMENTOS DE UN SISTEMA DE BASE DE DATOS 18
2.1. Identificar tipo de información 2.2. Identificar tipos de usuarios 2.3. Determinar el equipo a utilizar 2.4. Determinar los programas a desarrollar
19202021
CAPÍTULO III: DISEÑAR UNA BASE DE DATOS EN BASE AL MODELO ENTIDAD/RELACIÓN
22
3.1. Definir entidades y relaciones 3.2. Establecer atributos 3.3. Definir los enunciados semánticos 3.4. Establecer los esquemas para los enunciados semánticos 3.5. Realizar el diagrama entidad/relación
2223242627
CAPÍTULO IV: DESARROLLAR BASES DE DATOS MEDIANTE UN PROGRAMA ADMINISTRADOR
29
4.1. Crear tablas de acuerdo a las entidades diseñadas4.2. Asignar las claves principales a las tablas creadas 4.3. Establecer relaciones entre las tablas creadas
293536
CAPÍTULO V: VERIFICAR EL SISTEMA DE INFORMACIÓN. 435.1. Realizar pruebas al sistema de información5.2. Validar el sistema de información 5.3. Implantar el sistema de información 5.4. Realizar mantenimiento al sistema de información
43454849
CAPÍTULO VI: ELABORAR DOCUMENTOS DEL SISTEMA DE INFORMACIÓN EN UN LENGUAJE DE PROGRAMACIÓN VISUAL
51
6
6.1. Elaborar el manual de técnico 6.2. Elaborar el manual de usuario
5255
REFERENCIAS BIBLIOGRÁFICAS
1
CAPÍTULO I: APLICAR EL ANÁLISIS DE SISTEMAS DE ACUERDO A LAS
NECESIDADES Y REQUERIMIENTOS DE LOS USUARIOS
Un sistema de información es un conjunto de elementos que interactúan entre sí con
el fin de apoyar las actividades de una empresa o negocio. Estos elementos pueden ser
transformados en una base de datos para su manejo y control de datos para hacer más
eficiente el sistema.
Un sistema se puede identificar de dos formas: Sistemas automatizados y Sistemas
Manuales. Los sistemas manuales son aquellos que se llevan por medio de acciones
humanas denominados procesos. Los sistemas automatizados son aquellos se llevan a
cabo de manera automática, donde interviene la computadora para realizar los
procesos haciendo estos más eficientes y seguros.
Para fines de simplificar lo dicho anteriormente, se puede comparar el sistema manual
con la tiendita de la esquina que lleva el control de lo fiado en una libreta para su
posterior cobro, en cambio el sistema automatizado es un sistema similar pero llevado
en una computadora por ejemplo un supermercado donde se cobrea por código de
barras y se da un ticket; se cobra en efectivo o con tarjeta de crédito.
Para realizar el desarrollo de un sistema de manera eficiente, la primera etapa a
seguir es la realización de un análisis, ya que este es la base del éxito o fracaso del
diseño de un sistema de información. Por tanto, un analista de sistemas generalmente
evalúa la manera en que funciona un negocio, de tal suerte que se tiene que examinar
las entradas, el procesamiento de los datos y la salida de información con el propósito
de mejorar los procesos.
Diagrama 1: Flujo de información en un negocio
Proceso Salida Entrada
2
En la actualidad para muchas organizaciones, los sistemas de información basados
en computadoras es el corazón de sus actividades cotidianas. Por ejemplo, el cálculo
de nómina, control de mercancía en almacén, etc., por este motivo, al establecer los
sistemas de información basados en computadoras deben tener la certeza de lograr
un automatizado eficiente.
Otro punto importante para tomar en cuenta en la realización de los sistemas de
información es la necesidad del mismo sistema, ya que si un sistema no logra
satisfacer las necesidades de entrada y salida de datos precisos, confiables y
completos no sirve para lograr un mejor funcionamiento del mismo.
Estas y otras consideración para diseñar un sistema de información que satisfaga las
necesidades de un negocio, se lleva de una mejor manera cuando se planea acorde a
los requerimientos del sistema.
A continuación se presenta un método claro y fácil para el diseño de un sistema de
información, que ayuda a crear un sistema automatizado con la utilización de un
manejador de base de datos.
1.1. INVESTIGACIÓN PRELIMINAR
El primer paso para iniciar un diseño de un sistema de información con la utilización
de una Base de Datos es la investigación preliminar, la cual nos ayuda a comprender
los procesos y las cosas que pasan en un negocio para poder entender su
funcionamiento y de esta manera lograr aterrizar las ideas y no divagar en lo que se va
a investigar. Es recomendable comenzar con sencillas preguntas a la hora de obtener
información, tales como: ¿qué hacen en este lugar?, ¿cuáles son sus dificultades?, ¿Qué
hacen los empleados habitualmente?, etc.
3
La investigación preliminar comienza con la solicitud por parte del dueño del negocio
u otra persona que tiene interés de sistematizar su sistema manual.
SITUACIÓN: El dueño de la farmacia necesita tener un sistema de información que pueda usar para lograr la búsqueda eficaz de las medicinas cuando los clientes vayan a comprarla. ¿Cuál es su problema? La respuesta es muy variada, pero la respuesta directa a la situación es: R. El problema es que el dueño no es rápido en la búsqueda y por tanto, los clientes se le juntan y se desesperan, por tanto se van a buscar su medicina a otras farmacias. Las respuestas alternas son: R1. Si no tiene control de las medicinas para su búsqueda, puede ser posible que no tenga un control de la medicina y no sepa cuanta tiene en almacén. R2. Si no tiene un registro de la medicina, tampoco lo tendrá de los clientes, así que tampoco podrá tener un registro de sus clientes y saber cuáles son los que le puede dar promociones. ¿Qué soluciones darle? La respuesta es Automatizando su sistema. Esto es: lograr que lo que el dueño hace manualmente, pasar el trabajo a la computadora para que el solo se preocupe en traer la medicina y cobrar.
1.2. PROPUESTA DE SOLUCIÓN
Terminada la investigación preliminar, se presenta una propuesta de solución que
satisfaga las necesidades y presupuesto de la persona que te está contratando para
llevar a cabo la investigación.
Muchas solicitudes no están formuladas de manera clara, por lo que debe de
examinarse para determinar con precisión lo que el solicitante desea. Si el solicitante
pide ayuda sin saber qué es lo que está mal o en donde se encuentra el problema, la
aclaración se hace más difícil. En cualquier caso, antes de seguir adelante, la solicitud
debe estar claramente planteada.
4
Después de aclarar lo que la persona quiere hacer, es factible dar varias alternativas
para solucionar el o los problemas que se tienen en el sistema a automatizar.
Los problemas más comunes en un sistema de información son el manejo de mucha
información en sus operaciones y la mala administración del personal para procesar
esta gran cantidad de información en un periodo corto de tiempo.
SITUACIÓN: El dueño de la farmacia necesita tener un sistema de información que pueda usar para lograr la búsqueda eficaz de las medicinas cuando los clientes vayan a comprarla. ¿Cuál es la petición? La petición del dueño de la farmacia es que le puedas hacer un sistema que logre identificar en donde se encuentran las medicinas de los estantes. ¿Cuáles son las alternativas? Antes de hacer el sistema proponer acomodar las medicinas en de acuerdo a un orden, ya sea alfabéticamente, de acuerdo a la formula de la medicina, por etapas de edades, etc. La situación es clásica, el dueño necesita ser eficiente en la búsqueda, pero para lograrlo, primero hay que tener un orden en las medicinas de la farmacia, y después pensar en hacer el sistema.
1.3. ESTUDIO DE FACTIBILIDAD
Ya se conoce completamente el sistema manual y sus procesos, ahora se debe
determinar si los objetivos planteados anteriormente son factibles, es decir, si sobre el
sistema con que se cuenta actualmente se pueden realizar las modificaciones
necesarias para el logro de dichos objetivos.
Es importante determinar que el sistema solicitado sea factible, para ello existen tres
puntos importantes de factibilidad:
5
Factibilidad técnica: El trabajo ¿puede realizarse con el equipo actual, la tecnología
existente de software y el personal disponible? Si se necesita nueva tecnología ¿cuál es
la posibilidad de desarrollarla?
Factibilidad económica: Al crear el sistema ¿los beneficios que se obtienen serán
suficientes para aceptar los costos?, ¿los costos asociados con la decisión de no crear
el sistema son tan grandes que se debe aceptar el proyecto?
Factibilidad operacional: Si se desarrolla e implanta, ¿será utilizado el sistema?,
¿existirá cierta resistencia al cambio por parte de los usuarios que dé como resultado
una disminución de los posibles beneficios de la aplicación?
SITUACIÓN: Se llevó el estudio de factibilidad en la Farmacia, de la cual se obtuvieron los resultados siguientes: 1. No cuenta con equipo de cómputo para desarrollar el software, pero se piensa comprar uno nuevo. 2. Son pocos los clientes que acuden a comprar medicina, pero se cambiará de local. 3. No se puede organizar el dueño de la farmacia con las medicinas, esta renuente a cambiar su método de acomodo, pero se contratará a personal. ¿Es factible técnicamente? R. De acuerdo a los resultados, si no cuenta la farmacia con equipo, pero el dueño necesita el sistema, es recomendable comprar uno nuevo. ¿Es factible económicamente? R. Si se toma por el lado de que no tiene clientes, puede no ser factible, pero si se sabe de antemano que se cambiará a una zona como a lado de un hospital, vale la pena invertir. Así que si el caso es este último, es muy factible. ¿Es factible operacionalmente? La renuencia del dueño, puede ser algo que no sea factible, pero si se sabe que va a tener empleados, es posible lograr una mejor operatividad con los nuevos usuarios del sistema de la farmacia. En este sentido, de acuerdo a las investigaciones que se realicen, por lo generar un sistema siempre es factible si cumple con tres cosas: dinero, disponibilidad y procesos muy bien diseñados.
6
1.4. TOMA DE DECISIONES
¿QUÉ ES LA TOMA DE DECISIONES?
La toma de decisiones es un proceso en el que uno escoge entre dos o más
alternativas. Todos y cada uno de nosotros nos pasamos todos los días y las horas de
nuestra vida teniendo que tomar decisiones. Algunas decisiones tienen una
importancia relativa en el desarrollo de nuestra vida, mientras otras son gravitantes
en ella.
La toma de decisiones en una organización se circunscribe a todo un colectivo de
personas que están apoyando el mismo proyecto. Debemos de empezar por hacer una
selección de decisiones, y esta selección es una de las tareas de gran trascendencia en
el trabajo del jefe o encargado del proyecto.
Los pasos en el proceso de la toma de decisiones son:
1.‐ Determinar la necesidad de una decisión.
2.‐ Identificar los criterios de decisión.
3.‐ Asignar peso a los criterios.
4.‐ Desarrollar todas las alternativas.
5.‐ Evaluar las alternativas.
6.‐ Seleccionar la mejor alternativa.
Para darle una mejor explicación, a continuación se desglosa cada uno de los puntos
arriba mencionados:
1.Determinar la necesidad de una decisión El proceso de toma de decisiones
comienza con el reconocimiento de que se necesita tomar una decisión. Ese
7
reconocimiento lo genera la existencia de un problema o una disparidad entre cierto
estado deseado y la condición real del momento.
2. Criterios de decisión Una vez determinada la necesidad de tomar una
decisión, se deben identificar los criterios que sean importantes para la misma. Vamos
a considerar un ejemplo:
"Una persona piensa adquirir un automóvil, los criterios de decisión de un comprador
típico serán: precio, modelo, dos o más puertas, tamaño, nacional o importado, equipo
opcional, color, etc. Estos criterios reflejan lo que el comprador piensa que es
relevante. Existen personas que le son irrelevantes que sea nuevo o usado, lo
importante es que cumpla sus expectativas de marca, tamaño, imagen, etc., y se
encuentre dentro del presupuesto del que disponen. Para el otro comprador lo
realmente importante es que sea nuevo, despreciando el tamaño, marca, prestigio,
etc."
3. Asignar peso a los criterios.‐ Los criterios enumerados en el paso previo no tiene
igual importancia. Es necesario ponderar cada uno de ellos y priorizar su importancia
en la decisión.
Cuando el comprador del automóvil se pone a ponderar los criterios, prioriza los que
por su importancia condicionan completamente la decisión: precio y tamaño. Si el
vehículo elegido tiene los demás criterios (color, puertas, equipo opcional, etc.), pero
rebasa el importe de los que dispone para su adquisición o es de menor tamaño al que
precisamos por el uso que se le va a dar, entonces nos encontramos con que los demás
criterios son relevantes en base a otros de importancia trascendental.
4. Desarrollar todas las alternativas Desplegar las alternativas. El tomador de la
decisión tiene que confeccionar una lista de todas las alternativas posibles y que
podrían utilizarse para resolver el problema.
8
5. Evaluar las alternativas Una vez identificadas las alternativas, el tomador de
decisiones tiene que evaluar de manera crítica cada una de ellas. Las ventajas y
desventajas de cada alternativa resultan evidentes cuando son comparadas.
La evaluación de cada alternativa se hace analizándola con respecto al criterio
ponderado.
6. Seleccionar la mejor alternativa Una vez seleccionada la mejor alternativa se
llegó al final de proceso de toma de decisiones. En el proceso racional, esta selección
es bastante simple. El tomador de decisiones solo tiene que escoger la alternativa que
tuvo la calificación más alta en el paso número cinco. El ejemplo nos daría como
resultado la compra del Mercedes, con mínimas diferencias con las otras dos marcas.
El paso seis tiene varios supuestos, es importante entenderlos para poder determinar
la exactitud con que este proceso describe el proceso real de toma de decisiones
administrativas en las organizaciones.
En conclusión, la toma de decisiones se presenta en todo momento en nuestras vidas,
cuando debamos seleccionar entre varias opciones o caminos, y este proceso se va a
presentar mucho más para un analista de sistemas, ya que para realizar un sistema, o
modificar errores que encuentre en estos, va a tener que optar por la forma más eficaz
de resolverlo, teniendo en cuenta, tanto las necesidades que tenga, como todas las
partes que lo constituyen.
SITUACIÓN: El dueño de la farmacia quiere comprar una computadora, pero no sabe cual comprar. Una de marca o una armada. ¿Cuál elegir? De acuerdo a la economía del dueño de la farmacia se comprará, pero también de acuerdo a las necesidades del sistema, ya que si se pretende tener un sistema que tenga un lector de código de barras y además la licencia del Software, es recomendable una de marca, ya que esta contiene la licencia. Además de esta toma de decisiones, se presentan todavía más, las cuales se deben afrontar de acuerdo las necesidades del sistema.
9
1.5. REQUERIMIENTOS DE UN SISTEMA
El objeto de la etapa de determinación de requerimientos es definir lo que el sistema
debe ser capaz de realizar, para ello es necesario determinar cuáles serán las
entradas, salidas, operaciones y recursos que necesitará el sistema para operar
adecuadamente y cubrir las necesidades de la organización. No obstante debe quedar
bien claro que en esta etapa aún no estamos rediseñando el sistema, sino
determinando cuáles son los criterios generales de funcionamiento, mismos que nos
ayudarán en el rediseño del sistema.
Para la determinación de requerimientos el analista debe basarse principalmente en
los datos obtenidos en las etapas de Análisis del Sistema, pues ésta nos dice cuáles son
las necesidades de los usuarios. Pero también se deben tomar muy en cuenta los
planes futuros de la organización para lograr que el "nuevo sistema" se ajuste a dichos
planes El analista de sistemas debe determinar los requerimientos del "nuevo
sistema" en el siguiente orden:
1.‐ Salidas que debe producir el sistema, como son reportes, documentos,
desplegados, etc.
2.‐ Entradas necesarias para producir las salidas esperadas, las cuales pueden ser
tomadas de lentos fuentes o ser introducidas directamente al sistema.
3.‐ Todas las operaciones que debe realizar el sistema para producir las salidas
esperadas.
4.‐ Los recursos que se necesitan para la operación del sistema, como son: hardware,
software, recursos humanos, materiales y técnicos.
Es necesario que el analista determine primero cuáles serán las salidas que debe
producir el sistema, y basándose en éstas podrá determinar cuáles son las entradas
que se requerirán, qué operaciones deben llevarse a cabo y con qué recursos se debe
contar para producir las salidas deseadas. Así como definir los controles con los que
se debe contar.
10
SITUACIÓN: El sistema de la farmacia requiere la utilización de un escáner de código de barras para su funcionamiento, a su vez que imprima el ticket de compra. ¿Cuáles son los requerimientos? En este caso, son los ticket de compra para los usuarios, ya que el escáner es una necesidad que se determina en la toma de decisiones y el la factibilidad económica.
1.6. OBTENER LOS DATOS DEL SISTEMA EMPLEANDO HERRAMIENTAS
ANALÍTICAS
La obtención de la información, como se plantea en la investigación preliminar es en
base a preguntas, por tanto en esta sección se presenta los métodos de obtener datos
del lugar donde se desarrolla el sistema.
Entrevista con los usuarios
La herramienta más importante en la etapa de planteamiento de objetivos es la
entrevista con los usuarios, pues por medio de esta el analista de sistemas se da
cuenta de cómo operan las cosas actualmente y como les gustaría a los usuarios que
operaran en el futuro.
La forma más atinada para la realización de entrevistas es aplicarlas de arriba hacia
abajo, es decir, comenzar por los niveles gerenciales y terminar con los trabajadores
operacionales que participen en el sistema que se está estudiando.
A continuación se nombran una serie de aspectos que hay que tomar en cuenta si se
desea tener éxito en una entrevista:
a) Antes de realizar cualquier entrevista es necesario solicitar autorización para la
realización de la misma, esto se debe hacer ante el jefe inmediato superior de la
11
persona a ser entrevistada, y de ser posible que sea éste quien presente al analista con
su subordinado.
b) Toda entrevista debe ser planeada con anterioridad con el fin de tener bien claro
cuáles son les objetivos que se persiguen con ésta, es decir, realizar un esbozo de las
preguntas que se van a hacer al entrevistado, así como el enfoque que se le va a dar a
cada una de ellas; sin embargo el analista se debe permitir ciertos desvíos del plan,
pues en ocasiones las respuestas obtenidas indican que es necesario ahondar en
ciertos temas o quizá haya algunos temas que se tornen de poco o nulo interés, e
incluso hay ocasiones en las que hay que dar completamente un giro a lo que se tenía
planeado.
En realidad, no siempre es necesario determinar con anterioridad las preguntas que
se van a plantear, pues a veces el analista decide que es preferible realizar una
entrevista menos formal en la que solamente se vaya dirigiendo al entrevistado hacia
el tema o los temas que se desean conocer.
La decisión de realizar una entrevista bien planeada o una menos formal se toma
basándose en la labor que el entrevistado realiza dentro de la organización y la
información que se desea obtener.
c) Un punto importante para el éxito de la entrevista es buscar un horario oportuno
para que el entrevistado no se esté distrayendo, conteste todas las preguntas
rápidamente sin analizarlas por tener trabajo pendiente, o se presente cualquier otra
situación por la que no preste la atención que se necesita. Por lo anterior se
recomienda hablar antes con el entrevistado y darle la oportunidad de determinar el
día y la hora en que se realizará la entrevista, aclarándole que necesitamos de su
completa atención.
d) El analista de sistemas debe causar buena impresión al entrevistado, debe ser
cortés, nunca prepotente, debe transmitir confianza al entrevistado para que éste no
12
sienta que se le está juzgando o fiscalizando; el analista debe presentarse vestido de
una manera adecuada pues es difícil que alguien acceda a cooperar y poner su
confianza en una persona sucia y desaliñada.
e) Se deben evitar las entrevistas largas, pues llega un momento en que el
entrevistado se cansa y empieza a distraerse; por lo cual es preferible tener varias
entrevistas cortas en lugar de una muy larga.
f) Propiciar un ambiente adecuado de tal manera que la persona a entrevistar se
sienta bien, para ello es necesario considerar ciertos aspectos tales como el dejar
hablar al entrevistado, no interrumpirlo a menos de que se esté desviando demasiado
del tema. El analista no debe suponer nada ni dar algo por hecho, pues el entrevistado
se puede confundir o sentir mal. Hay que respetar a cualquier persona sea cual fuere
su puesto dentro de la organización. Es imprescindible también tratar de hablarle a
cada entrevistado en su lenguaje, pues no podemos utilizar el mismo con un gerente
que con el trabajador de menor nivel.
g) El analista debe concretarse al tema, no empezar a tratar asuntos que no tienen
nada que ver con el estudio del sistema.
h) El analista debe tener despiertos sus cinco sentidos, debe estar pendiente de lo que
pasa alrededor y del lenguaje corporal del entrevistado, pues en muchas ocasiones
estos aspectos revelan cosas importantes.
i) Inmediatamente después de terminada la entrevista ésta se debe transcribir y
documentar, incluso se pueden elaborar diagramas que contribuyan a una mejor
comprensión de lo investigado.
Una grabación de la entrevista es de gran ayuda para la documentación, pero ésta se
debe hacer sólo con el consentimiento del entrevistado. Un resumen y auto evaluación
podría servir de gran ayuda para entrevistas posteriores.
13
Preguntas en la entrevista
Las preguntas de la entrevista deben estar encaminadas a conocer perfectamente
todas las actividades que se realizan en el sistema, así como las entradas requeridas y
las salidas que éste produce; y por supuesto determinar cuáles son los cambios que
necesita el actual sistema.
A continuación se presentan algunas preguntas que no deben faltar en una entrevista
bien planeada.
El analista deber agregar aquéllas que considere necesarias. Primero se aplican las
preguntas que ayudan al conocimiento del sistema actual.
Generales
• ¿Qué actividades se realizan?
• ¿Quién lo hace?
• ¿Cómo lo hace?
• ¿Cuándo, dónde, cómo, por qué, para qué lo hace?
• ¿Cuánto dura cada una de estas actividades?
• ¿Qué políticas de decisión se siguen?
• ¿Qué costumbres se tienen en el sistema?
• ¿Cuáles son los controles con los que se cuenta?
Entradas
• ¿Qué entradas hay al sistema?
• ¿De dónde vienen?
• ¿Cuándo vienen?
• ¿En qué formato?
• ¿Cómo se procesan las entradas?
• ¿Qué control de entradas se tiene?
14
Salidas
• ¿Qué salidas hay?
• ¿De dónde salen?
• ¿Cuándo salen?
• ¿En qué formato salen?
• ¿A dónde van?
• ¿Qué control de salidas se tiene?
Equipo de procesamiento
• ¿Cuáles son las características del equipo?
• ¿Qué aplicaciones se corren en el equipo?
• ¿Es seguro el equipo?
• ¿Qué controles se tiene?
• ¿Hay integridad?
• ¿En qué ambiente se trabaja ‐ red, independiente, etc.?
• ¿Qué capacidad tiene el equipo?
Una vez que se conoce cómo trabaja el sistema actual, se procede a investigar los
posibles cambios al sistema, para lo cual proponemos las siguientes preguntas:
• ¿Cuáles son los problemas más comunes dentro del sistema?
• ¿Qué agregaría a todo el proceso?
• ¿Qué eliminaría?
• ¿Qué cambios le haría?
Cuando se han terminado las entrevistas con los usuarios y se conocen las
necesidades y opiniones de los usuarios, el analista de sistemas está en condiciones de
plantear ya en forma escrita los objetivos del "nuevo sistema".
Una vez redactados los objetivos se debe llevar a cabo un estudio de su rentabilidad, el
cual debe ser revisado y aprobado por los altos mandos de la empresa, quienes
decidirán si se realizará o no el desarrollo del sistema. Esto con el objeto de tener la
15
seguridad de lo que se está haciendo y por qué se está haciendo, pues sería frustrante
que en etapas posteriores, o incluso una vez terminado el desarrollo, nos diéramos
cuenta de que dicho desarrollo no proporciona ningún beneficio económico a la
empresa, pues bien sabemos que el objetivo principal de cualquier empresa es "ganar
dinero".
Si se tuvieran subprogramas que dependan de uno de los programas del segundo
nivel, se anotarían abajo de éste en el siguiente nivel, y así sucesivamente. Cuando el
analista de sistemas ha terminado la elaboración de árboles Modulares ya está en
condiciones de realizar la "organización de Módulos".
SITUACIÓN: El dueño de la farmacia no tiene tiempo para responder a todas las preguntas que se presentan. ¿Qué hacer para lograr obtener los datos? R1. Se puede realizar la entrevista en su casa, fuera del horario de trabajo. R2. Planear fracciones de la entrevista, de acuerdo al tiempo que se tiene. Las respuestas a esta pregunta pueden ser variadas de acuerdo a la situación, pero el punto crítico es que si se lleva acabo entrevistas de esta manera, el sistema que se piensa desarrollar tardará más tiempo en terminarse y eso no es bueno para los costos del mismo, ya que se elevarían. Con este punto, el dueño de la farmacia tiene que hacer a un lado lo que está haciendo o no se podrá terminar el sistema.
1.7. Diagrama de Flujo
El diagrama de flujo es importante para el análisis de sistema y para determinar
gráficamente el sistema estudiado, por tanto se presenta a continuación la forma de
elaboración y algunos ejemplos.
Elaboración de Diagramas de Flujo
Los diagramas de flujo son una herramienta muy útil en la etapa del Análisis.
Para un sistema proponemos dos tipos de diagramas de flujo:
16
• Diagramas de Flujo de Datos.
• Diagramas de Flujo del Programa.
Diagramas de Flujo de Datos
Este tipo de diagramas muestran cuáles son las entradas, salidas y procesos del
sistema; así como los orígenes y destinos de los datos.
Es recomendable no hacer muy detallado ese tipo de diagrama, pues el objetivo
principal es tener una visión general del sistema sin profundizar mucho en cada una
de las operaciones que este realiza. Se puede elaborar un diagrama en el que se
observe cómo está ubicado el sistema dentro de la organización y las relaciones que
tiene con los demás sistemas en caso de que existan y otro en el que se muestre cómo
intercalan los diferentes módulos que forman parte del sistema.
Los diagramas de Flujo de Datos cuentan con cuatro tipos de gráficos que son
explicados a continuación:
a) Flujo de datos.‐ Son los datos que fluyen en las diferentes operaciones del sistema.
Sobre la flecha debe tener el nombre con que se identifican los datos.
b) Procesos.‐ Representan la conversión de datos de entrada en datos de salida. Cada
proceso debe tener un número y un nombre.
17
c) Origen o destino externo de datos.‐ Representan personas u organismos que no
interesan en el estudio del sistema, pero operan como un origen o destino de los
datos.
d) archivos.‐ Son almacenes de datos. Cuando una flecha de flujo de datos apunta hacia
el símbolo de archivo, se indica que se está almacenando información en el archivo,
pero si la flecha sale de él, es indicio de que se está obteniendo información del
usuario.
A continuación se muestra un ejemplo de un Diagrama de Flujo de Datos basándose en
el ejemplo de la situación de la Farmacia:
Venta medicamento
Dueño
Cliente
Estante
Medicina
Medicina
Dinero
PC Código de Barras
Precio
18
CAPÍTULO II: DETERMINAR LOS ELEMENTOS DE UN SISTEMA DE BASE
DE DATOS
Esto trata, como su nombre lo dice, identificar los elementos que componen a un
Sistema de Base de Datos como son:
Información: conjunto organizado de datos procesados, que constituyen un mensaje
sobre un determinado ente o fenómeno.
Usuarios: Es todo aquel personaje que hace uso de un sistema de información y, en
este caso de un Sistema de Base de Datos:
Dentro de una estructura de una base de datos también está contenido objetos de la
base de datos:
Tablas: unidad donde crearemos el conjunto de datos de nuestra base de datos. Estos
datos estarán ordenados en columnas verticales. Aquí definiremos los campos y sus
características. Más adelante veremos qué es un campo.
Consultas: aquí definiremos las preguntas que formularemos a la base de datos con el
fin de extraer y presentar la información resultante de diferentes formas (pantalla,
impresora...)
Formulario: elemento en forma de ficha que permite la gestión de los datos de una
forma más cómoda y visiblemente más atractiva.
Informe: permite preparar los registros de la base de datos de forma personalizada
para imprimirlos.
19
Macro: conjunto de instrucciones que se pueden almacenar para automatizar tareas
repetitivas.
Módulo: programa o conjunto de instrucciones en lenguaje Visual Basic
2.1. IDENTIFICAR TIPO DE INFORMACIÓN
El primer paso para crear una base de datos, es planificar el tipo de información que
se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información
disponible y la información que necesitamos.
La planificación de la estructura de la base de datos, en particular de las tablas, es vital
para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en
una descripción de cada uno de los campos que componen el registro y los valores o
datos que contendrá cada uno de esos campos.
Los campos son los distintos tipos de datos que componen la tabla, por ejemplo:
nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo,
el tipo de campo, el ancho del campo, etc.
Los registros constituyen la información que va contenida en los campos de la tabla,
por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.
Generalmente los diferente tipos de campos que su pueden almacenar son los
siguientes: Texto (caracteres), Numérico (números), Fecha / Hora, Lógico
(informaciones lógicas si/no, verdadero/falso, etc., imágenes.
En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es
determinar claramente los campos necesarios, definirlos en forma adecuada con un
nombre especificando su tipo y su longitud.
20
2.2. IDENTIFICAR TIPOS DE USUARIOS
Hay 3 tipos diferentes de usuarios de un sistema de BD, diferenciados por la forma en
que interactúan con el sistema
Programadores de aplicaciones: Se encargan de diseñar y programar las
aplicaciones necesarias para la utilización de la B.D.
Usuario final: Es la persona que se dedica a trabajar sobre los datos almacenados en
la B.D. Hay usuarios finales avanzados que por medio del lenguaje de programación
SQL pueden acceder a los datos.
Administrador de B.D.: Es el usuario más importante de los tres, ya que es el que se
encarga de diseñar y modificar la estructura de la B.D.
2.3. DETERMINAR EL EQUIPO A UTILIZAR
Un servidor de bases de datos, no es más que un equipo que contiene un software
SGBD (Sistema Gestor de Bases de Datos), existe infinidad de software de este tipo y
puedes instalar cualquiera en tu propio equipo, volviéndolo así un servidor.
En estos momentos las más usadas son las Bases de Datos Relacionales que
almacenan los datos en tablas que mantienen los datos "relacionados" entre sí, de
forma que se mantienen coherentes.
La mayoría de las páginas web que contienen foros, o contenido actualizable,
almacena sus datos en una o más máquinas que tienen instalado un sistema de bases
de datos.
De acurdo a esto, el equipo que se debe comprar debe contener la seguridad de no
perder los datos en una es carga eléctrica u otro fenómeno que pueda ocurrir, por
21
tanto es necesario a demás de la PC conseguir no‐break o sistemas de alimentación de
energía alternas a la cotidiana para asegurar el resguardo de la información.
2.4. DETERMINAR LOS PROGRAMAS A DESARROLLAR
Hay muchas opciones para crear base de datos, los más comunes son Oracle, MySQL,
SQL Server y utilizan un lenguaje de comunicación llamado SQL (Simple Query
Language) que permite hacer selecciones de datos complejas, inserciones,
actualizaciones y eliminación de datos.
Aquí es recomendable utilizar un manejador de base de datos gratuito o aquel que
tenga licencia para su aplicación e instalación.
En cuanto a la programación del programa que va a interactuar con la base de datos se
puede tener la opción de Visual Basic, Visual FoxPro o Delphi, que son programas que
se pueden enlazar con la base de datos, sin embargo una base de datos también tiene
sus propias formas visuales para trabajar.
22
CAPÍTULO III: DISEÑAR UNA BASE DE DATOS EN BASE AL MODELO
ENTIDAD/RELACIÓN
El modelo Entidad – Relación fue propuesto por Peter Chen, en 1976, usado como el
modelo sobre el cual se soporta el diseño de una base de datos.
Permite crear un modelo de datos en términos de: Entidades, sus Atributos y
Relaciones entre las entidades.
Componentes del Modelo Entidad Relación
Entidades Atributos Relaciones
A continuación se presentan estos tres componentes
3.1. DEFINIR ENTIDADES Y RELACIONES
Las entidades: Son los objetos principales acerca de los cuales se almacena
información. Son cosas de importancia o interés para un área de negocios o para un
sistema que requiere del almacenamiento de datos.
Ejemplos: Personas, Lugares, Cosas o Eventos de interés.
Las Relaciones: Permiten representar diferentes tipos de relaciones entre entidades.
Tienen “semántica “, es decir, almacenan información acerca de la forma en que se
asocian las entidades.
Se dibujan así: RELACIÓN.
Nombre Entidad
23
SITUACIÓN Con el ejemplo de la farmacia: las entidades que se presentan son: Medicina y Cliente. De esto su relación seria:
3.2. ESTABLECER ATRIBUTOS
Los Atributos: son las características de las entidades. Describen a las entidades.
Representan características o cualidades de una entidad. Ejemplos: Nombre de una
persona, Nombres de ciudades, Número de empleado, Fecha de contratación, Monto a
pagar.
Atributo identificador: Identifican de manera única a cada
Ocurrencia de la entidad.
Descriptor: Describen una característica o cualidad de la Entidad.
SITUACIÓN Para la farmacia, un cliente tiene varios atributos: Nombre, dirección, teléfono, etc. En el diagrama se vería así:
3.3. DEFINIR LOS ENUNCIADOS SEMÁNTICOS
Atributo
Atributo
Cliente Medicina
Cliente
Nombre
Dirección
Teléfono
RFC
24
El propósito de los diagramas es mostrar las Entidades de datos y cómo éstas se
relacionan basando esto último en un enunciado.
El DER (diagrama entidad relación) se concentra sólo en las entidades de datos.
Para poder construir un diagrama entidad ‐ relación, se tiene que tener en cuenta
varias cosas, entre ella se comienza con la Pregunta inicial:
¿Cuáles son las entidades de interés acerca de las cuales se desea almacenar datos?
La respuesta a esta pregunta en específico para un negocio comercial podrían ser:
PRODUCTOS, INVENTARIO, PROVEEDORES, FACTURAS, ORDENES DE COMPRA.
El procedimiento que se debe seguir para su Construcción es: Dibujar un bloque para
cada entidad identificada. Para el nombre de las entidades, se recomienda que sean en
singular. Ejemplo:
CLIENTE en lugar de CLIENTES,
ARTICULO en lugar de ARTÍCULOS.
Siguiente pregunta:
¿Cuál relación existe entre cada par de entidades?
Para identificar las relaciones entre dos entidades se realizan dos preguntas:
• Primer pregunta de izquierda a derecha.
• Segunda pregunta de derecha a izquierda.
¿Un cliente cuantas facturas puede tener? Muchas.
¿Una factura cuantos clientes tiene? Una.
25
Después se tiene que analizar si la relación es obligatoria y
se representa así:
Se revisa en ambos sentidos a través de dos preguntas.
¿Una factura puede existir sin un cliente? No ya que es obligatorio tener un cliente.
¿Puede un cliente existir sin factura? Si ya que no es obligatorio tener una factura.
Ejemplo de Producto Factura
¿Un producto puede estar involucrado en muchas facturas? Sí.
¿Una factura cuantos productos puede tener? Muchos.
¿Una factura puede existir sin producto? Sí ya que no existe obligatoriedad.
¿Un producto puede existir sin una factura? Sí ya que no existe obligatoriedad.
En una relación de muchos a muchos se le debe asignar un nombre a la relación.
Tomando PRODUCTO Y PROVEEDOR
¿Un producto cuantos proveedores puede tener? Varios
¿Un proveedor cuantos productos puede tener? Muchos
¿Un proveedor puede existir sin producto? Sí ya que no tiene obligatoriedad
¿Un producto puede existir sin un proveedor? Sí ya que no tiene obligatoriedad
Entidades en un solo diagrama:
26
Para romper una relación de muchos a muchos se crea una tercera entidad con el
nombre de la relación, esta tendrá una relación de uno a muchos con las entidades
originales (el lado de muchos al lado de la nueva entidad y el lado de uno tendrá que
ser obligatorio con las entidades originales).
SITUACIÓN En la farmacia, la pregunta de la relación de cliente y medicina es así: ¿Un cliente cuantas medicinas puede comprar? Muchas. ¿Una medicina a cuantos clientes se le puede vender? muchas.
3.4. ESTABLECER LOS ESQUEMAS PARA LOS ENUNCIADOS SEMÁNTICOS
A continuación se presentan las tablas y la relación de los enunciados y sus preguntas
de la sección anterior para que se vea como quedarían estas preguntas representadas
gráficamente o mejor dicho en un Modelo Entidad ‐ Relación.
Cliente Medicina
27
Ejemplo de Cliente Factura
Ejemplo de Producto Factura
Tomando PRODUCTO Y PROVEEDOR
Diagrama completo
3.5. REALIZAR EL DIAGRAMA ENTIDAD/RELACIÓN
El modelo Entidad – Relación apoya el análisis.
• Definir los requerimientos de la empresa.
• Escribir la información acerca de las entidades y sus relaciones, requeridas para
modelar esos requerimientos.
• Determina los tipos de transacciones que se busca ejecutar sobre la Base de Datos.
El modelo Entidad ‐ Relación apoya el diseño.
28
• “Mejora” la habilidad del diseñador de Base de Datos.
• Permite definir los requerimientos de información del mundo real de la manera
precisa.
• Define la semántica de las relaciones entre los datos.
• Especifica lineamientos para definir reglas de integridad.
En base a estos conceptos, el modelo entidad relación puede ser tan extenso o corto
como lo determina la investigación preliminar. Como se presentó en el tema anterior
un diagrama terminado se ve de la siguiente manera, tomando todos los ejemplos
explicados:
SITUACIÓN El diagrama de la farmacia basando el supuesto que se necesita un sistema que determine la búsqueda rápida de artículos además de anexar la cartera de clientes queda de la siguiente manera:
Nota
Cantidad
Total
Fecha
Folio
Medicina
Nom
Marca
Caducidad
Código
Cliente
Nom
DirTel
RFC
RFC
Código
29
CAPÍTULO IV: DESARROLLAR BASES DE DATOS MEDIANTE UN
PROGRAMA ADMINISTRADOR
En este tema se toma como base el programa de base de datos llamado Microsoft
Access el cual es el que está instalado en la institución. Por tanto se desarrolla un
pequeño manual sencillo para los propósitos de informar y dar practica sencilla para
su manejo.
4.1. CREAR TABLAS DE ACUERDO A LAS ENTIDADES DISEÑADAS
En un Sistema de Base de Datos relacional, la información se almacena en “tablas”.
Cada tabla contiene un conjunto de información asociada a un grupo de similar
entidad.
Una “columna” representa un tipo único de información acerca de la entidad
(atributo). Una “fila” es un conjunto de tipos de información que describe una entidad.
Generalmente, la tabla está compuesta de múltiples filas, que constituyen un conjunto
de entidades similares que son descritas de acuerdo con un criterio predefinido
Nombre Apellido Dirección
Existe una relación de conceptos entre la nomenclatura de almacenamiento de una
Base de Datos y el almacenamiento tradicional en ficheros, éste se podría establecer
de la siguiente manera
Tabla Fichero
Fila Registro
Columna Campo del Registro
Filas
Columnas
30
Crear una tabla de datos
Para crear una tabla de datos tenemos que posicionarnos en la ventana base de
datos con el objeto tablas seleccionado, si hacemos clic en el icono se abre
una ventana con las distintas formas que tenemos para crear una tabla:
• Vista Hoja de datos
consiste en introducir
directamente los datos
en la tabla y según el
valor que
introduzcamos en la
columna determinará
el tipo de datos que
tiene la columna.
• Vista diseño es el método que detallaremos en esta unidad didáctica
• Asistente para tablas utiliza un asistente que nos va guiando paso por paso
en la creación de la tabla utilizando un juego de tablas que tiene ya
predefinidas.
• Importar tabla consiste en crear una nueva tabla a partir de otra existente en
otra base de datos.
• Vincular tabla consiste en crear una referencia a otra tabla almacenada en
otra base de datos.
Explicaremos a continuación la forma de crear una tabla en vista diseño. Este
método consiste en definir la estructura de la tabla es decir definir las distintas
columnas que esta tendrá y otras consideraciones como claves etc. Otra forma más
rápida de llegar a la vista diseño es desde la ventana Base de datos con el objeto
tablas seleccionado, haciendo doble clic en la opción Crear una tabla en vista
Diseño.
31
Aparecerá la ventana Diseño de tabla:
En la barra de título tenemos el nombre de la tabla (como todavía no hemos
asignado un nombre a la tabla, Access le ha asignado un nombre por defecto Tabla1;
a continuación tenemos la rejilla donde definiremos las columnas que componen
la tabla, se utiliza una línea para cada columna, así en la primera línea (fila) de la
rejilla definiremos la primera columna de la tabla y así sucesivamente. En la parte
inferior tenemos a la izquierda dos fichas (General y Búsqueda) para definir
propiedades del campo es decir características adicionales de la columna que
estamos definiendo. Y a la derecha tenemos un recuadro con un texto que nos da
algún tipo de ayuda sobre lo que tenemos que hacer, por ejemplo en este momento
el cursor se encuentra en la primera fila de la rejilla en la columna Nombre del campo
y en el recuadro inferior derecho Access nos indica que el nombre de un campo
puede tener hasta 64 caracteres.
Vamos rellenando la rejilla definiendo cada una de las columnas que compondrá la
tabla:
32
Podemos definir un campo utilizando el generador de campos que permite definir
campos a partir de los de unas tablas ejemplo y que se activa pulsando el icono
de la barra de herramientas.
O bien podemos definir nosotros mismos los campos directamente como
explicaremos a continuación.
En la primera fila escribir el nombre del primer campo, al
pulsar la tecla INTRO pasamos al tipo de datos, por defecto
nos pone Texto como tipo de dato. Si queremos cambiar de
tipo de datos, hacer clic sobre la flecha de la lista desplegable
de la derecha y elegir otro tipo.
Observa cómo una vez tengamos algún tipo de dato en la segunda columna, la parte
inferior de la ventana, la correspondiente a Propiedades del campo se activa para
poder indicar más características del campo, características que veremos con detalle
en la unidad temática siguiente.
A continuación pulsar la tecla INTRO para ir a la tercera columna de la rejilla.
Esta tercera columna no es obligatorio utilizarla ya que únicamente sirve para
introducir un comentario, normalmente una descripción del campo de forma que la
33
persona que tenga que introducir datos en la tabla sepa qué debe escribir ya que este
cometario aparecerá en la barra de estado de la hoja de datos.
Repetir el proceso hasta completar la definición de todos los campos (columnas) de
la Tabla.
Tipos de datos
A la hora de crear un campo en una tabla, hay que especificar de qué tipo son los
datos que se van a almacenar en ese campo.
Los diferentes tipos de datos de Access2002 son:
• Texto: permite almacenar cualquier tipo de texto, tanto caracteres como
dígitos y caracteres especiales. Tiene una longitud por defecto de 50
caracteres, siendo su longitud máxima de 255 caracteres. Normalmente se
utiliza para almacenar datos como nombres, direcciones o cualquier número
que no se utilice en cálculos, como números de teléfono o códigos postales.
• Memo: se utiliza para textos de más de 255 caracteres como comentarios o
explicaciones. Tiene una longitud máxima de 65.536 caracteres. Access
recomienda para almacenar texto con formato o documentos largos, crear un
campo Objeto OLE en lugar de un campo Memo.
En Access2002 se puede ordenar o agrupar por un campo Memo, pero Access sólo
utiliza los 255 primeros caracteres cuando se ordena o agrupa en un campo Memo.
• Número: para datos numéricos utilizados en cálculos
matemáticos. Dentro del tipo número la propiedad tamaño del
campo nos permite concretar más. En resumen los tipos Byte,
Entero y Entero largo permiten almacenar números sin
decimales; los tipos Simple, Doble y Decimal permiten decimales; el tipo Id. de
réplica se utiliza para claves autonuméricas en bases réplicas.
• Fecha/Hora: para la introducción de fechas y horas desde el año 100 al año
9999.
34
• Moneda: para valores de dinero y datos numéricos utilizados en cálculos
matemáticos en los que estén implicados datos que contengan entre uno y cuatro
decimales. La precisión es de hasta 15 dígitos a la izquierda del separador
decimal y hasta 4 dígitos a la derecha del mismo.
Access recomienda utilizar el tipo Moneda para impedir el redondeo de cifras en
los cálculos. Un campo Moneda tiene una precisión de hasta 15 dígitos a la
izquierda de la coma decimal y 4 dígitos a la derecha. Un campo Moneda ocupa 8
bytes de espacio en disco.
• Autonumérico: número secuencial (incrementado de uno a uno) único, o
número aleatorio que Microsoft Access asigna cada vez que se agrega un nuevo
registro a una tabla. Los campos Autonumérico no se pueden actualizar.
• Sí/No: valores Sí y No, y campos que contengan uno de entre dos valores (Sí/No,
Verdadero/Falso o Activado/desactivado).
• Objeto OLE: objeto como por ejemplo una hoja de cálculo de Microsoft Excel, un
documento de Microsoft Word, gráficos, imágenes, sonidos u otros datos
binarios.
• Hipervínculo: texto o combinación de texto y números almacenada como texto y
utilizada como dirección de hipervínculo. Una dirección de hipervínculo puede
tener hasta tres partes:
Texto: el texto que aparece en el campo o control.
Dirección: ruta de acceso de un archivo o página.
Subdirección: posición dentro del archivo o página.
Sugerencia: el texto que aparece como información sobre herramientas.
• Existe otra posibilidad que es la Asistente para búsquedas... que crea un campo
que permite elegir un valor de otra tabla o de una lista de valores mediante un
cuadro de lista o un cuadro combinado. Al hacer clic en esta opción se inicia el
Asistente para búsquedas y al salir del Asistente, Microsoft Access establece el
tipo de datos basándose en los valores seleccionados
35
4.2. ASIGNAR LAS CLAVES PRINCIPALES A LAS TABLAS CREADAS
La clave principal
Antes de guardar la tabla tendremos que asignar una clave principal.
La clave principal proporciona un valor único para cada fila de la tabla y nos
sirve de identificador de registros de forma que con esta clave podamos saber sin
ningún tipo de equivocación el registro al cual identifica. No podemos definir más de
una clave principal, pero podemos tener una clave principal compuesta por más de
un campo.
Para asignar una clave principal a un campo, seguir los siguientes pasos: Hacer clic
sobre el nombre del campo que será clave principal.
Hacer clic sobre el icono Clave principal de la barra de herramientas.
A la izquierda del nombre del campo aparecerá una llave indicándonos que dicho
campo es la clave principal de la tabla.
Si queremos definir una clave principal compuesta (basada en varios campos),
seleccionar los campos pulsando simultáneamente la tecla Ctrl y el campo a
seleccionar y una vez seleccionados todos los campos hacer clic en el icono .
Importante: Recordar que un campo o combinación de campos que forman la clave
principal de una tabla no puede contener valores nulos y no pueden haber dos filas
en la tabla con el mismo valor en el campo/s clave principal.
Cuando intentemos insertar una nueva fila con valores que infrinjan estas dos reglas,
el sistema no nos deja crear la nueva fila y nos devuelve un error de este tipo:
36
4.3. ESTABLECER RELACIONES ENTRE LAS TABLAS CREADAS
Para este tema, las relaciones son importantes en su explicación por tanto se
presentan tres partes para su mejor comprensión, comenzamos con la parte número I:
LAS RELACIONES (I)
En esta unidad veremos cómo relacionar tablas y los diferentes tipos de relaciones
que pueden existir entre dos tablas de una base de datos.
Crear la primera relación.
Para crear relaciones en Access2002 primero deberemos acceder a la ventana
Relaciones, podemos optar por:
• estando en la ventana Base de datos, ir al menú
Herramientas, y elegir la opción Relaciones...
O bien
• Hacer clic sobre el botón de la barra de
herramientas.
Aparecerá el cuadro de diálogo Mostrar tabla de la derecha esperando indicarle las
tablas que formarán parte de la relación a crear.
Seleccionar una de las tablas que pertenecen a la relación haciendo clic sobre ella,
aparecerá dicha tabla remarcada.
Hacer clic sobre el botón Agregar.
Repetir los dos pasos anteriores hasta añadir todas las tablas de las relaciones a
crear.
Hacer clic sobre el botón Cerrar.
37
Ahora aparecerá la ventana Relaciones con las tablas añadidas en el paso anterior.
Para crear la relación:
Ir sobre el campo de relación de la tabla principal (en nuestro caso aulaclic_codigo).
Pulsar el botón izquierdo del ratón y manteniéndolo pulsado arrastrar hasta el
campo código de la tabla secundaria (Tabla1).
Soltar el botón del ratón.
Aparecerá el cuadro de diálogo Modificar relaciones siguientes:
En la parte superior deben estar los nombres de las dos tablas relacionadas (clientes
de aulaClic y tabla1) y debajo de éstos el nombre de los campos de relación
(aulaclic_codigo y código). ¡Ojo! siempre deben ser campos que contengan el mismo
tipo de información y por lo tanto del mismo tipo.
38
Observa en la parte inferior el Tipo de relación que se asignará dependiendo de las
características de los campos de relación (en nuestro caso uno a varios).
Activar el recuadro Exigir integridad referencial haciendo clic sobre éste.
Si se desea, se puede activar las casillas Actualizar en cascada los campos
relacionados y Eliminar en cascada los registros relacionados.
Para terminar, hacer clic sobre el botón Crear.
Se creará la relación y ésta aparecerá en la ventana Relaciones
LAS RELACIONES (II)
Añadir tablas a la ventana Relaciones.
Si ya hemos creado una relación y queremos crear otra pero no se dispone de la tabla
en la ventana Relaciones debemos añadir la tabla a la ventana:
Primero nos situamos en la ventana Relaciones haciendo clic sobre el icono de la
barra de herramientas.
Para añadir la tabla podemos elegir entre:
• hacer clic sobre el icono Mostrar tabla
o bien,
• del menú Relaciones elegir la opción Mostrar tabla
Aparecerá el cuadro de diálogo Mostrar tablas estudiado en el apartado
anterior.
Añadir las tablas necesarias.
Cerrar el cuadro de diálogo.
39
Quitar tablas de la ventana Relaciones.
Si queremos eliminar una tabla de la ventana Relaciones:
Primero nos situamos en la ventana Relaciones haciendo clic sobre el icono de la
barra de herramientas.
Después podemos elegir entre:
• hacer clic con el botón derecho sobre la tabla y elegir la
opción Ocultar tabla del menú contextual que aparecerá,
• hacer clic sobre la tabla para seleccionarla y del menú
Relaciones elegir la opción Ocultar tabla desaparecerá
de la ventana la tabla y todas las relaciones asociadas a ella.
Modificar relaciones.
Para modificar relaciones ya creadas:
Posicionarse en la ventana Relaciones y elegir entre estas dos
formas:
• hacer clic con el botón derecho sobre la relación a
modificar y elegir la opción Modificar relación... del menú contextual que
aparecerá,
o bien,
• hacer clic sobre la relación a modificar y elegir del menú
Relaciones la opción Modificar relación...
Se abrirá el cuadro de diálogo Modificar relaciones
estudiado anteriormente.
Realizar los cambios deseados.
Hacer clic sobre el botón Aceptar.
40
Eliminar relaciones.
Si lo que queremos es borrar la relación podemos:
• hacer clic con el botón derecho sobre la relación a borrar y elegir la opción
Eliminar del menú contextual, o bien,
• hacer clic sobre la relación a modificar y elegir del menú Edición la opción
Eliminar
• hacer clic con el botón izquierdo sobre la relación, la relación quedará
seleccionada, y a continuación pulsar la tecla Del.
La relación queda eliminada de la ventana y de la base de datos
LAS RELACIONES (III)
Limpiar la ventana relaciones
Cuando nuestra base de datos contiene muchas tablas y muchas relaciones, la
ventana Relaciones puede llegar a ser tan compleja que sea difícil interpretarla.
Podemos salvar esta dificultad limpiando la ventana y visualizando en ella
únicamente las tablas que nos interesen y sus relaciones. Para ello utilizaremos la
opción Borrar diseño y Mostrar relaciones directas que describiremos a
continuación.
Para limpiar la ventana Relaciones:
Posicionarse en la ventana Relaciones y elegir entre estas dos formas:
41
• elegir del menú Edición la opción Borrar diseño
o bien,
• hacer clic en el icono de la barra de herramientas.
Desaparecerán todas las tablas y todas las relaciones de la ventana Relaciones.
Desaparecen las relaciones de la ventana pero siguen existiendo en la base de datos,
únicamente hemos limpiado la ventana.
A partir de ese momento podemos ir añadiendo a la ventana las tablas que nos
interesan (con la opción Mostar tabla estudiada anteriormente) y las relaciones
definidas con esas tablas con la opción Mostrar directas que explicaremos a
continuación.
Mostrar relaciones directas
Esta opción nos permite visualizar en la ventana Relaciones todas las relaciones
basadas en una tabla determinada para ello:
Posicionarse en la ventana Relaciones y elegir entre:
• Hacer clic con el botón derecho sobre la tabla y elegir la
opción Mostrar directas del menú contextual que aparecerá,
• Hacer clic sobre la tabla para seleccionarla y elegir del menú
Relaciones la opción Mostrar directas
42
• hacer clic sobre la tabla para seleccionarla y hacer clic en el icono
Aparecerán todas las relaciones asociadas a la tabla y todas las tablas que
intervienen en estas relaciones.
Visualizar todas las relaciones
Si queremos visualizar en la ventana Relaciones todas las relaciones:
Posicionarse en la ventana Relaciones y elegir entre:
• hacer clic con el botón derecho sobre el fondo de la ventana y
elegir la opción Mostrar todo del menú contextual que
aparecerá,
• elegir del menú Relaciones la opción Mostrar todo
• hacer clic en el icono
Aparecerán todas las relaciones existentes en la base de datos y las tablas asociadas
43
CAPÍTULO V: VERIFICAR EL SISTEMA DE INFORMACIÓN
La verificación del sistema es muy importante, ya que en este descansa toda la
investigación y su buena terminación.
5.1. REALIZAR PRUEBAS AL SISTEMA DE INFORMACIÓN.
Es necesario comprobar que el sistema de información desarrollado funciona como es
debido, en definitiva se trata de ejecutar los programas para encontrar errores. Las
pruebas se consideran satisfactorias si no se encuentra algún error. Es el método más
habitual para determinar si el equipo lógico funciona como debe.
Otras actividades para asegurar que el equipo lógico funciona como debe son:
• El uso de una metodología de desarrollo.
• Revisiones formales e informales.
• Reuniones de revisión estructurada.
• Gestión de la configuración.
• Uso de las normas y estándares de desarrollo.
• Pruebas estáticas y dinámicas.
Realización de las pruebas
Las diferentes pruebas que deben realizarse se basan en realizar pruebas a diferentes
niveles, es necesario probar si cada unidad funciona, luego es necesario probar si los
distintos componentes encajan entre sí y por último es necesario probar el sistema
globalmente. Este proceso es algo bastante lógico, pues si por ejemplo sólo probamos
el sistema sería difícil encontrar determinados tipos de errores.
44
Principios básicos de pruebas.
Deben ser llevadas a cabo por personas distintas a los diseñadores de los programas,
así se puede verificar además del correcto funcionamiento del programa su correcta
concepción e interpretación
Diseño de juegos de prueba.
Existen dos tipos de prueba:
• Pruebas Tipo Caja Blanca. Permiten examinar la estructura interna del
programa.
• Pruebas De Tipo Caja Negra. Donde los casos de prueba se diseñan
considerando exclusivamente las entradas y salidas del sistema, sin
preocuparse por la estructura interna del mismo.
Pruebas de tipo caja blanca.
Para su desarrollo se selecciona un conjunto de caminos lógicos y se generan datos de
prueba, determinando los valores específicos que definen la ejecución de esos
caminos seleccionados.
• PRUEBA DE COBERTURAS DE SENTENCIAS
Consiste en generar casos de prueba que permitan probar cada sentencia
dentro de un módulo al menos una vez.
• PRUEBAS DE COBERTURA DE CONEXIÓN.
Consisten en diseñar casos de prueba que consideren todos los posibles
valores de cada una de las condiciones.
• COMPLEJIDAD CICLO MATICA.
A partir de los diagramas de flujo de programa se dibujan gráficos de programa
que contienen nodos que representan bloques de código y conexiones entre
ellos, mostrando de esta forma las ramas entre los bloques de código.
45
Pruebas de tipo caja negra.
En este caso se busca probar:
• Las funciones realizadas por el sistema
• El cumplimiento de los objetivos del sistema
• Las reacciones del sistema ante los estímulos exteriores
• Las transacciones manejadas por el sistema
Lo fundamental en este tipo de pruebas es encontrar el subconjunto de todas las
entradas posibles del programa, esto es muy complejo, para conseguirlo se siguen
diferentes criterios:
• Particiones de Equivalencia.
• Análisis de Valores límite.
• Valores típicos de error.
• Valores Imposibles.
Terminación De Las Pruebas. El objetivo de las pruebas consiste en encontrar
errores, pero si ya no se encuentran errores (no quiere esto decir que no los haya)
debe seguirse un criterio de terminación de las pruebas; el criterio puede ser:
• Cuando el tiempo de la prueba ha expirado.
• Cuando todos los casos de prueba se ejecutan sin error.
5.2. VALIDAR EL SISTEMA DE INFORMACIÓN
La validación se refiere al proceso por el cual los datos son filtrados y aceptados o
rechazados en base a procedimientos definidos. Es también el paso previo a su
entrega.
46
Puntos a considerar:
• Debe verificarse la exactitud de los datos críticos, independientemente de si
fueron ingresados a mano o transferidos electrónicamente.
• Los chequeos deben ser parte de procedimientos rutinarios para identificar
errores.
• Deben existir procedimientos estándar para definir datos sin procesar,
seguridad para la entrada de datos y revisión.
• Los resultados finales deben ser trazables a quien ingresó los datos o al
instrumento desde el cual se incorporaron automáticamente.
• Cualquier falla o evento inusual ocurrido con el instrumento debe registrarse
junto con los datos sin procesar. Debe evaluarse el impacto del error sobre los
datos y tomar las acciones necesarias.
• Si se realizan cambios en los datos, los mismos no deben ocultar los datos
originales. Debe identificarse la persona que los hizo y la causa.
• Los informes de datos cuantitativos deben incluir la incertidumbre de
medición.
• Los datos deben ser validados por personal calificado y autorizado siguiendo
un procedimiento operativo estándar.
Datos exactos
Para lograr tener datos exactos y sin ningún error, es necesario tener en cuenta lo
siguiente:
• Correcto funcionamiento del instrumento.
• Mantenimiento preventivo del mismo.
• Calibración periódica.
• Verificación de su funcionamiento
47
Antes de aprobar o rechazar:
Cuando estés a punto de aprobar los datos están correctos a la hora de capturarlos en
el sistema, se debe de tener cuidado lo siguiente:
• Correcta identificación de las muestras.
• Posibilidad de transmisión de errores.
• Plausibilidad.
• Consistencia.
Con esto se puede evitar muchos dolores de cabeza a la hora de entregar el sistema,
por ejemplo mediante: *Comparaciones con datos similares. *Chequeo de
plausibilidad de valores respecto de límites definidos. *Análisis de regresión. *Tests
de outliers.
Lo que debemos preguntarnos es: ¿Qué podemos detectar al validar los datos?, la
respuesta es: * Potenciales problemas en el análisis. *Eventos inusuales durante el
muestreo. *Errores en la transcripción de los datos. *Errores en la presentación de los
datos.
Ahora bien, ¿Cómo debes proceder cuando detectes un error o algún dato anómalo?
La respuesta está en: Si encuentras un error, busca una solución. Si encuentras datos
anómalos, por ningún motivo los elimines, mejor los señalo para decidir más adelante
si los incluyo o no en la evaluación.
Chequeo rutinario y procedimiento de revisión
Tener procedimiento operativo estandarizado.
48
Chequear que todo esté correctamente identificado: Ver si las unidades son correctas,
Ver si los datos corresponden al nombre de la columna y fila, Ver que todas las
variables estén identificadas.
Identificar eventos: Anotar cualquier actividad inusual en la planilla de muestreo. Esto
puede contribuir a explicar datos anómalos detectados, por ej. Utilizando gráficos del
tipo concentración vs fecha.
Anotar cualquier novedad relacionada con el muestreo, análisis, cambio de operador,
fallas en los equipos:
Controlar posibles errores de transcripción de datos.
5.3. IMPLANTAR EL SISTEMA DE INFORMACIÓN
La implantación es el punto final (de una manera) para entregar el sistema a su dueño
para que de esta manera comience a utilizar el sistema y aproveche al máximo el
software de base de datos que se entrega.
El criterio recomendado para este paso consiste en presentar a la persona (que nos
contrato para realizar el sistema) diagramas de flujo y tablas de decisión en donde se
delineen las especificaciones del nuevos sistema. Esta información incluye:
Información general acerca de la compañía, sus planes futuros de procesamiento, y
una lista de las especificaciones del nuevo sistema. Las particularidades que se
refieren a estas especificaciones serán cubiertas en las secciones subsecuentes.
Para clarificar se presenta una tabla donde se ve la etapa de este paso y su
descripción:
49
Cuadro De Implantación De Sistemas
Etapa Descripción
1.‐ Adiestramiento a
usuarios
Debe de ser a nivel de escuela; se debe llevar a cabo
usando los manuales e instructivos obtenidos del diseño
de sistemas.
2.‐ Prueba del sistema por
usuarios
Es la actividad que reafirma a cada uno de ellos lo que
aprendió en el adiestramiento. Es muy importante que
ellos produzcan los datos de prueba de acuerdo con el
plan de la misma.
3.‐ Aprobación de resultados
de la prueba
La aprobación de los resultados de la prueba la deberán
hacer los usuarios a la luz de los que su grupo de prueba
les reporte al finalizar el tiempo de prueba.
4.‐ Conversión al sistema Consiste en la implantación de los procedimientos
contenidos en los diferentes manuales e instructivos
obtenidos en el paso del diseño de sistemas.
5.‐ Liberación del sistema Consiste en la entrega formal del sistema al usuario por
parte de los comités de factibilidad y técnico.
5.4. REALIZAR MANTENIMIENTO AL SISTEMA DE INFORMACIÓN
Con posterioridad a la fase de implementación de los sistemas, se continúa con la fase
de mantenimiento. El mantenimiento de sistemas es el mejoramiento continuo
después del inicio del funcionamiento para no dejar caer el sistema.
Cuando se elaboran planes para crear un sistema de información, las organizaciones
no pueden dejar de considerar que el mantenimiento de sistemas es la fase más
prolongada y costosa del ciclo de vida de los sistemas.
50
Un sistema implantado en una organización es necesario el mantenimiento, por lo
tanto esta organización o empresa debe ser flexible para apoyar el mantenimiento de
los sistemas existentes.
Es importante considerar la evaluación y el monitoreo de un sistema en términos del
mantenimiento necesario y, en consecuencia, reducir o contener los costos implícitos.
El mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los
cuales repercute en el plan estratégico de información institucional de diferentes
maneras:
• Mantenimiento correctivo. Independientemente de cuán bien diseñado,
desarrollado y probado está un sistema o aplicación, ocurrirán errores
inevitablemente. Este tipo de mantenimiento se relaciona con la solución o la
corrección de problemas del sistema. Atañe generalmente a problemas no
identificados durante la fase de ejecución. Un ejemplo de mantenimiento
correctivo es la falta de una característica requerida por el usuario, o su
funcionamiento defectuoso.
• Mantenimiento para fines específicos. Este tipo de mantenimiento se refiere a la
creación de características nuevas o a la adaptación de las existentes según lo
requieren los cambios en la organización o los usuarios, por ejemplo, los
cambios en el código tributario o el reglamento internos de la organización.
• Mantenimiento para mejoras. Se trata de la extensión o el mejoramiento del
desempeño del sistema, ya sea mediante el agregado de nuevas características,
o el cambio de las existentes. Un ejemplo de este tipo de mantenimiento es la
conversión de los sistemas de texto a GUI (interfaz gráfica de usuarios).
• Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno
de los más eficaces en función de los costos, ya que si se realiza de manera
oportuna y adecuada, puede evitar serios problemas en el sistema. Un ejemplo
de este mantenimiento es la corrección del problema del año 2000.
51
CAPÍTULO VI: ELABORAR DOCUMENTOS DEL SISTEMA DE
INFORMACIÓN EN UN LENGUAJE DE PROGRAMACIÓN VISUAL
Un manual de procedimientos es el documento que contiene la descripción de
actividades que deben seguirse en la realización de las funciones de una unidad
administrativa, o de dos ó más de ellas.
El manual incluye además los puestos o unidades administrativas que intervienen
precisando su responsabilidad y participación.
Suelen contener información y ejemplos de formularios, autorizaciones o documentos
necesarios, máquinas o equipo de oficina a utilizar y cualquier otro dato que pueda
auxiliar al correcto desarrollo de las actividades dentro de la empresa.
En él se encuentra registrada y transmitida sin distorsión la información básica
referente al funcionamiento de todas las unidades administrativas, facilita las labores
de auditoría, la evaluación y control interno y su vigilancia, la conciencia en los
empleados y en sus jefes de que el trabajo se está realizando o no adecuadamente.
La utilidad permite conocer el funcionamiento interno por lo que respecta a
descripción de tareas, ubicación, requerimientos y a los puestos responsables de su
ejecución.
Auxilian en la inducción del puesto y al adiestramiento y capacitación del personal ya
que describen en forma detallada las actividades de cada puesto.
Sirve para el análisis o revisión de los procedimientos de un sistema.
Interviene en la consulta de todo el personal.
Que se desee emprender tareas de simplificación de trabajo como análisis de tiempos,
delegación de autoridad, etc.
52
Para establecer un sistema de información o bien modificar el ya existente.
Para uniformar y controlar el cumplimiento de las rutinas de trabajo y evitar su
alteración arbitraria.
Determina en forma más sencilla las responsabilidades por fallas o errores.
Facilita las labores de auditoría, evaluación del control interno y su evaluación.
Aumenta la eficiencia de los empleados, indicándoles lo que deben hacer y cómo
deben hacerlo.
Ayuda a la coordinación de actividades y evitar duplicidades.
Construye una base para el análisis posterior del trabajo y el mejoramiento de los
sistemas, procedimientos y métodos.
6.1. ELABORAR EL MANUAL DE 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:
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:
53
• 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. (en su caso)
B) Estructura del documento.
Por cada documento final deberá entregarse copias al personal involucrado en el
proyecto. 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.
Ahora bien, la Estructura del documento MANUAL TÉCNICO es el siguiente, aclarando
que no es necesariamente una imposición, sino una sugerencia para lograr entregar y
realizar un manual con éxito.
• Í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
54
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: Es conveniente aclarar que los manuales varían de
acuerdo a las necesidades de los usuarios y los programadores, por tanto la
siguiente lista no es la definitiva ni la única que se puede aplicar para elaborar
un manual técnico.
1. Definición de reglas del negocio implementadas en el sistema desarrollado.
2. Diagramas de flujo de datos, junto con su respectivo diccionario de datos.
3. Controles de auditoría implementados en el sistema.
4. Descripción de campos requeridos por pantalla con presentación de
pantallas.
5. Diagrama de navegación del sistema.
6. Requerimientos de interface con otros sistemas.
7. Modelo lógico de datos, diagrama entidad‐relación.
8. Modelo de datos físico, junto con su respectivo diccionario de datos.
9. Matriz de procesos versus organización.
10. Matriz de programas versus entidades.
11. 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).
12. Á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
55
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.
• Mapa de navegación. muestra de forma gráfica la interconexión entre cada
una de las pantallas del sistema, lo que serviría para saber cómo llegar a
determinada parte de la aplicación. En este se muestran los menús, submenús
y pantallas a las que nos lleva cada uno de ellos.
• Descripción gráfica del mapa de navegación. En el anterior aparece de
forma de diagrama de flujo y en esta sección deberá aparecer ya con las
respectivas pantallas.
• Describe paso a paso los procesos, así como pantallas, botones, cuadros de
texto, etc., pero también se muestra el código de cada rutina, pantalla, botón,
etc. es decir, se muestra lo que hay detrás de la interfaz del usuario
6.2. ELABORAR EL MANUAL DE USUARIO
Manual de Usuario: Esta parte se divide en dos manuales distintos, uno por cada
aplicación cliente. Se explicará todas las posibles opciones que puede realizar el
56
usuario con estas aplicaciones de manera detallada, y mediante el uso de capturas de
pantalla. Este documento está dirigido al usuario final.
Estructura del manual del usuario:
• Portada: ¿De qué se trata el documento y quien lo elaboro?
• Introducción: Describe el uso del documento (¿para qué sirve?) y ¿de qué
habla? Análisis y requerimientos del sistema (¿que se ocupa para poder
instalarlo y usarlo?)
• Explicación del funcionamiento: Debes de poner paso a paso y con pantallas
bien explicadas cómo funciona el programa
• Glosario
Recomendaciones finales:
• Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la
menor dificultad posible.
• Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar
el programa.
• 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.
57
REFERENCIAS BIBLIOGRÁFICAS
Barker, R. (1994).El modelo entidad‐relación Case*method. España: Díaz de santos
Barranco, J. (2002).Metodología del análisis estructurado de sistemas. (2ª edición).
Madrid: Universidad Pontificia de Comillas
Cassel, P. et al (2002). Aprendiendo Microsoft Access 2002 en 21 lecciones
avanzadas. USA: Pearson Educación.
Date, C. J., et. al (2001). Introducción a los sistemas de Base de datos. (7ª edición)
USA: Pearson Educación.
David W. Embley, Robert C. Goldstein (1977).Conceptual modeling ‐ ER '97. Los
Angeles: Springer.
Gonzalez, J (2005). Microsoft Access: Bases de datos/ databases. España: Pujol &
Amado S.L.L.
Julie, E . et al (2005). Análisis y diseño de sistemas (6ª edición) USA: Pearson
Educación.
Klein, A. (1999). Todo sobre Microsoft Access 2000. España: Marcombo.
Mohammed, B (2006).Análisis y diseño de sistemas discretos de control: Teoría y
problemas resueltos. España: Visión.
Peter, R & Coronel, C. (2004). Sistemas de bases de datos: Diseño, implementación y
administración. (5ª edición). USA:Cengage Learning Editores. (pág. 836)
Pressman, R et al (1988).Ingeniería del software. España: McGraw Hill.