Documentacion de Residencia, tesis,

7/25/2019 Documentacion de Residencia, tesis,

1/139

INSTITUTO TECNOLGICO DE TAPACHULA

INGENIERA EN SISTEMAS COMPUTACIONALES PROYECTO:SISTEMA DE CONTROL INTEGRAL PARA LA SALAC DEL

LABORATORIO DE CMPUTO DELINSTITUTO TECNOLGICO DE TAPACHULA.

RESIDENTES:

SAMORANO LPEZ LENY FABIOLA 11510679

MARTNEZ RAMOS SHEYLA BERENICE 11510537

AGOSTO-DICIEMBRE 2015

FECHA DE INICIO: 24 DE AGOSTO DE 2015

FECHA DE TERMINACIN:

LIC. MNICA SIBLINAMARTNEZ SOLS

LIC. EZEQUIEL CRUZWONG

ASESOR EXTERNO ASESOR INTERNO


2/139

2

RESUMEN

Este proyecto describe el desarrollo de un sistema de control de acceso y salida para la

sala C del laboratorio de cmputo ya que su principal propsito consiste en reducir tiempos

de espera por parte del alumno del ITT.

Con la implantacin del sistema se ofrecer un servicio de calidad a los alumnos, ya

que permitir agilizar el proceso de registro, mantener la informacin en tiempo y forma, y

mejorar la eficiencia.


3/139

Tabla de contenido

RESUMEN............................................................................................................................. 2

ndice de Ilustraciones.............................................................................................................. 7

INTRODUCCIN................................................................................................................... 9

CAPITULO I........................................................................................................................ 11

DESCRIPCIN DEL PROYECTO.......................................................................................... 11

1. DESCRIPCIN DEL PROYECTO ............................................................................ 12

1.1 PLANTEAMIENTO DEL PROBLEMA ................................................................ 12

1.2 JUSTIFICACIN ................................................................................................ 13

1.3 OBJETIVOS ...................................................................................................... 14

1.3.1 OBJETIVO GENERAL ................................................................................ 14

1.3.2 OBJETIVOS ESPECFICOS ....................................................................... 14

1.4 ALCANCES DEL PROYECTO ........................................................................... 151.5 LIMITACIONES DEL PROYECTO ..................................................................... 15

1.6 IMPACTO .......................................................................................................... 16

1.6.1 IMPACTO SOCIAL ..................................................................................... 16

1.6.2 IMPACTO ECONMICO ............................................................................ 16

1.6.3 IMPACTO TECNOLGICO ........................................................................ 16

CAPITULO II....................................................................................................................... 17

ANTECEDENTES DEL......................................................................................................... 17

INSTITUTO TECNOLGICO DE TAPACHULA.................................................................... 17

2. ANTECEDENTES DE LA INSTITUCIN .................................................................. 18

2.1 HISTORIA .......................................................................................................... 18

2.2 DIRECTORES Y SUBDIRECTORES/AS ........................................................... 18

2.3 DIRECTORIO DE LA INSTITUCIN .................................................................. 21

2.4 EVOLUCIN ACADMICA ................................................................................ 23

2.5 LOGROS SIGNIFICATIVOS .............................................................................. 25

2.6 IMPACTO EN LA SOCIEDAD ............................................................................ 26

2.7 MISIN .............................................................................................................. 27

2.8 VISIN .............................................................................................................. 27

2.9 GIRO DE LA INSTITUCIN ............................................................................... 27

2.10 VALORES .......................................................................................................... 27

2.11 POLTICAS DE CALIDAD .................................................................................. 28

2.12 ORGANIGRAMA DEL LABORATORIO DE CMPUTO .................................... 28

2.13 UBICACIN ....................................................................................................... 29

CAPITULO III...................................................................................................................... 30


4/139

4

MARCO TERICO............................................................................................................... 30

3. MARCO TERICO ................................................................................................... 31

3.1 SISTEMAS DE INFORMACIN ......................................................................... 31

3.1.1 DEFINICIN DE UN SISTEMA DE INFORMACIN (SI) ............................ 31

3.1.2 CARACTERIZACIN DE UN SISTEMA DE INFORMACIN ..................... 31

3.1.3 ELEMENTOS QUE CONFORMAN UN SISTEMA DE INFORMACIN ...... 32

3.1.4 ACTIVIDADES QUE REALIZA UN SISTEMA DE INFORMACIN ............... 33

3.2 INGENIERA DE SOFTWARE ........................................................................... 34

3.2.1 DEFINICIONES DE LA INGENIERA DE SOFTWARE ............................... 34

3.2.2 ELEMENTOS DE LA INGENIERA DE SOFTWARE .................................. 35

3.2.3 EL CICLO DE VIDA DEL SOFTWARE. ....................................................... 36

3.3 METODOLOGA RUP ........................................................................................ 37

3.3.1 CARACTERSTICAS .................................................................................. 38

3.3.2 CICLO DE VIDA ......................................................................................... 393.3.3 DISCIPLINA DE DESARROLLO DE RUP ................................................... 41

3.3.4 ELEMENTOS DEL RUP ............................................................................. 41

3.3.5 ARTEFACTOS ........................................................................................... 41

3.4 UML (LENGUAJE UNIFICADO DE MODELADO) .............................................. 42

3.4.1 DEFINICIN DE UML ................................................................................. 42

3.4.2 DIAGRAMA DE CLASES ............................................................................ 43

3.4.3 DIAGRAMA DE CASOS DE USO ............................................................... 44

3.4.4 DIAGRAMA DE SECUENCIA ..................................................................... 45

3.4.5 DIAGRAMA DE COLABORACIN ............................................................. 46

3.5 BASE DE DATOS .............................................................................................. 47

3.5.1 CICLO DE VIDA DE UNA BASE DE DATOS .............................................. 47

3.5.2 MODELOS DE LOS DATOS ....................................................................... 49

3.5.3 MODELOS DE DATOS BASADOS EN OBJETOS ..................................... 49

3.5.4 MODELOS DE DATOS BASADOS EN REGISTROS ................................. 49

3.5.5 MODELO DE DATOS FSICOS .................................................................. 50

3.5.7 MODELO ENTIDAD-RELACIN ................................................................ 50

3.5.8 CARDINALIDAD ......................................................................................... 52

3.5.9 MODELO RELACIONAL ............................................................................. 53

3.5.10 LAS RELACIONES EN EL MODELO RELACIONAL .................................. 54

3.5.11 NORMALIZACIN ...................................................................................... 54

3.6 SISTEMAS GESTORES DE BASE DE DATOS (SGBD) ................................... 55

3.5.7 FUNCIONES DE LOS SGBD...................................................................... 55

3.6.2 ABSTRACCIN DE DATOS ....................................................................... 57


5/139

5

3.7 LENGUAJES DE BASE DE DATOS .................................................................. 58

3.7.1 LENGUAJE DE DEFINICIN DE DATOS ................................................... 58

3.7.2 LENGUAJE DE MANIPULACIN DE DATOS ............................................ 58

3.7.3 LENGUAJE SQL ......................................................................................... 59

3.8 MY SQL WORKBENCH ..................................................................................... 60

3.8.1 MANIPULACIN E IMPORTACIN DE DATOS ........................................ 60

3.9 LENGUAJE DE PROGRAMACIN .................................................................... 61

3.9.1 PARADIGMAS EN LENGUAJES DE PROGRAMACIN. ........................... 61

3.9.2 JAVA .......................................................................................................... 62

3.9.3 CARACTERSTICAS DE JAVA................................................................... 63

3.9.4 EL ENTORNO DE DESARROLLO DE JAVA.............................................. 64

3.10 ENTORNO DE PROGRAMACIN ..................................................................... 65

3.10.1 CARACTERSTICAS .................................................................................. 66

3.11 NAVICAT ........................................................................................................... 66CAPITULO IV...................................................................................................................... 68

DESARROLLO Y DESCRIPCIN DEL SISTEMA................................................................. 68

4. DESARROLLO Y DESCRIPCIN DEL SISTEMA .................................................... 69

4.1 CASOS DE USO ............................................................................................... 69

4.2 DESCRIPCIN DE CASOS DE USO ................................................................ 72

4.3 DIAGRAMA DE DESPLIEGUE .......................................................................... 77

4.4 MODELO RELACIONAL .................................................................................... 78

4.5 DICCIONARIO DE DATOS ................................................................................ 79

4.5.1 DALUMN .................................................................................................... 79

4.5.2 DCALUM.................................................................................................... 79

4.5.3 DCONFIG ................................................................................................... 80

4.5.4 DEQUIPO:.................................................................................................. 80

4.5.5 DESTADO .................................................................................................. 80

4.5.6 DINCIDENCIA ............................................................................................ 81

4.5.7 DINSTANCIA.............................................................................................. 81

4.5.8 DREPORT .................................................................................................. 81

4.5.9 DUSERS.................................................................................................... 82CAPITULO V RESULTADOS OBTENIDOS.......................................................................... 83

5. RESULTADOS ......................................................................................................... 84

5.1 PRUEBAS REALIZADAS ................................................................................... 84

5.2 PRUEBAS CON LECTOR DE CDIGO DE BARRAS ....................................... 84

5.3 PROPUESTA..................................................................................................... 86

5.4 CONCLUSIONES Y RECOMENDACIONES ..................................................... 86


6/139

6

ANEXOS.............................................................................................................................. 89

ANEXO 1 MANUAL DE INSTALACION.............................................................................. 90

REQUERIMIENTOS ..................................................................................................... 90

INSTALACIN DE NETBEANS ................................................................................... 91

INSTALACIN DE MYSQL ........................................................................................ 117

INSTALACION DE NAVICAT ..................................................................................... 127

ANEXO 2 MANUAL DE USUARIO DEL SISTEMA............................................................. 141

MEN PRINCIPAL ..................................................................................................... 141

MODULO PRESENTACIN....................................................................................... 146

MODULO ADMINISTRACIN DE EQUIPOS ............................................................. 150

MODULO ADMINISTRACIN DE USUARIOS ........................................................... 151

MODULO ALUMNOS EN SALA ................................................................................. 152

MODULO AGREGAR CARRERA............................................................................... 152

MODULO ADMINISTRACIN DE INCIDENCIAS ...................................................... 153MODULO IMPORTAR\EXPORTAR BASE DE DATOS .............................................. 154

MODULO REPORTES ............................................................................................... 155


7/139

7

ndice de IlustracionesILUSTRACIN 1 TOTAL DE ALUMNOS INSCRITOS EN LA INSTITUCIN.................................................................. 22ILUSTRACIN 2 ORGANIGRAMA DEL LABORATORIO DE CMPUTO DEL ITT ........................................................ 28ILUSTRACIN 3 UBICACIN DEL INSTITUTO TECNOLGICO DE TAPACHULA ....................................................... 29ILUSTRACIN 4 ELEMENTOS DE UN S.I. ................................................................................................................ 32ILUSTRACIN 5 ACTIVIDADES QUE REALIZA UN S.I. .............................................................................................. 34

ILUSTRACIN 6 ESFUERZO EN ACTIVIDADES SEGN FASE DEL PROYECTO .......................................................... 39ILUSTRACIN 7 EJEMPLO DE DIAGRAMA DE CLASES ............................................................................................ 43ILUSTRACIN 8 EJEMPLO DE UN CASO DE USO .................................................................................................... 44ILUSTRACIN 9 EJEMPLO DE UN DIAGRAMA DE SECUENCIA ............................................................................... 46ILUSTRACIN 10 EJEMPLO DE UN DIAGRAMA DE COLABORACIN ..................................................................... 47ILUSTRACIN 11 EJEMPLO DE MODELO ENTIDAD- RELACIN ............................................................................. 52ILUSTRACIN 12 EJEMPLO DE UNA BASE DE DATOS RELACIONAL ....................................................................... 53ILUSTRACIN 13 DEFINICIN DE RELACIN .......................................................................................................... 54ILUSTRACIN 14 LOS NIVELES DE ABSTRACCIN DE LOS DATOS ......................................................................... 58ILUSTRACIN 15 CASO DE USO GESTIN DE CARRERAS ....................................................................................... 69ILUSTRACIN 16 CASO DE USO GESTIN DE EQUIPOS ......................................................................................... 70ILUSTRACIN 17 CASO DE USO GESTIN DE USUARIOS ....................................................................................... 70ILUSTRACIN 18 CASO DE USO GESTIN DE ALUMNOS ....................................................................................... 71ILUSTRACIN 19 CASO DE USO GESTIN DE INCIDENCIAS ................................................................................... 71ILUSTRACIN 20 DIAGRAMA DE DESPLIEGUE DEL SISTEMA ................................................................................. 77ILUSTRACIN 21 ESQUEMA E-R DEL SISTEMA ...................................................................................................... 78ILUSTRACIN 22 LECTOR DE CDIGO DE BARRAS MODELO EC-CD-8500 ............................................................. 85
http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415070http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415070http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415075http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415075http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415077http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415077http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415078http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415078http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415079http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415079http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415080http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415080http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415081http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415081http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415083http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415083http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415086http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415086http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415087http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415087http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415088http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415088http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415088http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415087http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415086http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415083http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415081http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415080http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415079http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415078http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415077http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415075http://c/Users/Markus/Desktop/Sheyla/prueba.docx%23_Toc451415070


8/139

8

ndice de TablasTABLA 1 DOCUMENTACIN DEL CASO DE USO GESTION DE USUARIOS - AGREGAR USUARIO............................ 72TABLA 2 DOCUMENTACIN DEL CASO DE USO GESTION DE USUARIOS - EDITAR USUARIOS .............................. 73TABLA 3 DOCUMENTACIN DEL CASO DE USO GESTION DE EQUIPOS - AGREGAR EQUIPOS .............................. 74TABLA 4 DOCUMENTACIN DEL CASO DE USO MODULO PRESENTACIN - INGRESAR ALUMNOS A SALA ......... 75TABLA 5 DOCUMENTACIN CASO DE USO MODULO ADMINISTRACIN DE EQUIPOS - ELIMINAR EQUIPOS ...... 76

TABLA 6 DALUMN .................................................................................................................................................. 79TABLA 7 DCALUM .................................................................................................................................................. 79TABLA 8 DCONFIG.................................................................................................................................................. 80TABLA 9 DEQUIPO ................................................................................................................................................. 80TABLA 10 DEQUIPO ............................................................................................................................................... 80TABLA 11 DIICIDENCIA ........................................................................................................................................... 81TABLA 12 DINSTANCIA........................................................................................................................................... 81TABLA 13 DREPORT ............................................................................................................................................... 81TABLA 14 DUSERS .................................................................................................................................................. 82TABLA 15 CARACTERSTICAS TCNICAS DEL LECTOR DE CDIGO DE BARRAS ...................................................... 85


9/139

9

INTRODUCCIN

El Instituto Tecnolgico de Tapachula es una institucin educativa con ms de 30

aos en la formacin de profesionales en distintas carreras, siendo su principal objetivo

formar profesionales con slida base cientfica, tcnica y humanstica; profundizar la

actividad de investigacin, incidiendo en la aplicacin e innovacin de la ciencia y la

tecnologa.

Actualmente la sala C del Laboratorio de Computo de dicha institucin necesita de

un sistema integral que le permita agilizar los tiempos en cuanto al prstamo de un equipo de

cmputo. El implementar un sistema integral en esta institucin es de vital importancia con

el cual se pretende disminuir el tiempo de espera y ofrecer un servicio de calidad a los

alumnos.

El sistema que se presenta a continuacin, controlara informacin de la Sala C del

Laboratorio de Computo y nicamente ser disponible para las personas autorizadas.

Este documento est dividido en cinco captulos, cuyo contenido se describe a

continuacin:

En el captulo 1, se describe en que consiste el proyecto, as como sus objetivos,

limitaciones y alcance.

En el captulo 2, se da una pequea descripcin del instituto Tecnolgico deTapachula as como un diagnstico de la situacin dentro de la sala C del laboratorio de

Cmputo.

En el captulo 3, se describen y desarrollan las bases tericas que fundamentan el

proyecto, y se habla de base de datos, sistemas gestores, lenguaje de programacin y entorno


10/139

10

de desarrollo.

En el captulo 4, se describen las herramientas de diseo que se emplearon para la

creacin del sistema, como son casos de uso, modelo entidad relacin, etc.

En el captulo 5, se dan los resultados obtenidos durante las pruebas realizadas, y

conclusiones.


11/139

11

CAPITULO I

DESCRIPCIN DEL PROYECTO


12/139

12

1.DESCRIPCIN DEL PROYECTO

1.1 PLANTEAMIENTO DEL PROBLEMA

Actualmente la sala C del Laboratorio de Computo del Instituto Tecnolgico de

Tapachula cuenta con un sistema de acceso tradicional, es decir, mediante el llenado de un

formulario que es otorgado por los alumnos que realizan servicio social dentro del

laboratorio. En dicho formulario se anota el nmero de control, nombre, carrera, semestre as

como la hora de ingreso y de salida.

En este registro cada persona debe ser responsable de indicar su hora de entrada as

como su respectiva salida, pero no todos lo hacen. De esta forma el registro se vuelve intil

ya que no cumple su propsito como debe ser.

Este mtodo empleado para el acceso a la sala C no es muy confiable, debido a que la

informacin no lleva un orden y conforme los alumnos van ingresando a la sala, se van

anotando en dicho formulario, y en ciertas ocasiones se llegan a saltar el paso de registro.

Dichas listas donde se registran los accesos de los alumnos a la sala se almacenan en

cajas comunes, y esto conlleva al almacenamiento de infinidad de ellas, los cuales son un

problema cuando se necesita informacin del uso de los equipos de la sala C, ya que los

reportes no pueden elaborarse a tiempo y esto conlleva a no tener un control actualizado del

acceso a la sala C.

Debido a que esta informacin es capturada de forma manual, hay ocasiones que se

llegan a generar problemas, como la perdida de informacin por estar incompleto dicho

formulario, as como tambin que no est legible para la persona que lleva a cabo la captura,

por lo que los datos que se generan, no se encuentran disponibles en el momento en que se


13/139

13

requiere, lo que implica perder informacin y tiempo, lo cual no permite actualizar los datos

que se solicita.

El proceso de registro para tener acceso a la sala C, llega a ser tedioso y tardado para

los alumnos, ya que mientras esperan la asignacin de un equipo, puede que otro usuario

tome un equipo que este en buenas condiciones, lo que provoca que el usuario que se estaba

registrando se le asigna un equipo en psimas condiciones, o ya sea sin servicio de internet, lo

que genera la prdida de tiempo del usuario, as como frustracin y enojo al no contar con un

equipo del cual hacer uso para realizar sus tareas o sus respectivas investigaciones.

1.2 JUSTIFICACIN

Debido al aumento en cuanto al nmero de estudiantes de las carreras que oferta la

institucin y al avance tecnolgico, los encargados de dicho centro de cmputo se ven con la

necesidad de requerir un sistema en donde lleven el control de los accesos del alumnado a la

sala C del laboratorio de cmputo.

Es as que se lleg a la conclusin de disear y desarrollar un sistema que lleve el

control de acceso y estadsticas, el cual contar con los siguientes beneficios:

Tener un control de los prestadores de servicios (alumnos de servicio social), los cuales

llevaran el registro de los estudiantes que tienen acceso a la sala C del Laboratorio de

Cmputo.

Gestionar el acceso a la sala C, del Laboratorio de Computo.

Llevar un registro estadstico de la informacin

Agilizar el tiempo de espera.

Mejorar la calidad de la informacin recabada.


14/139

14

Registro de incidentes donde se guardaran los incidentes que se produzcan dentro de

la sala C del Laboratorio de Computo y donde un alumno sea el responsable.

Para la realizacin de este sistema se ha planteado un conjunto de actividades, desde

el anlisis de cmo opera la sala C del Laboratorio de Computo, el diseo del sistema y un

anlisis en cuanto a la herramienta adecuada que cumpla con las expectativas en cuanto al

desarrollo y programacin del sistema.

Con ese sistema se obtendr una buena organizacin, eficiencia, optimizacin del

tiempo de espera ya que se pretende disminuir el tiempo de atencin, buscado darle al

alumnado un mejor servicio.

1.3 OBJETIVOS

1.3.1 OBJETIVO GENERAL

Desarrollar un sistema integral que permita llevar el control de acceso, reportes y

estadsticas, para as obtener un mejor control de los datos de los usuarios de la sala C del

laboratorio de cmputo del Instituto Tecnolgico de Tapachula.

1.3.2 OBJETIVOS ESPECFICOS

Recabar la informacin sobre los servicios y funcionamiento de la sala C, as como

tambin los requerimientos a necesitar para el desarrollo y diseo del sistema.

Disear y desarrollar el sistema en una plataforma flexible, adecuada y fcil de

realizar, para lograr un buen sistema, utilizando los recursos con los que cuenta el

Instituto Tecnolgico de Tapachula.

Permitir el acceso de los alumnos, empleando un lector de cdigo de barra, el cual a

travs de su credencial de la escuela le dar el acceso a la sala C del Laboratorio de


15/139

15

Cmputo.

Hacer uso de las herramientas necesarias que permitan al sistema hacer conteos

estadsticos del acceso a la sala C.

Revisar los registros de entrada como de salida, verificando que se ponen a

disposicin del personal autorizado para ello.

Documentar el sistema de control de acceso y de servicios, con el fin de lograr las

expectativas deseadas y lograr cubrir las necesidades.

Determinar si el sistema es bien utilizado, si el mantenimiento que se le brindara es

confiable y seguro, si todos los cambios son suficientemente controlados.

1.4 ALCANCES DEL PROYECTO

Desarrollar un sistema integral de control de acceso, monitoreo y administracin,

validando los accesos del alumnado en general a travs del registro de cada alumno mediante

el nmero de control que se encuentra en su credencial estudiantil, que ser escaneado por

medio de un lector de cdigo de barras y de sta forma obtener los reportes y estadsticas de

uso tal y como lo requiera el personal del laboratorio de cmputo.

1.5 LIMITACIONES DEL PROYECTO

Se pretende analizar y desarrollar el sistema en un tiempo que comprende a los cuatro

meses como mnimo y como mximo de 6 meses, que es la duracin de la residencia.

La falta de otorgamiento de recursos por parte de la institucin para adquirir el lector

de cdigo de barras, sin embargo, si no se obtiene el mismo, se proceder a realizar

modificaciones al sistema, validando los accesos en forma manual a travs de teclear

el nmero de control del alumno.


16/139

16

El sistema solamente pretende registrar el acceso de los alumnos a la sala C del

Laboratorio de Cmputo. Puesto que el registro del acceso a la sala se lleva mediante

el nmero de control que se les otorga cuando se inscriben a la institucin.

Debido al tiempo de duracin de la residencia, posiblemente los conteos estadsticos

no puedan culminarse, dejando abierta la posibilidad para que ms adelante se pueda

terminar dicho objetivo, y realizarle mejoras al sistema.

El sistema ser implantado siempre y cuando se cuente con la autorizacin del jefe

del laboratorio y se tenga acceso a un equipo dentro de la sala C.

1.6 IMPACTO

1.6.1 IMPACTO SOCIAL

El impacto que se obtendr en el aspecto social es que al implementarse el sistema de

control de acceso dentro de la sala C los alumnos recibirn un servicio de calidad y eficiente al

disminuir los tiempos de espera por un equipo.

1.6.2 IMPACTO ECONMICO

Con la implantacin del sistema no se tendrn que adquirir licencias de pago, puesto

que las herramientas que se emplearon para disearlo e instalarlo son de software libre, siendo

as un ahorro en cuanto a costos.

1.6.3 IMPACTO TECNOLGICO

El impacto tecnolgico que se tendr consiste en tener un control de acceso usando

herramientas accesibles y de buena calidad, dejando de lado el registro tradicional y utilizando

un sistema. As la sala C contara con un sistema que registre el acceso de los alumnos.


17/139

17

CAPITULO II

ANTECEDENTES DEL

INSTITUTO TECNOLGICO DE TAPACHULA


18/139

18

2.ANTECEDENTES DE LA INSTITUCIN

2.1 HISTORIA

El 8 de abril con base y fundamento en el Decreto Presidencial, publicado en el Diario

Oficial de la Federacin, desaparece el Centro Regional de Enseanza Tcnica Industrial del

Soconusco (CeRETI Soconusco) y por instrucciones del Subsecretario de Educacin e

Investigacin Tecnolgicas, se cre en su lugar el Instituto Tecnolgico de Tapachula el da

16 de mayo de 1983.

El Instituto Tecnolgico de Tapachula inicia sus actividades administrativas el 15 de

junio, y las labores acadmicas el 22 del mismo mes, atendiendo en primera instancia, a la

poblacin estudiantil de los niveles medio superior y superior que pertenecan al CeRETI

Soconusco.

El 1 de julio del mismo ao, da inicio el primer semestre para alumnos inscritos dentro

del plan de estudios del Sistema Nacional de Institutos Tecnolgicos.

La planta de trabajadores estaba conformada por 81 personas, para atender una

matrcula de 148 alumnos de nivel medio superior y 172 alumnos del nivel superior.

2.2 DIRECTORES Y SUBDIRECTORES/AS

En julio de 1984, fue designado como director del Instituto Tecnolgico de Tapachula,

el C. Ing. Jorge El Castellanos Martnez, quin haba fungido como subdirector desde julio

de 1983 y fue relevado en la subdireccin por el C. M. C. Alberto Ganzo Figueroa.

El C. Ing. Jorge Carlos Garca Revilla, asume en julio de 1985 la direccin del

plantel, durante su gestin estuvieron como subdirectores los CC. Dr. Ren Javier Than


19/139

19

Mrquez (septiembre del 84 a mayo del 86) e Ing. Enrique Martnez Castillo (mayo 86 a

enero 87).

Correspondi en Marzo de 1987, al C. Ing. Nicols Baca Cisneros, tener la

responsabilidad de la Institucin, colaborando como subdirectores los CC. Ing. Ricardo

Jurez Lpez (enerojunio 87) e Ing. Vctor Manuel Ibarra Balderas (junio 87noviembre

88).

En 1988, ocurren cambios nuevamente, y a principios de septiembre, el C. Ing.

Ambrosio Elas Bernal Alcntara, acepta la direccin del plantel, y a fines del mes de

noviembre por segunda ocasin, un subdirector es el encargado de llevar las riendas de la

Institucin, esta responsabilidad recae en el C. Ing. Vctor Manuel Ibarra Balderas, y el

Ing. Jos Luis Mndez Navarro, lo sustituye en la subdireccin (noviembre 88 agosto

92).

En agosto de 1992, el C. Ing. Jos Luis Mndez Navarro recibe el nombramiento

de Director del Instituto Tecnolgico de Tapachula, y en este mismo mes, la subdireccin

queda bajo la responsabilidad del C. Ing. Armando Jess Zaragoza Villafn.

Las necesidades de organizacin fueron cambiantes y dinmicas, en atencin a la

demanda de la poblacin estudiantil, y fue as que el 11 de marzo de 1994, se autoriza y registra

en la Direccin General de Institutos Tecnolgicos (DGIT), la estructura orgnica funcional

de la Institucin, lo cual permite que se integren como directivos los CC. Ing. integren como

directivos: los CC. Ing. Alberto Romn Bonilla Villanueva, Ing. Armando Jess Zaragoza

Villafn e Ing. Ignacio Valdivia Mndez, como subdirectores de Planeacin y Vinculacin,

Acadmico y de Servicios Administrativos respectivamente.

El 6 de octubre de 1995, en presencia del C. Ing. Agustn Vzquez Vera, Subdirector


20/139

20

de Operacin de la DGIT, toma posesin como director el C. Ing. Alberto Romn Bonilla

Villanueva y en su lugar asume la responsabilidad de la subdireccin de planeacin y

vinculacin el C. Ing. Julio Csar Albores Abarca.

Nuevos cambios se suscitan y el C. Ing. Julio Csar Albores Abarca, a partir del 16

marzo del 1999, se desempea como Subdirector Acadmico y el C. M. A. Juan Amado

Rueda Ibarra, lo sustituye en la Subdireccin de Planeacin y Vinculacin.

A partir del 24 de febrero de 2000, un destacado egresado de la Institucin, asume el

cargo de Director del Instituto Tecnolgico de Tapachula, este honor le corresponde al C.

Mtro. Juan Amado Rueda Ibarra, sus colaboradores directivos son los CC.: Ing. Pedro

Ancheyta Bringas, Subdirector de Planeacin y Vinculacin, Ing. Julio Csar Albores Abarca,

Subdirector Acadmico y M. en A. Alicia Georgina Palacios Trinidad, Subdirectora de

Servicios Administrativos.

Un nuevo ciclo comienza a partir del 15 de diciembre de 2005, cuando toma posesin

como Director el Ing. Herman Caldern Pineda, sus colaboradores directivos son: Ing. JosAlfredo Len Hernndez subdirector acadmico, Mtro. Gelasio Montes Roa subdirector de

planeacin y vinculacin y el Mtro. Fernando Lpez Snchez subdirector de servicios

administrativos.

Con la representacin personal del Dr. Carlos Alfonso Garca Ibarra, Director General

de Educacin Superior Tecnolgica, el Mtro. Hctor Francisco Macas Daz, director de

Capacitacin y Desarrollo, el 26 de Marzo de 2010, le dio posesin como Director el M.C.A.

Miguel Cid Del Prado Martnez, destacado egresado de la Institucin. Su equipo de

colaboradores lo conforman como directivos: el Ing. Jos Alfredo Len Hernndez,

subdirector acadmico y el Mtro. Fernando Lpez Snchez, subdirector de servicios


21/139

21

administrativos.

En octubre de 2010, toman posesin como subdirectores: el Mtro. Fernando Lpez

Snchez, subdirector acadmico, el Mtro. Delfino Lpez Vzquez, subdirector de planeacin

y vinculacin y el Ing. Francisco Javier Meoo Morales, subdirector de servicios

administrativos.

2.3 DIRECTORIO DE LA INSTITUCIN

El directorio de la Institucin est conformado de la siguiente manera:

Ing. Pedro Ancheyta Bringas- Director del Instituto Tecnolgico de Tapachula

Ing. Fausto Salvador Garca Glvez- Jefe del Departamento de Ciencias Bsicas

Ing. Martn Njera Trejo - Jefe del Departamento de Ciencias de la Tierra

Ing. Rosember Hidalgo Lpez - Jefe del Departamento de Ingeniera Qumica y

Bioqumica

Dr. Luis Miguel Hernndez Barajas - Jefe del Departamento de Ingeniera Industrial

Mtra. Andrea Castaeda Reyes - Jefa del Departamento de Ciencias Econmico

Administrativa

Lic. Mnica Siblina Martnez Sols - Jefa del Departamento de Sistemas y

Computacin

Mtro. Delfino Lpez Vzquez Subdirector de Planeacin y Vinculacin

Mtro. Mario Francisco Fonseca Lozada - Jefe del Departamento de Planeacin,

Programacin y Presupuestacin

Lic. Vidalia Gmez Vzquez - Jefa del Departamento de Gestin Tecnolgica y

Vinculacin

Dr. Bertn Gernimo Prez- Jefe del Departamento de Comunicacin y Difusin


22/139

22

Lic. Jaime Rodas Campos- Jefe del Departamento de Actividades Extraescolares

Mtro. Roberto de Jess Aguilar Dillman - Jefe del Departamento de Servicios

Escolares

Ing. Delfino Cajina Pedreguera- Subdirector de Servicios Administrativos

Mtra., Ana Mara Salazar Ortiz- Jefa del Departamento de Recursos Financieros

Lic. Claudia Ins Pineda Ruz- Jefa del Departamento de Recursos Humanos

Lic. Balbina Meja Santos. - Jefa del Departamento de Recursos Materiales y Servicios

Mtro. Jos Concepcin Vera Aguilar.- Jefe del Departamento de Mantenimiento de

Equipo

Mtro. Nicols Cabrera Hidalgo- Jefe del Centro de Cmputo

Lic. Manuel Cerecedo Garca - Jefe del Centro de Informacin

Actualmente, se ofertan ocho carreras profesionales de las cuales se cuenta con una

poblacin estudiantil de: 2 mil 345 alumnos, distribuidos en las diferentes carreras de la

siguiente forma:

Ilustracin 1 Total de alumnos inscritos en la institucin


23/139

23

2.4 EVOLUCIN ACADMICA

En 1983, el I. T. de Tapachula, abre sus puertas a la superacin profesional a travs

de la carrera de Ingeniera Civil, adems contina atendiendo a 148 alumnos en nivel medio

superior con carreras terminales de Tecnlogos en Construccin y de Tecnlogos en

Electrotecnia, de igual manera, absorbe a la poblacin de nivel licenciatura del CeRETI, en

las carreras de Ingeniera Industrial en Transformacin de Productos Agropecuarios e

Ingeniera Civil, y se autoriza a los alumnos de esta ltima homologar sus estudios al plan

tecnolgico.

En junio de 1984 se culmina el primer estudio de investigacin de expectativas de

atencin educativa, para la creacin de nuevas carreras, el cual arroja como resultado que las

carreras de mayor demanda en orden de importancia eran Ingeniera Qumica, Ingeniera

Bioqumica, Ingeniera Industrial e Ingeniera Metalrgica.

Asimismo se presentaron, ante la Direccin General de Institutos Tecnolgicos,

propuestas de las academias para la implantacin de las carreras de Ingeniera Industrial en

Alimentos e Ingeniera Electromecnica. Siendo finalmente autorizada, el 15 de noviembre

de 1984; la carrera de Ingeniera Qumica, inscribindose para el semestre inicial, Septiembre

85Febrero 86, un total de 73 alumnos, el C. Ing. Jorge Carlos Garca Revilla, como director

del plantel, fue el encargado de darles la bienvenida.

El 29 de mayo de 1985, se autoriza la apertura de la carrera de Ingeniera Industrial,lo que hizo posible que para el semestre septiembre 86 - febrero 87 se inscribiera la primera

generacin conformada por 54 alumnos, siendo director del plantel el C. Ing. Jorge Carlos

Garca Revilla.


24/139

24

Uno de los objetivos primordiales del I. T. de Tapachula es brindar a la juventud

estudiosa del Estado de Chiapas, la oportunidad de formacin y superacin profesional a travs

de las diferentes carreras que se imparten, ampliando la oferta educativa; es por ello que en

1991 se crea la carrera de Licenciatura en Informtica, con una poblacin de 70 alumnos, y

es el C. Ing. Vctor Manuel Ibarra Balderas, director del plantel, el encargado de darle la

bienvenida a los alumnos de nuevo ingreso.

Un nuevo estudio sobre la demanda educativa en el Estado, muestra la necesidad de

proporcionar una nueva opcin de formacin profesional, por lo que en respuesta a ello el 28

de enero de 1993, siendo director el C. Ing. Jos Luis Mndez Navarro, se autoriza la carrera

de Ingeniera Electromecnica, inicindose en el mes de agosto del mismo ao con una

poblacin de 29 alumnos.

Las necesidades de la regin, as como un nuevo estudio de expectativas, dieron como

resultado que el 18 de junio de 2002, autorizaran la carrera de: Ingeniera en Sistemas

Computacionales. El C. Mtro. Juan Amado Rueda Ibarra, como mxima autoridad de la

Institucin, les da la bienvenida el 18 de agosto del 2003, a los 45 miembros de la primera

generacin de esta carrera.

A lo largo de 26 aos, el Instituto Tecnolgico de Tapachula ha refrendado su

compromiso con el Estado de Chiapas, de formar profesionistas que contribuyan a su

engrandecimiento, a travs de la solucin de problemas aplicando la ciencia y la tecnologa.

Es por ello que el 23 de agosto de 2009, el Ing. Herman Caldern Pineda, en su calidad de

Director, les dio la bienvenida a 88 alumnos que forman la primera generacin de Ingeniera

en Gestin Empresarial.


25/139

25

En agosto de 2010, corresponde al Mtro. Miguel Cid del Prado Martnez, director de

la Institucin, recibir 41 estudiantes de la primera generacin de la carrera de Ingeniera en

Informtica.

2.5 LOGROS SIGNIFICATIVOS

A lo largo de estos 30 aos, se destacan los siguientes logros:

Contar con un Cuerpo en Formacin Innovacin y Productividad, conformado por

docentes de las carreras de Ingeniera en Sistemas Computacionales, Ingeniera en

Informtica e Ingeniera Industrial.

El mayor logro acadmico, se alcanz en 2012, al obtener la acreditacin de la carrera

de Ingeniera Industrial en el nivel 1 por parte de CIEES.

La conclusin de la transferencia del Modelo de Incubacin de Empresas del Sistema

Nacional de Institutos Tecnolgicos (MiDE-SNIT).

El Consejo Institucional de Vinculacin del Instituto Tecnolgico de Tapachula.

Cuarto Lugar en el Certamen emprendedores 2013, en la categora de Proyecto de

Emprendimiento con el Sistema de Cobros Automatizados, desarrollado por alumnos

del noveno semestre de la carrera de Ingeniera en Sistemas.

Ser la nica Institucin Federal en el Estado de Chiapas, certificada con apego a:

Norma ISO 9001:2008 Sistema de Gestin de Calidad.

Norma ISO 14001:2004 Sistema de Gestin Ambiental.

Norma ISO 50001:2011 Sistema de Gestin de la Energa.

MEG 2003, Sistema de Gestin de Equidad de Gnero.


26/139

26

2.6 IMPACTO EN LA SOCIEDAD

Por su calidad y por su pertinencia para el desarrollo industrial y econmico de la

Regin, la labor educativa del I. T. de Tapachula es altamente estratgica para el desarrollo de

las comunidades, pues contribuye al enriquecimiento del capital humano e intelectual al

formar profesionales competitivos en las diferentes reas de ingeniera.

El I. T. de Tapachula contribuye, tambin de manera importante, con la promocin y

preservacin de la cultura y las artes de la regin a travs de su cultivo y difusin.

La educacin que imparte el I. T. de Tapachula es de suma importancia y pertinencia

para el desarrollo profesional de sus estudiantes y egresados, pues les asegura el dominio de

su rea profesional con una visin humanista que integra en su formacin el respeto de todas

las expresiones artsticas y culturales; de manera que los egresados de la Institucin son

profesionales requeridos por las empresas de la regin por su alto nivel competitivo, lo que

lo convierte en protagonistas exitosos de la nueva sociedad basada en el conocimiento.

A 30 Aos de vida y con una matrcula de 2,720 alumnos, en el nivel licenciatura, el

I. T. de Tapachula es un motor en el desarrollo econmico regional y un factor de primera

importancia para alcanzar la equidad social y regional a la que aspiran los mexicanos, que

incluye necesariamente una ms justa distribucin de los ingresos.

Por su cobertura, tanto en trminos numricos como geogrficos, el I. T. de Tapachula

es un instrumento del Gobierno Federal que se suma al proyecto de asegurar la equidad en el

acceso y en la distribucin territorial de oportunidades educativas. Por ello el I. T. de

Tapachula mantiene la tradicin que lo caracteriza de buscar en todo momento los ms altos

estndares de calidad educativa, y orientado a satisfacer las necesidades del desarrollo social,


27/139

27

cientfico y tecnolgico, cultural y humano de la Regin que hospeda a la Institucin.

2.7 MISIN

Contribuir a la conformacin de una sociedad ms justa, humana y con amplia cultura

cientfico-tecnolgica, mediante un sistema integrado de educacin superior tecnolgica,

equitativo en su cobertura y de alta calidad.

2.8 VISIN

El Sistema Nacional de Institutos Tecnolgicos se consolidar como un sistema de

educacin superior tecnolgica de vanguardia, as como uno de los soportes fundamentales

del desarrollo sostenido, sustentable y equitativo de la nacin y del fortalecimiento de su

diversidad cultural.

2.9 GIRO DE LA INSTITUCIN

Institucin educativa de nivel superior.

2.10 VALORES

El Instituto Tecnolgico de Tapachula, como institucin de educacin superior

considera que para el buen desarrollo armnico y el cumplimiento de su misin, sus

estudiantes y trabajadores deben de practicar los siguientes valores:

PERTENENCIA: Orgullo de formar parte dela institucin, plenamente identificado,

convencido, y comprometido con la misin y la visin del tecnolgico.

RESPONSABILIDAD: Cumplir con las funciones y tareas, individual y

grupalmente, con un sentido de compromiso y un enfoque centrado en la calidad.

INTEGRIDAD: Autenticidad y congruencia entre nuestros valores y

comportamiento.


28/139

28

PROFESIONALISMO: Ser tico, respetuoso, competente y mantenerse actualizado

constantemente.

INNOVACIN: Fomentar la creacin y desarrollo de proyectos que conduzcan al

logro de la visin institucional.

COMPROMISO SOCIAL: Desempearse con espritu de servicio y coadyuvar, a

travs de la educacin tecnolgica del medio ambiente.

2.11 POLTICAS DE CALIDAD

El Instituto Tecnolgico de Tapachula establece el compromiso de implementar todos

sus procesos orientndolos hacia la satisfaccin de sus clientes sustentada en la Calidad del

Proceso Educativo. Para cumplir con sus requerimientos mediante la eficacia de un Sistema

de Gestin de la Calidad y de mejora continua, conforme a la norma ISO 9001:2008/NMX-

CC-9001-IMNC-2008.

2.12 ORGANIGRAMA DEL LABORATORIO DE CMPUTO

En la ilustracin 2se muestra como est organizado el personal del laboratorio de

cmputo del ITT y el cargo correspondiente de cada uno de ellos.

Ilustracin 2 Organigrama del Laboratorio de Cmputo del ITT


29/139

29

2.13 UBICACIN

Este proyecto se llevar a cabo en las instalaciones del laboratorio de cmputo del

Instituto Tecnolgico de Tapachula, el cual se encuentra ubicado en Kilmetro 2, Carretera

a Puerto Madero, C.P. 30700, Tapachula, Chiapas. Telfonos: (52) (962) 62 52880, 62 52900,

62 54873, 62 54389. Fax Ext. 104 y 132. Ver la ubicacin del ITT en la ilustracin 3.

Ilustracin 3 Ubicacin del Instituto Tecnolgico de Tapachula


30/139

30

CAPITULO III

MARCO TERICO


31/139

31

3.MARCO TERICO

3.1 SISTEMAS DE INFORMACIN

3.1.1DEFINICIN DE UN SISTEMA DE INFORMACIN (SI)

Un Sistema de Informacin (abreviado de aqu en adelante como SI) es un conjunto

de elementos interrelacionados entre s que recolectan, almacenan, procesan y distribuyen

informacin para el apoyo en la toma de decisiones, la administracin y el control en una

organizacin.

3.1.2CARACTERIZACIN DE UN SISTEMA DE

INFORMACIN

Los Sistemas de Informacin difieren de cualquier otro software por dos razones

principales:

Almacenan gran cantidad de Informacin

Realizan un bajo grado de procesamiento sobre la informacin, y ste es,

fundamentalmente, de tipo estadstico

Aunque suene redundante, no est dems sealar, que la informacin que entrega un

SI, es utilizada para tomar decisiones organizacionales. As se catalogan como SI, aquellos

sistemas de informacin como:

Contabilidad: Informacin de flujos y estados financieros de la organizacin.

Personal: Toda la informacin referente al Recurso Humano de la institucin.

Registro Curricular (en una Universidad): Informacin respecto de los alumnos y

su situacin acadmica


32/139

32

3.1.3ELEMENTOS QUE CONFORMAN UN SISTEMA DE

INFORMACIN

Un SI est compuesto por 6 elementos claramente identificables, tal y como se

muestran en la ilustracin 4:

Base de Datos. Es donde se almacena toda la informacin que se requiere para la

toma de decisiones. La informacin se organiza en registros especficos e

identificables.

Transacciones. Corresponde a todos los elementos de interfaz que permiten al usuario:

consultar, agregar, modificar o eliminar un registro especfico de Informacin.

Informes. Corresponden a todos los elementos de interfaz mediante los cuales el

usuario puede obtener uno o ms registros y/o informacin de tipo estadstico (contar,

sumar) de acuerdo a criterios de bsqueda y seleccin definidos.

Procesos. Corresponden a todos aquellos elementos que, de acuerdo a una lgica

predefinida, obtienen informacin de la base de datos y generan nuevos registros de

informacin.

Usuario. Identifica a todas las personas que interactan con el sistema, esto incluye

desde el mximo nivel ejecutivo que recibe los informes de estadsticas procesadas,

Ilustracin 4 Elementos de un S.I.


33/139

33

hasta el usuario operativo que se encarga de recolectar e ingresar la informacin al

sistema.

Procedimientos Administrativos. Corresponde al conjunto de reglas y polticas de

la organizacin, que rigen el comportamiento de los usuarios frente al sistema.

Particularmente, debieran asegurar que nunca, bajo ninguna circunstancia un usuario

tenga acceso directo a la Base de Datos.

3.1.4ACTIVIDADES QUE REALIZA UN SISTEMA DE

INFORMACIN

Un sistema de informacin realiza cuatro actividades bsicas: entrada,

almacenamiento, procesamiento, y salida de informacin. A continuacin se definen cada una

de estas actividades.

Entrada de informacin. La entrada es el proceso mediante el cual el sistema de

informacin toma los datos que requiere para procesar la informacin. Las entradas

pueden ser manuales o automticas.

Almacenamiento de informacin. El almacenamiento es una de las actividades o

capacidades ms importantes que tiene una computadora, ya que a travs de esta

propiedad el sistema puede recordar la informacin guardada en la sesin.

Procesamiento de informacin. Es la capacidad del sistema de informacin para

efectuar clculos de acuerdo con una secuencia de operaciones preestablecidas. Estos

clculos pueden efectuarse con datos introducidos recientemente en el sistema o bien

con datos que estn almacenados. Esta caracterstica de los sistemas permite la

transformacin de datos fuente en informacin.

Salida de informacin. La salida es la capacidad de un sistema de informacin para


34/139

34

sacar informacin procesada o bien datos de entrada al exterior.

Ilustracin 5 Actividades que realiza un S.I.

3.2 INGENIERA DE SOFTWARE

3.2.1DEFINICIONES DE LA INGENIERA DE SOFTWARE

Ingeniera de Software es el estudio de los principios y metodologas para desarrollo

y mantenimiento de sistemas de software. (M.V.Zelkovitz, 1979)

Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el

diseo y construccin de programas de computadora y la documentacin asociada requerida

para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin como desarrollo de

software o produccin de software. (B.W.Bohem, 1976)

Ingeniera del Software trata del establecimiento de los principios y mtodos de la

ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en mquinas

reales. (BAUER, 1969)


35/139

35

3.2.2ELEMENTOS DE LA INGENIERA DE SOFTWARE

La Ingeniera de software abarca cuatro elementos clave:

Mtodos o tcnicas Indican cmo construir tcnicamente el software, y abarca unaserie de tareas que incluyen la planificacin y estimacin de proyectos, el anlisis de

requisitos, el diseo de estructuras de datos, programas y procedimientos, la

codificacin, las pruebas y el mantenimiento.

Herramientas: Son instrumentoso sistemas automatizados para realizar algo de la

mejor manera posible. Proporcionan un soporte automtico o semiautomtico para

todas las fases del desarrollo y sistemas que integran las herramientas de cada fase de

manera que sirven para todo el proceso. Estas herramientas se denominan CASE

(Computer Aided Software Engineering).

Procedimientos. Los procedimientos indicarn qu herramientas debern utilizarse

cuando se aplican determinadas tcnicas. Definen la secuencia en que se aplican

los mtodos, los documentos que se requieren, los controles que aseguran la

calidad y las directrices que permiten a los gestores evaluar los progresos.

Paradigmas. Representan un enfoque particular o filosofa para la construccin del

software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas.

Tambin hay situaciones donde un paradigma resulta ms apropiado que otro. Los

ms comunes son el desarrollo en cascada, el desarrollo en espiral, el desarrollo porprototipos, el desarrollo incremental, el desarrollo en V y el desarrollo orientado a

objetos.


36/139

36

3.2.3EL CICLO DE VIDA DEL SOFTWARE.

El trmino ciclo de vida del software describe el desarrollo de software, desde la fase

inicial hasta la fase final. El propsito de este programa es definir las distintas fases intermedias

que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el

software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de

desarrollo: se asegura de que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores

que se detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los

errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse

en la calidad del software, en los plazos de implementacin y en los costos asociados.

El ciclo de vida bsico de un software consta de los siguientes

procedimientos:

Definicin de objetivos: definir el resultado del proyecto y su papel en la

estrategia global.

Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los

requisitos del cliente y examinar cualquier restriccin que se pueda aplicar.

Diseo general: requisitos generales de la arquitectura de la aplicacin.

Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.

Programacin (programacin e implementacin): es la implementacin de un

lenguaje de programacin para crear las funciones definidas durante la etapa de

diseo.

Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para


37/139

37

garantizar que se implementaron de acuerdo con las especificaciones.

Integracin: para garantizar que los diferentes mdulos se integren con la

aplicacin. ste es el propsito de la prueba de integracin que est

cuidadosamente documentada.

Prueba beta (o validacin), para garantizar que el software cumple con las

especificaciones originales.

Documentacin: sirve para documentar informacin necesaria para los usuarios

del software y para desarrollos futuros.

Implementacin: La implementacin se establece como la construccin del

sistema. La actividad slo lleva a la prctica el sistema que se model en la fase

de diseo. La fase incluye las actividades de codificacin e integracin de los

diferentes mdulos constitutivos del sistema.

Mantenimiento: para todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento

continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

aplicacin dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo

de desarrolladores.

3.3 METODOLOGA RUP

Es una metodologa cuyo fin es entregar un producto de software. Se estructura todos

los procesos y se mide la eficiencia de la organizacin. Es un proceso de desarrollo de

software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodologa

estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas


38/139

38

orientados a objetos.

El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada

organizacin. Describe cmo aplicar enfoques para el desarrollo del software, llevando a

cabo unos pasos para su realizacin. Se centra en la produccin y mantenimiento de modelos

del sistema.

3.3.1CARACTERSTICAS

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,

cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e

incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos

(que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el

cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento,

una persona puede desempear distintos roles a lo largo del proceso).


39/139

39

3.3.2CICLO DE VIDA

Ilustracin 6 Esfuerzo en actividades segn fase del proyecto

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado

ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas

en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan

varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor

hincapi en las distintas actividades.

Fases del ciclo de vida del RUP:

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto

con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin

muy general de la arquitectura de software y producir el plan de las fases y el de

iteraciones posteriores.

Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que

permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza

la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del

problema, se disea la solucin preliminar.


40/139

40

Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,

para ello se deben clarificar los requerimientos pendientes, administrar los cambios de

acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el

proyecto.

Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para

los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de

aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe

verificar que el producto cumpla con las especificaciones entregadas por las personas

involucradas en el proyecto.

La metodologa RUP tiene 6 principios clave:

Adaptacin del proceso. El proceso debe adaptarse a las caractersticas de la organizacin

para la que se est desarrollando el software.

Balancear prioridades. Debe encontrarse un balance que satisfaga a todos los inversores

del proyecto.

Colaboracin entre equipos. Debe haber una comunicacin fluida para coordinar

requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.

Demostrar valor iterativamente. Los proyectos se entregan, aunque sea de una forma

interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del

producto y analizar la opinin y sugerencias de los inversores.

Elevar el nivel de abstraccin: Motivar el uso de conceptos reutilizables.

Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la

produccin.


41/139

41

3.3.3DISCIPLINA DE DESARROLLO DE RUP

Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para

el cual se est desarrollando el software.

Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.

Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema

automatizado y desarrollar una arquitectura para el sistema.

Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el

comportamiento deseado.

Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo

solicitado est presente.

Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

3.3.4ELEMENTOS DEL RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.

Trabajadores: Personas involucradas en cada actividad del proyecto.

Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un

documento, un modelo, un elemento del modelo.

3.3.5ARTEFACTOS

RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie

de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema

(entre otros). Estos artefactos (entre otros) son los siguientes:


42/139

42

Inicio:

o Documento Visin

o Especificacin de Requerimientos

Elaboracin:

o Diagramas de caso de uso

Construccin:

o Documento Arquitectura que trabaja con las siguientes vistas:

Vista lgica:

o Diagrama de clases

o Modelo E-R (Si el sistema as lo requiere)

Vista de implementacin:

o Diagrama de Secuencia

o Diagrama de estados

o Diagrama de Colaboracin

Vista conceptual

o Modelo de dominio

Vista fsica

o Mapa de comportamiento a nivel de hardware

3.4UML (LENGUAJE UNIFICADO DE MODELADO)

3.4.1DEFINICIN DE UML

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual de

propsito general que se utiliza para especificar, visualizar, construir y documentar los


43/139

43

artefactos de un sistema software. Captura decisiones y conocimiento sobre sistemas que deben

ser construidos. Se usa para comprender, disear, ojear, configurar, mantener y controlar la

informacin sobre tales sistemas. (James Rumbaugh, 2000) (Ivn Lpez Montalbn, 2014)

3.4.2DIAGRAMA DE CLASES

Una clase representa un concepto discreto dentro de la aplicacin que se est

modelando, que representa un elemento de un tipo particularun elemento cosa fsica (como

un avin), un elemento de negocio (como una solicitud), un elemento lgico (como la

programacin de la retransmisin de un evento), un elemento de una aplicacin (como el botn

de cancelar), un elemento de computacin (como una tabla indexada) o un elemento de

comportamiento (como una tarea). Una clase es el descriptor para un conjunto de objetos con

similar estructura, comportamiento y relaciones. Todos los atributos y operaciones se vinculan

a clases u otros clasificadores. Las clases son el punto alrededor del cual se organizan los

sistemas orientados a objetos.

Ilustracin 7 Ejemplo de Diagrama de Clases


44/139

44

3.4.3DIAGRAMA DE CASOS DE USO

Un caso de uso describe una interaccin con actores como una secuencia de mensajes

entre el sistema y uno o ms actores. El trmino actor incluye tanto a personas, como a otros

sistemas informticos y procesos. La ilustracin 8 muestra un diagrama de casos de uso para

una aplicacin de telefnica de venta por catlogo. El modelo se ha simplificado como ejemplo.

Ilustracin 8 Ejemplo de un Caso de Uso

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos

de uso y relaciones entre casos de uso.

Actor. Un actor es una idealizacin de un rol desempeado por una persona externa, un

proceso o cosa que interacte con el sistema, subsistema o clase. Un actor caracteriza la

interaccin que una clase de usuarios externos puede tener con el sistema. Un actor

puede ser humano, un sistema informtico o algn proceso ejecutable. Un actor se dibuja

como una persona pequea con trazos lineales y el nombre situado debajo de l.


45/139

45

Caso de uso. Un caso de uso es una descripcin de la secuencia de interacciones que

se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo

una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en

el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su

interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea

llevar a cabo usando el sistema.

3.4.4DIAGRAMA DE SECUENCIA

Un diagrama de secuencia muestra un conjunto de mensajes ordenados en una

secuencia temporal. Un uso de un diagrama de secuencia es mostrar la secuencia de

comportamiento de un caso de uso. Cuando el comportamiento se implementa, cada mensaje

del diagrama de secuencia responde a una operacin de una clase o a un evento disparado en

una transicin de una mquina de estados.

Elementos de un diagrama de secuencia

Rol de la Clase: El rol de la clase describe la manera en que un objeto se va a comportar

en el contexto.

Activacin: Los cuadros de activacin representan el tiempo que un objeto necesita para

completar una tarea.

Mensajes: Los mensajes son flechas que representan comunicaciones entre objetos.

Lneas de Vida: Las lneas de vida son verticales y en lnea de puntos, ellas indican la

presencia del objeto durante el tiempo.

Destruccin de Objetos: Los objetospueden ser eliminados tempranamente usando

una flecha etiquetada "" que apunta a una X.

Loops: Una repeticin o loop en un diagrama de secuencias, es representado como un


46/139

46

rectngulo. La condicin para abandonar el loop se coloca en la parte inferior entre

corchetes [ ].

3.4.5 DIAGRAMA DE COLABORACIN

El diagrama de colaboraciones describe las interacciones entre los objetos en trminos

de mensajes secuenciados. Los diagramas de colaboracin representan una combinacin de

informacin tomada de los diagramas de clases, de secuencias y de casos de uso, describiendo

el comportamiento, tanto de la estructura esttica, como de la estructura dinmica de un

sistema.

Ilustracin 9 Ejemplo de un Diagrama de Secuencia


47/139

47

Ilustracin 10 Ejemplo de un Diagrama de Colaboracin

3.5BASE DE DATOS

Una Base de Datos es una coleccin de informacin perteneciente a un mismo contexto

(o problema), que est almacenada de forma organizada en ficheros. (Ivn Lpez Montalbn,

2014).

Una base de datos est organizada mediante tablas que almacenan informacinconcerniente a algn objeto o suceso. Estas tablas se relacionan formando vnculos o relaciones

entre ellas, que ayudan a mantener la informacin de los diversos objetos de forma ordenada y

coherente (sin contradicciones).

3.5.1CICLO DE VIDA DE UNA BASE DE DATOS

Como todo, las bases de datos tienen una vida finita. Nacen en un arrebato de optirnismo,

y su vida discurre cosechando fama, fortuna y notoriedad o un anonimato tranquilo segn los

casos, antes de extinguirse. Incluso las bases de datos ms aclamadas acaban siendo sustituidas

con el tiempo por otras estructuras ms flexibles y actualizadas, y la vida comienza de nuevo.

Aunque su definicin exacta puede variar, por regla general el ciclo de vida de una base de datos


48/139

48

consta de seis fases.

Anlisis. En la fase de anlisis se entrevista a los accionistas y se examinan todos los

sistemas existentes para identificar los problemas, las posibilidades y los limites. En esta

fase se determinan los objetivos y el mbito del nuevo sistema.

Diseo. En la fase de diseo se crea el diseo conceptual a partir de las necesidades

determinadas previamente. Tambin se crea un diseo lgico y fsico para preparar la

implementacin de la base de datos.

Implementacin. En la fase de implementacin se instala el sistema de administracin

de la base de datos (DBMS), se crea la base de datos y se cargan o importan los datos.

Pruebas. En la fase de pruebas se examina la base de datos y se ajusta, por lo general

junto a las aplicaciones asociadas.

Puesta en marcha. En esta fase la base de datos opera normalmente, produciendo

informacin para sus usuarios.

Mantenimiento. En la fase de mantenimiento se introducen cambios en la base de

datos en respuesta a las nuevas necesidades o se modifican las condiciones operativas

(como una carga ms pesada).

El desarrollo de la base de datos no es independiente al desarrollo de los sistemas. De

hecho, se suele considerar como uno de los componentes del proceso ms amplio de desarrollo de

sistemas. Las fases del desarrollo de sistemas coinciden bsicamente con las fases del ciclo de

vida de una base de datos, con la diferencia de su alcance. Mientras el diseo de las bases de

datos se centra en el diseo del sistema para almacenar los datos, el diseo de sistemas se ocupa

adems de los procesos que incidirn en los datos. (Holzner, 2005).


49/139


50/139

50

define un nmero fijo de campos, cada uno de los cuales suele tener una longitud tambin fija.

Existen tres tipos principales de modelos lgicos de datos basados en registros:

El modelo de datos relacional,

El modelo de datos en red y

El modelo de datos jerrquico.

3.5.5MODELO DE DATOS FSICOS

Los modelos de datos fsicos describen cmo se almacenan los datos en la computadora,

representando informacin tal como las estructuras de registro, el ordenamiento de los registros

y las rutas de acceso. No hay tanto modelos fsicos de datos como modelos lgicos, y los

modelos fsicos ms comunes son:

El modelo unificador.

La memoria de marco.

3.5.7MODELO ENTIDAD-RELACIN

El modelo de datos entidad-relacin (E-R) est basado en una percepcin del mundo

real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre

estos objetos. Una entidad es una cosa u objeto en el mundo real que es distinguible de

otros objetos.

Las entidades se describen en una base de datos mediante un conjunto deatributos.

Una relacin es una asociacin entre varias entidades. El conjunto detodas las entidades del

mismo tipo, y el conjunto de todas las relaciones del mismotipo, se denomina respectivamente

conjunto de entidades y conjunto de relaciones.


51/139

51

La estructura lgica general de una base de datos se puede expresargrficamente

mediante un diagrama ER, que consta de los siguientes componentes:

Rectngulos, que representan conjuntos de entidades.

Elipses, que representan atributos.

Rombos, que representan relaciones entre conjuntos de entidades.

Lneas, que unen los atributos con los conjuntos de entidades y los conjuntos de

entidades con las relaciones.

Cada componente se etiqueta con la entidad o relacin que representa . Adems de

entidades y relaciones, el modelo E-R representa ciertas restricciones que los contenidos de

la base de datos deben cumplir. Una restriccin importante es la correspondencia de

cardinalidades, que expresa el nmero de entidades con las que otra entidad se puede asociar

a travs de un conjunto de relaciones. El modelo entidad-relacin se utiliza habitualmente en

el proceso de diseo de bases de datos.

El desarrollo de la base de datos no es independiente al desarrollo de los sistemas. De

hecho, se suele considerar como uno de los componentes del proceso ms amplio de desarrollo

de sistemas. Las fases del desarrollo de sistemas coinciden bsicamente con las fases del

ciclo de vida de una base de datos, con la diferencia de su alcance. Mientras el diseo de las

bases de datos se centra en el diseo del sistema para almacenar los datos, el diseo de

sistemas se ocupa adems de los procesos que incidirn en los datos.


52/139

52

3.5.8CARDINALIDAD

La Cardinalidad de una relacin se calcula a travs de las participaciones de sus

ocurrencias en ella. Se toman el nmero mximo de participaciones de cada una de las

entidades en la relacin.

De esta manera, se clasifican las siguientes cardinalidades:

Cardinalidad 1:1 (Uno a Uno): Esta Cardinalidad especfica que una entidad A

puede estar vinculada mediante una relacin a una y solo una ocurrencia de otra

entidad B. A su vez una ocurrencia de la entidad B solo puede estar vinculada a una

ocurrencia de la entidad A.

Cardinalidad 1: N (o 1: Muchos):Esta relacin especifica que una entidad A puede

estar vinculada mediante una relacin a varias ocurrencias de otra entidad B. Sin

embargo, una de las ocurrencias de la entidad B solo puede estar vinculada a una

ocurrencia de la entidad A.

Ilustracin 11 Ejemplo de Modelo Entidad- Relacin


53/139

53

Cardinalidad M: N (o Muchos: Muchos) O tambin N: M: Esta Cardinalidad

especfica que una entidad A puede estar vinculada mediante una relacin a varias

ocurrencias de la entidad B, y a su vez, una ocurrencia de la entidad B puede estar

vinculada a varias de la entidad A. (Ivn Lpez Montalbn, 2014)

3.5.9MODELO RELACIONAL

En el modelo relacional se utiliza un grupo de tablas para representar los datos y las

relaciones entre ellos. Cada tabla est compuesta por varias columnas, y cada columna tiene

un nombre nico. En la ilustracin 12, se presenta un ejemplo de base de datos relacional

consistente en tres tablas: la primera muestra los clientes de un banco, la segunda, las cuentas,

y la tercera, las cuentas que pertenecen a cada cliente.

El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos

basados en registros se denominan as porque la base de datos se estructura en registros de

formato fijo de varios tipos. Cada tabla contiene registros de un tipo particular. Cada tipo de

Ilustracin 12 Ejemplo de una base de datos relacional


54/139


55/139

55

de la misma, y si no cumple determinados criterios de calidad, hay que realizar, de forma

iterativa, sucesivos refinamientos en el diseo, para alcanzar la calidad deseada.

Uno de los parmetros que mide la calidad de una base de datos es la forma normal en

la que se encuentra su diseo. Esta forma normal puede alcanzarse cumpliendo ciertas

restricciones que impone cada forma normal al conjunto de atributos de un diseo. El proceso

de obligar a los atributos de un diseo a cumplir ciertas formas normales se llama

normalizacin.

Las formas normales pretenden alcanzar dos objetivos:

Almacenar en la base de datos cada hecho solo una vez, es decir, evitar la redundancia

de datos. De esta manera se reduce el espacio de almacenamiento.

Que los hechos distintos se almacenen en sitios distintos. Esto evita ciertas anomalas

a la hora de operar con los datos.

3.6 SISTEMAS GESTORES DE BASE DE DATOS (SGBD)

Se define un Sistema Gestor de Base de Datos, en adelante SGBD, como el conjunto

de herramientas que facilitan la consulta, uso y actualizacin de una base de datos.

3.5.7FUNCIONES DE LOS SGBD

Los SGBD cumplen con casi todas funciones que a continuacin se enumeran:

Permiten a los usuarios almacenar datos, acceder a ellos y actualizarlos de forma

sencilla y con un gran rendimiento, ocultando la complejidad y las caractersticas

fsicas de los dispositivos de almacenamiento.

Garantizan la integridad de los datos, respetando las reglas y restricciones que dicte

el programador de la base de datos. Es decir, no permiten operaciones que dejen cierto


56/139

56

conjunto de datos incompletos o incorrectos.

Integran, junto con el sistema operativo, un sistema de seguridad que garantiza el

acceso a la informacin exclusivamente a aquellos usuarios que dispongan de

autorizacin.

Proporcionan un diccionario de metadatos, que contiene el esquema de la base de

datos, es decir, cmo estn estructurados los datos en tablas, registros y campos, las

relaciones entre los datos, usuarios, permisos, etc.

Permiten el uso de transacciones, garantizan que todas las operaciones de la

transaccin se realicen correctamente, y en caso de alguna incidencia, deshacen los

cambios sin ningn tipo de complicacin adicional.

Ofrecen, mediante completas herramientas, estadsticas sobre el uso del gestor,

registrando operaciones efectuadas, consultas solicitas, operaciones fallidas y

cualquier tipo de incidencia. Es posible de este modo, monitorizar el uso de la base

de datos, y permiten analizar hipotticos malfuncionamientos.

Permiten la concurrencia, es decir, varios usuarios trabajando sobre un mismo

conjunto de datos. Adems, proporcionan mecanismos que permiten arbitrar

operaciones conflictivas en el acceso o modificacin de un dato al mismo tiempo por

parte de varios usuarios.

Independizan los datos de la aplicacin o usuario que est utilizndolos, haciendo ms

fcil su migracin a otras plataformas.

Ofrecen conectividad con el exterior. De esta manera, se puede replicar y distribuir

bases de datos. Adems, todos los SGBD incorporan herramientas estndar de

conectividad.

Incorporan herramientas para la salvaguarda y restauracin de la informacin en caso


57/139

57

de desastre. Adems, deben ofrecer sencillas herramientas para la importacin y

exportacin automtica de la informacin

3.6.2ABSTRACCIN DE DATOS

Para que el sistema sea til debe recuperar los datos eficientemente. Como muchos

usuarios de sistemas de bases de datos no estn familiarizados con computadores, los

desarrolladores esconden la complejidad a los usuarios a travs de varios niveles de

abstraccin para simplificar la interaccin de los usuarios con el sistema.

De tal manera que se dividen en tres niveles de abstraccin los cuales son los siguientes:

Nivel fsico: El nivel ms bajo de abstraccin describe cmo se almacenan realmente

los datos. En este nivel se describen a detalle las estructuras de datos complejas de

bajo nivel.

Nivel lgico: El siguiente nivel ms alto de abstraccin describe qu datos se

almacenan en la base de datos y qu relaciones existen entre esos datos.

Los administradores de bases de datos, son los que deben decidir cul es la

informacin que se mantiene en la base de datos.

Nivel de vistas: El nivel ms alto de abstraccin describe slo parte de la base de

datos completa. Debido a la variedad de informacin almacenada en una base de datos

muchos usuarios no necesitan toda esta informacin. En su lugar, tales usuarios

necesitan acceder slo a una parte de la base de datos. Para que su interaccin con elsistema se simplifique, se define la abstraccin del nivel de vistas. El sistema puede

proporcionar muchas vistas para la misma base de datos. (Abraham Silberschatz,

2002)


58/139


59/139

59

Un lenguaje de manipulacin de datos (LMD) es un lenguaje que permite a los

usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado.

Hay dos tipos bsicamente:

LMD procedimental. Requieren que el usuario especifique qu datos se

necesitan y cmo obtener esos datos.

LMD declarativo (tambin conocidos como LMD no procedimentales).

Requieren que el usuario especifique qu datos se necesitan sin especificar cmo

obtener esos datos.

3.7.3LENGUAJE SQL

SQL (Structured Query Language - Lenguaje Estructurado de Consultas) es el

lenguaje estndar para trabajar con bases de datos relacionales y es soportado prcticamente

por todos los productos en el mercado. Originalmente, SQL fue desarrollado en IBM

Research a principios de los aos setenta; fue implementado por primera vez a gran escala

en un prototipo de IBM, y posteriormente en numerosos productos comerciales de IBM y de

muchos otros fabricantes. El nombre oficial es Estndar Internacional del Lenguaje de Base

de Datos SQL (1992). (Date, 2001)

SQL se convirti, en trminos computacionales, en un lenguaje completo (ahora

incluye instrucciones como CALL, RETURN, SET, CASE. IF, LOOP, LEAVE, WHILE y

REPEAT, as como diversas caractersticas relacionadas como las variables y losmanejadores de excepciones). SQL es un lenguaje enorme.

Por ltimo, se debe mencionar que SQL est muy lejos de ser el lenguaje relacional

perfecto; padece de faltas tanto de omisin como de comisin. Sin embargo, este estndar,


60/139

60

es soportado por casi todos l

Documents

Documentacion de Residencia, tesis,