Universidad Evangélica Nicaragüense Martin Luther KingEscuela de Ingeniería
Ingeniería en Sistemas de Computación Automatizados
Desarrollo de un Sistema Web de Control de Inventario y Facturación en el Minisuper Silva
Para optar al título de: Ingeniero en Sistemas de Computación Automatizados.
Autores: JadderArcia Cordero. Herty Izaguirre González. Bayardo Cruz Picón.
Tutora: MSc. Blanca Antonia Rodríguez Martínez
Managua, Nicaragua2013
DEDICATORIA
Primeramente a Dios, que es el creador de todas las cosas el que nos ha dado las
fuerzas, por darnos la oportunidad de vivir y por estar con nosotros en cada paso
que damos, por fortalecer nuestros corazones y por haber puesto en nuestros
caminos a aquellas personas que han sido nuestros soporte y bendición durante
todos los años de estudios.
A nuestros padres, por apoyarnos en la culminación de nuestras carreras
profesional, por regalarnos la vida, los queremos mucho, gracias por creer en
nosotros y brindarnos su apoyo en los momentos difíciles. Padres, estaremos
agradecidos infinitamente por sus esfuerzos, todo esto se los debemos a ustedes.
A la Universidad Evangélica Nicaragüense, por forjar nuestros conocimientos para
nuestra formación académica y personal.
Finalmente a los maestros, aquellos que marcaron cada etapa de nuestro camino
universitario.
JadderArcia Cordero.
Herty Izaguirre González.
Bayardo Cruz Picón.
Página II
AGRADECIMIENTO
Agradecemos a Dios por habernos acompañado y guiado a lo largo de nuestras
carreras, siendo la fortaleza en los momentos de debilidad y facilitarnos una vida
llena de aprendizajes, experiencias y sobre todo felicidad.
Les damos las gracias a nuestros padres, por apoyarnos incondicionalmente, sus
sacrificios nos han dado la oportunidad de tener una excelente educación en el
transcurso de nuestras vidas. Sobre todo por ser un excelente ejemplo de vida a
seguir.
A nuestras familias por su constante apoyo y dedicación. A nuestros docentes por
su continuo apoyo a través de estos cinco años de estudio, brindándonos las
herramientas necesarias para convertirnos en profesionales con ética, capacidad y
liderazgo.
A nuestra tutora Msc. Blanca Antonia Rodríguez Martínez por guiarnos en cada
una de las etapas del desarrollo de nuestro trabajo de culminación de estudios de
pregrado.
A la Universidad Evangélica Nicaragüense por ser garante de nuestro desarrollo, a
sus planes sociales becarios que apoyan y ayudan al conglomerado de
Estudiantes, por habernos brindado las bases para un futuro de éxito y
buenaventura.
JadderArcia Cordero.
Herty Izaguirre González.
Bayardo Cruz Picón.
Página III
RESUMEN
El objetivo principal del presente trabajo de tesis es el desarrollo de un sistema de
control de inventario y facturación en el Minisuper Silva, con el fin de dar solución
a los inconvenientes que presenta esta área por no contar con un sistema efectivo
que permita manipular la cantidad de información de las operaciones que se
realizan diariamente.
Se empleó la investigación es de carácter proyectivo, con un nivel comprensivo y
un diseño de campo; empleándose como técnicas de recolección de datos la
revisión documental, la entrevista y la observación directa, con el fin de extraer
información del lugar objeto de estudio.
Para la construcción de este sistema se utilizó la metodología Watch
conjuntamente con el lenguaje UML (Lenguaje Unificado de Modelado). Los
resultados obtenidos con este desarrollo están enfocados a la reducción de los
tiempos de manejo de la información, riesgos de la pérdida de datos y generación
de reportes de gestión con mayor rapidez pa
ra la toma de decisiones gerenciales efectivas con mínimos porcentajes de error.
Página IV
CONTENIDO
DEDICATORIA................................................................................................................................ II
AGRADECIMIENTO......................................................................................................................III
RESUMEN...................................................................................................................................... IV
CONTENIDO...................................................................................................................................V
LISTA DE FIGURAS......................................................................................................................VI
LISTA DE CUADROS...................................................................................................................VII
1. INTRODUCCION........................................................................................................................1
2. OBJETIVOS................................................................................................................................2
OBJETIVO GENERAL................................................................................................................2
OBJETIVOS ESPECIFICOS......................................................................................................2
3. JUSTIFICACION........................................................................................................................2
4. CAPITULO 1: MARCO TEÓRICO...........................................................................................3
4.1 BASES TEORICAS..............................................................................................................3
4.1.1 Sistemas Web................................................................................................................3
4.1.2 Características...............................................................................................................4
4.1.3 Tecnologías....................................................................................................................5
4.1.4 Importancia.....................................................................................................................5
4.2 METODOLOGIA...................................................................................................................5
4.2.1 Método Watch................................................................................................................5
4.1.2 Objetivos del método Watch........................................................................................6
4.1.3Características del método Watch................................................................................6
4.1.4 Componentes del método Watch................................................................................7
4.1.4 Modelo de Producto......................................................................................................7
4.1.5 Modelo de Actores.........................................................................................................8
4.1.6 Modelo de Procesos......................................................................................................9
4.1.7 Lenguaje Unificado de Modelado................................................................................9
4.3 HERRAMIENTAS DE DESARROLLO.............................................................................10
4.3.1 Consolidado tecnológico.............................................................................................10
4.3.2 SQL Server 2008.........................................................................................................10
4. CAPITULO II: MARCO METODOLOGICO...........................................................................11
Página V
5.1 TRABAJO DE INVESTIGACION......................................................................................11
5.1.1 Tipo y Nivel de la Investigación.................................................................................11
5.1.2 Población y Muestra....................................................................................................11
5.1.3 Técnicas e Instrumentos de Recolección de Datos................................................11
5.1.4 Técnicas de Análisis de Datos...................................................................................11
5.1.5 Diseño Operativo.........................................................................................................11
5.1.6 Plan de Actividades.....................................................................................................13
6. CAPITULO III: DESAROLLO..................................................................................................14
6.1 CONTEXTO ORGANIZACIONAL.....................................................................................14
6.1.1 Antecedentes...............................................................................................................14
6.2 FASE 1- ANALISIS DE SISTEMA....................................................................................14
6.2.1 Documento Inicio del Proyecto..................................................................................14
6.2.2 Documento del Proceso de Instanciación del Método............................................22
6.2.3 Plan Integral del Proyecto..........................................................................................25
6.2.4 Plan Gestión de Riesgo..............................................................................................28
6.2.5 Plan Gestión de Configuración..................................................................................32
6.2.6 Modelado del Negocio................................................................................................35
6.2.7 Modelado del Sistema.................................................................................................42
6.3 FASE 2- DISEÑO DEL SISTEMA.....................................................................................61
6.3.1 Documento Diseño Arquitectónico............................................................................61
6.4 FASE 3- IMPLEMENTACION DEL SISTEMA................................................................67
6.4.1 Documento Implantación del Software.....................................................................67
7. CONCLUSIONES.....................................................................................................................72
8. RECOMENDACIONES............................................................................................................73
9. BIBLIOGRAFIA.........................................................................................................................74
10. ANEXOS.............................................................................................................................77
LISTA DE FIGURAS
Figura 1. Componentes del Método Watch.................................................................................7Figura 2. Tipos de Productos del Método Watch........................................................................8
Página VI
Figura 3. Clasificación de Actores del Método Watch................................................................8Figura 4. Clasificación de Procesos del Método Watch.............................................................9Figura 5. Diagrama de Gantt.......................................................................................................13Figura 6. Organigrama del área de objeto de estudio..............................................................14Figura 7. Clasificación de los Procesos del Método Watch durante el desarrollo del proyecto..........................................................................................................................................24Figura 8. Modelo de jerarquía del Sistema de Cita..................................................................36Figura 9. Diagrama de Objetivos de los Procesos del Sistema de Cita................................37Figura 10. Cadena de Valor del Negocio...................................................................................38Figura 11. Jerarquía de Procesos del Negocio.........................................................................39Figura 18. Diagrama de Actividad de Programar Cita..............................................................40Figura 19. Diagrama de Actividad de Elaboración de Histórico de Cita................................41Figura 20. Diagrama de Caso de Uso del Sistema..................................................................42Figura 21. Diagrama de Caso de Uso Gestión de Usuarios...................................................44Figura 22. Diagrama de Caso de Uso Gestión de Citas..........................................................47Figura 23. Diagrama de Caso de Uso Gestión de Históricos..................................................52Figura 24. Diagrama de Secuencia Autenticar Usuario...........................................................56Figura 25. Diagrama de Secuencia Buscar Usuario................................................................56Figura 26. Diagrama de Secuencia Crear Usuario...................................................................57Figura 27. Diagrama de Secuencia Editar Usuario..................................................................57Figura 28. Diagrama de Secuencia Realizar Solicitud.............................................................58Figura 29. Diagrama de Secuencia Aprobar Solicitud.............................................................58Figura 30. Diagrama de Secuencia Reprogramar Cita............................................................59Figura 31. Diagrama de Secuencia Cancelar Cita...................................................................59Figura 32. Diagrama de Secuencia Buscar Cita Mantenimiento............................................60Figura 33. Diagrama de Secuencia Ver Detalle Cita Mantenimiento.....................................60Figura 28. Arquitectura del Sistema...........................................................................................62Figura 29. Diagrama de Clases del Sistema.............................................................................63Figura 30. Diagrama de Componentes del Sistema.................................................................64Figura 31. Diseño lógico de la Base de Datos..........................................................................65Figura 32. Diseño Físico de la Base de Datos..........................................................................66
LISTA DE CUADROS
Cuadro 1. Consolidado Tecnológico...........................................................................................10Cuadro 2. Diseño Operativo........................................................................................................12
Página VII
Cuadro 3. Plan de Actividades....................................................................................................13Cuadro 4. Organización del personal del área de taller...........................................................18Cuadro 5. Interesados del Proyecto...........................................................................................19Cuadro 6. Identificación de Interesados del Proyecto..............................................................20Cuadro 7. Productos que generan la Metodología Watch.......................................................25Cuadro 8. Riesgo 1 a administrar en el proyecto......................................................................29Cuadro 9. Riesgo 2 a administrar en el proyecto......................................................................29Cuadro 10. Riesgo 3 a administrar en el proyecto...................................................................30Cuadro 11. Riesgo 4 a administrar en el proyecto...................................................................30Cuadro 12. Riesgo 5 a administrar en el proyecto...................................................................31Cuadro 13. Riesgo 6 a administrar en el proyecto...................................................................31Cuadro 14. Riesgo 7 a administrar en el proyecto...................................................................32Cuadro 15. Riesgo 8 a administrar en el proyecto...................................................................32Cuadro 25. Especificación del Caso de Uso Autenticar Usuario............................................43Cuadro 26. Especificación del Caso de Uso Gestión de Usuario...........................................44Cuadro 27. Especificación del Caso de Uso Crear Usuario....................................................45Cuadro 28. Especificación del Caso de Uso Editar Usuario...................................................46Cuadro 29. Especificación del Caso de Uso Gestión de Citas...............................................47Cuadro 30. Especificación del Caso de Uso Realizar Solicitud..............................................48Cuadro 31. Especificación del Caso de Uso Aprobar Solicitud..............................................49Cuadro 32. Especificación del Caso de Uso Reprogramar Cita.............................................50Cuadro 33. Especificación del Caso de Uso Cancelar Cita....................................................51Cuadro 34. Especificación del Caso de Uso Gestión de Históricos.......................................52Cuadro 35. Especificación del Caso de Uso Buscar Cita........................................................53Cuadro 36. Especificación del Caso de Uso Buscar Cita de Mantenimiento........................54Cuadro 37. Especificación del Caso de Uso Ver Detalle de Cita de Mantenimiento...........55Cuadro 29. Especificación de Caso de Prueba Usuario..........................................................69Cuadro 30. Especificación de Caso de Prueba Gestión de Histórico....................................70
Página VIII
1. INTRODUCCION
En la actualidad las pequeñas y medianas empresa necesitan el apoyo del los
sistemas de informacion para agilizar sus procesos de una manera mas exacta y
eficaz el supermercado silva se dedicara a venta de productos para el hogar en lo
que refiere a granos basicos, carnes , utencilios de cocina etc.
Esta tesis consiste en desarrollar un sistema de control de inventario y facturación
la cual constara con una base de datos donde se encontrara la información del
producto con el fin de brindar un servicio de exactitud en los precios de cada
producto que obtenga el cliente
Para ingresar datos los empleados (cajeros) utilizaran recursos tecnológicos como
cajas registradoras, computadoras,scaner, balanzas electrónicas etc.
La realidad de participar en un mercado es cada vezmás competitiva, dentro de un
entorno departamental ya que obliga a mejorar la calidad de estrategias de
producción, costos, administración y calidad.
La calidad se consigue por medio de una mejor incorporación de personal
capacitado, responsable, y comprometidos en el trabajo, y para una mejor
facturación y el control de inventario, tendrá fácil dominio en la interfaz del
programa la cual será fácil de dominar por el usuario.
El super mercado constara con dos sucursales una ubicada en Jinotepe y la otra
en diriamba.ya que se realizara con el fin de mejorar la satisfacción del cliente, ya
que mejorara la forma de adquirir sus productos.
2. OBJETIVOS
OBJETIVO GENERAL
Desarrollar un Sistema Web de Control de Inventario y Facturación en el
Minisuper Silva que optimice el procesamiento de compras y ventas de los
productos.
OBJETIVOS ESPECIFICOS
Determinar los requisitos del sistema funcionales y no funcionales,
considerando las necesidades de los usuarios del área.
Diseñar una arquitectura sólida para el sistema, que cumpla con los
requerimientos definidos.
Implementar la aplicación web en su versión beta (ambiente de pruebas) de
acuerdo a la arquitectura diseñada y a los requisitos especificados del sistema.
Página 2
3. JUSTIFICACION
El desarrollo del sistema para el proyecto del supermercado silva consiste en el
montaje y la creación de un sistema de inventario y facturación con el fin de
mejorar las necesidades básicas de la comunidad, se vio viabilidad a nivel de que
todos necesitamos comer, asearnos, etc.
Y en un sector donde hay escases se necesita un lugar que quede cerca, donde
se puedan comercializar los productos necesarios y a bajo costo, se vio la
oportunidad después de analizar el entorno y se dio la idea de servir a la
comunidad, se sabe que se va a conseguir los recursos para empezar, se cuenta
con la experiencia y ganas de ser un buen elemento para la sociedad y para el
progreso del departamento.
Página 3
4. CAPITULO 1: MARCO TEÓRICO
4.1 BASES TEORICAS
4.1.1Sistemas Web
Aplicación donde todos los usuarios pueden utilizarla accediendo a un navegador
a través de internet o de una intranet. Powell(1998) plantea:
Aplicación web estructurada como un sistema de información con arquitectura una
aplicación de tres capas. En su forma más común, el navegador web ofrece la primera
capa y un motor capaz de usar alguna tecnología web dinámica constituye la capa de en
medio y la base de datos es la tercera y última capa.
De acuerdo a León(2001) lo define: “Aplicación que se caracteriza por procesar
datos que están almacenados, tanto en base de datos como en páginas web que
se encuentran distribuidas sobre la red manipulados y mantenidos a través de
interfaces web”.
Los atributos de los sistemas web son:
1. Intensivas de Red, reside en una red y debe dar servicio a las necesidades de
una comunidad diversa de clientes.
2. Evolución continua, crece con una serie de versiones planificadas y
cronológicamente espaciadas.
3. Inmediatez, el tiempo que se tarda en comercializar el sitio web completo puede
ser cuestión de días o semanas.
4. Seguridad, se protege el contenido confidencial, proporcionando formas
seguras de transmisión de datos.
5. Estética, está dado por su apariencia e interacción.
Página 4
4.1.2Características
De acuerdo con ITEISA Desarrollo y Sistemas(2011), las características son:
Ubicuidad, se accede a la aplicación desde cualquier equipo informático
conectado a Internet, con independencia de su situación geográfica.
Multiusuario, puede tener varios usuarios con ubicaciones geográficas
diferentes conectados al sistema simultáneamente sin presentar problemas.
Independencia de software, para acceder a la aplicación se debe tener
instalado un navegador web.
Seguridad, albergar la aplicación web en un servidor remoto para
proporcionar inmunidad por cualquier avería del hardware, malware, etc.
Multiplataforma o interoperabilidad, son multiplataforma por diseño, por lo
que se puede conectar con la aplicación empleando cualquier sistema
operativo.
Ahorra tiempo, se realizan las tareas sencillas sin necesidad de descargar o
instalar ningún programa.
Menos requerimientos del hardware, estas aplicaciones no consume
espacio en disco duro y utilizan mínima memoria RAM, debido que la mayor
parte del trabajo recae en el servidor que reside la aplicación.
4.1.3 Tecnologías
Según Pressman(2002) los sistemas web incorporan tecnologías importantes:
1. Desarrollo basado en componentes, es un proceso que se centra en el diseño
y construcción de sistemas.
Página 5
2. Seguridad, la infraestructura de red se proporciona una variedad de medidas
de control como la encriptación, cortafuegos y otras.
3. Estándares, a medida que las aplicaciones crecen en tamaño y complejidad se
ha adoptado el estándar XML, permitiendo que los diseñadores definan
etiquetas personalizadas en las descripciones de la página web.
4.1.4 Importancia
Los sistemas web son importantes en una empresa ya que:
Provee a sus clientes información detallada y especifica acerca de sus
productos, procesos y servicios.
Actualiza la información a medida que se van desarrollando nuevos
aspectos de sus productos y servicios.
La aplicación de estos sistemas resulta más sencillo y económico
eliminando documentación en papel innecesaria.
Evalúa a sus clientes actuales y desarrolla nuevas oportunidades de
negocio.
4.2 METODOLOGIA
4.2.1 Método Watch
El método watches un marco de referencia para el desarrollo de software. Según
Montilva(2008):“Guía metodológica que establece las actividades, los procesos,
las prácticas, las técnicas, los estándares y las herramientas que deben emplear
para desarrollar los componentes arquitectónicos de una aplicación empresarial e
integrarla al sistema de negocios”.
Este método está fundamentado en las mejores prácticas de la ingeniería de
software y la gestión de proyectos, por lo que cubre todo el ciclo de vida de las
aplicaciones empresariales e integrarla al sistema de negocios.
Página 6
4.1.2 Objetivos del método Watch
El método watch ha sido elaborado para ser utilizado en el desarrollo de
aplicaciones empresariales, con la finalidad de:
a. Orientar a los equipos de desarrollo de lo que deben hacer y cómo desarrollar
la aplicación empresarial.
b. Garantizar la uniformidad, consistencia, facilidad y calidad de los componentes
arquitectónicos de la aplicación empresarial.
c. Gestionar el desarrollo de aplicaciones empresariales como proyectos de
ingeniería siguiendo los estándares de gestión de software.
d. Asegurar la aplicación de las mejores prácticas en el desarrollo de la aplicación
empresarial con el fin de producir software de calidad.
4.1.3Características del método Watch
Las características más relevantes del método watch son las siguientes:
1. Fundamento sólido, posee una base conceptual y metodológica de la
ingeniería del software y los sistemas de información empresarial.
2. Estructurado y modular, posee una clara estructura que facilita su comprensión
y utilización, debido que separa los tres elementos principales: actores,
procesos y producto.
3. Propósito específico, es dirigido al desarrollo de aplicaciones empresariales,
apoyando los procesos del negocio.
4. Flexible y adaptable, sus componentes son adaptados con relatividad facilidad.
Página 7
5. Empleo de mejores prácticas de desarrollo de software, utiliza estándares
internacionales aceptados y utilizados en la industria del software.
6. Utiliza procesos de gestión de proyectos, emplea prácticas establecidas en la
administración de desarrollo de software.
7. Integra los procesos de gestión con los procesos técnicos y de soporte, define
los tres grupos de procesos: técnicos, de gestión y de soporte para el
aseguramiento de la calidad del software.
4.1.4 Componentes del método Watch
Los componentes del método watch, describe sus elementos claves: el producto
que se requiere elaborar, los actores que lo elaboran y el proceso que los actores
deben seguir para elaborar el producto, como se muestra en la siguiente figura 1.
Figura 1. Componentes del Método Watch.Fuente: Montilva& Barrios (2007).
4.1.4 Modelo de Producto
Este modelo identifica y describe los tipos de productos que se generan, mediante
el uso del método, durante el desarrollo de una aplicación empresarial. A
continuación la figura 2, recoge los principales tipos de productos que se deben
Página 8
producir a lo largo del desarrollo de una aplicación empresarial y los clasifica de
acuerdo a los grupos de procesos donde ellos se generan.
Figura 2. Tipos de Productos del Método Watch.Fuente: Montilva& Barrios (2007).
4.1.5 Modelo de Actores
Este modelo identifica los actores interesados que están involucrados en el
desarrollo de las aplicaciones. La figura 3, clasifica a los actores en cuatro grupos
diferentes.
Figura 3. Clasificación de Actores del Método Watch.Fuente: Montilva& Barrios (2007).
Página 9
4.1.6 Modelo de Procesos
Este modelo describe detalladamente los procesos técnicos, de gestión y de
soporte que los equipos de desarrollo deben emplear para desarrollar una
aplicación empresarial, ilustrada en la figura 4.
Figura 4. Clasificación de Procesos del Método Watch.Fuente: Montilva& Barrios (2007).
4.1.7Lenguaje Unificado de Modelado
Este lenguaje notacional destinado al modelado de sistemas. De acuerdo a Booch,
Rumbaugh& Jacobson(2006): “Es un lenguaje estándar para escribir planos de
software. Puede utilizarse para visualizar, especificar, construir y documentar los
artefactos de un sistema que involucra una cantidad de software”.
El empleo de UML, está dado para comunicar y compartir el conocimiento de la
arquitectura del software, gracias a cinco perspectivas:
1. Definir, explicación de los conceptos a través de sus componentes señalando
los límites de lo que es esencial y de lo circunstancial.
2. Organizar, establece los recursos que se dispone en un orden de
responsabilidades formalizándose las reglas de relación y actuación; todo ello
orientado a conseguir un propósito.
Página 10
3. Visualizar, representa el funcionamiento de la organización por medio de
imágenes haciendo visible su naturaleza y complejidad.
4. Actuar, pensar y tomar decisiones de manera ágil y sistemática, siguiendo un
método que defina el modo de proceder en base a la relación de un conjunto de
actores, actividades, entregables que hace posible el escenario correcto.
5. Certificar, comprueba de manera verdadera que un entregable es completo,
coherente y usable para el propósito que ha sido creado.
4.3 HERRAMIENTAS DE DESARROLLO
4.3.1 Consolidado tecnológico
Para el desarrollo de nuestro sistema se utilizan las herramientastecnológicas más
adecuadas y que forman parte del estándar de desarrollo de la empresa Casa
Pellas con el fin de cumplir con los requerimientos proporcionados por el usuario.
Tecnología Nombre Versión DescripciónGestor de Base
de DatosSQL server
2008 R2Creador de base de datos
Lenguaje de Programación
ASP.Net 4.0 framework para aplicaciones web desarrollado y comercializado
por MicrosoftFramework 4.0 Representa una arquitectura
de software que modela las relaciones generales de las entidades del dominio
Servidor de Aplicaciones
Visual Studio 2008
Creación de aplicaciones, sitios y aplicaciones web, así como servicios web en cualquier entorno que soporte la plataforma .NET
Cuadro 1. Consolidado Tecnológico.Fuente: Autor (2013).
Página 11
Una vez mencionadas las herramientas tecnológicas utilizadas para el desarrollo
de los módulos del sistema, a continuación se hace hincapié en cada una de ellas.
4.3.2 SQL Server 2008
Es un sistema de gestión de bases de datos para administrarlo y analizarlos
5. CAPITULO 1: MARCO METODOLOGICO
5.1 TRABAJO DE INVESTIGACION
5.1.1 Tipo y Nivel de la Investigación
El trabajo de tesis se incorpora en el tipo de investigación de campo.Por cuanto,
tiene como características principal ubicar al investigador en contacto con el objeto
investigado permitiendo obtener información en el ambiente natural donde conviven las
personas y las fuentes consultadas de la que se obtendrán los datos más relevantes, para
luego realizar el análisis e interpretación de los resultados obtenidos. Arias (2006) señala:
“la investigación de campo es aquella que consiste en la recolección de datos
directamente de los sujetos investigados o de la realidad donde ocurren los hechos, sin
manipular o controlar variable alguna”.
Se considera un estudio descriptivo, ya que logra caracterizar el objeto de estudio
concreto, señalando su funcionamiento y características, sirviendo para ordenar y
sistematizar los aspectos involucrados en el trabajo indagatorio.
5.1.2 Población y Muestra
La población es fundamental en el estudio a fin de conocer alguna de sus características
según su tamaño La población posee una característica común la cual se estudia y da
origen a los datos de investigación la presente investigación se encuentra representada
por 3 personas (cada una gerente del departamento de producción, facturación e
inventario
La muestra es una parte representativa de la población, es decir que los datos obtenidos
de la muestra se cumplen en la población, características de esta población pequeña y
finita, basándose en la premisa expuesta anteriormente, se tomaron como unidades de
Página 12
estudio a todos los individuos que la forman, es decir la población de 3 personas va ser la
muestra del estudio.
5.1.3 Técnicas e Instrumentos de Recolección de Datos
5.1.4 Técnicas de Análisis de Datos
5.1.5 Diseño Operativo
Para el cumplimiento de los objetivos planteados, se empleó la metodología
Watch. Se inicia con una investigación preliminar típica del ciclo de vida del
desarrollo del software apoyado con el lenguaje de modelado unificado. A
continuación se muestra el cuadro operativo.
Fases Descripción Entregables Metodología/Herramientas
IAnálisis del
sistema
En fase consiste en adaptar el método WATCH a las características y a las condiciones existentes en el área de los talleres. Se pretende revisar y conocer las condiciones existentes para describir de manera general el sistema que se va a desarrollar.
Esto nos permitirá identificar, describir y evaluar los riesgos inherentes de la aplicación. Además se profundizará modelado del negocio y
Documento de inicio del proyecto.
Documento de instancia del Método.
Plan integral del proyecto.
Plan de Gestión de Riesgos.
Plan de Gestión de Configuración.
Modelado del Negocio.
Modelado del
Método Watch
Página 13
especificando cada uno de sus procesos, con el objetivo de definir los requerimientos funcionales y no funcionales del sistema, para su debida documentación permitiendo la elaboración de los diagramas de casos de uso.
Sistema.
II Diseño del
sistema
En esta fase se definen los estándares de diseño de la aplicación, definiendo el modelo arquitectónico con cada uno de sus componentes.
Documento de diseño arquitectónico.
Método WatchUML
III Implementación
del sistema
Esta fase consiste en la codificación de cada uno de los componentes definidos en el modelo arquitectónico, se realizan las pruebas funcionales y no funcionales, pruebas de integración y de aceptación
Documento Implantación del Software.
Método WatchUML
Cuadro 2. Diseño Operativo.Fuente: Autores (2013).
5.1.6 Plan de Actividades
Actividad Inicia Finaliza Duración (días)Fase I Análisis del sistemaFase II Diseño del Sistema
Página 14
Fase III Implementación del sistema
Cuadro 3. Plan de Actividades.Fuente: Autores (2013).
Tomando el desglose de actividades se realiza el diagrama de Gantt.
Figura 5. Diagrama de Gantt.Fuente: Autores (2013).
Página 15
CAPITULO III: DESAROLLO
6.1 CONTEXTO ORGANIZACIONAL
6.1.1 Antecedentes
6.1.2 Valores
6.1.3 Organigrama
Figura 6. Organigrama del área de objeto de estudio.Fuente: Autor (2013).
6.2 FASE 1- ANALISIS DE SISTEMA
6.2.1 Documento Inicio del Proyecto
Desarrollar un Sistema de inventario y facturacion para el minisúper silvaDOCUMENTO INICIO DEL PROYECTO
VERSION 1.0Autores Fecha Versión Descripción
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
Página 16
1. Introducción
Este es el primer documento formal del proyecto, el cual justifica técnicamente la
necesidad de desarrollar una nueva aplicación empresarial. Su objetivo es explicar
la necesidad de realizar la aplicación, para dar respuesta a las necesidades de
información que se tiene el super mercado silva. Este documento se elaborócon el
fin de automatizar las funciones y para llevar un control de los productos que
tendrá el minisúper.
2. Objetivos y Alcance del proyecto
2.1Objetivos
El objetivo del proyecto es Desarrollar un sistema Web para los minisúper silva
que permita el inventario y facturación de productosy tiene como objetivos
específicos:
Determinar los requisitos del sistema funcionales y no funcionales,
considerando las necesidades de los usuarios del área.
Diseñar una arquitectura sólida para el sistema, que cumpla con los
requerimientos definidos.
Implementar la aplicación web en su versión beta (ambiente de pruebas) de
acuerdo a la arquitectura diseñada y los requisitos especificados del sistema.
2.2 Alcance del proyecto
2.2.1 Alcance del producto
El Software a desarrollar abarcará a nivel general funcionalidades de procesos
para el control de citas para mantenimientos en los talleres de servicio de Casa
Pellas realizando: programación de citas tanto en la solicitud misma por parte del
cliente como en la aprobación por parte del personal de talleres y manejo de
históricos de las citas realizadas por los clientes.
Página 17
2.2.2 Alcance del Proyecto
Abarcara hasta la etapa implementación en ambiente de pruebas, basándose en
la Metodología WACHT.
3. Características Generales de la Aplicación
El producto ha desarrollado es un software que integra los procesos involucrados
en la realización de citas de mantenimientos que se realizan en el área de talleres
de la empresa Casa Pellas su funcionamiento será:
A) Realización de solicitud la cita: permitirá a los clientes la realización de las
solicitudes de citas de mantenimiento en los talleres de servicios, donde el
cliente podrá planificar la fecha y hora de la cita y brindar información
importante para el mantenimiento como son el tipo de mantenimiento, el tipo de
combustible, el kilometraje, etc.
B) Proceso de confirmación de cita: el encargado de llevar el control de las citas
del taller recibirá todas las solicitudes de citas hechas por los clientes y luego
de comprobar disponibilidad de los recursos para la cita, confirma o solicita
reprogramación al cliente, cabe destacar que existe una agenda en los talleres
donde se tiene una planificación de los trabajos programados, los asesores y
los técnicos asignados a los diversos mantenimientos, es importante
mencionar que la validación de disponibilidades de recursos no se realiza
durante la solicitud de la cita debido a que no existe una infraestructura de
información en el área de talleres actualmente que contenga un inventario de
bahías, técnicos y asesores que permita al sistema brindar esta funcionalidad
simplificando el proceso, para alcanzarlo será necesario primeramente una
reingeniería dentro de dicha área.
Página 18
C) Historiales: permitirá a los clientes tener la información histórica de todos los
mantenimientos realizados a los diferentes chasis en los talleres de
mantenimiento de servicios.
El sistema realizará validaciones en el ingreso de los datos lo que permita
minimizar la duplicación de trabajo, contará con un pequeño módulo de
administración que permitirá la generación de usuarios y claves para nuestros
clientes con el objetivo de permitirle tener acceso a toda su información histórica,
tendrá una base de datos actualizada y segura para almacenar información en
cualquier momento, permitirá la automatización de procesos para facilitar el flujo
de entradas y salidas del sistema, y en él se podrá visualizar información
necesarios para los procesos administrativos del área.
4. Requisitos Iníciales
Para garantizar el rendimiento adecuado del proyecto a desarrollar y por ende del
sistema propuesto es necesario contar con una serie de requisitos, en esta
oportunidad se mencionarán los requisitos mínimos para comenzar con el
proyecto, destacando que en la medida en que se avance en el desarrollo del
mismo estos requisitos aumentaran. En cuanto a requisitos de hardware se debe
contar con un computador para el manejo y almacenamiento de la información. En
lo que respecta a software se requieren programas como:
RationalApplicationDevelopers 8.0, WebSphereApplication Server v.8.0, Enterprise
Architect, Microsoft Visio, DB2 y Microsoft Project.
5. Visión del Negocio
El área de personal del los supermercados Silva contara 22 empleados con la
finalidad de ofrecer la mejor atención en los supermercados.
Página 19
Cargo en el área del supermercadoCargo Cantidad
1Jefe Contable 1Jefe de Taller 1Jefe de Citas 1Jefe de Recepción 1Instructor 1TSM 1Contadores 1Bodegueros 1Auxiliares Contables 1Atención al Cliente 1Asesor de Servicios 5Mecánico 6Chapistero 3Compradores 1Lavadores 4 Total 30
Cuadro 4. Organización del personal del área de taller.Fuente: Autores (2013).
6. Necesidad de Desarrollar el Sistema
En el área de talleres de la empresa Casa Pellas no se cuenta con un sistema
automatizado en ambiente web que facilite el proceso de creación de citas para
servicios de mantenimientos. Esto permitirá a los clientes realizar solicitudes de
citas desde una aplicación vía Internet ahorrándoles el trabajo de llegar
físicamente a la recepción de los talleres o llamar para solicitar la cita. Así mismo
constituye una mejora en el proceso de citas para los trabajadores del área puesto
que permite aprobar o reprogramas citas en base a la disponibilidad en la agenda
de los talleres conllevando a la automatización de los procesos.
7. Resumen de Interesados del proyecto
Página 20
Se describe todos los interesados (stakeholders) del proyecto:
Rol ResponsabilidadesLíder del Proyecto Elaborar el Plan Integral del Proyecto de desarrollo
de la aplicación. Prestar asistencia técnica a los miembros del equipo
de desarrollo. Gestionar los riesgos del proyecto. Dirigir y controlar la ejecución del Plan Integral del
Proyecto. Cerrar administrativa y técnicamente el proyecto.
Analista Descubrir, analizar, especificar y documentar los requisitos de la aplicación.
Validar, en conjunto con los usuarios, los requisitos establecidos.
Gestionar los requisitos. Especificar requisitos arquitectónicos.
Diseñador de Software
Diseñar y evaluar la arquitectura de la aplicación. Especificar cada una de las vistas arquitectónicas. Diseñar los detalles de la Interfaz U/S, las Bases de
Datos y los Componentes de Software Programador Codificar, documentar y probar los componentes de
software de la aplicación. Depurar los componentes que tengan errores. Integrar los componentes de la aplicación y
desplegarlos en la plataforma de ejecución del proyecto.
Elaborar los manuales de instalación, uso y mantenimiento.
Verificar y validar los productos de cada proceso del desarrollo.
Cuadro 5. Interesados del Proyecto.Fuente: Autores (2013).
Definimos qué papel desempeña cada interesado (stakeholders) del proyecto:
Nombre ResponsabilidadesIng. Javier Aburto Galeano Líder del ProyectoBr. Mario Osorno Torrez Analista
Diseñador Programador
Cuadro 6. Identificación de Interesados del Proyecto.Fuente: Autores (2013).
Página 21
8. Restricciones, Costos y Recursos
8.1Restricciones
Los participantes estarán constituidos por el jefe del área de desarrollo en la
gerencia de Informática de la empresa Casa Pellas que juega el papel de líder del
proyecto, los usuarios finales (clientes y operadores del sistema en el área de
talleres) y su servidor que será el encardo de desempeñar los papeles de Analista,
Diseñador y Programador del producto de software.
El sistema está siendo desarrollado en las instalaciones de la empresa Casa
Pellas S.A sucursal Plaza España, basándose en: Java, JQuery, Java Server
Faces y Java Persistence API.
8.2Costos
Los costos de producción representan la inversión inicial que realiza el
desarrollador o el equipo de trabajo durante la construcción del software, esto
incluye costos de: infraestructura, personal, adiestramientos, cursos o talleres
necesarios para la capacitación del personal involucrado y materiales utilizados.
Entre estos costos tenemos:
1. Costos de equipos y herramientas de trabajo: estos costos se generan por el
hardware y el software utilizado durante el desarrollo del proyecto. Debido a
que la empresa cuenta con el equipo y las herramientas de trabajo que se
utilizara, no se tendrá ningún tipo de gasto en relación a esto.
2. Costos de infraestructura: los costos de infraestructura se determinan a través
de los gastos generados al contar con un ambiente de trabajo apto para los
equipos y por el mobiliario requerido para cada uno de ellos. La empresa
Página 22
cuenta con un área de trabajo apta para los equipos, por lo que no se tendrá
gastos de infraestructura.
3. Costos de personal: incluye los sueldos de los empleados cuyos esfuerzos se
encuentran directamente asociados al proyecto. Durante el desarrollo del
sistema, se requiere la participación de dos (02) empleados en la empresa; el
jefe del proyecto y el encargado de realizar los roles de analista, diseñador y
programador, cabe mencionar que el trabajo no será remunerado puesto que
se realiza con fines académicos.
4. Costos de adiestramientos: estos costos se refieren a los generados por las
técnicas de capacitación y aprendizaje, como una herramienta para que el
personal involucrado en el proyecto adquiera los conocimientos necesarios que
le permitan desarrollar y ampliar aptitudes y actitudes para realizar el trabajo de
la manera correcta. En nuestro caso no será necesaria la capacitación pues se
cuenta con la experiencia de proyectos anteriores utilizando las mismas
herramientas tecnológicas.
5. Costos de materiales que se utilizaran: representan los costos relacionados a
la compra de resmas de papel, carpetas, ganchos de carpetas, cartuchos de
tinta para impresión, libretas de anotaciones, lapiceros entre otros. Recalcando
que estos materiales serán suministrados por la empresa.
8.3Supuestos Ambientales
Además de las personas encargadas del desarrollo del proyecto y del cliente, el
ambiente puede implícita o explícitamente influenciar o poner restricciones en los
requerimientos del sistema. El analista debe estar enterado de todo aquello que
Página 23
incida en el correcto funcionamiento de un software, por lo que en el proyecto a
desarrollar se percibe los siguientes supuestos ambientales:
1) Se deben conocer los sistemas que se han desarrollado en el área, ya que
estos ayudarán a definir los requerimientos.
2) Se deben dar las condiciones e instalaciones físicas necesarias para mantener
equipos de computación dentro del área de los talleres.
Los requerimientos del sistema están influenciados directamente por los usuarios
quienes tienen que estar conforme a los estándares y reglamentos técnicos
dictados por la empresa.
La influencia cultural debe ser considerada al desarrollar el sistema porque puede
afectar los requerimientos de éste. Muchas personas no se adaptan a los avances
tecnológicos, sin embargo creemos y confiamos que el personal que labora en el
área de los talleres hará uso pleno del sistema que se pretende implementar.
6.2.2 Documento del Proceso de Instanciación del Método
Desarrollo de un Sistema web para las citas de los talleres de servicio de la empresa Casa Pellas que optimice la recepción y procesamiento de solicitudes de mantenimiento.
DOCUMENTO DEL PROCESO DE INSTANCIACION DEL METODOVERSION 1.0
Autores Fecha Versión Descripción
Página 24
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
Este documento presenta la instanciación del método, el cual consiste en adaptar
el conjunto de procesos y actividades prescritas por el método, a las
características particulares del sistema que se va a implementar. Para realizar la
adaptación se toma en cuenta tanto las condiciones existentes en el ambiente de
trabajo como la complejidad de la aplicación; es decir, el proceso de ajuste del
método considera las características del producto que se desea desarrollar y del
ambiente organizacional de implantación para establecer el equipo de trabajo
requerido y el proceso que debe seguirse.
2. Procesos que se generan en el proyecto
Con el objeto de facilitar su descripción, estos modelos de procesos se han
organizado en tres grupos como se ilustra en la figura 13. El grupo de Procesos
Técnicos enmarcan todas las actividades de ingeniería que están relacionadas
directamente con el ciclo de desarrollo de las aplicaciones. El grupo de Procesos
de Gestión cubre todas las actividades de gestión de proyectos de software. El
grupo de Procesos de Soporte concentra todas aquellas actividades que son
necesarias para apoyar la ejecución de los procesos técnicos y gerenciales. Para
el desarrollo del proyecto se van realizar todos los procesos del método Watchque
se muestran a continuación:
Página 25
Figura 7. Clasificación de los Procesos del Método Watch durante el desarrollo del proyecto.Fuente: Autores (2013).
Una vez que los modelos de productos, procesos y actores han sido instanciados
se debe asegurar que el método resultante de la integración de estos tres
modelos, permitirá verdaderamente desarrollar el proyecto.
3. Productos que se generan del Proyecto
Página 26
El modelo de producto identifica y describe los tipos de productos que se pueden
generar durante el proyecto: “Desarrollar un sistema Web para los talleres de
servicio de la empresa Casa Pellas que permita la recepción y el procesamiento
de solicitudes para servicios de mantenimiento“. Estos tipos de productos son el
resultado parcial o final de la ejecución de los procesos técnicos, de gestión o de
soporte.
Para hacer la instanciación del modelo de productos se elabora una lista de los
productos concretos que se producirán durante el desarrollo del proyecto. Está
compuesto por tres tipos de productos: procesos de gestión, procesos técnicos y
procesos de soporte.
Grupo de Procesos ProductoProcesos de Gestión 1. Documento de Inicio del Proyecto.
2. Documento del Proceso de Instanciación del Método.3. Plan Integral del Proyecto.
Procesos Técnicos 1. Modelado del negocio.2. Modelado del Sistema.3. Documento de Diseño Arquitectónico.4. Documento Implantación del software.5. Aplicación:
Programas. Base de datos. Manuales.
Procesos de Soporte 1. Plan de Gestión de Riesgos.2. Plan de Gestión de Configuración.
Cuadro 7. Productos que generan la Metodología Watch.Fuente: Autores (2013).
6.2.3 Plan Integral del Proyecto
Desarrollo de un Sistema web para el súper mercado silva
Página 27
PLAN INTEGRAL DEL PROYECTOVERSION 1.0
Autor Fecha Versión Descripción
MarioOsorno 01/11/2011
0.9 Versión preliminar como propuesta de desarrollo
MarioOsorno 12/11/2011
1.0 Versión preliminar
1. Introducción
Es el documento más importante de la gestión del proyecto, por cuanto determina,
rige y guía la ejecución de todos los procesos del desarrollo de la aplicación. El
Plan de Integral del Proyecto define cómo el proyecto se debe iniciar, planificar,
ejecutar, controlar y cerrar. Este documento determinara la ejecución de todos los
procesos del desarrollo del proyecto: “Desarrollar un sistema Web para los talleres
de servicio Grupo Casa Pellas que permita la recepción y el procesamiento de
solicitudes para servicios de mantenimiento”. Se podrá establecer los objetivos y
alcance de la aplicación, el proceso técnico necesario para desarrollar dicha
aplicación, las actividades que componen cada uno de los procesos, el
cronograma de ejecución de estas actividades, y los recursos humanos,
tecnológicos, físicos y materiales necesarios para desarrollar las actividades.
2. Objetivos
Con los diferentes planes que más adelante se detallarán se pretende obtener
información que se necesita para llevar el proyecto planificado y controlado en lo
que respecta a tiempos, riesgos y cambios. Todo proyecto de software es
susceptible a riesgos los cuales si llegan a concretarse afectan los tiempos de
ejecución de las actividades y producen cambios en el proyecto, por esto los
objetivos que se persiguen con los diferentes planes que se realizan son los
siguientes:
1. Asegurar que el desarrollo de la aplicación sea sistemático, organizado, eficaz y
eficiente, mediante el empleo de los procesos de planificación, dirección y control.
Página 28
2. Garantizar que la aplicación se desarrolle a tiempo y siguiendo los estándares y
procedimientos establecidos para asegurar la calidad de la aplicación.
3. Manejar apropiadamente los riesgos que puedan surgir durante el desarrollo de
la aplicación y que puedan afectar los objetivos del proyecto.
4. Controlar la configuración de la aplicación.
3. Recursos Necesarios
3.1. Recursos Humanos
El equipo de trabajo está representado de la siguiente manera:
Se requiere primeramente del Ing. Javier Aburto Galeano cuya responsabilidad es
de ser el líder del proyecto: es la persona que elabora el Plan Integral del Proyecto
de desarrollo de la aplicación, presta asistencia técnica a los miembros del equipo
de desarrollo, dirige y controlar la ejecución del Plan Integral del Proyecto y es la
responsable general del proyecto ante la gerencia de informática de la empresa
Casa Pellas, esta persona valida cada uno de los documentos. Además del Br.
Mario Osorno Torrez quien llevará a cabo la realización del proyecto asumiendo
los roles de analista, diseñador y programador.
3.2. Recursos Tecnológicos
Para garantizar un rendimiento adecuado del sistema propuesto es necesario que
los equipos hardware donde se van a instalar y operar el sistema cumplan con los
siguientes requerimientos unidad central de procesamiento (CPU) Pentium IV, se
Página 29
recomienda 4096 megabyte (MB)/4 GB de memoria RAM, Disco Duro de 160 GB
y Sistema operativo Windows XP. Servidor WebSphereApplication Server
Enterprise Edición v.8.0, un Navegador Web y tener acceso en la intranet al
servidor de datos ISeries que contiene el Sistema Gestor de Bases de Datos DB2.
3.3. Recursos Materiales
Los miembros de trabajo del proyecto deben contar con resmas de papel tipo
carta, cartuchos de impresión, carpetas, lápices, lapiceros y marcadores, libreta de
anotaciones, CD-ROM, guías didácticas con información sobre el método de
desarrollo, material de apoyo y textos varios sobre los procesos y actividades a
desarrollar.
6.2.4 Plan Gestión de Riesgo
Desarrollo de un sistema Web para los talleres de servicio de la empresa Casa Pellas que permita la recepción y el procesamiento de solicitudes para servicios de mantenimiento
PLAN GESTION DE RIESGOVERSION 1.0
Autores Fecha Versión Descripción
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
La Planificación de la Gestión de Riesgos tiene como objetivo definir las
actividades, recursos, responsabilidades, costos, tiempos que son necesarios para
evaluar y responder a los riesgos del proyecto de citas de talleres de manera
organizada. El proyecto comienza considerando las características del ambiente
de desarrollo, del proyecto, la experiencia en el dominio y categoría de la
aplicación a desarrollar, las herramientas y recursos requeridos y disponibles,
Página 30
para luego determinar cuáles actividades de gestión de riesgos se llevaran a cabo,
cuando en qué orden y quiénes serán los responsables.
2. Riesgos a administrar
001 Descripción del RiesgoInexistencia de comunicación entre el cliente y los involucrados en el proyecto.
Tipo de Riesgo: Personal
Consecuencia:No contar con información para poder desarrollar el proyecto, y desviación en el cumplimiento de los requerimientos
Probabilidad Efecto del Riesgo: TolerableBaja Bajo Moderad
oAlto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): Analista del proyecto
Estrategia de Mitigación:Para evitar la disminución del flujo de comunicación se requiere hacer reuniones periódicas: semanalmente para el área de talleres y diariamente con el jefe del proyecto, con el fin de aumentar la retroalimentación.
Cuadro 8. Riesgo 1 a administrar en el proyecto.Fuente: Autores (2013).
002 Descripción del RiesgoIncumplimiento en la entrega de documentos a la gerencia de Informática, debido a cargas de trabajo fuertes no relativas al proyecto.
Tipo de Riesgo: Personal
Consecuencia:Retraso en la elaboración del proyecto.
Probabilidad Efecto del Riesgo: Serio.Baja Bajo Moderad
oAlto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): Analista del proyecto
Estrategia de Mitigación:Para evitar el incumplimiento en las asignaciones, se debe dar a conocer con anticipación la no participación en alguna versión y posteriormente exponer con aval dicha solicitud.
Página 31
Cuadro 9. Riesgo 2 a administrar en el proyecto.Fuente: Autores (2013).
003 Descripción del RiesgoIncumplimiento en la entrega de corregidos y/o aprobados del área de desarrollo de la gerencia de Informática.
Tipo de Riesgo: Personal
Consecuencia:Prolongación en la elaboración del proyecto.
Probabilidad Efecto del Riesgo: Serio.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): AnalistaDiseñadorProgramador
Estrategia de Mitigación: Los involucrados en el proceso de desarrollo deben apegarse al cumplimiento del cronograma de fechas.
Cuadro 10. Riesgo 3 a administrar en el proyecto.Fuente: Autores (2013).
004 Descripción del RiesgoLa no aprobación de artefactos ejecutables durante la construcción y pruebas del sistema por parte del área de desarrollo de la gerencia de Informática.
Tipo de Riesgo: Organizacional
Consecuencia:Proyecto reprobado o cancelado.
Probabilidad Efecto del Riesgo: Catastrófico.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Después de la implantación del proyecto.
Responsable (s): Líder del ProyectoAnalistaDiseñadorProgramador
Estrategia de Mitigación: Apegarse a las normas y exigencias del área de desarrollo, entregando documentos con buen contenido.
Cuadro 11. Riesgo 4 a administrar en el proyecto.Fuente: Autores (2013).
Página 32
005 Descripción del RiesgoResistencia al cambio por parte de los usuarios.
Tipo de Riesgo: Organizacional
Consecuencia:Proyecto cancelado.
Probabilidad Efecto del Riesgo: Serio.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Después de la implantación del proyecto.
Responsable (s): Líder del Proyecto
Estrategia de Mitigación: Coordinar una estrategia de comunicación interna que involucre a los usuarios en las ventajas del nuevo sistema y establecer reuniones, foros y conferencias con la doble finalidad de transmitir el proyecto a los usuarios y recibir retroalimentación que permitirá incorporar cambios que reduzcan la resistencia natural al cambio.
Cuadro 12. Riesgo 5 a administrar en el proyecto.Fuente: Autores (2013).
006 Descripción del RiesgoIncumplimiento del alcance del proyecto en el área de talleres debido a que un participante asume muchos roles.
Tipo de Riesgo: Organizacional
Consecuencia:Resistencia al cambio de paradigma de desarrollo de software.
Probabilidad Efecto del Riesgo: Serio.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): Líder del Proyecto
Estrategia de Mitigación: Adaptarse al nuevo paradigma de trabajo en la parte del desarrollo del software.
Cuadro 13. Riesgo 6 a administrar en el proyecto.Fuente: Autores (2013).
007 Descripción del RiesgoCrecimiento no controlado de requerimientos y alcance.
Tipo de Riesgo: Estimaciones
Consecuencia:Proyecto fuera de calendario y requerimientos.
Probabilidad Efecto del Riesgo:
Página 33
Serio.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): Líder del ProyectoAnalista DiseñadorProgramador
Estrategia de Mitigación: El alcance debe ser definido previo a la etapa de operación. Cualquier nuevo requerimiento que se constituya en un subsistema para los ya previstos, debe ser considerado como un nuevo proyecto.
Cuadro 14. Riesgo 7 a administrar en el proyecto.Fuente: Autores (2013).
008 Descripción del RiesgoFalta de conocimiento de la herramienta (como Java, RationalApplicationDevelopers, DB2, etc.).
Tipo de Riesgo: Herramientas
Consecuencia:Retardo en la entrega de documentos.
Probabilidad Efecto del Riesgo: Serio.Baja Bajo Moderado Alto
Periodo en el cual puede suceder:Durante la elaboración del proyecto.
Responsable (s): Líder del ProyectoAnalista DiseñadorProgramador
Estrategia de Mitigación: Adiestramiento inmediato al equipo de desarrollo, con el fin de prepararlos y así poder cumplir con sus asignaciones.
Cuadro 15. Riesgo 8 a administrar en el proyecto.Fuente: Autores (2013).
6.2.5 Plan Gestión de Configuración
Desarrollo de un Sistema web para las citas de los talleres de servicio de la empresa Casa Pellas que optimice la recepción y procesamiento de solicitudes de mantenimiento.
PLAN GESTION DE CONFIGURACIONVERSION 1.0
Autor Fecha Versión Descripción
Página 34
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
A lo largo del ciclo de vida del proceso de software, los productos de software
evolucionan. Desde la concepción del producto y la captura de requisitos inicial
hasta la puesta en producción del mismo, y posteriormente desde el inicio del
mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el
código como en la documentación asociada.
La gestión de configuración del software es una disciplina encargada del control
de la evolución de los productos de software. Es proceso de identificar y definir los
elementos en el sistema, controlando el cambio de estos elementos a lo largo de
su ciclo de vida.
2. Objetivos
Controlar sistemáticamente los cambios que puedan producirse en la
configuración.
Mantener la integridad de la configuración de la aplicación.
Mantener la trazabilidad de la configuración a lo largo de todo el desarrollo de
la aplicación.
3. Actividades de gestión de la configuración
Las actividades de gestión de la configuración identifican todas las actividades y
tareas que se requieren para el manejo de la configuración del sistema. Estas
deben ser tanto actividades técnicas como de gestión de configuración del
software, asícomo las actividades generales del proyecto que tengan implicancia
sobre el manejo de configuración.
Página 35
3.1 Identificación de la configuración
Se necesita definir un esquema de identificación para reflejar la estructura del
producto, esto involucra identificar la estructura y clases de componentes, dando a
cada uno un nombre, una identificación de versión y una identificación de
configuración. Para este proyecto los elementos de configuración se
corresponderán con los entregables.
3.2 Control de la configuración
Se deben controlar los cambios que se le hacen a través del ciclo de vida,
asegurando que el software sea consistente a través de la creación de una línea
base del producto. Se identifican y registran las solicitudes de cambio, se analiza y
evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y
distribuye el elemento de software modificado.
3.3 Contabilidad del estado de la configuración
Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.
Se preparan registros de gestión y reportes de estado que muestren el estado e
historia de los elementos de software controlados, incluyendo líneas base.
3.4 Gestión y entrega de versiones
Se controla formalmente la actualización y distribución de las versiones generadas
por el proyecto. La gestión de la entrega se encarga de identificar, empacary
entregar los ítems y componentes que forman cada versión entregable de la
aplicación.
3.5 Contabilidad del estado de la configuración
El responsable de monitorear el plan es el desarrollador del proyecto, quien se
encarga de llevar un registro de los artefactos generados y sus versiones. Los
cambios serán realizados y comunicados a todo los interesados en el proyecto a
través de las plantillas de solicitud de cambio. Este plan deberá ser revisado al
Página 36
inicio de cada iteración, modificado de acuerdo a lo necesario, aprobado y
distribuido al equipo de proyecto.
6.2.6 Modelado del Negocio
Desarrollo de un Sistema web para las citas de los talleres de servicio de la empresa Casa Pellas que optimice la recepción y procesamiento de solicitudes de mantenimiento.
MODELADO DEL NEGOCIOVERSION 1.0
Autor Fecha Versión Descripción
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
Este documento permite revisar y verificar el dominio organizacional donde
operará el sistema. Tiene como propósito realizar un análisis del modelado de
negocio del sistema a desarrollar; el objetivo es verificar y validar con los usuarios
que el modelo del negocio está representado correctamente y cumple con los
procesos de negocio actuales.
2. Representación del Modelado del Negocio
El modelo del negocio se simbolizará mediante UML BUSINESS que es una
extensión del lenguaje UML, que está orientado a procesos de negocio que
Página 37
incorpora nuevos símbolos para modelar, emplea estereotipos para agregar mayor
semántica a los símbolos utilizados, usa cadena de valor de MICHAEL PORTER
para modelar procesos al más alto nivel y descomponer cada proceso de la
cadena de valor en sub-procesos de más bajo nivel, los cuales serán desglosados
de manera más específica y completa.
3. Modelo de Jerarquía
En esta parte se genera como producto un diagrama de jerarquía de sistema.
Figura 8. Modelo de jerarquía del Sistema de Cita.Fuente: Autor (2013).
Página 38
4. Modelado de Objetivos
De una manera macro, el diagrama de objetivos correspondiente a los procesos
fundamentales del negocio.
Figura 9. Diagrama de Objetivos de los Procesos del Sistema de Cita.Fuente: Autor (2013).
Página 39
5. Modelo de Proceso de Negocio
Este modelo representa el conjunto de procesos que se realizan en el Sistema de
Negocios y que conllevan al logro de los objetivos del mismo. Mediante este
modelo se identifican todos los procesos que se llevan a cabo en el área de citas,
la relación entre ellos y los actores involucrados en el sistema, a fin de
comprender como funciona el negocio.
5.1 Cadena de Valor del Negocio
Se empleó la cadena de valor de MICHEL PORTER como modelo para analizar
las Actividades Primarias y las Actividades de Soporte del área de Cita. Las
actividades son los dos (2) procesos que se manejan en esa área, los cuales
permiten que se dé la atención al cliente, mientras las actividades de soporte son
aquellas que sirven de apoyo para la realización de las actividades dentro del
área.
Página 40
Figura 10. Cadena de Valor del Negocio.Fuente: Autores (2013).
Las actividades de soporte son todos aquellos que aportan materiales para que se
puedan dar todos los procesos del área de servicio de cita entre estas tenemos:
Infraestructura del Taller: es necesario tener las instalaciones del taller
adecuadas para poder atender la demanda de clientes.
Recurso Humano y Material: son indispensables las personas que tienen la
capacidad para realizar las actividades dentro del área del taller (recepcionista,
asesor de servicio, mecánico, etc.), de igual manera se necesita de una buena
iluminación y repuestos.
5.2 Jerarquía de los Procesos del Negocio.
Se establece una jerarquía dentro de cada proceso del área de servicio de cita.
Página 41
Figura 11. Jerarquía de Procesos del Negocio.Fuente: Autores (2013).
Fuente: Autor (2013).
Figura 12. Diagrama de Actividad de Programar Cita.
Página 42
Fuente: Autor (2011).
Figura 13. Diagrama de Actividad de Elaboración de Histórico de Cita.
Página 43
Fuente: Autor (2011).
6.2.7 Modelado del Sistema
Desarrollo de un Sistema web para las citas de los talleres de servicio de la empresa Casa Pellas que optimice la recepción y procesamiento de solicitudes
Página 44
de mantenimiento.MODELADO DEL SISTEMA
VERSION 1.0Autor Fecha Versión Descripción
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
Este documento permite representar la abstracción semántica del sistema,
teniendo como propósito encontrar los verdaderos requisitos y representarlos de
un modo adecuado para los usuarios, clientes y desarrolladores.
2. Diagramas de Caso de Uso
Proporcionan un medio sistemático de los requerimientos funcionales del sistema.
Figura 14. Diagrama de Caso de Uso del Sistema.
uc Diagrama de Caso de Uso del Sistema
Cliente
Administrador
Autenticar Usuario
Gestionar Usuario
Gestionar Cita s
Gestionar Historic o
Fuente: Autor (2011).
Cuadro 16. Especificación del Caso de Uso Autenticar Usuario.
Página 45
Especificación del Caso de Uso: Autenticar UsuarioID ECU_SICITASGCP_01Nombre: Autenticar UsuarioDescripción: Autenticar a usuario registrado para hacer
uso del sistema.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: Cliente, AdministradorPrecondiciones: Estar registrado en el sistema.Post condiciones: Validación realizada con éxito.Flujo Normal de eventos Validar:
1. El actor ingreso su nombre de usuario (login) y contraseña.2. El sistema valida los datos ingresado por el actor.3. Una vez validado el actor, el sistema muestra el menú de opcionesFlujos Alternos
Usuario No RegistradoEn el paso 1 del flujo normal, si el actor no existe se muestra un mensaje donde se le indica que debe ser registrado por el administrador.
Usuario InactivoEn el paso 1 del flujo normal, si el actor se encuentra registrado en el sistema pero su estado es inactivo, se muestra un mensaje donde se le indica que debe ser activado por el administrador del sistema.
Excepciones Intentos Fallidos
Si el actor realiza el paso 1 del flujo normal con más de 3 intentos fallidos el sistema inhabilita el usuario.ReferenciasAnotaciones Solo se permite el ingreso al sistema de los actores que
tienen estado Activo.
Fuente: Autor (2011).
Figura 15. Diagrama de Caso de Uso Gestión de Usuarios.
Página 46
Fuente: Autor (2011).
Cuadro 17. Especificación del Caso de Uso Gestión de Usuario.
Especificación del Caso de Uso: Gestionar UsuarioID ECU_SICITASGCP_02Nombre: Gestión de UsuarioDescripción: Crear al actor un nombre de usuario (login)
y generarle una clave de acceso para ingreso al sistema.
Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: Cliente, Administrador Precondiciones: Ser cliente de los talleres Casa Pellas y poseer una cuenta de
correo electrónico personal.Post condiciones: Realización de autenticación de usuario para validar acceso al
sistema.Flujo Normal de eventos Validar:
1. El actor se presenta ante el administrador del sistema de citas para solicitar sus credenciales de acceso al sistema.
2. El actor le crea en el sistema un usuario y una clave temporal de acceso para el actor.
3. El actor realiza una autenticación de prueba para validar el acceso al sistema.
Página 47
Flujos Alternos Usuario No es cliente
En el paso 1 del flujo normal, si el actor no está registrado como un cliente de los talleres y no presenta el documento que contiene el número de orden el mantenimiento en caso de ser primer mantenimiento de dicho actor en el taller, debe abocarse con quien lo atendió para solicitarle la orden de mantenimiento necesaria para que el administrador del sistema le genere sus credenciales de acceso.
ExcepcionesNingunaReferenciasAnotaciones Solo se puede crear una cuenta para ingreso al sistema
clientes del taller que dispongan de una cuenta de correo personal.
Fuente: Autor (2011).
Cuadro 18. Especificación del Caso de Uso Crear Usuario.
Especificación del Caso de Uso: Crear UsuarioID ECU_SICITASGCP_05Nombre: Crear UsuarioDescripción: El administrador del sistema de citas crea
un nuevo usuario en el sistema.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador tiene una sesión activa en el sistema de citas.
El cliente debe tener una orden de cita asociada.Post condiciones: Usuario creado satisfactoriamente.Flujo Normal de eventos Solicitud de Cita:
1. El actor ingresa a la ventana de gestión de usuarios.2. Busca la información del cliente asociada a un
número de orden.3. Digita un usuario (login) y una contraseña para cliente.4. Guarda la información del usuario.5. Entrega de las credenciales del acceso al cliente.
Flujos AlternosNinguno
ExcepcionesNingunoReferencias
Página 48
Anotaciones Cuando el cliente obtiene un usuario y una contraseña para acceder al sistema tiene disponible información histórica.
Fuente: Autor (2011).
Cuadro 19. Especificación del Caso de Uso Editar Usuario.
Especificación del Caso de Uso: Editar UsuarioID ECU_SICITASGCP_06Nombre: Editar UsuarioDescripción: El administrador del sistema de citas
modifica la información de un usuario en el sistema.
Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador debe tener una sesión activa en el sistema de
citas.El cliente debe existir en el sistema.
Post condiciones: Usuario modificado satisfactoriamente.Flujo Normal de eventos Editar Usuario:
1. El actor ingresa a la ventana de gestión de usuarios.
2. Busca la información del cliente asociada a un número de orden.
3. Modifica la información del usuario.4. Guarda la información del usuario.
Flujos AlternosNinguno
ExcepcionesUsuario no registrado en el sistema.ReferenciasAnotaciones La opción de modificar usuario generalmente se utiliza en el
sistema para deshabilitar usuarios.
Fuente: Autor (2011).
Figura 16. Diagrama de Caso de Uso Gestión de Citas.
Página 49
Fuente: Autor (2011).
Cuadro 20. Especificación del Caso de Uso Gestión de Citas.
Especificación del Caso de Uso: Gestionar CitasID ECU_SICITASGCP_03Nombre: Gestión de CitasDescripción: El cliente solicita una cita para realizar un
mantenimiento vehicular en los talleres de servicio Pellas y espera la aprobación de la cita por parte del responsable de citas.
Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: Cliente, Administrador Precondiciones: Tener una cuenta valida de correo electrónico además de contar
con información específica del auto como es: chasis, tipo combustible, código motor, placa(si tiene), kilometraje, etc.
Post condiciones: Solicitud enviada satisfactoriamente.Solicitud aprobada satisfactoriamente.
Flujo Normal de eventos Solicitud de Cita:
Página 50
1. El actor ingresa al formulario de solicitud de citas (puede acceder a dicho formulario sin iniciar sesión si es un cliente nuevo).
2. El actor rellena y envía el formulario web con toda la información requerida sobre su auto y propone una hora y fecha para la realización de la cita.
Aprobación de la cita1. El administrador del sistema recibe la solicitud, realiza una breve validación de
información.2. El administrador completa la información necesaria para la aprobación de la
cita.3. El administrador verifica disponibilidad de atención en la agenda de los
asesores de servicio.4. El administrado aprueba la cita al cliente.Flujos Alternos
Reprogramar CitaEn el paso 1 del flujo normal, si no existe disponibilidad en la agenda de talleres el administrador se comunicará con el cliente vía telefónica y propondrá una nueva hora conforme a la disponibilidad en la agenda, luego de lograr el acuerdo con el cliente se aprueba la cita.
Excepciones Cliente no puede presentarse a la cita
Si el cliente no puede presentarse a la cita por situaciones inesperadas el administrador del sistema puede cancelar dicha cita previa notificación del cliente.ReferenciasAnotaciones El proceso lo inicia el cliente con él envió del formulario de
solicitud y concluye con la aprobación de la cita por parte del administrador del sistema, pudiendo cambiar la fecha y hora inicial propuesta por el cliente en base a la disponibilidad de asesores y bahías, en acuerdo con el cliente.
Fuente: Autor (2011).
Cuadro 21. Especificación del Caso de Uso Realizar Solicitud.
Especificación del Caso de Uso: Realizar SolicitudID ECU_SICITASGCP_07Nombre: Realizar SolicitudDescripción: Los clientes realizan la solicitud en el
sistema de citas.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: ClientePrecondiciones: Acceder al formulario de solicitud de citas al cual se puede
acceder aunque no se tenga un usuario y contraseña de acceso al sistema.
Página 51
Rellenar el formulario de solicitud de citas con toda la información requerida.
Post condiciones: Solicitud enviada satisfactoriamente.Flujo Normal de eventos Solicitud de Cita:
1. El actor ingresa al formulario de solicitud de citas.2. El actor ingresa toda la información requerida en el formulario de
solicitud de citas.3. El actor envía el formulario de solicitud de citas.
Flujos AlternosEn el paso 1 del flujo normal, si el actor tiene unas credenciales para acceder al sistema puede iniciar sesión y acceder al formulario de solicitud de citas teniendo la facilidad que el sistema autocompleta parte de la información necesaria para realizar la solicitud.
ExcepcionesNingunoReferenciasAnotaciones La solicitud de citas puede realizarse aunque el actor no
tenga un usuario y contraseña para iniciar sesión en el sistema. Si el usuario realiza la solicitud con una sesión activa durante el procesamiento de la cita no es necesario validar la información del cliente.
Fuente: Autor (2011).
Cuadro 22. Especificación del Caso de Uso Aprobar Solicitud.
Especificación del Caso de Uso: Aprobar SolicitudID ECU_SICITASGCP_08Nombre: Aprobar SolicitudDescripción: El administrador del sistema aprueba la
cita de mantenimiento.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador debe tener una sesión activa en el sistema de
citas.Deben existir solicitudes pendientes de procesar.
Post condiciones: Solicitud aprobada satisfactoriamente.Flujo Normal de eventos Solicitud de Cita:
1. El actor selecciona una solicitud de cita2. El actor completa la información necesaria para aprobar la solicitud.
Página 52
3. Si la solicitud es de un cliente nuevo se realiza una breve validación de la información.
4. Se verifica disponibilidad en la agenda de los asesores de servicios y talleres para recibir el auto en la hora indicada en la solicitud.
5. Se aprueba la solicitud.
Flujos AlternosEn el paso 1 del flujo normal, si no existe disponibilidad en la agenda de talleres entonces se procede según el caso de uso reprogramar cita.
ExcepcionesNingunoReferenciasAnotaciones El proceso de validación se realiza solo cuando se trata de
un cliente nuevo del cual no se tiene registro en el sistema.
Fuente: Autor (2011).
Cuadro 23. Especificación del Caso de Uso Reprogramar Cita.
Especificación del Caso de Uso: Reprogramar CitaID ECU_SICITASGCP_09Nombre: Reprogramar CitaDescripción: Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: Deben existir solicitudes pendientes de procesar.Post condiciones: Solicitud aprobada con éxitoFlujo Normal de eventos Solicitud de Cita:
1. El actor selecciona una solicitud de cita2. El actor completa la información necesaria para aprobar la
solicitud.3. Si la solicitud es de un cliente nuevo se realiza una breve
validación de la información.4. Se verifica disponibilidad en la agenda de los asesores de
servicios y talleres para recibir el auto en la hora indicada en la solicitud.
5. Al no existir disponibilidad en la agenda se procede a llamar al cliente vía telefónica para consensuar una hora nueva para entrega del auto por parte del cliente.
6. Se aprueba la solicitud.
Flujos AlternosNinguno
Página 53
ExcepcionesNingunoReferenciasAnotaciones El proceso de validación se realiza solo cuando se trata de
un cliente nuevo del cual no se tiene registro en el sistema.
Fuente: Autor (2011).
Cuadro 24. Especificación del Caso de Uso Cancelar Cita.
Especificación del Caso de Uso: Cancelar CitaID ECU_SICITASGCP_10Nombre: Cancelar CitaDescripción: El administrador del sistema de citas
cancela una cita aprobada.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador debe tener una sesión activa en el sistema de
citas.Deben existir solicitudes aprobadas.
Post condiciones: Cita cancelada satisfactoriamente.Flujo Normal de eventos Solicitud de Cita:
1. El actor selecciona ver las citas aprobadas2. Seleccionar una cita en la lista de citas aprobadas.3. Procede a cancelar la cita de mantenimiento de servicios.
Flujos AlternosNinguno
ExcepcionesNingunoReferenciasAnotaciones El proceso de validación se realiza solo cuando se trata de
un cliente nuevo del cual no se tiene registro en el sistema.
Fuente: El Autor (2011).
Figura 17. Diagrama de Caso de Uso Gestión de Históricos.
Página 54
Fuente: Autor (2011).
Cuadro 25. Especificación del Caso de Uso Gestión de Históricos.
Especificación del Caso de Uso: Gestionar HistóricoID ECU_SICITASGCP_04Nombre: Gestión de HistóricosDescripción: Los clientes realizan consulta sobre sus
historiales de citas.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: Cliente, AdministradorPrecondiciones: 1) Haber concluido al menos un mantenimiento en los
talleres de servicio Pellas.2) Tener una sesión activa en el sistema de citas de
Mantenimientos de servicio.Post condiciones: Citas encontradas.Flujo Normal de eventos Consulta de Cita por cliente:
1. El actor ingresa a la sección de consulta de historiales de citas.2. El actor busca una cita determinada dentro de su historial.3. Consulta la información asociada a la cita de mantenimiento
seleccionada.
Consulta de Cita por el Administrado:1. El actor ingresa a la sección de consulta de historiales de citas.
Página 55
2. El actor busca una cita haciendo uso de los filtros disponibles como el código y nombre de cliente.
3. Consulta la información asociada a la cita de mantenimiento seleccionada.
Flujos AlternosNinguno
ExcepcionesNingunoReferenciasAnotaciones La consulta de históricos permite al cliente y al
administrador acceder a información particular sobre los mantenimientos realizados a los diferentes autos en el taller.
Fuente: Autor (2011).
Cuadro 26. Especificación del Caso de Uso Buscar Cita.
Especificación del Caso de Uso: Buscar CitaID ECU_SICITASGCP_11Nombre: Buscar CitaDescripción: El administrador del sistema de citas
busca un usuario en el sistema.Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador debe tener una sesión activa en el sistema de
citas.Deben existir usuarios ingresados en el sistema.
Post condiciones: Citas encontradas.Flujo Normal de eventos Buscar citas:
1. El actor ingresa a la ventana de gestión de usuarios.2. Ingresa en los campos de búsqueda el código o el
nombre del usuario a buscar.3. Seleccionar una cita en la lista de citas aprobadas.
Flujos AlternosNinguno
ExcepcionesNingunoReferenciasAnotaciones Ninguna.
Página 56
Fuente: Autor (2011).
Cuadro 27. Especificación del Caso de Uso Buscar Cita de Mantenimiento.
Especificación del Caso de Uso: Buscar Cita de MantenimientoID ECU_SICITASGCP_12Nombre: Buscar Cita de MantenimientoDescripción: El administrador del sistema de citas
puede buscar una cita específica o un conjunto de citas asociadas a un usuario.
Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: AdministradorPrecondiciones: El administrador debe tener una sesión activa en el
sistema de citas.El cliente debe existir en el sistema.
Post condiciones: Citas encontradas.Flujo Normal de eventos Buscar Cita:
1. El actor ingresa a la ventana de gestión de históricos.
2. Ingresa el código o nombre del cliente en el control de búsqueda.
3. Encuentra las citas asociadas al cliente objeto de búsqueda.
Flujos AlternosNinguno
ExcepcionesRegistros no encontrados.ReferenciasAnotaciones La búsqueda permite ver todos los mantenimientos
asociados a un cliente y los diferentes chasis que pueda tener asociados.
Fuente: Autor (2011).
Cuadro 28. Especificación del Caso de Uso Ver Detalle de Cita de Mantenimiento.
Especificación del Caso de Uso: Ver Detalle de Cita de Mantenimiento
Página 57
ID ECU_SICITASGCP_13Nombre: Ver cita de MantenimientoDescripción: El administrador o el cliente buscan
una determinada cita y procede a ver el detalle asociado.
Autor: Mario Osorno.Fecha de Creación: Domingo 20 de
Noviembre 2011Fecha última Modificación:
Domingo 20 de Noviembre 2011
Actores: Cliente, AdministradorPrecondiciones: El administrador debe tener una sesión activa en el
sistema de citas.El cliente de haber concluido al menos un mantenimiento.
Post condiciones: Ninguna.Flujo Normal de eventos Ver Citas de Mantenimientos:
1. El actor selecciona una cita de mantenimiento de servicios.
2. El actor revisa todo el detalle asociado a la orden del respectivo mantenimiento.
Flujos AlternosNinguno
ExcepcionesNingunoReferenciasAnotaciones El detalle de cita contiene información de interés
para el cliente en referencia a un mantenimiento. Se puede observar información como actividades realizadas al mantenimiento, kit de repuesto, costo de actividades, costo total, estimado total de tiempo del mantenimiento.
Fuente: Autor (2011).
Figura 18. Diagrama de Secuencia Autenticar Usuario.
Página 58
sd diagrama de secuencia Autenticar Usuario
Cliente
Login SicitasGcp UserSession:login_action AccesosUsuarios:VerficiarAcceso Iseries DB2Index Sicitasgcp
Introducir credenciales de acceso
IniciarSesion()
Validar Accesos()
validar permisosaplicacion()
ValidarUsuario()
status usuario()
Autorizaciones Usuario()
respuesta login()
redireccion index()
Fuente: Autor (2011).
Figura 19. Diagrama de Secuencia Buscar Usuario.
sd diagrama de secuencia de buscar usuario
Administrador
Interfaz bandeja deentrada de solicitud
de usuario
AdministracionUsuarios:buscar
Ingresar informacion()
buscar usuarios()
refrescar interfaz con resultados()
Fuente: Autor (2011).
Figura 20. Diagrama de Secuencia Crear Usuario.
Página 59
sd diagrama de secuencia crear usuario
Administrador
Interfaz Sistema GestionUsuarios:GuardarUsuario
Ingresar Informacion()
guardar Usuario()
validar informacion()
refrescar interfaz con la respuesta()
Fuente: Autor (2011).
Figura 21. Diagrama de Secuencia Editar Usuario.
sd diagrama de secuencia editar usuario
Administrador
GestionUsuarios:buscarInterfaz Sistema GestionUsuarios:guardarUsuario
IngresarDatos()
Buscar coincidencias clientes()
refrescar Interfaz()
editar Cliente()
Guardar Informacion()
validar informacion()refrescar Interfaz con la respuesta()
Fuente: Autor (2011).
Figura 22. Diagrama de Secuencia Realizar Solicitud.
Página 60
sd diagrama de secuencia realizar solicitud
Usuario
Interfaz formulariode solicitud cita
AdminCitas:RegistarCita
Ingresar Informacion()
validar informacion()
Ingresar solicitud de cita()
refrescar interfaz con larespuesta()
Fuente: Autor (2011).
Figura 23. Diagrama de Secuencia Aprobar Solicitud.
sd diagrama de secuencia aprobar solicitud
Administrador
Interfzar bandejade entrada de
solicitudes
AdministracionCitas:AprobarCita
procesar cita()
validar informacion()
validar disponiblilidad horario cita()
Confirma Cita()
refrescar interfaz con resultado()
Fuente: Autor (2011).
Figura 24. Diagrama de Secuencia Reprogramar Cita.
Página 61
sd diagrama de secuencia de reprogramar cita
Administrador
Interfaz bandejade entrada de
solicitudes
AdministracionCitas:AprobarCita
Cliente
cambio de horario de cita()
nuevo horario de cita()
aprobar cita()
validar informacion()
validardisponibilidadhorario cita()
aprobar solicitud cita()
refrescar interfaz con respuesta()
Fuente: Autor (2011).
Figura 25. Diagrama de Secuencia Cancelar Cita.
sd diagrama de secuencia de cancelar cita
Administrador
Interfaz bandejade solicitud citas
AdministracionCitas:CancelarCitas
cancelar cita()
cancelar cita()
refrescar interfaz con respuesta()
Fuente: Autor (2011).
Figura 26. Diagrama de Secuencia Buscar Cita Mantenimiento.
Página 62
sd diagrama de secuencia buscar cita mantenimiento
usuario
Interfaz bandejahistoria de citas
HistorialCitas:buscar
Ingresar Informacion()
buscar cita()
refrescar interfaz con resultados()
Fuente: Autor (2011).
Figura 27. Diagrama de Secuencia Ver Detalle Cita Mantenimiento.
sd diagrama de secuencia v er detalle cita mantenimie...
usuario
Interfaz bandejahistoria de citas
HistorialCitas:buscar Interfaz detalle decita de
mantenimiento
ingresar informacion()
buscar cita()
refresacar interfaz con resultados()
ver detalle cita()
mostrar detalle cita()
Fuente: Autor (2011).
Página 63
6.3 FASE 2- DISEÑO DEL SISTEMA
6.3.1 Documento Diseño ArquitectónicoDesarrollar un Sistema web para las citas de los talleres de servicio de la empresa Casa Pellas que optimice la recepción y procesamiento de solicitudes de mantenimiento.
DOCUMENTO DISEÑO ARQUITECTÓNICO
VERSION 1.0Autor Fecha Versión Descripción
Mario Osorno 01/11/2011 0.9 Versión preliminar como propuesta de desarrollo
Mario Osorno 12/11/2011 1.0 Versión preliminar
1. Introducción
El Diseño Arquitectónico produce la estructura de la aplicación representada como
una arquitectura de software que muestra sus componentes, sus conectores y las
restricciones arquitectónicas. Este diseño describe cómo se debe implementar las
especificaciones del diseño del sistema para asegurar que se cumplirá con todos
los requisitos acordados con el cliente.
2. Diseño Arquitectónico
El producto a desarrollar está definido bajo la siguiente arquitectura.
Página 64
Figura 28. Arquitectura del Sistema.Fuente: Autor (2011).
Esta arquitectura está dada por el modelo de vista de funcionalidad que describe
las funciones del sistema. Se encuentra representado por: modelo de vista
estructural y el modelo de despliegue.
2.1 Modelo de Vista de Estructural
Representa los elementos de diseño más importantes para la arquitectura del
sistema. Se encuentra representado por el modelo de clases y por las tarjetas
CRC.
2.1.1 Modelo de Clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura
de un sistema mostrando sus clases, atributos y las relaciones entre ellos. A
continuación se puede visualizar el modelo de clases del sistema.
Página 65
Figura 29. Diagrama de Clases del Sistema.Fuente: Autor (2011).
2.1.2Tarjetas CRC
Las tarjetas CRC son muy útiles para observar la relación entre cada una de las
clases que conforman el modelo de clases y sus responsabilidades. A
continuación se muestran las tarjetas CRC de las clases del modelo de clases:
2.2 Modelo deDespliegue
Se utiliza para modelar el hardware utilizado en la implementación del sistema y
las relaciones entre sus componentes.
Página 66
Figura 30. Diagrama de Componentes del Sistema.Fuente: Autor (2013).
Página 67
3. Diseño de Base de Datos
Es la visión que se tiene de un conjunto de datos relacionados, con cierto
significado inherente. Se encuentra representado por: diseño lógico y diseño
físico.
3.1Diseño lógico
Es la visión global de los datos, donde se incluye la descripción de todos los datos
e interrelaciones entre estos.
Figura 31. Diseño lógico de la Base de Datos.Fuente: Autor (2011).
Página 68
3.2Diseño físico
Es la representación de los datos con sus estructuras propias que va a emplear.
Figura 32. Diseño Físico de la Base de Datos.Fuente: Autor (2011).
Página 69
6.4 FASE 3- IMPLEMENTACION DEL SISTEMA
6.4.1 Documento Implantación del Software
Desarrollar un Sistema web para el control de inventario y facturación del supermercado Silva
DOCUMENTO IMPLANTANCION DEL SOFTWARE
VERSION 1.0Autores Fecha Versión Descripción
0.9 Versión preliminar como propuesta de desarrollo
1.0 Versión preliminar
1. Introducción
En este documento se describe los procesos técnicos de implementación
relacionados con la programación, pruebas y puesta en operación de la aplicación,
compuesto por los procesos de Programación & Integración, Pruebas de la
Aplicación y Entrega de la Aplicación, se llegará solo a las dos primeros procesos.
El primero Programación & Integración se encarga de producir, probar e integrar
los componentes arquitectónicos de la aplicación y el segundo Pruebas de la
Aplicación verifica y valida la aplicación para asegurarse que cumple con los
requisitos especificados y satisface las necesidades de la información y
automatización que tienen los usuarios.
2. Objetivos de la Implantación
El grupo de procesos de implementación tiene como objetivos generales los
siguientes:
Producir una versión de la aplicación de acuerdo a las especificaciones de
diseño arquitectónicoelaborado en los procesos de diseño.
Asegurarse que la versión cumple y satisface las necesidades del cliente.
Página 70
3. Especificaciones de los casos de pruebas
A continuación las especificaciones de los casos de pruebas aplicadas al sistema.
Especificación de Caso de Prueba: Usuario
Descripción: Este artefacto abarca el conjunto de pruebas realizadas sobre el proceso del sistema “Gestión de Usuarios”
Pruebas Efectuadas
Crear Usuario Buscar Usuario Editar Usuario
La prueba se realizará a partir del formulario de entrada de la aplicación.
1. Crear UsuarioDescripción Se ingresa al sistema utilizando un usuario y contraseña y se
ingresa al módulo “Gestión de Cita”Condiciones de Ejecución
La única condición es que el usuario esté registrado y tenga el perfil de administrador del sistema.
Entrada 1 Se introduce el nombre de usuario (login) en el campo de nombre usuario.
2 Se introduce la contraseña campo clave de acceso.3 Pulse el botón “Ingresar” (permite 3 intentos fallidos de
acceso)4 Se accede a la sección “Gestión de Usuarios” mediante el
menú.5 Se presiona el botón “Nuevo” para crear un nuevo registro6 Se ingresa el nombre del cliente y el sistema automáticamente
buscara información de este cliente en el sistema de talleres, de encontrar información se rellenarán automáticamente los campos.
7 Se completaran los campos restantes.8 Pulsamos el botón “Guardar” para crear el usuario.9 El sistema nos informará mediante un pop up que el usuario
ha sido creado exitosamente.Resultado Esperado
El sistema crea un Usuario correctamente.
Evaluación de Prueba
Prueba superada con éxito.
2. Buscar UsuariosDescripción El sistema mostrará la interfaz correspondiente al módulo “Gestión
de Usuario” con sus respectivas opciones (Agregar, Modificar)Condiciones de Ejecución
La única condición es que el usuario esté registrado para poder acceder al mismo y tenga el perfil de administrador.
Entrada 1 Se introduce el nombre de usuario (login) en el campo de nombre usuario.
Página 71
2 Se introduce la contraseña campo clave de acceso.3 Pulse el botón “Ingresar”(permite 3 intentos fallidos de acceso)4 Se accede a la sección “Gestión de Usuarios” mediante el
menú.5 Se coloca el nombre de usuario o código de cliente en el input
de filtro.6 Pulsamos el botón “Buscar”.7 El sistema nos muestra el resultado de la búsqueda donde
podemos seleccionar el registro que necesitemos.Resultado Esperado
El sistema busca el usuario correctamente.
Evaluación de la Prueba
Prueba superada con éxito
3. Modificar UsuarioDescripción El sistema mostrará la interfaz correspondiente al módulo “Gestión
de Usuario” con sus respectivas opciones (Agregar, Modificar)Condiciones de Ejecución
La única condición es que el usuario esté registrado para poder acceder al mismo y tenga el perfil de administrador.
Entrada 1 Se introduce el nombre de usuario (login) en el campo de nombre usuario.
2 Se introduce la contraseña campo clave de acceso.3 Pulse el botón “Ingresar”(permite 3 intentos fallidos de
acceso)4 Se accede a la sección “Gestión de Usuarios” mediante el
menú.5 Se coloca el nombre de usuario o código de cliente en el
input de filtro.6 Pulsamos el botón “Buscar”.7 El sistema nos muestra el resultado de la búsqueda donde
podemos seleccionar el registro que necesitemos.8 Una vez seleccionado el registro, pulsamos el botón
“Modificar” y el sistema nos mostrar una venta con la información del usuario.
9 Se modifica la información del usuario.10 Pulsamos en botón “Guardar”11 El sistema nos informa mediante un pop up que la
información ha sido guardada correctamente.Resultado Esperado
El sistema guarda la modificación de la información correctamente.
Evaluación de la Prueba
Prueba superada con éxito
Cuadro 29. Especificación de Caso de Prueba Usuario.Fuente: Autor (2011).
Página 72
Especificación de Caso de Prueba: Gestión de Históricos
Descripción: Este artefacto abarca el conjunto de pruebas realizadas sobre el proceso de sistema “Gestión de Históricos”
Pruebas Efectuadas
Consultar histórico de citas de un cliente.
1. Consultar de CitaDescripción: El usuario ingresa debe iniciar sesión en la aplicación y debe
dirigirse a la sección de históricos, ahí encontrará una interfaz que le permitirá listar, buscar y ver el detalle de las citas de mantenimiento que ha realizado.
Condiciones de Ejecución
Para consultar los históricos de citas el usuario debe iniciar sesión con un usuario y contraseña válida, bajo el perfil cliente.
Entrada 1 Se introduce el nombre de usuario (login) en el campo de nombre usuario.
2 Se introduce la contraseña campo clave de acceso.3 Pulse el botón “Ingresar”(permite 3 intentos fallidos de
acceso)4 Se accede a la sección “Consulta de Históricos” mediante el
menú.5 Al ingresar a la sección se muestra un grid con la
información general de los diversos mantenimientos asociados al cliente en sesión.
6 Se selecciona el registro que contiene la cita que deseamos ver en detalle.
7 Pulsamos el botón “Ver Detalle” y en una nueva ventana se nos muestra la información específica del mantenimiento seleccionado.
Resultado Esperado
El sistema permite acceder a la información básica y específica de las citas de mantenimiento de servicios.
Evaluación de Prueba
Prueba superada con éxito.
Cuadro 30. Especificación de Caso de Prueba Gestión de Histórico.Fuente: Autor (2011).
Página 73
4. Responsables de la Pruebas de la Aplicación
Las pruebas correspondientes de los procesos fueron realizadas y cubiertas al
finalizar la aplicación por todos los interesados (stakeholders) del proyecto, bajo
las políticas y estándares del supermercado Silva. El proceso de evaluación
estuvo a cargo del responsable del proyecto Ing. JadderArcia Cordero
5. Entrega de la Aplicación
El proceso técnico final del desarrollo de la aplicación será concluido con la
entrega de la aplicación al gerente del supermercado Silva
6. Capacitación de los Usuarios
A los usuarios de la aplicación se le dará la capacitación necesaria para manipular
de manera correcta losJadder Cordero procesos del sistema, la capacitación será
suministrada por el autor de la tesis desarrollador de la aplicación, quien diseño un
manual de usuario para que sirviese de guía. Se hará entrega del manual al
momento de entregar la aplicación y se pude evidenciar en el anexo de este
trabajo.
Página 74
CONCLUSIONES
Del análisis realizado en los supermercados silva, se pudo diagnosticar que la
creación del sistema de facturación e inventario es de gran importancia, pues de
ella depende la exactitud de como estarán almacenados, conllevando a efectuar
técnicas de recopilación de información (observación directa, entrevista y revisión
inventario), lo que permitió determinar los requisitos funcionales y no funcionales
para llevar acabo el desarrollo del sistema web, centrándose en los usuarios y sus
necesidades.
La metodología Watch, resultó ser una técnica favorable en el proceso de
desarrollo de software, brindado una serie de técnicas y procedimientos que
ayudaron a la construcción de la aplicación y cumplir con los requerimientos
definidos. Además el empleo del lenguaje UML, permitió obtener una visualización
más detallada de su estructura, ya que proporciona diferentes diagramas para
describir la arquitectura del sistema.
Gracias al desarrollo del sistema bajo plataforma web, lo cual permite su acceso
desde cualquier parte de la red o internet, ofreciendo así mayor facilidad a los
usuarios, ya q también facilita el trabajo a distancia, tampoco requiere complicadas
combinanciones de hardware o software ya que el uso de esta aplicación solo se
necesitara una pc, y será de fácil uso para los usarios ya que no requieren
conocimiento avanzados de computación.
Página 75
RECOMENDACIONES
Realizar la implantación del sistema desarrollado en el área de caja, para que los
usuarios puedan desempeñar sus funciones en un ambiente de trabajo
automatizado y organizado.
Elaborar un manual dirigido al personal del supermercado Silva, con el fin de
aprender a manejarlo y poder sacarle el máximo provecho a cada una de sus
funcionalidades.
Fortalecer la plataforma tecnológica del área para que todos los equipos
involucrados tengan acceso a la red, dado que la aplicación desarrollada es web.
Establecer un plan de mantenimiento de la aplicación asegurando así la
operatividad del sistema.
Continuar con el desarrollo de nuevos módulos en el sistema para incluir la mayor
cantidad de procesos operativos de la empresa, conllevando a efectuar una
aplicación más robusta y completa en pro de la total automatización.
Actualizar los manuales técnicos y de usuarios, en caso de que se agreguen
nuevos módulos a la aplicación.
Página 76
BIBLIOGRAFIA
Booch, G., Rumbaugh, J. & Jacobson, I. (2006).El Lenguaje Unificado de
Modelado. (2ª.ed.). Madrid: Pearson Educación.
Ceballos,F.J. (2005). Java 2. Curso de programación. Madrid: Rama.
Gómez, A. (2000). Sistemas de información. Herramientas prácticas para la
gestión empresarial. Madrid: Rama.
Herederos, C., López, J., Romo, S. & Salgado, S. (2004). Informática y
comunicaciones en la empresa.México: Pearson Educación.
Holzner,S. (2008). Java 2. Madrid: Anaya Multimedia.
IBM Corporation. (2011). DB2. Recuperado el 10 de Octubre de 2011, de
http://www-01.ibm.com/software/data/db2/
IBM Corporation. (2011), WebpshereApplication Server, Recuperado el 10 de
Octubre de 2011,
http://www-01.ibm.com/software/webservers/appserv/was/#
ITEISA Desarrollo y Sistemas, S.L. (2011). Aplicaciones Web. Recuperado el 20
de Septiembre de 2011, de http://www.iteisa.com/aplicaciones-web/
Página 77
Laundon, K.C. &Laundon, J.P. (2001).Administración de los Sistemas de
Información. Organización y Tecnología. (4ª.ed.). México: Prentice Hall
Hispanoamericana.
León, A. (2001). Teoría de los Sistemas Web. Madrid: Mcgraw Hill.
Mendoza,M. (1999).Sistema de información web.Madrid: Addison Wesley.
Montilva C, J. (2008). Watch. Método de desarrollo de software para aplicaciones
empresariales. Mérida-Venezuela: Nueva Visión.
Montilva C, J.& Barrios A, J. (2007). Desarrollo de software
empresarial.Recuperado el 20 de Septiembre de 2011,
dehttp://unefazuliasistemas.files.wordpress.com/2011/04/desarrollo-de-
software-empresarial-jonas-montilva-v0.pdf
Oracle Corporation. (2011).JavaServer Faces Technology.Recuperado el 10 de
Septiembre de 2011, de
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-
139869.html
O´Brien, J.A. &Marakas, G. M. (2006). Sistemas de Información Gerencial.
(6ª.ed.). México: McGraw Hill.
Powell, T.A. (1998). Ingeniería de Sitios Web. México: Prentice Hall.
Página 78
Pressman, R.S. (2002). Ingeniería del Software. Un enfoque práctico. (5ª.ed.).
Madrid: McGraw Hill.
Página 79
ANEXOS
Página 80