Está en la página 1de 274

An.

UNIVERSIDAD DE ORIENTE NUCLEO DE ANZOATEGUI ESCUELA DE INGENIERIA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACION Y SISTEMAS

DESARROLLO DE UN SISTEMA DE INFORMACIN BASADO EN ENTORNO WEB PARA EL CONTROL DE INVENTARIOS Y COSTOS DE UNA COMPAA COMERCIALIZADORA DE REPUESTOS AUTOMOTRICES UBICADA EN BARCELONA, ESTADO ANZOTEGUI.

REALIZADO POR:

_______________________ Noriega G., Rosio Carolina

_______________________ Alemn DL., Peter Andrews

Trabajo de Grado Presentado como Requisito Parcial para Optar al Ttulo de INGENIERO DE SISTEMAS

Barcelona, Julio de 2.010

UNIVERSIDAD DE ORIENTE NUCLEO DE ANZOATEGUI ESCUELA DE INGENIERIA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACION Y SISTEMAS

DESARROLLO DE UN SISTEMA DE INFORMACIN BASADO EN ENTORNO WEB PARA EL CONTROL DE INVENTARIOS Y COSTOS DE UNA COMPAA COMERCIALIZADORA DE REPUESTOS AUTOMOTRICES UBICADA EN BARCELONA, ESTADO ANZOTEGUI.

TUTORES: ____________________________ Ing. Claudio Cortinez Tutor Acadmico

Barcelona, Julio de 2.010

UNIVERSIDAD DE ORIENTE NUCLEO DE ANZOATEGUI ESCUELA DE INGENIERIA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACION Y SISTEMAS

DESARROLLO DE UN SISTEMA DE INFORMACIN BASADO EN ENTORNO WEB PARA EL CONTROL DE INVENTARIOS Y COSTOS DE UNA COMPAA COMERCIALIZADORA DE REPUESTOS AUTOMOTRICES UBICADA EN BARCELONA, ESTADO ANZOTEGUI.

JURADO CALIFICADOR:

_______________________________ Prof. Claudio Cortnez Asesor Acadmico

_____________________________ Prof. Victor Mujica Jurado Principal

_____________________________ Prof. Mercedes Ortiz Jurado Principal

Barcelona, Julio de 2.010

RESOLUCIN

Artculo 41 Reglamento de Trabajos de Grado: Los Trabajos de Grado son de la exclusiva propiedad de la Universidad de Oriente, y solo podrn ser utilizados a otros fines con el consentimiento del Consejo de Ncleo respectivo, quien deber participarlo previamente al Consejo Universitario, para su autorizacin.

IV

AGRADECIMIENTOS
Primeramente agradezco a mi Dios todopoderoso por permitirme estar aqu en este momento escribiendo estas letras en un punto importante de mi vida tanto profesional como personal, por darme la luz, la fuerza y por estar siempre delante de m y guindome por el camino correcto para lograr el xito de esta meta que estoy cumpliendo. A mi arcngel Miguel por estar siempre a mi lado, por ayudarme en los momentos oscuros y poniendo todo lo bueno a mi lado para lograr mis propsitos. Al Universo por traer a mi todas y cada una de las bendiciones que me mantienen de pie en la vida.

A mis padres Pedro y Nellys, por darme la vida, la educacin, los valores, los consejos y ensearme exactamente el camino que deba recorrer para cumplir mis sueos y dar recompensa a mis esfuerzos. A mis hermanos pilares fundamentales de mi modelo a seguir como persona y como profesional, gracias manos por sus enseanzas y por estar pendiente de m en todo momento. A toda mi familia los amo inmensamente.

A todos mis amigos, compaeros, conocidos que influyeron en m durante toda esta etapa con una palabra de aliento, con su apoyo o simplemente su amistad, a esas personas que recordare siempre: Gabriela, Marcel, Randy, Will, Shuvy, Geraldine Celta, allokita, Adriana y aquellos que se me pase saben que agradezco su amistad y su apoyo incondicional. A Carmen Paruta por no solo su apoyo sino la bendicin de haberme brindado una amistad sincera que pude encontrar a lo largo de toda mi carrera tqm. A Anyenis Pea especialmente por su Comprensin, cario y todo su apoyo.

A mi compaera de tesis Rosio Noriega por compartir este logro mutuo y haber superado esta etapa juntos con xito. Muuuacks linda.

A la Sra. Belkis por sus consejos, su ayuda en esos das tristes de todo este camino, gracias seora Belkis de corazn. Esto es algo que no se olvida jams.

Al profesor Claudio Cortinez por su colaboracin, su asesora y haberme ayudado a aprender siempre en la realizacin de este proyecto.

A los profesores Vctor Mujica y Mercedes Ortiz por su comprensin por su apoyo y brindarme la oportunidad de presentar este proyecto en tan poco tiempo gracias a ustedes mis padres me vieron exponer y graduarme. Gracias.

A mi Universidad de Oriente por haberme formado como profesional, como persona y haber conocido a los excelentes profesores que forjaron esta maravillosa carrera en m.

VI

AGRADECIMIENTOS
A mis padres Rosa Virginia Gutirrez y Jaime Ramn Noriega .No tengo palabras como agradecerles todo lo que han hecho por mi, por su apoyo incondicional , por estar all en los buenos y malos momentos de todo el periodo de mi tesis, por sus sabios consejos y por llenarme de paciencia . Gracias

A mis tos

Zoila Noriega, Nilza Noriega, Orlando Jaramillo y Fernando

Deusa .A mis tas por ser mis segundas madres, ya que han estado en los peores y mejores momentos de mi vida. A mi to por ser parte de mi vida y por estar en las buenas y en las malas, tendindome la mano para seguir adelante y no caer. Y por ltimo a mi to Fernando porque a travs de su sabidura y experiencia siempre ha tenido y tendr una palabra de aliento.

A mis tos Arelis Gutirrez, Milagro Gutirrez, Dusley Gutirrez, ngel Osuna, Ali Gutirrez. Ha ellos por aportar un granito de arena en mi sendero por medio de su carisma, alegra, fuerza, conocimiento, experiencia, sabidura, voluntad, optimismo. Gracias por estar conmigo.

A mis primos Jaramillo Noriega .Gracias por ser mas que mis primos, mis hermanos y por con partir cada una de mis experiencias y mis logros. Y a Doanny Noriega por todo el cario que me ha brindado.

A mis primos Deusa Noriega, incluyendo a mi prima Daniela (Novia de nando) por brindarme su amor, cario y abrirme las puertas de su casa como si fuera la ma en un momento dado. Ha y a mi cucu, prima eres ms que eso, eres mi amiga, gracias por serlo.

VII

A mis primos Osuna Gutirrez y Olivo Gutirrez Por ser parte de mi y tenerme siempre presenteEn especial mi primo Jos ngel, te quiero.

A mis locas amigas Gilliam Kingland(A su familia), Carmen Paruta, Nohely Boada, Adrianny Noriega y ni mas faltaba mi asesora personal de tesis Vanesa cuzzi. Gracias por ayudarme, por darme fuerzas para seguir, por sus concejos, por seguir mis locuras y por estar cerca de m. No lo olviden estoy orgullosa de cada una de ustedes, por ser quienes son y me siento honrada de contar con su amistad.

A mis amigos y compaeros de la universidad, Yade, Jaimeliz Milln (mi flanqus), Patricia fonsilla, Andrickson, Mara Charles, Sonia Yun, Miguel Rabelo, John Lanz, Mitchell Palomino, Armando Zabala, Luisanni, Edgar Crdova, Jos Luis Gmez, Rosimar Gmez, Rafael Solrzano, JR, Jorge (Vago), Reinaldo, Gabriela Sosa(mi loca), Gustavito, Anita .etc. Todos ellos formaron parte de mi vida universitaria y sin saberlo fueron una pieza

fundamental en cada una de las experiencias vividas en la UDO.

Definitivamente a mis hermanitos Jos Miguel Abad y Jackeline Gil. Ha uno por ponerme mano dura en mis estudios y exigirme mas de mi, tenerme paciencia y quererme como lo hace. Y ha la otra por que a pesar de no ser hermanas de sangre ella se ha sacrificado muchas veces por mi y yo por ella, porque es una hija mas para mis padres y para rosanny y para mi una hermana mas. Te quiero mucho mans

A mi mejor amigo Carlos Alcala (mi mol) por ser mi confidente, mi amigo, y mi apoyo. Gracias a ti estoy aqu escribiendo estas palabras para ti. VIII

A Cruz Martnez por darme una mano amiga cuando mas lo necesite y por ensearme que, ante todo, debemos tener calidad humana. Gracias feo. A Carlos Eduardo Prez porque en un momento dado me ofreci su cario incondicional, todo su apoyo y fuerzas para seguir adelante en mis estudios y en mi vida.

Claudio Cortinez tutor, por toda la paciencia que nos tuvo a mi compaero de tesis y a mi, por ayudarnos, por asesorarnos y guiarnos en la realizacin de la tesis.

Mercedes Ortiz colaboracin prestada.

y Vctor Mujica jurado de la tesis por toda su

A tres mujeres increbles, el cual, me siento honrada de conocerlas de ser partes de su vida laboral y personal: Ada Charles, Natalia Mendoza y Melina. Personas luchadoras, optimistas, capaces, que forjan su propio futuro, la cual son un patrn para m a seguir.

Y por ultimo pero no menos significativo a los profesores Carrasquero y Geraldino, de verdad muchsimas gracias por su colaboracin y tiempo que le dedicaron a corregir cada parte de la tesis. Gracias nuevamente.

IX

DEDICATORIA
A mi Dios todopoderoso, a mi arcngel Miguel y al Universo por escuchar mis oraciones, guiar e iluminar mis pasos en todo momento, por darme luz en los momentos de oscuridad y desesperanza. Mi Dios esta promesa que te hice la cumplir cada da de mi vida, esto es para ti.

A mis padres Pedro y Nellys, esto es para ustedes mis viejos los amo inmensamente. Como dira mi papa adelante siempre adelante, aqu estoy siguiendo sus consejos, todo lo que aprend, lo que me convert y lo que ser de aqu en adelante es para ustedes por siempre.

A mis hermanos como el logro que faltaba en la familia a ustedes para seguir adelante y que las alegras nunca acaben. A toda mi familia como la fuente de mis energas, de mi amor y mis esperanzas.

A los panas de O-kan, este esfuerzo se lo calaron ustedes completico y a ustedes va mi logro, los quiero mis hermanos del alma.

A mis amigos de la UDO, en los que encontr amistad, apoyo y energa, aquellos que llegaron a m y a los que llegu a ellos. A todos aquellos que formaron parte en un punto de mi carrera nunca los olvido y nuca los olvidare los quiero.

DEDICATORIA

Hoy por hoy sin duda alguna, a ti mi Dios que me has ayudado a abrir caminos, a cerrar heridas, y a enfrentar todas las adversidades que se me han presentado en la vida. Se que seguirs aqu a mi lado, luchando da a da para lograr cada una de mis metas.

A mis padres por ser ellos un ejemplo a seguir y un orgullo para mi. Por su constancia, ayuda, dedicacin, forjaron el ser que soy, por esta razn y muchas ms les dedico uno de mis tantos logros. Los Adoro.

Mis Abuelos que en paz descansen Atilio Noriega y Manuela Rojas de Noriega (Malulita). No tengo palabras como describir todo el amor, cario y aprecio que fundaron en m, eran, son y sern una parte fundamental en mi vidaLos amo!!!

Mis Abuelitos Marcos Gutirrez y Sara Rodrguez de Gutirrez. A ustedes les debo todo ese cario que les han brindado no solo a m sino a la familia completa. Ustedes me han enseado que la sencillez de la vida, la calidad humana, el cario de pareja, el amor y la unin de una familia siempre prevalecern a travs de los tiempos y eso me ha ayudado a ser una mejor persona.

Ta Yasenia, a ti te dedico y dedicare siempre cada uno de mis logros porque aparte de mis padres fuiste un modelo a seguir, de ti aprend que hay que luchar por lo que se quiere a travs de la perseverancia, dedicacin,

tenacidad se puede lograr lo que se proponga, porque ningn obstculo se

XI

compara con el que tu quisiste atravesar lastimosamente no pudiste y como me escribiste hace mucho tiempo atrs. Dice Estoy contigo sabes, porque cuando se ama no importa si se esta o no presente fsicamente para compartir con quien amas y lo que amas. Y lo se tita. A mi to marco por regalarle una sonrisa y la alegra a cada una de su familia.

A Ren Laya por llegar en el momento preciso a la vida de mi hermana, por brindarnos no solo a m sino a mi familia toda su ayuda y apoyo. Gracias por dejarme trabajar en tu empresa y dejar que desarrollara mi tema de tesis en ella. A mi compaero de tesis Peter Alemn por toda la paciencia y lo digo literalmente. Ya que a pesar de no habernos conocido anteriormente, sino al momento de unirnos como compaeros de tesis, me ayudado, me ha apoyado tanto en la tesis como en lo personal y de ahora en adelante siempre tendr un espacio en mi corazn y en mi vida. Gracias lindo!!

Y por ultimo y no menos importante a mi hermana (Mi Gorda) mi otro pedacito de vida de quien he aprendido lo vivaz, y su agilidad para

comprender las cosas, el cual, me eh esforzado por ser un modelo y un orgullo para ella. Te quiero.

XII

RESUMEN
El siguiente proyecto desarroll un sistema de informacin basado en un entorno web que permiti el manejo de inventarios y costos de los equipos y repuestos de la compaa Diesel Oriente C.A., la cual vena ejecutando todas y cada una de sus actividades de manera completamente manual y donde, el Sistema de Informacin para el Manejo de Inventarios y Costos (SIMIC), aporta una solucin efectiva a los inconvenientes y perdidas que ocasionaban estos antiguos procedimientos. Todo ello con el objetivo de simplificar las labores, brindar seguridad, comodidad, automatizacin y confidencialidad requeridas para controlar la informacin que procesa la empresa deviniendo en la consecuente optimizacin de los recursos que la organizacin estaba derrochando en sus labores cotidianas. Para el desarrollo y construccin del sistema se utilizaron herramientas de la

ingeniera de software como el Lenguaje de Modelado Unificado (UML) y se tom como base fundamental la implantacin del Proceso Unificado del Desarrollo de Software, que se refiere a un marco de desarrollo iterativo e incremental compuesto de cuatro fases, est dirigido por casos de uso y es centrado en la arquitectura. Se utiliz el lenguaje de programacin PHP, bases de datos relacionales con MySQL para la implementacin de los componentes del sistema desarrollados de tal modo que pudieran permitir futuras modificaciones, ampliaciones y mejoras en su funcionamiento. El desarrollo de este software se orienta a la creacin de un sistema para el control prctico de las actividades principales de inventarios y costos, marcando un modelo dentro de la compaa y siendo la primera aplicacin propuesta llevada a cabo en esta organizacin.

XIII

INDICE GENERAL
RESOLUCIN ............................................................................................... IV AGRADECIMIENTOS ..................................................................................... V AGRADECIMIENTOS ................................................................................... VII INDICE GENERAL...................................................................................... XIV CAPITULO I - PLANTEAMIENTO DEL PROBLEMA .................................... 24 1.1. PROBLEMA DE LA INVESTIGACIN............................................. 24 1.2. OBJETIVOS..................................................................................... 27 1.1.1. 1.1.2. Objetivo General ...................................................................... 27 Objetivos Especficos............................................................... 27

CAPITULO II - MARCO TEORICO ............................................................... 28 2.1. ANTECEDENTES DE LA INVESTIGACION ................................... 28 2.2. BASES TEORICAS ......................................................................... 30 2.2.1. Definicin de Sistemas ........................................................... 30

2.2.1.1. Caractersticas....................................................................... 30 2.2.1.2. Tipos ..................................................................................... 31 2.2.2. Sistema de Informacin. .......................................................... 32

2.2.2.1. Objetivos y Tipos de los Sistemas de Informacin. ............ 32 2.2.2.2. Componentes ..................................................................... 33 2.2.3. Base de Datos. ........................................................................ 33

2.2.3.1. Principales Bases de Datos Comerciales. .......................... 34 2.2.3.2. Diseo de una Base de Datos. ........................................... 35

XIV

2.2.3.3. Sistema Manejador de Base de Datos. .............................. 38 2.2.3.4. Objetivos del Sistema Manejador de Datos. ....................... 39 2.2.3.5. Funciones del Administrador de la Base de Datos (DBA) .. 42 2.2.4. Ingeniera de Software. ............................................................ 43

2.2.4.1. Capas de la Ingeniera de Software. ................................... 43 2.2.5. 2.2.6. Programacin Orientada a Objetos (POO) .............................. 44 Lenguaje Unificado de Modelado (UML).................................. 46

2.2.6.1. Principales Diagramas del UML.......................................... 46 2.2.6.2. Diagrama de Caso de Uso. ................................................ 48 2.2.6.3. Diagrama de Actividades. ................................................... 54 2.2.6.4. Diagrama de Clases de Anlisis. ........................................ 60 2.2.6.5. Diagrama de Interaccin. .................................................... 62 2.2.7. 2.2.8. Diagrama de Clases de Diseo. .............................................. 65 Proceso Unificado de Desarrollo Software. ............................. 72

2.2.8.1. Caractersticas del Proceso Unificado. ............................... 74 2.2.9. Nociones de PHP y MySQL en el Desarrollo Web. ................. 75

2.2.9.1. Concepto de PHP. .............................................................. 75 2.2.9.2. Concepto de Mysql. ............................................................ 76 2.2.10. Nociones de Modelos de Inventarios de Mercancas. ............. 77 2.2.10.1. Trminos Asociados a los Inventarios............................... 80 2.2.10.2. Polticas de inventario. ...................................................... 82 CAPITULO III - MARCO METODOLGICO ................................................. 84 3.1. TIPOS DE INVESTIGACIN. .......................................................... 84

XV

3.2. NIVEL DE LA INVESTIGACIN. ..................................................... 84 3.3. DISEO DE LA INVESTIGACIN. .................................................. 85 3.4. TCNICAS A UTILIZAR. ................................................................. 85 CAPITULO IV RESULTADOS ................................................................... 88 4.1. FASE DE INICIO ............................................................................. 88 4.1.1. 4.1.2. Resumen. ................................................................................ 88 Requisitos del sistema. ............................................................ 89

4.1.2.1. Contexto del sistema. ......................................................... 90 4.1.2.2. Modelo de Dominio. ............................................................ 91 4.1.2.3. Glosario de trminos. .......................................................... 93 4.1.2.4. Requerimientos Candidatos o Funcionales del Sistema. .... 94 4.1.2.5. Requisitos No Funcionales del Sistema. ............................ 95 4.1.2.6. Identificacin de Riesgos. ................................................... 97 4.1.2.7. Identificacin de los Actores del Sistema. .......................... 98 4.1.2.8. Identificacin de los Casos de Uso. .................................... 99 4.1.3. Anlisis de los Requerimientos del Sistema. ......................... 131

4.1.3.1. Diagrama de Clase de Anlisis Detallado Para el Caso de Uso Accesar al Sistema. ................................................................ 132 4.1.3.2. Diagrama de Clase de Anlisis Detallado para el Caso de Uso Procesar Inventario y Costo. .................................................. 133 4.1.3.3. Diagrama de Clase de Anlisis Detallado para el Caso de Uso Gestionar Clientes. ................................................................. 135 4.1.3.4. Diagrama de Clase de Anlisis Detallado para el Caso de Uso Realizar Configuracin. .......................................................... 136

XVI

4.1.3.5. Diagrama de Clase de Anlisis Detallado para el Caso de Uso Generar Reportes. .................................................................. 138 4.1.3.6. Diagrama de Colaboracin Detallado Para el Caso de Uso Accesar al Sistema. ....................................................................... 139 4.1.3.7. Diagrama de Colaboracin Detallado para el Caso de Uso Procesar Inventario y Costo. .......................................................... 140 4.1.3.8. Diagrama de Colaboracin Detallado Para el Caso de Uso Gestionar Clientes ......................................................................... 142 4.1.3.9. Diagrama de Colaboracin del Caso de Uso Realizar Configuracin. .................................................................................. 143 4.1.3.10. Diagrama de Colaboracin Detallado del Caso de Uso Generar Reportes. ........................................................................... 145 4.1.4. 4.1.5. Diseo.................................................................................... 146 Conclusin de la Fase de Inicio. ............................................ 147

4.2. FASE DE ELABORACIN............................................................. 148 4.2.1. 4.2.2. 4.2.3. 4.2.4. Resumen. .............................................................................. 148 Requisitos del Sistema. ......................................................... 149 Anlisis de los Requerimientos del Sistema. ......................... 150 Diseo del sistema propuesto. ............................................... 151

4.2.4.1. Diagramas de Clases de Diseo del Sistema. .................. 152 4.2.4.2. Diagrama de Capas. ......................................................... 160 4.2.4.3. Diseo de la Base de Datos. ............................................ 161 4.2.5. Conclusin de la fase de elaboracin. ................................... 170

4.3. FASE DE CONSTRUCCION ......................................................... 170

XVII

4.3.1. 4.3.2. 4.3.3. 4.3.4.

Resumen. .............................................................................. 170 Requisitos del sistema. .......................................................... 171 Anlisis de los Requerimientos del Sistema. ......................... 171 Diseo del sistema propuesto. ............................................... 172

4.3.4.1. Herramientas de Desarrollo Escogidas. ........................... 172 4.3.4.2. Diseo de las interfaces. .................................................. 178 4.3.5. Implementacin. .................................................................... 198

4.3.5.1. Implementacin Modulo Procesar Inventario y Costo. ...... 199 4.3.6. Pruebas. ................................................................................ 216

4.3.6.1. Pruebas de Caja Negra. ................................................... 217 4.3.7. Conclusin de la Fase de Elaboracin................................... 230

4.4. FASE DE TRANSICIN ................................................................ 230 4.3.8. 4.3.9. Resumen. .............................................................................. 230 Lanzamiento de la versin beta. ............................................ 232

4.3.10. Conclusin de la fase de transicin. ...................................... 232 CONCLUSIONES ....................................................................................... 234 RECOMENDACIONES ............................................................................... 237 BIBLIOGRAFIA ........................................................................................... 238 ANEXO: MANUAL DE USUARIO.. 241 METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSOS270

XVIII

INDICE DE TABLAS
Tabla 2.1. Comparacin de Diagramas de Secuencia y Colaboracin .................... 64 Tabla 4.1. Glosario de trminos. ............................................................................. 93 Tabla 4.2. Requisitos No Funcionales. .................................................................... 95 Tabla 4.3. Actores del Sistema. ............................................................................... 99 Tabla 4.4. Identificacin de los casos de uso. ....................................................... 100 Tabla 4.5. Flujo de eventos del Caso de Uso Accesar al Sistema. ......................... 104 Tabla 4.6. Flujo de eventos del Caso de Uso Procesar Inventario y Costo. .......... 106 Tabla 4.7. Flujo de Eventos del Caso de Uso 2.1 Procesar Equipos y Costos ........ 107 Tabla 4.8. Flujo de Eventos del Caso de Uso 2.2 Asignacin ................................ 109 Tabla 4.9. Flujo de Eventos del Caso de Uso 2.3 Devolucin. ............................... 111 Tabla 4.10. Flujo de Eventos del Caso de Uso 2.4 Desincorporacin. .................. 113 Tabla 4.11. Flujo de Eventos del Caso de Uso Realizar Configuracin .............. 116 Tabla 4.12. Flujo de Eventos del Caso de Uso 3.1 Controlar Usuarios. ................ 117 Tabla 4.13. Flujo de Eventos del Caso de Uso 2.5 Ajustar Precio. ........................ 119 Tabla 4.14. Flujo de Eventos del Caso de Uso 3.3 Respaldo de Datos. ................. 120 Tabla 4.15. Flujo de Eventos del Caso de Uso 3.4 Recuperar Datos. .................... 122 Tabla 4.16. Flujo de Eventos del Caso de Uso Gestionar Clientes. ....................... 125 Tabla 4.17. Flujo de Eventos del Caso de Uso 1.1.2 Generar Reporte.................. 127 Tabla 4.18. Flujo de Eventos del Caso de Uso 5.1 Tipo de Reporte ...................... 128 Tabla 4.19. Flujo de Eventos del Caso de Uso 5.2 Realizar Reporte ..................... 130 Tabla 4.20. Identificacin de los Casos de Prueba. ............................................... 220 Tabla 4.21. Caso de prueba Agregar Usuario. ....................................................... 224 Tabla 4.22. Caso de Prueba Modificar Usuario. .................................................... 225 Tabla 4.23. Caso de Prueba Agregar Equipo. ........................................................ 226 Tabla 4.24. Caso de Prueba Modificar Usuario. .................................................... 227 Tabla 4.25. Caso de Prueba Agregar Cliente. ........................................................ 228 Tabla 4.26. Caso de Prueba Modificar Cliente. ..................................................... 229

XIX

INDICE DE FIGURAS

Figura No. 2.1. Principales Diagramas UML. ........................................................... 48 Figura 2.2. Actor. ..................................................................................................... 50 Figura 2.3. Caso de Uso ........................................................................................... 50 Figura 2.4. Inclusin. ............................................................................................... 52 Figura 2.5. Exclusin................................................................................................ 53 Figura 2.6. Generalizacin....................................................................................... 54 Figura 2.7. Diagrama de Actividad Simple. ............................................................. 56 Figura 2.8. Decisin en un Diagrama de Actividad. ................................................ 57 Figura 2.9. Representacin de una transicin que se bifurca en dos rutas que se ejecutan de forma concurrente y luego se reincorporan. ...................................... 58 Figura 2.10. Representacin del envi de una indicacin y recepcin. .................. 58 Figura 2.11. Ejemplo de una nota UML................................................................... 59 Figura 2.12. Clase de Interfaz .................................................................................. 60 Figura 2.13. Clase Entidad. ...................................................................................... 61 Figura 2.14. Clase Control. ...................................................................................... 61 Figura 2.15. Diagrama de Colaboracin. ................................................................. 62 Figura 2.16. Diagrama de Secuencia. ...................................................................... 63 Tabla 2.1. Comparacin de Diagramas de Secuencia y Colaboracin .................... 64 Figura 2.17. Representacin de una Clase. ............................................................. 67 Figura 2.18. Asociacin. .......................................................................................... 69 Figura 2.19. Dependencia. ...................................................................................... 69 Figura 2.20. Herencia. ............................................................................................. 70 Figura 2.21. Composicin. ....................................................................................... 70 Figura 2.22. Agregacin. ......................................................................................... 71 Figura 2.23. RUP: Proceso Unificado de Desarrollo Software. ............................... 73 Figura 4.1. Fases y Flujos de Trabajo del Proceso Unificado (inicio). ..................... 89 Figura 4.2. Modelo de Dominio del Sistema Actual. ............................................... 92

XX

Figura 4.3. Modelo de Caso de Uso General S.I.M.I.C.. ..................................... 102 Figura 4.4. Caso de Uso Accesar al Sistema. ...................................................... 103 Figura 4.5. Diagrama de Estado del Caso de Uso Accesar al Sistema. .................. 104 Figura 4.6. Caso de Uso Procesar Inventario y Costo. ....................................... 105 Figura 4.7. Diagrama de Estado del Caso de Uso Procesar Inventario y Costo. ... 106 Figura 4.8. Diagrama de Estado del Caso de Uso 2.1 Equipos y Costos. ............... 108 Figura 4.9. Diagrama de Estado del Caso de Uso 2.2 Asignacin ......................... 110 Figura 4.10. Diagrama de Estado del Caso de Uso 2.2.2 Devolucin de Equipos. 112 Figura 4.11. Diagrama de Estado del Caso de Uso 2.4 Desincorporacin. ........... 114 Figura 4.12. Caso de Uso Realizar Configuracin. ............................................. 115 Figura 4.13. Diagrama de Estado del Caso de Uso Realizar Configuracin........... 116 Figura 4.14. Diagrama de Estado del Caso de Uso 3.1 Controlar Usuarios. ......... 118 Figura 4.15. Diagrama de Estado del Caso de Uso 3.2. Ajustar Costo. ................. 119 Figura 4.16. Diagrama de Estado del Caso de uso 3.2. Respaldo de Datos. ......... 121 Figura 4.17. Diagrama de Estado del Caso de Uso 3.3 Recuperar Datos. ............. 123 Figura 4.18. Caso de Uso Gestionar Clientes. .................................................... 124 Figura 4.19. Diagrama de Estado del Caso de Uso Gestionar Clientes. ................ 125 Figura 4.20. Caso de Uso Generar Reportes. ..................................................... 126 Figura 4.21. Diagrama de Estado del Caso de Uso 1.2 Generar Reporte.............. 127 Figura 4.22. Diagrama de Estado del Caso de Uso 5.1 Tipo de reporte................ 129 Figura 4.23. Diagrama de Estado del Caso de Uso 5.2 Realizar Reporte. ............. 130 Figura 4.24. Diagrama de Clase de Anlisis del Caso de Uso Accesar al Sistema. 132 Figura 4.25. Diagrama de Clase de Anlisis del Caso de Uso Procesar Inventario y Costo. .................................................................................................................... 134 Figura 4.26. Diagrama de Clase de Anlisis del Caso de Uso Gestionar Clientes.. 135 Figura 4.27. Diagrama de Clase de Anlisis del Caso de Uso Realizar Configuracin. .............................................................................................................................. 137 Figura 4.28. Diagrama de Clase de Anlisis para el Caso de Uso Generar Reportes .............................................................................................................................. 138 Figura 4.29. Diagrama de Colaboracin del Caso de Uso Accesar al Sistema. ..... 139

XXI

Figura 4.30. Diagrama de Colaboracin del Caso de Uso Procesar Inventario y Costo. .................................................................................................................... 141 Figura 4.31. Diagrama de Colaboracin del Caso de Uso Gestionar Clientes. ...... 142 Figura 4.32. Diagrama de Colaboracin del Caso de Uso Realizar Configuracin. 144 Figura 4.33. Diagrama de Colaboracin del Caso de Uso Generar Reportes........ 145 Figura 4.34. Diagrama de Paquete de Anlisis del Sistema SIMIC. ....................... 147 Figura 4.35. Fases y Flujos de Trabajo del Proceso Unificado (Elaboracin). ....... 150 Figura 4.36. Diagrama de Paquetes de Anlisis a partir de de los Casos de Usos Principales ............................................................................................................. 151 Figura 4.37. Diagrama de Clase de Diseo para el Caso de Uso Accesar al Sistema. .............................................................................................................................. 153 Figura 4.38. Diagrama de Clase de Diseo para el Caso Uso Procesar Inventario y Costo. .................................................................................................................... 155 Figura 4.39. Diagrama de Clase de Diseo para el Caso de Uso Realizar Configuracin. ....................................................................................................... 157 Figura 4.40. Diagrama de Clase de diseo para de Caso de Uso Gestionar Clientes. .............................................................................................................................. 158 Figura 4.41. Diagrama de Clase de Diseo para el Caso de Uso Generar Reportes. .............................................................................................................................. 159 Figura 4.42. Diagrama de Capas............................................................................ 161 Figura 4.43. Modelo Relacional de la Base de Datos SIMIC. ................................. 168 Figura 4.44. Prototipo de la Interfaz SIMIC. .......................................................... 169 Figura 4.45. Fases y Flujos de Trabajo del Proceso Unificado (Construccin). ..... 171 Figura 4.46. Interfaz Accesar al Sistema. .............................................................. 180 Figura 4.47. Interfaz Principal de Usuario. ............................................................ 181 Figura 4.48. Interfaz Realizar Configuracin. ........................................................ 182 Figura 4.49. Interfaz Controlar Usuarios. .............................................................. 184 Figura 4.50. Agregar/Editar Usuario ..................................................................... 184 Figura 4.51. Interfaz Ajustar Costo........................................................................ 185 Figura 4.52. Interfaz Respaldo de Datos. .............................................................. 186 Figura 4.53. Interfaz Recuperar Datos. ................................................................. 187

XXII

Figura 4.54. Interfaz Procesar Inventario y Costo. ................................................ 188 Figura 4.55. Interfaz Equipos y Costos. ................................................................. 189 Figura 4.56. Agregar/Editar Equipos. .................................................................... 190 Figura 4.57. Interfaz Asignacin. ........................................................................... 191 Figura 4.58. Interfaz Devolucin. .......................................................................... 192 Figura 4.59. Agregar Devolucin. .......................................................................... 193 Figura 4.60. Interfaz Desincorporacin. ................................................................ 194 Figura 4.61. Descargo del Equipo.......................................................................... 194 Figura 4.62. Interfaz Clientes. ............................................................................... 195 Figura 4.63. Agregar editar clientes. ..................................................................... 196 Figura 4.64. Interfaz Tipo de Reporte. .................................................................. 197 Figura 4.65. Periodo de Tiempo de Reporte. ........................................................ 197 Figura 4.66. Reporte Visualizado (Desincorporacin)........................................... 198 Figura 4.67. Fases y Flujos de Trabajo del Proceso Unificado (Transicin). ......... 231

XXIII

CAPITULO I - EL PROBLEMA
1.1. PROBLEMA DE LA INVESTIGACIN

Desde hace ya algunos aos las organizaciones han reconocido la importancia de la buena administracin de sus recursos principales como lo son: la materia prima, la mercanca y, por supuesto, la mano de obra.

En la actualidad, la informacin conjuntamente con los recursos bsicos, mano de obra y materia prima, ha obtenido una connotacin importante en la organizacin. Se le considera como promotora de la operacin misma, e inclusive puede llegar a ser un elemento decisivo en el proceso de la toma de decisiones, que pudiese determinar el xito o fracaso para la empresa.

La empresa Diesel Oriente C.A. es una entidad dedicada a la compra y venta de repuestos de vehculos pesados al mayor y en unidades, ubicada en la avenida Octavio Camejo (Av. Alterna) de la ciudad de Barcelona, municipio Simn Bolvar del Estado Anzotegui.

Bajo la tutela de tres accionistas principales la empresa posee un rea administrativa encargada de todos los procesos inherentes a las actividades diarias de la organizacin como: manejo de inventarios, control de costos, comercializacin de repuestos, importacin de mercanca, sueldos y salarios, etc.

Toda labor de la empresa inicia su proceso al momento de realizarse la importacin de la mercanca necesitada para la venta al pblico. Se

24

contacta a los proveedores habituales de acuerdo a los convenios establecidos, polticas de precios y comodidades en el traslado de los repuestos adquiridos.

Al momento de la importacin de una pieza, sta se registra en la compaa bajo una codificacin y datos de la empresa desde donde proviene el repuesto as como tambin todas las caractersticas de la pieza importada. A partir de este momento se almacena y se realiza un proceso de conteo del inventario actual de la compaa.

El problema en las labores de la empresa, radica en que al momento del registro o inventario de la mercanca, ya sea al recibirse repuestos nuevos o para la comprobacin de los productos que poseen y los faltantes, dicho proceso se realiza de manera manual lo cual conlleva a un trmite tedioso para la compaa ya que no se posee un sistema al cual se pueda recurrir y que permita arrojar informacin veraz, actualizada y oportuna de todos y cada uno los producto que posea la organizacin.

Todos estos datos estn en control del rea administrativa por medio de herramientas como Excel, que deben actualizarse continuamente. Generalmente, el uso de este tipo de control de informacin ocasiona que el ajuste de los precios, ya sea por cualquier tipo de cambio inflacionario o del dlar, tenga que ser realizado a cada pieza por separado y a travs de clculos manuales que repercuten en los inconvenientes antes mencionados de tiempo y trabajo.

Como solucin al problema planteado se propone disear, y posteriormente desarrollar, un sistema de informacin al que solo puedan accesar usuarios debidamente autorizados y registrados, que actualicen los 25

datos pertinentes de cada uno de los repuestos ya existentes y los de importacin, como sus costos, proveedores, codificacin, cantidad, etc., de manera rpida y sencilla. La aplicacin ser diseada utilizando herramientas de software y de sistemas de informacin. Para el diseo se emplear como metodologa el Proceso Unificado de Modelado (RUP).

La elaboracin de esta propuesta no solo representa un trabajo asignado, sino un aporte para la compaa, para la cual su alcance se

orienta a la creacin del diseo de un sistema de informacin para el control prctico y efectivo de las actividades ms relevantes con respecto a los proveedores, inventario, costos entre otros.

El diseo de esta aplicacin marca un modelo en cuanto al desarrollo de software se refiere en la empresa Diesel Oriente C.A. siendo la primera aplicacin propuesta y llevado a cabo en esta organizacin.

La importancia de la creacin de este sistema puede visualizarse desde dos puntos de vista diferentes.

Como primer punto se tiene a la empresa, este sistema proporcionar un medio de informacin con el cual las importaciones sern registradas por los diferentes usuarios de manera rpida y sencilla, as como tambin el control y actualizacin de precios e inventario de las piezas existentes.

Por otro lado, los usuarios, el sistema proporcionar una interfaz grfica muy sencilla en el que los registros y consultas sern de manera muy simple y prctica, obteniendo como resultado informacin precisa y veraz en tiempos muy reducidos a diferencia de la actualidad.

26

1.2.

OBJETIVOS

1.2.1. Objetivo General

Desarrollar un sistema de informacin basado en entorno web para el control de inventarios y costos de una compaa comercializadora de repuestos automotrices ubicada en Barcelona, Estado Anzotegui.

1.2.2. Objetivos Especficos

Describir

el sistema actual de inventario y costos que se encuentra

en la compaa.

Identificar los requerimientos de informacin del sistema.

Modelar la estructura del sistema en un entorno web.

Modelar la base de datos del sistema de informacin.

Realizar una Interfaz accesible, interactiva y de fcil manejo para los usuarios del sistema.

Codificar los mdulos del sistema.

27

CAPITULO II - MARCO TEORICO


2.1. ANTECEDENTES DE LA INVESTIGACION

Existen diversos trabajos de grado dentro de la Universidad de Oriente que sirven de base para la elaboracin de este proyecto que por primera vez se est desarrollando en la empresa Diesel Oriente mediante el PROCESO UNIFICADO DE MODELADO. Entre estos trabajos se encuentran:

Rojas, H. (2008), elabor un trabajo denominado Diseo de un Sistema de Informacin para la Automatizacin del Proceso de Facturacin y Cobranza de la Carga Transportadora por las Empresas Registradas en el Puerto de Guanta. Este proyecto se bas en el diseo de un sistema de informacin para la automatizacin del proceso de facturacin y cobranza de la carga transportada por las empresas registradas en el Puerto de Guanta, utilizando los diagramas del Lenguaje Unificado para el Modelado (UML) y para la creacin de la interfaz Microsoft Visual Basic 6.0.

Serritielo, K. (2007), expone el Diseo de un Sistema de Informacin para el Proceso de Asignacin de Citas a los Pacientes de una Institucin Diagnstica. Este proyecto se bas en el diseo de un sistema de informacin que permitiera automatizar el proceso de citas de los pacientes, utilizando la metodologa del Lenguaje de Modelado Unificado (UML) como herramienta para el diseo del proyecto.

28

Cedeo, J. (2007), este autor elabor el Desarrollo de una Aplicacin Web para el Registro, Manejo, Control de Eventos Organizados por la Unidad de Calidad de Vida del Departamento de Recursos Humanos de PDVSA-Refinacin Puerto la Cruz. Este proyecto se bas en el diseo de una aplicacin que permitiera darle mayor rapidez, seguridad y eficiencia a diversas operaciones, utilizando como metodologa de diseo el Proceso Unificado Racional junto con la metodologa y procedimientos de desarrollo propios de la empresa y la gerencia dedicada a estos proyectos (PDVSAAIT).

Snchez, M. (2005), este autor aport el Diseo de un Sistema de Informacin para Automatizar Algunas de las Actividades Relacionadas con el Proceso de Produccin de Crudo y Gas desde el Yacimiento hasta las Estaciones de Flujo, que se Realizan en una Empresa Petrolera, en Punta de Mata. El propsito de este proyecto fue disear un sistema automatizado que permitiera procesar, almacenar y generar toda la informacin relacionada a las actividades, costos de pozos y estaciones de flujos de la empresa. El proceso del diseo incluy el levantamiento de la informacin mediante entrevistas al personal de la empresa; adems del anlisis de las base de datos involucradas, lo cual permiti determinar el comportamiento del sistema actual y as elaborar el modelo del sistema propuesto, a travs de la metodologa del Proceso Unificado Racional.

Sifontes, M. y Carrin, A. (2005), estos autores expusieron el Diseo de un Sistema de Informacin para el Control de los Servicios de la Gerencia de ventas de la Empresa CANTV., Regin Oriental. Este proyecto se bas en el diseo de un sistema de informacin utilizando los diagramas del Lenguaje de Modelado Unificado (UML) para determinar los requerimientos necesarios del nuevo sistema. 29

2.2.

BASES TEORICAS

2.2.1. Definicin de Sistemas

Es un conjunto de elementos dinmicamente relacionados formando una actividad para alcanzar un objetivo operando sobre datos, energa y/o materia para proveer informacin.

2.2.1.1. Caractersticas

Segn Bertalanffy, sistema es un conjunto de unidades recprocamente relacionadas. De ah se deducen dos conceptos: propsito (u objetivo) y globalismo (o totalidad).

Propsito u objetivo: todo sistema tiene uno o algunos propsitos. Los elementos (u objetos), como tambin las relaciones, definen una distribucin que trata siempre de alcanzar un objetivo.

Globalismo o totalidad: un cambio en una de las unidades del sistema, con probabilidad producir cambios en las otras. El efecto total se presenta como un ajuste a todo el sistema. Hay una relacin de causa/efecto. De estos cambios y ajustes, se derivan dos fenmenos: entropa y homeostasia. o Entropa: es la tendencia de los sistemas a desgastarse, a desintegrarse, para el relajamiento de los estndares y un aumento de la aleatoriedad. La entropa aumenta con el correr del tiempo. Si aumenta la informacin, disminuye la entropa, pues la informacin es la base de la configuracin y del orden. 30

Homeostasia: es el equilibrio dinmico entre las partes del sistema. Los sistemas tienen una tendencia a adaptarse con el fin de alcanzar un equilibrio interno frente a los cambios externos del entorno.

2.2.1.2.

Tipos

En cuanto a su constitucin, pueden ser:

Sistemas Fsicos o Concretos: Compuestos por equipos, maquinarias, objetos y cosas reales. Es el hardware.

Sistemas Abstractos: Compuestos por conceptos, planes, hiptesis e ideas. Muchas veces solo existen en el pensamiento de las personas. Es el software.

En cuanto a su naturaleza, pueden ser:

Sistemas

Cerrados:

Son

todos

aquellos

sistemas

cuyo

comportamiento es determinstico y programado y que opera con muy pequeo intercambio de energa y materia con el ambiente.

Sistemas Abiertos: Presentan intercambio con el ambiente, a travs de entradas y salidas, es decir, intercambian energa y materia con el ambiente.

31

2.2.2. Sistema de Informacin.

Un sistema de informacin es un conjunto de elementos que interactan entre si con el fin de apoyar las actividades de una empresa o negocio. En un sentido amplio, un sistema de informacin no necesariamente incluye equipo electrnico (hardware). Sin embargo, en la prctica se utiliza como sinnimo de sistema de informacin computarizado.

2.2.2.1.

Objetivos y Tipos de los Sistemas de Informacin.

Los sistemas de informacin deben cumplir con tres objetivos bsicos dentro de las organizaciones:

Automatizar los procesos operativos.

Proporcionar informacin que sirva de apoyo al proceso de toma de decisiones.

Lograr ventajas competitivas a travs de su implantacin y uso.

Entre los principales tipos de sistemas de informacin tenemos:

Sistemas Transaccionales.

Sistemas de Apoyo a las Decisiones.

Sistemas Estratgicos.

32

2.2.2.2.

Componentes

El Sistema de Informacin est constituido por los procedimientos, personas y medios tcnicos que permiten capturar, tratar y difundir la informacin, de forma que pueda contribuir a la toma de decisiones o a la puesta en prctica de dichas decisiones, es decir, a la ejecucin de acciones concretas. Los sistemas de informacin pueden ser clasificados en tres grupos:

Las herramientas tecnolgicas (hardware, software, base de datos, telecomunicaciones).

Las personas.

Los procedimientos.

2.2.3. Base de Datos.

Es un conjunto de datos en un formato estndar, el cual est diseado para compartir informacin entre varios usuarios.

Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayora por documentos y textos impresos en papel e indexados para su consulta. En la actualidad, y debido al desarrollo tecnolgico de campos como la informtica y la electrnica, la mayora de las bases de datos estn en formato digital (electrnico), que ofrece un amplio rango de soluciones al problema de almacenar datos.

33

2.2.3.1.

Principales Bases de Datos Comerciales.

Entre las principales bases de datos comerciales se tienen:

Base de Datos Jerrquica.

Base de Datos de Red.

Base de Datos Relacional.

Base de Datos Orientada a Objetos.

Se definen los modelos de base de datos ms actuales e importantes:

Base de Datos Relacional.

E.F. Codd ide el mtodo de base de datos relacional en la dcada de 1970, y en pocos aos, tres elementos se integraron para hacer que la base de datos relacional se volviera el mtodo predominante para guardar datos. Primero, los tericos definieron los conceptos bsicos e ilustraron las ventajas. Segundo, los programadores que desarrollaron el software del sistema de administracin de base de datos crearon componentes eficaces. Tercero, el desempeo del hardware mejor para manejar las exigencias ms grandes del sistema.

34

La ventaja del mtodo relacional es que el desarrollador no necesita saber cules preguntas se harn sobre los datos. Si los datos se definen con cuidado, la base de datos puede resolver en forma prctica cualquier pregunta con eficacia. Esta flexibilidad y eficacia son las principales razones del predominio del modelo relacional.

Base de Datos Orientada a Objetos.

Una base de datos orientada a objetos (OO) es un mtodo nuevo y en evolucin de organizar datos. El mtodo OO comenz como un proceso nuevo para crear programas computacionales. La meta es definir los objetos que se pueden utilizar en muchos programas, lo cual ahorra tiempo y reduce los errores.

2.2.3.2.

Diseo de una Base de Datos.

Los sistemas de informacin son complejos, cambian sin cesar, y es costoso crearlos y darles mantenimiento. Pero un sistema bien diseado genera enormes beneficios para una organizacin. Desarrollar un sistema til requieres que se comprenda al usuario y se comunique con el. Esto suele requerir organizar y dirigir a un equipo de desarrolladores. Los diseos de un sistema son modelos que se emplean para facilitar esta comunicacin y colaboracin en equipo. De la misma manera los diseos son una simplificacin o una imagen de las operaciones de negocios que subyacen. Los modelos del diseo tambin registran las caractersticas, suposiciones y restricciones fundamentales en cualquier negocio.

Los pasos que se deben seguir para el diseo de una base de datos son los siguientes: 35

Identificacin de los Requisitos del Usurario: un aspecto desafiante de disear un sistema es determinar los requerimientos. Es necesario comprender por completo las necesidades de negocio antes de poder crear un sistema til. Un paso fundamental es entrevistar a los usuarios y observar las operaciones de la empresa. Si bien este paso suena fcil, puede ser difcil; sobre todo cuando los usuarios con coinciden entre s. Incluso en las mejores circunstancias, la comunicacin puede ser difcil. Excelentes habilidades de comunicacin y la experiencia son importantes para volverse un buen diseador. Una de las tareas ms importantes al disear una aplicacin de base de datos es identificar de manera oportuna los datos que necesiten guardarse. Siempre y cuando se recolecten los datos y se organicen con cuidado, el DBMS facilita crear y modificar los informes, mientras se habla con los usuarios, ser prescindible recolectar sus documentos, en decir, sus informes y formulario. Estos documentos proporcionan informacin acerca de los datos y las operaciones bsicas de la empresa. Adems se necesitan reunir tres segmentos bsicos de informacin para el diseo inicial: 1) los datos que necesitan recolectarse, 2) el tipo de datos (dominio), y 3) la cantidad de datos relacionados.

Definir el Objeto del Negocio: El diseo de una base de datos se concentra en identificar los datos que necesitan almacenarse. Despus, se crean las consultas para buscar los datos, formularios de ingreso para introducir datos nuevos y los informes para recuperar y desplegar los datos de un modo que coincida con las necesidades del usuario. Por ahora, el paso ms importante es

36

organizar los datos para que el sistema de base de datos los maneje con eficiencia.

Todos los negocios tratan con entidades u objetos; por ejemplo: clientes, productos, empleados y ventas. Desde una perspectiva de sistema, una entidad es un elemento del mundo real al que se pretende dar seguimiento. Esa entidad se describe mediante sus atributos y propiedades. Por ejemplo, la entidad de los clientes tiene un nombre, direccin y nmero telefnico. En trminos de un modelo, una entidad enlistada con sus propiedades se conoce con el nombre de clase. En el ambiente de programacin una clase tambin puede construir mtodos o funciones que puede

desempear, lo cual es posible enlistar con la clase. Por ejemplo, las clases de los clientes pueden tener un mtodo para agregar a un cliente nuevo, los diseos de base de datos rara vez necesitan describir mtodos, de modo que no suelen listarse.

Los diseadores de una base de datos necesitan algn modo de conservar notas y mostrar la lista de clases a los usuarios y otros diseadores. Hoy en da se han desarrollados varias tcnicas grficas, pero el mtodo moderno es utilizar un diagrama de clase. Un diagrama de clase representa cada clase como un cuadro que contiene una lista de propiedades para la clase. Los diagramas de clase tambin muestran como se relacionan las la clases entre si al conectarlas con lneas.

Creacin de las Tablas y Relaciones: el objeto principal en el diseo de una base de datos es identificar los datos que necesitarn los usuarios. Los datos se guardarn con cuidado, de modo que la 37

base de datos pueda almacenarlos y recuperarlos de manera eficiente. Las bases de datos relacionales alcanzan esta eficiencia al guardar los datos en tablas. Estas tablas representan las clases de negocio en donde las propiedades se convierten en columnas de tablas, y cada fila representa los datos para uno de los objetos. De modo que, mientras se habla con los usuarios y se comienza a identificar los datos que se van a reunir, es necesario organizarlos en clases. Aunque este proceso no es difcil, se debe tener cuidado, ya que las tablas de datos deben cumplir con ciertos requisitos.

Las clases, que terminan por convertirse en tablas, se relacionan entre s. Por ejemplo, la clase Sales (ventas) contiene un atributo para identificar al Customer (cliente) que participa en la venta; de modo que la clase Customer est conectada a la clase Sales. En un diagrama de clase esta relacin se exhibe mediante una lnea que conecta a las dos clases.

Estas relaciones tambin tienen un valor numrico que contienen informacin de negocios adicional. En el ejemplo Customer/Sales, casi todas las empresas tienen una poltica de que solo un cliente se lista en una venta, pero un cliente puede participar en muchas ventas distintas. Por lo tanto, existe una relacin uno a varios entre Customer y Sales. Estas relaciones son esenciales para el diseo preciso de la base de datos.

2.2.3.3.

Sistema Manejador de Base de Datos.

Los sistemas de gestin de base de datos (SGBD); (en ingls: Database Management System, abreviado DBMS) son un tipo de software muy especfico, dedicado a servir de interfaz entre la base de datos, el usuario y 38

las aplicaciones que la utilizan. El propsito general de los sistemas de gestin de base de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirn en informacin relevante, para un buen manejo de datos.

El SGBD incorpora como herramienta fundamental dos lenguajes, para la definicin y la manipulacin de los datos. El lenguaje de definicin de datos (DDL, Data Definition Language) provee de los medios necesarios para definir los datos con precisin, especificando las distintas estructuras. Acorde con el modelo de arquitectura de tres niveles, habr un lenguaje de definicin de la estructura lgica global, otro para la definicin de la estructura interna, y un tercero para la definicin de las estructuras externas.

El lenguaje de manipulacin de datos (DML, Data Manipulation / Management lenguaje), que es el encargado de facilitar a los usuarios el acceso y manipulacin de los datos. Pueden diferenciarse en

procedimentales (aquellos que requieren que datos se necesitan y como obtenerlos) y no procedimentales (que datos se necesitan, sin especificar cmo obtenerlos) y se encargan de la recuperacin de los datos almacenados, de la insercin y supresin de datos en la base de datos, y de la modificacin de los existentes.

2.2.3.4.

Objetivos del Sistema Manejador de Datos.

Existen distintos objetivos que deben cumplir los SGBD:

Abstraccin de la Informacin: Los SGBD ahorran a los usuarios detalles acerca del almacenamiento fsico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se 39

hace transparente al usuario. As, se definen varios niveles de abstraccin.

Independencia: La independencia de los datos consiste en la capacidad de modificar el esquema (fsico o lgico) 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 informacin que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultnea. 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 debera aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programacin de este tipo de condiciones.

Seguridad: La informacin almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta informacin se encuentra segura frente a usuarios malintencionados, que intenten leer informacin privilegiada; frente a ataques que deseen manipular o destruir la informacin; o simplemente ante las torpezas de algn usuario autorizado pero despistado. Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categoras de permisos.

40

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 informacin almacenada. Los SGBD proveen

mecanismos para garantizar la recuperacin de la base de datos hasta un estado consistente conocido en forma automtica.

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

Control de la Concurrencia: En la mayora de entornos (excepto quizs el domstico), lo ms habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar informacin, bien para almacenarla. Y es tambin frecuente que dichos accesos se realicen de forma simultnea. As pues, un SGBD debe controlar este acceso concurrente a la informacin, que podra derivar en inconsistencias.

Manejo de Transacciones: Una Transaccin es un programa que se ejecuta como una sola operacin. Esto quiere decir que el estado luego de una ejecucin en la que se produce una falla es el mismo que se obtendra si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho ms simple que si no se dispusiera de ellos.

41

Tiempo de Respuesta: Lgicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la informacin solicitada y en almacenar los cambios realizados.

2.2.3.5.

Funciones del Administrador de la Base de Datos (DBA).

a. Definicin del esquema: se consigue al escribir una serie de definiciones que el compilador de definicin de datos traduce a un conjunto de tablas que se almacenan de forma permanente en el diccionario de datos.

b. Definicin de la estructura de almacenamiento y del mtodo de acceso: se lleva a cabo al escribir la definicin de la estructura del almacenamiento mediante el lenguaje de definicin de datos, que posteriormente son traducidas por el compilador del lenguaje de almacenamiento y definicin de datos.

c. Concepcin de automatizacin para el acceso a los datos: mediante este acceso se regulan las partes de las bases de datos a las que va a tener acceso los diversos usuarios. Adems se debe especificar la correspondencia entre cualquier esquema externo y el esquema conceptual.

d. Definicin

de

los

procedimientos

de

validacin:

pueden

considerarse una extensin lgica del esquema conceptual.

42

2.2.4. Ingeniera de Software.

Es el establecimiento y uso de principios robustos de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione

eficientemente sobre mquinas reales. Es la Aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software.

2.2.4.1.

Capas de la Ingeniera de Software.

La ingeniera del software es una tecnologa multicapa, las cuales son: Un Enfoque de Calidad, Proceso, Mtodos y Herramientas.

Cualquier enfoque de ingeniera (incluida la ingeniera del software) debe apoyarse sobre un compromiso de organizacin de calidad.

El fundamento de la ingeniera del software es la capa de proceso. El proceso de ingeniera del software es la unin que mantienen juntas las capas de tecnologa y permite un desarrollo racional y oportuno de la ingeniera del software. Los mtodos de la ingeniera del software indican como construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del software dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.

43

Las herramientas de la ingeniera del software proporcionan un enfoque automtico o semiautomtico para el proceso y para los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computadora.

2.2.5. Programacin Orientada a Objetos (POO)

La programacin orientada a objetos (POO u OPP, segn sus siglas en ingles) es un paradigma de programacin que usa objetos y sus interacciones para disear aplicaciones y programas de computadoras. Est basado en varias tcnicas, incluyendo herencia, modularidad, polimorfismos y encapsulamiento. Su uso se popularizo a principios de la dcada de 1990. Actualmente son muchos los lenguajes de programacin que soportan la orientacin a objetos.

La programacin orientada a objetos es una forma de programar que trata de encontrar una solucin a estos problemas. Introduce nuevos conceptos, que superan y amplan conceptos antiguos ya conocidos. Entre ellos se destacan los siguientes: Clase: definimientos de las propiedades y comportamientos de un tipo de objeto concreto. La instanciacin es la lectura de estas definiciones y la creacin de un objeto a partir de ellas , ( de c a d), es la facilidad mediante la cual la clase D ha definido en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definido por las misma D.

44

Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (mtodos). Se

corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa).

Mtodo: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un cambio en las propiedades del objeto, o la generacin de un " evento" con u nuevo mensaje para otro objeto del sistema.

Evento: un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin q genera.

Mensaje: una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus mtodos con ciertos parmetros asociados al evento que lo gener.

Propiedad o atributos: contenedor de un tipo de datos asociados a un objeto a una clase de objetos, que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas , y cuyo valor puede ser alterado por la ejecucin de algn mtodo.

45

2.2.6. Lenguaje Unificado de Modelado (UML).

Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables.

El UML es un lenguaje de modelado, y no un mtodo. La mayor parte de los mtodos consisten, al menos en principio, en un lenguaje y en un proceso para modelar. El lenguaje de modelado es la notacin

(principalmente grfica) de que se valen los mtodos para expresar los diseos. El proceso es la orientacin que nos dan sobre los pasos a seguir para hacer el diseo.

2.2.6.1.

Principales Diagramas del UML.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. Entre los principales diagramas se encuentran:

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

46

Diagrama de clases.

Diagrama de componentes.

Diagrama de objetos.

Diagrama de despliegue.

Diagrama de paquetes.

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

Diagrama de actividades.

Diagrama de casos de uso.

Diagrama de estados.

Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

Diagrama de secuencia.

Diagrama de colaboracin.

A continuacin en la Figura N 2.1 se muestran los principales diagramas del lenguaje unificado de modelado: 47

Figura No. 2.1. Principales Diagramas UML. Fuente: Elaboracin Propia.

2.2.6.2.

Diagrama de Caso de Uso.

Un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, sta es una herramienta valiosa, ya que es tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que pueda ser utilizado por la gente en general (no slo por expertos en computacin).

48

Imagnese el caso de uso como una coleccin de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencia se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inici, o por otro actor.

No siempre es fcil para los usuarios explicar cmo pretenden utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo as como una ciencia oculta, con muy poca informacin para los usuarios, aquellos que osaban a preguntar se les daba informacin muy poco explcita o ciertamente confusa respecto a lo que utilizaran.

La idea es involucrar a los usuarios en las etapas iniciales del anlisis y diseo del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente ayudar, en lugar de ser un manojo de expresiones de computacin incomprensibles e inmanejables por los usuarios finales.

A continuacin se presentan algunas definiciones informales para conocer un poco ms sobre el diagrama de casos de uso y sus elementos:

Actor: Es algo con comportamiento, como una persona (identificada por un rol), sistema informatizado u organizacin. Se representa mediante la figura N 2.2 mostrada a continuacin:

49

Figura 2.2. Actor. Fuente: Elaboracin propia.

Escenario: Es la secuencia especfica de acciones e interacciones entre los actores y el sistema objeto de estudio; tambin se denomina instancia de caso de uso. Es una historia en particular del uso de un sistema o un camino a travs de un caso de uso.

Caso de Uso: Es una coleccin de escenarios con xito y fallo relacionados, que describe a los actores utilizando un sistema para satisfacer un objetivo. Se representa mediante la figura N 2.3 mostrada a continuacin:

Nombre Del Caso De Uso

Figura 2.3. Caso de Uso Fuente: Elaboracin Propia.

50

Los actores no son solamente roles que juegan las personas, sino tambin organizaciones, software y mquinas. Existen tres tipos de actores con relacin al SuD (System under Discussion):

Actor Principal: Tiene objetivos de usuario que se satisfacen mediante el uso de los servicios del SuD.

Actor

de

Apoyo:

Proporciona

un

servicio

(por

ejemplo:

informacin) al SuD. Normalmente se trata de un sistema informtico, pero podra ser una organizacin o una persona.

Actor Pasivo: Est interesado en el comportamiento del caso de uso, pero no es principal ni de apoyo (por el ejemplo: la agencia tributaria de gobierno).

Los casos de uso se escriben con formatos diferentes, dependiendo de la necesidad, a continuacin se describen cada uno de ellos:

Breve: Resumen conciso de un prrafo, normalmente del escenario principal con xito.

Informal: Formato de prrafo en un estilo informal. Mltiples prrafos que comprenden varios escenarios.

Completo: El ms elaborado. Se escriben con detalles todos los pasos y variaciones, y hay secciones de apoyo como

precondiciones y garantas de xito.

51

Cabe destacar que para este trabajo de grado el formato que se adopt para el diagrama de casos de uso es el formato completo presentado en el libro UML y Patrones del autor Craig Larman.

Existen tres relaciones principales entre los casos de uso, las cuales se describen a continuacin:

(Include) o (use): Es una forma de interaccin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde

mltiples casos de uso a una descripcin individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include".

Este uso se asemeja a una expansin de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno.

Se representa mediante la figura N 2.4 mostrada a continuacin:

Nombre Del Caso De Uso


Include

Figura 2.4. Inclusin. Fuente: Elaboracin Propia.

52

Extensin (Extends): Es otra forma de interaccin, un caso de uso dado, (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones.

La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extends. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin.

La extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. Se representa mediante la figura N 2.5 mostrada a continuacin:

Nombre Del Caso


Figura 2.5. Exclusin. Fuente: Elaboracin Propia. Exclude

De Uso

La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos.

Generalizacin: En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un

53

tringulo dibujado desde el caso de uso especializado al caso de uso general. Se representa mediante la figura 2.6 mostrada a continuacin:

Figura 2.6. Generalizacin. Fuente: Elaboracin Propia.

Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intensin y extensin.

2.2.6.3.

Diagrama de Actividades.

El diagrama de actividades es muy parecido a los viejos diagramas de flujo. Muestra los pasos (conocidos como actividades) as como puntos de

54

decisin y bifurcaciones. Es til para mostrar lo que ocurre en un proceso de negocios u operacin. Se encuentra como parte integral del anlisis de un sistema.

El diagrama de actividades ha sido diseado para mostrar una visin simplificada de lo que ocurre durante una operacin o proceso. Es una extensin de diagramas de estados. El diagrama de estados muestra los estados de un objeto y representa actividades como flechas que conectan a los estados. El diagrama de actividades resalta, precisamente, a las actividades.

A cada actividad se le representa por un rectngulo con las esquinas redondeadas. El procesamiento dentro de una actividad se lleva a cabo y, al realizarse, se contina con la siguiente actividad. Una flecha representa la transicin de una a otra actividad.

Al igual que el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un crculo relleno) y uno final (representado por una diana).

A continuacin la figura 2.7 muestra el punto inicial y el punto final del diagrama de actividad simple, adems la representacin de dos actividades y una transicin de una actividad a otra:

55

Figura 2.7. Diagrama de Actividad Simple. Fuente: Elaboracin Propia.

Casi siempre una secuencia de actividades llegar a un punto donde se realizar alguna decisin. Ciertas condiciones le llevarn por un camino y otras por otro (pero ambas son mutuamente exclusivas).

Se puede representar un punto de decisin de dos formas: la primera es mostrar las rutas posibles que parten directamente de una actividad y la segunda es llevar la transicin hacia un rombo y que de all salgan las rutas de decisin. De cualquier forma, indicar la condicin con una instruccin entre corchetes junto a la ruta correspondiente.

A continuacin en la figura N 2.8 se muestra un ejemplo de las dos formas de representar una decisin:

56

Figura 2.8. Decisin en un Diagrama de Actividad. Fuente: Elaboracin Propia.

Conforme se modelen actividades se tendr la oportunidad de separar una transicin en dos rutas que se ejecuten al mismo tiempo (es decir, de forma concurrente) y luego se renan.

Para

representar esta

divisin,

se utilizar

una

lnea

gruesa

perpendicular a la transicin y las rutas paralelas partirn de ella. Para representar la reincorporacin, ambas rutas apuntarn a otra lnea gruesa.

A continuacin en la figura 2.9 se muestra un ejemplo de lo expuesto anteriormente:

57

Figura 2.9. Representacin de una transicin que se bifurca en dos rutas que se ejecutan de forma concurrente y luego se reincorporan. Fuente: Elaboracin Propia.

Durante una secuencia de actividades, es posible enviar una indicacin. Cuando se reciba, la indicacin provocar que se ejecute una actividad. El smbolo para evitar enviar una indicacin es un pentgono convexo, y el que recibe es un pentgono cncavo. La figura 2.10 es una representacin clara de lo expuesto anteriormente:

Figura 2.10. Representacin del envi de una indicacin y recepcin. Fuente: Elaboracin Propia.

58

En un diagrama de actividades, puede representar las actividades de acuerdo con la responsabilidad asignada. Esto se hara con marcos de responsabilidad, mismos que son segmentos paralelos que corresponden a los responsables de realizar cada tarea.

Tambin es posible combinar al diagrama de actividades con smbolos de otros diagramas con lo que se producirn diagramas hbridos. Por ejemplo tenemos la nota UML.

Es frecuente que alguna parte del diagrama no presente una clara explicacin del porqu est all o la manera en que trabaja. Cuando ste sea el caso, la nota UML ser til. Imagine a una nota como el equivalente grfico de un papel adhesivo. La nota es un rectngulo con una esquina doblada, y dentro del rectngulo se coloca la explicacin. La misma se adjunta al elemento del diagrama conectndolos mediante una lnea discontinua. A continuacin en la figura 2.11 se muestra un ejemplo de una nota UML:

Figura 2.11. Ejemplo de una nota UML. Fuente: Elaboracin Propia.

59

2.2.6.4.

Diagrama de Clases de Anlisis.

Los modelos de clases son una abstraccin de una o varias clases y/o subsistemas del diseo del sistema en un nivel ms alto y menos formal. Siempre encajan en uno de los tres estereotipos bsicos:

Clase de Interfaz: Se utiliza para modelar la interfaz entre el sistema y sus actores. Representan abstracciones de ventanas, formularios, paneles, interfaces de comunicacin, interfaces de impresoras, sensores y terminales. Cada clase de interfaz debera asociarse con al menos un actor, y viceversa.

Se representa mediante la figura 2.12 mostrada a continuacin:

Figura 2.12. Clase de Interfaz Fuente: Elaboracin Propia

Clase de Entidad: Se utilizan para modelar informacin que posee una larga vida y que a menudo es persistente. Modelan la informacin y el comportamiento asociado a algn fenmeno o

60

concepto. Derivan de una clase de entidad del

negocio

correspondiente. Suelen mostrar una estructura de datos lgica y contribuyen a comprender de qu informacin depende el sistema.

Se representa mediante la figura 2.13 mostrada a continuacin:

Figura 2.13. Clase Entidad. Fuente: Elaboracin Propia.

Clase

de

Control:

Representan

coordinacin,

secuencia,

transacciones y control de otros objetos y se usan con frecuencia para encapsular el control de un caso de uso en concreto. Sirven para modelar los aspectos dinmicos del sistema. Se representa mediante la figura N 2.14 mostrada a continuacin:

Figura 2.14. Clase Control. Fuente: Elaboracin Propia.

61

2.2.6.5.

Diagrama de Interaccin.

El trmino diagrama de interaccin es una generalizacin de dos tipos de diagramas UML ms especializados; ambos pueden utilizarse para representar de forma similar interacciones de mensajes:

Diagramas de Colaboracin.

Diagramas de Secuencia.

Los diagramas de colaboracin ilustran las interacciones entre objetos en un formato grafo o red, en el cual los objetos se pueden colocar en cualquier lugar del diagrama, como se muestra en la figura 2.15:

Figura 2.15. Diagrama de Colaboracin. Fuente: Elaboracin Propia.

Los diagramas de secuencia ilustran las interacciones de un tipo de formato con el aspecto de una valla, en el que cada objeto nuevo se aade a la derecha, como se muestra en la figura 2.16:

62

Figura 2.16. Diagrama de Secuencia. Fuente: Elaboracin Propia.

Cada tipo tiene puntos fuertes y dbiles. Cuando se dibujan diagramas para publicarlos en pginas estrechas, los diagramas de colaboracin tienen la ventaja de permitir la expansin vertical para los nuevos objetos; los objetos adicionales en un diagrama de secuencia deben extenderse hacia abajo, lo que supone una limitacin. Por otro lado, los ejemplos de diagramas de colaboracin dificultan que se vea fcilmente la secuencia de mensajes.

La mayora utilizan los diagramas de secuencia cuando utilizan una herramienta CASE para hacer ingeniera inversa del cdigo fuente a diagramas de interaccin, puesto que muestran claramente la secuencia de mensajes. En la tabla 2.1 siguiente se comparan ambos diagramas con sus respectivos puntos fuertes y dbiles:

63

Tabla 2.1. Comparacin de Diagramas de Secuencia y Colaboracin


Tipo Puntos Fuertes
Muestra claramente la secuencia u ordenacin en el tiempo de los mensajes. Notacin simple. Economiza espacio, flexibilidad al aadir nuevos objetos en dos dimensiones. Es mejor para ilustrar bifurcaciones complejas, iteraciones y comportamientos concurrentes.

Puntos Dbiles
Fuerza a entender por la derecha cuando se aaden nuevos objetos; consume espacio horizontal.

Secuencia

Colaboracin

Difcil ver la secuencia de mensajes. Notacin ms compleja.

Fuente: Craig Larman.

Para efectos de este trabajo de grado se eligi el diagrama de colaboracin siendo el adecuado para modelar el sistema de informacin como observarn ms adelante. Por este motivo se profundizara ms en este diagrama.

Un diagrama de objetos muestra a los objetos como tales y sus relaciones entre s. Un diagrama de colaboraciones es una extensin de uno de objetos. Adems de las relaciones entre objetos, el diagrama de colaboraciones muestra los mensajes que se envan los objetos entre s. Por lo general, evitar la multiplicidad dado que podra ser fuente de confusin.

Para representar un mensaje, se dibuja una flecha cerca de la lnea de asociacin entre dos objetos, esta flecha apunta al objeto receptor. El tipo de mensaje se mostrar en una etiqueta cerca de la flecha; por lo general, el mensaje le indicar al objeto receptor que se ejecute una de sus operaciones. El mensaje finalizar con un par de parntesis, dentro de los 64

cuales colocar los parmetros (en caso de haber alguno) con los que funcionar la operacin. Los mensajes deben estar numerados en forma continua y creciente (ejemplo: 1,2,3).

El diagrama de colaboracin utiliza los tres estereotipos bsicos al igual que en el diagrama de clases de anlisis, pero en este diagrama se le consideran objetos en vez de clases, tales como:

Objeto Interfaz.

Objeto de Control.

Objeto Entidad.

2.2.7. Diagrama de Clases de Diseo.

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.

A continuacin se describen un conjunto de definiciones bsicas para este tipo de diagramas:

Atributos: tambin llamados propiedades o caractersticas. Son valores que corresponden a un objeto, como color, material, cantidad, ubicacin. Generalmente se conoce como la informacin 65

detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades seran: la marca, tamao, color y peso.

Operaciones: son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operacin se escribe con minsculas si consta de una sola palabra. Si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Interfaz: es un conjunto de operaciones y/o propiedades que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mnimos del objeto.

Al disear una clase se debe pensar en cmo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se disea. Durante el proceso del diseo de las clases se toman las propiedades que identifican como nico al objeto y otras propiedades adicionales como datos que corresponden al objeto.

En UML, una clase es representada por un rectngulo que posee tres divisiones, como se ve continuacin en la figura N 2.17:

66

Figura 2.17. Representacin de una Clase. Fuente: Elaboracin Propia.

En donde:

Superior: Contiene el nombre de la Clase.

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la clase (pueden ser privado, protegido o pblico).

Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno (dependiendo de la visibilidad: privado, protegido o pblico).

Los atributos o caractersticas y los mtodos u operaciones de una clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:

Pblico (public, +): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

67

Privado (private, -): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar).

Protegido (protected, #): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase, adems de las subclases que se deriven.

Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes, tales como:

Asociacin: Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o n-arias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar el nmero de instancias de una clase que participan en una relacin mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociacin que determina los valores que indican cuales son los valores que se asociarn. Una se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociacin.

68

Esta relacin entre clases, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Se representa mediante la figura N 2.18 a continuacin:

Figura 2.18. Asociacin. Fuente: Elaboracin Propia.

La Dependencia o Instanciacin (uso): una relacin de dependencia se establece ente clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente. Representa un tipo de relacin muy particular, en la que una clase es instanciada (si instanciacin es dependiendo de otro objeto/clase). Se denota por una flecha punteada como se ve en la figura N 2.19 a continuacin:

Figura 2.19. Dependencia. Fuente: Elaboracin Propia.

La herencia: por su parte indica que una subclase hereda los mtodos y atributos especificados por una Superclase, por ende la superclase, adems de poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de la superclase

69

(pblico y protegido). Se representa mediante la figura N 2.20 a continuacin:

Figura 2.20. Herencia. Fuente: Elaboracin Propia.

Composicin: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye (el objeto base se construye a partir del objeto incluido, es decir, es parte/todo). La composicin se destaca por ser representada por un rombo relleno como se ve en la figura N 2.21 a continuacin:

Figura 2.21. Composicin. Fuente: Elaboracin Propia.

Agregacin: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye (el objeto base utiliza al incluido para su funcionamiento). La agregacin se destaca por un rombo transparente, la flecha en este tipo de relacin indica la navegabilidad del objeto

70

referenciado. Cuando no existe este tipo en particularidad la flecha se elimina.

Figura 2.22. Agregacin. Fuente: Elaboracin Propia.

Adems de los mencionados anteriormente existen casos particulares de las clases como:

Clase Abstracta: La cual se denota con el nombre de la clase y de los mtodos con letra itlica. Esto indica que la clase definida no puede ser instanciada debido a que posee mtodos abstractos (an no han sido definidos, es decir, sin implementacin) la nica forma de utilizarla es definiendo subclases, que implementen los mtodos abstractos definidos.

Clase Parametrizada: La cual se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parmetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo ms tpico es el caso de un diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genricos.

71

La cardinalidad de las relaciones, en UML, indica el grado y el nivel de dependencia, se anotan en cada extremo de la relacin y stas pueden ser: Uno es a muchos: 1* (1n). 0 es a muchos: 0*(0n).

Nmero fijo: m (m denota el nmero).

2.2.8. Proceso Unificado de Desarrollo Software.

Aunque UML es bastante independiente del proceso de desarrollo que se siga, los mismos creadores de UML propusieron su propia metodologa de desarrollo, denominada Proceso Unificado de Desarrollo. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos.

En la figura 2.23 se tiene un grfico de RUP, en este grafico se observa los flujos de trabajos de esta metodologa. El Proceso Unificado est basado en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes software interconectados a travs de interfaces bien definidas. El Proceso Unificado utiliza UML para expresar grficamente todos los esquemas de un sistema software.

72

Figura 2.23. RUP: Proceso Unificado de Desarrollo Software. Fuente:http://www.dsi.uclm.es/personal/franciscomsimarro/pfc/pfc07/do c/rosa07.pdf

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

73

2.2.8.1.

Caractersticas del Proceso Unificado.

Iterativo e Incremental:

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Dirigido por los Casos de Uso.

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin y prueba.

74

Centrado en la Arquitectura.

El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

Enfocado en los Riesgos.

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

2.2.9. Nociones de PHP y MySQL en el Desarrollo Web.

2.2.9.1.

Concepto de PHP.

PHP es un lenguaje de secuencia de comandos de servidor diseado especficamente para la web. Dentro de una pgina web se puede incrustar cdigo PHP que se ejecutara cada vez que se visite una pgina. El cdigo PHP es interpretado en el servidor Web y genera cdigo HTML y otro contenido que el visitante vera.

PHP fue concebido en 1994 y es fruto del trabajo de un hombre, Rasmus Lerdorf. Ha sido adoptado por otras personas de talento y ha experimentado cuatro importantes transformaciones hasta convertirse en el 75

producto actual. En agosto de 2004, se encontraba instalado en ms de 17 millones de dominios de todo el mundo y su nmero crece rpidamente.

PHP es un producto de cdigo abierto, lo que quiere decir que se puede acceder a su cdigo. Se puede utilizar, modificar y distribuir sin coste alguno.

Las siglas PHP equivalan inicialmente a Personal Home Page (Pgina de Inicio Personal) pero se modificaron de acuerdo a la convencin de designacin de GNU (DEL INGLES, Gnus Not Unix) y ahora equivale a PHP HIpertext Precessor (Preprocesador de hipertexto PHP).

2.2.9.2.

Concepto de Mysql.

MySQL es un sistema de administracin de base de datos relacionales (RDBMS) rpido y solido. Las bases de datos permiten almacenar, buscar, ordenar y recuperar datos de forma eficiente. El servidor de MySQL controla el acceso a los datos para garantizar el uso simultneo de varios usuarios, para proporcionar acceso a dichos datos y para asegurarse de que solo obtienen acceso a ellos los usuarios con autorizacin. Por lo tanto, MySQL es un servidor multiusuario y de subprocesamiento mltiple. Utiliza SQL (del ingles Structured Query Language o Lenguaje de Consulta Estructurado), el lenguaje estndar para la consulta de bases de datos utilizado en todo el mundo. MySQL lleva disponible desde 1996 pero su nacimiento se remonta a 1979. Ha obtenido el galardn Choice Award del Linux Journal Readers en varias ocasiones.

76

2.2.10. Nociones de Modelos de Inventarios de Mercancas.

Inventario. Es el conjunto de bienes propiedad de una empresa que han sido adquiridos con el nimo de volverlos a vender en el mismo estado en que fueron comprados, o para ser transformados en otro tipo de bienes y vendidos como tales.

Las empresas dedicadas a la compra y venta de mercancas, por ser esta su principal funcin y la que dar origen a todas las restantes operaciones, necesitaran de una constante informacin resumida y analizada sobre sus inventarios, lo cual obliga a la apertura de una serie de cuentas principales y auxiliares relacionadas con esos controles. Entres estas cuentas podemos nombrar las siguientes:

Inventario (inicial).

Compras.

Devoluciones en compra.

Gastos de compras.

Ventas.

Devoluciones en ventas.

77

Mercancas en trnsito.

Inventario (final).

El Inventario Inicial representa el valor de las existencias de mercancas en la fecha que comenz el periodo contable. Esta cuenta se abre cuando el control de los inventarios, en el Mayor General, se lleva en base al mtodo especulativo, y no vuelve a tener movimiento hasta finalizar el periodo contable cuando se cerrar con cargo a costo de ventas o bien por Ganancias y Prdidas directamente.

En la cuenta Compras se incluyen las mercancas compradas durante el periodo contable con el objeto de volver a venderlas con fines de lucro y que forman parte del objeto para el cual fue creada la empresa. No se incluyen en esta cuenta la compra de Terrenos, Maquinarias, Edificios, Equipos, Instalaciones, etc. Esta cuenta tiene un saldo deudor, no entra en el balance general de la empresa, y se cierra por Ganancias y Prdidas o Costo de Ventas.

Devoluciones en compra, se refiere a la cuenta que es creada con el fin de reflejar toda aquella mercanca comprada que la empresa devuelve por cualquier circunstancia; aunque esta cuenta disminuir la compra de mercancas no se abonar a la cuenta compras.

Los gastos ocasionados por las compras de mercancas deben dirigirse a la cuenta titulada: Gastos de Compras. Esta cuenta tiene un saldo deudor y no entra en el Balance General.

78

La cuenta Ventas controlar todas las ventas de mercancas realizadas por la Empresa y que fueron compradas con este fin. Por otro lado tambin se tienen las Devoluciones en Venta, la cual est creada para reflejar las devoluciones realizadas por los clientes a la empresa.

En algunas oportunidades, especialmente si la empresa realiza compras en el exterior, se cuenta con que se han efectuado ciertos desembolsos o adquirido compromisos de pago ( documentos o giros) por mercancas que la empresa compr pero que, por razones de distancia o cualquier otra circunstancia, aun no han sido recibidas en el almacn. Para contabilizar este tipo de operaciones se debe utilizar la cuenta: Mercancas en Trnsito.

El Inventario Actual (Final) se realiza al finalizar el periodo contable y corresponde al inventario fsico de la mercanca de la empresa y su correspondiente valoracin. Al relacionar este inventario con el inicial, con las compras y ventas netas del periodo se obtendr las Ganancias o Prdidas Brutas en Ventas de ese perodo.

Los inventarios sirven para cinco propsitos principales:

1. Permite desarrollar y alcanzar economas a escala.

2. Balance del suministro y la demanda.

3. Permite la especializacin en la manufactura.

4. Proporciona proteccin a la incertidumbre.

79

5. Acta como amortiguador en interfaces criticas en la cadena de abastecimiento.

2.2.10.1. Trminos Asociados a los Inventarios.

Demanda.

Este trmino est definido como la cantidad de bienes que los consumidores estn dispuestos a adquirir a un precio y cantidad dato en un tiempo determinado.

Punto de Reorden.

Es el nivel de inventario que indica el momento en que debe hacerse un pedido.

Tamao de Lote.

Es un grupo de artculos idnticos que se renen por conveniencia para pedirlos o fabricarlos a un costo mnimo.

Inventario de Seguridad.

Es el inventario que sirve de amortiguador para satisfacer la demanda si sta aumenta de forma repentina.

80

Tiempo de Entrega.

Es el tiempo que transcurre entre la emisin de un pedido y la recepcin del mismo.

Nivel de servicio.

Es la probabilidad de tener el inventario suficiente como para responder a un pedido.

Costo unitario del artculo.

Es el costo derivado de comprar o producir los artculos individuales de inventarios. Su unidad de medida es ($/unidad).

Costos de ordenar o pedir.

Es el costo relacionado a la adquisicin de un grupo o lote de artculos, tambin se dice que es el costo de las acciones necesaria para realizar una nueva compra. Este costo de pedir no depende del nmero de artculos que tenga el lote respectivo, sino que est asociado a las

actividades de hacer el pedido si es desde el punto de vista de comprar, o de los costos de transformar el sistema (costos de set up) y adecuarlo a la fabricacin de un nuevo lote o corrida de produccin. Su unidad de

medida es ($/orden).

81

Costos de mantener o poseer inventarios.

Este costo est asociado a la permanencia

del artculo durante un

perodo de tiempo. Su valoracin se determina en funcin del tiempo almacenado y del valor del bien involucrado.

Costos de inexistencia.

Son los costos que reflejan las consecuencias de quedarse sin material en un determinado momento.

2.2.10.2. Polticas de inventario.

La Poltica de Inventario se refiere a la Revisin y Disciplina utilizada para ordenar y controlar los inventarios.

La poltica de Inventario trata de responder a las siguientes interrogantes: o Cundo debe ser emitida la orden? o Cunto se debe comprare (tamao del lote)?

Existen dos tipos de Polticas de Revisin de Inventarios: Poltica de Revisin Peridica y Poltica de Revisin Continua.

82

Poltica de Revisin Peridica.

Bajo esta poltica, los Niveles de Inventario son monitoreados a intervalos de tiempo T, donde T es la longitud de tiempo determinada segn sea el criterio ordenado. La cantidad a ordenar est dada en funcin de cmo sean las decisiones de reposicin.

Poltica de Revisin Continua.

Bajo esta poltica, el monitoreo del inventario es permanente y una vez que se alcanza el punto de reorden r es emitida una orden de compra. El punto r se determina en funcin de un nivel de seguridad aceptado y en funcin de la cantidad consumida durante el tiempo que demora en obtenerse la reposicin

83

CAPITULO III - MARCO METODOLGICO


3.1. TIPOS DE INVESTIGACIN.

Existen muchos modelos y formas de clasificarlos. Sin embargo, lo importante es precisar los criterios de clasificacin.

En este sentido se identifican:

Tipos de investigacin segn el Nivel.

Tipos de investigacin segn el Diseo.

Tipos de investigacin segn el Propsito.

Sin embargo, independientemente de su clasificacin, todos son tipos de investigacin, y al no ser excluyentes, un estudio puede ubicarse en ms de una clase.

3.2.

NIVEL DE LA INVESTIGACIN.

El nivel de investigacin de este proyecto es del tipo Descriptivo.

La investigacin descriptiva consiste en la caracterizacin de un hecho, fenmeno, individuo o grupo, con el fin de establecer su estructura o comportamiento. Los resultados de este tipo de investigacin se ubican en un nivel intermedio en cuanto a la profundidad de los conocimientos se refiere.

84

3.3.

DISEO DE LA INVESTIGACIN.

El diseo de investigacin de este proyecto es de Campo.

La investigacin de campo es aquella que consiste en la recoleccin de datos directamente de los sujetos investigados, o de la realidad donde ocurren los hechos (datos primarios), sin manipular o controlar variable alguna, es decir, el investigador obtiene informacin pero no altera las condiciones existentes.

3.4.

TCNICAS A UTILIZAR.

Como el diseo de esta investigacin es de Campo, las tcnicas a utilizar son las siguientes:

La observacin: Es una tcnica que consiste en visualizar o captar mediante la vista, en forma sistemtica, cualquier hecho, fenmeno o situacin que se produzca en la naturaleza o en la sociedad, en funcin de unos objetivos de investigacin preestablecidos.

La observacin puede ser estructurada o no estructurada: o Estructurada: correspondencia

Es

aquella unos

que

adems

de

realizarse gua

en

con

objetivos,

utiliza

diseada

previamente, en la que se especifican los elementos que sern observados.

85

o No Estructurada: Es la que se efecta en funcin de un objeto, pero sin gua prediseada que especifique cada uno de los aspectos que deben ser observados.

La encuesta: Se define como una tcnica que pretende obtener informacin que suministra un grupo o muestra de sujetos acerca de si mismos, o en relacin con un tema en particular.

La encuesta realizada fue de tipo oral: o Encuesta Oral: Esta se fundamenta en un interrogatorio cara a cara o por va telefnica, en el cual el encuestador pregunta y el encuestado responde. Se realizan pocas y breves preguntas.

La entrevista: Ms que un simple interrogatorio, es una tcnica basada en un dialogo o conversacin cara a cara, entre el entrevistador y el entrevistado acerca de un tema previamente determinado.

La entrevista se realizo de forma no estructurada: o Entrevista no estructurada o informal: En esta modalidad no se dispone de una gua de preguntas elaboradas previamente.

Proceso Unificado de Desarrollo de Software:

El Proceso Racional Unificado (Rational Unified Process), habitualmente resumido como RUP es un proceso de desarrollo de software y, junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar

86

ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin.

El Proceso Unificado posee tres paradigmas que lo identifican y particularizan de forma nica, estos son: o Dirigido por Casos de Uso. o Centrado en la Arquitectura. o Iterativo e Incremental.

87

CAPITULO IV RESULTADOS
4.1. FASE DE INICIO

4.1.1. Resumen.

La principal meta de esta fase es la del arranque del proyecto en s. Todos y cada uno de los anlisis pertinentes, de la informacin recaba, tienen lugar al comienzo de sta etapa para poder obtener los requerimientos necesarios que permitan, debido a lo expuesto en el planteamiento del problema al inicio de este proyecto, justificar el desarrollo del sistema, que luego se complementar en la fase de elaboracin.

Se inicia con la observacin y estudio del entorno actual en donde se evaluar el mbito y alcance del sistema, seguidamente se elaborarn los modelos iniciales o versiones que permitirn estructurar el cuerpo o arquitectura del sistema.

Se trabajarn con los flujos de trabajo de requisitos el cual es el que soporta el peso mximo en esta etapa, tal como se muestra en la figura 4.1 de las fases y flujos del proceso unificado. Se observarn los requisitos funcionales mediante la identificacin y estudio de los actores y casos de uso, as como tambin aquellos requisitos no funcionales que completarn la arquitectura base del sistema. Todo ello ayudar a identificar los factores de riesgo y permitir pasar al anlisis con los datos obtenidos de los casos de uso aplicando los diagramas de clase de anlisis y de colaboracin.

88

Figura 4.1. Fases y Flujos de Trabajo del Proceso Unificado (inicio). Fuente: Elaboracin Propia.

4.1.2. Requisitos del sistema.

Esta parte del flujo de trabajo de la metodologa usada es de vital importancia ya que va a guiar el desarrollo del proyecto hacia el sistema que se est trabajando. Es aqu cuando todos los mtodos de empleo cumplen su funcin de una manera correcta y se logra obtener la arquitectura base del sistema.

Para lograr estos objetivos, es necesario que se conozcan las caractersticas del sistema, los procesos que se den cumplir y las necesidades a satisfacer. Esto se logra con el reconocimiento e identificacin correcta de los requisitos, as como tambin la diferenciacin de aquellos requisitos ambiguos e incompletos de los funcionales y no funcionales. De

89

esta manera se podr obtener en resultado un funcionamiento ptimo del sistema en el que se est creando el proyecto.

4.1.2.1.

Contexto del sistema.

El contexto de este sistema inicia con la descripcin de las tareas y procesos en el manejo de la mercanca importada o en almacn que posee la empresa Diesel Oriente C.A. La informacin ha sido recabada por los mtodos y tcnicas de recoleccin de datos antes expuestos como las entrevistas, no estructuradas, realizadas con el personal directivo de la compaa e integrantes del personal que labora en la organizacin. Todo ello permite la familiarizacin con el sistema, sus caractersticas y necesidades.

La informacin encontrada de un profundo anlisis de las actividades y procesos que ocurren en la empresa para el manejo de su mercanca, se divide y resume de la siguiente manera:

Registro y Codificacin de Mercanca Ingresada: Al momento de la importacin de una pieza, o el ingreso por compra, sta se registra en la compaa bajo una codificacin y datos de la empresa desde donde proviene el repuesto as como tambin todas las caractersticas de la pieza adquirida. A partir de este momento se almacena y se realiza un proceso de conteo del inventario actual de la compaa.

Ajuste del Precio a Moneda Nacional: Se realiza el ajuste del precio de cada repuesto de moneda extranjera a moneda nacional de acuerdo al tipo de cambo vigente y la actualizacin de los precios de piezas ya en almacn en concordancia de cualquier ajuste inflacionario o alza del Dlar o Euro que exista. 90

Verificacin de Inventario en Existencia: Cada cierto perodo de tiempo la compaa realiza un inventario de verificacin de la cantidad de mercanca que posee, para de esta manera controlar el nmero de repuestos o piezas que se van a adquirir.

Como se ha dicho en la exposicin del problema que conlleva a la realizacin de este proyecto, los procesos se realizan de manera manual lo cual desemboca a un trmite tedioso e inclusive prdida de tiempo valioso para la compaa. Adicionalmente, el uso de este tipo de control de informacin ocasiona que el ajuste de los precios, ya sea por cualquier tipo de cambio inflacionario o del dlar, tenga que ser realizado a cada pieza por separado y a travs de clculos manuales que repercuten en los inconvenientes antes mencionados de tiempo y trabajo.

Es por ello que el proyecto prev resolver estos inconvenientes que generan los procedimientos manuales, para as poder agilizar el tiempo de accin y respuesta del trabajo realizado en la empresa.

4.1.2.2.

Modelo de Dominio.

Es el comienzo de diseo del sistema para entender y expresar el contexto del mismo, es construido bajo las normas de UML, donde se describen los casos o eventos que suceden en el entorno donde va a trabajar el sistema. ste se presenta como uno o ms diagramas de clase que contienen no conceptos propios de un sistema de software sino de la propia realidad fsica.

91

El modelo de dominio de sistema del sistema actual, se puede observar a travs de la figura 4.2, en este modelo se presenta un diagrama de clase representando las entidades que existen en el sistema. Se puede ver el elemento Diesel Oriente C.A. que es el nombre de la empresa donde se est estudiando el sistema actual, encargado del proceso de manejo del inventario y costo de los equipos que se encuentran en la compaa. Se expresan las entidades Administrador, Empleados, que pertenecen a Diesel Oriente C.A. y son los encargados de realizar todas las actividad es referentes al manejo de los equipos dentro del sistema en estudio. La entidad Administrador est relacionada con las entidades Reportes y Hoja de Clculo, ya que a travs de ellas se lleva el control de los precios de los equipos en inventario, as como tambin se obtienen los informes de los equipos en existencia y aquellos que han salido del inventario previamente. La entidad Empleados est relacionada con las entidades Clientes e Inventarios ya que ellos se encargan del control de los productos que se encuentran en la empresa y el manejo de la informacin de los clientes de la compaa.

Figura 4.2. Modelo de Dominio del Sistema Actual. Fuente: Elaboracin Propia.

92

4.1.2.3.

Glosario de trminos.

Es un catlogo de trminos generales que facilitan la comprensin de aquellos trminos poco conocidos, generalmente contienen los trminos ms utilizados.

En la tabla 4.1 se muestra el glosario de trminos del sistema, incluye todos los trminos que deben ser explicados para mejorar la comunicacin entre los usuarios y el desarrollo del sistema.

Tabla 4.1. Glosario de trminos (1/2). Trminos SIMIC Descripcin Sistema de Informacin para el Manejo de Inventarios y Costos. Es el sistema propuesto para la automatizacin de las actividades de manejo y control de inventarios y costos. Diesel Oriente La Compaa donde se encuentra el sistema actual. C.A. Administrador Se encarga de la configuracin del sistema. Empleados Conjunto de personas que trabajan en la empresa Diesel Oriente C.A. que se encargan del manejo y distribucin de la informacin. Clientes Son empresas o particulares que adquirirn los productos comercializados por la empresa y de los cuales se tendr un control. Fuente: Elaboracin Propia.

93

Tabla 4.1. Glosario de trminos (2/2). Trminos Inventarios Descripcin Proceso manual de las cantidades de cada uno de los productos encontrados en la empresa. Reportes Son informes clasificados por

periodos de tiempo de los productos y mercancas del inventario segn su status: por Asignacin, Devolucin o Desincorporacin. Hoja de calculo Proceso manual por el cual se calculan el IVA y Dlar para los precios de cada uno de los productos existentes en la compaa. Fuente: Elaboracin Propia.

4.1.2.4.

Requerimientos Candidatos o Funcionales del Sistema.

El sistema debe permitir el acceso solo a los usuarios que estn definidos en el sistema.

Solo podr agregar, modificar y eliminar usuarios en el sistema, la persona previamente autorizada por el administrador del mismo.

El sistema debe permitir visualizar la informacin de los equipos de la compaa.

94

El sistema debe emitir reportes de: Asignacin, Desincorporacin y Devolucin de los activos de la empresa.

El sistema debe incluir el respaldo y recuperacin de los datos y slo puede ser realizado por el administrador del sistema.

4.1.2.5.

Requisitos No Funcionales del Sistema.

Estos requisitos especifican las propiedades del sistema, restricciones, rendimiento, mantenimiento, extensibilidad o fiabilidad.

Se puede entender que dicho requisito no pueden asociarse a ningn caso de uso especifico o determinado, sin embargo cada uno de ellos tienen impacto sobre varios casos de uso o ninguno. Por esta razn tambin son importantes al momento del conocimiento y anlisis de un sistema.

En la tabla 4.2 se representan los requisitos no funcionales:

Tabla 4.2. Requisitos No Funcionales (1/2). REQUISITOS Extensible DESCRIPCION El software debe permitir la incorporacin de nuevas funcionalidades en su estructura. Debe estar apto para el ingreso de futuras ampliaciones y el soporte de mayor cantidad de datos a travs del tiempo. Mantenible El software diseado debe permitir el mantenimiento y ampliacin de la funcionalidad del sistema. Fuente: Elaboracin propia.

95

Tabla 4.2. Requisitos No Funcionales (2/2). REQUISITOS Transparencia DESCRIPCION Que sea accesible a una revisin por alguien distinto a quien lo ha creado. Que la documentacin del sistema sea clara. Amigable El diseo de la interfaz del usuario debe poseer una estructura amigable para que resulte de fcil

entendimiento para los usuarios. Accesible La base de datos debe estar ubicada en un servidor en el cual se puedan acceder los datos a travs de la red de rea local. Seguridad Proporcionar la seguridad necesaria de los datos manejados. Preventivo Debe emitir avisos que indiquen cualquier tipo de cambios realizados a los datos del sistema. Eficiencia Agilizar los procesos cotidianos para lograr aumentar la productividad en el trabajo realizado, y disminuir los tiempo de ocio ocasionados por el retardo en la respuesta del sistema actual. Fuente: Elaboracin propia.

96

4.1.2.6.

Identificacin de Riesgos.

En el proceso unificado es vital reconocer los riesgos ms importantes o crticos en la fase de inicio y en la fase de elaboracin, esto garantiza acabar con los mismos en una etapa temprana del proyecto.

Para la identificacin de los riesgos, se accedi a los medios usados anteriormente como el acceso a informacin impresa suministrada por la empresa, tcnicas de recoleccin de datos a travs de entrevistas no estructuradas, lo que se obtuvo como resultado una recopilacin de datos suficientes para as identificar los posibles riesgos.

En base a que el desarrollo del proyecto se hizo bajo el proceso unificado, cuyos aspectos estn dirigidos por casos de uso, el cual se centran en la arquitectura, en ser iterativo e incremental. Por medio de ello se identificaron los siguientes riesgos:

Que el usuario no pueda acceder a todas las reas destinadas para l o que exceda el acceso a las mismas, interfiriendo con informacin que no le corresponde, riesgo que es considerable pues, cada usuario debe tener accesibilidad plena a la aplicacin, por ello se establecen niveles de acceso entre usuarios y los diferentes puntos de acceso a una misma informacin.

Violacin del sistema al momento visualizar la informacin no autorizada al usuario que haya ingresado al sistema, es por esto que se establece el uso de contrasea y nombres de usuario para ingresar de manera correcta.

97

El tamao de la plataforma disponible actualmente para albergar la base datos, ya que sta en futuras ampliaciones del sistema puede no soportar la cantidad de informacin que se le ingrese. Es por ello que la plataforma debe ser lo suficientemente grande para soportar posteriores ampliaciones y datos de equipos y actividades en la compaa.

Teniendo en cuenta los riegos identificados, se desarrollarn los casos de usos y los diagramas UML necesarios para llegar a un balance entre los requisitos del sistema y las condiciones que deben cumplir, para as eliminar o disminuir los riesgos.

4.1.2.7.

Identificacin de los Actores del Sistema.

El contexto del sistema, luego de ser analizado, permite, entonces, identificar los actores del sistema. Los actores son personas, sistemas o hardware que interactan con el sistema, quienes hacen uso de la funcionalidad de la misma o aportan funcionalidad, por lo tanto pueden obtener o ingresar informacin. Un sistema externo tambin es considerado un actor que acta con el sistema. Bsicamente los actores son los terceros que interactan con el sistema y los casos de uso definen la forma en la que ellos van a ser utilizados.

En la tabla 4.4 se muestran los actores del sistema y sus funciones:

98

Tabla 4.3. Actores del Sistema.

ACTOR
Supervisor Soporte Integral

FUNCIONES
Es el encargado de recibir e ingresar los equipos nuevos, anexando los datos de stos en el sistema. Su funcin va orientada a la supervisin de las actividades realizadas para el control del inventario y costo. Su funcin es realizar consultas de los procesos nombrados anteriormente y generar reportes de dichas consultas como asignacin, devolucin y desincorporacin de los activos. Es el encargado de la configuracin de los usuarios y de sistema y de realizar las actualizaciones necesarias para que el sistema tenga un buen funcionamiento. El administrador tiene la responsabilidad de respaldar los datos almacenados en el sistema y adems servir de soporte, previo pedido de algn usuario, de todos los mdulos del sistema para agilizar las actividades correspondientes. Son todo aquellos que intervienen en el proceso de distribucin de informacin. Los empleados encuentran un beneficio del sistema, ya que es un medio de apoyo para la realizacin de las actividades. Los empleados pueden acceder al sistema con dos fines: el de Gestionar informacin importante de los clientes y el de Generar reportes principales para el control del inventario. Fuente: Elaboracin Propia.

Analista de Soporte Integral

Administrador del Sistema

Empleados del Sistema

4.1.2.8.

Identificacin de los Casos de Uso.

Un caso de uso es un modo de utilizar el sistema, si se sabe describir todos los casos de uso, se sabr lo que debe hacer el sistema.

99

En el modelo de caso de uso del sistema SIMIC se podr observar su descripcin en la tabla 4.5 donde se muestran los casos de uso, sus descripciones y actores.

Tabla 4.4. Identificacin de los casos de uso (1/2). CASO DE USO Accesar al Sistema La DESCRIPCION pieza y fundamental dinamismo de que ACTORES Supervisor Soporte Integral. Analista Integral. Administrador del sistema. Empleados. Soporte

seguridad

posee el sistema. Las claves de seguridad que debe poseer cada usuario tienen diferentes niveles de acceso basado en esto, le permitir o limitara desarrollar distintas funciones en el sistema. Procesar Inventario y Costo Se realizan las operaciones de ingreso de los equipos nuevos y llevar la administracin de

Supervisor Soporte Integral. Analista Integral. Administrador del Sistema. Soporte

aquellos equipos existentes. En este proceso tambin se realiza las operaciones de de precios la de

actualizacin

acuerdo a su equivalente en moneda extranjera o algn

cambio inflacionario existente. Fuente: Elaboracin Propia.

100

Tabla 4.4. Identificacin de los casos de uso (2/2). CASO DE USO Realizar Configuracin DESCRIPCION Permite usuarios acceso configurar que al los ACTORES Administrador del sistema.

tienen sistema.

Realiza el mantenimiento del sistema por medio del respaldo y recuperacin de la base de datos para su funcionamiento. Gestionar Clientes Permite llevar un control de los clientes fijos de la empresa. Generar Reportes Permite obtener Administrador del sistema. Empleados. Administrador del sistema. Empleados. correcto

informacin de repuestos segn su status en el inventario.

Fuente: Elaboracin Propia.

A continuacin en la Figura 4.3 se muestra el caso de uso general del sistema de informacin para el manejo de inventarios y costos (SIMIC), donde se muestra en detalle lo expuesto en las tablas anteriores sobre cada caso de uso general, los actores que intervienen y las relaciones que existen entre cada uno de ellos.

101

Figura 4.3. Modelo de Caso de Uso General S.I.M.I.C.. Fuente: Elaboracin Propia.

102

Descripcin del Caso de Uso Accesar al Sistema.

Figura 4.4. Caso de Uso Accesar al Sistema. Fuente: Elaboracin Propia.

Nombre del Caso de Uso: Accesar al Sistema. Actores: Supervisor Soporte Integral, Analista Soporte Integral,

Administrador del Sistema, Empleados del Sistema. Descripcin: Permite a los usuarios ingresar a la interfaz principal del SIMIC con el propsito de ingresar al sistema y gestionar, de acuerdo a su nivel de acceso, la informacin generada en la empresa con respecto al inventario de mercanca que se maneja. Pre-Condicin: El actor solicita el acceso al sistema, se identifica y cumple con los parmetros de seguridad necesarios.

103

Tabla 4.5. Flujo de eventos del Caso de Uso Accesar al Sistema. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor solicita el acceso al 2. Muestra una interfaz inicial, sistema. donde se pide colocar en los campos indicados el nombre del usuario y su contrasea. 3. El actor ingresa los datos 4. Se procesan los datos. solicitados. 5. Si los datos ingresados son validos, se autoriza el acceso al sistema, y se muestra una interfaz de entrada principal. 6. Finaliza el caso de uso Caminos Alternativos Paso 3. El Actor cancela la operacin. Paso 5. Los datos ingresados no son validos, se muestra una notificacin y finaliza el caso de uso. Fuente: Elaboracin Propia.

Figura 4.5. Diagrama de Estado del Caso de Uso Accesar al Sistema. Fuente: Elaboracin Propia.

104

Descripcin del Caso de Uso Procesar Inventario y Costo.

Figura 4.6. Caso de Uso Procesar Inventario y Costo. Fuente: Elaboracin Propia.

Nombre del Caso de Uso: Procesar Inventario y Costo. Actores: Supervisor Soporte Integral, Analista Soporte Integral,

Administrador del Sistema. Descripcin: Le permite al usuario ingresar los equipos nuevos al sistema y llevar la administracin de los activos existentes en el inventario. Pre-Condicin: El actor deber pulsar la opcin Procesar Inventario del men principal.

105

Tabla 4.6. Flujo de eventos del Caso de Uso Procesar Inventario y Costo. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor selecciona la opcin 2. El Sistema muestra un men Procesar Inventario y Costo con cuatro casillas Procesar del men Principal. Equipos y Costos, Asignacin, Devolucin y Desincorporacin. 3. El actor selecciona la opcin que 4. Se procesa la opcin desee ejecutar. seleccionada por el usuario. 5. Finaliza el caso de uso. Caminos Alternativos Paso 1. El Actor selecciona otra opcin. Paso 3. El actor no realiza ninguna seleccin y vuelve al men principal. Fuente: Elaboracin Propia.

Figura 4.7. Diagrama de Estado del Caso de Uso Procesar Inventario y Costo. Fuente: Elaboracin Propia.

106

Nombre de Caso de Uso: Procesar Equipo y Costos. Actores: Supervisor Soporte Integral, Administrador del Sistema. Descripcin: Se procesa toda la informacin de los equipos registrados en el sistema, editar o eliminar sus datos, as como tambin sus costos, sus existencias y la opcin para agregar nuevos elementos al inventario. Pre-Condicin: El actor selecciona la opcin Procesar Equipos y Costos del Men Procesar Inventario y Costo.

Tabla 4.7. Flujo de Eventos del Caso de Uso Procesar Equipos y Costos Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema visualiza una lista opcin Equipos y Costos del de los equipos en inventario y men Procesar Inventario y los botones para: Agregar, Costo. Modificar y Eliminar un equipo y editar su existencia y costo asociado 3. El actor selecciona la accin e 4. El sistema procesa y guarda introduce datos de ser los datos del equipo en la necesario. base datos y muestra confirmacin. 5. Finaliza el caso de uso Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor cancela la operacin y vuelve al men anterior. Paso 4. El equipo ingresado ya existe o datos invlidos, no se guardan los datos y se muestra una confirmacin. Fuente: Elaboracin Propia.

107

Figura 4.8. Diagrama de Estado del Caso de Uso Equipos y Costos. Fuente: Elaboracin Propia.

Nombre de Caso de Uso: Asignacin. Actores: Analista Soporte Integral, Administrador del Sistema. Descripcin: Permite al usuario asignar un equipo solicitado por el cliente.

Pre-Condicin: El actor selecciona la opcin Asignacin del Men Procesar Inventario y Costo.

108

Tabla 4.8. Flujo de Eventos del Caso de Uso Asignacin Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema visualiza botn de opcin Asignacin del men bsqueda de los clientes en el Procesar Inventario y Costo. sistema. Casillas para los datos del cliente elegido. Seleccin de fecha y botn para agregar los equipos de la asignacin y monto total. 3. El actor pulsa el botn Buscar. 4. El sistema visualiza una lista de todos los clientes disponibles. 5. El actor selecciona 6. El sistema Visualiza a un cliente cdula/RIF y nombre del cliente seleccionado. 7. El actor selecciona la fecha 8. El sistema visualiza una lista Y presiona el botn agregar de los equipos en inventario y los botones de seleccin. 9. El actor selecciona el o los 10. Visualizar una lista de los Equipos a asignar. equipos agregados y la casilla Monto contendr el total de los precios de los equipos. 11. El actor pulsa el botn de 12. El sistema guarda la Grabar la asignacin. asignacin. 13. Finaliza el Caso de Uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor no realiza ninguna accin y vuelve al men anterior. Fuente: Elaboracin Propia

109

Figura 4.9. Diagrama de Estado del Caso de Uso Asignacin Fuente: Elaboracin Propia.

Nombre de Caso de Uso: Devolucin. Actores: Analista Soporte Integral, Administrador del Sistema.

110

Descripcin: Permite al usuario registrar las devoluciones realizadas sobre equipos ya asignados previamente. Pre-Condicin: El actor selecciona la opcin Devolucin del Men Procesar Inventario y Costo.

Tabla 4.9. Flujo de Eventos del Caso de Uso Devolucin. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra una opcin Devolucin del men interfaz donde se despliega Procesar Inventario y Costo. las listas de todas las asignaciones realizadas actualmente. Opciones de bsqueda y botn para agregar la devolucin. 3. El actor busca o selecciona la 4. El sistema muestra las asignacin especfica y especificaciones de la presiona el botn de asignacin, cliente y equipos devolucin. adquiridos. 5. El actor debe tildar el motivo 6. El sistema procesa la accin a de la devolucin, as como la ejecutar y realiza la cantidad de equipos a devolucin solicitada. devolver. Y presiona el botn Grabar. 7. Finaliza el caso de uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor no realiza ninguna accin y vuelve al men anterior. Paso 6. El actor cancela las opciones y el proceso no se guarda. Paso 7. Datos invlidos se muestra una notificacin de error y se reinicia la operacin. Fuente: Elaboracin Propia

111

Figura 4.10. Diagrama de Estado del Caso de Uso Devolucin de Equipos. Fuente: Elaboracin Propia.

Nombre de Caso de Uso: Desincorporacin. Actores: Analista Soporte Integral, Administrador del Sistema. Descripcin: Permite al usuario desincorporar o descargar del inventario un equipo que no tenga vida til o que no est apto para su asignacin o venta

112

debido a este daado, obsoleto o presente cualquier anomala en su funcionamiento. Estos equipos son sacados del inventario para su posterior reparacin o cambio y son registrados para seguir un control que sern visualizados con reportes o informes del motivo por el cual fueron descargados del sistema. Pre-Condicin: El actor selecciona la opcin Desincorporacin del Men Procesar Inventario y Costo.

Tabla 4.10. Flujo de Eventos del Caso de Uso Desincorporacin. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema visualiza una lista opcin Desincorporacin del de los equipos en inventario y men Procesar Inventario y el botn para descargo. Costo. 3. El actor pulsa Botn 4. El sistema visualiza nombre De descargo del equipo del equipo, Cantidad en existencia y las casillas para ingresar cantidad de descargo y motivo y los botones de aceptar o cancelar la operacin. 5. El actor introduce la cantidad 6. El sistema procesa los datos De descargo y motivo y del descargo, guarda el Pulsa el botn de aceptar. descargo y muestra una confirmacin. 7. Finaliza el caso de uso Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor no realiza ningn ingreso y vuelve al men anterior. Paso 5. Datos invlidos se muestra una notificacin de error y se reinicia la operacin. Paso 7. El actor cancela las opciones y el proceso no se guarda. Fuente: Elaboracin Propia

113

Figura 4.11. Diagrama de Estado del Caso de Uso Desincorporacin. Fuente: Elaboracin Propia.

114

Descripcin del Caso de Uso Realizar Configuracin.

Figura 4.12. Caso de Uso Realizar Configuracin. Fuente: Elaboracin Propia.

Nombre del Caso de Uso: Realizar Configuracin. Actores: Administrador del Sistema. Descripcin: El actor realiza actividades de mantenimiento y seguridad en el sistema, controlando la administracin de los usuario, Ajustar los parmetros de los precios, Respaldo y Recuperacin de los datos almacenados. Pre-Condicin: El actor selecciona la opcin Realizar Configuracin del men principal.

115

Tabla 4.11. Flujo de Eventos del Caso de Uso Realizar Configuracin Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra un men opcin Realizar con las opciones Controlar Configuracin del men Usuarios, Respaldo de principal. Datos y Recuperar Datos. 3. El actor selecciona una de las 4. Se procesa la opcin opciones del men. seleccionada por el usuario. 5. Finaliza el caso de uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor vuelve al men principal. Fuente: Elaboracin Propia.

Figura 4.13. Diagrama de Estado del Caso de Uso Realizar Configuracin. Fuente: Elaboracin Propia.

116

Nombre del Caso de Uso: Controlar usuarios. Actores: Administrador del Sistema. Descripcin: El actor realiza actividades de administracin de los usuarios del sistema, con la posibilidad de agregar, modificar, eliminar usuarios, darle un tipo y un determinado nivel de acceso. Pre-Condicin: El actor selecciona la opcin Controlar Usuarios del men Realizar Configuracin.

Tabla 4.12. Flujo de Eventos del Caso de Uso Controlar Usuarios. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra una lista opcin Controlar Usuarios con todos y cada uno de los del men Realizar usuarios del sistema, paneles Configuracin. de bsqueda personalizada para uno usuario o grupo de usuarios en especifico y los botones para agregar, modificar y eliminar usuarios determinados. 3. El actor pulsa un botn de 4. El sistema procesa la opcin accin, introduce datos de ser solicitada, los datos necesario y guarda la accin. ingresados y guarda las acciones ejecutadas. 5. Termina el caso de uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor vuelve al men principal. Fuente: Elaboracin Propia.

117

Figura 4.14. Diagrama de Estado del Caso de Uso Controlar Usuarios. Fuente: Elaboracin Propia.

Nombre de Caso de Uso: Ajustar de Precio. Actores: Supervisor Soporte Integral, Analista Soporte Integral,

Administrador del Sistema. Descripcin: Permite al usuario cambiar los parmetros de costos del producto: Dlar e IVA. Pre-Condicin: El actor selecciona la opcin Ajustar Precio del Men Realizar Configuracin.

118

Tabla 4.13. Flujo de Eventos del Caso de Uso Ajustar Precio. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema Visualiza los opcin Ajustar Precio del parmetros actuales de Dlar men Realizar e IVA, y las casillas para Configuracin. introducir los nuevos valores. 3. El actor Introduce los Nuevos 4. Procesa los datos valores y pulsa Aceptar introducidos por el usuario, y ajustar los precios de los productos en inventario. 5. El sistema actualiza los parmetros de los precios ajustados 6. Fin del caso de uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor no realiza ningn ingreso y vuelve al men anterior. Fuente: Elaboracin Propia

Figura 4.15. Diagrama de Estado del Caso de Uso Ajustar Costo. Fuente: Elaboracin Propia.

119

Nombre del Caso de Uso: Respaldo de Datos. Actores: Administrador del Sistema, Sistema de Base de Datos (BDD). Descripcin: Se encarga de crear una copia de datos de toda la base de datos para almacenarla en una ubicacin segura, como el disco duro, en un servidor de archivos o en algn dispositivo externo de almacenamiento. Pre-Condicin: El actor selecciona la opcin Respaldo de Datos del men Realizar Configuracin.

Tabla 4.14. Flujo de Eventos del Caso de Uso Respaldo de Datos. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema le solicita al usuario opcin Respaldo de Datos un directorio de destino para del men Realizar guardar la copia de la base de Configuracin. datos. 3. El actor proporciona el destino 4. El sistema procesa la solicitado para almacenar los direccin y lleva a cabo el datos de la base de datos a respaldo de los datos al respaldar y se acepta para dar directorio indicado. inicio al respaldo. 5. El sistema muestra un mensaje indicando el resultado de la operacin. 6. Fin del Caso de Uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor cancela la operacin. Fuente: Elaboracin Propia.

120

Figura 4.16. Diagrama de Estado del Caso de uso Respaldo de Datos. Fuente: Elaboracin Propia.

Nombre del Caso de Uso 3.3: Recuperar Datos. Actores: Administrador del Sistema.

121

Descripcin: El usuario administrador podr tener la opcin de recuperar los datos del sistema de toda la base de datos, que previamente haya sido respaldada, desde una ubicacin segura, en el disco duro de la compaa y cualquier unidad extrable de almacenamiento, en caso de producirse un error por alguna anomala que pueda causar que la base de datos se dae. Pre-Condicin: El actor selecciona la opcin Recuperar Datos del men Realizar Configuracin.

Tabla 4.15. Flujo de Eventos del Caso de Uso Recuperar Datos. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema le solicita al usuario opcin Recuperar Datos del un directorio donde se men Realizar encuentran los datos a Configuracin. recuperarse. 3. El actor proporciona la ruta a 4. El sistema descarga desde el seguir para recuperar la directorio toda la base de informacin y se da la orden datos. para iniciar la operacin. 5. El sistema muestra un mensaje indicando el resultado de la operacin. 6. Fin del Caso de Uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor cancela la operacin. Paso 5. De haber un error el sistema mostrara un mensaje de operacin fallida y regresara al paso 2. Fuente: Elaboracin Propia.

122

Figura 4.17. Diagrama de Estado del Caso de Uso Recuperar Datos. Fuente: Elaboracin Propia.

123

Descripcin del Caso de Uso Gestionar Clientes.

Figura 4.18. Caso de Uso Gestionar Clientes. Fuente: Elaboracin Propia.

Nombre del Caso de Uso: Gestionar Clientes. Actores: Supervisor de Soporte Integral, Analista de Soporte Integral, Empleados del sistema y Administrador del Sistema. Descripcin: Permite al usuario empleado el manejo, de todos y cada uno de los datos de los clientes frecuentes y fijos de la empresa dndoles de alta a clientes nuevos, modificando clientes existentes o eliminndolos del sistema. Pre-Condicin: El actor selecciona la opcin Gestionar Clientes del men principal.

124

Tabla 4.16. Flujo de Eventos del Caso de Uso Gestionar Clientes. Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra una lista opcin Gestionar Clientes con los clientes del sistema y del men principal. los botones para agregar, modificar y eliminar clientes determinados. 3. El actor selecciona la opcin 4. Fin del Caso de Uso. deseada de acuerdo a la operacin a realizar. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor cancela la operacin y vuelve al men principal. Fuente: Elaboracin Propia.

Figura 4.19. Diagrama de Estado del Caso de Uso Gestionar Clientes. Fuente: Elaboracin Propia.

125

Descripcin del Caso de Uso Generar Reportes.

Figura 4.20. Caso de Uso Generar Reportes. Fuente: Elaboracin Propia.

Nombre del Caso de Uso: Generar Reporte. Actores: Administrador del Sistema, Empleados del Sistema. Descripcin: Le permite al usuario dependiendo del parmetro

seleccionado, asignacin, devolucin o desincorporacin y bajo un periodo de tiempo especificado en el momento de su ejecucin, poder consultar y obtener toda la informacin de la administracin de los activos de la compaa. Arrojar los datos de equipos que han salido de la compaa y dependiendo del parmetros de los clientes o empleados que procesaron dicha salida. Pre-Condicin: El actor selecciona la opcin Generar Reporte del Men Principal.

126

Tabla 4.17. Flujo de Eventos del Caso de Uso 1.1.2 Generar Reporte Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra una opcin Generar reporte del interfaz para elegir el Tipo de men principal. Reporte. 3. El actor deber seleccionar la 4. El sistema procesa la opcin opcin para as introducir los solicitada. datos solicitados. 5. Finaliza el caso de uso. Caminos Alternativos Paso 3. El actor no realiza ninguna seleccin y vuelve al men anterior. Fuente: Elaboracin Propia.

Figura 4.21. Diagrama de Estado del Caso de Uso Generar Reporte. Fuente: Elaboracin Propia.

127

Nombre de Caso de Uso: Tipo de Reporte. Actores: Administrador del Sistema, Empleados del Sistema. Descripcin: Le permite al usuario poder seleccionar el periodo de tiempo por el cual se van a procesar los datos para visualizar el reporte segn el parmetro seleccionado anteriormente. El sistema mostrara un calendario en el men para poder seleccionar el periodo de inicio y fin de la consulta. Pre-Condicin: El actor selecciona la opcin Tipo de Reporte del Men Generar Reporte.

Tabla 4.18. Flujo de Eventos del Caso de Uso Tipo de Reporte Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber accesar a la 2. El sistema muestra un men opcin Tipo de Reporte del para que el usuario pueda men Generar Reporte. definir el periodo a visualizar para el reporte seleccionado previamente. 3. El actor deber seleccionar, 4. El sistema procesa los datos en el calendario mostrado, el ingresados por el usuario. periodo consultar para definir el reporte. 5. El actor pulsa el botn de 6. El sistema procesa los datos y aceptar y enva los datos busca la informacin ingresados. solicitada. 7. Finaliza el caso de uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor no realiza ninguna seleccin y vuelve al men anterior. Paso 5. El actor cancela la operacin y sale de la interfaz. Fuente: Elaboracin Propia.

128

Figura 4.22. Diagrama de Estado del Caso de Uso Tipo de reporte. Fuente: Elaboracin Propia.

Nombre de Caso de Uso: Realizar Reporte. Actores: Administrador del Sistema, Empleados del Sistema. Descripcin: Le permite al actor poder consultar y obtener informacin de las actividades que se llevan en el inventario. Pre-Condicin: El actor selecciona el Tipo de Reporte del Men Generar Reporte.

129

Tabla 4.19. Flujo de Eventos del Caso de Uso Realizar Reporte Flujo de Eventos Accin del Actor Respuesta del Sistema 1. El actor deber pulsar la 2. El sistema muestra una opcin aceptar luego de interfaz donde visualiza la indicar el periodo. consulta de acuerdo al parmetro seleccionado. 3. El actor solicita imprimir el 4. El sistema genera el reporte reporte generado. impreso. 5. Finaliza el Caso de Uso. Caminos Alternativos Paso 1. El actor selecciona otra opcin. Paso 3. El actor cancela y no imprime el reporte y vuelve al men anterior Fuente: Elaboracin Propia.

Figura 4.23. Diagrama de Estado del Caso de Uso Realizar Reporte. Fuente: Elaboracin Propia.

130

4.1.3. Anlisis de los Requerimientos del Sistema.

El objetivo del anlisis es desarrollar un modelo de funcionamiento de sistema, luego de haber obtenido los requisitos funcionales del sistema, por medio de los casos de uso. El resultado es un modelo inicial de anlisis para definir con precisin los casos de uso y que sirvan como gua en el establecimiento de la arquitectura candidata. En el flujo de trabajo de anlisis se crea una primera aproximacin al modelo de diseo.

Como se mencion anteriormente, se crea una primera aproximacin al modelo de diseo, por lo que no se muestra muchos detalles a pesar de tener un lenguaje ms formal. Para obtener esta primera aproximacin al modelo de diseo se utilizan los Modelos de Anlisis. Entre ellos, Los Diagramas de Clases de Anlisis, slo se centran en los requisitos funcionales previamente obtenidos, mostrando los procesos ms a fondo y adems, comienzan a dar forma a la arquitectura del sistema. Por medio de los Diagramas de Clases de Anlisis, se puede observar que entre la interfaz principal que comunica al actor con el sistema y el surgimiento de otras interfaces, se encuentran los gestores, que son los encargados de activar otras interfaces y de los procesos en general.

Una vez analizados los elementos internos del sistema, es necesario observar las distintas interacciones que ocurren entre ellos. Cuando el usuario enva un mensaje a un caso de uso para invocarlo, inicia su proceso. Este mensaje es recibido por una interfaz especfica, la cual enviara otro mensaje a la clase de control determinada para realizar el proceso de forma ordenada. Para detallar esta comunicacin, se utilizan los Diagramas de Colaboracin.

131

4.1.3.1.

Diagrama de Clase de Anlisis Detallado Para el Caso de Uso Accesar al Sistema.

En el sistema se va a permitir el acceso solo a los usuarios registrados por seguridad de la misma. Para esto, se cuenta con la interfaz acceso al sistema como se observar en la figura 4.24, la clase interfaz Accesar al Sistema representan las interacciones entre el actor y el sistema.

La clase gestor Accesar al Sistema maneja los procesos necesarios para el acceso al sistema y tambin dirige al usuario a la clase interfaz principal. La clase entidad Usuario da el acceso a la informacin requerida por la clase gestor, para dar respuesta a las solicitudes realizadas por los actores.

Figura 4.24. Diagrama de Clase de Anlisis del Caso de Uso Accesar al Sistema. Fuente: Elaboracin Propia.

132

4.1.3.2.

Diagrama de Clase de Anlisis Detallado para el Caso de Uso Procesar Inventario y Costo.

La operacin ms importante del sistema que se lleva a cabo es el de procesar inventario y costo, el cual lo realizan los usuarios de soporte encargados del buen funcionamiento, seguridad y actualizacin de los registros e informacin del inventario y los costos asociados de los equipos en la compaa, como se puede observar en la figura 4.25, podemos tomar en cuenta la interfaz usuario procesar inventario y costo, que junto con la clase gestor de interfaz procesar inventario y costo permiten al usuario seleccionar las clases de interfaz: Procesar Equipos y Costos, Asignacin, Devolucin o Desincorporacin las cuales, la clase de interfaz Procesar Equipos y Costos junto con la clase gestor Procesar Equipos y Costos permite que el usuario pueda controlar los equipos en inventario, sus existencias y sus precios, de igual manera ingresar nuevos equipos a la base de datos de la compaa. La interfaz Asignacin, Devolucin Y

desincorporacin, conjuntamente con sus gestores de interfaz permiten al usuario modificar el status de los equipos existentes. En primer lugar para asignarlos a un cliente, buscndolos en la entidad Inventario y guardndolo en la entidad Asignacin, segundo en la interfaz Devolucin donde poseer las vistas y procesos para registrar la informacin de un producto que, previa asignacin, ha sido devuelto a la empresa por algn motivo en especifico. Por ltimo la clase interfaz Desincorporacin, donde el usuario podr dar de baja algn equipo del inventario. Las clases gestores de estas interfaces manejaran los procesos necesarios para las gestiones solicitados por los usuarios.

133

Figura 4.25. Diagrama de Clase de Anlisis del Caso de Uso Procesar Inventario y Costo. Fuente: Elaboracin Propia.

134

4.1.3.3. Diagrama de Clase de Anlisis Detallado para el Caso de Uso Gestionar Clientes.

La funcin principal del caso de uso Gestionar clientes en el sistema es el manejo de la informacin precisa de la misma. Como pude ver en la figura 4.35 la clase interfaz Gestionar Clientes junto con el gestor Gestionar Clientes permiten a los usuarios seleccionar las clases interfaz: Agregar

Cliente, Modificar Cliente y Eliminar Cliente. Todo esto conlleva a llegar a la clase entidad Cliente para obtener la informacin requerida y as dar resultado a la solicitud de los actores.

Figura 4.26. Diagrama de Clase de Anlisis del Caso de Uso Gestionar Clientes. Fuente: Elaboracin Propia.

135

4.1.3.4.

Diagrama de Clase de Anlisis Detallado para el Caso de Uso Realizar Configuracin.

Una de las operaciones ms relevantes del sistema, es la configuracin ya que tiene como responsabilidad garantizar el buen funcionamiento y seguridad de todo el sistema en general. Como se puede observar en la figura 4.27, donde la clase interfaz Realizar Configuracin junto con la clase gestor Realizar Configuracin permiten al usuario seleccionar las clases de interfaz: Controlar Usuario, Ajustar Costo, Respaldo de Datos y Recuperar Datos. Tomando en cuenta que la interfaz Controlar Usuarios permite al mismo poder seleccionar los procesos inherentes al manejo de la informacin de los usuarios registrados en el sistema, as como tambin el ingreso de datos de nuevos entes que tendrn interaccin con el software en cuestin de la empresa. La clase gestor Controlar Usuario permitir que los elementos que se requieran modificar, de algn usuario existente o nuevo, puedan ser procesados de una manera correcta. Todo este proceso en comunicacin con la entidad Usuarios de donde se obtiene la informacin pertinente a la solicitud. La clase de interfaz Ajustar Costo permite al usuario cambiar los parmetros que definen los costos de los equipos que se encuentran en la entidad Inventario, el gestor Ajustar Costo controla el proceso de actualizacin. Por ltimo se encuentran las clases de interfaz Respaldo de Datos y Recuperar datos, para poder realizar copias de seguridad de la base de datos, debido a alguna falla del sistema o anomala externa, y poder recuperar la informacin previamente respaldada. Los gestores manejan las solicitudes y procesos realizados y las entidades Respaldo e Inventario son necesarios para almacenar y recuperar la informacin requerida.

136

Figura 4.27. Diagrama de Clase de Anlisis del Caso de Uso Realizar Configuracin. Fuente: Elaboracin Propia.

137

4.1.3.5.

Diagrama de Clase de Anlisis Detallado para el Caso de Uso Generar Reportes.

Los usuarios pueden realizar consultas acerca de la informacin que se encuentra en el sistema por medio de los reportes, es por esta razn que se cuenta con la opcin Generar Reportes. En la figura 4.37 se puede observar que la interfaz Generar Reporte representa una interaccin con el actor del sistema, el cual le permite seleccionar los tipos de reporte que son las clases de entidades: Asignacin, Devolucin, Desincorporacin y Reporte. Por medio de cada una de ellas se tiene el acceso a la informacin requerida por las clases de gestor con la intencin de dar respuesta a la solicitud de los actores.

Figura 4.28. Diagrama de Clase de Anlisis para el Caso de Uso Generar Reportes Fuente: Elaboracin Propia.

138

4.1.3.6.

Diagrama de Colaboracin Detallado Para el Caso de Uso Accesar al Sistema.

En la Figura 4.29 se puede observar el Diagrama de Colaboracin de la realizacin del caso de uso Accesar al Sistema, detallando la interaccin entre los distintos elementos del mismo en la siguiente leyenda:

Leyenda:
1: Ingresar datos del usuario. 3: Confirmar Acceso. 2: Procesar peticin de acceso.

Figura 4.29. Diagrama de Colaboracin del Caso de Uso Accesar al Sistema. Fuente: Elaboracin Propia.

139

4.1.3.7.

Diagrama de Colaboracin Detallado para el Caso de Uso Procesar Inventario y Costo.

En la figura 4.30 se observa el Diagrama de Colaboracin para el caso de uso Procesar Inventario y Costo, detallando la interaccin entre los distintos elementos del mismo de acuerdo a la leyendo explicada ms abajo.

Los usuarios del sistema inician el proceso envindole un mensaje a la interfaz Procesar Inventario y Costo, el objeto interfaz Procesar Inventario y Costo muestra las distintas operaciones que los usuarios pueden realizar como son: Procesar Equipos y Costos, Asignacin, Devolucin y

Desincorporacin. Luego solicita al Gestor Procesar Inventario y Costo para activar la interfaz correspondiente de acuerdo a la operacin a realizar.

Leyenda:
1: Gestionar interfaz de Procesar Inventario y Costo. 3: Seleccionar equipo y accin. 5: Guardar equipo en sistema. 7: Mostrar Confirmacin. 9: Selecciona cliente y equipos para Asignacin. 11: Buscar equipo en inventario. 13: Asignar Equipos. 15: Solicitar interfaz Devolucin de Equipos. 17: Procesar datos del equipo. 19: Mostrar datos de la asignacin. 21: Mostrar una confirmacin. 23: Seleccionar Equipo e ingresar cantidad y motivo de la desincorporacin. 25: Buscar equipo a desincorporar en el inventario. 26: Equipo solicitado encontrado. 28: Mostrar Confirmacin. 2: Solicitar Interfaz Equipos y Costos. 4: Procesar Accin y Datos Ingresados. 6: Equipo Procesado. 8: Solicitar interfaz Asignacin. 10: Procesar equipos a asignar. 12: Mostrar equipos a asignar. 14: Mostrar Confirmacin. 16: Ingresar o seleccionar la asignacin especifica. 18: Buscar equipo asignado. 20: Realizar Devolucin. 22: Solicitar interfaz Desincorporacin. 24: Procesar los datos del equipo seleccionado.

27: Almacenar Desincorporacin en el sistema.

140

Figura 4.30. Diagrama de Colaboracin del Caso de Uso Procesar Inventario y Costo. Fuente: Elaboracin Propia.

141

4.1.3.8.

Diagrama de Colaboracin Detallado Para el Caso de Uso Gestionar Clientes

En la figura 4.31 se puede observar el Diagrama de Colaboracin de la realizacin del caso de uso Gestionar Clientes, puntualizando la interaccin entre los distintos elementos del mismo a travs de la siguiente leyenda, donde los usuarios llevan a cabo el control de todos los clientes fijos que posee la empresa y los de mayor importancia.

Leyenda: 1: Gestionar interfaz Agregar Cliente. 3: Cliente Procesado. 2: Procesar Cliente. 4: Mostrar Confirmacin.

Figura 4.31. Diagrama de Colaboracin del Caso de Uso Gestionar Clientes. Fuente: Elaboracin Propia.

142

4.1.3.9.

Diagrama de Colaboracin del Caso de Uso Realizar Configuracin.

En la figura 4.32 se puede observar el Diagrama de Colaboracin de la realizacin del caso de uso Realizar Configuracin, puntualizando la interaccin entre los distintos elementos del mismo, donde los usuarios llevan a cabo la configuracin de distintos componentes del sistema. el proceso se inicia al gestor de interfaz de Realizar Configuracin recibir un mensaje del usuario solicitndole la opcin de configuracin segn la siguiente leyenda:

Leyenda:
1: Activar el Gestor Interfaz Realizar Configuracin. 3: Ingresar datos del usuario. 5: Procesar Usuario. 7: Mostrar Confirmacin. 9: ingresar nuevos parmetros de ajuste de costo. 11: Almacenar los nuevos parmetros en sistema. 13: Mostrar confirmacin. 15: Seleccionar la opcin de respaldo de datos. 17: Buscar datos de la entidad Inventario. 19: Almacenar los datos en la entidad Respaldo. 21: Solicitar Interfaz de Recuperar Datos. 23: Procesar informacin de recuperacin de datos. 25: Mostrar Datos solicitados. 27: Mostrar Confirmacin. 2: Solicitar Controlar Usuarios. 4: Activar el Gestor de interfaz Controlar Usuarios. 6: Usuario Procesado. 8: Solicitar Interfaz Ajustar Costo. 10: Procesar los nuevos parmetros. 12: costos ajustados. 14: Solicitar interfaz Respaldo de Datos. 16: Procesar informacin de respaldo de datos. 18: Mostrar datos solicitados. 20: Mostrar Confirmacin. 22: Seleccionar la opcin de recuperar datos. 24: Buscar Informacin en la entidad Respaldo. 26: Almacenar los datos en la entidad Inventario.

143

Figura 4.32. Diagrama de Colaboracin del Caso de Uso Realizar Configuracin. Fuente: Elaboracin Propia.

144

4.1.3.10. Diagrama de Colaboracin Detallado del Caso de Uso Generar Reportes.

En la figura 4.33, se representa el diagrama de Colaboracin del Caso de Uso Generar Reportes. Aqu se exhibe la interaccin entre los distintos elementos del mismo. Todas estas interacciones quedan expuestas en la siguiente leyenda.

Leyenda:
1: Solicitar Generar Reportes. 3: Buscar datos en la entidad Asignacin. 5: Buscar datos en la entidad Devolucin. 7: Buscar datos en la entidad Desincorporacin. 9: Activar Gestor Imprimir Reporte. 11: Reporte registrado. 2: Activar gestor Interfaz Generar Reportes. 4: Mostrar datos solicitados. 6: Mostrar datos solicitados. 8: Mostrar datos solicitados. 10: Registrar Reporte. 12: Mostrar Confirmacin.

Figura 4.33. Diagrama de Colaboracin del Caso de Uso Generar Reportes. Fuente: Elaboracin Propia.

145

4.1.4. Diseo

En la fase de inicio se desarrolla principalmente el flujo de trabajo de requisitos y el flujo de trabajo de anlisis que se construye a pequea escala, todo ello para elaborar un modelo inicial utilizado en el flujo de trabajo de diseo donde se establecer la estructura del software de toda la aplicacin que se est desarrollando y que, debido a su complejidad y conjunto de elementos que posee, en esta parte no se necesitan ejecutar, se abarcara en el capitulo siguiente con mayor amplitud.

Para el desarrollo de un modelo inicial de anlisis para el sistema SIMIC, se tomaron en cuenta: los requisitos, diagramas y principales subsistemas captados en flujos anteriores, dando como resultado el siguiente diagrama de Paquetes de Anlisis, donde se encuentran los principales subsistemas y las entidades con las que guardan relacin, todo esto dentro de un paquete que representa al sistema, denominado SIMIC.

Se emple el diagrama de Paquetes de Anlisis, debido a que estos diagramas proporcionan un medio para organizar artefactos del modelo en piezas manejables, es decir, organiza los elementos en grupos para comprenderlos ms fcilmente.

En la figura 4.34 se muestra el diagrama de paquetes de anlisis del sistema SIMIC al cual se hace referencia.

146

Figura 4.34. Diagrama de Paquete de Anlisis del Sistema SIMIC. Fuente: Elaboracin Propia.

4.1.5. Conclusin de la Fase de Inicio.

Esta fase de inicio sirvi de base para la realizacin del proyecto. Las herramientas diversas utilizadas en esta etapa valieron para representar los requisitos candidatos y las mltiples necesidades que el sistema deba cubrir para satisfaccin de los usuarios. En primer lugar, se genero un modelo de dominio que permito la comprensin en un nivel bsico de la funcionalidad del sistema y sus interconexiones. Luego, y dando respuesta a la verdadera labor que el sistema deba cubrir para el usuario, se desarrollaron los casos

147

de uso importantes, los actores que intervienen en cada uno de ellos y la forma en que estn relacionados entre s.

Fue necesaria una vista interna del sistema para dar atencin con mayor precisin a los requisitos obtenidos y eliminar los posibles aspectos que pudieran no estar claros para el proyecto. Todo ello, con el propsito de dar una vista previa y primaria de cmo sera el flujo base de la arquitectura del sistema. Por esta razn, se recurri a herramientas que nos permitan cumplir con este objetivo como lo son: Diagramas de Clases de Anlisis, Diagramas de Colaboracin y un modelo inicial de anlisis proporcionado por un Diagrama de Paquetes de Anlisis.

Es necesario explicar que las dos partes principales a desarrollar, como los casos de uso y la arquitectura del sistema, debe avanzar a la par ya que uno complementa y se relaciona con el otro en el sentido de que el primero indica la funcionalidad y el segundo forma, y los casos de uso deben de tener el desarrollo necesario para formar parte de la arquitectura y sta, a su vez, debe proveer el espacio necesario donde los casos de uso funcionaran correctamente.

4.2.

FASE DE ELABORACIN

4.2.1. Resumen.

En esta etapa del proyecto, se va a establecer una base slida de la arquitectura del sistema, para ello, se va a requerir identificar la mayor parte de los requisitos funcionales, es decir, desarrollar, de ser necesario, los

148

casos de uso restantes encontrados posterior a la fase de inicio. Tambin es requerido haber controlado los riesgos principales del sistema.

Todo esto, dar como resultado que stos requisitos, conjuntamente con la arquitectura del sistema obtenida sea lo suficientemente slida y estable y que aquellos riesgos presentes e identificados en la fase de inicio sean controlados en su totalidad.

Sin embargo, cabe destacar que una sola iteracin fue necesaria para identificar y establecer en su totalidad los requisitos y funcionalidades del sistema denominado SIMIC y los cuales fueron analizados a travs de los distintos diagramas elaborados.

Se puede observar, en la siguiente figura de los flujos de trabajo del proceso unificado, que, para la fase de elaboracin, van a cobrar una significativa fuerza y atencin los flujos de trabajo de diseo e implementacin.

4.2.2. Requisitos del Sistema.

Como se mencion, la meta fundamental de esta etapa es la de abordar la mayor parte de los casos de uso o la totalidad de los mismos, tomando como punto de partida todos aquellos que no fueron encontrados en la fase anterior.

Durante la etapa de inicio los requisitos del sistema fueron cubiertos en su totalidad, as como tambin la funcionalidad del mismo, por lo que no

149

se encontraron en esta parte nuevos casos de uso que pusieran ser analizados.

Figura 4.35. Fases y Flujos de Trabajo del Proceso Unificado (Elaboracin). Fuente: Elaboracin Propia.

4.2.3. Anlisis de los Requerimientos del Sistema.

El flujo de trabajo de anlisis se desarrolla sobre los casos de uso identificados en esta parte y, debido a que todos los requisitos y casos fueron identificados en la fase inicial, no se crearan nuevos diagramas de clases de anlisis ni de colaboracin en esta fase de elaboracin.

En la figura 4.36, se puede observar el diagrama de Paquetes de Anlisis del sistema SIMIC, que muestra los principales casos de uso: Accesar al Sistema, Procesar Inventario y Costo, Gestionar Clientes, Realizar Configuracin y Generar Reportes, representados de la manera habitual (por

150

medio de elipses) y sus relaciones con los diferentes paquetes por medio de lneas punteadas que representan las funcionalidades asociadas.

Figura 4.36. Diagrama de Paquetes de Anlisis a partir de de los Casos de Usos Principales Fuente: Elaboracin Propia

4.2.4. Diseo del sistema propuesto.

El flujo de trabajo de diseo toma importancia en esta etapa ya que su objetivo fundamental es la de comenzar a dar forma a la lnea base de la arquitectura del sistema, todo ello logrado a travs de las distintas vistas y modelos de objetos que representen la realizacin fsica de los casos de uso.

La estructura del Software de toda la aplicacin que se esta desarrollando, por medio del modelo de diseo del sistema propuesto como:

151

el diseo de la base de datos, diagramas de clases de diseo y el diseo de las interfaces de usuario; todo esto con el fin de representar las diferentes operaciones y actividades que se realizaran en el sistema, as como las relaciones existentes entre ellos

4.2.4.1.

Diagramas de Clases de Diseo del Sistema.

El desarrollo de los diagramas de clases del sistema SIMIC, permiten identificar los elementos estticos que intervienen en el mismo. En las siguientes figuras se van a mostrar los diagramas de clase de diseo de acuerdo a los diferentes casos de uso ya identificados en captulos anteriores.

Diagrama de Clase de Diseo Para el Caso de Uso Accesar al Sistema.

La figura 4.37 muestra el Diagrama de Clase de Diseo para el caso de uso Accesar al Sistema. Aqu se muestran, la clase, la relaciones y los atributos de como el usuario tiene acceso al sistema a travs de su nombre de usuario, asignado cuando el administrador agrega sus datos por vez primera a la base de datos, y clave de usuario. A travs de la clase accesar al sistema, podr accesar a la interfaz principal de la misma donde se encuentran los mdulos principales que conforman el sistema de inventario y costo SIMIC (Procesar Inventario y Costo, Realizar Configuracin, Gestionar Clientes y Generar Reportes). En este diagrama se muestra, adicionalmente, la entidad Usuarios donde se encontrar toda la informacin necesaria para darle acceso, segn sea el cargo y la responsabilidad, a la persona que ingrese al sistema y manipule cualquiera de sus mdulos.

152

Figura 4.37. Diagrama de Clase de Diseo para el Caso de Uso Accesar al Sistema. Fuente: Elaboracin Propia.

153

Diagrama de Clase de Diseo para el Caso de Uso Procesar Inventario y Costo.

El diagrama de clase de diseo para este caso de uso, permite al usuario realizar operaciones como: Manipular la informacin de los equipos y sus costos y administrar los datos del inventarios cambiando los status de los equipos en l por Asignacin, Devolucin o Desincorporacin.

La clase interfaz Procesar Equipos y Costos se encarga de procesar toda la informacin de los equipos registrados en el inventario de la compaa, cambiar sus datos, sus existencias, sus costos o agregar nuevos elementos al inventario.

La clase interfaz Asignacin es mostrada en este diagrama en donde se dan las relaciones y atributos para colocar en venta un equipo y asignarlo a un cliente en especifico. Se muestra de igual manera la clase de interfaz Devolucin el cual permite al usuario, en este caso al analista de soporte, registrar la devolucin de un equipo, previa asignacin, debido a algn motivo en especfico. Por ltimo se encuentra la clase de interfaz Desincorporacin la cual se encarga de procesar aquellas actividades donde se elimina un equipo, o un grupo de ellos, del inventario por no encontrarse aptos para ser asignados debido a alguna anomala en su funcionamiento.

En la figura 4.38, se muestra el diagrama de clase de diseo para el caso de uso procesar inventario y costos del sistema SIMIC.

154

Figura 4.38. Diagrama de Clase de Diseo para el Caso Uso Procesar Inventario y Costo. Fuente: Elaboracin Propia.

155

Diagrama de Clase de Diseo para el Caso de Uso Realizar Configuracin.

Este diagrama de clase para el caso de uso Realizar Configuracin, le permite al usuario observar las operaciones como: Controlar Usuarios, Ajustar Costos, Respaldar y Recuperar datos del sistema.

En la clase Controlar Usuario se realizan las operaciones del control de todos los usuarios del sistema: registro de nuevos usuarios, modificar los datos de un usuario y eliminar un usuario. Estas actividades guardan una relacin de composicin con la clase Procesar Usuario de acuerdo a la actividad a realizar para el usuario.

La clase Ajustar Costo se encarga de buscar los equipos, ajustar sus costos, de acuerdo a los parmetros y porcentajes establecidos, IVA y Dlar, y guardar sus precios, segn los nuevos parmetros ingresados.

La clase de Respaldo de Datos, sobre la base de datos, se encarga de realizar las operaciones del resguardo de datos, la cual har uso de la ruta de almacenamiento especificada por el administrador del sistema para realizar una copia de los datos que sean administrados dentro de la base de datos.

La clase de recuperacin se extraen los datos que hayan sido respaldados previamente y restaurarlos nuevamente a la base de datos del sistema.

156

La figura 5.39 muestra el diagrama de clase de diseo para el caso de uso Realizar Configuracin.

Figura 4.39. Diagrama de Clase de Diseo para el Caso de Uso Realizar Configuracin. Fuente: Elaboracin Propia.

157

Diagrama de Clase de Diseo para el Caso de Uso Gestionar Clientes.

Este diagrama de clase de diseo, de la figura 4.40, le permite al usuario, observar las operaciones de almacenamiento, bsqueda y proceso de toda la informacin concerniente a los clientes de la empresa.

En la clase Gestionar Clientes se realizan las operaciones de registro de nuevos clientes, modificar los datos del cliente y eliminar algn cliente. Estas actividades guardan una relacin de composicin con la clase Procesar Cliente de acuerdo a la actividad a realizar.

Figura 4.40. Diagrama de Clase de diseo para de Caso de Uso Gestionar Clientes. Fuente: Elaboracin Propia.

158

Diagrama de Clase de Diseo para el Caso de Uso Generar Reportes.

La figura 4.41 muestra el Diagrama de Clase de Diseo para el Caso de Uso Generar Reportes. Aqu se muestra la clase interfaz Generar Reportes, la cual podr permitir al usuario seleccionar el tipo de reporte a realizar ya sea por Asignacin, Devolucin o por Desincorporacin en una fecha especfica. Tambin se podr generar el reporte de acuerdo al parmetro seleccionado.

Figura 4.41. Diagrama de Clase de Diseo para el Caso de Uso Generar Reportes. Fuente: Elaboracin Propia.

159

4.2.4.2.

Diagrama de Capas.

El diagrama de capas evidencia las dependencias y distribuciones de cada una de las capas de los sub-sistemas del diseo. Este diagrama se divide en capas de acuerdo al nivel al que intervienen los sub sistemas necesarios. En la figura 4.42 se muestran las capas del sistema SIMIC el cual inicia con la capa especifica de aplicacin, el cual contiene todos los sub sistemas de SIMIC que se interconectan con el sistema de la capa general de aplicacin: Sistema de Informacin para el Manejo de Inventarios y Costos S.I.M.I.C.

La comunicacin entre la capa general de aplicacin y la capa intermedia es a travs de los paquetes de programacin y del diseo Web. Entre los principales software de programacin se cuenta con PHP 5.2.9 lenguaje de programacin orientado en la creacin de paginas web dinamicas, NetBeans IDE 6.8 para el manejo de las funciones de programacin en conjunto con el lenguaje PHP con el cual se puede, escribir, compilar, depurar y ejecutar cada odigo que se tenga, el manejador de Base de Datos Relacionales y de cdigo abierto MySQL 6.0 y el servidor Apache Web Server 2.2.8 y por ltimo se tiene la capa de software del sistema donde se encuentra el sistema operativo Windows Vista Ultimate, evolucin de su predecesor Windows XP, con opciones de dinamismo, navegacin y control superiores a otros sistemas operativos, el cual fue utilizado para operar el sistema de Inventario y Costo SIMIC y el conjunto de protocolos del entrono web donde operara el software desarrollado.

160

Figura 4.42. Diagrama de Capas. Fuente: Elaboracin Propia.

4.2.4.3.

Diseo de la Base de Datos.

La gestin del sistema se ve alimentada por el manejo del conjunto de informacin que fluye a travs del mismo. La base de datos es la fuente vital para que esta gestin se d eficientemente. Para la realizacin de esta base se tomaron los diagramas de anlisis y los de clases. Para que ste sea lo ms estable posible, es necesario proporcionar independencia de los datos con respecto a los procesos ejecutados, mejorando as, la disponibilidad e integridad de los datos.

161

El diseo de la base de datos y sus tablas se realizara mediante el modelo relacional, modelo lgico caracterizado por ser entendible, que esta orientado a bases de datos relacionales y a la administracin dinmica de los datos.

Diseo de las Tablas.

Para el sistema SIMIC se dise la base de datos compuesta por las siguientes tablas: o Tabla 1: Usuarios.

La Tabla Usuarios es la que va a almacenar toda la informacin de los usuarios del sistema y encargados de tener el manejo, control y revisin del funcionamiento de SIMIC dentro de la empresa. Esta tabla servir de registro y agenda para realizar cualquier contacto necesario con ellos y monitorear sus datos ante cualquier cambio. Esta tabla se va llenando al momento que el administrador agregue algn nuevo usuario que interactu con el sistema y es modificada cuando se eliminan o modifican los datos de cualquier usuario. La clave primaria de la tabla Usuarios es cod_usuario, el esquema de la tabla es el siguiente: cod_usuario (Codigo de Usuario, clave primaria),

LOG_USR (Nombre de Usuario, requerido al momento de accesar al sistema), NOM_USU (Nombre de la persona que se est agregando como usuario del sistema), APELLIDO_USR (Apellido del Usuario), PAS_USR (Contrasea otorgada al usuario, requerida al momento de accesar al sistema), CED_USR (Cedula de Identidad del usuario), TELF_USR (Telfono de contacto que posee el usuario),

162

CARGO_USR (Cargo asignado al usuario, Administrador, Soporte o Empleado), ADMIN (Referido para Guardar el acceso de tipo administrador, valores de referencia 1 0), ACC_CONF (Guarda el nivel de acceso al modulo de configuracin para el usuario, Valores 1 activado 0 desactivado), ACC_INV (Guarda el nivel acceso para el modulo de inventario y costo, permite el acceso con un valor de 1 y lo inhabilita con un valor de 0), ACC_CLI (Guarda el nivel acceso para el modulo de gestin de clientes, permite el acceso con un valor de 1 y lo inhabilita con un valor de 0), ACC_REP (Guarda el nivel acceso para el modulo generar reportes, permite el acceso con un valor de 1 y lo inhabilita con un valor de 0). o Tabla 2: Cargos.

La Tabla Cargos se ir llenando en conjunto con la tabla Usuarios ya que esta va a contener los tipos de usuarios que interactan con el sistema (Administrador, Empleado o Soporte) y la definicin de los accesos que puedan tener. La clave Primaria de Cargos es id_cargo (Cdigo para conocer el tipo de cargo que posee y referenciar su bsqueda en la tabla) y contiene un campo adicional llamado descripcin (Describe el tipo de cargo). o Tabla 3: Equipo.

La Tabla Equipos va a almacenar los datos de los equipos en existencia, su identificacin, sus cantidades y precios. La clave primaria de esta Tabla estar compuesta por id_equipo y el esquema de la tabla es el siguiente: id_equipo (Cdigo del equipo o serial,

163

clave primaria de la tabla), nomb_equipo (Nombre del equipo que se est procesando), marca (Marca del equipo adquirido y procesado), modelo (Modelo del equipo), cant_exi (Cantidad en existencia en el inventario de ese equipo en especifico), costo_bs (Valor del equipo en moneda nacional de haber sido adquirido dentro del pas), costo_dl (Valor del equipo en Dlares de haber sido importado y cancelado con dicha moneda extranjera), utilidad (Porcentaje de ganancia que le da la empresa al equipo procesado), Precio (Precio final del equipo). o Tabla 4: Clientes.

La tabla Clientes va a contener almacenado toda la informacin referente a los clientes de la empresa, identificacin, cedula, nombres y apellidos del contribuyente, direccin, telfonos y empresa a la que representa en caso de ser una persona jurdica, necesaria para llevar el control de las asignaciones y devoluciones de los equipos. La clave primaria de la tabla ser el campo id_cli y el esquema de la tabla es la siguiente: id_cli (Cdigo del cliente procesado, clave primaria de la tabla), contrib_cli (Almacenara Nombre y Apellido del cliente), ced_cli (Cedula de Identidad del cliente), direc_cli (Direccin de residencia del cliente), tel_cli (Telfono de contacto del cliente), tipo_cont (Almacenar si el cliente es natural o jurdico), repre_emp (Representante de la empresa), tel_repre_emp (Telefono de contacto del representante de la empresa). o Tabla 5: Asignacin.

164

La tabla Asignacin almacenara toda la informacin de todos aquellos procesos donde un equipo se le asigna a un cliente en una venta, en esta tabla estar contenida informacin como el cdigo de la asignacin, la identificacin del cliente involucrado, la fecha de la transaccin y el monto. Esta tabla se complementa con

asignacin_detalle y su clave primaria estar representada con cod_asig. El esquema de la tabla ser el siguiente: cod_asig (Codigo por el cual la asignacin esta registrada, clave primaria de la tabla), id_cliente (Codigo del cliente al cual le fue asignado el o los equipos en la venta), fecha_as (Fecha en la que fue realizada la operacin de asignacin), monto_as (Monto total de la asignacin). o Tabla 6: Asignacion_detalle.

La tabla asignacin_detalle contendr los detalles de la transaccin realizada en la compra-venta de los equipos entre la compaa y el cliente. Contendr informacin como el cdigo del equipo involucrado, la cantidad del mismo asignado, el precio total, etc. La clave primaria de esta tabla ser el cdigo de la asignacin representada por cod_asig y el esquema de la tabla ser el siguiente: cod_asig (Cdigo de la asignacin), cod_equipo (el cdigo del equipo que fue asignado), cantidad (La cantidad asignada de ese equipo en particular), precio (El precio del equipo asignado), total (Precio total del equipo asignado, precio multiplicado por la cantidad). o Tabla 7: Devolucin.

165

La tabla devolucin almacenara los datos de todas aquellas transacciones por las cuales un equipo, o varios equipos, ya asignado son devueltos por algn motivo en especfico. La clave primaria de esta tabla ser el cdigo de devolucin, la cual est representada por el campo cod_dev. La tabla est distribuida por los siguientes campos: cod_dev (Cdigo de la devolucin registrada, Clave primaria de la tabla), cod_asig (Cdigo de la asignacin realizada previamente en donde se encuentra el equipo que va a ser devuelto), fecha_dev (Fecha en que se est registrando la devolucin), motivo_dev (Motivo por el cual el cliente est devolviendo el equipo), monto_dev (Monto total en devolucin registrada). o Tabla 8: Devolucin_Detalle.

La tabla devolucin_detalle contendr los detalles del equipo que ha sido devuelto en la transaccin registrada. Almacenar informacin como el cdigo del equipo involucrado, la cantidad del mismo devuelto, el precio total. La clave primaria de esta tabla ser el cdigo de la devolucin representada por cod_dev y el esquema de la tabla ser el siguiente: cod_dev (Cdigo de la devolucin), id_equipo (el cdigo del equipo que fue devuelto), cantidad (La cantidad a devolver de ese equipo en particular), precio (El precio del equipo devuelto), total (Precio total del equipo que ha sido devuelto, precio multiplicado por la cantidad). o Tabla 9: Desincorporacin.

166

Esta tabla contiene a los equipos que son sacados del inventario por algn desperfecto y que no son aptos para la venta. Contiene informacin acerca del cdigo del descargo, fecha del proceso, equipo involucrado usuario encargado de la desincorporacin y el motivo del mismo. La clave primaria de esta Tabla estar compuesta por id_des y el esquema de la tabla es el siguiente: id_des (Cdigo de la desincorporacin, clave primaria de la tabla), fecha_des (Fecha en que se esta registrando el descargo), id_equipo (cdigo o serial del equipo del cual se esta realizando la desincorporacin), cantidad (Cantidad del equipo a desincorporar), id_usuario (Identificacin del usuario que realiz el descargo), motivo_des (Motivo por el cual se ha registrado un descargo de un equipo en especifico). o Tabla 10: Parmetros.

Esta tabla almacenara los parmetros necesarios para uso del programa en elementos como reportes y el ajuste de precio debido a cambios del IVA o Dlar. Estar contenido informacin referente a datos de identificacin de la empresa y los elementos que modifican los precios de los equipos mencionados anteriormente. La clave primaria estar representada por cdigo y el esquema total distribuida por los siguientes campos: (cdigo (Codigo de la empresa), nomemp (Nombre de la empresa), rif (Rif de la empresa), direccin (Direccin de ubicacin), ciudad (Ciudad de ubicacin), estado, telfono, encabezado1, encabezado2, encabezado3 (encabezados utilizados en reportes), imagen_izq (Imagen representativa de la empresa usada en las interfaces), dlar (Parmetros para el clculo de precios), iva (Parmetro para el clculo de precios).

167

Es necesario destacar que adems de haber diseado las tablas bajo el modelo relacional, estas cumplen con la mayora de las formas normales que conforman la normalizacin, herramienta de verificacin de las bases de datos relacionales cuya finalidad es eliminar o reducir al mnimo las redundancias e inconsistencias en los datos.

Interrelaciones.

Se dice que dos tablas estn interrelacionadas cuando una posee una clave fornea de la otra. Una clave fornea, es el atributo o conjunto de atributos dentro una tabla que contienen claves primarias de otra tabla. En la figura 4.43, se pueden observar las interrelaciones entre las tablas pertenecientes a la base de datos del sistema SIMIC.

Figura 4.43. Modelo Relacional de la Base de Datos SIMIC. Fuente: Elaboracin Propia.

168

4.2.5. Prototipo de Interfaz SIMIC.

El prototipo de las interfaces del sistema SIMIC muestra como seria la estructura de las vistas de usuarios, para que stos puedan explotar toda su funcionalidad desde los distintos mdulos. Con el objetivo de tener una interfaz intuitiva, de fcil acceso y manejo en la figura 4.44 se describe el boceto de una pgina funcional al momento de finalizado el sistema. Puede observarse en la esquina superior izquierda el logo del sistema, al lado de esta el banner principal, con el contenido representativo de la empresa, identificacin del usuario que est abriendo sesin y los botones de salida del sistema. Del lado izquierdo de la pantalla el men de acceso a todos los mdulos del sistema que estar presente en todas las vistas de usuario. Por ltimo y en todo el centro la pagina que mostrara la informacin de usuarios, equipos, clientes y reportes o formularios para la entrada de datos por parte del usuario desde el teclado.

Figura 4.44. Prototipo de la Interfaz SIMIC. Fuente: Elaboracin Propia.

169

4.2.6. Conclusin de la fase de elaboracin.

La fase de elaboracin muestra la existencia de requisitos que ya fueron abordados en la fase anterior, los cuales cubren la realizacin de la descripcin de la lnea base de la arquitectura, que consisti: en la identificacin de los subsistemas, el diseo de las tablas pertenecientes a la base de datos y los diagramas de clases de diseo de los principales componentes del sistema.

4.3.

FASE DE CONSTRUCCION

4.3.1. Resumen.

Esta etapa del proyecto, el objetivo principal es alcanzar la capacidad operacional del sistema por medio de los diversos modelos que se desarrollan hasta completarse. En este caso, la arquitectura no tendra mayores modificaciones ya que sta viene definida de la fase de elaboracin. Los componentes, caractersticas y requisitos deben ser implementados, integrados y probados en su totalidad para as obtener una versin aceptable y de calidad.

La figura 4.45 muestra las fases y flujos de trabajo del proceso unificado, donde se puede observar que el flujo de trabajo con mayor demanda es el de implementacin ya que se busca obtener la versin beta del sistema SIMIC para as realizar las pruebas necesarias sobre el mismo.

170

Figura 4.45. Fases y Flujos de Trabajo del Proceso Unificado (Construccin). Fuente: Elaboracin Propia.

4.3.2. Requisitos del sistema.

En la fase de inicio se identificaron diversos requisitos que fueron tomados con sus respectivos casos de uso, donde la funcionalidad del sistema fue prcticamente cubierta en su totalidad. En esta etapa no se crearon nuevos casos de uso, pues no se identificaron nuevos requisitos en el sistema.

4.3.3. Anlisis de los Requerimientos del Sistema.

La totalidad de los casos de uso ya fueron identificados y abordados en las fases anteriores, en la presenta fase no se encontraron nuevos casos de uso por lo que en este flujo de trabajo no es necesario crear nuevos diagramas pertenecientes a los modelos de anlisis.

171

4.3.4. Diseo del sistema propuesto.

Est enfocado en el flujo de diseo que por medio de este se desarrollaran los prototipos de interfaces de usuario, prototipos que sern sometidos a una serie de pruebas de uso por los usuarios para as obtener las interfaces definitivas.

4.3.4.1.

Herramientas de Desarrollo Escogidas.

Las herramientas a utilizar van a depender del tipo de aplicacin que se desee desarrollar, en este caso se aplicaran a un entorno web. La seleccin de las herramientas se realiz con el objetivo de obtener una implementacin de componentes que garantice el comportamiento dinmico que caracteriza a las aplicaciones de este tipo.

Lenguaje de Programacin de Aplicacin Web: PHP.

PHP (Hypertext Pre-processor) es un lenguaje de programacin interpretado, diseado originalmente para la creacin de pginas web dinmicas. El lenguaje PHP es un lenguaje de programacin de estilo clsico, es un lenguaje de programacin con variables, sentencias condicionales, bucles, funciones, etc. No es un lenguaje de marcas como podra ser HTML, XML o WML. Est ms cercano a JavaScript o a C.

Pero a diferencia de Java o JavaScript que se ejecutan en el navegador, PHP se ejecuta en el servidor, por eso nos permite acceder a los recursos que tenga el servidor como por ejemplo podra ser una base de datos. El

172

programa PHP es ejecutado en el servidor y el resultado enviado al navegador. El resultado es normalmente una pgina HTML.

Al ser PHP un lenguaje que se ejecuta en el servidor no es necesario que el navegador lo soporte, es independiente de ste, pero sin embargo para que las pginas PHP funcionen, el servidor donde estn alojadas debe soportar PHP.

Entre las caractersticas que posee el lenguaje PHP, las ms importantes y las que le dan la fama de ser uno de los lenguajes web ms utilizados en el mercado estn:

Soporte para Bases de Datos:

Una de sus caractersticas ms potentes es su suporte para gran cantidad de bases de datos. Entre su soporte pueden mencionarse InterBase, mSQL, MySQL, Oracle, Informix, PosgreSQL, entre otras. PHP tambin ofrece la integracin con las varias bibliotecas externas, que permiten que el desarrollador haga casi cualquier cosa desde generar documentos en pdf hasta analizar cdigo XML.

Cdigo Abierto:

Como producto de cdigo abierto, PHP goza de la ayuda de un gran grupo de programadores, permitiendo que los fallos de funcionamiento se encuentren y se reparan rpidamente. El cdigo se pone al da continuamente con mejoras y extensiones de lenguaje para ampliar las capacidades de PHP. Es utilizado en aplicaciones Web-

173

relacionadas por algunas de las organizaciones ms prominentes tales como Mitsubishi, Redhat, Der Spiegel, MP3-Lycos, Ericsson y NASA.

PHP es la opcin natural para los programadores en mquinas con Linux que ejecutan servidores web con Apache, pero funciona igualmente bien en cualquier otra plataforma de UNIX o de Windows, con el software de Firefox o del web server de Microsoft. PHP tambin utiliza las sesiones de HTTP, conectividad de Java, expresiones regulares, LDAP, SNMP, IMAP, protocolos de COM (bajo Windows).

Base de Datos: MySQL:

MySQL es la base de datos Open Source ms popular y, posiblemente, mejor del mundo. Su continuo desarrollo y su creciente popularidad est haciendo de MySQL un competidor cada vez ms directo de gigantes en la materia de las bases de datos como Oracle.

MySQL es un sistema de administracin de bases de datos (Database Management System, DBMS) para bases de datos relacionales. As, MySQL no es ms que una aplicacin que permite gestionar archivos llamados de bases de datos.

Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza multiples tablas para almacenar y organizar la informacin. MySQL fue escrito en C y C++ y destaca por su gran adaptacin a diferentes entornos de desarrollo, permitiendo su interactuacin con los lenguajes de programacin ms utilizados como PHP, Perl y Java y su

174

integracin en distintos sistemas operativos comercializados en el mercado.

Tambin es muy destacable, la condicin de Open Source de MySQL, que hace que su utilizacin sea gratuita e incluso se pueda modificar con total libertad, pudiendo descargar su cdigo fuente. Esto ha favorecido muy positivamente en su desarrollo y continuas actualizaciones, para hacer de MySQL una de las herramientas ms utilizadas por los programadores orientados a Internet.

NetBeans IDE.

La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados mdulos. Un mdulo es un archivo Java que contiene clases de java escritas para interactuar con las APIs de NetBeans y un archivo especial (manifest file) que lo identifica como mdulo. Las aplicaciones construidas a partir de mdulos pueden ser extendidas agregndole nuevos mdulos. Debido a que los mdulos pueden ser desarrollados independientemente, las aplicaciones basadas en la plataforma NetBeans pueden ser extendidas fcilmente por otros desarrolladores de software.

NetBeans es un proyecto de cdigo abierto de gran xito con una gran base de usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo el mundo. Sun MicroSystems fund el proyecto de cdigo abierto NetBeans en junio de 2000 y contina siendo el patrocinador principal de los proyectos.

175

El IDE NetBeans es un IDE - una herramienta para programadores pensada para escribir, compilar, depurar y ejecutar programas. Est escrito en Java - pero puede servir para cualquier otro lenguaje de programacin. Existe adems un nmero importante de mdulos para extender el IDE NetBeans. El IDE NetBeans es un producto libre y gratuito sin restricciones de uso.

El NetBeans IDE es un IDE de cdigo abierto escrito completamente en Java usando la plataforma NetBeans. El NetBeans IDE soporta el desarrollo de todos los tipos de aplicacin Java (J2SE, web, EJB y aplicaciones mviles). Entre sus caractersticas se encuentra un sistema de proyectos basado en Ant, control de versiones y refactoring.

NetBeans IDE 6.5, la cual fue lanzada el 19 de noviembre de 2008, extiende las caractersticas existentes del Java EE (incluyendo Soporte a Persistencia, EJB 3 y JAX-WS). Adicionalmente, el NetBeans Enterprise Pack soporta el desarrollo de Aplicaciones empresariales con Java EE 5, incluyendo herramientas de desarrollo visuales de SOA, herramientas de esquemas XML, orientacin a web servicies (for BPEL), y modelado UML. El NetBeans C/C++ Pack soporta proyectos de C/C++, mientras el PHP Pack, soporta PHP 5.

Modularidad. Todas las funciones del IDE son provistas por mdulos. Cada mdulo provee una funcin bien definida, tales como el soporte de Java, edicin, o soporte para el sistema de control de versiones. NetBeans contiene todos los mdulos necesarios para el desarrollo de aplicaciones Java en una sola descarga, permitindole al usuario comenzar a trabajar inmediatamente.

176

Sun Studio, Sun Java Studio Enterprise, y Sun Java Studio Creator de Sun Microsystems han sido todos basados en el IDE NetBeans.

Sistema Operativo: Microsoft Vista Ultimate.

Windows Vista es una versin de Microsoft Windows, lnea de sistemas operativos desarrollada por Microsoft. Esta versin se enfoca para ser utilizada en equipos de escritorio en hogares y oficinas, equipos porttiles, "tablet PC" y equipos "media center".

El proceso de desarrollo termin el 8 de noviembre de 2006 y en los siguientes tres meses fue entregado a los fabricantes de hardware y software, clientes de negocios y canales de distribucin. El 30 de enero de 2007 fue lanzado mundialmente y fue puesto a disposicin para ser comprado y descargado desde el sitio web de Microsoft.

La aparicin de Windows Vista viene ms de 5 aos despus de la introduccin de su predecesor, Windows XP, es decir el tiempo ms largo entre dos versiones consecutivas de Microsoft Windows.

Entre las caractersticas principales de Windows Vista estn:

Mayor control paterno sobre el uso de la computadora por parte de los hijos, tiempo de navegacin y sitios.

Mayor seguridad en la navegacin.

177

Un entorno ms dinmico y tridimensional.

Evolucin del sistema operativo Windows XP.

Toma en cuenta que cada vez ms gente trabaja con una conexin a Internet.

Devuelve al usuario el control de la computadora para que se convierta en el gestor.

Incorpora programas de edicin de video y nuevos gestores de archivos multimedia (fotografa, msica y otros). Mantiene los programas habituales de correo electrnico, agenda y otros.

Cuenta con versiones mejoradas de sus programas de trabajo como el procesador de textos Word, la hoja de clculo Excel y la de presentaciones PowerPoint.

Tiene la capacidad de abrirse indistintamente en ingls o en espaol, segn lo prefiera la persona que se siente al teclado.

4.3.4.2.

Diseo de las interfaces.

El objetivo fundamental en la elaboracin de las interfaces del sistema SIMIC estuvo centrado en la sencillez y facilidad de uso por parte del usuario. Es por esto, que el desarrollo del entorno del sistema fue elaborado para que el

178

usuario se maneje de una manera intuitiva por los diferentes mdulos que lo componen.

Las siguientes figuras a continuacin representan las interfaces de la versin beta del sistema SIMIC en sus distintos mdulos de trabajo:

Interfaz Accesar al Sistema:

En la figura 4.46, se puede observar la interfaz Accesar al Sistema, que ser la primera a la que el usuario tendr acceso, donde se proceder a identificarse para poder entrar al sistema, ingresando su nombre de usuario y su contrasea asignada, de acuerdo a un nivel de acceso. Primera vista que dar lugar seguidamente a la interfaz principal donde se encontrarn los mdulos que manejo del sistema SIMIC. A continuacin se describen los principales elementos de esta interfaz:

Logotipo de la empresa Diesel Oriente C.A.

Identificacin del sistema empleado SIMIC.

Campos para la identificacin del usuario mediante Nombre de Usuario y la Clave.

Botones para Aceptar o Cancelar el envo de la informacin suministrada para obtener el acceso al usuario solicitante.

179

Figura 4.46. Interfaz Accesar al Sistema. Fuente: Sistema de Informacin SIMIC.

Interfaz Principal de Usuario:

La interfaz principal de usuario es la base para tener acceso a diferentes mdulos del sistema SIMIC. Los diferentes mdulos estarn siempre presentes en la columna izquierda de la pantalla para un mejor acceso y facilidad del trabajo.

En la figura 4.47 se muestra la interfaz y se identifica los distintos elementos que lo representan: o Logotipo de la empresa Diesel Oriente C.A. .

180

o Identificacin del sistema de manejo de inventario SIMIC. o Men de acceso rpido a los distintos mdulos del sistema. o Botones de acceso a los distintos mdulos del sistema. o Identificacin del usuario y la opcin para desconectarse del sistema.

Figura 4.47. Interfaz Principal de Usuario. Fuente: Sistema de Informacin SIMIC.

Interfaz realizar configuracin

La figura 4.48 muestra la interfaz de Realizar Configuracin, donde el administrador tendr acceso el proceso de los usuarios del sistema, los

181

parmetros que definen los costos de los equipos y las opciones de respaldo y recuperacin de todo el sistema.

La interfaz sigue la tendencia del men de los mdulos principales en la parte izquierda, la identificacin del usuario, logotipo de la empresa Diesel Oriente C.A., identificacin del sistema SIMIC, la opcin de de salida del sistema y los iconos de acceso a los sub mdulos de Configuracin.

Figura 4.48. Interfaz Realizar Configuracin. Fuente: Sistema de Informacin SIMIC.

Interfaz Controlar Usuarios

La figura 4.49 muestra la interfaz controlar usuarios. En esta parte el administrador del sistema podr procesar y llevar el control de la informacin

182

de los usuarios del sistema. Se muestra un listado de todos y cada uno de ellos conjuntamente con la informacin de nombre de usuario, nombre del empleado y el cargo que posee, y las opciones para agregar, modificar y eliminar cualquiera de los usuarios que se seleccione del listado inicial. Adicionalmente, se muestra un panel para la bsqueda personalizada de cualquier usuario en especfico o un grupo de ellos. Los elementos de la interfaz se enumeran a continuacin: o Botn para agregar nuevo usuario. o Panel de bsqueda. o Botn de edicin de usuario. o Botn de eliminar usuario. o Listado de los usuarios del sistema.

Los elementos restantes guardan similitud y aparecen en las interfaces de usuarios anteriores y se repiten en todos las vistas: panel de men de mdulos del sistema en el lado izquierdo para el acceso a los distintos mdulos del sistema SIMIC, imagen representativa de la empresa, encontrado en la parte inferior seguido del men de mdulos, y del sistema de informacin de inventarios y costos SIMIC, ubicado en la parte superior izquierda de la pantalla, identificacin de usuario que est ejecutando la sesin en ese momento y el botn de desconexin de la sesin activa ubicado en el lado derecho de la pantalla en la interfaz de usuario.

183

Figura 4.49. Interfaz Controlar Usuarios. Fuente: Sistema de Informacin SIMIC.

Figura 4.50. Agregar/Editar Usuario Fuente: Sistema de Informacin SIMIC.

184

Interfaz Ajustar Costo

La interfaz ajustar costo se muestra en la figura 4.51 y representa la parte del sistema donde el administrador podr cambiar los parmetros que definen los precios finales de los equipos para la venta, el Impuesto al Valor Agregado IVA y la tasa de cambio del dlar actual. Los elementos diferentes a la vista anterior son los campos que contienen a los parmetros y los botones para modificar sus valores inciales.

Figura 4.51. Interfaz Ajustar Costo. Fuente: Sistema de Informacin SIMIC..

185

Interfaz de Respaldo de Datos.

La interfaz Respaldo de Datos contendr la vista necesaria para el usuario administrador en donde ste pueda realizar copias de seguridad de la base de datos en general. Aqu podr guardar la informacin de los equipos en sistema en la direccin del disco duro o una unidad de almacenamiento extrable que desee para poder restaurarla en el momento indicado. o Direccin de almacenamiento en disco duro o disco extrable.

Figura 4.52. Interfaz Respaldo de Datos. Fuente: Sistema de Informacin SIMIC.

186

Interfaz Recuperar Datos.

La figura 4.53 muestra la vista de la interfaz de usuario Recuperar Datos donde el administrador podr restaurar la base de datos del sistema previamente guardado en una unidad de almacenamiento. La base de datos puede quedar corrupta debido a una baja del voltaje o cualquier otro motivo y puede ser restaurada de una copia de seguridad realizada previamente. Muestra una opcin para elegir la ruta desde donde se restituir la base en el sistema.

Figura 4.53. Interfaz Recuperar Datos. Fuente: Sistema de Informacin SIMIC.

187

Interfaz Procesar Inventario y Costo.

Esta interfaz de usuario mostrar el men principal para trabajar directamente con los equipos ingresados en el sistema. Distribuye la vista en iconos que dan acceso a los mdulos de inventarios: Equipos, Asignacin, Devolucin y Desincorporacin. Los elementos de la interfaz no varan con respecto a las vistas anteriores solo en los elementos de acceso a los mdulos de inventarios y costos. La figura 4.54 nos muestra la interfaz:

Figura 4.54. Interfaz Procesar Inventario y Costo. Fuente: Sistema de Informacin SIMIC.

188

Interfaz Procesar Equipos y Costos.

La interfaz procesar equipos y costos muestra la vista para que el usuario, de soporte o administrador, pueda procesar todo lo concerniente a los equipos ingresados, o a ingresar, en el sistema. Entre los elementos destacables estn: o Panel de bsqueda de equipos especficos. o Botn de Agregar Nuevo Equipo. o Botones para Editar Existencia, Editar informacin o eliminar equipos.

Figura 4.55. Interfaz Equipos y Costos. Fuente: Sistema de informacin SIMIC.

189

Figura 4.56. Agregar/Editar Equipos. Fuente: Sistema de Informacin SIMIC.

Interfaz Asignacin.

La interfaz Asignacin muestra la vista en donde el usuario de soporte, en especial el analista de soporte, carga y procesa todas aquellas transacciones en donde un equipo es asignado, o vendido, a un cliente en especfico. Muestra un formulario para el ingreso inicial del cliente al cual se le va a asignar el equipo. Muestra una opcin de bsqueda para localizar de una manera alterna al cliente solicitado, la fecha de la transaccin ser elegida del calendario que se observa en la interfaz, la bsqueda de los equipos que sern asignados se realizara cuando el usuario pulse el botn Agregar y el monto parcial y total de la operacin sern calculados a medida que se ingresen equipos al listado con sus cantidades. La figura 4.56 ensea los elementos de la interfaz de usuario Asignacin:

190

Figura 4.57. Interfaz Asignacin. Fuente: Sistema de Informacin SIMIC.

Interfaz Devolucin.

La interfaz devolucin muestra todas las asignaciones realizadas en el sistema y a travs de ella el usuario soporte, o administrador, podr procesar todas aquellas devoluciones de equipo por parte del cliente debido a algn motivo, falla, avera, etc., que presente ste el cual previamente fue vendido y asignado.

En la figura 4.58 se hace una vista de la interfaz devolucin:

191

Figura 4.58. Interfaz Devolucin. Fuente: Sistema de Informacin SIMIC.

La figura 4.59 muestra la vista al momento de agregar una devolucin de un equipo que fue previamente asignado a un cliente en especfico. Entre los elementos principales estn: cedula/Rif del cliente, nombre del cliente, la fecha de la asignacin, monto por la cual fue hecha la asignacin en ese momento, seguidamente la opcin para que el usuario determine la fecha en que se est solicitando procesar esa devolucin, el motivo de la devolucin, monto de la devolucin, que estar dada por la diferencia de el monto del equipo devuelto y el monto total de la asignacin y los equipos que fueron asignados con la opcin de agregar la cantidad de cada equipo a devolver.

192

Figura 4.59. Agregar Devolucin. Fuente: Sistema de Informacin SIMIC.

Interfaz Desincorporacin.

La interfaz de Desincorporacin se muestra en la figura 4.60 en donde el usuario de soporte, o administrador, como los usuarios que poseen acceso a estos mdulos, podrn sacar del inventario actual los equipos que se encuentren con alguna anomala que impida que puedan ser asignados en alguna venta.

Se muestra una lista de todos y cada uno de los equipos con los paneles de bsqueda de vistas anteriores y la opcin para modificar la existencia del equipo debido a alguna desincorporacin que se realice.

La figura 4.61 mostrara la vista de modificacin de la cantidad debido al descargo.

193

Figura 4.60. Interfaz Desincorporacin. Fuente: Sistema de Informacin SIMIC.

Aqu se muestra el formulario a llenar para solicitar la cantidad de descargo de un equipo en especifico:

Figura 4.61. Descargo del Equipo. Fuente: Sistema de Informacin SIMIC.

194

Interfaz Gestionar Clientes.

La interfaz Gestionar Clientes muestra las opciones para que el usuario pueda gestionar toda la informacin referente a los clientes de la compaa. Se accede a travs del men principal en el modulo de clientes y ensea una vista en donde inicialmente lista a todos los clientes agregados al sistemas. Seguidamente, todas las opciones para procesar la informacin que permita agregar, editar o eliminar un cliente. Esta interfaz tiene similitud con la interfaz de Usuarios posee un panel de bsqueda personalizada y los botones de accin. La figura 4.62 representa a sta interfaz Clientes contenido todos sus elementos:

Figura 4.62. Interfaz Clientes. Fuente: Sistema de Informacin SIMIC.

195

Figura 4.63. Agregar editar clientes. Fuente: Sistema de Informacin SIMIC.

Interfaz Generar Reportes.

La interfaz Generar Reportes muestra las opciones requeridas para procesar la solicitud de los reportes de equipos segn sus status y de acuerdo a un periodo de tiempo determinado.

En primer lugar el usuario tendr la opcin de escoger el reporte debido al parmetro de status de los equipos ya sea por asignacin, devolucin o desincorporacin. El usuario escoge el periodo de tiempo de por el cual se har la consulta y el sistema procesara todo y cada uno de los datos de los equipos que estarn en el informe y arrojara una nueva ventana en un formato pdf para visualizar e imprimir el reporte ejecutado.

Las siguientes figuras muestran las vistas que tendr el usuario al momento de seleccionar visualizar un reporte en especfico:

196

Figura 4.64. Interfaz Tipo de Reporte. Fuente: Elaboracin Propia.

La figura 4.65 muestra la vista de usuario cuando se va a escoger el periodo por el cual se har la consulta de acuerdo al parmetro seleccionado previamente.

Figura 4.65. Periodo de Tiempo de Reporte. Fuentes: Elaboracin Propia.

197

Figura 4.66. Reporte Visualizado (Desincorporacin). Fuente: Elaboracin Propia.

4.3.5. Implementacin.

El flujo de trabajo de implementacin es el centro de la fase de construccin. Se inicia con los resultados del diseo de la etapa de elaboracin, es decir, las clases identificadas, estas conforman los subsistemas, que integrados conforman el sistema. Aqu se desarrolla el cdigo necesario para la construccin de las clases mencionadas.

El cdigo mostrado a continuacin muestra la implementacin de las funciones principales, y ms importantes, de los componentes del sistema. Entre estas funciones podemos mencionar: acceso al sistema por parte del

198

usuario, acceso a la base de datos y las funciones que comprenden al modulo principal del sistema Procesar Inventario y Costo.

4.3.5.1.

Implementacin Modulo Procesar Inventario y Costo.

Funcin para Agregar Equipos al Sistema.


<?php //llamando a las libreras incluidas require_once '../lib/common.php'; include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

//conectar con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Equipo"; $tabla="equipo";

//de haberse enviado la informacin del formulario de agregar equipo if(isset($_POST['aceptar'])) { //dejarse campos obligatorios en blanco if (($_POST['id'] == '') || ($_POST['nombre'] == '') || ($_POST['cantidad'] == '') || ($_POST['costo_texto'] == '0') || ($_POST['cantidad'] == 0)) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Datos imcompletos, no se puede realizar la operacion\")"; echo "</SCRIPT>";

199

} else { //preguntar en la base de datos por el equipo ingresado $consulta2="select * from $tabla where id_equipo=$_POST[id]"; $resultado2=query($consulta2,$conexion); $fila=num_rows($resultado2);

if($fila > 0) {echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"El Codigo ya Existe Asiganado a un Equipo\") parent.cont.location.href=\"equipo_add.php\""; echo "</SCRIPT>";} else {

//insertar el equipo en la base de datos $consulta="insert into ".$tabla." values

('$_POST[id]','$_POST[nombre]','$_POST[tipo]','$_POST[cantidad]','$_POST[costo_ bs]','$_POST[costo_dolar]','$_POST[utilidad]','$_POST[costo_texto]','$_POST[marca ]','$_POST[modelo]')"; $resultado=query($consulta,$conexion); if(!$resultado) { echo type=\"text/javascript\"> alert(\"ERROR\")"; echo "</SCRIPT>"; } "<SCRIPT language=\"JavaScript\"

//cerrar la base de datos cerrar_conexion($conexion);

//script para mandar un mensaje de xito

200

echo"<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Operacion Realizada con Exito\") parent.cont.location.href=\"".$url.".php?pagina=1\" </SCRIPT>"; } } } else { $conexion = conexion_conf(); $consulta="select * from parametros"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado);

} ?>

Funcin para Editar un Equipo.


<?php

//libreras requeridas require_once '../lib/common.php'; include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

//conectando con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Equipo";

201

$tabla="equipo";

//luego de enviar los datos desde el formulario if(isset($_POST['aceptar'])) { //validando que el campo nombre obligatorio no est vacio if (($_POST['nombre'] == '')) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Datos imcompletos, no se puede realizar la operacion\")"; echo "</SCRIPT>"; } else { //actualizando en la base de datos $consulta="update tip_equipo='$_POST[tipo]', costo_dl='$_POST[costo_dolar]', ".$tabla." set nomb_equipo='$_POST[nombre]', costo_bs='$_POST[costo_bs]', utilidad='$_POST[utilidad]',

precio='$_POST[costo_texto]', marca='$_POST[marca]', modelo='$_POST[modelo]' where id_equipo='$_POST[id]'"; $resultado=query($consulta,$conexion); if(!$resultado) { echo type=\"text/javascript\"> alert(\"ERROR\")"; echo "</SCRIPT>"; } "<SCRIPT language=\"JavaScript\"

//cerrando la base de datos cerrar_conexion($conexion);

echo"<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Operacion Realizada con Exito\")

202

parent.cont.location.href=\"".$url.".php?pagina=1\" </SCRIPT>"; } }

//Consultar la base de datos para preguntar por el iva y dolar $conexion = conexion_conf(); $consulta="select * from parametros"; $resultado=query($consulta,$conexion); $fila2=fetch_array($resultado);

//mandar el cdigo segn sea el caso.. post o get. if($_POST['codigo']) { $codigo = $_POST['codigo']; } else { $codigo = @$_GET['codigo']; }

//consultar la base de datos para solicitar la informacin del equipo $consulta2="select * from ".$tabla." where id_equipo='".$codigo."'"; $resultado2=query($consulta2,$conexion); $fila=fetch_array($resultado2); ?>

Funcin para Modificar la Cantidad Existente de un Equipo.


<?php

//libreras requeridas require_once '../lib/common.php';

203

include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

//conectar con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Equipo"; $tabla="equipo";

//se envia la informacion del cambio de cantidad desde el formulario if(isset($_POST['aceptar'])) { //validar que el campo no est vacio.. el sistema no guarda la operacin if (($_POST['cantidad'] == '')) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Datos imcompletos, no se puede realizar la operacion\")"; echo "</SCRIPT>"; } else {

//consulta la base de datos la cantidad del equipo especifico $consulta="select id_equipo='$_POST[codigo]'"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado); $c=$fila[cant_exi]+$_POST[cantidad]; cant_exi from ".$tabla." where

204

//actualizar la base de datos con la nueva cantidad $consulta="update id_equipo='$_POST[codigo]'"; $resultado=query($consulta,$conexion); if(!$resultado) { echo type=\"text/javascript\"> alert(\"ERROR\")"; echo "</SCRIPT>"; } "<SCRIPT language=\"JavaScript\" ".$tabla." set cant_exi='$c' where

//se cierra la conexion con la base de datos cerrar_conexion($conexion); //header echo"<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> parent.cont.location.href=\"".$url.".php?pagina=1\" </SCRIPT>"; } } else {

//Captura el codigo segn el mtodo de envio post o get if($_POST['codigo']) { $codigo = $_POST['codigo']; } else { $codigo = @$_GET['codigo']; }

//Consulta la base de datos para solicitar la informacin del equipo

205

$consulta="select * from ".$tabla." where id_equipo='".$codigo."'"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado); } ?>

Eliminar un Equipo del Sistema.


<?php //librera requerida require_once '../lib/common.php';

//conectar con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Equipo"; $tabla="equipo"; $titulos=array("Codigo","Nombre"); $indices=array("1","2");

//se pulsa la opcin de eliminar el equipo deseado if(isset($_POST['aceptar'])){

//se realiza la consulta para verificar que el equipo no este asignado $consulta_p="select * from asignacion_detalle where

id_equipo='".$_POST["codigo"]."'"; $resultado_p=query($consulta_p,$conexion); $num= num_rows($resultado_p);

if($num > 0) //equipo est asignado {echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\">

206

alert(\"El Equipo Tiene Asignaciones No Puede ser Eliminado\") parent.cont.location.href=\"equipo_list.php\""; echo "</SCRIPT>";} else { //cdigo para eliminar el equipo de la base de datos $consulta="DELETE id_equipo='".$_POST["codigo"]."'"; FROM ".$tabla." where

//ejecutar el query $resultado=query($consulta,$conexion) movimiento"); or die("no se actualizo el

//cerrar la conexin con la base de datos cerrar_conexion($conexion); echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Operacion Realizada con Exito\") parent.cont.location.href=\"".$url.".php?pagina=1\" </SCRIPT>"; }} $codigo = @$_GET['codigo'];

//Consultar la base de datos para solicitar la informacin del equipo $consulta="select * from ".$tabla." where id_equipo='".$codigo."'";; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado); ?>

Funcin para Agregar la Asignacin de un Equipo.


<?php //Libreras requeridas require_once '../lib/common.php';

207

include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

//Conexin con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Asignacion"; $tabla="asignacion";

//cuando se pulsa la opcin guardar y se enva el formulario if(isset($_POST['guardar'])) {

$rs

query("SELECT

max(cod_asig)

as

cod_asig

FROM

".$tabla."",$conexion); while ($row_rs = fetch_array($rs)) { $var_codigo=$row_rs['cod_asig']; } $var_codigo+=1; $ced=$_POST['Cuenta']; $fecha=fecha_sql($_POST['fechaD']); $monto=$_POST['monto'];

//seleccionar el cliente de la asignacin $consulta_cli="select * from clientes where ced_cli='$ced'"; $resultado_cli=query($consulta_cli,$conexion); $fila_cli=fetch_array($resultado_cli); //insertar en la tabla de asignacin

208

$consulta="insert into ".$tabla." (cod_asig,id_cli,fecha,monto) values ('$var_codigo','$fila_cli[id_cli]','$fecha','$monto')"; $resultado=query($consulta,$conexion);

$var_total_reg=$_POST['contador'];

for($i=1; $i<=$var_total_reg; $i++){

$cad_equi="id_equipo".$i; $cad_cant="cantidad".$i; $cad_precio="precio".$i;

$x_cod_equipo = $_POST[$cad_equi]; $x_cantidad = $_POST[$cad_cant]; $x_precio = $_POST[$cad_precio];

//buscar el equipo a asignar $consulta="select * from equipo where id_equipo='$x_cod_equipo'"; $rm=query($consulta,$conexion); $equipo=fetch_array($rm);

$total = $equipo[precio]*$x_cantidad;

//Validando que la cantidad del equipo a asignar sea mayor que 0 if ($x_cantidad>0 && $total>0) { $nueva_can=$equipo[cant_exi]-$x_cantidad; //para insertar en asignacin detalle de la base de datos

209

$var_sql="insert

into

asignacion_detalle

values('$var_codigo','$x_cod_equipo','$x_cantidad','$equipo[precio]','$total',$i)"; $insert=query($var_sql,$conexion); $var_equipo="update id_equipo='$x_cod_equipo'"; $insert=query($var_equipo,$conexion); } } //asignacin guardada echo "<script language=\"javascript\" >alert ('Se guardo la Asignacion!!!') location.href='../menu_int.php?cod=2'</script>"; equipo set cant_exi=$nueva_can where

} else {

$conexion = conexion_conf(); $consulta="select * from parametros"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado); } ?>

Funcin para Guardar una Devolucin de un Equipo.


<?php //libreras requeridas require_once '../lib/common.php'; include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

210

//conectar con la base de datos $conexion=conexion_conf();

$url="equipo_list"; $modulo="Equipo"; $tabla="devolucion";

//se pulsa la el botn para guardar la devolucin y enviar el formulario if(isset($_POST['guardar'])) {

$ced=$_POST['Cuenta']; $fecha=fecha_sql($_POST['fechaDev']); $monto=$_POST['monto']; $monto_asig=$_POST['monto_asig']; $monto_devo=$_POST['diferencia']; $cod_asig=$_POST['cod_asig'];

$rs

query("SELECT

max(cod_dev)

as

cod_dev

FROM

".$tabla."",$conexion); while ($row_rs = fetch_array($rs)) { $var_codigo=$row_rs['cod_dev']; }

$var_codigo+=1;

//se actualiza el monto de la asignacin restndole la devolucin $consulta="update asignacion set monto= $monto_asig where cod_asig = $cod_asig";

211

//se guarda la devolucin en la base de datos $consulta="insert (cod_dev,cod_asig,fecha,motivo,monto) ('$var_codigo','$cod_asig','$fecha','$monto_devo')"; $resultado=query($consulta,$conexion); into ".$tabla." values

$var_total_reg=$_POST['contador'];

echo "<script language=\"javascript\" >alert ('Se guardo la Asignacion!!!') location.href='../menu_int.php?cod=2'</script>";

$conexion = conexion_conf(); $consulta="select * from parametros"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado);

$consulta="select * from asignacion where cod_asig=$_GET[codigo]"; $resultado=query($consulta,$conexion); $fila2=fetch_array($resultado);

$consulta="select * from clientes where id_cli=$fila2[id_cli]"; $resultado=query($consulta,$conexion); $fila22=fetch_array($resultado); if($fila22[tipo_cont]==N) { $rif="V-".$fila22[ced_cli];

212

} else { $rif="J-".$fila22[ced_cli]; }

?>

Desincorporar una Cantidad de un Equipo del Sistema.


<?

//inicia la sesin de usuario para guardar la desincorporacin if (!isset($_SESSION)) { session_start(); }

?>

<?php

//libreras requeridas require_once '../lib/common.php'; include ("../header.php"); include ("../phpmkrfn.php"); include ("../ewupload.php"); require_once '../lib/config.php';

//conectar con la base de datos $conexion=conexion_conf();

$url="equipo_list2";

213

$modulo="Descargo"; $tabla="equipo"; $tabla2="descargo";

//Recibe la informacin segn sea el caso de mtodo de envio if($_POST['codigo']) { $codigo = $_POST['codigo']; } else { $codigo = @$_GET['codigo']; }

//se acepta la desincorporacin y se enva la informacin del formulario if(isset($_POST['aceptar'])) {

//validar que el campo de la cantidad no est vaco.. no se guardara el descargo if (($_POST['cantidad'] == '')) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"Datos imcompletos, no se puede realizar la operacion\")"; echo "</SCRIPT>"; } else { //se consulta la base de datos sobre la cantidad existente $consulta="select cant_exi from ".$tabla." where id_equipo='".$codigo."'"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado);

//se valida que la cantidad ingresada sea mayor que la existente

214

if($_POST[cantidad]>$fila[cant_exi]) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"El descargo NO puede ser MAYOR que la Existencia\") parent.cont.location.href=\"".$url.".php?pagina=1\""; echo "</SCRIPT>"; } else {

$c=$fila[cant_exi]-$_POST[cantidad];

//se actualiza la base de datos $consulta="update id_equipo='$_POST[codigo]'"; $resultado=query($consulta,$conexion); $fecha= date("Y-m-d"); $consulta2="insert (fecha_des,id_equipo,cantidad,id_usuario,motivo) into ".$tabla2." values ".$tabla." set cant_exi='$c' where

('$fecha','$_POST[codigo]','$_POST[cantidad]','$_SESSION[nombre]','$_POST[motiv o]')"; $resultado2=query($consulta2,$conexion); if(!$resultado) { echo "<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> alert(\"ERROR\")"; echo "</SCRIPT>"; }

//se cierra la conexin con la base de datos cerrar_conexion($conexion);

echo"<SCRIPT language=\"JavaScript\" type=\"text/javascript\"> parent.cont.location.href=\"".$url.".php?pagina=1\"

215

</SCRIPT>"; } } }

//Recibe el cdigo segn sea el caso de mtodo de envio if($_POST['codigo']) { $codigo = $_POST['codigo']; } else { $codigo = @$_GET['codigo']; }

//Consulta a la Base de datos por la informacin del equipo $consulta="select * from ".$tabla." where id_equipo='".$codigo."'"; $resultado=query($consulta,$conexion); $fila=fetch_array($resultado);

?>

4.3.6. Pruebas.

El propsito de realizar una serie de pruebas necesarias a cada construccin del sistema es de inspeccionar los resultados de la implementacin de los componentes. Se efectan dos tipos de prueba: la de integracin y la del sistema.

Las pruebas de integracin se realizan en los diferentes componentes del sistema, para as confirmar la correcta comunicacin entre ellos y el buen funcionamiento unitario del software.

216

Para la prueba del sistema, se recurre a un procedimiento conocido como la prueba de la caja negra, as mismo conocido como las pruebas funcionales, las cuales, se realizan sobre cada uno de los mdulos que van hacer interfaz con los usuarios para estudiar sus respuestas a entradas proporcionadas previamente. . 4.3.6.1. Pruebas de Caja Negra.

Las pruebas de caja negra se centran en lo que se espera del mdulo. Estn especialmente dirigidas a los mdulos que van a ser interfaz con el usuario (apariencia de mens, teclas, accesibilidad, canales de comunicacin, etc.), procedimiento que trata de encontrar casos en que el mdulo no se atiene a su especificacin, por eso se denominan pruebas funcionales, donde el probador se limita a suministrar datos como entrada y salida sin preocuparse de lo que pueda estar haciendo el mdulo por dentro o por el cdigo. Estas pruebas siguen la tcnica algebraica conocida como clases de equivalencia, donde cada parmetro de entrada es tratado como un modelo algebraico, donde los datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales, a un conjunto reducido de clases de equivalencia, entonces es suficiente para probar un caso de cada clase, pues los dems datos de la misma clase son equivalentes.

Las interfaces que aceptan datos de entrada por parte de los usuarios en el sistema SIMIC, son las siguientes: Controlar Usuarios donde se agregan y modifican usuarios del sistema, Procesar Equipos y Costos donde se Insertan nuevos elementos de equipos al inventario o se pueden modificar

217

su informacin y Gestionar Clientes, la prueba de caja negra se realizaran en las interfaces mencionadas ya que son las ms significativas en el sistema.

Las clases de equivalencias se identifican de las siguientes maneras:

1. Nmeros 2. Alfabtico 3. Alfanumrico 4. Seleccin

Los diferentes tipos de datos de entrada por grupos son los siguientes:

A. Nombre: Campo donde se escribe el primer nombre del usuario, es alfabtico. B. Apellido: Campo donde se escribe el primer apellido del usuario, es alfabtico. C. Cdula: Campo donde se escribe la cedula del usuario, es alfanumrico. D. Telfono: Campo donde se escribe el nmero telefnico usuario, es numrico. E. Cargo: Campo donde se selecciona el cargo del usuario, es seleccin. F. Usuario: Campo donde se especifica el Login, el cual, es alfanumrico. G. Contrasea: Campo donde se especifica la contrasea del usuario, es alfanumrico. H. Confirmacin de contrasea: Campo donde se vuelve a escribir la contrasea del usuario, es alfanumrico. del

218

I. Mdulos de acceso del sistema: Campos donde se selecciona los mdulos de acceso al sistema dependiendo del cargo del usuario, es seleccin. J. Cdigo: Campo donde se especifica el cdigo del equipo, es alfanumrico. K. Nombre: campo donde se especifica el nombre del equipo, es alfabtico. L. Parte de equipos: Campo donde se especifica la parte en que se encuentra el equipo en el vehculo, es alfabtico. M. Marca de equipo: Campo donde se escribe la del equipo, es alfanumrico. N. Modelo del equipo: Campo donde se especifica el serial del equipo, es alfanumrico. O. Cantidad del producto: Campo donde se escribe la cantidad del equipo, numrico. P. Costos (Bolvares, Dlar): Son los campos donde se especifica el precio del equipo, es numrico. Q. Utilidad: Campo donde se especifica el porcentaje de utilidad del equipo, es numrico. R. Cdula/Rif: Campo donde se especifica el nmero del cliente, es numrico. S. Contribuyente: Campo donde se escribe el nombre completo del cliente, es alfabtico. T. Direccin: Campo donde especifica la direccin del cliente, es alfanumrico. U. Tipo de Contribuyente: Campo donde se selecciona el tipo de contribuyente, es seleccin. Tablas de Identificacin de los Casos de Prueba:

219

Tabla 4.20. Identificacin de los Casos de Prueba (1/4).


Grupo Caso de Prueba Valida No valida Clase de Equivalencia

A A A A B B B B C C C C D D D D E E E E F F F

12345 ABIDS F23HJ S 12345 HJKL GH78KL S 23456 GHJK 567TY S 56789 DFGHJ GH678YU S 234589 FGJSI 44RHJ S 23567 DFGH 879HJ X X X X X X X X

1 2

X X X

3 4 1 2

X X

3 4 1

X X X

2 3 4 1

X X X X X X

2 3 4 1 2 3 4 1 2 3
Fuente: Elaboracin Propia.

220

Tabla 4.20. Identificacin de los Casos de Prueba (2/4).


Grupo Casos de Prueba Valida No valida Clases de Equivalencia

F G G G G H H H H I I I I J J J J K K K K L L

S 12678 FGHJK EFB50 S 3457 FNBMM 678HIK S 12345 WDBNJI AS3457 S 121456 DCVBN 986ZX S 23897 GHJKL 234DCB S 12378 DFGGH X X X X X X X X X X X X

4 1 2 3

4 1 2 3

X X X X

4 1 2 3 4 1 2 3

X X

4 1 2

X X X

3 4 1 2
Fuente: Elaboracin Propia.

221

Tabla 4.20. Identificacin de los Casos de Prueba (3/4).


Grupo Casos de Prueba Valida No valida Clases de Equivalencia

L L M M M M N N N N O O O O P P P P Q Q Q Q

DSC5B S 234567 SDCVBN 345FGM S 12345 DFGBN 34DFG67 S 2345 FGHJD 345FG S 334567 SDFRT 34DCVB S 22345 VGHBN 2WE34R S X X X X X X X X X

X X

3 4 1 2 3

4 1 2 3

4 1

X X X

2 3 4 1

X X X

2 3 4 1

X X X

2 3 4

Fuente: Elaboracin Propia.

222

Tabla 4.20. Identificacin de los Casos de Prueba (4/4).


Grupo Casos de Prueba Valida No valida Clases de Equivalencia

R R R R S S S S T T T T U U U U

123456 SDFG 23ED67 S 34567 DFGG 4RRKL S 23478 DFGT 56FGG S 2345 DFGVB 23XC S

X X X X X X X X X X X X X X X X

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Fuente: Elaboracin Propia.

Las siguientes tabulaciones darn paso a la aplicacin de los valores reales a los distintos casos de prueba donde el sistema acepta datos provenientes del usuario, los cuales se han descrito anteriormente.

223

Aplicacin al Caso de Prueba Agregar Usuario.

Tabla 4.21. Caso de prueba Agregar Usuario. Caso de Prueba Agregar Usuario Nombre: Pedro Entrada Apellido: Caneln Cedula: 16578980 Telfono: 04246675897 Usuario: pc34 Contrasea: 3rr6 Confirmar Contrasea:3rr6 Cargo: Administrador

Los campos son validos. Los nuevos Resultados datos del usuario son guardados en la Base de Datos del sistema. El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC.

Ingresar la informacin del usuario y Procedimiento presionar el botn Agregar.

Fuente: Elaboracin Propia.

224

Aplicacin al Caso de Prueba Modificar Usuario.

Tabla 4.22. Caso de Prueba Modificar Usuario. Caso de Prueba Modificar Usuario Nombre: Pedro Entrada Apellido: Caneln Cedula: 16578980 Telfono: 04246675897 Usuario: pc34 Contrasea: 3rr6 Confirmar Contrasea:3rr6 Cargo: Administrador

Los campos son validos. Los nuevos Resultados datos del usuario son guardados en la Base de Datos del sistema. El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC.

Ingresar la informacin del usuario y Procedimiento presionar el botn Aceptar. Fuente: Elaboracin Propia.

225

Aplicacin al Caso de Prueba Agregar Equipo.

Tabla 4.23. Caso de Prueba Agregar Equipo. Caso de Prueba Agregar Equipo Cdigo : 001AB Entrada Nombre: Empacadura. Parte del Equipo: Motor. Marca del equipo: Pai. Modelo del Equipo: aer45. Cantidad: 150. Costos (Bolvares/ Dlar): 120Bsf. Utilidad: 15% Los campos son validos. Los datos Resultados de los nuevos equipos son

guardados en la Base de Datos del sistema. El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC. Ingresar la informacin del usuario y Procedimiento presionar el botn Aceptar. Fuente: Elaboracin Propia.

226

Aplicacin al Caso de Prueba Modificar Equipo.

Tabla 4.24. Caso de Prueba Modificar Usuario. Caso de Prueba Modificar Equipo Cdigo : 001AB Entrada Nombre: Empacadura. Parte del Equipo: Motor. Marca del equipo: Pai. Modelo del Equipo: aer45. Cantidad: 150. Costos (Bolvares/ Dlar): 120Bsf. Utilidad: 15% Los campos son validos. Los datos Resultados de los nuevos equipos son

guardados en la Base de Datos del sistema. El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC. Ingresar la informacin del usuario y Procedimiento presionar el botn Aceptar. Fuente: Elaboracin Propia.

227

Aplicacin al Caso de Prueba Agregar Cliente.

Tabla 4.25. Caso de Prueba Agregar Cliente. Caso de Prueba Agregar Cliente Cedula/ Rif: 17345678. Entrada Contribuyente: Mario Lpez. Direccin: Barcelona, Urb. El Ingenio, casa 6-56, Quinta San Mario. Tipo de Contribuyente:

El campo Tipo de Contribuyente no Resultados es vlido, los datos del cliente no

son guardados en la Base de Datos del sistema, hasta que se ingrese correctamente el campo Tipo de Contribuyente El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC.

Ingresar la informacin del usuario y Procedimiento presionar el botn Aceptar.

Fuente: Elaboracin Propia.

228

Aplicacin al Caso de Prueba Modificar Cliente.

Tabla 4.26. Caso de Prueba Modificar Cliente. Caso de Prueba Modificar Cliente Cedula/ Rif: 17345678. Entrada Contribuyente: Mario Lpez. Direccin: Barcelona, Urb. El Ingenio, casa 6-56, Quinta San Mario. Tipo de Contribuyente:

El campo Tipo de Contribuyente no Resultados es vlido, los datos del cliente no

son guardados en la Base de Datos del sistema, hasta que se ingrese correctamente el campo Tipo de Contribuyente El usuario que est ingresando los Condiciones datos debe ser del tipo Administrador SIMIC.

Ingresar la informacin del usuario y Procedimiento presionar el botn Aceptar.

Fuente: Elaboracin Propia.

229

4.3.7. Conclusin de la Fase de Elaboracin.

En esta fase de elaboracin se seleccionaron diversas herramientas para el desarrollo de los distintos componentes del sistema. En el flujo de diseo se lograron las diferentes interfaces de interaccin con los usuarios y se implementaron los casos de uso en su totalidad.

La implementacin de los componentes del sistema, se llev a cabo por medio de la construccin de un cdigo que tuvo como base fundamental los diagramas logrados en los dos captulos anteriores, por medio de estos se logra la realizacin da la versin beta del sistema SIMIC. Para obtener un producto con la calidad y confiabilidad necesaria, le fueron aplicadas distintas pruebas al sistema alcanzado, demostrando as, que el producto es estable para ser usado y presenta diversas funcionalidades de valor.

4.4.

FASE DE TRANSICIN

4.4.1. Resumen.

En la fase de transicin tiene como objetivo primordial el preparar el sistema para que ste sea entregado y sea apto para su utilizacin por parte de los usuarios finales. Esto se logra a travs de pruebas realizadas al software en donde el sistema va a operar. Todo ello arroja resultados importantes sobre el correcto funcionamiento del sistema, posibles fallas.

Los posibles cambios que se implementen al sistema sern realizados sobre el producto activo que fue obtenido en la fase previa de construccin,

230

ya que en las fases anteriores se logro la estabilidad necesaria y los requisitos han sido cubiertos en su totalidad. Es decir, se extiende la funcionalidad del sistema obtenido para garantizar que se cumplan con los requisitos y necesidades que los usuarios han solicitado satisfacer.

Es necesario, una vez finalizadas las pruebas que dar el producto a los usuarios finales, que stos reciban el debido entrenamiento y documentacin que ser til para el manejo del programa. Para esto, se instalar el sistema SIMIC en el servidor ubicado en el departamento de soporte de la empresa Diesel Oriente C.A. Una vez instalado, se realizaran las pruebas finales, en conjunto con los usuarios que interactuaran con el sistema, para lograr un correcto, total y definitivo funcionamiento ptimo. En la figura 4.67, se muestran las fases y flujos de trabajo del proceso unificado para la fase de transicin.

Figura 4.67. Fases y Flujos de Trabajo del Proceso Unificado (Transicin). Fuente: Elaboracin Propia.

231

La fase de transicin finaliza con los siguientes resultados:

Lnea base del producto completo y corregido que incluye todos los modelos del sistema.

Se han alcanzado los objetivos fijados en la fase de Inicio.

El usuario est satisfecho.

Lanzamiento del producto.

4.4.2. Lanzamiento de la versin beta.

Este proceso se iniciar con la instalacin del sistema en el entorno de operacin dentro de la empresa, que ser el Departamento de Soporte, all se citaran a los empleados del mismo en los que estarn: el administrador del sistema, los usuarios de soporte integral y un representante por parte de los empleados en general.

Una vez instalado el programa, el uso del mismo por parte de los usuarios finales dar por concluida la fase de transicin.

4.4.3. Conclusin de la fase de transicin.

En esta fase de transicin los cambios anunciados en el resumen no dieron lugar de un modo significativo, es decir no fueron necesarios la implementacin de cambios importantes sobre los componentes del software.

232

Esto nos dice que los objetivos planteados en las fases iniciales del proyecto fueron cubiertos y comprueban la robustez y estabilidad de la lnea base de la arquitectura.

Finalmente, el sistema ha cubierto las expectativas y requerimientos de la empresa Diesel Oriente C.A., por lo cual el lanzamiento del programa fue realizado con xito y las necesidades de los usuarios finales fue cubierta en su totalidad.

233

CONCLUSIONES
Una vez cumplidas en su totalidad con todas las fases del Proceso Unificado de Desarrollo de Software, implantado para la construccin del sistema de informacin, denominado SIMIC, basado en un entorno web para el manejo de inventario y costos de la empresa Diesel Oriente C.A., se concluy lo siguiente:

1. En el proceso del manejo del inventario y control de costos llevado a cabo en la empresa Diesel Oriente C.A. se encontraron deficiencias debido a que no cuenta con una herramienta automatizada, que permita llevar el registro de la informacin correctamente, lo que genera prdida de tiempo al personal y ocasiona, en oportunidades, perdidas de datos valiosos para la empresa.

2. Se analiz del estado actual de cmo se distribuye la informacin en la compaa para determinar las actividades y los procesos necesarios que posteriormente daran como resultados la obtencin de los requerimientos del nuevo sistema y de los distintos mdulos que ste posee.

3. Para el diseo del sistema, parte inicial del proyecto, se utilizo la herramienta UML, la cual permiti visualizar, especificar, construir y documentar cada una de las actividades involucradas.

4. Para el anlisis y comprensin del diseo preliminar de SIMIC, se utilizaron los diagramas de casos de uso para la identificacin y captura de los requisitos adecuados para la estructura interna del

234

sistema. Los diagramas de clases de anlisis, para transformar y comprender los diagramas de casos de uso y la forma en que los objetos se relacionan e interactan entre s. Los diagramas de colaboracin que van a mostrar la interaccin que consta un conjunto de objetos y los mensajes enviados entre ellos. Por ltimo, los diagramas de clases de diseo que permitieron visualizar la estructura esttica del sistema y poder definir cada una de las clases identificadas para el sistema propuesto. Todo ello permiti conocer la arquitectura de la lnea base del sistema.

5. Se aplicaron niveles de acceso para los usuarios para garantizar la confiabilidad de la informacin procesada en el sistema. todo ello, debido a que la compaa maneja gran volumen de datos y la integridad de los datos se vera amenazada por el uso indebido de algn usuario malintencionado.

6. Para el almacenamiento de los registros de equipos y sus estados dentro de la empresa, as como tambin los clientes y usuarios que interactan con el sistema, se elaboro una estructura de base de datos relacional que garantiza el control de esta informacin en el momento deseado y evitando los problemas de redundancia en las existencias.

7. Las interfaces fueron diseadas de una manera que fueran de gran valor a los usuarios finales, que puedan ser manejados de una manera sencilla, amigable, que identificara a la empresa donde opera y en donde cualquier usuario nuevo en el sistema pudiera comprender de una manera rpida.

235

8. Los componentes del sistema SIMIC fueron diseados de modo tal que pudieran permitir futuras modificaciones, ampliaciones y mejoras en su funcionamiento para nuevas necesidades.

9. El uso del lenguaje de programacin PHP y del manejador de bases de datos MySQL, como piezas clave de la estructura de un entorno Web, facilit el desarrollo del sistema de forma precisa y eficaz, debido a que estas herramientas poseen requerimientos de funcionamiento mnimo y permiten crear aplicaciones complejas que pueden ser comprendidas de una manera rpida y fcil.

10. Las pruebas realizadas en la fase de construccin pudieron determinar la forma efectiva en que el sistema trabaja, sin errores y de manera eficiente en cada uno de los mdulos que posee.

236

RECOMENDACIONES
1. Es necesario que el espacio disponible en disco para el hospedaje del sistema y el almacenamiento de registro sea lo suficientemente grande ya que los cambios que en un futuro que se le hagan al sistema y la cantidad de informacin que por tiempo prolongado se inserte en l pueden requerir mayor cantidad de memoria en disco.

2. Desarrollar futuras actualizaciones al sistema, que permitan la automatizacin de otros procesos realizados en la empresa Diesel Oriente C.A. Se recomiendan posibles mdulos que pueden intervenir ms en el proceso de compra y venta de los repuestos y los procesos de importacin y exportacin que la empresa pueda realizar en un futuro ya que es uno de sus puntos principales en una prxima expansin de su cartera de negocios.

3. Aunque se estipula en la fase de transicin, el adiestramiento al personal debe ir reforzndose a medida que surgen nuevas tcnicas de automatizacin, nuevas tecnologas e intervienen nuevos usuarios a las actividades contempladas en el sistema. Todo esto, con la finalidad de tener empleados preparados con el uso de esta herramienta informtica, garantizando la seguridad y funcionamiento ptimo de dicho sistema.

237

BIBLIOGRAFIA
Arias, F. (2004). El proyecto de investigacin: Introduccin a la Metodologa cientfica. (4 ed.). Caracas: Espteme.

Bertalanffy Von, L. (1976). Teora General de los Sistemas. Ciudad de Mxico: Fondo de Cultura Econmica.

Booch, G., Jacobson, I. y Rumbaugh, J. (1999). El Proceso Unificado de Desarrollo de Software. UML. (1 ed.). Madrid: Addison - Wesley Iberoamericana.

Cedeo, J. (2007). Desarrollo de una Aplicacin Web para el Registro, Manejo, Control de Eventos Organizados por la Unidad de Calidad de Vida del Departamento de Recursos Humanos de PDVSA-Refinacin Puerto la Cruz. Trabajo de Grado no publicado. Universidad de Oriente, Puerto la Cruz.

Cohen, D. y Asn, E. (2000). Sistemas de Informacin para los Negocios. (3a ed.). Ciudad de Mxico: Mc Graw Hill.

Fowler, M. y Scott K. (1997). UML Gota a Gota. (1 ed.). Ciudad de Mxico: Pearson Addison Wesley.

Harwryszkiewycz, T. (1994). Analisis y diseo de Base de Datos. (3 ed.). Ciudad de Mxico: Megabyte.

238

Post, G. (2006). Sistemas de Administracin de Bases de Datos. (3 ed.). Ciudad de Mxico: Mc Graw Hill.

Pressman, R. (2002). Ingeniera del Software. (5 ed.). Madrid: Mc Graw Hill.

Rojas, H. (2008). Diseo de un Sistema de Informacin para la Automatizacin del Proceso de Facturacin y Cobranza de la Carga Transportadora por las Empresas Registradas en el Puerto de Guanta. Trabajo de Grado no publicado. Universidad de Oriente, Puerto la Cruz, Venezuela.

Sabino, C. (2005). Metodologa de la Investigacin. (3 ed.) Argentina: El Cid.

Snchez, M. (2005). Diseo de un Sistema de Informacin para Automatizar Algunas de las Actividades Relacionadas con el Proceso de Produccin de Crudo y Gas desde el Yacimiento hasta las Estaciones de Flujo, que se Realizan en una Empresa Petrolera, en Punta de Mata. Trabajo de Grado no publicado. Universidad de Oriente, Puerto la Cruz, Venezuela. Schmuller, J. (1999). Aprendiendo UML en 24 Horas. (1 ed.). Madrid: Prentice Hall.

Serritielo, K. (2007). Diseo de un Sistema de Informacin para el Proceso de Asignacin de Citas a los Pacientes de una Institucin Diagnstica. Trabajo de Grado no publicado. Universidad de Oriente, Puerto la Cruz, Venezuela.

239

Sifontes, M y Carrin, A. (2005). Diseo de un Sistema de Informacin para el Control de los Servicios de la Gerencia de ventas de la Empresa CANTV., Regin Oriental. Trabajo de Grado no publicado. Universidad de Oriente, Puerto la Cruz, Venezuela.

Welling, L. y Thomson, L. (2005). Desarrollo Web Con PHP y MySQL. (3 ed.). Madrid: Anaya Multimedia.

240

ANEXO: MANUAL DE USUARIO

MANUAL DE USUARIO SIMIC

241

TABLA DE CONTENIDO

1. Introduccin. 2. Accesar al Sistema. 3. Interfaz Principal. 4. Interfaz Realizar Configuracin. 4.1. Controlar Usuarios. 4.1.1. Agregar Usuarios. 4.1.2. Editar Usuarios. 4.1.3. Eliminar Usuarios. 4.2. Interfaz Ajustar Costo. 4.3. Interfaz Respaldar Datos. 4.4. Interfaz Recuperar Datos. 5. Interfaz Procesar Inventario y Costo. 5.1. Interfaz Procesar Equipos y Costos. 5.1.1. Agregar Equipo. 5.1.2. Modificar Equipo. 5.1.3. Modificar Existencia. 5.1.4. Eliminar Equipo. 5.2. Interfaz Asignacin. 5.3. Interfaz Devolucin. 5.4. Interfaz Desincorporacin. 6. Interfaz Gestionar Clientes. 6.1. Agregar Cliente. 6.2. Editar Cliente. 6.3. Eliminar Cliente. 7. Interfaz Generar Reportes.

242

1. Introduccin.

La funcin principal del manual de usuario presentado en este documento, es la de dar soporte y ayuda que sirva de una eficaz gua para la correcta manipulacin del software SIMIC (Sistema de Informacin para el Manejo de Inventarios y Costos) y optimizar todas y cada una de las funcionalidades que ste programa presenta.

SIMIC es una herramienta desarrollada con la finalidad de automatizar los procesos de manejo de la informacin de los equipos y repuestos contenidos en el inventario de la compaa Diesel Oriente C.A., y as aportar una solucin a los inconvenientes de los procesos manuales,

simplificndolos, agilizndolos y brindando, a su vez, la comodidad, la seguridad realizado. y confidencialidad necesaria, con el fin optimizar el trabajo

Dentro de las tareas principales del sistema SIMIC se encuentra proceso de la informacin de todos y cada uno de los equipos del inventario como: Ingreso de nuevos elementos, editar o eliminar equipos en especficos, registro del cambio de status segn su manipulacin en el inventario. Adicionalmente, el manejo de la informacin de usuarios del sistema, clientes de la empresa, respaldo y recuperacin de datos y la opcin de generar reportes con datos veraces y oportunos sobre informacin vital.

A continuacin se muestran las descripciones de todas estas tareas del sistema SIMIC.

243

2. Accesar al Sistema.

La seguridad del sistema SIMIC es el elemento primordial para mantener la informacin que all se encuentra, de una manera resguardada de una manipulacin que no est contemplada y que haya sido realizada por personas ajenas a la compaa. Es por eso que solo usuarios registrados con un nombre de usuario y contrasea, previamente otorgadas por el administrador del sistema, sern los que tendrn, segn su nivel de privilegio, el acceso total o parcial a los mdulos del programa.

Figura A1. Accesar al Sistema.

Al ingresar al sistema saldr la primera interfaz llamada Accesar al Sistema, donde resaltara este espacio elaborado para que el usuario coloque su nombre y contrasea proporcionadas. Seguidamente pulsar el botn Aceptar para comenzar a trabajar y dirigirse a la interfaz principal.

244

3. Interfaz Principal.

Una vez ingresados los datos y obtener el acceso al sistema, aparecer la interfaz principal de usuario donde resaltar una imagen representativa de la compaa Diesel Oriente C.A., logo del sistema SIMIC, identificacin del usuario que est abriendo sesin y del lado izquierdo el men principal de los mdulos del sistema.

Figura A2. Interfaz Principal.

Como se describi anteriormente, se observa el men principal del lado izquierdo de la pantalla que contiene los mdulos de acceso a los distintos componentes del programa: Realizar Configuracin, Procesar Inventario y Costo, Gestionar Clientes y Generar Reportes. En la Figura A2 se muestra este men de componentes.

245

Este men estar presente en todas y cada una de las interfaces de usuario del sistema SIMIC y dar la opcin para que el usuario pueda moverse a travs de ellos de una manera rpida con solo pulsar en cualquiera de los botones que prefiera.

Figura A3. Men de los Mdulos del Sistema.

El usuario solo tendr acceso al modulo de Configuracin, los dems mdulos tendr acceso solo para soporte tcnico previo aviso del usuario encargado del mismo.

4. Interfaz Realizar Configuracin.

Esta interfaz es muy importante para el buen funcionamiento del sistema. En esta parte el usuario administrador podr procesar toda la informacin de todos y cada uno de los usuarios encontrados en el inventario. Agregar nuevos elementos al sistema, editar sus datos, y eliminar un usuario especfico.

Esta seccin es muy importante ya que el administrador podr cambiar los parmetros por los cuales se ajustan los precios de todos los equipos. Adicionalmente, la base de datos puede, debido a alguna falla, ser respaldada y enviada a una ubicacin segura en una unidad de almacenamiento y a la vez ser recuperada en el momento que se desee para dar mantenimiento al software.

246

Figura A4. Interfaz Realizar Configuracin.

En esta interfaz el usuario administrador obtiene las opciones para procesar a los usuarios, ajustar los costos y respaldar y recuperar los datos de la base de datos. La figura A5 mostrara con detalles los iconos de acceso de este modulo de configuracin.

Figura A5. Men Configuracin.

247

4.1.

Controlar Usuarios.

La interfaz de usuario Controlar Usuarios servir para que el administrador del sistema pueda, manejar de una manera completa toda la informacin referente a los usuarios nuevos o ya registrados en el sistema.

Al entrar en esta opcin el administrador puede observar una lista de todos los usuarios registrados hasta el momento en el sistema y las diferentes opciones que puede pulsar para editar un usuario en especifico, eliminarlo o agregar uno nuevo a la base de datos de SIMIC.

Figura A6. Interfaz Controlar Usuarios.

Es necesario notar la opcin de bsqueda ubicada en la parte superior encima del listado de usuarios del sistema. en esta busca el administrador

248

podr localizar a un usuario o un grupo de ellos, de una manera rpida, a travs del nombre de usuario.

Figura A7. Bsqueda de Usuarios.

En la figura A8 puede observarse los botones para agregar, editar o eliminar un usuario determinado que se elija del listado mostrado anteriormente.

Figura A8. Botones para Agregar, Editar o Eliminar Usuarios.

4.1.1. Agregar Usuario.

En esta seccin se agregan nuevos usuarios al sistema, dndoles un tipo y estado determinado, que definir su futura interaccin con la aplicacin.

249

Figura A9. Agregar Usuario.

Para agregar el nuevo usuario el administrado deber rellenar todos los campos mostrados en la figura anterior: Nombre, Apellido, Cedula, Telfono, Cargo, Nombre de Usuario, Contrasea, Confirmacin de la Contrasea y en la parte de abajo del formulario muestra unos combos de seleccin para determinar el nivel de acceso que tendr el nuevo usuario para manejar el sistema o los mdulos a los cuales podr accesar. Una vez ingresados todos los datos se deber pulsar el botn aceptar para eviar los datos y registrar la persona en la base de datos.

4.1.2. Editar Usuarios.

Al pulsar el botn de editar usuario en el listado de usuarios inicial, el sistema muestra una vista idntica a la mostrada para agregar un usuario, solo que estar ya rellenada con la informacin a editar del usuario.

250

Figura A10. Editar Usuario.

Una vez cambiada la informacin deseada se pulsa el botn de aceptar para registrar el cambio en el sistema.

4.1.3. Eliminar Usuarios.

Para eliminar un usuario el administrador en el listado de usuarios deber pulsar el botn con figura de papelera en el usuario especifico, luego se mostraran los datos del usuario a eliminar y se debe pulsar el botn Aceptar para confirmar la eliminacin.

Figura A11. Eliminar Usuario.

251

4.2.

Interfaz Ajustar Costo.

Esta interfaz provee la opcin para que el usuario administrador pueda modificar los parmetros que definen los precios de los equipos, IVA y Dlar. La interfaz muestra unos campos de textos con los valores actuales de los parmetros que pueden ser modificados. Al colocar el valor deseado se debe proceder a pulsar el botn de Aceptar para registrar el cambio realizado. Automticamente cambiaran, a parte de los parmetros mencionados, los precios de los equipos en el inventario. En la parte superior de la vista estar el botn de regresar para no realizar ningn cambio.

Figura A12. Interfaz Ajustar Costo.

4.3.

Interfaz Respaldar Datos.

La interfaz Respaldar Datos es una de las interfaces de usuarios ms importantes dentro del sistema SIMIC. A travs de ella el usuario administrado puede hacer una copia de seguridad de toda la base de datos y guardarla en una ubicacin segura para realizar al software cualquier tipo de mantenimiento y soporte.

Al pulsar la opcin de respaldo de datos, el sistema da la opcin para guardar la base de datos en la direccin que el usuario administrador desee, ya sea en el disco duro o alguna unidad de almacenamiento extrable.

252

Figura A13. Interfaz Respaldo de Datos.

4.4.

Interfaz Recuperar Datos.

La interfaz recuperar datos puede restaurar la base de datos respaldada previamente para activarla en el sistema debido a alguna falla externa que haya dejado la base de datos corrupta. Al pulsar esta opcin el sistema proporciona la oportunidad de buscar la direccin donde se ha guardado la copia de seguridad de la base de datos y al ubicarla se debe pulsar la opcin Restaurar.

La figura A14 muestra la vista que tendr el usuario al momento de restaurar una base de datos respaldada previamente.

253

Figura A14. Interfaz Recuperar Datos.

5. Interfaz Procesar Inventario y Costo.

La interfaz Procesar Inventario y Costos es el modulo vital del Sistema de Informacin de Inventarios y Costos (SIMIC). En esta parte del sistema, el usuario, en especfico los usuarios de soporte, Analista de Soporte Integral y Supervisor de Soporte Integral, podrn manipular de una manera directa el inventario de la compaa y los costos de los equipos asociados. Aadido a esto, estos usuarios que tienen acceso a este modulo pueden registrar y los status de los equipos, si son asignados, devueltos por el cliente o desincorporados del sistema debido a alguna falla que presenten.

Esta dividido en 4 interfaces de usuarios los cuales son: Procesar Equipos y Costos, Asignacin, Devolucin y Desincorporacin.

La figura A15 muestra la vista que tendr el usuario al momento de seleccionar la opcin de Procesar Inventario y Costo.

254

Figura A15. Interfaz Procesar Inventario y Costo.

5.1.

Interfaz Procesar Equipos y Costos.

La interfaz de Equipos y costos dar la opcin al usuario de soporte para poder procesar toda la informacin de los equipos registrados en el sistema y agregar nuevos elementos al mismo. La interfaz, para seguir con la secuencia y darle al usuario una ayuda a manejar mas intuitivamente el programa, trabaja de manera similar a controlar usuarios.

Al ingresar en esta interfaz el sistema mostrara un listado de todos y cada uno de los equipos registrados en el sistema, asi como tambin las opciones para agregar, editar alguna, cambiar su existencia o eliminar cualquier elemento elegido.

255

Figura A16. Interfaz Procesar Equipos y Costos.

Como puede observare, la interfaz muestra una gran similitud con la interfaz de controlar usuarios que ya se ha descrito. De esta forma el manejo del sistema se hace de una manera mas intuitiva y mucho mas fcil al usuario.

5.1.1. Agregar Equipo.

Figura A17. Agregar Equipo.

256

Para agregar un equipo al sistema se debe rellenar todo los campos mostrados en el formulario de la figura A17. En la seccin de Calculo de Precio, estarn las opciones para calcular de una manera automtica el precio del equipo. El campo de costo en Bs., ste campo de texto ser rellenado por el costo en bolvares del equipo adquirido por la empresa en el caso que haya sido adquirido en el mercado nacional. El campo Coto en Dr$ ser rellenado cuando el equipo es importado y su pago fue realizado en moneda extranjera. Seguidamente, el campo ganancia ser rellenado con el porcentaje de ganancia que la empresa desea obtener con la venta del equipo. Al ingresar todo estos valores en el formulario automticamente el campo texto ser calculado con el precio final del equipo.

5.1.2. Modificar Equipo.

La interfaz modificar equipo posee las mismas caractersticas de la interfaz de agregar equipo, con la diferencia de que sus campos estn rellenados con la informacin previamente ingresada cuando se agrego ese equipo en particular. Los campos estarn disponibles para ser modificados y al pulsar el botn de Aceptar se confirmara el cambio y los nuevos datos sern registrados en la base de datos.

La figura A18 muestra la vista de usuario al momento de modificar un usuario.

257

Figura A18. Modificar Usuario.

5.1.3. Modificar Existencia.

Al registrar un equipo en especfico queda registrado una cantidad del mismo en la base de datos, se pueden agregar al mismo tipo de equipo, elementos similares que son producidos en lotes. Al momento de ingresar un equipo cuyo tipo, nombre y caractersticas han sido agregados anteriormente, puede sumarse a la existencia del equipo ya ingresado. Para modificar estos valores pulsamos el botn en forma de smbolo de adicin en color verde y colocamos en nmero deseado.

258

Figura A19. Botn para Agregar a la Existencia del Equipo.

Al pulsar este botn el sistema nos ofrece una vista donde nos indica la existencia actual y un campo de texto para el ingreso de la cantidad de equipos de ese mismo tipo a ingresar. Al finalizar se confirma la operacin al pulsar el botn Aceptar.

Figura A20. Agregar Existencia.

5.1.4. Eliminar equipo.

La eliminacin de algn elemento del inventario se realiza al pulsar el botn de papelera en el listado de equipos de la interfaz de equipos y costos, de una forma similar al momento de eliminar algn usuario.

259

5.2.

Interfaz de Asignacin.

La interfaz de Asignacin permite al usuario de soporte, en este caso al analista de soporte integral, registrar la vinculacin o asignacin de equipo o un grupo de ellos a un cliente que los ha adquirido a travs de la venta. La figura A21 muestra que pulsar la opcin de asignacin, en la interfaz de Inventario y Costo, se observan campos de texto para ingresar, en primer lugar, al cliente que est solicitando el equipo. El cliente puede localizarse ingresando la cedula directamente en el campo de texto mostrado o presionando el botn buscar que abrir una lista de todo los clientes registrados en el sistema. La figura A22 muestra la lista. Para seleccionar a un cliente se pulsa el botn en forma de signo de adicin de color verde.

Figura A21. Interfaz Asignacin.

Seguidamente se selecciona la fecha en la cual se est registrando la asignacin y se pulsa el botn de Agregar el cual mostrara un listado de todos los equipos para elegir aquellos que son solicitados para su asignacin.

260

Figura A22. Listado de Clientes.

Figura A23. Listado de Equipos.

261

Por ltimo, se ingresa la cantidad de cada equipo a asignar, automticamente el monto total se calcula y se guarda en el campo de texto ubicado seguidamente de la fecha de asignacin, luego se pulsa el botn de Grabar para registrar la asignacin y confirmar la operacin.

Figura A24. Vista Final de la Asignacin.

5.3.

Interfaz Devolucin

La Interfaz Devolucin proporciona la opcin al usuario analista de soporte integral para poder registrar aquellos equipos, que previa asignacin a un cliente, son devueltos por algn motivo en especifico. La interfaz muestra un listado con todas las asignaciones registradas hasta el momento y del cual se seleccionara uno de ellos para registrar los equipos que el cliente est por devolver.

262

Figura A25. Interfaz Devolucin.

Al pulsar en la asignacin solicitada, se observa una vista de usuario donde se presentan los datos de la asignacin previa registrada, datos del cliente, fecha de la asignacin, monto total. Seguido a estos las opciones para seleccionar los datos para el registro de la devolucin: fecha de la devolucin, motivo de la devolucin y un campo donde se guardara el monto de la devolucin, o suma de los precios de los equipos devueltos, y la diferencia entre la devolucin y la asignacin.

Para seleccionar los equipos que el cliente solicita devolver, y la cantidad de ellos, se presenta un listado con los equipos vendidos, las cantidades asignadas y un campo para escribir las cantidades a devolver. En este momento los montos nombrados anteriormente se calcularan de manera automtica. Se pulsa la opcin grabar para registrar la devolucin.

263

Figura A26. Registro de la Devolucin.

5.4.

Interfaz Desincorporacin.

Los equipos en el inventario pueden sufrir desperfectos por humedad, anomalas en su funcionamiento debido al polvo, etc. Estos equipos quedaran, en ese momento, imposibilitados para ser asignados a algn cliente en una venta. Esta interfaz procesa la desincorporacin de stos equipos que son sacados o descargados del inventario para poder ser reparados o devueltos a los proveedores de donde fueron adquiridos.

Se pulsa la opcin de desincorporacin del men de Inventario y el sistema proporciona un listado de todos los equipos y la opcin para descargar las cantidades deseadas del mismo.

264

Figura A27. Interfaz Desincorporacin.

Figura A28. Cantidad a Descargar y Motivo.

6. Gestionar Clientes.

La Interfaz de Gestionar clientes permite al usuario, en este caso de tipo empleado, a procesar toda la informacin de los clientes de la empresa. Principalmente la forma de control y manejo de esta informacin es similar a como se gestionan los datos de los usuarios en el modulo de configuracin.

Se muestra un listado de todos los clientes registrados en el sistema y las opciones para editar sus datos, eliminar sus datos o agregar nuevos registros de clientes a la base de datos.

265

Figura A29. Interfaz Gestionar Clientes.

6.1.

Agregar Nuevo Cliente.

Para Agregar a un nuevo cliente, se pulsa la opcin en el botn Agregar en la parte superior, el cual har que el sistema muestre una vista de usuario donde el empleado podr ingresa los datos del cliente y opcional datos si este llegara a ser una persona jurdica. La figura A30 muestra el formulario para agregar nuevo cliente y presionar el botn Aceptar para registrar los datos y confirmar el proceso.

Figura A30. Formulario para Agregar Nuevo Usuario.

266

6.2.

Editar un Cliente.

Para editar a un cliente debe pulsarse el botn en el cliente escogido en el listado con el botn en forma de lpiz. La vista de usuario resultante ser la misma que en otras interfaces de edicin de datos, similar a la figura anterior pero con los campos rellenados de la informacin del cliente que previamente se ha agregado.

6.3.

Eliminar a un Cliente.

La eliminacin de un cliente se obtiene pulsando el botn en forma de papelera en el cliente en especfico escogido del listado. La vista resultante contendr campos con la cedula o rif del cliente, nombre y apellido. Pulsando la opcin Aceptar el registro del cliente ser eliminado de la base de datos del sistema.

Figura A31. Eliminar un Cliente.

7. Interfaz Generar Reportes.

En esta seccin, los usuarios pueden realizar reportes sobre el estado de toda la informacin de los procesos de Asignacin, Devolucin y Desincorporacin de equipos en el sistema, de manera rpida y sencilla, slo es necesario llenar una serie de parmetros y listo.

267

En primer lugar al pulsar la opcin de Generar reportes del men izquierdo de los mdulos del sistema, se genera una vista para el usuario que permite escoger el tipo de consulta que arrojara el reporte requerido. La figura A32 muestra los tipos de reporte a seleccionar.

Figura A32. Tipo de Reporte a Seleccionar.

Una vez seleccionado el tipo de consulta que se requiere del sistema para que ste genere el informe, se selecciona el periodo de tiempo por el cual se generara el reporte. Esto se realiza ingresando en dos campos de texto la fecha de inicio o fin de la consulta o pulsando el calendario ubicado al lado de los campos se podr seleccionar el da exacto.

Figura A33. Seleccin del Periodo del Reporte.

268

Por ltimo el sistema mostrara una pantalla adicional, ubicada en una ventana diferente donde mostrara un archivo en pdf con el reporte generado de la consulta que se realizo, el usuario podr optar por guardar o imprimir el informe mostrado. La figura A34 muestra un ejemplo de un reporte de tipo Desincorporacin.

Figura A34. Ejemplo de Reporte Generado.

269

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:

DESARROLLO
TTULO

DE

UN

SISTEMA

DE

INFORMACIN

BASADO EN ENTORNO WEB PARA EL CONTROL DE INVENTARIOS Y COSTOS DE UNA COMPAA

COMERCIALIZADORA DE REPUESTOS AUTOMOTRICES UBICADA EN BARCELONA, ESTADO ANZOTEGUI.


SUBTTULO

AUTOR (ES): APELLIDOS Y NOMBRES Noriega G., Rosio C. CDIGO CULAC / E MAIL CVLAC: V-17.223.733 E MAIL: rossnorieg@hotmail.com CVLAC: E MAIL: Alemn DL ., Peter A. CVLAC: V-17.222.896 E MAIL: aleman859@hotmail.com CVLAC: E MAIL:

PALBRAS O FRASES CLAVES: _________________________________________________________ INVENTARIO _________________________________________________________ COSTO _________________________________________________________ EQUIPOS _________________________________________________________ ASIGNACION _________________________________________________________ DEVOLUCION _________________________________________________________ SISTEMA _________________________________________________________ 270

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:

REA

SUBREA

Ingeniera y Ciencias Aplicadas

Departamento Sistemas

de

Computacin

RESUMEN (ABSTRACT):

El presente proyecto desarroll un sistema de informacin basado en una entorno Web para el control de inventarios y costos de una Compaa Comercializadora de Repuesto Automotrices ubicada en Barcelona, Estado Anzotegui. Este sistema contribuye una solucin a los inconvenientes que presentan los procesos de inventario y costos para agilizar estos procesos y brindar la comodidad,

seguridad y confidencialidad necesaria con la finalidad de mejorar el trabajo que realiza la empresa citada anteriormente. Para el desarrollo y construccin del sistema se utilizaron herramientas de la ingeniera de software como el Lenguaje de Modelado Unificado (UML) y se tom como base fundamental la implantacin del Proceso Unificado del Desarrollo de Software, que se refiere a un marco de desarrollo iterativo e incremental compuesto de cuatro fases, est dirigido por casos de uso y es centrado en la arquitectura. Se utiliz el lenguaje de programacin PHP y bases de datos relacionales con MySQL.________________

271

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:

CONTRIBUIDORES: APELLIDOS Y NOMBRES ROL / CDIGO CVLAC / E_MAIL ROL CVLAC: E_MAIL E_MAIL CA AS

Cortnez, Claudio

x TU

JU

V-12.155.334 c_cortinez@hotmail.com

Ortiz, Mercedes

ROL CVLAC: E_MAIL E_MAIL

CA

AS

TU

JU

mercedes04@yahoo.com

Mujica, Vctor

ROL CVLAC: E_MAIL E_MAIL ROL CVLAC: E_MAIL E_MAIL

CA

AS

TU

JU

victormujica@hotmail.com

CA

AS

TU

JU

FECHA DE DISCUSIN Y APROBACIN:

2010 AO

07 MES

27 DA

LENGUAJE. SPA

272

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:


ARCHIVO (S): NOMBRE DE ARCHIVO TESIS. Inventarios y Costos.doc TIPO MIME Application/msword

CARACTERES EN LOS NOMBRES DE LOS ARCHIVOS: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z.

abcdefghijklmnopqrstuvwxy

z. 0 1 2 3 4 5 6 7 8 9.
ALCANCE ESPACIAL: ___________________________________ (OPCIONAL) TEMPORAL: ___________________________________ (OPCIONAL)

TTULO O GRADO ASOCIADO CON EL TRABAJO:

Ingeniero de Sistemas_______________________________________
NIVEL ASOCIADO CON EL TRABAJO:

Pregrado__________________________________________________
REA DE ESTUDIO:

Departamento de Computacin y Sistemas________________________


INSTITUCIN:

Universidad de Oriente / Ncleo Anzotegui_______________________

273

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:

DERECHOS

De acuerdo al artculo 41 del reglamento de trabajos de grado________________ _________________________________________________________________ Los Trabajos de Grado son de la exclusiva propiedad de la Universidad de ____ Oriente, y solo podrn ser utilizados a otros fines con el consentimiento del____ Consejo de Ncleo respectivo, quien deber participarlo previamente al Consejo Universitario, para su autorizacin._____________________________________ _________________________________________________________________ _________________________________________________________________

Alemn DL., Peter A.

Noriega G., Rosio C.

AUTOR

AUTOR

AUTOR

Cortnez, Claudio

Ortiz, Mercedes

Mujica, Vctor

TUTOR

JURADO

JURADO

Rojas, Luis F.

POR LA SUBCOMISION DE TESIS

274

También podría gustarte