Universidad Tecnológica de Querétaro

Firmado digitalmente por Universidad Tecnológica de Querétaro Nombre de reconocimiento (DN): cn=Universidad Tecnológica de Querétaro, o=Universidad Tecnológica de Querétaro, ou, [email protected], c=MX Fecha: 2013.04.30 10:14:56 -05'00'

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

Nombre del proyecto: “APLICATIVO WEB PARA CONTROL DE INVENTARIOS”

Empresa:

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

Memoria que como parte de los requisitos para obtener el título de: Ingeniero en Tecnologías de la Información y Comunicación

Presenta:

OCTAVIO GONZÁLEZ PALOMARES

Asesor de la UTEQ M. EN C. Raúl García Pérez

Asesor de la Empresa LIC. Alfredo García Rodríguez

Santiago de Querétaro, Qro. Abril 2013

Resumen Se busca implementar un aplicativo web con el seguimiento de un patrón de diseño, denominado Modelo Vista Controlador ya que se intenta seguir patrones de desarrollo dentro del Departamento de TI de la Universidad Tecnología de Querétaro. Se quiere comenzar con modelos y Frameworks ya que muchas de las soluciones de Software no están implementadas con estos tipos de Normas que poco a poco son más utilizadas y tal vez, requeridas para tener un software de calidad, mantenibilidad y de óptimo rendimiento. Para ello se pretende que con el modelo MVC se pueda dar pauta en el uso de Frameworks más robustos y de soporte internacional. El sistema se desarrolla usando dos bases de datos dentro de los servidores de la institución y por eso mismo no se muestran las tablas de los usuarios y de los departamentos. Cabe señalar que se usa una metodología estructurada de programación para el desarrollo del aplicativo. Palabras clave: guía, referencia, tesis, Modelo, Vista, Controlador. Abstract It seeks to implement a web application to track a design pattern called Model View Controller as it tries to follow patterns of development within the IT Department at the University of Technology in Queretaro. It wants to start with models and Frameworks because many of our software solutions are not implemented with these types of standards that are gradually used and perhaps required to have software quality, maintainability and optimum performance. This is intended that the MVC pattern can be given to the use of more robust Frameworks and international standars. The system is developed using two databases servers within the same institution and therefore do not show tables of users and departments. The developing of this application is using a structured programming for application development. Agradecimientos A mi familia y seres queridos por estar incondicionalmente a mi lado. Muchas gracias por estar en esta fase de mi vida.

Página | 2

ÍNDICE Página

Resumen ................................................................................................................ 2 Abstract .................................................................................................................. 2 Agradecimientos ................................................................................................... 2 Índice ...................................................................................................................... 3 Tabla de Ilustraciones ........................................................................................... 4 I. INTRODUCCIÓN ................................................................................................. 5 II. ANTECEDENTES ............................................................................................... 5 III. JUSTIFICACIÓN ................................................................................................ 6 IV. OBJETIVOS ...................................................................................................... 6 V. ALCANCE .......................................................................................................... 7 VI. FUNDAMENTACIÓN TEÓRICA........................................................................ 8 VII. PLAN DE ACTIVIDADES ................................................................................. 9 VIII. RECURSOS MATERIALES Y HUMANOS.................................................... 11 IX. DESARROLLO DEL PROYECTO ................................................................... 13 X. RESULTADOS OBTENIDOS ........................................................................... 29 XI. ANÁLISIS DE RIESGO ................................................................................... 29 XII. CONCLUSIONES ........................................................................................... 30 XIII. RECOMENDACIONES .................................................................................. 30 XIV. REFERENCIAS BIBLIOGRÁFICAS ............................................................. 30

Página | 3

Tabla de Ilustraciones Página Ilustración 1- Grafica de Gantt............................................................................... 10 Ilustración 2- Diagrama de Base de Datos ............................................................ 14 Ilustración 3- Vista login ........................................................................................ 14 Ilustración 4- Vista Inicio Consumibles .................................................................. 15 Ilustración 5- Vista inicio Accesorios ..................................................................... 15 Ilustración 6- Vista Accesorios Disponibles ........................................................... 16 Ilustración 7- Vista agregar Accesorio ................................................................... 16 Ilustración 8- Vista Proveedores............................................................................ 17 Ilustración 9- Vista Proveedores (Accesorios) ....................................................... 17 Ilustración 10- Vista Menú Accesorios .................................................................. 20 Ilustración 11- Vista Menú Consumibles ............................................................... 20 Ilustración 12- Vista Accesorios ............................................................................ 22 Ilustración 13- Vista Botón Ver Accesorios ........................................................... 24 Ilustración 14- Vista Ver Accesorios Detallado ...................................................... 25 Ilustración 15- Vista Agregar Accesorio ................................................................ 26 Ilustración 16- Vista Avisos ................................................................................... 28

Página | 4

I. INTRODUCCIÓN El desarrollo de software ha evolucionado a pasos agigantados desde la década de los 80’s, a tal grado que las aplicaciones de hoy día son tan diversas y potentes que es requerido el conocer de varios lenguajes de programación para complementar funcionalidades con otros lenguajes y resolver problemas cotidianos de una manera cada vez más fácil y casi autómata. Este proyecto pretende establecer la inicialización de un programa de control de activos de un inventario dentro de del Departamento de Tecnologías de Información de una Institución Educativa con un patrón muy común en el ámbito de software, que es el patrón Modelo, Vista y Controlador. Este patrón se enfoca en la frase, “Divide y vencerás”; que a su vez ayuda a esquematizar de manera más fácil las funciones del Software para su desarrollo y su mantenibilidad, así como su crecimiento oportuno al agregar otra funcionalidad sin tener que ver esquemas gigantescos. Cada parte del modelo que se pretende implementar ayuda a facilitar las tareas de diseño y programación ya que el contenido de configuración, de información y de visualización está concentrada en módulos separados.

II. ANTECEDENTES La Universidad Tecnológica de Querétaro está seccionada en diferentes divisiones, departamentos y subdirecciones como órganos interdependientes. Por esto, la institución usa metodologías diversas para la comprensión y resolución de las necesidades de cada área con apoyos tecnológicos (dispositivos, herramientas, consumibles, redes internas de comunicación, sistemas administrativos de información, etc.) interinos que de igual manera, requieren ser controlados y distribuidos de manera equitativa. De por medio, la Universidad Tecnológica de Querétaro se apoya del Departamento de Tecnologías de Información (DTI) para dar solución a las necesidades de las divisiones, departamentos y subdirecciones con dichas tecnologías informáticas. Página | 5

III. JUSTIFICACIÓN El desarrollo del sistema surge como respuesta a las necesidades internas del Departamento de Tecnologías de Información (DTI) como solución a la organización y control de inventarios y almacenaje de recursos necesarios para el uso de las divisiones, departamentos y subdirecciones de la Universidad Tecnológica de Querétaro.

Este sistema tiene como objetivo cubrir aspectos

concernientes a los activos almacenados dentro del Departamento de Tecnologías de Información (DTI) los cuales son distribuidos a áreas o equipos específicos para facilitar o complementar las actividades dentro de la institución. El sistema estará basado principalmente en un control de inventario de los activos que ingresan al Departamento de Tecnologías y se asignan posteriormente a las divisiones, departamentos o subdirecciones; así también, tener conocimiento de la ubicación ya que

pueden ser agregados en equipos para actualizar o remplazar

componentes. El objetivo principal es tener un control total de esta información con fines estadísticos y administrativos, ya que se desea conocer las actividades de uso y frecuencia dentro de los departamentos de la institución, además de la disponibilidad de los componentes en el inventario y sus costos.

IV. OBJETIVOS 

Se administrará el flujo de los activos del almacén del Departamento de Tecnologías de Información (DTI) con respecto a las solicitudes las divisiones, departamentos y subdirecciones de la institución.



Se tendrá conocimiento del estado de los activos con respecto a la distribución en las divisiones, departamentos y subdirecciones de la institución con un apartado de verificación de los activos asignados.

Página | 6

V. ALCANCE El desarrollo del aplicativo abarcará las etapas comunes de desarrollo (análisis, diseño, programación e implementación) de software en el modelo de cascada, el cual implica, no pasar a otra fase si una de las fases no se ha concluido por completo. Este tipo de modelo de desarrollo permite estar interactuando directamente con la fase anterior para realizar rápidamente un cambio que provoque problemas sin tener que iniciar nuevamente el ciclo de desarrollo desde el principio. Analíticamente pueden cubrir las necesidades requeridas por la institución con las herramientas que se disponen actualmente ya que se pueden verificar teóricamente sin necesidad de llevar a la práctica los requisitos actuales. Prácticamente se podrán cubrir las necesidades de los requisitos, aun así, se deben de mencionar ciertas características importantes; los usuarios dentro del aplicativo no podrán ver partes de los inventarios a los cuales no les corresponde interactuar. Ciertas partes del aplicativo serán solo de lectura, lo cual lleva a la generación automática de información alimentada por ambos inventarios. No todos los campos podrán estar forzosamente validados en cuestión de tipos de datos, ya que en ellos se requiere libertad al incluir números y letras. El aplicativo no podrá estar trabajando independientemente consumiendo recursos exclusivos ya que contará con interactividad con otra base de datos dentro del mismo servidor de la institución. El aplicativo únicamente y por razones de compatibilidad estará desarrollado con herramientas que permitan el uso libre, distribución y manipulación del código desarrollado dentro de la institución.

Página | 7

VI. FUNDAMENTACIÓN TEÓRICA Al paso del tiempo las empresas, sin importar su nivel, requieren de un modelo administrativo cada vez mejor; parte de ellas siguen modelos los cuales, siendo eficientes no siempre entregan buenos resultados, sin embargo, se pueden maximizar tiempos y reducir actividades con ciertos procesos de automatización. Los datos usados por el Departamento de Tecnologías de la Información en su inventario proceden, mayoritariamente, de los activos que entran para ser distribuidos posteriormente a las divisiones, departamentos y subdirecciones de la institución. El administrador de activos de inventarios por medio de una serie de formatos y procedimientos, distribuye los activos al solicitante correspondiente (basándose en formatos de solicitud).

El aplicativo estará basado en gran parte en la manera que administran los activos de inventarios de DTI , todo esto tiene como objetivo familiarizar de un modo práctico el uso de las nuevas tecnologías de la información y el trabajo que se realiza ya que seguirá siendo parcialmente el mismo pero con modalidades automatizadas.

Página | 8

VII.PLAN DE ACTIVIDADES En este apartado se mostrará el plan de actividades de desarrollo del sistema de inventarios el cual comienza el día 11 de Febrero de 2013 y concluye el día 25 de Marzo de 2013. Dicho plan de actividades fue elaborado con una herramienta para calendarizar actividades con diagramas de Gantt, el resultado se muestra a continuación: Nombre de tarea Inventario DTI Análisis Análisis del problema Postulación de soluciones Levantamiento de requisitos Diseño Planeación diseño Valoración propuestas Diseño interfaces Diseño base de datos Programación Programación Interfaces Acoplamiento con Base de datos Pruebas e implementación Montaje sistema al servicio local Documentación Final

Duración 31 días 11 días 5 días 3 días 6 días 6 días 3 días 1 día 3 días 2 días 13 días 13 días 5 días 3 días 1 día 2 días

Página | 9

Comienzo lun 11/02/13 lun 11/02/13 lun 11/02/13 lun 18/02/13 lun 18/02/13 lun 25/02/13 lun 25/02/13 jue 28/02/13 mar 26/02/13 vie 01/03/13 mar 05/03/13 mar 05/03/13 lun 11/03/13 jue 21/03/13 jue 21/03/13 vie 22/03/13

Fin lun 25/03/13 lun 25/02/13 vie 15/02/13 mie 20/02/13 lun 25/02/13 lun 04/03/13 mie 27/02/13 jue 28/02/13 jue 28/02/13 lun 04/03/13 jue 21/03/13 jue 21/03/13 vie 15/03/13 lun 25/03/13 jue 21/03/13 lun 25/03/13

Ilustración 1 - Grafica de Gantt

Página | 10

VIII. RECURSOS MATERIALES Y HUMANOS Requisitos mínimos para el análisis, desarrollo e implementación del aplicativo web de Inventarios del Departamento de Tecnologías de Información.

Recurso Humano: Lenguaje de programación: PHP Ver. 3+ ( Hypertext Pre-Processor), Nivel Intermedio. Herramienta de Modelado Web: HTML Ver. 3+ (HyperText Markup Language), Nivel Básico. Base de Datos: MySQL Ver. 3+, Nivel Intermedio.

Recursos Materiales:

Dimensionando una tipología de hardware específica para un cierto número de Accesos / Clientes en el servidor.

200 Accesos / Clientes

Intel Pentium 100MHz De un mínimo de 32 MB a 64 MB RAM De un mínimo de 250MB a 2GB de espacio libre en el disco duro para el Caching.

200 a 2000 Accesos / Clientes

Intel Pentium 133MHz 64 MB RAM mínimo De un mínimo de 2GB a 4GB de espacio libre en el disco duro para el Caching

Página | 11

Requisitos mínimos del servidor para resultados óptimos del aplicativo web con respecto al servidor elegido:

MySQL (para resultados óptimos) 

Soporte para protocolo TCP/IP.



Procesador Intel Dual Core 1.8 Ghz, AMD Dual Core 1.8 Ghz (o superior en cualquiera de ellos).



Memoria RAM de 1 GB (800 Mhz)



Disco Duro 2 GB disponibles (Mínimo)

Apache (para resultados óptimos) 

. Perl-Compatible Regular Expressions Library (PCRE)



Disk Space 50 MB disponible.



ANSI-C Compiler and Build System



Memoria Ram 512MB

Página | 12

IX. DESARROLLO DEL PROYECTO Para el desarrollo del proyecto se comenzó con un breve análisis para poder levantar los requisitos pertinentes con respecto a las necesidades que el Departamento de Tecnologías de Información requiere. Se realizó un cuestionario a los administradores encargados de controlar los activos de los inventarios referentes a qué tipo de información manejan, como la administran y que información es la más importante. Con base a los resultados se les propuso una interfaz que puede adaptarse a la solución de la necesidad que ellos buscan. Además se requiere que la configuración del aplicativo lleve un Modelo de trabajo el cual pueda ayudar no sólo al entendimiento del aplicativo sino también al orden estructural del mismo, ya que se desea contar progresivamente con Frameworks de programación para posteriores aplicaciones dentro del departamento de Tecnologías de Información. El modelo utilizado es el patrón de MVC (Modelo, Vista, Controlador), que consiste en separar los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. El modelo es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado. La vista presenta el modelo en un formato adecuado para interactuar, usualmente es la interfaz de usuario. El controlador responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista, el controlador es el intermediario entre el modelo y la vista ya que como su nombre lo dice, controla los eventos que requiere el usuario por medio de la vista.

Página | 13

Como parte del modelo del aplicativo se diseñó la siguiente base de datos con los atributos necesarios para la interactividad y almacenaje de la información con respecto a los consumibles y accesorios de los inventarios:

Ilustración 2- Diagrama de Base de Datos

Las vistas base (muchas de ellas utilizan funcionalidades similares, por lo mismo no se incluyen en la vista por cuestiones de versatilidad del documento, pero se explicarán más adelante) para la administración de los inventarios son:

Ilustración 3- Vista login

Página | 14

Ilustración 4- Vista Inicio Consumibles

Ilustración 5- Vista inicio Accesorios

Página | 15

Ilustración 6- Vista Accesorios Disponibles

Ilustración 7- Vista agregar Accesorio

Página | 16

Ilustración 9-Vista Proveedores (Accesorios) Ilustración 8- Vista Proveedores

La funcionalidad general del aplicativo de inventarios es: conocer la distribución de los activos y además, la disponibilidad de los mismos dentro del almacén, para ello se emplean consultas e inserciones en las tablas correspondientes de la base de datos para administrar esta información. Como se mencionaba, este aplicativo está diseñado con base al patrón de diseño Modelo Vista Controlador (MVC), el cual implica dividir en capas las funcionalidades para tener una distribución arquitectónica a nivel Software más ordenada, y con esto se pretende tener una mejor legibilidad para posteriores actualizaciones o tener un referente para otro tipo de aplicativos web. El contenido dentro del aplicativo está distribuido en diferentes niveles para su configuración, lo cual permite ordenar no sólo las funcionalidades, sino también el contenido visual y otros tipos de archivos que se pueden usar para enriquecer el contenido del aplicativo.

Página | 17

Ilustración 9- Vista Contenido MVC

Existen cuatro carpetas para distribuir la información utilizada dentro del aplicativo. La carpeta de ‘controladores’ almacena archivos que se usan para llamar las vistas requeridas por el usuario y también incluyen sentencias de eventos para manipular la información que se requiera en conjunto con los archivos de la carpeta modelos. La carpeta ‘modelos’ contiene archivos con sentencias para el acceso a datos, estas sentencias se pueden referir a la inserción, la actualización, el borrado de información o consulta. La carpeta ‘style’ contiene los archivos necesarios para la visualización de imágenes, colores, fuentes, etc. y formatos de diseño para la presentación de información dentro del aplicativo. La carpeta ‘vistas’ contiene los archivos que mostrarán la información con respecto a las solicitudes del usuario, dirigidas por los archivos de control de la carpeta ‘controladores’. El archivo ‘conexión.php’ es el encargado de establecer los parámetros de conexión para la base de datos. Ejemplo: El archivo ‘index.php’ funge un papel importante ya que en él se direccionan los eventos que se solicitan y se muestra el contenido del aplicativo ya que con este archivo ‘index.php’ será el único con el que el usuario estará en contacto. Página | 18

Los datos necesarios para dirigir al usuario con respecto a sus funciones dentro de la administración de inventarios serán asignadas filtrando información almacenada en el sistema independiente denominado Sistema de Ordenes de Servicio, el cual esta administrado por el Departamento de Tecnologías de Información de la Universidad Tecnológica de Querétaro. Por cuestiones de seguridad no se podrá mostrar información de acceso u otros referentes de seguridad o formas de manipulación de datos, ya que la propiedad de esa información es exclusiva de las Jefaturas de la Universidad Tecnológica de Querétaro, y por esta cuestión se sustituirán varios valores y funciones para poder ilustrar la información con carácter educativo que se emplearon básicamente para el desarrollo de este aplicativo.

Página | 19

Cuando un usuario inicie sesión se generará una Cookie la cual contiene información del usuario; con esta información contenida en el archivo de sesión se le direccionará a su módulo de inventarios con las siguientes instrucciones:

Si el usuario no corresponde a ningún departamento de inventarios se le mandará de regreso al portal del Departamento de Tecnologías de información. Si el usuario corresponde a algún departamento de inventarios se le mostrará la información concerniente a su departamento.

Además, existe un control para mostrar el menú con respecto a departamentos, ya que cada departamento cuenta con diferentes funcionalidades con respecto a sus activos y el cómo manipula la información de cada uno de ellos.

Ilustración 10- Vista Menú Accesorios

Ilustración 11-Vista Menú Consumibles

Página | 20

Este tipo de información se muestra con la solicitud de una vista hacia el controlador del menú. Cabe señalar que las vistas del HEADER y el FOOTER se encuentran en archivos separados, esto se hace para reducir el contenido de cada vista con respecto a la información contenida, es decir, únicamente se muestran cuando se incluyen en las vistas en donde se requieran.

Cada vista tiene una variable de ubicación, que se usa para enviarlo como parámetro al controlador de la vista del menú para poder mostrar las opciones seleccionadas por ejemplo: ‘$ubicacion= accesorios.php’.

La instrucción para mostrar el contenido del menú con respecto a su departamento es la siguiente:

Se instancía una clase de control dentro de la carpeta de controladores para poder enviarle los parámetros de departamento, el parámetro de ‘$ubicación’ se usa para representar el color de enlace elegido al seleccionar un módulo en el menú.

Se envían los parámetros antes mencionados al constructor de la clase para almacenarlos en variables que se usaran posteriormente para mostrar los menús.

Se condicionan las variables para poder mostrar el contenido de cada ubicación e inventario concerniente con las siguientes líneas de código:

Página | 21

Cuando un usuario entra a la página principal que le corresponde, se le muestran ciertos datos que le pueden servir de referentes para la administración de los activos. Por ejemplo, la siguiente tabla que está ubicada en los accesorios muestra contenido “resumido” es decir, información que requiere ver el usuario de manera rápida y no detallada:

Ilustración 12- Vista Accesorios

Este contenido lo muestra la vista de inicio con ayuda del controlador de la tabla “resumen” el cual dispone de un modelo para acceso a la información de la base de datos.

Página | 22

Al iniciar sesión el usuario, automáticamente la vista principal solicita el controlador para mostrar el contenido.

La instrucción se guarda en la variable ‘$items’ y envía los parámetros de conexión a la función del modelo para conectarse a la base de datos.

La función de resumen de accesorios recibe el parámetro de conexión y efectúa una consulta con la variable ‘$consulta’, al final se regresa la variable a ‘$items’ que se ubica en la vista principal para poder llenar el formato de presentación.

Página | 23

De esta manera se llena el contenido del formato de presentación en la página principal de accesorios y varios formatos más dentro del aplicativo de inventarios, ya que en la mayoría de los casos son consultas informativas. Por ejemplo, el botón ‘Ver Accesorios’ ubicado en la página principal del aplicativo muestra a detalle el contenido de los accesorios disponibles con la opción de poder administrar la información.

Ilustración 13 - Vista Botón Ver Accesorios

Existen botones de administración de contenido en los diferentes módulos de consulta del aplicativo. Con ellos se podrán ver a detalle los contenidos de cada módulo o administrar el contenido de la página, ya sea actualizando, eliminando o agregando contenido. Se emplea nuevamente el uso del controlador y la vista, que Página | 24

posteriormente el controlador solicita información al modelo para llenar la tabla de la vista con el mismo procedimiento que se explicó anteriormente. Las funciones específicas de los botones es enviar a la página principal o ‘index.php’ el controlador que se usará y la acción que se empleará.

Ilustración 14- Vista Ver Accesorios Detallado

Por ejemplo, al dar clic al botón ‘Ver Accesorios’ se le envían los siguientes parámetros a ‘index.php’ de la siguiente manera:

/index.php?controlador=accesorios&acción=mostraraccesorios

Así que el usuario lo único que podrá ver en la URL del navegador son acciones y no variables.

Al querer modificar o eliminar información de un campo, el botón modificar envía

al

index.php

parámetros

como

/index.php?controlador=accesorios&acción=actualizaaccesorios. Así que ‘index.php’ ya sabe que debe de llamar al controlador de accesorios y dentro del controlador de accesorios llamar la función de ‘actualizaraccesorios’.

Página | 25

O por ejemplo, Al agregar un accesorio nuevo se le solicita la vista del formato de agregar accesorios:

Ilustración 15- Vista Agregar Accesorio

La vista al ser llenada le envía los parámetros a una función de agregar nuevo accesorio, la función llama al modelo y el modelo regresa el contenido:

Aquí la única diferencia con solo mostrar el contenido es que el modelo recibe los parámetros del formulario directamente, ya que en la vista se incluyen implícitamente las funciones: Página | 26

Una parte importante del aplicativo es mostrar en ciertos módulos un aviso si el contenido de un accesorio llega a un límite, es decir, que si esta por acabarse un accesorio se mande una alerta para después solicitar más del mismo accesorio. Esta función se ejecuta cada vez que el usuario inicia sesión, y se muestra en la página principal de los inventarios.

Esta instrucción introduce en avisos los accesorios que estén cerca del límite de no existencia, quiere decir que cuando la cantidad de accesorios disminuya y llegue hasta el stock mínimo, el usuario pueda ir solicitando más de ese accesorio si no se cuenta con los accesorios inmediatamente, se puede pausar el aviso para no ser mostrado o se puede eliminar el aviso.

Página | 27

Este formato se muestra con una consulta a la tabla de avisos:

Ilustración 16 - Vista Avisos

También una función importante en la asignación de recursos es: que si el recurso no cubre con la cantidad solicitada para la asignación, que no permita hacer la asignación:

También, cuando se desee quitar o agregar un asignación, que se reste o sume la cantidad disponible de ese accesorio o consumible.

Toda la seguridad será heredada de las funciones que tiene el Sistema de Ordenes de Servicio, por lo tanto, no se muestran esas instrucciones ya que el Departamento de Tecnologías de Información se encargará de asignar esas validaciones.

Página | 28

X. RESULTADOS OBTENIDOS Los resultados obtenidos gracias a este aplicativo podrán facilitar la proyección de información de la cantidad de activos que cuenta el Departamento de Tecnologías de Información, así como quien los asigna y a quien. Con esto se podrán enterar fácilmente de la disponibilidad de los activos en los inventarios y poder darse cuenta si se requieren o no accesorios y/o consumibles. Además, al aplicar el patrón de diseño se pretende la fomentación de Frameworks de desarrollo para futuras aplicaciones.

XI. ANÁLISIS DE RIESGO Factor de Riesgo: Tiempo Nivel Impacto: Moderado Mitigación: Calendarizar eventos y asignar niveles de importancia.

Factor de Riesgo: Falta de conocimiento en las Tecnologías Nivel de Impacto: Moderado Mitigación: Proveer de capacitaciones referentes a la Tecnología a usar.

Factor de Riesgo: Cambio de Alcance Nivel de Impacto: Moderado Mitigación: Entablar conversaciones claras con el cliente con respecto a las funcionalidades y necesidades.

Página | 29

XII. CONCLUSIONES

Algo muy importante con respecto al desarrollo es la manera de trabajar con los modelos, ya que al estar trabajando con patrones crece significativamente la calidad del software y su desempeño. La estructuración independientemente de la tecnología que se use para desarrollar es muy importante para establecer rutinas de diseño y programación, facilita el desarrollo y el mantenimiento de las aplicaciones sin importar su extensibilidad o plataforma de desarrollo.

XIII. RECOMENDACIONES Algo que agregar con respecto a los modelos es que no sólo hay que guiarse bajo patrones y Frameworks de desarrollo, sino también seguir las buenas prácticas de programación que cada lenguaje de programación tiene. Muchas veces no se sigue por tener estilos de programación diferentes, creo que al poder tener un seguimiento fiel a las normas y estatutos de las buenas prácticas para desarrollo de cualquier sistema a nivel web o stand alone, se facilitarían y ahorrarían mucho tiempo en mantenimiento y depuración.

XIV. REFERENCIAS BIBLIOGRÁFICAS PHP Manual http://www.php.net/manual/es/ (Achour, Betz, Dovgal, Lopes, & Olson, 2013)

Zend Referense Manual http://manual.zfdes.com/es/coding-standard.html (Zend Corporation, 2013)

Página | 30