tesis minisuper silva45 (autoguardado).docx

114
Universidad Evangélica Nicaragüense Martin Luther King Escuela 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

Upload: bayardo-daniel-cruz-picon

Post on 29-Nov-2015

422 views

Category:

Documents


8 download

TRANSCRIPT

Page 1: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 2: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 3: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 4: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 5: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 6: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 7: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 8: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 9: Tesis Minisuper Silva45 (Autoguardado).docx

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.

Page 10: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 11: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 12: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 13: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 14: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 15: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 16: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 17: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 18: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 19: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 20: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 21: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 22: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 23: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 24: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 25: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 26: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 27: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 28: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 29: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 30: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 31: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 32: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 33: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 34: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 35: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 36: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 37: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 38: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 39: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 40: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 41: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 42: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 43: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 44: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 45: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 46: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 47: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 48: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 49: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 50: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 51: Tesis Minisuper Silva45 (Autoguardado).docx

Fuente: Autor (2011).

Figura 13. Diagrama de Actividad de Elaboración de Histórico de Cita.

Página 43

Page 52: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 53: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 54: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 55: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 56: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 57: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 58: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 59: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 60: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 61: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 62: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 63: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 64: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 65: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 66: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 67: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 68: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 69: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 70: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 71: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 72: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 73: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 74: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 75: Tesis Minisuper Silva45 (Autoguardado).docx

Figura 30. Diagrama de Componentes del Sistema.Fuente: Autor (2013).

Página 67

Page 76: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 77: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 78: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 79: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 80: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 81: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 82: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 83: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 84: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 85: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 86: Tesis Minisuper Silva45 (Autoguardado).docx

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

Page 87: Tesis Minisuper Silva45 (Autoguardado).docx

Pressman, R.S. (2002). Ingeniería del Software. Un enfoque práctico. (5ª.ed.).

Madrid: McGraw Hill.

Página 79

Page 88: Tesis Minisuper Silva45 (Autoguardado).docx

ANEXOS

Página 80