UNIVERSIDAD TECNOLOGICA DEL PERU

FACULTAD DE INGENIERIA DE SISTEMAS Y ELECTRONICA

Proyecto:

DISEÑO DE UN SISTEMA DE ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN PARA

LA EMPRESA DERRAMA MAGISTERIAL

Presentado por:

Berly Jaqquehua Cano

Cesar Junior Gamio Sánchez

Asesor:

Dr. Papa Quiroz, Erik Alex

Lima – Perú

2013
Tabla de contenido
ESCRIBIR EL TÍTULO DEL CAPÍTULO (NIVEL 1) 1

ESCRIBIR EL TÍTULO DEL CAPÍTULO (NIVEL 2) 2

Escribir el título del capítulo (nivel 3) 3

ESCRIBIR EL TÍTULO DEL CAPÍTULO (NIVEL 1) 4

HFHFGHFGHGFHGFHFGHFHGF 5
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
HHFGHGF 6
CAPITULO 3: METODOLOGIA, ANALISIS Y DISEÑO

3.1. METODOLOGIA

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas
metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte
tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del
proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben
producir, las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser
efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en
otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más
artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el
resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia
habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras
dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las
metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al
desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su
efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están
revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus
seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las
metodologías tradicionales.

3.1.1. EVALUACION DE METODOLOGIAS AGILES

Para el presente proyecto se realizó la evaluación de 6 metodologías desarrolladas en el capítulo

anterior:

 SCRUM
 Crystal Methodologies
 Dynamic Systems Development Method (DSDM)
 Adaptive Software Development (ASD)
 Feature-Driven Development (FDD)
 Lean Development (LD)
 La Tabla 10, compara las distintas aproximaciones ágiles en base a tres parámetros: vista del sistema como
algo cambiante, tener en cuenta la colaboración entre los miembros del equipo y características más
específicas de la propia metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc.
También incorpora como referencia no ágil el Capability Madurity Model (CMM).

CM DSD
ASD Crystal FDD LD Scrum XP
M M

Sistema como algo 1 5 4 3 3 4 5 5

cambiante

Colaboración 2 5 5 4 4 4 5 5

Características Metodología (CMM)

 Resultados 2 5 5 4 4 4 5 5

 Simplicidad 1 4 4 3 5 3 5 5

 Adaptabilidad 2 5 5 3 3 4 4 3

 Excelencia técnica 4 3 3 4 4 4 3 4

 Prácticas de 2 5 5 4 3 3 4 5
colaboración

Media CM 2.2 4.4 4.4 3.6 3.8 3.6 4.2 4.4

Media Total 1.7 4.8 4.5 3.6 3.6 3.9 4.7 4.8

Tabla 10. Ranking de “agilidad” (Los valores más altos representan una mayor agilid ad)
Fig. 10: Comparación conceptual de Metodologías Agiles
Una vez obtenida la puntuación decidimos elegir las dos metodologías con más alto ratio dando
como ganadores al Scrum como metodología de Gestión del proyecto y XP como metodología de
desarrollo del Sistema de Administración de Inventarios – ATI.

3.1.2. METODOLOGIAS SELECCIONADAS

3.1.2.1. APLICACION DE LA METODOLOGIA DE GESTION - SCRUM

Fig. 11: Proceso de la Metodología Scrum

I. PERSONAS

El facilitador (Scrum Master)

FUNCION: El gestor de proyecto pasa a ser un facilitador que vela por que se cumpla el proceso de
Scrum, quita impedimentos, protege al equipo y facilita las reuniones para que tanto el equipo como
el cliente colaboren y se obtengan las máximas sinergias.

El buen gestor de un equipo ágil

El buen gestor confía en su equipo y lo potencia; ayuda a que avance, promueve la comunicación y
la confianza entre el equipo y con el cliente; tolera errores y no busca culpables, sino mejorar el
proceso de trabajo; practica con el ejemplo.

El cliente (Product Owner)

Es el representante de todos los interesados en el proyecto, con autoridad para tomar decisiones.
Define los objetivos del producto o proyecto y dirige los resultados del proyecto maximizando su
ROI, para lo cual participa en las reuniones de planificación de iteración y de demostración.

El equipo (Team)
Desarrolla el producto y tiene un objetivo común, dado que adquiere un compromiso en cada
iteración. Es un equipo autoorganizado y multidisciplinar, idealmente de entre 5 y 9 personas a
tiempo completo, en una misma localización física y trabajando en un único proyecto.

Potenciación del equipo

El equipo selecciona los objetivos/requisitos que se compromete a desarrollar en cada iteración.
Se autogestiona para identificar tareas, estimar esfuerzos y autoasignarse tareas. Al finalizar cada
iteración demuestra los objetivos completados y analiza las mejoras a realizar en su modo de
trabajar.

Skills en un equipo ágil

Los skills en un equipo ágil se pueden agrupar según estén relacionados con la orientación a
producir valor para el receptor final del producto, con la capacidad de trabajar en equipo o con la
capacidad de mejorar.

Colaboración y comunicación entre el equipo y con el cliente

El equipo participa con el cliente en la creación de la lista de objetivos/requisitos priorizada del
producto o proyecto, proporciona la estimación de su esfuerzo y pregunta al cliente los detalles en la
reunión de planificación de la iteración.
II. PROCESO REALIZADO

A) FASE I : PLANIFICACION DE LA ITERACION

Este fue el primer día donde se llevó a cabo la primera reunión con los interesados del
proyecto – DERRAMA MAGISTERIAL, realizamos la división en dos partes:

i. SELECCIÓN DE REQUISITOS

Derrama Magisterial realizo la presentación la lista de requisitos priorizadas del

producto. El equipo de desarrollo realizamos las preguntas las dudas que surgieron
y seleccionamos los requisitos más prioritarios a realizar en la iteración, de modos
que cuando el cliente interno lo solicite pueda ser entregado.

DURACION: 4 horas

ii. PLANIFICACION DE ITERACION

El equipo realizo la elaboración de la lista de tareas de la iteración necesarias para

desarrollar los requisitos a los cuales nos comprometimos en la primera parte. La
estimación de esfuerzos se realizó de manera conjunta.

DURACION: 4 horas
CLIENTES INTERNOS

# Tipo de Unidad Unidad / Descripción

1 Alta Dirección Consejo de Vigilancia

2 Directorio

3 Gerencia General

4 Gerencia Administrativa

5 Unidad de Línea Equipo de Previsión Social

6 Equipo de Crédito Social

7 Equipo de Cobranzas

8 Equipo de Caja-Bóveda

9 Equipo de Administración de OFIDES

10 OFIDES

11 Unidad de Negocio Equipo de Administración Central de

Hoteles y Afines
# Tipo de Unidad Unidad / Descripción

12 Bazar del Maestro

13 Equipo Comercialización de
Inmobiliaria

14 Unidad de Apoyo Equipo de Administración de

Personal

15 Equipo de Contabilidad

16 Equipo de Logística y Servicios

Generales

17 Equipo de Sistemas
B) FASE II : EJECUCION DE LA ITERACION

El equipo a cargo del proyecto estaba obligado a realizar la reunión de sincronización en

donde cada miembro del equipo del trabajo inspeccionaba el trabajo del resto que está
realizando como (dependencias entre tareas, progreso hacia el objetivo de la iteración,
obstáculos que pueden impedir este objetivo), todo esto se realizaba a fin de poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido .En la reunión
cada miembro del equipo responde a tres preguntas:

i. ¿Qué he hecho desde la última reunión de sincronización?

ii. ¿Qué voy a hacer a partir de este momento?
iii. ¿Qué impedimentos tengo o voy a tener?

Durante cada iteración el facilitador realizo todas las facilidades para poder cumplir con el
compromiso.

Realizo la protección de interrupciones externas que puedan afectar al compromiso o

nuestra productividad.

DURACION: 15 minutos
Perspectiva Pe
Pe

Perspectiva FINANCIERA

F1. Implementar una metodología de Análisis Costo/Beneficio en los proyectos de Tecnologías de la

Información.
 Perspectiva CLIENTE

C1. Mejorar la atención de los requerimientos informáticos.

C2. Mejorar el sistema informático empresarial.

C3. Elaborar planes de capacitación en el uso de los productos y servicios de T.I.

C4. Propiciar una cultura de seguridad de la Información.

Perspectiva INTERNA

I1. Mejorar la organización y planeación (estratégica, táctica y operativa).

I2. Mejorar la plataforma de base de datos, redes y comunicaciones.

I3. Desarrollar y mejorar los procesos, metodologías, estándares y uso de herramientas de T.I.

I4. Implementar la seguridad informática.

C) FASE III: INSPECCION Y ADAPTACION

El último día de la primera iteración se realizó una reunión de revisión de la iteración, las
cuales dividimos en dos partes:

i. DEMOSTRACION

El equipo realizo la presentación al cliente los requisitos completados en la

iteración. En función a los resultados mostrados y de los cambios que haya
habido en el contexto del proyecto, el cliente realizo las adaptaciones necesarias
de manera objetiva, desde la primera iteración, replanificando el proyecto.

DURACION: 4 horas
ii. RETROSPECTIVA

El equipo realizo como ha sido la manera en que han realizado el trabajo y

cuales han sido los problemas que podrían impedir progresar adecuadamente,
tratando de mejorar de manera continua nuestra productividad.

DURACION: 4 horas
Fig. 12: Proceso de la Metodología Scrum
 3.1.2.2. APLICACIÓN METODOLOGIA DE DESARROLLO (XP - eXtreme Programming)

 Comenzamos con las reuniones del personal de atención de ventanillas aproximadamente 2

semanas para recaudar historias, registrarlas pero más que nada comprenderlas, posteriormente se
empezó a realizar la codificación de pruebas en NUnit para la plataforma .NET. El éxito de las
pruebas se debe al trabajó en pareja con la codificación y la simplicidad, escatimando esfuerzos,
incluso reautorizándolo.

 Una vez terminado las reuniones aunque eso no quiere decir que ya acabaron las participaciones de
los usuarios, solo después de tener ya definidas las historias de usuario es necesario crear un plan
de publicaciones, donde se indiquen las historias de usuario que se crearán para cada versión del
programa y las fechas en las que se publicarán estas versiones. Un "plan de publicaciones es una
planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales
de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán
implementadas en cada versión del programa. Tienen que estar claros estos cuatro factores: los
objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en
cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el
número de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo
realizado.

 Generalmente se tiene que dividir en iteraciones de aproximadamente 3 semanas de duración. Al

comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas
anteriormente pero las que serán implementadas. También se seleccionan las historias de usuario
que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas historias
de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los
programadores.

 Particularmente, es sencillo estimar la velocidad del proyecto, eso sí, basta con contar el número de
historias de usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Con dicha velocidad podemos
controlar todas las tareas que se puedan desarrollar en el tiempo del que dispone la iteración.
Adicionalmente es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no
es adecuada, solo entonces hay que negociar con el cliente un nuevo para definir las historias para
la codificación.

 El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno
codifica haciendo hincapié en la calidad de la función o método que está implementando, el otro
analiza si ese método o función es adecuado y está bien diseñado. De esta forma se consigue un
código y diseño con gran calidad. Naturalmente, es necesario que los desarrolladores se reúnan
diariamente y expongan sus problemas, soluciones e ideas de forma conjunta.
  Las reuniones tienen que ser fluidas y esto es precisamente un complemente necesario y semejante
conjuntamente con la metodología SCRUM. Todo el mundo tiene que tener voz y voto.
Posteriormente, hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo
menos complicado posible para conseguir un diseño fácilmente entendible e implementable que a la
larga costará menos tiempo y esfuerzo desarrollar. Usaremos glosarios de términos y una correcta
especificación de los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus
posteriores ampliaciones y la reutilización del código.

 No obstante pero constante, es mejor nunca añadir funcionalidad extra al programa aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el
desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos. Para optimizar usamos la
refactorización que es mejorar y modificar la estructura y codificación de códigos ya creados sin
alterar su funcionalidad. Ya que refactorizar supone revisar de nuevo estos códigos para procurar
optimizar su funcionamiento. Es muy común rehusar códigos ya creados que contienen
funcionalidades que no serán usadas y diseños obsoletos.

 Como ya se dijo anteriormente, el cliente es una parte más del equipo de desarrollo; su presencia es
indispensable en el proceso de la metodología XP puesto que a la hora de codificar una historia de
usuario su presencia es aún más necesaria. Solo los clientes son los que crean las historias de
usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada
historia de usuario, el cliente debe especificar detalladamente lo que ésta hará y también tendrá que
estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada. La codificación debe hacerse ateniendo a estándares de codificación ya
creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y
escalabilidad.

En esta metodología lo sobresaliente es el uso de pruebas para comprobar el funcionamiento de los códigos
que vayamos implementando. El uso de las pruebas en metodología XP es el siguiente:

 Se deben crear las aplicaciones que realizarán las pruebas con un entorno de desarrollo específico
para pruebas.
 Hay que someter a pruebas las distintas clases del sistema omitiendo los métodos más triviales.
 Se deben crear las pruebas que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes las pruebas que el código.
 Un punto importante es crear pruebas que no tengan ninguna dependencia del código que en un
futuro evaluará.
 Como se comentó anteriormente las distintas pruebas se deben subir al repositorio de código
acompañado del código que verifican.
 Prueba de aceptación. Las pruebas mencionadas anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario.

 Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán

pruebas que analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en la descripción de
requisitos. 

3.2. ANALISIS
Tanto el equipo de desarrollo como el cliente tienen un papel activo en la ingeniería   de requisitos:
un conjunto de actividades que son denominadas análisis. El cliente replanteo un sistema confuso, a
nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador
actuó como interrogador, como consultor, como persona que resuelve problemas y como
negociador.
Porque sabíamos que entender la necesidad del cliente era tener un gran porcentaje del proyecto
como exitoso. Nos organizamos de manera multidisciplinaria a fin de colaborar todos en sus campos
de especialidad. Así obteniendo una compenetración con el cliente haciendo participe en el proyecto
y así nosotros obtener mejor el conjunto de historia para priorizar y estimar tiempos.
 
Comenzamos estableciendo el tiempo mínimo de interactuación con el cliente:

DURACION: Medio día.

LUGAR: Sala de Gerencia.

3.2.1. MODELAMIENTO DE PROCESOS ACTUALES

Proceso: Reporte de Incidencia

Objetivo El usuario envía solicitud, observación.

Descripción El usuario envía informe de incidencia, indicando el problema

observado.
Subprocesos

Prioridad Primaria
 Tiempo de ejecución Siempre que sea necesario

Proceso: Revisión y diagnóstico.

Objetivo Diagnosticar situación.

Descripción

Subprocesos El analista de soporte al usuario realiza la revisión.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Realización de documentos de entrada

Objetivo Realizar la documentación obligatoria

Descripción

Subprocesos El analista de soporte al usuario realiza la documentación con el sistema

ATI que actualmente la derrama magisterial utiliza.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Realización de documentos de salida

Objetivo Realizar la documentación obligatoria

Descripción

Subprocesos El analista de soporte al usuario realiza la documentación con el sistema

ATI que actualmente la derrama magisterial utiliza.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Aprobación de documento

Objetivo Supervisor de plataforma y operaciones

Descripción

Subprocesos El supervisor del área emite su aprobación según el diagnóstico del

analista de soporte al usuario.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Aprobación de documento final

Objetivo Jefe de Sistemas

Descripción

Subprocesos El jefe de sistemas aprueba según la coherencia del documento.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Entrega de documento al encargado del área

Objetivo Analista de soporte al usuario

Descripción

Subprocesos El analista de soporte al usuario entrega documento

Aprobado por el área de sistemas.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Realización del requerimiento

Objetivo Encargado del área(secretaria)

 Descripción

Subprocesos El encargado del área realiza el requerimiento según diagnóstico del

analista de soporte al usuario.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

Proceso: Entrega a Servicios Generales

Objetivo Encargado del área(secretaria)

Descripción

Subprocesos El encargado del área entrega el requerimiento al área de Logística

quien se encarga de proveer al usuario.

Prioridad Primaria

Tiempo de ejecución Siempre que sea necesario

3.2.2. FUNCIONALIDAD

El módulo de Administración de Equipos de TI, apoya en llevar el control de todos los Activos Fijos
relacionados tecnologías de Información (Monitores, PCS, Teclados etc.).

3.2.2.1. DESCRIPCIÓN DE FUNCIONES DE NEGOCIOS

Aquí se describe las principales funciones que presenta el módulo.

# NOMBRE DE NEGOCIO NIVEL

[M]acroproceso, [P]roceso, [A]ctividad -> M P A

1 Registrar Equipos Nuevos X

Esta función permite registrar en detalle los equipos ingresados:
 Registra datos relevantes del equipo.
 Registra fecha y usuario que se realizo el registro.
 Registra partes del Equipo con nivel de detalle.
 Verifica y Actualizar datos del Equipo y sus Partes.

2 Registrar Ingreso de Equipos X

Esta función permite Registrar el ingreso de Equipos a Soporte
Técnico:
 Ingreso por Garantía
 Ingreso por Mantenimiento
 Ingreso por Inventario físico
 Ingreso por Registro de Equipo

3 Registrar Salida de Equipos X

Esta función permite Registrar la salida de Equipos de Soporte
Técnico.
 Salida por Garantía.
 Salida por Baja.
 Salida a Almacén.

X
4 Generar Informe de Equipos
Esta función permite registrar el incidente y problemas que
puedan tener los Equipos.

5 Mantenimiento X
Esta función permite mantener dar mantenimiento a las tablas
paramétricas del sistema.
MAPEO DE FUNCIONES DE NEGOCIO VS MENÚ

1 2 3

# FUNCION DE NEGOCIO # MENU

1 Registrar Equipos Nuevos 3, 8

2 Registrar Ingreso de Equipos 3

3 Registrar Salida de Equipos 3

4 Generar Informe de Equipos 7

5 Unificar Asociados 5

IDENTIFICACIÓN DE ACTORES
 # ACTOR

1 TÉCNICO
Es el responsable de registrar los equipos, generar informes y registrar entradas y
salidas de los equipos del Soporte Técnico.

2 SUPERVISOR
Es el encargado de dar mantenimiento a las tablas paramétricas, crear nuevos
usuarios y llevar el control de ingreso de los usuarios.

BW_Supervisor BW_Tecnico

LISTA DE CASOS DE USO

# CODIGO CASO DE USO DE SISTEMA

1 CU-01 Inventariar Equipos.

2 CU-02 Inventariar Parte.

3 CU-03 Detalle de Inventario.

4 CU-04 Registrar Entrada.

5 CU-05 Tipo Entrada.

6 CU-06 Registra Salida.

7 CU-07 Tipo Salida.

8 CU-08 Informe.
9 CU-09 Mantenimiento.

3.2.2.2. DESCRIPCIÓN DE CASOS DE USO

CASO DE USO: CU01 – INVENTARIAR EQUIPOS

SECCION DESCRIPCION

1 - DESCRIPCION CU01 – Inventariar Equipos

Este caso de uso permite registrar los atributos del equipo.

2 - PRE–  Usuario debe estar registrado por el supervisor.

CONDICION  El nombre de usuario y password deben ser válidos.

3 - FLUJO  1) Ingresar Equipo.

 2) Ingresar Atributos.
 3) Ingresar responsable de SSGG.
 4) Validar Series.

4 - POST-  Se genera una Guía de Entrada señalando que el equipo ya

CONDICION ingreso a Soporte Técnico.

6 - EXCEPCIONES  Si el equipo posee partes movibles, tienen que ser registradas

CASO DE USO: CU02 – INVENTARIAR PARTE

SECCION DESCRIPCION

1 - DESCRIPCION CU02 – Inventariar Parte

Este caso de uso permite registrar las partes de un equipo.

2 - PRE–  Se debe de a ver realizado el cu01 antes de poder realizar

CONDICION este caso

3 - FLUJO  1) Registrado el Equipo.

 2) Registro de los Atributos de la parte.
 3) Validación de Serie.

4 - POST-  Se registra el detalle de la Guía de Entrada del Equipo.

CONDICION

5 - EXCEPCIONES  Ninguna.
 SECCION DESCRIPCION

CASO DE USO: CU03 – DETALLE DE INVENTARIO

SECCION DESCRIPCION

1 - DESCRIPCION CU03 – Detalle de Inventario

Este caso de uso permite registrar la fecha en que fueron
realizados los registros, así como el responsable de ellos.

2 - PRE–  Ninguna.
CONDICION

3 - FLUJO  1) Registro de Equipo.

 2) Registra detalle de registro de equipo.
 3) Registro de Parte Equipo.
 4) Registro Detalle de Registro de Parte de Equipo.

4 - POST-  Ninguna.
CONDICION

5 - EXCEPCIONES  Ninguna.

CASO DE USO: CU04 – REGISTRAR ENTRADA

SECCION DESCRIPCION

1 - DESCRIPCION CU04 – Registrar Entrada

Este caso de uso permite registrar las Entradas que los Equipos
realizan a Soporte Técnico.

2 - PRE–  El equipo debe ser previamente registrado en el sistema.

CONDICION

3 - FLUJO  1) Equipo registrado.

 2) Se realiza Una Guía de Entrada.
 3) Se indica el motivo y El responsable de la entrega.
 4) Genera reporte de Ingreso.
 SECCION DESCRIPCION

 5) Actualiza el un Stock temporal.

4 - POST-  Se genera la salida del equipo.

CONDICION

5 - EXCEPCIONES  Ninguna.

CASO DE USO: CU05 – TIPO ENTRADA

SECCION DESCRIPCION

1 - DESCRIPCION CU05 – Tipo Entrada

Este caso de uso permite definir el tipo de Entrada que realiza el
equipo.

2 - PRE–  Realizar la entrada de un equipo.

CONDICION

3 - FLUJO  1) Realización de Entrada.

 2) Definición el tipo de Entrada.

4 - POST-  Ninguna.
CONDICION

5- EXCEPCIONES  Ninguna.

CASO DE USO: CU06 – REGISTRA SALIDA

SECCION DESCRIPCION

1 - DESCRIPCION CU06 – Registra Salida

Este caso de uso permite registrar la salida de Equipos de
Soporte Técnico.

2 - PRE–  El equipo se encuentra en Stock Temporal.

CONDICION

3 - FLUJO  1) Equipo en Stock temporal.

 2) Genera Guía de Salida.
 3) Define tipo de Salida.
 SECCION DESCRIPCION

 4) Genera reporte de Guía de Salida.

4 - POST-  Ninguna.
CONDICION

5 - EXCEPCIONES  Ninguna.

CASO DE USO: CU07 – TIPO SALIDA

SECCION DESCRIPCION

1 - DESCRIPCION CU07 – Tipo Salida

Este caso de uso permite definir el tipo de Salida que tiene el
Equipo.

2 - PRE–  Generación de la guía de Salida.

CONDICION

3 - FLUJO  1) Stock Temporal de Equipos.

 2) Salida de equipo de Stock Temporal de Soporte Técnico.
 3) Definición de Tipo de Salida. Tipo Salida.

4 - POST-  Ninguna.
CONDICION

5 - EXCEPCIONES  Ninguna.

CASO DE USO: CU08 – INFORME

SECCION DESCRIPCION

1 - DESCRIPCION CU08 – Informe

Este caso de uso permite registrar todos los Informes que se
realiza para un equipo por incidentes o problemas.

2 - PRE–  El equipo debe estar previamente Registrado.

CONDICION

3 - FLUJO  1) Registro de Equipo.

 2) Detección de falla o problema.
 3) Generación de Informe.
 SECCION DESCRIPCION

 4) Generación de Informe.

4 - POST-  Ninguna.
CONDICION

5 - EXCEPCIONES  Ninguna.

CASO DE USO: CU09 – MANTENIMIENTO

SECCION DESCRIPCION

1 - DESCRIPCION CU09 – Mantenimiento

Este caso de uso permite dar mantenimiento a las tablas
paramétricas de sistemas.

2 - PRE–  Ninguna.
CONDICION

3 - FLUJO  Ninguno.

4 - POST-  Ninguna.
CONDICION

5 - EXCEPCIONES  Ninguna.

3.2.2. IDENTIFICACIÓN DE ACTORES Y ARTEFACTOS POR CATEGORÍA DE SERVICIO

NRO CATEGORIA / ACTORES ARTEFACTOS

1 Categoría: Configuración de Usuarios:

ACTORES: ARTEFACTOS:

- Propietario o responsable del - Manual de Políticas de Sistemas

Sistema de Información - Solicitud de Apertura de Servicios
- Autoriza la configuración: - Solicitud de Baja de Servicios
 o Jefe de Personal (SEDE) - Solicitud de Reasignación de
o Jefe de Ofides (OFIDE) Servicios
- Usuario Final
- Operador de sistemas
- Jefe de Plataforma

2 Categoría: Desarrollo y mant. de Sistemas:

ACTORES: ARTEFACTOS:

- Propietario o responsable del - Solicitud de Nuevo desarrollo

Sistema de Información - Solicitud de Modificación
- Analista de Negocio (Area usuaria) - Reporte de Incidencia y Correctivo
- Analista de Funcional
- Analista-Programador
- Supervisor DyM
- Analista QA

Categoría: Soporte de Información ARTEFACTOS:

ACTORES: - Solicitud de información.

- Reporte de control de ejecución de
3 - StakeHolders: procesos recurrentes.
o Propietario o responsable
del Sistema de Información
o Gerencias
- Supervisor DyM
- Programador SQL
- Operador de Base de Datos
- Jefe de Plataforma

DESCRIPCION DE PROCESOS

Procedimiento de Atención de requerimiento de nuevo desarrollo en sistemas.

La figura muestra el proceso por el cual el cliente solicita desarrollo de un sistema, la imagen
proyecta el proceso establecido por el equipo de Sistemas.

NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

1 Se crea la SRD. Analista de negocio Solicitud SRD: Creada

Aprueba la solicitud de requerimiento de desarrollo Usuario Jefe

(SRD)

2 Se recepciona la SRD. Auxiliar de Solicitud SRD: Recepcionada

Revisa y recepciona la solicitud SRD adjuntándola ala Sistemas Carpeta:

carpeta “Solicitudes Recepcionadas” “Solicitudes recepcionadas”

NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

3 Se transfiere la SRD para su revisión. Supervisor DyM Solicitud SRD: En revisión.

El Supervisor DyM revisa y separa transfiriendo la SRD Carpetas:

de la carpeta “Solicitudes Recepcionadas” a la carpeta “Solicitudes en revisión”

“Solicitudes en revisión” para su respectivo análisis de

gestión y revisión.

4 Se evalúa la solicitud SRD Supervisor DyM Solicitud SRD:

El Supervisor DyM acepta, Observa o cancela la Aceptada / Observada /

solicitud SRD adjuntándola según corresponda a la Cancelada

carpeta “Solicitudes Aceptadas” o “Solicitudes Carpetas:

Observadas” o “Solicitudes Canceladas” “Solicitudes Aceptadas”

El Supervisor DyM debe asegurar y ser responsable de “Solicitudes Observadas”

validar que el SRD tenga un sustento procedimental a “Solicitudes Canceladas”

nivel de negocio.

En caso sea aceptada se envía al Analista Funcional.

5 El Analista funcional revisa la SRD y dispone el inicio Analista Funcional Solicitud SRD: En análisis

del periodo de Análisis Funcional correspondiente Documento de Análisis

generando el documento de Análisis respectivo. funcional

Culminado su trabajo de Análisis lo envía al Analista de

Sistemas para la elaboración de las especificaciones de

análisis y diseño respectivas previa aprobación del

documento de análisis funcional por parte del

Supervisor DyM y así como del Usuario Jefe.

NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

6 El analista de sistemas revisa la SRD así como el Analista de Solicitud SRD: En diseño

documento de análisis funcional y dispone el inicio del Sistemas Documento de

periodo de elaboración de especificaciones de análisis especificaciones de Análisis

y diseño. y diseño

Al final de su trabajo envía al Supervisor DyM el

documento elaborado.

7 Revisa, modifica y aprueba las especificaciones de Supervisor DyM Orden de desarrollo

diseño conjuntamente con el Analista de negocio. Doc. de Análisis .Funcional

Especificaciones de diseño

8 Genera la orden de desarrollo. Supervisor DyM Orden de desarrollo

Evalúa y asigna al analista-programador la orden de

desarrollo correspondiente.

9 El analista-programador revisa la SRD y orden de Analista- Solicitud SRD: En

desarrollo así como todos los artefactos Programador codificación

complementarios.

Inicia el proceso de codificación. Al final entrega el

ejecutable para pruebas unitarias al Analista Funcional

10 El analista funcional prepara documento de pruebas Analista Funcional Solicitud SRD: En pruebas

funcionales a partir de los escenarios definidos por el Analista de negocio unitarias.

Analista de negocio y/o Jefe de Unidad solicitante del Jefe de Unidad Documento de pruebas

requerimiento. unitarias.
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

11 Con la conformidad de las pruebas unitarias, el Analista Analista Funcional - Documento SRD
- Documento de Análisis
funcional solicita las fuentes y demás componentes Analista- Funcional
- Documento de
necesarios al Analista-Programador. Programador especificaciones de
Análisis y diseño.
El Analista Funcional prepara la Hoja de pase a - Documento de pruebas
unitarias
producción adjuntando: - Fuentes de
codificación.
- Documento SRD - Hoja de Pase a
- Documento de Análisis Funcional producción.
- Documento de especificaciones de Análisis y
diseño.
- Documento de pruebas unitarias
- Fuentes de codificación.
Se envía todo el conjunto de artefactos al Supervisor

DyM.

12 El supervisor DyM revisa todos los artefactos y Supervisor DyM - Documento SRD
- Documento de Análisis
complementa los detalles pendientes de la hoja de pase Funcional
- Documento de
a producción o cualquier información adicional para el especificaciones de
Análisis y diseño.
envío a pruebas de calidad y pase a producción. - Documento de pruebas
unitarias
Envía todos los artefactos al Supervisor QA. - Fuentes de codificación
- Hoja de Pase a
Producción

13 El Supervisor QA revisa la hoja de pase a producción y Supervisor QA Solicitud SRD: En pruebas

todos sus artefactos complementarios. de calidad.

Acepta, solicita información adicional u observa el pase - Plan de pruebas

- Orden de pruebas de
a producción. calidad.

En caso de aceptación prepara el documento de plan

de pruebas así como la estrategia del mismo.

Genera la orden de pruebas de calidad y la envía al

Analista de Calidad
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

14 El analista de calidad revisa el plan de pruebas y la Analista de Calidad - Orden de pruebas de

calidad
orden de pruebas de calidad. - Plan de pruebas
- Fuentes actualizadas
El analista de Calidad prepara toda la infraestructura de - Ejecutable final.
- Hoja de pase a
pruebas solicitando directa o a través del Supervisor producción

QA los requerimientos necesarios y suficientes.

Al final de las pruebas el Analista de calidad informa los

resultados de los mismos.

15 Con la conformidad de las pruebas de calidad, el Supervisor QA - Hoja de pase a

producción
Supervisor QA da su autorización y envía la hoja de - Fuentes
- Ejecutable
pase a producción y todos sus artefactos al Supervisor

de Plataforma para que disponga el despliegue final.

16 El supervisor de PyO revisa la hoja de pase a Supervisor PyO Solicitud SRI: Enviado a pase

producción, solicita información adicional si lo cree a producción.

conveniente, acepta u observa el pase. - Hoja de pase a

producción
Si es conforme elabora la secuencia de acciones y - Fuentes
- Ejecutable
responsables para iniciar la coordinación del pase.

17 Al final del despliegue el Supervisor PyO comunica a Supervisor PyO

todos la culminación del Pase.

18 El Jefe de la unidad solicitante confirma la puesta en Jefe de Unidad Solicitud SRD: Terminado

producción de lo solicitado. Solicitante

19 El auxiliar de sistemas archiva el SRD en la carpeta Auxiliar de Carpeta:”Solicitudes

“Solicitudes Atendidas” toda la documentación referida Sistemas Atendidas”

al pase a producción realizado.

Procedimiento de Atención de requerimiento de modificación del sistema
Atención de requerimiento de modificación del sistema
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

1 Crea la solicitud de requerimiento informático (SRM) Usuario Jefe Solicitud SRM: Creada

2 Se recepciona la SRM. Auxiliar de Solicitud SRM: Recepcionada

Revisa, da conformidad y recepciona la solicitud SRM Sistemas Carpeta:

adjuntándola a la carpeta “Solicitudes Recepcionadas” “Solicitudes recepcionadas”

3 Se asigna SRM para su revisión. Supervisor DyM Solicitud SRM: En revisión.

El Supervisor DyM revisa y separa transfiriendo la SRM Carpetas:

de la carpeta “Solicitudes Recepcionadas” a la carpeta “Solicitudes en revisión”

“Solicitudes en revisión” para su respectivo análisis y

revisión.

4 Se evalúa la solicitud SRM Supervisor DyM Solicitud SRM:

El Supervisor DyM acepta, Observa o cancela la Aceptada / Observada /

solicitud SRM adjuntándola según corresponda a la Cancelada

carpeta “Solicitudes Aceptadas” o “Solicitudes Carpetas:

Observadas” o “Solicitudes Canceladas” “Solicitudes Aceptadas”

En caso sea aceptada se envía al Analista Funcional. “Solicitudes Observadas”

“Solicitudes Canceladas”

6 El Analista funcional revisa la SRM y dispone el inicio Analista Funcional Solicitud SRM: En análisis

del periodo de Análisis Funcional correspondiente Documento de Análisis

generando el documento de Análisis respectivo. funcional

Culminado su trabajo de Análisis lo envía al Analista de

Sistemas para la elaboración de las especificaciones de

análisis y diseño respectivas.

NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

7 El analista de sistemas revisa la SRM así como el Analista de Solicitud SRM: En diseño

documento de análisis funcional y dispone el inicio del Sistemas Documento de

periodo de elaboración de especificaciones de análisis especificaciones de Análisis y

y diseño. diseño

Al final de su trabajo envía al Analista Funcional el

documento elaborado.

8 Revisa las especificaciones de diseño, ajusta Analista Funcional Orden de Desarrollo

documento de análisis funcional, prepara la orden de Doc. de Análisis .Funcional

desarrollo y lo envía al Supervisor DyM. Especificaciones de diseño

9 Revisa y actualiza la orden de desarrollo y demás Supervisor DyM Orden de desarrollo

artefactos.

Evalúa y asigna al analista-programador la orden de

desarrollo correspondiente.

10 El analista-programador revisa la SRM y orden de Analista- Solicitud SRM: En codificación

desarrollo así como todos los artefactos Programador

complementarios.

Inicia el proceso de codificación. Al final entrega el

ejecutable para pruebas unitarias al Analista Funcional

11 El analista funcional prepara documento de pruebas Analista Funcional Solicitud SRM: En pruebas

funcionales a partir de los escenarios definidos por el Analista de negocio unitarias.

Analista de negocio y/o Jefe de Unidad solicitante del Jefe de Unidad Documento de pruebas

requerimiento. unitarias.
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

12 Con la conformidad de las pruebas unitarias, el Analista Analista Funcional - Documento SRM
- Documento de Análisis
funcional solicita las fuentes y demás componentes Analista- Funcional
- Documento de
necesarios al Analista-Programador. Programador especificaciones de
Análisis y diseño.
El Analista Funcional prepara la Hoja de pase a - Documento de pruebas
unitarias
producción adjuntando: - Fuentes de codificación.
- Hoja de Pase a
- Documento SRM producción.
- Documento de Análisis Funcional
- Documento de especificaciones de Análisis y
diseño.
- Documento de pruebas unitarias
- Fuentes de codificación.
Se envía todo el conjunto de artefactos al Supervisor

DyM.

13 El supervisor DyM revisa todos los artefactos y Supervisor DyM - Documento SRM
- Documento de Análisis
complementa los detalles pendientes de la hoja de pase Funcional
- Documento de
a producción o cualquier información adicional para el especificaciones de
Análisis y diseño.
envío a pruebas de calidad y pase a producción. - Documento de pruebas
unitarias
Envía todos los artefactos al Supervisor QA. - Fuentes de codificación
- Hoja de Pase a
Producción

14 El Supervisor QA revisa la hoja de pase a producción y Supervisor QA Solicitud SRM: En pruebas de

todos sus artefactos complementarios. calidad.

Acepta, solicita información adicional u observa el pase - Plan de pruebas

- Orden de pruebas de
a producción. calidad.

En caso de aceptación prepara el documento de plan

de pruebas así como la estrategia del mismo.

Genera la orden de pruebas de calidad y la envía al

Analista de Calidad
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

15 El analista de calidad revisa el plan de pruebas y la Analista de Calidad - Orden de pruebas de

calidad
orden de pruebas de calidad. - Plan de pruebas
- Fuentes actualizadas
El analista de Calidad prepara toda la infraestructura de - Ejecutable final.
- Hoja de pase a
pruebas solicitando directa o a través del Supervisor producción

QA los requerimientos necesarios y suficientes.

Al final de las pruebas el Analista de calidad informa los

resultados de los mismos.

16 Con la conformidad de las pruebas de calidad, el Supervisor QA - Hoja de pase a

producción
Supervisor QA da su autorización y envía la hoja de - Fuentes
- Ejecutable
pase a producción y todos sus artefactos al Supervisor

de Plataforma para que disponga el despliegue final.

17 El supervisor de PyO revisa la hoja de pase a Supervisor PyO Solicitud SRM: Enviado a

producción, solicita información adicional si lo cree pase a producción.

conveniente, acepta u observa el pase. - Hoja de pase a

producción
Si es conforme elabora la secuencia de acciones y - Fuentes
- Ejecutable
responsables para iniciar la coordinación del pase.

18 Al final del despliegue el Supervisor PyO comunica a Supervisor PyO

todos la culminación del Pase.

19 El Jefe de la unidad solicitante confirma la puesta en Jefe de Unidad Solicitud SRM: Terminado

producción de lo solicitado. Solicitante

20 El auxiliar de sistemas archiva el SRM en la carpeta Auxiliar de Carpeta:”Solicitudes

“Solicitudes Atendidas” toda la documentación referida Sistemas Atendidas”

al pase a producción realizado.

5.3 Procedimiento de Atención de requerimientos correctivos por incidencia.
Atención de requerimientos correctivos por incidencia
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

1 EL usuario final crea el reporte de Incidencia(RIC). Usuario Final RIC : Creado

Comunica a Sistemas (HelpDesk) vía correo Reporte de Incidencia de los

adjuntando el RIC con copia a su Jefe de unidad. Sistemas (RIC)

El usuario final debe consultar y asegurar que la falla no

es por mal procedimiento interno y comunicar

explícitamente a sistemas cuando el inconveniente se

originó por error humano.

2 HelpDesk registra el reporte y descarta o corrige HelpDesk RIC : En revisión

inconveniente originado en plataforma y operaciones.

Si se descarta la incidencia por inconveniente en

plataformas y operaciones entonces se deriva al

Supervisor DyM.

3 El Supervisor DyM registra la incidencia y la asigna Supervisor DyM RIC: En revisión

para su revisión a un analista-programador disponible o

solicita la colaboración del Supervisor QA a través del

Analista de calidad.
NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

4 El analista- programador o analista de calidad Analista- RIC: En revisión

encargado elabora su diagnostico indicando las Programador

acciones necesarias para su corrección. Analista de Calidad

Se debe estimar el tiempo de atención y comunicarlo

oportunamente para que el equipo o unidad solicitante

sepa tomar las acciones adecuadas.

5 Si la incidencia es de código el Supervisor DyM debe Supervisor DyM RIC: Enviado a corrección

generar la orden de desarrollo de inmediato adjuntando

el reporte de incidencia y diagnostico.

6 Si la incidencia es por data El supervisor DyM o Supervisor DyM o RIC: Enviado a corrección

Supervisor QA debe enviar inmediatamente el script Supervisor QA

correctivo.

7 Al final de la implementación de la corrección el Usuario Usuario Final RIC: Terminado

Final que reporto la incidencia debe dar su conformidad

en la instancia (plataforma/desarrollo o calidad) donde

se resolvió el inconveniente vía email a así como

también obligatoriamente al auxiliar de sistemas y Jefe

de unidad para el registro final correspondiente.

5.3 Procedimiento de Atención de requerimientos de Solicitud de información.

Atención de requerimientos de Solicitud de información

NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

1 Crea la solicitud de requerimiento de información (SRI) Usuario Jefe Solicitud SRI: Creada

El usuario Jefe envía la solicitud de requerimiento de

información a Sistemas.

2 El supervisor DyM o Supervisor QA según sea el caso Usuario Jefe Solicitud SRI: En Revisión

revisa el requerimiento de información pudiendo afinar Supervisor DyM

el requerimiento con el usuario Jefe. Supervisor QA

Si hay cambios el requerimiento original se cancela

cambiándolo por uno nuevo.

3 El supervisor DyM o QA envía el SRI al diseñador de Analista- Solicitud SRI: En desarrollo

reportes gerenciales (Analista-Programador o experto Programador

en Soluciones de explotación de información).

El diseñador de reportes envía una vez terminado envía

los scripts al Analista QA para su respectiva validación.

4 El analista de calidad revisa los scripts para asegurar la Analista QA Solicitud SRI: En pruebas

calidad de información generada, es decir para verificar

que lo obtenido es lo que se ha pedido.

Terminado su revisión envía el script al administrador

de base de datos para su pase a producción.

 NRO ACTIVIDAD UNIDAD / ACTOR ARTEFACTO / ESTADO

4 El Administrador de base de datos revisa y procura la Administrador de Solicitud SRI: En pruebas

optimización del script. base de datos

Envía la conformidad al Supervisor QA.

5 El administrador de base de datos programa la tarea Administrador de Solicitud SRI: En

informando sobre su tiempo de ejecución y base de datos programación

disponibilidad esperada.

6 El usuario Jefe al recibir la confirmación de Usuario Jefe Solicitud SRI: Terminada

disponibilidad de la información envía la confirmación

final de la atención del requerimiento.

FORMATOS DE ATENCIÓN

NRO CODIGO DEFINICIÓN

1 SRD SOLICITUD DE REQUERIMIENTO DE NUEVO DESARROLLO

 Es el documento que contiene los criterios y definición de requerimientos

funcionales y no funcionales convenidos y aprobados por el propietario del

Sistema de Información y que conducirán el desarrollo, pruebas y puesta en

producción del mismo.

2 SRM SOLICITUD DE REQUERIMIENTO DE MODIFICACION EN LOS SISTEMAS

Es el documento que contiene los criterios y definición del requerimiento de

cambio.

3 RIC REPORTE DE INCIDENCIA Y CORRECTIVO

Es el documento que reporta el detalla de la incidencia incurrida por parte de

los sistemas de información.

4 RDI REPORTE DE DIAGNOSTICO DE INCIDENCIA

Es el documento que reporta el detalla de la incidencia incurrida por parte de

los sistemas de información.

5 ORC ORDEN DE CORRECIÓN

Es el documento que contiene la programación, recursos y tiempos de

desarrollo asignados a los analistas-programadores.

6 SRI SOLICITUD DE REQUERIMIENTO DE INFORMACION

Es el documento que contiene los criterios y definición de las necesidades de

información solicitados.

7 ORD ORDEN DE DESARROLLO

Es el documento que contiene la programación, recursos y tiempos de

desarrollo asignados a los analistas-programadores.

8 DAN DOCUMENTO DE ANÁLISIS

Es el documento que contiene el análisis funcional de la propuesta de

cambio o nuevo desarrollo .

9 EAD ESPECIFICACIONES DE ANÁLISIS Y DISEÑO

Es el documento que contiene los detalles técnicos para la implementación

de la solución .

10 EIM ESPECIFICACIONES DE IMPLEMENTACION

Es el documento técnico que contiene los requisitos e indicaciones sobre la

instalación del producto desarrollado.

11 HPP HOJA DE PASE A PRODUCCION

Es el documento principal que contiene la orden de pase a producción.

12 PNP PLAN DE PRUEBAS

Es el documento que contiene la estrategia, recursos, cronograma y detalle

de las pruebas a realizarse .

13 DRE DISEÑO DEL REPORTE

Es el documento que contiene la interfaz visual y semántica del contenido de

la información requerida.

14 SCR SCRIPT DEL REPORTE

Es el conjunto de instrucciones en lenguaje SQL que generan la información

solicitada..
3.3. DISEÑO

El diseño fue planificado de manera sincronizada al análisis del sistema, un buen diseño
supone un buen análisis (requerimientos del cliente) por ello enfatizamos en la recolección
de datos.

A. DIAGRAMA DE PAQUETES
 pk Salida

pk Ingreso

Tecnico
(f rom pk Actors)
pk Inventariar

pk Informe
Aquí se está definiendo las tres capas básicas que son: Capa de Presentación, Capa de Lógica de
Negocio y Capa de Base de datos las cuales interactúan una con otra. En el paquete de Capa de
Presentación tenemos al componente de módulo de activo fijo el cual manda los datos del usuario al
componente de seguridad para realizar las validaciones de acceso el cual retorna al componente de
servicios web para que pueda realizar sus operaciones o búsquedas en las interfaces de cambio de activo,
asignación, actualización de activos, reportes de solicitudes de activos, reporte de solicitudes aprobadas y
reporte de solicitudes rechazadas. El componente code behind del paquete de capa de presentación
realizara las instrucciones de código ASP.NET que interactúan completamente con el paquete de Capa de
Lógica de Negocio cuyos componentes son los intermediarios para establecer una arquitectura de código
con las interfaces y el acceso a la conexión a base de datos. En el paquete de Capa de Base de Datos,
los componentes trabajan para establecer la conexión a la base de datos, mandar, ejecutar y retornar las
consultas y operaciones a la base de datos.

B. DIAGRAMA DE CASOS DE USO

El

proceso sigue con la generación de la solicitud por parte del personal de atención de ventanilla, la solicitud

<<derive>> <<include>>

uc Tipo Salida uc Registar Salida uc Registrar Entrada uc Tipo Entrada

(from uc Inclu... (from pk Use Ca... (from pk Use Ca.. . (from uc Inclu...

<<include>>

<<extend>>

uc Inventariar Equipos uc Inventaria Parte

Tecnico
(from pk Use Ca.. . (from uc Ext...
(from pk Act ors)

<<include>>
<<include>>

uc Detalle de Inventario
(from uc Inclu...
uc Informe
(from pk Use Ca...

uc Mantenimiento
Supervisor
(from pk Use Ca.. .
(from pk Act ors)

luego de ser registrado por el solicitante, el primer aprobador tendrá la visualización de la solicitud al detalle
para finalmente “aprobar o rechazar” la solicitud y así sucesivamente se irá subiendo de nivel, llegando
posteriormente al Jefe de Plataforma de Operaciones, luego al Jefe de Sistemas hasta que el último
aprobador, el gerente administrativo, lo apruebe.
C. DIAGRAMA DE ANALISIS DE DISEÑO

BE_Informe
(from 1.Business Entity)

Guarda Detalle 1 Relaciona * 1 Guarda D etalle 1

1 1

BE_Ficha_Nac_Equipo BE_Equipo BE_ParteEquipo BE_Ficha_Nac_ParteEquipo

(from 1.Business Entity) (from 1.Business Entity) (from 1.Business Entity) (from 1.Business Entity)

Guarda Guarda
Genera /Actualiz a
BE_ControlUs uario
(from 1.Business E ntity)

BE_GuiaEntrada BE_DetalleEntrada BE_D etalleSalida

(from 1.Business Entity) (from 1.Business Entity) (from 1.Business Entity)

Genera

BE_GuiaSalida
(from 1.Business Entity)
 REGISTRO DE EQUIPOS

FInvEquipoParte TDMATI
(f rom Boundary ) (f rom Control)

TFInvEquipo TDMATI
BW_Tecnico (f rom Boundary ) (f rom Control)

(f rom 2. Business Worker)

REGISTRO DE ENTRADAS

TFStockEntra TDMATI
(f rom Boundary ) (f rom Control)

TFStock TDMATI
BW_Tecnico (f rom Boundary ) (f rom Control)

(f rom 2. Business Worker)

REGISTRO DE SALIDAS

TFSalida
(f rom Boundary )

TFStock TDMATI
BW_Tecnico (f rom Boundary ) (f rom Control)

(f rom 2. Business Worker)

TFSalidaMasiva
(f rom Boundary )

GENERACION DE INFORMES

TFInfoTec
(f rom Boundary )

TFInvEquipo TDMATI
BW_Tecnico (f rom Boundary ) (f rom Control)

(f rom 2. Business Worker)

CLASE UNIDAD DESCRIPCION

FPrincipal ATI001 Clase Formulario contiene el menú principal del Sistemas.

FAcceso ATI002 Clase Formulario contiene la seguridad de ingreso al sistema.

FTransGuiSali ATI33O Ninguna.

Clase Formulario contiene el mantenimiento de Usuario y

FManUsuario ATI100 Oficinas.

Clase Formulario contiene el mantenimiento de Tipo de

FManTipoEquipo ATI110 Equipo.

Clase Formulario contiene el Mantenimiento de Partes de

FManComponente ATI120 Equipo.

FManOficina ATI130 Ninguna.

FManResponsable ATI140 Clase Formulario contiene el Mantenimiento de Responsables.

FInvEquipo ATI200 Clase Formulario contiene el Registro de Equipos

Clase Formulario contiene el Stock de Equipos que están en

FStock ATI300 Soporte Técnico.

FSalida ATI310 Clase Formulario contiene el Registro de Salidad de un Equipo

Clase Formulario contiene el Generador de Informe por

FInfoTec ATI320 Equipo.

FConsGuiaEntra ATI500 Ninguna.

FConsEquipo ATI510 Ninguna.

FConsOrdTras ATI530 Ninguna.

Clase Controlador contiene todos los ClientDataSet del

DMATI ATIDM1 Sistemas y su Socked de conexión al servidor de Aplicaciones.

Clase Formulario contiene Mantenimiento de Tecnología de

FManEquipoTecno ATI111 Equipos.

FManColor ATI115 Clase Formulario contiene Mantenimiento de Color de Equipos

Clase Formulario contiene Mantenimiento de Modelo de

FManEquipoModel ATI112 Equipos.

FManEquipoMarca ATI113 Clase Formulario contiene Mantenimiento de Marca de

 Equipos.

FManEquipoTipo ATI114 Clase Formulario contiene Mantenimiento de Tipo de Equipo

Clase Formulario contiene Mantenimiento de Características

FManComCarac ATI121 de Parte Equipo.

Clase Formulario contiene Mantenimiento de Marca de Parte

FManComMarca ATI122 Equipo.

Clase Formulario contiene Mantenimiento de Tipo de Parte

FManComTipo ATI123 Equipo.

Clase Formulario contiene Mantenimiento de Unidad de Parte

FManComUnidad ATI124 Equipo

Clase Formulario contiene la descripción de los Atributos del

FInvEquipo1 ATI201 Equipo.

FInvParteEquipo ATI210 Clase Formulario contiene Registro de Parte de Equipo

Clase Formulario contiene la descripción de los Atributos de la

FInvParteEquipo1 ATI211 Parte Equipo.

Clase Formulario contiene los equipos que están dentro del

FStockEntra ATI301 Stock Temporal de Soporte Técnico.

Clase Formulario contiene el modo de salida de Equipos en

FSalidaMasiva ATI311 forma masiva (Mas de uno por vez)
 D. DIAGRAMAS DE ACTIVIDAD

REGISTRO DE ENTRADAS

: BE_GuiaEntrada : BE_DetalleEntrada

Pre Condicion

Documento de Guía de
Entrada

Guía de Entrada

Tipo de Guía de
Entrada

Contiene Partes Si
Guía de
Entrada Partes

No

Actualiza el
Stock Temporal

REGISTRO DE SALIDAS
 : BE_GuiaSalida : BE_DetalleSalida

Pre Condición que el

Equipo este en
Soporte Técnico

Guía de Salida Documento de Guía

de Salida

Tipo de Guía de
Salida

Contiene Partes Si
Detalle de Guía
de Salida

No

Actualiza el
Stock Temporal

REGISTRO DE EQUIPOS
 : BE_ParteEquipo

Equipo ya
Inventariado

No

Inventariar
Equipo

Si
Si
Inventariar Parte Inventario
de Partes

No

GENERACION DE INFORMES
 : BE_Equipo : BE_Informe : BE_GuiaEntrada

Documento de Informe Técnico

Realizado

Causa para Genera un

realizar el Informe Informe

Estado de No Estado de Informe

Informe Atendido Técnico, una ves
Técnico Incial
reingresado el
Equipo

Nueva Entrada Si Genera entrada

Atendido
No
 E. DIAGRAMA DE ESTADOS

Estos son los estados por los que pasa la solicitud una vez registrada por el solicitante; Registrado,
Aprobado_nivel_1, Aprobado_nivel_2, Aprobado_nivel_3 y Aprobado_nivel_4. El flujo representa la
estrategia para la evaluación rápida del cambio, asignación y actualización del activo fijo. En caso de
que no se llegara a aprobar en cualquier nivel, automáticamente se cambiara al estado rechazado,
teniendo la oportunidad de ser registrado nuevamente para que se corrija o modifique algo, por el
contrario puede ser anulado haciendo que se elimine la solicitud de la base de datos.
 F. DIAGRAMA DE CLASES

Estas clases sirven para la relación de tablas de la base de datos del proyecto del sistema. Dichas
clases además evitan la ineficiencia de duplicidad de registros, en las solicitudes tenemos los tipos
de solicitudes, los estados de la solicitud, las aprobaciones de la solicitud, el historial de la solicitud.
En la tabla solicitud_empleado existe también los datos del empleado, la sede en que trabaja, el
área perteneciente, el tipo de empleado ya se por su cargo en el organigrama de la empresa. En
cuanto al activo, la posición que debería estar dentro del área, es decir su puesto del empleado.
 G. DIAGRAMAS DE ENTIDAD-RELACIÓN

UNIDAD ESTADOPARTE
UNIDADID: VARCHAR2(20) ESTADOID: VARCHAR2(20)
NOMBRE: VARCHAR2(50) NOMBRE: VARCHAR2(50)
ACCESOS_LOG

APLCLIENTE: VARCHAR2(5)
IPCLIENTE: VARCHAR2(15)
USUCLIENTE: VARCHAR2(20)
FECHORREGING: DATE
FECHORREGOUT: DATE
UNIDADCONTROL IDEREG: VARCHAR2(14)
IDPC: VARCHAR2(25)
FICNACPAREQUIPO
UNIDADID: VARCHAR2(20)
FICNACPAREQUIPOID: VARCHAR2(20)
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20)
PARTE_EQUIPO FECHA: DATE
PARTE_EQUIPOID: VARCHAR2(20) ACF120 ACF121
USERID: VARCHAR2(20)
TIPOID: VARCHAR2(20) PARTE_EQUIPOID: VARCHAR2(20)
SERIE: VARCHAR2(50) ESTADO_PARTE_EQUIPOID: VARCHAR2(20) LOCID: VARCHAR2(2) LOCID: VARCHAR2(2)
CARACTERISTICA
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20) EQUIPOID: VARCHAR2(20) LOCDES: VARCHAR2(30) PISO: VARCHAR2(2)
CARACTERISTICAID: VARCHAR2(20) PISODES: VARCHAR2(30)
MARCAID: VARCHAR2(20)
NOMBRE: VARCHAR2(50) FRU: VARCHAR2(25)
ACF123
CAPACIDAD: VARCHAR2(25) ACF122
UNIDADID: VARCHAR2(20)
CARACTERISTICAID: VARCHAR2(20) LOCID: VARCHAR2(2)
DETALLE_GUIA_ENTRADA LOCID: VARCHAR2(2)
CARACCONTROL ESTADOID: VARCHAR2(20) PISO: VARCHAR2(2)
DETALLE_GUIA_ENTRADAID: VARCHAR2(20) PISO: VARCHAR2(2)
EQUIPOID: VARCHAR2(20) AREA: VARCHAR2(2)
AREA: VARCHAR2(2)
GUIA_ENTRADAID: VARCHAR2(20) AREADES: VARCHAR2(50)
CARACTERISTICAID: VARCHAR2(20) AREADES: VARCHAR2(50)
PARTE_EQUIPOID: VARCHAR2(20) AMBCOD: VARCHAR2(3)
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20)
ESTADO_PARTE_EQUIPOID: VARCHAR2(20) AMBDES: VARCHAR2(50)
CIAID: VARCHAR2(2)
FLG: VARCHAR2(1)
TIPO_PARTE_EQUIPO
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20)
DETALLE_GUIA_SALIDA
NOMBRE: VARCHAR2(50) DETALLE_GUIA_SALIDAID: VARCHAR2(20)
GUIA_SALIDAID: VARCHAR2(20)
PARTE_EQUIPOID: VARCHAR2(20)
MARCAC ESTADO_PARTEID: VARCHAR2(50)
MARCAID: VARCHAR2(20)
NOMBRE: VARCHAR2(50)

MARCACCONTROL

MARCAID: VARCHAR2(20)
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20)

GUIA_ENTRADA
TIPOC REFERENCIA
GUIA_ENTRADAID: VARCHAR2(20)
TIPOID: VARCHAR2(20) REFERENCIAID: VARCHAR2(10)
FECHA: DATE
NOMBRE: VARCHAR2(50) OBSERVACIONES: VARCHAR2(500) NOMBRE: VARCHAR2(25)
SSGGID: VARCHAR2(20) DESCRIPCION: VARCHAR2(25)
USERID: VARCHAR2(20)
TIPOCCONTROL EQUIPOID: VARCHAR2(20)
ESTADO_EQUIPOID: VARCHAR2(20)
USUARIOID: VARCHAR2(20)
NOMBRE_PARTE_EQUIPOID: VARCHAR2(20) NROREQUERIMIENTO: VARCHAR2(25) GUIA_ENTRADA_TIPO
TIPOID: VARCHAR2(20) GUIA_ENTRADA_TIPOID: VARCHAR2(10) GUIA_ENTRADA_TIPOID: VARCHAR2(10)
USUARIOCONTROID: VARCHAR2(20)
REFERENCIAID: VARCHAR2(10) NOMBRE: VARCHAR2(50)
PROCEDENCIAID: VARCHAR2(20) DESCRIPCION: VARCHAR2(50)
TECNOCONTROL INFOID: VARCHAR2(20)
DETALLE_GUIA_ENTRADAID: VARCHAR2(20)
TECNOLOGIAID: NUMBER GUIA_SALIDA
NOMBRE_EQUIPOID: NUMBER GUIA_SALIDAID: VARCHAR2(20)
FECHA: DATE
OBSERVACIONES: VARCHAR2(500)
NUMSTICKER: VARCHAR2(25)
SSGGID: VARCHAR2(20) SSGG
TECNOLOGIA
USERID: VARCHAR2(20) SSGGID: VARCHAR2(20)
TECNOLOGIAID: NUMBER ESTADO_EQUIPOID: VARCHAR2(20)
NOMBRE: VARCHAR2(50) GUIA_ENTRADAID: VARCHAR2(20) NOMBRE: VARCHAR2(100)
USUARIOID: VARCHAR2(10) CLAVE: VARCHAR2(50)
GUIA_SALIDA_TIPOID: VARCHAR2(10) DESCRIPCION: VARCHAR2(50)
USUARIOCONTROID: VARCHAR2(20)
EQUIPOID: VARCHAR2(20)
MODELO DESTINOID: VARCHAR2(20)
MODELOID: NUMBER
NOMBRE: VARCHAR2(50)

EQUIPO
EQUIPOID: VARCHAR2(20)
MODELOCONTROL SERIE: VARCHAR2(50)
ESTADOID: VARCHAR2(20)
MODELOID: NUMBER USUARIOID: VARCHAR2(20)
NOMBRE_EQUIPOID: NUMBER ESTACIONID: VARCHAR2(20)
NROINVENTARIO: VARCHAR2(50)
FRU: VARCHAR2(50)
TECNOLOGIAID: NUMBER
MODELOID: NUMBER
USUARIO MARCAID: NUMBER
TIPOID: NUMBER GUIA_SALIDA_TIPO
USUARIOID: VARCHAR2(10) GUIA_SALIDA_TIPOID: VARCHAR2(10)
NOMBRE_EQUIPOID: NUMBER
NOMBRE: VARCHAR2(80) COLORID: NUMBER NOMBRE: VARCHAR2(50)
OFICINAID: NUMBER USUARIOCONTROID: VARCHAR2(20) DESCRIPCION: VARCHAR2(50)

USUARIOCONTROL
USUARIOCONTROID: VARCHAR2(20) TGE003 TGE007
LOCID: VARCHAR2(20)
PISO: VARCHAR2(20) GRUPOID: VARCHAR2(20) USERID: VARCHAR2(20)
AREA: VARCHAR2(20) GRUPODES: VARCHAR2(30) USERNOM: VARCHAR2(30)
AMBCOD: VARCHAR2(20) GRUPOADM: VARCHAR2(1) GRUPOID: VARCHAR2(20)
USUARIOID: VARCHAR2(10) FLAGCONTROL: VARCHAR2(25)
PASSWORD: VARCHAR2(20)
TGE006
TIPO_EQUIPO
TGE001
NOMBRE_EQUIPOID: NUMBER
USERID: VARCHAR2(20)
NOMBRE: VARCHAR2(50) USERNOM: VARCHAR2(30)
GRUPOID: VARCHAR2(20)
OBSERVACIONES: VARCHAR2(50) PASSWORD: VARCHAR2(20)
MODULOID: VARCHAR2(20)
FECEXP: DATE
TIPO: VARCHAR2(1)
OFDESID: VARCHAR2(2)
OBJETO: VARCHAR2(50)
CTLFAC: VARCHAR2(1)
NIVEL: VARCHAR2(1)
ESTADO FLGAUT: VARCHAR2(4)
FORMA: VARCHAR2(20)
ESTADOID: VARCHAR2(20) FECINI_PWD: DATE
DESCRIPCION: VARCHAR2(40)
FECFIN_PWD: DATE
NOMBRE: VARCHAR2(50) DESCRIPTIVO: VARCHAR2(50)
DIASEXP_PWD: NUMBER
DIASDURAC_PWD: NUMBER
CTRL_IP: VARCHAR2(1)
TIPO
TIPOID: NUMBER
NOMBRE: VARCHAR2(50)

TIPOCONTROL FICNACEQUIPO
FICNACEQUIPOID: VARCHAR2(20)
NOMBRE_EQUIPOID: NUMBER FECHA: DATE
TIPOID: NUMBER USERID: VARCHAR2(20)
EQUIPOID: VARCHAR2(20)
ESTADO_EQUIPOID: VARCHAR2(20)
MARCA
MARCAID: NUMBER
INFORME
NOMBRE: VARCHAR2(50) INFOID: VARCHAR2(20)
INFORMEID: VARCHAR2(50)
FECHA: DATE
USERID: VARCHAR2(20)
MARCACONTROL
EQUIPOID: VARCHAR2(20)
PROBLEMA: VARCHAR2(500)
NOMBRE_EQUIPOID: NUMBER DIAGNOSTICO: VARCHAR2(500)
MARCAID: NUMBER SOLUCIONADO: VARCHAR2(10)
ACCION: VARCHAR2(500)
USUARIOID: VARCHAR2(20)
OBSERVACIONES: VARCHAR2(500)
USUARIOCONTROID: VARCHAR2(20)

COLOR
COLORID: NUMBER
NOMBRE: VARCHAR2(50)
 TABLAS

Tabla

Nombre

ACCESOS_LOG

ACF120

ACF121

ACF122

ACF123

CARACCONTROL

CARACTERISTICA

COLOR

DETALLE_GUIA_ENTRADA

DETALLE_GUIA_SALIDA

EQUIPO

ESTADO

ESTADOPARTE

FICNACEQUIPO

FICNACPAREQUIPO

GUIA_ENTRADA

GUIA_ENTRADA_TIPO

GUIA_SALIDA

GUIA_SALIDA_TIPO

INFORME

MARCA

MARCAC

MARCACCONTROL

MARCACONTROL
Tabla

Nombre

MODELO

MODELOCONTROL

PARTE_EQUIPO

REFERENCIA

SSGG

TECNOCONTROL

TECNOLOGIA

TGE001

TGE003

TGE006

TGE007

TIPO

TIPO_EQUIPO

TIPO_PARTE_EQUIPO

TIPOC

TIPOCCONTROL

TIPOCONTROL

UNIDAD

UNIDADCONTROL

USUARIO

USUARIOCONTROL

Columna "ACCESOS_LOG" Tabla

Is FK Nombre Is PK

No APLCLIENTE No
Columna "ACCESOS_LOG" Tabla

Is FK Nombre Is PK

No IPCLIENTE No

No USUCLIENTE No

No FECHORREGING No

No FECHORREGOUT No

No IDEREG No

No IDPC No

Columna "ACF120" Tabla

Is FK Nombre Is PK

No LOCID No

No LOCDES No

Columna "ACF121" Tabla

Is FK Nombre Is PK

No LOCID No

No PISO No

No PISODES No

Columna "ACF122" Tabla

Is FK Nombre Is PK

No LOCID No

No PISO No

No AREA No

No AREADES No
Columna "ACF123" Tabla

Is FK Nombre Is PK

No LOCID No

No PISO No

No AREA No

No AREADES No

No AMBCOD No

No AMBDES No

No CIAID No

No FLG No

Columna "CARACCONTROL" Tabla

Is FK Nombre Is PK

Si CARACTERISTICAID No

No NOMBRE_PARTE_EQUIPOID No

Columna "CARACTERISTICA" Tabla

Is FK Nombre Is PK

No CARACTERISTICAID Si

No NOMBRE No

Columna "COLOR" Tabla

Is FK Nombre Is PK

No NOMBRE No

No COLORID Si
Columna "DETALLE_GUIA_ENTRADA" Tabla

Is FK Nombre Is PK

No DETALLE_GUIA_ENTRADAID Si

No GUIA_ENTRADAID No

Si PARTE_EQUIPOID No

No ESTADO_PARTE_EQUIPOID No

Columna "DETALLE_GUIA_SALIDA" Tabla

Is FK Nombre Is PK

No DETALLE_GUIA_SALIDAID Si

Si GUIA_SALIDAID No

Si PARTE_EQUIPOID No

No ESTADO_PARTEID No

Columna "EQUIPO" Tabla

Is FK Nombre Is PK

No EQUIPOID Si

No SERIE No

Si ESTADOID No

Si USUARIOID No

No ESTACIONID No

No NROINVENTARIO No

No FRU No

Si TECNOLOGIAID No

Si MODELOID No

Si MARCAID No

Si TIPOID No
Columna "EQUIPO" Tabla

Is FK Nombre Is PK

Si NOMBRE_EQUIPOID No

Si COLORID No

Si USUARIOCONTROID No

Columna "ESTADO" Tabla

Is FK Nombre Is PK

No ESTADOID Si

No NOMBRE No

Columna "ESTADOPARTE" Tabla

Is FK Nombre Is PK

No ESTADOID Si

No NOMBRE No

Columna "FICNACEQUIPO" Tabla

Is FK Nombre Is PK

No FICNACEQUIPOID Si

No FECHA No

No USERID No

Si EQUIPOID No

No ESTADO_EQUIPOID No

Columna "FICNACPAREQUIPO" Tabla

Is FK Nombre Is PK

No FICNACPAREQUIPOID Si
Columna "FICNACPAREQUIPO" Tabla

Is FK Nombre Is PK

No FECHA No

No USERID No

Si PARTE_EQUIPOID No

No ESTADO_PARTE_EQUIPOID No

No EQUIPOID No

Columna "GUIA_ENTRADA" Tabla

Is FK Nombre Is PK

No GUIA_ENTRADAID Si

No FECHA No

No OBSERVACIONES No

Si SSGGID No

No USERID No

Si EQUIPOID No

No ESTADO_EQUIPOID No

No USUARIOID No

No NROREQUERIMIENTO No

Si GUIA_ENTRADA_TIPOID No

No USUARIOCONTROID No

Si REFERENCIAID No

No PROCEDENCIAID No

No INFOID No

Si DETALLE_GUIA_ENTRADAID No
Columna "GUIA_ENTRADA_TIPO" Tabla

Is FK Nombre Is PK

No GUIA_ENTRADA_TIPOID Si

No NOMBRE No

No DESCRIPCION No

Columna "GUIA_SALIDA" Tabla

Is FK Nombre Is PK

No GUIA_SALIDAID Si

No FECHA No

No OBSERVACIONES No

No NUMSTICKER No

Si SSGGID No

No USERID No

No ESTADO_EQUIPOID No

No GUIA_ENTRADAID No

Si USUARIOID No

Si GUIA_SALIDA_TIPOID No

No USUARIOCONTROID No

Si EQUIPOID No

No DESTINOID No

Columna "GUIA_SALIDA_TIPO" Tabla

Is FK Nombre Is PK

No GUIA_SALIDA_TIPOID Si

No NOMBRE No

No DESCRIPCION No
Columna "INFORME" Tabla

Is FK Nombre Is PK

No INFOID Si

No INFORMEID No

No FECHA No

No USERID No

Si EQUIPOID No

No PROBLEMA No

No DIAGNOSTICO No

No SOLUCIONADO No

No ACCION No

No USUARIOID No

No OBSERVACIONES No

No USUARIOCONTROID No

Columna "MARCA" Tabla

Is FK Nombre Is PK

No NOMBRE No

No MARCAID Si

Columna "MARCAC" Tabla

Is FK Nombre Is PK

No MARCAID Si

No NOMBRE No
Columna "MARCACCONTROL" Tabla

Is FK Nombre Is PK

Si MARCAID No

No NOMBRE_PARTE_EQUIPOID No

Columna "MARCACONTROL" Tabla

Is FK Nombre Is PK

No NOMBRE_EQUIPOID No

Si MARCAID No

Columna "MODELO" Tabla

Is FK Nombre Is PK

No NOMBRE No

No MODELOID Si

Columna "MODELOCONTROL" Tabla

Is FK Nombre Is PK

Si MODELOID No

No NOMBRE_EQUIPOID No

Columna "PARTE_EQUIPO" Tabla

Is FK Nombre Is PK

No PARTE_EQUIPOID Si

Si TIPOID No

No SERIE No

Si NOMBRE_PARTE_EQUIPOID No

Si MARCAID No
Columna "PARTE_EQUIPO" Tabla

Is FK Nombre Is PK

No FRU No

No CAPACIDAD No

Si UNIDADID No

Si CARACTERISTICAID No

Si ESTADOID No

Si EQUIPOID No

Columna "REFERENCIA" Tabla

Is FK Nombre Is PK

No REFERENCIAID Si

No NOMBRE No

No DESCRIPCION No

Columna "SSGG" Tabla

Is FK Nombre Is PK

No NOMBRE No

No SSGGID Si

No CLAVE No

No DESCRIPCION No

Columna "TECNOCONTROL" Tabla

Is FK Nombre Is PK

Si TECNOLOGIAID No

No NOMBRE_EQUIPOID No
Columna "TECNOLOGIA" Tabla

Is FK Nombre Is PK

No NOMBRE No

No TECNOLOGIAID Si

Columna "TGE001" Tabla

Is FK Nombre Is PK

No GRUPOID No

No MODULOID No

No TIPO No

No OBJETO No

No NIVEL No

No FORMA No

No DESCRIPCION No

No DESCRIPTIVO No

Columna "TGE003" Tabla

Is FK Nombre Is PK

No GRUPOID No

No GRUPODES No

No GRUPOADM No

Columna "TGE006" Tabla

Is FK Nombre Is PK

No USERID No

No USERNOM No

No PASSWORD No
Columna "TGE006" Tabla

Is FK Nombre Is PK

No FECEXP No

No OFDESID No

No CTLFAC No

No FLGAUT No

No FECINI_PWD No

No FECFIN_PWD No

No DIASEXP_PWD No

No DIASDURAC_PWD No

No CTRL_IP No

Columna "TGE007" Tabla

Is FK Nombre Is PK

No USERID No

No USERNOM No

No GRUPOID No

No FLAGCONTROL No

No PASSWORD No

Columna "TIPO" Tabla

Is FK Nombre Is PK

No NOMBRE No

No TIPOID Si
Columna "TIPO_EQUIPO" Tabla

Is FK Nombre Is PK

No NOMBRE No

No NOMBRE_EQUIPOID Si

No OBSERVACIONES No

Columna "TIPO_PARTE_EQUIPO" Tabla

Is FK Nombre Is PK

No NOMBRE_PARTE_EQUIPOID Si

No NOMBRE No

Columna "TIPOC" Tabla

Is FK Nombre Is PK

No TIPOID Si

No NOMBRE No

Columna "TIPOCCONTROL" Tabla

Is FK Nombre Is PK

No NOMBRE_PARTE_EQUIPOID No

Si TIPOID No

Columna "TIPOCONTROL" Tabla

Is FK Nombre Is PK

No NOMBRE_EQUIPOID No

Si TIPOID No
Columna "UNIDAD" Tabla

Is FK Nombre Is PK

No UNIDADID Si

No NOMBRE No

Columna "UNIDADCONTROL" Tabla

Is FK Nombre Is PK

Si UNIDADID No

No NOMBRE_PARTE_EQUIPOID No

Columna "USUARIO" Tabla

Is FK Nombre Is PK

No NOMBRE No

No USUARIOID Si

No OFICINAID No

Columna "USUARIOCONTROL" Tabla

Is FK Nombre Is PK

No USUARIOCONTROID Si

No LOCID No

No PISO No

No AREA No

No AMBCOD No

Si USUARIOID No
 H. DIAGRAMA DE DESPLIEGUE

ARQUITECTURA DEL SERVIDOR

 Aquí el usuario se conecta a la red mediante un navegador y luego ingresa al servidor que es el
nodo maestro que balancea hacia los dos nodos donde se evaluara al usuario y este gestionara lo
que deba hacerse en el servidor web que a su vez estarán conectados para sus peticiones al
servidor de base de datos que usa 4 base de datos.

I. INTERFAZ GRAFICA

Las interfaces mostradas son el diseño a grosso modo de nuestro sistema de módulo de activos fijos
de la empresa Derrama Magisterial. Tanto la entrada como el módulo de activos fijos donde se
visualizan las opciones a realizar como cambiar activos, asignar activos, actualizar activos, mientras
que en reportes tenemos, la búsqueda de solicitudes, las solicitudes rechazadas y las solicitudes
aprobadas.

ANEXOS

GLOSARIO DE TERMINOS

Actores

Los Actores representan lo que interactúa con el sistema. Ellos representan a todo lo que necesita
intercambiar información con el sistema
Atributo

Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un
dominio de valores determinado

Caso De Uso Extendido

Indica que la funcionalidad e un caso de uso extendido, puede ser opcionalmente usada por un caso de uso
Base.

Caso De Uso Incluido

Indica que la funcionalidad de un caso de uso incluido es usada por un caso de Uso Base

Casos De Uso

Se usan para especificar el comportamiento del sistema sin definir su estructura. Es una operación/tarea
específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien
desde la invocación desde otro caso de uso.

Casos De Uso De Negocio

Define que debería pasar en el negocio cuando se lleva a cabo, Describe también la ejecución de una
secuencia de acciones que producen un resultado para un actor del negocio.

Clases

Es una abstracción de la realidad, la cual servirá como modelo para los objetos que se realizarán
posteriormente.

Clasificadores

Instrumentos que nos permite realizar el diagrama de secuencia en la Fase de Análisis O.O.

Componente

Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un

conjunto de interfaces a las que proporciona su realización

Control

También llamado como gestor, es un clasificador que permite delegar responsabilidades a otros
clasificadores.

Device

Es un componente de hardware, sin capacidad de

Procesamiento

Diagramas De Actividad

Es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para
especificar

Diagramas De Casos De Uso

Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. Los

Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación

Diagramas De Clases

Es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con
sus relaciones estructurales y de herencia

Diagramas De Colaboración

Diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de
secuencia, los diagramas de colaboración muestran explícitamente las relaciones de los roles.

Diagramas De Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los
cambios que permiten pasar de un estado a otro

Diagramas De Secuencia

Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En
particular muestra los objetos participantes en la interacción y la secuencia de mensajes intercambiados

Driver

Un driver es un conjunto de clases que permiten establecer la comunicación entre el programa java y el
DBMS que se está utilizando

Entidad

Es un clasificador que representa a una tabla dentro de una base de datos.

Esquema

Lugar lógico el cual se colocan un conjunto de tablas dentro de una base de datos, en el caso de Oracle, este
manejador nombra al esquema de la misma manera que el usuario para no causar confusiones posteriores.
Foro

Reunión para discutir asuntos de interés actual ante un auditorio que puede intervenir en la discusión

GUI

Es la interfaz Gráfica del Usuario. (Ventanas)

Hardware

Conjunto de elementos materiales de un ordenador Electrónico

Interface

Es un clasificador que representa a las ventanas u otros sistemas dentro del Diagrama de Secuencias de la
Fase de Análisis O.O.

JDBC

JDBC es usado para enviar comandos SQL hacia una base de datos relacional, que puede ser Oracle,
Infomix, SyBase, etc. Establece una conexión con una BD. Envía sentencias SQL. Procesa los resultados

Links

Más conocido como enlace, como su mismo nombre nos lo dice, nos permite enlazar documentos, páginas
web, etc. para poder así dar un mayor dinamismo de lo que se este haciendo en ese momento (página web,
documento, presentaciones, etc.)

Metodo

Implementación de una operación en seudocódigo.

Metodología

Es un enfoque particular, fundado en ciertos principios generales, de orden filosófico; es un modo de

comprender la realidad

Nodo

Elemento físico que existe en tiempo de ejecución y representa un recurso computacional, generalmente tiene
algo de Memoria y a menudo Capacidad de Procesamiento.

Operaciones

Es una acción que un objeto puede realizar.

Paquetes

Un paquete es un elemento de modelo, de propósito general que sirve para organizar los elementos del
modelo en grupos.

Processor

Es un componente de hardware capaz de ejecutar Programas

Red

Conjunto de ordenadores, impresoras y otros medios informáticos conectados entre sí

Requisitos No Funcionales

Son los que no se pueden asociar a ningún caso de uso.

RUP

RUP (Rational Unified Process) es un proceso de desarrollo de software que en forma disciplinada asigna
tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).

Software

Conjunto de programas de ordenador y técnicas Informáticas

SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, compuesto por
comandos, cláusulas, operadores y funciones de agregado. Estos elementos se combinan en las
instrucciones para crear, actualizar y manipular las bases de datos.

Bibliografía

Capítulo 1 y 2: Marco teórico

 UML
Teoría y Diagramas:
  http://kuainasi.ciens.ucv.ve/adsi2010-2/uml/index.html#

Página de UML (esta en inglés):

 http://www.omg.org/gettingstarted/what_is_uml.htm

 Estado del Arte

 http://www.kmkey.com/productos/software_gestion_calidad
 Scrum
 http://www.proyectosagiles.org/graficos-trabajo-pendiente-burndown-charts
 Antecedentes
 Medina, M. (2008), "Sistema Desarrollo de un Sistema de Información para el Registro y
Control de los Materiales y Equipos de la Empresa Venezolana de Construcciones
y Mantenimiento VECHAA, C.A, Maturín Estado Monagas"
 Arias, J. (2007), elaboró un proyecto titulado: "Programa para el Control de Entrada y Salida
de Materiales Escolares y Limpieza del Colegio Internacional Monagas, Maturín Estado
Monagas"
 http://mohamed-tecnologia-ani.blogspot.com/2011/11/capitulo-ii.html

Capítulo 3: Metodología, Análisis y diseño

 http://www.cyta.com.ar/ta0502/b_v5n2a1.htm

 http://www.dtic.ua.es/jdare10/presentaciones/JDARE10-07.pdf

 http://www.icons.es/software-1/37-ingenieria-software/65-desarrollo-agil-scrum

 http://dc376.4shared.com/doc/74duwX4l/preview.html

 http://dc398.4shared.com/doc/emA_aeu2/preview.html

 http://www.taringa.net/posts/info/867068/SCRUM-Desarrollo-Agil-de-Software.html

 http://www.acis.org.co/fileadmin/Base_de_Conocimiento/IV_JornadaGerencia/
JorgeGiraldo_IVJGP.pdf
 http://nuspawn.wordpress.com/programacion-e-ing-de-software/scrum-desarrollo-de-software/