Proyecto Sistema de Mesa de Ayuda

CURSO : SISTEMAS DE INFORMACION II
DOCENTE : Ing. Mirko Manrique Ronceros
ALUMNOS :  Ramirez Cava, Shanira Lisset

 Jaico Advincula, José Rodolfo
 Sandoval Ramirez, Jennifer
PROYECTO :
CONSTRUCCION DE UN SISTEMA HELP DESK
NUEVO CHIMBOTE - PERÚ

2018
CompuNegocios S.A.C, 2019 Pág. 1

METODOLOGÍA RUP
FASE DE INICIO
I. DESCRIPCIÓN
1. Tópico Analizado
Desarrollo e implementación de un Sistema de información “Help Desk” para la

empresa CompuSol
2. Problema planteado
La falta de un sistema Help Desk en la empresa CompuNegocios para la gestión

de servicios técnicos trae como consecuencia los siguientes problemas:
 El proceso de registro de incidencias o reclamos es manualmente a sus clientes

toma mucho tiempo y es propensa a errores. Además, se tiene que llenar los
datos del cliente cada vez que se le emite un nuevo reclamo.
 La empresa es propensa a sufrir de pérdidas de información de las incidencias

que presentan sus clientes ante cualquier evento inesperado como incendios o
desastres naturales.
 Los tiempos de respuestas para solución de una incidencia no son los

adecuados y el seguimiento que quisiera el cliente no está implementado, en
todo caso el cliente si quisiera saber cómo va su producto tendría que ir
directamente a la tienda.

II DOCUMENTO VISIÓN
Visión
2.1. Introducción
Las organizaciones dependen cada vez más de las tecnologías de información para alcanzar
sus objetivos corporativos y en este documento presentamos la empresa CompuNegocio
SAC que se dedica a las ventas de portátiles, como también de accesorios de computadoras
de marcas reconocidas como Lenovo y HP no es la excepción pues también requiere un
sistema de información para incrementar sus ventas y tengan cada vez más clientes
satisfechos.
Debido a la gran abundancia de información disponible a usuarios de internet, una de las
necesidades que surgen es la de proveer a usuario de medios de manejar de manera más
efectiva el gran volumen, dinamismo y complejidad de la información. La información
tiene que ser inteligente en un Sistema web donde permita realizar consultas, lo cual es el
primer contacto con el cliente. Actualmente la empresa CompuNegocios SAC no cuenta
con este sistema de información, es decir un sistema web que le permita llegar
satisfactoriamente al cliente y poner el servicio técnico o incidencias o consultas que desea
realizar.
 2.1.1 Propósito
El propósito fundamental de este documento es de captar y analizar los requerimientos y
funcionalidades de la empresa CompuNegocios SAC el cual va a permitir que los clientes
puedan realizar consultas, incidencias o servicio técnico vía web logrando así un mayor
grado de satisfacción de los mismos.
 2.1.2 Alcance
El presente documento visión recoge las características del sistema web de la empresa
CompuNegocios SAC que se dedica a la venta de accesorios de computadoras (portátiles,
laptops, etc.) con diferentes marcas reconocidas; se encarga de lograr que los clientes
realicen consultas, incidencias o servicio técnico vía web.

 2.1.3 Definiciones, Acrónimos, y Abreviaciones
RUP: Son las siglas de Rational Unified Process. Se trata de una metodología para describir
el proceso de desarrollo de software.
SAC: Sociedad anónima cerrada. Es aquella sociedad mercantil cuyos titulares lo son en
virtud de una participación en el capital social a través de títulos o acciones.

 2.1.4 Referencias
- Glosario.
- Plan de desarrollo de software.
- RUP (Rational Unified Process).
- Diagrama de casos de uso.
2.2. Posicionamiento
2.2.1 Oportunidad de Negocio
El presente sistema Web fue planeado para gestionar las incidencias de cualquier tipo que
se le presente al cliente en los dispositivos informáticos o maquinas computacionales
compradas llevando el seguimiento del mismo hasta su la solución, además de brindar
información inteligente ante la desorientación común que tienen los clientes con tantos
medios de búsquedas que hay en el internet, a través de esto CompuNegocios SAC elevará
la calidad de servicio, soporte y atención que le brinda a sus clientes. Además, los datos de
las incidencias estarán siempre actualizados, lo cual es un factor muy importante para poder
llevar el control de las incidencias, es así como CompuNegocios SAC podrá ponerse a la
vanguardia en el uso de las tecnologías de información aplicadas al entorno web como lo
hacen otras tiendas de computo.
 2.2.2 Sentencia que define el problema
Problema Comunicación entre el cliente y la empresa y tiempo de respuesta

al cliente.
Afecta Toda la empresa y clientes.
Impacto La molestia del cliente al no recibir respuesta inmediatamente.
Implementar un sistema Web permitiría que los clientes puedan

Una solución realizar consultas o reclamos y la empresa pueda hacer un
seguimiento adecuado.

 2.2.3 Sentencia que define la posición del Producto
Para CompuNegocios SAC
Son los involucrados en el entorno del problema:

Quienes
administrador, clientes y personal técnico.
Es un sistema web se intuitivo y fácil de usar por el usuario

Esta solución
para registra las incidencias del cliente con algún producto.
Gestiona el control de incidencias y permite hacer el

Tal que
seguimiento a las incidencias
El sistema actual que no cuenta con un servicio de atención
A diferencia de al cliente que le pueda brindar el seguimiento de las

incidencias.
Permite escuchar los problemas que tienen los clientes,

interpretarlos con la mayor brevedad y dar una solución
mediante una interfaz gráfica sencilla y amigable. Además
Nuestro producto
proporciona un acceso rápido y actualizado a la
información desde cualquier punto que tenga acceso a la
base de datos.
2.3. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios
Stakeholders:
 Administrador (Dueño)
Usuarios:
 Vendedores
 Técnicos
 Clientes

 2.3.1 Resumen de Stakeholders
Nombre Descripción Responsabilidades
Franklin García Dueño y administrador El stakeholder realiza:
Rosas de la empresa. Representa a todos los usuarios
posibles del sistema.
Seguimiento del desarrollo del

proyecto.
Aprueba requisitos y funcionalidades.
 2.3.2 Resumen de Usuarios
Nombre Descripción Stakeholder
Vendedores Se encarga de la atención a los Franklin García Rosas

clientes efectuar las ventas.
Técnicos Su función es de solucionar Franklin García Rosas
problemas técnicos en los
productos con alguna falla o
realizar servicios informáticos.
Nombre Descripción Stakeholder
Clientes (varios) Lleva a cabo la realización de Franklin García Rosas

compras de algún producto o
requerimientos de servicios
informáticos.
 2.3.3 Entorno de usuario

- Computadora:
Especificaciones:
Procesador: Intel Dual Core 2.3 GHz
RAM: 4 Gb DDR3
Disco Duro: 500 Gb
Placa Madre: Intel Desktop DG41RQ
SO: Windows 7 Ultimate
- Router: Proveedor: Telefónica
- Cable de red: UTP Cat. 5
- Browser: Google Chrome.
 2.4 Perfil de los Stakeholders
2.4.1 Representante legal de la Empresa.
Representante Franklin García Rosas.
Descripción Representante Global de la Empresa “CompuNegocios SAC”.
Tipo Dueño y Administrador.
Responsabilidad Encargado de mostrar las necesidades los requerimientos concernientes

es
al sistema. Además, lleva a cabo un seguimiento del desarrollo del
proyecto y aprobación de los requisitos y funcionalidades del sistema.
Criterio de Mejor control de incidencias.

Éxito
Menor consumo de recursos humanos.
Grado de Revisión de requerimientos.
participación
Comentarios Ninguno
 2.5 Perfiles de Usuario

2.5.1 Vendedores
Representante
Descripción Vendedor de la empresa.
Tipo Vendedor
Responsabilidad Atención de los clientes y registro de las ventas o servicio.

es
Cobro del costo por las ventas y/o servicio.
Criterio de Menos tiempo en brindar ayuda a los clientes.

Éxito
Grado de Comunicación del manejo del negocio desde el punto de vista de sus
participación funciones.
Comentarios Ninguno

2.5.2 Técnicos
Representante
Descripción Técnico de la empresa.
Tipo Técnico
Responsabilidad Efectuar el servicio técnico solicitado.

es
Criterio de Menos tiempo en brindar ayuda a los clientes.
Éxito
Grado de Comunicación del manejo del negocio desde el punto de vista de sus
participación funciones.
Comentarios Ninguno
2.5.4 Cliente
Representante
Descripción Cualquier cliente de la empresa.
Realiza la presentación de las incidencias mediante el sistema web.
Tipo Entidad Externa.
Responsabilidad Realizar el pago por el servicio.

es Realizar la presentación de sus consultas y/o requerimientos y/o
reclamos.
Criterio de Rapidez en presentar sus requerimientos.
Éxito Accesibilidad de consultar por la/s incidencia/s presentada/s.
Grado de Ninguna
participación
Comentarios Ninguna

 Descripción Global del Producto
 2.6.1 Perspectiva del producto
El producto a desarrollar es una aplicación web en línea para llevar el seguimiento de los
reclamos o dudas que tenga el cliente acerca de un producto, tratándole de ofrecer la
soluciona más rápida posible.
 2.6.2 Resumen de características
A continuación, se mostrará un listado con los beneficios que obtendrá el cliente a partir
del producto:
Beneficio del cliente Características que lo apoyan
Accesibilidad El usuario encontrará una interfaz
amigable y de fácil uso que le permitirá
realizar el registro de las incidencias del
cliente.
Alarma de avisos. El usuario encontrara una pequeña alarma
en la parte superior del sistema web que
indique que debe llamar al cliente para ver
si ya le han solucionado el problema.
Orden y registro de la información de los El servicio web mantiene la información
reclamos. en una base de datos.
Evitar pérdida de información de las Respaldo de la información de las
incidencias. incidencias en la BD ubicada en el
Hosting.
Rápida adaptación a los Configurable al contexto donde
se desarrolla.
cambios
 2.6.3 Suposiciones y dependencias
Intensión de actualización del sistema web.
Se asume que cada computadora personal involucrada, donde se quiera acceder a la
aplicación web, deberá contar con el servicio de internet para poder acceder al servidor
de aplicaciones. Esto con el objetivo de que cada usuario pueda acceder a la información
que requiera, y le permita registrar, modificar y generar sus incidencias dentro de la
aplicación.
 2.6.4 Costo y precio

Costo: Pago a los desarrolladores: S/.3000.00
Hosting: S/. 150.00 (anual)
Precio: Precio final del proyecto desarrollado: S/. 6000.00

III Plan de Desarrollo del Software
 Introducción
Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la propuesta
elaborada como respuesta al proyecto de prácticas de la asignatura de Sistemas de Información II de la
Facultad de Informática de la Universidad Nacional del Santa. Este documento provee una visión global del
enfoque de desarrollo propuesto.
El proyecto ha sido ofertado por un grupo de estudiantes de la misma escuela, basado en una metodología de
Rational Unified Process en la que únicamente se procederá a cumplir con las tres primeras fases que marca
la metodología, constando únicamente en la tercera fase de dos iteraciones. Es importante destacar esto puesto
que utilizaremos la terminología RUP en este documento. Se incluirá el detalle para las fases de Inicio y
Elaboración y adicionalmente se esbozarán las fases posteriores de Construcción y Transición para dar una
visión global de todo proceso.
El enfoque desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las
características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los
artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP.
3.1.1 Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para controlar el
proyecto. En él se describe el enfoque de desarrollo del software.
Los usuarios del Plan de Desarrollo del Software son:
 El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y para realizar su
seguimiento.
 Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer, cuándo deben
hacerlo y qué otras actividades dependen de ello.
3.1.2 Alcance
El Plan de Desarrollo de Software describe el plan global usado para el desarrollo del Sistema de Mesa de
Ayuda para la empresa CompuNegocios SAC. El detalle de las iteraciones individuales se describe en los
planes de cada iteración, documentos que se aportan en forma separada. Durante el proceso de desarrollo en
el artefacto “Visión” se definen las características del producto a desarrollar, lo cual constituye la base para
la planificación de las iteraciones. Para la versión 0.9 del Plan de Desarrollo de Software, nos hemos basado
en la captura de requisitos por medio del asesor del proyecto, el Ing. Mirko Manrique Ronceros, y en las
ideas y propuestas hechas por los integrantes del equipo de desarrollo; una vez comenzado el proyecto y
durante la fase de inicio se genera la primera versión del artefacto “Visión”, el cual se utilizará para refinar
este documento. Posteriormente, el avance del proyecto y el seguimiento de cada una de las iteraciones
ocasionarán el ajuste de este documento produciendo nuevas versiones actualizadas.
3.1.3 Resumen
Después de esta introducción, el resto del documento está organizado en las siguientes secciones:
Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del proyecto,
estableciendo los artefactos que serán producidos y utilizados durante el proyecto.
Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo.
Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del proyecto y
describe cómo se realizará su seguimiento.

Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de software,
incluyendo métodos, herramientas y técnicas que serán utilizadas.
 Vista General del Proyecto

3.1.4 Propósito, Alcance y Objetivos
La información que a continuación se incluye ha sido extraída de las diferentes reuniones que se han
celebrado con el asesor del proyecto desde el inicio del mismo, Ing. Mirko Manrique Ronceros; y de las ideas
y propuestas formuladas por los integrantes del equipo de desarrollo.
La empresa CompuNegocios S.A.C. se dedica a la venta de componentes de computadoras y brinda servicios
de soporte técnico buscando satisfacer las necesidades de sus clientes.
Según la información recogida, se concluye que es necesario atender las incidencias que se presenten en la
empresa, que los clientes obtengan respuestas en un tiempo prudente y asimismo hacer posible que la empresa
lleve un seguimiento de las incidencias. Todo ello puede ser implementado utilizando las nuevas tecnologías
de información como es la tecnología web que permite el desarrollo de Sistemas Web proporcionando de
esta manera un servicio de ayuda a los cuales el cliente podrá acceder de forma fácil y segura y, además, el
administrador podrá interactuar con los clientes mediante este medio.
El sistema se ocupará de los siguientes aspectos:
 Información general de la empresa
o La organización de la empresa
o Perfil de los empleados
o Políticas de la empresa
 Servicios
o Descarga de manuales y tutoriales relacionados a los productos y/o servicios.
o Un centro de notificaciones para cada cliente.
3.1.5 Suposiciones y Restricciones

Las suposiciones y restricciones respecto al sistema, y que se derivan directamente de las entrevistas con el
asesor del proyecto son:
A. Las incidencias presentadas por los clientes se almacenarán en un buzón que solamente el
administrador podrá acceder, responder y llevar un seguimiento de ello.
B. La información o las respuestas será propio para cada cliente.
C. Los clientes solo tendrán acceso a sus propias cuentas.
Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del proyecto,
particularmente conforme evolucione el artefacto “Visión”.
3.1.6 Entregables del proyecto
A continuación, se indican y describen cada uno de los artefactos que serán generados y utilizados por el
proyecto y que constituyen los entregables. Esta lista constituye la configuración de RUP desde la perspectiva
de artefactos, y que proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos
los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término
del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. Sin embargo, el resultado

de cada iteración y los hitos del proyecto están enfocados a conseguir un cierto grado de completitud y
estabilidad de los artefactos. Esto será indicado más adelante cuando se presenten los objetivos de cada
iteración.
1) Plan de Desarrollo del Software

Es el presente documento.
2) Visión
Este documento define la visión del producto desde la perspectiva del cliente, especificando las
necesidades y características del producto. Constituye una base de acuerdo en cuanto a los requisitos del
sistema.
3) Glosario
Es un documento que define los principales términos usados en el proyecto. Permite establecer una
terminología consensuada.
4) Modelo de Casos de Uso

El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se
representa mediante Diagramas de Casos de Uso.
5) Especificaciones de Casos de Uso

Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple
descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento, donde se
incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También,
para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante
un Diagrama de Actividad.
6) Especificaciones Adicionales
Este documento capturará todos los requisitos que no han sido incluidos como parte de los casos de uso
y se refieren requisitos no-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas,
aplicación de estándares, requisitos de calidad del producto, tales como: confiabilidad, desempeño, etc., u
otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc.
7) Prototipos de Interfaces de Usuario

Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que
proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los requisitos del sistema. Estos
prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna herramienta gráfica o prototipos
ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo
serán entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este artefacto, será
desechado en la fase de Construcción en la medida que el resultado de las iteraciones vaya desarrollando el
producto final.
8) Modelo de Análisis y Diseño

Este modelo establece la realización de los casos de uso en clases y pasando desde una representación
en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño (incluyendo una
orientación hacia el entorno de implementación), de acuerdo al avance del proyecto.
9) Modelo de Datos
Previendo que la persistencia de la información del sistema será soportada por una base de datos
relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo con el enfoque
para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se
utiliza un profile UML para Modelado de Datos, para conseguir la representación de tablas, claves, etc.).
10) Modelo de Implementación

Este modelo es una colección de componentes y los subsistemas que los contienen. Estos componentes
incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de ficheros necesarios para la
implantación y despliegue del sistema. (Este modelo es sólo una versión preliminar al final de la fase de
Elaboración, posteriormente tiene bastante refinamiento).
11) Modelo de Despliegue

Este modelo muestra el despliegue la configuración de tipos de nodos del sistema, en los cuales se hará
el despliegue de los componentes.
12) Casos de Prueba

Cada prueba es especificada mediante un documento que establece las condiciones de ejecución, las
entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de
regresión en cada iteración. Cada caso de prueba llevará asociado un procedimiento de prueba con las
instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podrá ser
automatizable mediante un script de prueba.
13) Solicitud de Cambio

Los cambios propuestos para los artefactos se formalizan mediante este documento. Mediante este
documento se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los
requisitos del producto. Así se provee un registro de decisiones de cambios, de su evaluación e impacto, y se
asegura que éstos sean conocidos por el equipo de desarrollo. Los cambios se establecen respecto de la última
baseline (el estado del conjunto de los artefactos en un momento determinado del proyecto) establecida. En
nuestro caso al final de cada iteración se establecerá una baseline.
14) Plan de Iteración

Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos asignados, dependencias
entre ellas. Se realiza para cada iteración, y para todas las fases.
15) Evaluación de Iteración

Este documento incluye le evaluación de los resultados de cada iteración, el grado en el cual se han
conseguido los objetivos de la iteración, las lecciones aprendidas y los cambios a ser realizados.
16) Lista de Riesgos

Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden
decreciente de importancia y con acciones específicas de contingencia o para su mitigación.
17) Manual de Instalación

Este documento incluye las instrucciones para realizar la instalación del producto.
18) Material de Apoyo al Usuario Final

Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guías del
Usuario, Guías de Operación, Guías de Mantenimiento y Sistema de Ayuda en Línea
19) Producto
Los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos apropiados para
facilitar su instalación. El producto, a partir de la primera iteración de la fase de Construcción es desarrollado
incremental e iterativamente, obteniéndose una nueva release al final de cada iteración.
3.1.7 Evolución del Plan de Desarrollo del Software

El Plan de Desarrollo del Software se revisará semanalmente y se refinará antes del comienzo de cada
iteración.
 Organización del Proyecto
3.1.8 Participantes en el Proyecto
El personal del proyecto ha sido escogido considerando las cuatro fases de RUP, estará formado por los
siguientes puestos de trabajo, los 4 alumnos del VI ciclo de la carrera de Ingeniería de Sistemas e
Informática en la Facultad de Ingeniería de la Universidad Nacional del Santa como parte del curso de
Sistema de Información II:
Jefe de Proyecto.
El alumno Jaico Advincula Jose Rodolfo.es el responsable del cargo en mención, con
conocimientos en el Diseño y Evaluación de Proyectos, Elaboración de Análisis FODA, Elaboración
de diagramas GANTT, Desarrollador de aplicaciones Cliente/Servidor, incentivando el liderazgo
para el trabajo en equipo.
Analista de Sistemas.
La persona encargada de realizar el rol de analista de sistemas debe ser aquel estudiante de ingeniería
de sistemas que tenga conocimientos básicos de UML, principalmente conocer y tener experiencia
en cuanto a el desarrollo de la metodología RUP, que tenga un buen desempeño en cuanto a gestión
de sistemas se trate y mantenga una buena organización de todos los documentos redactados en el
transcurso del desarrollo del proyecto, ésta labor será llevada a cabo por la alumna Ramirez Cava
Shanira.
Analistas - Programadores.
El rol de programador será compartido por todos los integrantes del equipo de desarrollo, todos ellos
con conocimiento, dominio en la utilización de la tecnología a utilizar.
Cabe destacar que, más allá de tener responsables definidos para cada rol, todos los integrantes del
equipo de desarrollo apoyarán en la realización de la labor de cada responsable.
Ingeniero de Software.
Rol desempeñado por la alumna Ramirez Sandoval Jennifer, con conocimientos y experiencia en
modelado y documentación de sistemas con UML y dominio de herramientas CASE para la gestión
de requisitos y modelado de sistemas, como Rational Rose.
3.1.9 Interfaces Externas
El asesor del proyecto, el Mg. Ing. Mirko Manrique Ronceros proporcionará algunos de los requisitos del
sistema y será el encargado de evaluar los artefactos que presentaremos cada semana y según el plan
establecido.
El equipo de desarrollo interactuará activamente con el asesor del proyecto para la especificación y validación
de los artefactos generados.
3.1.10 Roles y Responsabilidades
A continuación, se describen las principales responsabilidades de cada uno de los puestos en el equipo de
desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP.
Puesto Responsabilidad
El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina
las interacciones con los clientes y usuarios, y mantiene al equipo del
proyecto enfocado en los objetivos. El jefe de proyecto también establece
Jefe de Proyecto
un conjunto de prácticas que aseguran la integridad y calidad de los
artefactos del proyecto. Además, el jefe de proyecto se encargará de la
gestión de riesgos. Planificación y control del proyecto.

Captura, especificación y validación de requisitos, interactuando con el
cliente y los usuarios de CompuNegocio SAC mediante entrevistas.
Analista de Sistemas
Elaboración del Modelo de Análisis y Diseño. Colaboración en la
elaboración de las pruebas funcionales.
Construcción de prototipos. Colaboración en la elaboración de las
Programador
pruebas funcionales, modelo de datos y en las validaciones con el usuario.
Gestión de requisitos, gestión de configuración y cambios, elaboración

Ingeniero de Software del modelo de datos, preparación de las pruebas funcionales, elaboración
de la documentación. Elaborar modelos de implementación y despliegue.
 Gestión del Proceso

3.1.11 Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado.
3.1.12 Plan del Proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.
3.1.12.1 Plan de las Fases
El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas. La siguiente tabla
muestra una la distribución de tiempos y el número de iteraciones de cada fase (para las fases de Construcción y
Transición es sólo una aproximación muy preliminar)
Nro.
Fase Duración
Iteraciones
Fase de Inicio 1 2 SEMANAS
Fase de Elaboración 1 4 SEMANAS
Fase de Construcción 1 8 SEMANAS
Fase de Transición 1 2 SEMANAS

Los hitos que marcan el final de cada fase se describen en la siguiente tabla.
Descripción Hito
Fase de Inicio En esta fase desarrollarán los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el artefacto
Visión. Los principales casos de uso serán identificados y se hará un
refinamiento del Plan de Desarrollo del Proyecto. La aceptación del
cliente /usuario del artefacto Visión y el Plan de Desarrollo marcan el
final de esta fase.
Fase de En esta fase se analizan los requisitos y se desarrolla un prototipo de

Elaboración arquitectura (incluyendo las partes más relevantes y / o críticas del
sistema). Al final de esta fase, todos los casos de uso correspondientes
a requisitos que serán implementados en la primera release de la fase de
Construcción deben estar analizados y diseñados (en el Modelo de
Análisis / Diseño). La revisión y aceptación del prototipo de la
arquitectura del sistema marca el final de esta fase. En nuestro caso
particular, por no incluirse las fases siguientes, la revisión y entrega de
todos los artefactos hasta este punto de desarrollo también se incluye
como hito. La primera iteración tendrá como objetivo la identificación
y especificación de los principales casos de uso, así como su realización
preliminar en el Modelo de Análisis / Diseño, también permitirá hacer
una revisión general del estado de los artefactos hasta este punto y
ajustar si es necesario la planificación para asegurar el cumplimiento de
los objetivos. Ambas iteraciones tendrán una duración de una semana.

Fase de Durante la fase de construcción se terminan de analizar y diseñar
Construcción todos los casos de uso, refinando el Modelo de Análisis / Diseño. El
producto se construye en base a 2 iteraciones, cada una produciendo
una release a la cual se le aplican las pruebas y se valida con el cliente
/ usuario. Se comienza la elaboración de material de apoyo al usuario.
El hito que marca el fin de esta fase es la versión de la release 2.0,
con la capacidad operacional parcial del producto que se haya
considerado como crítica, lista para ser entregada a los usuarios para
pruebas beta.
Fase de En esta fase se prepararán dos releases para distribución, asegurando

Transición una implantación y cambio del sistema previo de manera adecuada,
incluyendo el entrenamiento de los usuarios. El hito que marca el fin
de esta fase incluye, la entrega de toda la documentación del proyecto
con los manuales de instalación y todo el material de apoyo al
usuario, la finalización del entrenamiento de los usuarios y el
empaquetamiento del producto.
3.1.12.2 Calendario del Proyecto

A continuación, se presenta un calendario de las principales tareas del proyecto incluyendo sólo las fases de Inicio
y Elaboración. Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la
realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los
artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de
acuerdo a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque, en ella lo ensombrecido marca
el énfasis de cada disciplina (workflow) en un momento determinado del desarrollo.

Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica cuándo el artefacto en
cuestión tiene un estado de completitud suficiente para someterse a revisión y aprobación, pero esto no quita la
posibilidad de su posterior refinamiento y cambios.
Disciplinas / Artefactos generados o modificados

Comienzo Aprobación
durante la Fase de Inicio
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de
Objetos del Negocio
Requisitos
Glosario Semana 05 Semana 06
Visión Semana 05 Semana 06
Modelo de Casos de Uso Semana 05 siguiente fase
Especificación de Casos de Uso Semana 05 siguiente fase
Especificaciones Adicionales Semana 06 siguiente fase
Análisis/Diseño
Modelo de Análisis/Diseño Semana 07 siguiente fase
Modelo de Datos Semana 07 siguiente fase
Implementación
Prototipos de Interfaces de Usuario Semana 08 siguiente fase
Modelo de Implementación Semana 08 siguiente fase
Pruebas
Casos de Pruebas Funcionales Semana 10 siguiente fase
Despliegue
Modelo de Despliegue Semana 10 siguiente fase
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 1.0 y
Semana 06 Semana 07
planes de las Iteraciones
Ambiente Durante todo el proyecto

Disciplinas / Artefactos
generados o modificados durante la Comienzo Aprobación
Fase de Elaboración
aprobado
Objetos del Negocio
Requisitos
Glosario Semana 06 aprobado
Visión Semana 06 aprobado
Modelo de Casos de Uso Semana 06 Semana 10
Especificación de Casos de Uso Semana 06 Semana 10
Especificaciones Adicionales Semana 06 Semana 10
Análisis / Diseño
Revisar en cada
Modelo de Análisis / Diseño Semana 07
iteración
Revisar en cada
Modelo de Datos Semana 07
iteración
Implementación
Revisar en cada
Prototipos de Interfaces de Usuario Semana 08
iteración
Revisar en cada
Modelo de Implementación Semana 08
iteración
Pruebas
Revisar en cada
Casos de Pruebas Funcionales Semana 10
iteración
Despliegue
Revisar en cada
Modelo de Despliegue Semana 10
iteración
Semana 09 Semana 10

Disciplinas / Artefactos
generados o modificados durante la Comienzo Aprobación
Fase de Construcción
aprobado
Objetos del Negocio
Requisitos
Glosario Semana 06 aprobado
Visión Semana 06 aprobado
Modelo de Casos de Uso Semana 06 aprobado
Especificación de Casos de Uso Semana 06 aprobado
Especificaciones Adicionales Semana 06 aprobado
Análisis / Diseño
Modelo de Análisis / Diseño Semana 07 Semana 11
Modelo de Datos Semana 07 Semana 11
Implementación
Prototipos de Interfaces de Usuario Semana 08 Semana 12
Modelo de Implementación Semana 08 Semana 12
Pruebas
Casos de Pruebas Funcionales Semana 10 Semana 13
Despliegue
Modelo de Despliegue Semana 10 Semana 13
Semana 12 Semana 13

 Seguimiento y Control del Proyecto
Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión. Cada requisito tendrá una serie
de atributos tales como importancia, estado, iteración donde se implementa, etc. Estos atributos
permitirán realizar un efectivo seguimiento de cada requisito.
Control de Calidad
El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto, por
el asesor del proyecto y por el resto de los integrantes del equipo de desarrollo. Gestión de Riesgos
Gestión de Configuración
Los defectos detectados en las revisiones y formalizados también en una Solicitud de Cambio
tendrán un seguimiento para asegurar la conformidad respecto de la solución de dichas deficiencias.
Para la revisión de cada artefacto y su correspondiente garantía de calidad se utilizarán las guías de
revisión y checklist (listas de verificación) incluidas en RUP.
Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las
acciones establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista será
evaluada al menos una vez en cada iteración.
Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de los artefactos generados y sus
versiones. También se incluirá la gestión de las Solicitudes de Cambio y de las modificaciones que
éstas produzcan, informando y publicando dichos cambios para que sean accesibles a todos los
participantes en el proyecto. Al final de cada iteración se establecerá una un registro de estado

IV. MODELO DEL NEGOCIO
1. Modelado del análisis del negocio
4.1. Descripción del sistema actual
“CompuSol” es una empresa Chimbotana creada el 18 de mayo de 2003, realiza trabajos de ventas
al por menor y mayor en computadoras, impresoras, laptops, notebooks, monitores, servidores,
periféricos, accesorios, software y la especializada zona gamer, además mantenimiento,
reparación e instalación, también cuentan con una amplia variedad de accesorios, piezas y
equipos de cómputo de alta gama.
La empresa cuenta actualmente con una computadora en donde se tiene información como
proformas, de las ventas, lista de clientes y lista de proveedores en archivos de Word y Excel de
esta forma tiene un controla de la parte administrativa.
Pero Actualmente la empresa no cuenta con un sistema “Help Desk” para gestionar la
información de las incidencias o reclamos que realizan los clientes ante un problema con los
equipos. Por lo tanto, se tienen los siguientes problemas:
El proceso de registro de incidencias o reclamos es manualmente a sus clientes toma

mucho tiempo y es propensa a errores. Además, se tiene que llenar los datos del cliente
cada vez que se le emite un nuevo reclamo.
La empresa es propensa a sufrir de pérdidas de información de las incidencias que

presentan sus clientes ante cualquier evento inesperado como incendios o desastres
naturales.
Los tiempos de respuestas para solución de una incidencia no son los adecuados y el
seguimiento que quisiera el cliente no está implementado, en todo caso el cliente si
quisiera saber cómo va su producto tendría que ir directamente a la tienda.
4.2. Identificación de procesos
A partir de la entrevista realizada al cliente y de los documentos y formatos proporcionados

por este, se obtuvo la descripción de los procesos del sistema actual:
 El cliente para realizar alguna compra de componentes de computadora se apersona
directamente a la tienda en donde efectúa la compra.
 Asimismo, en caso de algún reclamo o incidencia a presentar se trata directamente
en la misma tienda siendo atendido por la Asistenta de Soporte.
 La Asistenta de Soporte analiza la incidencia presentada por el cliente y si es necesario
lo deriva al Área de soporte técnico o se realiza el cambio del producto defectuoso si
fuese el caso.
 Las incidencias presentadas se registran físicamente y se lleva el seguimiento de
manera manual.
 Una vez solucionado la incidencia el cliente firma en el registro de incidencia
correspondiente que queda en la empresa.

 El cliente para obtener información del seguimiento de la incidencia presentada puede
hacerlo únicamente en la tienda en donde se buscará la ficha que contiene su nombre y
todos los detalles del registro de la incidencia.
4.3. Visión y Misión
MISION:
Consolidarnos y posicionarnos como la mejor empresa del Perú en prestación de servicios
técnicos en equipos de cómputo portátil, como también en la venta de productos tecnológicos de
alta calidad, con total garantía, mediante una excelente atención personalizada con calidad,
eficiencia y eficacia buscando la satisfacción del cliente a través de soluciones efectivas.
Consolidarnos y posicionarnos como la mejor empresa del Perú en

prestación de servicios técnicos en equipos de cómputo portátil, como
también en la venta de productos tecnológicos de alta calidad, con total
garantía, mediante una excelente atención personalizada con calidad,
eficiencia y eficacia buscando la satisfacción del cliente a través de
soluciones efectivas.
Misión
VISION:
La visión de esta empresa es ser la primera opción de los clientes actuales y futuros,
satisfaciendo sus necesidades y requerimientos. Además, ser reconocida en el ámbito nacional,
por la calidad de sus servicios, atención, y mantenerse líder de competitividad en el mercado de
la computación, brindando servicios de Mantenimiento de Computo asistiendo personalmente en
el menor tiempo posible a satisfacer las necesidades del cliente, dándole así atención
personalizada y una supervisión constante de sus equipos.
La visión de esta empresa es ser la primera opción de los clientes

actuales y futuros, satisfaciendo sus necesidades y requerimientos.
Además, ser reconocida en el ámbito nacional, por la calidad de sus
servicios, atención, y mantenerse líder de competitividad en el
mercado de la computación, brindando servicios de Mantenimiento
de Computo asistiendo personalmente en el menor tiempo posible a
satisfacer las necesidades del cliente.
Misión

4.4. Reglas del negocio:
 Las devoluciones a COMPUSOL para trámite de garantía deben de ser dentro del tiempo que
cubre la Garantía.
 En productos de Software no hay garantía ni devoluciones. En caso software defectuoso puede

ser devuelto para reemplazo del mismo artículo.
 Para el registro y aceptación del reclamo del producto debe ser con la boleta de compra.
 El vendedor no podrá proceder a solucionar algún incidente sin consultar al administrador.
 Todos los productos que se reciben para garantía deben de estar en su empaque original.
Cualquier discrepancia puede resultar en demora concerniente a su garantía. Si el producto no
es devuelto a COMPUSOL con todo su empaque original se devolverá el artículo a usted. Si
parte de un producto se encuentra defectuoso, todo el artículo debe ser devuelto para su
reembolso o reemplazo.
 Sólo serán válidas garantías por defectos del fabricante, NO POR DAÑO FÍSICO (llámese daño
físico a productos quebrados, rayados, quemados, con circuitos quemados, sellos de garantía
violados o con piezas sueltas). Notas: Aquellos productos que presenten daño físico o que
presenten el (los) sellos de garantía propios del fabricante violado(s), automáticamente pierden su
garantía.
 En caso de que su pedido llegue con daño físico por parte del COURIER, y/o con algún faltante,
solamente se hará valido el cambio si el cliente lo reporta dentro de las próximas 24hrs. de haber
recepcionado el paquete.
 Deberá anexar una carta explicando el problema del producto enviado a garantía, no se procederá
a su revisión si no se incluye dicho documento y esto demoraría el tiempo de respuesta.
 En el caso de que el producto ya lo haya descontinuado el fabricante o se encuentre agotado, se

entregará uno de las mismas características o similares como reemplazo. Dichos reemplazos
continúan con la misma garantía del producto original.
 En caso de que el producto presentado a garantía mostrara un buen funcionamiento se cobrará

un cargo de 20.00 soles por diagnóstico del equipo.
 Los días máximo de espera para la solución de una incidencia es de 5 a 30 días hábiles al
registro del reclamo.
 Desde la compra de un equipo de gama media usted recibe un descuento del 7%.
 Por la compra varias unidades de computo se le hace un descuento de hasta 15% dependiendo
de la marca a compra.

4.5. Objetivos del Negocio
 Aumentar la satisfacción de los clientes

 Incrementar la rentabilidad
 Mejorar la gestión de incidencias registradas
 Solucionar las incidencias en un menor tiempo

4.6. Modelado de casos de uso de análisis de negocio

4.6. Objetos del negocio

4.7 Diagrama de actividad del negocio (Áreas: Reclamos).
4.8 Localización
La empresa se localiza en la dirección Jirón Ladislao Espinar 429, Chimbote en el distrito de
Chimbote

4.9. Modelado del organigrama
Administrador
Franklin García Rosas
Vendedor
Maciel Brenda Mendez
Tecnico Tecnico Tecnico

Hugo Joel Sanchez Pedro Gabriel Rodriguez Andres Barrionuevo

REQUERIMIENTO DEL SISTEMA
CONOCIMIENTO DE LOS REQUERIMIENTOS
REQUERIMIENTOS FUNCIONALES
Identificación RF01
del
requerimiento:
Nombre del Verificación de Usuario.

Requerimiento:
Características:Los usuarios deberán identificarse para acceder al sistema, mediante

una ventana con campos de texto para el usuario y la contraseña.
Descripción del El sistema deberá contar con un sistema de usuarios con acceso
requerimiento: restringido a cierta información según el tipo de usuario.
Requerimiento
NO funcional:
Prioridad del requerimiento:

Alta
del
requerimiento:
Nombre del Registro de Cliente.

Requerimiento:
Características:Los clientes deberán hacer una comprar para poder generar una cuenta
a su nombre.
Descripción del El sistema deberá contar con un formulario donde podrá llenarse los
requerimiento: datos del cliente y el DNI del mismo será la clave para poder identificar
si ya tiene una cuenta.
Requerimiento
NO funcional:

Alta

del
requerimiento:
Nombre del Registro de Personal.

Requerimiento:
Características:El personal podrá registrarse en el sistema solo a través del

administrador que estará en cargado de llenar el formulario del
personal con todos los datos que haya de él
Descripción del El sistema deberá contar con un formulario donde podrá llenarse los
requerimiento: datos del personal y además tener acceso a la Base de datos para el
registro respectivo.
Requerimiento
NO funcional:

Alta
del
requerimiento:
Nombre del Incidencias Terminadas

Requerimiento:
Características:El técnico encargado después de solucionar dicha incidencia da el cierre

y pone a la incidencia como solucionada.
Descripción del El sistema deberá contar con una opción para que se pueda dar por
requerimiento: finalizado la incidencia sin en caso tuvo solución o no.
Requerimiento
NO funcional:

Alta

del
requerimiento:
Nombre del Incidencias nuevas

Requerimiento:
Características: El cliente registra sus incidencias.
Descripción del El sistema deberá contar con un formulario donde el cliente podrá
requerimiento: registrar su incidencia con todos los detalles posibles.
Requerimiento
NO funcional:

Alta
del
requerimiento:
Nombre del Incidencias Pendientes
Requerimiento:
Características:El jefe técnico pone en estado pendiente las incidencias aun no

atendidas.
Descripción del El sistema deberá contar una opción dentro de la lista de estados que
requerimiento: le permita poner una incidencia pendiente.
Requerimiento
NO funcional:

Alta

del
requerimiento:
Nombre del Reporte Incidencias
Requerimiento:
Características:El administrador visualiza los reportes que se generan durante el

periodo de un mes.
Descripción del El sistema deberá contar con reportes estadísticos gráficos acerca de
requerimiento: cómo se está llevando las incidencias.
Requerimiento
NO funcional:

Alta
Identificación del RF08

requerimiento:
Nombre del Consultar Clientes.
Requerimiento:
Características: El sistema contará con una ventana en la que el usuario podrá
ingresar el DNI o nombre del cliente y se le mostrará toda la
información del cliente mediante campos de texto o tablas
según el tipo de dato.
Descripción del Permite obtener información general y de contacto de los
requerimiento: clientes: Nombre del cliente o razón social, DNI, dirección; así
como los datos de la persona de contacto: nombre, número de
teléfono y correo electrónico.
Requerimiento NO
funcional:
Alta

REQUERIMIENTOS NO FUNCIONALES
Identificación del RNF01

requerimiento:
Nombre del Requerimiento: Interfaz del sistema.
Características: El sistema presentara una interfaz de usuario
sencilla para que sea de fácil manejo a los usuarios
del sistema.
Descripción del Al iniciar la aplicación del sistema, se deberá contar
requerimiento: con accesos directos a tareas y consultas que se
pueden realizar como: registro de incidencias,
consultas de incidencias. Etc.
Alta

requerimiento:
Nombre del Requerimiento: Desempeño
Características: El sistema garantizará a los usuarios un buen
desempeño en cuanto a la consulta de los datos
almacenados en él.
Descripción del Garantizar el desempeño del sistema informático a
requerimiento: los diferentes usuarios. En este sentido la
información almacenada o registros realizados
podrán ser consultados y actualizados permanente
y simultáneamente, sin que se afecte el tiempo de
respuesta.
Alta

requerimiento:
Nombre del Requerimiento: Requerimientos de Compatibilidad
Características: El sistema deberá de ser compatible con diferentes
versiones de Windows, desde Windows 7 hasta el
actual.
Descripción del El sistema debe disponer de la capacidad de ser
requerimiento: instalado en un ordenador con sistema operativo
Windows.
Alta

requerimiento:
Nombre del Requerimiento: Plataforma de Desarrollo
Características: El sistema deberá ser programado en PHP 7.2.4
Descripción del El sistema debe ser desarrollado en el lenguaje de
requerimiento: programación PHP 7.2.4 haciendo uso de un ID
orientado a ello como PHP Storm.
Alta

requerimiento:
Nombre del Requerimiento: Motor de Base de datos
Características: El sistema deberá ser desarrollado con el motor de
base de datos MySql 5.7.21
Descripción del El sistema debe utilizar el motor de base de datos
requerimiento: MySql 5.7.21 sin presentar errores.
Alta

requerimiento:
Nombre del Requerimiento: BK de seguridad de la Base de Datos
Características: El sistema deberá realizar el backup de la base de
datos.
Descripción del El sistema debe realizar el backup cada cierto
requerimiento: periodo de la base de datos por motivo de
seguridad.
Alta
ENCONTRANDO ACTORES Y CASOS DE USO

Actores:
 Administrador
 Cliente
 Soporte Técnico
 Vendedor

Administrador Vendedores
(f rom Casos de Uso del Negocio)
Clientes
Jefe de Sistemas
Técnicos Usuario
Actor Descripción
Administrador, encargado de gestionar las tablas del
sistema, registrar personal, además de monitorear las
incidencias registradas por los clientes, es la máxima
autoridad dentro del departamento de sistemas y es quien
dirige y controla el proceso de brindar soporte a las
Administrador
incidencias presentadas por el usuario.
Persona que registra a los clientes con los respectivos

productos que compró.
Vendedores
Son todas las personas que han comprado algún producto

o han recibido servicio técnico, y que al registrar su
incidencia deberán hacer uso del sistema así como
Clientes también poder hacer un seguimiento de cada incidencia
que ingresó al sistema.
Es la persona que trabaja en el área de sistemas y que está
en capacidad de dar soporte técnico a los usuarios, para
Técnicos
lo que empleará el sistema.

Casos de Uso
Caso de Uso Descripción Nuevo
CU - 01 Acceder al Sistema SI
CU - 02 Registrar Cliente NO
CU - 03 Gestionar Personal NO
CU - 04 Asignar incidencias NO
CU - 05 Evaluar incidencias NO
CU - 06 Resolver incidencias NO
CU - 07 Registrar incidencias NO
CU - 08 Hacer seguimiento a las incidencias SI
CU - 09 Consultar incidencias SI
CU - 10 Generar reportes de incidencias SI

DIAGRAMAS DE CASOS DE USO
Diagrama de caso de Uso General del Sistema
Resolver incidencia:
Asigna Tecnico
Incidencia Cerrada
Técnicos
(f rom Actores del Sistema)
Jefe del Sistema

Administrador Incidencia en desarrollo
Actualiza estado de la incidencia (f rom Actores del Sistema)
Nueva incidencia

Gestión Personal:
Contratacion de Personal
Actualiza Informacion Personal

Administrador
Despido de Personal
Registro incidencias
Envia Incidencia
Clientes
Modifica incidencia

Registrar cliente
Registrar Cliente
Modificar Cliente
Vendedores
...)
<<include>>
Buscar Cliente
Generar reportes de incidencias
Reportes Graficos
Reporte por barras
Administrador
Reportes Circular

Evaluación de sistema
Recibe incidencia
Jefe de sistema
Administrador
Asignar incidencia
Registrar Cliente
Caso de Uso: Registrar Cliente
Tipo de Caso de Uso: Primario
Actores: Vendedor
Propósito: Registrar a los clientes
Resumen: El vendedor registra los clientes que realizan una venta.
Acciones normales de los eventos
Acción del vendedor Respuesta del Sistema
1. Activa función de REGISTRAR CLIENTE.
2.Muestra pantalla de REGISTRO DE CLIENTE.
3.Ingresa datos de Cliente 4.Comprueba si el cliente fue registrado.
5. Muestra mensaje con respecto a la búsqueda del
cliente.
5. Comprueba si todos los campos fueron llenados.
6. Muestra mensaje con respecto al llenado de
datos.
7. Registra Cliente.
8.El sistema confirma el registro del cliente y
guarda
Decisión Alterna
Línea 3:Si no se desea registrar se cancela caso de uso.

Registrar Incidencia
Caso de Uso: Registrar Incidencia
Actores: Cliente
Propósito: Registrar una incidencia del producto comprado.
Resumen: El cliente registra la incidencia de un producto vendido por la empresa.
Acciones de los Actores Respuesta del Sistema
1. El usuario selecciona la opción de Registrar
Incidencia
2.Muestra la pantalla de Registro de Incidencia
3.El cliente llena la información acerca de
Incidencia
4. Verifica si los datos ingresados son
correctos
5. Comprueba si todos los campos fueron
llenados.

datos.
7.Registra incidencia.
8. El sistema confirma registro de incidencia y

guarda.
Decisión Alterna
Línea 3: Al ser un movimiento ya existente, el usuario puede modificar los datos generales
REGISTRO DE PERSONAL
Caso de Uso: Registrar personal
Actores: Administrador
Propósito: Registrar a los personal
Resumen: El administrador registra los personales que realizan una venta.
Acción del administrador Respuesta del Sistema
1. Activa función de REGISTRAR PERSONAL.
2.Muestra pantalla de REGISTRO DE PERSONAL.
3.Ingresa datos de Personal 4.Comprueba si el personal fue registrado.
5. Muestra mensaje con respecto a la búsqueda del
personal.
5. Comprueba si todos los campos fueron llenados.
datos.
7. Registra Personal.
8.El sistema confirma el registro del personal y
guarda

Acceder al sistema
Caso de Uso: Acceder al sistema
Actores: Gerente, Secretaria, Técnico
Propósito: Describe el proceso para validar un usuario para tener acceso al sistema
Resumen: El usuario accede al sistema mediante su usuario y contraseña
1. Activa la función LOGIN. 2.Muestra pantalla de LOGIN.
3 Ingresa Usuario. 4.Valida caracteres.
5. Comprueba si el usuario existe.
6. Muestra mensaje con respecto a la búsqueda de

usuario.
7.Ingreso de Contraseña 8.Valida Caracteres.
9.Comprueba si la contraseña es correcta.
10. Muestra mensaje con respecto a la comparación

de la contraseña.
11. Valida Usuario 12.El sistema confirma el registro (guardar datos).
Decisión Alterna
Línea 3:
Si no se encuentra el usuario, se le permite hacer solicitud de registro
Línea 4:
El usuario posee 3 intentos para ingresar, pasados estos, muestra el mensaje intentar más tarde y
se cierra el sistema
Actualiza estado de la incidencia

Caso de Uso: Actualiza estado de la incidencia
Actores: Técnico
Propósito: Describe el proceso de como el técnico actualiza la información de un equipo.
Resumen: El técnico describe la situación actual de la incidencia y si es posible envía foto de la situación.
Acciones del actor Respuesta del Sistema
1. Ingresa al formulario de la Incidencia. 2.Muestra por pantalla el FORMULARIO DE
INCIDENCIA.
3 Ingresa los nuevo datos 4.Valida caracteres.
5. Muestra mensaje de confirmación.
6.Acepta y da click a SI 7.- El sistema confirma el registro (guardar datos).

Decisión Alterna
Línea 4:
En caso que algunos caracteres no estén permitidos no se podrá acceder.
Incidencias Cerradas
Caso de Uso: Incidencias Cerradas
Actores: Jefe de sistema
Propósito: Describe el proceso de como el jefe de sistema toma una decisión acerca de la solución de una
incidencia.
Resumen: El jefe de sistema recibe el diagnóstico del técnico acerca de la incidencia que se le encargo para
que pueda tomar una decisión de dar finalizada la incidencia como solucionada o si necesita otra revisión.
Acciones del actor Respuesta del Sistema
1. Ingresa al formulario ‘Incidencia en solución’. 2.Muestra por pantalla el formulario “Incidencia en
solución”.
3 Ingresa a la notificación de uno de sus técnicos
4.-Lee el diagnóstico del técnico
5.-Da por cerrado y solucionado la incidencia.
6. Muestra mensaje de confirmación si desea cerrar

la incidencia.
8.Acepta y da click a SI 8.- El sistema confirma y guarda la incidencia en un
estado de cerrado(solucionado).
Decisión Alterna
Modificar Incidencia:
Caso de Uso: Modifica la incidencia
Actores: Cliente
Propósito: El cliente podre modificar la información de su incidencia.
Resumen: El cliente podrá agregar o cambiar alguna información acerca de la información de su
incidencia siempre y cuando este incidencia aun no sea revisada.
1. El usuario ingresa a su formulario de
incidencia
2.Muestra en pantalla el formulario de
Incidencia
3.El cliente modifica la información acerca de
Incidencia ya registrada
4. Verifica si los datos ingresados son
correctos
5. Comprueba si todos los campos fueron
llenados.

6. Muestra mensaje de confirmacion con
respecto al llenado de datos.
7.Da click a SI.
8. El sistema confirma registro de incidencia y

guarda.
Decisión Alterna
DESPIDO DE PERSONAL
Caso de Uso: Despido personal
Actores: Administrador
Propósito: Maneja el despido de personal
Resumen: El administrador despide a un personal técnico y su estado en la base de datos cambiado de 1 a
0 para evitar eliminar información del personal.
Acción del administrador Respuesta del Sistema
1. EL administrador ingresa a lista del personal
técnico.
2.-Buscar al técnico a despedir.
3.-Click en la fila del técnico.
4.Muestra por pantalla los datos del técnico
escogido.
5.-Va a la parte inferior y Click en el botón 6.-Muestra un mensaje de confirmación para la
“Despedir” acción a realizar.
7.-Click en SI 8.- El sistema confirma el registro del personal y lo
elimina de la lista.
9.-En la base de datos cambia el estado de 1 a 0
10.-Muestra un mensaje con la confirmación de que
se ha realizado correctamente.
Decisión Alterna
Asignación de Técnico
Caso de Uso: Asignación de Técnico
Actores: Jefe de sistema
Propósito: Maneja la asignación de un técnico para la solución de la incidencia
Resumen: El administrador lee las incidencias enviadas por el cliente y decide a que personal técnico será
encargado de solucionar dicha incidencia.
Acción del Actor Respuesta del Sistema
1. El administrador va la parte inferior del
formulario de incidencia y da click en el botón “Ver
incidencias”
2.-Muestra una lista con los técnicos disponibles.
3.-Click en la fila del técnico escogido para 4.-Muestra un mensaje de confirmación para la
encargarse de esa incidencia . acción a realizar.
5.-Click en SI 6.- El sistema confirma la acción del Administrador.
7.-Se asigna a la incidencia al personal técnico
8.-Se registra en la base de datos la asignación
9.-Muestra un mensaje con la confirmación de que
se ha realizado correctamente.
Decisión Alterna
Seguimiento de la incidencia
Caso de Uso: Seguimiento de la incidencia

Actores: Cliente
Propósito: El cliente hace el seguimiento a su incendia.
Resumen: El cliente podrá a través de la aplicación llevar un seguimiento de su producto viendo el reporte
que le entrega el técnico encargado de su incidencia.
Acción del Actor Respuesta del Sistema
1. Cliente se va a la opción de menú “Seguimiento
de incidencia”
6.-Muestra una interfaz con la información acerca
de su incidencia hasta ahora.
7.-Digita alguna sugerencia
8.-Sale de la aplicación
Decisión Alterna

ANÁLISIS DEL SISTEMA
DIAGRAMA DE COLABORACIÓN
Registrar Incidencias
Acceder al Sistema

DIAGRAMA DE SECUENCIA
Registrar incidencia

Acceder al Sistema

DISEÑO DEL SISTEMA
DIAGRAMA DE ESTADO
Registrar incidencia
Acceder al Sistema

DIAGRAMA DE ACTIVIDAD
Registrar Incidencia

Acceder al Sistema
Hacer seguimiento de incidencias registradas

DIAGRAMA DE COMPONENTES
Interfaz Interfaz Interfaz Interfaz Jefe Interfaz

Cliente Técnico Vendedor Sistemas Admin
Main - Template
Gentelella
SISMA /routes/web.php
Librerias
PHP
MySQL
Laravel
Data Base

DIAGRAMA DE DESPLIEGUE

 Referencias
 Kimmel, P. (2010). Manual de UML. México: McGraw-Hill Interamericana.
Tomado
de http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?docID
=10433806
 Campderrich, F. B. (2003). Ingeniería del software. España: Editorial
UOC.Tomado
=10646149
 Gutierrez, C. C. (2011). Casos prácticos de UML. España: Editorial
Complutense. Tomado
=10536104

Proyecto Sistema de Mesa de Ayuda

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proyecto Sistema de Mesa de Ayuda

Uploaded by

Copyright:

Available Formats

CURSO : SISTEMAS DE INFORMACION II

DOCENTE : Ing. Mirko Manrique Ronceros

ALUMNOS :  Ramirez Cava, Shanira Lisset

CONSTRUCCION DE UN SISTEMA HELP DESK

NUEVO CHIMBOTE - PERÚ

CompuNegocios S.A.C, 2019 Pág. 1

Desarrollo e implementación de un Sistema de información “Help Desk” para la

La falta de un sistema Help Desk en la empresa CompuNegocios para la gestión

 El proceso de registro de incidencias o reclamos es manualmente a sus clientes

 La empresa es propensa a sufrir de pérdidas de información de las incidencias

 Los tiempos de respuestas para solución de una incidencia no son los

CompuNegocios S.A.C, 2019 Pág. 3

CompuNegocios S.A.C, 2019 Pág. 4

 2.2.2 Sentencia que define el problema

Problema Comunicación entre el cliente y la empresa y tiempo de respuesta

Afecta Toda la empresa y clientes.

Impacto La molestia del cliente al no recibir respuesta inmediatamente.

Implementar un sistema Web permitiría que los clientes puedan

CompuNegocios S.A.C, 2019 Pág. 5

Son los involucrados en el entorno del problema:

Es un sistema web se intuitivo y fácil de usar por el usuario

Gestiona el control de incidencias y permite hacer el

El sistema actual que no cuenta con un servicio de atención

A diferencia de al cliente que le pueda brindar el seguimiento de las

Permite escuchar los problemas que tienen los clientes,

2.3. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios

CompuNegocios S.A.C, 2019 Pág. 6

Seguimiento del desarrollo del

Aprueba requisitos y funcionalidades.

 2.3.2 Resumen de Usuarios

Nombre Descripción Stakeholder

Vendedores Se encarga de la atención a los Franklin García Rosas

Nombre Descripción Stakeholder

Clientes (varios) Lleva a cabo la realización de Franklin García Rosas

 2.3.3 Entorno de usuario

Representante Franklin García Rosas.

Descripción Representante Global de la Empresa “CompuNegocios SAC”.

Tipo Dueño y Administrador.

Responsabilidad Encargado de mostrar las necesidades los requerimientos concernientes

Criterio de Mejor control de incidencias.

 2.5 Perfiles de Usuario

Descripción Vendedor de la empresa.

Responsabilidad Atención de los clientes y registro de las ventas o servicio.

Criterio de Menos tiempo en brindar ayuda a los clientes.

CompuNegocios S.A.C, 2019 Pág. 8

Descripción Técnico de la empresa.

Responsabilidad Efectuar el servicio técnico solicitado.

Descripción Cualquier cliente de la empresa.

Realiza la presentación de las incidencias mediante el sistema web.

Tipo Entidad Externa.

Responsabilidad Realizar el pago por el servicio.

CompuNegocios S.A.C, 2019 Pág. 9

 2.6.4 Costo y precio

CompuNegocios S.A.C, 2019 Pág. 10

CompuNegocios S.A.C, 2019 Pág. 11

 Vista General del Proyecto

3.1.5 Suposiciones y Restricciones

CompuNegocios S.A.C, 2019 Pág. 12

1) Plan de Desarrollo del Software

4) Modelo de Casos de Uso

5) Especificaciones de Casos de Uso

7) Prototipos de Interfaces de Usuario

8) Modelo de Análisis y Diseño