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

ii

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.

iii

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.

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. OBJETIVOS ................................................................................................................................. 29

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

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

6. 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

v

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

8

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.

9

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.

10

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.

11

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.

12

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,

13

Costo, Calidad, Recursos Humanos, Comunicacin, Riesgo, Procura y

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.

14

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

15

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:

16

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 y 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.

17

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).

18

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

19

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.

20

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

21

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.

22

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.

23

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.

24

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)

25

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.

26

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,

27

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

1 (Antologa Ciclos de vida del software 2013)

28

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.

29

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.

30

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.

31

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.

32

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.

33

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

34

6.1.1.2 Diseo

Mapa de navegacin

Figura 9: Mapa de navegacin

LOGIN PRINCIPAL

PRINCIPAL

USUARIO

OPCIONES DE USUARIO

PUESTO

DEPARTAMENTO

EQUIPO

IMPRESORAS

ALTA

ACTUALIZACION

BAJA

DISPOSITIVOS

ALTA

ACTUALIZACION

BAJA

PROCESOS

ASIGNACION

ACTUALIZACION DE ASIGNACION

MODELO

MARCA

REPORTES

RESPONSIVA

STATUS DE LOS RECURSOS

ASIGNACIONES

SALIR CERRAR

35

Diagrama de casos de uso

Figura 10: Diagrama de casos de uso del sistema

36

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:

37

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

Application.

Figura 12: Creacin del proyecto

38

Figura 13: Creacin de un nuevo formulario

Creacin de la base de datos

TABLA ACCESO

Nombre campo Tipo tamao PK FK DESCRICPIN

id_acceso Int 10 x identificador de Tabla

fk_usuario Int 10 x identificador de Tabla usuario

username Varchar 50 Usuario

password Varchar 50 Contrasea

TABLA USUARIO

Nombre campo Tipo tamao PK FK DESCRICPIN

id_usuario Int 10 x identificador de Tabla

fk_departamento Int 10 x identificador de Tabla departamento

fk_puesto Int 10 x identificador de Tabla puesto

nombre_usuario Varchar 50 Nombre

ap_usuario Varchar 50 Paterno

am_usuario Varchar 50 Materno

foto_usuario Varchar 200 Foto

TABLA DEPARTAMENTO

Nombre campo Tipo tamao PK FK DESCRICPIN

id_departamento x identificador de Tabla

39

nombre_departamento

descripcion_departamento

TABLA PUESTO

Nombre campo Tipo tamao PK FK DESCRICPIN

id_puesto x identificador de Tabla

nombre_puesto

descripcion_puesto

TABLA MARCA

Nombre campo Tipo tamao PK FK DESCRICPIN

id_marca x identificador de Tabla

nombre_marca

descripcion_marca Tabla 1: Datos de la base de datos

40

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

41

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

42

6.3. GESTIN DE TIEMPO

6.3.1 Definicin de las actividades

Actividad Proceso

Anlisis 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

43

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

44

6.3.5. Desarrollo del cronograma

Figura 15: Cronograma de actividades

45

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.

46

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.

47

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.

48

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.

49

6.5. GESTIN DE COMUNICACIONES

6.5.1 Identificar interesados

Interesado Medio de

comunicacin

Frecuencia Formalidad Tipo receptor

Director impreso Semanal Formal Junta y

reporte

Analista,

programador,

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,

electrnico

Diario Informal Mensaje Director

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.

50

6.5.3 Distribuir informacin

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.

Programador Analista

Director

Diseador

Cliente Formal (quincenal)

Informal (diaria)

Formal (semanal)

Formal (semanal)

Formal (semanal)

Formal (semanal)

Informal (diaria) Informal

(diaria)

Programador Analista

Director

Diseador

Cliente Formal (Quincenal)

Informal (diaria)

Formal (semanal)

Formal (semanal)

Formal (semanal)

Formal (semanal)

Informal (diaria) Informal

(diaria)

51

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.

52

6.6. GESTIN DE CALIDAD

6.6.1. Planificacin de la calidad

Norma Descripcin Aplicacin Proceso Beneficios

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.

-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

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

53

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).

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

Para establecer,

implementar,

monitorear, revisar,

mantener y mejorar

un Sistema de

Administracin de

Seguridad de

Informacin

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

54

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.

-funcionalidad

-Confiabilidad

-usabilidad

-eficiencia

-facilidad

-portabilidad.

Tabla 5: Matriz de calidad

55

6.7. GESTIN DE RIESGOS

6.7.1 Planificacin de riesgos

Clave Actividad Riesgo Prevencin Criterio Impacto

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

56

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

57

6.8. GESTIN DE ADQUISICIONES

6.8.1 Planificar compras y adquisiciones

Material Vendedor Garanta Fecha de

entrega

Documento

que avale la

compra

Computadoras -- 1 ao Los primeros

15 das del

proyecto

Facturas

Artculos de

papelera

Office depot 15 das Los primero 7

das del mes

Facturas o

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

58

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.

59

6.9 GESTIN DE COSTOS

6.9.1. Estimacin de costos

Materiales

Concept

o

Tipos Clase Deprec

iacin

Costo

Neto

IVA Cantid

ad

Costo

Total Direc

tos

Indi

rect

os

Fijo Varia

ble

Laptop 2 aos $5,000.00 $800.00

5 $29,000

.00

Impresora 1 ao $1,500.00 $240.00

1 $1,740.

00

Copiadora 3 aos $5,000.00 $800.00

1 $5,800.

00

Scanner 2 aos $1,000.00 $160.00

1 $1,160.

00

Telefonos 3 aos $400.00 $64.00

3 $1,392.

00

Paqueter

a Office

1 ao $2,000.00 $320.00

1 $2,320.

00

Delphi 1 ao $1,000.00 $160.00

1 $1160.0

0

SQL 1 ao $3,000.00 $480.00

1 $3,480.

00

TOTAL: $46,052

.00

Tabla 9: estimacin de costos de materiales

60

Insumos

Conce

pto

Tipos Clase Deprecia

cin

Cost

o

Neto

IVA Cantid

ad

Cost

o

Total

Direct

os

Indirec

tos

Fij

o

Varia

ble

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: $2,436

.00

Tabla 10: Estimacin de costos de insumos

61

Servicios

Conce

pto

Tipos Clase Deprecia

cin

Cost

o

Neto

IVA Cantid

ad

Costo

Total Direct

os

Indirec

tos

Fij

o

Varia

ble

Luz N/A

$2,000

.00

$320.

00 2

$4,640.

00

Agua N/A

$200.0

0

$32.0

0 2 $464.00

Inmuebl

e

N/A $4,000

.00

$640.

00 4

$18,560

.00

Internet N/A

$400.0

0

$64.0

0 4

$1,856.

00

Servicio

Telefni

co

N/A

$400.0

0

$64.0

0 4

$1,856.

00

Impuest

os

N/A $ $ $

TOTAL: $27,376

.00

Tabla 11: Estimacin de costos de servicios

62

Recursos humanos

Concep

to

Tipos Clase Deprecia

cin

Cost

o

Neto

IV

A

Cantid

ad

Costo

Total Direct

os

Indirec

tos

Fij

o

Varia

ble

Salario

Director

Proyecto

N/A $5,000

.00

N/

A 8

$40,000.

00

Salario

Analista

N/A $3,000

.00

N/

A 1

$3,000.0

0

Salario

Diseado

r

N/A

$3,000

.00

N/

A 2

$6,000.0

0

Salario

Program

ador

N/A

$3,000

.00

N/

A 3

$9,000.0

0

Salario

Jefe rea

N/A

$4,000

.00

N/

A 8

$32,000.

00

TOTAL: $90,000

.00

Tabla 12: Estimacin de costos de personal

63

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

64

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.

65

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.

66

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-programacion-

mas_2795.html. (s.f.). Obtenido de http://borjacasla.blogspot.mx/2013/03/los-

5-lenguajes-de-programacion-mas_2795.html