INSTITUTO POLITÉCNICO NACIONAL...i NOMBRE DE LA MATERIA DESARROLLO HUMANO INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECANICA Y ELÉCTRICA SECCIÓN DE ESTUDIOS

i

NOMBRE DE LA MATERIA DESARROLLO HUMANO

INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECANICA Y ELÉCTRICA

SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

“DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA

ADMINISTRAR UNA MICROEMPRESA. CASO DE ESTUDIO: NEGOCIO PARA COMERCIALIZAR

ARTESANÍAS”.

TESIS

QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INGENIERÍA DE SISTEMAS

PRESENTA:

ING. JOSÉ LUIS GONZÁLEZ DOMÍNGUEZ

DIRECTORA DE TESIS: M. EN C. GRACIELA VÁZQUEZ ÁLVAREZ

MÉXICO D.F., a 30 de junio de 2010.

Diseño de un Sistema de Información para Administrar una Microempresa.

Caso de estudio: Negocio para comercializar Artesanías.

i. Ing. José Luis González Domínguez Página ii



i. Ing. José Luis González Domínguez Página iii



i. Ing. José Luis González Domínguez Página iv

INDICE

Resumen .......................................................................................................... viii

Abstract .............................................................................................................. ix

INTRODUCCIÓN ............................................................................................... x

Prólogo ...................................................................................................... x

Contexto .................................................................................................... xi

Objetivo general ......................................................................................... xi

Objetivos particulares ................................................................................ xi

Justificación ............................................................................................... xi

Beneficios esperados ................................................................................ xii

Límites ...................................................................................................... xii

Estructura de la tesis. .............................................................................. xiii

Capítulo 1 “MARCOS CONTEXTUAL, METODOLÓGICO, TEÓRICO

Y COCEPTUAL”..………….……………………………………….……1

CONTEXTUAL” ................................................................................................. 1

Resumen del Capítulo 1 ............................................................................ 2

1.1 Marco Contextual ................................................................................. 2

1.2 Marco Metodológico ............................................................................ 3

1.3 Marco Teórico ..................................................................................... 4

1.4 Marco Conceptual ................................................................................ 7

Capítulo 2 “ANÁLISIS Y DISEÑO DEL SISTEMA DE INFORMACIÓN” .......... 10

Resumen del Capítulo 2 .......................................................................... 11

Preámbulo ........................................................................................... 12

2.1 Fase de Análisis del Sistema de Información ................................... 13

2.1.1 Antecedentes Históricos de la Empresa .................................... 13

2.1.2 Identificación y obtención de: Misión, Visión, Objetivos, ............ 14

Funciones y Políticas de la empresa. ....................................... 14

2.1.3 Identificación de la estructura organizacional de la empresa .... 15

2.1.4 Diagrama de casos de uso ........................................................ 16

2.1.5 Diagrama de flujo de datos Nivel 0 (DFD) ................................. 17

2.1.6 Diagrama de flujo de datos Nivel 1………..…..…………….…....17

2.1.7 Diagrama a bloques modificado……………………………………18

2.1.8 Identificación de los Procesos Actuales………..…………..……..19



i. Ing. José Luis González Domínguez Página v

2.1.9 Identificación, recopilación y obtención de todo tipo

de documentos e información ................................................... 20

2.1.10 Alcances Presentes y Futuros…………………………………. 23

2.1.11Elaboración de la Tabla Sistémica del Sistema Actual………… 23

2.2. Fase de Diseño del Sistema de Información .................................... 25

2.2.1 Identificación de los procesos del Sistema Propuesto .............. 25

2.2.2 Elaboración del Diagrama de Gantt……...….………….……….27

2.2.3 Elaboración del Diagramas PERT……………………….….……28

2.2.4 Elaboración del Marco Normativo del Sistema Futuro…………30

2.2.5 Definición de las Funciones del Nuevo Sistema incluido

el Perfil del Usuario ................................................................... 31

2.2.6 Determinación de la posible Herramienta de Construcción ...... 33

2.2.7 Diagrama de flujo de datos modificado Nivel 1 de

del sistema propuesto……...………………………………………...33

2.2.8 Realización del Análisis Costo-Beneficio………….………….…34

2.2.9 Elaboración de la Tabla Sistémica del Sistema de

Información Propuesto ............................................................... 36

2.2.10 Realización de la Arquitectura del sistema ............................... 36

2.2.11 Diseño de las Salidas ............................................................... 39

2.2.12 Diseño de las Entradas………...…………...…………………..40

2.2.13 Diseño de los Procesos utilizando el Modelo

WARNIER-Orr………………………………………...………….…42

2.2.14 Diseño de la Naturaleza Jerárquica de Salida

desprendida del Modelo Warnier-Orr ........................................ 42

2.2.15 Diseño de la Base de Datos con el modelo relacional………….45

Capítulo 3 "CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN” .............. 46


3.1 Construcción del hardware e instalación de la plataforma……………48

3.1.1 . Requerimientos de hardware………………………………………48

3.1.2 Elección de la computadora....................................................... 49

3.1.3 Herramientas necesarias ........................................................... 51

3.1.4 Ensamblado de la computadora ................................................ 52

3.1.5 Instalación del Sistema Operativo ............................................. 55

3.2 Construcción del software ............................................................. 58

3.2.1 Base de Datos del Sistema de Información………………………58



i. Ing. José Luis González Domínguez Página vi

3.2.2 Datos vs. Información………………… ....................................... 58

3.2.3 Sistema Gestor de la Base de Datos………. ............................. 59

3.2.4 Generalidades de los SGBD ó SMBD ........................................ 59

3.2.5 Elección del SGBD para el SI en cuestión ................................. 60

3.2.6 Representación conceptual de la BD ......................................... 61

3.2.7 Diseño de la Base de Datos con el Modelo Relacional .............. 62

3.2.8 Normalización ............................................................................ 62

3.2.9 Formas normales ....................................................................... 63

3.2.9.1 Primera Forma normal ............................................................. 63

3.2.9.2 Segunda Forma normal ........................................................... 64

3.2.9.3Tercera Forma normal .............................................................. 64

3.3Construcción Física de la Base de Datos con Access 2007…………..65

3.3.1 Tablas creadas ........................................................................... 65

3.3.2 Diccionario de datos. .................................................................. 66

3.3.3 Formularios creados. .................................................................. 77

3.3.4 Informes Creados. ...................................................................... 79

Capítulo 4 “PRUEBAS Y RESULTADOS” ........................................................ 80


4.1 Definición .......................................................................................... 81

4.2 Fundamentos y objetivos de la prueba. ............................................ 82

4.3 Características de las pruebas de software ...................................... 83

4.4 Métodos de prueba ............................................................................ 83

4.5Prueba de interfaces gráficas. ............................................................ 84

4.5.1 Para las ventanas. ...................................................................... 84

4.5.2 Para menús emergentes y operantes con el ratón ..................... 85

4.5.3 Para entrada de datos. .............................................................. 86

4.6 Resultados. ..................................................................................... 86

4.7 Toma de decisiones. .......................................................................... 86

Capítulo 5 “CONCLUSIONES Y TRABAJOS FUTUROS” ............................... 88


5.1 Cumplimiento del objetivo general. .................................................... 89

5.2 Consecución de los objetivos particulares ....................................... 90

5.3 Conclusión general .......................................................................... 90

5.4 Trabajos futuros ............................................................................... 90

REFERENCIAS BIBLIOGRÁFICAS Y DE INTERNET ..................................... 92



i. Ing. José Luis González Domínguez Página vii

GLOSARIO ....................................................................................................... 95

ANEXO 1: REGLAS DE CODD PARA LA EVALUACIÓN DE UN SGBD .......... xi

ANEXO 2: RECOPILACIÓN DE DOCUMENTOS DEL SISTEMA ACTUAL ...... xi

ANEXO 3: MANUAL DEL USUARIO .................................................................. xi

ÍNDICE DE FIGURAS ....................................................................................... xii

ÍNDICE DE TABLAS ........................................................................................ xiii



i. Ing. José Luis González Domínguez Página viii

RESUMEN Esta tesis es un trabajo de investigación sobre el Diseño de un

Sistema de Información para Administrar una Microempresa. Caso de Estudio: Negocio para comercializar artesanías. El soporte teórico lo dan por un lado los trabajos de Peter Checkland, en lo referente al enfoque de la Teoría General de Sistemas y por el otro, los trabajos de Edgar Frank Codd, en lo que respecta al Modelo Relacional de las Bases de Datos. Se utilizó la metodología LGS de Leopoldo Galindo Soria para el desarrollo de Sistemas de Información.

El producto final es un Sistema de Información basado en

computadora, con un Sistema de Base de Datos como corazón de aquel, mismo que permite la administración de la microempresa caso de estudio de la presente tesis. Las pruebas y sus resultados permiten hacer un análisis de la microempresa de manera tal que permitan coadyuvar en la toma de decisiones de la gestión de la misma. En la parte final se presentan las conclusiones a la luz de los objetivos originales y los trabajos futuros que pudieran dar continuidad a esta investigación.



i. Ing. José Luis González Domínguez Página ix

ABSTRACT

This thesis is a research paper on the Design of an Information System for Managing a Micro business. Case Study: Business to market handicrafts. The theoretical support is given on the one hand by the work of Peter Checkland, regarding the approach of General Systems Theory and on the other, the work of Edgar Frank Codd, in regard to the Relational Model of Databases. LGS methodology of Leopoldo Galindo Soria was used for the development of Information Systems.

The final product is an Information System based on a computer

with a Database System as the heart of that, it allows the administration of the micro business, case study of this thesis. The tests and their results allow an analysis of the micro-business so as to allow take management decisions about it.

The final section presents the findings in the light of the original objectives and future work that could give continuity to this investigation.



i. Ing. José Luis González Domínguez Página x

INTRODUCCIÓN

Prólogo

Como atinadamente señalara Ludwig von Bertalanffy, considerado el padre de la Sistémica, “la Teoría General de Sistemas es una visión amplia la cual va más allá de los problemas tecnológicos y demanda de una reorientación que se hace necesaria en la ciencia en general y en el glamur de las disciplinas desde la Física y la Biología hasta las Ciencias del Comportamiento, las Sociales y la Filosofía” (1968).

Bajo esta premisa es que el de la palabra, vio en la Maestría en

Ciencias en Ingeniería de Sistemas un terreno idóneo para satisfacer sus inquietudes académicas y de investigación ya que se encontraba ante la oportunidad de combinar los principios de su formación académica original en el campo de las ciencias exactas y la parte humana, social y filosófica de su experiencia de vida.

Por tanto el presente trabajo de tesis es mucho más que un mero

requisito para la obtención del grado académico, es el corolario de un extraordinario proyecto de formación e investigación académicas. Es luego entonces, el producto que da testimonio del camino recorrido y de lo mucho que se le disfrutó.

La investigación es en torno a los Sistemas de Información y a

resolver un problema concreto de índole personal, mas no con el propósito de servirse utilitariamente de ella. La idea fue más bien, realizar una investigación pragmática que no quedara archivada y sin utilidad para nadie; contar con un trabajo que se pudiera “aterrizar” en lo práctico y con beneficio no sólo individual sino social.

Por lo antes expuesto, someto a su amable consideración, el

presente trabajo de investigación. De antemano agradezco sus comentarios y aportaciones.

Atentamente

J.L.G.D.



i. Ing. José Luis González Domínguez Página xi

Contexto

La presente investigación está ubicada dentro del requisito marcado dentro del Reglamento de Estudios de Posgrado del Instituto Politécnico Nacional en el Capítulo 5, Artículo 54 y publicado en la Gaceta Politécnica 633 del 31 de julio de 2006 (Villa-Rivera, 2006), como trabajo de tesis y su correspondiente defensa oral para la obtención del grado de Maestro en Ciencias en Ingeniería de Sistemas, en virtud de que los estudios de posgrado realizados fueron en la Sección de Estudios de Posgrado e Investigación de la Escuela Superior de Ingeniería Mecánica y Eléctrica-Zacatenco de este instituto.

El desarrollo de este trabajo de tesis está basado en la Ingeniería

de Sistemas, entendida ésta como la aplicación de las ciencias exactas para desarrollar sistemas y transformar un problema en una descripción de un modelo de éste, contemplando el uso de definiciones, síntesis, análisis, diseño, pruebas y evaluación.

La línea de investigación en la que se circunscribe este trabajo de

tesis es en el área de los Sistemas de Información y Bases de Datos.

Objetivo general

Diseñar un sistema de información para administrar una microempresa. Caso de Estudio: Negocio para Comercializar Artesanías.

Objetivos particulares

Analizar y evaluar los sistemas de información para la administración.

Identificar las características particulares del negocio para comercializar Artesanías del caso de estudio de la presente investigación.

Diseñar y construir el Sistema Informático en cuestión.

Implantar y Documentar el Sistema Informático referido.

Justificación

Dado el grave deterioro económico nacional e internacional por el que atraviesa la sociedad contemporánea, se requiere consolidar e impulsar las pequeñas empresas y microempresas que puedan dar lugar a la recuperación del ingreso de la población, sobre todo el de las capas más desprotegidas económica y socialmente. El desarrollo de este trabajo ayudará a fortalecer una microempresa para comercializar artesanías en la ciudad de Actopan Hidalgo al dotarla de un Sistema de Información para mejorar su administración.

Es imperativo, luego entonces, promover el apoyo tecnológico a

los negocios pequeños y micro, de forma tal que se estimule su crecimiento y



i. Ing. José Luis González Domínguez Página xii

consolidación. Tal es el caso del Diseño de un Sistema Informático Basado en Computadoras que apoye la administración de la microempresa mencionada.

Dicho en otras palabras, es necesario coadyuvar a detonar las

economías locales de las distintas regiones del país, sobre todo en estos momentos de depresión económica generalizada, en los que se requiere impulsar los negocios generadores de auto-empleo bajo un esquema de Desarrollo Sustentable; entendiendo como tal a aquel que está en consonancia con sus entorno social, ecológico y que tiene presente en todo momento el desarrollo de los individuos en todas sus esferas. El negocio al que se hace alusión en el Caso de Estudio de la presente investigación, promueve que los artesanos de la región de Actopan Hidalgo se auto empleen al vender sus productos manufacturados con base en materias primas locales, haciendo una explotación racional de los recursos renovables de su entorno.

En conclusión, la realización de la presente investigación se justifica, además de los puntos antes expuestos, en la necesidad de diseñar un Sistema de Información compatible con los requerimientos específicos de un negocio para comercializar artesanías, propiedad del que suscribe, en virtud de que los sistemas de información para la administración de pequeñas empresas existentes en el mercado, tales como los productos de MaxiComercio ERP & POS, SME Toolkit América Latina o de Microsoft Dynamics son de propósito general y difícilmente utilizables de forma directa. Cabe mencionar que el negocio en cuestión se lanzó de una forma empírica y sin un sistema de información basado en computadoras.

Beneficios esperados

El principal beneficio esperado es el impacto que pueda tener para beneficio de la comunidad y de la sociedad en su conjunto. Es lo mínimo que puede esperarse para retribuirle en parte a la sociedad al haber podido ser beneficiado por alcanzar estudios de nivel de posgrado.

En la medida en que esta investigación pueda ser un detonante para el despegue del negocio caso de estudio, se estará beneficiando a una gran cantidad de artesanos y fabricantes locales, con lo que no sólo se estará beneficiando a la entidad, sino a todo el estado, el país y la sociedad en su conjunto.

Límites

Una de las limitantes principales de esta investigación es que los Sistemas de información y que los sistemas en general, pueden y deben ser perfectibles. Para que un sistema de información pueda alcanzar su punto de equilibrio, debe haber estado en operación lo suficiente como para alcanzar su maduración. Y aún en este caso, siempre podrán hacerse cambios que



i. Ing. José Luis González Domínguez Página xiii

beneficien la sobrevivencia del sistema. Como señala Maya: “todo sistema debe ser actualizado para su época y para las circunstancias que así lo requieran, esto le permitirá a todo sistema seguir evolucionando.” (2008).

En consonancia con lo anterior se encuentra la evolución

vertiginosa que todo el software está teniendo, razón por la cual no sería de extrañarse que en poco tiempo el sistema propuesto caiga en obsolescencia; no obstante, el principio de diseño y los conceptos generales pueden ser aplicables a productos futuros.

Estructura de la tesis.

La tesis se encuentra compuesta por cinco capítulos, los cuales presentan bloques bien definidos de distintas fases de la investigación. A continuación se da cuenta de la estructura de cada uno de ellos:

Capítulo 1: “Marcos contextual, metodológico, teórico

y conceptual”.- Formado a su vez por cuatro subcapítulos. En ellos se da cuenta del contexto, metodología, teoría y conceptos principales subyacentes en toda la investigación.

Capítulo 2.- “Análisis y diseño del sistema de información”.- Compuesto por dos subcapítulos. En el primero se hace el análisis del problema objeto de estudio, es decir del negocio para la comercialización de artesanías. En otras palabras, se presenta la forma en que había venido operando esta microempresa. En el segundo subcapítulo se hace el análisis del sistema de información que se propone.

Capitulo 3.- “Construcción del sistema de

información”.- Constituido por dos subcapítulos. El primero tiene que ver con la construcción del hardware, en tanto que el segundo expone la construcción del software. En ambos casos, se expone la problemática encontrada y la manera en que fue resuelta.

Capítulo 4.- “Pruebas y resultados”.- Organizado en un

solo bloque en el que como su nombre lo indica, se presentan las pruebas a las que fue sometido el sistema y los resultados de éstas.

Capítulo 5.- “Conclusiones y

Trabajos Futuros”.- Estructurado también en una sola unidad en la que se presentan las ideas concluyentes de la investigación y los Trabajos Futuros.

1

“Of knowledge there is no satiety”

Francis Bacon

(1561-1626)

CAPÍTULO 1

MARCOS CONTEXTUAL,

METODOLÓGICO,

TEÓRICO Y CONCEPTUAL



i. Ing. José Luis González Domínguez Página 2

CAPÍTULO 1

MARCOS CONTEXTUAL METODOLÓGICO, TEÓRICO Y CONCEPTUAL

Resumen del Capítulo 1

RESUMEN DEL CAPÍTULO 1

En este primer capítulo se ubica la investigación

dentro de contexto (marco contextual); se presenta la metodología

desarrollada durante la investigación (marco metodológico); la

teoría que sirve de soporte a esta tesis (marco teórico) y los

conceptos básicos sobre los que discurre esta investigación (marco

conceptual).

1.1 Marco Contextual

Toda investigación debe ubicar dentro de contexto el entorno en el que se desarrollará ésta y un trabajo de tesis no es la excepción. En este sentido, esta tesis se enmarca en una situación muy particular al desarrollar un Sistema Informático con aplicación inmediata y de interés específico para el




que la suscribe, para administrar un negocio propio para la comercialización de artesanías en la ciudad de Actopan, estado de Hidalgo. Independientemente del trámite académico para la obtención del grado, tal y como lo señala Ángeles Mendieta (Mendieta Alatorre, 1979); esta investigación presenta el diseño de un sistema de información, el cual bien puede ser de aplicación diversa para la administración de negocios de otra índole y que aporta un enfoque meta-disciplinario de lo que es la administración de negocios. Desde el punto de vista geográfico, este municipio se encuentra localizado 37 km al NO de Pachuca, la capital del estado de Hidalgo, misma que a su vez está ubicada en el centro de la República Mexicana y a 97 Km al norte de la ciudad de México por la carretera federal No. 85. Cuenta con una población que ronda los 48,500 habitantes y su economía es primordialmente basada en los servicios y el comercio, aunque en el pasado reciente era de tradición agrícola y artesanal. (Actopan (Hidalgo)). La Fig 1.1 muestra de manera gráfica la ubicación de este poblado.

Figura 1. 1 Ubicación geográfica del municipio de Actopan Hidalgo

Fuente: (Google, 2009)

1.2 Marco Metodológico

Dada la naturaleza de la investigación, es decir una tesis teórico-práctica, la metodología utilizada para desarrollar la misma fue tanto Investigación Documental como de Campo. (Muñoz Razo, 1998). Por la forma de tratar y recopilar información se trata de una tesis de técnicas mixtas y que da soución a una problemática específica. En cuanto al sistema informático per se, se utiliza la metodología LGS (Galindo Soria L. , 2005) para el desarrollo de Sistemas de información basados en computadora el cual consta de cuatro fases y son: Análisis, Diseño, Construcción e Implantación del sistema.




En lo concerniente al Diseño de la Base de Datos propiamente dicho, se utilizó la metodología propuesta por González Lozano R. (2009) misma que consta de ocho pasos:

Especificar el objetivo de la base de datos. Definir las tablas que se necesitan enla base de datos. Especificar qué campos se requieren en cada tabla. Especificar la llave principal de cada tabla. Definir el tipo de dato que se va a manejar en cada campo. Ajustar los datos Definir las relaciones entre las tablas. Introducir los datos y crear todos los objetos necesarios.

Evidentemente el anterior es un proceso iteractivo que se debe repetir de manera contínua, inclusive aún trabajando el sistema, con el propósito de hacer mejoras sistemáticas. Cuando es el caso, es decir cuando se trata de un rediseño o un trabajo de reingeniería, es necesario hacer un análisis del por qué la base de datos en cuestión no cumplió con las expectativas y requerimientos deseados. Huelga decir que no es el caso de esta investigación.

1.3 Marco Teórico

La teoría que da sustento al rigor científico que requiere este trabajo es la Teoría General de Sistemas Aplicada (TGSA). Este Enfoque Sistémico ó Paradigma de Sistemas, como también se le conoce, resulta ser una herramienta muy útil para el diseño de sistemas en general -y los sistemas de información no son la excepción- en virtud de que brinda una visión en la que se involucran muchas otras ciencias e interpretaciones filosóficas para la representación de la realidad, lo cual implica un cuestionamiento a fondo del cómo funcionan los sistemas y a un cambio de paradigma o forma de entender éstos. Adicionalmente, como señala John Van Gigch: “La TGSA postula funciones del diseño de sistemas comunes al proceso de diseño de todos los sistemas como: toma de decisiones, implantación de objetivos, cuantificación, medición, evaluación, optimización, sub-optimización, planeación, control, diagnóstico, etc.” (1987). La Fig. 1.2 muestra la interrelación de algunas de estas funciones del diseño. Los sistemas así diseñados son más ricos ya que parten de modelos de decisión heurísticos (técnicas de la indagación y el descubrimiento) (Real Academia, 2001) y algorítmicos teniendo en cuenta indicadores sociales y conceptos como la calidad de vida de los individuos.




Investiga el qué

(contenidos y

métodos)

Planeación y

Acción

“Cómo”

Control (regulación)

Aprendizaje

Figura 1. 2 Interrelación de las funciones del diseño de sistemas.

Fuente: Elaboración propia.

Cabe señalar aquí que la Teoría General de Sistemas da los

elementos para la comprensión, análisis, estudio y diseño de los sistemas en general ya que se encarga del estudio de los sistemas de complejidad organizada y no aborda de manera restrictiva a los sistemas de información, como frecuentemente se le asocia. Si bien es cierto que la presente investigación sí tiene que ver con estos últimos, es debido a que éstos también pueden ser estudiados a la luz de la TGSA. Como se podría expresar en términos matemáticos: El conjunto de los sistemas de información pertenece al rango de la función TGSA mas no de manera exclusiva. En lo particular, dada la naturaleza de la investigación de ser un sistema de información de aplicación inmediata a la administración de una microempresa, se hizo uso de la Metodología de Checkland o también denominada Análisis Aplicado de Sistemas. Evidentemente se está ante un problema difícil de estudiar mediante el método rigurosamente científico de medición, experimentación, hipótesis, predicción, argumentación formal, etc.; Luego entonces se hace necesario la utilización de una metodología que trate de encontrar regularidad en los eventos y traer casos particulares bajo generalizaciones, teorías y leyes; aplicando la metodología del método científico modificada apropiadamente para el dominio de sistemas “flexibles” basadas en la demostración de los deseos, ansiedades, placeres y dolores del ser humano y sin excluir la investigación moral. (Van Gigch, 1987). E inclusive el propio Van Gigch va más allá citando a Checkland: “el paradigma de ciencia y el paradigma de sistemas se complementan entre sí. No existe contradicción al reclamar que ambos pueden coexistir y están integrados en el contexto de la ciencia”. Ahora bien, ¿por qué específicamente la Metodología de Checkland y no otra? Peter Checkland con experiencia profesional en el campo de la Administración dentro de la industria vivió de manera personal la problemática de abordar problemas sociales, políticos y humanos con el método científico, en virtud de lo cual desarrolló su Metodología para Sistemas Suaves (SSM por sus siglas en inglés) por ser aplicable a los Sistemas Estructurados de las organizaciones humanas como es el caso de la Administración de una Microempresa. Esta consta básicamente de 7 pasos los




cuales son: 1) Investigación del Problema Estructurado, 2) Muestra del Problema a través de gráficas enriquecidas. 3) Definición de fondo de los Sistemas Relevantes (Cliente, Actores, Proceso de transformación, Weltanschauung –visión del mundo, Dueño, Restricciones ambientales). 4) Modelos Conceptuales. 5) Comparación de los puntos 2 y 4. 6) Cambios factibles deseables. 7) Acción para mejorar la situación problemática. (Checkland, 1994). La Tabla 1.1 muestra esta metodología y sus fases.

Tabla 1. 1 Fases de la metodología de Checkland

Fuente: (Checkland, 1994)

METODOLOGÍA DE CHECKLAND

No.

FASE

1 Investigación del Problema Estructurado

2 Muestra del Problema a través de gráficas enriquecidas

3 Definición de fondo de los Sistemas Relevantes(Cliente, Actores, Proceso de transformación, Weltanschauung–visión del mundo, Dueño, Restricciones ambientales)

4 Modelos Conceptuales

5 Comparación de los puntos 2 y 4

6 Cambios factibles deseables.

7 Acción para mejorar la situación problemática

En lo concerniente al andamiaje teórico de las Bases de Datos Relacionales –en el siguiente apartado se presenta este concepto de manera sucinta y en el Capitulo 3 se abordan con mayor profundidad- el soporte lo brindan los trabajos presentados por el matemático y químico inglés, prócer de la computación y padre de las Bases de Datos Relacionales el Dr. Edgar Frank Codd (1923-2003). La Figura 1. 3 muestara su fotografía.




Figura 1. 3 Fotografía del Dr. Edgar F. Codd.

Fuente: (Obituario de Edgar F Codd)

Es específicamente en el artículo denominado “Un modelo relacional de datos para grandes bancos de datos compartidos" ("A Relational Model of Data for Large Shared Data Banks") donde el Dr. Codd publica sus trabajos en la Revista “Communications of the ACM” (1970 No. 6).

En dicho trabajo define el modelo relacional y publica trece reglas para la evaluación de los sistemas manejadores de bases de datos relacionales (SMBDR ó SGBDR). De esta forma es como nacen las bases de datos relacionales. (Communications of the ACM, 1970). En el Anexo 1 se presentan de manera puntual las trece reglas del Dr. Codd para la evaluación de un SGBDR.

1.4 Marco Conceptual

Finalmente en este capítulo se presenta el Marco Conceptual que deja en claro las definiciones torales que dan pauta a este trabajo. La razón es que es imprescindible que antes de entrar propiamente en materia – para este caso abordar propiamente dicho el diseño del sistema de información- se deje plenamente constancia de los conceptos que sirven de soporte a toda la investigación. Una forma de presentar estos conceptos es por medio de la denominada pirámide conceptual (Galindo Soria L. , 2006). Esta mecánica de




presentar los conceptos permite que de manera gráfica y simplificada se den los conceptos fundamentales en cuestión. La Figura 1. 4 muestra la pirámide conceptual de este trabajo.

SISTEMAS CIENCIAS SOCIALES

CLASIFICACIÓN DE LAS EMPRESAS POR S U TAMAÑO

CLASIFICACIÓN DEL NEGOCIO POR SU GIRO

NE

GO

CIO

S E

N G

RA

L

NE

GO

CIO

S M

IXT

OS

NE

GO

CIO

S E

N E

SP

E.

MIC

RO

EM

PR

ES

A

PE

QU

EÑ

A E

MP

RE

SA

ME

DIA

NA

EM

PR

ES

A

AD

MIN

IST

RA

CIÓ

N

EC

ON

OM

ÍA

PS

ICO

LO

GÍA

MA

TE

RIA

LIS

MO

AD

MIN

IST

RA

CIÓ

N

(PLA

NE

AC

IÓN

, O

RG

AN

IZA

CIÓ

N,

D

IRE

CC

IÓN

, C

ON

TR

OL)

SIS

TE

MA

S

BLA

ND

OS

SIS

TE

MA

S D

UR

OS

SIS

. D

E I

NF

OR

MA

CIÓ

N

SIS

IST

EM

A

PO

LÍT

ICO

SIS

TE

MA

A

MB

IEN

TA

L

PLANEACIÓN

AN

ÁLIS

IS

DIS

EÑ

O

CO

NS

TR

UC

CIÓ

N

CO

NT

RO

L

DISEÑO SISTEMA DE INFORMACIÓN ADMINISTRACIÓN MICROEMPRESA NEGOCIO DE ARTESANÍAS

DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA ADMINISTRAR UNA

MICROEMPRESA: CASO DE ESTUDIO: NEGOCIO PARA COMERICALIZAR ARTESANÍAS

Figura 1. 4 Pirámide Conceptual

Fuente: Elaboración personal a partir de (Galindo Soria L. , 2006)

De donde se pueden ubicar en un solo golpe de vista los conceptos fundamentales que a continuación se detallan:

Diseño.- es el proceso previo de configuración mental en la búsqueda de una solución en cualquier campo del saber humano.




Sistema de información.- es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa mediante el uso de un equipo de cómputo.

Administración.- también denominada Administración de

empresas o Ciencia Administrativa, es una ciencia social que estudia la organización de las empresas y la manera como gestionan los recursos, procesos y resultados de sus actividades.

Micro-empresa.- también denominada PYME, es un concepto un tanto variante pues depende de la legislación de cada país. La Unión Europea por ejemplo distingue por ejemplo a una microempresa como aquella organización que tiene un número igual o menor a 10 empleados y/o su volumen de facturación es igual o inferior a 2 millones de euros y/o su balance general anual es igual o menor a los 2 millones de euros. (Secretaría de Economía)

Base de datos.- es un modelo de un aspecto de la realidad

de una organización (Kent, 1978)

Otra definición la proporciona el profesor Ricardo González Lozano (2009) al señalar que se puede decir de manera sencilla que se trata de un conjunto de datos organizados y relacionados entre sí, en relación con algún propósito o tema en concreto.

Proceso de diseño de una base de datos.- es la

actividad de representar, las clases, los atributos y las relaciones entre las bases de datos. (Beynon-Davies, 2004)

Los anteriores conforman los conceptos básicos que se consideran son suficientes para poder abordar la presente investigación. Con el propósito de no hacer este apartado del Marco Conceptual, una sección en la que se presente un largo listado de conceptos interminable, se prefirió enviar los demás conceptos a una sección del Glosario que se presenta después del capítulo 5 de las Conclusiones.

Por consiguiente ya se está en posibilidad de entrar en materia en cuanto al sistema de información que se abordará.

10

“Yo no estudio para saber más,

sino para ignorar menos”

Sor Juana Inés de la Cruz

( 1651- 1695)

CAPÍTULO 2

ANÁLISIS Y DISEÑO DEL SISTEMA

DE INFORMACIÓN

http://es.wikipedia.org/wiki/1651





CAPÍTULO 2

ANÁLISIS Y DISEÑO DEL SISTEMA DE INFORMACIÓN



En este segundo capítulo se abordan tanto el análisis

del sistema actual como el diseño del sistema propuesto. Cada

uno dando nombre a un subcapítulo. En el primero, se presentan

los antecedentes, la misión, visión y objetivos de la empresa, su

estructura organizacional, diagramas y tabla sistémica del sistema

actual. En la fase de diseño se identifican los procesos, se

presentan los diagramas de Gant y PERT, el marco normativo del

sistema futuro, el perfil del usuario, la herramienta de

construcción, el análisis costo beneficio, el diseño de las entradas

y salidas, el diseño de la naturaleza jerárquica de la base de

datos y el diseño de la base de datos en modo relacional.




Preámbulo

Toda vez que se ha ubicado el trabajo dentro del contexto en el que se desarrollará y que se han establecido la metodología rectora de la investigación, así como la teoría que servirá de soporte y se han dejado en claro los conceptos básicos que se utilizarán; se puede proceder al análisis del problema a resolver, mismo que partirá de la Fase de Análisis. Una manera gráfica de visualizar lo que se debe hacer se muestra en la Figura 2. 1 muestra de una manera gráfica la identificación de lo que se tiene que hacer en una investigación.

LO QUE SE

TIENE QUE

HACER

PROCESO SALIDA ENTRADA

LO QUE

SE TIENE

LO QUE

SE DESEA

Figura 2. 1 Identificación de lo que se tiene que hacer en una investigación

Fuente: Elaboración propia

En virtud de que se trata de un sistema informático dentro de una empresa, es necesario hacer un estudio cronológico de la misma. Lo cual tal vez parecerá obvio; no obstante en muchas ocasiones no se efectúa, lo que por demás resulta lógico. Es decir, se requiere indagar sobre el pasado de la organización, el estado actual de la misma y sólo entonces proceder a plantear la alternativa de solución o diseño del sistema de información.




2.1 Fase de Análisis del Sistema de Información

2.1.1 Antecedentes Históricos de la Empresa

Los antecedentes históricos de la empresa son de suma importancia, pues sin ellos se estaría efectuando un diseño de un sistema del cual no se tienen antecedentes. Es por ello que esta fase de análisis debe iniciar con un estudio de las raíces del sistema. Si no se conoce el pasado no es posible entender el presente y menos aún tratar de proponer alternativas de solución para el futuro. A manera de ficha cronológica se presentan algunas fechas que se consideran, fueron importantes en el devenir histórico del negocio que se abordará en esta investigación:

1866 Don Benito Juárez García de paso por Actopan Hidalgo y con su gabinete itinerante pernocta precisamente en el sitio donde hoy se ubica el Negocio para la Comercialización de Artesanías denominada “La Casa de los Azulejos”. Recuérdese que es una época de turbulencia política en el país, ante el ofrecimiento de la Corona de México a Maximiliano de Habsburgo por la denominada Junta de Nobles.

1867-1900

El inmueble es ocupado como hotel, caballeriza y casa habitación.

1900-1973

Se instalan diversos tipos de negocios en este lugar. Desde una farmacia hasta un restaurante.

1974-2002 El predio en cuestión pasa a poder de la familia Domínguez y es arrendado, instalándose ahí otros giros comerciales que van desde una veterinaria y rosticería hasta una tienda de muñecos de peluche.

2003 Después de un juicio por la vía civil, se recupera el local ya que a pesar del deterioro del lugar y del retraso en sus rentas, el inquilino en cuestión se negaba a desocupar el lugar.




2004-2006 Se realizan obras de reconstrucción y acondicionamiento ya que el estado físico del local era inclusive peligroso para sus ocupantes.

28-dic-2006 Abre sus puertas el Negocio para la comercialización de Artesanías denominado “La Casa de los Azulejos”.

2.1.2 Identificación y obtención de: Misión, Visión, Objetivos, Funciones y Políticas de la empresa.

Después de ver y entender donde está la empresa y como es que está en las condiciones en las que se encuentra, es necesario conocer a la organización en sí, hacia dónde se dirige, su filosofía etc. Una forma objetiva de realizarlo es estableciendo su Misión, Visión, Objetivos, Funciones y Políticas. MISIÓN Distribuir los productos artesanales de la más alta calidad producidos en la región. VISIÓN El negocio se visualiza como la tienda de artesanías más importante no sólo en la localidad sino en la región entera. OBJETIVOS El objetivo de la empresa es hacer que cualquier turista que visite esta localidad adquiera al menos un producto artesanal en este negocio.

FUNCIONES PRINCIPALES Se distinguen las siguientes funciones principales:

Buscar y localizar productores de artesanías. Identificar los productos de mayor demanda. Identificar los productos que mejor precio tienen. Evaluar los productos antes y durante la adquisición. Comprar los productos. Organizar catálogos y/ó inventarios Almacenar los productos de forma segura. Exhibir los productos. Vender los productos.




POLÍTICAS El negocio en cuestión tiene las siguientes políticas:

El elemento principal de la empresa es el cliente. La honestidad con proveedores y clientes es fundamental. En la medida de lo posible se brindará un valor agregado a

los productos ofrecidos. Los productos comercializados serán preferentemente de

fabricación local o al menos nacional. Se promoverá en todo momento la satisfacción total del

cliente.

2.1.3 Identificación de la estructura organizacional de la empresa.

Es necesario conocer plenamente la estructura organizacional de la empresa antes de desarrollar cualquier proyecto para ella, ya que ayudará a ubicar a las áreas que se pretende apoyar así como la posible relación que tiene con otras áreas de la organización. Además facilita la selección de las personas que deben ser entrevistadas y a quien se debe solicitar información. La Figura 2. 2 muestra el organigrama del negocio estudiado.

Figura 2. 2 Organigrama del Negocio. Fuente: Elaboración propia

Se puede observar que aunque se trata de una empresa pequeña, cuenta con la estructura fundamental para su operación, dejando a un despacho externo actividades tales como la contabilidad.




2.1.4 Diagrama de casos de uso

El diagrama de CASOS DE USO proporciona a partir de la información elemental respecto de la operación del área sobre la que se realizará el sistema, una visión general del mismo. Con ello se puede deducir, con la ayuda de otras herramientas, el total de los elementos que se requerirán dentro del sistema informático. La Figura 2. 3 presenta el Diagrama de Casos de uso para el Negocio del Caso de Estudio de este proyecto.

COMPRAR

ARTESANIAS

ETIQUETAR ARTESANIAS Y REGISTRAR EN

INVENTARIO

DESIGNAR ALMACEN

TEMPORAL

EXHIBIR PARA VENTA

VENDER

ENTREGAR REPORTES Y RECURSOS

PROVEEDOR AUXILIAR

RESPONSABLE DE TIENDA

DESPACHO EXTERNO

CLIENTE

Obsérvese como surgen 3 grupos de actividades, de donde se concluye que al menos existirán 3 subsistemas

Escenario Dialogo Actor

Figura 2. 3 Diagrama de Casos de Uso para el Negocio del Caso de Estudio





2.1.5 Diagrama de flujo de datos Nivel 0 (DFD)

El diagrama de flujo de datos (DFD) inicia en el nivel 0, donde únicamente se aprecia que existe un sistema. Éste tiene entradas (de diversos tipos) y después de transformaciones proporciona salidas (de diversos tipos), sin poder tener en este punto respuestas a interrogantes tales como: ¿Por qué?, ¿Cómo?, ¿En qué secuencia? Etc. En la Figura 2. 4 se muestra el Diagrama de Flujo de Datos para “La Casa de Los Azulejos”.

NIVEL 0

PRODUCTOS

DINERO

ORDENES DE TRABAJO

INSUMOS

ARTESANIAS

DINERO

REPORTES DE ACTIVIDADES MERMA Y DESPERDICIO

SISTEMA DE INFORMACIÓN

PARA LA ADMINISTRACIÓNDE UN NEGOCIO

PARA COMERCIALIZAR DE ARTESANIAS

Figura 2. 4 Diagrama de Flujo de Datos Nivel 0 para el Negocio: “La Casa de los Azulejos".


Se puede advertir que este Diagrama de Flujo de Datos Nivel 0 es

prácticamente una caja negra en la que se pueden ver simplemente entradas y salidas.

2.1.6 Diagrama de flujo de datos Nivel 1 (DFD)

A partir del diagrama de casos de uso modificado, es muy sencillo trasladar la secuencia obtenida a un diagrama de flujo de datos (DFD) que permite observar los contenedores de datos que se requieren, las secuencias, acciones, procesos, etc.

La Fig. 2.5 muestra el Diagrama de Flujo de Datos Nivel 1 para el Caso de Estudio.




P1

COMPRAR ARTESANIAS

P2

ETIQUETAR ARTESANIAS

P3

REGISTRAR ARTESANIAS

P4

EXHIBIR PARA VENTA

P5

VENDER

P6

ENTREGAR REPORTES Y

DINERO

PROVEEDOR

DESPACHO

EXTERNO

BD2 COMPRAS . . .

BD3 INVENTARIOS . . .

BD4 VENTAS . .

Artesanía (materia prima)

Datos de artesanía

Datos de la compra

Artesanía (RECLASIFICADA)

Artesanía (producto para venta)

Datos de artesanía vendida

Datos de las compras

Datos de existencias y movimientos


Comprobantes de venta

Datos de venta

Detalle y resumen de reportes

Datos de las ventas

NIVEL 1

Datos de artesanía y etiqueta

Datos de artesanía y ubicación



Figura 2. 5 Diagrama de Flujo de Datos Modificado Nivel 1 para el negocio caso de estudio.


2.1.7 Diagrama a bloques modificado.

A través del diagrama de flujo en bloques se puede determinar la secuencia en que los procesos intervienen así como algunos de los requerimientos más importantes. La Figura 2. 6 muestra el Diagrama en bloques modificado para el Caso de Estudio.




PROVEEDOR

COMPRAR ARTESANIAS



EXHIBIR ARTESANIAS

VENDER ARTESANIAS

ENTREGAR REPORTES Y RECURSOS

DESPACHO EXTERNO

REMISION

ETIQUETAS

INVENTARIO

-- ------- -

REMISION

REMISION

Figura 2. 6 Diagrama en Bloques Modificado para el Caso de Estudio.


2.1.8 Identificación de los Procesos Actuales

Partiendo de la lista de funciones del área particular de trabajo y el DFD se construye una lista de los procesos que actualmente se realizan en el área, y que por consiguiente son los que desarrolla el sistema actual de manera manual:

COMPRA DE ARTESANIAS.- Los proveedores (artesanos) ofrecen sus productos en el negocio, cuando son productos que nunca se habían comprado se negocia, hasta alcanzar un acuerdo respecto del precio y futuras operaciones, cerrando el trato con una remisión simple.




ETIQUETAR ARTESANÍAS.- Una vez entregadas las artesanías se les adhiere una etiqueta en la que se encuentra el número de artesano y el precio.

REGISTRAR ARTESANÍAS.- en un libro se anota la fecha en que se compra, el precio de compra, una breve descripción del producto y el precio de venta.

EXHIBIR ARTESANÍAS.- se colocan las piezas en anaqueles de exhibición, registrándose la fecha en que esto sucede.

VENDER ARTESANÍAS.- Se venden las artesanías de acuerdo a los precios indicados en las etiquetas, registrándose la venta en el libro y entregando una remisión simple junto con la artesanía.

ENTREGAR REPORTES.- Cada 2 semanas se entregan las copias de las remisiones de venta, así como copias del libro y las remisiones de compra a un despacho externo, para que realice los procesos contables, y autorice las cantidades de dinero disponible para comprar artesanías para el siguiente período.

2.1.9 Identificación, recopilación y obtención de todo tipo de documentos e información

La recopilación de los documentos e información da una idea muy

clara del tipo de organización de que se trata. Por ello es necesario conocer la forma precisa en que se realizan las operaciones y recabar información documental, ó referencias que aporte información o ayuda al proyecto. La Tabla 2. 1 y la Tabla 2. 2 presentan la relación de los documentos obtenidos del Sistema Actual. El código de la primera columna hace alusión a que tales documentos constituyen el Anexo 2 (ANE2) y el número después del guión al número progresivo dentro de éste de cada uno de ellos.




Tabla 2. 1 Recopilación de documentos del sistema actual (1ra. parte)


CÓDIGO DOCUMENTO CARACTERÍSTICA

ANE2.1 Remisión de compra Es un documento importante pues informa sobre el número de artículos comprados; costo de los mismos; datos de los proveedores (no siempre) y características de los productos.

ANE2.2 Libro de registro (inventario)

Se trata de una base de datos manual (carpeta) en la que se encuentran asentados los artículos que se han adquirido junto con sus códigos o claves con los cuales son identificados de manera única.

ANE2.3 Remisión de venta Es una nota no foliada que se entrega al cliente y en la que se anotan los artículos vendidos, su descripción y su precio.

ANE2.4 Estado de Cuenta de Proveedor

Es un documento por proveedor en el que se anota principalmente la mercancía que ha dejando a consignación y el monto de lo que se le adeude.




Tabla 2. 2 Recopilación de documentos del sistema actual (2a. parte)


CÓDIGO DOCUMENTO CARACTERÍSTICA

ANE2.5 Reporte de ventas Es una hoja en la que se anota el total de ventas diarias, se incluye además de la fecha, el número de artículos, su código y su precio.

ANE2.6 Reporte de compras Es un concentrado de las compras realizadas organizado por fechas. Su utilidad radica en poder ver el historial de los precios de compra.

ANE2.7 Reporte de Cuentas por Pagar

Es un concentrado que muestra de manera compacta el total de las cuentas por pagar. Se obtiene con base en el Estado de Cuenta de Proveedor.

ANE2.8 Concentrado de Apartados

Se trata de una base de datos manual (cuaderno) en el que se anotan los artículos que han sido apartados para su posterior adquisición. Se anota el nombre del cliente, la cantidad de artículos, sus códigos, su precio total y la cantidad que se está dejando a cuenta para garantizar el apartado.




2.1.10 Alcances Presentes y Futuros

Es necesario establecer cuales son los alcances del sistema actualmente, para a posteriori definir los alcances del nuevo sistema con base en los tiempos y los costos que se deseen.

Actualmente el sistema opera totalmente de forma manual, recopilando la información en papel, de diferentes formas, inclusive en fragmentos irregulares y poco legibles, depositando los datos en bolsas de plástico, cuadernos y contenedores que dificultan la interpretación y consolidación de la información hacia los reportes.

El sistema que se propone debe facilitar la captura de la información, imprimir los comprobantes correspondientes, y permitir la emisión de reportes en cualquier momento, inclusive a través de la Internet, ya sea por los despachos externos de asesoría y/o consultoría o por la administración, o directivos.

2.1.11 Elaboración de la Tabla Sistémica del Sistema Actual

Es de suma importancia conocer los Elementos del Sistema Actual y entre más conciso se haga mejor. Una excelente forma de realizarlo es por medio de la denominada Tabla Sistémica (Galindo Soria L. , 2006). Su ventaja radica que en un solo documento y de un solo vistazo se pueden percibir todos los elementos. En la Tabla 2. 3 se muestra la Tabla Sistémica del Sistema Actual. Cabe hacer mención que en estos momentos se está analizando todavía el estado en el que se encuentran las cosas, por decirlo en términos coloquiales, el hoy del sistema.




Tabla 2. 3 Tabla Sistémica de los Elementos del Sistema Actual. Fuente: Elaboración propia a partir de (Galindo Soria L., 2006)

TABLA SISTÉMICA DE LOS ELEMENTOS DEL SISTEMA ACTUAL

SUB SISTEMA ENTRADAS PROCESO SALIDAS TIEMPOS Y

VOLÚMENES

DATOS CONTROLES DISTRIBUCIÓN

Compras

Número, descripción y precio de productos ofertados

Compra de artículos a mejor precio

Facturas, remisiones y notas de venta

De 15 minutos a 1 hora, / Mínimo 1 compra por semana

Datos del Proveedor, número, descripción y precio de productos

Proveedor calificado, precio no mayor al 10% anterior

Gerente

Responsable de Almacén

Almacén Facturas, remisiones y

notas de venta y margen de ganancia

Etiquetado de productos, asignación precio de venta y alta en inventario

Etiquetas con código y precio

En función del número de artículos de 10 min a 1 hora / Cada compra

Código del producto, Precio de venta

Un código único por producto (No. de serie). Precio autorizado por gerencia

Vendedor,

Gerente

Ventas Producto

etiquetado Ubicación de producto para su exhibición y venta

Productos ubicados para su exhibición y Facturas de Venta

Cada que se realiza una transacción comercial / Una factura por venta

Número, descripción, precio de productos vendidos y venta total

Folio de facturas

Gerente y Despacho Externo

Ventas Facturas de

las ventas del Día

Emisión de reporte de venta del Día

Reporte de venta del Día

10 min / 1 vez al día

Número, descripción, precio de productos vendidos y venta total del día

Vo. Bo. del Gerente de la Tienda

Despacho Externo y Socios de la Tienda

Despacho Externo

Concentrado de ventas diarias

Preparación de pago de impuestos

Notificación al SAT

1 hora / 1 vez al mes

Monto mensual de venta y total de artículos en inventario

Vo. Bo. del Gerente de la Tienda

SAT y Socios de la Tienda

25

2.2. Fase de Diseño del Sistema de Información

2.2.1 Identificación de los procesos del Sistema Propuesto

Ya se está en estos momentos en posibilidad de comenzar a hablar del Sistema de Información que se tendrá a futuro, en otras palabras, se comenzará a visualizar el “mañana” del sistema.

El sistema que se propondrá deberá incluir algunos procesos mínimos, así que es importante establecer cuales son éstos dentro del nuevo sistema. Adviértase que algunos de estos elementos ya forman parte del sistema en su “estado presente”, por ende pudiera a simple vista parecer una redundancia del apartado 2.2.8 sobre la identificación de los Procesos Actuales; no obstante, como se verá a continuación, existen elementos que ya de entrada hacen alusión a un sistema computacional.

Luego entonces el sistema debe procesar toda la información con la ayuda de las tecnologías de información y comunicaciones, registrando electrónicamente las actividades realizadas. Se distinguen los siguientes procesos:

COMPRA DE ARTESANÍAS.- Módulo mediante el cual se registran las compras, en una interface amigable para que la captura sea rápida y simple.

ETIQUETAR ARTESANÍAS.- Módulo que emite las etiquetas codificadas para los productos que se encuentran en inventario.

REGISTRAR ARTESANÍAS.- Módulo de análisis para clasificar los productos que se compran, para poder hacer comparativos por agrupamiento.

EXHIBIR ARTESANÍAS.- Módulo en el que se establece la ubicación en la que se colocan los productos, llevando un control específico para inventarios físicos.

VENDER ARTESANÍAS.-Registro de la venta de los productos, así como el ingreso de dinero.

REGISTRAR APARTADO DE MERCANCIAS.- Subsistema mediante el cual se realiza una venta a plazos. La mercancía ya no puede ser vendida dado que se ha dado un anticipo para su apartado.

ENTREGAR REPORTES.- Módulo que genera la transferencia y/o entrega de reportes.




El sistema debe procesar toda la información con la ayuda de las tecnologías de información y comunicaciones, registrando electrónicamente las actividades realizadas y pudiendo de esta forma obtener de manera automática los siguientes reportes:

REPORTE DE LOS PROVEEDORES.- Módulos que permite conocer concentradamente la información de las operaciones de proveedores.

REPORTE ESTADÍSTICO DE COMPRAS.- Módulo que genera información estadística de las compras, en diferentes formas (volumen, estacionalidad, etc.).

REPORTE ESTADÍSTICO DE VENTAS.- Módulo que permite interpretar los movimientos de venta, como tendencia por grupo, por producto, etc.

REPORTE ESTADÍSTICO DE TODO AQUELLO POR LO QUE PREGUNTAN LOS VISITANTES.- Mediante el registro de los productos por lo que los clientes potenciales preguntan, permite saber que es lo que la población objeto requiere y no se tiene.

REPORTE ESTADISTÍCO DE FLUJO DE CAPITAL (BRUTO).- Para determinar como se mueve el capital, por tiempo, por segmento, la tendencia de saldos etc.

ENVIO DE INFORMACIÓN PERIÓDICAMENTE VIA INTERNET.- Módulo que condensa los reportes y los envía a través de la Internet, a la Dirección, y al despacho externo, de forma totalmente automatizada.




2.2.2 Elaboración del Diagrama de Gantt

En el desarrollo de Proyectos -y los de sistemas de información no son la excepción- es imprescindible contar con un plan de trabajo que permita conocer los tiempos requeridos para el desarrollo de los mismos; aunque sea sólo una estimación, ya que se sabe que en la realidad pueden extenderse los tiempos mucho más allá de lo planeado. Una técnica para lograrlo son las Gráficas o Diagramas de Gantt, las cuales reciben su nombre en honor de su desarrollador el ingeniero mecánico, de origen norteamericano, Henry Laurence Gantt, quien en 1910 presentó esta técnica que consiste básicamente en utilizar barras horizontales para indicar el tiempo que se requerirá para realizar determinada actividad. La Tabla 2. 4 muestra el Diagrama de Gantt para el desarrollo de este proyecto.

Tabla 2. 4 Diagrama de Gantt del Proyecto en su conjunto.


HERRAMIENTAS LUGAR DUR INICIO FIN COSTO 04-fe

b-09

11-fe

b-09

18-fe

b-09

PROPUESTA 1 12/02/2009 13/02/2009 1

REAL 1 12/02/2009 13/02/2009 100,00$ 1

PROPUESTA 1 13/02/2009 14/02/2009 1

REAL 1 13/02/2009 14/02/2009 100,00$ 1

PROPUESTA 1 14/02/2009 15/02/2009 1

REAL 1 14/02/2009 15/02/2009 50,00$ 1

PROPUESTA 2 15/02/2009 17/02/2009 1

REAL 3 15/02/2009 18/02/2009 300,00$ 1 1

PROPUESTA 1 17/02/2009 18/02/2009 1 1

REAL 2 18/02/2009 20/02/2009 300,00$ 1

PROPUESTA 1 18/02/2009 19/02/2009 1

REAL 1 20/02/2009 21/02/2009 100,00$ 1

PROPUESTA 1 19/02/2009 20/02/2009 1

REAL 2 21/02/2009 23/02/2009 50,00$ 1

PROPUESTA 10 20/02/2009 02/03/2009 1

REAL 15 23/02/2009 10/03/2009 500,00$ 1

PROPUESTA 5 02/03/2009 07/03/2009

REAL 10 10/03/2009 20/03/2009 150,00$ M S-OFFICE ACTOPAN, HGO

M S-OFFICE CUBICULO

M S-OFFICE ACTOPAN, HGO

M S-OFFICE CUBICULO



M S-OFFICE CUBICULO

M S-OFFICE CUBICULO

FECHAS

M S-OFFICE CUBICULO




2.2.3 Elaboración del Diagramas PERT

Otra técnica para presentar los requerimientos de tiempo lo constituyen los Diagramas PERT. Se trata de una herramienta usada para programar, organizar y coordinar tareas dentro de un proyecto. PERT son las siglas en inglés de “Program Evaluation Review Technique” (Técnica de Evaluación y Revisión de Proyectos). Esta metodología fue desarrollada en la marina de los EE.UU., en conjunto con Bozze, Allen y Hamillton en 1958 para manejar el programa de misiles submarinos Polaris. La Figura 2. 7 muestra el Diagrama de PERT con los requerimientos de tiempo para este proyecto.




2d2d

Act.1.1.1.-

Identificar

Misión, Visión.

0d0d

Subfase 1.1-

Con. Del M.A.

0d0dFase 1.- Análisis

0d15d

Subfase 1.3.-

Propuesta Gral.

De Solución del

“Mañana”.

0d13d

Subfase 1.2.-

Identificación y

Análisis del hoy. 2d15d

Act.1.2.1.- Identificar

y Analizar Sis. Act.

4d19d

Act. 1.3.1.-

Elaborar Diag.

Gantt y PERT.

2d2d

Act.1.1.2.-

Identificar

Estructura Org.

2d2d

Act.1.1.3.-

Identificar Área

Particular.

2d4d

Act.1.1.4.-

Identificar

Funciones del

Área Particular.

3d7d

Act.1.1.5.-

Elaborar DFD.

3d10d

Act.1.1.6.-

Identificar

Procesos

involucrados.

6d13d

Act.1.1.7.-

Identificar

Documentación.

2d9d

Act.1.1.8.-

Identificar

Alcances.

2d21d

Act.1.3.2.-

Elaborar Marco

Normativo del

Futuro.

2d23d

Act.1.3.3.-

Definir

funciones del

Nuevo Sistema.

1d22d

Act.1.3.4.-

Definir

herramientas de

construcción. 2d23d

Act.1.3.5.-

Elaborar Nuevo

DFD

2d25d

Act.1.3.6.-

Definir

Elementos del

Nuevo Sistema

2d27d

Act.1.3.7.-

Realzar el

Análisis Costo-

Beneficio

15d13Fase 2.- Diseño

0d27d

Subfase 2.1.-

Evaluación del

Anál. y Diseño

de Est. Básica.

3d30d

Act. 2.1.1.-

Diseño de Est.

Bás. Diccionario

de Datos.

0d30d

Subfase 2.2.-

Diseño

Preliminar

2d32d

Act. 2.2.1.-

Diseño de la

Arquitectura del

Sistema.

2d34d

Act 2.2.2-

Diseño de las

Salidas.

2d36d

Act 2.2.3-

Diseño de las

Entradas.

1d37d

Act 2.2.4-

Diseño de la

Tabla Visual

(VTOC)

1d37d

Act 2.2.5-

Diseño de los

Procesos

Modelo Warnier-

Orr.

0d37d

Subfase 2.3.-

Diseño

Detallado

3d40d

Act. 2.3.1.-

Diseño de la

Estructura de la

BD con el

Modelo E-R

2d42d

Act. 2.3.2.-

Diseño de la BD

con el Modelo

Relacional.

0d42d

Fase 3.-

Construcción

0d52d

Fase 4.-

Implantación.

4d44d

Subfase 3.1.-

Construcción del

Sistema de

Información

4d48d

Act. 3.1.1.-

Construcción de

la BD.

2d54d

Subfase 4.1.-

Implantación del

Sistema de

Información.

3d57d

Act. 4.1.1.-

Implantación de

la BD.

2d50d

Act. 3.1.2.-

Construcción de

las Pantallas de

Entrada

2d56d

Act. 4.1.2.-

Implantación de

las Pantallas de

Entrada.

2d50d

Act. 3.1.3.-

Construcción de

las Pantallas de

Salida.

2d56d

Act. 4.1.3.-

Implantación de

las Pantallas de

Salida.

2d52d

Act. 3.1.4.-

Construcción de

los Reportes

Impresos.

3d60d

Act. 4.1.4.-

Implantación de

los Reportes

Impresos.

Figura 2. 7 Diagrama de PERT del proyecto.





2.2.4 Elaboración del Marco Normativo del Sistema Futuro

La Elaboración del Marco Normativo del Nuevo Sistema es una pieza clave del Sistema de Información, ya que permite definir con el Usuario lo que éste espera. Es aquí donde deberán definirse todas aquellas políticas, reglas, normas y restricciones a las que deberá sujetarse el Nuevo Sistema. En otras palabras lo que hará y lo que no hará el Sistema: Los nuevos flujos, documentos, informes, controles, tiempos y responsabilidades dentro de la organización para apoyar el cabal cumplimiento de las actividades y decisiones involucradas. La firma del Usuario es altamente recomendada.

El negocio para la Comercialización de Artesanías, Caso de Estudio de la presente tesis, se regirá bajo el siguiente Marco Normativo, tal y como se consensuó y estuvo autorizado por las personas involucradas:

La negociación de los precios de compra será función del Responsable de Compras y/o el Gerente.

Los Proveedores (Artesanos) serán apercibidos de lo anterior así como del hecho de que para que su mercancía sea recibida deberá contar con la correspondiente factura, remisión o mínimo un desglose detallado por cada entrega que realicen. La información mínima que deberá contener dicho documento será: cantidad de productos, breve descripción de éstos.

El Responsable de Compras será la persona encargada de mantener al día la base de datos de los Proveedores.

El Responsable del Almacén no recibirá en ningún caso productos que carezcan de la documentación señalada en el punto anterior.

Será función del Responsable del Almacén el asignar el código de los nuevos productos, acordar con el gerente el precio de venta, etiquetarlos (incluyendo tanto código como precio) y darlos de alta en el inventario.

El Vendedor asignará la ubicación física de las nuevas adquisiciones a fin de exhibirlas para su venta, tomando en cuenta las sugerencias del Gerente.




Toda venta al público deberá realizarse con la correspondiente factura, remisión o „ticket‟ de venta, mismo que será generado de manera automática por el Nuevo Sistema.

En los casos en los que por fallas en el suministro de energía eléctrica o fallas en la computadora, no se pueda generar el documento anterior de manera automática, se emitirá un documento de forma manual, mismo que será vaciado en el Sistema de Información una vez que se haya resuelto el problema, archivando el documento que medio para la transacción comercial.

El Sistema descargará del Inventario, de manera automática, los productos de la venta.

Será función del Vendedor emitir el Reporte Diario de Ventas al final del día, mismo que será revisado por el Gerente de la Tienda.

El Gerente de la Tienda deberá subir este Reporte Diario de Ventas al Sistema para su distribución tanto al Despacho Externo como a los Inversionistas, Dueños o Directivos del Negocio.

Será función también del Gerente del Negocio la emisión del Reporte Mensual de Ventas, así como su distribución al igual que el caso anterior.

El Despacho Externo será el encargado de elaborar los reportes necesarios para su presentación ante el SAT para el pago de los impuestos respectivos.

2.2.5 Definición de las Funciones del Nuevo Sistema incluido el Perfil del Usuario La definición de las funciones que desarrollará el Nuevo Sistema,

así como el Perfil del Usuario en este momento del desarrollo del proyecto permiten tener con mayor claridad aquello que hará y también lo que no debe esperarse del Nuevo Sistema y de la persona que interactuará con el mismo.




FUNCIONES

El Nuevo Sistema será capaz de realizar las siguientes funciones:

Almacenar en las Bases de Datos la información relativa a los Proveedores, Clientes, Productos adquiridos, Precios, Transacciones, Impuestos pagados, Ventas Diarias y Ventas Mensuales.

Dar de manera automática el precio de compra y venta de un determinado producto.

Llevar un control de la mercancía existente.

El histórico de los precios a los que se han comprado los diferentes artículos.

Elaborar de manera automática Remisiones de venta, Reporte de venta diaria, Reporte de venta Mensual, Impuestos a pagar.

Conocer el tipo de venta realizada, ya sea al contado o por el Sistema de Apartado.

PERFIL DEL USUARIO La (s) persona(s) que interactúe(n) con el Nuevo Sistema

deberá(n) tener el siguiente perfil:

Tener un mínimo de nivel secundaría a fin de poder comprender los elementos del Sistema.

Aceptar retos de manera tal que aún cuando no sea

experto en el uso de computadoras al menos no se sienta impactado por el uso de la nueva tecnología.

Mostrar disponibilidad para la capacitación que se le debe

dar antes de implantar el Nuevo Sistema.




2.2.6 Determinación de la posible Herramienta de Construcción

En estos momentos ya se está en posibilidad de determinar la

Herramienta con la cual se analizará, se planeará, construirá y finalmente se redactará lo que será el Sistema de Información. Esta determinación permite ir visualizando los requerimientos que se tendrán y su obtención en caso de carecer de las mismas.

La Herramienta a utilizar será: Microsoft Office System 2007, la cual es un conjunto de software de aplicación específica que hizo su aparición en 1989.

2.2.7 Diagrama de flujo de datos modificado Nivel 1 del sistema propuesto En el caso de “La Casa de los Azulejos” el nuevo sistema es

prácticamente igual al anterior, la diferencia sustancial, es que cambia de hacerse a mano, con lápiz y cuaderno a un Sistema de Información Basado en Computadora. La Figura 2. 8 muestra el Diagrama de Flujo de Datos Modificado del Sistema Propuesto.




P1

COMPRAR ARTESANIAS

P2


P3


P4

EXIBIR PARA VENTA

P5

VENDER

P6

ENTREGAR REPORTES Y

DINERO

PROVEEDOR

DESPACHO

EXTERNO

CAT 1 CATALOGO DE PROVEEDORES

BD2 COMPRAS . . .

BD3 INVENTARIOS . . .

Datos del proveedor

Artesanía (materia prima) Artesanía (materia prima)

Datos de artesanía

Datos de la compra

Artesanía (RECLASIFICADA)


Datos de artesanía vendida


Datos de existencias y movimientos


Comprobantes de venta

Datos de venta

Detalle y resumen de reportes

Datos de las ventas

NIVEL 1


Datos de artesanía y ubicación



CAT 2 CATALOGO DE PRODUCTOS

CAT 3 CATALOGO DE COMPRADORES

BD4 VENTAS . .

CAT 4 CATALOGO DE CLIENTES

Figura 2. 8 Diagrama de Flujo de Datos modificado (DFD-M) del Nuevo Sistema Propuesto.


2.2.8 Realización del Análisis Costo-Beneficio

Es importante señalar aquí que el presente análisis se refiere al Proyecto del Sistema de Información y no al Negocio bajo estudio. Aclarado lo anterior, el análisis costo-beneficio del desarrollo del sistema arroja fuertes pérdidas, en virtud de que los egresos superan los 35,000.00 pesos mientras los ingresos son de apenas 6,000.00 pesos, aunque se proyecta la venta del sistema en otras empresas de estructura semejante. La Tabla 2. 5 muestra este Análisis Costo-Beneficio.




Tabla 2. 5 Análisis Costo-Beneficio del Sistema de Información a Desarrollar.


EGRESO

INGRESO UTIL.BRUT SALDO MES DIRECTO RENTA

EQUIPO1

RENTA EQUIPO

2 TOTAL

FEBRERO $

1,500.00 $

555.56 $

555.56 $

2,611.11 $

1,000.00 -$

1,611.11 -$ 1,611.11

MARZO $

3,150.00 $

555.56 $

555.56 $

4,261.11 $

1,000.00 -$

3,261.11 -$ 4,872.22

ABRIL $

2,500.00 $

555.56 $

555.56 $

3,611.11 $

1,000.00 -$

2,611.11 -$ 7,483.33

MAYO $

7,750.00 $

555.56 $

555.56 $

8,861.11 $

1,000.00 -$

7,861.11 -$ 15,344.44

JUNIO $

14,000.00 $

555.56 $

555.56 $

15,111.11 $

1,000.00 -$

14,111.11 -$ 29,455.56

JULIO 0 $

555.56 $

555.56 $

1,111.11 $

1,000.00 -$

111.11 -$ 29,566.67

TOTAL $

35,566.67 $

6,000.00 -$

29,566.67 -$ 29,566.67

La Figura 2. 9 es una gráfica que muestra este análisis.

-$35.000,00

-$30.000,00

-$25.000,00

-$20.000,00

-$15.000,00

-$10.000,00

-$5.000,00

$-

$5.000,00

$10.000,00

$15.000,00

$20.000,00

FEBRERO MARZO ABRIL MAYO JUNIO JULIO

EGRESO

INGRESO

UTIL.BRUT

SALDO

Figura 2. 9 Gráfica del Análisis Costo-Beneficio del Sistema de Información. Fuente: Elaboración propia




2.2.9 Elaboración de la Tabla Sistémica del Sistema de Información Propuesto Es menester ahora definir los elementos Sistémicos del Nuevo

Sistema Informático Propuesto. Para el caso que se presenta son básicamente los mismos elementos del Sistema Manual. Nuevamente se hará uso de la denominada Tabla Sistémica (Galindo Soria L. , 2006). Como se dijo en su oportunidad, su ventaja radica que en un solo documento y de un solo vistazo se pueden percibir todos los elementos. La Tabla 2. 6 muestra los elementos Sistémicos del Sistema de Información que se propone.

2.2.10 Realización de la Arquitectura del sistema

La Arquitectura del Sistema permite ver de una manera gráfica y “de un solo golpe”, la forma como se relacionarán los elementos del Nuevo Sistema de Información; tiene la ventaja, luego entonces, de poder ser entendida sin problemas lo mismo por el experto que por el lego. La Figura 2. 10 muestra la Arquitectura Básica del Sistema Propuesto.




Compras

Proveedores

Ventas Clientes

Movimientos al

inventario

Entrada: Datos de usuario

Entrada: Compras Proveedores Etiquetas

Usuarios

Productos

Consultas: Precios Inventarios

Entrada: Ventas Clientes

Reportes por lotes: Ventas Compras Balances Movimientos

DIR. GRL.

EMPLEADO

DESPACHO

CONTABLE

Figura 2. 10 Arquitectura Básica del Sistema Propuesto.





Tabla 2. 6 Tabla Sistémica de los Nuevos Elementos del Sistema. Fuente: Elaboración propia a partir de: (Galindo Soria L., 2006)

TABLA SISTÉMICA

TABLA SISTÉMICA DE LOS NUEVOS ELEMENTOS DEL SISTEMA

SUB SISTEMA ENTRADAS PROCESO SALIDAS TIEMPOS Y

VOLÚMENES

DATOS CONTROLES DISTRIBUCIÓN

Compras

Número, descripción y precio de productos ofertados

Compra de artículos a mejor precio

Facturas, remisiones y notas de venta

De 15 minutos a 1 hora, / Mínimo 1 compra por semana

Datos Proveedor, número, descripción y precio de productos

Proveedor calificado, precio no mayor al 10% anterior

Gerente

Responsable de Almacén

Almacén Facturas,

remisiones y notas de venta y margen de ganancia

Etiquetado de productos, asignación precio de venta y alta en inventario

Etiquetas con código y precio

En función del número de artículos de 10 min a 1 hora / Cada compra

Código del producto, Precio de venta

Un código único por producto (No. de serie). Precio autorizado por gerencia

Vendedor,

Gerente

Ventas Producto

etiquetado Ubicación de producto para su exhibición y venta

Productos ubicados para su exhibición y Facturas de Venta

Cada que se realiza una transacción comercial / Una factura por venta

Número, descripción, precio de productos vendidos y venta total

Folio de facturas

Gerente y Despacho Externo




2.2.11 Diseño de las Salidas

Se entiende por salida a todo tipo de información que se obtiene de un Sistema Informático sea impresa, desplegada, verbal, multimedia o a la red de redes. Si se tiene presente que dicho Sistema Informático es evaluado en función de la calidad de su salida, luego entonces ésta es una característica importantísima del mismo. He aquí la razón por la cual se diseñaron y se presentan primero las salidas. La Figura 2. 11 y la Figura 2. 12 muestran el diseño de las Salidas.

LOGO ENCABEZADO

CAMPO 1

CAMPO 1

CAMPO 1

CAMPO 1

Figura 2. 11 Salida No. 1 del Sistema de información.





LOGO ENCABEZADO

CAMPO 1

CAMPO 1

CAMPO 1

CAMPO 1

Figura 2. 12 Salida No. 2 del Sistema de información.


2.2.12 Diseño de las Entradas

La importancia de las entradas se desprende de una regla básica en la Informática: “Si entra basura al sistema, saldrá basura”. En consecuencia es crucial el realizar un diseño adecuado de éstas. La Figura 2. 13 y la Figura 2. 14 muestran el diseño de las Salidas.




LOGO ENCABEZADO

CAMPO 1

CAMPO 1

CAMPO 1

CAMPO 1

Figura 2. 13 Entrada No. 1 del Sistema de información. Fuente: Elaboración propia

LOGO ENCABEZADO

CAMPO 1

CAMPO 1

CAMPO 1

CAMPO 1

Figura 2. 14 Entrada No. 2 del Sistema de información. Fuente: Elaboración propia




2.2.13 Diseño de los Procesos utilizando el Modelo WARNIER- Orr

El desarrollo de sistemas estructurados en datos (DSED, ó DSSD,

por sus siglas en inglés), también denominado metodología de Warnier-Orr, ha evolucionado del innovador trabajo sobre el análisis del campo de información realizado por J. D. Warnier. Éste permite al analista representar la jerarquía de información de una manera compacta. Se analiza el campo de la información y se representa la naturaleza jerárquica de la salida. La Figura 2. 15 muestra el Modelo Warnier Orr del Sistema de Información para la Administración de la Microempresa (SIAM).

2.2.14 Diseño de la Naturaleza Jerárquica de Salida desprendida del Modelo Warnier-Orr El siguiente paso consiste en diseñar la naturaleza jerárquica de

la salida a partir del uso del Modelo Warnierier-Orr del SIAM. La Figura 2. 16 muestra este diseño. En ésta se pueden apreciar las salidas de una manera jerárquica con base en el Modelo Warnieier-Orr, el cual viene a ser precisamente el Diseño arquitectónico del sistema.




M ENSAJE DE ERROR

SALIR DEL SIAM

CARGAR PERFIL DE SEGURIDAD

M ENSAJE DE ERROR

CIERRA M ODULO

AGREGA NUEVO PRODUCTO

M ODIFICA DATOS DE PRODUCTO

M ENSAJE DE ERROR

CIERRA M ODULO

AGREGA PROVEEDOR

M ODIFICA DATOS DE PROVEEDOR

M ODIFICAR DATOS DE INVENTARIO

M ODIFICAR DATOS DE PROVEEDOR

REGISTRAR M OVIM IENTO AL INVENTARIO

M ENSAJE DE ERROR

CIERRA M ODULO

AGREGA CLIENTE

M ODIFICA DATOS DE CLIENTE

M ODIFICAR DATOS DE INVENTARIO

M ODIFICAR DATOS DE CLIENTE

REGISTRAR M OVIM IENTO AL INVENTARIO

M ENSAJE DE ERROR

CIERRA M ODULO

IM PRESIÓN

DATOS

NUEVO USUARIO

M ODIFICAR USUARIO

VALIDACION DE USUARIO

EXTRAER CATALOGO DE CONTRASEÑAS Y USUARIOS DE LA BD

COM PARAR USUARIOS Y CONTRASEÑASSI ES INCORRECTO

ACCESO VALIDADO

INVENTARIO

SI EL PERFIL DE SEGURIDAD RECHAZA EL ACCESO

ACCESA A INVENTARIO

COM PRA

CONFIGURACION


CANFIGURAR SIAM

USUARIOS


PROVEEDORES

RECIBIR M ERCANCIA

VENTA


CLIENTES

RECIBIR M ERCANCIA

Figura 2. 15 Modelo Warnier-Orr del Sistema de Información.





SISTEMA DE INFORMACIÓN PARA LA ADMINISTRACIÓN DE UN MICROEMPRESA (SIAM)

INVENTARIOS

PRODUCTOS

VENTA

VENTAS CLIENTES

COMPRAS

COMPRAS RECEPCIONES

ADMINISTRACION

REPORTE GENERAL

USUARIOS CONF. GRL

Figura 2. 16 Diseño Arquitectónico del Sistema.





2.2.15 Diseño de la Base de Datos con el modelo relacional

El segundo nivel de abstracción del Modelo ANSI/SPARC, 1975 para la estructuración de un Sistema de Base de Datos es el denominado Nivel Conceptual, Empresarial o Integral, el Modelo Relacional cae precisamente dentro de esta clasificación. La Figura 2. 17 muestra el Modelo Relacional para la Base de Datos de SIAM.

COMPRAS

CompID PK

CompFecha SK

CompOper SK

CompSubtot ComptImp

CompFolioAjeno SK

ProvRFC

PROVEEDOR

ProvId PK

ProvNomv PorvApePat ProvApeMat ProvMaterial ProvProd ProvDirec ProvCol ProvCiudad ProvEdo ProvCP

ProvRFC SK

ProvTel ProvCel

PRODUCTOS

ProdClave PK

ProdNombre SK

ProdDescripción ProdUltCosto ProvRFC

ProdMaterial SK

ProdCódigo SK

VENTAS

VentID PK

VentFecha VentCliente VentVendedor VentSubtotal VentIVA

DETALLE DE VENTAS

DetVentID FK

DetVentClaveProd FK

DetVentCant DetVentPrecioUnitario DetVentDesc

DETALLE DE COMPRAS

CompID PK

DetCompID PK

ProdNombre FK

DetCompCant DetCompPrecioUnitario

INVENTARIO

IveID FK

InveMivimiento FK

InveProdClave SK

InveAnterior InveCantidad InveSaldo

InveFecha SK

InveOperador SK

InveFolio FK

CLIENTES ClieID PK ClieNom ClieApePat ClieApeMat ClieDirec ClieCol ClieCiudad ClieEdo ClieCP

ClieRFC SK

ClieTel ClieCel

Figura 2. 17 Modelo Relacional de la Base de Datos. Fuente: Elaboración propia

46

“Querido lector, esta noticia servirá para informarle

que acabo de hacer pública una máquina de mi

invención, con la cual usted por sí solo puede sin

esfuerzo alguno, realizar todas las operaciones

aritméticas y puede liberarse del esfuerzo que a

veces fatiga su espíritu…” (1645)

Blaise Pascal

(1623- 1662)

CAPÍTULO 3

CONSTRUCCIÓN DEL SISTEMA

DE INFORMACIÓN






CAPÍTULO 3

CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN



Este capítulo número tres está estructurado en tres

subcapítulos. En el primero de ellos, relativo a la Construcción del

Hardware e Instalación de la plataforma, se exponen los requisitos

mínimos de hardware, se justifica la elección de la computadora,

se da el listado de la herramienta necesaria para el armado de

ésta, una reseña del ensamblado de la máquina y la instalación

del sistema operativo. En el segundo subcapítulo, el de la

Construcción del Software se presenta una discusión de lo que son

los datos en contraposición con la información, lo que es el

Sistema Gestor de la Base de Datos, la elección de éste, la

representación conceptual de la Base de Datos, el diseño dela

Base de Datos con el Modelo Relacional y el concepto de

normalización. En el tercer subcapítulo relativo a la Construcción

Física de la Base de Datos en Access, se presentan las tablas

creadas, sus relaciones, los formularios diseñados, las consultas

empleadas y los informes creados.




3.1 Construcción del hardware e instalación de la plataforma.

3.1.1 Requerimientos de hardware Dado que se trata de un sistema de información basado en

computadora, es menester hacer la elección del ordenador donde correrá el sistema informático. Para tal efecto se analizaron los requerimientos de hardware mínimos indispensables para la instalación de Microsoft Office System 2007. La Tabla 3. 1 muestra estos requerimientos de hardware del computador en el que deberá correr el sistema informático.

Tabla 3. 1 Requerimientos de hardware del sistema

Fuente: (González Lozano, 2009)

ELEMENTO CARÁCTERÍSTICAS

PROCESADOR IGUAL O SUPERIOR A 500 MHz

DISCO DURO AL MENOS 1.5 GB

MEMORIA 256 MB DE RAM

PANTALLA SUPERIOR O IGUAL A 1024 X 786

PERIFÉRICOS MICROSOFT INTELLIMOUSE O COMPATIBLE

SISTEMA OPERATIVO WINDOWS XP O POSTERIOR




3.1.2 Elección de la computadora Tomando en cuenta estos requerimientos mínimos de hardware y

considerando que el contar con una máquina armada es una buena alternativa, ya que permite expandir el sistema en cualquier instante y reduce el costo implicado, se decidió irse por esta opción. La Figura 3. 1 muestra una copia de la factura de compra de los componentes de esta computadora a armar:

Figura 3. 1 Factura de compra de los componentes de la computadora a armar Fuente: Digitalización del documento original con fecha 18-dic-2009.




Físicamente los componentes antes descritos se pueden apreciar en la Figura 3. 2 y en la Figura 3. 3; en la primera figura empacados en tanto que en la segunda ya se encuentran desempacados.

Figura 3. 2 Componentes empacados de la computadora a armar

Fuente: Fotografía propia.

Figura 3. 3 Componentes desempacados de la computadora a armar.

Fuente: Fotografía propia.




La Figura 3. 4 muestra una tarjeta madre típica.

Figura 3. 4 Tarjeta madre.

Fuente: Fotografía de Curso de Reparación y Mantenimiento de computadoras CECATI No. 128

3.1.3 Herramientas necesarias La herramienta necesaria para proceder al armado en cuestión se

muestra en la Tabla 3. 2. Adviértase que se hace necesario el uso de una pulsera antiestática, ya que las tarjetas electrónicas contienen circuitos fabricados con tecnología C-MOS, lo cual los hace altamente vulnerables a las cargas estáticas.

Tabla 3. 2 Herramientas necesarias para el armando de la computadora.

Fuente: (García, J. R.l, 2005)

CANTIDAD DESCRIPCCIÓN

1 Desarmador de cruz

1 Desarmador plano

1 Pinzas de punta

1 Pulsera antiestática




3.1.4 Ensamblado de la computadora En primera instancia se procedió al armado de la unidad de

procesamiento central (CPU, por sus siglas en inglés), dado que en términos generales es la parte más delicada y sensible del sistema informático. La

Tabla 3. 3 muestra la secuencia general de los pasos que se siguieron para el armado de la computadora.

Tabla 3. 3 Secuencia general de armado de computadora

Fuente: (Alcalá, 2006)

No. SECUENCIA GENERAL DE ARMADO

1 Conexión y configuración de la tarjeta madre

2 Montar el Procesador.

3 Instalación de Memoria

4 Instalación de Tarjeta Madre en el CPU

5 Configuración de LEDs de encendido

6 Montaje y configuración de las unidades (CD-ROM, disco duro, disqueteras)

7 Cableado

8 Conexión de los cables (buses y alimentación).

9 Inserción de las Tarjetas de expansión.




La Figura 3. 5 muestra parte del cableado y configuración de la tarjeta madre; en tanto que la Figura 3. 6 muestra la computadora ya cableada en su parte interna.

Figura 3. 5 Cableado de la computadora

Fuente: Fotografía propia

Figura 3. 6 Vista interna de la computadora ya armada





Enseguida se procedió al primer encendido y a la configuración del “setup”. La Figura 3. 7 y la Figura 3. 8 muestran estos hechos.

Figura 3. 7 Primer encendido de la computadora


Figura 3. 8 Configuración del "setup"





3.1.5 Instalación del Sistema Operativo A continuación se procedió a la instalación del sistema operativo

de la computadora. Se instaló el sistema operativo Windows XP, Service Pack 3. La Figura 3. 9 muestra los discos con los que se llevó a cabo esta instalación.

Figura 3. 9 Discos de instalación del sistema operativo.


La Figura 3. 10 y la Figura 3. 11 muestran algunas fases de

esta instalación del sistema operativo.

Figura 3. 10 Programa de Instalación de Windows XP Profesional.





Figura 3. 11 Instalación del Sistema Operativo al 50%.


Acto seguido se procedió a la instalación de los controladores. La Figura 3. 12 muestra parte de esta operación.

Figura 3. 12 Instalación de los controladores.





La Figura 3. 13 muestra el fin de la fase de la instalación tanto del sistema operativo como de los controladores.

Figura 3. 13 Culminación de la instalación del Sistema Operativo y controladores.


Con lo que ya se estaba en posibilidades de instalar el Sistema

Gestor de la Base de Datos y los demás programas de Microsoft Office 2007. La Figura 3. 14 muestra parte de este proceso.

Figura 3. 14 Instalación del Sistema Gestor de la Base de Datos.





Finalmente para terminar este proceso, se procedió a la instalación de la paquetería adicional de Microsoft Office 2007. La Figura 3. 15 muestra parte de esta operación.

Figura 3. 15 Instalación de paquetería complementaria de Microsoft Office 2007.


3.2 Construcción del software

3.2.1 Base de Datos del Sistema de Información

Como ha quedado de manifiesto a lo largo del capítulo anterior, la

Base de Datos (BD) es el corazón del Sistema Informático (SI). En este sentido es que este tercer capítulo, dedicado a la construcción del SI, versará en gran medida en torno al diseño de la Base de Datos.

De esta forma es que se abordarán temas tales como el sistema

que se utilizará para la gestión de la BD; las entradas, procesos y salidas de la BD; el sistema físico o hardware que albergará a la BD, etcétera.

3.2.2 Datos vs. Información Un dato aislado y por sí solo es carente de significado en tanto

que la información son los datos interpretados. Dicho en otras palabras, la información son datos colocados dentro de un contexto significativo. (Beynon-Davies, 2004). Lo que es más un dato es la representación de un hecho aislado que puede registrarse mediante un número, en tanto que la información son datos relacionados en un contexto significativo lo cual da lugar a la toma de decisiones.




La presente investigación aspira a ser un sistema de información; asumiendo la responsabilidad que ello conlleva, ya que deberá ubicarse en un contexto, ser significativo y poder brindar la oportunidad de tomar decisiones específicas y concretas.

3.2.3 Sistema Gestor de la Base de Datos

El Sistema Gestor o Manejador de la Base de Datos (SGBD) o

(SMBD) es un software que permite administrar, auditar, compartir y realizar copias de seguridad de toda la información de una organización y no deja de ser más que una herramienta; en virtud de ello diversos autores son de la idea que su importancia no es crucial. No obstante, su elección es toral en el diseño de un sistema de información ya que de ello dependerá la operación del mismo.

3.2.4 Generalidades de los SGBD ó SMBD

Existen distintos objetivos que deben cumplir los SGBD, de entre ellos destacan los siguientes por su grado de importancia (Beynon-Davies, 2004):

Abstracción de la información. Los SMBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.

Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.

Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura frente a usuarios malintencionados, que intenten leer información privilegiada; frente a ataques que deseen manipular o destruir la información; o simplemente ante las torpezas de algún usuario autorizado pero despistado. Normalmente, los SGBD disponen de un complejo




sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.

Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper la información almacenada. Los SGBD proveen mecanismos para garantizar la recuperación de la base de datos hasta un estado consistente (ver Consistencia, más arriba) conocido en forma automática.

Respaldo. Los SGBD deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.

Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo más habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso concurrente a la información, que podría derivar en inconsistencias.

Manejo de Transacciones. Una Transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que el estado luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.

Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.

3.2.5 Elección del SGBD para el SI en cuestión

Para la implementación del presente sistema de información tal y como se señaló desde el apartado 2.3.7 del capítulo anterior, se optó por Microsoft Access 2007 por cumplir con los requerimientos de versatilidad y eficiencia necesarios; por ser un SGBD que permite compartir información con otros SGBD y por la evaluación que del mismo se hizo, a la luz de las trece reglas de Codd (Anexo 1), tal y como se hace referencia en el Capítulo 1, en el inciso 1.3. Adicionalmente se trata de un sistema fácilmente asequible.

Aunado a lo anterior, cabe señalar que se trata de un software de gran difusión entre Pequeñas y Medianas Empresas (PYMES) – el cual es precisamente el caso de la presente investigación- cuyas bases de datos no requieren de excesiva potencia, ya que se integra perfectamente con el resto de aplicaciones de Microsoft y permite crear pequeñas aplicaciones con unos




pocos conocimientos del Programa. Tiene un sistema de seguridad de cifrado bastante primitivo y puede ser la respuesta a proyectos de programación de pequeños y medianos tamaños.

Los documentos hechos en Microsoft Access 2007 tienen la extensión: “.accdb”. Cabe señalar que en todas las versiones anteriores de Access, el programa manejó la extensión: “.mdb”.

3.2.6 Representación conceptual de la BD

Un buen punto de partida para abordar la BD es el diseño conceptual de la misa, ya que éste es una representación gráfica que expresa claramente las especificaciones y requerimientos del usuario mediante un esquema. Dicho diseño conceptual está conformado por un diseño lógico y un diseño físico. La Figura 3. 16 muestra esta conformación del diseño conceptual.

DISEÑO CONCEPTUAL

DISEÑO LÓGICO

DISEÑO FÍSICO

Figura 3. 16 Diseño conceptual de una base de datos.

Fuente: (Beynon-Davies, 2004)

El diseño lógico es una descripción de la estructura de la BD, en

términos de la estructura de los datos e independientemente del SGBD que se vaya a utilizar. Por otro lado, el diseño físico es una descripción de la implementación de una BD en memoria secundaria, las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por tal motivo éste sí dependerá del SGBD. La Figura 3. 17 muestra el diseño lógico de la BD del SI a construir.




CATÁLOGO DE MATERIALES

CATÁLOGO DE PROVEEDORES

VENTAS

DETALLE COMPRAS

CATÁLOGO DE CLIENTES

COMPRAS

DETALLE DE VENTAS

CATÁLOGO DE PRODUCTOS

INVENTARIO

CATÁLOGO DE COMPRADORES

Figura 3. 17 Diseño lógico de la base de datos


Adviértase que se han identificado diez entidades, de las cuales

cinco son catálogos, quedando un total de cinco entidades o tablas y cuatro relaciones, excluyendo a aquellas tablas consideradas como catálogos, cuyas relaciones se encuentran marcadas con líneas punteadas.

3.2.7 Diseño de la Base de Datos con el Modelo Relacional El segundo nivel de abstracción del Modelo ANSI/SPARC, 1975

para la estructuración de un Sistema de Base de Datos es el denominado Nivel Conceptual, Empresarial o Integral, el Modelo Relacional cae precisamente dentro de esta clasificación.

3.2.8 Normalización Un problema potencial muy recurrente asociado con en el diseño

de bases de datos relacionales es la redundancia de los datos. Este problema potencial puede reducirse si se emplea la técnica de la normalización.

Dicho en otras palabras, la normalización es el proceso por el cual

se toman las requisiciones del usuario y se transforman en estructuras menos complejas. Ésta no comprende aspectos de la organización física de la base de datos, únicamente trata con el ámbito del diseño lógico.

La normalización es luego entonces una técnica para producir un

conjunto de relaciones con una serie de propiedades deseables, partiendo de los requisitos de datos de una organización. (Connolly, 2005).




En este sentido debe entenderse que el propósito de la normalización es identificar un conjunto adecuado de relaciones que soporte los requisitos de datos de una organización; de manera tal que el número de atributos necesarios sea mínimo, los atributos con una relación fuerte se encuentren en la misma relación y haya una redundancia mínima, es decir cada atributo esté representado una sola vez, excepción hecha de las claves externas, las cuales son esenciales para combinación de relaciones.

Dado un conjunto de datos que se va a representar en un SBD, la

normalización, ayuda a responder preguntas de la forma, ¿cómo se opta por una estructura adecuada para esos datos?, es decir ¿cómo se decide qué relaciones se necesitan y que atributos deben tener? El cual es precisamente el problema de diseño de base de datos.

Tanto la idea de la normalización como el concepto de las

dependencias funcionales aparecieron por primera vez en el artículo de Edgar F. Codd, “Further Normalization of the Data Base Relational model” (1971). Posteriormente un gran número de investigadores han contribuido al desarrollo de este concepto y la mayoría de los artículos publicados han adoptado una posición muy formal y rigurosa hacia los conceptos básicos, los cuales, son esencialmente simples y muy atractivos.

El proceso de normalización consta de tres pasos:

1. Eliminar todos los grupos que están repetidos. 2. Eliminar todas las dependencias parciales. 3. Eliminar las dependencias transitivas. 3.2.9 Formas normales Una vez realizados estos tres pasos señalados en el punto

anterior, el resultado es la creación de múltiples relaciones con una forma normal terciaria.

Ahora bien, ¿qué es la forma normal terciaria? o más aún, ¿qué

son las formas normales?

Como también se dejó claro en el inciso anterior, fue también Codd quien definió la primera, segunda y tercera formas normales.

3.2.9.1 Primera Forma normal

Se dice que una relación está en primera forma normal (1NF) si y sólo si satisface la restricción de que sus dominios simples subyacentes contengan sólo valores atómicos.




En otras palabras, el atributo B de una relación R es funcionalmente dependiente del atributo A de R si, en cada instante, cada valor de A está asociado con no más de un valor de B dentro de la relación R. Esto equivale a decir que “B” es funcionalmente dependiente “A” si “A identifica a B”. O sea, si en cualquier instante se sabe el valor de A. Entonces el valor de B queda determinado, lo cual se denota.

Se pueden elaborar diagramas para aclarar las dependencias

funcionales (DF). Si “B” es funcionalmente dependiente de “A”, se dibuja una flecha que va de “A” hasta “B” (esto hace recordar, la notación de la lógica matemática, en la que:

A B

significa “A” identifica a “B”, o si “A” entonces “B”, o sea, si “A” tiene un valor “a”, entonces “B” tiene un valor “b”.

3.2.9.2 Segunda Forma normal

Una relación R se halla en la segunda forma normal (2FN) si está en la primera forma normal (1FN) y cada uno de sus atributos es dependiente funcional completo (DFC) de cada llave candidata de R.

Todo atributo de una relación debe ser dependiente de la totalidad

de la llave, si no es así, ese atributo deberá llevarse a una relación aparte. Con base en lo anterior, se forma otra relación, esta otra relación,

se forma con los otros atributos.

3.2.9.3 Tercera Forma normal

Se supone que A, B, C, son tres atributos o tres conjuntos de atributos, de una relación R, si C es funcionalmente dependiente de B y B lo es de A, entonces C es funcionalmente dependiente de A. Si la correspondencia inversa no es simple, esto es, si A no es funcionalmente dependiente de B, o B no es funcionalmente dependiente de C, se dice entonces que C es transitivamente dependiente de A, Dependencia Transitiva (TD, por sus siglas en inglés). La Figura 3. 18 muestra de manera gráfica las tres formas normales dentro del universo de las relaciones, tanto las normalizadas como las no normalizadas.




Fuente: (Gama, 2001)

3.3 Construcción Física de la Base de Datos con Access 2007. Obviamente la construcción física de la Base de datos es la parte

medular de la presenta investigación, sobre todo si se tiene en cuenta que es la conjunción tanto del hardware con del software con todos los conceptos de bases de datos antes vertidos y todos estos elementos sumados son diferentes a su interrelación dentro de un mismo sistema. Recuérdese que “teniendo en cuenta las partes de la metodología de los sistemas suaves, en su forma desarrollada, una reexaminación de toda la metodología puede tratar de direccionar la pregunta de qué es lo que caracteriza su aproximación, haciendo más que la suma de sus partes.” (Checkland, 1999).

3.3.1 Tablas creadas Físicamente se crearon nueve tablas, en consonancia con lo que

se había diseñado. La Figura 3. 19 muestra estas tablas y sus relaciones.

Figura 3. 18 Formas Normales.




Figura 3. 19 Tablas y sus relaciones


3.3.2 Diccionario de datos. Los datos cuando se presentan ordenados en una tabla de

manera que contengan las características lógicas y puntuales de éstos, así como su descripción, longitud contenido y organización reciben el nombre de diccionario de datos.

El diccionario de datos de la base de datos del presente sistema

de información está formado por: el Catálogo de Proveedores; el Catálogo de Compradores; la tabla de Compras; la tabla del Detalle de Compras; el Catálogo de Productos; la tabla del Inventario; el Catálogo de Clientes; el Catálogo de Ventas y el Catálogo de Detalle de Ventas.

De la




Tabla 3. 4 a la Tabla 3. 12 se presenta dicho Diccionario de Datos donde están todos estos datos de acuerdo a como se realizó la construcción física de la base de datos.

68

Tabla 3. 4 Catálogo de Proveedores Fuente: Elaboración Propia



Diseño de la Estructura Básica del SI (Diccionario de Datos: Catálogo de Proveedores)

En el diseño de Bases de Datos un elemento fundamental es el Diccionario de Datos.

CATÁLOGO DE PROVEEDORES CONSECUTIVO IDENTIFICADOR

ÚNICO NOMBRE DESCRIPCIÓN TIPO LONGITUD DOMINIO RANGO ¿VALOR

ÚNICO? ¿LLAVE PRIMARIA?

¿LLAVE SECUNDARIA?

HOMÓNIMOS OBSERV.

1 ProvID CLAVE CLAVE DEL PROVEEDOR AUTO NUMÉRICO

ENTERO LARGO

SÍ SÍ NO

2 ProvNom NOMBRE NOMBRE DEL PROVEEDOR TEXTO 25 NO NO NO

3 ProvApePat APELLIDO APELLIDO PATERNO TEXTO 25 NO NO NO

4 ProvApeMat APELLIDO APELLIDO MATERNO TEXTO 25 NO NO NO

5 ProvMaterial MATERIAL MATERIAL PRINCIPAL TEXTO 25 NO NO NO

6 ProvProd PRODUCTO PRIN. PRODUCTO QUE PROVEE

TEXTO 25 NO NO NO

7 ProvDirec CALLE Y NUM. CALLE Y NUMERO TEXTO 25 NO NO NO

8 ProvCol COLONIA COLONIA DONDE RADICA TEXTO 25 NO NO NO

9 ProvCiudad CIUDAD CIUDAD DONDE RADICA TEXTO 25 NO NO NO

10 ProvEdo ESTADO ESTADO DONDE RADICA TEXTO 25 NO NO NO

11 ProvCP CP CODIGO POSTAL DE LA DIREC.

NUMERO ENT.

5 NO NO NO

12 ProvRFC RFC REG. FED. DE CAU. TEXTO 13 SI NO NO

13 ProvTel TELEFONO TELEFONO DE LA EMPRESA TEXTO 25 NO NO NO

14 ProvCel FAX NUMERO DE FAX DE LA EMPRESA

TEXTO 25 NO NO NO




Tabla 3. 5 Catálogo de Compradores


A continuación se presenta el relativo al Proveedor:

CATÁLOGO DE COMPRADORES CONSECUTIVO IDENTIFICADOR



¿LLAVE SECUNDARIA?

HOMÓNIMOS OBSERV.

1 CompradorID CLAVE CLAVE DEL COMPRADOR AUTO NUMÉRICO

ENTERO LARGO

SÍ SÍ NO

2 CompradorNom NOMBRE NOMBRE DEL COMPRADOR TEXTO 25 NO NO NO

3 CompradorApePat APELLIDO APELLIDO PATERNO DEL COMPRADOR

TEXTO 25 NO NO NO

4 CompradorApeMat APELLIDO APELLIDO MATERNO DEL COMPRADOR

TEXTO 25 NO NO NO



Diseño de la Estructura Básica del SI (Diccionario de Datos: Catálogo de Compradores)




Tabla 3. 6 Diccionario de Datos: Compras.




Diseño de la Estructura Básica del SI (Diccionario de Datos: Compras)

Dada su naturaleza es importante tener mucho cuidado al desarrollar un Diseño apropiado del Diccionario de Datos. A continuación se presenta el bloque relativo a Compras:

COMPRAS CONSECUTIVO IDENTIFICADOR



LLAVE SECUNDARIA

HOMÓNIMOS OBSERV.

1 CompID IDENTIFICADOR IDENTIFICADOR UNICO DEL DOCUMENTO

NUMERO ENTERO SI SI NO

2 CompFecha FECHA FECHA DE LA OPERACIÓN FECHA NO NO SI

3 CompComprador COMPRADOR EMPLEADO QUE REALIZA LA OPERACIÓN

TEXTO 15 NO NO NO

4 CompImp IMPUESTOS IMPUESTO GRAVADO EN LA OPERACIÓN

NUMERO DOBLE NO NO NO

5 CompFolioAjeno IDENTIFICADOR DE LA OTRA EMPRESA

IDENTIFICADOR DEL DOCUMENTO DE LA OTRA EMPRESA

TEXTO 10 NO NO SI

6 ProvID CLAVE CLAVE DEL PROVEEDOR AUTO NUMÉRICO

ENTERO LARGO

SÍ NO SÍ




Tabla 3. 7 Diccionario de Compras: Compras Detalle.




Diseño de la Estructura Básica del SI (Diccionario de Datos; Compras a Detalle)

Otros nombres con los que también se le conoce al Diccionario de Datos son: Diccionario Físico, Directorio, Catálogo o Repositorio. En seguida se presenta el bloque relativo a Compras de Detalle:

DETALLE DE COMPRAS

CONSECUTIVO IDENTIFICADOR ÚNICO NOMBRE DESCRIPCIÓN TIPO LONGITUD DOMINIO RANGO ¿VALOR


LLAVE SECUNDARIA

HOMÓNIMOS OBSERV.

1 CompID IDENTIFICADOR IDENTIFICADOR UNICO DEL DOCUMENTO

NÚMERO ENTERO NO SI SI

2 DetCompID IDENTIFICADOR IDENTIFICADOR UNICO DEL DOCUMENTO

NÚMERO ENTERO NO SI SI

3 ProdNombre PRODUCTO NOMBRE DEL PRODUCTO TEXTO 10 NO NO SI

4 DetCompCant CANTIDAD CANTIDAD DE PRODUCTOS


5 DetCompPrecioUnitario PRECIO PRECIO UNITARIO DEL PRODUCTO

MONEDA NO NO NO




Tabla 3. 8 Diccionario de Datos: Productos.




Diseño de la Estructura Básica del SI (Diccionario de Datos: Productos)

Los elementos del Diccionario de Datos son: Número consecutivo, Identificador Único, Nombre, Descripción, Tipo, Longitud Dominio, Rango, Valor Único, Llave Primaria, Llave Secundara, Homónimo y Observaciones. A continuación se presenta la parte

relativa a los Productos:

CATÁLOGO DE PRODUCTOS CONSECUTIVO IDENTIFICADOR



LLAVE SECUNDARIA

HOMÓNIMOS OBSERV.

1 ProdID CLAVE IDENTIFICADOR DE CADA PRODUCTO

TEXTO 10 SI SI NO PRODUCTO

2 ProdNombre NOMBRE NOMBRE COMERCIAL TEXTO 15 SI NO SI

3 ProdDescripción DESCRIPCION LEYENDA COMERCIAL QUE INCLUYE SUS CUALIDADES O ATRIBUTOS

TEXTO 50 NO NO NO

4 ProdUltCosto ULTIMO COSTO

ULTIMO COSTO AL QUE SE COMPRO

MONEDA NO NO NO

5 ProdPrecio PRECIO PRECIO DE VENTA MONEDA NO NO NO

6 ProdMaterial MATERIAL TIPO DE MATERIALES CON QUE SE FABRICA

TEXTO 10 NO NO SI MATERIAL

7 ProdCódigo CODIGO DE BARRAS

IDENTIFICADOR DE CODIGO DE BARRAS

TEXTO 18 SI NO SI CODIGO




Tabla 3. 9 Diccionario de Datos: Movimientos al Inventario.




Diseño de la Estructura Básica del SI (Diccionario de Datos; Movimientos al Inventario)

A continuación se presenta el bloque del Diccionario que se refiere al Movimiento al Inventario:

INVENTARIO

CONSECUTIVO IDENTIFICADOR ÚNICO

NOMBRE DESCRIPCÓN TIPO LONGITUD DOMINIO RANGO ¿VALOR ÚNICO?

¿LLAVE PRIMARIA?

LLAVE SECUNDARIA

HOMÓNIMOS OBSERV.

1 InveID ID IDENTIFICADOR UNICO CONSECUTIVO

NUMERO ENTERO "-16,000 a 16,000"

0 a 1000

SI SI NO MOVIMIENTO

2 InveMovimiento MOVIMIENTO TIPO DE MOVIMIENTO TEXTO 10 NO NO SI

3 InveProdClave PRODUCTO CLAVE DEL PRODUCTO TEXTO 10 NO NO SI

4 InveAnterior CANTIDAD ANTERIOR

INVENTARIO ANTERIOR AL MOVIMIENTO

NUMERO DOBLE "-32000 a 32000"

0.00 a 1000

NO NO NO

5 InveCantidad CANTIDAD OPERADA

CANTIDAD QUE SE MUEVE NUMERO DOBLE "-32000 a 32000"

0.00 a 1000

NO NO NO

6 InveSaldo CANTIDAD RESULTANTE

INVENTARIO RESULTANTE DE LA OPERACIÓN

NUMERO DOBLE "-32000 a 32000"

0.00 a 1000

NO NO NO

7 InveFecha FECHA FECHA DE LA OPERACIÓN FECHA NO NO SI

8 InveOperador OPERADOR IDENTIFICADOR DE LA PERSONA QUE REALIZA EL MOVIMIENTO

TEXTO 15 NO NO SI

9 InveFolio CLAVE DE DOCUMENTO

IDENTIFICADOR UNICO DEL DOCUMENTO DONDE SE HIZO EL MOVIMIENTO

NUMERO ENTERO "-16,000 a 16,000"

0 a 1000

NO NO SI




Tabla 3. 10 Diccionario de Datos: Clientes.




Diseño de la Estructura Básica del SI (Diccionario de Datos; Clientes)

En seguida se presenta el bloque del Diccionario que se refiere a los Clientes:

CATÁLOGO DE CLIENTES

CONSECUTIVO IDENTIFICADOR UNICO

NOMBRE DESCRIPCION TIPO LONGITUD DOMINIO RANGO ¿VALOR UNICO?

¿LLAVE PRIMARIA?

LLAVE SECUNDARIA

OMONIMOS OBSERV.

1 ClieID CLAVE CLAVE CLIENTE AUTONUMÉRICO ENTERO LARGO

SÍ SÍ NO

2 ClienNom NOMBRE(S) DEL CLIENTE

NOMBRE(S) DEL CLIENTE TEXTO 25 NO NO NO

3 ClieApePat APELLIDO APELLIDO PATERNO DEL CLIENTE

TEXTO 25 NO NO NO

4 ClieApeMat APELLIDO APELLIDO MATERNO DEL CLIENTE

TEXTO 25 NO NO NO

5 ClieDirec DIRECCIÓN CALLE Y NUMERO

NOMBRE DE LA CALLE Y NUMERO EXTERNO E INTERNO

TEXTO 25 NO NO NO

6 ClieCol COLONIA COLONIA DONDE RADICA TEXTO 25 NO NO NO

7 ClieCiudad CIUDAD CIUDAD DONDE RADICA TEXTO 25 NO NO NO

8 ClieEdo ESTADO ESTADO DONDE RADICA TEXTO 25 NO NO NO

9 ClieCP CP CÓDIGO POSTAL DE LA DIRECCION

NUMERO ENTERO

5 NO NO NO

10 ClieRFC RFC REGISTRO FEDERAL DE CAUSANTES DE LA EMPRESA

TEXTO 13 SI SI NO

11 ClieTel TELÉFONO TELÉFONO DE LA EMPRESA TEXTO 25 NO NO NO

12 ClieCel CELULAR CELULAR DEL CLIENTE TEXTO 25 NO NO NO




Tabla 3. 11 Diccionario de Datos: Ventas.




Diseño de la Estructura Básica del SI (Diccionario de Datos: Ventas)

La siguiente tabla presenta el bloque del Diccionario que se refiere a las Ventas:

VENTAS

CONSECUTIVO IDENTIFICADOR UNICO

NOMBRE DESCRIPCION TIPO LONGITUD DOMINIO RANGO ¿VALOR UNICO?

¿LLAVE PRIMARIA?

LLAVE SECUNDARIA

OMONIMOS OBSERV.

1 VentID IDENTIFICADOR IDENTIFICADOR UNICO DEL DOCUMENTO

NUMERO ENTERO SI SI NO

2 VentFecha FECHA FECHA DE LA OPERACIÓN FECHA NO NO SI

3 VentCliente CLIENTE IDENTIFICADOR ÚNICO DEL CLIENTE

TEXTO 10 NO NO SI

4 VentVendedor VENDEDOR PERSONA DE “LA CASA DE LOS AZULEJOS” QUE REALIZA LA OPERACIÓN

TEXTO 15 NO NO NO

5 VentSubtotal SUBTOTAL SUBTOTAL ANTES DE IMPUESTOS

NUMERO ENTERO LARGO

NO NO NO

6 VentIVA IMPUESTOS IMPUESTO GRAVADO EN LA OPERACIÓN

NUMERO ENTERO LARGO

NO NO NO




Tabla 3. 12 Diccionario de Datos: Detalle de Ventas.




Diseño de la Estructura Básica del SI (Diccionario de Datos: Detalles de Ventas)

Finalmente se presente la parte del Detalle de Ventas:

DETALLE DE VENTAS

CONSECUTIVO IDENTIFICADOR

UNICO NOMBRE DESCRIPCION TIPO LONGITUD DOMINIO RANGO ¿VALOR

UNICO? ¿LLAVE PRIMARIA?

LLAVE SECUNDARIA

OMONIMOS OBSERV.

1 DetVentID IDENTIFICADOR IDENTIFICADOR UNICO DEL DOCUMENTO

NUMERO ENTERO NO SI SI

2 DetVentClaveProd ITEM IDENTIFICADOR UNICO DE LA PARTIDA EN EL DOCUMENTO

NUMERO ENTERO NO SI NO

3 DetVentCant CANTIDAD CANTIDAD DEL PRODUCTO TEXTO NO NO SI

4 DetVentPrecioUnitario PRECIO PRECIO UNITARIO DEL PRODUCTO


5 DetVentDesc DESCUENTO DESCUENTO EN LA OPERACIÓN





3.3.3 Formularios creados. El formulario es la herramienta amigable para el usuario final, la

cual permite la introducción de los datos a las tablas. En el Sistema de Base de Datos propuesto, se crearon un total de

ocho formularios y cinco subformularios. En el primer caso, éstos fueron: Formulario del catálogo de Productos; Formulario del Catálogo de Materiales, Formulario del Catálogo de Proveedores, Formulario del Catálogo de Clientes, Registro de Compras, Registro de Venta, Registro de Compradores y el Menú principal. En el segundo caso fueron: Subformulario del Detalle de Ventas, Subformulario del la Consulta de Inventario para Compra, Subformulario del Inventario, Subformulario Consulta3 y Subformulario Consulta4.

A guisa de ejemplo se presentan en la Figura 3. 20, Figura 3. 21

y la Figura 3. 22 el Formulario del Registro de Compras, El Registro de Ventas y la Captura de Información de Clientes.

Figura 3. 20 Formulario del Registro de Compras.





Figura 3. 21 Formulario del Registro de Ventas.


Figura 3. 22 Captura de Información de Clientes.





3.3.4 Informes Creados. Los informes son las salidas o reportes creados para brindar la

información necesaria al usuario.

Como muestra de estos se presentan en la Figura 3. 23 y en la los informes de Existencia de Productos en el Inventario.

Figura 3. 23 Informe de Existencia de Productos en Inventario.


En el Anexo 3 (Ane3) se da una relación más detallada de las

pantallas y operación del Sistema de Información.

80

“El experimentador que no

sabe lo que está buscando

no comprenderá lo que

encuentra”.

Claude Bernard (1813-1878)

CAPÍTULO 4

PRUEBAS Y RESULTADOS

http://www.proverbia.net/citasautor.asp?autor=1166




CAPÍTULO 4 PRUEBAS Y RESULTADOS



En este capítulo cuatro, como su nombre lo indica se

presenta la definición de prueba de software, los métodos que de

ésta existen y se abordan dichas pruebas como los resultados que

dieron vialidad al presente Sistema de Información. Así mismo se

presentan alternativas para que el usuario final pueda tomar

decisiones basadas en el análisis de la información del sistema

informático.

4.1 Definición

Se entiende como prueba de software a la revisión final de las especificaciones del diseño y de la codificación, esta prueba es un elemento crítico para la garantía de calidad del software. (Pressman, 1997).

Es una actividad desdeñada por muchos ingenieros de software, a

pesar de que en muchos de los casos, sobre todo en las industrias consideradas como críticas como la aeronáutica o la nuclear, se emplee entre el 30 y 40% del esfuerzo total del proyecto en la prueba.




4.2 Fundamentos y objetivos de la prueba.

En cierta medida la prueba del software presenta una contradicción, pues si bien el diseño requirió de una mentalidad creativa, el proceso de la prueba debe intentar deshacer o echar por tierra aquello que se acaba de construir. Es menester luego entonces que se descarten ideas preconcebidas y se superen cualquier conflicto de intereses que aparezcan cuando se descubran los errores, en virtud de que puede haber una o varias personas afectadas.

Como bien señala nuevamente el propio Pressman citando a

(Davis, 1995), existen una serie de principios que dan fundamentación a las pruebas de software y son (1997):

A todas las pruebas se les debe poder hacer un seguimiento hasta los requisitos del cliente.

Las pruebas deben planificarse mucho antes de que empiecen.

El principio de Pareto es aplicable a las pruebas de software.

Las pruebas deben empezar lo „pequeño‟ y progresar hacia lo „grande‟.

No es posible hacer pruebas exhaustivas en el caso del software. Otro clásico de la ingeniería del software, Myers, establece: “hay

tres normas que pueden servir acertadamente como objetivos de las pruebas de software y son:

1. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.

2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

3. Una prueba tiene éxito si descubre un erro no detectando hasta entonces. (1979).




4.3 Características de las pruebas de software

Las pruebas de software deben de ser de fácil aplicación, de hecho existen métricas que pueden usarse para medir la facilidad de una prueba en la mayoría de sus aspectos.

La muestra una lista de cotejo que da el conjunto de

características que llevan a un software a que sea fácil de probar:

Tabla 4. 1 Lista de cotejo de las características de las pruebas de software.

Fuente: Elaboración propia a partir de (Pressman, 1997)

NO. CARACTERÍSTICA

1 Operatividad

2 Observable

3 Control

4 Capacidad de descomposición

5 Simplicidad

6 Estabilidad

7 Facilidad de compresión

4.4 Métodos de prueba

Existe una gran variedad de métodos para probar un software, dependiendo sobre todo de la naturaleza del mismo. A continuación se dan algunos de los métodos más representativos para realizar estas pruebas:

Prueba de caja blanca

Prueba de caja negra.

Prueba del camino básico.

Notación de grafo de flujo.




Complejidad de los ciclos.

Prueba de estructura de control.

Prueba de flujo de control.

Análisis de valores límite.

Prueba de interfaces gráficas.

4.5 Prueba de interfaces gráficas.

Dada la naturaleza del sistema de información diseñado, el método seleccionado para probarlo fue el de la de interfaces gráficas, pues el SGBD utilizado, Access 2007, cae en este rubro.

Las interfaces gráficas de usuario (IGU) presentan interesantes

desafíos para los ingenieros de software. Debido a los componentes reutilizables provistos como parte de los entornos de desarrollo de las IGU, la creación de la interfaz de usuario se ha convertido en menos costosa en tiempo y más exacta. Al mismo tiempo, la complejidad de las IGU ha aumentado, originando más dificultad en el diseño y ejecución de los casos de prueba.

El diseño de esta prueba se compone de tres módulos básicos: 1)

Para las ventanas. 2) Para menús emergentes y operantes con el ratón y 3) Para entrada de datos.

4.5.1 Para las ventanas.

Para el efecto se diseño un cuestionario que pudiera servir de directriz para la creación de una serie de pruebas genéricas. Las preguntas son:

¿Se abrirán las ventanas basándose en órdenes que emanan del teclado o en un menú?

¿Se puede ajustar el tamaño, mover y desplegar la ventana?

¿Está todo el contenido de la información dentro de la ventana accesible adecuadamente con el ratón teclas de función, flechas de dirección y teclado?

¿Se regenera adecuadamente cuando se sobrescribe y se vuelve a abrir?

¿Están operativas todas las funciones relacionadas con la ventana?

¿Están disponibles y desplegados apropiadamente en la ventana todos los menús emergentes, barras de herramientas, barras deslizantes, cuadros de diálogo, botones, iconos y otros controles importantes?




Cuando se despliegan varias ventanas, ¿se representa adecuadamente el nombre de cada ventana?

¿Está resaltada adecuadamente la ventana activa?

Si se utiliza multitarea, ¿están actualizadas todas las ventanas en los momentos adecuados?

¿Causan las selecciones múltiples o incorrectas del ratón dentro de las ventanas efectos secundarios inesperados?

¿Están de acuerdo con las especificaciones los indicadores de audio y/o color de la ventana o cómo consecuencia de operaciones de la ventana?

¿Se cierra adecuadamente la ventana?

4.5.2 Para menús emergentes y operantes con el ratón

De manera semejante, para el siguiente bloque se diseñaron las siguientes preguntas:

¿Se muestra la barra de menú apropiada con el contexto apropiado?

¿Despliega la barra de menú de la aplicación características relacionadas con el sistema?

¿Funcionan adecuadamente las operaciones de despliegue?

¿Funcionan adecuadamente los menús de escape y barras de herramientas?

¿Están listadas adecuadamente todas las funciones del menú y sub-funciones emergentes?

¿Son todas las funciones del menú accesibles con el ratón?

¿Es correcto el tipo, tamaño y formato del texto?

¿Es posible invocar todas las funciones del menú usando su orden alternativa de texto?

¿Están resaltadas las funciones del menú (o difuminadas) dependiendo del contexto de las operaciones actuales de la ventana?

¿Se ejecutan todas las funciones de cada menú como se anunciaba?

¿Son suficientemente claros los nombres de las funciones del menú?




¿Hay ayuda disponible para cada elemento del menú y es sensible al contexto?

¿Se reconocen apropiadamente las operaciones del ratón a lo largo de todo el contexto?

¿Si se necesita múltiples clics, están apropiadamente reconocidos en el contexto?

¿Si el ratón tiene varios botones, son reconocidos apropiadamente en el contexto?

¿Cambian adecuadamente el cursor, el indicador de procesamiento y el puntero al invocar diferentes operaciones?

4.5.3 Para entrada de datos.

¿Si se repiten y son introducidos adecuadamente los datos alfanuméricos en el sistema?

¿Funcionan adecuadamente los modos gráficos de entra de datos?

¿Se reconoce adecuadamente los datos no válidos?

¿Son inteligibles los mensajes de entrada de datos?

4.6 Resultados.

La aplicación de las pruebas antes descritas arrojó resultados bastante favorables, ya que a pesar de haber encontrado errores en el formato y tipo de los datos dentro de las tablas, en términos generales el sistema informático pasó todas las pruebas. Evidentemente lo anterior se deriva de hecho de haber utilizado para el diseño de la base de datos a un SGBD que adicionalmente es una IGU muy amigable.

4.7 Toma de decisiones.

Una de las ventajas de contar con un sistema informático para la administración del negocio caso de estudio es la utilidad que puede tener la información que arroje aquel para la toma de decisiones.

De esta manera es posible visualizar de manera clara la tendencia

de las ventas, para poder con base en ello, realizar las compras más adecuadas.

Los informes de reporte de venta mensual permiten realizar una declaración más oportuna y correcta de las obligaciones fiscales.




La identificación de los clientes más „leales‟ es muy sencilla y pueden de esta forma, realizarse actividades como contactarlos u ofrecerles descuentos especiales.

El sistema de ventas con apartados tenía la desventaja de que en

ocasiones el cliente mantenía apartada una mercancía por mucho tiempo y sin tomar acción para ello. El sistema informático permite ahora alertar de este hecho y contactar el cliente o cancelar el apartado de la mercancía.

El manejo de las cuentas por pagar es ahora mucho más fácil y

puede llevarse un control más preciso del proveedor al que más se le compra y el financiamiento, si es que lo da, en que tiempo y términos se encuentra.

88

“Un especialista es una persona

que cada vez sabe más sobre menos,

hasta que termina sabiéndolo

todo sobre nada...y nada sobre todo.”

Danny Kaye

(1913-1987)

CAPÍTULO 5

CONCLUSIONES Y TRABAJOS FUTUROS






CAPÍTULO 5

CONCLUSIONES Y TRABAJOS FUTUROS



En este capítulo número cinco se retoman tanto el

objetivo general como los objetivos particulares para presentar una

discusión del cumplimiento de los mismos. De igual forma se

presenta una conclusión general sobre el paradigma de la

sistémica. Por ultimo se presentan los trabajos futuros que

pudieran dar continuidad a la presente investigación.

5.1 Cumplimiento del objetivo general.

Se puede concluir que el presente trabajo de tesis cubrió los objetivos planteados originalmente y que se logró cumplir con las expectativas, inclusive más allá, que del mismo se tenían.

Retomando el objetivo general el cual a la letra dice: “Diseñar un

sistema de información para administrar una microempresa. Caso de Estudio: Negocio para Comercializar Artesanías. Se puede señalar que se llegó a la




concreción del sistema informático y que por ende la administración del negocio para la comercialización de artesanías es mucho más sencilla.

5.2 Consecución de los objetivos particulares

De manera similar se pueden retomar uno a uno los objetivos particulares que se plantearon desde el principio de la presente investigación y es posible afirmar que todos ellos se cumplieron.

En este sentido, el primero de los objetivos particulares fue:

“Analizar y evaluar los sistemas de información para la administración.”, y como se señaló se evaluaron los productos existentes en el mercado, tales como los productos de MaxiComercio ERP & POS, SME Toolkit América Latina o de Microsoft Dynamics mas éstos son de propósito general y difícilmente utilizables de forma directa en un negocio para la comercialización de artesanías.

El siguiente objetivo particular decía: “Identificar las características

particulares del negocio para comercializar artesanías del caso de estudio de la presente investigación.” El segundo capítulo da amplia cuenta de ello, en virtud de que se hace un análisis de los antecedentes, la etapa actual del negocio y los requerimientos a futuro de esta microempresa.

Es en el capítulo tres donde se cubre el tercer objetivo particular

al: “Diseñar y construir el Sistema Informático en cuestión.” A lo largo de este capítulo se pueden ver todos los productos tanto de hardware como de software que se diseñaron y se construyeron.

Por último, el objetivo de “Implantar y Documentar el Sistema

Informático referido.”, se cumplió en el capítulo cuatro. Fase ésta muy importante en el diseño de sistemas de información.

5.3 Conclusión general

Al margen de haber retomado tanto el objetivo general como los objetivos específicos y haber analizado el cumplimiento de los mismos, de manera general se puede concluir que el paradigma holístico que brinda la Teoría General de Sistemas para la solución de cualquier problema, es muy completo, en virtud de que permite visualizar todas las variables del sistema.

5.4 Trabajos futuros

Existen varios trabajos que pudieran dar continuidad a la presente investigación. El más inmediato y dada la naturaleza del negocio bajo estudio y el avance de las tecnologías de la información y comunicación, sería el diseño




y construcción de una interfaz web, con la cual se pudiera administrar el negocio para la comercialización de artesanías vía internet.

Otro trabajo futuro bien podría ser la adecuación del presente sistema de información para realizar transacciones seguras para el pago y transferencia de fondos así como la emisión de la facturación electrónica requerida por el Sistema de Administración Tributaría. Esto coadyuvaría a la comercialización allende nuestras fronteras.




REFERENCIAS BIBLIOGRÁFICAS Y DE INTERNET

1.- Academia Mexicana de la Lengua. (2001). Academia Mexicana de la Lengua. Recuperado el 11 de enero de 2010, de http://www.academia.org.mx/rae.php

2.- Actopan (Hidalgo). (s.f.). Recuperado el 27 de abril de

2009, de http://es.wikipedia.org/wiki/Actopan_(Hidalgo)

3.- Alcalá, H. C. (2006). Ensamblaje de computadoras. Recuperado el 30 de 03 de 2010, de http://www.slideshare.net/angelcaido666x/ensamblje-de-computadoras

4.- Bertalanffy, L. v. (1968). General systems theory.

Edmonton: George Braziller, Inc.

5.- Beynon-Davies, P. (2004). Database Systems. London, Ingland: Palgrave MacMillan.

6.- Checkland, P. (1994). La metodología de sistemas

suaves en acción. Lancaster: Megabyte y Wiley.

7.- Checkland, P. (1999). Systems Thinking, Systems Practice. Lancastere: John Wiley & Sons, Ltd.

8.- Codd, E. F. (1971). Further Normalization of the Data

Base Relational model. ACM.

9.- Communications of the ACM. (jun de 1970). Recuperado el 10 de 10 de 2009, de http://cacm.acm.org/magazines/1970/6/12368-a-relational-model-of-data-for-large-shared-data-banks/pdf

10.- Connolly, T. M. (2005). Sistemas de bases de dato, un

enfoque práctico para diseño, implementación y gestión. Madrid: Pearson Educación S.A.

11.- Davis, A. (1995). Principles of Software Development.

Mc Graw Hill, Inc.

12.- Denis, A., & Roth, B. H. (2006). Systems Analysis Design. Indiana: John Wiley & Sons, Inc.




13.- Galindo Soria, L. (2006). Metodología para el Desarrollo de Sistemas de Información. 2o. Congreso Internacional de Metodología de la Ciencia de la Investigación para la Educación. México: AMMCI.

14.- Galindo Soria, L. (2005). Pearson Eduaction (Prentice

Hall-Addison Wesley. México D.F.: Pearson Eduaction (Prentice Hall-Addison Wesley).

15.- Gama, M. L. (2001). Sistema Funto de Venta para

Farmacias Interfarma. Mëxico D.F.: I.P.N.

16.- García, J. R.l. (29 de 09 de 2005). Recuperado el 03 de 04 de 2010, de Mantenimiento de computadoras, PC: http://www.mailxmail.com/curso-mantenimiento-computadoras-pc/armado-computadora-1

17.- González Lozano, R. (2009). Bases de Datos con

Access 2007. México D.F.: Alfaomega.

18.- González Nava, L. M. (2007). Microsoft Access 2007, los datos en orden. Nezahualcoyotl, Estado de México: Guias inmediatas de computación.

19.- González, M. d. (19 de abril de 2010). Tepito vende

bases de datos oficiales. El Universal , págs. 1, 14.

20.- Google. (20 de abril de 2009). Google Earth. EE.UU.

21.- Hoffer, J. A., & Valacich, J. F. (1999). Modern Systems Analysis and Design. Dayton: Addison-Wesley.

22.- Kendall, K. E. (1999). Systems Analysis and design.

New Jersey: Prentice Hall International.

23.- Martínez Ostria, D. (s.f.). Bienvenido a Actopan.com. . Recuperado el 26 de 04 de 2009, de http://www.actopan.com/creditos.html

24.- Maya-Martínez, P. (2008). Propuesta de un método de

solución sitémico para crear y/o evaluar modelos. México D.F.: I.P.N.

25.- Mendieta Alatorre, Á. (1979). Tesis Profesionales.

México: Purrúa.

26.- Muñoz Razo, C. (1998). Cómo elaborar y asesorar una investigación de tesis. México: Pearson Educación.




27.- Myers, G. (1979). The art of software testing. Wiley.

28.- Obituario de Edgar F Codd. (s.f.). Recuperado el 10 de 10 de 2009, de http://www.dcc.uchile.cl/~rbaeza/inf/codd.html

29.- Pressman, R. S. (1997). Ingeniería del Software un

enfoque práctico. Madrid: Mc Graw Hill, Inc.

30.- Ramos, J. y. (22 de abril de 2010). PGR, Cisen y SPP van por ladroes de datos. El Universal , págs. 1, 4, 6 y 7.

31.- Real Academia, E. (2001). Diccionario de la lengua

española. Recuperado el 01 de mayo de 2009, de http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=heurístico

32.- Secretaría de Economía. (s.f.). Recuperado el 13 de

mayo de 2009, de http://www.economia.gob.mx/swb/swb/

33.- Van Gigch, J. (1987). Teoría General de Sistemas. Sacramento, California: Trillas.

34.- Villa-Rivera, J. E. (2006). Reglamento de Estudios de

Posgrado del Instituo Politécnico Nacional. Gaceta Politécnica .




GLOSARIO Atributo.- es la unidad datos más pequeña, que representa cada

elemento de datos (se conforma por un conjunto de caracteres). Coloquialmente conocido como campo, sobre todo en la literatura de los Sistemas Manejadores de Bases de Datos.

Base de datos.- es un conjunto de datos organizados y relacionados entre sí, en función con algún propósito o tema en concreto.

Base de datos relacional.- se trata de un conjunto de tablas relacionadas por un campo en común, puede también ser definida como un conjunto de relaciones.

Campo.- es la unidad de datos más pequeña, que representa cada elemento de dato (se conforma por un conjunto de caracteres).

Consulta.- es el método para acceder a los datos; por medio de ésta se puede agregar, procesar, filtrar, manejar y modificar en cualquier forma los datos que se tienen en las tablas de las bases de datos.

Formulario.- es una ventana de Windows que tiene como propósito introducir y editar los datos de las tablas de una manera más funcional y agradable por medio de objetos gráficos llamados controles, como botones, listas desplegables, cuadros de texto, imágenes, videos, etcétera.

Informe.- impresión, pantalla o exposición de video cuyo objetivo es difundir información de salida del sistema.

Integridad referencial.- conjunto de reglas para garantizar que las relaciones entre los registros de las tablas relacionadas sean válidas y que los cambios realizados en una tabla sean los apropiados para que no se elimine ni modifique la información que está relacionadas.

Llave.- también denominada clave y es un campo dentro de una tabla. Las hay principales, secundarias y externas o foráneas. En el primer caso define de manera única al registro dentro de una tabla.

Macros.- conjunto de una o más acciones para la automatización de tares seleccionadas.

Microsoft Office.- conjunto de software de aplicación específica desarrollado por Microsoft. Hizo su aparición en 1989. La versión 2007 denominada Microsoft Office System 2007 fue lanzada el 30 de enero de 2007 y contiene: Instalación de Microsoft Office 2007, Microsoft Office Access 2007, Microsoft Access 2007, Microsoft Office Groove 2007, Microsoft Office InfoPath




2007, Microsoft Office OneNote 2007, Microsoft Office Outlook 2007, Microsoft Office PowerPoint 2007, Microsoft Office Project 2007, Microsoft Office Publisher 2007, Microsoft Office Visio 2007 y Microsoft Office Word 2007.

Módulos.- colección de declaraciones y procedimientos de Visual Basic para la manipulación de la base de datos.

Objeto OLE.- Tecnología de Microsoft para compartir información entre distintas aplicaciones de Windows. Las siglas obedecen al nombre en inglés "Object Linking and Embedding” Esto permite la creación de documentos o programas incorporando elementos de otros. Para la ejecución de dicho programa/documento deben existir los archivos o programas necesarios para ejecutarlos. Por ejemplo, dentro de un documento en Word se pueden utilizar gráficos de Excel.

Redundancia de datos.- es el almacenamiento de los mismos datos más de una vez en diferentes lugares ocasionando incremento de tiempo y de trabajo, desperdicio de espacio e inconsistencia de datos. Si una base de datos está bien diseñada no habrá redundancia de datos; excepción hecha de la llaves principales, en donde se guarda la información de manera duplicada o en la redundancia de datos controlada, que se emplea para mejorar su rendimiento en las consultas.

Relación.- es el vínculo entre dos o más entidades que describe alguna interacción entre ellas y que da origen a las tablas.

Sistemas de Gestión de Bases de Datos (SGBD).- software cuyo propósito es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante, para un buen manejo de datos. Identificados también por las siglas SMBD que significa Sistemas Manejadores de Bases de Datos ó DBMS, por su nombre en inglés “Data Base Management Systems”.

SQL.- lenguaje de consulta estructurado, las siglas obedecen a su nombre en idioma inglés: Structured Query Language. Se trata del lenguaje de consultas a bases de datos más utilizado. Es un lenguaje declarativo que permite especificar diversos tipos de operaciones. Es un lenguaje de cuarta generación (4GL). (González Lozano, 2009)

Tabla.- es un arreglo bidimensional organizado por filas y columnas (se conforma por un conjunto de registros).

Tupla.- es una secuencia ordenada de objetos, se emplean en matemáticas para describir objetos que tiene una estructura y que por

http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos16/manual-ingles/manual-ingles.shtml




tanto son capaces de descomponerse en cierto número de componentes (a1, a2,...,an). En la teoría de base de datos se define como una función finita que mapea, es decir asocia unívocamente, los nombres con algunos valores. Dicho en otras palabras, es un conjunto de elementos de distinto tipo que se guardan de manera consecutiva en memoria. En este sentido es equivalente al término registro que manejan los SGBD y se entiende como una fila de una tabla misma que se conforma por un conjunto de campos.

xi

ANEXO 1: REGLAS DE CODD PARA LA EVALUACIÓN DE UN SGBD

Regla 1: regla de la información

Para que un sistema se denomine "sistema de administración de bases de datos relacionales", debe usar (exclusivamente) sus capacidades relacionales para gestionar la base de datos.

Regla 2: regla del acceso garantizado

Para todos y cada uno de los datos (valores atómicos) de una Base de Datos Relacional (BDR) se garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.

Cualquier dato almacenado en una BDR tiene que poder ser direccionado unívocamente. Para ello hay que indicar en qué tabla está, cuál es la columna y cuál es la fila (mediante la clave primaria).

Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas implementaciones. En estos casos, para lograr un efecto similar se puede hacer lo siguiente:

Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).

Crear un índice único sobre la clave primaria.

No eliminar nunca el índice.

Regla 3: tratamiento sistemático de valores nulos

Los valores nulos (que son distintos de la cadena vacía, blancos, 0,...) se soportan en los SGBD totalmente relacionales para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos.

Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento sistemático de los mismos.

Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lógicas.

Lógica trivaluada. En una posible solución. Existen tres (no dos) valores de verdad: Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones lógicas:

xi

null Y null = null

Verdadero Y null = null

Falso Y null = Falso

Verdadero O null = Verdadero

Etcétera.

Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica pues es más difícil de entender.

Regla 4: diccionario dinámico en línea basado en el modelo relacional

La descripción de la base de datos se representa a nivel lógico de la misma manera que los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales.

Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se almacenan usando el modelo relacional, con todas las consecuencias.

Regla 5: regla del sub-lenguaje de datos completo

Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ejemplo: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:

Definición de datos Definición de vistas Manipulación de datos (interactiva y por programa) Limitantes de integridad Limitantes de transacción (iniciar, realizar, deshacer) (Begin,

commit, rollback).

Además de poder tener interfaces más amigables para hacer consultas, etc., siempre debe de haber una manera de hacerlo todo de manera textual, que es tanto como decir que pueda ser incorporada en un programa tradicional. Un lenguaje que cumple esto en gran medida es SQL.

xi

Regla 6: regla de actualización de vistas

Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.

El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no está muy claro.

Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.

Regla 7: inserción, actualización y borrado de alto nivel

La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la recuperación de los datos (consultas), sino también a la inserción, actualización y borrado de datos.

Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una (un registro de cada vez).

Regla 8: independencia física de datos

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel físico cuando quiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.

El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.

Es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualización de datos. La independencia física se refiere sólo a la separación entre las aplicaciones y las estructuras físicas de almacenamiento.

La capacidad de modificar el esquema conceptual sin obligar a rescribir los programas de aplicación.

Regla 9: independencia lógica de datos

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando quiera que se realicen cambios a las tablas base que preserven la información.

xi

Cuando se modifica el esquema lógico preservando información (no valdría p.ej. eliminar un atributo) no es necesario modificar nada en niveles superiores.

Ejemplos de cambios que preservan la información:

Añadir un atributo a una tabla base.

Sustituir dos tablas base por la unión de las mismas. Usando vistas de la unión puedo recrear las tablas anteriores.

Regla 10: independencia de integridad

Los limitantes de integridad específicos para una determinada base de datos relacional deben poder ser definidos en el sub-lenguaje de datos relacional y almacenables en el catálogo, no en los programas de aplicación.

El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus relaciones y evitar que éstas (limitantes) se codifiquen en los programas. Por tanto en una BDR se deben poder definir limitantes de integridad.

Cada vez se van ampliando más los tipos de limitantes de integridad que se pueden utilizar en los SGBDR, aunque hasta hace poco eran muy escasos.

Como parte de los limitantes inherentes al modelo relacional (forman parte de su definición) están:

Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una clave primaria.

Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe existir en la relación donde es primaria.

Regla 11: independencia de distribución

Una BDR tiene independencia de distribución.

Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una distribuida.

Las BDR son fácilmente distribuibles:

Las tablas se dividen en fragmentos que se distribuyen.

xi

Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los fragmentos.

Sin embargo se complica más la gestión interna de la integridad, etc.

Esta regla es responsable de tres tipos de transparencia de distribución:

Transparencia de localización. El usuario tiene la impresión de que trabaja con una BD local. (Aspecto de la regla de independencia física)

Transparencia de fragmentación. El usuario no se da cuenta de que la relación con que trabaja está fragmentada. (Aspecto de la regla de independencia lógica de datos).

Transparencia de replicación. El usuario no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares.

Regla 12: regla de la no subversión

Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto nivel (una relación (conjunto de registros) de cada vez)

Regla 0: integridad de la base de datos. Cada sistema que pretenda ser un sistema de administración de

base de datos relacional, debe ser capaz de administrar completamente los datos a través de sus capacidades relacionales.

xi

ANEXO 2: RECOPILACIÓN DE DOCUMENTOS DEL SISTEMA ACTUAL

Figura Ane2. 1 Remisión de una compra

Fuente: Digitalización propia

Figura Ane2. 2 Hoja del libro de registros o inventario


xi

Figura Ane2. 3 Remisión de una venta.


Figura Ane2. 4 Estado de cuenta de un proveedor


xi

Figura Ane2. 5 Reporte de venta diaria


Figura Ane2. 6 Reporte de compras


xi

Figura Ane2. 7 Reporte de cuentas por pagar.


Figura Ane2. 8 Concentrado de apartados.


xi

ANEXO 3: MANUAL DEL USUARIO

Documentación de la base de datos. La documentación de cualquier actividad es crucial tanto para dar

cuenta de lo que se está haciendo, como para lograr el correcto funcionamiento de la fase de arranque de aquello que se está proponiendo. Y ni que decir de los probables cambios o modificaciones que se requieran a futuro. Éstos son muy intrincados si no existe un documento base que nos dé una buena referencia de aquellos cambios que se desean realizar.

Evidentemente los sistemas de bases de datos no podrían ser la

excepción en este sentido. Por ello se suscribe lo señalado por Denis & Roth cuando dicen “la escritura de programas puede ser divertida y una actividad creativa. Los programadores noveles a menudo se les encuentra desarrollando programas y están mucho menos encantados con la tarea de probar y documentar su trabajo. No obstante un programa no pude ser considerado terminado hasta en tanto no se haya documentado y pasado las pruebas finales.” (2006)

Fase de mantenimiento.

La fase de mantenimiento comienza justo en el momento en el que el sistema de información ha sido liberado. Es por ello que se advierte: “Una vez que un sistema de información ha sido instalado se encuentra esencialmente en la fase de mantenimiento. Ahora bien, cuando un sistema se encuentra en esta fase, una persona dentro del área de desarrollo de sistemas será la responsable de recopilar solicitudes de mantenimiento de los usuarios del sistema e inclusive de terceros.” (Hoffer & Valacich, 1999).

ANE3. 1 Fases de mantenimiento.

Fuente: (Hoffer & Valacich, 1999)

FASE DESCRIPCIÓN

1 Obtención de los requerimientos de mantenimiento

2 Transformación de los requerimientos en cambios

3 Diseño de cambios

4 Implementación de cambios

xi

Vulnerabilidad de los sistemas de información. En virtud de que las bases de datos, siendo el corazón de los

sistemas de información, son un conjunto de datos organizados y relacionados entre sí, con algún propósito o tema en concreto; a menudo, éstas son el blanco perfecto para que se cometan actos ilícitos con ellas, ya que en muchos de los caso guardan información muy valiosa o inclusive confidencial. Información que utilizada con fines de lucro o extorsión, puede poner en riesgo a cualquier persona, cualquier negocio, organización empresarial o inclusive un país entero.

En este sentido se publicó el 19 de abril del presente en un periódico de circulación nacional que “bases de datos que contienen información personal de millones de mexicanos están a la venta en 12 mil dólares en la ciudad de México en el barrio de Tepito” (González, 2010). La misma nota agrega que “especialistas del Instituto Nacional de Ciencias Penales y de la Universidad Autónoma Metropolitana reconocieron que las bases de datos almacenadas por el gobierno no son 100% confiables debido a la falta de control, que las hace vulnerables a robos y fugas de información.”

Para Alberto Nava, especialista en delitos cibernéticos del Instituto Nacional de Ciencias Penales (INACIPE) y citado por Luz María González, autora del artículo antes referido, “las bases de datos de los ciudadanos en poder de instancias gubernamentales no son tan seguras como deberían serlo, pues no hay disposiciones expresas sobre su resguardo, confidencialidad y manejo. Con respecto a las sanciones por robo de información, afirmó que están contempladas en el artículo 211Bis del Código Penal Federal, pero esta disposición protege solamente a las entidades federales y no a las bases locales, como las de tenencia e impuesto predial” (2010). Por su parte, José Luis Piñeyro, especialista en temas de seguridad de la UAM y también citado por González en su nota periodística, consideró que “se requieren urgentemente mayores controles para el manejo de las bases de datos con información oficial y de ciudadanos por lo que propuso establecer mecanismos de auditorías y rendición de cuentas, tanto internamente, desde las propias dependencias gubernamentales como en las compañías que tienen bajo su resguardo las bases de datos, como a través del Poder Legislativo pudiendo ser una comisión del Poder Legislativo la que supervise al personal y garantice la confidencialidad de las bases de datos, de o contario, los riesgos pueden ser muy altos.” (González, 2010).

Como reacción a lo anterior, tres días más tardes se publicó en el

mismo medio impreso que “el secretario de Gobernación, Fernando Gómez Mont, estaba preocupado por la venta en internet de datos personales de millones de mexicanos e informó que la PGR y el CISEN investigarían el caso.” (Ramos, 2010). En la misma nota periodística se “confirmó que Jacqueline Peschard, comisionada presidenta del Instituto Federal de Acceso a la Información (IFAI), presentó una queja ante la dependencia para que investigue si hay funcionarios federales involucrados en la venta de la base de datos del padrón electoral.”

xi

Al margen de las querellas legales y de la veracidad de la publicación periodística, lo que es evidente es que las bases de datos son altamente vulnerables y que mal utilizadas pueden dañar muy gravemente lo mismo a un individuo que a una nación completa.



i. Ing. José Luis González Domínguez Página xii

ÍNDICE DE FIGURAS Figura 1. 1 Ubicación geográfica del municipio de Actopan Hidalgo ........................................................... 3 Figura 1. 2 Interrelación de las funciones del diseño de sistemas. .............................................................. 5 Figura 1. 3 Fotografía del Dr. Edgar F. Codd. ............................................................................................... 7 Figura 1. 4 Pirámide Conceptual................................................................................................................... 8

Figura 2. 1 Identificación de lo que se tiene que hacer en una investigación ............................................. 12 Figura 2. 2 Organigrama del Negocio. ....................................................................................................... 15 Figura 2. 3 Diagrama de Casos de Uso para el Negocio del Caso de Estudio ............................................. 16 Figura 2. 4 Diagrama de Flujo de Datos Nivel 0 para el Negocio: "La Casa de los Azulejos". .................... 17 Figura 2. 5 Diagrama de Flujo de Datos Modificado Nivel 1 para el negocio caso de estudio. .................. 18 Figura 2. 6 Diagrama en Bloques Modificado para el Caso de Estudio. ..................................................... 19 Figura 2. 7 Diagrama de PERT del proyecto. .............................................................................................. 29 Figura 2. 8 Diagrama de Flujo de Datos modificado (DFD-M) del Nuevo Sistema Propuesto. ................... 34 Figura 2. 9 Gráfica del Análisis Costo-Beneficio del Sistema de Información. ............................................ 35 Figura 2. 10 Arquitectura Básica del Sistema Propuesto. ........................................................................... 37 Figura 2. 11 Salida No. 1 del Sistema de información. ............................................................................... 39 Figura 2. 12 Salida No. 2 del Sistema de información. ............................................................................... 40 Figura 2. 13 Entrada No. 1 del Sistema de información. ............................................................................ 41 Figura 2. 14 Entrada No. 2 del Sistema de información. ............................................................................ 41 Figura 2. 15 Modelo Warnier-Orr del Sistema de Información. ................................................................. 43 Figura 2. 16 Diseño Arquitectónico del Sistema. ........................................................................................ 44 Figura 2. 17 Modelo Relacional de la Base de Datos. ................................................................................. 45

Figura 3. 1 Factura de compra de los componentes de la computadora a armar ...................................... 49 Figura 3. 2 Componentes empacados de la computadora a armar ........................................................... 50 Figura 3. 3 Componentes desempacados de la computadora a armar. ..................................................... 50 Figura 3. 4 Tarjeta madre. .......................................................................................................................... 51 Figura 3. 5 Cableado de la computadora ................................................................................................... 53 Figura 3. 6 Vista interna de la computadora ya armada ............................................................................ 53 Figura 3. 7 Primer encendido de la computadora ...................................................................................... 54 Figura 3. 8 Configuración del "setup" ......................................................................................................... 54 Figura 3. 9 Discos de instalación del sistema operativo. ............................................................................ 55 Figura 3. 10 Programa de Instalación de Windows XP Profesional. ........................................................... 55 Figura 3. 11 Instalación del Sistema Operativo al 50%. ............................................................................. 56 Figura 3. 12 Instalación de los controladores. ............................................................................................ 56 Figura 3. 13 Culminación de la instalación del Sistema Operativo y controladores. .................................. 57 Figura 3. 14 Instalación del Sistema Gestor de la Base de Datos. .............................................................. 57 Figura 3. 15 Instalación de paquetería complementaria de Microsoft Office 2007. .................................. 58 Figura 3. 16 Diseño conceptual de una base de datos. .............................................................................. 61 Figura 3. 17 Diseño lógico de la base de datos ........................................................................................... 62 Figura 3. 18 Formas Normales. .................................................................................................................. 65 Figura 3. 19 Tablas y sus relaciones ........................................................................................................... 66 Figura 3. 20 Formulario del Registro de Compras. ..................................................................................... 77 Figura 3. 21 Formulario del Registro de Ventas. ........................................................................................ 78 Figura 3. 22 Captura de Información de Clientes. ...................................................................................... 78 Figura 3. 23 Informe de Existencia de Productos en Inventario. ................................................................ 79



i. Ing. José Luis González Domínguez Página xiii

ÍNDICE DE TABLAS Tabla 1. 1 Fases de la metodología de Checkland ........................................................................................ 6

Tabla 2. 1 Recopilación de documentos del sistema actual (1ra. parte) .................................................... 21 Tabla 2. 2 Recopilación de documentos del sistema actual (2a. parte) ..................................................... 22 Tabla 2. 3 Tabla Sistémica de los Elementos del Sistema Actual. ............................................................... 24 Tabla 2. 4 Diagrama de Gantt del Proyecto en su conjunto. ...................................................................... 27 Tabla 2. 5 Análisis Costo-Beneficio del Sistema de Información a Desarrollar. .......................................... 35 Tabla 2. 6 Tabla Sistémica de los Nuevos Elementos del Sistema. ............................................................. 38

Tabla 3. 1 Requerimientos de hardware del sistema ................................................................................. 48 Tabla 3. 2 Herramientas necesarias para el armando de la computadora. .............................................. 51 Tabla 3. 3 Secuencia general de armado de computadora ........................................................................ 52 Tabla 3. 4 Catálogo de Proveedores ........................................................................................................... 68 Tabla 3. 5 Catálogo de Compradores ......................................................................................................... 69 Tabla 3. 6 Diccionario de Datos: Compras. ................................................................................................. 70 Tabla 3. 7 Diccionario de Compras: Compras Detalle. ................................................................................ 71 Tabla 3. 8 Diccionario de Datos: Productos. ............................................................................................... 72 Tabla 3. 9 Diccionario de Datos: Movimientos al Inventario. ..................................................................... 73 Tabla 3. 10 Diccionario de Datos: Clientes. ................................................................................................ 74 Tabla 3. 11 Diccionario de Datos: Ventas. .................................................................................................. 75 Tabla 3. 12 Diccionario de Datos: Detalle de Ventas. ................................................................................. 76

Tabla 4. 1 Lista de cotejo de las características de las pruebas de software.............................................. 83

Documents

INSTITUTO POLITÉCNICO NACIONAL...i NOMBRE DE LA MATERIA DESARROLLO HUMANO INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECANICA Y ELÉCTRICA SECCIÓN DE ESTUDIOS