DESARROLLO DE UN SISTEMA DE CONTROL DE ...repository.udistrital.edu.co/bitstream/11349/2374/1...7 Figura 37. Diagrama Caso de Uso para REQ-FNC-11 77 Figura 38. Diagrama de Secuencia

DESARROLLO DE UN SISTEMA DE CONTROL DE INVENTARIO FÍSICO Y DE SOFTWARE BAJO UNA ARQUITECTURA WEB IMPLEMENTANDO

PROTOTIPADO Y PROGRAMACIÓN EXTREMA PARA CYZA OUTSOURCING S.A.

Elaborado por:

JORGE EMILIO ARAQUE GONZALEZ

Cod 20022020007

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA INGENIERÍA DE SISTEMAS

BOGOTÁ 2015

DESARROLLO DE UN SISTEMA DE CONTROL DE INVENTARIO FÍSICO Y DE SOFTWARE BAJO UNA ARQUITECTURA WEB IMPLEMENTANDO

PROTOTIPADO Y PROGRAMACIÓN EXTREMA PARA CYZA OUTSOURCING S.A.

Elaborado por:

JORGE EMILIO ARAQUE GONZALEZ

Cod 20022020007

Directora:

LILIAN ASTRID BEJARANO GARZÓN

Ingeniera de Sistemas

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA INGENIERÍA DE SISTEMAS

BOGOTÁ 2015

Nota de Aceptación:

_________________________________ _________________________________ _________________________________ _________________________________ _________________________________ _________________________________

Jurados

_____________________________________________

_____________________________________________

_____________________________________________

LILIAN BEJARANO (Directora Interna)

_____________________________________________ JHON JAIRO ROLDAN (Director Externo)

3

CONTENIDO

Pág.

LISTA DE FIGURAS ................................................................................................ 6

LISTA DE TABLAS .................................................................................................. 8

INTRODUCCIÓN ................................................................................................... 10

1. PLANTEAMIENTO DEL PROBLEMA ................................................................ 12

2. OBJETIVOS ....................................................................................................... 14

General: .............................................................................................................. 14

Específicos: ........................................................................................................ 14

3. JUSTIFICACIÓN ................................................................................................ 15

4. MARCO REFERENCIAL.................................................................................... 18

4.1 MARCO TEÓRICO ....................................................................................... 18

4.1.1 Sistema de Inventario. ............................................................................ 18

4.1.2 Clasificación de los Inventarios de acuerdo a la localización física. ....... 19

4.1.3 Fundamentos de la Codificación de Barras. ........................................... 20

4.1.4 Fundamentos del Escaneado. ................................................................ 27

4.2 ESTADO DEL ARTE .................................................................................... 31

4.2.1 Software Mónica ..................................................................................... 32

4.2.2 TPV Comercios ...................................................................................... 33

4.2.3 EcountERP ............................................................................................. 34

4.3 MARCO CONCEPTUAL ............................................................................... 37

4.3.1 Arquitectura Multicapa ............................................................................ 37

4.3.2 Arquitectura Física.................................................................................. 44

4.3.3 Herramientas RAD ................................................................................. 45

4.3.4 Asp.NET ................................................................................................. 45

4.3.5 Visual Studio .......................................................................................... 46

4.3.6 Servidor de Aplicaciones ........................................................................ 46

4.3.7 Controles Propietarios ............................................................................ 46

4

4.3.7.1 Controles de Telerik para ASP Ajax .................................................... 46

5. METODOLOGÍA ................................................................................................ 48

5.1 PROGRAMACIÓN EXTREMA...................................................................... 48

5.1.1 Valores de la Programación Extrema ..................................................... 48

5.1.2 Principios básicos de la Programación Extrema .................................... 49

5.1.3 Roles dentro de la programación extrema .............................................. 53

5.2 PROTOTIPOS .............................................................................................. 54

5.2.1 Prototipo corregido ................................................................................. 55

5.2.2 El prototipo corregido dentro de la Programación Extrema .................... 55

5.3 ESTRUCTURA DE DESGLOSE EDT .......................................................... 56

6. DISEÑO METODOLÓGICO ............................................................................... 58

6.1 FASE DE LEVANTAMIENTO DE DATOS .................................................... 58

6.1.1 Identificación de Interesados .................................................................. 58

6.1.2 Historias de Usuarios ............................................................................. 59

6.1.3 Levantamiento de Requerimientos ......................................................... 64

6.1.4 Casos de Uso ......................................................................................... 72

6.1.5 Diagramación de Flujos de Sistema De Inventarios ............................... 77

6.2 FASE DE PLANEACIÓN .............................................................................. 78

6.2.1 Plan de Desarrollo .................................................................................. 78

6.2.1.1 Desglose de Trabajo ........................................................................... 81

6.2.1.2 Proceso de Desarrollo ......................................................................... 84

6.2.1.3 Diagrama de Proceso de desarrollo de un Ciclo ................................. 85

6.2.1.4 Diagrama de Proceso de desarrollo proyecto General ........................ 86

6.2.2 Plan de Pruebas ..................................................................................... 87

6.2.3 Plan de Control de Cambios ................................................................... 87

6.2.4 Plan de Cierre de Proyecto .................................................................... 87

6.3 FASE DE DESARROLLO ............................................................................. 88

6.3.1 Creación del proyecto ............................................................................. 88

6.3.2 Desarrollo de Proyecto Base .................................................................. 88

6.3.3 Desarrollo de Módulos ............................................................................ 91

5

6.3.4 Construcción de Servicios Web .............................................................. 98

6.3.5 Instalador Cliente de Servicios Windows ................................................ 98

6.4 FASE DE PRUEBAS Y CONTROL DE CAMBIOS ....................................... 99

6.4.1 Pruebas de Integración .......................................................................... 99

6.4.2 Control de Cambios .............................................................................. 110

6.4.3 Pruebas de Aceptación ........................................................................ 111

6.5 FASE CIERRE ............................................................................................ 115

7 ANÁLISIS COSTO/BENEFICIO ........................................................................ 116

7.1 COSTOS .................................................................................................... 116

7.2 BENEFICIOS .............................................................................................. 117

7.3 COMPARATIVO CON OTRAS PROPUESTAS DEL MERCADO .............. 119

8. CONCLUSIONES ............................................................................................ 121

9. REFERENCIAS ............................................................................................... 122

10. BIBLIOGRAFÍA .............................................................................................. 123

11. CITAS DE INTERNET ................................................................................... 124

LISTA DE ANEXOS ............................................................................................. 125

6

LISTA DE FIGURAS Pág.

Figura 1. Partes del código de barras2. .................................................................. 22

Figura 2. Code 1282 ............................................................................................... 23

Figura 3. Code 392 ................................................................................................. 23

Figura 4. Intercalado 2 de 52 .................................................................................. 23

Figura 5. Código EAN2 ........................................................................................... 24

Figura 6. Código UPC2........................................................................................... 24

Figura 7. Código QR2 ............................................................................................. 25

Figura 8. Datamatrix2 ............................................................................................. 25

Figura 9. Código PostNet2 ..................................................................................... 26

Figura 10. CódigoPDF4172 .................................................................................... 26

Figura 11. Escaneado del Código. ......................................................................... 27

Figura 12. Lápiz Óptico .......................................................................................... 28

Figura 13. Escáner CCD ........................................................................................ 28

Figura 14.Escáner de Pistola ................................................................................. 29

Figura 15. Laser Omnidireccional .......................................................................... 30

Figura 16. Escáner de Ranura ............................................................................... 30

Figura 17. Pantalla de Inventarios de Software Mónica ......................................... 32

Figura 18. Módulo de Inventarios. Software TPV Comercios ................................ 34

Figura 19. Vista de Ecount Software ...................................................................... 36

Figura 20. Esquema de Componentes de la aplicación ......................................... 38

Figura 21.Esquema lógico de la capa de presentación ......................................... 39

Figura 22. Esquema lógico de la capa de negocio ................................................ 41

Figura 23. Esquema lógico de la capa de acceso a datos ..................................... 42

Figura 24. Diagrama físico y de red de la aplicación ............................................. 44

Figura 25. Taller de Diseño RAD (Rapid Application Management) ...................... 55

Figura 26. Diagrama típico de un esquema de desglose de trabajo ...................... 57

Figura 27. Caso de Uso para REQ-FNC-01 .......................................................... 72

Figura 28. Diagrama Caso de Uso para REQ-FNC-02 .......................................... 72









7


Figura 38. Diagrama de Secuencia por Funcionalidad Identificada Sistema de Control de Inventarios Planteado ........................................................................... 78

Figura 39. Esquema General Funcional Sistema de Control de Inventarios Planteado ............................................................................................................... 80

Figura 40. Diagrama de proceso de un ciclo de desarrollo Sistema de Inventarios Cyza ....................................................................................................................... 85

Figura 41. Diagrama de Representación del proceso de desarrollo General Sistema de Control de Inventarios Planteado ........................................................ 86

Figura 42. Diagrama de Entidad Relación Base de datos Proyecto Base ............. 89

8

LISTA DE TABLAS Pág.

Tabla 1. Listado de Interesados Sistema de Inventarios Cyza .............................. 58

Tabla 2. Historia de Usuario HU1 .......................................................................... 59








Tabla 10. Historia de Usuario HU9 ........................................................................ 62

Tabla 11. Historia de Usuario HU10 ...................................................................... 62







Tabla 18. Requerimiento Funcional REQ-FNC-01 ................................................. 65











Tabla 29. Requerimiento No Funcional REQ-NFN-01 ........................................... 71




Tabla 33. Tabla de Módulos del Sistema de Inventario Cyza ................................ 79

Tabla 34. Tabla de Desglose de Trabajo Sistema de Inventario Cyza .................. 81

Tabla 35. Formato de Pruebas 1. Proyecto Base .................................................. 99

Tabla 36. Formato de Pruebas 2. Proyecto Base ................................................ 100

9




Tabla 40. Formato de Pruebas 1. Modulo Administración del Sistema ................ 102

Tabla 41. Formato de Pruebas 2. Modulo Administración del Sistema ................ 103

Tabla 42. Formato de Pruebas 1. Modulo Administración de Usuarios ............... 104

Tabla 43. Formato de Pruebas 2. Modulo Administración de Usuarios ............... 105

Tabla 44. Formato de Pruebas 1. Módulo de Ingreso de Elementos ................... 106

Tabla 45.Formato de Pruebas 1. Módulo de Consultas ....................................... 107

Tabla 46. Formato de Pruebas 1. Módulo de Reportes ....................................... 108

Tabla 47. Formato de Pruebas 1. Módulo de Histórico ........................................ 109

Tabla 48. Formato de Pruebas 1. Instalador Cliente ............................................ 109

Tabla 49. Historial de Cambios ............................................................................ 110

Tabla 50. Prueba 1 para REQ-FNC-5 .................................................................. 111

Tabla 51. Prueba 2 para REQ-FNC-05 ................................................................ 112




Tabla 55. Formulario de Pruebas de Aceptación ................................................. 111

Tabla 56. Lista de entregables del proyecto ........................................................ 115

Tabla 57. Tabla Comparativa de otras propuestas .............................................. 119

10

INTRODUCCIÓN

Toda organización requiere administrar sus recursos tecnológicos y conocer plenamente la existencia de equipos e infraestructura informática a su disposición. Estos tipos de controles se pueden supervisar con herramientas que faciliten el acceso a dicha información y además permitan realizar tareas de mantención y rastreo constante.

El proyecto planteado implementa un aplicativo programado a medida de las necesidades de la empresa para el control y gestión automática de inventarios de hardware y software de toda la plataforma informática. Esta solución consiste en la elaboración de un software que administra y presenta información referente a las características físicas y descriptivas de los equipos.

Se realiza un estudio de la tecnología, información requerida, recursos y alcances para verificar la viabilidad del proyecto y las ventajas obtenidas al desarrollar un software propio y a la medida para Cyza Outsourcing S.A.

El software es implementado siguiendo las principales fases para la ejecución de proyectos que son planeación, desarrollo, control, seguimiento y cierre.

El proceso de planeación descubre la funcionalidad de la futura solución y establece el procedimiento de desarrollo del software, programación de tiempo y la gestión de recursos a disposición. Todo esto es resultado de actividades de levantamiento de datos, entrevistas, estudio de requerimientos funcionales, casos de usos, historias de usuarios y diagramación de roles.

El proceso de desarrollo aplica lo planteado en la planeación y se ejecuta la codificación del software mediante la metodología de programación extrema y prototipado, explotando los beneficios de esta práctica de desarrollo ágil.

11

El proceso de seguimiento y control de cambios se realiza en ciclos cortos, donde el resultado de una codificación es inmediatamente sometida a prueba con resultados que pueden ser satisfactorios o que deben entrar a recodificar para somerterlo a un ciclo de cambio. Este proceso es elemental en la programación extrema donde la codificación, pruebas y corrección se hacen en paralelo en el proceso de implementación.

El código satisfactorio será incluido en el prototipo base el cual va reuniendo todos los requerimientos funcionales del software hasta llegar a convertirse en el producto final con toda la plataforma completa y totalmente funcional, esta es la fase de cierre.

Este proyecto muestra en detalle cada una de las fases indicadas con los soportes de los procesos documentados, desglose de las tareas realizadas, el procedimiento ingenieril y producto final con manuales de uso, manuales técnicos y actas de entregas satisfactorias.

12

1. PLANTEAMIENTO DEL PROBLEMA

Cyza Outsourcing S.A. es una empresa que ofrece servicios de seguridad documental y cuenta con el apoyo de personal especializado que complementa los procesos referentes a este sector. Es así como pertenecen al equipo de trabajo personas con perfiles de investigador, grafólogos, dactiloscopistas, abogados y técnicos que hacen parte del proceso que garantiza transacciones seguras referentes a la identidad de un cliente.

Por ello cada funcionario es dotado de elementos asignados por Cyza para adelantar sus procesos particulares y acceder a las herramientas necesarias para cumplir con sus tareas específicas. Es importante para la compañía conocer en todo momento la disponibilidad de sus activos y recursos, entre los que se encuentran equipos de cómputo, equipos de ofimática como impresoras, escáneres o copiadoras, escritorios, sillas y para algunos cargos especializados dispositivos biométricos. Asimismo saber a qué personas ha sido asignado cada elemento entregado.

Actualmente Cyza Outsourcing S.A lleva un proceso netamente manual sobre la Gestión de Inventarios únicamente apoyado por un archivo realizado en hoja de cálculo donde se listan en una tabla las características del equipo que procede a hacer parte de los activos de la compañía. En dicha tabla se detallan datos propios de cada elemento como su marca, su referencia, un número serial, su ubicación, sede y responsable del activo. Una vez que se requiere conocer la cantidad de elementos de un determinado tipo, como una cámara, o una impresora, se utiliza la herramienta de filtro de la hoja de cálculo y se realiza el conteo correspondiente. En todo momento se cuenta únicamente con el apoyo que puedan realizar las herramientas asociadas a la hoja de cálculo sin dejar de ser un procedimiento manual. Adicional a ello se está implementando un sistema de etiquetado que es colocado en cada uno de los elementos que harán parte del Inventario de la Empresa. Actualmente se realiza la recolección de los datos característicos que posteriormente serán incluidos en el archivo manual de Inventario. Cada etiqueta contiene un número único y un correspondiente código de barras que actualmente no está siendo explotado.

13

Por la naturaleza del sistema que se lleva actualmente para alimentar el documento de Inventario, el proceso de actualización es realmente engorroso. En muchos casos los equipos se trasladan de una sede a otra y no es posible hacerles un seguimiento concreto porque tales movimientos no han sido registrados ni actualizados en el soporte documental.

Nuevamente, y por las características tan básicas en las que se adelanta este proceso de levantamiento de inventario, se presume que la información no está segura, inclusive con un alto grado de inconsistencia en los datos ya que se ha presentado el caso en el que se manipula más de un archivo, utilizando documentos copia que generan dispersión de la información. De esta forma no se puede determinar cuál es el archivo original ni cuál es el actualizado. Todos los esfuerzos para llevar un Inventario actualizado podrían irse abajo con el simple hecho de que se perdiera el archivo de hoja de cálculo con el que se trabaja en la actualidad.

Otro proceso directamente afectado es el asociado con el seguimiento de la asignación de equipos. En la empresa es habitual que se haga la contratación de personal por periodos cortos firmando contratos a término fijo con duraciones hasta de 3 meses. Por ello es indispensable un sistema que entregue información precisa de los elementos que le han sido asignados a un funcionario en particular para poder generar documentos de paz y salvo al final de cada periodo de contratación. Esto en la actualidad no se está llevando debido al nivel de complejidad que representa entregar a tiempo un listado de los equipos asignados a la persona que está próxima a entregar su cargo.

Formulación del Problema:

¿Cómo desarrollar una herramienta de software que permita almacenar y gestionar la información referente a los equipos físicos con los que cuenta Cyza Outsourcing S.A. y los recursos de software incluyendo las características de cada máquina y la vigencia de sus licencias, utilizando dispositivos tales como lectores de código de barras para explotar el uso de las etiquetas utilizadas por la empresa para distinguir cada elemento?

14

2. OBJETIVOS

General: • Desarrollar un aplicativo Web a la medida para realizar tareas de Gestión

de Inventarios y licenciamiento de claves de software en equipos físicos y componentes de software apoyado en un dispositivo lector de código de barras para Cyza Outsourcing S.A.

Específicos: • Ejecutar el levantamiento de la información correspondiente a recursos

físicos como equipos de cómputo, biométricos, de monitoreo y de control de acceso capturando sus características diferenciadoras como su marca y referencia para alimentar la información del repositorio de datos que almacene ésta información.

• Desarrollar una rutina de autenticación contra Directorio Activo para los usuarios que pretendan ingresar al Sistema de Control de Inventarios implementando la estructura de usuarios y unidades organizacionales que propone el modelo de Active Directory para determinar accesos y funciones de autorización de ingreso al software.

• Desarrollar un componente que permita monitorear el estado de hardware de los computadores que pertenezcan a Cyza para hacer seguimiento de cambios en su configuración y que permitan ser reportados al servidor central de forma automática.

• Crear roles específicos para los usuarios que van a utilizar la aplicación mediante módulos que encapsulen funciones específicas de tal manera que las tareas de un operario difieran de las sugeridas para un administrador.

• Registrar el artículo inventariado junto con su información asociada mediante la captura y lectura del código de barras utilizando una pistola lectora.

• Implementar la programación extrema como base de la metodología a utilizar en el proceso de desarrollo del Sistema de Control de Inventarios e incluir el prototipado como un componente complementario a la fase de taller de diseño propio de una metodología ágil como lo es XP.

• Publicar el Sistema de Control de Inventarios en un servidor de aplicaciones de manera funcional para operar en Cyza Outsourcing S.A.

15

3. JUSTIFICACIÓN

Toda compañía se apoya en herramientas que le permitan facilitar la ejecución de sus procesos internos en todos los niveles, ya sean operativos, de calidad, administrativos e inclusive de investigación y desarrollo. Particularmente habiendo estudiado las necesidades de una empresa emergente como lo es Cyza Outsourcing S.A. existen muchos procesos que requieren ser potenciados con ayuda de software adicional. Bajo un contexto ingenieril y queriendo brindar soluciones que apoyen estos procedimientos, se ha optado por abordar el caso puntual de la gestión de inventarios para recursos físicos y de software con los que la compañía cuenta y que son esenciales para garantizar el cumplimiento de sus tareas operativas.

De la mano de herramientas que pretenden incrementar la consistencia y el buen funcionamiento de un proceso como lo es un Sistema de Gestión de Calidad (SGC) y cuya implementación es complementaria a la etapa de desarrollo de software, se presenta una oportunidad para integrar dichos estándares a esta propuesta de implementación de Gestión de Inventario para no solo aplicar el desarrollo de un software que cubra una necesidad sino que además permita ejecutar el proceso de desarrollo anclado a metodologías de buenas prácticas en todos los procesos de construcción del software, regidos por políticas de calidad.

Un Sistema de Gestión de Inventarios nunca ha sido abordado formalmente por Cyza Outsourcing S.A. de tal manera que no ha existido en la compañía un software que realice esta operación y durante sus 5 años de funcionamiento no se ha creado ni implementado una herramienta que supla esta necesidad, sin embargo el control de inventarios se ha convertido en una operación que requiere ser apoyada por una solución de software de manera urgente debido a que progresivamente aumenta el número de activos de la empresa a medida que incrementa la contratación de personal y se consolidan más licitaciones de proyectos que implica conocer de manera efectiva los recursos físicos y de software que la compañía tiene a su disposición tanto para asignarlos al personal como para destinarlos a la puesta en marcha de los nuevos proyectos. La solución debe ser un software a la medida por dos razones principales: primero para atender los requisitos específicos que la empresa exige y que no pueden ser suplidos por las propuestas existentes en el mercado comercial ya que el software

16

propuesto pretende cumplir con las condiciones de un administrador de inventarios pero a la vez debe ser capaz de funcionar como un administrador de terminales de computación de forma remota y segundo para permitir la integración de forma flexible con otros componentes de software desarrollados en Cyza Outsourcing S.A para potenciar sus funcionalidades y centralizar la información de varias áreas en una estructura distribuida de pequeños aplicativos.

La importancia de realizar esta implementación radica en la oportunidad de sistematizar una operación que facilite la gestión de inventario sobre los recursos tanto físicos como recursos de software de Cyza Outsourcing S.A. llevando procesos previos a la implementación de código como lo son, el análisis de los actores implicados en las necesidades que se pretenden cubrir, el levantamiento de requerimientos funcionales y no funcionales así como los procesos propios de la implementación a nivel de programación que implican el uso de metodologías de desarrollo, todo esto bajo el marco de estándares destinados a mejorar el resultado final y el cual la empresa ha comenzado a apropiar para todas sus áreas.

Naturalmente para el departamento de Desarrollo estas condiciones están orientadas a garantizar que las técnicas empleadas permitan un proceso de desarrollo ágil, óptimo, de buenas prestaciones y limpio en su elaboración y ejecución.

La solución planteada permitirá agilizar los procesos de recolección de datos sobre los elementos que formen parte del inventario de la empresa, será un software a disposición de la compañía para llevar seguimiento de todos sus activos y cuyo número crece rápidamente considerando que la compañía se encuentra en plena expansión haciendo de esta futura herramienta un elemento de primordial complemento a solicitudes puntuales sobre el estado de cada activo.

Al ser un software hecho a la medida tendrá la ventaja de proporcionar toda la información necesaria para garantizar la disposición de recursos físicos y de software a los técnicos, grafólogos, abogados, personal de monitoreo, personal tecnológico y administrativo, para todas las sedes con infraestructura tecnológica

17

con las que cuenta Cyza Outsourcing S.A. Al ser contemplado como un aplicativo bajo una arquitectura Web se garantiza una mayor disponibilidad de la herramienta para la consulta, ingreso o asignación de un nuevo elemento que esté a punto de formar parte del inventario debido a que la aplicación a desarrollar estará hospedada en un servidor dedicado centralizado.

18

4. MARCO REFERENCIAL

4.1 MARCO TEÓRICO

4.1.1 Sistema de Inventario. Un concepto general define el sistema de inventario como una relación ordenada de bienes y existencias de una entidad o empresa con la finalidad de conocer el estado y la cantidad de elementos disponibles. Según Muller: “Un inventario puede ser algo tan elemental como una botella de limpiador de vidrios empleada como parte del programa de mantenimiento de un edificio, o algo más complejo, como una combinación de materias primas y ensamblajes que forma parte de un proceso de manufactura” (Muller, 2004)[1]. Dependiendo del contexto y la actividad comercial de cada organización se puede establecer una definición más precisa sobre el Inventario. En muchas ocasiones tal definición va orientada a empresas que tienen una mayor actividad comercial y que su núcleo de negocio es el de comprar materia prima para generar productos terminados. Para estos casos se presenta una mayor importancia en determinar costes de adquisición, valores adicionales de procesamiento de productos y la estimación del valor final de su producto destinado a la venta. Según Taha “se considera a los inventarios como un mal necesario: si son muy pocos, causan costosas interrupciones; si son demasiados equivalen a tener un capital ocioso” (Muller, 2004)[1].

En un contexto más específico los inventarios tienen varios elementos categorizados dependiendo fundamentalmente de su naturaleza en la organización. De esta manera se clasifican en:

• Materias primas • Productos terminados • Productos en proceso • Artículos de consumo • Artículos para servicio, reparación y repuesto

En ocasiones para cada uno de estos elementos mencionados se suele llevar un inventario teniendo de esta manera Inventario de Materias Primas o Inventario de Productos Terminados etc.

19

4.1.2 Clasificación de los Inventarios de acuerdo a la localización física. Partiendo del hecho de que se debe conocer la ubicación física de un artículo para poder contarlo, saber quién lo tiene en custodia o en qué sede de la empresa se encuentra se establece de manera teórica las distintas clasificaciones que se le puede otorgar a un inventario y las consideraciones que tiene el llevar una u otra distribución. Independientemente del espacio que las compañías dispongan para el almacenamiento de sus productos, existen sistemas de localización que utilizan mejor el espacio y me manera más eficaz que otros (Muller, 2004)[3].

El propósito de un sistema de localización de materiales es la definición de procedimientos que permita seguir el movimiento de los productos dentro de las instalaciones y para considerar qué sistema de localización funciona mejor se debe tratar de maximizar y estimar lo siguiente:

• Uso del espacio • Uso del equipo • Uso de la mano de obra • Accesibilidad a todos los artículos • Protección contra daños • Facilidad para localizar los artículos • Reducción de costos administrativos

Intentar implementar un único sistema puede ser difícil de realizar, en ocasiones es preciso contemplar la posibilidad de implementar más de una modalidad de seguimiento para optimizar la administración del inventario. La clasificación es la siguiente:

4.1.2.1 Sistemas de memoria. Caracterizados por ser exclusivamente dependientes de la recordación humana. Los fundamentos de este sistema de localización son la simplicidad, la relativa ausencia de papeleo y digitación de datos, y la utilización máxima de todo el espacio disponible. Los sistemas de memoria dependen directamente de las personas que lo manejan y las condiciones bajo las cuales funcionan tales sistemas contemplan sitios de almacenamiento de número y tamaño limitado, con variedad de artículos a almacenar limitados y un número limitado de operarios también. (Muller, 2004)[3].

20

4.1.2.2 Sistemas de localización fija. Cada artículo tiene su lugar. Si una unidad de existencias se almacena en grandes cantidades, puede tener dos o más sitios de almacenamiento. Sin embargo, tomadas colectivamente, todas estas posiciones son los únicos lugares donde el artículo puede permanecer en las instalaciones, y ningún otro artículo puede quedar allí. Los sistemas de localización fija exigen grandes cantidades de espacio pensando en el momento en que exista un grado máximo de elementos para almacenar. También se debe contar con la existencia de espacios disponibles pero que no se encuentran en uso pero que sin embargo pueden ser plenamente usados en el momento en que se requieran ya sea por la forma del producto, por las características singulares de otros productos que al llegar serán asignados a ésta particular ubicación y que no pueden ser ocupados. A esta situación se le conoce como efecto panal. (Muller, 2004)[3].

4.1.2.3 Sistemas de localización aleatoria. Su principal característica es que nada tiene un lugar fijo, pero se sabe dónde está todo. Existe una maximización del espacio por cuanto ningún artículo tiene una ubicación fija y puede situarse donde exista espacio. Los sistemas de memoria no dependen del sitio de almacenamiento, ni de las características particulares de los elementos inventariados, únicamente dependen de la mente del encargado de los inventarios. Los sistemas aleatorios tienen la flexibilidad de los sistemas de memoria, unida al control de los sistemas fijos. Como lo indica Muller (2004)[3]:

“En esencia, un artículo puede situarse en cualquier lugar, siempre y cuando su localización se anote con precisión en una base de datos de computador o en un sistema manual de tarjetas. Cuando el artículo se mueve, se elimina de la respectiva localización. Por consiguiente la dirección de una unidad de existencias es la localización donde se encuentra mientras permanezca allí”. (Muller p.65) [3]

4.1.3 Fundamentos de la Codificación de Barras. El proceso en el que las personas identifican un objeto tiende a provocar errores y gasto de tiempo en manipular, registrar esa información en una base de datos y luego hacer las modificaciones necesarias para seguir los cambios en la localización, el tamaño de los elementos o las cantidades. Muller afirma (2004)[3]:

21

“Mientras menos se dependa de la intervención humana para identifica elementos, registrar información y hacer seguimiento de datos, más oportunos y exactos serán los registros. La codificación de barras es una valiosa herramienta para capturar datos importantes con rapidez y precisión. La eficiencia en la captura de información y la precisión del código de barras suelen ser razones suficientes para justificar, en cuanto a costo, la instalación de la codificación de barras dentro de una operación de levantamiento de datos” (Muller, 2004)[3].

La codificación de barras es un método óptico para lograr la identificación automática de cualquier elemento mediante un conjunto de líneas paralelas verticales de distinto grosor y espaciado que en su conjunto contienen una determinada información. Depende de una luz visible o invisible que se refleja en un dibujo impreso. Las barras o áreas oscuras en el interior del dibujo absorben la luz, y los espacios o áreas intermedias la reflejan. La absorción y la reflexión contrastante las capta un aparato que lee el dibujo reflejado y decodifica la información.

La correspondencia o mapeo entre la información y el código que la representa se denomina simbología1. Existen simbologías para diferentes aplicaciones, cada una de ellas con diferentes características que pueden ser las siguientes.

• Numéricas o alfanuméricas • De longitud fija o longitud variable • Discretas o continuas • Número de grosor de elementos • De auto verificación

4.1.3.1 Elementos de los códigos de barras. El lenguaje de un código de barras es un alfabeto fijo compuesto de diversos patrones de barras oscuras y espacios de luz intermedios. Existen muchos tipos de códigos de barras y no todos son símbolos. Sus partes se describen en la siguiente figura.

1 Wikipedia. Simbología: es la representación perceptible de una idea, con rasgos asociados por una convención socialmente aceptada.

22

Figura 1. Partes del código de barras2.

• Zona de Silencio: (Quietzone). Corresponde a un área en blanco prudencial que le permite al lector de código ubicar un punto inicial desde el cual pueda realizar las mediciones. Se encuentra en los dos extremos debido a que la lectura se puede realizar de izquierda a derecha o viceversa.

• Carácter Inicio: Con la finalidad de que los códigos se puedan leer en cualquier dirección, los caracteres iniciales y finales indican al escáner dónde comienza el mensaje. Es habitual que el carácter que se encuentra a la izquierda o en la parte superior del símbolo sea el inicial, y aquel que se encuentra a la derecha o en la parte inferior corresponda al final.

• Caracteres de datos: Estos constituyen el mensaje real dentro del código y pueden estar conformados por letras del alfabeto, números, símbolos o una combinación de los tres.

• CheckSum: Son caracteres adicionales adjuntos al código de barras para garantizar buenas lecturas. Estos son necesarios en algunos códigos de barras propensos a error como aquellos que traen un campo de caracteres de datos muy denso. Cabe aclarar que no todos los códigos de barras lo requieren, en especial aquellos que tienen la propiedad de auto revisión.

23

4.1.3.2 Tipos de códigos de barras

Figura 2. Code 1282

Esta simbología es un código de barras muy compacto para toda aplicación alfa numérica. El conjunto de caracteres ASCII completo (128 caracteres) puede ser codificado en esta simbología sin duplicar caracteres. Si el código de barras tiene 4 o más números consecutivos los números están codificados en modo doble densidad donde dos caracteres están codificados en una sola posición.

Figura 3. Code 392

El code 39 es el código de barras de uso más común para aplicaciones regulares. Es popular debido a que puede contener texto y números (A-Z, 0-9 +,-) y puede ser leído por casi cualquier lector de código de barras en su propia configuración y es uno de los primeros en ser implementados dentro de los más modernos. Es un código de barras de ancho variable y puede tolerar cualquier número de caracteres que el lector pueda barrer.

Figura 4. Intercalado 2 de 52

24

Es un código de barras exclusivamente numérico cuya figura es ligeramente más larga que el código de barras UPC-A cuando se codifica con 10 dígitos. Esta simbología tiene la flexibilidad para codificar cualquier número par de dígitos. Si el número es impar se coloca un cero al principio. Este código es un excelente candidato para aplicaciones exclusivamente numéricas y es la mejor simbología para lectores de montaje fijo.

Figura 5. Código EAN2

Es un sistema de códigos de barras adoptado por más de 100 países. El más usual es el EAN13 como el presentado en la Figura 5. El primer digito siempre se sitúa afuera más otros once dígitos. El tren de números es completado con un dígito de control que se calcula realizando la siguiente operación para el código 123456789722:

• Se invierte el orden del número de entrada así: 227987654321 • Se suman los números en posición impar: 2+7+8+6+4+2 = 29 • Se multiplica por tres el resultado: 29*3 = 87 • Suma de las posiciones pares: 2+9+7+5+3+1 = 27 • Suma total 87+27 = 114 • Decena inmediatamente superior: 120 • Digito de control: 120-114 = 6

Figura 6. Código UPC2

25

Es la simbología más usada en el comercio minorista de EEUU para codificación exclusiva de números con una longitud de 12 dígitos. El primer número es llamado “numero de sistema” que va del 1 al 7 indicando un tamaño y peso determinado. Los dígitos del segundo al sexto representan el número del fabricante que debe ser único y que es asignado por un organismo de control. Los dígitos del séptimo al onceavo corresponden al código que el fabricante asigna a cada producto mientras que el doceavo dígito realiza la función de código de control.

Figura 7. Código QR2

El código QR es un sistema para almacenar información en una matriz de puntos viéndose como un código de barras bidimensional creado por la compañía Denso Wave en 1994 y se caracteriza por tener tres cuadrados que permiten detectar la posición del código al lector. En la actualidad este tipo de código es muy difundido para almacenar URLs para buscar productos por internet ya que muchos dispositivos móviles ahora tienen la capacidad de leer este tipo de simbología.

Figura 8. Datamatrix2

26

Es un sistema industrial de codificación bidimensional que permite la generación de un gran volumen de información en un formato muy reducido, con una alta fiabilidad de lectura gracias a sus sistemas de información redundante y corrección de errores que permiten una lectura con hasta un 30% de daño.

Figura 9. Código PostNet2

Este tipo de simbología está reservado a la industria postal usando este tipo de código de barras en los sobres de mensajería. El uso de este código acelera la gestión de correos logrando ahorros de tiempo por clasificación automática. PostNet es creado en 1980 implantándose en el Servicio Postal de los Estados Unidos.

Figura 10. CódigoPDF4172

Es un código multi filas, de longitud variable que tiene alta capacidad de almacenamiento de datos. Se le considera un archivo portátil de datos (Portable Data File o PDF) y tiene una capacidad de hasta 1800 caracteres numéricos, alfanuméricos y especiales por lo que no requiere consultar un archivo externo. Cuenta con mecanismos de detección de errores conformados por 9 niveles de seguridad lo que le permite la lectura y decodificación exitosa aun cuando el daño del código llegue hasta un 40%. Este tipo de simbología tiene muchas aplicaciones industriales pero es ampliamente usado como código de identificación para la Cédula de Ciudadanía.

4.1.4 Fundamentos del Escaneado.existen dispositivos encargados de hacer la lectura de estas scuales son llamados escáner de código de barras realiza la lectura y emite la interpretación del código que representan la consecución de líneas y espacios de la imagen.básicamente de un láserlectura del láser y la interfaz de comunicación entre el dispositivo y un computador, ya sea por intermedio de un cable, bluetooth o Wifi.

4.1.4.1 Procedimiento de lecturadispositivo denominado “escáner” proyecta una luz sobre un símbolo de código de barras y la obtención de la información proveniente del código de barras se realiza al capturar la luz que es reflejada de las árbarras. Internamente existe una conversión de una señal visual análoga a una señal digital haciendo un proceso de decodificación de la información representada en el código de barras. (Muller 2004)

El láser del escáner comienza a leer el código de barras en un espacio blanco que es una zona fija antes de la primera barra y continúa pasando hasta la última línea, para finalizar en el espacio blanco que sigue a ésta. Debido a que el código no se puede leer si se pasa el escáner fuera de la zona del símbolo, las alturas de las barras se eligen de manera tal área del código de barras. Mientras más larga sea la información a codificar, más largo será el código de barra

2Wikipedia. Escáner de Código de Barras. Consultado en http://es.wikipedia.org/wiki/Esc%C3%A1ner_de_c%C3%B3digo_de_barras

27

4.1.4 Fundamentos del Escaneado. Para hacer uso de los códigos de barras existen dispositivos encargados de hacer la lectura de estas scuales son llamados escáner de código de barras que por medio de un lárealiza la lectura y emite la interpretación del código que representan la consecución de líneas y espacios de la imagen. Un escáner se compone

láser, un decodificador que realiza la interpretación de la y la interfaz de comunicación entre el dispositivo y un computador,

ya sea por intermedio de un cable, bluetooth o Wifi.

.4.1 Procedimiento de lectura. La lectura se produce en el instante en que un dispositivo denominado “escáner” proyecta una luz sobre un símbolo de código de barras y la obtención de la información proveniente del código de barras se realiza al capturar la luz que es reflejada de las áreas oscuras y claras del símbolo de barras. Internamente existe una conversión de una señal visual análoga a una

haciendo un proceso de decodificación de la información representada en el código de barras. (Muller 2004) [3]

Figura 11. Escaneado del Código.

del escáner comienza a leer el código de barras en un espacio blanco que es una zona fija antes de la primera barra y continúa pasando hasta la última línea, para finalizar en el espacio blanco que sigue a ésta. Debido a que el código

se pasa el escáner fuera de la zona del símbolo, las alturas de las barras se eligen de manera tal que la zona de lectura se mantenga dentro del área del código de barras. Mientras más larga sea la información a codificar, más largo será el código de barras necesario.2

Wikipedia. Escáner de Código de Barras. Consultado en

http://es.wikipedia.org/wiki/Esc%C3%A1ner_de_c%C3%B3digo_de_barras

hacer uso de los códigos de barras existen dispositivos encargados de hacer la lectura de estas simbologías los

por medio de un láser realiza la lectura y emite la interpretación del código que representan la

Un escáner se compone , un decodificador que realiza la interpretación de la

y la interfaz de comunicación entre el dispositivo y un computador,

La lectura se produce en el instante en que un dispositivo denominado “escáner” proyecta una luz sobre un símbolo de código de barras y la obtención de la información proveniente del código de barras se realiza

eas oscuras y claras del símbolo de barras. Internamente existe una conversión de una señal visual análoga a una

haciendo un proceso de decodificación de la información

del escáner comienza a leer el código de barras en un espacio blanco que es una zona fija antes de la primera barra y continúa pasando hasta la última línea, para finalizar en el espacio blanco que sigue a ésta. Debido a que el código

se pasa el escáner fuera de la zona del símbolo, las alturas de que la zona de lectura se mantenga dentro del

área del código de barras. Mientras más larga sea la información a codificar, más

28

4.1.4.2 Tecnologías de lecturas. Actualmente se distinguen las siguientes tecnologías de lectura de código de barras:

Figura 12. Lápiz Óptico

Se trata de un periférico parecido a un lápiz normal que se utiliza sobre una pantalla o una superficie plana. Está conectado a un cordón eléctrico y requiere de un software especial para su funcionamiento. El lápiz contiene sensores luminosos y envía una señal al computador cada vez que registra una luz, por ejemplo cuando los elementos negros que se encuentran debajo de la punta del lápiz son detectados e interpretados como una señal eléctrica. Su desventaja radica en que debe ser deslizado a lo ancho del código y el envío de una señal digital por cada barra detectada se hará a la misma frecuencia y velocidad con que se deslice el lápiz por la superficie y depende de la calidad de la impresión del código de barras.

Figura 13. Escáner CCD

Escáner CCD (Changed Coupled Device)3

3Lector de Código de Barras CCD de largo alcance. Consultado en: http://www.identific-ar.com.ar/argoxas8150.htm

29

Los escáneres CCD tienen una cabeza lectora del mismo ancho que el código de barras aproximadamente de 2 a 4 pulgadas. El usuario coloca la cabeza del lector en el código de barras y una serie de Leds barre el código de barras y lo lee. Puede trabajar con casi todos los códigos de barras de baja calidad y requiere una superficie relativamente plana. Este escáner debe estar a menos de 1 centímetro de distancia para leer el código. La superficie puede estar ligeramente curva en la dirección de las barras.

Figura 14.Escáner de Pistola

Escáner de Pistola4

Este dispositivo realiza un barrido mediante una luz láser y genera una señal similar a la del lápiz óptico pero a mayor frecuencia. Esta señal es conocida como HHLC (Hand Held Laser Combatible), no requiere decodificador de teclado y puede leer a distancia de 5 a 30 centímetros. Puede tener inconvenientes de lectura cuando hay demasiada luz ambiental.

4Focus MS 1960 Metrologic. Consultado en: http://www.comercialsacrida.com/escaner.html

30

Figura 15. Laser Omnidireccional

Escáner Omnidireccional5

Este tipo de lectores funciona enviando un patrón de rayos laser que permite leer un símbolo de código de barras sin importar su orientación. Tiene la ventaja de ofrecer un índice de FRR (False Rate Rejection) muy cercano al 100% gracias a su precisión. Como su característica principal es que se encuentran fijos en un lugar los códigos de barras son llevados hacia ellos. Son ampliamente usados en las cajas registradoras de supermercado o ensamblados en las bandas transportadoras donde leen las cajas o paquetes cuando estos se mueven en la línea. También usados en las líneas aéreas para procesar equipaje.

Figura 16. Escáner de Ranura

Escáner de Ranura6

5EscanerPosiflexLS-1000 consultado en: http://www.tpvcomponentes.com/scanner-posiflex-ls1000/producto.html?p=15043

31

Los escáneres de Ranura son implementados para control de tiempo y relojes chequeadores de trabajo, seguridad y otros sistemas. Tienen una ranura por la cual se pasan las tarjetas con código de barra al igual de cómo lo haría un lector de bandas magnéticas que usan las tarjetas de crédito.

4.2 ESTADO DEL ARTE

Los sistemas de control de inventarios tienen un antecedente íntimamente relacionado con el concepto de la administración y surge como una necesidad específica de control. La teoría de inventarios está orientada a construir la metodología adecuada para procurar una mejor organización de los elementos que serán objeto de ordenamiento, ya sean materias primas, productos en proceso, suministros que complementan la operación de una empresa o sus productos terminados.

En la actualidad se puede disponer de infinidad de soluciones de software orientadas a los sistemas de inventarios que se diferencian unos de otros, ya sea por el esquema de arquitectura que la solución plantea o el conjunto de funcionalidades que la herramienta propone. Luego de haber estudiado varias opciones se puede enmarcar que existe una gama extensa de propuestas enfocadas a brindar soluciones al tema de la organización de los productos dentro de una empresa pero sobretodo orientado para las que tienen una razón social comercial en su mayoría. Este direccionamiento por supuesto que es totalmente válido ya que como parte de la optimización de recursos y el uso adecuado de los productos de una empresa va enlazada su organización, conocimiento de lo que se tiene y la concientización del diferencial costo/ beneficio que determina el nivel de productividad que se está generando. Por eso fue común encontrar el control de inventario como un módulo que complementa una agrupación de servicios y funciones que cubren integralmente las necesidades de un negocio o una empresa a mayor escala junto con soluciones orientadas a compras, facturación, nómina y contabilidad en general. Las siguientes son algunas de las herramientas vigentes y que se diferencian básicamente en el esquema de software siendo unas totalmente web mientras que otras manejan un entorno de instalación local. 6 Escáner de Ranura Marson MT-412. Consultado en: http://spanish.alibaba.com/product-gs/marson-mt412-slot-card-scanner-for-tablet-pc-aidc-pos-terminal-rs232-ps2-usb-interface-286693331.html

32

4.2.1 Software Mónica7. Es un paquete integral que presenta soluciones orientadas a contabilidad que incluye módulos de facturación, cuentas por cobrar, cuentas por pagar y trae un módulo específico para control de inventario. Incluye además muchas herramientas que facilitan los procedimientos contables como conversión de moneda, generación de facturas o cálculo de comisión para vendedores y clasificaciones especiales para rotular productos (físicos, servicios, ocasionales).

Características. • Diseñado por Technotel, una empresa con una trayectoria de más de 22

años originaria de Miami (Florida). • Software completamente en español. • Aplicativo para funcionar localmente en un computador convencional. • Funciona sobre sistemas Windows. • La persistencia de datos esta soportada en Microsoft SQL Express 2008. • Sus funcionalidades están orientadas a empresas cuyo núcleo de negocio

sea la comercialización de productos. • Su costo redondea los $290.000 pesos colombianos.

Figura 17. Pantalla de Inventarios de Software Mónica

Fuente: http://www.technotel.com/monica-requerimientos.html#4

7 Software Mónica. Consultado en http://www.technotel.com/index.html

33

4.2.2 TPV Comercios8. Una completa herramienta para administración de negocios con módulos especializados en gestionar productos desde un enfoque comercial y administrativo, manejando por separado la gestión back-office (administración) y front-office (ventas).

Características:

• Desarrollado por Atrisoft con trayectoria de 10 años en el mercado. • Aplicaciones soportadas con certificaciones Microsoft y Partner de Microsoft

para Sistemas Embebidos. • Permite clasificar los productos por categorías o familias. • Puede definir diferentes políticas de precios de acuerdo a los clientes,

temporadas u horarios de trabajo. • Permite la consulta e impresión de etiquetas definiendo formatos

personalizados. • Contiene un sistema gestión de tickets orientado al empleado que toma el

pedido permitiendo la política de comisiones por venta. • Realiza gestión de cajas llevando de forma automática los movimientos de

dinero y pudiendo realizar históricos de cierres de caja. • Permite realizar gestión de relación con proveedores. • Permite usar múltiples puntos de venta teniendo terminales independientes

con una base de consulta centralizada para evitar duplicidad. • Su costo oscila los $93.000 pesos colombianos.

8 Software TPV Comercios. Consultado en http://www.atrisoft.com/Product/Details/300271857

34

Figura 18. Módulo de Inventarios. Software TPV Comercios

Fuente: http://www.atrisoft.com/Product/Details/300271857

4.2.3 EcountERP9. Un sistema basado en la web presentado como una herramienta personalizable para pymes cuyo acceso se realiza a través de internet gracias a que cuenta con una arquitectura basada en la nube (cloud computing) que permite la facilidad de acceder mediante dispositivos móviles. Presenta todo

9EcountERP Software. Consultado en http://www.ecounterp.com/es/index.jsp

35

un paquete modular para contabilidad, inventario, producción, ventas compras y comercio. Aunque la empresa que lo desarrolla es oriental, se preocupa por adaptar sus preferencias a los estándares latinoamericanos y normatividades vigentes.

Características:

• Acceso mediante la nube. • Registro ilimitado de usuarios. • Certificación en ISO 27001. • Ofrece un sistema integrado de soluciones (incluyendo inventario) • Actualizaciones gratuitas. • Acceso desde dispositivos móviles • Rastreo de código de barras. • Administración de ubicaciones • Reportes especializados. • Portal de atención al cliente. • Suscripción de US$55 mensuales.

36

Figura 19. Vista de Ecount Software

Fuente: http://www.ecounterp.com/es/product/inventory/product-inventory-management.jsp

37

4.3 MARCO CONCEPTUAL

Lo que se describe a continuación corresponde a la explicación procedimental que se pretende realizar en la etapa de desarrollo del software para Cyza Outsourcing S.A incluyendo la concepción lógica de los componentes que harán parte de la solución planteada. Dicha explicación incluye herramientas de software, componentes que enriquecen la interfaz gráfica del software y conceptos que Cyza Outsourcing aplica para sus proyectos y que como principales interesados en la solución de software desean que permanezcan presentes en esta propuesta para garantizar identidad corporativa.

El Sistema de Gestión de Inventarios para Cyza Outsourcing está orientado a desarrollarse bajo el modelo arquitectónico que propone Microsoft.Net. Un Framework que expande su funcionalidad a las facilidades que prestan las aplicaciones basadas en la Web y que se soportan en estándares abiertos como XML (Extensible Markup Language) estableciendo una intercomunicación entre sistemas indiferentemente de la plataforma en que fueron desarrollados, enriqueciendo su funcionalidad y permitiendo una mayor facilidad de acceso mediante cualquier dispositivo con conectividad a internet. (Ceballos p.5)[4]

4.3.1 Arquitectura Multicapa10 Para obtener una mayor concepción lógica de la aplicación web se pretende implementar una técnica orientada a aplicaciones empresariales que permite una fácil administración y construcción. La programación Multicapa propone dividir los componentes de la aplicación en capas definidas con funciones específicas como lo son:

• Capa de presentación • Capa de negocio • Capa de acceso a datos

La facilidad que ofrece implementar éste esquema es permitir la manipulación independiente de cada capa pero sin olvidar que cada una de ellas debe interactuar con su similar. Si se requiere incluir una nueva funcionalidad o un nuevo componente que involucre a una capa específica, se puede realizar tal cambio sin que esto afecte las demás capas conservando su independencia.

10 Vergara Zapata, David Esteban. Introducción a la programación Multicapas. En http://www.elguille.info/colabora/puntoNET/jevergara_Multitier.htm

38

La manera en que cada capa se comunica con la otra será a través de APIs (Interfaz de Programación de Aplicaciones) que son generadas por la herramienta RAD integrada en el entorno de trabajo de Visual Studio. Cada API encierra en una librería el conjunto de funciones y procedimientos propios de su capa para ser utilizados como una abstracción de ella. Inclusive los componentes de terceros se manifiestan en el aplicativo mediante funcionalidades encerradas en APIs que el proveedor entrega para adaptar a las aplicaciones.

Figura 20. Esquema de Componentes de la aplicación

Fuente: Diseño personal11

4.3.1.1 Capa de presentación. Dentro de ésta capa se encuentran todos los componentes de interfaz gráfica de cara al usuario y que serán la herramienta de interacción con el aplicativo. Es de vital importancia que se realice en vista de diseño una presentación clara de la información. Particularmente cada frontal debe

11 Diagrama de autoría propia sobre la interacción de los componentes que harán parte del desarrollo del software. Realizado en Paint.NET

39

cumplir con un esquema acorde con la empresa generando identidad del aplicativo dentro de la compañía.

La aplicación contará con una página maestra que será la que contenga el esquema de diseño principal de la aplicación. Este formulario web tiene la particularidad de que se carga una sola vez al ejecutar la aplicación lo que permite instanciar allí únicamente componentes o variables de aplicación que serán llamados una única vez durante todo el ciclo de vida del aplicativo.

Figura 21.Esquema lógico de la capa de presentación


Adicionalmente existirán los formularios web llamados ContentPage que serán encapsulados por la página maestra. Estas páginas de contenido serán las que tengan toda la distribución de controles aspx y ajax, las vistas de formatos, tablas, listas desplegables, y la manipulación general de los datos a través de estos controles que logren la interacción con el usuario. (Johnson p.584)[5] 12 Diseño de autoría propia que describe organización lógica de los componentes de presentación en el software. Realizado en Paint.NET

40

Cada formulario web cuenta con un componente que administra la vista de diseño con su correspondiente generación de código html que hace posible la renderización de todos los controles para hacerlos visibles en un browser. Adicional a esto se enlaza un archivo con extensión .cs (C#) o .vb (VisualBasic) que se denomina CodeBehind y que tiene como función encapsular allí todo el componente lógico detrás de su diseño como funciones y control de eventos sobre los componentes visuales. (Johnson p.20)[5]

4.3.1.2 Capa de negocio. En ésta capa residen los criterios de validación que están sujetos a las reglas de negocio definidas en un principio para los datos que son transportados desde y hacia la capa de presentación, así como los datos que están próximos a ser almacenados en el motor de base de datos mediante la comunicación con la capa de datos.

La capa de negocio es conformada por varias bibliotecas de clases que internamente están compuestas de clases separadas y definidas de tal manera que cada una de ellas represente una entidad de negocio. Muchas de estas entidades de negocio tienen la función de representar objetos provenientes de la base de datos. El ejemplo más típico es la representación de una “tabla” de base de datos como un objeto “entidad de negocio” que contendrá toda la información de la tabla. Como cada biblioteca requiere tener representación en una biblioteca de clases distinta, ésta se hará presente en forma de API conteniendo internamente acceso a las funciones y propiedades que se hayan definido como públicas dentro de ella.

41

Figura 22. Esquema lógico de la capa de negocio

Diseño personal13

Aunque los controles contenidos en los formularios web de la capa de presentación incluyen componentes que ayudan a validar los datos mediante comprobaciones como su longitud o su tipo, la gran mayoría de funciones de validación sobre los datos provenientes de los frontales web deben recaer en la capa de negocio. Es importante que se valide desde aquí la compatibilidad o nulidad de un dato específico si la capa de negocio comprueba que este tipo de dato será aceptado por la base de datos. En resumen la capa de negocio debe garantizar que todo dato proveniente de la capa de presentación cumple integralmente con la definición de datos que son esperados en los campos de cada tabla de la base de datos.

Adicional a lo descrito anteriormente esta capa permite agrupar lógicamente bibliotecas complementarias que eventualmente tendrían la función de presentar métodos utilitarios que podrán ser usados transversalmente en el aplicativo pudiéndose pensar en un API que se encargue del cifrado de datos, o transformaciones específicas que no pudiera contener las bibliotecas que por defecto ofrece Visual Studio. De esta manera podrían ser llamados desde cualquiera de las capas que conforman la aplicación.

13 Esquema de autoría propia que ilustra la comunicación entre distintas bibliotecas de clases que pertenecen a la misma distribución lógica de la capa de negocio. Diseño realizado en Paint.NET.

42

4.3.1.3 Capa de acceso a datos Desde esta capa se agrupan todos los métodos que serán de ayuda para establecer la comunicación con el motor de base de datos. La capa de acceso a datos administrará todo el proceso de acceso al repositorio de almacenamiento de datos como la apertura de conexiones, las cadenas de conexión a SQL, las consultas a la base de datos las cuales se realizarán por intermedio de procedimientos almacenados, esto con el fin de evitar presentar consultas transact-sql visibles desde aplicación y evitando así ataques por inyección de código.

Como existen procesos recurrentes sobre operaciones comunes de consulta y escritura en la base de datos, la capa de acceso a datos incluye un componente de terceros llamado Enterprise Library14 que permite encapsular implícitamente rutinas que se encargan de aperturas, cierres y liberación de conexiones cada vez que se requiere tener acceso a la base de datos. Adicional a esto es importante incluir un objeto de acceso denominado ADO.Net (Access Data Object) presente en Visual Studio (para otros motores existen elementos como OracleClient para Oracle) que será el objeto representante que mediará entre la aplicación y la instancia de base de datos. (Johnson, 2007)[5].

Figura 23. Esquema lógico de la capa de acceso a datos


14 MSDN-Microsoft. Enterprise Library. Disponible en: http://msdn.microsoft.com/en-us/library/ff632023.aspx 15 Representación de comunicación entre el motor de base de datos con el software por intermedio del componente ADO.NET

43

Visual Studio maneja elementos que permiten encapsular estructuras traídas desde la base de datos. Estos objetos son denominados DataSets que son componentes complejos de datos en los que internamente vienen subelementos que representan las tablas y las relaciones de tablas. El elemento que almacena la información de una tabla se denomina DataTable y los que contienen las relaciones entre tablas son DataRelationship. Así un DataSet tiene la facultad de almacenar todo un conjunto de datos complejo permitiendo manipular dicha información en la aplicación. El uso más común es el de establecer un DataTable como origen de datos para presentar información en un frontal por medio de una Rejilla (Grid). Se puede complementar esta funcionalidad con el resto de operaciones CRUD para una tabla (Create – Read – Update – Delete) manipulando los registros temporalmente sobre el DataTable y una vez que esté preparado, realizar la correspondiente escritura en el repositorio de base de datos volcando los datos almacenados en el DataTable sobre la tabla destino.

44

4.3.2 Arquitectura Física La distribución física requerida para poner en marcha el aplicativo de gestión de inventarios sugiere la disposición de los recursos presentados en el siguiente esquema físico y de red.

Figura 24. Diagrama físico y de red de la aplicación


Al interior de Cyza Outsourcing existe una granja de servidores con roles específicos. Los servidores dispuestos son:

• Servidor Web (Dominio) • Servidor de Aplicaciones • Servidor de Directorio Activo • Servidor de Base de Datos

16 Diagrama de autoría propia que dispone el esquema físico de los equipos de hardware proporcionados por Cyza Outsourcing S.A. Realizado en Microsoft Visio 2007.

45

Actualmente la empresa ya cuenta con esta estructura de red de servidores y cumplen las funciones que posteriormente serán explicadas.

El servidor web también realiza funciones de servidor de dominio y es quien resuelve la dirección www.cyza.com.co de la compañía. Este servidor está de cara a internet tras un Firewall que restringe las peticiones no deseadas. Internamente se comunica con el servidor de aplicaciones donde residirá la aplicación web.

El servidor de aplicaciones es un servidor virtualizado que ejecuta el Administrador de Aplicaciones bajo IIS (Internet Information Services) que será el contenedor del pool de aplicaciones donde se encontrará el sistema de gestión de inventarios. El acceso al aplicativo de gestión de inventarios tendrá un componente de autenticación contra Directorio Activo consultando la existencia de los usuarios al Servidor de Active Directory destinado para esta función. Esta funcionalidad es muy importante de cara a futuras integraciones del aplicativo con otros proyectos de la empresa ya que de esta manera se podrá realizar una construcción integral de aplicaciones centralizadas en un único repositorio de usuarios.

La persistencia de los datos estará a cargo del servidor de bases de datos que se encargará de controlar la instancia de SQL Server que almacenará el catálogo de datos destinada a guardar los registros generados en la aplicación. La ventaja de mantener el repositorio independiente de la aplicación implica que dicha información podrá ser administrada y salvaguardada mediante los procesos habituales de aseguramiento de la información como el copiado, restauración, gestión de backups o tareas programadas que ayudarán a cuidar la integridad de las bases de datos de todos los repositorios de la compañía incluyendo el nuevo.

4.3.3 Herramientas RAD Son recursos de software que tienen como propósito adelantar desarrollos en tiempos muy cortos y que junto con metodologías que comparten esta necesidad de inmediatez permiten cumplir con el objetivo principal: reducción de tiempos. RAD (Rapid Application Development) es un enfoque orientado a objetos integrando métodos de desarrollo y software, se adapta muy bien al proceso de satisfacer más de cerca los requerimientos cambiantes de los negocios. Muy útil además cuando existe una competencia cercana y es necesario ofrecer una solución más rápida que el resto de los rivales donde prima la ley del que “pegue primero”. (Kendall, 1995)

4.3.4 Asp.NET Es una plataforma que incorpora una serie de características y utilidades para diseñar aplicaciones Web como formularios Web o servicios Web.

46

Los formularios Web se utilizan para crear aplicaciones en las cuales la interfaz primaria de usuario es un explorador. Entre ellas se incluyen las aplicaciones que se ponen a disposición del público a través de la red. Una característica importante es que no hay costos de distribución, puesto que los usuarios tienen ya instalada la única parte de la aplicación que necesitan: el browser.

Las aplicaciones de formularios Web son por definición independientes de la plataforma; es decir, los usuarios pueden interactuar con la aplicación independientemente del tipo de explorador que tengan, e incluso, del tipo de equipo que utilicen. (Ceballos, 1999)[4].

4.3.5 Visual Studio Visual Studio es un conjunto completo de herramientas de desarrollo para construir aplicaciones Web, servicios Web, aplicaciones Windows o de escritorio y aplicaciones para dispositivos móviles. El entorno de desarrollo integrado que ofrece esta plataforma como todas sus herramientas y con la biblioteca de clases .NET Framework, es compartido en su totalidad por Visual Basic, Visual C++, y Visual C#, permitiendo así crear con facilidad soluciones en las que intervengan varios lenguajes y en las que el diseño se realiza separadamente respecto a la programación.

4.3.6 Servidor de Aplicaciones. Es un software que proporciona aplicaciones a los equipos o dispositivos cliente, por lo general a través de internet y utilizando el protocolo http. Los servidores de aplicaciones se distinguen de los servidores web por el uso extensivo de contenido dinámico y por su frecuente integración con base de datos.

Un servidor de aplicaciones es un producto basado en un componente que se encuentra en el plano intermedio de la arquitectura central de un servidor. Proporciona servicios “middleware” es decir, trabaja con un intermediario para la seguridad y el mantenimiento además de proveer el servicio a datos.

4.3.7 Controles Propietarios Paquete realizado por otros proveedores de software que distribuyen versiones personalizadas y mejoradas de los controles ASP tradicionales existentes dentro de VisualStudio.NET.

4.3.7.1 Controles de Telerik para ASP Ajax Controles Web para páginas ASP desarrollados por una empresa Búlgara cuyo nombre es Telerik. La distribución de controles ASP es una versión mejorada de los controles típicos que vienen dentro

47

de Visual Studio y permiten realizar las mismas tareas pero con controles enriquecidos y visualmente mejor trabajados. Actualmente se ha distribuido la versión 2015 Q1.

48

5. METODOLOGÍA

5.1 PROGRAMACIÓN EXTREMA

La Programación Extrema (XP) forma parte del movimiento de desarrollo ágil de software que se basa en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto y que tiene como premisas los siguientes aspectos (Beck, 1999)[8]:

• Los individuos y sus interacciones son más importantes que los procesos y las herramientas.

• El software que funciona es más importante que la documentación exhaustiva.

• La colaboración con el cliente en lugar de la negociación de contratos. • La buena disposición ante el cambio en lugar de seguir un plan cerrado.

La Programación Extrema es un enfoque que ha adoptado prácticas de desarrollo de software ya existentes en otras metodologías de desarrollo y las ha llevado al extremo. Un ejemplo de ello es la retroalimentación que es importante para los programadores, analistas, diseñadores, usuarios y computadores. Así que la programación extrema usa ciclos de retroalimentación cada vez más rápidos e intensos, que proporcionan más información. Este enfoque de programación intenta definir un plan global del sistema, desarrollar y liberar rápidamente el software y posteriormente revisarlo de forma continua para incorporarle características adicionales. (Kendall, 1999)[7].

La implementación de cada uno de los principios y valores que esta metodología sugiere será descrita a continuación queriendo explicarse el cómo será puesto en práctica para obtener los mejores resultados durante todo el desarrollo del proyecto en Cyza Outsourcing S.A.

5.1.1 Valores de la Programación Extrema Debido a que frecuentemente existe una tensión entre lo que los diseñadores hacen a corto plazo y lo que es comercialmente deseable a largo plazo es importante ser consciente de apoyar los valores que formarán una base colaborativa en un proyecto de software. Tales valores son:

49

• Comunicación: Los proyectos de los sistemas que requieren una actualización constante y un diseño técnico, son especialmente propensos a errores por falta de comunicación. Si se suman problemas típicos como fechas de entrega ajustadas, uso de jerga especializada y la muy común concepción de que los programadores son poco comunicativos con las personas, entonces hay serias posibilidades de fallar en éste ámbito. Para ello ya se aplica en el área de desarrollo la práctica de reuniones cortas y periódicas de alrededor de 15 minutos para resolver dudas e inquietudes entre los miembros del equipo y el director de desarrollo y para enterarse de los avances del proyecto.

• Simpleza: Es un pensamiento que implica no abrumarse por la aparente complejidad de la tarea. Consiste en comenzar por el elemento más sencillo y a partir de allí construir el requerimiento con sus características adicionales, pero para ello se debe tener claro el enfoque referente a las metas del proyecto.

• Retroalimentación: Ocurre cuando existe un prototipo que es evaluado por los clientes y principales interesados en ese desarrollo. Una retroalimentación crítica viene de los clientes que comparan la meta del plan con el progreso que se ha tenido. De esta manera la retroalimentación ayuda a los programadores a hacer los ajustes necesarios para orientar el software al resultado esperado.

• Valentía: Este valor se rige por un nivel de confianza propio y a su vez existente en el equipo de desarrollo. Es no tener miedo a empezar de nuevo si es necesario, teniendo la perspicacia de reconocer ese momento ayudándose del instinto. Para Kendall (1995)[7]“La valentía es un valor de alto riesgo y de alta recompensa que anima a la experimentación que el equipo puede tomar de una forma más rápida e innovadora para lograr su meta” (Kendall, 1995)[7].

5.1.2 Principios básicos de la Programación Extrema Se trata de doce principios agrupados en cuatro grandes categorías así (Kendall, 1995)[7]:

5.1.2.1 Retroalimentación a escala fina.

• El principio de pruebas: Se debe establecer un periodo de pruebas de aceptación del programa comúnmente denominado “periodo de caja negra” donde se definirán las entradas al sistema y los resultados esperados de

50

estas entradas. El área de desarrollo cuenta con la participación de una ingeniera con el rol de “Encargada de Pruebas” (tester) y está en la capacidad de realizar las pruebas unitarias que pretenden medir el funcionamiento puntual de una parte de la aplicación.

• Proceso de planificación: en esta fase el cliente tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado “Historias del Usuario” (UserStories) que conformarán el “Plan de Liberación”, el cual define los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario.

• El cliente en el sitio: tendrá la potestad de determinar los requerimientos, definir las funcionalidades, señalar las prioridades y responder a las preguntas de los programadores. Esta fuerte interacción con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes que su creación generan. Para Cyza el principal cliente será el representante del área que hará un fuerte uso del sistema de control de inventarios que para este caso se trata del área de infraestructura quienes son los que actualmente llevan a cabo el levantamiento de inventario sobre los equipos de la compañía.

• Programación en parejas: Este principio requiere que los programadores que sigan esta metodología escriban su código en parejas, compartiendo una sola máquina para promover el trabajo en equipo y el incremento de la calidad en el código. Esta práctica ayuda a reducir el porcentaje de errores que se producen al codificar ya que tal revisión es realizada por las dos personas que están trabajando sobre el mismo código y promueve la difusión de la funcionalidad completa del software a más de un miembro del equipo evitando dependencia a una sola persona y la privatización del código.

Para cubrir este principio en Cyza Outsourcing teniendo en cuenta de que se trata de una propuesta de pasantía individual, se propone someter la codificación a un procedimiento ya existente en la empresa y es el de publicar a un servidor de control de versiones (SVN) el proyecto que se va a realizar, permitiendo el acceso a este repositorio por otros miembros del departamento. Puntualmente el jefe del área de desarrollo tendrá acceso como líder del grupo y al realizar un rol de “Coach” (Entrenador del proyecto) estará en la obligación de conocer los aspectos relevantes del aplicativo y su funcionamiento, esto con el fin de poder generar las directrices apropiadas durante todo el ciclo de desarrollo. Otro rol que podrá

51

actuar como colaborador en este aspecto será el “tester” a quien podrá indicársele el comportamiento de la funcionalidad que está a punto de probar. Como el área de desarrollo de Cyza es pequeño es común que los compañeros de codificación conozcan funcionalidades, estándares de codificación en común e inclusive se relaten experiencias de codificado que otro miembro del grupo haya experimentado en sus proyectos para ser retroalimentado al grupo.

5.1.2.2 Proceso continuo en lugar de por lotes

• Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear “builds” (versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. El entorno de trabajo de VisualStudio.Net facilita la realización de este ejercicio ya que su Framework incluye un Servidor de Aplicaciones virtual que permite compilar y ejecutar el aplicativo en tiempo real para lograr visualizar los avances obtenidos.

• Refactorización: permite mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y re codifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado e ineficiente.

• Entregas pequeñas: sugiere colocar un sistema sencillo en producción rápidamente para actualizarse de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar de las 2 o 3 semanas como máximo. Para ello el área de desarrollo dispone de un servidor virtualizado de pruebas y con las características que pudiera compartir un ambiente real de producción en cuanto a configuración y garantía de requerimientos para la publicación de la versión. Este servidor no cubrirá aspectos puntuales de accesibilidad como concurrencia o altos recursos ya que solo se pretende evaluar la funcionalidad del desarrollo de software publicado.

52

5.1.2.3 Entendimiento Compartido

• Diseño simple: se basa en la filosofía de que el mayor valor de los negocios es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.

• Metáfora: es desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias que son breves descripciones de un trabajo de un sistema.

• Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método evita hacer lo que hacen los métodos tradicionales en los que un simple programador posee un conjunto de código y solo él conoce su funcionamiento.

• Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas del mismo, desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.

5.1.2.4 Bienestar del programador

La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor calidad. Minimizar las horas extras y mantener los programadores frescos generará código de mayor calidad. Esta es una premisa que se cumple a cabalidad en Cyza Outsourcing. Si por alguna razón no se completó una tarea para el mismo día entonces será resuelto al día siguiente y así evitar sobrecargar el estado anímico y físico del programador.

53

5.1.3 Roles dentro de la programación extrema

5.1.3.1 El cliente Es el responsable de conducir el proyecto. Toma decisiones de negocio y debe entender los cambios del mismo a lo largo del tiempo: identifica si una historia tiene el mismo valor ahora que cuando se identificó.

Derechos

• Cambiar el alcance del proyecto para hacer frente a los cambios en la planificación.

• Determinar qué funcionalidades serán las siguientes en implementarse. • Medir el progreso del proyecto en cualquier momento, lanzando las pruebas

de aceptación. • Detener el proyecto en cualquier momento sin perder la inversión realizada,

manteniendo en producción un producto estable y continuar planificando otras funcionalidades más importantes.

Responsabilidades

• Confiar en las decisiones técnicas de los desarrolladores. • Analizar los riesgos correctamente. • Seleccionar las historias que aportan más valor para cada iteración. • Definir las historias de usuario de forma precisa, permitiendo a los

desarrolladores realizar estimaciones precisas. • Participar en el equipo ofreciendo directrices y feedback tan pronto y

preciso como sea posible.

5.1.3.2 El Programador Una vez que se han comprendido las historias de usuario, la metodología XP adjudica a los programadores la responsabilidad de tomar decisiones técnicas. Los desarrolladores estiman el tiempo que les va a tomar cada historia y transforman las historias de usuario en código.

Derechos

• Estimación de su propio trabajo, teniendo autoridad para tomar decisiones técnicas.

• Delimitar el trabajo responsabilizándose de aquellas tareas que van a ser capaces de llevar a cabo.

• Implementar la funcionalidad que cubre las necesidades del cliente.

54

• No tomar decisiones de negocio.

Responsabilidades

• Seguir las directrices del equipo. • Desarrollar las funcionalidades realmente necesarias. • Establecer una comunicación fluida con el cliente.

5.1.3.3 El Tester Es el encargado de las pruebas y ayuda al cliente a definir y escribir las pruebas de aceptación de las historias de usuario. Este rol en un equipo XP también es responsable de realizar test periódicamente e informar los resultados al equipo.

5.1.3.4 El Coach Su papel es guiar y orientar al equipo y su objetivo es que el equipo comprenda las directrices de XP. No se trata de que sean solo lecciones teóricas sino que debe conocer el aspecto práctico de la metodología para ofrecer ejemplos y proponer ideas que permitan mejorar.

5.1.3.5 El Tracker Hace el seguimiento de acuerdo a la planificación. La métrica más importante para XP es la velocidad del equipo que se define como el tiempo ideal estimado para las tareas frente al tiempo real dedicado. Ésta métrica ayuda a determinar si el proyecto está dentro del tiempo de la iteración. Este rol puede ser tomado por el Coach.

5.1.3.6 Big Boss Es la persona que tiene la idea general del proyecto y está familiarizado con su estado. El cliente puede asumir este papel.

5.2 PROTOTIPOS

Este tipo de programación está concebido para conocer de primera mano el interés y la reacción de los usuarios y de los directivos hacia el prototipo, conocer cómo reaccionan al interactuar con él y qué tan preparado está dicho prototipo para satisfacer sus necesidades de acuerdo a las características del sistema que se adoptó para elaborarlo (Kendall, 1995)[9]. Para efectos de integrar esta práctica como una metodología complementaria a la programación extrema solo se explicará un tipo de prototipo que será el ideal para integrarlo al modelo general de trabajo con la programación extrema y que operará bajo un carácter colaborativo e

55

inclusive puede definirse como un componente dependiente del enfoque general de XP.

5.2.1 Prototipo corregido Tiene que ver con la construcción de un sistema que funciona pero que se corrige simultáneamente. Conocido también como elaboración de una tabla experimental. En los sistemas de información corresponde a un modelo funcional que tiene todas las características necesarias pero es ineficiente. Esto se presenta debido a que el programa se escribió rápidamente con el objeto de ser funcional en lugar de ser eficiente.

5.2.2 El prototipo corregido dentro de la Programación Extrema Para entender la función de un prototipo dentro del esquema de la programación extrema hay que conocer la etapa de XP donde el prototipo entra a participar.

Figura 25. Taller de Diseño RAD (Rapid Application Management)

Fuente: Análisis y Diseño de Sistemas. Kendall &Kennetp.162

El Taller de Diseño RAD se puede representar como un taller donde se diseña y se refina un prototipo existiendo una participación intensa, no pasiva donde

56

interviene el cliente y el desarrollador. Durante el taller de diseño RAD, los usuarios responden a los prototipos operativos reales y los analistas refinan los módulos diseñados basados en las respuestas de los usuarios. El formato de taller es muy estimulante y si están presentes los usuarios y los analistas experimentados no queda duda de que el esfuerzo creativo puede impulsar el desarrollo.

Habiendo explicado esto, el prototipo es el resultado del análisis de las historias de usuario y su representación funcional. También puede ser pensado como el producto que puede presentarse al usuario para ser sometido a su evaluación y aprobación. Dentro de la etapa de trabajo con el usuario y la construcción del sistema existen varias iteraciones que van reforzando la conformación del prototipo como un componente más robusto y cercano a la solución que el usuario espera recibir. Para la ejecución del sistema de gestión de inventarios aunque se trate de un problema conocido, por el hecho de tratarse de un software hecho a la medida obliga a presentar una propuesta que se asemeje a lo puntualmente requerido por Cyza Outsourcing S.A. en condición de agente solicitante. El prototipo resultante debe ser sometido a criterio del usuario o cliente a manera de preliminar. Cuando haya pasado por las iteraciones suficientes este prototipo no se desecha sino que inmediatamente hará parte de la solución.

5.3 ESTRUCTURA DE DESGLOSE EDT

Metodología que permite descomponer las actividades y tareas de forma jerárquica un proceso de desarrollo o ejecución de un proyecto. El propósito de la EDT es organizar y subdividir el desarrollo en componentes más pequeños y más fáciles de manejar, permitiendo predecir diversos escenarios, optimizar decisiones, medir recursos utilizados con exactitud y generar plan para la implementación de un proyecto. (PMBOK, 2014)[11]

57

Figura 26. Diagrama típico de un esquema de desglose de trabajo

Fuente: http://www.pmoinformatica.com/2013/12/plantilla-estructura-desglose-trabajo.html

58

6. DISEÑO METODOLÓGICO

La metodología para el desarrollo del software utilizada es programación extrema, bajo un procedimiento de arquitectura multicapa y con sistema de seguimiento, control y aprobación por ciclos y prototipado.

El proyecto se desarrolla en 5 fases, fase Levantamiento de datos, fase de planeación, fase desarrollo, fase de pruebas y fase de cierre.

6.1 FASE DE LEVANTAMIENTO DE DATOS

Se identifican los actores principales para definir las necesidades y requerimientos que desean que el software satisfaga, todas estas solicitudes son llevadas a papel en un formato de “historias de usuario”.

De este proceso se genera documentación de requerimientos, casos de uso y se establece cronograma de actividades y desglose de trabajo (EDT)

6.1.1 Identificación de Interesados Se enlistan las personas que están en potestad para determinar requerimientos, definir las funcionalidades, señalar las prioridades y responder a las preguntas del programador.

Tabla 1. Listado de Interesados Sistema de Inventarios Cyza

Nombre Apellidos

Organización Cargo Rol en Proyecto

Influencia en Fase del Proceso

Jhon Roldan CYZA Director de Tecnología

Rol de Cliente – Coach – Traker – Big Boss

ALTA

Jorge Araque CYZA Analista de Desarrollo

Rol de Programador

MEDIA

William Ortiz CYZA Analista de Infraestructura

Rol de Cliente BAJA

Leandro Ovalle CYZA Director Operativo

Rol de Cliente ALTA

Jaime Rincón CYZA Gerente Rol de Patrocinador

ALTA

Johana Lesmes CYZA Analista de Pruebas

Rol de Tester MEDIA

59

6.1.2 Historias de Usuarios Se realiza entrevista a los interesados del proyecto y se toma los datos de los requerimientos en el formato “Historias de usuario”. (Anexo "Historias de Usuario"). La información anotada se muestra a continuación.

Tabla 2. Historia de Usuario HU1

HISTORIA DE USUARIO ID: HU1

NOMBRE: Autenticación de Usuarios.

PRIORIDAD EN NEGOCIO: alta USUARIO: Jhon Jairo Roldan

CARGO: Director De Tecnología

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Los usuarios que ingresen a la aplicación deben estar autenticados mediante Directorio Activo garantizando que sean usuarios que pertenecen al esquema organizacional de la empresa. OBSERVACIONES: La empresa ya cuenta con un esquema de Directorio Activo, el software debe integrarse a dicho esquema. Sin embargo puede usar un método de autenticación solo de software permitiendo validación dual tanto de AD como del propio software.



NOMBRE: Propiedades de los elementos a ingresar

PRIORIDAD EN NEGOCIO: alta USUARIO: William Ortiz

CARGO: Analista de Infraestructura

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Los elementos que se ingresen al Sistema de Inventarios deben tener en su descripción unas propiedades elementales las cuales son:

- Número de placa - Serial - Modelo - Marca - Responsable - Estado

OBSERVACIONES: A estas propiedades se le pueden agregar cuantas características sean requeridas para complementar la descripción de cada elemento.

60



NOMBRE: Módulos en el software


CARGO: Director De Tecnología

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: La aplicación debe estar dividida en módulos. Cada modulo debe encargarse de una sola funcionalidad y debe estar claramente diferenciado de otra. OBSERVACIONES:



NOMBRE: Colores corporativos y logos

PRIORIDAD EN NEGOCIO: media USUARIO: Leandro Ovalle

CARGO: Director de Operaciones

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: La presentación visual del software debe llevar los logos de la empresa y un formato de colores acorde con la presentación corporativa. OBSERVACIONES:



NOMBRE: Creación de roles personalizados.


CARGO: Director de Tecnología

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: El Sistema de Inventarios debe tener la capacidad de asignar roles a un usuario. Estos roles se deben personalizar de tal manera que pueda efectuar tareas puntuales y a la vez diferentes a otro rol. Para ello cada rol puede involucrar el acceso de algunos de los módulos presentes en la aplicación y denegar el acceso a otro módulo según sea requerido en el momento. OBSERVACIONES:

61



NOMBRE: Acceso al Sistema de Inventarios.


CARGO: Director de Tecnología

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: La aplicación debe poder ser accedida tanto en la red interna de la empresa como a través de internet por intermedio del servidor de aplicaciones de Cyza. OBSERVACIONES:



NOMBRE: Pistola Lectora de Barras

PRIORIDAD EN NEGOCIO: USUARIO: Jhon Jairo Roldan

CARGO: Director de Tecnología.

DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Es primordial el uso de pistolas lectoras de código de barras en el proceso de enrolamiento de elementos en el Sistema de Inventarios para facilitar la captura de los datos. Deben poder usarse tanto en el formulario de ingreso y cuando se realice una búsqueda. OBSERVACIONES:



NOMBRE: Uso de herramientas ADO para comunicación con Bases de Datos

PRIORIDAD EN NEGOCIO: media USUARIO: Jhon Jairo Roldan


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: La aplicación debe conectarse con un Motor de Bases de Datos SQL y usar componentes que agilicen y gestiones las conexiones como Enterprise Library. OBSERVACIONES:

62



NOMBRE: criterios de búsqueda



DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Para el módulo de consultas es necesario utilizar un componente que permita personalizar las búsquedas y obtenga los datos según el criterio del usuario. No se debe limitar a buscar por un solo criterio. OBSERVACIONES:



NOMBRE: Consultores y Administradores de Inventarios

PRIORIDAD EN NEGOCIO: media USUARIO: William Ortiz


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Debe existir usuarios que solo puedan consultar información del inventario y otro usuario que pueda realizar cambios y asignaciones de elementos de una sede a otra para que se garantice que ese elemento haya sido autorizado a ser cambiado por una sola persona o un grupo específico de administradores. OBSERVACIONES:



NOMBRE: Apariencia de textos

PRIORIDAD EN NEGOCIO: baja USUARIO: Jhon Jairo Roldan


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: El texto de los frontales debe ser grande y estilizado. Que maneje fuentes llamativas y con una presentación fresca y clara. OBSERVACIONES:

63



NOMBRE: Seguimiento de los elementos en el inventario



DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: El sistema debe permitirme hacer consulta sobre todos los movimientos realizados a un elemento de tal manera que pueda identificar que traslados pudo tener, así como las ubicaciones que haya podido tener hasta la actualidad. También debe indicarme el nombre del usuario que ha realizado tales modificaciones. OBSERVACIONES:



NOMBRE: Exportar Consultas Personalizadas.



DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: La aplicación debe permitirme exportar a un archivo en Excel una consulta específica que realice. De ésta manera debo poder filtrar la información de los elementos por varios criterios específicos y a su vez generar un archivo de salida del resultado de la búsqueda OBSERVACIONES:



NOMBRE: Instalar Servicio de Windows en maquinas inventariadas.

PRIORIDAD EN NEGOCIO: USUARIO: Jhon Jairo Roldan


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Específicamente para el inventario de computadores se debe crear un instalador que se ejecute en el equipo que va a ser inventariado para que funcione como un Servicio de Windows y pueda obtener toda la información relacionada al Software y Hardware instalado. Esta información debe estar vigente todo el tiempo por lo que si se detecta un cambio, la aplicación

64

pueda enviar la información al Sistema de Inventarios y mantenga vigente la configuración del equipo. OBSERVACIONES:



NOMBRE: Panel de bienvenida.

PRIORIDAD EN NEGOCIO: bajo USUARIO: Jhon Jairo Roldan


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Incluir un panel de mensaje de bienvenida al sistema y que permita poner allí noticias o información relevante que pueda ser visto por cualquier usuario que ingrese a la aplicación. OBSERVACIONES:



NOMBRE: Clasificación de los elementos

PRIORIDAD EN NEGOCIO: media USUARIO: William Ortiz


DESARROLLADOR ENCARGADO: Jorge Araque (Analista De Desarrollo) DESCRIPCION: Cada elemento que se ingrese a la aplicación debe poder ser clasificado por un tipo de elemento, ser asociado a un área y pertenecer a una sede de la empresa OBSERVACIONES:

6.1.3 Levantamiento de Requerimientos Se procede a Analizar las historias de usuario y de acuerdo a ello se establecen requerimientos funcionales y no funcionales con sus respectivas entradas y salida del proceso, condiciones y restricciones para su funcionamiento. De este proceso se diligencia el formato “Formato de Levantamiento de Requerimientos”.

65

6.1.3.1 Requerimiento Funcionales

Tabla 18. Requerimiento Funcional REQ-FNC-01

REQ-FNC-01 Tipo de Requerimiento:

Nueva Funcionalidad

Descripción: Cada usuario que ingrese a la aplicación debe autenticarse. Para ello existirá un método que hará una consulta al Directorio Activo para que sea él quien determine si el usuario existe y si las credenciales de nombre y contraseña son correctas. Éste método se define como autenticación por Directorio Activo y el acceso a la aplicación dependerá de su estado en del DA.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 1 de enero de 2014 Actor: Administrador de Aplicación Precondiciones: - El Administrador es el único usuario que existirá desde el

comienzo de la aplicación. - La aplicación debe conectarse al servidor de Directorio Activo - El usuario debe existir en el Directorio Activo

Pos condiciones: - Un usuario creado existirá en la aplicación como un usuario ligado a sus credenciales de Directorio Activo.

Entradas: - Los datos de un usuario nuevo que será creado. Restricciones: - Solo existirá un usuario reservado en la aplicación (el primer

administrador) Salidas: - Un usuario enlazado con procedimiento de autenticación

contra Directorio Activo lo que implica usar las credenciales de acceso del Directorio Activo.



Nueva Funcionalidad

Descripción: Un usuario puede ser creado y asociado al método de autenticación propietaria que permite validar dicho usuario localmente para la aplicación sin pertenecer a un Directorio Activo. Para éste caso las credenciales de usuario y su información complementaria estará presente en la base de datos de la aplicación.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 8 de enero de 2014 Actor: Administrador del Sistema Precondiciones: - Debe existir un Administrador del Sistema

- No debe existir el usuario que está en proceso de creación. Pos condiciones: - Se habrá creado un nuevo usuario con el método de

autenticación propietaria lo que implica que no requiere existir

66

en el Directorio Activo. Entradas: - Los datos relevantes al nuevo usuario que se va a crear. Restricciones: - NA Salidas: - Un nuevo usuario bajo autenticación propietaria.



Nueva Funcionalidad

Descripción: La aplicación tendrá un módulo que se encargará del ingreso de elementos al Sistema. Éste módulo tendrá un formulario con campos que representan las propiedades de cada elemento ingresado.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 8 de enero de 2014 Actor: Usuario con rol de enrolador de elementos Precondiciones: Se establece que los elementos ingresados tendrán los

siguientes datos - Id Elemento, Numero de Placa, Marca, Modelo, Serial, Sede,

Área, Responsable, Observaciones, Fecha Registro, Fecha Ingreso, Categoría

Pos condiciones: - Se ingresa el elemento a la Base de Datos. Entradas: - Ingreso de elementos mediante el “formulario de ingreso”. Restricciones: NA Salidas: - Dialogo de confirmación del ingreso de elementos.



Nueva Funcionalidad

Descripción: Se implementará un módulo con la capacidad de gestionar “Grupos” que contengan asociaciones de módulos. De ésta manera un Grupo puede contener uno o más módulos de la aplicación y tener un nombre específico. Ejemplo: puede existir un grupo llamado “Enrolador” que tenga habilitado el módulo de “ingreso de elementos” y el de “consulta de elementos”

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 15 de enero de 2014 Actor: Administrador de Usuarios Precondiciones: - Deben existir módulos creados.

67

Pos condiciones: - Se crearán grupos que contengan módulos. Entradas: - Un nuevo Grupo vacío.

- Adición de módulos al nuevo grupo Restricciones: - Un grupo solo puede contener módulos y no ser

contenedor de otro grupo. Salidas: - Un grupo con módulos internamente.



Nueva Funcionalidad

Descripción: Dentro del módulo de “administración de usuarios” se requiere gestionar usuarios de tal manera que pueda asignarse de forma personalizada la pertenencia a uno o varios de los grupos creados en el “módulo de gestión de Grupos”.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 15 de enero de 2014 Actor: Administrador de Usuarios Precondiciones: - Deben existir Grupos creados

- Deben existir Usuarios creados Pos condiciones: - Los usuarios tendrán asignado uno o varios grupos. Entradas: - Un usuario creado sin asignación de grupos. Restricciones: - Un usuario de Directorio Activo no puede personalizar

sus grupos Salidas: - Usuarios con asignación de grupos que le dan acceso a

los módulos incluidos dentro de cada grupo.



Nueva Funcionalidad

Descripción: El Sistema de Gestión de Inventarios debe ser publicado en un Servidor con rol de aplicaciones que tenga una IP pública para ser accedido desde internet. Para ello se dispondrá del Servidor de Aplicaciones de Cyza.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 15 de enero de 2014 Actor: Analista de de Desarrollo Precondiciones: - Disponer de un Servidor de Aplicaciones

- Conocer la Ip Publica del Servidor. Pos condiciones: - El Sitio Web estará publicado en el servidor.

68

- Se podrá acceder al Sitio Web desde cualquier equipo con internet.

Entradas: - Binarios de la aplicación listos para ser publicados. Restricciones: Salidas: - Acceso a la aplicación por medio de la URL del sitio web.



Nueva Funcionalidad

Descripción: Crear un módulo de búsqueda que se encargará de presentar las herramientas necesarias para que un usuario de la aplicación pueda realizar las búsquedas de elementos del inventario de forma precisa. El usuario puede usar un control que realizará el filtro por criterios directamente relacionados con las propiedades del elemento.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 15 de enero de 2014 Actor: Usuario consultor Precondiciones: - El usuario debe pertenecer a un grupo con acceso al

módulo de consultas Pos condiciones: - El frontal le presentará el resultado de la búsqueda en una

rejilla con los datos de los elementos que cumplen con el criterio de búsqueda.

Entradas: - Número de placa, serial, modelo, fecha de ingreso, área, sede, categoría nombre del responsable.

Salidas: - Listado de elementos que cumplen con las condiciones de búsqueda



Nueva Funcionalidad

Descripción: Se requiere un módulo que permita visualizar el histórico de movimientos realizados a todos los elementos de la aplicación. Cada vez que un elemento del inventario es modificado por un usuario con los permisos requeridos para dichas modificaciones, la aplicación debe registrar el historial de cambios, describiendo allí que elemento cambió, cuál era su estado anterior y cuál es el estado actual. Además el registro debe incluir la fecha de cuando se realizó la modificación y el nombre del responsable de la acción.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 17 de enero de 2014

69

Actor: Administrador del Sistema. Precondiciones: Debe haberse realizado al menos una tarea de modificación

para una de las propiedades del elemento del inventario. Pos condiciones: Se visualizará un listado de registros que muestren las

modificaciones realizadas a los elementos del inventario. Entradas: - Acceso al módulo de histórico de movimientos Restricciones: - Solo podrá acceder el usuario con pertenencia al grupo

correcto. Salidas: - Un listado de registros que evidencien modificación en

alguna de las propiedades del elemento de inventario.



Nueva Funcionalidad

Descripción: Es necesario contar con un módulo que permita personalizar una consulta y que a su vez permita exportar a un archivo de Excel el resultado de la consulta

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 21 de enero de 2014 Actor: Usuario Generador de Reportes Precondiciones: - Conocer el criterio de consulta y acceso al módulo de

reportes. Postcondiciones: - Archivo con formato xls con el resulta de la consulta. Entradas: - Los criterios de consulta adecuados para generar la salida

correcta Restricciones: - Se requiere un usuario con permiso para acceder al módulo. Salidas: - Se genera un documento de Excel con el resultado de la

consulta.



Nueva Funcionalidad

Descripción: Se requiere la creación de un Paquete de Instalación que permita la instalación de un Servicio de Windows que se ejecute en segundo plano y que tenga la facultad de obtener toda la información referente a la configuración de Hardware y de Software del equipo donde se hospeda. La aplicación evaluará si existe un cambio de hardware o de software y en el siguiente reinicio del equipo enviará la nueva información vía Servicios Web al Servidor del Sistema de Gestión de Inventarios. Para que el programa identifique el software o

70

hardware debe interactuar con el servicio de WMI presente en los sistemas Windows

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 21 de enero de 2014 Actor: Servicio de Windows Precondiciones: Se debe instalar el Servicio de Windows en el Sistema

Operativo del equipo al que se pretende obtener la información de hardware y software.

Pos condiciones: Llegará a la base de datos la información relacionada con la configuración de hardware y software que tiene dicho equipo.

Entradas: NA Restricciones: Si en el próximo reinicio no se encuentra ningún tipo de

cambio la aplicación no tendrá la necesidad de enviar datos. Salidas: El resultado de los cambios de hardware o software que haya

tenido la maquina será escrito en la base de datos donde posteriormente podrá ser consultado.



Nueva Funcionalidad

Descripción: La aplicación debe tener un módulo que permita gestionar los elementos del inventario pero debe ser manipulado por un usuario o un grupo de usuarios con perfil de administrador el cual esté al tanto de los cambios que eventualmente tengan los elementos, ya sea sobre su estado, su ubicación o la persona a la que ha sido asignada.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 21 de enero de 2014 Actor: Usuario Administrador Precondiciones: Habrá más de un elemento susceptible a cambio de ubicación, estado o

cualquier otra característica que describa al elemento. Pos condiciones: Se generará modificación sobre alguna de las propiedades del elemento

sujeto al cambio. Entradas: - Búsqueda del elemento que será sometido a modificación. Restricciones: - Ésta operación debe ser realizada únicamente por un usuario con

perfil de administración (que pertenezca a un grupo con modulo de Gestión de Elementos)

Salidas: - El elemento con algunas de sus propiedades modificadas - Un registro en el histórico de movimientos.

71

6.1.3.2 Requerimiento no Funcionales

Tabla 29. Requerimiento No Funcional REQ-NFN-01

REQ-NFN-01 Tipo: Usabilidad Descripción: Para apoyar el proceso de captura de información de los

elementos para ingresar al inventario se incluye el uso de captura mediante la pistola lectora de barras.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 08-enero-2014 Requerimiento Padre: REQ-FNC-03


REQ-NFN-02 Tipo: Usabilidad Descripción: Para mejorar la conectividad con base de datos se sugiere el uso de

herramientas ADO que administren mejor las conexiones hacia base de datos. Uno de éstos elementos es Enterprise Library que realiza la apertura (Open) y cierre (Close) de conexión de manera automatizada mientras que solo deba preocuparse por la construcción de los querys.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 08-10-2014 Requerimiento Padre:


REQ-NFN-03 Tipo: Visualización Descripción: Fomentar el uso en los frontales de la aplicación de textos grandes y

elegantes que permitan una presentación más clara y fresca. Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 08-10-2014 Requerimiento Padre: REQ-FNC-113 del paquete de requerimientos 40


REQ-NFN-04 Tipo: Visualización Descripción: Implementar en el panel principal de la aplicación un Panel de

Bienvenida al cual se le pueda personalizar el texto y permita a los usuarios ver allí alguna tarea o noticia relevante. Hará las veces de Cartelera con anotaciones que se consideren importantes o no.

Autor: Jorge Araque Solicitante Ing. Jhon Jairo Roldan Fecha de Creación: 08-10-2014 Requerimiento Padre: REQ-FNC-113 del paquete de requerimientos 40

72

6.1.4 Casos de Uso Se establecen las iteraciones actor-software de cada uno de los requerimientos establecidos y se diagraman a continuación:

Figura 27. Caso de Uso para REQ-FNC-01

Figura 28. Diagrama Caso de Uso para REQ-FNC-02

73




74


75



76



Figura

6.1.5 Diagramación diagrama de funcionalidades del software resultado del datos. Los objetivos y lo que se quiere que el programa realice, se muestra en el Diagrama a continuación.

77

Figura 37. Diagrama Caso de Uso para REQ-FNC

de Flujos de Sistema De Inventariosdiagrama de funcionalidades del software resultado del estudio y levantamiento de datos. Los objetivos y lo que se quiere que el programa realice, se muestra en el Diagrama a continuación.

FNC-11

De Inventarios Se establece y levantamiento de

datos. Los objetivos y lo que se quiere que el programa realice, se muestra en el

78

6.1.5.2 Diagrama de Funcionalidades y procesos Sistema de Control de Inventarios Cyza

Figura 38. Diagrama de Secuencia por Funcionalidad Identificada Sistema de Control de Inventarios Planteado

6.2 FASE DE PLANEACIÓN

6.2.1 Plan de Desarrollo

6.2.1.1 Módulos de Software El Sistema de Control de Inventarios se va a dividir en módulos, encargados cada uno de un rol específico entre las funcionalidades

79

del software. Cada Módulo es programado e incluyendo en un Módulo base prototipo (Proyecto Base), el cual va integrando cada pequeña entrega y unificando las funcionalidades para el Software.

A continuación, se indican los módulos programados para desarrollar en el software.

Tabla 33. Tabla de Módulos del Sistema de Inventario Cyza

Modulo Funcionalidad Dependencia Dependiente Prioridad Módulo de Ingreso de Elementos

Permite registrar en el Sistema de Inventarios un elemento nuevo

Módulo de Consulta Módulo de Generación de reportes Módulo de Gestión de elementos

Depende de módulo de Administración de grupos

Alta

Módulo de Consultas

Permite realizar consulta de elementos ya registrados

Ninguno Depende del módulo de Ingreso de elementos y módulo de Administración de grupos

Media

Módulo de Generación de Reportes

Exporta consultas a un archivo en Excel

Ninguno Depende del módulo de Ingreso de elementos y módulo de Administración de grupos

Baja

Módulo de Administración del Sistema

Administra parámetros de la aplicación y la Gestión de Grupos

Ninguno Ninguno Alta

Módulo de Administración de Usuarios

Administra el método de autenticación y los grupos a los que pertenecerá un usuario

Acceso a todos los módulos de la aplicación

Ninguno Alta

Proyecto base Contiene toda la estructura básica y las

Todos los futuros módulos de la

Ninguno Muy alta

80

rutinas de comunicación con base de datos

aplicación

Construcción de Servicios Web

Expone todas las funciones que permiten a una aplicación cliente la comunicación con el Sistema de Inventarios

Genera dependencia a la aplicación cliente que se comunicará con éste servicio web

Depende de la inclusión propuesta por la aplicación base

Alta

Instalador Cliente y Servicios Windows

Paquete de instalación que se ejecuta como un servicio de Windows que enviará datos de hardware y software del computador host

Genera dependencia del módulo de consultas

Depende de la existencia de los Servicios Web

Media

6.1.6.1 Esquema General Sistema de Control de Inventarios Cyza

Figura 39. Esquema General Funcional Sistema de Control de Inventarios Planteado

Fuente: Diseño personal. Realizado con la herramienta de diseño Paint.Net con Licencia LGPL

81

6.2.1.1 Desglose de Trabajo EDT Se realiza las subdivisiones del proceso de desarrollo de cada módulo, desglosando la actividad en tareas particulares para establecer con facilidad tiempos, esfuerzo y orientación en el proceso de programación.

Tabla 34. Tabla de Desglose de Trabajo Sistema de Inventario Cyza

Orden Actividad-Tareas 1 Sistema de Gestión de Inventarios 1.1 Preparación Proyecto Base 1.1.1 Base de Datos 1.1.1.1 Construcción de Modelo Entidad Relación Base 1.1.1.2 Implementación en SQL Server de la Base de Datos 1.1.2 Capa de Datos 1.1.2.1 Construcción de Componentes ADO para comunicarse con Base

de Datos 1.1.2.2 Implementación de Enterprise Library para operaciones CRUD

con BD 1.1.2.3 Creación de Clases que almacenan las funciones principales para

consulta a BD 1.1.3 Capa de Negocio 1.1.3.1 Creación de Clases Utilitarias para encapsular funciones de

Seguridad o Encriptación 1.1.3.2 Clases que conforman el ACL (Listas de Control de Acceso) 1.1.4 Capa de Presentación. Interfaz de usuario. 1.1.4.1 Creación de Pagina Maestra 1.1.4.2 Creación de Pagina de Login 1.1.4.3 Frontales elementales de Administración del Sistema 1.2 Módulo de Administración del Sistema 1.2.1 Base de Datos 1.2.1.1 Creación de Tablas que almacenen los módulos de la aplicación 1.2.1.2 Creación de Tablas con los roles de la aplicación 1.2.1.3 Creación de tablas relacionales que integran módulos con roles 1.2.2 Capa de Negocio 1.2.2.1 Creación de clases que encapsulan funciones para administración

de módulos y roles 1.2.3 Capa de Presentación. Interfaz de usuario. 1.2.3.1 Generación de frontal para visualizar la configuración de

parámetros de la aplicación 1.2.3.2 Frontal para crear por interfaz un nuevo rol y asignar los módulos

que tendrá 1.2.4 Integración a Proyecto Base 1.2.4.1 Configuración en Aplicación para incluir modulo creado. 1.3 Módulo de Administración de Usuarios 1.3.1 Base de Datos 1.3.1.1 Creación de Tablas para almacenamiento de datos de usuarios 1.3.2 Capa de Negocio

82

1.3.2.1 Creación de clases que contiene operaciones CRUD para usuarios de la aplicación

1.3.2.2 Clases que contienen funcionalidad para autenticar usuarios del directorio activo

1.3.3 Capa de Presentación. Interfaz de usuario. 1.3.3.1 Construcción de módulos para gestionar creación de usuarios 1.3.3.2 Frontales para administrar la asignación de roles a cada usuario 1.3.4 Integración a Proyecto Base 1.3.4.1 Configuración en Aplicación para incluir modulo creado. 1.4 Módulo de Administración de Grupos 1.4.1 Base de Datos 1.4.1.1 Creación de Tablas para almacenamiento de Grupos 1.4.1.2 Creación de Tablas intermedias para relacionar Usuarios y

Grupos 1.4.2 Capa de Negocio 1.4.2.1 Creación de clases que contiene operaciones CRUD para grupos 1.4.3 Capa de Presentación. Interfaz de usuario. 1.4.3.1 Construcción de módulos para gestionar la creación de grupos 1.4.4 Integración a Proyecto Base 1.4.4.1 Configuración en la aplicación para incluir módulo creado 1.5 Módulo de Ingreso de Elementos 1.5.1 Base de Datos 1.5.1.1 Integración a Modelo en BD de tabla “Elementos” con campos

respectivos 1.5.1.2 Creación de Tablas complementarias como “Áreas”, “Sedes”,

“Estado” o “Categoría” 1.5.2 Capa de Negocio 1.5.2.1 Creación de Entidades de Negocio con las propiedades de cada

Elemento 1.5.2.2 Clases de operaciones CRUD sobre tabla Elementos para

Ingresar, Editar, Actualizar 1.5.3 Capa de Presentación. Interfaz de usuario. 1.5.3.1 Creación de frontal con formulario de ingreso de un Elemento y

sus propiedades 1.5.3.2 Diseño e inclusión de validadores por cada control del formulario. 1.5.4 Integración a Proyecto Base 1.5.4.1 Configuración en Aplicación para incluir modulo creado. 1.6 Módulo de Consultas 1.6.1 Capa de Negocio 1.6.1.1 Clases para operaciones CRUD sobre datos de consulta a BD 1.6.2 Capa de Presentación. Interfaz de usuario. 1.6.2.1 Creación de frontales para la visualización de las consultas

formuladas 1.6.3 Integración a Proyecto Base 1.6.3.1 Configuración en Aplicación para incluir modulo creado. 1.7 Módulo de Generación de Reportes 1.7.1 Capa de Negocio

83

1.7.1.1 Creación de clases que tienen la lógica de consulta y la construcción del reporte

1.7.2 Capa de Presentación. Interfaz de usuario. 1.7.2.1 Creación de Frontales para la visualización de los reportes

generados 1.7.3 Integración a Proyecto Base 1.7.3.1 Configuración en Aplicación para incluir modulo creado. 1.8 Módulo de Historial de Movimientos 1.8.1 Capa de Negocio 1.8.1.1 Clases con operaciones CRUD para consultas en bases de datos 1.8.2 Capa de Presentación. Interfaz de usuario. 1.8.2.1 Frontal para visualización de historial de movimientos 1.8.3 Integración a Proyecto Base 1.8.3.1 Configuración en la aplicación para incluir módulo creado 1.9 Construcción de Servicios Web 1.9.1 Generación de WebMethods 1.9.1.1 Construcción de los métodos del servicio web que serán visibles

desde instalador cliente 1.9.2 Fase de Exposición de Servicios 1.9.2.1 Publicación de Servicio Web para acceder a los WebMethods 1.10 Instalador Cliente de Servicio Windows 1.10.1 Base de Datos 1.10.1.1 Integración al modelo ER las tablas que tendrán información de

HW y SW enviados desde el Servicio de Windows instalado en cada computador que ingrese al inventario.

1.10.2 Componente Lógico 1.10.2.1 Conjunto de clases que guardan la lógica de integración con WMI

(Windows Management Instrumentation) para obtener información de hardware y software.

1.10.3 Instalador 1.10.3.1 Creación de un paquete de instalación (msi) para instalar en los

computadores nuevos que sean sometidos a inventario.

84

6.2.1.2 Proceso de Desarrollo Para el desarrollo se utiliza el método de programación extrema utilizando prototipo corregido sobre el proyecto base con inclusiones de módulos y tareas simplificadas organizadas en la EDT. La secuencia de desarrollo se presenta a continuación:

1. Desarrollo Proyecto Base Prototipo

2. Estructura base de datos Entidad Relación.

3. Estructura Multicapas, Capa de Datos, Negocio y Presentación.

4. Desarrollo de módulos Funcionales del Sistema: Modulo de Administración de Sistema, Modulo de Administración de Usuarios, Modulo de Ingreso de Elementos, Modulo de Consultas, Modulo de Generación de Reportes y Modulo de Movimientos Históricos.

5. Construcción de Servicios Web.

6. Generación de paquetes de instalación de Servicios Windows.

Cada proceso se realizara en ciclos de desarrollo, iteración de ciclos e integración en proyecto base.

85

6.2.1.3 Diagrama de Proceso de desarrollo de un Ciclo

Figura 40. Diagrama de proceso de un ciclo de desarrollo Sistema de Inventarios Cyza

Fuente: Diseño personal. Realizado con herramienta de diseño gráfico Paint.NET con licencia LGPL.

86

6.2.1.4 Diagrama de Proceso de desarrollo proyecto General

Figura 41. Diagrama de Representación del proceso de desarrollo General Sistema de Control de Inventarios Planteado

Fuente: Diseño personal. Realizado con herramienta de diseño gráfico Paint.NET con licencia LGPL.

87

6.2.2 Plan de Pruebas El proceso de pruebas se divide en pruebas unitarias, pruebas de integración y pruebas de aceptación todas realizadas mediante el método de caja negra.

6.2.2.1 Pruebas Unitarias Se realizan pruebas al código resultado de cada ciclo de desarrollo y definiendo la aceptación funcional y así proceder a indexar al prototipo base del proyecto. Estas pruebas no requieren registro y el técnico de desarrollo es el encargado de realizarlas.

6.2.2.2 Pruebas de Integración Se realizan pruebas de funcionalidad del prototipo base del proyecto cada vez que se integra una funcionalidad o módulo, definiéndola aceptación funcional integral en el prototipo base del proyecto. Se diligencia formato de “Formato de Pruebas de software” (Anexo DD-FPS).

6.2.2.2 Pruebas de Aceptación Se realizan pruebas del prototipo base de proyecto integrado en su totalidad para verificar la funcionalidad del programa en general y su aceptación y posterior implementación a productivo. El proyecto base deja de ser prototipo y pasa a ser el software como tal, Sistema de Gestión de Inventarios. Se diligencia formato de “Formato de Pruebas de Aceptación” (Anexo DD-FPA).

6.2.3 Plan de Control de Cambios Después de realizar las pruebas, los códigos que no cumplen con los objetivos funcionales, se procede a realizar los cambios requeridos.

Si la solicitud de cambio se origina de una prueba unitaria, se realiza recodificación inmediata y se vuelve hacer la prueba, se itera cuantas veces sea necesario hasta alcanzar los requerimientos funcionales requeridos.

En el caso de generar requerimiento de cambio a partir de una prueba integral o de aceptación, se debe verificar la documentación diligenciada en los formatos de pruebas de software y proceder a realizar re codificación y cambios en el prototipo. Estos cambios son documentados en el documento “Formato de control de cambios de software” (Anexo DD-FCC). Luego se vuelve a realizar pruebas.

6.2.4 Plan de Cierre de Proyecto Superada la fase de pruebas, se realiza la entrega del Sistema de Gestión de Inventarios a Cyza por medio magnético, con los respectivos manuales de administración y de usuario. Todo queda oficializado en documento debidamente firmado, formato “Acta de Entrega de Satisfacción” (DD-AES).

88

6.3 FASE DE DESARROLLO

Se sigue el proceso planteado en el plan de desarrollo, en secuencia y siguiendo la metodología de programación extrema. Cada módulo de programación es realizada en micro ciclos de desarrollo, verificación pruebas, cambios e integración al proyecto base prototipo. (Figura 40 página 81).

Siguiendo esta secuencia se indica a continuación el proceso general del desarrollo ingenieril del sistema de Inventarios Cyza.

6.3.1 Creación del proyecto Se crea el nuevo proyecto en Visual Studio con la distribución de las bibliotecas disponiendo la Solución en:

- Proyecto de Biblioteca de Clases (para capa de datos) - Proyecto de Biblioteca de Entidades (Entidades) - Proyecto de Biblioteca de Clases (para capa de negocio) - Proyecto de Aplicación Web (para capa de presentación)

6.3.2 Desarrollo de Proyecto Base El proyecto base es el desarrollo de todo lo básico para la funcionalidad de cualquier software en estructura multicapas con uso de las aplicaciones Web. El proyecto base es a su vez el modelo prototipo donde se ira anexando los módulos en cada fase y se verifica su funcionalidad a medida que se integra todas las unidades específicas del desarrollo.

6.3.2.1 Base de Datos Se construye la base de datos apoyado en el modelo de entidad relación base para implementar tablas requeridas en el desarrollo de cada uno de los módulos del Software.

6.3.2.1.1 Esquematización de la Base de Datos Se genera la base de datos estructurada así:

- Tabla usuarios que almacenará los usuarios del sistema - Tabla de Parámetros de Configuración que almacena los valores claves

que permiten que la aplicación funcione adecuadamente. - Tabla LogErrores que almacena los registros de errores generados por la

aplicación. - Tabla TipoEventoLog que permite clasificar los tipos de log que puede

generar la aplicación. - Tabla LogEventos que almacena los registros de eventos generados por

alguna acción que se realice dentro del sistema.

89

- Tabla TipoIdentificación que guarda los diferentes tipos de identificación que los usuarios establezcan.

6.3.2.1.2 Diagrama Entidad Relación Base

Figura 42. Diagrama de Entidad Relación Base de datos Proyecto Base

6.3.2.2 Capa de Datos Se Desarrolla la capa que encierra el manejo de toda la funcionalidad referente a la comunicación con un Motor de Base de Datos.

Se incluyen librerías de Enterprise Library que traen funcionalidades específicas para abrir, liberar y cerrar conexiones, así como gestores de consultas bajo procedimientos almacenados.

Se implementan las siguientes unidades específicas sobre el desarrollo:

- Implementación de librerías de Enterprise Library para hacer llamado del objeto “DataBase” que se encargará de la gestión de conexión a base de datos.

90

- Creación de la clase “GestorBD” que encapsula todas las posibles funciones para interactuar con objetos de tipo “procedimiento almacenado”

- Uso de componentes ADO (ActiveXDataObject) en la clase GestorBD para interactuar con objetos de bases de datos.

6.3.2.3 Capa de Negocios Se implementa la capa que encierra toda la lógica de negocio y validación de los datos que provienen de la capa de presentación y van a ser almacenados a base de datos. Se generan las siguientes clases:

- Agrupación Seguridad que tiene la clase de RegistroLogin. - Clase “NegocioBase” que encapsula funciones recurrentes como en

Registro de Excepciones. Todas las clases que se generen en ésta capa deberán heredar de ésta clase.

- Clase “Parametros” que guarda valores que hacen las veces de referencia dentro de una variable de sesión. Ejemplo: si se quiere obtener la dirección IP del servidor de dominio que se encuentra almacenado en una variable de sesión se debe acceder así Session[Parametros.SRV_AD].

- Clase “Constantes” que almancena valores constantes que serán usados dentro de la capa de negocio.

6.3.2.3.1 Entidades Se implementa la capa que contiene todas las clases que sirven como representaciones de Entidades de Negocio y objetos provenientes de base de datos. Son entidades fuertemente tipadas y encapsulan propiedades. Se implementan las siguiente Entidades:

- EstadoSesion.cs - Modulo.cs - Usuario.cs

6.3.2.5 Capa de Presentación Se implementa la capa de Aplicación Web que estructuralmente contiene carpetas que agrupan las vistas según los módulos creados. Los recursos implementados son:

- References: son las referencias a librerías complementarias de la aplicación - AppCode: folder que contiene las siguientes clases:

o CategoriaMenu.cs: guarda la lógica y jerarquía de los elementos del menú de navegación.

o DialogoBase.cs: Clase base de la que heredarán todas los frontales que se presenten en una ventana de dialogo.

91

o GestorObjetos.cs: Clase que guarda la lógica que permite gestionar la instanciación y creación de objetos fuertemente tipados. Todo llamado e instancia lo realizará ésta clase.

o PaginaBase.cs: en esta clase se encapsulan funciones generales y de uso común por todas las páginas de la aplicación. Por tal motivo cada página debe heredar de ésta clase.

o VariablesAplicacion.cs: guarda todas las constantes que permitirán el acceso a las variables de aplicación.

o VarialbesSesion.cs: guarda todas las constantes que permitirán el acceso a las variables de sesión.

- Dialogos: folder que contiene todas las paginas aspx que hacen la función de páginas en forma de dialogo (ventanas pequeñas)

o CambioClave.aspx - Usrs: folder que contiene el frontal básico de usuarios

o AdminUsuarios.aspx - Login.aspx: Frontal presente en la raíz que representa la vista de acceso a

la apliación. - Logout.aspx: frontal de salida de la aplicación. - Web.config: Archivo de configuración de la aplicación desde donde se

establece los parámetros de conexión a base de datos y otros parámetros importantes.

6.3.3 Desarrollo de Módulos

Los Módulos son las características y funcionalidades únicas del sistema exigidas para desarrollar el software con los objetivos planteados y los requerimientos exigidos por el cliente. De acuerdo al plan de ejecución, se realiza el procedimiento de desarrollo e integración.

6.3.3.1 Modulo de Administración del Sistema Este módulo es responsable de la administración de los procesos y funcionalidades propias del sistema en sus flujos internos, gestión de mensaje de bienvenida y parámetros de la aplicación.

6.3.3.1.1 Inclusiones Base de datos En base de datos se crean los procedimientos almacenados para la tabla de parámetros.

Se crean y agrega las siguientes tablas requeridas para el funcionamiento de este módulo:

92

- Tabla “ParametrosConfiguración” que almacena los valores reconocidos como parámetros y que hacen posible el funcionamiento de la aplicación.

- Tabla “LogEventos” que guarda todo evento que esté contemplado deba ser objeto de registro.

- Tablas “LogErrores” que guarda todo evento de error que se presente en la aplicación a nivel funcional.

6.3.3.1.2 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para administración de módulos y roles. Las Clases son:

- Clase “Parametros.cs” que guarda las funciones que permiten modificar los valores que hacen las veces de parámetros en la aplicación. Aquí mismo se efectúa la edición del texto presente en el mensaje de bienvenida.

6.3.3.1.3 Inclusiones Capa de Presentación Se implementa los frontales para visualizar la configuración de parámetros de la aplicación. Los frontales son:

- AdminConfig.aspx. Frontal que dispone de dos pestañas, una llamada “Pagina de bienvenida” que permite personalizar el tablero de noticias e información para todos los usuarios y “Configuraciones generales” donde se encuentran los parámetros del sistema.

6.3.3.1.4 Integración con Proyecto Base El desarrollo de este módulos es integrado con el proyecto base, actualizando el sistema en base de datos, capas de negocio y presentación. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.3.2 Modulo de Administración de Usuarios Este módulo es la parte del software que administra y gestiona la autenticación y permisos de los usuarios que acceden a la aplicación.

6.3.3.2.1 Inclusiones Base de datos En base de datos se crean los procedimientos almacenados para la tabla de parámetros, grupos y módulos.


- Tabla “Usuario”: es para almacenamiento de datos de usuarios - Tabla “TipoIdentificacion”: define los tipos de documento posibles. - Tabla “GruposUsuario que relaciona un Grupo con un Usuario.

93

6.3.3.2.2 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para administración de los usuarios:

- Agrupación ACL (Listas de Control de Acceso) que contiene las siguientes clases:

o TiposIdentificacion.cs: clase que gestiona la obtención de los tipos de identificación registrados en la base de datos.

o Usuarios.cs: clase que encierra toda funcionalidad que permite crear, editar, consultar o eliminar un usuario en la base de datos y administrar el procedimiento de autenticación por Active Directory.

- Agrupación de lógica de Directorio Activo compuesta por las siguientes clases:

o AdminAD.cs: clase que se encarga de la administración y gestión de objetos del directorio activo.

o ParametrosAD.cs: clase que almacena los nombres de los tipos de objetos que pueden existir dentro del protocolo LDAP. Deben tipificarse explícitamente porque su descripción es única y fundamental a la hora de obtener un recurso de directorio activo.

o UsuariosAD.cs: representa un objeto Usuario propio del directorio activo con las propiedades que maneja el protocolo LDAP para éste tipo específico de objeto.

6.3.3.2.3 Inclusiones Capa de Presentación Se implementa los frontales de visualización para usuarios del sistema. Los frontales son:

- Frontal “AdminUsuarios.aspx es la vista para la administración de usuarios

6.3.3.2.4 Integración con Proyecto Base El desarrollo de este módulos es integrado con el proyecto base, actualizando el sistema en base de datos, capa de negocio y presentación. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.3.3 Módulo de Administración de Grupos Este módulo es la parte del software que administra y gestiona la creación y configuración de los grupos de la aplicación.

6.3.3.3.1 Inclusiones Base de datos En base de datos se crean los objetos Tabla para almacenar los grupos de la aplicación, así como la generación de los

94

procedimientos almacenados que tendrán interacción con dicha tabla. Los objetos creados son los siguientes:

- Tabla “Grupos”: almancena los grupos propietaris que se creen en la aplicación.

- Tabla “GruposMapeoLDAP”: registra allí los grupos que se identifiquen que fueron creados en el DirectorioActivo y que serán usados en la aplicación.

- Tabla “Modulos”: se usa para consignar la lista de módulos presentes en la aplicación.

- Tabla “ModulosGrupo”: representa la relación de pertenencia y asociación entre módulos y grupos.

6.3.3.3.2 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para administración de los grupos:

- Agrupación ACL (Lista de Control de Acceso). Contiene a la clase Grupos.cs que se encarga de gestionar los grupos de tipo propietario en su creación, modificación, consulta o eliminación.

- Agrupación de lógica de Directorio Activo compuesta por las siguiente clase:

o GruposAD.cs: clase que gestiona la creación, consulta, renombramiento y eliminación de un grupo a nivel de Directorio Activo.

6.3.3.3.3 Inclusiones Capa de Presentación Se implementa los frontales de visualización para usuarios del sistema. Los frontales son:

- Frontal AdminGrupos.aspx: Rejilla que contiene el listado de grupos creados en la aplicación. Allí se dispone la gestión de los módulos pertenecientes a cada grupo.

6.3.3.3.4 Integración con Proyecto Base El desarrollo de este módulos es integrado con el proyecto base, actualizando el sistema en base de datos, capas de negocio y presentación. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.3.4 Modulo de Ingreso de Elementos Este módulo es la parte del software que administra los procesos de registros de datos de los elementos que van a ser inventariados en el sistema.

6.3.3.4.1 Inclusiones Base de datos En base de datos se crean objetos tipo tabla y los procedimientos almacenados para las tablas indicadas.

95


- Tabla Elemento: almacena los registros de los elementos que se ingresan a la aplicación.

- Tabla complementaria Áreas: consigna las áreas a las que puede pertenecer un elemento.

- Tabla complementaria Sedes: almacena el listado de sedes donde un elemento puede encontrarse.

- Tabla complementaria Estado: representa los múltiples estados que puede tener un elemento del inventario.

- Tabla complementaria Categoría: almacena el listado de categorías a las que puede pertenecer un elemento.

- Tabla complementaria InformaciónExtendida: registra atributos adicionales para un elemento según su categoría.

- Tabla complementaria AtributoElemento: guarda los diferentes atributos que puede tener un elemento.

- Tabla complementaria InformacionPC: Permite almacenar los atributos referentes únicamente a un equipo de cómputo como lo son el software y el hardware.

6.3.3.4.2 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para el ingreso de nuevos elementos a la base de datos.

Se adicionan nuevas Entidades en la capa de negocios que son representaciones fuertemente tipadas en la tabla de base de datos. Las entidades son:

- Area.cs - AtributoElemento.cs - Categoría.cs - Elemento.cs - Estado.cs - Sede.cs

Las Entidades son agrupadas en la función “DescripcionFisica” que almacena clases que se encargan de gestionar toda operación de inserción sobre las entidades de negocio. Las clases son:

o Areas.cs o AtributoElemento.cs o Categorias.cs

96

o Elementos.cs o Estados.cs o InformacionesExtendidas.cs o Sedes.cs

6.3.3.4.3 Inclusiones Capa de Presentación Se implementa los frontales para visualizar, ingresar, editar y actualizar los elementos y datos al inventario. El frontal es:

- IngresoElementos.aspx: Frontal con un formulario para el ingreso de elementos.


6.3.3.5 Modulo de Consultas Este módulo permite realizar consulta de elementos ya registrados.

6.3.3.5.1 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para administración de módulos. Las Clases son:

- Agrupación “Descripcion Fisica” que almacena clases que se encargan de gestionar toda operación de consulta sobre las entidades de negocio. Las clases son las siguientes:

o Areas.cs o AtributoElemento.cs o Categorias.cs o Elementos.cs o Estados.cs o InformacionesExtendidas.cs o Sedes.cs

6.3.3.5.2 Inclusiones Capa de Presentación Se implementa los frontales para ingresar parámetros y visualizar las consultas realizadas al sistema. El frontal es:

97

- Consultas.aspx: Frontal que hace posible la consulta de los elementos registrados en el inventario.

6.3.3.5.3 Integración con Proyecto Base El desarrollo de este módulos es integrado con el proyecto base, actualizando el sistema en capas de negocio y presentación. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.3.6 Modulo de Generación de Reportes Este módulo genera Reportes y permite su exportación en archivos .xls.

6.3.3.5.1 Inclusiones Capa de Presentación Se implementa el frontal que realizará una consulta específica y adicionalmente presentará una opción para exportar los datos recientemente consultados. El frontal responsable es:

- Reportes.aspx

6.3.3.6.3 Integración con Proyecto Base El desarrollo de este módulos es integrado con el proyecto base, actualizando el sistema en capas de negocio y presentación. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.3.7 Modulo Historial de Movimientos Este módulo es la parte del software que realiza el registro de todos los movimientos realizados a los elementos inventariados.

6.3.3.7.1 Inclusiones Base de datos En base de datos se crea y agrega la tabla requeridas para el funcionamiento de este módulo:

- Tabla Historial: Consigna allí la acción de modificación que realice un usuario sobre un elemento específico.

6.3.3.7.2 Inclusiones Capa de Negocio Se crean las clases que encapsulan funciones para la inserción y consulta de un registro histórico. Las Clases son:

- Agrupación “Historial” que contiene la siguiente clase: o Historicos.cs: Clase que contiene las funciones necesarias para

registrar un evento de modificación de atributos de una clase. También se encontraran allí las funciones para traer de base de datos el listado histórico de movimientos en la aplicación.

98

6.3.3.7.3 Inclusiones Capa de Presentación Se implementa los frontales para consulta el histórico de movimiento de elementos en inventarios. El frontal es:

- Historicos.aspx: Frontal que mostrará el listado de movimientos realizados por los usuarios de la aplicación. Mostrando el estado anterior y actual del movimiento por cada acción.


6.3.4 Construcción de Servicios Web Representa la exposición de las funciones principales que permitirán la interacción entre el Sistema de Inventarios con cualquier sistema cliente que requiera comunicarse con él.

Se implementa:

- WCFInventario.svc: Nombre del servicio web que contiene los “web methods” expuestos y listos para ser consumidos por sistemas externos.

- Construcción de los métodos del servicio web que serán visibles desde instalador cliente.

- Publicación de Servicio Web para acceder a los WebMethods

Luego se realiza proceso de integración con el proyecto base. Se realiza proceso de pruebas y control de cambio. (Sección 6.1)

6.3.5 Instalador Cliente de Servicios Windows Se genera paquete de instalación que se ejecuta como un servicio de Windows que enviará datos de hardware y software del computador inventariado hacia el Sistema de Inventarios.

6.3.5.1 Inclusiones Base de datos Integración al modelo Entidad Relación de las tablas que tendrán información de Hardware y Software enviados desde el Servicio de Windows instalado en cada computador que ingrese al inventario.

6.3.5.2 Instalador

99

Se genera una nueva solución en Visual Studio como “aplicación de Windows” y se implementa siguiendo los siguientes pasos:

- Se configura el paquete para que sea un Servicio Windows. - Se genera una capa de negocio internamente que contiene la interacción

con componentes WMI (Windows Management Instrumentation) para captura de los datos de Hardware y Software.

- Se agrega una clase especial que se denomina como un proxy del Servicio Web que está a la escucha de peticiones en la aplicación Web de Inventarios. Éste proxy contiene la información de los métodos que se requieren consumir para enviar los datos de hardware y software del computador donde ha sido instalado.

- Se agrega un nuevo proyecto a la Solución de Visual Studio para generar un paquete de instalación .msi (Microsoft Installer) y poder distribuir el Servicio de Windows como un instalador.

6.4 FASE DE PRUEBAS Y CONTROL DE CAMBIOS

6.4.1 Pruebas de Integración En programación extrema se realizan pruebas sobre el proceso de desarrollo y se realizan cuando se incluye un cambio sobre el proyecto base prototipo, para este caso se realizan pruebas de integración sobre módulo terminado e incluido en el proyecto base. Se realiza proceso y se diligencia formato de pruebas “DD-FPS” generados en el proceso de desarrollo del software. A continuación se indica las pruebas realizadas.

6.4.1.1 Pruebas de Integración Proyecto base Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 35. Formato de Pruebas 1. Proyecto Base

Prueba No. 1 Funcionalidad/Método Proyecto Base Fecha DD/MM/AA Detalle Para iniciar la aplicación debe existir por lo menos un usuario

Administrador que es el único usuario con la condición de “Reservado” y no podrá ser removido de la aplicación. El proceso será el siguiente:

100

• Acceder a la URLhttp://localhost/Inventarios • Iniciar sesión con el usuario Administrador “Admin” • Visualizar la página de Inicio de la aplicación. • Visitar el frontal de administración (único frontal activo) • Salir de la aplicación mediante el control de logout.

Comentarios Con éste ejercicio se comprueba el funcionamiento de la validación de usuarios propietarios y específicamente el usuario reservado de la aplicación.

Entradas Un Usuario Reservado (Administrador) Salidas Acceso a la aplicación y posterior cierre.

Resultado Satisfactorio Si X No


Prueba No. 2 Funcionalidad/Método Proyecto Base Fecha DD/MM/AA Detalle El objetivo es probar la funcionalidad de Gestión de

Usuarios y Gestión de Grupos. El procedimiento completo es el siguiente:

• Acceder como usuario administrador • Ingresar al módulo de “Parametrización” • Seleccionar la opción de “Administración de Grupos” • Crear un nuevo grupo y darle un nombre • Asignarle al grupo nuevo módulos existentes • Volver a módulo de “parametrización” • Seleccionar la opción de “Administración de

Usuarios” • Crear un usuario nuevo • Asignarle al usuario nuevo el grupo recientemente

creado • Cerrar la sesión con el administrador e iniciar sesión

con nuevo usuario • Comprobar que el usuario nuevo puede acceder a

los módulos del grupo que se le fue asignado. Comentarios Es necesario realizar toda la operación anteriormente

descrita para poder comprobar la funcionalidad descrita en el REQ-FNC-5 que habla de la gestión de grupos, módulos y usuarios.

Entradas Nuevo grupo, Nuevo usuario Salidas Grupo con módulos asociados y dicho grupo asignado a un

usuario Resultado Satisfactorio

Si X No

101


Prueba No. 3 Funcionalidad/Método Proyecto Base Fecha DD/MM/AA Detalle Prueba de componentes de Access Data Object para

comunicación con bases de datos. Procedimiento: • Ingresar a la aplicación como usuario Administrador • Ir al frontal de Configuración de la Aplicación • Ir a la pestaña de Configuraciones Generales • Modificar el parámetro de “Umbral de minutos para el

timeOut” • Consultar en la base de datos la tabla

“ParametrosConfiguracion” • Comprobar que el campo correspondiente haya sido

modificado Comentarios Con la operación anterior se garantiza que el componente de

gestión de acceso a la base de datos está operando. Inclusive desde el mismo momento en que se accede a la aplicación se está poniendo a prueba las funciones de Lectura o escritura en base de datos.

Entradas Un parámetro por modificar Salidas La actualización en base de datos del parámetro modificado


Prueba No. 4 Funcionalidad/Método Proyecto Base Fecha DD/MM/AA Detalle El motivo de la prueba es acceder a la aplicación y en compañía

del solicitante validar el cumplimiento del REQ-NFN-03 sobre la condición de los textos usados en el aplicativo, para determinar aprobación sobre el tipo de fuentes que se usaron

Comentarios Entradas Acceso a la aplicación Salidas Visualización de las fuentes usadas, tamaños y distribución.


102


Prueba No. 5 Funcionalidad/Método Proyecto Base Fecha DD/MM/AA Detalle Para visualizar el panel de bienvenida se debe realizar el

siguiente proceso: • Acceder a la aplicación con usuario Administrador • Ir a la opción de Configuración • Seleccionar la pestaña de “Pagina de Bienvenida” • Utilizar el editor de texto agregando la información

que el usuario desee. Seleccionando diferentes tipos de tamaño, fuente o color de texto dentro del área de edición.

• Dar clic en el botón de “Guardar” • Ir a la vista de “Página Principal” • Comprobar que los cambios realizados se vean

reflejados en el cuadro de mensaje de bienvenida de la página principal.

Comentarios Entradas Un mensaje nuevo en el apartado de configuración de

mensaje de bienvenida Salidas La visualización de modificación en la página principal.


6.4.1.2 Pruebas de Integración Modulo Administración del Sistema Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 40. Formato de Pruebas 1. Modulo Administración del Sistema

Prueba No. 1 Funcionalidad/Método Funcionalidad de modificación de mensaje de bienvenida Fecha DD/MM/AA Detalle Desde el módulo de administración del sistema es posible

realizar modificación al mensaje de bienvenida. Para ellos se realiza el siguiente procedimiento:

• Ingresar al sistema utilizando un usuario con credenciales de administrador

• Desde el menú de navegación dirigirse a “configuración del sistema”

• Ubicarse en la pestaña con el texto “Página de bienvenida”.

• Utilizar el control con la barra de controles de texto y la pizarra para escritura de texto. Escribir un mensaje personalizado.

103

• Usar el botón “preview” para tener la vista preliminar del texto.

• Una vez terminada la edición se guardará el mensaje oprimiendo el botón “Guardar Cambios”.

• Para comprobar los nuevos cambios basta con ir a la página de inicio de la aplicación y ver el mensaje presente en la página inicial.

Comentarios Entradas Acceso a la configuración de “Pagina de bienvenida” Salidas La modificación del mensaje de bienvenida desde el control

de edición de texto. Resultado Satisfactorio

Si X No

Tabla 41. Formato de Pruebas 2. Modulo Administración del Sistema

Prueba No. 2 Funcionalidad/Método Modificación de Configuraciones Generales Fecha DD/MM/AA Detalle El Sistema de Inventarios cuenta con un módulo con acceso

a los parámetros de configuración que influyen en el comportamiento de la aplicación o intervienen en el acceso de otros recursos como comunicación hacia otros servidores. La prueba se realiza de la siguiente manera:

• Ingresar a la aplicación con un Administrador. • Desde el menú de navegación dirigirse a

“Configuración de la aplicación”. • Seleccionar la pestaña “Configuraciones Generales”. • Modificar los diferentes parámetros (ver deck de

pruebas para mas detalles) • Cada vez que se modifique un valor hay que usar el

botón “Guardar” para que los cambios tengan efecto. Comentarios Entradas Acceso con usuario administrador. Salidas Parámetros generales modificados


104

6.4.1.3 Pruebas de Integración Modulo de Administración de Usuarios Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 42. Formato de Pruebas 1. Modulo Administración de Usuarios

Prueba No. 1 Funcionalidad/Método Funcionalidad de autenticación por Directorio Activo Fecha DD/MM/AA Detalle El sistema cuenta con un sistema de autenticación

propietaria pero se requiere integrar un sistema adicional de Autenticación por Directorio Activo. Para comprobar su funcionamiento se realiza el siguiente proceso:

• Tener disponible un Servidor de Directorio Activo • Crear un usuario en el Active Directory • Ingresar a la aplicación como usuario Administrador • Ir a la Configuración de la aplicación • En el campo de Dirección de Controlador de

Dominio ingresar la IP del Servidor de Directorio Activo disponible.

• En los campos de “Usuario de dominio” y “Clave Usuario de Dominio” debe ingresar las credenciales de un usuario validado en el Directorio Activo

• Ingresar a Parametrización/Configuración de Usuarios

• Crear un nuevo usuario y en “otros datos” seleccionar Tipo de Autenticación como “Directorio Activo”

• En Datos Personales para el campo Inicio de Sesión ingresar el mismo nombre de usuario que registra en el Directorio Activo

• Finalmente ingresar a la aplicación con el nuevo usuario usando las credenciales de nombre y contraseña del Directorio Activo

Comentarios Cuando se crea un usuario con autenticación por Directorio Activo la gestión de grupos queda deshabilitada debido a que sus grupos asignados serán determinados por los grupos existentes en el Directorio Activo

Entradas Un usuario creado con autenticación por Directorio Activo

Salidas Acceso a la aplicación con credenciales de Directorio Activo.


105

Tabla 43. Formato de Pruebas 2. Modulo Administración de Usuarios

Prueba No. 2 Funcionalidad/Método Funcionalidad de Autenticación Propietaria Fecha DD/MM/AA Detalle La aplicación también debe tener un segundo sistema de

autenticación que será Propietaria lo que implica que es la misma aplicación la que se encarga de autenticar un usuario. Esta función es excluyente a la autenticación por Directorio Activo. Para probar su funcionamiento se realiza lo siguiente:

• Acceder con un usuario administrador • Ingresar a Parametrización/Configuración de

usuarios • Dar clic en “Nuevo Usuario” • Ingresar la información de usuario incluyendo el

nombre de Inicio de sesión y en “otros datos” en la opción de “Tipo de Autenticación” seleccionar “Propietaria”.

• Finalizar la creación con el botón de “Crear Nuevo”. • En la rejilla de usuarios ubicar el seleccionado y

seleccionar “clave” para establecer una nueva clave”. • Salir e ingresar de nuevo con el usuario recién

creado. • Digitar el nombre de usuario con el Nombre de

Usuario con que se creó y la contraseña que se le asignó.

Comentarios Entradas Nuevo grupo, Nuevo usuario Salidas Grupo con módulos asociados y dicho grupo asignado a un

usuario Resultado Satisfactorio

Si X No

106

6.4.1.4 Pruebas de Integración Modulo de Ingreso de Elementos Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 44. Formato de Pruebas 1. Módulo de Ingreso de Elementos

Prueba No. 1 Funcionalidad/Método Ingreso de Elementos Fecha DD/MM/AA Detalle Esta función permitirá ingresar los elementos que serán

incluidos en el inventario. Para ello se debe realizar el siguiente proceso:

• Acceder a la aplicación con un usuario que tenga acceso al módulo de ingreso de elementos.

• Dirigirse al menú Inventarios/Ingreso de Elementos.

• Diligenciar el formulario que se abre a continuación donde se incluyen los siguientes datos: número placa, estado, sede, área, responsable, observaciones, fecha de ingreso y categoría.

Comentarios En las precondiciones del formato de requerimiento asociado a ésta funcionalidad se mencionaba la propiedad “Id Elemento” pero éste valor único será asignado internamente en la base de datos. Para identificar un objeto se tendrá como referencia “Número de Placa”

Entradas Un Usuario Reservado (Administrador) Salidas Acceso a la aplicación y posterior cierre.

Resultado Satisfactorio Si No X

Detalles a Modificar • Entre las propiedades del elemento a ingresar se incluye la “fecha de ingreso”

que debiera ser la fecha en que el elemento ha sido adquirido por la empresa. Pero no siempre se da que el elemento se ingrese el mismo día en que fue adquirido y éste campo tomaba la fecha actual del sistema. Se requiere que exista otro campo adicional que permita registra la fecha en que el elemento ha sido enrolado en la aplicación (fecha del sistema) y el campo que actualmente se llama “fecha de ingreso” pueda ser editable por el usuario permitiendo ingresar la fecha en que fuera adquirido inclusive si esta fecha es antecesora del momento en que el sistema de inventarios haya estado en funcionamiento.

• En las pruebas se detecta otra situación que se considera mejorable y corresponde a la inclusión de un aspecto de estimación económica. Por petición del área de contabilidad se espera tener dos campos adicionales, uno que haga referencia al costo del elemento y otro que indique el costo asegurado.

107

6.4.1.5 Pruebas de Integración Modulo de Consultas Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 45.Formato de Pruebas 1. Módulo de Consultas

Prueba No. 1 Funcionalidad/Método Búsqueda de elementos en Inventarios Fecha DD/MM/AA Detalle Existe un módulo para que un usuario consultor pueda

realizar una búsqueda personalizada sobre el inventario. El procedimiento es el siguiente:

• Acceder con un usuario que tenga acceso al módulo de Consulta de Elementos

• Navegar al menú Inventarios/Consultas y seleccionar la opción “Consulta Inventarios”.

• Allí verá un control web que permitirá construir la consulta requerida. El aspecto del control es el siguiente:

• La barra se compone de 4 elementos

o AND: corresponde al tipo de operador lógico que se utilizará. Puedeser AND, OR Not And y Not Or

o +: el símbolo más permite agregar una nueva barra con una propiedad del elemento que servirá como criterio de búsqueda.

o +[=]: este símbolo permite agregar un bloque

de propiedades para agrupar más de un sub criterio de búsqueda

o X: elimina la barra o sub barra creada.

• Usar el control para establecer un criterio específico. Ejemplo: Quiero buscar los elementos cuyo número de placa sean mayores a 200 y el estado sea Disponible.

108

• Dar clic en Aplicar filtro para que aparezca el

resultado

Comentarios Este control puede ser complejo de utilizar y requiere

obligatoriamente una capacitación para garantizar éxito en las consultas

Entradas Parámetros de búsqueda que son las propiedades de los elementos existentes en el sistema de inventarios.

Salidas Rejilla con los resultados de la búsqueda. Resultado Satisfactorio

Si X No

6.4.1.6 Pruebas de Integración Modulo de Generación de reportes Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 46. Formato de Pruebas 1. Módulo de Reportes

Prueba No. 1 Funcionalidad/Método Generación de Reportes Fecha DD/MM/AA Detalle Este modulo debe permitir exportar a un archivo en disco el

resultado de una consulta a modo de reporte con el fin de poder transportar ésta información. El procedimiento de prueba es el siguiente:

• Utilizar un usuario con acceso al módulo de generación de reportes

• Realizar una consulta a la base de Inventarios con ayuda del control de consultas personalizadas

• De generar un resultado posteriormente usar la opción de “Generar Reporte”

Comentarios Entradas Un criterio de búsqueda específico Salidas Un archivo en Excel que contiene el resultado de dicha

búsqueda. Resultado Satisfactorio

Si X No

109

6.4.1.7 Pruebas de Integración Modulo Históricos Movimientos Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 47. Formato de Pruebas 1. Módulo de Histórico

Prueba No. 1 Funcionalidad/Método Consulta de Históricos Fecha DD/MM/AA Detalle Se pretende consultar el historial de movimientos realizados a los

elementos registrados en el sistema de inventarios. El procedimiento es el siguiente:

• Utilizar un usuario con acceso al módulo de Consulta de Históricos

• Ir al menú de navegación y hallar la ubicación Inventarios/Históricos

• Acceder y revisar la tabla de históricos presentada.

Comentarios Entradas Acceso al frontal de históricos Salidas Todos los registros de históricos de movimientos realizados en la

aplicación. Resultado Satisfactorio

Si X No

6.4.1.8 Pruebas de Integración Instalador Cliente Windows Se procede a establecer las pruebas, se realizan y verifican resultados funcionales.

Tabla 48. Formato de Pruebas 1. Instalador Cliente

Prueba No. 1 Funcionalidad/Método Búsqueda de elementos en Inventarios Fecha DD/MM/AA Detalle Probar la instalación y el comportamiento del Cliente para

Windows llamado InfoHardware. El procedimiento es el siguiente:

• Descargar el paquete InforHardware.msi • Iniciar el asistente de instalación en el computador

que será registrado en la base de inventarios • Ir al destino donde se instalaron los archivos

resultantes posiblemente en Archivos de Programa. • Identificar el archivo InfoHardwareCyza.exe.config y

abrirlo con un editor de texto • Identificar la etiqueta dentro del XML siguiente

<appSettings> <add key="NumeroPlaca" value="XXXXX"/> </appSettings>

• En value colocar el número de placa que tendrá

110

asignado físicamente el computador • Guardar y cerrar. • Reiniciar el computador • El programa que se instala es realmente un Servicio

de Windows que se ejecutará cada vez que se reinicie el computador y hará envío de la información de software y hardware de la maquina host.

• Comprobar en base de datos la existencia de nueva información procedente del cliente de Servicio Windows instalado

Comentarios Entradas Un número de placa en el archivo de configuración de

InfoHardware Salidas La generación de registros que contienen información de

hardware y software de la máquina a la que se le fue instalado el Servicio de Windows.


6.4.2 Control de Cambios Las pruebas que tuvieron resultado no satisfactorio, se realiza registro en formato “DD-FCC” y se realiza el proceso de recodificación para hacer los cambios requeridos para el funcionamiento del sistema. Después de hacer los cambios se vuelve a realizar la prueba y se vuelve a generar documentación hasta que la prueba satisfaga la funcionalidad buscada.

6.4.2.1 Historial de Cambios Las A continuación se relacionan los cambios realizados y las pruebas generadas.

Tabla 49. Historial de Cambios

Historial de Cambios

Modulo Descripción Responsable

Administración de grupos

• Se corrige la carga de los Grupos Creados para ser visualizados en el panel de usuarios a la hora de intentar asignar un grupo a un usuario.

Jorge Araque

Administración de grupos

• Puede suceder que existan dos grupos diferentes pero que incluyan a un mismo módulo. Se modifica la aplicación para que un usuario que tenga dos grupos que compartan un módulo no visualice en su perfil dos veces el mismo módulo en el menú de la aplicación.

Jorge Araque

111

Ingreso de Elementos

• En el formulario de Ingreso de Elementos se incluye un campo nuevo llamado “Fecha de Registro” que obtiene la fecha del sistema y se edita el existente campo “Fecha de Ingreso” para que sea editable.

Jorge Araque

Ingresos de elementos

• Por petición de Contabilidad se debe incluir en el formulario de Ingreso de Elementos los campos “Costo” y “Costo Asegurado”

Jorge Araque


• Aunque el módulo de consultas cuenta con un control que permite personalizar las búsquedas de forma acertada se requiere un control adicional que haga búsquedas elementales por Número de Placa o por Serial (con pistola lectora)

Jorge Araque


• Se requiere que se pueda alternar entre el control elemental de búsqueda y el control personalizado de búsqueda

Jorge Araque

6.4.2.2 Prueba Después de Cambios Se procede a establecer las pruebas después de los cambios realizados, se ejecutan y verifican resultados funcionales.

Tabla 50. Prueba 1 para REQ-FNC-5

Prueba No. 1 Req. Asociado REQ-FNC-5 Funcionalidad/Método Sobre Proyecto Base – Panel de administración de usuarios

y asignación de grupos Fecha DD/MM/AA Detalle Aunque se estaban creando los grupos en su respectivo panel de

Administración de usuarios, no era posible asignar un grupo a determinado usuario por lo que se incluye en el panel de usuarios un link para visualizar y seleccionar los grupos que serán asignados a ese usuario. Procedimiento:

• Acceder como Administrador • Ingresar al módulo de “parametrización” • Seleccionar la opción de “Administración de Usuarios” • Crear un usuario nuevo • Marcar el link de “Grupos” que abrirá una ventana

emergente • Seleccionar uno o varios grupos (previa configuración de

módulos dentro de cada grupo) Comentarios Entradas Nuevo usuario y selección de uno o varios grupos para

dicho usuario Salidas Usuario con grupos asociados y acceso de ese usuario a los

módulos enlazados a los grupos a los que pertenece Resultado Satisfactorio

Si X No

112


Prueba No. 2 Req. Asociado REQ-FNC-5 Funcionalidad/Método Sobre Proyecto Base – Panel de administración de usuarios y

asignación de grupos Fecha DD/MM/AA Detalle Un usuario puede tener asignado más de un grupo y cada

grupo puede contener más de un módulo en común. El menú de navegación de cada usuario se construye dependiendo de la cantidad de módulos que ese usuario tenga asignados por intermedio de los grupos. Anteriormente sucedía que si dos grupos tenían un mismo módulo enlazado entonces el menú de navegación del usuario construía dos veces el mismo Menú Ítem. Esto se arregla para que el sistema detecte un solo módulo. Prueba:

• Acceder como Administrador • Ingresar al módulo de “parametrización” • Seleccionar la opción de “Administración de Grupos” • Editar un primer grupo en el link “modulos” y enlazar el

módulo de Configuración de la Aplicación. • Editar un segundo grupo con el mismo módulo del

punto anterior • Seleccionar la opción de “Administración de Usuarios” • Seleccionar un usuario creado • Marcar el link de “Grupos” que abrirá una ventana

emergente • Seleccionar los dos grupos que tienen el módulo de

Administración de usuario. • Guardar cambios y salir del perfil de Administrador • Ingresar con el usuario al que fue enlazado los dos

grupos previos • Comprobar el menú de navegación y detectar si se ve

una sola vez la opción de Configuración de la Aplicación.

Comentarios Entradas Usuario con grupos enlazados (previamente editados con el

mismo módulo) Salidas Menú de Navegación sin opciones duplicadas.


113


Prueba No. 3 Req. Asociado REQ-FNC-03 Funcionalidad/Método Sobre Módulo de Ingreso de Elementos, Registro de nuevo

Elemento, modificación de campos en el formulario Fecha DD/MM/AA Detalle Originalmente existía un campo de Fecha de Ingreso pero no

era editable y tomaba la fecha del sistema. Se modifica el campo para que sea editable. Procedimiento de prueba:

• Acceder a la aplicación con ayuda de un usuario con acceso al módulo de ingreso de elementos.

• Navegar hasta Inventarios/ Ingreso de Elementos. • Comprobar que el formulario contenga el campo de

“Fecha de Ingreso” con opción de ser editado manualmente.

• Diligenciar los datos completos del formulario. • Finalizar con el botón “Ingresar Elemento”

Comentarios Internamente al momento de Ingresar el elemento ya se encuentra incluido el campo de Fecha de Registro pero éste no requiere ser visualizado en el frontal y tomará la fecha del sistema.

Entradas Número de Placa, Marca, Modelo, Serial, Sede, Área, Responsable, Observaciones, Fecha de Registro, Fecha Ingreso, Categoría

Salidas Un nuevo elemento ingresado al Inventario. Resultado Satisfactorio

Si X No


Prueba No. 4 Req. Asociado REQ-FNC-03 Funcionalidad/Método Sobre Módulo de Ingreso de Elementos, Registro de nuevo

Elemento, modificación de campos en el formulario Fecha DD/MM/AA Detalle Debido a una petición hecha por el Departamento de

Contabilidad se agregan dos nuevos campos. El procedimiento de pruebas es el siguiente:

• Acceder a la aplicación con ayuda de un usuario con acceso al módulo de ingreso de elementos.

• Navegar hasta Inventarios/ Ingreso de Elementos. • Comprobar que el formulario contenga los campos de

“Costo” y “Costo Asegurado” • Intentar campos alfabéticos para comprobar que se

valida el ingreso únicamente de datos numéricos • Intentar guardar.

114

• De no ser posible ingresar datos alfabéticos en los nuevos campos, corregir y finalmente guardar con “Ingresar Elemento”.

Comentarios Entradas Número de Placa, Marca, Modelo, Serial, Sede, Área,

Responsable, Observaciones, Fecha de Registro, Fecha Ingreso, Categoría, Costo, Costo Asegurado

Salidas Un nuevo elemento ingresado al Inventario. Resultado Satisfactorio

Si X No


Prueba No. 5 Req. Asociado REQ-FNC-07 Funcionalidad/Método Sobre Módulo de Consulta de Elementos Fecha DD/MM/AA Detalle Utilizar los controles de búsqueda presentes en el frontal de

Consultas. El procedimiento es el siguiente: • Acceder con un usuario que tenga acceso al módulo de

Consulta de Elementos • Navegar al menú Inventarios/Consultas y seleccionar la

opción “Consulta Inventarios”. • Comprobar que ahora existen dos tipos de controles:

o Búsqueda de elemento por Placa o Serial o Búsqueda Personalizada

• En el primer control marcar el botón de Placa e ingresar un valor. Comprobar el resultado con el botón “buscar”.

• Luego seleccionar “Serial” y realizar el mismo ejercicio del punto anterior.

• Luego alternar con el control de filtro personalizado poniendo la opción “Si”. Allí aparecerá el control de búsqueda. Generar algunos criterios y comprobarlos con el botón de “Aplicar Filtro”

Comentarios Entradas Uso de algunos criterios de búsqueda de elementos Salidas Rejilla con los registros que cumplen con los criterios

descritos. Resultado Satisfactorio

Si X No

111

6.4.3 Pruebas de Aceptación Se realizan pruebas del prototipo base de proyecto integrado en su totalidad para verificar la funcionalidad del programa en general y su aceptación y posterior implementación a productivo. El proyecto base deja de ser prototipo y pasa a ser el software como tal, Sistema de Gestión de Inventarios. Se diligencia formato de “Formato de Pruebas de software”.

Tabla 55. Formulario de Pruebas de Aceptación

PROCESO SUBPROCESO DESCRIPCION USUARIO ACCION DE ENTRADA

RESULTADO DE SALIDA

¿SATISFACTORIO?

Frontal de Login Ingreso de Usuario y Contraseña

Frontal principal de acceso a la aplicación

Administradores, consultores

Ingreso de credenciales de usuario existente

Accede a la página principal

Si

Ingreso de credenciales de usuario inexistente

Texto “Verifique nombre de usuario y/o clave asignada”

SI

Parametrización Administración de usuarios

Frontal para gestionar la creación, modificación y eliminación de usuarios

Administradores Creación de nuevo usuario

Usuario Creado SI

Asignación de grupos a usuario creado

Usuario Modificado SI

Inactivación de usuario creado

No se puede acceder a la aplicación

SI

Cambio de clave de usuario creado

Clave modificada SI

Borrar primer usuario administrador

No es posible eliminar el administrador primario

SI

Borrar usuario creado posteriormente

Usuario eliminado SI

Administración de Grupos

Frontal para gestionar la creación, modificación y eliminación de grupos

Administradores Creación de un grupo nuevo de tipo “Propietario”

Grupo creado SI

Asignación de varios módulos del sistema al grupo creado

Módulos asignados correctamente a grupo

SI

Eliminación del grupo recientemente creado

Luego de mensaje de confirmación se elimina el grupo

SI

Creación de grupo como tipo “Directorio Activo”

Se crea el grupo y se habilita el mapeo LDAP

SI

Eliminación de grupo Se elimina el grupo SI

112

de tipo “Directorio Activo”

Administración de Configuración

Pagina de Bienvenida Vista que permite modificar el mensaje de bienvenida con ayuda del control de editor de texto

Administradores Ingresar un mensaje personalizado de bienvenida.

Se modifica el mensaje. SI

Editar el mensaje existente y cambiar el texto

Se modifica el mensaje SI

Cambiar el color del texto existente

Se modifica el color del texto

SI

Configuraciones Generales

Vista desde la cual se pueden modificar los parámetros de configuración de la aplicación.

Administradores Ingresar una dirección de controlador de dominio inexistente.

Se guarda el parámetro. (pero no es posible validar el acceso con un usuario de directorio activo

SI

Ingresar la dirección de controlador de dominio correcta

Se guarda el parámetro. Los usuarios de directorio activo pueden ingresar.

SI

Se establece un timeout de la aplicación en 3 minutos

El usuario permanece inactivo durante 3 minutos y una vez intenta realizar una acción es redireccionado a la pantalla de login.

SI

Dejar el parámetro de “Activar validación del browser” en SI

Solo permite el acceso a la aplicación desde navegadores permitidos (IE, Chrome o FireFox)

SI

Activar la validación de grupos LDAP

Realiza mapeo de los grupos del Directorio Activo

SI

Inactivar la validación de grupos LDAP

Carga los módulos de la aplicación almacenados en la base de datos

SI

Se ingresa un usuario y contraseña de directorio activo

Guarda el parámetro y garantiza la carga de grupos LDAP

SI

Inventarios Ingreso de Elementos Frontal que contiene el formulario que permitirá la operación de ingreso de elementos

Usuario Radicador Intentar Ingresar Elemento sin completar las casillas del formulario

El programa exige el campo requerido con un texto de validación por cada campo sin completar

SI

Abrir las listas desplegables para comprobar que los

Aparecen correctamente las lista de estado, sede, area, categoría

SI

113

datos son traídos de la base de datos Intentar ingresar un articulo usando un número de placa ya existente en la base de datos

Se muestra el texto “Compruebe que el número de placa ingresado no haya sido usado previamente.”

SI

Se ingresa un articulo con todos los datos de forma coherente y usando un número de placa nuevo

Aparece el texto “Elemento ingresado satisfactoriamente”

SI

Consultas Frontal que permite realizar búsquedas de los elementos que se encuentran registrados en el inventario

Usuario Consultor, usuario radicador

Usar el control básico (de consultas por placa o serial) y seleccionar el valor 400

Como la placa 400 existe se presenta la información asociada a dicha placa desde la rejilla inferior de la página.

SI

Usar el control básico y seleccionar un número de placa no registrado en base de datos

En la rejilla inferior se presenta el texto “no hay registros para visualizar”

SI

Usar el control básico para buscar un serial existente en base de datos

Se presenta el o los elementos (acción permitida) que tenga el mismo número serial

SI

En el frontal marcar SI en ¿usar filtro personalizado?

Se activa un nuevo control y se deshabilita la búsqueda básica

SI

Desde el control personalizado dar clic en “Aplicar Filtro” sin criterios

El criterio de cero condiciones traerá todos los elementos existentes en la base de datos

SI

Agregar un criterio donde el número de placa sea mayor estricto que 200

La consulta trae todos los elementos que sean mayores a 200

SI

Gestión de Elementos Frontal donde se puede realizar proceso de modificación y reasignación de los elementos ya existentes en la base de datos

Usuario consultor, usuario radicador, usuario administrador

Usar el control personalizado para generar el criterio de búsqueda que traiga los elementos que se desean editar.

El control filtra por el criterio seleccionado y trae en la rejilla el resultado de la búsqueda mientras el elemento cumpla con dicho criterio

SI

Del resultado de un búsqueda seleccionar

Aparece una ventana emergente con toda la

SI

114

un registro y dar clic en “Editar”

información editable del elemento.

Modificar uno de los datos del elemento del inventario y guardar

Se cierra la ventana emergente y se aplica el filtro de nuevo. Los datos se han modificado correctamente

SI

Intentar eliminar un elemento de la base de datos de inventarios

No es posible ya que no existe una opción que admita este comando

SI

Reportes Frontal que permite una consulta y posterior generación de reporte que consignará en un archivo con formato Excel la exportación de la consulta.

Usuario consultor, usuario radicador.

Realizar una consulta con ayuda del control personalizado.

Al aplicar filtro se obtiene el resultado en la rejilla inferior de la página. De no coincidir la búsqueda aparecerá el texto “no hay registros para visualizar”

SI

Descargar reporte antes de consultar

No es posible mientras no se haga una consulta

SI

Descargar reporte luego de una consulta

El link “generar reporte” es visible luego de que la búsqueda arroje resultados

SI

Historico de Movimientos

Frontal que contiene todo el histórico de movimientos realizados por cualquier usuario de la aplicación con la facultad de alterar las propiedades de un elemento existente en la base de datos

Abrir el frontal para visualizar el listado histórico de movimientos

Se visualiza una rejilla con las propiedades: Tipo de objeto, estado anterior, estado actual, tipo movimiento, fecha movimiento y usuario movimiento

SI

115

6.5 FASE CIERRE

Con pruebas de Satisfacción y Aceptación del sistema, el software ya no es prototipo, pasa a ser el Sistema de inventarios Cyza, 100% funcional.

Para la entrega, se cumple con los requisitos del checklist (tabla 56) y se firma acta de entrega y recibido a satisfacción.

Tabla 56. Lista de entregables del proyecto

Entrega Check Anexo Medios con Instalador y software (DVD) N/A Manual de Usuario Administrador Inventarios Manual de Usuario Módulos de Inventarios Manual Técnico de Publicación Inventarios Documentación Pruebas satisfactorias Acta de recibido a Satisfacción

116

7 ANÁLISIS COSTO/BENEFICIO

Es el análisis que pone en consideración los costos y beneficios del nuevo sistema versus el anterior.

Debido un grado de dificultad, el proyecto en vez de un beneficio monetario, entrega ventajas operativas brindando soporte a procesos internos de la compañía que no eran medibles en términos de ganancias lucrativas. Sin embargo se expone los beneficios intangibles que son más importantes que los cuantificables desde el punto de vista económico. (Kendall p.331)[8]

7.1 COSTOS

Representaron los conceptos requeridos para implementar el sistema propuesto. Todos son medibles y estimables en unidades económicas.

Los costos involucrados en el sistema de gestión de inventarios son los siguientes:

• Coste de desarrollo Tiempo: 611 horas de desarrollo. Coste al proyecto: $3.818.750

• Adquisición de equipos Tiempo: 5 años. Coste al proyecto: $0 • Licencias de herramientas desarrollo Tiempo: 16 meses. Coste al

proyecto: $0 • Adquisición de infraestructura Tiempo: 5 años. Coste al proyecto: $0 • Gastos de material (papelería) Tiempo: 16 meses. Coste al proyecto:

$60.000 • Gastos de mantenimiento Tiempo: después de 16 meses. Coste al

proyecto: $120.000 anuales • Proveedores de internet Tiempo 16 meses. Coste al proyecto: $0 • Gastos de formación Tiempo: 1 mes. Coste al proyecto: $0

117

7.2 BENEFICIOS

Corresponde a todo tipo de ventajas y aspectos positivos del proyecto y ganancias brindadas por el software. Son beneficios tangible y cuantificable en términos económicos o intangibles y cualitativos y no ponderables de una forma objetiva. Los beneficios identificados en el proyecto son los siguientes:

Tangibles:

• Incremento de productividad: Mejor utilización de recursos humanos. Se dispone de un solo operario que realice la jornada de inventario de una sede específica en vez de dos operarios que originalmente se asignaban. El tiempo de jornada por un operario que utilice la herramienta propuesta será de al menos la mitad de lo que un operario lo hacía de manera manual lo que se traduce en un ahorro del 50% en gastos operativos por contratación de mano de obra.

• Ahorro de gastos de mantenimiento: Orientado a los elementos inventariados. El nuevo sistema permite saber de forma inmediata el estado de cada artículo y comprobar si aún están dentro del periodo de garantía del proveedor. Por desconocimiento de éste concepto y la falta de información a tiempo hubo en promedio un coste anual de $1.000.000. Justificación: Cyza Outsourcing S.A. debió pagar a terceros arreglos urgentes por fallos a nivel de hardware por no contar con un repositorio que permitiera consultar si los componentes con fallas estaban dentro del periodo de garantía del proveedor.

• Ahorro de material: Con el uso del aplicativo se eliminó la implementación de planillas manuales e impresas en formato físico de cada empleado como se llevaba anteriormente. Se estima una reducción de coste de por lo menos $200.000 anuales. Justificación: En los últimos tres periodos ha sido necesario llevar un formato de paz y salvo que describe los artículos asignados a cada empleado. Son alrededor de 5 hojas ($1.000) por persona y se lleva registro en promedio de 200 personas. Estas hojas deben ser reemplazadas al finalizar cada año al renovar la información consignada.

• Ahorro de costes por Incumplimiento: El uso del nuevo sistema evita no incurrir en fallos por incumplimientos correspondientes a los Acuerdos de Nivel de Servicio pactados con los clientes externos a causa de no conocer

118

a tiempo el número de máquinas que se encontraban no operativas dentro de uno de los proyectos convenidos. Una de las cláusulas permitía una cantidad mínima de máquinas que podrían no funcionar pero no se podía sobrepasar éste mínimo. Por la violación de ésta cláusula la empresa dejó de percibir $10.000.000 en un solo periodo anual. Naturalmente este tipo de eventualidades son esporádicas pero igualmente perjudiciales.

Intangibles:

• Software hecho a la medida garantizando cumplir con necesidades puntuales del cliente permitiendo adaptar sus funciones a los procesos particulares en la compañía.

• Sistematización de los procesos de control sobre los activos de Cyza Outsourcing S.A. permite tener una mejor administración de los recursos de la compañía ofreciendo veracidad de la información y centralización de la misma.

• Mejoramiento ante la reacción de la puesta en marcha de un nuevo proyecto de servicio en la empresa, permitiendo disponer de los equipos requeridos al conocer su estado y accesibilidad.

• Lograr que el área de infraestructura que funciona de manera transversal sobre los proceso de Cyza tenga una mejor imagen dentro de la compañía brindando un verdadero soporte a nivel de recursos e información valiosa.

• El sistema de control de inventarios evita incurrir en fallos por desconocimiento de existencia de equipos disponibles, fallos sobre acuerdos de nivel de servicios o sub-utilización de recursos por elementos que realmente se pueden explotar traduciéndose en ahorros significativos para la empresa.

119

7.3 COMPARATIVO CON OTRAS PROPUESTAS DEL MERCADO

Tabla 57. Tabla Comparativa de otras propuestas

Fuente de precios TPV Comercios: http://www.shareit.com/product.html?productid=300271859&sessionid=2613425814&random=46f75a50509feb2ce736871d9ea574b9 Fuente de precios EcountERP: http://www.ecounterp.com/es/manual/resources-pricing.jsp Fuente de precios Symantec Altiris: http://buy.norton.com/es-mx/norton-software

CARACTERÍSTICA SISTEMA CONTROL

INV.

SOFTWARE MÓNICA

TPV COMERCIOS

ECOUNTERP

SYMANTEC ALTIRIS

Acceso de administración desde la Web SI NO NO SI SI

Uso de Pistola lectora SI SI SI SI NO

Generación de Reportes SI SI SI SI SI

Vinculación de usuarios contra Directorio Activo SI NO NO NO NO

Módulo de Consultas SI SI SI SI NO

Base de datos controlado por Cyza SI SI NO NO SI

Implementación de módulos Independientes SI NO SI SI NO

Software hecho a la medida SI NO NO NO NO

Software integrable con otros aplicativos de Cyza Outsourcing

SI NO NO NO NO

Permite expandir funcionalidades futuras aún después de publicado.

SI NO NO NO NO

País de Origen ESTADOS UNIDOS ESPAÑA ESTADOS

UNIDOS ESTADOS UNIDOS

Costo producto $7,935,000 $ 290.000 por terminal

€ 93 (eur) por terminal

$110,000 mensual

U$176 Para 10 usuarios

Soporte anual $0 N/d €68 (eur) $0 U$100

Terminal adicional $0 $290.000 €88 (eur) $0 U$90

120

Se decide evaluar la oferta del mercado contra las características puntuales de la propuesta de Sistema de Control de Inventario para Cyza Outsourcing debido a que se trata de un software a la medida y se pretende evaluar si existe en el mercado una propuesta que cumpla con todos los requisitos sugeridos al software que se pretende desarrollar.

En este cuadro comparativo se incluye un producto llamado Symantec Altiris que es un software de inventario de equipos y realiza operaciones de control sobre terminales finales logrando monitorear internamente las configuraciones y características de hardware que cada uno de los equipos utiliza, así como aplicativos de software que también se encuentren instalados presentando información completa sobre la manipulación de cada terminal (EndPoint). No dispone de ningún tipo de funcionalidad contable.

En general las demás propuestas cumplen con el propósito de manejar un proceso de inventario pero todos ellos están orientados a cumplir esta funcionalidad desde el ámbito de una empresa comercial y es por eso que inclusive tienen módulos de contabilidad, manejo de flujo de caja, rendimiento de vendedores, etc. Pero son funcionalidades que Cyza Outsourcing no requiere implementar.

Se concluye que las propuestas existentes en el mercado no satisfacen completamente las necesidades de Cyza Outsourcing en funcionalidad debido a que prácticamente Cyza requiere de un desarrollo capaz de llevar la gestión de inventarios de los equipos físicos de la empresa pero además requiere de un componente que monitoree internamente las características de software, así como los componentes de hardware configurados en cada máquina y finalmente que este software debe poder integrarse con un sistema de autorización compatible con Active Directory.

121

8. CONCLUSIONES

• Se entrega un software capaz de inventariar elementos de software y hardware recopilando toda información relevante y característica de cada elemento.

• Se implementa una funcionalidad de acceso con integración de autenticación contra el Directorio Activo de la empresa garantizando el uso de un solo usuario para varios sistemas de la compañía.

• Se incluye en la solución desarrollada un instalador cliente para ser montado en los equipos de cómputo de la empresa con la capacidad de monitorear la configuración de hardware y software.

• La administración de los usuarios en la aplicación tiene la flexibilidad suficiente para personalizar roles con accesos específicos dentro de la aplicación.

• El proceso de enrolamiento de nuevos elementos al Sistema de Gestión de Inventarios integra satisfactoriamente el uso de la pistola lectora.

• Durante el proceso de desarrollo de la solución se adopta la metodología de Programación Extrema poniendo en práctica sus valores y principios y se aplica el uso complementario de Prototipos como herramienta colaborativa presente durante toda la etapa de desarrollo.

• Se realiza la publicación y entrega del Sistema de Gestión de Inventarios debidamente instalado en los servidores de Cyza Outsourcing S.A para su uso operativo en el ambiente de producción de la compañía.

122

9. REFERENCIAS

[1] Muller, Max. Fundamentos de la Administración de Inventarios. Bogotá: Grupo

Editorial Norma 2004.

[2] Taha, Hamdy A. Investigación de Operaciones. (7ª Edición). México: Pearson

Educación. 2004.

[3] Muller, Max. Fundamentos de la Administración de Inventarios. Bogotá: Grupo

Editorial Norma 2004.

[4] Ceballos, F. J. Enciclopedia de Microsoft Visual C#. Madrid: Alfaomega RA-

MA. 2006

[5] Johnson, G. y Northrup, T. Microsoft.NET Framework 2.0 Web-Base Client

Development. Washington: Microsoft Press 2007.

[6] Fritz Bauer Citado por Pressman, Roger S. Ingeniería de Software; un enfoque

práctico. McGraw Hill. España. 2002.

[7] Kendall, Kenneth E. Análisis y Diseño de Sistemas. Elaboración de Prototipos,

RAD y Programación Extrema. México. 1995.

[8] Beck, Kent. Extreme Programming Explained: Embrace Chance. Addison-

Wesley Pub Co. 1999.

[9] Kendall, Kenneth E. Análisis y Diseño de Sistemas. Elaboración de Prototipos,

RAD y Programación Extrema. México. 1995.

[10] Kendall, Kenneth E. Análisis y Diseño de Sistemas. Preparación de la

Propuesta de Sistemas. México. 1995.

[11] PMBOK@, Project Mannager Institute, Guia de Fundamentos para la Dirección

de Proyectos. 2014.

123

10. BIBLIOGRAFÍA

• Beck, Kent. (1999) Extreme Programming Explained: Embrace Change. (1ª

Edición). Addison-Wesley Pub Co.

• Ceballos Sierra, Francisco Javier. (2006) Enciclopedia de Microsoft Visual

C#. Introducción a Microsoft.Net. México: Alfaomega Grupo Editor, S.A.

• Chiavenato, Idalberto (2006) Introducción a la Teoría General de la

Administración. (7ª Edición). Mexico: McGraw Hill.

• Fowler, Martin. Scott, Kendall (2000) UMLGota a Gota. México: Prentice

Hall.

• INSTITUTO COLOMBIANO DE NORMALIZACION Y CERTIFICACION.

Presentación de Tesis, Trabajos de Grado y Otros Trabajos de

Investigación. NTC 1486. Sexta Edición. Bogotá D.C.

• Johnson, Glenn (2007) Microsoft.NETFramenwork Web-Based. Training Kit.

Washington: Microsoft Press

• Kendall, Kenneth E. (2005) Análisis y Diseño de Sistemas. (6ª Edición).

México: Pearson Education.

• Muller, Max (2004) Fundamentos de la Administración de Inventarios.

Bogotá: Grupo Editorial Norma.

• PerezLopez, Cesar (2011). Microsoft SQL Server 2008 R2 México: Ra-Ma

Editorial.

• Pressman, Roger S. (2002). Ingeniería de Software. Un Enfoque Práctico.

(5ª Edición). España: McGraw Hill.

• Taha, Hamdy A. (2004) Investigación de Operaciones (7ª Edición). México:

Pearson Educación.

124

11. CITAS DE INTERNET

• Añasco Baquero, Carlos Dorian. Administración de una Bodega. Capitulo

12: Control de Inventarios. Publicado el 6 de agosto de 2010. En

http://www.emagister.com/curso-administracion-bodega/control-inventarios

• Código de Barras, (8 de octubre de 2008) ABC de código de barras.

Consultado de http://www.idautomatica.com/informacion-tecnica/codigo-de-

barras.php

• Escáner de Lápiz óptico, (5 de febrero de 2007) Escáner, Lápiz óptico y

escritorio. Blog consultado en http://trabajocarloshendrick.blogspot.com/

• Generador de Código de Barras Online. Consultado de http://barcode.tec-

it.com/barcode-generator.aspx?LANG=es

• Una Aproximación a los Modelos de Inventarios (s.f) Consultado el día 20

de agosto de 2012, de http://www.investigacion-

operaciones.com/Modelo%20Inventarios.htm

• Software Mónica. Consultado el 22 de julio de 2013, de

http://www.technotel.com/

• Gabriela Flores Talavera, Formando Investigadores. Estado del Arte.

Publicación del 17 de enero de 2011. http://formandoinvestigadores-

gft.blogspot.com/2011/01/estado-del-arte.html

• Introducción a la programación Multicapa. David Esteban Vergara Zapata.

Publicado el 29 de mayo de 2004. En

http://www.elguille.info/colabora/puntoNET/jevergara_Multitier.htm

• Plantilla de estructura de desglose de trabajo (EDT). Ricardo Arturo

Rodríguez Morillo. Publicado el 23 de diciembre de 2013. En

http://www.pmoinformatica.com/2013/12/plantilla-estructura-desglose-

trabajo.html

125

LISTA DE ANEXOS

Anexo A. Acta de Seguimiento primera visita.

Anexo B. Acta de Seguimiento segunda visita

Anexo C. Formatos con concepto de Viable

Anexo D. Sábana de Notas.

Anexo E. Contrato Laboral.

Anexo F. Acta de Entrega a Satisfacción.

Documents

DESARROLLO DE UN SISTEMA DE CONTROL DE ...repository.udistrital.edu.co/bitstream/11349/2374/1...7 Figura 37. Diagrama Caso de Uso para REQ-FNC-11 77 Figura 38. Diagrama de Secuencia