UNIVERSIDAD TECNOLGICA DE TABASCO

Anlisis y Diseo de un Sistema de Inventario para la

Abarrotera DEYA

Que presenta:
T.S.U. Yarely Anahi Snchez Villegas

Para acreditar la materia de Integradora I

Asesor Acadmico:
M. en I.S. Francisco Javier Velzquez Medelln

Parrilla, Centro, Tabasco.

Mxico. Agosto del 2014

AGRADECIMIENTOS

Le doy gracias primeramente a Dios por darme la vida y permitirme llegar a este
momento que significa un avance ms en el logro de mis metas y proyectos. Le doy
gracias a mi hija que sin duda alguna es mi motivacin principal para el logro de mis
metas, ella que ha entendido mis ausencias y ocupaciones para poder lograr una
meta ms en mi vida. Le doy gracias a mis abuelos paternos porque sin ellos no
habra podido seguir este camino. Le doy gracias a mis padres por que al principio su
apoyo fue incondicional. Le doy gracias a mis profesores por compartir si valioso
conocimiento conmigo y le doy gracias a todas y cada una de las personas que
estuvieron ah para apoyarme en cada momento.

ii

RESUMEN

Este proyecto es una propuesta para la mejora de la administracin del almacn de

la abarrotera DEYA, la abarrotera tiene la necesidad de una mejor administracin
ya que no cuentan con un sistema especfico para su inventario, debido a que su
crecimiento ha sido rpido, por esta razn no es una necesidad de la abarrotera
tener un control de los productos en existencia e inexistentes en su almacn al igual
que las entradas y salidas de productos.

Realizar el sistema de inventario consiste en optimizar los procesos que se realizan

en el almacn a travs de hojas de clculo, ya que esto siempre va a tener un
margen de error alto.

El sistema de inventario propone tener un control de todas las entradas y salidas de

los productos, un control de los usuarios que tienen acceso al sistema, esto quiere
decir que no todos los usuarios tendrn los mismos privilegios al entrar al sistema.

iii

INDICE
1.

INTRODUCCION ........................................................................................................................... 8

2.

ANTECEDENTES ....................................................................................................................... 10

3.

JUSTIFICACION ......................................................................................................................... 11

4.

MARCO TEORICO ..................................................................................................................... 12

4.1

FUNDAMENTOS TERICOS ........................................................................................... 12

4.1.1 PMBOK ............................................................................................................................... 12

4.1.2 Lenguajes de programacin......................................................................................... 13
4.1.3 Manejadores de base de datos .................................................................................... 17
4.1.4 Modelos de desarrollo de software ............................................................................ 20
4.2.

MARCO CONTEXTUAL .................................................................................................... 28

4.2.1 Nombre de la empresa ................................................................................................... 28

4.2.2 Misin ................................................................................................................................. 28
4.2.3 Visin .................................................................................................................................. 28
5.

6.

OBJETIVOS ................................................................................................................................. 29
5.1.

OBJETIVO GENERAL ....................................................................................................... 29

5.2.

OBJETIVOS ESPECFICOS ............................................................................................. 29

METODOLOGA.......................................................................................................................... 30
6.1. GESTIN DE INTEGRACIN ............................................................................................. 30
6.1.1 Desarrollo del proyecto ................................................................................................. 30
6.2 GESTIN DE ALCANCE ........................................................................................................ 40
6.2.1 Acta constitutiva .............................................................................................................. 40
6.2.2 Definicin del alcance .................................................................................................... 41
6.2.3 EDT ...................................................................................................................................... 41
6.3. GESTIN DE TIEMPO ........................................................................................................... 42
6.3.1 Definicin de las actividades ....................................................................................... 42
6.3.2. Establecimiento de la secuencia de actividades ................................................... 42
6.3.3. Estimacin de los recursos de actividades ............................................................ 43
6.3.4 Estimacin de la duracin de las actividades ......................................................... 43
6.3.5. Desarrollo del cronograma .......................................................................................... 44

6.4. GESTIN DE RECURSOS HUMANOS .............................................................................. 45

6.4.1. Organigrama del proyecto ........................................................................................... 45
6.4.2. Roles y responsabilidades .......................................................................................... 45
6.4.3. Plan de recursos humanos .......................................................................................... 47
6.5. GESTIN DE COMUNICACIONES ..................................................................................... 49
6.5.1 Identificar interesados ................................................................................................... 49
6.5.2 Planificar comunicaciones ........................................................................................... 49
6.5.3 Distribuir informacin .................................................................................................... 50
6.5.4 Gestionar expectativas .................................................................................................. 50
6.5.5 Informar el desempeo .................................................................................................. 51
6.6. GESTIN DE CALIDAD ........................................................................................................ 52
6.6.1. Planificacin de la calidad ........................................................................................... 52
6.7. GESTIN DE RIESGOS ........................................................................................................ 55
6.7.1 Planificacin de riesgos ................................................................................................ 55
6.7.2 Identificar riesgos ........................................................................................................... 56
6.8. GESTIN DE ADQUISICIONES .......................................................................................... 57
6.8.1 Planificar compras y adquisiciones ........................................................................... 57
6.8.2 Planificar contratacin ................................................................................................... 57
6.8.3 Solicitar respuestas de vendedores ........................................................................... 58
6.8.4 Seleccin de vendedores .............................................................................................. 58
6.9 GESTIN DE COSTOS........................................................................................................... 59
6.9.1. Estimacin de costos .................................................................................................... 59
6.9.2 Preparacin del presupuesto ....................................................................................... 63
7.

ANALISIS DE RESULTADOS .................................................................................................. 64

8.

CONLUSIONES Y RECOMENDACIONES ............................................................................ 65

9.

FUENTES CONSULTADAS ..................................................................................................... 66

INDICE DE FIGURAS
Figura 1: Fases del modelo cascada ......................................................................... 21
Figura 2: Modelo en espiral ....................................................................................... 23
Figura 3: Modelo evolutivo ........................................................................................ 24
Figura 4: Modelo RUP ............................................................................................... 25
Figura 5: Modelo SCRUM ......................................................................................... 27
Figura 6: Diagrama de actividades del proceso actual .............................................. 31
Figura 7: Logo de JAVA 2SE..................................................................................... 33
Figura 8: Logo de MySQL ......................................................................................... 33
Figura 9: Mapa de navegacin .................................................................................. 34
Figura 10: Diagrama de casos de uso del sistema.................................................... 35
Figura 11: Modelo entidad relacin ........................................................................... 36
Figura 12: Creacin del proyecto .............................................................................. 37
Figura 13: Creacin de un nuevo formulario ............................................................. 38
Figura 14: EDT del proyecto...................................................................................... 41
Figura 15: Cronograma de actividades ..................................................................... 44
Figura 16: Organigrama ............................................................................................ 45
Figura 17: Distribucin de la informacin .................................................................. 50

INDICE DE TABLAS

Tabla 1: Datos de la base de datos ........................................................................... 39

Tabla 2: Definicin de actividades ............................................................................. 42
Tabla 3: Sueldos y salarios ....................................................................................... 48
Tabla 4: Interesados.................................................................................................. 49
Tabla 5: Matriz de calidad ......................................................................................... 54
Tabla 6: Matriz de riesgos ......................................................................................... 56
Tabla 7: Identificacin de los riesgos ........................................................................ 56
Tabla 8: compras y adquisiciones ............................................................................. 57
Tabla 9: estimacin de costos de materiales............................................................. 59
Tabla 10: Estimacin de costos de insumos ............................................................. 60
Tabla 11: Estimacin de costos de servicios ............................................................. 61
Tabla 12: Estimacin de costos de personal ............................................................. 62
Tabla 13: costos generales ....................................................................................... 63

1. INTRODUCCION

Este proyecto trata sobre el desarrollo de un sistema de inventario para la abarrotera

DEYA, cabe mencionar que la abarrotera no cuanta con un sistema de inventario y
es necesario para su mejor administracin en su almacn.
Por inventario se define al registro total de los bienes y dems cosas pertenecientes
a una persona o comunidad, hecho con orden y precisin. Por extensin, se
denomina inventario a la comprobacin y recuento, de las existencias fsicas en s
mismas y/o con las tericas documentadas.
Con el fin de registrar y controlar los inventarios, las empresas adoptan los sistemas
pertinentes para evaluar sus carencias de mercancas con el fin de fijar su posible
masa de produccin y regateo, Comprender el concepto, caractersticas y los
fundamentos de los sistemas de embarcacin de inventarios puede ser de gran
utilidad para la empresa, ya que son estos lo que realmente fijan el punto de
produccin que se pueda tener en un periodo. El administrador financiero debe tener
la informacin pertinente que le permita tomar decisiones sobre el manejo que se le
debe dar a este rubro del activo organizacional. En el campo de la gestin
empresarial, el inventario registra el conjunto de todos los bienes propios y
disponibles para la venta a los clientes, considerados como activo corriente. Los
bienes de una entidad empresarial que son objeto de inventario son las existencias
que se destinan a la venta directa o aquellas destinadas internamente al proceso
productivo como materias primas, productos inacabados, materiales de embalaje o
envasado y piezas de recambio para mantenimiento que se consuman en el ciclo de
operaciones.
Este proyecto consta de nueve captulos:
El primer captulo es la introduccin en donde se hablara a grandes rasgos de lo que
es el proyecto.

El segundo captulo es de antecedentes en donde delinearemos los antecedentes de

la empresa y entendamos un poco los requerimientos de la empresa para el sistema.
El tercer captulo es la justificacin en donde plasmaremos las razones por las cuales
se lleva a cabo dicho proyecto.
El cuarto captulo es el marco terico en donde explicaremos un poco la teora de lo
que es un sistema de inventarios, leguajes de programacin, modelos de desarrollo,
manejadores de base de datos entre otros conceptos bsicos para el entendimiento
pleno del proyecto.
El quinto captulo son los objetivos tanto general como especficos, en este captulo
explicaremos detalladamente cual es el objetivo del proyecto y las tareas principales
que se realizaran.
El sexto captulo es metodologa, en donde explicaremos que metodologa
utilizaremos para realizar el proyecto, en este caso la metodologa a utilizar es el
PMBOK, en este captulo se desglosara cada una de las gestiones del PMBOK
relacionadas claro a nuestro proyecto.
El sptimo captulo es anlisis de resultados, en este captulo se especificara si los
resultados del proyecto han sido los esperados.
El octavo captulo son las conclusiones y las recomendaciones en donde se
especificara recomendaciones sobre el proyecto realizado y las conclusiones a las
que llegamos al concluir el proyecto.
El noveno y ultimo capitulo es las fuentes consultadas que es simplemente
proporcionar las bibliografas de las fuentes que se consultaron a lo largo de la
realizacin del proyecto.

2. ANTECEDENTES

La abarrotera DEYA necesita un control de inventario para su almacn ya que sus

sucursales han crecido y han aumentado en nmero necesita tener un mejor control
de su almacn.

Nosotros buscamos que esta abarrotera que no cuenta con un sistema de inventario
en uso, que posiblemente, no tengan un control o si lo tiene solo lo tengan en papel,
u otros mtodos rudimentarios que no son muy efectivos y que ocasionan perdidas al
negocio o empresa, de esta manera se creara

este sistema para ofrecerles un

respaldo de confianza, al tener un control total de los productos que se tienen en

almacn.

10

3. JUSTIFICACION

La idea de este proyecto surge ante la necesidad de esta abarrotera, ellos tienen un
sistema antigua a base de libros y formatos para la entrega y recepcin de
mercanca y tambin para las salidas, aparte de los libros, tambin se lleva un
pequeo control en una hoja de datos de Excel pero no es suficiente.

Por esta causa se tom la decisin de empezar este proyecto ya que por la
expansin y crecimiento de la abarrotera se necesita un sistema de inventario claro y
fcil de usar para una buena administracin del almacn de la abarrotera.

11

4. MARCO TEORICO

4.1

FUNDAMENTOS TERICOS

4.1.1 PMBOK
Desarrollada por el Project Management Institute (PMI), la Gua del PMBOK es
el conjunto de conocimientos en Direccin/Gestin/Administracin de Proyectos
generalmente reconocidos como buenas prcticas, y que se constituye como
estndar de Administracin de proyectos. La Gua PMBOK comprende dos
grandes secciones, la primera sobre los procesos y contextos de un proyecto, la
segunda sobre las reas de conocimientos especficos para la gestin de un
proyecto.
El modelo propuesto por el PMI para la ejecucin de proyectos plantea la
aplicacin de herramientas y tcnicas (componentes base en la estructura
seguida por el PMBOK) a lo largo del ciclo de vida del proyecto, las cuales se
encuentran enmarcadas en Procesos, que a su vez conforman Macro-procesos.
Adicionalmente, en un proyecto existen una serie de aspectos o aristas a
considerar, los cuales en su conjunto proporcionan una visin de 360 en la
direccin del proyecto. Estos aspectos se agrupan y denominan reas de
Conocimientos, incluyen: Integracin, Alcance, Tiempo, Costo, Calidad, Recursos
Humanos, Comunicacin, Riesgo, Procura y Stakeholder. El PMI en su ltima
actualizacin a la norma incluy la Atencin a los Stakeholder como una nueva
rea de Conocimiento. En la versin anterior el manejo de los Stakeholders
formaba parte del rea de conocimiento Comunicacin.
Existe un cruce entre los Macro-procesos y las reas de Conocimiento, es decir,
en cada Macro-proceso (Inicio, Planificacin, Ejecucin, Seguimiento/Control y
Cierre) se encuentran aspectos relacionados con la Integracin, Alcance, Tiempo,

12

Costo,

Calidad,

Recursos

Humanos,

Comunicacin,

Riesgo,

Procura

Stakeholders que deben ser atendidos.

En 1987, el PMI public la primera edicin del PMBOK en un intento por
documentar y estandarizar informacin y prcticas generalmente aceptadas en la
gestin de proyectos. La edicin actual, la quinta, provee referencias bsicas a
cualquiera que est interesado en la gestin de proyectos. Posee un lxico
comn y una estructura consistente para el campo de la gestin de proyectos.
Otros Cuerpos del Conocimiento de la Gestin de Proyectos han sido
desarrollados. Por ejemplo, en Inglaterra, el APMBOK de la Association for
Project Management (APM), en Europa, las Competencias de lnea de base de la
International Project Management Association (IPMA), que rene a miembros de
por lo menos 43 pases de varios continentes, y en Japn, el P2M: A guidebook
for project and program management for enterprise innovation de la Engineering
Advancement Association of Japan (ENNA).

4.1.2 Lenguajes de programacin

C
Creado en 1972 por Dennis MacAlistair Ritchie en los laboratorios Bell como
evolucin del anterior lenguaje B. Es un lenguaje orientado a la implementacin
de sistemas operativos, concretamente Unix que fue desarrollado en C.
Es un lenguaje de propsito general muy utilizado cuyas principales
caractersticas son:

Combina caractersticas de los lenguajes de bajo nivel con los de alto nivel,
lo que permite crear programas eficientes.

Es un lenguaje pequeo ya que slo ofrece sentencias de control sencillas

y funciones.

13

Permite la programacin estructurada y el diseo modular lo que mejora la

apariencia, comprensin y mantenimiento de los programas.

Se realizan programas portables que se pueden ejecutar sin necesidad de

realizar cambios en diversas computadoras.

Incluye la utilizacin de punteros. Un puntero es una variable que apunta

(contiene) a la direccin de memoria de otra variable.

Modularidad, el programa se puede dividir en mdulos que se tratan de

manera independiente.

Todo programador sabe programar en C debido a que es uno de los primeros

lenguajes que se aprenden a utilizar. El motivo de que sea uno de los primeros es
porque varios lenguajes de programacin estn formados a partir de C y es
necesario conocer sus estructuras e instrucciones.
El lenguaje C es uno de los ms utilizados en la actualidad ya que nos permite
crear programas eficientes, caracterstica muy importante a la hora de realizar un
programa. Es un lenguaje simple y fcil de entender, lo que reduce los tiempos
de desarrollo y comprensin de los programas.
Por ltimo decir que es muy comn programar sistemas en C ya que nos permite
tener un control casi absoluto de la computadora.

C++
El lenguaje de programacin surgi a mediados de los 80 gracias a Bjarne
Stroustrup y fue desarrollado a partir del lenguaje C en los laboratorios AT&T Bell.
Es un lenguaje orientado a objetos aunque tambin tiene las mismas
caractersticas que C, como por ejemplo su eficiencia y el uso de punteros.
Como es lgico, y debido a que se cre a partir de C, C++ cuenta con diversas
mejoras y avances respecto de C, lo que le hace un lenguaje ms completo y por
ello que los programadores tienden a programar ms en este lenguaje. Un
14

programa en C++ soporta instrucciones escritas en C, pero un programa escrito

en C no nos permite ejecutar instrucciones de C++, por lo que vindolo de sta
forma resulta ms cmodo programar en C++.
Es un lenguaje muy popular debido a la eficiencia y robustez de sus programas.
Adems de ser un lenguaje orientado a objetos, tambin nos permite realizar
programas estructurados, lo cul nos da libertad a la hora de programar. Nos da
cierta libertad debido a que no es tan estricto a la hora de escribir cdigo como en
C.
Es un lenguaje compilado, es decir, compila directamente al cdigo que entienden
los ordenadores por lo que es uno de los lenguajes ms rpidos.
Es portable al gran nmero de compiladores que permiten utilizar los programas
en diversas computadoras con diferentes sistemas operativos.
Soporta varios paradigmas de programacin. Un paradigma de programacin
(dicho de manera informal) es una forma de pensar a la hora de programar, el
ms utilizado es el paradigma de programacin orientada a objetos.
Un aspecto importante a destacar es la amplia cantidad de manuales, libros y
cdigo fuente disponibles sobre C++, lo que nos da ciertas facilidades a la hora
de aprender a programarlo.

Java
Surgi en 1991 gracias a un grupo de ingenieros de Sun Microsystems como
lenguaje de programacin para electrodomsticos.
Fue en 1995 cuando Java comenz a utilizarse como lenguaje de programacin
de computadoras.
Las caractersticas ms importantes de este lenguaje de programacin son:

15

Es un lenguaje orientado a objetos. Un objeto se compone de atributos

(estado del objeto) y mtodos (comportamiento) que actan sobre esos
atributos. Para comprender lo que es un objeto, voy a mostrarles una
analoga del mundo real: al igual que en el mundo virtual, en el mundo real
los objetos tienen un estado y un comportamiento. Por ejemplo, un coche
es un objeto que tiene una serie de estados o atributos (matrcula, marca,
modelo, color, marchas) y una serie de comportamientos o mtodos
(corriendo, parado, aparcando, cambio de marcha). Todos los objetos
tienen un identificador nico que los diferencia del resto de objetos. En el
ejemplo anterior el identificador del coche es la matrcula.

Modularidad, nos permite dividir los programas en pequeos mdulos

denominados clases, para reducir la complejidad del problema y, en caso
de producirse un fallo, ste solamente afecta al mdulo donde se produjo y
no a todo el programa.

Es robusto, es decir, es un lenguaje de programacin fiable que reacciona

adecuadamente ante situaciones excepcionales.

Es un lenguaje de programacin portable que nos permite utilizar los

programas desarrollados en java en cualquier ordenador con cualquier
sistema operativo.

Dinmico, podemos compilar y ejecutar los programas en tiempo real.

Seguro, elimina los accesos ilegales a memoria que realizan los punteros
en C.

En definitiva, Java es uno de los lenguajes ms utilizados actualmente ya que

podemos reutilizar el cdigo de los programas y su arquitectura neutral nos
permite

utilizarlo

en

cualquier

arquitectura

sistema

operativo

independientemente de la mquina en que se realiz el programa.

Es un lenguaje fcil de aprender lo que reduce los tiempos de formacin y
aprendizaje de las personas que lo vayan a utilizar.

16

Las perspectivas de futuro son que prcticamente toda la programacin ser

orientada a objetos, aspecto con el que ya cuenta Java y permite acercarnos a la
forma de pensar de las personas.
Actualmente Java cuenta con diversos entornos de desarrollo muy buenos como
son Netbeans o Eclipse..

4.1.3 Manejadores de base de datos

Bases de datos
Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con
la abreviatura B. D.) es un conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemticamente para su posterior uso. En este sentido, una biblioteca
puede considerarse una base de datos compuesta en su mayora por documentos y
textos impresos en papel e indexados para su consulta. En la actualidad, y debido al
desarrollo tecnolgico de campos como la informtica y la electrnica, la mayora de
las bases de datos estn en formato digital (electrnico), que ofrece un amplio rango
de soluciones al problema de almacenar datos.
Existen programas denominados sistemas gestores de bases de datos, abreviados
SGBD, que permiten almacenar y posteriormente acceder a los datos de forma
rpida y estructurada. Las propiedades de estos SGBD, as como su utilizacin y
administracin, se estudian dentro del mbito de la informtica.
Las aplicaciones ms usuales son para la gestin de empresas e instituciones
pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto
de almacenar la informacin experimental.
Aunque las bases de datos pueden contener muchos tipos de datos, algunos de ellos
se encuentran protegidos por las leyes de varios pases. Por ejemplo, en Espaa los
datos personales se encuentran protegidos por la Ley Orgnica de Proteccin de
Datos de Carcter Personal (LOPD).
17

Bases de datos orientadas a objetos

Este modelo, bastante reciente, y propio de los modelos informticos orientados a
objetos, trata de almacenar en la base de datos losobjetos completos (estado y
comportamiento).
Una base de datos orientada a objetos es una base de datos que incorpora todos los
conceptos importantes del paradigma de objetos:

Encapsulacin - Propiedad que permite ocultar la informacin al resto de los

objetos, impidiendo as accesos incorrectos o conflictos.

Herencia - Propiedad a travs de la cual los objetos heredan comportamiento

dentro de una jerarqua de clases.

Polimorfismo - Propiedad de una operacin mediante la cual puede ser

aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones

sobre los datos como parte de la definicin de la base de datos. Una operacin
(llamada funcin) se especifica en dos partes. La interfaz (o signatura) de una
operacin incluye el nombre de la operacin y los tipos de datos de sus argumentos
(o parmetros). La implementacin (o mtodo) de la operacin se especifica
separadamente y puede modificarse sin afectar la interfaz. Los programas de
aplicacin de los usuarios pueden operar sobre los datos invocando a dichas
operaciones a travs de sus nombres y argumentos, sea cual sea la forma en la que
se han implementado. Esto podra denominarse independencia entre programas y
operaciones.

Bases de datos relacionales

ste es el modelo utilizado en la actualidad para modelar problemas reales y
administrar datos dinmicamente. Tras ser postulados sus fundamentos en 1970 por
Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en
consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea
18

fundamental es el uso de "relaciones". Estas relaciones podran considerarse en

forma lgica como conjuntos de datos llamados "tuplas". Pese a que sta es la teora
de las bases de datos relacionales creadas por Codd, la mayora de las veces se
conceptualiza de una manera ms fcil de imaginar. Esto es pensando en cada
relacin como si fuese una tabla que est compuesta por registros (las filas de una
tabla), que representaran las tuplas, y campos (las columnas de una tabla).
En este modelo, el lugar y la forma en que se almacenen los datos no tienen
relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene
la considerable ventaja de que es ms fcil de entender y de utilizar para un usuario
espordico de la base de datos. La informacin puede ser recuperada o almacenada
mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la
informacin.
El lenguaje ms habitual para construir las consultas a bases de datos relacionales
es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un
estndar implementado por los principales motores o sistemas de gestin de bases
de datos relacionales.
Durante su diseo, una base de datos relacional pasa por un proceso al que se le
conoce como normalizacin de una base de datos.
Durante los aos 80 la aparicin de dBASE produjo una revolucin en los lenguajes
de programacin y sistemas de administracin de datos. Aunque nunca debe
olvidarse que dBase no utilizaba SQL como lenguaje base para su gestin.

Gestin de bases de datos

Los sistemas de gestin de bases de datos (en ingls database management
system, abreviado DBMS) son un tipo de software muy especfico, dedicado a servir
de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.

19

Gestin de bases de datos distribuida (SGBDD)

La base de datos y el software SGBD pueden estar distribuidos en mltiples sitios
conectados por una red. Hay de dos tipos: 1. Distribuidos homogneos: utilizan el
mismo SGBD en mltiples sitios. 2. Distribuidos heterogneos: Da lugar a los SGBD
federados o sistemas multibase de datos en los que los SGBD participantes tienen
cierto grado de autonoma local y tienen acceso a varias bases de datos autnomas
preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura
cliente-servidor. Estas surgen debido a la existencia fsica de organismos
descentralizados. Esto les da la capacidad de unir las bases de datos de cada
localidad y acceder as a distintas universidades, sucursales de tiendas, etctera.

4.1.4 Modelos de desarrollo de software

Modelo en cascada
Modelo en Cascada (Winston W. Royce en 1970 y posteriormente revisada por Barry
Boehm en 1980 e Ian Sommerville en 1985)
El modelo de ciclo de vida clsico, tambin denominado "modelo en cascada", se
basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre.
Se pasa, en orden, de una etapa a la siguiente slo tras finalizar con xito las tareas
de verificacin y validacin propias de la etapa. Si resulta necesario, nicamente se
da marcha atrs hasta la fase inmediatamente anterior.
Este modelo tradicional de ciclo de vida exige una aproximacin secuencial al
proceso de desarrollo del software. Por desgracia, esta aproximacin presenta una
serie de graves inconvenientes, entre los que cabe destacar:

Los proyectos reales raramente siguen el flujo secuencial de actividades que

propone este modelo.

Normalmente, es difcil para el cliente establecer explcitamente todos los

requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no
20

vea evolucionar el proyecto no tendr una idea clara de qu es lo que

realmente quiere).

No habr disponible una versin operativa del sistema hasta llegar a las
etapas finales del proyecto, por lo que la rectificacin cualquier decisin
tomada errneamente en las etapas iniciales del proyecto supondr un coste
adicional significativo, tanto econmico como temporal (y eso sin tener en
cuenta la mala impresin causada por un retraso en la fecha de entrega).

Figura 1: Fases del modelo cascada

Por lo cual a lo que se recurre es a generar un prototipo:

Recoleccin y refinamiento de requisitos.

Diseo rpido.

Construccin del prototipo.

Evaluacin.

Desarrollo del producto.

21

Modelo Iterativos
En 1994, el Departamento de Defensa de Estados Unidos (el mayor contratista
mundial de proyectos de desarrollo de software) cambi oficialmente sus estndares
de desarrollo de software y descart el modelo en cascada para introducir el
estndar 498, que utiliza un modelo iterativo de desarrollo de software.
Los modelos iterativos consisten en descomponer un proyecto de desarrollo de
software en una serie de subproyectos de menor envergadura. Estos subproyectos
deben disearse de tal forma que cada uno de ellos aporte funcionalidad nueva para
el sistema desde el punto de vista del usuario final del mismo.
Los modelos iterativos de desarrollo de software permiten adelantar el momento en
el que se determina si un proyecto es tcnicamente viable o no (con lo que se
eliminan costes innecesarios si, finalmente, el proyecto hubiese de cancelarse).
Tambin promueven una mejor comunicacin con el usuario/cliente, ya que se
dispondr antes de una versin operativa del sistetma, aunque sea de funcionalidad
reducida. Estas versiones intermedias del producto ayudan a la eliminacin de
malentendidos que pueden surgir en la etapa de elicitacin de requerimientos.
Adems, ayudan a que el usuario se forme una idea ms clara de lo que realmente
necesita.

Modelo en Espiral (Barry Boehm en 1986)

El modelo en espiral de Barry Boehm hace especial hincapi en la prevencin de
riesgos. Este modelo define cuatro actividades principales: planificacin (determinar
los objetivos, alternativas y restricciones del proyecto), anlisis de riesgos (anlisis
de alternativas e identificacin/resolucin de riesgos), ingeniera (desarrollo del
producto) y evaluacin (revisin por parte del cliente y valoracin de los resultados
obtenidos de cara a la siguiente iteracin). En cada iteracin alrededor de la espiral
se construyen versiones cada vez ms completas del software.
22

Figura 2: Modelo en espiral

Modelo Evolutivo
Los modelos evolutivos (como el modelo Evo de Tom Gilb o los modelos giles
populares hoy en da, entre los que se encuentra la auto-denominada programacin
extrema) se caracterizan por realizar entregas por etapas del sistema. Usualmente,
el proyecto se descompone en iteraciones de longitud fija (de 1 a 6 semanas) y cada
iteracin ha de proporcionar algn aspecto completo de la funcionalidad del sistema.
Cada ciclo se concentra en las funciones de mayor valor aadido. De esta forma, si
se cancelase el proyecto en cualquier momento, el usuario siempre tendr lo mximo
que se puede conseguir con los recursos invertidos hasta el momento. Igualmente,
se puede prorrogar el proyecto si se considera interesante seguir aadindole
funcionalidad al proyecto.

23

Figura 3: Modelo evolutivo

Modelo CMMI
El modelo CMMI (Capability Maturity Model - Integrated, propuesto por el Instituto de
Ingeniera del Software de la Universidad de Carnegie-Mellon) identifica una serie de
reas clave en trminos de objetivos especficos y prcticas necesarias para lograr
esos objetivos. Los objetivos establecen las caractersticas que el proceso de
desarrollo de software debe tener para que las actividades de cada rea puedan ser
efectivas. En cierto sentido, CMMI viene a ser como una certificacin de calidad ISO
9000 adaptada a proyectos de desarrollo de software. Una certificacin de este tipo
puede ayudar a conseguir determinados tipos de proyectos (gubernamentales,
principalmente), si bien slo garantiza que el proyecto se realiza siguiendo un
proceso definido, no que las distintas tareas se realicen correctamente.
De hecho, el proceso puede estar perfectamente definido y "certificado" sin ser el
proceso adecuado para el proyecto que tengamos entre manos.
El Modelo Tiene 4 reas de conocimiento:

Ingeniera de Software (SW)

Ingeniera de Sistemas (SE)

Desarrollo Integrado de Productos y Procesos (IPPD)

Acuerdos con Proveedores (SS)

24

Modelo RUP
El Proceso Unificado de Rational (RUP, Rational Unified Process, propuesto
originalmente por una empresa llamada Rational Software Corporation que hoy es
una divisin de IBM) describe un marco adaptable para procesos iterativos de
desarrollo de software. El ciclo de vida de un proyecto RUP se divide en ciclos de
desarrollo individuales que, a su vez, se descomponen en cuatro fases principales
(incepcin, elaboracin, construccin y transicin). Para cada una de estas fases,
RUP identifica qu disciplinas (actividades) son las ms relevantes. Finalmente, en
un proyecto concreto cada fase viene definida por una serie de objetivos y se
descompone en iteraciones de duracin fija.

Figura 4: Modelo RUP

Inicio (Inception): El objetivo general de esta fase es establecer un acuerdo entre

todos los interesados acerca de los objetivos del proyecto. Es significativamente
importante para el desarrollo de nuevo software, ya que se asegura de identificar los
riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de
software existente, esta fase es ms breve y se centra en asegurar la viabilidad de
desarrollar el proyecto.
25

Elaboracin: El objetivo en esta fase es establecer la arquitectura base del sistema

para proveer bases estables para el esfuerzo de diseo e implementacin en la
siguiente fase. La arquitectura debe abarcar todas las consideraciones de mayor
importancia de los requerimientos y una evaluacin del riesgo.
Construccin:El objetivo de la fase de construccin es clarificar los requerimientos
faltantes y completar el desarrollo del sistema basados en la arquitectura base. Vista
de cierta forma esta fase es un proceso de manufactura, en el cual el nfasis se
torna hacia la administracin de recursos y control de la operaciones para optimizar
costos, tiempo y calidad.
Transicin: Esta fase se enfoca en asegurar que el software est disponible para sus
usuarios. Se puede subdividir en varias iteraciones, adems incluye pruebas del
producto para poder hacer el entregable del mismo, as como realizar ajuste menores
de acuerdo a ajuste menores propuestos por el usuario. En este punto, la
retroalimentacin de los usuarios se centra en depurar el producto, configuraciones,
instalacin y aspectos sobre utilizacin.

Modelo SCRUM (Scrum Development Process)

Scrum es un modelo de desarrollo gil caracterizado por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y

ejecucin completa del producto.

Basar la calidad del resultado ms en el conocimiento tcito de las personas

en equipos autoorganizados, que en la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una

tras otra en un ciclo secuencial o de cascada.

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a
principios de los 80, al analizar cmo desarrollaban los nuevos productos las
principales empresas de manufactura tecnolgica: Fuji-Xerox, Canon, Honda, Nec,

26

Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product
Development Game, 1986).
Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es
apropiada para proyectos con requisitos inestables y para los que requieren rapidez y
flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de
software.
SCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y
que puede tomarse como punto de partida para definir el proceso de desarrollo que
se ejecutar durante un proyecto. Los roles principales en Scrum son el
ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de
proyecto, el ProductOwner, que representa a los stakeholders (interesados externos
o internos), y el Team que incluye a los desarrolladores.1

Figura 5: Modelo SCRUM

(Antologa Ciclos de vida del software 2013)

27

4.2. MARCO CONTEXTUAL

4.2.1 Nombre de la empresa

Abarrotera DEYA

4.2.2 Misin
Satisfacer las necesidades de productos y servicios de las comunidades donde
estamos presentes, fomentando en cada uno de nosotros nuestra filosofa y valores
para asegurar una relacin permanente y valiosa con nuestros clientes,
colaboradores, proveedores, accionistas, comunidad y medio ambiente, obteniendo
de esta manera una adecuada rentabilidad y garantizando as nuestra permanencia y
crecimiento.

4.2.3 Visin
Servir cada vez a un mayor nmero de comunidades como lder, al ofrecer la mejor
experiencia de compra para el cliente y el mejor lugar para trabajar para nuestros
colaboradores, derivado de una constante innovacin.

28

5. OBJETIVOS

5.1. OBJETIVO GENERAL

Disear un sistema de inventario para la abarrotera Mi Changarrito, en donde se
cree una base de datos y una interfaz que sea amigable con el usuario y ayude a la
administracin de la abarrotera.

5.2. OBJETIVOS ESPECFICOS

Disear las interfaces de login, registrar usuario, agregar un nuevo producto,

contar existencias, consultar producto.

Crear una base de datos para la buena administracin del almacn de la

abarrotera.

Programar todas las interfaces del sistema de inventario de la abarrotera.

Hacer la conexin a la base de datos y las interfaces del sistema.

Tener un sistema de inventario para la abarrotera Mi Changarrito.

29

6. METODOLOGA

6.1. GESTIN DE INTEGRACIN

6.1.1 Desarrollo del proyecto

En este apartado del proyecto se explicara paso a paso el desarrollo del
proyecto y la manera en cmo se fue haciendo.

6.1.1.1 Anlisis
El anlisis del proyecto consiste en verificar como se realizan los procesos en la
empresa actualmente, y de esta manera podremos detectar las necesidades de
la empresa y ofrecer un producto que cumpla con todos los requerimientos de la
empresa.

Descripcin del sistema actual

Actualmente la empresa no cuenta con una informacin que lleve a cabo la
generacin de un inventario, todo se hace a travs de una hoja de clculo donde
se realiza la captura de la informacin diariamente generando una bitcora que
desenfoca en un proceso demasiado tedioso.

30

Diagrama de procesos del sistema actual

Figura 6: Diagrama de actividades del proceso actual

Deteccin de problemas y necesidades

Los problemas: Errores al realizar la doble captura de la informacin, lo que
conlleva a una duplicidad de informacin incompleta, ya que los encargados de
proporcionar los datos en tiempo y forma.

31

Las necesidades: Disear una aplicacin cliente /servidor en la que la captura de

la informacin se realice de manera sencilla, para que a su vez se puedan
obtener un inventario preciso y actualizaciones de los datos en tiempo y forma.

Alternativa de solucin
Desarrollar un sistema de informacin que permita llevar un control de fallos que
se presentan en un inventario. La aplicacin debe exportar dichos reportes en
archivos Excel y a partir de los datos obtenidos.

El diseo de este nuevo sistema de informacin promete dar respuesta y

solucin a los problemas antes mencionados, ya que con l se busca
agilizar la realizacin de un inventario, generacin del historial y mostrar de
manera errnea y obtenidos en diferentes periodos de tiempo (das, semanas,
meses), la empresa a la que ms reportes se les haya enviado y con

ms

inconsistencia presentaron.

El Sistema incluir:
Inicio de Sesin
Catlogos

Lenguaje a utilizar

NetBeans IDE es un entorno de desarrollo - una herramienta para que los

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

32

Figura 7: Logo de JAVA 2SE

DMBS a utilizar

El DBMS a utilizar para el almacenamiento de la Informacin del Sistema es

MYSQL. Ya que es un sistema de gestin de bases de datos relacional,
multihilo y multiusuario. Su popularidad como aplicacin web est muy ligada
a PHP, que a menudo aparece en combinacin con MySQL. MySQL es una
base de datos muy rpida en la lectura cuando utiliza el motor no transaccional
MyISAM, pero puede provocar problemas de integridad en entornos de alta
concurrencia en la modificacin. En aplicaciones web hay baja concurrencia en
la modificacin de datos y en cambio el entorno es intensivo en lectura de datos,
lo que hace a MySQL ideal para este tipo de aplicaciones. Sea cual sea el
entorno en el que va a utilizar MySQL, es importante adelantar monitoreo sobre
el desempeo pa ra detectar y corregir errores tanto de SQL como de
programacin.

Figura 8: Logo de MySQL

33

6.1.1.2 Diseo
Mapa de navegacin

OPCIONES DE
USUARIO
USUARIO

PUESTO

EQUIPO

DEPARTAMENT
O
ALTA

PRINCIPAL

IMPRESORAS

ACTUALIZACION
BAJA
ALTA

LOGIN

PRINCIPAL

PROCESOS

DISPOSITIVOS

ACTUALIZACION

ASIGNACION

BAJA

ACTUALIZACION
DE ASIGNACION
MODELO
MARCA
RESPONSIVA

REPORTES

STATUS DE LOS
RECURSOS
ASIGNACIONES

SALIR

Figura 9: Mapa de navegacin

34

CERRAR

Diagrama de casos de uso

Figura 10: Diagrama de casos de uso del sistema

35

Diseo de la base de datos (Modelo E-R)

Figura 11: Modelo entidad relacin

6.1.1.3 Desarrollo
Desarrollo de las interfaces
Para la creacin de una de las pantallas de la aplicacin se necesitan ciertos
factores que son de mucha importancia. Se utiliz el IDE Netsbeans 7.2 para el
diseo y programacin de todas las pantallas y formularios de la aplicacin.

La creacin del formulario principal de la aplicacin y de las dems pantallas fue

de la siguiente manera:

36

Se abri el Netbeans Archivo->Nuevo Proyecto-> y se seleccion Java->Java

Application.

Figura 12: Creacin del proyecto

37

Figura 13: Creacin de un nuevo formulario

Creacin de la base de datos

Nombre campo
id_acceso
fk_usuario
username
password
Nombre campo
id_usuario
fk_departamento
fk_puesto
nombre_usuario
ap_usuario
am_usuario
foto_usuario
Nombre campo
id_departamento

TABLA ACCESO
Tipo
tamao PK FK
Int
10 x
Int
10
x
Varchar
50
Varchar
50
TABLA USUARIO
Tipo
tamao PK FK
Int
10 x

DESCRICPIN
identificador de Tabla
identificador de Tabla usuario
Usuario
Contrasea
DESCRICPIN
identificador de Tabla
identificador de Tabla
departamento
identificador de Tabla puesto
Nombre
Paterno
Materno
Foto

Int
10
x
Int
10
x
Varchar
50
Varchar
50
Varchar
50
Varchar
200
TABLA DEPARTAMENTO
Tipo
tamao PK FK DESCRICPIN
x
identificador de Tabla
38

nombre_departamento
descripcion_departamento
Nombre campo
id_puesto
nombre_puesto
descripcion_puesto
Nombre campo
id_marca
nombre_marca
descripcion_marca

Tipo

TABLA PUESTO
tamao PK FK DESCRICPIN
x
identificador de Tabla

Tipo

TABLA MARCA
tamao PK FK DESCRICPIN
x
identificador de Tabla

Tabla 1: Datos de la base de datos

39

6.2 GESTIN DE ALCANCE

6.2.1 Acta constitutiva
En la ciudad Villahermosa, Tabasco a los 15 das del mes de mayo del ao dos
mil catorce, que presenta la C. Yarely Anahi Snchez Villegas el acta constitutiva
del proyecto Anlisis y Diseo de un Sistema de Inventario para la Abarrotera
DEYA en este documentos se le llamara a la C. Yarely Anahi Snchez Villegas
como administrador y a la empresa se le referir como el cliente.

A. Antecedentes.- Nuestra empresa se dedica al desarrollo de software, y en

este caso en particular pretende crear un sistema de inventario y punto de
venta para facilitar la administracin a las empresas que lo requieran.

B. Justificacin del proyecto.- El sistema de inventario y el punto de venta es

una herramienta indispensable pata el control de la mercanca y las ventas
realizadas en la empresa.

C. Requisitos del sistema.- El sistemas de inventario contara con varios

mdulos, uno de ellos ser la consulta de los productos en donde mostrara la
informacin del producto como el nombre, el cdigo, la existencia, la cantidad
de mercanca que va a llegar, el precio al pblico, el precio al costo, el
proveedor, los das de visita del proveedor. Otro modulo ser el de agregar un
nuevo producto, y el de eliminar un producto existente.

______________________________

__________________________

T.S.U. Yarely Anahi Snchez Villegas

Representante Abarrotera DEYA

40

6.2.2 Definicin del alcance

Este proyecto es un sistema de inventario en el cual los administradores de la
abarrotera tendrn un control absoluto de los almacenes de sus diferentes
sucursales, de esta manera podr tener control de los productos, podr dar entrada y
salida a los productos cambiar el precio, otros usuarios solo podrn ver la cantidad
de producto que existe en almacn, y el sistema de punto de venta ya en
funcionamiento estar conectado a la base de datos de inventarios para que cada
que se venda un producto sume los precios y descuente los productos del stock de
almacn que se hayan vendido.

6.2.3 EDT

Figura 14: EDT del proyecto

41

6.3. GESTIN DE TIEMPO

6.3.1 Definicin de las actividades
Actividad
Anlisis

Proceso
Deteccin de necesidades
Lenguaje a utilizar
DMBS a utilizar

Diseo

Diseo de las interfaces

Diseo de la base de datos

Desarrollo

Programacin de las interfaces

Creacin de la base de datos
Conexin
Tabla 2: Definicin de actividades

6.3.2. Establecimiento de la secuencia de actividades

1. Anlisis
2. Diseo
3. Desarrollo

42

6.3.3. Estimacin de los recursos de actividades

Los recursos a utilizar son:

Computadoras (Lap Top)

Netbens

SQL

Impresoras

Tinta

Papel

Scanner

Copiadora

Lapiceros

Libretas

6.3.4 Estimacin de la duracin de las actividades

1. Anlisis 15 das
2. Diseo 30 das
3. Desarrollo 30 das

43

6.3.5. Desarrollo del cronograma

Figura 15: Cronograma de actividades

44

6.4. GESTIN DE RECURSOS HUMANOS

6.4.1. Organigrama del proyecto

Figura 16: Organigrama

6.4.2. Roles y responsabilidades

-----Director----Funciones: Definir los objetivos del proyecto, manejar los recursos, ajustarse al
presupuesto, administrar los costos, administrar la calidad del proyecto, gestionar los
plazos, garantizar que la informacin fluya entre el personal necesario, analizar y
manejar los riesgos, manejar el recurso humano, negociar con proveedores, hacer un
seguimiento oportuno.
Formacin: Lic. Sistemas o afn.

45

Perfil: Conocimiento en el rea de TI, manejo adecuado del personal, excelente

presentacin.
Experiencia: Minina de 1 ao en el puesto

-----Jefe de rea----Funciones: Este ser el jefe directo del analista, el diseador y el programador; y
responder, entregara informes de avances y problemticas al director.
Formacin: Licenciatura o ingeniera en informtica o afn.
Perfil: Responsable, proactivo, buena comunicacin, comprometido con su trabajo,
conocimiento en C#, SQL.
Experiencia: Mnima de un ao

-----Analista----Funciones: Analizar los requerimientos del proyecto, y as formar parte del diseo y
la programacin del software.
Formacin: Licenciatura o ingeniera en informtica o afn.
Perfil: Responsable, proactivo, buena comunicacin, comprometido con su trabajo,
conocimiento en C#, SQL.
Experiencia: Mnima de un ao

-----Diseador----Funciones: Disear la interfaz del software con las herramientas necesarias y

disponibles.

46

Formacin: Licenciatura o ingeniera en informtica o afn.

Perfil: Responsable, proactivo, buena comunicacin, comprometido con su trabajo,
conocimiento en C#, SQL.
Experiencia: Mnima de un ao.

-----Programador----Funciones: Crear el cdigo y la base de datos del software.

Formacin: Licenciatura o ingeniera en informtica o afn.
Perfil: Responsable, proactivo, buena comunicacin, comprometido con su trabajo,
conocimiento en C#, SQL.
Experiencia: Mnima de un ao.

6.4.3. Plan de recursos humanos

Formas de contratacin
El contrato de los empleados ser por el tiempo que el proyecto dure, los pagos
sern quincenales, y en caso de que se requiera una ampliacin del contrato se les
avisara a los empleados con anticipacin.

Plan de crecimiento
Todos los empleados sern evaluados al final del proyecto, y segn su evaluacin
podrn tener una bonificacin extra econmica y/o seguir participando en los
siguientes proyectos.

47

Liderazgo
Nuestro administrador de proyecto debe ser un lder que comunique a sus
empleados lo que sucede y que tome en cuenta las necesidades de sus empleados,
todo esto para tener un ambiente laboral apto y que el proyecto salga excelente.

Sueldos y salarios
Puesto

Sueldo

Forma de pago

Director

$5,000.00

Quincenal

Jefe de rea

$4,000.00

Quincenal

Analista

$3,000.00

Quincenal

Diseador

$3,000.00

Quincenal

Programador

$3,000.00

Quincenal

Tabla 3: Sueldos y salarios

Capacitacin
Todo el personal ser capacitado antes de empezar el proyecto y las veces que sean
necesarias durante este, para as garantizar a los clientes un personal de excelencia
altamente capacitado en su rea laboral.

48

6.5. GESTIN DE COMUNICACIONES

6.5.1 Identificar interesados
Interesado

Medio de

Frecuencia Formalidad

Tipo

receptor

Junta y

Analista,

reporte

programador,

comunicacin
Director

impreso

Semanal

Formal

diseador
Director

personal

quincenal

Formal

reunin

Cliente

Analista

electrnico

diario

Informal

mensaje

programador,
diseador

Programador

electrnico

Diario

Informal

Mensaje

Analista,
diseador

diseador

Electrnico

Diario

Informal

Mensaje

Programador
y analista

Cliente

Telfono,

Diario

Informal

Mensaje

Director

electrnico
Tabla 4: Interesados

6.5.2 Planificar comunicaciones

Se ha llegado al acuerdo de que las reuniones o juntas para aclarar dudas y distribuir
la informacin necesaria se llevaran a cabo cada semana, los integrantes de estas
juntas sern: el director, los programadores, diseadores y analistas. De esta manera
se podr distribuir la informacin correctamente.

49

6.5.3 Distribuir informacin

Formal
(Quincenal)

Cliente
Informal
(diaria)

Director

Formal
(semanal)

Formal
(semanal)

Programador

Analista
Formal
(semanal)

Formal
(semanal)

Informal
(diaria)

Informal
(diaria)

Diseador

Figura 17: Distribucin de la informacin

6.5.4 Gestionar expectativas

En cada junta realizada se revisara que las actividades vayan de acuerdo al
cronograma de esta manera podremos decir que las expectativas del proyecto son
buenas y todo marcha segn lo planeado.

50

6.5.5 Informar el desempeo

Es de suma importancia que todos los integrantes de las juntas elaboren un reporte
de las actividades que hicieron semanalmente y explicar si sus actividades van de
acuerdo al cronograma que avances o retrasos han tenido y cul fue la causa para
as poder ayudar a resolver los problemas y eficientar el proyecto.

51

6.6. GESTIN DE CALIDAD

6.6.1. Planificacin de la calidad
Norma

Descripcin

Aplicacin

Proceso

ISO 9000

ISO 9000 es un
conjunto de normas
sobre calidad y
gestin de calidad,
establecidas por la
Organizacin
Internacional de
Normalizacin (ISO).
Se pueden aplicar en
cualquier tipo de
organizacin o
actividad orientada a
la produccin de
bienes o servicios. Las
normas recogen tanto
el contenido mnimo
como las guas y
herramientas
especficas de
implantacin como los
mtodos de auditora.
El ISO 9000 especifica
la manera en que una
organizacin opera
sus estndares de
calidad, tiempos de
entrega y niveles de
servicio.

Para establecer,
documentar,
controlar, medir y
mejorar los
procesos y
productos dentro de
la organizacin.

Se utilizara para
mejorar la
documentacin, los
procesos y el
producto final.

Beneficios
-Estandarizar las
actividades del
personal que trabaja
dentro de la
organizacin por
medio de la
documentacin.
-Incrementar la
satisfaccin del cliente
al asegurar la calidad
de productos y
servicios de manera
consistente, dada la
estandarizacin de los
procedimientos y
actividades.
-Medir y monitorear el
desempeo de los
procesos.
Incrementar la eficacia
y/o eficiencia de la
organizacin en el
logro de sus objetivos.
-Mejorar
continuamente en los
procesos, productos,
eficacia, entre otros.
-Reducir las
incidencias negativas
de produccin o
prestacin de
servicios.

ISO 20000

Es el estndar
reconocido
internacionalmente en
gestin de servicios de
TI

Es un estndar
para la Gestin de
servicios de TI.
Provee una gua
para la realizacin
de auditoras y para
la remediacin de
los hallazgos
identificados

52

Se utilizara para
mejorar las
actividades y
controlar su
efectividad, de esta
manera se podrn
definir mejor las
actividades del
proyecto.

-Demuestra que se
tienen procedimientos
y controles adecuados
in situ para
proporcionar un
servicio de calidad de
TI coherente y a un
coste efectivo.
-Los suministradores
de servicios de TI se
han vuelto cada vez
ms sensibles y
responsables con los
servicios que prestan

ms que de la
tecnologa que
puedan proporcionar.
-Los proveedores
externos de servicios
pueden usar la
certificacin como un
elemento
diferenciador y
acceder a nuevos
clientes, ya que esto
cada vez ms se
convierte en una
exigencia contractual.

-Permite seleccionar,
gestionar y
proporcionar un
servicio externo ms
efectivo.
-Ofrece oportunidades
para mejorar la
eficiencia, fiabilidad y
consistencia de sus
servicios de TI que
impactan
positivamente tanto en
los costes como en el
servicio.

ISO 27000
(ISO/IEC
27000:2005)

La serie de normas
ISO/IEC 27000 son
estndares de
seguridad publicados
por la Organizacin
Internacional para la
Estandarizacin (ISO)
y la Comisin
Electrotcnica
Internacional (IEC).

Para establecer,
implementar,
monitorear, revisar,
mantener y mejorar
un Sistema de
Administracin de
Seguridad de
Informacin

La serie contiene las

mejores prcticas
recomendadas en
Seguridad de la
informacin para
desarrollar,
implementar y
mantener
Especificaciones para
los Sistemas de
Gestin de la
Seguridad de la

53

Se utilizara para
establecer.
Implementar,
monitorear, revisar,
mantener y mejorar
la seguridad de la
informacin.

-Cumplimiento
-Ventaja de
comercializacin
-Disminucin de
gastos
-Ordenamiento de su
megocio

Informacin (SGSI).
CMMI (Capability
Maturity Model
Integration)

Integracin de
modelos de madurez
de capacidades o
Capability maturity
model integration
(CMMI) es un modelo
para la mejora y
evaluacin de
procesos para el
desarrollo,
mantenimiento y
operacin de sistemas
de software.

Para mejorar las

actividades de un
proyecto, rea u
organizacin, ya
que proporciona un
marco de referencia
para evaluar la
efectividad de los
procesos actuales,
facilitando con ello
la definicin de
actividades,
prioridades y metas
para garantizar la
mejora continua.

Se utilizara para
gestionar los
servicios, esta
misma norma nos
proporciona una
gua para la
realizacin de
auditoras y para la
remediacin de los
problemas
identificados.

-Mejora la visibilidad
sobre los Proyectos
-Mejora la
comunicacin
-Mejora la
planificacin
-Reduce el Re-trabajo
-Mejora la calidad del
producto
-Conocimiento de la
organizacin
-Mejora el ambiente
de trabajo
-Se genera una Base
de Conocimiento
-Se tiene una visin
compartida
-Un cliente ms
informado

ISO 9126

ISO 9126 es un
estndar internacional
para la evaluacin de
la calidad del software.
Est reemplazado por
el proyecto SQuaRE,
ISO 25000:2005, el
cual sigue los mismos
conceptos.

El estndar ISO
9126 ha sido
desarrollado en un
intento de identificar
los atributos clave
de calidad para el
software. El
estndar identifica 6
atributos clave de
calidad.

Este estndar se
realizara y se
utilizara para la
calidad del software,
esta norma identifica
6 atributos de
calidad.

Tabla 5: Matriz de calidad

54

-funcionalidad
-Confiabilidad
-usabilidad
-eficiencia
-facilidad
-portabilidad.

6.7. GESTIN DE RIESGOS

6.7.1 Planificacin de riesgos
Clave

Actividad

Riesgo

Prevencin

Criterio

R001

Calcular
los costos

Incremento en
costos de
insumos y
materiales a
utilizar

Al momento
de
presupuestar,
dejar un
margen del
10%

Este riesgo se
da ya que los
precios de
muchos
materiales
suben de precio
constantemente

R002

Desarrollo
del
software

Virus en el
sistema

Se activara un
antivirus en
todas las
computadoras
que se
utilizaran
durante el
proyecto

Este riesgo se
toma en cuenta
porque siempre
existe la
vulnerabilidad
de que un virus
llegue a nuestra
computadora

R003

Desarrollo
del
software

Falla en la
energa
elctrica

Como comprar
una planta
elctrica
resultara muy
costoso, una
opcin podra
ser decir a los
empleados
que por ese
da trabajen
en sus casas

Ningn lugar
est exento de
que la energa
elctrica falle.

R004

Anlisis

Anlisis
errneo de los
requerimientos
del proyecto

Contratar al
personal
capacitado y
probar sus
conocimientos

En ocasiones la
persona no se
contratan las
personas con
los
conocimientos

55

Impacto

necesarios
R005

Desarrollo
del
software

Perdida de
informacin

Siempre es
necesario
tener un
respaldo de
todo el
proyecto.

Se puede
perder
informacin del
proyecto y esto
atrasara la
conclusin del
mismo

Tabla 6: Matriz de riesgos

6.7.2 Identificar riesgos

RIESGO

RESPUESTA POTENCIAL

Aumento en los costes

-Negociar con el cliente

-Absorber el problema

Virus en el sistema

-Instalar

antivirus

en

todas

las

computadoras
Perdida de informacin

-Tener de dos a tres respaldos en

diferentes computadoras

Falta de electricidad

-Enviar a los trabajadores a trabajar en

casa

Anlisis inadecuado de
requerimientos

-Trabajar horas extras

-Negociar con el cliente

Tabla 7: Identificacin de los riesgos

56

6.8. GESTIN DE ADQUISICIONES

6.8.1 Planificar compras y adquisiciones
Material

Vendedor

Garanta

Fecha de

Documento

entrega

que avale la
compra

Computadoras

--

1 ao

Los primeros

Facturas

15 das del
proyecto
Artculos de

Office depot

15 das

papelera

Los primero 7

Facturas o

das del mes

notas de venta

Tabla 8: compras y adquisiciones

6.8.2 Planificar contratacin

Se lanzara una convocatoria y se buscara presupuestos de los materiales requeridos
en el proyecto, los proveedores que mejor presupuesto tengan o que le convenga al
proyecto, sern llamados para empezar el proceso de contratacin.
Los puntos que se tomaran en cuenta para contratar a proveedores sern:

Que el proveedor entienda la necesidad

El coste total del proyecto

La capacidad tcnica del proveedor

La capacidad financiera

La capacidad de produccin

El tamao del negocio

Derechos de propiedad

57

6.8.3 Solicitar respuestas de vendedores

El nico proveedor calificado para artculos de papelera es Office Depot, se
especificara el contrato hecho con esta empresa o proveedor y la propuesta hecha
por la misma.

6.8.4 Seleccin de vendedores

En esta parte el proyecto recibe varias propuestas de muchos proveedores y esta
selecciona el que ms le convenga y de los proveedores seleccionados estos
entraran a un proceso de contratacin, al departamento indicado, para as tener el
contrato especfico y las polticas indicadas.

58

6.9 GESTIN DE COSTOS

6.9.1. Estimacin de costos
Materiales
Concept
o

Tipos
Direc
tos

Clase

Indi
rect
os

Fijo

Varia
ble

Deprec
iacin

Costo

IVA

Neto

Cantid
ad

Costo
Total

Laptop

2 aos

$5,000.00

$800.
00

$29,000
.00

Impresora

1 ao

$1,500.00

$240.
00

$1,740.
00

Copiadora

3 aos

$5,000.00

$800.
00

$5,800.
00

Scanner

2 aos

$1,000.00

$160.
00

$1,160.
00

Telefonos

3 aos

$400.00

$64.0
0

$1,392.
00

Paqueter
a Office

1 ao

$2,000.00

$320.
00

$2,320.
00

Delphi

1 ao

$1,000.00

$160.
00

$1160.0
0

SQL

1 ao

$3,000.00

$480.
00

$3,480.
00

TOTAL:

$46,052
.00

Tabla 9: estimacin de costos de materiales

59

Insumos
Tipos
Conce
pto

Direct
os

Clase

Indirec
tos

Fij
o

Varia
ble

Deprecia
cin

Cost
o

IVA

Cantid
ad

Neto

Cost
o
Total

Tner

N/A

$1,500
.00

$240.
00

$1,740
.00

Hojas
blancas

N/A

$200.0
0

$32.0
0

$232.0
0

Lapicer
os

N/A

$100.0
0

$16.0
0

$116.0
0

Lpices

N/A

$100.0
0

$16.0
0

$116.0
0

Libretas

N/A

$50.00

$8.00

$58.00

Folders

N/A

$150.0
0

$24.0
0

$174.0
0
TOTAL:

Tabla 10: Estimacin de costos de insumos

60

$2,436
.00

Servicios
Tipos
Conce
pto

Direct
os

Clase

Indirec
tos

Fij
o

Varia
ble

Deprecia
cin

Cost
o

Costo
IVA

Cantid
ad

Total

Neto

Luz

N/A

$2,000
.00

$320.
00

$4,640.
00

Agua

N/A

$200.0
0

$32.0
0

$464.00

Inmuebl
e

N/A

$4,000
.00

$640.
00

$18,560
.00

$400.0
0

$64.0
0

$1,856.
00

$1,856.
00

Internet

N/A

Servicio
Telefni
co

N/A

$400.0
0

$64.0
0

Impuest
os

N/A

TOTAL:

Tabla 11: Estimacin de costos de servicios

61

$27,376
.00

Recursos humanos

Tipos
Concep
to

Direct
os

Clase

Indirec
tos

Fij
o

Deprecia
cin

Varia
ble

Cost
o

Costo
IV
A

Cantid
ad

Total

Neto

Salario
Director
Proyecto

N/A

$5,000
.00

N/
A

$40,000.
00

Salario
Analista

N/A

$3,000
.00

N/
A

$3,000.0
0

$3,000
.00

N/
A

$6,000.0
0

Salario
Diseado
r

N/A

Salario
Program
ador

N/A

$3,000
.00

N/
A

$9,000.0
0

Salario
Jefe rea

N/A

$4,000
.00

N/
A

$32,000.
00

TOTAL:

$90,000
.00

Tabla 12: Estimacin de costos de personal

62

6.9.2 Preparacin del presupuesto

Concepto

Costo

Materiales

$46,052.00

Insumos

$2,436.00

Servicios

$27,376.00

Recursos humanos

$90,000.00
TOTAL:

$165,864.00

Tabla 13: costos generales

63

7. ANALISIS DE RESULTADOS

Como anlisis final de la realizacin de este proyecto cabe destacar que el sistema
de inventario solo fue analizado y diseado mas no implementado por el corto tiempo
de realizacin, pero confi en que ser un gran sistema a implementar y que cuando
esto se realice la abarrotera tendr un mejoramiento en su administracin del
almacn y esto se ver reflejado en la reduccin del ndice de perdida en los
inventarios.

64

8. CONLUSIONES Y RECOMENDACIONES
Con la realizacin de este proyecto se ha puesto en prctica lo que hemos aprendido
a lo largo de este cuatrimestre en la materia de Administracin e proyectos de TI II e
Integradora I, siendo este proyecto en la cual tenemos que comprobar todos los
conocimientos adquiridos.

A lo largo de la creacin del proyecto han surgido dudas que han sido aclaradas por
el profesor y nos hemos guiado de la gua PMBOK para su realizacin. De esta
manera hemos podido realizar la documentacin necesaria de una forma favorable.

En lo personal me sirvi para aprender cosas nuevas y reforzar mis conocimientos

en base de datos y algo de programacin.

65

9. FUENTES CONSULTADAS

http://manejadores-de-bases-de-datos.wikispaces.com/. (s.f.). Obtenido de

http://manejadores-de-bases-de-datos.wikispaces.com/

Antologa Ciclos de vida del software 2013. (s.f.).

http://borjacasla.blogspot.mx/2013/03/los-5-lenguajes-de-programacionmas_2795.html. (s.f.). Obtenido de http://borjacasla.blogspot.mx/2013/03/los5-lenguajes-de-programacion-mas_2795.html

66