Informe Practica Quichua

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
“INFORME DE PRÁCTICAS PRE-PROFESIONALES”
Título : Aplicación web para la gestión de información del servicio técnico.
Entidad : Megacenter Perú SAC
Alumno : Quichua Poma, Grimaldo
Asesor : Msc. Ing. Porras Flores Efraín Elías.
Ayacucho – Perú
2017
DEDICATORIA
A mis padres y a mis hermanos, quienes siempre me apoyaron en los distintos momentos
de mi vida, por todo el aliento brindado y confiar en mí a pesar de tantas dificultades.
A los docentes de mi escuela, quienes mi apoyaron, mi enseñaron y formaron parte de mi

aprendizaje y ser competitivo en la sociedad.
ii
AGRADECIMIENTO
A la Universidad Nacional de San Cristóbal de Huamanga, mi alma máter, por la

oportunidad de formar parte y ser un buen profesional, a todos los docentes que con sus
enseñanzas de alguna forma han contribuido en el desarrollo de mi formación.
iii
CONTENIDO
DEDICATORIA.............................................................................................................. ii
AGRADECIMIENTO ................................................................................................... iii
CONTENIDO ................................................................................................................. iv
RESUMEN ..................................................................................................................... vi
INTRODUCCIÓN ........................................................................................................ vii
CAPITULO I
OBJETIVOS DEL TRABAJO
1.1. OBJETIVO GENERAL ..................................................................................... 1
1.2. OBJETIVOS ESPECÍFICOS ............................................................................. 1
CAPITULO II
MARCO TEORICO
2.1. GESTIÓN DE INFORMACIÓN ....................................................................... 2
2.2. TIEMPO DE ESPERA DEL CLIENTE ............................................................ 2
2.3. PROCESO .......................................................................................................... 2
2.4. CALIDAD DE SERVICIO ................................................................................ 3
2.5. SISTEMA DE INFORMACIÓN ....................................................................... 4
2.5.1. ACTIVIDADES DE UN SISTEMA DE INFORMACIÓN ............................... 4
2.6. APLICACIÓN WEB .......................................................................................... 5
2.6.1. VENTAJAS DE UNA APLICACIÓN WEB ..................................................... 6
2.7. INGENIERÍA DE SOFTWARE ........................................................................ 7
2.7.1. MODELOS DEL PROCESO DE SOFTWARE ................................................ 8
2.7.2. CICLO DE VIDA DE UN SOFTWARE ........................................................... 9
2.8. METODOLOGÍA ICONIX ............................................................................. 12
2.8.1. CARACTERÍSTICAS DE ICONIX ................................................................ 13
2.8.2. FACES DE ICONIX ........................................................................................ 14
iv
2.9. SISTEMA GESTOR DE BASE DE DATOS RELACIÓN ............................. 23
2.10. LENGUAJE DE PROGRAMACIÓN ORIENTADO A OBJETOS ............... 24
2.11. TECNOLOGÍAS DE INTERNET ................................................................... 26
CAPITULO III
RESULTADOS
3.1. DESARROLLO DEL PROYECTO ................................................................ 28
3.1.1. MODELADO CONCEPTUAL ........................................................................ 28
3.1.2. ANÁLISIS DE REQUERIMIENTOS .............................................................. 28
3.1.3. MODELO DE CASO DE USO ........................................................................ 34
3.1.4. REVISIÓN DE REQUISITOS ......................................................................... 50
3.1.5. DISEÑO PRELIMINAR .................................................................................. 64
3.1.6. REVISIÓN DEL DISEÑO PRELIMINAR ...................................................... 70
3.1.7. ARQUITECTURA TÉCNICA ......................................................................... 77
3.1.8. DISEÑO............................................................................................................ 80
3.1.9. IMPLEMENTACIÓN ...................................................................................... 87
CAPITULO IV
RECOMENDACIONES
3.2. RECOMENDACIONES ................................................................................ 100
BIBLIOGRAFÍA ........................................................................................................ 101
v
RESUMEN
La práctica pre-profesional se realizó en el área de Sistemas de la empresa

MEGACENTER PERÚ SAC durante los meses de enero a mayo del 2017. Con el
propósito de desarrollar un sistema web de gestión de servicio técnico, para mejorar los
procesos de gestión del ciclo de atención a las órdenes de servicio, solucionando tareas
pendientes y realizar el seguimiento del estado de orden de trabajo del equipo ingresado.
Teniendo los principales módulos de administrar personal, registrar clientes, generar
orden de trabajo, generar informe técnico y administrar estado del equipo por entregar.
El desarrollo del presente informe presento en capítulos sobre el ciclo de desarrollo del
sistema mediante la metodología ágil y formal ICONIX.
En capítulo I presenta el objetivo general y objetivos específicos del proyecto.
En capitulo II presenta el marco teórico, gestión de información, sistemas de información,

software, metodología Iconix, gestor de base de datos, programación orientado a objetos
y tecnologías de internet.
En capítulo III presenta el desarrollo de la metodología Iconix, para el desarrollo del

sistema web de gestión de información del servicio técnico, siguiendo todas las fases de
la metodología con sus respectivos diagramas estáticos (modelo de dominio, modelo de
dominio actualizado y diagrama de clases) y dinámicos (diagrama de casos de uso,
diagrama de robustez y diagrama de secuencia).
El cuarto capítulo presenta las conclusiones y recomendaciones sobre la experiencia del

desarrollo de software y recomendaciones para buen funcionamiento del sistema.
vi
INTRODUCCIÓN
Según Cruz (2008), Gestión de la información es la denominación convencional de un

conjunto de procesos por los cuales se controla el ciclo de vida de la información, desde
su obtención (por creación o captura), hasta su disposición final (su archivo o
eliminación). El servicio técnico es el conjunto de acciones realizadas por uno o varios
especialistas para prevenir y/o solucionar problemas de una variedad de equipos.
El área de servicio técnico es el responsable de todo el proceso de soporte técnico, donde

el equipo técnico realiza soluciones innovadoras, rápidas, seguras, confiables y efectivas,
para que la organización brinde plena satisfacción a sus necesidades de nuestro cliente.
La elección personal que me impulso a realizar mi practica en este proyecto es para poder
mejorar la gestión de información de servicio técnico y los procesos relacionados al
soporte técnico, el motivo es que en la empresa el proceso de soporte técnico y la gestión
de información era ineficiente, entonces esto genera la insatisfacción del cliente como en
largas tiempos de espera, falta de información sobre el diagnóstico del equipo,
desconfianza sobre el proceso de reparación de su producto, etc., desarrollando el sistema
de gestión de información podemos satisfacer cabalmente las necesidades y expectativas
del cliente con calidad, eficiencia y eficacia, generando confianza entre la empresa y el
cliente.
Los objetivos específicos son: a) Analizar, diseñar, implementar y probar la gestión de

servicio técnico, con la finalidad de automatizar los procesos de gestión que se realizan
en las áreas de recepción y de servicio técnico. b) Analizar, diseñar, implementar y probar
la automatización de la gestión de servicio técnico, con la finalidad de disminuir el tiempo
de espera del cliente sobre el proceso de reparación del equipo ingresado. c) Analizar,
diseñar, implementar y probar la automatización de la gestión de servicio técnico, con la
finalidad de impedir la perdida de alguna información sobre el proceso de diagnóstico y
reparación del equipo.
vii
CAPÍTULO I
OBJETIVOS DEL TRABAJO
1.1. OBJETIVO GENERAL

Desarrollar una aplicación web para la gestión de información de servicio técnico,
mediante la metodología de desarrollo Iconix, un sistema de gestor de base de datos
relacional, un lenguaje de programación orientado a objetos y tecnologías de internet, con
la finalidad de automatizar los procesos de gestión del área de recepción y servicio
técnico.
1.2. OBJETIVOS ESPECÍFICOS

a) Analizar, diseñar, implementar y probar la gestión de servicio técnico, con la
finalidad de automatizar los procesos de gestión que se realizan en las áreas de
recepción y de servicio técnico.
b) Analizar, diseñar, implementar y probar la automatización de la gestión de
servicio técnico, con la finalidad de disminuir el tiempo de espera del cliente sobre
el proceso de reparación del equipo ingresado.
c) Analizar, diseñar, implementar y probar la automatización de la gestión de
servicio técnico, con la finalidad de impedir la perdida de alguna información
sobre el proceso de diagnóstico y reparación del equipo.
1
CAPITULO II
MARCO TEÓRICO
2.1. GESTIÓN DE INFORMACIÓN
Según Cruz (2008), “la GI es también una actividad económica mediante la cual
se trazan objetivos y estrategias, se organizan y distribuyen recursos, y se conducen y
controlan acciones para un mejor manejo y uso de la información, de forma que se
garantice eficaz y eficientemente, su identificación, obtención, representación,
almacenamiento, búsqueda y recuperación, circulación o distribución, análisis y uso, con
beneficios y la creación de ventajas competitivas para la organización”.
Gestión de la información (GI) es la denominación convencional de un conjunto de

procesos por los cuales se controla el ciclo de vida de la información, desde su obtención
(por creación o captura), hasta su disposición final (su archivo o eliminación).
Según Chávez y Pérez (2009), “La gestión de información es coordinar, dirigir y controlar
los flujos de información que tiene lugar en cada sistema, de manera sistemática.
Tomando en cuenta segmentos típicos de los sistemas, como pueden ser el ambiente, los
procesos que se generan, las personas y las tecnologías implicadas entre otros; que de
conjunto interrelacionan. Así como del conocimiento actualizado y preciso del ciclo de
vida de los documentos que genera el sistema”.
2.2. TIEMPO DE ESPERA DEL CLIENTE

Según Bravo (2008), el “Tiempo de espera del cliente es cada vez más importante,
es la espera física en una cola para ser atendido”.
Huerta y Rodríguez (2006), “Uno de los recursos no renovables más valioso con que
cuenta el ser humano es el tiempo. Cuando los directivos y colaboradores de la
organización administran adecuadamente el tiempo, contribuyen a optimizar las
funciones y a eliminar tiempos muertos para mejorar el desempeño organizacional”.
2.3. PROCESO
Para Bravo (2008), “Los procesos representan el hacer de la organización, por lo
tanto, un proceso es una competencia que la empresa tiene (comprar, vender, entregar),
2
la cual es realizada por varias personas y se desagrega en un conjunto de actividades e
interacciones. Una actividad es el hacer de una persona en un momento del tiempo, tal
como llenar una solicitud o cobrar en una caja. Una interacción es lo que sucede entre las
actividades y que permiten llegar a obtener la entrada de la siguiente, tal como un
documento que se envía por mano o por computador y que debe llegar a tiempo a su
destino”.
Según Bravo (2015) “Un proceso es una competencia de la organización que le agrega
valor al cliente a través del trabajo en equipo de personas, en una secuencia organizada
de actividades, interacciones, estructura y recursos que transciende a las áreas”.
2.4. CALIDAD DE SERVICIO

Según Bravo (2015) “Tiene que ver con eliminar la insatisfacción del cliente
producto de la no satisfacción de las expectativas. Es decir, en la medida que el producto
o ser-vicio hace lo que tiene que hacer, en tiempo y costos convenidos, reducimos los
motivos de insatisfacción del cliente. Es un concepto relativo a las expectativas del cliente
en un rango de precios generalmente aceptado”.
Según Armijo (2011), “La calidad del servicio es una dimensión específica del
desempeño que se refiere a la capacidad de la institución para responder en forma rápida
y directa a las necesidades de sus usuarios. Son extensiones de la calidad factores tales
como: oportunidad, accesibilidad, precisión y continuidad en la entrega de los servicios,
comodidad y cortesía en la atención. La calidad de servicio se puede mejorar por la vía
de mejorar los atributos o características de los servicios que se entregan a los usuarios”.
“La calidad en la gestión pública, debe medirse en función de la capacidad para satisfacer
oportuna y adecuadamente las necesidades y expectativas de los ciudadanos, de acuerdo
a metas preestablecidas, alineadas con los fines y propósitos superiores de la
administración pública, de acuerdo a resultados cuantificables que tengan en cuenta el
interés y las necesidades de la sociedad”, SGP/PCM (2014).
SISTEMA DE GESTIÓN DE INFORMACIÓN DE SERVICIO TÉCNICO

El sistema de gestión de información de servicio técnico está diseñado, pensado y
3
programado con nuestros clientes que ofrecen servicios de asistencia técnica a domicilio.
El sistema de gestión de información le permite gestionar eficientemente los órdenes de

trabajo, informe técnico del equipo y administrar el estado de reparación del equipo.
EQUIPO TÉCNICO
Los técnicos, son los encargados del mantenimiento o reparación con mayor movilidad
de la empresa. La mayoría de ocasiones se encuentran en movimiento sin contar con las
herramientas necesarias para ofrecer un servicio óptimo.
2.5. SISTEMA DE INFORMACIÓN

Según Cotos (2005), “Un sistema de información es un sistema que reúne,
almacena, procesa y distribuye conjuntos de información entre los diferentes elementos
que configuran una organización, y entre la organización misma y su entorno”.
Para Pressman (2005), “Un sistema de información posee cuatro actividades básicas que
son de entrada, almacenamiento, procesamiento y salida de información”.
Según Sánchez (2004), “Es un conjunto de componentes que interactúan entre sí, con la
finalidad de apoyar las actividades de una organización; como tal, está compuesto por un
conjunto de elementos de hardware, software, personas, procedimientos, herramientas y
otros factores. Posee cuatro actividades básicas: entrada, almacenamiento, procesamiento
y salida de información”.
2.5.1. ACTIVIDADES DE UN SISTEMA DE INFORMACIÓN

A. ENTRADA DE INFORMACIÓN
Según Tomayo (2000), “Es el proceso mediante el cual el Sistema de Información
toma los datos que requiere para procesar la información”.
Según Tomayo (2000), “Las entradas pueden ser manuales o automáticas. Los manuales
son aquellas que se proporcionan en forma directa por el usuario, mientras que las
automáticas son datos o información que provienen o son tomadas de otros sistemas o
módulos”.
4
B. ALMACENAMIENTO DE INFORMACIÓN
Según Amaya (2005), “El almacenamiento es una de las actividades o capacidades
más importantes que tiene una computadora, ya que a través de esta propiedad el sistema
puede recordar la información guardada en la sección o proceso anterior”.
C. PROCESAMIENTO DE INFORMACIÓN
Según Fernandez (2006), “Es la capacidad del Sistema de Información para
efectuar cálculos de acuerdo con una secuencia de operaciones preestablecidas”.
Para Tomayo (2000), “El procesamiento de información permite la transformación de

datos fuente en información que puede ser utilizada para la toma de decisiones, lo que
hace posible, entre otras cosas, que un tomador de decisiones genere una proyección
financiera a partir de los datos que contiene un estado de resultados o un balance general
de un año base”.
D. SALIDA DE INFORMACIÓN
Según Fernández (2006), “La salida es la capacidad de un Sistema de Información
para sacar la información procesada o bien datos de entrada al exterior”.
Según Amaya (2005), “Un sistema de información es el sistema de personas, registros de

datos y actividades que procesa los datos y la información en cierta organización,
incluyendo manuales de procesos o procesos automatizados”.
2.6. APLICACIÓN WEB

Según Rale (2011), “En la ingeniería de software se denomina aplicación web a
aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a
través de Internet o de una intranet mediante un navegador”.
Para Moreira (2009), Los "sistemas Web" o también conocido como "aplicaciones Web"
son aquellos que están creados e instalados no sobre una plataforma o sistemas operativos
(Windows, Linux). Sino que se alojan en un servidor en Internet o sobre una intranet (red
local).
5
Según Moreira (2009), “Una aplicación web es un programa informático que en lugar de
ejecutarse en un ordenador personal (en adelante, una aplicación de escritorio), se ejecuta
parcialmente en un servidor remoto, al que se accede a través de Internet por medio de un
navegador web”.
2.6.1. VENTAJAS DE UNA APLICACIÓN WEB

Según Moreira (2009), una aplicación web tiene las siguientes ventajas:
a) Una aplicación web tiene la misma estructura de una página web. Los empleados,
tanto en su casa como en la oficina, han de adaptarse cada día a decenas de páginas
web que tienen un diseño y un modo de uso diferente. Una aplicación de escritorio
requiere de una curva de aprendizaje más alta, y una aplicación web se aprende
de forma más rápida y eficaz. Por ello, los empleados posiblemente lo
agradecerán.
b) Los datos con los que se trabaja en una aplicación web se almacenan y procesan
en ese servidor externo, aunque en cualquier momento se puede guardar, por
ejemplo, informes y hojas de cálculo en el ordenador. Esto supone aumentar la
seguridad de los datos, pues en caso de virus informáticos y otros problemas de
seguridad en el ordenador, no existe riesgo de pérdida de información ya que el
servidor actúa como ejecutor y como copia de seguridad. En el peor de los casos
solo habría que formatear el ordenador y configurar un navegador web. También,
cuando se producen robos de equipos, el ladrón no se llevará información
privilegiada, campo especialmente aplicable hoy en día con el creciente uso de
ordenadores portátiles por parte de empleados de la empresa.
c) El mantenimiento es más barato, rápido y eficaz. Cuando se trabaja con una

aplicación de escritorio, un cambio en la misma supone el aplicar el mismo en
todos los ordenadores de la empresa: más carga de trabajo para el informático (y
mayor factura por horas si el servicio es subcontratado), y posiblemente el
empleado tendrá que dejar de trabajar durante un tiempo, que podría ser de
minutos o de horas. También, un cambio en la aplicación afecta inmediatamente
a todos los usuarios, siendo ésta una ventaja en el caso en que haya que hacer un
cambio urgente en la misma.
6
d) Con relación al personal debidamente autorizado, este puede acceder y
modificar los datos con los que trabaje en cualquier lugar del mundo y de
forma instantánea. Esto es especialmente útil en la gestión de redes comerciales
o en el caso de teletrabajadores: el control de sus actividades se lleva de forma
puntual y en directo, sin esperas como por ejemplo, a que el empleado venga por
la oficina y enseñe sus datos. Si aun así se quiere proteger este acceso desde
cualquier parte, siempre se puede limitar el pleno acceso y hacer que solo las
conexiones que se hagan desde la oficina puedan usar el programa.
e) Relacionado con el punto anterior, se optimiza el tiempo de trabajo por

empleado. Como los datos están en un lugar común, y no en el ordenador de cada
uno, en muchas ocasiones se podrá acceder a los datos necesarios por la aplicación
web sin tener que ir a pedir esos datos a otro compañero u otro departamento.
f) Internet se basa en estándares. Quizás en el momento actual, o en el futuro, podría

interesarnos que nuestra aplicación web pueda interactuar con otras
aplicaciones web propias o de terceros (o incluso con aplicaciones de
escritorio), ampliando y mejorando así sus funciones y características.
2.7. INGENIERÍA DE SOFTWARE

Para Diehl (2007), “La ingeniería de software es toda información relacionada al
desarrollo de software o a la información relacionada al desarrollo de un sistema
específico. Aquí se incluye información relacionada al proyecto, información sobre la
tecnología de software, conocimiento acerca de sistemas similares y la información
detallada relacionada a la identificación y solución de problemas técnicos”.
Según Sommerville (2005), “La ingeniería de software es una disciplina de ingeniería que
comprende todos los aspectos de la producción de software desde las etapas iniciales de
la especificación del sistema, hasta el mantenimiento después de que se utiliza. La
ingeniería de software comprende las formas prácticas para desarrollar y entregar un
software útil”.
7
2.7.1. MODELOS DEL PROCESO DE SOFTWARE
Según James (2004), “Los modelos generales no son descripciones definitivas de
los procesos del software. Más bien, son abstracciones de los procesos que se pueden
utilizar para explicar diferentes enfoques para el desarrollo de software. Puede pensarse
en ellos como marcos de trabajo del proceso que pueden ser extendidos y adaptados para
crear procesos más específicos de ingeniería de software”.
Para Sommerville (2005), “Un modelo del proceso software es una representación
abstracta de un proceso del software, cada modelo de proceso representa un proceso desde
una perspectiva particular, y así proporciona solo información parcial sobre ese proceso”.
Los modelos de procesos de software son:
A. EL MODELO EN CASCADA
Sommerville (2005), “Considera las actividades fundamentales del proceso de
especificación, desarrollado, validación y evolución, y los representa como fases
separados del proceso, tales como la especificación de los requerimientos, el diseño del
software, la implementación, las pruebas”.
Según Diehl (2007), “Este es el más básico de todos los modelos y sirve como bloque de
construcción para los demás modelos del ciclo de vida. La visión del modelo cascada del
desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través
de una secuencia más simple de fases, cada fase tiene un conjunto de metas bien definidas,
y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o
quizás a una subsecuencia de metas de la fase”.
B. DESARROLLO EVOLUTIVO
Según Sommerville (2005), “Este enfoque que entrelaza las actividades de
especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a
partir de especificaciones abstractas. Este se refina basándose en las peticiones del cliente
para producir un sistema que satisfaga sus necesidades”.
C. INGENIERÍA DE SOFTWARE BASADO EN COMPONENTES

Para Sommerville (2005), “Este enfoque se basa en la existencia de un número
significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca
8
en integrar estos componentes en el sistema más que en desarrollarlos desde cero”.
2.7.2. CICLO DE VIDA DE UN SOFTWARE

Según Winblad, Edwards y King (2003), “Un modelo de ciclo de vida de software
es una vista de actividades que ocurren durante el desarrollo de software, intenta
determinar el orden de las etapas involucradas y los criterios de transición asociadas entre
estos etapas”.
Para Sommerville (2005), “un modelo de ciclo de vida define el estado de las fases a
través de las cuales se mueve un proyecto de desarrollo de software”.
El termino ciclo de vida del software describe el desarrollo de software desde la fase
inicial hasta la fase final, proponiendo etapas que sirven como referencia para realizar
este proceso. Las fases que conforman el ciclo de vida son:
Figura N° 2.1: Ciclo de vida de software Sommerville (2005)
A. ANÁLISIS PREVIO
Según Campderrich (2003), “Ahora se trata de formalizar lo requerimientos; el
documento obtenido en la etapa anterior se tomara como punto de partida para esta fase.
9
Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y
depurar”.
B. ANÁLISIS DE REQUISITOS
Según Campderrich (2003), “Es necesario determinar qué elementos intervienen
en el sistema a desarrollar, asi como su estructura, relaciones, evolución en el tiempo,
detalle de sus funcionalidades, que van a dar una descripción clara de que sistema vamos
a construir, que funcionalidades va a adoptar y que comportamiento va a tener”.
Según Diehl (2007), “Investigar y documentar las decisiones acerca de las cuales son los
alcances que tendrá el sistema y cuales requerimientos estarán fuera de este. Esta es quizás
la etapa más crítica de todo el proyecto debido a que en ella el usuario define qué es lo
que tendrá y no tendrá en el sistema final”.
Según Sommerville (2005), “Se investiga y documenta como el usuario interactúa con el
sistema y como esto afecta al mismo”.
C. DISEÑO
Según Sommerville (2005), “Se definirán en detalles entidades y relaciones de las
bases de datos, se pasara de cosas de uso esenciales a su definición como casos
expandidos reales, se seleccionara el lenguaje más adecuado, el Sistema Gestor de Bases
de Datos a utilizar en su caso”.
Según Winblad, Edwards y King (2003), “El proceso de diseño del sistema divide los
requerimientos en sistemas hardware o software. Establece una arquitectura completa del
sistema. El diseño del software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones”.
Según Winblad, Edwards y King (2003), “En esta etapa se tiene un razonable detalle y
descripción de las principales clases en el sistema. Se debe de revisar cada clase
definiéndoles los atributos y operaciones”.
D. PROGRAMACIÓN
Según Campderrich (2003), “El código del programa debe desarrollar la tarea
10
solicitada, y debe ser legible de modo que otros programadores lo puedan mantener. Los
programas se escriben usualmente en módulos separados, cada módulo desarrolla alguna
tarea específica y debe funcionar independientemente y en relación con el resto del
programa”.
Segun Winblad, Edwards y King (2003), “Se deben de definir clases en código, para
cualquier lenguaje de programación utilizado, como primer paso se debe de definir cada
clase en el lenguaje escogido. En la definición de la clase se debe de especificar: nombre
de la clase, nombre de los atributos y nombre de las operaciones indicando el número y
tipo de sus argumentos”.
Para Sommerville (2005), “Las operaciones definidas en una clase debe ser implementada
como una función separada en el programa. Las clases simples pueden ser implementadas
por un simple programador mientras las clases complejas tienen que ser desarrolladas por
un equipo de programadores debido a que pueden tener cientos de operaciones
relacionadas”.
E. PRUEBA
“Durante la fase de pruebas, el programa se ejecuta y se revisa. Las tareas deben
ejecutarse sin errores en los resultados y también sin errores fatales. Los defectos en los
programas se llaman bugs” (Sommerville, 2005).
“El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado

correctamente, sin errores de diseño y/o programador” (Campderrich, 2003).
“Cada clase antes de poder ser considerada segura para ser rehusada por otros
programadores en otros proyectos deberá ser aprobada debidamente, esta prueba tendrá
que realizarse de manera separada” (Winblad, Edwards y King, 2003).
F. MANTENIMIENTO
“Durante la fase de mantenimiento, se determina cualquier error y deficiencia en el
programa, y se realizan cualquier acción para resolverla, mientras se preserva la
integridad del programa” (Sommerville, 2005).
11
2.8. METODOLOGÍA ICONIX
Para Augusto (2005), “es un proceso de desarrollo de software orientado a objetos
que tiene como característica ser guiado por casos de uso y ser un modelo iterativo
incremental, ser una metodología intermediaria entre la complejidad de RUP y la
simplicidad de XP sin dejar de lado el análisis utilizando el lenguaje UML”.
Según Rosenberg y Sthephens (1999), “el proceso ICONIX se define como un proceso
desarrollo práctico. ICONIX está entre la complejidad del RUP (Rational Unified
Processes) y la simplicidad y pragmatismo del XP (Extreme Programming), sin eliminar
las tareas de análisis y diseño que XP no contempla”.
Según Porras (2011), “el proceso ICONIX se divide en una parte estática y otra dinámica,
que son iterativos, podemos hacer una iteración de todo el proceso para un par de casos,
hasta codificar y hacer las pruebas. Por esto, el proceso ICONIX es ideal para proyectos
pequeños y medianos”, en resumen la metodología ICONIX es:
a) El primero.- Identificar el mundo real y los objetos de dominio del negocio
(modelo de dominio).
b) El segundo.- Definir los requisitos de comportamiento (casos de uso).
c) El tercero.- Realizar análisis de robustez para eliminar la ambigüedad de los casos
de uso y determinar los defectos del modelo de dominio (diagrama de robustez).
d) El cuarto paso.- asignar el comportamiento a los objetos (diagrama de secuencia),
e) El quinto paso.- finalizar el modelo estático (diagrama de clases)
f) El sexto paso.- escribir y generar código (código fuente)
g) El séptimo paso.- realizar pruebas de aceptación (prueba).
Para Rosenberg y Stephens (2007) el “Proceso de Iconix se divide en flujos de trabajo

dinámicos y estáticos, que son altamente repetitivo; usted puede ir a través de una
repetición de todo el proceso para una pequeña cantidad de casos de uso (quizás un par
de paquetes de valor, que no es una cantidad enorme teniendo en cuenta que cada caso de
uso es sólo un par de párrafos), todo el camino a la fuente de código y pruebas unitarias.
Por esta razón, el proceso Iconix es muy adecuado para proyectos agiles, donde se
necesita información rápida sobre factores tales como los requisitos, el diseño, y las
estimaciones”.
12
Figura N° 2.2: Flujo de trabajo Iconex, Rosenberg y Sthephens (2007)
2.8.1. CARACTERÍSTICAS DE ICONIX

A. ITERATIVO E INCREMENTAL
“Las iteraciones múltiples ocurren entre el desarrollo del modelo de dominio e
identificar y analizar los casos de uso. Otras iteraciones existen también, como los
procesos del equipo a través del ciclo de vida. El modelo estático se refina
incrementalmente durante las iteraciones sucesivas a través del modelo dinámico
(compuesto de los casos de uso, análisis de robustez y el diagrama de secuencia)”
(Rosenberg y Stephens, 2007).
“Varias iteraciones ocurren entre el desarrollo del modelo del dominio y la identificación
de los casos de uso. El modelo estático es incrementalmente refinado por los modelos
dinámicos“(Saldaña, 2011).
B. TRAZABILIDAD
“El enfoque ofrece un alto grado de seguimiento. Por el contrario, a cada paso
usted consultara de alguna manera los requisitos anteriores. Nunca hay un punto en que
el proceso le permita desviarse lejos de las necesidades del usuario. Seguimiento se refiere
también, al hecho que usted puede seguir los objetos paso a paso como el análisis dentro
del diseño” (Rosenberg y Stephens, 2007).
13
“Cada paso está referenciado por algún requisito. Se define trazabilidad como la
capacidad de seguir una relación entre los diferentes artefactos producidos” (Saldaña,
2011).
C. DINÁMICA DE UML
Según Rosenberg y Scott (1999), “La metodología ofrece un uso dinámica del
UML como los diagramas de caso de uso, diagrama de secuencia y diagrama de
colaboración”.
2.8.2. FACES DE ICONIX

Según Porras (2011), las principales actividades de ICONIX son: análisis de
requisitos, análisis y diseño preliminar, diseño e implementación.
ANÁLISIS DE REQUISITOS
a) Requisitos funcionales: Definir lo que el sistema debe ser capaz de hacer.
Dependiendo de la forma en que su proyecto está organizado, ya sea que usted
participe en la creación de los requisitos funcionales o que los requisitos serán
"dictados desde lo alto" de un cliente o un equipo de analistas de negocios.
b) Modelo de Dominio: debe comprender el ámbito del problema sin ambigüedad.
c) Requisitos de comportamiento: Define la forma en que el usuario y el sistema
interactúan. Es decir, escribir el primer proyecto de casos de uso. Comenzar con
un prototipo GUI e identificar todos los casos de uso, o por lo menos, tener una
primera lista de casos de uso, que cambiara a medida que se explora los requisitos
en mayor profundidad.
d) Etapa 1: Revisión de Requisitos: en esta etapa la descripción de los casos de uso
debe coincidir con los requisitos del cliente. Revisar los casos de uso por grupos
pequeños, antes de diseñarlos. Luego en cada iteración, para un pequeño grupo de
casos de uso, hacer lo que describimos a continuación.
DISEÑO PRELIMINAR
a) Dibujar diagrama de robustez.- Es una “imagen del objeto” descripción por
paso de una caso de uso, reescribir los casos de uso a medida que avanza.
b) Actualizar modelo de dominio.- Mientras escribe los casos de uso y dibuja el
14
diagrama de robustez, descubrirá algunas clases “pérdidas”, corregir las
ambigüedades y, añadir atributos a los objetos de dominio.
c) Nombrar controladores.- Nombre todas las funciones lógicas del software,
necesarios para que los casos de uso funcionen.
d) Escribir.- Reescribir el borrador de los casos de uso. Inicia la etapa 2 con la
revisión del diseño preliminar.
DISEÑO DETALLADO
a) Diagrama de Secuencia.- Dibuje un diagrama de secuencia, uno para cada caso
de uso, para mostrar en detalle cómo va a implementar el caso de uso caso. La
función fundamental de un diagrama de secuencia es asignar comportamiento a
sus clases.
b) Actualice el modelo de dominio.- al dibujar los diagramas de secuencia, añadir
operaciones a los objetos entidad. el modelo de dominio debe convertirse en un
modelo estático, o diagrama de clases.
c) Depurar el modelo estático.- quitar inconsistencias diagrama de clases.
Etapa 3: Revisión crítico del diseño.
IMPLEMENTACIÓN
d) Código y pruebas unitarias.- Escribir el código fuente y formular las pruebas
unitarias o, escriba las pruebas unitarias y luego el código.
e) Integración y pruebas de escenario.- Base las pruebas de integración en los
casos de uso, para aprobar los cursos básico y alterno.
f) Revisar código y actualizar el modelo.- Luego prepararse para la siguiente
iteración del proceso ICONIX, con otro pequeño grupo de casos de uso.
A. MODELO DE DOMINIO
Según Rosenberg y Stephens (2007), “El Modelo de Dominio es un artefacto
colaborativo vivo. Es refinado y actualizado en cada parte el proyecto, de modo que
refleja siempre la comprensión actual del espacio del problema”.
Según Porras (2011), “El modelo de dominio en la práctica es un diagrama de clases

(objetos de dominio) para mostrar cómo se relacionan entre sí. El modelo de dominio
15
muestra las relaciones de generalización (es un,) agregación (tiene un) y asociación entre
las clases de dominio”.
Figura N° 2.3: Modelo de dominio (Rosenberg y Stephens, 2007).
B. MODELO DE CASOS DE USO

Para Porras (2011), los modelos de casos de uso son desarrollados en cooperación
con el modelo de dominio; los casos de uso sirven de para pruebas de funcionalidades
durante la fase de implementación; un caso de uso es una secuencia de acciones que un
actor realiza en el sistema para alcanzar un objetivo.
Un casos de uso es una secuencia de acciones que un actor realiza en el sistema para
alcanzar un objetivo (Rosenberg, et al., 2005).
Para Porras (2011), “Los casos d uso con ICONIX sirven para diseñar, estimar el tiempo
y esfuerzo de desarrollo. Otra visión de casos de uso, es un resumen técnico para
especificar los requerimientos, ICONIX enseña a escribir casos de uso como el primer
paso para obtener buen diseño orientado a objetos y como medio para obtener código de
alta calidad”.
16
Figura 2.4: Modelo de Casos de Uso (Rosenberg y Stephens, 2007).
C. REVISIÓN DE REQUISITOS
Según Rosenberg y Stephens (2007), La sesión de revisión de requisitos garantiza
que el sistema tal y como se describe coincide con los requisitos. Se trata de un período
de sesiones de colaboración que impliquen al representante(s) del cliente, los usuarios
finales (es decir, las personas que realmente van a utilizar el sistema, o quien está usando
el sistema actual que se sustituirá), y las personas de marketing-básicamente, todos los
stakeholders que tienen un interés en asegurar que los requisitos encajen con su punto de
vista del sistema.
Para Porras (2011), La revisión de requisitos debe incluir al cliente, el analista de

negocios, un miembro del equipo de desarrollo, un usuario final y un administrador
implicado en el proyecto.
17
Figura 2.5: Revisión de Requisitos (Rosenberg y Stephens, 2007).
D. ANÁLISIS DE ROBUSTEZ
Según Rosenberg y Stephens (2007), Para obtener a partir de los casos de uso un
diseño detallado (y luego el código), lo que se necesita es enlazar los casos de uso a los
objetos. La técnica que se describe en este capítulo, el análisis de robustez, le ayuda a
superar la brecha que existe del análisis al diseño. En pocas palabras, es una manera de
analizar sus casos de uso e identificar un primer conjunto de objetos para cada caso de
uso. Estos se clasifican en objetos interfaz, objetos entidad, y controladores (que son a
menudo más como funciones que como objetos)
Según Porras (2011), El análisis de robustez es una “imagen” de un caso de uso, el

diagrama de robustez y la descripción del caso de uso deben coincidir con precisión. La
descripción del caso de uso en el formato nombre-verbo-nombre, permite construir el
diagrama de robustez y el diseño detallado fácilmente, el análisis de robustez ayuda a
desambiguar el caso de uso.
18
Figura 2.6: Análisis de Robustez (Rosenberg y Stephens, 2007).
E. REVISIÓN DE DISEÑO PRELIMINAR

Según Rosenberg y Stephens (2007), Las sesiones de Revisión del Diseño
Preliminar (RDP) ayudan a asegurarse que los diagramas de robustez, el modelo de
dominio, y la descripción de casos de uso coincidan entre sí. Esta revisión es el "puente"
entre el diseño preliminar y en las etapas del diseño detallado, para cada paquete de casos
de uso.
La revisión del diseño preliminar debe incluir al cliente, el analista de negocios, un

miembro del equipo de desarrollo, un usuario final y un administrador implicado en el
proyecto. (Porras, 2011).
19
Figura 2.7: Revisión de Diseño Preliminar (Rosenberg y Stephens, 2007).
F. DIAGRAMA DE SECUENCIA
Una vez que se ha finalizado el análisis de robustez, y ha celebrado una Revisión
del Diseño Preliminar, es tiempo de iniciar el diseño detallado. En este momento, la
descripción de sus casos de uso debe ser completa, correcta, detallada y explícita. En
resumen, los casos su uso deben estar en un estado del que se pueda crear un diseño
detallado.
Según Rosenberg y Stephens (2007), Todos los pasos del proceso hasta este momento
han estado preparando a los casos de uso para la actividad del diseño detallado. Después
de haber completado el análisis de robustez y la RDP, debería tener descubiertas casi
todas las clases de dominio que va a necesitar. También es necesario tener la arquitectura
técnica (AT) en la presente etapa.
Según Porras (2011), El comportamiento de un caso de uso se detalla mediante el

diagrama de secuencia, éste muestra la colaboración dinámica entre objetos del sistema,
también observamos la secuencia de mensajes enviados entre los objetos. El diagrama de
secuencia, permite asignar operaciones a los objetos interfaz y entidad, porque los
controladores (verbos) del diagrama de robustez, se convierten en mensajes (operaciones)
entre los objetos interfaz y entidad (nombres). En conclusión, actualizamos el modelo
20
estático con las operaciones y los atributos identificados en las fases anteriores.
Figura 2.8: Diagramas de Secuencia (Rosenberg y Stephens, 2007).
G. REVISIÓN CRÍTICA DE DISEÑO

Según Rosenberg y Stephens (2007), Luego de utilizado el análisis de robustez
para desambiguar la descripción de los casos de uso y descubrir las clases de dominio
faltantes, mantenido una revisión de diseño preliminar (PDR) para asegurarte que los
casos de uso coinciden con lo que el cliente realmente quiere, y elaborado
cuidadosamente un diseño detallado de los casos de uso que se implementó hasta esta
versión se está casi listo para comenzar la codificación, hay una sola etapa rápida pero de
vital importancia es la revisión del diseño crítico.
Según Porras (2011), La revisión crítica de diseño es un paso entre el diseño y la

implementación, usamos tres criterios: hacer coincidir la descripción de los casos de uso
con los diagramas de secuencia, verificar la continuidad de los mensajes y revisar par un
buen diseño. Si se diseña cada caso de uso aplicando los tres criterios, entonces el diseño
está listo para la codificación.
21
Figura N° 2.9: Revisión del diseño critico (Rosenberg y Sthephens, 2007).
H. IMPLEMENTACIÓN
Según Porras (2011), Usando los diagramas de secuencia y el diagrama de clases
realizamos la implementación. Para este fin, mostramos un método sistemático para
convertir el diseño de código fuente, en la práctica también debemos escribir las pruebas
unitarias para los controladores. Si el diseño presenta errores una vez que ha comenzado
a codificar, corregirlo.
Según Rosenberg y Stephens (2007), Si usted ha pasado por todo el esfuerzo para crear
un diseño agradable y detallado, vale la pena tener una buena idea de cómo traducir ese
diseño detallado en el código fuente (y las pruebas unitarias, por supuesto).
22
Figura N° 2.10: Implementacion (Rosenberg y Sthephens, 2007).
2.9. SISTEMA GESTOR DE BASE DE DATOS RELACIÓN

Según Osorio (2008), un SGBD relacional permite almacenar y manejar datos
mediante tablas y relaciones entre tablas donde el contenido de cada registro de la base
de datos contiene información relacionada con un tema permitiendo que los datos de dos
clases de información puedan ser manipulados como una única entidad basada en los
valores de los datos relacionados. Por ejemplo, sería una redundancia almacenar la
información sobre el nombre y el país de un autor con todos los libros de su autoría.
Jiménez (2014) afirma que una base de datos relacional es aquella que representa los
datos y las relaciones entre los datos mediante una colección de tablas, las bases de datos
relacionales poseen ventajas sobre otros tipos de bases de datos en aspectos como la
independencia física, independencia lógica, flexibilidad, uniformidad, sencillez.
Según Nevado (2010), “Las bases de datos relacionales poseen ventajas como la
independencia de datos y los programas; menor redundancia de datos, integridad de los
datos, coherencia de los resultados, mayor seguridad en los datos, datos más
documentados, acceso a datos más eficiente, reducción del espacio de almacenamiento,
acceso simultaneo a los datos; pero tiene desventajas como instalación costosa, requiere
personal calificado, implantación larga y difícil, ausencia de estándares reales, falta de
23
rentabilidad a corto plazo”.
2.10. LENGUAJE DE PROGRAMACIÓN ORIENTADO A OBJETOS

Para Martinez (2002), la programación orientada a objetos se puede definir como
una filosofía para programar encapsulando datos y código para formar objetos, que
interactúan para obtener los resultados esperados.
Según Álvarez (2008), “La programación orientada a objetos es una forma especial de
programar, más cercana como expresaríamos la cosas en la vida real que otros tipos de
programación”.
Según Flores (2005), “La programación orientada a objetos es realmente un nuevo estilo
de programación, el cual, básicamente consiste en definir clases y poner dichas clases a
comunicarse o conversar entre sí”.
Groussard (2012) señala que “la programación orientada a objetos se basa en los
conceptos de: encapsulamiento, herencia y el polimorfismo”.
A. ENCAPSULAMIENTO
Según Groussard (2012), “La encapsulación es la capacidad de crear y controlar
el acceso a un grupo de elementos. Las clases facilitan el medio más fiable para asegurar
la encapsulación. La encapsulación asegura también un control sobre la utilización de
datos y procedimientos o funciones mediante la utilización de modificadores de acceso”.
Según Garrido (2006), “El encapsulamiento nos permite combinar los datos y las
operaciones en un mismo objeto, de forma que éste ofrece una interfaz de comunicación
para relacionarse con otros objetos, haciendo inaccesibles todos los detalles internos de
su funcionamiento”.
B. HERENCIA
Según Groussard (2012), “La herencia permite la creación de una nueva clase,
basada en una clase existente. La clase que sirve de plantilla para la creación de otra clase
de llama clase base. La clase así creada hereda de los campos, propiedades, métodos y
24
eventos. Las clases creadas a partir de una clase se llaman clases derivadas, así se puede
definir una clase base y reutilizarla varias veces para crear clases derivadas”.
Según Garrido (2006), “La herencia es un mecanismo que permite indicar que una clase
de objetos hereda las propiedades de otra. Por ejemplo, podemos tener un sistema de
gestión en el que hay que procesar los datos de los empleados. Para ello, podemos crear
la clase de objetos. En ésta, se resuelven los problemas comunes a cualquier empleado”.
C. POLIMORFISMO
Según Groussard (2012), “El polimorfismo permite utilizar varias clases de
manera intercambiable incluso si estas clases implementan sus propiedades y métodos de
manera diferente. Estas propiedades y métodos se pueden usar con el mismo nombre, sin
importar la clase a partir de la cual se ha construido el objeto”.
Para Garrido (2006), “El polimorfismo permite que un objeto determine, en tiempo de
ejecución, la operación realizar de acuerdo a determinados parámetros”.
Aguilar (1998), “La programación orientada a objetos toma los mejores ideas de la
programación estructurada que combina con nuevos y poderosos conceptos que animan
o alientan una nueva visión de la tarea de la programación. La programación orientada a
objetos permite descomponer fácilmente un problema en subgrupos de partes
relacionadas. Entonces, puede traducir estos subgrupos en unidades auto contenidos
llamados objetos”.
D. OBJETOS
Según Rueda (2005), “Un objeto es una encapsulación abstracta de información,
junto con los métodos o procedimientos para manipularla. Un objeto contiene operaciones
que definen su comportamiento y variables que definen su estado entre las llamadas a las
operaciones”.
E. CLASE
Según Winblad, Edwardsy King (2003), “Un diagrama de clase es un modelo del
problema, que captura todos los requerimientos de los requerimientos de usuario. Este
conocimiento de los requerimientos está contenido en las clases, atributos, métodos y
25
asociaciones entre las clases. Las clases representan entidades físicas y conceptuales del
negocio”.
Según Rueda (2005), “Una clase no está limitada a comportarse solo como lo define su
padre, sino que, además, puede definir un comportamiento propio, es decir que se pueden
agregar nuevos métodos en ella”.
2.11. TECNOLOGÍAS DE INTERNET

Según Belloch (2012), afirma que podríamos definir Internet como la red de redes,
también denomina red global o red mundial. Es básicamente un sistema mundial de
comunicaciones que permite acceder a información disponible en cualquier servidor
mundial, así como interconectar y comunicar a ciudadanos alejados temporal o
físicamente.
Según Stair y Reynolds (2014), “La Internet es la red de computación más grande del
mundo. En realidad es un grupo de redes conectadas entre sí que intercambian libremente
información, la Internet transmite datos de una computadora a otra”.
A. PROTOCOLO HTTP
Según Forouzan (2002), “el protocolo de transferencia de hipertexto (http,
hypertext transfer protocol) es un protocolo utilizado principalmente para acceder a datos
de la World Wide Web (WWW). El protocolo transfiere datos en la forma de texto plano,
hipertexto, sonido, video, etc. Sin embargo, se denomina protocolo de transferencia de
hipertexto debido a que su eficiencia permite su uso en un entorno basado en hipertexto
en el que hay rápidos saltos de un documento a otro.”
Según Salavert (2003), “El protocolo HTTP es un protocolo que funciona a nivel de
aplicación según el modelo de referencia OSI, este protocolo se basa en el modelo
cliente/servidor, es decir, consiste en un intercambio de mensaje entre dos dispositivos;
a) El cliente, que es el que solicita servicios a un servidor. Su aplicación es lo que se
conoce en Internet como navegadores, b) El servidor, que es el dispositivo que responde
a las solicitudes de los clientes. Usualmente se les conoce como servidor Web, aunque en
realidad son servidores de protocolo HTTP”.
26
B. PROTOCOLO TCP/IP
Según Forouzan (2002). “El protocolo TCP/IP (Protocolo de control de
transmisión/ protocolo entre redes) es un protocolo jerárquico compuestos por módulos
interactivos, cada uno de los cuales proporciona una funcionalidad específica, pero que
no son necesariamente interdependientes y que definen como se intercambian todas las
trasmisiones a través de internet”.
Para Tanenbaum (2003), “el TCP (Protocolo de Control de Transmisión) se ha diseñado

para enviarse un flujo de datos confiable de extremo a extremo a través de una interred
no confiable. Una interred difiere de una sola red debido a que diversas partes podrían
tener diferentes topologías, anchos de banda, retardos, tamaños de paquete y otros
parámetros. TCP tiene un diseño que se adapta de manera dinámica a las propiedades de
la interred y que se sobrepone a muchos tipos de fallas”.
C. APLICION WEB
Caivano (2009) señala que las aplicaciones web son aquellas aplicaciones que los
usuarios pueden utilizar accediendo a un servidor web a través de internet o de una
intranet mediante un navegador. En otras palabras, es una aplicación software que se
codifica en un lenguaje soportado por los navegadores web en la que se confía la
ejecución al navegador.
D. PATRÓN MVC
Según Teniente, Ramon, Mayol y Gómez (2003) señalan que el patrón Modelo-
Vista-Controlador es un patrón arquitectónico que consiste en descomponer sistema en
tres componentes, modelo (proceso) que incluye la implementación de las
funcionalidades y los datos del sistema, vista (salida) que muestra la información al
usuario final y el controlador (entrada) que es el responsable de gestionar la interacción
con el usuario.
27
CAPITULO III
RESULTADOS
3.1. DESARROLLO DEL PROYECTO

3.1.1. MODELADO CONCEPTUAL
Es el primer modelo de dominio del caso de gestión de información del proceso
de servicio técnico.
Figura N° 3.1: Flujo de servicio técnico
3.1.2. ANÁLISIS DE REQUERIMIENTOS

E. REQUISITOS FUNCIONALES
Nº
REQUISITOS FUNCIONALES PRIORIDAD
REQ.
01 El Administrador debe ser capaz de crear una cuenta de
ALTA
usuario para el acceso al sistema.
02 El Administrador debe ser capaz de registrar los datos del ALTA
personal de la empresa por área
03 El sistema debe permitir a administrar al personal de la
MEDIA
28
empresa, como mantener, modificar datos y usuarios.
04 El sistema debe permitir autenticar el ingreso de los usuarios
ALTA
autorizados.
05 El usuario de “Recepción” debe ser capaz de registrar los
ALTA
datos de los clientes naturales y jurídicas
06 El usuario de “Recepción” debe ser capaz de registrar las
ATLA
observaciones, accesorios y el defecto de los equipos que
ingresan a la recepción.
07 El sistema debe generar el número de orden de trabajo del
ALTA
equipo (OT), al registrar los equipos que ingresan a la
recepción.
08 El sistema debe generar reporte del Orden de Trabajo (OT),
ALTA
luego para ingresar al almacén del área de servicio técnico
con su Orden.
09 El sistema debe mostrar al usuario de “Recepción” una lista
ALTA
de equipos ingresados.
10 El sistema debe mostrar al usuario “Técnico” una lista de
MEDIA
todos los equipos ingresados por el área de recepción.
11 El usuario “Técnico” debe ser capaz de buscar el equipo
ALTA
ingresado, por el número de Orden de Trabajo(OT)
12 El sistema debe mostrar al usuario “Técnico” al detalle el
ALTA
defecto, las observaciones y accesorios del equipo con que
ha ingresado al área de recepción (que defecto tenia, con que
accesorios).
13 El usuario “Técnico” debe ser capaz de registrar su informe
ALTA
técnico del equipo revisado.
14 El usuario “Técnico” debe ser capaz de actualizar el estado
MEDIA
del equipo ingresado por el área de recepción.
ALTA
de todos los equipos reparados y/o revisados listos por
entregar al cliente.
16 El usuario de “Recepción” debe ser capaz de buscar el
ALTA
equipo reparado por el número de Orden de Trabajo.
29
17 El sistema debe generar un reporte del informe técnico del
ALTA
equipo por entregar al cliente.
18 El usuario de “Recepción” debe ser capaz de actualizar el
MEDIA
estado de la lista de equipos por entregar, al entregar el
equipo reparado al cliente.
ALTA
de todos los equipos entregados por día.
20 El sistema debe generar un reporte de la lista de equipos
ALTA
entregados por día y mes.
21 El sistema debe mostrar al usuario una lista de equipos
MEDIA
ingresados por día.
22 El sistema debe mostrar al usuario el estado de reparación
MEDIA
y/o revisión de equipos ingresados.
23 El sistema de debe mostrar al usuario una lista de equipos
MEDIA
reparados por entregar al cliente.
24 El sistema debe mostrar al usuario de “Administración”
MEDIA
una lista de todos los equipos entregados por el área de
recepción al cliente por día y mes.
25 El usuario “Técnico” debe ser capaz de actualizar el estado
MEDIA
del equipo revisado.
Tabla N° 3.1: Requisitos funcionales
F. REQUISITOS NO FUNCIONALES
Nº
REQUISITOS NO FUNCIONALES PRIORIDAD
REQ.
1 El sistema debe presentar interfaces fáciles de usar ALTA
2 El sistema debe ser capaz de ejecutarse en cualquier sistema
ALTA
operativo
3 El sistema debe ser amigable y ser multiplataforma para las
ALTA
diferentes versiones de navegadores (Explorer, Mozilla,
Chrome).
Tabla N° 3.2: Requisitos funcionales
30
G. CASOS DE PRUEBA DE ACEPTACIÓN
Nº Req. Nº C.P Casos de Prueba de Aceptación

01 Verificar que los datos de los clientes (naturales o jurídicas) estén
correctos.
02 Comprobar que las características y los accesorios de los equipos
05 ingresados son correctas
06 03 Verificar que el orden del trabajo (OT) del equipo se haya
07 generado correctamente.
08 04 Comprobar que el equipo ingresado pertenece a un cliente
09 correspondiente correctamente.
05 Imprimir el reporte del equipo ingresado para verificar las
características, el estado, el OT, con que componentes a
ingresado sean correctos.
06 Comprobar que los equipos registrados se muestren en la lista de
equipos ingresados
Tabla N° 3.3: Caso de prueba de aceptación. Generar Orden de Trabajo

06 01 Verificar que el orden del trabajo (OT) del equipo se haya
08 generado correctamente.
10 02 Imprimir el reporte del equipo ingresado, para verificar las
12 características, el estado, el OT, y los accesorios ingresados estén
correctos.
03 Verificar que los equipos registrados se muestren en la lista de
equipos ingresados
04 Comprobar que el defecto, observaciones y accesorios del
equipo registrado en el área de recepción sean correctas.
Tabla 3.4: Caso de prueba de aceptación. Ingresar equipos al almacén de servicio técnico

02 01 Comprobar que los datos del personal del área de servicio técnico
31
07 sean correctas.
08 02 Verificar que el orden del trabajo (OT) del equipo registrado se
10 haya generado correctamente.
11 03 Comprobar que el reporte impreso del equipo ingresado sea al
12 detalle para verificar las características, el estado, el OT, con que
13 accesorios a ingresado al almacén de servicio técnico.
14 04 Comprobar que los equipos registrados por Recepción se
muestren en la lista de equipos ingresados al almacén de servicio
técnico.
05 Comprobar que la búsqueda de equipos por OT sea correctas.
06 Comprobar que el defecto, observaciones y accesorios
registrados en el área de recepción sean correctas.
07 Comprobar que los campos requeridos del módulo informe
técnico se hayan completado.
Tabla N° 3.5: Caso de prueba de aceptación. Realizar informe técnico

13 01 Verificar que el informe técnico del equipo revisado se haya
15 registrado correctamente.
16 02 Comprobar que los equipos reparados y/o revidados se muestren
17 en la lista de productos por entregar al cliente.
03 Comprobar que la búsqueda de equipos por el número de Orden
de Trabajo sea correctas.
04 Comprobar que el reporte generado del informe técnico del
producto reparado y/o revisado sea correctas.
Tabla N° 3.6: Caso de prueba de aceptación. Generar reporte del informe técnico

11 01 Comprobar que el informe técnico del equipo se haya registrado
12 correctamente.
13 02 Verificar que los equipos reparados se muestren en la lista de
14 equipos por entregar de manera correcta.
32
15 03 Comprobar que la búsqueda de equipos por el número de Orden
18 de Trabajo sea correctas.
22 04 Verificar que la actualización del estado de proceso de
23 reparación del equipo esté correctas.
05 Comprobar que el defecto, observaciones y accesorios
registrados en el área de recepción estén conformes.
06 Comprobar que el reporte del informe técnico generado del
equipo reparado esté conforme.
07 Comprobar que el estado del equipo se haya actualizado
correctamente.
Tabla N° 3.7:Caso de prueba de aceptación. Administrar estado de equipos por entregar
GLOSARIO DE TÉRMINOS
Persona
Cliente
Recepcionista
Administrador
Administrativo
Técnico
Usuario
Cuenta de Usuario
Producto
Alancen de servicio técnico
Informe técnico
Estado de reparación
Revisado
En espera de Repuesto
En Proceso de Reparación
Control de Calidad
Reparado
No Reparado
H. MODELO DE DOMINIO
33
Figura N° 3.2: Modelo de dominio. Software de gestión de información
3.1.3. MODELO DE CASO DE USO

A. PROTOTIPO DE INTERFAZ GRAFICA
Figura N° 3.3: Prototipo de interfaz básica, caso de uso, autenticar usuario
34
Figura N° 3.4: Prototipo de interfaz básica, caso de uso, administrar personal
Figura N° 3.5: Prototipo de interfaz básica, caso de uso, registrar cliente
35
Figura N° 3.6: Prototipo de interfaz básica, caso de uso, generar orden trabajo
Figura N° 3.7: Prototipo de interfaz básica, caso de uso, generar informe técnico
36
B. LISTA DE CASOS DE USO
N° C.U. CASOS DE USOS

01 Autenticar Usuario
02 Administrar Personal
03 Registrar Cliente
04 Generar Orden de Trabajo
05 Realizar Informe Técnico
06 Administrar estado del equipo por entregar
07 Mostar equipos ingresados
08 Mostrar equipos reparados
09 Generar reporte del informe técnico
10 Mostrar Equipos entregados al cliente
11 Generar reporte de equipos entregados
12 Administrar estado de revisión del equipo
Tabla N° 3.8: Lista de Casos de Uso
C. CASOS DE USO ORGANIZADO POR PAQUETES
Figura N° 3.9: Casos de Uso Organizado por paquetes
37
D. DIAGRAMA DE CASOS DE USO POR PAQUETE
uc Administracion
Sistema de Gestion de Informacion
CU-01: Autenticar Usuario
CU-02: Administrar Personal
Administrador
(from Actors)
Figura N° 3.10: Casos de uso del paquete “Administración”
uc Recepcion
CU-03: Registrar Cliente
CU-04: Generar Orden de

Trabaj o
CU-06: Administrar estado del

equipo por entregar
Recepcionista
Figura N° 3.11: Casos de uso del paquete “Recepción”
38
uc Serv icio Tecnico
CU-05: Realizar Informe

Técnico
CU-12: Administrar estado de

rev isión del equipo
Tecnico
(from Actors)
Figura N° 3.12: Casos de uso del paquete “Servicio Técnico”
uc Equipo
Sistema de gestion de Informacion
CU-07: Mostar equipos

ingresados
CU-08: Mostrar equipos

reparados
Adnimistrativ o
(from Actors)

entregados al cliente
Figura N° 3.13: Casos de uso del paquete “Equipo”
39
uc Reporte
CU-09: Generar reporte del

informe técnico
CU-11: Generar reporte de

equipos entregados
Recepcionista
(from Actors)
Figura N° 3.14: Casos de uso del paquete “Reporte”
E. RELACIÓN ENTRE REQUISITOS FUNCIONALES Y CASOS DE USO
REQUISITOS FUNCIONALES CASOS DE USO

Req 04. El sistema debe permitir autenticar el
ingreso de los usuarios autorizados. CU-01: Autenticar usuario
Req 01. El Administrador debe ser capaz de crear
una cuenta de usuario para el acceso al
sistema.
Req 02. El Administrador debe ser capaz de registrar
los datos del personal de la empresa por CU-02: Administrar personal
área.
Req 03. El sistema debe permitir a administrar al
personal de la empresa como mantener,
modificar datos y usuarios.
Req 05. El usuario de “Recepción” debe ser capaz
de registrar los datos de los clientes CU-03: Registrar cliente
40
naturales y jurídicas
de registrar las observaciones, accesorios
y el defecto de los equipos que ingresan a
la recepción. CU-04: Generar Orden de
Req 07. El sistema debe generar el número de orden Trabajo
de trabajo del equipo (OT), al registrar los
equipos que ingresan a la recepción.
Req 09. El sistema debe mostrar al usuario de
“Recepción” una lista de equipos
ingresados.
Req 08. El sistema debe generar reporte del Orden
de Trabajo (OT), luego para ingresar al
almacén del área de servicio técnico con
su orden.
Req 10. El sistema debe mostrar al usuario
“Técnico” una lista de todos los productos
ingresados por el área de recepción.
Req 11. El usuario “Técnico” debe ser capaz de
buscar el equipo ingresado por el número
de Orden de Trabajo (OT).
Req 12. El sistema debe mostrar al usuario CU-05: Realizar informe
“Técnico” al detalle el defecto, las técnico
observaciones y accesorios del equipo con
que ha ingresado al área de recepción (que
defecto tenia y con qué accesorios).
registrar su informe técnico del equipo
revisado.
actualizar el estado del equipo reparado.
“Recepción” una lista de todos los
41
productos reparados y/o revisados listos
por entregar al cliente. CU-06: Administrar estado del
Req 16. El usuario de “Recepción” debe ser capaz equipo por entregar.
de buscar el equipo reparado por el
número de Orden de Trabajo.
de actualizar el estado del equipo por
entregar, al entregar el equipo reparado
y/o revisado al cliente, a un estado
“Entregado”.
Req 21. El sistema debe mostrar al usuario una lista CU-07: Mostrar equipos
de productos ingresados por día. ingresados
Req 22. El sistema debe mostrar al usuario el estado

de reparación y/o revisión de productos
ingresados.
Req 23. El sistema de debe mostrar al usuario una CU-08: Mostrar equipos
lista de equipos reparados por entregar al reparados.
cliente.
Req 17. El sistema debe generar un reporte del CU-09: Generar reporte del
informe técnico del equipo por entregar al informe técnico
cliente.
“Recepción” una lista de todos los
equipos entregados por día.
Req 24. El sistema debe mostrar al usuario de CU-10: Mostrar equipos
“Administración” una lista de todos los entregados al cliente
equipos entregados por el área de
recepción al cliente por día y mes.
Req 20. El sistema debe generar un reporte de la CU-11: Generar reporte de
lista de equipos entregados por día y mes. equipos entregados
Req 25. El usuario “Técnico” debe ser capaz de CU-12: Administrar estado de
actualizar el estado del equipo reparado revisión del equipo.
42
y/o revisado.
Tabla N° 3.9: Relación entre requisitos funcionales y casos de uso
F. PRIMER BORRADOR DE CASOS DE USO
Casos de uso Descripción

Curso Básico
1. El usuario accede al sistema.
2. El sistema muestra un formulario del login al
usuario.
3. El usuario ingresa su usuario y contraseña y hace
clic en la opción “Ingresar”.
4. El sistema evalúa los datos ingresados por el
usuario, con lo cual se ejecuta el curso alterno.
5. El sistema muestra al usuario el menú con las
opciones propias del perfil del usuario.
CU-01: Autenticar Usuario Curso Alterno
1. Si el usuario no ingresa ningún dato a las cajas de
texto, el sistema muestra un mensaje de advertencia
“Error en la operación.”.
2. El sistema verifica si los datos ingresados del
usuario son correctas.
3. El sistema muestra al usuario un mensaje de error
“Error en la operación.”.
4. El usuario ingresa su usuario y contraseña
nuevamente.
5. El sistema autentica al usuario.
Tabla N° 3.10: Primer borrador del caso de uso “Autenticar Usuario”

Curso Básico
opciones propias del perfil del Administrador.
2. El usuario selecciona la opción “administrar
personal”.
3. El sistema muestra una caja de texto de búsqueda
del colaborador por nombre y apellido, la lista de
todos los colaboradores de la empresa y el
formulario de ingreso de datos con las cajas de texto
bloqueado.
4. El usuario ingresa el nombre del colaborador para
buscar.
43
5. El sistema encuentra y muestra al colaborador
indicado.
CU-02: Administrar
6. El usuario selecciona al colaborador sobre el cual
personal se realizara una de las opciones “Modificar” o
“Eliminar”, con lo cual se ejecuta el curso alterno
(CA-1) y (CA-2).
7. El usuario desea ingresar a un nuevo usuario,
entonces hace clic en la opción “Nuevo” y se
habilita todas las cajas de texto para ingresar los
datos del nuevo colaborador, luego del cual hace
clic en la opción “Guardar”, con lo cual se ejecutara
el curso alterno (CA-3).
8. El sistema guarda la información en la base de datos
y muestra un mensaje de confirmación, en caso
contario un mensaje de error.
9. El usuario hace clic en Aceptar.
Curso Alterno
CA-1:
1. El usuario hace clic en la opción “Modificar”.
2. El sistema carga los datos del colaborador en las
cajas de texto correspondiente sobre el cual se
realizara cualquier modificación.
3. El usuario modifica los datos convenientes y hace
clic en la opción “Actualizar”.
4. El sistema guarda la información modificada en la
base de datos y muestra un mensaje de
confirmación, en caso contrario muestra un
mensaje de error.
CA-2:
1. El usuario hace clic en la opción “Eliminar”.
2. El sistema cambia de estado activo (1) a inactivo (0)
contario muestra un mensaje de error.
CA-3:
1. El usuario procede a ingresar los datos del nuevo
colaborador.
2. El usuario hace clic en la opción “Guardar”
3. El sistema valida que la información ingresada en
las cajas de texto sean consistentes.
4. El sistema muestra un mensaje de advertencia en
caso de que si una de las cajas obligatorias está
vacía o falta ingresar.
Tabla N° 3.11: Primer borrador del caso de uso “Administrar Personal”
44
CURSO BÁSICO
opciones propias del perfil del usuario Recepcionista.
2. El usuario selecciona la opción “Registrar Cliente”.
3. El sistema muestra una caja de texto de búsqueda del
cliente por nombre, la lista de todos los clientes
registrados de la empresa y el formulario de ingreso
de datos del cliente con las cajas de texto bloqueado.
4. El usuario hace clic en la opción “Nuevo”.
5. El sistema desbloquea las cajas de texto.
6. El usuario ingresa los datos necesarios del cliente,
luego del cual hace clic en la opción “Guardar”, con
lo cual se ejecuta el Curso Alterno (CA-1).
CU-03: Registrar Cliente 7. El sistema guarda la información en la base de datos
contrario muestra un mensaje de error.
CURSO ALTERNO
CA-1:
1. El usuario procede a ingresar los datos del cliente.
2. El sistema valida que la información ingresada en las
cajas de texto sean consistentes, si está vacía o son
números en las cajas de texto correspondiente
muestra un mensaje de advertencia en caso contrario
un mensaje de error.
3. El usuario verifica que la información ingresada en
las cajas sean correctas y hace clic en la opción
“Guardar”.
Tabla N° 3.12: Primer borrador del caso de uso “Registrar Cliente”

CURSO BÁSICO
2. El usuario selecciona la opción “Generar OT”.
equipo por el número de OT, la opción “Generar
Reporte”, la lista de equipos ingresados pendientes
por reparar con las opciones de “Modificar” y
45
“Eliminar” y el formulario del equipo con las cajas
de texto bloqueado.
6. El usuario ingresa todas las observaciones
CU-04: Generar orden de
necesarios, los accesorios, con que defecto y el
trabajo estado de ingreso del equipo por cliente luego del
cual hace clic en la opción “Guardar”, con lo cual se
ejecuta el Curso Alterno (CA-1).
7. El sistema genera el orden de trabajo (OT) del
producto, de acuerdo al orden del registro del equipo.
10. El sistema muestra el equipo en la lista de equipos
ingresados pendientes por reparar el equipo
registrado con sus observaciones y accesorios.
11. El usuario ingresa el número del OT del equipo para
buscar y modificar cuando sea necesario.
12. El sistema busca y muestra el equipo buscado por el
número del orden de trabajo.
13. El usuario selecciona el equipo sobre el cual realizara
alguna modificación alguna del equipo, realizando
clic sobre la opción “Modificar” del registro
correspondiente.
14. El sistema muestra toda la información del equipo
antes seleccionada en las cajas de texto
correspondiente.
15. El usuario recepcionista modifica algunas
informaciones necesarias, luego del cual hace clic en
la opción “Modificar” con lo cual se ejecuta el Curso
Alterno (CA-2).
16. El sistema actualiza la información en la base de
datos y muestra un mensaje de confirmación, en caso
contrario un mensaje de error.
17. El usuario hace clic en “Aceptar”.
buscar y generar reporte del orden de trabajo del
equipo.
20. El usuario procede generar reporte haciendo clic en
la opción “Generar Reporte” con lo cual se ejecutara
el Curso Alterno (CA-3).
CURSO ALTERNO
CA-1:
46
1. El usuario procede ingresar las observaciones
necesarias, accesorios, defecto y el estado de ingreso
del equipo.
cajas de texto sean consistentes, en caso si está vacía,
o son números en cada caja de texto correspondiente
muestra un mensaje de advertencia, en caso contrario
“Guardar”.
CA-2:
1. El usuario recepcionista procede modificar la
información necesaria del equipo.
2. El sistema valida que la información modificada en
las cajas de texto sean consistentes, en caso de que la
información modificada no es consistente muestra un
mensaje de advertencia en caso contrario un mensaje
de error.
3. El usuario verifica que la información modifica en las
cajas sean correctas y hace clic en la opción
“Actualizar”.
CA-3:
1. El sistema mostrara las opciones de impresión.
2. El usuario selecciona las opciones de impresión
solicitadas y hace clic en el botón “Imprimir”.
3. El sistema procede a la impresión del documento
mostrado.
Tabla N° 3.13: Primer borrador del caso de uso “Generar orden de trabajo”

CURSO BÁSICO
opciones propias del perfil del Técnico.
2. El usuario selecciona la opción “Generar Informe
técnico”.
3. El sistema muestra el formulario de informe técnico
al usuario con una caja de texto de búsqueda del
equipo por el número de orden de trabajo (OT)
desbloqueada y la opción “Buscar”, y una tabla de
lista de equipos ingresados por el “área de recepción”
con la opción “Generar” y las demás cajas de texto
bloqueado.
47
4. El usuario ingresa el número de OT del equipo en la
caja de texto de búsqueda, para buscar el equipo
revisado sobre el cual a ingresar su informe técnico.
5. El sistema busca al equipo por el número de OT
ingresado y muestra el equipo indicado con sus
observaciones, accesorios y defecto.
CU-05: realizar Informe 6. El usuario hace clic en la opción “Generar”.
7. El sistema muestra en las cajas de texto
Técnico
correspondiente toda la información registrada del
equipo ingresado por el área de recepción y
desbloquea las cajas de texto de ingresar el informe
técnico.
8. El usuario ingresa la información del proceso de
revisión y/o reparación del equipo y actualiza el
estado de OT del equipo revisado, luego del cual hace
clic en la opción “Actualizar”, con lo cual se ejecuta
11. El sistema muestra al usuario de “Recepción” la
información actualizada en la tabla de lista de
productos revisados y/o reparados.
CURSO ALTERNO
CA-1:
1. El usuario procede a ingresar la información del
proceso de revisión y/o reparación del equipo.
cajas de texto sean consistentes, si el campo es
obligatorio o son números en las cajas de texto
correspondiente muestra un mensaje de advertencia,
en caso contrario muestra un mensaje de error.
“Actualizar”.
Tabla N° 3.14: Primer borrador del caso de uso “Realizar Informe técnico”

CURSO BÁSICO
48
2. El usuario selecciona la opción “Equipos por
entregar”.
3. El sistema muestra el formulario de equipos por
entregar al usuario con una caja de texto de búsqueda
del equipo por el número de orden de trabajo (OT)
desbloqueada y la opción “Generar Reporte”, y una
tabla de lista de equipos reparados y aceptados por
entregar con la opción “Entregar” y las demás cajas
de texto bloqueado.
reparado y aceptado por entregar, sobre el cual a
actualizar el estado de OT.
ingresado y muestra el equipo indicado con su
CU-06: Administrar estado informe técnico.
6. El usuario hace clic en la opción “Entregar”.
del equipo por entregar
equipo reparado en el área de servicio técnico y
desbloquea las cajas de texto de actualizar el estado
de OT.
8. El usuario verídica la información del equipo y
procede actualizar el estado de OT del equipo
reparado y aceptado por entregar, luego del cual hace
equipo.
CURSO ALTERNO
CA-1:
1. El usuario procede a actualizar el estado de OT del
equipo.
2. El sistema valida que la información actualizada en
las cajas de texto sean consistentes, en caso contrario
muestra un mensaje de advertencia, o un contrario
muestra un mensaje de error.
49
3. El usuario verifica que la información en las cajas
sean correctas y hace clic en la opción “Actualizar”.
CA-3:
mostrado.
Tabla N° 3.14: Primer borrador del caso de uso “Administrar estado del equipo por
entregar”
3.1.4. REVISIÓN DE REQUISITOS

A. REVISIÓN DEL MODELO DE DOMINIO
Figura N° 3.15: Revisión de modelo de dominio
B. REVISIÓN DE LA INTERFAZ GRAFICA
50
Figura N° 3.16: Prototipo de interfaz gráfica “Administrar personal”
51
Figura N° 3.17: Prototipo de interfaz gráfica “Generar Orden de trabajo”
Figura N° 3.18: Prototipo de interfaz gráfica “Realizar informe técnico”
52
Figura N° 3.19: Prototipo de interfaz gráfica “Administrar estado del equipo por
entregar”
C. REVISIÓN DE LOS CASOS DE USO

Curso Básico
1. El usuario accede al sistema.
2. El sistema muestra un formulario del login al
usuario.
3. El usuario ingresa su usuario y contraseña y hace
clic en la opción “Ingresar”.
4. El sistema evalúa los datos ingresados por el
usuario, con lo cual se ejecuta el curso alterno.
CU-01: Autenticar Usuario Curso Alterno
1. Si el usuario no ingresa ningún dato a las cajas de
texto, el sistema muestra un mensaje de advertencia
“ingrese su usuario y contraseña”.
2. El sistema verifica si los datos ingresados del
usuario son correctas.
53
3. El sistema muestra al usuario un mensaje de error
“el usuario y/o contraseña son incorrectas”.
4. El usuario ingresa su usuario y contraseña
nuevamente.
5. El sistema autentica al usuario.
Tabla N° 3.15: Revisión del caso de uso “Autenticar Usuario”

Curso Básico
2. El usuario selecciona la opción “administrar
personal”.
de colaboradores por el nombre, una tabla de la lista
de todos los colaboradores de la empresa y el
formulario de ingreso de datos con las cajas de texto
bloqueado.
4. El usuario ingresa el nombre del colaborador para
buscar.
5. El sistema encuentra y muestra al colaborador
CU-02: Administrar indicado.
6. El usuario selecciona al colaborador sobre el cual
personal
se realizara una de las opciones “Modificar” o
“Eliminar”, con lo cual se ejecuta el curso alterno
(CA-1) y (CA-2).
7. El usuario desea ingresar a un nuevo usuario,
habilita todas las cajas de texto para ingresar los
datos del nuevo colaborador, luego del cual hace
clic en la opción “Guardar”, con lo cual se ejecutara
el curso alterno (CA-3).
Curso Alterno
CA-1:
1. El usuario hace clic en la opción “Modificar”.
2. El sistema carga los datos del colaborador en las
54
mensaje de error.
CA-2:
1. El usuario hace clic en la opción “Eliminar”.
CA-3:
colaborador.
3. El sistema valido que la información ingresada en
Tabla N° 3.16: Revisión del caso de uso “Administrar Personal”

CURSO BÁSICO
7. El usuario selecciona la opción “Registrar Cliente”.
cliente por número de documento, una tabla de lista
de todos los clientes registrados de la empresa y el
formulario de ingreso de datos del cliente con las
cajas de texto bloqueado.
luego del cual hace clic en la opción “Guardar”, con
CU-03: Registrar Cliente lo cual se ejecuta el Curso Alterno (CA-1).
CURSO ALTERNO
CA-1:
55
cajas de texto sean consistentes, si está vacía, son
números en las cajas de texto corresponde y muestra
un mensaje de advertencia en caso contrario un
mensaje de error.
“Guardar”.
Tabla N° 3.17: Revisión del caso de uso “Registrar Cliente”

CURSO BÁSICO
2. El usuario selecciona la opción “Generar OT”.
Reporte”, una tabla de lista de equipos ingresados
pendientes por reparar con las opciones de
“Modificar” y “Eliminar” y el formulario del equipo
con las cajas de texto bloqueado.
CU-04: Generar orden de necesarios, los accesorios, con que defecto y el
estado de ingreso del equipo por cliente luego del
trabajo
cual hace clic en la opción “Guardar”, con lo cual se
7. El sistema genera el orden de trabajo (OT) del
producto, de acuerdo al orden del registro del equipo.
10. El sistema muestra el equipo en la lista de equipos
ingresados pendientes por reparar el equipo
registrado con sus observaciones y accesorios.
alguna modificación alguna del equipo, realizando
clic sobre la opción “Modificar” del registro
correspondiente.
56
correspondiente.
15. El usuario recepcionista modifica algunas
informaciones necesarias, luego del cual hace clic en
la opción “Modificar” con lo cual se ejecuta el Curso
Alterno (CA-2).
equipo.
CURSO ALTERNO
CA-1:
necesarias, accesorios, defecto y el estado de ingreso
del equipo.
cajas de texto sean consistentes, en caso si está vacía,
o son números en cada caja de texto correspondiente
muestra un mensaje de advertencia, en caso contrario
“Guardar”.
CA-2:
de error.
“Actualizar”.
CA-3:
57
mostrado.
Tabla N° 3.18: Revisión del caso de uso “Generar Orden de Trabajo”

CURSO BÁSICO
técnico”.
al usuario con una caja de texto de búsqueda del
desbloqueada y la opción “Buscar”, y una tabla de
lista de equipos ingresados por el “área de recepción”
con el icono “Generar” y las demás cajas de texto
bloqueado.
revisado sobre el cual a ingresar su informe técnico.
6. El usuario hace clic sobre el icono “Generar”.
CU-05: Realizar Informe 7. El sistema muestra en las cajas de texto
Técnico
equipo ingresado por el área de recepción y
técnico.
CURSO ALTERNO
CA-1:
58
“Actualizar”.
Tabla N° 3.19: Revisión del caso de uso “Realizar informe técnico”

CURSO BÁSICO
entregar”.
entregar con el icono “Entregar” y las demás cajas de
texto bloqueado.
reparado y aceptado por entregar, sobre el cual a
informe técnico.
CU-06: Administrar estado 6. El usuario hace clic sobre el icono “Entregar”.
de OT.
8. El usuario verifica la información del equipo y
59
buscar y generar reporte del informe técnico del
equipo reparado.
CURSO ALTERNO
CA-1:
equipo.
CA-3:
mostrado.
Tabla N° 3.20: Revisión del caso de uso “Administrar estado del equipo por entregar”

CURSO BÁSICO
2. El usuario selecciona la opción “Equipos
ingresados”.
3. El sistema muestra la opción de búsqueda por día y
una tabla de lista de todos los equipos registrados por
el área de recepción.
4. El usuario selecciona de que día desea consultar la
lista de equipos registrados y hace clic en la opción
ingresados “Buscar”.
5. El sistema muestra una lista de equipos ingresados
del día seleccionada.
60
CURSO ALTERNO
lista de equipos ingresados.
2. El sistema valida que el día seleccionado sea
consistente o cuando está vacía muestra un mensaje
de advertencia.
Tabla N° 3.21: Revisión del caso de uso “Mostar Equipos ingresados”

CURSO BÁSICO
ingresados”.
una tabla de lista de todos los equipos reparados en
el área de servicio técnico.
lista de equipos reparados y hace clic en la opción
reparados “Buscar”.
5. El sistema muestra una lista de equipos reparados del
día seleccionada.
CURSO ALTERNO
lista de equipos reparados.
de advertencia.
Tabla N° 3.22: Revisión del caso de uso “Mostar equipos reparados”

CURSO BÁSICO
entregar”.
3. El sistema muestra una caja de texto de búsqueda por
el número de Orden de Trabajo (OT) del equipo
desbloqueado y la opción “Generar Reporte”, una
tabla de lista de todos los equipos reparados.
4. El usuario ingresa el número de OT del equipo que
desea generar el reporte de informe técnico.
61
5. El sistema muestra el equipo buscado por el número
OT en la lista de productos reparados.
CU-09: Generar reporte del
6. El usuario hace clic en la opción “Generar Reporte”
informe técnico 7. El sistema muestra su informe técnico del equipo
buscado en formato pdf.
8. El usuario comienza imprimir haciendo clic en la
opción “Imprimir” con lo que se ejecutará el Curso
Alterno.
CURSO ALTERNO
1. El usuario ingresa el OT del equipo que desea
generar el reporte de informe técnico.
2. El sistema valida que el OT ingresado sea consistente
en caso si el OT del producto ingresado aún no está
reparado muestra un mensaje de advertencia.
mostrado.
Tabla N° 3.23: Revisión del caso de uso “generar reporte del informe técnico”

CURSO BÁSICO
entregados”.
una tabla de lista de todos los equipos entregados por
el área de recepción.
lista de equipos entregados y hace clic en la opción
entregados al cliente “Buscar”.
5. El sistema muestra una lista de equipos entregados
CURSO ALTERNO
lista de equipos entregados.
de advertencia.
Tabla N° 3.24: Revisión del caso de uso “Mostar equipos reparados”
62
CURSO BÁSICO
Entregados”.
una lista de todos los productos entregados al cliente.
4. El usuario selecciona de que día desea generar el
reporte y hace clic en la opción “Buscar”.
6. El usuario hace clic en la opción “Generar Reporte”
CU-11: Generar reporte de del día seleccionado en formato pdf.
8. Opcionalmente el usuario podrá dar clic en la opción
equipos entregados al
“Imprimir” con lo que se ejecutará el Curso Alterno.
cliente
CURSO ALTERNO
1. El usuario selecciona de que día desea generar el
reporte.
de advertencia.
solicitadas y hace click en el botón “Imprimir”.
mostrado.
Tabla N° 3.25: Revisión del caso de uso “Generar reporte de equipos entregados al
cliente”

CURSO BÁSICO
técnico”.
al usuario con una caja de texto de búsqueda de
equipos por el número de orden de trabajo (OT)
63
desbloqueada y la opción “Buscar”, una tabla de lista
de equipos revisados con la opción “Actualizar” y las
demás cajas de texto bloqueado.
4. El usuario ingresa el número de OT del equipo a la
caja de texto de búsqueda, para buscar el producto
sobre el cual a actualizar el estado de reparación.
informe técnico realizado.
6. El usuario hace clic sobre el icono “Actualizar”.
7. El sistema desbloquea las cajas de texto y muestra en
las cajas de texto correspondiente toda la
CU-12: Administrar estado información del equipo buscado.
8. El usuario actualiza alguna información y el estado
de revisión del equipo
del proceso reparación del equipo seleccionado,
luego del cual hace clic en la opción “Actualizar”,
con lo cual se ejecuta el Curso Alterno (CA-1).
11. El sistema muestra al usuario la información
actualizada en la tabla de lista de productos
reparados.
CURSO ALTERNO
CA-1:
1. El usuario procede a actualizar el estado del proceso
de reparación del equipo.
2. El sistema valida que la información actualizada sean
consistentes en las cajas de texto correspondiente, en
caso contrario muestra un mensaje de error.
3. El usuario verifica que la información actualizada en
“Actualizar”.
Tabla N° 3.26: Revisión del caso de uso “Administrar estado de revisión del equipo”
3.1.5. DISEÑO PRELIMINAR

A. DIAGRAMA DE ROBUSTEZ
64
sd Administrar Personal
Curso Basico
1) El sistema muestra al usuario el menú con las
2) El usuario selecciona la opción "administrar
personal".
3) El sistema muestra una caja de texto de
búsqueda de colaboradores por el nombre,
una tabla de la lista de todos los
colaboradores de la empresa y el formulario Mostrar Lista Personal
Menu Administrar
de ingreso de datos con las cajas de texto Personal
bloqueado.
4) El usuario ingresa el nombre del colaborador
para buscar.
5) El sistema encuentra y muestra al colaborador
indicado.
6) El usuario selecciona al colaborador sobre el
cual se realizara una de las opciones
"Modificar" o "Eliminar", con lo cual se
ejecuta el curso alterno (CA-1) y (CA-2). Mostrar Mensaje de
7) El usuario desea ingresar a un nuevo usuario, Error
entonces hace clic en la opción "Nuevo" y se
habilita todas las cajas de texto para ingresar Mostrar Formulario
los datos del nuevo colaborador, luego del Administrar Personal
cual hace clic en la opción "Guardar", con lo
cual se ejecutara el curso alterno (CA-3). Actor
8) El sistema guarda la información en la base Trabajador
(from Actors)
de datos y muestra un mensaje de
confirmación, en caso contario un mensaje de
error. Insertar Personal
9) El usuario hace clic en Aceptar.
Curso Alterno Registar Nuevo
CA-1: Personal
1) El usuario hace clic en la opción "Modificar". Formulario Administrar
2) El sistema carga los datos del colaborador en Personal
las cajas de texto correspondiente sobre el
cual se realizara cualquier modificación.
3) El usuario modifica los datos convenientes y
hace clic en la opción "Actualizar".
4) El sistema guarda la información modificada Buscar Personal
en la base de datos y muestra un mensaje de
mensaje de error.
CA-2:
1) El usuario hace clic en la opción "Eliminar".
2) El sistema cambia de estado activo (1) a
inactivo (0) y muestra un mensaje de Actualizar Pesonal
Mostrar Mensaje de
confirmación, en caso contario muestra un
error
mensaje de error.
CA-3:
1) El usuario procede a ingresar los datos del
nuevo colaborador.
2) El usuario hace clic en la opción "Guardar"
3) El sistema valido que la información
ingresada en las cajas de texto sean
consistentes.
4) El sistema muestra un mensaje de advertencia
en caso de que si una de las cajas obligatorias
está vacía o falta ingresar.
Figura N° 3.20: Diagrama de robustez del caso de uso “Administrar personal”
65
sd Registrar Cliente
CURSO BÁSICO
1) El sistema muestra al usuario el menú
con las opciones propias del perfil del
usuario Recepcionista.
2) El usuario selecciona la opción
"Registrar Cliente".
3) El sistema muestra una caja de texto
de búsqueda del cliente por número de
documento, una tabla de lista de todos
los clientes registrados de la empresa y Mostrar Lista Cliente
Menu Registrar Cliente
el formulario de ingreso de datos del
cliente con las cajas de texto
bloqueado.
4) El usuario hace clic en la opción
"Nuevo".
5) El sistema desbloquea las cajas de
texto.
6) El usuario ingresa los datos necesarios
del cliente, luego del cual hace clic en Mostrar Mensaje de
la opción "Guardar", con lo cual se Error
Mostrar Formulario
ejecuta el Curso Alterno (CA-1). Actor Registrar Cliente Cliente
7) El sistema guarda la información en la
base de datos y muestra un mensaje de (from Actors)
confirmación, en caso contrario muestra
CURSO ALTERNO
CA-1: Insertar Cliente
1) El usuario procede a ingresar los datos
del cliente.
2) El sistema valida que la información Formulario Registrar Registrar Nuevo Cliente
ingresada en las cajas de texto sean Cliente
consistentes, si está vacía, son números
en las cajas de texto corresponde y
muestra un mensaje de advertencia en
caso contrario un mensaje de error.
3) El usuario verifica que la información
ingresada en las cajas sean correctas y
hace clic en la opción "Guardar". Mostrar Mensaje de
Validacion
Figura N° 3.21: Diagrama de robustez del caso de uso “Registrar cliente”
66
obj ect CU-04: Generar Orden de Trabaj o
CURSO BÁSICO
1) El sistema muestra al usuario el menú con las opciones
propias del perfil del usuario Recepcionista.
2) El usuario selecciona la opción "Generar OT".
3) El sistema muestra una caja de texto de búsqueda del
equipo por el número de OT, la opción "Generar
Reporte", una tabla de lista de equipos ingresados Buscar Cliente Cliente
pendientes por reparar con las opciones de "Modificar" y
"Eliminar" y el formulario del equipo con las cajas de
texto bloqueado.
4) El usuario hace clic en la opción "Nuevo".
5) El sistema desbloquea las cajas de texto.
6) El usuario ingresa todas las observaciones necesarios, Buscar Equipo Equipo
los accesorios, con que defecto y el estado de ingreso
del equipo por cliente luego del cual hace clic en la
opción "Guardar", con lo cual se ejecuta el Curso
Alterno (CA-1).
7) El sistema genera el orden de trabajo (OT) del producto,
de acuerdo al orden del registro del equipo. Buscar Costo
CostoMantenimiento
8) El sistema guarda la información en la base de datos y mantenimiento
muestra un mensaje de confirmación, en caso contrario
9) El usuario hace clic en Aceptar. Mostrar Mensaje de
10) El sistema muestra el equipo en la lista de equipos Error
ingresados pendientes por reparar el equipo registrado
con sus observaciones y accesorios. Insertar Orden de
11) El usuario ingresa el número del OT del equipo para Trabajo
buscar y modificar cuando sea necesario. Formulario Orden de
12) El sistema busca y muestra el equipo buscado por el Trabajo
número del orden de trabajo. Actor Registrar Nuevo Orden
13) El usuario selecciona el equipo sobre el cual realizara Trabajo
alguna modificación alguna del equipo, realizando clic (from Actors)
sobre la opción "Modificar" del registro correspondiente.
14) El sistema muestra toda la información del equipo antes
seleccionada en las cajas de texto correspondiente.
15) El usuario recepcionista modifica algunas informaciones
necesarias, luego del cual hace clic en la opción
"Modificar" con lo cual se ejecuta el Curso Alterno (CA- Mostrar Formulario Mostrar Mensaje de Buscar Orden Trabajo
2). Administrar Producto Error
16) El sistema actualiza la información en la base de datos
y muestra un mensaje de confirmación, en caso hace clic
17) El usuario hace clic en "Aceptar".
18) El usuario ingresa el número del OT del equipo para
equipo. Actualizar Orden de
19) El sistema busca y muestra el equipo buscado por el Trabajo
20) El usuario procede generar reporte haciendo clic en la OrdenTrabajo
opción "Generar Reporte" con lo cual se ejecutara el
Curso Alterno (CA-3).
Generar Reporte de
CURSO ALTERNO Orden de trabajo
CA-1:
1) El usuario procede ingresar las observaciones
necesarias, accesorios, defecto y el estado de ingreso Menu Generar Orden
del equipo. Trabajo
2) El sistema valida que la información ingresada en las
cajas de texto sean consistentes, en caso si está vacía, o
son números en cada caja de texto correspondiente
muestra un mensaje de advertencia, en caso contrario Mostrar Lista Equipos
un mensaje de error. Ingresados
3) El usuario verifica que la información ingresada en las
cajas sean correctas y hace clic en la opción "Guardar".
CA-2:
1) El usuario recepcionista procede modificar la
2) El sistema valida que la información modificada en las
cajas de texto sean consistentes, en caso de que la
de error.
3) El usuario verifica que la información modifica en las
"Actualizar".
CA-3:
1) El sistema mostrara las opciones de impresión.
2) El usuario selecciona las opciones de impresión
solicitadas y hace clic en el botón "Imprimir".
3) El sistema procede a la impresión del documento
mostrado.
Figura N° 3.22: Diagrama de robustez del caso de uso “Generar Orden de Trabajo”
67
sd Realizar Informe Técnico
CURSO BÁSICO
2) El usuario selecciona la opción "Generar
Informe técnico".
3) El sistema muestra el formulario de informe
técnico al usuario con una caja de texto de
búsqueda del equipo por el número de orden
de trabajo (OT) desbloqueada y la opción
"Buscar", y una tabla de lista de equipos
ingresados por el "área de recepción" con el
icono "Generar" y las demás cajas de texto
bloqueado.
Menu Generar Informe
4) El usuario ingresa el número de OT del equipo
en la caja de texto de búsqueda, para buscar el Tecnico Mostrar Lista Equipos
Orden de trabajo
equipo revisado sobre el cual a ingresar su ingresados
informe técnico.
5) El sistema busca al equipo por el número de
OT ingresado y muestra el equipo indicado con hace clic
sus observaciones, accesorios y defecto.
6) El usuario hace clic sobre el icono "Generar".
7) El sistema muestra en las cajas de texto
Mostrar Mensaje Error
correspondiente toda la información registrada
del equipo ingresado por el área de recepción y
desbloquea las cajas de texto de ingresar el Buscar Orden Trabajo
informe técnico. Mostrar Formulario de
8) El usuario ingresa la información del proceso de Informe Tecnico
estado de OT del equipo revisado, luego del
cual hace clic en la opción "Actualizar", con lo Actor
cual se ejecuta el Curso Alterno (CA-1).
(from Actors) Trabajador
9) El sistema guarda la información en la base de Buscar Tecnico
datos y muestra un mensaje de confirmación, en
caso contrario muestra un mensaje de error.
11) El sistema muestra al usuario de "Recepción" la
Formulario de Informe
productos revisados y/o reparados. Tecnico
CURSO ALTERNO Generar Informe Insertar Informe

Inorme Tecnico
CA-1: Tecnico Tecnico
1) El usuario procede a ingresar la información del
2) El sistema valida que la información ingresada
en las cajas de texto sean consistentes, si el
campo es obligatorio o son números en las cajas
de texto correspondiente muestra un mensaje
de advertencia, en caso contrario muestra un
mensaje de error.
3) El usuario verifica que la información ingresada Mostar Mensaje de
en las cajas sean correctas y hace clic en la Error
opción "Actualizar".
Figura N° 3.23: Diagrama de robustez del caso de uso “Realizar Informe Técnico”
68
sd CU-06: Administrar estado del equipo por entregar
CURSO BÁSICO
2) El usuario selecciona la opción "Equipos por
entregar".
3) El sistema muestra el formulario de equipos por
entregar al usuario con una caja de texto de
búsqueda del equipo por el número de orden de
trabajo (OT) desbloqueada y la opción "Generar
Reporte", y una tabla de lista de equipos reparados y Equipo
aceptados por entregar con el icono "Entregar" y las
demás cajas de texto bloqueado.
4) El usuario ingresa el número de OT del equipo en la
Mostar Lista Equipos
reparado y aceptado por entregar, sobre el cual a Menu Equipo por
Entregar Reparados
InformeTecnico
5) El sistema busca al equipo por el número de OT
informe técnico. Generar Reporte
6) El usuario hace clic sobre el icono "Entregar". Informe Tecnico
7) El sistema muestra en las cajas de texto
correspondiente toda la información registrada del hace clic
de OT.
8) El usuario verifica la información del equipo y
procede actualizar el estado de OT del equipo Buscar Equipo OrdenTrabajo
reparado y aceptado por entregar, luego del cual Mostrar Formulario
hace clic en la opción "Actualizar", con lo cual se Equipos por entregar
9) El sistema guarda la información en la base de datos
10) El usuario hace clic en Aceptar. Recepcionista Mostrar Mensaje de
11) El usuario ingresa el número del OT del equipo para Error Actualizar estado del
(from Actors)
buscar y generar reporte del informe técnico del orden
equipo reparado.
12) El sistema busca y muestra el equipo buscado por el
13) El usuario procede generar reporte haciendo clic en
Formulario Equipos por
la opción "Generar Reporte" con lo cual se ejecutara
entrgar
el Curso Alterno (CA-2). Generar Entrega Orden Insertar Entrega Orden EntregaOrden
CURSO ALTERNO
CA-1:
1) El usuario procede a actualizar el estado de OT del
equipo.
2) El sistema valida que la información actualizada en
Mostrar Mensaje de
Error
3) El usuario verifica que la información en las cajas
sean correctas y hace clic en la opción "Actualizar".
CA-3:
1) El sistema mostrara las opciones de impresión.
2) El usuario selecciona las opciones de impresión
solicitadas y hace clic en el botón "Imprimir".
3) El sistema procede a la impresión del documento
mostrado.
Figura N° 3.24: Diagrama de robustez del caso de uso “Administrar estado del equipo
por entregar”
B. MODELO DE DOMINIO ACTUALIZADO
69
class Modelo de Domi...
TipoDocumento
- IdTipoDocumento: int
Persona
Usuario - Abreviatura: String
- IdPersona: int - Denominacion: String
- IdUsuario: int Tiene Tiene
- IdTipoPersona: int - Estado: bit
- Usuario: String - Nombre: String
- Contraseña: String - ApePerno: String
- FechaRegistro: Date - ApeMaterno: String
- TelefonoFijo: String Es un
TipoPersona
Tiene - TelefonoMovil: String
- Email: String - IdTipoPersona: int
- Direccion: String - Denominacion: String
- Estado: bit
TipoUsuario
- IdRolUsuario: int
- Abreviatura: String
- Denominacion: String
Cliente Trabaj ador

Area
- IdTrabajador: int Pertenece
- IdCliente: int - IdArea: int
- IdPersona: int - IdPersona: int
- IdArea: int
- FechaNacimiento: Date
TipoEquipo PrecedenciaRepuesto
Genera
- IdTipoProducto: int Reistra - IdProcedenciaRepuesto: int
- Denominacion: String - Denominacion: String
Tiene
Pertenece OrdenTrabaj o InformeTecnico
- IdProducto: int - IdInformeTecnico: int

Equipo Pertenece
- Marca: String - InformeTecnico: String
- Serie: String - Defecto: String
- IdEquipo: int Pertenece
- Accesorio: String - Solucion: String
- NomEquipo: String Tiene
- Defecto: String
- Marca: String EstadoReparacion
- Descripcion: String
- Procesador: String
- Observacion: String
- IdEstadoReparacion: int
Tiene
Incluye Tiene
CostoMantenimiento EstadoOrdenTrabaj o EntregaEquipo

Es Entregado
- IdCostoMantenimiento: int - IdEstado: int - IdEntregaEquipo: int
- Descripcion: String - Denominacion: String - FechaEntrega: date
- Costo: double
Figura N° 3.25: Modelo de dominio actualizado
3.1.6. REVISIÓN DEL DISEÑO PRELIMINAR

A. REVISIÓN DE LA DESCRIPCIÓN DE LOS CASOS DE USO

CURSO BÁSICO
2. El usuario selecciona y hace clic en la opción
“Registrar Cliente”.
cliente por número de documento, una tabla de lista
de todos los clientes registrados con los iconos
“Modificar” y “Registrar” y el formulario de ingreso
de datos del cliente con las cajas de texto bloqueado.
CU-03: Registrar Cliente luego del cual hace clic en la opción “Guardar”, con
lo cual se ejecuta el Curso Alterno (CA-1).
70
CURSO ALTERNO
CA-1:
cajas de texto sean consistentes.
caso de que si una de las cajas obligatorias está vacía
o falta ingresar.
“Guardar”.
Tabla N° 3.28: Revisión del caso de uso “Registrar Cliente”

Curso Básico
“administrar personal”.
de trabajadores por el nombre, una tabla de la lista
de todos los trabajadores de la empresa con los
iconos “Modificar” y “Eliminar” y el formulario de
registro de datos con las cajas de texto bloqueado.
4. El usuario ingresa el nombre del trabajador para
buscar.
5. El sistema encuentra y muestra al trabajador
buscado.
6. El usuario selecciona al trabajador sobre el cual se
realizara una de las opciones “Modificar” o
CU-02: Administrar “Eliminar”, con lo cual se ejecuta el curso alterno
(CA-1) y (CA-2).
personal
7. El usuario desea registrar a un nuevo usuario,
desbloquea todas las cajas de texto para ingresar los
datos del nuevo trabajador, luego del cual hace clic
en la opción “Guardar”, con lo cual se ejecuta el
curso alterno (CA-3).
71
Curso Alterno
CA-1:
1. El usuario hace clic sobre el icono “Modificar”.
2. El sistema muestra los datos del trabajador en las
mensaje de error.
CA-2:
1. El usuario hace clic sobre el icono “Eliminar”.
CA-3:
trabajador.
3. El sistema valida que la información ingresada en
Tabla N° 3.27: Revisión del caso de uso “Administrar Personal”

CURSO BÁSICO
“Generar OT”.
Reporte”, una tabla de lista de equipos ingresados
72
pendientes por reparar con las opciones de
“Modificar” y “Eliminar” y el formulario de generar
el orden de trabajo con las cajas de texto bloqueado.
CU-04: Generar orden de
trabajo necesarios, los accesorios, con que defecto y el
estado de orden del equipo por cliente, luego del cual
hace clic en la opción “Guardar”, con lo cual se
7. El sistema genera el número de orden de trabajo (OT)
del equipo, de acuerdo al orden del registro del
equipo.
10. El sistema muestra en la lista de equipos ingresados
pendientes por reparar el equipo registrado con sus
observaciones y accesorios.
alguna modificación del equipo, realizando clic sobre
el equino “Modificar” del registro correspondiente.
correspondiente.
15. El usuario procede modificar algunas informaciones
necesarias, luego del cual hace clic en la opción
“Modificar” con lo cual se ejecuta el Curso Alterno
(CA-2).
equipo.
CURSO ALTERNO
CA-1:
73
necesarias, accesorios, defecto y el estado de orden
del equipo.
cajas de texto sean consistentes, en caso de que la
información ingresada no es consistente muestra un
de error.
“Guardar”.
CA-2:
de error.
“Actualizar”.
CA-3:
mostrado.
Tabla N° 3.29: Revisión del caso de uso “Generar Orden de Trabajo”

CURSO BÁSICO
“Generar Informe técnico”.
desbloqueada y la opción “Buscar”, una tabla de lista
de equipos ingresados por el “área de recepción” con
el icono “Generar” y el formulario de registro de
informe técnico con las cajas de texto bloqueado.
ingresado sobre el cual a ingresar su informe técnico.
74
6. El usuario hace clic sobre el icono “Generar”.
CU-05: Realizar Informe equipo ingresado por el área de recepción y
Técnico
técnico.
CURSO ALTERNO
CA-1:
“Actualizar”.
Tabla N° 3.30: Revisión del caso de uso “Realizar informe técnico”

CURSO BÁSICO
“Equipos por entregar”.
75
entregar con el icono “Entregar” y las demás cajas de
texto bloqueado.
17. El usuario ingresa el número del OT del equipo en la
caja de texto de búsqueda, para buscar el equipo por
entregar y generar reporte del informe técnico del
equipo reparado y sobre el cual a actualizar el estado
de OT.
18. El sistema busca el equipo por el número de OT
ingresado y muestra el equipo buscado con su
CU-06: Administrar estado informe técnico.
20. El usuario hace clic sobre el icono “Entregar” para
actualizar el estado de entrega del equipo.
de OT.
22. El usuario verifica la información del equipo y
CURSO ALTERNO
CA-3:
mostrado.
CA-1:
equipo.
76
Tabla N° 3.31: Revisión del caso de uso “Administrar estado del equipo por entregar”
b. revisión del modelo de dominio actualizado

class Modelo de Domi...
TipoDocumento
- IdTipoDocumento: int
Persona
Usuario - Abreviatura: String
- IdPersona: int - Denominacion: String
- IdUsuario: int Tiene Tiene
- IdTipoPersona: int - Estado: bit
- Usuario: String - Nombre: String
- Contraseña: String - ApePerno: String
- FechaRegistro: Date - ApeMaterno: String
- TelefonoFijo: String Es un
TipoPersona
Tiene - TelefonoMovil: String
- Email: String - IdTipoPersona: int
- Direccion: String - Denominacion: String
- Estado: bit
TipoUsuario
- IdRolUsuario: int
- Abreviatura: String
Cliente Trabaj ador

Area
- IdTrabajador: int Pertenece
- IdCliente: int - IdArea: int
- IdPersona: int - IdPersona: int
- IdArea: int
- FechaNacimiento: Date
TipoEquipo PrecedenciaRepuesto
Recoge Genera
- IdTipoProducto: int Genera - IdProcedenciaRepuesto: int
- Denominacion: String - Denominacion: String
Tiene
Pertenece OrdenTrabaj o InformeTecnico
- IdProducto: int - IdInformeTecnico: int

Equipo que pertenece a un
- Marca: String - InformeTecnico: String
- Serie: String - Defecto: String
- IdEquipo: int Pertenece
- Accesorio: String - Solucion: String
- NomEquipo: String Tiene
- Defecto: String
- Marca: String EstadoReparacion
- Descripcion: String
- Procesador: String
- Observacion: String
Tiene
Contiene
Incluye Tiene
CostoMantenimiento EstadoOrdenTrabaj o EntregaEquipo

Tiene
- IdCostoMantenimiento: int - IdEstado: int - IdEntregaEquipo: int
- Descripcion: String - Denominacion: String - FechaEntrega: date
- Costo: double
Figura N° 3.26: Modelo de dominio actualizado
3.1.7. ARQUITECTURA TÉCNICA

A. DIAGRAMA DE COMPONENTES
77
Figura N° 3.27: Arquitectura técnica. Diagrama de componentes
B. DIAGRAMA DE DESPLIEGUE
78
Figura N° 3.28: Arquitectura técnica. Diagrama de despliegue
79
3.1.8. DISEÑO
A. DIAGRAMA DE SECUENCIA
Figura N° 3.29: diagrama de secuencia. Registrar cliente
80
Figura N° 3.30: Diagrama de secuencia. Administrar personal
81
Figura N° 3.31: Diagrama de secuencia. Generar orden de trabajo
82
Figura N° 3.32: Diagrama de secuencia. Realizar informe técnico
83
Figura N° 3.33: Diagrama de secuencia. Administrar estado del equipo por entregar
84
B. DIAGRAMA DE CLASES DE DISEÑO
class Diagrama de clases
Usuario Persona TipoPersona

TipoUsuario - IdPersona: int - IdTipoPersona: int
- IdUsuario: int
- IdRolUsuario: int - IdPersona: int - IdTipoPersona: int - Denominacion: String
- Abreviatura: String - IdTipoUsuario: int - Nombre: String Pertenece - FechRegistra: Date
- Denominacion: String - FechaVigencia: Date - ApePaterno: String - FechModifica: Date
- ApeMaterno: String 1..* 1 - Estado: bit
- FechRegistra: Date Tiene - NombUsuario: String
- FechModifica: Date - Contrasenia: String Tiene - IdTipoDocumento: int TipoDocumento
- Estado: bit 1 1..* - FechRegistra: Date - NumDocumento: String + Listtipopersona() : List
1..* 1 - Telefono: String - IdTipoDocumento: int + Insertartipopersona() : boolean
- FechModifica: Date
+ Listtipousuario() : List - Estado: bit - TelefonoMovil: String - Abreviatura: Sting + Eliminartipopersona() : boolean
+ Insertartipousuario() : boolean - Email: String - Denominacion: String + Actualizartipopersona() : boolean
+ Eliminartipousuario() : boolean + Listusuario() : List - Direccion: String - FechRegistra: Date
+ Actualizartipousuario() : boolean + Insertarusuario() : boolean - IdRegUsuaRegistra: int Tiene - FechModifica: Date
+ Eliminarusuario() : boolean - IdRegUsuaModifica: int - Estado: bit
- FechRegistra: Date 1..* 1
+ Actualizarusuario() : boolean
- FechModifica: Date + Listtipodocumento() : List
- CantidadModifica: int + Insertartipodocumento() : boolean
- Estado: bit + Eliminartipodocumento() : boolean
+ Actualizartipodocumento() : boolean
TipoEquipo
Trabaj ador
- IdTipoEquipo: int Cliente Area
- IdTrabajador: int
- IdCliente: int - IdPersona: int - IdArea: int
- FechRegistra: Date
- IdPersona: int - IdArea: int - Denominacion: String
- FechRegistra: Date - FechaNacimiento: Date - FechRegistra: Date
- Estado: bit
- FechModifica: Date - Experiencia: String Pertenece - FechModifica: Date
- Estado: bit - GradoAcademico: String
+ Listtipoequipo() : List
- FechRegistra: Date 1..* 1 - Estado: bit
+ Insertartipoequipo() : boolean
+ Listcliente() : List - FechModifica: Date + Listarea() : List
+ Eliminartipoequipo() : boolean
+ Autocompletecliente() : ArrayList - Estado: bit + Insertararea() : boolean
+ Actualizartipoequipo() : boolean
+ Insertarcliente(opersona, ocliente) : boolean + Eliminararea() : boolean
1 + EliminarclienteBean() : boolean + Listtrabajador() : List + Actualizararea() : boolean
+ Actualizarcliente(opersona, ocliente) : boolean + Autocompletetrabajador() : ArrayList
+ Insertartrabajador(opersona, otrabajador, ousuario) : boolean
Pertenece
1 + EliminartrabajadorBean() : void
+ ActualizartrabajadorBean(opersona, otrabajador, ousuario) : boolean
Recoge
1..* Genera 1 1..* Genera
ProcedenciaRepuestos
Equipo 1..* 1..*

1 - IdProcedenciaRepuesto: int
- IdEquipo: int OrdenTrabaj o - FechRegistra: Date
InformeTecnico
- IdTipoEquipo: int
- IdOrdenTrabajo: int - FechModifica: Date
- NomEquipo: String - IdInformeTecnico: int - Estado: bit
- Marca: String - IdCliente: int
- IdOrdenTrabajo: int
- Procesador: String Pertenece - FechaEntrega: Date Incluye
- InformeTecnico: String 1 + Listprocedenciarepuesto() : List
- FechRegistra: Date - IdEquipo: int
1 1 - - Defecto: String + Insertarprocedenciarepuesto() : boolean
- FechModifica: Date Modelo: String 1..*
- Solucion: String + Eliminarprocedenciarepuesto() : boolean
- Estado: bit - Serie: String
- IdProcedenciaRepuesto: int + Actualizarprocedenciarepuesto() : boolean
- Accesorios: String
+ Listequipo() : List - Observacion: String Pertenece - IdTecnico: int
+ Insertarequipo() : boolean - Descripcion: String
- Defecto: String 1 1 - FechRegistra: Date
+ Eliminarequipo() : boolean - FechModifica: Date
+ Actualizarequipo() : boolean - IdRecepcionista: int
- Estado: bit
- IdCostoMantenimiento: int
- PagoAdelantado: double
1 + Listinformetecnico() : List
- IdEstadoOrden: int
CostoMantenimiento + JqGridinformetecnico() : ArrayList
- FechRegistra: Date
+ JqGridproductoreparado() : ArrayList
- IdCostoMantenimiento: int + Autocompleteinformetecnico() : ArrayList
- Estado: bit 1..*Tiene
- Descripcion: String + Insertarinformetecnico(oinformetecnico, oordentrabajo) : boolean
- Costo: double + Actualizarinformetecnico() : boolean EstadoReparacion
+ Listordentrabajo() : List
- FechRegistra: Date Tiene 1 -
+ JqGridordentrabajo() : ArrayList Contiene 1 IdEstadoReparacion: int
1 1..* + Autocompleteordentrabajo() : ArrayList - Denominacion: String
- Estado: bit Tiene
+ Insertarordentrabajo() : boolean - FechRegistra: Date
+ Eliminarordentrabajo() : boolean - FechModifica: Date
+ Listcostomantenimiento() : List
+ Actualizarordentrabajo() : boolean 1..* - Estado: bit
+ Insertarcostomantenimiento() : boolean
+ Eliminarcostomantenimiento() : boolean 1..* EntregaOrden + Listestadoreparacion() : List
+ Actualizarcostomantenimiento() : boolean Tiene un + Insertarestadoreparacion() : boolean
- IdEntregaOrden: int
+ Eliminarestadoreparacion() : boolean
1 - IdOrdenTrabajo: int
+ Actualizarestadoreparacion() : boolean
1..* - IdInformeTecnico: int
- FechaEntrega: Date
EstadoOrden
- IdEstadoOrden: int
- IdEsadoOrden: int - FechRegistra: Date
- Denominacion: int - FechModifica: Date
- FechRegistra: Date - Estado: bit
- FechModifica: Date Tiene
- Estado: bit + Listentregaorden() : List
1 1..*
+ JqGridentregaorden() : ArrayList
+ Listestadoorden() : List + Autocompleteentregaorden() : ArrayList
+ Insertarestadoorden() : boolean + Insertarentregaorden() : boolean
+ Eliminarestadoorden() : boolean
+ Actualizarestadoorden() : boolean
Figura N°3.34: Diagrama de clases
C. DIAGRAMA DE BASE DE DATOS
85
Figura N° 3.35: Base de datos físico
86
3.1.9. IMPLEMENTACIÓN
A. CREACIÓN DE LA BASE DE DATOS
Figura N° 3.36: Creación de base de datos
Figura N° 3.37: Asignación de rol de usuario con privilegios
87
88
89
90
91
Figura N° 3.38: Creacion y relacion de tablas de la base de datos
Figura N° 3.39: Inserción de datos
B. MAQUETACIÓN DE FRONT.END CON BOOTSTRAP

Para la maquetación de las interfaces, utilizamos el framework Bootstrap v4.0,
porque Bootstrap es un primer marco frontal móvil elegante, intuitivo y de gran alvanse
para el desarrollo web más rápido y más fácil. Se utiliza HTML, CSS y JavaScript.
Estructura básica de Bootstrap:
Figura N° 3.40: Estructura básica del Framework Bootstrap
92
C. IMPLEMENTACIÓN DE LA PÁGINA DE INICIO
93
94
Figura N°3.41: Maquetacion de la pagina de inicio (index.jsp)
95
Figura N° 3.42: Pagina de inicio del sistema de gestion de informacion (extranet)
Figura N° 3.43: Pagina de inicio del sistema de gestion de informacion (intranet)
96
D. IMPLEMENTACIÓN DE LOS CASOS DE USO
97
Figura N° 3.44: Código del caso de uso “Generar orden de trabajo”
98
Figura N° 3.45: Interfaz del caso de uso “Generar orden de trabajo”
Figura N° 3.46: Interfaz de reporte del caso de uso “Generar orden de trabajo”
99
CAPITULO IV
RECOMENDACIONES
3.2. RECOMENDACIONES
a) Se debe capacitar a todos los usuarios de las áreas implicados en la utilización del
sistema de gestión de información del servicio técnico y establecer un reglamento
interno para el uso obligatorio del sistema.
b) Se recomienda al equipo técnico del área de servicio técnico registrar con

responsabilidad su informe técnico del equipo revisado de acurdo al orden de
trabajo físico.
c) Se recomienda al usuario del área de recepción registrar todo lo necesario del

equipo que está ingresando y generar su orden de trabajo.
d) Se debe desarrollar un sistema de cotización de accesorios de cómputo, redes y de

servicio de mantenimiento o soporte técnico, para que los clientes cotizan desde
cualquier lugar geográfico.
100
BIBLIOGRAFÍA
1. Aguilar, J. (1998). Programación Orientada a Objetos (2° Ed), Editorial McGraw

Hill.
2. Amaya, J. (2005). Sistemas de Información Gerenciales (1° Ed), Editorial Ecoe
Ediciones.
3. Armijo, M. (2011). Planificación estratégica e indicadores de desempeño en el
sector público, Instituto Latinoamericano y del Caribe de Planificación
Económica y Social (ILPES) Santiago de Chile.
4. Belloch, C. (2012). Las Tecnologías de la Información y comunicación en el
aprendizaje. Departamento de Métodos de Investigación y Diagnostico en
Educación. Manuscrito no publicado. Universidad de Valencia, Valencia, España.
5. Bravo J. (2013): Resumen libro Gestión de procesos 5ª edición, Gestión de
procesos (Valorando la práctica).
6. Bravo, J. (2008): Gestión de procesos, Santiago de Chile, Editorial Evolución.
7. Caivano, R. (2009). Aplicaciones web 2.0. Villa María: Eduvim.
8. Campderrich, B. (2003). Ingeniería de software (1° Ed), Editorial Uoc.
9. Diehl, S. (2007). Visualización de software: Visualizar la estructura,
comportamiento y evolución del Software. Springer Science & Business Media.
10. Fernández, V. (2006). Desarrollo de Sistemas de Información: una Metodología
Basada en el Modelado, Univ. Politécnica de Catalunya, 2010. Editor Upc
Edicions.
11. Forouzan, B. (2002). Transmisión de Datos y Redes de Comunicaciones (2da.
Ed.). Madrid, España, McGraw-Hill/Interamericana.
12. Garrido, A. (2006). Fundamentos de programación en C++. Las Rosas, Madrid,
España:Delta.
13. Groussard, T. (2012).Visual Basic 2012. Cornella de Llobregat, Barcelona:
Ediciones ENI.
14. Huerta J. y Rodriguez G. (2006): Desarrollo de habilidades directivas, México,
Pearson.
15. Jiménez, M. (2010). Bases de datos relacionales y modelado de datos. Málaga,
España: IC Editorial.
16. Nevado, V. (2010). Introducción a las bases de datos relacionales. Madrid,
España: Visión Libros.
101
17. Porras, E. (2011). La Metodología Ágil y Formal ICONIX para el Desarrollo de
Software: Teoría y Práctica. Ayacucho, Perú: Ami Ayacucho.
18. Pressman, R. (2005). Ingeniería del Software: Un Enfoque Practico (5° Ed),
McGraw Hill.
19. Rodríguez Cruz, (2008): La gestión de información y la inteligencia: integración
en los contextos organizacionales.
20. Rosenberg, D y Stephens, M. (2005). Agile Development with ICONIX Process:
People, Process, and Pragmatism (1ra. Ed.). Estados Unidos, Apress.
21. Rosenberg, D. y Sthephens, M. (2007). Casos de uso guiado por modelos de
objetos con UML. Estados Unidos: Board.
22. Salavert, A. (2003).Los protocolo en la redes de ordenadores. Barcelona, España:
UPC.
23. Sanchez, J. (2004). Principios sobre bases de datos relacionales (2° Ed),
California, Stanford: Creative Commons.
24. Sanchez, J. (2004). Principios sobre bases de datos relacionales (2° Ed),
California, Stanford: Creative Commons.
25. SGP/PCM, (2014) Metodología para la implementación de la gestión por procesos
en las entidades de la administración pública.
26. Sommerville, L. (2005). Ingeniería de Software (2° Ed), Editorial CoopyBook.
27. Stair, R. y Reynolds, G. (2014). Principles of information systems. (12º Ed.).
Boston, USA: Cengage Learning.
28. Tanenbaum, A. (2003). Redes de Computadoras (4ta Ed.). Atlacomulco, México,
Pearson Educación
29. Teniente, E., Ramon, A, Mayol, E. y Gómez, C. (2003). Diseño de sistemas
software en UML. Barcelona: Ediciones UPC.
30. Tomayo, A. (2000). Sistemas de Información (1° Ed) Editorial McGraw Hill.
31. Winblad, A., Edwards, S. y King, D. (2003). Software Orientado a Objetos (7°
Ed), Editorial Addison-wesley.
32. Yarelys Chávez Montejo (2009): Licenciada en Bibliotecología y Ciencias de la
Información.
102

Informe Practica Quichua

Cargado por

Copyright:

Formatos disponibles

Informe Practica Quichua

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe Practica Quichua

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“INFORME DE PRÁCTICAS PRE-PROFESIONALES”

Título : Aplicación web para la gestión de información del servicio técnico.

Entidad : Megacenter Perú SAC

Alumno : Quichua Poma, Grimaldo

Asesor : Msc. Ing. Porras Flores Efraín Elías.

A los docentes de mi escuela, quienes mi apoyaron, mi enseñaron y formaron parte de mi

A la Universidad Nacional de San Cristóbal de Huamanga, mi alma máter, por la

AGRADECIMIENTO ................................................................................................... iii

INTRODUCCIÓN ........................................................................................................ vii

OBJETIVOS DEL TRABAJO

1.1. OBJETIVO GENERAL ..................................................................................... 1

1.2. OBJETIVOS ESPECÍFICOS ............................................................................. 1

2.1. GESTIÓN DE INFORMACIÓN ....................................................................... 2

2.2. TIEMPO DE ESPERA DEL CLIENTE ............................................................ 2

2.3. PROCESO .......................................................................................................... 2

2.4. CALIDAD DE SERVICIO ................................................................................ 3

2.5. SISTEMA DE INFORMACIÓN ....................................................................... 4

2.5.1. ACTIVIDADES DE UN SISTEMA DE INFORMACIÓN ............................... 4

2.6. APLICACIÓN WEB .......................................................................................... 5

2.6.1. VENTAJAS DE UNA APLICACIÓN WEB ..................................................... 6

2.7. INGENIERÍA DE SOFTWARE ........................................................................ 7

2.7.1. MODELOS DEL PROCESO DE SOFTWARE ................................................ 8

2.7.2. CICLO DE VIDA DE UN SOFTWARE ........................................................... 9

2.8. METODOLOGÍA ICONIX ............................................................................. 12

2.8.1. CARACTERÍSTICAS DE ICONIX ................................................................ 13

2.8.2. FACES DE ICONIX ........................................................................................ 14

2.10. LENGUAJE DE PROGRAMACIÓN ORIENTADO A OBJETOS ............... 24

2.11. TECNOLOGÍAS DE INTERNET ................................................................... 26

3.1. DESARROLLO DEL PROYECTO ................................................................ 28

3.1.1. MODELADO CONCEPTUAL ........................................................................ 28

3.1.2. ANÁLISIS DE REQUERIMIENTOS .............................................................. 28

3.1.3. MODELO DE CASO DE USO ........................................................................ 34

3.1.4. REVISIÓN DE REQUISITOS ......................................................................... 50

3.1.5. DISEÑO PRELIMINAR .................................................................................. 64

3.1.6. REVISIÓN DEL DISEÑO PRELIMINAR ...................................................... 70

3.1.7. ARQUITECTURA TÉCNICA ......................................................................... 77

3.1.9. IMPLEMENTACIÓN ...................................................................................... 87

3.2. RECOMENDACIONES ................................................................................ 100

BIBLIOGRAFÍA ........................................................................................................ 101

La práctica pre-profesional se realizó en el área de Sistemas de la empresa

En capítulo I presenta el objetivo general y objetivos específicos del proyecto.

En capitulo II presenta el marco teórico, gestión de información, sistemas de información,

En capítulo III presenta el desarrollo de la metodología Iconix, para el desarrollo del

El cuarto capítulo presenta las conclusiones y recomendaciones sobre la experiencia del

Según Cruz (2008), Gestión de la información es la denominación convencional de un

El área de servicio técnico es el responsable de todo el proceso de soporte técnico, donde

Los objetivos específicos son: a) Analizar, diseñar, implementar y probar la gestión de

1.1. OBJETIVO GENERAL

1.2. OBJETIVOS ESPECÍFICOS

Gestión de la información (GI) es la denominación convencional de un conjunto de

2.2. TIEMPO DE ESPERA DEL CLIENTE

2.4. CALIDAD DE SERVICIO

SISTEMA DE GESTIÓN DE INFORMACIÓN DE SERVICIO TÉCNICO

El sistema de gestión de información le permite gestionar eficientemente los órdenes de

2.5. SISTEMA DE INFORMACIÓN

2.5.1. ACTIVIDADES DE UN SISTEMA DE INFORMACIÓN

Para Tomayo (2000), “El procesamiento de información permite la transformación de