Diseño de un sistema de información para la gerencia de desarrollo agropecuario de Guayana CVG (página 2)
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores.
JERARQUÍA DE GENERALIZACIÓN
Una entidad E es una generalización de un grupo de entidades EE… E si cada ocurrencia de cada una de esas entidades es también una ocurrencia de E. Todas las propiedades de la entidad genérica E son heredadas por las subentidades.
Cada jerarquía es total o parcial, y exclusiva o superpuesta. Una jerarquía es total si cada ocurrencia de la entidad genérica corresponde al menos con una ocurrencia de alguna subentidad. Es parcial si existe alguna ocurrencia de la entidad genérica que no corresponde con ninguna ocurrencia de ninguna subentidad. Una jerarquía es exclusiva si cada ocurrencia de la entidad genérica corresponde, como mucho, con una ocurrencia de una sola de las subentidades. Es superpuesta si existe alguna ocurrencia de la entidad genérica que corresponde a ocurrencias de dos o más subentidades diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad como subentidad. Un subconjunto siempre es una jerarquía parcial y exclusiva.
DISEÑO LÓGICO
El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones
Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos.
El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional.
Metodología de diseño lógico en el modelo relacional
La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.
Construcción de un diseño lógico.
Construir y validar los esquemas lógicos locales para cada vista de usuario.
Convertir los esquemas conceptuales locales en esquemas lógicos locales.
Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.
Validar cada esquema mediante la normalización.
Validar cada esquema frente a las transacciones del usuario.
Dibujar el diagrama entidad-relación.
Definir las restricciones de integridad.
Revisar cada esquema lógico local con el usuario correspondiente.
Construir y validar el esquema lógico global.
Mezclar los esquemas lógicos locales en un esquema lógico global.
Validar el esquema lógico global.
Estudiar el crecimiento futuro.
Dibujar el diagrama entidad-relación final.
Revisar el esquema lógico global con los usuarios.
En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario y se validan. En esta fase se refinan los esquemas conceptuales creados durante el diseño conceptual, eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el modelo que soporta el SGBD, en el caso que nos ocupa, el modelo relacional. Una vez hecho esto, se obtiene un primer esquema lógico que se valida mediante la normalización y frente a las transacciones que el sistema debe llevar a cabo, tal y como se refleja en las especificaciones de requisitos de usuario. El esquema lógico ya validado se puede utilizar como base para el desarrollo de prototipos. Una vez finalizada esta fase, se dispone de un esquema lógico para cada vista de usuario que es correcto, comprensible y sin ambigüedad.
3.2.1. CONVERTIR LOS ESQUEMAS CONCEPTUALES LOCALES EN ESQUEMAS LÓGICOS LOCALES.
En este paso, se eliminan de cada esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente:
(a)
Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una nueva entidad intermedia y dos relaciones de uno a muchos de esta nueva entidad con las entidades originales. La nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales.
(b)
Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de ellas por una nueva entidad (débil) intermedia que se relaciona con cada una de las entidades originales. La cardinalidad de estas nuevas relaciones binarias dependerá de su significado.
(c)
Eliminar las relaciones recursivas, sustituyendo cada una de ellas por una nueva entidad (débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La cardinalidad de estas relaciones dependerá de su significado.
(d)
Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales. La cardinalidad de estas relaciones dependerá del tipo de la relación original y de su significado.
(e)
Eliminar los atributos multievaluados, sustituyendo cada uno de ellos por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original.
(f)
Revisar las relaciones de uno a uno, ya que es posible que se hayan identificado dos entidades que representen el mismo objeto (sinónimos). Si así fuera, ambas entidades deben integrarse en una sola.
(g)
Eliminar las relaciones redundantes. Una relación es redundante cuando se puede obtener la misma información que ella aporta mediante otras relaciones. El hecho de que haya dos caminos diferentes entre dos entidades no implica que uno de los caminos corresponda a una relación redundante, eso dependerá del significado de cada relación.
Una vez finalizado este paso, es más correcto referirse a los esquemas conceptuales locales refinados como esquemas lógicos locales, ya que se adaptan al modelo de base de datos que soporta el SGBD escogido.
3.2.2. DERIVAR UN CONJUNTO DE RELACIONES (TABLAS) PARA CADA ESQUEMA LÓGICO LOCAL.
En este paso, se obtiene un conjunto de relaciones (tablas) para cada uno de los esquemas lógicos locales en donde se representen las entidades y relaciones entre entidades, que se describen en cada una de las vistas que los usuarios tienen de la empresa. Cada relación de la base de datos tendrá un nombre, y el nombre de sus atributos aparecerá, a continuación, entre paréntesis. El atributo o atributos que forman la clave primaria se subrayan. Las claves ajenas, mecanismo que se utiliza para representar las relaciones
entre entidades en el modelo relacional, se especifican aparte indicando la relación (tabla) a la que hacen referencia.
A continuación, se describe cómo las relaciones (tablas) del modelo relacional representan las entidades y relaciones que pueden aparecer en los esquemas lógicos.
(a)
Entidades fuertes. Crear una relación para cada entidad fuerte que incluya todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes.
Cada uno de los identificadores de la entidad será una clave candidata. De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas. Para escoger la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:
Escoger la clave candidata que tenga menos atributos.
Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro.
Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en el futuro.
Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto).
Escoger la clave candidata más fácil de utilizar desde el punto de vista de los usuarios.
(b)
Entidades débiles. Crear una relación para cada entidad débil incluyendo todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes. Añadir una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de la relación que representa a la entidad padre en la nueva relación creada para la entidad débil. A continuación, determinar la clave primaria de la nueva relación.
(c)
Relaciones binarias de uno a uno. Para cada relación binaria se incluyen los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. La entidad hijo es la que participa de forma total (obligatoria) en la relación, mientras que la entidad padre es la que participa de forma parcial (opcional). Si las dos entidades participan de forma total o parcial en la relación, la elección de padre e hijo es arbitraria. Además, en caso de que ambas entidades participen de forma total en la relación, se tiene la opción de integrar las dos entidades en una sola relación (tabla). Esto se suele hacer si una de las entidades no participa en ninguna otra relación.
(d)
Relaciones binarias de uno a muchos. Como en las relaciones de uno a uno, se incluyen los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre es la de “la parte del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es la de “la parte del uno'' (cada hijo tiene un solo padre).
(e)
Jerarquías de generalización. En las jerarquías, se denomina entidad padre a la entidad genérica y entidades hijo a las subentidades. Hay tres opciones distintas para representar las jerarquías. La elección de la más adecuada se hará en función de su tipo (total/parcial, exclusiva/superpuesta).
Crear una relación por cada entidad. Las relaciones de las entidades hijo heredan como clave primaria la de la entidad padre. Por lo tanto, la clave primaria de las entidades hijo es también una clave ajena al padre. Esta opción sirve para cualquier tipo de jerarquía, total o parcial y exclusiva o superpuesta.
Crear una relación por cada entidad hijo, heredando los atributos de la entidad padre. Esta opción sólo sirve para jerarquías totales y exclusivas.
Integrar todas las entidades en una relación, incluyendo en ella los atributos de la entidad padre, los atributos de todos los hijos y un atributo discriminativo para indicar el caso al cual pertenece la entidad en consideración. Esta opción sirve para cualquier tipo de jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo será multievaluado.
Una vez obtenidas las relaciones con sus atributos, claves primarias y claves ajenas, sólo queda actualizar el diccionario de datos con los nuevos atributos que se hayan identificado en este paso.
3.2.3. VALIDAR CADA ESQUEMA FRENTE A LAS TRANSACCIONES DEL USUARIO.
El objetivo de este paso es validar cada esquema lógico local para garantizar que puede soportar las transacciones requeridas por los correspondientes usuarios. Estas transacciones se encontrarán en las especificaciones de requisitos de usuario. Lo que se debe hacer es tratar de realizar las transacciones de forma manual utilizando el diagrama entidad-relación, el diccionario de datos y las conexiones que establecen las claves ajenas de las relaciones (tablas). Si todas las transacciones se pueden realizar, el esquema queda validado. Pero si alguna transacción no se puede realizar, seguramente será porque alguna entidad, relación o atributo no se ha incluido en el esquema.
3.2.4. DIBUJAR EL DIAGRAMA ENTIDAD-RELACIÓN.
En este momento, se puede dibujar el diagrama entidad-relación final para cada vista de usuario que recoja la representación lógica de los datos desde su punto de vista. Este diagrama habrá sido validado mediante la normalización y frente a las transacciones de los usuarios.
3.2.5. DEFINIR LAS RESTRICCIONES DE INTEGRIDAD.
Las restricciones de integridad son reglas que se quieren imponer para proteger la base de datos, de modo que no pueda llegar a un estado inconsistente. Hay cinco tipos de restricciones de integridad.
(a)
Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir, no admiten nulos.
(b)
Restricciones de dominios. Todos los atributos tienen un dominio asociado, que es el conjunto los valores que cada atributo puede tomar.
(c)
Integridad de entidades. El identificador de una entidad no puede ser nulo, por lo tanto, las claves primarias de las relaciones (tablas) no admiten nulos.
(d)
Integridad referencial. Una clave ajena enlaza cada tupla de la relación hijo con la tupla de la relación padre que tiene el mismo valor en su clave primaria. La integridad referencial dice que si una clave ajena tiene un valor (si es no nula), ese valor debe ser uno de los valores de la clave primaria a la que referencia. Hay varios aspectos a tener en cuenta sobre las claves ajenas para lograr que se cumpla la integridad referencial.
¿Admite nulos la clave ajena? Cada clave ajena expresa una relación. Si la participación de la entidad hijo en la relación es total, entonces la clave ajena no admite nulos; si es parcial, la clave ajena debe aceptar nulos.
¿Qué hacer cuando se quiere borrar una ocurrencia de la entidad padre que tiene algún hijo? O lo que es lo mismo, ¿qué hacer cuando se quiere borrar una tupla que está siendo referenciada por otra tupla a través de una clave ajena? Hay varias respuestas posibles:
Restringir: no se pueden borrar tuplas que están siendo referenciadas por otras tuplas.
Propagar: se borra la tupla deseada y se propaga el borrado a todas las tuplas que le hacen referencia.
Anular: se borra la tupla deseada y todas las referencias que tenía se ponen, automáticamente, a nulo (esta respuesta sólo es válida si la clave ajena acepta nulos).
Valor por defecto: se borra la tupla deseada y todas las referencias toman, automáticamente, el valor por defecto (esta respuesta sólo es válida si se ha especificado un valor por defecto para la clave ajena).
No comprobar: se borra la tupla deseada y no se hace nada para garantizar que se sigue cumpliendo la integridad referencial.
¿Qué hacer cuando se quiere modificar la clave primaria de una tupla que está siendo referenciada por otra tupla a través de una clave ajena? Las respuestas posibles son las mismas que en el caso anterior. Cuando se escoge propagar, se actualiza la clave primaria en la tupla deseada y se propaga el cambio a los valores de clave ajena que le hacían referencia.
(e)
Reglas de negocio. Cualquier operación que se realice sobre los datos debe cumplir las restricciones que impone el funcionamiento de la empresa.
Todas las restricciones de integridad establecidas en este paso se deben reflejar en el diccionario de datos para que puedan ser tenidas en cuenta durante la fase del diseño físico.
3.2.6. VALIDAR EL ESQUEMA LÓGICO GLOBAL
Este proceso de validación se realiza, de nuevo, mediante la normalización y mediante la prueba frente a las transacciones de los usuarios. Pero ahora sólo hay que normalizar las relaciones que hayan cambiado al mezclar los esquemas lógicos locales y sólo hay que probar las transacciones que requieran acceso a áreas que hayan sufrido algún cambio.
3.2.7. DIBUJAR EL DIAGRAMA ENTIDAD-RELACIÓN FINAL.
Una vez validado el esquema lógico global, ya se puede dibujar el diagrama entidad-relación que representa el modelo de los datos de la empresa que son de interés. La documentación que describe este modelo (incluyendo el esquema relacional y el diccionario de datos) se debe actualizar y completar.
DISEÑO FÍSICO.
El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones, pueden provocar una reestructuración del esquema lógico.
METODOLOGÍA DE DISEÑO FÍSICO PARA BASES DE DATOS RELACIONALES
El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
Traducir el esquema lógico global para el SGBD específico.
Diseñar las relaciones base para el SGBD específico.
Diseñar las reglas de negocio para el SGBD específico.
Diseñar la representación física.
Analizar las transacciones.
Escoger las organizaciones de ficheros.
Escoger los índices secundarios.
Considerar la introducción de redundancias controladas.
Estimar la necesidad de espacio en disco.
Diseñar los mecanismos de seguridad.
Diseñar las vistas de los usuarios.
Diseñar las reglas de acceso.
Monitorizar y afinar el sistema.
SUBSECCIONES
• Traducir el esquema lógico global
• Diseñar la representación física
• Diseñar los mecanismos de seguridad
• Monitorizar y afinar el sistema
TRADUCIR EL ESQUEMA LÓGICO GLOBAL
La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber:
Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas.
Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos).
Si el sistema soporta la definición de dominios.
Si el sistema soporta la definición de reglas de negocio.
Cómo se crean las relaciones base.
DISEÑAR LAS RELACIONES BASE PARA EL SGBD ESPECÍFICO
Las relaciones base se definen mediante el lenguaje de definición de datos del SGBD. Para ello, se utiliza la información producida durante el diseño lógico: el esquema lógico global y el diccionario de datos. El esquema lógico consta de un conjunto de relaciones y, para cada una de ellas, se tiene:
El nombre de la relación.
La lista de atributos entre paréntesis.
La clave primaria y las claves ajenas, si las tiene.
Las reglas de integridad de las claves ajenas.
En el diccionario de datos se describen los atributos y, para cada uno de ellos, se tiene:
Su dominio: tipo de datos, longitud y restricciones de dominio.
El valor por defecto, que es opcional.
Si admite nulos.
Si es derivado y, en caso de serlo, cómo se calcula su valor.
Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo "a las 20:30 del último día laborable de cada año archivar los inmuebles vendidos y borrarlos'. Para estas restricciones habrá que escribir programas de aplicación específicos. Por otro lado, hay SGBD que no permiten la definición de restricciones, por lo que éstas deberán incluirse en los programas de aplicación.
Todas las restricciones que se definan deben estar documentadas. Si hay varias opciones posibles para implementarlas, hay que explicar porqué se ha escogido la opción implementada.
DISEÑAR LA REPRESENTACIÓN FÍSICA
Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta:
Productividad de transacciones. Es el número de transacciones que se quiere procesar en un intervalo de tiempo.
Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el punto de vista del usuario, este tiempo debería ser el mínimo posible.
Espacio en disco. Es la cantidad de espacio en disco que hace falta para los ficheros de la base de datos. Normalmente, el diseñador querrá minimizar este espacio.
Lo que suele suceder, es que todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir monitorizándolo para observar sus prestaciones e ir ajustándolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorizar y afinar el sistema.
Hay algunas estructuras de almacenamiento que son muy eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dicha estructura de almacenamiento para inicializar la base de datos y cambiarla, a continuación, para su posterior operación. Los tipos de organizaciones de ficheros disponibles varían en cada SGBD. Algunos sistemas proporcionan más estructuras de almacenamiento que otros. Es muy importante que el diseñador del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utiliza.
Para mejorar las prestaciones, el diseñador del esquema físico debe saber cómo interactúan los dispositivos involucrados y cómo esto afecta a las prestaciones:
Memoria principal: Los accesos a memoria principal son mucho más rápidos que los accesos a memoria secundaria (decenas o centenas de miles de veces más rápidos). Generalmente, cuanta más memoria principal se tenga, más rápidas serán las aplicaciones. Sin embargo, es aconsejable tener al menos un 5% de la memoria disponible, pero no más de un 10%. Si no hay bastante memoria disponible para todos los procesos, el sistema operativo debe transferir páginas a disco para liberar memoria (paging). Cuando estas páginas se vuelven a necesitar, hay que volver a traerlas desde el disco (faltas de página). A veces, es necesario llevar procesos enteros a disco (swapping) para liberar memoria. El hacer estas transferencias con demasiada frecuencia empeora las prestaciones.
CPU: La CPU controla los recursos del sistema y ejecuta los procesos de usuario. El principal objetivo con este dispositivo es lograr que no haya bloqueos de procesos para conseguirla. Si el sistema operativo, o los procesos de los usuarios, hacen muchas demandas de CPU, ésta se convierte en un cuello de botella. Esto suele ocurrir cuando hay muchas faltas de página o se realiza mucho swapping.
Entrada/salida a disco: Los discos tienen una velocidad de entrada/salida. Cuando se requieren datos a una velocidad mayor que ésta, el disco se convierte en un cuello de botella. Dependiendo de cómo se organicen los datos en el disco, se conseguirá reducir la probabilidad de empeorar las prestaciones. Los principios básicos que se deberían seguir para repartir los datos en los discos son los siguientes:
Los ficheros del sistema operativo deben estar separados de los ficheros de la base de datos.
Los ficheros de datos deben estar separados de los ficheros de índices
Los ficheros con los diarios de operaciones deben estar separados del resto de los ficheros de la base de datos.
Red. La red se convierte en un cuello de botella cuando tiene mucho tráfico y cuando hay muchas colisiones.
Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos puede provocar mejoras en otros.
ESCOGER LAS ORGANIZACIONES DE FICHEROS
El objetivo de este paso es escoger la organización de ficheros óptima para cada relación. Por ejemplo, un fichero desordenado es una buena estructura cuando se va a cargar gran cantidad de datos en una relación al inicializarla, cuando la relación tiene pocas tuplas, también cuando en cada acceso se deben obtener todas las tuplas de la relación, o cuando la relación tiene una estructura de acceso adicional, como puede ser un índice. Por otra parte, los ficheros dispersos (hashing) son apropiados cuando se accede a las tuplas a través de los valores exactos de alguno de sus campos (condición de igualdad en el WHERE). Si la condición de búsqueda es distinta de la igualdad (búsqueda por rango, por patrón, etc.), la dispersión no es una buena opción. Hay otras organizaciones, como la ISAM o los árboles B+.
Las organizaciones de ficheros elegidas deben documentarse, justificando en cada caso la opción escogida.
ESTIMAR LA NECESIDAD DE ESPACIO EN DISCO
En caso de que se tenga que adquirir nuevo equipamiento informático, el diseñador debe estimar el espacio necesario en disco para la base de datos. Esta estimación depende del SGBD que se vaya a utilizar y del hardware. En general, se debe estimar el número de tuplas de cada relación y su tamaño. También se debe estimar el factor de crecimiento de cada relación.
DISEÑAR LOS MECANISMOS DE SEGURIDAD
Los datos constituyen un recurso esencial para la empresa, por lo tanto su seguridad es de vital importancia. Durante el diseño lógico se habrán especificado los requerimientos en cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta implementación, el diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya a utilizar.
DISEÑAR LAS VISTAS DE LOS USUARIOS
El objetivo de este paso es diseñar las vistas de los usuarios correspondientes a los esquemas lógicos locales. Las vistas, además de preservar la seguridad, mejoran la independencia de datos, reducen la complejidad y permiten que los usuarios vean los datos en el formato deseado.
DISEÑAR LAS REGLAS DE ACCESO
El administrador de la base de datos asigna a cada usuario un identificador que tendrá una palabra secreta asociada por motivos de seguridad. Para cada usuario o grupo de usuarios se otorgarán permisos para realizar determinadas acciones sobre determinados objetos de la base de datos. Por ejemplo, los usuarios de un determinado grupo pueden tener permiso para consultar los datos de una relación base concreta y no tener permiso para actualizarlos.
MONITORIZAR Y AFINAR EL SISTEMA
Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para observar sus prestaciones. Si éstas no son las deseadas, el esquema deberá cambiar para intentar satisfacerlas. Una vez afinado el esquema, no permanecerá estático, ya que tendrá que ir cambiando conforme lo requieran los nuevos requisitos de los usuarios. Los SGBD proporcionan herramientas para monitorizar el sistema mientras está en funcionamiento.
BASES ESTRUCTURALES DE LOS SISTEMAS COMPUTARIZADOS.
Adaptado exactamente a las especificaciones del cliente:
Los Sistemas Computarizados son "SOFTWARE HECHO A LA MEDIDA" adaptado a cada proceso de acuerdo a las especificaciones del cliente, lo cual resulta una ventaja determinante sobre los "paquetes" estándar para los cuales la empresa debe hacer modificaciones para ajustarse a sus entradas y salidas.
2. Dirigidos hacia la toma de decisiones en áreas funcionales:
Los Sistemas Computarizados están dirigidos a proveer información acerca de actividades funcionales generalmente no cubiertas por los esfuerzos de sistematización en las empresas, tales como producción, control de calidad, mantenimiento, utilización de equipos, logística, transporte, distribución, ventas, administración y recurso humanos, generando estadística e informe relativos a la gestión en cada caso.
3. Modulares e Interactivos:
La altísima ínter-relación existente entre las diversas actividades en la empresa impone la necesidad de integrar las diversas gestiones a través de recursos comunes y compartidos, mediante lo cual se logra además un mayor grado de efectividad en el manejo de la información. En este sentido los MIP logran un alto grado de interacción debido a que todos pueden entrelazarse entre sí.
4. Computadores Personales, Procesamiento Distribuido e Integración:
A pesar de no ser limitativo los Sistemas Computarizados operan dentro de un esquema de Procesamiento Distribuido, con Computadores Personales (PC) como Terminales Inteligentes del sistema de computación existente en la empresa con equipos "mini", o Mainframe con los MIP actuando como mecanismo de captura de datos, toda vez que parten de la alimentación diaria de los documentos y registros básicos tanto en el área operacional como comercial de la empresa los cuales son posteriormente transferido a través de una emulación al computador central, eliminando la necesidad de transcripción y procesamiento previo a su ingreso al sistema de contabilidad.
5. Enfocado hacia a los usuarios:
Los Sistemas Computarizados están dirigidos a proveer un mecanismo de evaluación y control de la gestión en cada una de Jas áreas funcionales de la empresa, más aun, han sido diseñado para fácil instalación y aprovechamiento máximo, toda vez que son adaptado exactamente a las operaciones y procedimientos existentes, por lo tanto permitiendo su implementación en forma sencilla.
6. Reducción de costos indirectos vía eliminación de transacciones:
Los gastos indirectos representan sin duda uno de los rubros de mayor importancia dentro del comportamiento de los costos en toda empresa. Dichos gastos están a su vez influenciados por los procedimientos existentes, por lo tanto, una alta cantidad de transacciones y procedimiento manual de datos acarrea consigo un altísimo costo, el cual es eliminado automáticamente con la implantación de los Sistemas Computarizados. Cada Sistemas Computarizados es perfectamente justificable desde un punto de vista de costo/beneficio basado estrictamente en el costo de su instalación Vs. los ahorros incurrido como resultado de dicha instalación, a corto plazo.
BENEFICIOS PROVENIENTES DE LA INSTALACIÓN DE LOS SISTEMAS COMPUTARIZADOS
1. Sustanciales ahorros netos de costos a corto plazo:
La sistematización de cualquier actividad vía Sistemas Computarizados representa un ahorro inmediato de costos, mediante la reducción de horas – hombre, formatos, tiempo, etc., necesarios para la recolección, procesamiento, reparación y trascripción de datos, necesarios para generar la información que es utilizada en la toma de decisiones. De hecho rara vez el tiempo de recuperación de la inversión en los Sistemas Computarizados excede los tres (3) meses.
2. Incremento de la productiva:
Como fuera mencionado en el punto anterior, la disminución de horas-hombre en el manejo de datos implica menores costos, y una mayor productividad, particularmente de la mano de obra indirecta a muy corto plazo. No obstante, quizás el impacto de mayor relevancia sobre la productividad total de la empresa sea el hecho de que permite la generación oportuna de información con respecto a los procesos, facilitando así mismo la toma de acciones rápidas referentes a la utilización de materia primas, equipos, mano de obra, decisiones operacionales, etc., evitando la toma de decisión basada en "Información del mes pasado", o simplemente basadas en "la nariz de quien tiene el problema".
3. Gastos de personal Vs inversión en recursos humanos:
Como fuera antes mencionado el empleo de personal para la realización de actividades repetitivas y monótonas, en las cuales el uso de su intelecto esta reducido a cero, conlleva no solo a la sub – utilización de un valioso talento, sino además hace más costoso los procesos, implicando, generalmente la generación de cargos superfluos y caros, lo cual disminuye la rentabilidad y competitividad de nuestras empresas. Por otro lado, el personal dedicado a estas tareas rara vez muestra motivación a ser su trabajo, toda vez que se ve "castrado" de la posibilidad de emplear su creatividad y conocimiento en la labor que desempeña independientemente de su nivel educativo y cultural, lo cual podría ser corroborado por cualquier libro de psicología elemental. Sin embargo, quizás lo más grave de esta situación sea el hecho de que muchas de nuestras empresas involucra personal de nivel, el cual dedica gran cantidad de su valioso tiempo a la preparación de informes y reportes.
4. Óptimo aprovechamiento de la infraestructura de computación existente:
Mediante un uso más racional del computador central a través del procesamiento distribuido, se logra la satisfacción de necesidades sin que este conlleve a una degradación de los sistemas, la desmejoría de los tiempos de respuestas, etc., toda vez por el contrario dicha operatividad se ve mejorada mediante el procesamiento local y la interacción eventual y no constante.
5. Mayor precisión en la información:
La detección de errores es llevada a cabo mediante mecanismos de seguridad de cada Sistemas Computarizados tiene incluido como parte de su diseño, evitando por lo tanto la "transcripción de basura que necesariamente va generar basura". Como resultado de la eliminación de transcripciones, la posibilidad de errores e imprecisión se ve notablemente disminuida. Los datos son alimentados una sola vez, en forma precisa, y de allí quedan disponibles para ser utilizados por el resto de la empresa.
RAZONES PARA IMPLANTAR UN SISTEMA DE INFORMACIÓN
Existen las siguientes razones para implantar un Sistema de Información:
Capacidad
• Mayor velocidad de procesamiento: El sistema de Información permitirá realizar operaciones tales como: cálculos, ordenamientos, recuperación y ejecuciones repetidas de la misma tarea con mayor velocidad que los seres humanos.
• Incremento en el volumen: El Sistema de Información tendrá la capacidad de procesar una gran cantidad de transacciones a medida que crezcan los .flujos de información en la organización.
• Recuperación más rápida de la información: El Sistema de Información, permitirá la localización de la información desde el sitio donde se encuentran almacenada.
Control
• Mayor exactitud y mejora en la consistencia: Permitirá además, llevar a cabo los procesos de cómputos, incluidos los aritméticos, de manera correcta y simple en la misma forma salvaguardar datos importantes y sensibles en una forma accesible solo de personal autorizado.
• Comunicación: El Sistema de Información permitirá mejorar y acelerar el flujo de información entre localidades remotas, así .como dentro de las oficinas. Una de las actividades principales del Departamento de Mantenimiento es la de conservar y mejorar el flujo de información entre sus diferentes secciones. Este mecanismo le permite mantener y mejorar su rendimiento y eficiencia ante los requerimientos del Departamento de Producción ofreciéndole alta disponibilidad de equipos.
METODOLOGÍA PARA DESARROLLO DE SISTEMAS DE INFORMACIÓN
Para el desarrollo de Sistemas de Información, se toman en consideración diferentes enfoques, que permiten abordar la situación problema. Dentro de los más utilizados se pueden presentar los siguientes:
• MEDSI (Metodología Estructurada para el Desarrollo de Sistemas de Información).
• Método de Desarrollo Estructurado (Metodología Estructurada)
• Prototipos.
MEDSI es una Metodología Estructurada para el Desarrollo de Sistemas de Información en y para organizaciones de cualquier tipo.
Entre las características resaltantes de esta metodología podemos señalar las siguientes:
Es estructurada: Esta característica se debe a dos razones esenciales: a) Utiliza diferentes métodos y técnicas estructuradas, que son propias de la ingeniería de programación y que han demostrado ser las más eficientes y eficaces para el desarrollo de sistemas programados.
b) Guía paso a paso – de arriba hacia abajo – al grupo que las aplica; explicando primero, de forma muy general, lo que debe hacerse, para luego entrar en los detalles, a medida que se avanza, hasta explicar las tareas esenciales que el grupo debe llevar a cabo para desarrollar un sistema de información.
Es completa: Cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización. Guía ai grupo de desarrollo, a través de las fases, a un nivel bastante detallado; explicando las actividades que deben hacerse y en la mayoría de los casos, enumerando las tareas específicas que los miembros del grupo deben efectuar.
Es particionada: A fin de manipular mejor la complejidad inherente a un proyecto de este tipo, la metodología se divide en fases. Cada una de estas fases se divide en pasos, los cuales están orientados a algún tipo de tópico, aspecto o elemento de del sistema de información. Cada paso a-su vez, agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo. Donde así requiera,
las actividades descomponen en tareas específicas, las cuales deben ser ejecutadas por un miembro o sub-grupo en un plazo o período de tiempo relativamente corto. (Para proyectos grandes: entre 1 y 2 semanas, generalmente).
Las fases y pasos se orientan a mostrar que debe hacer el grupo de desarrollo, mientras que las actividades y tareas, o bien, detallan lo que debe hacerse, o muestra como hacerse mediante la aplicación de alguna técnica.
Es modificable y adaptable: El grupo de desarrollo puede modificar fácilmente la metodología, bien para introducir nuevos elementos como para eliminar algunos. De igual modo, puede adaptarla a las condiciones, exigencias y características de la organización donde se utilice o a cualquier tipo de proyecto de sistema de información.
El ciclo de vida del desarrollo de sistemas es un enfoque por fase del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo específico de actividad del analista y del usuario.
El ciclo de vida del desarrollo de sistemas normalmente incluye las siguientes fases:
A. Definición del Proyecto
B. Análisis de las Necesidades del Sistema
C. Conversión e Implantación
D. Diseño del Sistema Recomendado
E. Diseño Detallado
F. Programación del Sistema
G. Prueba del Sistema
A. Definición del Proyecto: El definir un proyecto de sistemas de información consiste en justificar el desarrollo de un nuevo sistema de información, estableciendo factibilidad posible de realización y de ser posibles su planificación, desarrollo e implantación.
Esta primera fase abarca los siguientes puntos:
Estudio Preliminar: Para iniciar el desarrollo de un sistema de información, y tener una visión preliminar del trabajo a desarrollar se deben realizar entrevistas y observaciones directas del sistema actual bajo estudio, para ello se utilizan herramientas tales como las técnicas de las entrevistas, cuestionarios y observaciones directas.
Estudio de Factibilidad: El estudio de factibilidad comienza con el estudio de los problemas que la gerencia de un departamento encuentra para operar con los sistemas actuales o para afrontar nuevas necesidades administrativa de la empresa. Sea cual sea el origen de los problemas o requerimientos, el estudio de factibilidad tiene como objetivo determinar si es posible ofrecer una solución automatizada a dichos problemas. Para ello, durante esta etapa inicial se debe tener presente:
Revisar y analizar los nuevos requerimientos.
Determinar si es posible establecer nuevos procedimientos y adoptar nuevos y mejores métodos para cumplir en forma más eficaz las actividades de la función.
Determinar si la inversión que implicará la implantación de esa forma más eficaz está justificación con relación a los beneficios que adoptará.
Delinear los parámetros que gobernarán y delimitarán el proyecto de desarrollo de esa solución.
Identificación de Problemas, Oportunidades y Objetivos: En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificación de problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del sistema a desarrollar, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. Esta fase requiere de observaciones honesta de lo que esta sucediendo en el negocio.
Las oportunidades son situaciones que el analista considera que pueden ser mejoradas por medio del uso de sistemas de información computarizados. Él aprovecha las oportunidades pueden permitir que el negocio gane un avance competitivo o ponga un estándar de la industria.
La identificación de objetivos es también un componente importante en la primera fase. En primer lugar, el analista debe descubrir lo que está tratando de hacer el negocio, luego será capaz de ver si algún aspecto de aplicación de sistemas de información puede ayudar para que el negocio alcance sus objetivos atacando problemas específicos u oportunidades.
Determinación de los requerimientos de información: La siguiente fase a la que entra el analista es la determinación de los requerimientos de información para los usuarios particulares involucrados. En esta fase el analista se esfuerza por comprender qué información necesita el usuario para realizar su trabajo. El analista de sistemas saber los detalles de las funciones actuales del sistemas necesita saber los detalles de las funciones actuales del sistema bajo estudio, esto lo realiza a través de las siguientes interrogantes: quién, dónde, cuándo y cómo.
Factibilidad Técnica: El analista debe encontrar si los recursos técnicos actuales pueden ser mejorados o añadidos, en forma tal que satisfaga la petición bajo consideración, esto con el objetivo de determinar el tipo y condición de los equipos hardware que se requerirá para el desarrollo y la implantación.
Factibilidad Económica: la factibilidad económica considera los recursos básicos de tiempo propio y del equipo de sistemas, el costo de hacer un estudio de sistema completo, el costo del tiempo de los empleados de negocio, el costo estimado del hardware y el costo estimado del software y/o desarrollo de software.
Factibilidad Operacional: La factibilidad operacional del proyecto depende de los recursos humanos disponibles para el proyecto, e involucra proyectar si el sistema operará y será usado una vez que éste instalado.
Si los usuarios están cansados virtualmente con el sistema presente, no ven problemas con él y, por lo general no está involucrado en la petición de un nuevo sistema, la resistencia ante la implementación del nuevo sistema, será fuerte. Las oportunidades de que alguna vez llegue a ser operacional son escasas.
En forma alterna, si los usuarios han expresados la necesidad de un sistema que es operacional la mayor parte del tiempo tenga una forma más eficiente y accesible, si tiene una mejor oportunidad de que el sistema solicitado llegue a ser utilizado.
B. Análisis de las Necesidades del Sistema: En esta fase el analista involucra el análisis de las necesidades del sistema. Nuevamente, herramientas y técnicas especiales ayudan para que el analista haga la determinación de los requerimientos. Una herramienta de ésta es el uso de diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, así como sus especificaciones, si son alfanuméricos y que tanto espacio ocupan si se imprimen. En este punto del ciclo de vida del desarrollo de sistema, el analista prepara una propuesta de sistema que integra lo que ha sido encontrado, proporciona análisis de costo/beneficio de las alternativas y hace recomendaciones sobre lo que debe ser hecho.
C. Diseño de Sistema Recomendado: En esta fase del ciclo de vida del desarrollo de sistemas, el analista usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de información sean correctos. Además, el analista también proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantallas.
Parte del diseño lógico del sistema de información es diseñar la interfaz de usuario. La interfaz conecta al usuario con el sistema y es, por lo tanto, extremadamente importante. La fase de diseño también incluye el diseño de archivos o bases de datos que guardaran la mayor parte de los datos necesarios para los tomadores de decisiones de la organización. Una base de datos bien organizada es la base para todos los sistemas de información, aquí el analista trabaja con los usuarios para diseñar la salida que satisfaga sus necesidades de información.
Por último el analista debe diseñar procedimientos de control y respaldo para proteger el sistema y a los datos y producir paquetes de especificaciones de programa para los programadores.
D. Diseño Detallado: Durante esta etapa se desarrolla las especificaciones de programas y procedimientos. Cada reporte, formato de pantalla, archivo, tabla, base de datos, módulos y componentes del sistema se especifica en detalle suficiente para que el documento constituya una verdadera guía en la construcción del nuevo sistema. También en esta etapa se desarrollan y bosquejas los procedimientos manuales administrativos, muchas veces denominados procedimientos manuales, que regimentarán todas las actividades que rodearán los procedimientos mecanizados del nuevo sistema.
E. Programación: A pesar de que la actividad central de esta fase es el desarrollo y la prueba de los programa, por lo que le da ese nombre, en esta etapa también se desarrollan los procedimientos administrativos, se preparan los manuales para el usuario y operaciones y se ensambla lo que constituirá la documentación del sistema.
En esta fase cada programa se prueba individualmente, aunque no es descartable que se realicen las primeras pruebas del sistema. También se desarrollan y prueban los programas necesarios para llevar acabo la conversión de los datos del sistema y para crear los nuevos archivos o bases de datos.
F. Prueba del Sistema: La prueba del sistema valida y verifica como conjunto, todos los componentes desarrollados en la fase anterior se integran y prueban como un todo. Como resultado de esta prueba, los programas y la documentación se ajustan y se corrigen.
Con el fin de aligerar la implantación es frecuente que, hacia el final de la base de prueba, se comience a entrenar al personal de los departamentos que utilizarán el nuevo sistema.
G. Conversión e Implantación: En esta fase se crean los archivos, las bases de datos y las tablas necesarios para el funcionamiento normal del nuevo sistema. Una vez que, tanto la función como auditoría, corroboran que el nuevo sistema ha sido inicializado satisfactoriamente, se da comienzo a las pruebas en paralelo, prueba piloto, etc.
El entrenamiento del personal que utilizará y operará el sistema se completa en esta fase y una vez concluida, el sistema pasa a ser responsabilidad de operaciones y mantenimiento y del departamento usuario.
CARACTERÍSTICAS QUE DEBEN POSEER LOS FLUJOGRAMAS
Sintética: La representación que se haga de un sistema o un proceso deberá quedar resumido en pocas hojas, de preferencia en una sola. Los diagramas extensivos dificultan su comprensión y asimilación, por tanto dejan de ser prácticos.
Simbolizada: La aplicación de la simbología adecuada a los diagramas de sistemas y procedimientos evita a los analistas anotaciones excesivas, repetitivas y confusas en su interpretación
De forma visible a un sistema o un proceso: Los diagramas nos permiten observar todos los pasos de un sistema o proceso sin necesidad de leer notas extensas.
SIMBOLOGÍA PARA LA ELABORACIÓN DE FLUJOGRAMAS DE USO GENERALIZADO
Se muestran los símbolos estándar utilizados para poder formular diagramas de procesos. Ver figura nº 3.8.1.
SIMBOLOGÍA PARA LA ELABORACIÓN DE DIAGRAMAS DE FLUJO DE USO GENERALIZADO
DISEÑO Y ELABORACIÓN DE FLUJOGRAMAS
Este se rige por una serie de símbolos, normas y pautas convencionales las cuales son:
1. El formato o esqueleto del Flujograma debe dividirse en partes que representan a los departamentos, secciones o dependencias involucradas en el procedimiento. Cada departamento o sección debe mostrarse una sola vez en el Flujograma y en el mismo orden o secuencia cronológica de su aparición en el procedimiento que se describe de izquierda a derecha.
2. Se debe mostrar una misma dependencia más de una vez en el Flujograma aun cuando las acciones del procedimiento regresen a la misma.
3. Las líneas indicadoras del Flujograma deben ser más delgadas que las líneas divisorias del formato, rectas y angulares, dotadas de flechas en sus extremos terminales.
4. Cada paso o acción del procedimiento debe enumerarse con claridad y describirse brevemente con muy pocas palabras.
5. Cuando algún documento queda retenido en alguna dependencia del Flujograma se indica según sea archivado: definitivamente, temporalmente o retenido por algunos días ("D"), horas ("O") o minutos (´)
6. Cuando hay que destruir algún documento luego de ser utilizado en el procedimiento se indica con una (X) grande.
7. Cuando en el procedimiento algún documento da origen a otro se indicará en el Flujograma mediante una flecha interrumpida.
Siempre resultará mejor que el Flujograma se muestre en una sola hoja, pero cuando en su extensión se tenga que continuar en otra página, se señala mediante un símbolo en forma de pentágono, en la página donde se interrumpe y el mismo que suele llamarse conector se colocará en otra página.
CAPÍTULO IV
Marco metodológico
En el capitulo se muestra los aspectos referidos al Diseño metodológico que fue utilizado para el desarrollo del estudio que se propuso en el proyecto; por tanto, se menciona el tipo de estudio que se desarrolla, la población y muestra con que se trabajara, los instrumentos que se utilizaron para conocer sobre el problema y tener base de conocimiento de la situación actual y especificación sobre el procedimiento que será seguido para el desarrollo del diseño de sistema de información automatizado sobre el control de asistencia técnica de los productos hortícolas.
TIPO DE ESTUDIO
El presente trabajo fue desarrollado bajo el estudio no experimental, debido a que se observo el comportamiento de las variables sin alterar ninguna de ellas; el estudio es de tipo descriptivo, aplicado o tecnológico.
El estudio es de tipo descriptivo de acuerdo con Hernandez (1998) (42) ,quien manifiesta que: "consiste en describir, analizar, interpretar o medir la naturaleza actual, composición de los procesos o propiedades importantes de cualquier fenómeno que sea sometido a análisis.
Zorilla (1988) (43), manifiesta que una investigación tecnológica o también conocida como investigación aplicada es: "una actividad orientada a la generación de nuevo conocimiento técnico que pueda ser aplicado directamente a la producción y distribución de bienes y servicios, lo cual puede conducir a una innovación o mejora".
De acuerdo con las citaciones antes mencionadas el diseño de sistema de información dará respuesta a través de la aplicación de nuevos conocimientos a la problemática planteada, logrando así optimizar la confiabilidad de reportes y tiempos de obtención de los mismos.
POBLACIÓN Y MUESTRA.
De acuerdo con el objetivo en estudio, es necesario definir claramente las características de la población y la muestra que fueron objeto de estudio en la presente investigación.
Por ello debe establecerse la unidad de análisis y delimitación tanto de la población como la de la muestra en estudio. De acuerdo con WEIERS 1989, la población es definida como: …el total de elementos sobre el cual queremos hacer una inferencia basándonos en la información relativa a la muestra" y la muestra es definida como: "la parte de la población y seleccionaremos, medimos y observamos. (pag 97)
En tal circunstancia, de acuerdo con los antes mencionados y para efecto del trabajo, la muestra u objeto de estudio fue el 100% es decir, igual a la población y fue constituida por todas las hortalizas que cultivan los productores que gozan de la asistencia técnica, adscritos de a la gerencia de desarrollo agropecuario.
INSTRUMENTOS
De acuerdo con los objetivos planteados, se utilizaron instrumentos para la recolección de información que son necesarias para el desarrollo de esta investigación.
Zorrilla (1988) (46), en este sentido, plantea que un instrumento es el medio utilizado para obtener datos o información con el fin que puedan utilizarse correctamente, este debe ser confiable y contribuyente a la medición, preparación codificación y análisis de las variables en estudio.
Siguiendo lo expuesto, para el desarrollo de la investigación, recolectar, analizar información, se utilizaron los siguientes instrumentos.
Entrevista no estructuradas
Las entrevistas no estructuradas se realizaron al personal de asistencia técnica departamento adscrito a la gerencia de desarrollo agropecuario, con el fin de conocer la situación actual en cuanto al cumplimiento de las actividades de asistencia técnica a los productores agropecuarios.
Observación directa.
Esta técnica se baso en visualizar y examinar la gestión de las actividades y procesos a realizar en el departamento de asistencia técnica, al mismo tiempo se determino que se esta haciendo, como se esta haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo demora, donde se hace y porque se hace.
Red Internet, bibliotecas y otras fuentes.
A través del uso de la red Internet y las consultas a las referencias bibliográficas, se obtuvo información sobre estudios ya elaborados anteriormente y modelos de aplicación actual, lo que sirvió como punto de referencia de comparación para crear nuevas posibles aplicaciones.
Paquetes computarizados.
Los paquetes computarizados fueron apoyo al desarrollo y análisis estadístico de los datos a presentar, se utilizaron los siguientes programas: Openoffice.org procesador de texto, Openoffice.org calculo y GLADE con GTK.
PROCEDIMIENTO METODOLÓGICO
Para lograr el objetivo de estudio, el cual esta referido al diseño de sistema de información para registrar y controlar las asistencias técnicas a los productores hortícolas fue necesario el desarrollo de los siguientes pasos:
Recolectar y analizar toda la información adquirida sobre los procesos descritos a realizar en asistencia técnica, a través de entrevistas no estructuradas al personal técnico.
Registrar y analizar los datos y variables que serán utilizadas para el proceso de sistema de información.
Analizar y determinar los procesos claves entre la interacción del departamento de asistencia técnica y el productor hortícola.
Determinar la caracterización y recursos necesarios de información de los procesos claves del departamento.
Diseñar la base de almacenamiento de datos, los cuales serán registrados y procesados para realizar los reportes de información.
Diseñar conceptualmente los procesos de información necesarios para llevar el control de asistencia técnica de los productores.
Diseñar el proceso lógico del diseño conceptual, proceso por el cual se regirá el sistema de información.
Diseñar el modelo interfaz (físico) del sistema de información, muestra de como se vera en pantalla el sistema de información.
Realización de un estudio de factibilidad, a través de la recolección de datos, para determinar si el estudio a tratar puede ser implementado en la empresa.
Determinación de la factibilidad técnica en hardware.
Determinación de la factibilidad técnica en software.
Determinación de la factibilidad económica.
Determinación de la factibilidad operacional.
Diseñar manual de instrucciones y procedimiento del sistema de información.
CAPÍTULO V
Diagnóstico y análisis de la situación actual
Diagnostico y análisis de la situación actual de las actividades de asistencia técnica realizadas a los productores de hortalizas.
La gerencia de desarrollo agropecuario adscrita a la gerencia de desarrollo industrial tiene entre sus funciones brindar asistencias técnica a los productores adscritos a la red de productores de agrícolas de la gerencia de desarrollo agropecuario C.V.G. Además de llevar registros de los avances de los distintos cultivos, para controlar con mayor calidad el cultivo y así obtener el mayor rendimiento de las plantas cosechadas.
Actualmente la recolección y procesamiento de la información sobre los ingresos de nuevo productores hortícola y las actividades de la asistencia técnica es llevada a cabo de forma manual, lo cual involucra un retardo en la preparación de datos referentes a los reportes, lo que sin duda agrega un costo adicional al proceso e imposibilita la detención rápida de problemas y posterior toma de decisiones dirigidas a corregir los problemas.
Esta situación no solo retrasa a este proceso sino que además genera un costo agregado por concepto de que se utilizaran más horas-hombres en la búsqueda y preparación de datos referentes a las actividades de asistencia técnica para generar reportes, lo cual ocasiona demoras en la solicitud de información.
A razón de esta situación con el objetivo de darle una solución a este problema, la gerencia de desarrollo agropecuario considero que todas las actividades de asistencia técnica deben ser respaldadas por un sistema de información automatizado que permita el resguardo de todas las operaciones de asistencia técnica y así obtener información con mayor fluidez en el menor tiempo posible a la hora de tomar alguna decisión.
PROCESOS INVOLUCRADOS EN EL DEPARTAMENTO DE ASISTENCIA TÉCNICA.
DESCRIPCIÓN DE LOS FLUJOS DE DATOS DEL SISTEMA ACTUAL
NUEVO PRODUCTOR
El proceso comienza una vez que un nuevo productor se acerca a la gerencia de desarrollo agropecuario y realiza una solicitud para asistencia técnica sobre algún rubro hortícola o frutal a cultivar.
La gerencia a recibir esta solicitud envía al departamento de asistencia técnica una instrucción para realizar una asistencia técnica al productor que hizo la solicitud.
El departamento de asistencia técnica llama al productor y se pone en contacto para realizar inspección y diagnostico del campo en donde se realizara el cultivo.
Al realizar esas observaciones y escuchar peticiones del productor el técnico del departamento registra al productor en su base de datos y después el técnico una vez analizado la situación y requerimientos, realiza recomendaciones para hacer del campo lo mas productivo posible y también programa la próxima visita para observar avance es de acotar que estas actividades son archivadas por el departamento.
Una vez que el productor ejecuta actividades de recomendaciones, el técnico visita el campo productivo en forma de cumplir con la fecha de visita programada toma apuntes de observaciones y analiza el campo y procede para el comienzo de cultivos.
Ver figura 5.1 Diagrama de flujo del proceso de nuevo productor.
AVANCES DE CULTIVOS
Una vez que el productor ya esta ingresado en la base de datos y decide cambiar de rubro hortícola a cultivar se realiza el siguiente proceso:
Realiza la solicitud de asistencia técnica para cultivar un nuevo productor hortícola el técnico se dirige al sitio de la producción y analiza la situación toma apuntes sobre las propiedades físicas del terreno y toma muestra para enviarlas al laboratorio para conocer las propiedades químicas del suelo, una vez que se obtienen los resultados, el técnico envía unas actividades, recomendaciones y una planificación de visitas para observar el comportamiento del cultivo; toda esta información es archivada por el departamento.
El productor al recibir las series de actividades y recomendaciones las ejecutas.
El técnico en su próxima fecha de visita realiza una inspección, toma notas y muestra del suelo y en esa visita se presentan 2 alternativas las cuales son: ¿si cumple con las especificaciones necesarias para pasar a la siguiente etapa del cultivo? ó ¿aun falta por tratamiento del suelo? Si el suelo aun no cumple con las especificaciones se vuelven hacer unas series de actividades y recomendaciones, pero si cumple el productor podrá pasar a la siguiente etapa la cual es de semillero.
El técnico analiza y evalúa las semillas, después de tomar apuntes, realiza una serie de actividades y recomendaciones para cultivar esas semillas. Se le envía las actividades y recomendaciones al productor y se archiva una copia en el departamento de asistencia técnica de lo antes enviado. El productor al recibir las actividades y recomendaciones decide ejecutarlas.
El técnico en su próxima visita observa si la etapa de semillero fue culminada y si las plantas están preparadas para pasar al siguiente paso el cual es el trasplante, sino se repite el proceso de observar el semillero.
En la actividad de trasplante el técnico envía una lista con las actividades a seguir de cómo se realizara el trasplante y recomendaciones y son enviadas al productor y se guarda una copia a los archivos del departamento. El productor ejecuta las actividades enviadas por el departamento. El técnico en la siguiente visita observar si la etapa de trasplante termino, si aun no ha terminado se le realiza otras series de actividades y recomendaciones al productor (estas son archivadas al igual en el departamento) pero si termino con éxito el trasplante pasa a la siguiente etapa, la cual es el mantenimiento del cultivo.
El técnico en la posterior visita observa avances de crecimiento y tomas apuntes sobre lo observado, después elabora un plan de actividades y una lista de recomendaciones para el mantenimiento del cultivo y son enviadas al productor y una copia de ellas es archivada en el departamento.
El productor se encarga de ejecutar esas actividades y seguir bien las recomendaciones.
Si el proceso de mantenimiento aun no termina se siguen elaborando planes de mantenimiento sino se pasa a la siguiente etapa la cual es sobre el cultivo. En esta etapa el técnico elabora planes para la recolección del producto hortícola de la mejor forma.
El productor realiza actividades sobre la cosecha de la hortaliza. Al culminar la etapa de recolección de la hortaliza, el técnico propone serie de actividades para la comercialización del mismo.
Por ultimo el técnico elabora reportes sobre rendimiento de la cosecha y datos que soporten la producción. Al finalizar todo el cultivo el técnico le pregunta al productor si desea cultivar otro rubro si el productor desea cultivar otro rubro se procede el proceso nuevamente desde la etapa de análisis del suelo, sino culmina la asistencia técnica con ese productor.
Ver figura 5.2 Diagrama de flujo del proceso avances de cultivo
Figura: 5.2 Diagrama de flujo del proceso avances de cultivo
Fuente: Elaboración Propia
5.2.3. PROCESO DE REPORTES MENSUALES
El proceso comienza con una instrucción que es enviada desde la gerencia de desarrollo agropecuaria exigiendo el reporte mensual sobre los productores de hortalizas.
El jefe de departamento recibe la instrucción y exige reportes de avances a los técnicos.
Los técnicos de asistencia técnica recopilan toda la información necesaria par la creación del mismo, luego preparan y después de extraer los datos solicitados elaboran el reporte.
Es enviado al jefe de departamento y este lo revisa y realiza una presentación del mismo.
El jefe de departamento le presenta el informe a la gerente de desarrollo agropecuario.
La gerente de desarrollo agropecuario analiza los datos suministrado por tal departamento y realiza toma de decisiones sobre el análisis y posteriormente elabora plan de acción para el siguiente mes.
Ver figura 5.3 diagrama de flujo del proceso de reportes mensuales.
Figura: 5.3 Diagrama de flujo del Proceso de Reportes Mensuales.
Fuente: Elaboración propia.
DESARROLLO DEL SISTEMA DE INFORMACIÓN
Para desarrollar y proponer el nuevo sistema de información que cumplirá con los objetivos planteados, a continuación se presenta cada una de las fases de las metodologías estructuradas de los sistemas de información
Fase I: DEFINICIÓN DE PROBLEMA
Para definir el problema que planteara la propuesta de un sistema de información que automatice el control de las asistencias técnicas mencionado en la situación actual, se procedió a realizar los siguientes estudios:
ESTUDIO PRELIMINAR:
Para un análisis mas profundo de la situación que se presenta en el departamento de asistencia técnica se utilizo la herramienta diagrama causa – efecto, Tomando en consideraciones todos los procesos ejecutados por el departamento de asistencia técnica (ver grafico 5.4. Diagrama causa-efecto)
Mano de obra: El departamento de asistencia técnica se encuentran 15 técnico especializado para ejecutar visitas y emitir recomendaciones al productor, sin embargo hay un solo técnico que aparte de estar encargado en ejecutar visitas también esta encomendado de recolectar toda la información para realizar el reporte final, incrementado a este la carga de trabajo y causando que el informe salga deficiente por el exceso de información que posee,
Método: No existe procedimientos descritos que se puedan ejecutar al pie de la letra al momento de realizar alguna visita, el técnico levanta reportes de lo que se halla visto en la situación actual, sin embargo estos reportes no son del 100% ya que algunas veces el técnico pasa por alto algunos detalles que se deben conocer para elaborar reportes confiables.
Maquinaria y equipo: En el departamento de asistencia técnica el 70 % de la información que es manejada por el departamento es registrada de forma física y solo el 20% es llevado de forma digital. Lo que ocasiona una perdida de tiempo al elaborar el informe mensual, debido que el técnico que recolecta tiene que leer el 100% de todos los reportes para poder obtener la información requerida.
Materiales: Los técnicos al ir a una visita técnica llevan consigo una planilla donde ellos anotan todo lo que se observa de la situación actual, pero estas anotaciones se realizan de forma no estructurada, se pude notar que no hay un orden o un patrón a seguir al estructurar un reporte de visita. Lo que obliga al técnico que recolecta toda la información del reporte final, leer todo el reporte de la visita.
Medición: Existe indicadores para medir los objetivos planteados sin embargo estos indicadores solo se reflejan al cumplir el 100% de la cosecha y para los nuevos productores, no hay indicadores que permitan medir los avances del cultivo.
Medio ambiente: Los reportes de las visitas no son debidamente calificados, por lo que si el técnico que elabora el reporte final se equivoca en algunos datos de algún productor en especifico deberá de leer todos los reportes de ese mes para poder encontrar ese reporte de visita en especifico
ALTERNATIVA PROPUESTA PARA LA IMPLANTACIÓN DEL SISTEMA:
Se propone como mejor alternativa para el manejo de la información referente al registro de la asistencia técnica de avances de los cultivos hortalizas y de los productores, un sistema de información automatizado que sea funcionalmente sencillo y de fácil manejo de formato estructurado, que se pueda tener a la mano en todo momento como referencia instantánea.
Denominación del sistema propuesto: Sistema de información automatizado para el control de registros de nuevos productores y de asistencias técnicas a los productores de hortalizas.
Estructura del sistema
Figura 5.9 Estructura modular Búsqueda del sistema de información
Fuente: Elaboración propia.
JUSTIFICACIÓN DE LA ALTERNATIVA PROPUESTA:
En vista de que la gerencia de desarrollo agropecuario tiene entre sus funciones controlar las actividades de asistencia técnica de los cultivos de hortalizas y el manejo de toda la información generada en todo este proceso, es de gran importancia que esta información pueda tenerse a la mano en todo momento de ser consultada o chequeada por el usuario como referencia instantánea y agilizar el proceso en la toma de decisión.
FACTIBILIDAD TÉCNICA DEL HARDWARE
El sistema de información automatizado para el registro de los avances en las asistencias técnicas y el ingreso de nuevos productores, requerirá para su implantación un equipo con las siguientes características como mínimas para su funcionamiento regular:
Mínimos Requerimientos de Hardware
Requerimientos Recomendados
Pentium® 3/4 o AMD Athlon – 500 Mhz o mayor.
Disco Duro 20 GB.
256 MB RAM
Tomando en cuenta estas condiciones mínimas requeridas y evaluando el equipo que será instalado el sistema de información, se considera factible ya que el computador supera las exigencias mínimas para un buen funcionamiento.
FACTIBILIDAD TÉCNICA DEL SOFTWARE
Para el desarrollo del sistema a nivel de programación, se propone a utilizar un lenguaje PERL, que permite el desarrollo del software, centrándose en la representación de los resultados deseados. Obviamente debe existir una estructura de base de datos para registrar la información, la forma ideal en que esta base se creara es con el programa PHP y POSTGLADE SQL
Para el perfeccionamiento del sistema a nivel de programación, se propone utilizar el lenguaje de última generación PERL, que permite el desarrollo del sistema, el lenguaje puede centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce resultados. Obviamente, debe existir una estructura de datos con información relevante a la que el GLADE con GTK puede acceder rápidamente.
GLADE con GTK es uno de los lenguaje estándar de programación utilizado por la empresa para la construcción de programas para editar procesar y gestionar grandes bases de datos relacionados entre sí, posee múltiples cualidades, entre las cuales se tiene: cómo dos diálogos entre ventanas, posibilidad de creación de menú y proyectos sofisticados y el opcional empleo del Mouse con el fin de facilitar la navegación del cursor por la pantalla y la activación de las diversas opciones posibles.
FACTIBILIDAD ECONÓMICA
Los costos asociados con el sistema del servicio son los gastos, salidas o pérdidas resultantes del desarrollo y del uso de un sistema. Los beneficios son las ventajas que se obtienen de la instalación y utilización del mismo. Las tres clasificaciones principales de costos y beneficios son:
• Tangibles o intangibles
• Fijos o variables
• Directos o indirectos
COSTOS TANGIBLES
Son aquellos que pueden ser proyectados con precisión por el analista de sistema. En los costos tangibles están incluidos: el costo del equipo (Computadoras); el costo de los recursos; el costo del tiempo del analista de sistema; el costo del tiempo de los programadores y los salarios de otros empleados.
COSTOS DE EQUIPOS/ MATERIALES
Los costos de equipos resultan de la adquisición o utilización de todos los dispositivos asociados con el trabajo. Para el presente estudio, los costos de equipos van a estar conformados de la siguiente manera (ver tabla 5.6.1) :
COSTOS DE PERSONAL
Los costos de personal incluyen el salario o beneficio de todos los individuos que desarrollan u operan el sistema.
Para la implantación del sistema se requiere de:
Un Analista de Métodos y Procedimientos: Establece un estudio de métodos y los procedimientos que regirán en la empresa, aplicando procedimientos y técnicas correspondientes para el estudio.
Un Procesador de Datos: se encargará de cumplir tareas de administración de datos. Ordenará la información técnica de cada uno de los reportes elaborado por los técnicos, mediante la recolección de datos suministrados por los diferentes registros.
Un Programador: es responsable de la codificación, prueba e integración de los componentes del nuevo sistema. Dirige las especificaciones del desarrollo del diseño y programa el software para poner en marcha el sistema.
COSTOS INTANGIBLES
Son difíciles de estimar y pueden ser que no sean conocidos, estos incluyen:
La pérdida de una ventaja competitiva, debido a la falta de información oportuna.
Disminución de la productividad del departamento, debido a una toma decisión por información fuera de tiempo.
BENEFICIOS INTANGIBLES
Los principales beneficios que se esperan obtener del sistema son:
a) Contar con una base de datos real de los registro de nuevo productores y avances de asistencias técnicas., con el objeto de mantener confiabilidad de la información requerida.
b) Procesar la información de las actividades de asistencia técnica.
c) Aumento sistemático de la confiabilidad de los reportes de avances.
d) Estabilidad del sistema de información, a través del tiempo y las personas.
e) Facilita la evaluación de los resultados del cumplimiento de los objetivos.
BENEFICIOS TANGIBLES
Son ventajas cuantificables (bolívares, recursos o tiempo ahorrado) que se acumulan en la organización por medio del uso del sistema de información.
En el sistema propuesto se pueden apreciar de la siguiente manera:
Puntualidad en la información. La información se puede tener a la mano con mayor rapidez y en el momento oportuno.
Disminución de las horas/hombres empleadas en el registro de información en el proceso de información. Se agilizará la búsqueda de cualquier información de interés.
Menor probabilidad de cometer errores administrativos.
COMPARACIÓN DE COSTOS/BENEFICIOS
Hay muchas técnicas bien conocidas para la comparación de costos beneficios del sistema propuestos. Incluyen análisis de punto de equilibrio, recuperación, análisis de flujo efectivo y valor presente. Todas estas técnicas proporcionan formas directas para proporcionar información a los tomadores de decisiones acerca de sí vale la pena el sistema propuesto.
La implantación del nuevo sistema, generalmente involucra costos de equipo, software, recurso humano y mantenimiento del programa entre otros, a su vez involucra un beneficio que no puede ser cuantificable como para hacer un análisis de costo beneficio.
El beneficio más importante se obtendrá a largo plazo con la aplicación del sistema, el cual podrá contribuir con la gestión de registro de historial y que el reporte general funcione con una mayor eficiencia y por ende pueda contribuir efectivamente al cumplimiento de las metas del departamento.
Con la puesta en funcionamiento de este sistema de información habrá un beneficio intangible que se reflejará en lo siguiente:
Las recomendaciones planificadas y controladas para cada productor, permitirá utilizar los recursos necesarios para cada actividad en particular, permitiendo: mantener al productor en constante operación de la finca, reducción de fallas de producción, controlar gastos, etc.)
ANÁLISIS DE LA FACTIBILIDAD ECONÓMICA
Dado que la Gerencia de asistencia técnica, cuenta con el hardware y el software para el desarrollo del sistema no es necesario generar un costo adicional por adquisición de los mismos.
En cuanto al recurso humano la empresa no cuenta con el personal necesario para desarrollar el sistema al nivel de su automatización. Sin embargo la adquisición de un pasante informático podría desarrollar el Sistema de información sin ningún inconveniente debido a que este no presenta complejidades.
De acuerdo con las razones expuestas anteriormente se concluye que económicamente existe la posibilidad de implantar el sistema.
FACTIBILIDAD OPERACIONAL
El sistema automatizado planteado resulta operativo debido a que emitirá los diferentes resultados deseados por el usuario y funciona en forma efectiva con cada una de las situaciones que se presenten en la consulta y/o modificación en los mismos.
FASE II: ANÁLISIS DEL CONTEXTO
A continuación se presenta el modelo del sistema de información actual del control de registro de nuevo productores y avances de asistencia técnica a productores Hortícolas, con sus respectivas entradas y salidas de información.
Análisis del Inventario de productores hortícolas: La clasificación a los tipos de productores se toman en cuenta por la localización geográfica.
 Página anterior | Volver al principio del trabajo | Página siguiente  |