Proyecto Mini Mercado Titulación
130
INDICE DE CONTENIDO I. GENERALIDADES.................................................1 1. INTRODUCCION..................................................1 2. PROBLEMA DE INVESTIGACIÓN.....................................2 2.1. PLANTEAMIENTO DEL PROBLEMA.................................2 2.2. FORMULACIÓN DEL PROBLEMA...................................3 3. OBJETIVOS.....................................................3 3.1. OBJETIVO GENERAL...........................................3 3.2. OBJETIVOS ESPECIFICOS......................................3 4. ALCANCES......................................................4 5. LÍMITES.......................................................5 6. JUSTIFICACIÓN.................................................5 6.1. JUSTIFICACIÓN TÉCNICA......................................5 6.2. JUSTIFICACIÓN ECONÓMICA....................................6 7. FACTIBILIDAD..................................................6 7.1. FACTIBILIDAD TÉCNICA.......................................6 7.2. FACTIBILIDAD ECONÓMICA.....................................7 7.3. FACTIBILIDAD OPERACIONAL...................................9 8. METODOLOGÍA..................................................10 8.1. TIPO DE INVESTIGACIÓN.....................................10 8.2. TÉCNICAS DE INVESTIGACIÓN.................................11 8.3. CICLO DE VIDA DEL DESARROLLO DE SOFTWARE..................12 8.4. METODOLOGIA DEL DESARROLLO DE SOFTWARE....................13 8.4.1. METODOLOGIA SCRUM.....................................13 II. MARCO TEORICO................................................12 1 SISTEMA......................................................12 1.1 DEFINICIÓN................................................12 1.2 MODELO DE SISTEMA..........................................13 2 SISTEMA DE INFORMACION.......................................13
-
Upload
jesus-remigio -
Category
Documents
-
view
27 -
download
1
Transcript of Proyecto Mini Mercado Titulación
INDICE DE CONTENIDO
I. GENERALIDADES........................................................................................................1
1. INTRODUCCION...........................................................................................................1
2. PROBLEMA DE INVESTIGACIÓN................................................................................2
2.1. PLANTEAMIENTO DEL PROBLEMA....................................................................2
2.2. FORMULACIÓN DEL PROBLEMA........................................................................3
3. OBJETIVOS...................................................................................................................3
3.1. OBJETIVO GENERAL............................................................................................3
3.2. OBJETIVOS ESPECIFICOS..................................................................................3
4. ALCANCES....................................................................................................................4
5. LÍMITES.........................................................................................................................5
6. JUSTIFICACIÓN............................................................................................................5
6.1. JUSTIFICACIÓN TÉCNICA....................................................................................5
6.2. JUSTIFICACIÓN ECONÓMICA.............................................................................6
7. FACTIBILIDAD...............................................................................................................6
7.1. FACTIBILIDAD TÉCNICA.......................................................................................6
7.2. FACTIBILIDAD ECONÓMICA................................................................................7
7.3. FACTIBILIDAD OPERACIONAL............................................................................9
8. METODOLOGÍA..........................................................................................................10
8.1. TIPO DE INVESTIGACIÓN..................................................................................10
8.2. TÉCNICAS DE INVESTIGACIÓN........................................................................11
8.3. CICLO DE VIDA DEL DESARROLLO DE SOFTWARE......................................12
8.4. METODOLOGIA DEL DESARROLLO DE SOFTWARE......................................13
8.4.1. METODOLOGIA SCRUM.............................................................................13
II. MARCO TEORICO......................................................................................................12
1 SISTEMA.....................................................................................................................12
1.1 DEFINICIÓN.........................................................................................................12
1.2 MODELO DE SISTEMA............................................................................................13
2 SISTEMA DE INFORMACION.....................................................................................13
2.1 DEFINICIÓN.........................................................................................................13
2.2 CLASIFICACIÓN..................................................................................................14
2.2.1 SISTEMA DE PROCESAMIENTO DE TRANSACCIONES (TPS)................15
2.2.2 SISTEMA DE CONOCIMIENTO (KWS)........................................................15
2.2.3 SISTEMA DE AUTOMATIZACION DE OFICINA (OAS)...............................15
2.2.4 SISTEMA DE INFORMACION GERENCIAL (MIS)......................................15
2.2.5 SISTEMA DE APOYO A LA TOMA DE DECISIONES (DSS).......................15
2.2.6 SISTEMA DE SOPORTE GERENCIAL (SSG).............................................16
2.2.7 SISTEMAS EXPERTOS (SE).......................................................................16
2.3 SISTEMA DE PROCESAMIENTO DE TRANSACCIONES (TPS).......................16
2.3.1 INTRODUCCION...........................................................................................16
2.3.2 QUÉ SON LOS SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES…….............................................................................……………17
3.3.3. CUALÉS SON LOS SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES18
3 METODOLOGIA DE DESARROLLO DE SOFTWARE...............................................19
3.1 DEFINICIÓN.........................................................................................................19
3.2 CLASIFICACIÓN..................................................................................................19
3.2.1 ESTRUCTURADAS.......................................................................................19
3.2.2 NO ESTRUCTURADAS................................................................................19
3.2.2.1 CLASES DE METODOLOGIAS....................................................................20
3.2.2.1.1METODOLOGIAS TRADICIONALES...........................................................20
3.2.2.1.2METODOLOGIAS ÁGILES...........................................................................21
3.3 MODELO DE PROTOTIPOS...............................................................................22
3.3.1 CICLO DE VIDA POR PROTOTIPADO........................................................23
3.4 METODOLOGÍA SCRUM.....................................................................................26
3.4.1 DEFINICIÓN..................................................................................................26
3.4.2 INTRODUCCIÓN A LA METODOLOGÍA SCRUM........................................27
3.4.3 CONTROL DE LA EVOLUCIÓN DEL PROYECTO......................................28
3.4.3.1 REVISION DE LAS ITERACIONES..............................................................28
3.4.3.2 DESARROLLO INCREMENTAL...................................................................28
3.4.3.3 DESARROLLO EVOLUTIVO........................................................................29
3.4.3.4 AUTO ORGANIZACION................................................................................29
3.4.3.5 COLABORACION..........................................................................................30
3.4.4 VISIÓN GENERAL DEL PROCESO.............................................................30
3.4.4.1 LAS REUNIONES.........................................................................................31
3.4.4.2 LOS ELEMENTOS........................................................................................31
3.4.4.3 LOS ROLES..................................................................................................32
3.4.5 VISIÓN GENERAL DEL PROCESO.............................................................33
3.4.5.1 VALORES......................................................................................................33
4 INVENTARIO...............................................................................................................35
4.1 CONCEPTO DE INVENTARIO............................................................................35
4.2 CLASIFICACION DE INVENTARIO.....................................................................36
4.2.1 INVENTARIO PERPETUO............................................................................36
4.2.2 INVENTARIOS INTERMITENTES................................................................36
4.2.3 INVENTARIO FINAL.....................................................................................36
4.2.4 INVENTARIO INICIAL...................................................................................36
4.2.5 INVENTARIO FISICO....................................................................................37
4.2.6 INVENTARIO MIXTO....................................................................................37
4.2.7 INVENTARIO DE PRODUCTOS TERMINADOS.........................................37
4.2.8 INVENTARIO EN TRANSITO.......................................................................37
4.2.9 INVENTARIO DE MATERIA PRIMA.............................................................37
4.2.10 INVENTARIOS EN PROCESO.....................................................................38
4.2.11 INVENTARIOS EN CONSIGNACIÓN...........................................................38
4.2.12 INVENTARIO MÁXIMO.................................................................................38
4.2.13 INVENTARIO MINIMO..................................................................................38
4.2.14 INVENTARIO DISPONIBLE..........................................................................38
4.2.15 INVENTARIO EN LINEA...............................................................................38
4.2.16 INVENTARIO AREGADO.............................................................................39
4.2.17 INVENTARIO EN CUARENTENA.................................................................39
4.2.18 INVENTARIO DE PREVISIÓN......................................................................39
4.2.19 INVENTARIO DE SEGURIDAD....................................................................39
4.2.20 INVENTARIO DE ANTICIPACIÓN................................................................40
4.2.21 INVENTARIO DE LOTE O DE TAMAÑO DE LOTE.....................................40
4.2.22 INVENTARIO ESTACIONALES....................................................................40
4.2.23 INVENTARIO PERMANENTES....................................................................40
4.2.24 INVENTARIOS CLÍNICOS............................................................................41
5 CONCEPTO DE SISTEMA DE VENTAS....................................................................41
5.1 DEFINICIONES....................................................................................................41
5.1.1 VENTA...........................................................................................................41
5.1.2 VENDEDOR..................................................................................................41
5.1.3 CLIENTE.......................................................................................................42
5.1.4 FACTURACION.............................................................................................42
5.1.5 EL COMERCIO.............................................................................................42
6 CONCEPTO DE FACTURACIÓN................................................................................43
7 BASE DE DATOS........................................................................................................43
7.1 SISTEMA DE GESTION DE BASE DE DATOS...................................................44
7.1.1 DEFINICION..................................................................................................44
7.1.2 CLASIFICACIÓN...........................................................................................44
7.1.3 MYSQL..........................................................................................................46
7.1.3.1 DEFINICIÓN..................................................................................................46
7.1.3.2 INTERIORES Y PORTABILIDAD..................................................................46
7.1.3.3 SEGURIDAD.................................................................................................46
7.1.3.4 ESCALABILIDAD Y LIMITES........................................................................46
7.1.3.5 CONECTIVIDAD...........................................................................................47
8 LA EMPRESA MINI MERCADO “LA GLORIA”...........................................................48
8.1 MISIÓN.................................................................................................................48
8.2 VISIÓN..................................................................................................................48
9 ORGANIGRAMA..........................................................................................................49
III. MARCO PRACTICO................................................................................................50
1. INTRODUCCION.........................................................................................................50
1.1. EQUIPO SCRUM..................................................................................................50
2. PILA DE PRODUCTOS............................................................................................51
2.1. HISTORIAS DE USUARIO...................................................................................52
2.1.1. HISTORIAS DE USUARIO SPRINT 1..........................................................52
2.2. PLANIFICACION DE LOS SPRINTS...................................................................56
2.2.1. ESTIMACION DE SPRINT............................................................................56
2.2.2. DEFINICION DE SPRINT 1..........................................................................56
2.2.3. DETALLES DE TAREAS DEL SPRINT 1.....................................................56
2.2.4. TAREAS REALIZADAS SPRINT 1: ACCESO AL SISTEMA........................58
2.2.5. TAREAS REALIZADAS SPRINT 1: INGRESO DE PRODUCTOS...............60
2.2.6. TAREAS REALIZADAS SPRINT 1: VENTA DE PRODUCTOS...................62
2.2.7. TAREAS ADICIONALES EN SPRINT 1........................................................64
2.2.7.1. TAREA REALIZADA SPRINT 1: REGISTRO DE PERSONAL.....................64
2.2.8. INFORME PRIMER SPRINT.........................................................................66
2.3. HISTORIAS DE USUARIO SPRINT 2..........................................................67
2.3.1. DEFINICION DE SPRINT 2..........................................................................70
2.3.2. DETALLE DE TAREAS DEL SPRINT 2........................................................70
2.3.3. TAREAS REALIZADAS SPRINT 2: GENERACION ORDENES DE COMPRA………………………………………………………………………………………72
2.3.4. TAREAS REALIZADAS SPRINT 2: DISEÑO PAGINA WEB........................74
2.3.5. TAREAS REALIZADAS SPRINT 2: REGISTRA/IMPRIME FACTURAS......75
2.3.6. INFORME SPRINT 2.....................................................................................76
2.4. HISTORIAS DE USUARIO SPRINT 3..........................................................76
2.4.1. DEFINICION SPRINT 3.................................................................................79
2.4.2. DETALLE DE TAREAS DEL SPRINT 3........................................................79
2.4.3. TAREAS REALIZADAS SPRINT 3: INGRESO Y MODIFICACION DE CATEGORIAS.............................................................................................................80
2.4.4. TAREAS REALIZADAS SPRINT 3: TIPOS DE USUARIO...........................81
2.4.5. TAREAS REALIZADAS SPRINT 3: CONSULTA POR PRODUCTO...........82
2.4.6. INFORME SPRINT 3.....................................................................................84
10 RECOMENDACIONES Y CONCLUSIONES...........................................................84
10.1 CONCLUSIONES.............................................................................................84
10.2 RECOMENDACIONES....................................................................................84
11 BIBLIOGRAFIA........................................................................................................85
INDICE DE TABLAS Y GRAFICOSTabla 1. Costo Hardware 7
Tabla 2. Costo Recurso Humano 7
Tabla 3. Costo de Capacitaciones 8
Tabla 4. Costo de Licencia de Software 8
Tabla 5. Costo de Implementación del Sistema 8
Grafico 1. Ciclo de vida del Software 20
Grafico 2. Esquema del modelo de sistema 24
Grafico 3. Elementos de un sistema de Información 25
Grafico 4. Desarrollo evolutivo 33
Grafico 5. Modelo evolutivo: Construcción de prototipos 36
Grafico 6. Proceso SCRUM 37
Grafico 7. Estructura del desarrollo ágil 38
Grafico 8. Estructura central del SCRUM 39
Grafico 9. Visión general del proceso 41
Grafico 10. Elementos modelo SCRUM 42
Grafico 11. Roles SCRUM 43
Grafico 12. Visión general del Modelo SCRUM 44
Grafico 13. Organigrama de la Empresa 60
Tabla 6. Visión general del proceso 62
Tabla 7. Pila de Productos 63
Tabla 8. Historia de Usuario: Acceso a la aplicación 64
Tabla 9. Historia de Usuario: Ingreso de Productos 65
Tabla 10. Historia de Usuario: Venta de Productos 66
Tabla 11. Estimación de Sprint 55
Tabla 12. Tabla general de Sprint 1 55
Tabla 13. Tabla detallada tarea: Acceso al Sistema 55
Tabla 14. Tabla detallada tarea: Ingreso de productos 56
Tabla 15. Tabla detallada tarea: Venta de productos 57
Grafico 14. Burn Down: Acceso a la Aplicación 58
Grafico 15. Ingreso a la Aplicación 59
Grafico 16. Roles por tipo de usuario 59
Grafico 17. Burn Down: Ingreso de Productos 60
Grafico 18. Ingreso orden de compra de productos 61
Grafico 19. Burn Down: Venta de Productos 62
Grafico 20. Venta de productos 63
Grafico 21. Impresión venta de productos 63
Tabla 18 – Historia de usuario: Generación de órdenes de compra
Tabla 19 – Historia de usuario: Diseño de página WEB
Tabla 20 – Historia de usuario: Registro e Impresión de Facturas
Tabla 21 – Definición de Sprint 2
Tabla 22 – Detalle tarea: Generación de órdenes de compra
Tabla 22 – Detalle tarea: Diseño de página WEB
Tabla 23 – Detalle tarea: Registro e impresión de Facturas
Tabla 23 – Historia de Usuario: Ingreso y modificación de categorías de productos
Tabla 24 – Historia de Usuario: Tipo de usuarios
Tabla 25 – Historia de Usuario: Consulta de Productos
Tabla 26 – Definición Sprint 3
Tabla 27 – Detalle de tareas: Ingreso y modificación de categorías de productos
Tabla 28 – Detalle de tareas: Tipos de usuarios
Tabla 29 – Detalle de tareas: Consulta de Productos
Grafico 22 - Burn Down: Registro de Personal ……………………………………………………………………………..64
Grafico 23 - Registro de Personal………………………………………………………………………………………………….65
Grafico 24 - Burn Down: Generación de Orden de compra ……………………………………………………… 84
Grafico 25 - Generación de Orden de compra ……………………………………………………………………………85
Grafico 26 - Formulario de orden de compra …………………………………………………………………………….85
Grafico 27 - Ingreso a la aplicación ……………………………………………………………………………………………86
Grafico 28 - Menú principal………………………….……………………………………………………………………………86
Grafico 29 - Menú de orden de compra ……………………………………………………………………………………86
Grafico 30 - Formulario de orden de compra ……………………………………………………………………………87
Grafico 31 - Burn Down: Registra e imprime Factura. ………………………………………………………………87
Tabla 23 – Historia de Usuario: Ingreso y modificación de categorías de productos………………….88
Tabla 24 – Historia de Usuario: Tipo de usuarios………………………………………………………………………89
Tabla 25 – Historia de Usuario: Consulta de Productos.……………………………………………………………90
Tabla 26 – Definición Sprint 3 …………………………………………………………………………………………………91
Tabla 27 – Detalle de tareas: Ingreso y modificación de categorías de productos……………………91
Tabla 28 – Detalle de tareas: Tipos de usuarios……………………………………………………………………….91
Tabla 29 – Detalle de tareas: Consulta de Productos……………………………………………………………….92
Grafico 32 - Burn Down: Ingreso y modificación de categorías de productos………………………….92
Grafico 33 - Ingreso y modificación de categorías de productos……………………………………………..93
Grafico 34 - Burn Down: Tipos de Usuarios……………………………………………………………………………..93
Grafico 35 - Formulario Tipos de Usuarios……………………………………………………………………………….94
Grafico 36 - Burn Down: Consulta por producto………………………………………………………………………94
Grafico 36 - Formulario: Consulta por producto………………………………………………………………………95
CAPITULO 1
GENERALIDADES
1
I. GENERALIDADES
1. INTRODUCCION
Los Sistemas de Información y las Tecnologías de Información han cambiado la
forma en que operan las organizaciones actuales. A través de su uso logran
importantes mejoras, pues automatizan los procesos operativos, suministran una
plataforma de información necesaria para la toma de decisiones y, lo más
importante, su implantación logra ventajas competitivas o reducir la ventaja de los
rivales.
La fácil disponibilidad que poseen las computadoras y las tecnologías de
información, han creado una revolución informática en la sociedad y de forma
particular en los negocios, el manejo de información generada por computadora
difiere en forma significativa del manejo de datos producidos manualmente.
El mejor aliado para una empresa que se precie de ser mejor que las demás es
siempre estar a la vanguardia. Toda empresa que se dedique a la venta de un
determinado artículo, ha visto la necesidad de tener una buena administración de
inventarios y ventas en el negocio, con o sin fines de lucro es esencial para su
funcionamiento adecuado y para la subsistencia dentro de un mercado
competitivo. Es importante en toda empresa, que se dedique a la comercialización
de productos, tener un sistema eficiente de control de inventarios, el cual permita
saber, cuánto y cuándo se debe pedir para el reabastecimiento de las mercaderías
para la venta.
En la presente monografía se desarrolla un sistema de inventario y ventas vía web
para el mini mercado “La Gloria” la cual se dedica a la venta de productos de
primera necesidad de empresas reconocidas en el país y productos importados. El
propósito de este sistema es brindarle al mini mercado un beneficio de seguridad y
manejo exacto de todas las transacciones de venta e inventario que a diario
realizan en el mini mercado.
2
2. PROBLEMA DE INVESTIGACIÓN
2.1. PLANTEAMIENTO DEL PROBLEMA
El problema del mini mercado “La Gloria”, radica en que todos los procesos
que se realizan, son de forma manual, desde el control de inventario, venta de
productos y facturación, lo único que tienen para registrar es un libro de
control, es decir que las actividades se dan de forma simple y hay que sentarse
a procesar información a mano y con calculadora.
Las compras se procesan de forma manual, no se cuenta con una base de
datos de proveedores, para las cuenta que se debe pagar por los pedidos hay
que revisar manualmente los documentos, pero como no está organizada se
tiende a extraviar o perder, lo que causa retrasos a la hora que se necesita
datos de un proveedor o verificar la fecha de pago o el monto de la deuda y
otros, repercutiendo en un manejo inadecuado de la información, poco
conocimiento de la existencia de los productos y controles no muy eficientes.
Esto se identifica mediante entrevistas realizadas al personal del mini mercado,
lo cual permitió identificar otros problemas que se listan a continuación:
El manejo de inventarios, es de forma manual e implica mucho
esfuerzo.
El registro de ventas es manual, causando pérdidas de datos.
La facturación es manual, causando pérdida de tiempo por ser
muchos datos los que debe incluir en esta.
Demora en la ubicación de los proveedores de productos
Demora en la validación de la fecha de vencimiento, se hace una
revisión manual producto por producto.
Para poder hacer una orden de compra de productos se debe
realizar un conteo manual de los estantes y del almacén de
productos.
No se cuenta con un seguimiento en la entrega de pedidos.
3
No se cuenta con un control eficiente sobre las ventas de productos.
No se cuenta con un reporte de lo recaudado en el día.
No se cuenta con un registro detallado de los clientes.
No se cuenta con información histórica.
De tal manera el problema central radica en que no se cuenta con un
control adecuado para proceso de inventario y ventas de los productos.
2.2. FORMULACIÓN DEL PROBLEMA
¿Cómo optimizar los procesos de control de inventario y venta de productos en
el mini mercado “La Gloria”?
3. OBJETIVOS
3.1. OBJETIVO GENERAL
Desarrollar un Sistema de Información para el mini mercado “La Gloria” que
optimice los procesos de inventario y ventas.
3.2. OBJETIVOS ESPECIFICOS
Diseñar el modelo del sistema para los requerimientos definidos.
Aplicar la metodología SCRUM para desarrollar el sistema de inventario
y ventas.
Utilizar el lenguaje de programación PHP, Java Script, HTML y el gestor
de base de datos MySQL, para el desarrollo del sistema.
Crear una base de datos para almacenar los datos requeridos para el
buen funcionamiento del sistema.
4
Diseñar las interfaces del sistema de modo que sea fácil de entender y
utilizar.
4. ALCANCES
El sistema de inventario y ventas, se desarrollara en un lenguaje que permitirá una
interfaz amigable con los usuarios, se restringirá el acceso a ciertos módulos
donde solo el personal autorizado tendrá acceso.
El sistema será cliente servidor, para esto los equipos tendrán que estar en una
red LAN que se implementara.
La investigación se realizará en el lapso de seis meses contemplando el segundo
semestre de la gestión 2013.
La investigación se realizará en la ciudad de la Paz, en la zona de Achachicala
donde se ubica el mini mercado “La Gloria”, que clasifica para la compra y venta
de artículos de primera necesidad el alcance de personas que usaran el mini
mercado es de clase baja a media.
El sistema de Información cuenta con los siguientes módulos:
Módulo de Inventario
Registro de ingreso de los productos.
Generar las órdenes de compra a los proveedores.
Registra las órdenes de compra de los productos.
Editar las categorías de los productos
Módulo de Ventas
Registro de la venta de productos y registro de factura.
Módulo de Personal
Registro de personal.
5
Asignación de roles a los usuarios.
Registro de tipos de usuarios.
Modificación de roles de los cajeros.
Módulo de Consultas
Reporte de Productos.
5. LÍMITES
El Sistema de inventario y ventas no contara con un sistema contable, ni con lector
de código de barras para el registro y venta de los productos.
6. JUSTIFICACIÓN
6.1. JUSTIFICACIÓN TÉCNICA
El Proyecto a desarrollar, se realiza por la necesidad que tiene el mini mercado
“La Gloria”, ya que no cuenta con un sistema de información de inventario y
ventas, mismo que mejorara el proceso, dando facilidades al personal y de
esta forma optimizara los servicios que presta a sus clientes.
Es necesario el control de inventario para que se automatice las transacciones
de compra y venta que realiza el mini mercado de forma repetitiva. Así se
ahorrara tiempo haciendo conteo de existencias de productos.
El proyecto se justifica técnicamente, porque puede desarrollarse con los
equipos de computación Pentium IV con las siguientes características:
procesador de 3 GHz, capacidad mínima de disco duro de 80 GB o superior,
una capacidad en memoria RAM de 512 MB como mínimo, equipos que serán
adquiridos por el mini mercado “La Gloria”, la adquisición de software como
Linux, Windows XP, que es adecuado para su implantación, equipo que será
destinado para caja y servidor, también se deberá adquirir un HUB para la
comunicación entre cliente / Servidor.
6
6.2. JUSTIFICACIÓN ECONÓMICA
El proyecto se justifica económicamente, ya que permitirá que el mini mercado
optimice el control de inventario y venta de productos, mejorando el tiempo que
toma el control manual de los productos, conteo de los productos vendidos, el
análisis, desarrollo e implementación se realizará por una persona.
La parte que más dificulta cualquier desarrollo de un sistema son los costos
que este ocasione, para un comercio lo importante es invertir si las ganancias
van a ser vistas de manera rápida. A la hora de invertir se busca la manera de
que la inversión sea mínima pero sobre todo que los equipos proporcionen
rendimiento al óptimo. Los costos abarcan la mayoría del proceso del
desarrollo del software desde el análisis pasando por la planeación y el
mantenimiento estos de alguna manera van agregando costos lo que provoca
un aumento a medida que se avanza en cada etapa. El desarrollo del sistema
no tiene costo monetario alguno ya que se empleara herramientas del tipo
“Software Libre”. Con la decisión de emplear herramientas económicamente
factibles se podrá obtener beneficios las cuales se nombra a continuación:
Disminución del tiempo en sus actividades diarias.
Disminuir el manejo de documentos que se maneja en el almacén.
7. FACTIBILIDAD
7.1. FACTIBILIDAD TÉCNICA
La factibilidad Técnica demuestra si el sistema propuesto tendrá éxito al
momento de la implantación y operación de éste. Esto se hace considerando
que existe disponibilidad de hardware y software, actualmente se cuenta con el
7
personal que será capacitado para administrar el sistema de información de
inventario y ventas.
Después de haber analizado los aspectos mencionados anteriormente se ha
llegado a la conclusión:
a. Se cuenta con el recurso humano disponible que participara en el
funcionamiento del sistema informático.
b. Para el desarrollo del proyecto se tomara en cuenta las especificaciones
técnicas del Hardware, que actualmente se cuenta.
c. Para el desarrollo del Software se contara con software libre y el sistema
operativo que actualmente tienen los equipos de computación.
d. El nivel de conocimiento de las personas que darán el soporte al Sistema
de Información no es el adecuado para administrar la Base de Datos, por lo
que se preparará una capacitación en manejo de base de datos y sitios web
para asegurar el correcto mantenimiento del sistema de información.
7.2. FACTIBILIDAD ECONÓMICA
En la factibilidad económica se establecen los costos y beneficios del proyecto.
A continuación se presentan los cuadros que muestra un resumen de los
costos de desarrollo e implantación del Sistema de Inventarios y ventas del
mini mercado “La Gloria”.
HardwareCantidad Descripción Costo/unitario Costo Total Observación
2 PC de escritorio 700 140040 metros de cable UTP 1,5 60
8 Conectores RJ45 0,69 5,523 Conectores RJ45 hembra 3,4 10,21 switch base 10/100 8 puertos 47 47
Costo de Hardware 1.522,72$
Tabla 1. Costo Hardware
8
Costo del Recurso Humano del SistemaCantidad Descripción Costo/unitario Costo Observación
1 Analistas 315 315
El costo de análisis y desarrollo será el mínimo por tratarse de un proyecto académico
Costo de Recurso Humano 315,00$
Tabla 2. Costo Recurso Humano
Costo CapacitacionesCantidad Descripción Costo/unitario Costo Observación
10 Horas 50 50
El costo de capacitación será el mínimo por tratarse de un proyecto académico
Costo de Recurso Humano 50,00$
Tabla 3. Costo de Capacitaciones
Licencia de SoftwareCantidad Descripción Costo/unitario Costo ObservaciónMySqL Gestor de Base de Datos 0 0 Software libre
Windows XP Sistema Operativo0 0
Se encuentra incluido con la compra del requipo
Costo de licencias de software $ 0
Tabla 4. Costo de Licencia de Software
Costo de Implementación del sistemaDescripción Costo/unitario Costo
1.522,72$ 315,00$
50,00$ -$
Costo de Hardware 1.887,72$
HardwareRecurso HumanoCapacitacionesLicencia de software
Tabla 5. Costo de implementación del Sistema
Después de determinar los costos estimados del equipo para el desarrollo de un
sistema de Información de Inventario y Ventas, a continuación se describe las
razones por las que se propone el equipo antes mencionado:
a. El hardware se considera el más apropiado para el desarrollo del Sistema.
b. El sistema de gestión de base de datos es MySQL ya que no se incurriría
en ningún gasto.
9
c. El costo del analista es el mínimo por tratarse de un desarrollo académico.
d. El costo de capacitación se refiere a la capacitación que se impartirá al
personal sobre el uso y mantenimiento del sistema propuesto.
7.3. FACTIBILIDAD OPERACIONAL
La Factibilidad Operacional permite determinar si no existe resistencia al
cambio entre los usuarios del sistema, que obstaculice, el desarrollo, la
implantación y ejecución del mismo. Se hizo una entrevista sobre el grado de
aceptación y necesidad de un sistema automatizado de inventario y ventas, y
se llegó a las siguientes conclusiones:
a. El personal está de acuerdo en que se desarrolle un sistema de información
automatizado, ya que consideran que es necesario la implementación de un
Sistema que ayude en el control de inventarios y ventas de los productos.
b. El proyecto es factible operacionalmente desde el punto de vista del recurso
que lo utilizara, ya que todos los involucrados cumplen con los requisitos
necesarios para que el sistema opere de forma satisfactoria.
10
8. METODOLOGÍA
8.1. TIPO DE INVESTIGACIÓN
Para la realización del proyecto se analizaron diversos tipos de investigación y
se tomó el que más se adecua al proyecto. La investigación proyectiva,
consiste en la elaboración de una propuesta, un plan, un programa o un
modelo, como solución a un problema o necesidad de tipo práctico, ya sea de
un grupo social, o de una institución, o de una región geográfica, en un área
particular del conocimiento, a partir de un diagnóstico preciso de las
necesidades del momento, los procesos explicativos o generadores
involucrados y de las tendencias futuras, es decir, con base en los resultados
de un proceso investigativo.
La investigación proyectiva se ocupa de cómo deberían ser las cosas, para
alcanzar unos fines y funcionar adecuadamente. La investigación proyectiva
involucra creación, diseño, elaboración de planes, o de proyectos; sin
embargo, no todo proyecto es investigación proyectiva. Para que un proyecto
se considere investigación proyectiva, la propuesta debe estar fundamentada
en un proceso sistemático de búsqueda e indagación que requiere la
descripción, el análisis, la comparación, la explicación y la predicción. A partir
del estadio descriptivo se identifican necesidades y se define el evento a
modificar; en los estadios comparativo, analítico y explicativo se identifican los
procesos causales que han originado las condiciones actuales del evento a
modificar, de modo que una explicación plausible del evento permitirá predecir
ciertas circunstancias o consecuencias en caso de que se produzcan
determinados cambios; el estadio predictivo permitirá identificar tendencias
futuras, probabilidades, posibilidades y limitaciones. En función de esta
11
información, el investigador debe diseñar o crear una propuesta capaz de
producir los cambios deseados.
Se usa investigación proyectiva porque hay situaciones que no están
marchando como debieran, y que se desean modificar o modificarse. Porque
hay potencialidades que no se están aprovechando. Porque hay problemas a
resolver. El investigador diagnostica el problema (evento a modificar), explica a
qué se debe (proceso causal) y desarrolla la propuesta con base en esa
información.
8.2. TÉCNICAS DE INVESTIGACIÓN
La técnica es indispensable en el proceso de la investigación, ya que integra la
estructura por medio de la cual se organiza la investigación, La técnica
pretende los siguientes objetivos:
Ordenar las etapas de la investigación.
Aportar instrumentos para manejar la información.
Llevar un control de los datos.
Orientar la obtención de conocimientos.
En cuanto a las técnicas de investigación, se aplicaron:
La Técnica de Campo permite la observación en contacto directo con el
objeto de estudio, y el acopio de testimonios que permitan confrontar la
teoría con la práctica en la búsqueda de la verdad objetiva.
Técnica de Observación directa, permite conocer de manera rápida los
procesos que se realizan en el mini mercado.
Técnica de Entrevistas, es para la recopilación de información mediante
una conversación profesional, con la que además se adquirirse
información acerca de lo que se investiga, los resultados a lograr en la
misión dependen en gran medida del nivel de comunicación entre el
investigador y los participantes en la misma.
12
Técnica de Cuestionarios, se formula una serie de preguntas que
permiten detectar las necesidades.
8.3. CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
El Ciclo de Vida del Desarrollo de Sistemas es una metodología de sistemas
usada para facilitar el desarrollo de los sistemas de información. Además, el
Ciclo de Vida del Desarrollo de Software ayuda a los gestores de proyecto con
la planificación del desarrollo y la puesta en marcha de un sistema de
información que reúna los requisitos del usuario, y que sea completado a
tiempo y dentro de los límites del presupuesto. Con el Ciclo de Vida del
Desarrollo de Software, un administrador de proyecto gestiona de forma
efectiva las tareas y detalles de un proyecto de desarrollo de sistemas, y
comunica las fechas, objetivo importantes a las personas involucradas o
afectadas por el proyecto. Las fases del Ciclo de Vida del Desarrollo del
Software son la planificación conceptual, la definición de requisitos, el diseño,
el desarrollo y las pruebas, la puesta en marcha, las operaciones y el
mantenimiento y la disposición.
13
Grafico 1 - Ciclo de vida del Software
8.4. METODOLOGIA DEL DESARROLLO DE SOFTWARE
8.4.1. METODOLOGIA SCRUM
La metodología Scrum permite abordar proyectos complejos desarrollados
en entornos dinámicos y cambiantes de un modo flexible. Está basada en
entregas parciales y regulares del producto final en base al valor que
ofrecen a los clientes. Es una opción de gestión ideal para acometer
proyectos desarrollados en entornos complejos que exigen rapidez en los
resultados y en los que la flexibilidad es un requisito imprescindible. Scrum
ofrece agilidad y el, resultado, siempre, valor.
CAPITULO 2MARCO TEORICO
12
II. MARCO TEORICO
1 SISTEMA
1.1 DEFINICIÓN
Un sistema es un conjunto de elementos interrelacionados de modo tal que
producen como resultado algo superior y distinto a la simple agregación de los
elementos.
De acuerdo con esta definición, en todo sistema existen los siguientes
componentes: elementos, relaciones y objetivo.
Los elementos o partes que conforman un sistema pueden ser humanos o
mecánicos, tangibles o intangibles, estáticos o dinámicos.
Las relaciones entre los elementos son las que hacen que todo sistema sea
complejo. La importancia de las relaciones, tanto en el análisis y el diseño como
en el comportamiento del sistema, es fundamental. Esto se advierte con
frecuencia en el ámbito de las organizaciones. Muchos gerentes, por ejemplo,
obtienen resultados exitosos donde otros fracasaron, a pesar de que emplean a
las mismas personas y cuentan con los mismos recursos. Lo que estos gerentes
han hecho es utilizar de otra manera los mismos elementos, asignándoles distintos
roles y modificando sus interrelaciones. En una palabra, han cambiado el diseño
del sistema.
En cuanto al objetivo, puede afirmarse que constituye la razón de ser de un
sistema. El comportamiento teleológico, es decir, dirigido a la búsqueda de un
objetivo, de un resultado, de una meta o de un estado de equilibrio, constituye una
característica presente en todos los sistemas. El objetivo define al sistema; nada
puede hacerse respecto a un sistema (estudiarlo, rediseñarlo, evaluarlo, operarlo,
dirigirlo, etc.) si no se conoce su objetivo.
El logro de un resultado superior y distinto a la simple agregación de los elementos
constituye lo que se llama “efecto sinérgico”. Si a un sistema se le saca (o se le
13
agrega) una parte, no puede esperarse que siga funcionando igual; pero, a raíz de
la sinergia, ni siquiera puede esperarse que funcione “igual, menos (o más) la
proporción de esa parte”. Un claro ejemplo, en este sentido, es el de la
combinación de dos medicamentos, cuyo resultado, al ingerirlos, puede ser muy
distinto a la simple suma de sus efectos separados.
1.2 MODELO DE SISTEMA
Todo sistema se puede definir por sus entradas, su proceso y sus salidas, y
responde, por lo tanto, al modelo cuyo esquema es el que se muestra en la
Figura 1.
Grafico 2 - Esquema del modelo de sistema.
2 SISTEMA DE INFORMACION
2.1 DEFINICIÓN
Un sistema de Información puede definirse técnicamente como un conjunto de
componentes interrelacionados que permiten capturar, procesar, almacenar y
distribuir la información para apoyar la toma de decisiones y el control en una
institución.
Además, para apoyar a la toma de las decisiones, la coordinación y el control,
los sistemas de información pueden también ayudar a los administradores y al
personal a analizar problemas, visualizar cuestiones complejas y crear nuevos
productos.
Los Sistemas de Información pueden contener datos acerca de personas,
lugares y cosas importantes dentro de la institución y el entorno que lo rodea.
14
Tres actividades de un sistema de información producen la información que la
institución requiere para la toma de decisiones, para el control de las
operaciones, el análisis de los problemas y la creación de nuevos productos y
servicios. Estas actividades son:
ALIMENTACIÓN O INSUMO Captura o recolecta datos dentro de la
organización o del entorno que la rodea.
PROCESAMIENTO Transforma estos datos primos a algo que tenga más
sentido.
PRODUCTO O SALIDA Transfiere la información procesada a las personas
o actividades donde deba ser empleado
RETROALIMENTACION Es el producto regresado a personas indicadas
dentro de la institución para ayudarles a evaluar o a corregir la etapa de
alimentación.
Grafico 3 - Elementos de un Sistema de Información
2.2 CLASIFICACIÓN
Los objetivos básicos que deben cumplir los Sistemas de Información son:
Automatización de procesos operativos.
Proporcionar información que sirva de apoyo al proceso de toma de
decisiones.
15
Lograr ventajas competitivas a través de su implantación y uso.
La clasificación de los sistemas de información es la siguiente:
2.2.1 SISTEMA DE PROCESAMIENTO DE TRANSACCIONES (TPS)
Recolectan, almacenan, modifican y recuperan la información generada por
las transacciones producidas en una organización. Si durante una
transacción se produce un error, el TPS debe ser capaz de deshacer las
operaciones realizadas hasta ese momento. Es muy útil para el
procesamiento de transacciones on-line.
2.2.2 SISTEMA DE CONOCIMIENTO (KWS)
Auxilian a los trabajadores en la creación e integración de nuevo
conocimiento en la organización. Están diseñados para aumentar la
productividad de los trabajadores.
2.2.3 SISTEMA DE AUTOMATIZACION DE OFICINA (OAS)
Aplicaciones destinadas a ayudar al trabajo diario del administrativo de una
organización, forman parte de este tipo de software los procesadores de
textos, las hojas de cálculo, los editores de presentaciones, los clientes de
correo electrónico, etc.
2.2.4 SISTEMA DE INFORMACION GERENCIAL (MIS)
Son el resultado de interacción colaborativa entre personas, tecnologías y
procedimientos. Apoyan a nivel administrativo entregando información útil
para el planteamiento, control y toma de decisiones.
2.2.5 SISTEMA DE APOYO A LA TOMA DE DECISIONES (DSS)
Herramienta para realizar el análisis de las diferentes variables de un
negocio con la finalidad de apoyar el proceso de toma de decisiones. Su
principal característica es la capacidad de análisis multidimensional (OLAP)
que permite profundizar en la información hasta llegar a un alto nivel de
16
detalle, analizar datos desde diferentes perspectivas, realizar proyecciones
de información para pronosticar lo que puede ocurrir en el futuro, análisis de
tendencias, análisis prospectivo, etc.
2.2.6 SISTEMA DE SOPORTE GERENCIAL (SSG)
Trabajan con información interna y externa a la organización y están
diseñados para abordar la toma de decisiones que requieren juicio,
evaluación y comprensión.
2.2.7 SISTEMAS EXPERTOS (SE)
Es una aplicación informática capaz de solucionar un conjunto de
problemas que exigen un gran conocimiento sobre un determinado tema.
Emulan el comportamiento de un experto en un dominio concreto y en
ocasiones son usados por éstos. Con los sistemas expertos se busca una
mejor calidad y rapidez en las respuestas dando así lugar a una mejora de
la productividad del experto.
2.3 SISTEMA DE PROCESAMIENTO DE TRANSACCIONES (TPS)
2.3.1 INTRODUCCION
Las distintas clases de sistemas de información surgen de la satisfacción de
diferentes necesidades. Si el sistema de información satisface las
necesidades del sistema-organización, las distintas clases de subsistemas
de información habrán de satisfacer las necesidades de distintos
subsistemas de la organización.
De acuerdo con el modelo de Herbert Simón, las organizaciones se
estructuran en tres niveles: el nivel operativo, constituido por un sistema de
procesos físicos de producción y distribución; el nivel de las decisiones
programadas, que maneja operaciones, y el nivel de las decisiones no
programadas, que genera decisiones programadas. La información que
17
concierne a la toma de decisiones es utilizada por el nivel de las decisiones
no programadas; éste transmite sus decisiones, en forma de planes, al nivel
de las decisiones programadas, el que, restringido por estos planes, genera
la información que regula los procesos físicos del nivel operativo.
Estas precisiones permiten analizar los tipos de sistemas de información, lo
cual constituye un tema de relevante interés para la conducción de las
organizaciones.
2.3.2 QUÉ SON LOS SISTEMAS DE PROCESAMIENTO DE
TRANSACCIONES
Históricamente, los sistemas de información transaccionales fueron los
primeros (y, durante muchos años, casi los únicos) en ser incorporados al
procesamiento computadorizado.
En el contexto de los sistemas de información, una transacción es un
intercambio entre un usuario que opera una terminal y un sistema de
procesamiento de datos, en el que se concreta un determinado resultado.
Implica la captura y validación de los datos ingresados por el usuario, la
consulta y/o actualización de archivos, y una salida o respuesta. Esta
definición connota en la transacción su carácter de operación individual,
relativamente breve e indivisible.
Los sistemas de información transaccionales, por lo tanto, están destinados
a satisfacer las necesidades del nivel operativo.
Explotan la capacidad y velocidad de las computadoras para almacenar y
procesar grandes volúmenes de datos. Realizan operaciones repetitivas y
relativamente sencillas, y contribuyen a automatizar las tareas más
rutinarias y tediosas, a eliminar el “papeleo”, a acelerar los trámites, a
disminuir la cantidad de mano de obra, a minimizar los errores, a facilitar la
registración y recuperación de datos desagregados y, en general, a reducir
18
o aligerar las actividades que desarrollan los empleados u operarios de las
organizaciones.
3.3.3. CUALÉS SON LOS SISTEMAS DE PROCESAMIENTO DE
TRANSACCIONES
En este tipo de sistemas, se encuentran los que son prácticamente
comunes a todas las organizaciones, tales como los de Contabilidad,
Facturación, Inventarios, Ventas, Proveedores, Cuentas Corrientes,
Cobranzas, Caja, Bancos, Sueldos, Finanzas, Compras, Planeamiento y
Control de la Producción, etc. También pertenecen a esta clase muchos
otros sistemas (llamados “sistemas para mercados verticales”) que resultan
más específicos de una rama de actividad, como, por ejemplo,
Administración de Obras Sociales, Administración de Sistemas de Medicina
Prepaga, Administración de AFJP, Servicios Financieros, Reserva de
Pasajes, Administración Hospitalaria, Administración Hotelera,
Administración de Propiedades, Administración de Instituciones Educativas,
Producción de Seguros, etc.
Si no para todos, para la mayoría de estos sistemas existe una variada
oferta de paquetes de programas estandarizados. Los más numerosos son
los diseñados para las organizaciones más pequeñas, y su costo, su grado
de estandarización y su sencillez de manejo los hacen muy accesibles, así
como aptos para su empleo con los más económicos modelos de
computadoras personales. En el otro extremo, se encuentran las versiones
más potentes y costosas, las que suelen tener mayores exigencias de
implantación; generalmente, requieren personal especialmente entrenado,
recursos de computación relativamente caros y sofisticados, y la adaptación
de los programas a las necesidades particulares de la organización. Sobre
todo en el caso de esta categoría superior de paquetes, se plantea la
alternativa estratégica de optar por estas soluciones de terceros o encarar
el desarrollo de sistemas “a medida”, es decir, especialmente diseñados y
construidos para la organización en que serán utilizados.
19
3 METODOLOGIA DE DESARROLLO DE SOFTWARE
3.1 DEFINICIÓN
Son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de
software. También se define como un conjunto ordenado de pasos a seguir
para llegar a la solución de un problema u obtención de un producto llamado
software.
En general las metodologías llevan a cabo una serie de procesos comunes que
son buenas prácticas para lograr los objetivos antes mencionados
independientemente de cómo hayan sido diseñadas. Una metodología está
compuesta por:
Cómo dividir un proyecto en etapas.
Qué tareas se llevan a cabo en cada etapa.
Qué restricciones deben aplicarse.
Qué técnicas y herramientas se emplean.
Cómo se controla y gestiona un proyecto.
3.2 CLASIFICACIÓN
Las metodologías se clasifican de la siguiente forma:
3.2.1 ESTRUCTURADAS
Orientadas a procesos
Orientadas a datos
Mixtas
3.2.2 NO ESTRUCTURADAS
Orientadas a objetos
Sistemas de tiempo real
20
3.2.2.1 CLASES DE METODOLOGIAS
Las metodologías a tratar desde el punto de vista de la arquitectura de
software y la administración de proyectos serán las siguientes:
3.2.2.1.1 METODOLOGIAS TRADICIONALES
Modelo en Cascada
Modelo de Procesos Incrementables
Modelo de desarrollo rápido de aplicaciones (DRA)
Modelos Evolutivos
o Construcción de Prototipos
o Modelo en Espiral
o Modelo de desarrollo concurrente
Modelos iterativos
Capability Maturity Model (SW-CMM)
Capability Maturity Model Integration for Development (CMMI-
DEV)
Big Design Up Front (BDUF)
Cleanroom Software Engineering
Rational Unified Process (RUP)
Essential Unified Process for Software Development (EssUP)
Fusebox Lifecycle Process (FLiP)
Software Process Improvement and Capability dEtermination
(SPICE)
Métrica
Jackson System Development (JSD)
Joint Application Development (JAD)
Open Unified Process (OpenUP)
21
3.2.2.1.2 METODOLOGIAS ÁGILES
Extreme Programming (XP)
Scrum
Agile Modeling Adaptive Software Development (ASD)
Crystal Clear
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Lean Software Development (LSD)
Agile Unified Process (AUP)
Software Development Rhythms
Agile Documentation
ICONIX Process
Microsoft Solutions Framework (MSF)
Agile Data Method
Database Refactoring
LeanCMMI
22
3.3 MODELO DE PROTOTIPOS
La Ingeniería de Software es una disciplina que ofrece métodos y técnicas para
desarrollar y mantener software de calidad, el cual tiene por objetivo satisfacer
las necesidades del cliente. En la ingeniería de software es importante que el
producto sea confiable, completo y cumpla con las fechas y plazos
establecidos. Dentro de la Ingeniería del software existen varios modelos para
llegar a la construcción final de un producto de software y optimizar el
desarrollo del mismo, cada modelo tiene ventajas y desventajas.
El desarrollo evolutivo se basa en la idea de desarrollar una implementación
inicial, exponiéndola a los comentarios del usuario y refinándola a través de las
diferentes versiones hasta que se desarrolla un sistema adecuado.
Grafico 4 - Desarrollo evolutivo
Existen dos tipos de desarrollo evolutivo:
Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el
cliente para explorar sus requerimientos y entregar un sistema final. El
desarrollo empieza con las partes del sistema que se comprenden
mejor. El sistema evoluciona agregando nuevos atributos propuestos
por el cliente.
23
Prototipos desechables, donde el objetivo del proceso de desarrollo
evolutivo es comprender los requerimientos del cliente y entonces
desarrollar una definición mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar con los requerimientos
del cliente que no se comprenden del todo.
La ventaja de un proceso del software que se basa en un enfoque evolutivo es
que la especificación se puede desarrollar de forma creciente.
El modelo de prototipos pertenece a los modelos de desarrollo evolutivo y es
usado cuando un prototipo debe ser construido en poco tiempo sin usar
muchos recursos.
Es habitual que en un proyecto software:
No se identifiquen los requisitos detallados de entrada, procesamiento o
salida.
No se está seguro de la eficiencia de un algoritmo, o de la forma en que
se ha de implantar la interface hombre-máquina.
Lo habitual es construir un PROTOTIPO.
3.3.1 CICLO DE VIDA POR PROTOTIPADO
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se
está desarrollando desde que nace la idea inicial hasta que el software es
retirado o remplazado (muere).
Entre las funciones que debe tener un ciclo de vida se pueden destacar:
Determinar el orden de las fases del proceso de software.
Establecer los criterios de transición para pasar de una fase a la
siguiente.
Definir las entradas y salidas de cada fase.
Describir los estados por los que pasa el producto.
Describir las actividades a realizar para transformar el producto.
24
Definir un esquema que sirve como base para planificar, organizar,
coordinar, desarrollar, entre otros.
Las etapas de un ciclo de vida de un software son:
Inicio: éste es el nacimiento de la idea. Aquí definimos los objetivos
del proyecto y los recursos necesarios para su ejecución. Hacia
dónde queremos ir, y no cómo queremos ir. Las características
implícitas o explícitas de cada proyecto hacen necesaria una etapa
previa destinada a obtener el objetivo por el cual se escribirán miles
o cientos de miles de líneas de código. Un alto porcentaje del éxito
de nuestro proyecto se definirá en estas etapas que, al igual que la
etapa de debugging, muchos líderes de proyecto subestiman.
Planificación: idearemos un planeamiento detallado que guíe la
gestión del proyecto, temporal y económicamente.
Implementación: acordaremos el conjunto de actividades que
componen la realización del producto.
Puesta en producción: nuestro proyecto entra en la etapa de
definición, allí donde se lo presentamos al cliente o usuario final,
sabiendo que funciona correctamente y responde a los
requerimientos solicitados en su momento. Esta etapa es muy
importante no sólo por representar la aceptación o no del proyecto
por parte del cliente o usuario final sino por las múltiples dificultades
que suele presentar en la práctica, alargándose excesivamente y
provocando costos no previstos.
Control en producción: control del producto, analizando cómo el
proceso difiere o no de los requerimientos originales e iniciando las
acciones correctivas si fuesen necesarias. Cuando decimos que hay
que corregir el producto, hacemos referencia a pequeñas
desviaciones de los requerimientos originales que puedan llegar a
surgir en el ambiente productivo. Si nuestro programa no realiza la
tarea para lo cual fue creada, esta etapa no es la adecuada para el
rediseño. Incluimos también en esta etapa el liderazgo,
25
documentación y capacitación, proporcionando directivas a los
recursos humanos, para que hagan su trabajo en forma correcta y
efectiva.
La construcción de prototipos se puede utilizar como un modelo del proceso
independiente. Sin importar la forma en que éste se aplique, el paradigma
de construcción de prototipos ayuda al desarrollador de software y al cliente
a entender de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos.
Etapas:
Plan rápido.
Modelado, diseño rápido.
Construcción del Prototipo.
Desarrollo, entrega y retroalimentación.
Comunicación.
Grafico 5 - Modelo evolutivo: Construcción de prototipos
26
3.4 METODOLOGÍA SCRUM
Grafico 6 - Proceso SCRUM
3.4.1 DEFINICIÓN
La metodología Scrum permite abordar proyectos complejos desarrollados
en entornos dinámicos y cambiantes de un modo flexible. Está basada en
entregas parciales y regulares del producto final en base al valor que
ofrecen a los clientes.
Es una opción de gestión ideal para acometer proyectos desarrollados en
entornos complejos que exigen rapidez en los resultados y en los que la
flexibilidad es un requisito imprescindible. Scrum ofrece agilidad y el,
resultado, siempre, valor.
27
La metodología Scrum permite abordar proyectos complejos desarrollados
en entornos dinámicos y cambiantes de un modo flexible. Está basada en
entregas parciales y regulares del producto final en base al valor que
ofrecen a los clientes.
3.4.2 INTRODUCCIÓN A LA METODOLOGÍA SCRUM
Scrum es una metodología de desarrollo muy simple, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en la adaptación
continua a las circunstancias de la evolución del proyecto.
Scrum es una metodología ágil, y como tal:
Es un modo de desarrollo de carácter adaptable más que predictivo.
Orientado a las personas más que a los procesos.
Emplea la estructura de desarrollo ágil: incremental basada en
iteraciones y revisiones.
Grafico 7 - Estructura del desarrollo ágil
Se comienza con la visión general del producto, especificando y dando
detalle a las funcionalidades o partes que tienen mayor prioridad de
desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve
(normalmente de 30 días).
28
Cada uno de estos periodos de desarrollo es una iteración que finaliza con
la producción de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su
evolución a través de reuniones breves diarias en las que todo el equipo
revisa el trabajo realizado el día anterior y el previsto para el día siguiente.
Grafico 8 - Estructura central del SCRUM
3.4.3 CONTROL DE LA EVOLUCIÓN DEL PROYECTO
Scrum controla de forma empírica y adaptable la evolución del proyecto,
empleando las siguientes prácticas de la gestión ágil:
3.4.3.1 REVISION DE LAS ITERACIONES
Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una
revisión con todas las personas implicadas en el proyecto. Este es el
periodo máximo que se tarda en reconducir una desviación en el
proyecto o en las circunstancias del producto.
3.4.3.2 DESARROLLO INCREMENTAL
Durante el proyecto, las personas implicadas no trabajan con diseños o
abstracciones.
29
El desarrollo incremental implica que al final de cada iteración se
dispone de una parte del producto operativa que se puede inspeccionar
y evaluar.
3.4.3.3 DESARROLLO EVOLUTIVO
Los modelos de gestión ágil se emplean para trabajar en entornos de
incertidumbre e inestabilidad de requisitos.
Intentar predecir en las fases iniciales cómo será el producto final, y
sobre dicha predicción desarrollar el diseño y la arquitectura del
producto no es realista, porque las circunstancias obligarán a
remodelarlo muchas veces.
Para qué predecir los estados finales de la arquitectura o del diseño si
van a estar cambiando. En Scrum se toma a la inestabilidad como una
premisa, y se adoptan técnicas de trabajo para permitir esa evolución
sin degradar la calidad de la arquitectura que se irá generando durante
el desarrollo.
El desarrollo Scrum va generando el diseño y la arquitectura final de
forma evolutiva durante todo el proyecto. No los considera como
productos que deban realizarse en la primera “fase” del proyecto. (El
desarrollo ágil no es un desarrollo en fases).
3.4.3.4 AUTO ORGANIZACION
Durante el desarrollo de un proyecto son muchos los factores
impredecibles que surgen en todas las áreas y niveles. La gestión
predictiva confía la responsabilidad de su resolución al gestor de
proyectos.
En Scrum los equipos son auto-organizados (no auto-dirigidos), con
margen de decisión suficiente para tomar las decisiones que consideren
oportunas.
30
3.4.3.5 COLABORACION
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del
equipo. Ésta es necesaria, porque para que funcione la auto-
organización.
Auto-organización como un control eficaz cada miembro del equipo
debe colaborar de forma abierta con los demás, según sus capacidades
y no según su rol o su puesto.
3.4.4 VISIÓN GENERAL DEL PROCESO
Scrum denomina “sprint” a cada iteración de desarrollo y recomienda
realizarlas con duraciones de 30 días.
El sprint es por tanto el núcleo central que proporciona la base de desarrollo
iterativo e incremental.
Grafico 9 - Visión general del proceso
31
Los elementos que conforman el desarrollo SCRUM son:
3.4.4.1 LAS REUNIONES
Planificación de sprint: Jornada de trabajo previa al inicio de cada
sprint en la que se determina cuál va a ser el trabajo y los
objetivos que se deben cumplir en esa Iteración.
Reunión diaria: Breve revisión del equipo del trabajo realizado
hasta la fecha y la previsión para el día siguiente.
Revisión de sprint: Análisis y revisión del incremento generado.
3.4.4.2 LOS ELEMENTOS
Pila del producto: lista de requisitos de usuario que se origina con
la visión inicial del producto y va creciendo y evolucionando
durante el desarrollo.
Pila del sprint: Lista de los trabajos que debe realizar el equipo
durante el sprint para generar el incremento previsto.
Incremento: Resultado de cada sprint.
32
Grafico 10 – Elementos modelo SCRUM
3.4.4.3 LOS ROLES
Scrum clasifica a todas las personas que intervienen o tienen interés en
el desarrollo del proyecto en: propietario del producto, equipo, gestor de
Scrum (también Scrum Manager o Scrum Master) y “otros interesados”.
Los tres primeros grupos (propietario, equipo y gestor) son los
responsables del proyecto.
Grafico 11 – Roles SCRUM
Propietario del producto: El responsable de obtener el mayor
valor de producto para los clientes, usuarios y resto de
implicados.
Equipo de desarrollo: grupo o grupos de trabajo que
desarrollan el producto.
Scrum Manager: gestor de los equipos que es responsable del
funcionamiento de la metodología Scrum y de la productividad
del equipo de desarrollo.
33
3.4.5 VISIÓN GENERAL DEL PROCESO
3.4.5.1 VALORES
Scrum es una “carrocería” para dar forma a los principios ágiles. Es una
ayuda para organizar a las personas y el flujo de trabajo; como lo
pueden ser otras propuestas de formas de trabajo ágil: Cristal, DSDM,
etc.
La carrocería sin motor, sin los valores que dan sentido al desarrollo
ágil, no funciona.
Delegación de atribuciones al equipo para que pueda auto-
organizarse y tomar las decisiones sobre el desarrollo.
Respeto entre las personas. Los miembros del equipo deben
confiar entre ellos y respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Trabajo centrado en el desarrollo de lo comprometido
Información, transparencia y visibilidad del desarrollo del
proyecto.
34
Grafico 12 - Visión General del Modelo SCRUM
35
4 INVENTARIO
Representa el activo circulante de mayor importancia para el mayor número de
empresas que compran artículos para revenderlos. Dado a esta condición, y a
efecto de dar a conocer lo que el administrador o contador público debe de tener
presente sobre la naturaleza del inventario y la técnica para su control.
4.1 CONCEPTO DE INVENTARIO
Un inventario consiste en la existencia de productos físicos que se conservan
en un lugar y momento determinado.
Los inventarios en una planta de fabricación abarcan la materia prima, la
mercancía en proceso y los artículos terminados.
El inventario es uno de los activos más importantes para muchas empresas.
Las principales fuentes de ingreso para las empresas industriales y mercantiles
es la venta de lo que tienen en inventario, a un precio más alto que su costo.
Los inventarios tienen particular porque pueden afectar en forma considerable
tanto al estado de utilidades como al estado de situación financiera.
Los inventarios son partidas de activo que se tienen para sus ventas en el
curso normal de los negocios, o se usaran o consumirán en la producción de
mercancías para vender.
Entre los bienes del activo excluidos específicamente del inventario, porque no
se vende en el curso normal de los negocios, se encuentran partidas como
planta, maquinaria y equipo, de las que se dispondrán finalmente, así como las
inversiones en valores que se disponen.
36
4.2 CLASIFICACION DE INVENTARIO
4.2.1 INVENTARIO PERPETUO
Es el que se lleva en continuo acuerdo con las exigencias en el almacén.
Por medio de un registro detallado que puede servir también como auxiliar,
donde se llevan los importes en unidades monetarias y las cantidades
física.
Lo registros perpetuos son útiles para preparar los estados financieros
mensuales, trimestrales o provisionales. También este tipo de inventario
ofrece un alto grado de control, porque los registros de inventarios están
siempre actualizados.
4.2.2 INVENTARIOS INTERMITENTES
Este inventario se puede efectuar varias veces al año. Se recurre a él, por
razones diversas no se pueden introducir en la contabilidad del inventario
contable permanente al que se trata de cumplir en parte.
4.2.3 INVENTARIO FINAL
Este inventario se realiza al termino del ejercicio económico, generalmente
al finalizar el periodo y puede ser utilizado para determinar un nueva
situación patrimonial en ese sentido, después de efectuadas las
operaciones mercantiles de dichos periodos.
4.2.4 INVENTARIO INICIAL
Es el que se realiza al dar comienzos de las operaciones.
37
4.2.5 INVENTARIO FISICO
Es el inventario real. Es contar, pesar, o medir y anotar todas y cada una de
las diferentes clases de bienes. Que se hallen en existencia en la fecha del
inventario, y evaluar cada una de dichas partidas. Se realiza como una lista
detallada y valoradas de las exigencias.
4.2.6 INVENTARIO MIXTO
Es de una clase de mercancías cuyas partidas no se identifican o no
pueden identificarse con un lote en particular.
4.2.7 INVENTARIO DE PRODUCTOS TERMINADOS
Este tipo de inventario es para todas las mercancías que un fabricante es
producido para vender a su cliente.
4.2.8 INVENTARIO EN TRANSITO
Es utilizada con el fin de sostener las operaciones para sostener las
operaciones para abastecer los conductos que ligan a las compañías con
sus proveedores y sus clientes, respectivamente.
Existe porque un material debe moverse de un lugar a otro, mientras el
inventario se encuentra en camino, no puede tener una función útil para las
plantas y los clientes, existen exclusivamente por el tiempo de transporte.
4.2.9 INVENTARIO DE MATERIA PRIMA
38
En él se representan existencias de los insumos básicos de los materiales
que habrá de incorporarse al proceso de fabricación de una compañía.
4.2.10 INVENTARIOS EN PROCESO
Son existencias que se tienen a medida que se añade mano de obra, otros
materiales y de más costos indirectos a la materia prima bruta, la que se
llegara a conformar ya sea un sub-ensamble o componente de un producto
terminado; mientras no concluya su proceso de fabricación, ha de ser
inventarios en procesos.
4.2.11 INVENTARIOS EN CONSIGNACIÓN
Es aquella mercadería que se entrega par ser vendida pero el título de
propiedad lo conserva el vendedor.
4.2.12 INVENTARIO MÁXIMO
Debido al enfoque de control de masas empleados, existe el riesgo que el
control de inventario pueda llegar demasiado alto para algunos artículos.
Por lo tanto se establece un control de inventario máximo. Se mide en
meses de demanda pronosticada.
4.2.13 INVENTARIO MINIMO
Es la cantidad mínima del inventario a ser mantenida en el almacén.
4.2.14 INVENTARIO DISPONIBLE
Es a aquel que se encuentran disponibles para la producción o venta.
39
4.2.15 INVENTARIO EN LINEA
Es aquel que aguarda a ser procesado en la línea de producción.
4.2.16 INVENTARIO AREGADO
Se aplica cuando al administrar las exigencias del único artículo representa
un alto costo, para minimizar el impacto del costo en la administración del
inventario, los artículos se agrupan ya sea en familia u otros tipos de
clasificación de materiales de acuerdo a su importancia económica
4.2.17 INVENTARIO EN CUARENTENA
Es aquel que debe de cumplir con un periodo de almacenamiento antes de
disponer del mismo, es aplicado a bienes de consumo, generalmente
comestible u otros.
4.2.18 INVENTARIO DE PREVISIÓN
Se tienen con el fin de cubrir una necesidad futura permanente definida. Se
diferencia con el respecto a los de seguridad, en que los de previsión se
tienen a la luz de una necesidad que se conoce con certeza razonable y por
lo tanto, involucra un menor riesgo.
4.2.19 INVENTARIO DE SEGURIDAD
Son aquellos que existen en un lugar dado de la empresa como resultado
de incertidumbre en la demanda u oferta de unidades en dicho lugar.
Los inventarios de seguridad concernientes a materias primas, protegen
contra la incertidumbre de la actuación de proveedores debido a factores
con el tiempo de espera, huelgas, vacaciones o unidades que al ser de la
40
mala calidad no podrán ser aceptadas. Se utilizan para prevenir faltantes
debido a fluctuaciones inciertas de la demanda.
4.2.20 INVENTARIO DE ANTICIPACIÓN
Son los que se establecen con anticipación a los periodos de mayor
demanda, a programas de producción comercial o a un periodo de cierre de
la planta. Básicamente los inventarios de anticipación almacenan horas-
trabajos y horas-máquinas para futuras necesidades y limitan los cambios
en la tasas de producción.
4.2.21 INVENTARIO DE LOTE O DE TAMAÑO DE LOTE
Estos son en tamaño que se piden en tamaño de lote porque es más
económico hacerlo así que pedirlo cuando sea necesario satisfacer la
demanda.
4.2.22 INVENTARIO ESTACIONALES
Los inventarios utilizados con este fin se diseñan para cumplir más
económicamente la demanda estacional variando los niveles de producción
para satisfacer fluctuaciones en la demanda.
También estos inventarios son utilizados para suavizar el nivel de
producción de las operaciones, para que los trabajadores no tengan que
contratarse o despedirse frecuentemente. Inventarios intermitentes: es un
inventario realizado con cierto tiempo y no de una sola vez al final del
periodo contable.
4.2.23 INVENTARIO PERMANENTES
41
Es un método seguido en el funcionamiento de algunas cuentas, en general
representativas de existencias, cuyo saldo ha de coincidir en cualquier
momento con el valor de los stocks.
4.2.24 INVENTARIOS CLÍNICOS
Son inventarios para apoyar la decisión de los inventarios; algunas de ellas
se consideran aceptables solamente en circunstancias especiales, en tanto
que otras son de aplicación general.
5 CONCEPTO DE SISTEMA DE VENTAS
Un sistema de ventas es en subsistema dentro de la unidad empresarial que
integre elementos necesarios de esta para conseguir que las necesidades de los
clientes sean satisfechas de una manera transparente con eficiencia y control
efectivo, tanto de dinero como de los créditos que se otorguen a los clientes.
5.1 DEFINICIONES
5.1.1 VENTA
Es la acción y efecto de vender (traspasar la propiedad de algo a otra
persona tras el pago de un precio convenido). El término se usa tanto para
nombrar a la operación en sí misma como a la cantidad de cosas que se
venden.
5.1.2 VENDEDOR
El vendedor es el elemento más importante de las ventas personales
porque permite establecer una comunicación directa y personal con los
clientes actuales y potenciales de la empresa, y además, porque tiene la
42
facultad de cerrar la venta y de generar y cultivar relaciones personales a
corto y largo plazo con los clientes.
5.1.3 CLIENTE
Cliente es la persona, empresa u organización que adquiere o compra de
forma voluntaria productos o servicios que necesita o desea para sí mismo,
para otra persona o para una empresa u organización; por lo cual, es el
motivo principal por el que se crean, producen, fabrican y comercializan
productos y servicios.
5.1.4 FACTURACION
Las facturas de venta son un instrumento que sirve como constancia para el
vendedor y para el comprador de la operación realizada. Describe en ella lo
que se ha comprado y por ende vendido, y el precio pagado. En este caso
el hecho descrito es la operación de compraventa. Se deben consignar en
ella los datos personales del comprador y del vendedor, sus domicilios y
sus condiciones respecto a las cargas impositivas. Se deben también dejar
anotados los datos de los productos o servicios vendidos (cantidad,
descripción de los mismos para identificarlos, precio unitario y precio total).
También debe aclararse las condiciones de venta (si es al contado o a
crédito, pagadero con cheque, en efectivo, con tarjera de crédito o débito, si
es al por mayor o por menor). Al emitir facturas el comerciante se obliga al
pago de impuestos por el importe facturado.
43
5.1.5 EL COMERCIO
Sin lugar a duda el proceso de globalización lleva a evolucionar el mercado,
a romper fronteras a destruir el paradigma que decía “Mercado es el lugar
donde se intercambian productos” ya sea en forma de trueque, venta,
crédito, etc.
Dentro del mercado existe una industria llamada del retail. Esta se refiere
principalmente al comercio minorita/detallista, pero antes de llegar a este
punto se dará una breve reseña histórica sobre cómo se origina y desarrolla
el comercio y mercado.
Con el desarrollo de la ciencia y la tecnología se han implementado nuevos
estilos de mercado no-físicos como el e-commerce, e-bussiness, remates
en línea, etc. Las cuales son un claro ejemplo de cómo la globalización es
un factor clave en la evolución de los mercados actuales ya que en estos
casos se han traspasados aspectos territoriales por el sólo hecho de
comprar algún producto.
Surgen algunas corrientes como la mundialización, que explican cómo se
están masificando el consumo, formas de vivir, gustos y preferencias, etc.
6 CONCEPTO DE FACTURACIÓN
Es La programación que se hace en las computadoras de una empresa o negocio,
para emitir facturas de manera eficaz, así capturar los datos del cliente ( para que
no los tengas que volver a capturar), describir el producto que se compra ( a veces
cada producto tiene un código y con solo ponerlo describe completamente el
producto), aparece automáticamente el número de factura, la fecha, el sub total iva
y total, la cadena original y el sello digital dos importantes datos fiscales, etc., sin
necesidad de que lo hagas manualmente, la finalidad es hacer más rápido y
eficiente el proceso de emisión de facturas, sobre todo en empresas que facturan
muy frecuente, le facilita el trabajo enormemente.
44
7 BASE DE DATOS
La base de datos es un almacén de datos relacionados con diferentes modos de
organización. Una base de datos representada algunos aspectos del mundo real,
aquellos que le interesan al diseñador. Se diseña y almacena datos con un
propósito específico.
De forma sencilla podemos indicar que una base de datos no es más que un
conjunto de información relacionada que se encuentra agrupada o estructurada.
Desde el punto de vista informático, una base de datos es un sistema formado por
un conjunto de datos almacenados en discos que permiten el acceso directo a
ellos y un conjunto de programas que manipulan ese conjunto de datos.
Desde el punto de vista más formal, podríamos definir una base de datos como un
conjunto de datos estructurados, fiables y homogéneos, organizados
independientemente en máquina, accesibles a tiempo real, compatibles por
usuarios concurrentes que tienen necesidades de información diferente y no
predecible en el tiempo.
7.1 SISTEMA DE GESTION DE BASE DE DATOS
7.1.1 DEFINICION
Los sistemas de gestión de base de datos son un tipo de software muy
específico, dedicado a servir de interfaz entre la base de datos, el usuario y
las aplicaciones que la utilizan.
Se compone de un lenguaje de definición de datos, de un lenguaje de
manipulación de datos y de un lenguaje de consulta.
El propósito general de los sistemas de gestión de base de datos es el de
manejar de manera clara, sencilla y ordenada un conjunto de datos.
7.1.2 CLASIFICACIÓN
45
MYSQL es un sistema gestor de bases de datos que se puede encuadrar dentro de la categoría de los programas open-source.
APACHE DERBY este es un sistema gestor de base de datos
relacional escrito en Java que puede ser embebido en aplicaciones
Java y utilizado para procesos de transacciones online.
DB2 es una marca comercial, propiedad de IBM, bajo la cual se
comercializa un sistema de gestión de base de datos, es un motor de
base de datos relacional que integra XML de manera nativa, lo que
permite almacenar documentos completos dentro del tipo de datos
xml para realizar operaciones y búsquedas de manera jerárquica
dentro de éste, e integrarlo con búsquedas relacionales.
POSTGRESQL es un sistema de gestión de base de datos relacional
orientada a objetos y libre, como muchos otros proyectos de código
abierto.
SQLITE es un sistema de gestión de bases de datos relacional
compatible con ACID.
FileMaker es una aplicación multiplataforma (Windows y Mac) de
base de datos relacional de FileMaker Inc. (una subsidiaria de Apple
Inc.). FileMaker integra el motor de la base de datos con la interfaz,
lo que permite a los usuarios modificar la base de datos al arrastrar
elementos (campos, pestañas, botones...) a las pantallas o formas
que provee la interfaz.
Visual FoxPro es un lenguaje de programación orientado a objetos y
procedural.
Paradox Base de datos relacional para entorno MS Windows,
anteriormente disponible para MS-DOS y Linux.
Microsoft SQL Server es un sistema para la gestión de bases de
datos producido por Microsoft basado en el modelo relacional.
Oracle Database es un sistema de gestión de base de datos objeto-
relacional desarrollado por Oracle Corporation.
SYBASE Principalmente conocida por su base de datos relacional
Adapative Server Enterprise (ASE).
46
7.1.3 MYSQL
7.1.3.1 DEFINICIÓN
La conectividad, velocidad y seguridad hace de MySQL altamente
conveniente para acceder a base de datos en Internet. Sistema de Gestión
de Base de Datos. Una implementación Cliente Servidor, basado en el
álgebra relacional, se caracteriza por disponer toda la información contenida
en tablas, y las relaciones entre datos deben ser representadas
explícitamente en esos mismos datos.
Es un software de código abierto escrito en C y C++, accesible para
cualquiera para usarlo y modificarlo. MySQL usa el GPL (GNU Licencia
Publica General) no nos cuesta dinero a menos que lo incluyamos en un
software comercial.
7.1.3.2 INTERIORES Y PORTABILIDAD
El principal objetivo de MySQL es velocidad y robustez.
Escrito en C y C++
Usa tablas en disco B-Tree muy rápidas con compresión de
índice.
Multiproceso, es decir puede usar varias CPU si éstas están
disponibles.
Puede trabajar en distintas plataformas y S.O. distintos.
7.1.3.3 SEGURIDAD
47
Sistema de contraseñas y privilegios muy flexible y segura (se encriptan
cuando se conectan a un servidor).
7.1.3.4 ESCALABILIDAD Y LIMITES
Registros de longitud fija y variable. Se permite hasta 64 índices
por tabla. Cada índice puede consistir desde 1 hasta 16 columnas
o partes de columnas. El máximo ancho de límite son 1000 bytes.
Un índice puede usar prefijos de una columna para los tipos de
columna CHAR, VARCHAR, BLOB, o TEXT.
Diversos tipos de columnas como enteros de 1, 2, 3, 4, y 8 bytes,
coma flotante, doble precisión, carácter, fechas, enumerados, etc.
Todos los datos están grabados en formato ISO8859_1.
7.1.3.5 CONECTIVIDAD
Los clientes usan TCP/IP (para cualquier plataforma), en
Windows pueden usar names pipes y en Unix utilizan socket unix
para conectarse al servidor.
El servidor soporta mensajes de error en distintas lenguas
(permite escoger el lenguaje).
Todos los comandos tienen -help o -? Para las ayudas.
ODBC (Open Database Connectivity), se puede utilizar ACCESS
para conectar con el servidor MySQL y los clientes pueden
ejecutarse en Windows o Unix.
48
8 LA EMPRESA MINI MERCADO “LA GLORIA”
El mini mercado La Gloria se encuentra ubicada en la ciudad de La Paz, zona
Achachicala calle 3 en la avenida Ramos Gavilán #395, el mini mercado la Gloria
es una micro empresa, inscrita como persona natural y representada por Carola
Quispe, creada el 25 de mayo del año 2003 en la ciudad de La Paz, tiene como
objetivo la venta de productos de primera necesidad como ser; abarrotes,
productos lácteos, productos de limpieza, alimentos frescos, etc., ofrece a su
clientela:
• Atención amable y trato preferencial a sus clientes
• Productos frescos, limpios y garantizados.
• Peso completo.
• Rapidez en la atención.
8.1 MISIÓN
Proveer a nuestros clientes, una amplia variedad de productos de calidad y un
servicio de excelencia y así brindar una buena atención y satisfacer las
necesidades de nuestros clientes.
8.2 VISIÓN
Ser líder en la comercialización de productos de primera necesidad, tener
calidad y servicio, tener el conocimiento para satisfacer las necesidades y
expectativas de nuestros clientes y así contribuir al desarrollo económico de
nuestro país.
49
9 ORGANIGRAMA
Grafico 13 – Organigrama de la Empresa
CAPITULO 3
MARCO PRÁCTICO
50
III. MARCO PRACTICO
1. INTRODUCCION
El desarrollo del presente proyecto tiene por objetivo crear el Sistema de
inventario y ventas para el mini mercado La Gloria utilizando la metodología ágil
SCRUM.
Como primer punto se establecen los requerimientos funcionales del sistema
mediante la historia de usuarios. A partir de estos requerimientos se continúa con
la planificación de las tareas que serán implementadas conocidas como pilas del
producto, determinando un periodo de trabajo y asignado prioridades para su
desarrollo. Este proceso iterativo de manera cíclica permite desarrollar las pilas de
sprints. Finalmente se logra obtener un producto de calidad cumpliendo con las
características funcionales mínimas exigidas por la metodología.
1.1.EQUIPO SCRUM
Persona Contacto Rol
PRODUCT OWNER Carola Quispe Propietario del producto para quien se desarrolla el sistema
SCRUM MASTER Jesús Remigio Gestor del desarrollo del proyecto. Está encargado de recopilar y conformar la pila del sprint con la ayuda del Product Owner.
Cumple las funciones de analizar y diseñar el sistema.
SCRUM TEAM Jesús Remigio Programador del sistema. Se encarga de implementar cada una de las tareas establecidas
Tabla 6 - Visión general del proceso
51
2. PILA DE PRODUCTOS
ID NOMBRE PRIORIDAD ESTIMACION1 Acceso al sistema 1 82 Ingreso de Productos 2 33 Generación de Ordenes de Compra 4 34 Ingreso y Modificación de Categorias de Productos 8 35 Venta de Productos 3 46 Registro de Personal 9 27 Registro de Facturas 6 88 Impresión de Facturas 7 89 Roles por usuario 10 1
10 Tipos de Usuarios 11 211 Consulta de Productos 12 312 Diseño de Pagina WEB 5 12
Tabla 7 – Pila de Productos
ID NOMBRE PRIORIDAD ESTIMACION1 Acceso al sistema 12 Ingreso de Productos 23 Registro de Clientes 104 Generación de Ordenes de Compra 45 Registro de Ordenes de Compra 56 Ingreso y Modificación de Categorias de Productos 87 Venta de Productos 38 Registro de Personal 119 Registro de Facturas 7
10 Impresión de Facturas 911 Roles por usuario 1212 Tipos de Usuarios 1313 Roles de Cajeros 1414 Consulta de Productos 1515 Diseño de Pagina WEB 6
52
2.1.HISTORIAS DE USUARIO
2.1.1. HISTORIAS DE USUARIO SPRINT 1
53
Número: 1
Riesgo en desarrollo: Baja
Iteración asignada: 1
Descripción: Cliente requiere que almomento de ingresar a la aplicación le solicite usuario y password.
Observación: La aplicación contara con una tabla donde se registraran los datos del usuario, tambien se registrara el rol para que acceda solo a los modulos que le corresponda según cargo.
Programador responsable: Jesús Remigio Pérez
Usuario: Administrador del Sistema, Administrador del Negocio, Cajero.
HISTORIA DE USUARIO
Nombre Historia: Acceso a la aplicación
Puntos estimados: 4
Prioridad en negocio: Baja
Tabla 8 – Historia de Usuario: Acceso a la aplicación
54
Número: 2
Riesgo en desarrollo: Alta
Iteración asignada: 1
Descripción: Cliente quiere el ingreso de productos a la aplicación.
Observación: La aplicación contara con tablas donde se registraran los productos, ordenes de compra y proveedores.
Programador responsable: Jesús Remigio Pérez
Usuario: Administrador del Negocio
HISTORIA DE USUARIO
Nombre Historia: Ingreso de Productos
Puntos estimados: 3
Prioridad en negocio: Alta
Tabla 9 – Historia de Usuario: Ingreso de Productos
55
Número: 2
Riesgo en desarrollo: Alta
Iteración asignada: 1Puntos estimados: 4
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente, requiere un registro de las ventas de productos, descuente lo vendido del inventario, calcule el total vendido, genere un detalle de lo que se esta vendiendo y se imprima.
Observación: La aplicación contara con tablas de ventas donde se registrara lo vendido y conexiones con tablas de productos para descontar del inventario.
HISTORIA DE USUARIO
Usuario: Administrador del Negocio, Cajero
Nombre Historia: Venta de Productos
Prioridad en negocio: Alta
Tabla 10 – Historia de Usuario: Venta de Productos
56
Número: 6
Riesgo en desarrollo: Media
Iteración asignada:
Observación: La aplicación contara con tablas de empleados donde se registraran los datos requeridos por el usuario, estas deberán relacionarse con los módulos de roles.
Prioridad en negocio: Media
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente, requiere que se registre los empleados con sus datos personales, se registre las funciones del empleado y se genere el código de empleado.
HISTORIA DE USUARIO
Usuario: Administrador del Negocio
Nombre Historia: Registro del Personal
Puntos estimados: 2
Tabla 11 – Historia de Usuario: Registro de Personal
57
2.2.PLANIFICACION DE LOS SPRINTS
2.2.1. ESTIMACION DE SPRINT
SPRINT 1 SPRINT 2 SPRINT 3ESTIMACION 3 Semanas 3 Semanas 3 Semanas
Tabla 12 – Estimación de Sprint
2.2.2. DEFINICION DE SPRINT 1
ID NOMBRE PRIORIDAD ESTIMACION1 Acceso al sistema 1 82 Ingreso de Productos 2 36 Venta de Productos 3 4
15
ID NOMBRE
1 Acceso al sistema7 Venta de Productos2 Ingreso de Productos
Tabla 13 – Tabla general de Sprint 1
2.2.3. DETALLES DE TAREAS DEL SPRINT 1
Tabla 14 – Tabla detallada tarea: Acceso al Sistema
58
ID NOMBRE PRIORIDAD2 Ingreso de Productos 2
creación función ingresar productocreación función nuevo proveedorcreación función nueva orden de compra
Creación interfaz web (Formulario)Creación función verifica orden de compraCreación función carga datos de proveedorCreación función ID productoCreación función carga datos de productos al formulario
Tabla 15 – Tabla detallada tarea: Ingreso de productos
ID NOMBRE PRIORIDAD6 Venta de Productos 3
Creación función de Imprimir detalle de ventaCreación función de venta
Creación de función registro cantidad de productosCreación función descuento del inventarioCreación función calculo monto de la compra de productoCreación de función Sub total del calculo de compraCreación función registro de ventaCreación de función de nuevo registro de ventaCreación función finalizar ventaCreación función tipo de pagoCreación función registro de pago efectivoCreación funcion calculo de cambioCreación función de listar detalle de productos a vender
Creación de función visualiza precio unitario de producto
Creación tabla de ventasCreación tabla de facturasCreación interfaz grafica de usuarioCreación función registro de cajeroCreación función adición de clientesCreación función verificación de productosCreación función visualiza nombre de productos
59
Tabla 16 – Tabla detallada tarea: Venta de productos
2.2.4. TAREAS REALIZADAS SPRINT 1: ACCESO AL SISTEMA
0
2
4
6
8
10
12
Acceso a la AplicaciónTarea: Acceso al Sistema - Sprint 1Tarea: Acceso al Sistema - Sprint 1 Real-izado
Grafico 14 - Burn Down: Acceso a la Aplicación
60
Grafico 15 - Ingreso a la Aplicación
Grafico 16 – Roles por tipo de usuario
61
2.2.5. TAREAS REALIZADAS SPRINT 1: INGRESO DE PRODUCTOS
62
Grafico 17 - Burn Down: Ingreso de Productos
63
Grafico 18 - Ingreso de productos
64
2.2.6. TAREAS REALIZADAS SPRINT 1: VENTA DE PRODUCTOS
Grafico 19 - Burn Down: Venta de Productos
65
Grafico 20 - Venta de productos
Grafico 21 – Impresión venta de productos
66
2.2.7. TAREAS ADICIONALES EN SPRINT 1
2.2.7.1. TAREA REALIZADA SPRINT 1: REGISTRO DE PERSONAL
ID NOMBRE PRIORIDAD6 Registro de Personal 9
Creación de función de codigo/Login/password de empleadoCreación de función de adicionar datos de empleadoCreación de función de nuevo empleado
Creación de tabla de empleadosCreación de interfaz grafica (Formulario)Creación función de carga de datos de empleadosCreación de función de carga de direcciónCreación de función de fecha de ingreso/cargo/Sueldo/turno de empleado
Tabla 17 – Registro de Personal
Grafico 22 - Burn Down: Registro de Personal
67
Grafico 23 - Registro de Personal
68
2.2.8. INFORME SPRINT 1
Se entregó a la Sra. Carola Quispe (product owner) el primer sprint y se le
mostro la aplicación con el desarrollo de lo planificado. Adicional a las
tareas planificadas para este Sprint, se tuvo que adicionar dos tareas, ya
que eran parte importante para el control de los accesos (Registro de
personal y Roles por usuario), mismos que no fueron contemplados en el
relevamiento inicial, esta adición de nuevas tareas genero mayor carga de
trabajo en el desarrollo pero se llegó a la meta trazada.
El product owner observo que en la venta de productos solicitaba ingresar
la fecha y hora presionando un botón y solicito que esto se marque en
forma automática, por lo que se realizó un pequeño ajuste, otra observación
fue que al momento de calcular el monto total salía con muchos decimales,
por lo que se realizó ajustes en el script de suma de la función que calcula
el monto total para que redondee a 2 decimales.
69
2.3.HISTORIAS DE USUARIO SPRINT 2
Número: 3
Riesgo en desarrollo: Medio
Iteración asignada:Puntos estimados: 3
HISTORIA DE USUARIO
Usuario: Administrador del Negocio
Nombre Historia: Generación de órdenes de compra
Prioridad en negocio: Media
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente, requiere que se pueda generar las órdenes de compra para los provedores, también se debe poder imprimir.
Observación: Aplicación contara con tablas donde se podrá registrar las órdenes de compra, donde se podrá realizar el seguimiento de los productos.
Tabla 18 – Historia de usuario: Generación de órdenes de compra
70
Número: 13
Riesgo en desarrollo: Baja
Iteración asignada:
HISTORIA DE USUARIO
Usuario: Administrador del Sistema, Administrador del Negocio, Cajero
Nombre Historia: Diseño de página WEB
Prioridad en negocio: Baja
Puntos estimados: 12
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente, requiere una aplicación que sea fácil de usar.
Observación: Aplicación contara con un diseño sencillo y fácil de usar.
Tabla 19 – Historia de usuario: Diseño de página WEB
71
HISTORIA DE USUARIO
Número: 8/9 Usuario: Cajero
Nombre Historia: Registro e Impresión de Facturas
Prioridad en negocio: Media Riesgo en desarrollo: Medio
Puntos estimados: 8/8 Iteración asignada:
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente requiere que se registre las facturas al momento de realizar la venta y que también se pueda imprimir.
Observación: Aplicación contara con una tabla donde se registren las facturas y podrá realizar la impresión de facturas,
Tabla 20 – Historia de usuario: Registro e Impresión de Facturas
2.3.1. DEFINICION DE SPRINT 2
72
ID NOMBRE PRIORIDAD ESTIMACION3 Generación de ordenes de Compra 4 3
13 Diseño de Pagina WEB 5 128 Registro de Facturas 6 89 Impresión de Facturas 7 8
31
Tabla 21 – Definición de Sprint 2
2.3.2. DETALLE DE TAREAS DEL SPRINT 2
ID NOMBRE PRIORIDAD3 Generación de Ordenes de Compra 4
Creación función calculo de precio de compracreación función ingresar productocreación función nuevo proveedorcreación función nueva orden de compraCreación función listar orden de compraCreación función imprimir orden de compra
Creación interfaz webCreación función genera orden de compraCreación función de validación de proveedorCreación función carga datos de proveedorCreación función validación de producto
Creación de tabla de productosCreación tabla de proveedorCreación tabla categoría
Tabla 22 – Detalle tarea: Generación de órdenes de compra
ID NOMBRE PRIORIDAD5 Diseño de página WEB 8
Definir los estilosBuscar imágenes e iconos
Determinar el formato grafico
73
Tabla 22 – Detalle tarea: Diseño de página WEB
ID NOMBRE PRIORIDAD7/8 Registro / Impresión de Facturas 6/7
Creación función Impresión facturaCreación formulario de factura
Creación función adiciona factura al formularioCreación función genera factura
Tabla 23 – Detalle tarea: Registro e impresión de Facturas
2.3.3. TAREAS REALIZADAS SPRINT 2: GENERACION ORDENES DE
COMPRA
74
Grafico 24 - Burn Down: Generación de Orden de compra
75
Grafico 25 - Generación de Orden de compra
Grafico 26 - Formulario de orden de compra
76
2.3.4. TAREAS REALIZADAS SPRINT 2: DISEÑO PAGINA WEB
Grafico 27 - Ingreso a la aplicación
Grafico 28 - Menú principal
Grafico 29 - Menú de orden de compra
77
Grafico 30 - Formulario de orden de compra
2.3.5. TAREAS REALIZADAS SPRINT 2: REGISTRA/IMPRIME
FACTURAS
Grafico 31 - Burn Down: Registra e imprime Factura.
78
2.3.6. INFORME SPRINT 2
Se entregó a la Sra. Carola Quispe (product owner) el segundo sprint con el
desarrollo de lo planificado. Se presentó y explico el funcionamiento de los
módulos implementados y el producto owner estaba de acuerdo.
Se hizo la revisión de las tareas a detalle y se identificó que las tareas 7 y 8
(registro e impresión de facturas) eran afines por lo que se decidió
realizarlos en una sola tarea.
No se tuvo mayor inconveniente ni observaciones por parte del usuario.
79
2.4.HISTORIAS DE USUARIO SPRINT 3
Número: 5
Riesgo en desarrollo: Media
Iteración asignada:
HISTORIA DE USUARIO
Usuario: Administrador del Sistema y Administrador del Negocio
Nombre Historia: Ingreso y Modificación de categorías de productos
Prioridad en negocio: Media
Puntos estimados: 3
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente requiere poder ingresar, modificar y eliminar las categorías de los productos.
Observación: La aplicación contara con una tabla de categorías de productos donde se registraran y tambien se podrá listar.
Tabla 23 – Historia de Usuario: Ingreso y modificación de categorías de productos
80
Número: 10
Riesgo en desarrollo: Baja
Iteración asignada:
Prioridad en negocio: Baja
Puntos estimados: 2
Programador responsable: Jesús Remigio Pérez
Descripción: La aplicación requiere se cree un módulo de tipos de usuarios donde se registraran los diferentes cargos que existirán en el mini mercado.
Observación: Aplicación consultara la tabla empleados donde se registra el cargo y podrá realizar ABM.
Nombre Historia: Tipos de usuarios
HISTORIA DE USUARIO
Usuario: Administrador del Sistema y Administrador del Negocio
Tabla 24 – Historia de Usuario: Tipo de usuarios
81
Número: 5
Riesgo en desarrollo: Baja
Iteración asignada:
Observación: La aplicación contara con una conexión a la tabla de productos para realizar las consultas.+A28A15:C39
Prioridad en negocio: Baja
Puntos estimados: 3
Programador responsable: Jesús Remigio Pérez
Descripción: Cliente requiere poder consultar los productos agotados, cantidad que tiene en stock, stock mínimo y listar los productos.
HISTORIA DE USUARIO
Usuario: Administrador del Sistema y Administrador del Negocio
Nombre Historia: Consulta de Productos
Tabla 25 – Historia de Usuario: Consulta de Productos
82
2.4.1. DEFINICION SPRINT 3
ID NOMBRE PRIORIDAD ESTIMACION5 Ingreso y Modificación de Categorías de Productos 8 3
10 Tipos de Usuarios 11 211 Consulta de Productos 12 3
Tabla 26 – Definición Sprint 3
2.4.2. DETALLE DE TAREAS DEL SPRINT 3
ID NOMBRE PRIORIDAD5 Ingreso y Modificación de Categorías de Productos 8
Creación función Adición de categoríasCreación función Modificar categoríasCreación función Eliminar categoríasCreación función Buscar categoríasCreación función Nueva categoríacreación función Listar categorías
Creación interfaz web (Formulario)
Tabla 27 – Detalle de tareas: Ingreso y modificación de categorías de productos
ID NOMBRE PRIORIDAD10 Tipos de usuarios 11
Creación interfaz web (Formulario)Creación función Adición tipo de usuarioCreación función Modificar tipo de usuarioCreación función Eliminar tipo de usuarioCreación función Buscar tipo de usuarioCreación función Nueva tipo de usuariocreación función Listar tipo de usuario
Tabla 28 – Detalle de tareas: Tipos de usuarios
83
ID NOMBRE PRIORIDAD11 Consulta de Productos 12
Creación función listar todos los productosCreación función listar por categoríaCreación función Limpiar
Creación interfaz web (Formulario)Creación función Buscar ProductosCreación función Lista productos agotados
Tabla 29 – Detalle de tareas: Consulta de Productos
2.4.3. TAREAS REALIZADAS SPRINT 3: INGRESO Y MODIFICACION
DE CATEGORIAS
Grafico 32 - Burn Down: Ingreso y modificación de categorías de productos.
84
Grafico 33 - Ingreso y modificación de categorías de productos.
2.4.4. TAREAS REALIZADAS SPRINT 3: TIPOS DE USUARIO
Grafico 34 - Burn Down: Tipos de Usuarios
85
Grafico 35 - Formulario Tipos de Usuarios
2.4.5. TAREAS REALIZADAS SPRINT 3: CONSULTA POR PRODUCTO
Grafico 36 - Burn Down: Consulta por producto
86
Grafico 36 - Formulario: Consulta por producto
2.4.6. INFORME SPRINT 3
Se entregó a la Sra. Carola Quispe (product owner) el tercer sprint con el
desarrollo de lo planificado. Se presentó y explico el funcionamiento de los
módulos implementados y el producto owner estaba de acuerdo.
No se tuvo mayor inconveniente ni observaciones por parte del usuario.
87
10 CONCLUSIONES Y RECOMENDACIONES
10.1 CONCLUSIONES
Se logró identificar la necesidad fundamental que existe en el mini
mercado con respecto al manejo de inventario de productos disponibles
para la venta.
El proceso de desarrollo del aplicativo web se cumplió con lo planeado y
cumple con los requerimientos del personal que maneja el inventario y
venta de los productos del mini mercado.
Se realizó el diseño del sistema en base a la metodología SCRUM.
Se desarrollaron los módulos del sistema con sus respectivas
funcionalidades.
Se realizaron las pruebas del funcionamiento de los módulos de
sistema.
10.2 RECOMENDACIONES
Se recomienda que una vez implementado el software de inventario este
se alimente de la manera más rápida con la información actual de los
productos.
Se recomienda que en un corto plazo o de acuerdo a la necesidad y
crecimiento del mini mercado se implemente el registro, venta de
productos con lector de código de barras y el sistema contable.
88
11 BIBLIOGRAFIA
Carballar, D. (2011). Introducción a la Ingenieria de Software. Recuperado
el Septiembre de 2013, de:
http://www.eduinnova.es/dic09/Ingenieria_Software.pdf
CitónM. (2006). Método ágil scrum aplicado al desarrollo de un software de
trazabilidad. Artgentina.
Henrik Kniberg, SCRUM y XP desde las Trincheras
Hicks. Introducción a la Ingeniería Industrial y Ciencias de la
Administración, p 106, 1977, Ed. Mc Graw- Hill
Ian Gilfillan, La Biblia de MySql
INTECO. (2009). Ingeniería del software: metodologías y ciclos de vida.
Laboratorio Nacional de Calidad del Software de INTECO.
Joseph Schmuller, Aprendiendo UML en 24 horas.
Kennett E. Kendall, Julio E. Kendall, Análisis y diseño de Sistemas.
Kenneth C. Laudon, Jane P. Laudon, Administración de los Sistemas de
Información, pag 8-9-15.
Max Muller, Fundamentos de la Administración de Sistemas
Roger S. Pressman, Ingeniería del Software, Un enfoque práctico.
Raul Horacio Saroka, Sistemas de Información, p 47
Richard J. Tersine, Principles of Inventory and Materials Management, p 2-
3, 1999, Ed. North-Holland
Sommerville, I. (2005). Ingeniería del software. Pearson Educación.
Venezuela, U. d. (Julio de 2012). Metodologías para el desarrollo de
software. Recuperado en agosto de 2013, de
http://wiki.monagas.udo.edu.ve/index.php/Metodolog
%C3%ADas_para_el_desarrollo_de_software#Metodolog.C3.ADas_Vs._Ci
clo_de_vida
