CAPITULO 1. Marco de Referencia
CAPITULO 1. MARCO DE REFERENCIA. 1.1 MARCO TEÓRICO 1.1.1 DEFINICIÓN DE CONCEPTOS SOBRE SISTEMAS DE INFORMACIÓN 1.1.1.1 DEFINICIÓN DE SISTEMAS
En la actualidad la Teoría de Sistemas es utilizada como metodología en diversos ámbitos de negocios, en las ciencias naturales y otros. En el proyecto se empleará dicha metodología, por lo que es necesario mencionar los diferentes conceptos:
Al definir un Sistema deben identificarse los siguientes elementos: a)
Entradas: Son los insumos del sistema.
b)
Proceso: Conjunto de recursos y actividades que transforman las Entradas en salidas.
c)
Salida: Es el producto del sistema.
d)
Frontera: Es el limite del sistema.
e)
Medio ambiente: Es el entorno donde opera el sistema.
f)
Retroalimentación: Conjunto de estándares y procedimientos que Permiten el control del Sistema.
Procesamiento: Son los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el Sistema.
1.1.1.2 DEFINICIÓN DE TERMINOS IMPORTANTES EN EL ANALISIS DE SISTEMAS
En esta parte del documento se conceptúa los términos utilizados para el desarrollo del proyecto, y en el cual su definición es importante para un correcto entendimiento del mismo.
SISTEMA: 1
CAPITULO 1. Marco de Referencia Es un conjunto de componentes que
interaccionan entre sí para lograr un objetivo
común.
SISTEMA DE INFORMACIÓN: Es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa, desde la comunicación interna entre los diferentes componentes de la organización y líneas telefónicas hasta sistemas de computo que generan reportes periódicos para varios usuarios y que proporcionan servicio a todos los demás sistemas de una organización y enlazan todos sus componentes en forma tal que estos trabajen con eficiencia para alcanzar el mismo objetivo.
SISTEMAS ORGANIZACIONALES. En un sistema Organizacional, la finalidad es producir bienes o productos que satisfagan la demanda de un mercado, para alcanzar este objetivo los sistemas interactúan con su medio ambiente para definir los materiales necesarios.
Existen varios tipos de categorías de Sistemas de Información Organizacional: a)
Sistemas para el procesamiento de Transacciones. (TPS).
b)
Sistema de Información Administrativa. (MIS).
c)
Sistema para el Soporte de Decisiones. (DSS).
d)
Sistema de automatización de oficina (OAS).
e)
sistemas de trabajo de conocimiento (KWS).
f)
Sistemas expertos e inteligencia artificial (AI).
g)
Sistemas de apoyo a ejecutivos (ESS).
Sistemas para el procesamiento de Transacciones. (TPS): Tienen como finalidad mejorar las actividades rutinarias de una empresa y de las que depende toda la organización. Una Transacción es cualquier suceso o actividad que afecta a toda la Organización. Sistemas de Información Administrativa (MIS): Ayuda a los gerentes a tomar decisiones adecuadas y a resolver problemas de tipo administrativo. El sistema diseñado responde a esta clasificación, por las razones que se expondrán más adelante. 2
CAPITULO 1. Marco de Referencia
Sistema para el Soporte de Decisiones. (DSS): Ayudan a los Gerentes que deben tomar decisiones no muy estructuradas si no existen procedimientos claros.
Sistema de automatización de oficina y sistemas de manejo de conocimientos (OAS): Estos sistemas dan cabida al trabajo a nivel de conocimiento.
Sistemas expertos e inteligencia artificial (AI): Estos sistemas aplican la experiencia de los tomadores de decisiones para resolver problemas específicos estructurados. La meta de los sistemas expertos es la inteligencia artificial. La inteligencia artificial tiene su empuje en desarrollar máquinas que se comporten de forma inteligente.
Sistemas de apoyo a ejecutivos (ESS): Estos sistemas ayudan a los ejecutivos de las organizaciones a tomar decisiones a nivel estratégico.
Un factor clave en el uso de estos sistemas es determinar la información necesaria. En consecuencia, los sistemas para el soporte de decisiones deben tener una flexibilidad mayor que la de los demás sistemas de información. El usuario debe ser capaz de solicitar informes definiendo su contenido y especificando la forma para producir la información.
Aunque de diferente escritura los anteriores términos son uno mismo, lo que cambia es el nombre, ya que encierran un solo concepto y es un sistema de toma de decisiones a nivel organizacional, y que ayudará a dar solución a los problemas dentro de la misma, mediante la generación de reportes. Se puede decir entonces, que el Sistema a desarrollar en la presente investigación es un Sistema de Información Administrativa (MIS)1 por sus siglas en inglés, pues servirá para la toma de decisiones administrativas en los decanatos de la UFG, después de realizar las inspecciones de calidad en el aula.
1
ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN (James A. Senn) pp 25-29, 1992
3
CAPITULO 1. Marco de Referencia Considerando
el número
y complejidad de los elementos
y sus relaciones, y la
posibilidad de predecir su comportamiento, este sistema se clasifica como complejo y determinista.2 Complejo porque formará parte de un Macro Sistema
de la UFG y
determinista porque se sabe de antemano los resultados que producirá, como son los reportes, informes, etc.
Toda organización puede verse como un sistema, en el cual sus componentes trabajan juntos para alcanzar la misión de la misma. Estos componentes pueden ser tangibles como los productos, maquinarias, recurso humano y financiero e intangible como los datos e información que fluyen de un departamento a otro.3
La Teoría General de Sistemas aplicada al estudio de las organizaciones y a la Administración define un sistema como: “una organización compuesta por hombre y máquinas empeñadas en una actividad coordinada dirigida hacia una meta, enlazados mediante sistemas de información e influidos por el ambiente externo4”.
Sistema de Información puede definirse entonces, como el conjunto de datos y procedimientos cuyo fin es el de proporcionar a la Gerencia información técnica para el desempeño de sus funciones.5 Los procedimientos para el procesamiento de datos pueden realizarse de manera manual o con ayuda de software especial instalados en las computadoras.
Cuando en un sistema de información por computadora se hace uso de programas para el procesamiento de datos, se denomina Sistema de Información Automatizado.
Un sistema de información automatizado contiene los siguientes elementos: a. Software: Los programas de computadora, las estructuras de datos y la documentación asociada, que sirven para realizar el método lógico, procedimiento o control requerido. 2
Sistema de Administrativos ( René Serrano Nájera ) pp.30 1997 ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN (James A. Senn) pp.29. 1992 4 SISTEMAS ADMINISTRATIVOS (Rene Serrano Nájera) pp. 18, 1997 5 ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN (James A. Senn ) 1992 3
4
CAPITULO 1. Marco de Referencia b. Hardware: Elementos físicos de una computadora o sistema de cómputo, tales como dispositivos de entrada, procesamiento, almacenamiento, comunicación y salida. c. Usuario: Los individuos que son usuarios y operadores del software y del hardware. Es de considerar que usuario no solo es quien opera el software sino todo aquel que hace uso de la información generada del sistema. d. Documentación Interna y Externa: Son los manuales operativos, técnicos y de usuarios y de otra información descriptiva que explica el uso de la operación del sistema.
1.1.1.2.1
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.
El análisis y diseño de un sistema de información es desarrollado de mejor manera mediante el uso del “ciclo de vida del desarrollo de sistemas” (SDLC por sus siglas en Inglés)
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS: es un conjunto ordenado y sistemático de acciones cuyo fin es el de resolver los problemas de una empresa, por medio del desarrollo y el soporte de los sistemas de información resultantes.
A continuación se presentan los principales pasos del ciclo de vida de desarrollo de sistemas:
a)
Identificación de problemas, oportunidades y objetivos.
b)
Determinación de requerimientos de información.
c)
Análisis de las necesidades del sistema.
d)
Diseño del sistema recomendado.
e)
Desarrollo y documentación del software.
f)
Prueba y mantenimiento del sistema.
g)
Implementación y evaluación del sistema.
1.1.2
PARADIGMA A UTILIZAR EN EL DESARROLLO DEL SOFTWARE.
5
CAPITULO 1. Marco de Referencia Tomando en cuenta que el sistema para el control y seguimiento de las inspecciones de calidad en el aula a implementar en la universidad debe quedar su diseño totalmente documentado, se utilizará el paradigma del
Método de desarrollo por
Análisis
Estructurado. Casi la mayoría de especialistas en sistemas de información reconocen que sistemas grandes y complejos son difíciles de comprender de manera completa. Sin embargo, el método de desarrollo por análisis estructurado tiene la finalidad de superar esta dificultad por medio de 1) la división de sistemas en componentes y 2) la construcción de un modelo del sistema. En el análisis estructurado se especifica lo que se requiere que el sistema o aplicación haga, no así como se cumplirán los requerimientos o la forma de cómo implantar la aplicación. Mas bien permite que las personas observen los elementos lógicos ( lo que el sistema hará) separado de los componentes físicos como computadores, terminales, dispositivos de almacenamiento, etc. Los elementos esenciales del análisis estructurado son símbolos gráficos, diagramas de flujo de datos y diccionario centralizado de datos.
1.1.2.1
PROTOTIPOS.
Se refiere a un modelo que funciona para una aplicación de sistema de información determinado. El prototipo no posee todas las características de un sistema Final, mas bien incluye elementos suficientes para permitir a las personas utilizar el sistema propuesto para determinar que les gusta o no, para luego cambiarle o añadirle6.
CARACTERISTICAS DE UN PROTIPO:
1. Es una aplicación que funciona. 2. La finalidad del prototipo es probar varias suposiciones formuladas por analistas y usuarios con respecto a las características requeridas en el sistema. 3. Se crean con rapidez 4. Evoluciona a través de un proceso interactivo. 6
ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN (James A. Senn), Pag. 243
6
CAPITULO 1. Marco de Referencia 5. Tienen un costo bajo de desarrollo.
Con base al Método de desarrollo por análisis estructurado, se elaborará el “Prototipo de características seleccionadas”, pues es un modelo operacional que incluye algunas, pero no todas las características que tendrá el sistema final del
“Sistema de Control y
Seguimiento de las Inspecciones de Calidad en el Aula que realizan los Decanatos de la UFG”, pero que posteriormente puede ser retomado como base para darle la depuración necesaria.
1.1.3 DIAGRAMAS DE FLUJO DE DATOS. Los diagramas de flujos de datos también son llamados Carta de Burbujas, DFD, Diagramas de burbujas, modelo de proceso, diagrama de flujo de trabajo o modelo de función en la literatura computacional, y son parte del paradigma del método de desarrollo por análisis estructurado. A medida que la información se mueve a través del software, es modificada por una serie de transformaciones. El DFD es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.
1.1.3.1
COMPONENTES DE UN DFD.
El proceso.
Sinónimos comunes son burbuja, función o transformación. El proceso muestra una parte del sistema que transforma entradas en salidas; es decir, muestra cómo es que una o más entradas se transforman en salidas. El proceso se representa gráficamente como un óvalo o un rectángulo con esquinas redondeadas. Estas diferencias son sólo de forma, y se debe optar por alguna de ellas y utilizarla en forma consistente.
7
CAPITULO 1. Marco de Referencia
Fig. 1
Representaciones utilizadas para procesos, la de la izquierda corresponde a la utilizada por Gane y Sarson, y la de la derecha es utilizada por Ward y Mellor, así como por Yourdon y De Marco. Nótese que el proceso se nombra con una palabra o frase, que intentan dar una primera aproximación de lo que hacen, por ejemplo VALIDAR ENTRADA, CONTROL TEMPERATURA, etc.
El flujo.
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por ello, los flujos representan datos en movimiento, mientras que los almacenes representan datos en reposo.
Fig. 2
Flujo de Datos, que lleva la ruta de un cliente, almacén de datos, una entidad o un proceso. Se utiliza esta presentación en casi todos los formalismos propuestos. En la mayoría de los sistemas que se modelan, los flujos realmente representarán datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos otros tipos de información con los que se suele tratar en sistemas computarizados. Esto no significa que los DFD no sean una herramienta útil en el modelado de procesos no automatizados computacionalmente, como por ejemplo una línea de ensamblado.
8
CAPITULO 1. Marco de Referencia Fig. 3
Esta es la representación dada por Gane y Sarson7 a un flujo de materiales. Con esto, se representa que se ingresan datos o materiales de tipo no computacional. Es útil en el modelamiento de procesos productivos. Los flujos de datos tienen un nombre el que representa el significado del paquete de información que se mueve a lo largo del flujo. Los flujos de datos pueden converger o divergir en un DFD.
El almacén.
El almacén se utiliza para modelar un conjunto de paquetes de datos en reposo. Se denota por dos líneas paralelas u otras alternativas gráficas. De modo característico, el nombre que se usa para un almacén es el plural del que se usa para los paquetes que entran y salen del almacén por medio de flujos.
Fig. 4
Representaciones utilizadas para almacenes de datos, la de la izquierda corresponde a la utilizada por Gane y Sarson, y la de la derecha es utilizada por Ward y Mellor, así como por Yourdon y De Marco. A menudo, los almacenes de datos se implementan como archivos o bases de datos. También pueden ser implementados en sistemas manuales como archivadores, carpetas, etc.
El Terminador.
7
Análisis y Diseño de Sistemas de Información. James A. Senn, pag. 181, 182.
9
CAPITULO 1. Marco de Referencia Un terminador gráficamente se representa como un rectángulo. Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente un terminador es una persona o un grupo, por ejemplo una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, el terminador puede ser otro sistema.
Fig. 5
Terminador o "External", que en este caso representa al usuario del sistema. Se utiliza esta presentación en casi todos los formalismos propuestos. Suele ser muy fácil identificar los terminadores en el sistema que se está modelando. A veces el terminador es el usuario, que nos dice "pienso entregar los datos A, B y C al sistema y espero que éste me entregue los datos X, Y y Z". En otros casos, el usuario se considera parte del sistema y ayudará a identificar los terminadores relevantes.
1.1.3.2
GUÍA PARA LA CONSTRUCCIÓN DE UN DFD.
a. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores. b. Numerar los procesos. c. Redibujar el DFD tantas veces como sea necesario estéticamente. d. Evitar los DFD excesivamente complejos. e. Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualesquiera DFD relacionado con él. (evitar procesos con sólo entradas o salidas, así como flujos y procesos no etiquetados).
1.1.3.3
DFD POR NIVELES.
10
CAPITULO 1. Marco de Referencia Se organiza el DFD global en una serie de niveles de modo que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior. Esto es análogo a la organización de mapas en un atlas. El DFD de primer nivel consta sólo de una burbuja, que representa el sistema completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores externos (junto con los almacenes externos que pudiera haber). Este DFD especial se conoce como Diagrama de Contexto. El DFD que sigue del diagrama de Contexto se conoce como la figura 0. Representa la vista de más alto nivel de las principales funciones del sistema, al igual que sus principales interfaces.
Ejemplo de un diagrama de contexto.
Fig. 6
Diagrama nivel 0. Aquí se presenta la primera descomposición funcional del sistema.
11
CAPITULO 1. Marco de Referencia
Fig 7
Diagrama Nivel 1. En este caso se presenta una descomposición funcional del módulo 1. 12
CAPITULO 1. Marco de Referencia
Fig. 8
Diagrama nivel 2. En este caso se presenta una descomposición funcional del módulo 1.3 13
CAPITULO 1. Marco de Referencia
Fig 9
1.1.3.4 DICCIONARIO DE DATOS. La segunda herramienta de modelado importante, aunque no tiene la presencia y atractivo gráfico de los DFD, los diagramas Entidad-Relación o los diagramas de estructuras, es el diccionario de datos. El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de los almacenes y cálculos intermedios. El diccionario de datos define los datos haciendo lo siguiente: •
Describe el significado de los flujos y almacenes que se muestran en los DFD.
•
Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos, es decir, paquetes complejos que pueden descomponerse en unidades más elementales. 14
CAPITULO 1. Marco de Referencia •
Describen la composición de los paquetes de datos en los almacenes.
•
Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.
•
Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación u otro modelo de datos.
1.1.3.5 NOTACIÓN DEL DICCIONARIO DE DATOS. Existen muchos esquemas de notación comunes utilizados. Este es uno de los más utilizados. =: está compuesto de +:y ( ) :optativo (puede estar presente o ausente) { } : iteración [ ] : seleccionar una de varias alternativas * * : comentario @ : identificador (campo clave) para un almacén | : separa opciones alternativas en la construcción Por ejemplo, podemos definir nombre = título de cortesía + nombre + (segundo nombre) + apellido paterno + apellido materno título de cortesía = [Sr. | Srta. | Sra. | Dr. | Profesor ] nombre = {caracter legal} apellido paterno = {caracter legal} apellido materno = {caracter legal} 1.1.3.6 COMPLETITUD DEL DICCIONARIO DE DATOS.
15
CAPITULO 1. Marco de Referencia Para verificar varios detalles de corrección del sistema independientemente del usuario, el analista puede asegurarse que el diccionario esté completo y sea consistente y no contradictorio. Así, puede plantearse las siguientes preguntas: •
¿Se ha definido en el diccionario cada flujo del DFD?
•
¿Se han definido todos los componentes de los datos en el diccionario?
•
¿Se ha definido más de una vez algún dato?
•
¿Se ha utilizado la notación correcta para todas las definiciones del diccionario de datos?
•
¿Hay elementos de datos en el diccionario que no estén relacionados con el DFD u otros diagramas?
1.1.3.7
ESPECIFICACIONES DEL PROCESO.
La especificación del proceso es la descripción de qué es lo que sucede en cada burbuja primitiva en el nivel más bajo de un DFD. También es llamado Minispec o mini especificación. Su propósito es definir lo que debe hacerse para transformar entradas en salidas. La forma más utilizada para realizar las especificaciones de procesos es el lenguaje estructurado, pero se puede utilizar cualquier método que satisfaga dos requerimientos cruciales: •
La especificación del proceso debe expresarse de una manera que puedan verificarlo tanto el usuario como el analista. Precisamente por esta razón se evita el lenguaje narrativo como herramienta de especificación: es ambiguo, sobre todo si describe acciones alternativas y acciones repetitivas. Por naturaleza, también tiende a causar gran confusión cuando expresa condiciones booleanas compuestas (esto es combinaciones de los operadores AND, OR y NOT).
El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al usuario final que esté involucrado. A pesar de que el analista es típicamente quien escribe la especificación del proceso, habitualmente será un público bastante diverso de
16
CAPITULO 1. Marco de Referencia usuarios, administradores, auditores, personal de control de calidad y otros, el que leerá la especificación del proceso. 1.1.4 TEORIA DE BASES DE DATOS.
Una parte muy importante de las aplicaciones que se desarrollan actualmente hacen uso extensivo de las Bases de Datos (arquitecturas cliente/servidor, Servicios Web, etc.). Entender la arquitectura interna de una Base de Datos es una ayuda muy importante de cara al diseño y la construcción de Bases de Datos relacionales. Conocer la teoría nos permite realizar consultas más eficientes y detectar los problemas más rápidamente, así como elaborar una solución para los mismos.
Así que el desarrollo de la base de datos es un enfoque para transformar los requerimientos de información en una base de Datos Operacional. DEFINICIÓN. Una Base de Datos es un conjunto de informacion estructurada en registros y almacenada en un soporte electronico legible desde un computador. Cada registro constituye una unidad autonoma de informacion, que puede estar a su vez estructurada en diferentes campos o tipos de datos que se recogen en dicha Base de Datos.
1.1.4.1 •
CONCEPTOS BASICOS.
DATO: conocido tambien como campo y son los elementos individuales de los archivos
•
REGISTRO: Esta formado por un conjunto de datos pertenecientes a una entrada.
•
LLAVE: Se trata de un atributo o conjunto de atributos que idenifican de forma unica a todos los registros del archivo. Esta llave puede ser primaria (PK) cuando identifica de manera exclusiva a un registro
o secundaria (FK) cuando no
identifica de manera exclusiva un registro. Se puede dar el caso que exista algún 17
CAPITULO 1. Marco de Referencia identificador mas en la entidad, pero a estos identificadores se les denomina Identificadores Candidatos. •
ENTIDAD: Se puede definir como entidad a cualquier objeto, real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información.
•
ARCHIVO: Conjunto de registros relacionados.
•
RELACION: Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función.
Existen tres tipos de Relaciones:
a) Relacion de muchos a uno (M a 1 ó M:1) b) Relacion de muchos a muchos (M a M ó M:M) c) Relacion de uno a uno (1 a 1 ó 1:1). •
ATRIBUTOS: Las entidades se componen de atributos que son cada una de las propiedades o características que tienen. Los atributos describen la entidad para clasificar, identificar o expresar en estado de la misma.
1.1.4.2
MODELO ENTIDAD RELACIÓN
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. Los elementos básicos de una Base de Datos relacional son las tablas y las relaciones entre ellas. La forma de distribuir los datos y de establecer las relaciones queda fijada en el diseño.
18
CAPITULO 1. Marco de Referencia En los diagramas del modelo se dan las relaciones entre los datos de una tabla y otra, asi como
la forma como estos se comportan en una aplicación determinada. Los
analistas deben realizar el diseño adecuado para la interacción con las bases de datos y hacer la correcta elección de los métodos para organizarlos. Las relaciones entre entidades se describen por medio de su dependencia una de la otra, asi como por el alcance de la relación.
Existen dos tipos de dependencia entre entidades, la existencial y la de identificación. En la existencial una entidad no puede existir si la otra no esta presente. La existencia de una, depende de la existencia de la otra. Asi que si se eliminan registros de una tabla que tiene dependencia existencial con otra, los registros de la otra tabla tambien se eliminan. En la dependencia de identificación, una entidad no puede identificarse de manera única con sus propios atributos. Asi que la identificación se hace posible solamente a través de las relaciones de una entidad con otras.
1.1.4.2.1 NOTACIÓN PARA EL DIAGRAMA ENTIDAD RELACIÓN
El modelo Entidad Relación define todos los datos que se ingresan, se almacenan, se transforman y se generan en una aplicación. Estos elementos que se representan por medio de Entidades, que son cualquier objeto, real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información.
a)
ATRIBUTOS.
Los atributos de una entidad son la informacion que la describe y que se se necesita conocer. A continuacion se describen los diferentes tipos de atributos de una entidad:
Carácter: Es representada por la letra “C” o una letra A seguida de su longitud. Boolean: Representada por la letra “L”, asumiendo que son de un carácter . Memo: Se representan por las letras “TXT”.
19
CAPITULO 1. Marco de Referencia Numéricos:
Representados por la letra “N”, seguidos de su longitud, cuando se
especifica decimales, se coloca una coma seguido del numero de decimales. Hora: Representado por la letra “T”., longitud de 4 caracteres. Fecha: Representado por la letra “D”, longitud de 10 caracteres.
b)
CARDINALIDAD.
La cardinalidad se refierre al numero de entidades particulares con las que puede estar relacionada una entidad determinada. A continuación se muestran diferentes ejemplos de cardinalidad: •
UNO A MUCHOS.
Entidad B
Entidad A
Fig. 10
Indica que una clave de la entidad A posee varios elementos relacionados en la entidad B o que varios elementos de la entidad B, se relacionan solo con una clave de la entidad A. •
UNO A UNO. Entidad D
Entidad C Fig. 11
Indica que un elemento de la clave de la entidad C, se le asigna un único elemento de la entidad D y para cada elemento de la clave de entidad D contiene un único elemento en la entidad C.
20
CAPITULO 1. Marco de Referencia •
CARDINALIDAD NULA. RESTRICCIONES
Entidad B
Entidad A Fig. 12
Indica que una clave de la entidad A, posee cero, uno o varios elementos relacionados en la entidad B o que cero, una o varios elementos de la entidad B, se relacionan solo con una clave de la entidad A.
Entidad C
Entidad D Fig. 13
Indica que la clave de la entidad C posee cero o un elemento relacionado en la entidad D. El cero es el simbolo de restriccion de cardinalidad e indica que ese elemento de la entidad no queda asociado con el otro elemento de la otra entidad. A esto se le conoce como Asociaciones nulas. •
CARDINALIDAD DE MUCHOS A MUCHOS.
Entidad B
Entidad A
Fig.14
Una interrelación es de muchos a muchos entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A. Un caso muy característico de esta interrelación es la que surge entre las tablas docente y materias de un centro de estudios. Un docente puede impartir varias materias y una 21
CAPITULO 1. Marco de Referencia materia puede ser impartida por varios docentes a la vez, dentro de la misma institución. Esta interrelación la representamos como A:n, n:B. No se deben definir relaciones de este tipo en un sistema de bases de datos, debido a su complejidad a la hora de su mantenimiento, por este motivo se debe transformar este tipo de relación es dos interrelaciones de tipo 1: n, empleando para ello una tabla que denominaremos puente y que estará formada por las claves de ambas tablas. Esta tabla puente debe contener una única clave compuesta formada por los campos clave de las tablas primeras.
Entidad puente Claves de entidad A y B
Entidad A
Entidad B
Fig. 15
c) Llave.
El modelo entidad - relación exige que cada entidad tenga un identificador, se trata de un atributo o conjunto de atributos que identifican de forma única a cada uno de los ejemplares de la entidad. De tal forma que ningún par de ejemplares de la entidad puedan tener el mismo valor en ese identificador. Las llaves pueden ser de dos tipos: Primaria PK ( Primary Key ) por sus siglas en inglés y Foranea FK (Forain Key ) por sus siglas en inglés.
1.1.5
DESCRIPCIÓN
DE
INSTRUMENTOS
PARA
RECOLECCCIÓN
DE
INFORMACIÓN.
Dentro del Análisis de Sistemas Informáticos existen instrumentos o “técnicas para encontrar hechos”8, las cuales son las que nos ayudan a descubrir cuales son las posibles necesidades de los usuarios, aspectos importantes a tomar en cuenta dentro del
8
, ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN James A. Senn,
22
CAPITULO 1. Marco de Referencia mismo, así como las posibles mejoras para obtener un Sistema de alta calidad y conforme a todas las expectativas requeridas. A continuación se detallan y se conceptualizan cada una de ellas:
Entrevista:
El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organización. También vende el sistema durante la misma. Las entrevistas son diálogos de preguntas y respuestas planeados por anticipado entre dos persona. Las preguntas tienen dos tipos básicos: abiertas y cerradas. Las preguntas abiertas dejan abiertas todas las opciones de respuesta para el entrevistado. Las preguntas cerradas limitan las opciones posibles de respuesta. Las entrevistas pueden ser estructuradas en tres formas básicas, estructura de pirámide, de embudo o de rombo. Las estructuras piramidales comienzan con preguntas cerradas y detalladas y se amplían a preguntas más generales. Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas mas especificas. Las estructuras de rombo combinan las fuerzas de las otras dos estructuras, pero se llevan mas tiempo en realizarse9.
Esta es una de las herramientas que se utilizaron en la investigación de campo dentro del proyecto. La población a entrevistar es reducida, por lo tanto, la muestra es intencionada, es decir, que abarcó a todo el grupo que tienen interés en el proyecto, en este caso los decanos, coordinadores y directores de escuelas de las diferentes facultades de la universidad.
Cuestionarios:
Mediante el uso de cuestionarios, los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y características de personas importantes dentro de la organización. Los cuestionarios son útiles si: las personas de la organización están ampliamente dispersas, muchas gentes están involucradas con el proyecto de 9
ANÁLISIS Y DISEÑO DE SISTEMAS (. Kendall &. Kendall),
23
CAPITULO 1. Marco de Referencia sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay necesidad para la sensibilización del problema antes de que se realicen entrevistas10.
Observación:
Los analistas usan la observación como una técnica de recopilación de información. Por medio de la observación obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organización, comprenden la influencia del ambiente físico de éste, interpretan los mensajes enviados por el tomador por medio de su vestimenta y al acomodo de su oficina y comprenden la influencia del tomador de decisiones con respecto a los demás, el analista observa las actividades típicas del tomador de decisiones y su lenguaje corporal.
Además de la observación del comportamiento del tomador de decisiones, el analista de sistemas debe observar también lo que le rodea.
Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicación de la oficina, (2) la ubicación del escritorio del tomador de decisiones, (3) el equipo de oficina fijo, (4) las propiedades, tales como calculadoras y pantallas, (5) revistas del negocio y periódicos, (6) iluminación y color de la oficina y (7) la vestimenta usada por el mismo. 11
Revisión de Registros.
Varios tipos de registros y reportes pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. Al revisar sus registros, el analista examina la información asentada en ellos relacionada con el sistema y los usuarios. La revisión de registros puede efectuarse al comienzo del estudio, como introducción.
10
ANÁLISIS Y DISEÑO DE SISTEMAS ( Kendall & Kendall, )
11
ANÁLISIS Y DISEÑO DE SISTEMAS ( Kendall & Kendall )
24
CAPITULO 1. Marco de Referencia Los registros incluyen manuales de políticas, reglamentos y procedimientos estándares de operaciones utilizados por la mayor parte de las organizaciones como guías para los Gerentes y empleados. Estos pueden ser de gran ayuda para el analista en su afán de comprender el sistema.12 1.1.6 ESTÁNDARES DE CALIDAD ISO 9000. En los siguientes párrafos se define la familia de Normas ISO 9000 que servirá de base para el sistema a diseñar, que tendrá un enfoque hacia la mejora contínua.
Un sistema de garantía de calidad se puede definir como la estructura organizativa, responsabilidades, procedimientos, procesos y recursos para implementar gestión de calidad (ANS 87). ISO 9000 describe los elementos de garantía de calidad en términos genéricos que pueden aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.
Para identificarse con uno de los modelos de sistema de garantía de calidad de ISO 9000, el sistema de calidad y las operaciones de una empresa son examinados minuciosamente por auditores externos para ajustarlo a los estándares y a la operación efectiva. Después de un registro correcto, la empresa recibe un certificado avalado por los auditores.
Las auditorias de seguimiento cada seis meses aseguran el ajuste
continuo a los estándares.
La familia de normas ISO 9000 es un conjunto de reglas internacionales y guías de calidad que ha obtenido un reconocimiento mundial como base para establecer sistemas de gestión de la calidad. Presentan una visión global de las normas y demuestra cómo, colectivamente, forman la base para la mejora continua y la excelencia empresarial.
La Norma ISO 9001 se aplica cuando el objetivo es lograr de forma coherente la satisfacción del cliente con los productos y/o servicios que la organización ofrece; cuando 12
ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN (James A. Senn)
25
CAPITULO 1. Marco de Referencia se necesita demostrar la capacidad de solvencia
de los requerimientos
del mismo
logrando de esta manera la mejora continua del sistema de gestión de calidad.
La Norma ISO 9001 está organizada en un formato sencillo, con términos que son fácilmente reconocidos por todos los sectores de negocio para todos los grupos de productos, incluyendo los proveedores de servicios. La norma se utiliza para propósitos de certificación por las organizaciones que buscan el reconocimiento de su sistema de gestión de la calidad.
ISO 9001:2000 Sistemas de gestión de la calidad. Requisitos. Esta es la norma que se emplea para cumplir eficazmente los requisitos del cliente y los reglamentos aplicables, para conseguir la satisfacción del mismo.
La Norma ISO 9001:2000 se utiliza para establecer un sistema de gestión que proporcione confianza en la conformidad del producto, con requisitos previamente establecidos para luego ser certificado por una entidad externa.
1.1.6.1
MANTENIMIENTO DE LOS BENEFICIOS Y LA MEJORA CONTÍNUA.
La mayoría de los nuevos usuarios obtienen beneficios cuantificables muy pronto en el proceso de aplicación de los requisitos de la norma en sus operaciones. Estos beneficios iniciales son debidos generalmente a las mejoras en la organización y en la comunicación interna. Los beneficios tienen que acentuarse mediante una auditoría interna y una revisión por la dirección del desempeño del sistema eficaz. Como todos los sistemas, o mejora o pierde su eficacia; no permanece estático por mucho tiempo.
Cuando se adopta la Norma ISO 9001 debe esforzarse por satisfacer a los clientes y por mejorar continuamente el sistema de gestión de la calidad. La mejora continua es un proceso para incrementar la eficacia de la organización para cumplir con su política y objetivos de la calidad. La Norma requiere que se planifique y gestione los procesos necesarios para el control de calidad.
26
CAPITULO 1. Marco de Referencia En la figura 16, se muestra el esquema de búsqueda de la mejora contínua.
1.1.6.2
ESQUEMA DE BÚSQUEDA DE LA MEJORA CONTÍNUA13.
Fig. 16
1.1.7
ORGANIGRAMA FUNCIONAL DE LA UNIVERSIDAD FRANCISCO GAVIDIA.
A continuación, en la Fig. 17 se muestra el Organigrama funcional de la UFG14.
13 14
http://www.monografias.com/trabajos14/principios-deming/principios-deming.shtml http://www.ufg.edu.sv/institucional/organi.swf.
27
CAPITULO 1. Marco de Referencia 1.1.7.1 ORGANIGRAMA FUNCIONAL DE LA UFG.
CONSEJO DIRECTIVO CONSEJO ASESOR RECTORIA
ASISTENTE DE RECTORIA
AUDITORIA INTERNA
VICE RECTORIA
AUDITORIA EXTERNA
COMITÉ DE CALIDAD
SECRETARIA GENERAL
CONSEJO ACADEMICO ADMINISTRACION ACADEMICA CONSEJO DE DECANOS
FISCALIA
DIRECTOR DE CALIDAD
DIRECCION ADMINISTRATIVA
DECANATO FACULTAD DE CIENCIAS ECONOMICAS
DIRECCION ACADEMICA
DECANATO FACULTAD DE JURISPRUDENCIA Y CCSS
DIRECCION DE TEC. Y COMUNICACIONES
DECANATO FACULTAD DE ING. Y ARQUITECTURA
DIRECCION DE DESARROLLO ESTUDIANTIL
CENTRO REGIONAL DE OCCIDENTE Fig. 17
28
DIRECCION DE RECURSOS HUMANOS
DIRECCION FINANCIERA
CAPITULO 1. Marco de Referencia 1.1.7.2
MISIÓN
"La formación de profesionales competentes, con sentido ético, críticos y propositivos, utilizando recursos humanos, científicos y tecnológicos apropiados, para contribuir a impulsar los cambios que propicien el desarrollo sostenible del país y de la región."
1.1.7.3 VISIÓN
"Ser institución de educación superior plenamente acreditada por organismos nacionales e internacionales".
29
