Sunteți pe pagina 1din 136

FACULTAD DE CIENCIAS DE GESTIN

ESCUELA DE INGENIERA DE SISTEMAS

TESIS
DESARROLLO DE UN SISTEMA WEB PARA LA GESTIN DE
ACTIVOS FSICOS TI EN LA UNIVERSIDAD AUTNOMA DEL PER

PRESENTADO POR:
ARTETA MONTOYA REYNALDO JEAN PIERRE
JUSTO PAIPAY ANGEL BYLLY

PARA OPTAR EL TTULO PROFESIONAL


DE INGENIERO DE SISTEMAS

LIMA PER
2014

DEDICATORIAS

Este trabajo est dedicado a Dios quin supo guiarme por el buen camino, darme fuerzas
para seguir adelante y no caer en los problemas que se presentaban.
A mis padres por su apoyo, consejos, comprensin, amor, ayuda en los momentos difciles,
y por ayudarme con los recursos necesarios para estudiar. A mis hermanas por estar
siempre presentes, acompandome para poderme realizar.
Reynaldo Jean Pierre Arteta Montoya

Este trabajo est dedicado a Dios que me di la oportunidad de vivir y de regalarme una
familia maravillosa, con mucho cario principalmente a mis padres que me dieron la vida y
han estado conmigo en todo momento.
Gracias por todo Pap y Mam por darme una carrera para mi futuro y por creer en m,
aunque hemos pasado momentos difciles siempre han estado apoyndome y brindndome
todo su amor, por todo esto les agradezco de todo corazn el que estn conmigo a mi lado.

Angel Bylly Justo Paipay

ii

AGRADECIMIENTOS

Agradezco a Dios, a mis padres y mis hermanas por ser mis guas y estar pendientes
siempre de m; porque sin su ayuda no habra sido posible realizar este proyecto ni ser
alguien en la vida.
Agradezco a mi asesor Ing. Javier Gamboa Cruzado y al Ing. Jusein Quevedo Cabrera por
su tiempo y dedicacin empleados en el desarrollo de este proyecto, y a la vez por todos
sus conocimientos y aportes que han sido de mucha ayuda para cumplir exitosamente con
la elaboracin eficiente de esta tesis.

Reynaldo Jean Pierre Arteta Montoya

Agradezco a Dios, a mis padres por el apoyo constante e incondicional durante la


realizacin de este proyecto, a mis hermanos por el apoyo y compresin por sus consejos
para seguir adelante en mi vida profesional.
Agradezco al Ingeniero Jusein Quevedo Cabrera por su apoyo y tiempo que nos dedic a
pesar de muchas adversidades.
Finalmente agradezco a nuestro asesor Ing. Javier Gamboa Cruzado

Angel Bylly Justo Paipay

iii

RESUMEN
DESARROLLO DE UN SISTEMA WEB PARA LA GESTIN DE
ACTIVOS FSICOS TI EN LA UNIVERSIDAD AUTNOMA DEL
PER
Reynaldo Arteta

Angel Justo

jpierre.arteta@gmail.com

angel.jp.147@gmail.com

En la actualidad, en el Per existe una Gestin de Activos Fsicos TI en el bajo control de


informacin sobre activos fsicos ti, debido a que en el rea no pueden tener un control ms
seguro y exacto mediante un sistema. El proyecto tiene como finalidad brindar un Sistema
Web que se desarrolla para la Gestin de Activos Fsicos TI en la Universidad Autnoma
del Per, que le permite llevar un mejor control de las actividades del rea de Soporte
Tcnico y administrativas que se realizan en la Universidad; as como tambin proteger los
datos y disponer de informacin oportuna y confiable que sea de utilidad para el rea.
La metodologa que se utiliz fue ICONIX, est es una metodologa de desarrollo
del software que se halla a medio camino entre un RUP y un XP, esta metodologa deriva
directamente del RUP y su fundamento es el hecho de que un 80% de los casos pueden ser
resueltos tan solo con un uso del 20% del UML, con lo cual se simplifica muchsimo el
proceso sin perder documentacin al dejar solo aquello que es necesario.
ICONIX se gua a travs de casos de uso y sigue un ciclo de vida iterativo e
incremental. El objetivo es que a partir de los casos de uso se obtenga el sistema final.
La finalidad al implementar el sistema web en el rea de soporte de la universidad
autnoma del Per es contar con una herramienta que interacte con el personal de soporte
tcnico. Y est Gestin de activos fsicos TI.

Palabras Claves: Sistema Web, RUP, ICONIX, Soporte Tcnico, Gestin de Activos
Fsicos TI, Ciclo de Vida Iterativo e Incremental.

iv

ABSTRACT

WEB DEVELOPMENT OF A SYSTEM FOR PHYSICAL ASSET


MANAGEMENT IT IN AUTONOMOUS UNIVERSITY OF PERU
Reynaldo Arteta

Angel Justo

jpierre.arteta@gmail.com

angel.jp.147@gmail.com

Today, in Peru there is a Physical Asset Management in IT under control of information on


physical assets you, because in the area can not be more safe and precise control through a
system. The project aims to provide a Web system that is developed for IT Physical Asset
Management at the Autonomous University of Peru, which allows you to keep better track
of the activities of the area of Technical and Administrative Support performed in the
University; as well as protect data and provide timely and reliable information that is
useful for the area.
The methodology used was ICONIX, is a methodology for software development
that is halfway between RUP and XP, this methodology derives directly from the RUP and
its foundation is the fact that 80 % of cases can only be solved with a use of 20% of the
UML, which greatly simplifies the process without losing documents leaving only what is
necessary.
ICONIX is guided by use cases and follows a cycle of iterative and incremental
life. The aim is that from the use cases for the final system.
Order to implement the system in web support area of the Autonomous University
of Peru is to have a tool to interact with the support staff. And it's IT Physical Asset
Management.

Key Words: Web, RUP, ICONIX , Technical Support, IT Physical Asset Management,
Life Cycle Iterative and Incremental System.

INTRODUCCIN

El presente trabajo de investigacin tiene como objetivo principal desarrollar un Sistema


Web, utilizando la metodologa de Iconix, para mejorar el proceso de Gestin de Activos
Fsicos TI en la Universidad Autnoma del Per.
En todas las organizaciones se realiza la Gestin de Activos Fsicos TI, donde
tienen un registro de forma manual o en Excel, teniendo en cuenta que requieren reducir la
entrega de reportes, numero de reportes solicitados, porcentaje en la exactitud, porcentaje
de malas decisiones tomadas y satisfaccin del usuario. Es importante tambin la visin
histrica de todas las variables analizadas y el anlisis de los datos del entorno. Estos
requerimientos no son difciles de resolver dado que la informacin esta efectivamente en
el Sistema Web, puesto que cualquiera de las actividades que realiza la organizacin est
reflejada en forma minuciosa en la base de datos.
Es fundamental que en toda empresa los procesos estn definidos. Las herramientas
que permiten que los procesos de la empresa puedan ser integrados satisfactoriamente son
las Tctiles, sino que no sera posible manipulacin de los datos (SQL Server 2012).
El presente proyecto consiste en la implementacin de la Gestin de Activos TI a la
Universidad Autnoma del Per, que le permita mejorar el manejo de informacin del
rea. Esto conlleva a que las personas que toman decisiones.
Las limitaciones encontradas en la fase de desarrollo de la aplicacin del Sistema
Web fue que el tiempo para la implementacin y por eso hubo un retraso en la realizacin
de las encuestas y/o entrevistas.

La tesis consta de cinco captulos que se describen a continuacin:


Captulo I Planteamiento Metodolgico: En este captulo se describe el planteamiento
del problema junto con la realidad problemtica, se formula el problema y la justificacin;
adems se plantean los objetivos a cumplir y se desarrolla el marco terico y conceptual
necesario. Se formula la hiptesis y se identifican las variables junto con sus indicadores,
se describe el tipo de estudio y el diseo de investigacin a utilizar. Adems se determina
la poblacin involucrada en la investigacin y se obtiene la muestra que se utilizar para la
recoleccin de datos y se describe los mtodos de anlisis que se utilizarn para la
contratacin de resultados.

vi

Captulo II Marco Referencial: En esta seccin se formula los antecedentes de la


investigacin nacionales e internacionales, como tambin especifica el marco terico sobre
la tesis presentada.
Captulo III Metodologa Desarrollada: En este captulo se detallan las etapas para el
desarrollo del sistema, describiendo los requerimientos y todos los diagramas elaborados.
Captulo IV Anlisis de Resultados y Contrastacin de la Hiptesis: Realiza el
anlisis de resultados y las pruebas de hiptesis y se realiza adems la discusin de
resultados segn las medidas obtenidas.
Captulo V Conclusiones y Recomendaciones: En esta seccin se detallan las
conclusiones y recomendaciones obtenidas durante la investigacin.
Al final presentando las referencias bibliogrficas, anexos, apndices y glosario de
trminos.
Los autores.

vii

NDICE

DEDICATORIAS

ii

AGRADECIMIENTOS

iii

RESUMEN

iv

ABSTRACT

INTRODUCCIN

vi

INDICE

viii

NDICE DE FIGURAS

xii

NDICE DE TABLAS

xii

CAPTULO I: PLANTEAMIENTO METODOLGICO

1.1 PLANTEAMIENTO DEL PROBLEMA

1.1.1 Descripcin de la Realidad Problemtica

1.1.2 Definicin del Problema

1.1.3 Enunciado del Problema

1.2 TIPO Y DISEO DE LA INVESTIGACIN

1.2.1 Tipo de Investigacin

1.2.2 Nivel de la Investigacin

1.3 JUSTIFICACIN E IMPORTANCIA

1.4 OBJETIVOS

1.4.1 Objetivo General

1.4.2 Objetivos Especficos

1.5

HIPTESIS

1.6 VARIABLES E INDICADORES

1.6.1 Variables

1.6.2 Indicadores

1.7 LIMITACIONES DE LA INVESTIGACIN

1.8 DISEO DE INVESTIGACIN

1.9 TCNICAS E INSTRUMENTOS DE INVESTIGACIN

viii

10

CAPTULO II: MARCO REFERENCIAL


2.1 ANTECEDENTES DE LA INVESTIGACIN

13

2.2 MARCO TERICO

17

2.3 ELECCIN DE LA METODOLOGA

39

CAPTULO III: DESARROLLO DEL SISTEMA WEB


3.1 GENERALIDADES

42

3.1.1 Primera Fase: Anlisis de Requerimientos

42

3.1.2 Segunda Fase: Anlisis de Diseo Preliminar

42

3.1.3 Tercera Fase: Diseo Detallado

42

3.1.4 Cuarta Fase: Implementacin

42

3.2 ESTUDIO DE FACTIBILIDAD

43

3.2.1 Factibilidad Tcnica

43

3.2.2 Factibilidad Operativa

43

3.2.3 Factibilidad Econmica

43

3.4

MODELAMIENTO DEL NEGOCIO

44

3.3.1 Descripcin del Negocio


3.5

44

ANLISIS DE REQUERIMIENTOS

50

3.5.1

Requerimientos del Sistema

50

3.5.2

Modelo de Dominio

52

3.5.3

Modelo de Casos de Uso

53

3.6

ANLISIS Y DISEO PRELIMINAR

53

3.6.1

Descripcin de casos de uso

53

3.6.2

Diagrama de Robustez

60

3.7

DISEO DETALLADO

61

3.7.1

Diagrama de Secuencia

61

3.7.2

Diagrama de Clases Final

64

3.7.3

Diagrama de Componentes

65

3.7.4

Diagrama de Despliegue

65

3.8

IMPLEMENTACIN

3.8.1

66

Pruebas del Sistema

66

ix

CAPTULO IV: ANLISIS DE RESULTADOS Y CONTRASTACIN


DE LA HIPTESIS
4.1 UNIVERSO Y MUESTRA

78

4.1.1 Universo

78

4.1.2 Muestra

78

4.2 NIVEL DE CONFIANZA

78

4.3 ANLISIS E INTERPRETACIN DE RESULTADOS

78

4.3.1 Resultados Genricos

78

4.3.2 Resultados Especficos

78

4.3.3 Resultados Numricos

79

4.4 CONTRASTACIN DE LA HIPTESIS

92

CAPTULO V: CONCLUSIONES Y RECOMENDACIONES


5.1 CONCLUSIONES

101

5.2 RECOMENDACIONES

102

REFERENCIAS BIBLIOGRFICAS

103

APNDICES

105

GLOSARIO DE TRMINOS

120

NDICE DE FIGURAS
Figura 01. Ubicacin de la Universidad Autnoma del Per.
Figura 02. Proceso de Gestin de Activos Fsicos TI el rea de Soporte Tcnico de
Universidad Autnoma del Per.
Figura 03. Elementos del Sistema de Informacin.
Figura 04. Niveles del Sistema de Informacin.
Figura 05. Estructura Cliente - Servidor.
Figura 06. Fases del Ciclo de Desarrollo RUP.
Figura 07.Diagramas de Modelos UML.
Figura 08. Diagrama de pruebas.
Figura 09. Modelo de Dominio.
Figura 10. Modelo de Caso de Uso.
Figura 11.Diagrama de Robustez.
Figura 12. Diagrama de Secuencia.
Figura 13. Fases de la Metodologa ICONIX.
Figura 14. Servicio de Educacin de la Universidad Autnoma del Per.
Figura 15. Organigrama de la Universidad Autnoma del Per.
Figura 16. Stakeholders Internos y Externos.
Figura 17. Modelo de Dominio.
Figura 18. Modelo de Casos de Uso.
Figura 19. Registar Componentes TI.
Figura 20. Registrar Componentes TI.
Figura 21. Gestionar Catlogos de Componentes TI.
Figura 22. Gestionar Consultas
Figura 23. Diagrama de Clases Final.
Figura 24. Diagrama de Componentes.
Figura 25. Diagrama de Despliegue.
Figura 26. Pantalla de Registro de Componentes TI
Figura 27. Pantalla de Catlogos de Componentes TI
Figura 28. Nodos prueba P03.
Figura 29. Grafo de Flujo Prueba P03.

xi

3
4
18
19
23
24
27
33
34
35
35
36
37
45
47
48
52
53
60
61
62
63
64
65
65
66
70
75
75

NDICE DE TABLAS
Tabla 01. Datos actuales.
Tabla 02.Inversin en Hardware.
Tabla 03. Inversin en Software.
Tabla 04.Inversin en Personal.
Tabla 05.Usuarios e Interesados.
Tabla 06. Resumen de las necesidades de Usuarios e Interesados.
Tabla 07. Caractersticas generales de los requerimientos.
Tabla 08. Casos de Uso.
Tabla 09.Criterios priorizacin de casos de uso.
Tabla 10.Puntajes de priorizacin de casos de uso.
Tabla 11. Puntajes de priorizacin de casos de uso.
Tabla 12. Clases de equivalencia Prueba P01.
Tabla 13. Casos de Prueba P01.
Tabla 14. Casos de Prueba P02.
Tabla 15. Casos de Prueba P02.
Tabla 16. Casos de Prueba P03.
Tabla 17. Promedio de los indicadores de la Post-Prueba (GC) y Post-Prueba (GE).
Tabla 18. Resultados de Post-Prueba (GC) y Post-Prueba (GE) para el KPI 1.
Tabla 19: Resultados de Post-Prueba (GC) y Post-Prueba (GE) para el KPI 2.
Tabla 20: Resultados de Post-Prueba (GC) y Post-Prueba (GE) para el KPI3
Tabla 21: Resultados de Post-Prueba (GC) y Post-Prueba (GE) para el KPI 4.

xii

5
43
44
44
50
50
51
51
53
54
54
67
69
71
72
76
80
81
83
85
87

CAPTULO I
PLANTEAMIENTO METODOLGICO

Si quieres vivir una vida feliz, tala a una meta,


no a una persona o a un objeto.
Albert Einstein

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

1.1 PLANTEAMIENTO DEL PROBLEMA


1.1.1 Descripcin de la Realidad Problemtica
MUNDIAL
En medio de la crisis econmica, las empresas han tenido que apresurar el paso para
adecuarse a las exigencias de los mercados globales. Este esfuerzo implica repartir la
responsabilidad entre los cuadros directivos y los mandos tcnicos, y adoptar aquellos
recursos y filosofas que han proliferado en las industrias de todo el mundo que
parecen tener por denominador comn un rotundo no a la improvisacin y un
entusiasta s a la competitividad.
Para enfrentar la competitividad global, las empresas deben considerar el enfoque de
la manufactura de clase mundial.
Algunas de las caractersticas que tienen las compaas que se han catalogado como de
clase mundial, son: Toyota, Sony, Hewlett Packard, IBM, Ford, Cementos de Yaqui,
Pepsico, Tecate, etc.
Las compaas de clase mundial utilizan Benchmarking para evaluar y conocer las
polticas y prcticas de la industria a nivel mundial.
PER
Las empresas mantienen registros de materias primas y productos terminados. Los
inventarios de materias primas sirven como entradas al proceso de produccin y los
inventarios de productos terminados sirven para satisfacer la demanda de los clientes
y/o usuarios. Puesto que estos registros representan frecuentemente una considerable
inversin, las decisiones con respecto a las cantidades de inventarios son importantes.
Los modelos de inventario y la descripcin matemtica del sistema constituyen una
base para las decisiones.
Mantener un registro, es tomar decisiones en corto tiempo. Se refiere a la efectividad
que toda empresa busca y/o desea conseguir.
Existen

empresas

que

disean

modelos

matemticos

donde

describen

el

comportamiento del sistema de registros.


Otras empresas, lo realizan de forma manual o usando el Microsoft Office ms
actualizado para poder registrar todos sus datos obtenidos.
Estas formas de registro de activos son vlidas; pero tienen desventajas, sea de baja
efectividad.

-2-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

UNIVERSIDAD AUTNOMA DEL PER


En la actualidad, el objetivo es automatizar todo el proceso de registros de equipos
computacionales de la empresa, debido a los cambios que se han producido en este
tiempo.
El cambio que se desea obtener sobre la informacin referente a los equipos de la
empresa es que sea de forma clara, rpida y efectiva. Tomando en cuenta, que el
control de registros de equipos es una herramienta que permitir ordenar y controlar
un activo importante de la empresa y recursos influyentes en el proceso de productivo.

Figura 01. Ubicacin de la Universidad Autnoma del Per.


1.1.2 Definicin del Problema
En el rea de Soporte Tcnico de la Universidad Autnoma del Per, la problemtica
se debe a la Gestin de Activos Fsicos TI, ya que no cuenta con un sistema para la
recoleccin de datos. Cuando necesitan visualizar un reporte o informacin requerida
en distintos periodos de tiempos. Y no tener la informacin en corto tiempo mostrando
la efectividad lleva a tomar decisiones errneas con respecto a la adquisicin de
productos y mantenimiento. Adems al realizar los reportes requeridos, generalmente
pedidos por cargos superiores, demora mucho tiempo, debido a que este proceso es
casi manual o en Excel. Esta forma de obtener la informacin conlleva a gastos
materiales y sobre todo tiempo.

-3-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

Figura 02. Proceso de Gestin de Activos Fsicos TI en la Universidad Autnoma del


Per.

-4-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

El proceso muestra los siguientes problemas:


No se tiene un control de los Activos Fsicos TI.
Demora en la entrega de reportes solicitados.
Malas decisiones tomadas por parte del Jefe de Soporte Tcnico.
No se tiene exactitud de informacin.
Falta de satisfaccin ante los problemas presentados mediante la gestin de activos
Fsicos TI.
Tabla 01. Datos actuales.
N

Indicadores

Datos de Pre Prueba (Promedio)

El tiempo para generar reportes.

48.24 %

Numero de reportes solicitados por ciclo.

8 reportes/ciclo

Porcentaje en la exactitud de informacin.

48.23 %

Porcentaje de malas decisiones tomadas

55.01 %

Satisfaccin del Usuario

Bajo

1.1.3 Enunciado del Problema


De qu manera el uso del Sistema Web, mejorar la Gestin de Activos Fsicos TI en
la Universidad Autnoma del Per?.

1.2 TIPO Y DISEO DE LA INVESTIGACIN


1.2.1 Tipo de Investigacin
Aplicada, porque el presente trabajo se aplicar la metodologa ICONIX para mejorar
la Gestin de Activos Fsicos TI; donde es una metodologa e desarrollo de software,
basada en la complejidad de anlisis de la metodologa RUP (Rational

Unified

Process) y la practicidad para desarrollar de la metodologa XP (Extreme


Programming).

1.2.2 Nivel de la Investigacin


Experimental, No hay soluciones de Gestin de Activos Fsicos TI del rea de
Soporte Tcnico en la Universidad Autnoma del Per, entonces a travs de tipo
experimental, se aplicara el Sistema Web para un mejor manejo de informacin y
poder reducir tiempo en los reportes.

-5-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

Correlacional, ya que se determinar en qu medida estn relacionadas las variables


dependiente e independiente.
1.3 JUSTIFICACIN E IMPORTANCIA
Las ventajas de automatizar los procesos son numerosas: reducir costos, reducir el trabajo
de los administrativos, satisfacer las expectativas de servicio, reducir al mnimo el tiempo
de entrega y la prdida de informacin.
Verificar el estado en que se encuentran para evitar inconvenientes, como por ejemplo
prdida de informacin o solicitudes doblemente emitidas. De la misma manera controlar
algunos datos especficos del inventario se podr disminuir en gran medida la prdida de
material y el fallo de entregas pendientes.
Representa un avance en el aspecto tecnolgico, ya que el rea, realiza el registro de forma
manual y mediante Excel. Para finalizar se puede decir que este proyecto est motivado a
aplicar los conocimientos adquiridos y dejar un aporte funcional en la Universidad
Autnoma del Per, institucin que nos ha brindado grandes beneficios a lo largo de los
aos de estudio.
El sistema se desarrollar en Visual Studio 2012 como lenguaje de programacin,
empleando SQL Enterprise 2012 como base de datos y Aspx como Servidor Web, por ser
una aplicacin Web las operaciones se pueden realizar desde cualquier punto donde se
tenga acceso a Internet, de este modo las solicitudes u otras operaciones se pueden hacer
con facilidad y rapidez. El Sistema Web, evita la redundancia y prdida de informacin,
disminuye los tiempos de respuesta y lleva un registro minucioso y detallado del inventario
para la mejora del rea y crecimiento de la Universidad.
Conveniencia: Mediante la implementacin del Sistema Web para la Gestin de
Activos Fsicos de TI en la Universidad Autnoma del Per, se proporcionar una
informacin detallada y actualizada que reducir tiempo, ante requerimientos
solicitados a corto plazo.
Relevancia Social: El objetivo de este proyecto es la reduccin de tiempo y la
optimizacin de recursos en el rea de soporte tcnico de la Universidad Autnoma
del Per; este beneficio se ver reflejado en la seguridad y en el control de datos,
mejorando la eficiencia y/o eficacia del personal de soporte tcnico.
Pero no solo se beneficiar el rea de soporte tcnico, tambin tendr un impacto la
universidad mediante la tecnologa implementada.

-6-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

Implicaciones Prcticas: La implementacin del Sistema Web, cubrir los


requerimientos del rea de soporte tcnico, reduciendo tiempo en el proceso de
registro y mantenimiento de computadoras.
Ya que en la actualidad, las diversas organizaciones tienen informacin extensa y
de forma manual. Por consecuencia, el tiempo es mayor ante un requerimiento
solicitado.
La solucin presentada es mediante un Sistema Web, donde se podr optimizar la
informacin, ya que, dicha solucin no es muy vista en otras organizaciones.

1.4 OBJETIVOS
1.4.1 Objetivo General
Desarrollar un Sistema Web orientado a la Gestin de Activos Fsicos TI en la
Universidad Autnoma del Per.
1.4.2 Objetivos Especficos
a) Analizar Requerimientos
b) Analizar y Disear Preliminarmente
c) Disear Detalladamente
d) Implementar las Pruebas.

1.5 HIPTESIS
Si se utiliza el Sistema Web, entonces mejorar la Gestin de Activos Fsicos TI en la
Universidad Autnoma del Per.
1.6 VARIABLES E INDICADORES
1.6.1 Variables
a) Variable Independiente: Sistema Web.
b) Variables dependiente: Proceso de Gestin de Activos Fsicos TI en la
Universidad Autnoma del Per.

1.6.2 Indicadores
Conceptualizacin
Variable Independiente: Sistema Web.

-7-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

Indicador: Presencia Ausencia


Descripcin: Cuando es No, es debido a que el Sistema Web, no existe en la
Universidad Autnoma del Per, y an el problema existe en la institucin. Cuando es
Si, es debido a que se implement el Sistema Web de Gestin de Activo Fsicos TI.

Variables Dependiente: Proceso de Gestin de Activos Fsicos TI en la Universidad


Autnoma del Per.
Indicador

Descripcin

Tiempo para generar reportes

Es el Tiempo que le toma al personal de


Soporte Tcnico en generar reportes.

N reportes solicitados por ciclo


Porcentaje en la exactitud de

Es el Nmero de Reportes solicitados por ciclo.


Es el Porcentaje de exactitud de informacin.

informacin

% de Malas Decisiones tomadas

Es el Porcentaje de Malas Decisiones tomadas


mediante la informacin brindada.

Satisfaccin del Usuario

Es la satisfaccin del Usuario, de acuerdo a la


Gestin de Activos Fsicos TI

Operacionalizacin
Variable Independiente: Sistema Web.
Indicador

ndice

Presencia-Ausencia

No, S

Variables Dependiente: Proceso de Gestin de Activos Fsicos TI en la Universidad


Autnoma del Per.

-8-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

INDICADOR

NDICE

UNIDAD DE
MEDIDA

UNIDAD DE
OBSERVACIN

Tiempo para generar


reportes

[40-55]

Minutos

Reloj

[5-10]

Nmero de Reportes
solicitados por ciclo.

Jefe de Soporte

N reportes solicitados
por ciclo
Porcentaje en la
exactitud de
informacin

Porcentaje de Malas
Decisiones Tomadas

Satisfaccin del
Usuario

[40-60]

[50-60]

% de Exactitud de
informacin.

Jefe de Soporte

% de Malas
Decisiones Tomadas

Jefe de soporte

Jefe de Soporte

Bajo
Regular
Alto

1.7 LIMITACIONES DE LA INVESTIGACIN


Tiempo: Es muy limitado y esto podra alargar el tiempo estimado de nuestro
proyecto.
Recursos Econmicos: Es limitado y podra retrasar el proyecto.

1.8 DISEO DE INVESTIGACIN


Ge X O1
Gc O2
Dnde:

Ge = Grupo Experimental: Es el grupo de estudio al que se aplicar el estmulo


(Sistema Web).

X = Sistema Web: Estmulo o condicin experimental.

-9-

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

Gc = Grupo de Control: Es un grupo de control al que no se aplicar el estmulo


(Sistema Web).

O1 = Datos de la Post-Prueba para los indicadores de la Variable Dependiente una


vez implementado el Sistema Web: Mediciones Post-Prueba del grupo
experimental.

O2 = Datos de la Post-Prueba para los indicadores de la Variable Dependiente una


vez implementado el Sistema Web: Mediciones Post-Prueba del grupo de control.

- = Falta de estmulo o condicin experimental.

Descripcin:
Se trata de escoger de forma intencional de un grupo experimental (Ge), al que se aplicar
un Sistema Web (X), el cual se les aplica a trabajadores del rea de Soporte Tcnico de la
Universidad Autnoma del Per (O1); en un segundo grupo (Gc), conformado de manera
intencional por trabajadores del rea de Soporte Tcnico de la Universidad Autnoma del
Per, donde no se le aplicar el estmulo, sirviendo slo como grupo de control; en forma
simultnea se le aplica una prueba (O2).
Los

dos

grupos estn constituidos de forma intencional pero

representativa

estadsticamente. Tanto en ausencia como en presencia del Sistema Web.


Al finalizar la prueba se espera que los resultados del grupo O1 sean mejores que el O2.

1.9 TCNICAS E INSTRUMENTOS DE INVESTIGACIN


A) Tcnicas e Instrumentos de la Investigacin de Campo
TCNICAS

INSTRUMENTOS

Observacin Directa

Reportes de lo realizado.

Estructurada

Fichas de Observacin de los trabajadores.

No participante
Realizacin de Entrevistas
Estructuradas

Formato de Entrevista.

Espontaneas

Grabaciones.

Aplicacin de Cuestionario
Abierto

Cuestionario (Documento).

Cerrado

- 10 -

CAP. I: PLANTEAMIENTO METODOLGICO

R. Arteta - A. Justo

B) Tcnicas e Instrumentos de la Investigacin Experimental


TCNICAS

Seguimiento del mtodo de registro del

INSTRUMENTOS

Computadora.

personal encargado.

Seguimiento del desempeo del Personal

Fichas de seguimiento.

del rea de soporte tcnico.

Seguimiento del grupo experimental.

Fichas de seguimiento del personal de


soporte tcnico segn mtodos de registro.

C) Tcnicas e Instrumentos de la Investigacin Documental

TCNICAS

INSTRUMENTOS

Revisin de:
Libros

Computadoras

Tesis

Diapositivas

Artculos

Fotocopias

Internet

CD-ROM

Revistas

DVD

Tesis

Libreta de apuntes

Documentacin Estadstica

USB

Base de Datos

Impresiones

- 11 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

CAPTULO II
MARCO REFERENCIAL

Intenta no volverte un hombre de xito,


sino volverte un hombre de valor.
Albert Einstein

- 12 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

2.1 ANTECEDENTES DE LA INVESTIGACIN


1) Autor: Jos Miguel Suniaga Salazar
Ttulo: Desarrollo de una Aplicacin Web basada en Tecnologa HelpDesk para ofrecer
Servicios de Soporte Tcnico e Inventario en la Gerencia de Informtica de la Empresa
C.A. hidrolgica del centro, en valencia estado Carabobo
Resumen:
La Gerencia de Informtica de la empresa C.A. Hidrolgica del Centro, HIDROCENTRO
tiene como objetivo ofrecer a los empleados de la empresa servicios de calidad en el rea
de informacin; desarrollando sistemas ptimos y dando soporte a los recursos
informticos con eficiencia, en el menor tiempo posible. En tal sentido, la Gerencia de
Informtica debe: mantener un control del inventario de los recursos informticos de la
empresa as como de los servicios que se prestan a estos, de manera que se pueda gestionar
los equipos que estn activos y vigilar el desempeo de los servicio de soporte tcnico a
cargo de los empleados de la gerencia. Actualmente, la gerencia lleva este control de
manera manual, es por esa razn que se requiere de un proyecto que permita la
automatizacin de dichos procesos. En este informe de trabajo de grado se presenta el
diseo de un Sistema de Administracin de Inventario y Mantenimiento de Equipos
(SAIME) que apoyar los procesos descritos anteriormente, el cual est modelado y
documentado bajo el Lenguaje Unificado de Modelado (UML), siguiendo la metodologa
RUP.

2) Autor: Vernica Virginia Polanco Garrido


Ttulo: Desarrollo de una aplicacin WEB para soporte de gestin de negocio y manejo
de inventario para la empresa INVERSIONES VPL, C.A
Resumen:
El problema planteado en este estudio se focaliz en la empresa VPL, C.A. y se centr en
los requerimientos establecidos en esta empresa para optimizar los procesos de compra de
mercanca, comercializacin de productos y manejo de inventario por cuanto los mismos
constituyen el manejo crtico del negocio. Esta investigacin cumple con el desarrollo de
una aplicacin ecommerce para agilizar y optimizar los procesos operacionales de la
empresa a travs de una aplicacin WEB. Para el desarrollo de este sistema se sigui la
metodologa del Proceso Unificado para el Desarrollo de Sistemas de Informacin (RUP)
la cual plantea la implementacin de las mejores prcticas apoyado en una arquitectura de

- 13 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

tres (3) capas. La codificacin del sistema se realiz utilizando la Programacin Orientada
a Objetos y finalmente se document la reestructuracin de los procesos a travs del uso de
diagramas UML.
Todos los objetivos planteados en la investigacin fueron alcanzados como producto de la
correcta utilizacin de las herramientas de modelado visual y construccin sistemtica e
iterativa de cada uno de los mdulos del sistema. Finalmente, la presente investigacin
presenta su aporte en el uso de nuevas herramientas de desarrollo de software tal y como lo
es la metodologa RUP, la cual est poco explotada pero con un auge creciente en el
mbito de desarrollo de aplicaciones.

3) Autor: Cecilia Adriana Moreno Cifuentes


Ttulo: Sistema de Gestin y Control del Inventario de Consumo Interno e Inventario
para la Produccin
Resumen:
Este artculo describe el trabajo de grado que realizo la autora para obtener por el ttulo de
Ingeniera en Sistemas Computacionales en la Universidad Tcnica del Norte. La entidad
beneficiaria es el Instituto Superior Tecnolgico de la Industria del Cuero Cotacachi
ISTICC, que forman bachilleres y tecnlogos especialistas en el diseo de calzado,
confecciones y marroquinera. Para la bodega y almacn de insumos del plantel se
desarroll una herramienta informtica, que permita inventariar y optimizar el manejo de
los materiales y materias primas que se utilizan en la planta de produccin y de los
suministros de oficina que se consumen y venden dentro del plantel. El sistema se
denomina SIGCI - Sistema de Gestin y Control de Inventarios de Consumo Interno y
para la Produccin, el mismo que fue desarrollado con herramientas libres; entre ellas, base
de datos MySQL, lenguaje de programacin PHP v.5.0. Se utiliz la metodologa de
desarrollo de software: RUP (Rational Unified Process).

4) Autor: Toribio Helwer Guerra Flores


Ttulo: Desarrollo de un Aplicativo Web basado en Ajax para el Control de Inventarios
Mobiliarios de la Institucin Educativa Pronoe Galileo
Resumen:
El rea de direccin forma la parte principal del organigrama estructural de la institucin
educativa PRONOE GALILEO, tiene como una de sus funciones inventariar sus bienes y

- 14 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

luego presentar los reportes al promotor de la organizacin galileo, las instituciones


educativas particulares mantienen este proceso y las nacionales lo presentan al director del
rea de almacn de la UGEL DEL SANTA teniendo este reporte una estructura fijada.
El presente trabajo, propone realizar un aplicativo web que permita mejorar el control de
los bienes de la institucin educativa PRONOE GALILEO, el cual podra adaptarse a otras
instituciones o ser usada por las UGEL en el Per para controlar los bienes de las
instituciones educativas a cargo.
Aporte:
Este trabajo servir de apoyo en la identificacin de la problemtica de una institucin,
adems del importante uso que tiene la tecnologa para apoyar en la solucin de la misma.

5) Autor: P. Carrin, L. Huamn


Ttulo: Sistema Informtico y Web para los Servicios Acadmicos del Instituto Superior
Pedaggico Privado Talara Basadas en Tecnologas .net.
Resumen:
Se realiz un sistema informtico y web para el instituto superior pedaggico privado
talara. Este sistema informtico permite llevar un mejor control de las actividades
acadmicas que se realizan en el instituto; as como tambin seguridad en los datos y tener
informacin oportuna y confiable que sea de utilidad para las autoridades y personal
administrativo del instituto
Se utiliz el proceso unificado de Rational (RUP) que usa el lenguaje unificado de modelo
UML se realiz una transformacin del modelado de clases al modelo entidad-relacin
para hacer posible la construccin de la base de datos en Microsoft Access
La implementacin se realiz en el Lenguaje de programacin Microsoft visual basic.net y
ASP.NET y el modelado en Rational Suite 2003 Enterprise Edition
Las expectativas

cubiertas por la aplicacin para el rea de secretaria son bastantes

importantes al disminuir el tiempo en la captura de los datos durante el desarrollo de las


matriculas permitiendo anticipar los problemas prevenirlos y no estar detrs de la
ocurrencia de los mismos o de sus consecuencias.

- 15 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

6) Autor: J. Alva, N. Paredes


Ttulo: Desarrollo e Implementacin de un Sistema Web para el Control Acadmico en el
Instituto Superior Pblico Chocope
Resumen:
El sistema web se desarrolla para el control acadmico en el instituto superior pblico
CHOCOPE permite llevar en un mejor control de las actividades acadmicas y
administrativas k se realizan en el instituto as como tambin proteger los datos y disponer
de informacin oportuna y confiable k sea de utilidad para las autoridades personal
administrativo, docente y alumnado e incluso de los apoderados del instituto
La metodologa que se utilizo fue el RUP mediante el cual se realiza una trasformacin del
modelo de clases al modelo entidad-Relacin para hacer posible la construccin de la base
de datos en el gestor SQL server 2000
La implementacin se realiz bajo el lenguaje de programacin Microsoft studio.net en
ASP.NET y el modelado en Rational Rose suite 2003 Enterprise Edition as como
Macromedia Mx 2004 para el diseo. La aplicacin cubre todos los requerimientos del rea
de secretaria de registros acadmicos la cual es la ms importante para el control
acadmico permitiendo apoyar decididamente en la funcin de esta rea y prevenir
problemas acadmicos a raz de un registro que no ajuste a los requerimientos establecidos
por el instituto.

7) Autor: Oscar Samuel Gmez Snchez


Ttulo: Campus virtual mvil para mejorar el Acceso a la Informacin Acadmica
Universitaria
Resumen:
La presente investigacin, tiene como finalidad brindar un Campus Virtual Mvil a la
Universidad Csar Vallejo que le permita mejorar el acceso a la informacin acadmica de
los alumnos.
Aporte:
Este trabajo servir de gua para conocer la metodologa ICONIX y realizar una buen
procedimiento de dicha metodologa.

- 16 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

8) Autor: Alejandro Antonio Lpez Romero


Ttulo: Diseo de un sistema de informacin basado en Aplicacin Web que permita la
automatizacin del control de activos informticos del distrito Cabrutica, divisin faja
Pretolffera del Orinoco
Resumen:
En la siguiente investigacin se realiz un estudio del sistema actual de las actividades que
se llevan a cabo para el control de los activos informticos del Distrito Cabrutica, ubicado
en San Diego de Cabrutica en el estado Anzotegui. A raz de este estudio se describieron
los subsistemas involucrados en el proceso, as como tambin las actividades que se
desarrollan en la administracin del inventario; y se comprobaron algunas deficiencias
relacionadas en el proceso de control de los activos, lo cual genera una labor poco
eficiente. Por esta razn, se plante el diseo de un sistema de informacin que agilice los
procedimientos dentro del departamento de soporte integral especficamente a la parte
relacionada al control de activos, de forma que optimice la capacidad de respuesta a
cualquier problemtica que se presente, disminuyendo las horas hombres y evitando
duplicidad en la informacin. Luego se procedi a realizar el anlisis correspondiente a los
requerimientos necesarios para el diseo del sistema, se utiliz la herramienta del lenguaje
unificado de modelado (UML), el cual se basa en la elaboracin de un conjunto de
diagramas con el fin de establecer la estructura del software del proyecto, mostrando las
clases, sus operaciones y atributos, as como las relaciones que existen entre cada una de
ellas. Finalmente se utiliz el lenguaje WebML para mejor visualizacin a la hora de
realizar el diseo de las interfaces. El producto final de la realizacin de este trabajo result
en un sistema de informacin propio y automatizado, permitir la mejor gestin de la
informacin, reducir el tiempo de bsqueda, la disminucin de errores y de esta forma
aumentar la productividad da a da del departamento de soporte integral.
2.2 MARCO TERICO
A) Sistema de Informacin
Definicin
Un Sistema de Informacin (SI) es considerado como un conjunto de componentes
interrelacionados que recuperan, procesa, almacenan y distribuyen informacin para
soportar la toma de decisiones, la coordinacin y el control de una organizacin.1
1

Suniaga, J. Desarrollo de una Aplicacin Web basada en Tecnologa Helpdesk, 2009, p.45.

- 17 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Los sistemas de informacin buscan cumplir tres objetivos bsicos dentro de las
organizaciones:
Automatizacin de procesos operativos.
Proporcionar informacin que sirva de apoyo en la toma de decisiones.
Lograr ventajas competitivas a travs de su implementacin y uso.

Objetivos
1. Proporcionar datos oportunos y exactos que permitan tomas decisiones acertadas y
mejorar la relacin entre los recursos de la empresa.
2. Garantizar informacin exacta y confiable, as como su almacenamiento de tal
forma que est disponible cuando se necesite.
3. Servir como herramienta para que los gerentes realicen planeacin, control y toma
de decisiones en sus empresas. 2
Elementos
Procedimientos, es el modo de ejecutar determinadas acciones que suelen realizarse
de la misma forma, con una serie comn de pasos claramente definidos, que
permiten realizar una ocupacin o trabajo correcto.
Informacin, es un conjunto organizado de datos procesados, que constituyen un
mensaje sobre un determinado ente.
Usuarios, de un producto informtico (hardware o software), es la persona a la que
va destinada dicho producto una vez que ha superado las fases de desarrollo
correspondientes.
Equipos, lo necesario para la comunicacin, el procesamiento y el almacenamiento
de la informacin.

Figura 03. Elementos del Sistema de Informacin.

Laudon, K. Laudon, J. Sistemas de Informacin Gerencial., 2004, p. 52.

- 18 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Adems, los tipos de SI dan servicios a los diferentes niveles de una organizacin:
Sistemas a Nivel Operativo,

Supervisan las actividades elementales y las

transacciones de la organizacin. El propsito principal es responder a preguntas de


rutina y dar seguimiento a las transacciones a travs de la organizacin.
Sistemas a Nivel de Conocimiento, Son el apoyo al conocimiento y trabajo con
datos en la empresa. El propsito es ayudar a los negocios a integrar nuevos
conocimientos en l y controlar el flujo del trabajo.
Sistemas a Nivel Administrativo, Sirven a las actividades de supervisin, control,
toma de decisiones y administrativas de los gerentes del nivel medio. El propsito
principal es contestar la pregunta de estn funcionando bien las cosas? Adems de
Qu pasara si...?
Sistemas a Nivel Estratgico, Ayudan a la alta gerencia a crear e implantar nuevas
estrategias y tendencias a largo plazo. El propsito principal es parear los cambios en
el ambiente externo con las capacidades organizacionales existentes.

Figura 04. Niveles del Sistema de Informacin.

Tipos
Sistemas de Procesamiento de Transacciones (SPT), son los sistemas bsicos de
negocio que dan servicio al nivel operativo de la organizacin. Un sistema de
procesamiento de transacciones es un sistema computarizado que efecta y registra las
transacciones diarias necesarias para dirigir negocios.
Sistemas de Trabajo del Conocimiento y Sistemas de Oficina (STC), provee la
informacin necesaria en el nivel de conocimiento de una organizacin. Su trabajo

- 19 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

consiste en crear informacin nueva y conocimientos para ser integrados correctamente


en la organizacin.
Sistemas de Informacin Gerencial (SIG), reportan las operaciones bsicas de la
empresa, es decir, los estados financieros y de resultados y sus respectivos anexos.
Sistemas de Apoyo a la Toma de Decisiones (SAD), ayuda a los gerentes a tomar
decisiones

que son nicas, cambian rpido y no se proveen fcilmente por

adelantado. Son interactivos, el gerente puede simular situaciones y cambiar


variables.
Sistemas de Apoyo Ejecutivo (SAE), son sistemas de informacin a nivel
estratgico de la organizacin diseados para abordar la toma de decisiones no
estructurada mediante grficos y comunicaciones avanzadas. Las decisiones no
rutinarias requieren juicio, evaluacin y comprensin por que no existen
procedimientos estndares para llegar a una solucin.

B) Sistema Web
Definicin
Son aquellos que no son desarrollados sobre una plataforma o sistema operativo, sino que
se administra en un servidor sobre una Intranet y/o Internet.
La diferencia con las pginas web es que tienen bases de datos con un interfaz ms
amigable.3
Caractersticas
Acceso desde cualquier ubicacin con conexin a internet.
Utilizacin en redes internas.
Seguridad basada y roles de acceso.
Disponibilidad las 24 horas.
Informacin actualizada constantemente.
Multi Usuario.
Multi idioma.4
Ventajas
Independencia de la plataforma (Windows Linux, etc)
3

Lujn, S. Programacin de aplicaciones web: historia, principios bsicos y clientes web. 2002. p. 63
https://sites.google.com/site/hguaymas/servicios3

- 20 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Acceso a travs de internet.


Rpido, distribuido, escalable.
Tecnologas open source sin costos de licencia.
Desventajas
Depende de la conexin a internet
Requerimientos de hardware intermedios.
Tipos de Sistema Web
ERP - Enterprise Resource Planning
Planificacin de recursos empresariales, son sistemas de informacin que integran
todos los datos y procesos de una organizacin en un nico sistema.
CRM - Customer Relationship Management
Es la gestin de la relacin con los clientes a travs del conocimiento de sus hbitos
y necesidades de consumo.
BI - Business Intelligence
Es un tipo de sistema que realiza anlisis detallados y bsqueda de informacin
estratgicas en grandes bases de datos para toma de decisiones en las empresas.
B2B - Business To Business
Es un principio un concepto que describe negocios entre empresas. Un Sistema B2B
permite que empresas conversen electrnicamente con otras empresas, esas
conversaciones pueden ser operaciones de compra y venta, prestacin de servicios,
entre otros.
B2C - Business To Consumer
Es ms conocido como comercio electrnico y describe las operaciones electrnicas
realizadas entre una empresa productora, distribuidora o prestadora de servicios a un
consumidor final.
WEB 2.0 - Sistema Colaborativo
Uno de los ms recientes conceptos es la web 2.0. Aunque no exista una definicin
muy exacta para ese tipo de sistema, el que mejor le queda es el de un sistema
colaborativo, donde los usuarios generan, clasifican, distribuyen y utilizan la
informacin al mismo tiempo.5

5 http://www.informatica-hoy.com.ar/aprender-informatica/Tipos-de-sistemas-para-empresas-ERP-CRM-B2B-y-mas.php

- 21 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Elementos
Aplicacin Web
En la ingeniera de software se denomina aplicacin web a aquellas aplicaciones que
los usuarios pueden utilizar accediendo a un servidor web a travs de Internet o de
una intranet mediante un navegador. En otras palabras, es una aplicacin software
que se codifica en un lenguaje soportado por los navegadores web en la que se confa
la ejecucin al navegador.
Las aplicaciones web son populares debido a lo prctico del navegador web como
cliente ligero, a la independencia del sistema operativo, as como a la facilidad para
actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de
usuarios potenciales.
World Wide Web
La Red informtica mundial, es un sistema de distribucin de informacin basado en
hipertexto o hipermedios enlazados y accesibles a travs de Internet. Con un
navegador web, un usuario visualiza sitios web compuestos de pginas web que
pueden contener texto, imgenes, vdeos u otros contenidos multimedia, y navega a
travs de ellas usando hiperenlaces.
Interfaces
Las interfaces web tienen ciertas limitaciones en las funcionalidades que se ofrecen
al usuario. Los desarrolladores web generalmente utilizan lenguajes interpretados
(scripts) en el lado del cliente para aadir ms funcionalidades, especialmente para
ofrecer una experiencia interactiva que no requiera recargar la pgina cada vez (lo
que suele resultar molesto a los usuarios). Recientemente se han desarrollado
tecnologas para coordinar estos lenguajes con las tecnologas en el lado del servidor.
Por ejemplo, AJAX es una tcnica de desarrollo web que usa una combinacin de
varias tecnologas.
Servidor Web
Un servidor web o servidor HTTP, es un programa informtico que procesa una
aplicacin del lado del servidor realizando conexiones bidireccionales y/o
unidireccionales y sncronas o asncronas con el cliente generando o cediendo una
respuesta en cualquier lenguaje o aplicacin del lado del cliente. El cdigo recibido
por el cliente suele ser compilado y ejecutado por un navegador web. Para la

- 22 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

transmisin de todos estos datos, suele utilizarse algn protocolo. Generalmente se


utiliza el protocolo HTTP para estas comunicaciones.
Cliente - Servidor
La arquitectura cliente-servidor es un modelo de aplicacin distribuida en el que las
tareas se reparten entre los proveedores de recursos o servicios, llamados servidores,
y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa,
el servidor, que le da respuesta. Esta idea tambin se puede aplicar a programas que
se ejecutan sobre una sola computadora, aunque es ms ventajosa en un sistema
operativo multiusuario distribuido a travs de una red de computadoras.

Figura 05. Estructura Cliente - Servidor.


Navegador Web.
Es una aplicacin que opera a travs de Internet, interpretando la informacin de
archivos y sitios web. A su vez nos permite acceder al contenido de las webs, blogs,
foros, galeras fotogrficas, etc.
El navegador interpreta el cdigo, HTML generalmente, en el que est escrita la
pgina web y lo presenta en pantalla permitiendo al usuario interactuar con su
contenido y navegar hacia otros lugares de la red mediante enlaces o hipervnculos.

C) RUP
Definicin
El Proceso Unificado Rational (Rational Unified Proccess en Ingls, conocido como RUP)
es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado
UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
- 23 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Su objetivo es asegurar la produccin de software de alta calidad que satisfaga la necesidad


del usuario final dentro de un tiempo y presupuesto previsible. Es una metodologa de
desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la
arquitectura.6

Caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y


cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

Dirigidos por casos de uso

Incremental

Reduce el costo de riesgo a los costos de un solo incremento

Fases
La estructura dinmica de RUP es la que permite que este sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas.7

Figura 06. Fases del Ciclo de Desarrollo RUP.


6

http://es.scribd.com/doc/51486224/rup

http://fabianbermeop.blogspot.com/2010/12/metodologia-rup-desarrollo-de-software.html

- 24 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Fase de Inicio
Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las
actividades de modelamiento de la empresa y en sus requerimientos.
Fase de Elaboracin
Durante esta fase de elaboracin, las interacciones se centran al desarrollo de la base
de diseo, encierran ms los flujos de trabajo de requerimientos, modelo de la
organizacin, anlisis, diseo y una parte de implementacin orientada a la base de la
construccin.
Fase de Construccin
Se lleva a cabo la construccin del producto por medio de una serie de iteraciones las
cuales se seleccionan algunos casos de uso, se redefine su anlisis y diseo y se
procede a su implantacin y pruebas. En esta fase se realiza una pequea cascada
para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva
implementacin del producto.
Fase de Transicin
La fase final busca garantizar que se tiene un producto preparado para su entrega al
usuario final. Dependiendo del tipo de proyecto podr requerir de entornos
intermedios para su correcta validacin, antes de su pasea produccin.
D) UML
Definicin:
Es una tcnica de modelado, no una metodologa o el caso de modelamiento Arquitect,
muchas personas tienen esa confusin, espero despus de esta clara explicacin no haya
lugar a dudas.
Permite la especificacin, visualizacin, construccin y documentacin de los elementos
de un sistema software, tambin se utiliza en el modelado de procesos de negocio u otros
sistemas no-software. Este lenguaje es una notacin calificado por la OMG como tcnica
de modelado estndar.8
Elementos:
Elementos Estructurales
Son los nombres de los modelos UML, en su mayora son las partes estticas de un modelo
y representan cosas conceptuales o materiales.
8

Rosa Menndez Mueras. Construccin de Software Orientado Objetos con el Proceso Unificado y UML, un punto de vista

prctico. Lima: Consejo Editorial UCCI; 2005.

- 25 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Clases, es una descripcin de un conjunto de objetos que comparten los


mismos atributos, operaciones, relaciones y semntica.
Interfaz, describen el comportamiento parcial o completo visible externamente
de un elemento por medio de una coleccin de operaciones.
Colaboracin, Es una sociedad de roles y otros elementos que cooperan para
dar un comportamiento mayor que la suma de los comportamientos de sus
elementos.
Casos de Uso, es una descripcin de un conjunto de secuencias de acciones
que un sistema ejecuta y que produce un resultado observable de inters para
un actor particular.
Clase Activa, es una clase cuyos objetos tienen uno o ms procesos o hilos de
ejecucin por lo y tanto pueden dar lugar a actividades de control. Una clase
activa es igual que una clase, excepto que sus objetos representan elementos
cuyo comportamiento es concurrente con otros elementos. Se representa igual
que una clase, pero con lneas ms gruesas.
Componentes, es una parte fsica y reemplazable de un sistema que conforma
con un conjunto de interfaces y proporciona la implementacin de dicho
conjunto. Un componente representa tpicamente el empaquetamiento fsico de
diferentes elementos lgicos, como clases, interfaces y colaboraciones.
Nodo, es un elemento fsico que existe en tiempo de ejecucin y representa un
recurso computacional que, por lo general, dispone de algo de memoria y, con
frecuencia, de capacidad de procesamiento. Un conjunto de componentes
puede residir en un nodo y puede migrar de un nodo a otro.
Elementos de Comportamiento
Los elementos de comportamiento son las partes dinmicas de un modelo. Se podra
decir que son los verbos de un modelo y representan el comportamiento en el tiempo
y espacio. Los principales elementos son los que a continuacin se mencionan:
Iteracin, Comprende un conjunto de mensajes que se intercambian entre un
conjunto de objetos, para cumplir un objetivo especfico.
Mquinas de Estados, Especifica la secuencia de estados por los que pasa un
objeto o una interaccin, en respuesta a eventos.

- 26 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Actividad, es un comportamiento que especifica la secuencia de pasos que


ejecuta un proceso computacional, a un paso de una actividad se denomina
accin.
Elementos de Agrupacin
Los elementos de agrupacin son las partes organizativas de los modelos de UML.
Slo hay un elemento de agrupacin:
Paquete, Sirve para organizar elementos en grupos. Un paquete es puramente
conceptual (slo existe en tiempo de desarrollo).
Elementos de Anotacin
Los elementos de anotacin es la explicacin de los modelos de UML. Son
comentarios que se pueden aplicar para describir, clarificar y hacer observaciones
sobre cualquier elemento de un modelo.
Nota, es simplemente un smbolo para mostrar restricciones y comentarios
junto a un elemento o una coleccin de elementos. Se utilizan para adornar los
diagramas con restricciones o comentarios que se expresan mejor en texto
informal o formal.
Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma
que un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de
diagramas que normalmente se usan en pequeos subconjuntos para poder representar las
cinco vistas principales de la arquitectura de un sistema.

Figura 07.Diagramas de Modelos UML.

- 27 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Diagramas de Casos de Uso


Los diagramas de casos de uso, describen las relaciones y las dependencias entre un
grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no estn pensados para
representar el diseo y no puede describir los elementos internos de un sistema.
Los diagramas de casos de uso, sirven para facilitar la comunicacin con los futuros
usuarios del sistema y con el cliente, resultan especialmente tiles para determinar las
caractersticas necesarias que tendr el sistema.
Diagramas de Secuencia
En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se
utiliza un diagrama para cada llamada a representar. Es imposible representar en un
solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se
escoge un punto de partida. El diagrama se forma con los objetos que forman parte de
la secuencia, estos se sitan en la parte superior de la pantalla, normalmente, en la
izquierda se sita al que inicia la accin. De estos objetos sale una lnea que indica su
vida en el sistema. Esta lnea simple, se convierte en una lnea gruesa cuando
representa que el objeto tiene el foco del sistema, es decir cuando l est activo.
Diagramas de Comunicacin
Los diagramas de colaboracin muestran las interacciones que ocurren entre los
objetos que participan en una situacin determinada. Esta es ms o menos la misma
informacin que la mostrada por los diagramas de secuencia, pero destacando la forma
en que las operaciones se producen en el tiempo, mientras que los diagramas de
colaboracin fijan el inters en las relaciones entre los objetos y su topologa.
Los diagramas de colaboracin, estn indicados para mostrar una situacin o flujo,
programas especficos; y son unos de los mejores tipos de diagramas para demostrar o
explicar rpidamente un proceso dentro de la lgica del programa.
Diagramas de Clases
Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un
sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de
clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se
crea el diseo conceptual de la informacin que se manejar en el sistema, y los
componentes que se encargarn del funcionamiento y la relacin entre uno y otro. En

- 28 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

un diagrama de clases se pueden distinguir principalmente dos elementos: clases y sus


relaciones.
Diagramas de Objetos
Forma parte de la vista esttica del sistema. En este diagrama se modelan las
instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones,
pero en un momento concreto del sistema. Estos diagramas contienen objetos y
enlaces. En los diagramas de objetos tambin se pueden incorporar clases, para
mostrar la clase de la que es un objeto representado.
Diagramas de Estado
Muestran una mquina de estados compuesta por estados, transiciones, eventos y
actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy
importantes a la hora de modelar el comportamiento de una interfaz, clase o
colaboracin.
Diagramas de Actividades
Los diagramas de actividad describen la secuencia de las actividades en un sistema.
Los diagramas de actividad son una forma especial de los diagramas de estado, que
nicamente (o mayormente) contienen actividades.
Diagramas de Componentes
Se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las
dependencias entre un conjunto de componentes. No es necesario que un diagrama
incluya todos los componentes del sistema, normalmente se realizan por partes. Cada
diagrama describe un apartado del sistema.
En el diagrama de componentes situaremos libreras, tablas archivos, ejecutables y
documentos que formen parte del sistema. Uno de los usos principales es que puede
servir para ver que componentes pueden compartirse entre sistemas o entre diferentes
partes de un sistema.
Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y
los componentes que residen en ellos. Muestran la vista de despliegue esttica de una
arquitectura y se relacionan con los componentes ya que, por lo comn, los nodos
contienen uno o ms componentes.

- 29 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Diagrama de Interaccin
Los diagramas de interaccin toman los elementos esenciales de los diagramas de
objetos y los reestructuran para enfocarlos a la lectura de los mensajes en orden. El
orden se indica mediante la posicin vertical, siendo el primer mensaje el de la parte
superior y el ltimo el de la parte inferior. Por tanto no necesitan nmeros de
secuencia. Los diagramas de interaccin son mejores que los diagramas de objetos
para capturar la semntica de los escenarios en un momento temprano del ciclo de
desarrollo.
Diagrama de Estructura Compuesta
Un diagrama de estructura compuesta es un diagrama que muestra la estructura interna
de un clasificador, incluyendo sus puntos de interaccin a otras partes del sistema.
Esto muestra la configuracin y relacin de las partes que juntas realizan el
comportamiento de clasificador contenido.
Los elementos de clase han sido descriptos en gran detalle en la seccin en los
diagramas de clase. Esta seccin describe la forma en que las clases se pueden mostrar
como elementos compuestos exponiendo interfaces y conteniendo puertos y partes.
Diagrama de Paquetes
Muestra cmo un sistema est dividido en agrupaciones lgicas mostrando las
dependencias entre esas agrupaciones. Dado que normalmente un paquete est
pensado como un directorio, los diagramas de paquetes suministran una
descomposicin de la jerarqua lgica de un sistema.
Los Paquetes estn normalmente organizados para maximizar la coherencia interna
dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con
estas lneas maestras sobre la mesa, los paquetes son buenos elementos de gestin.
Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre
ellos pueden indicar el orden de desarrollo requerido.
Diagrama de Tiempos
Un diagrama de tiempos o cronograma es una grfica de formas de onda digitales que
muestra la relacin temporal entre varias seales, y cmo vara cada seal en relacin
a las dems.
Un cronograma puede contener cualquier nmero de seales relacionadas entre s.
Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o
nivel bajo, de cada una de las seales en cualquier instante de tiempo especificado, y
- 30 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

el instante exacto en que cualquiera de las seales cambia de estado con respecto a las
restantes.
El propsito primario del diagrama de tiempos es mostrar los cambios en el estado o la
condicin de una lnea de vida (representando una Instancia de un Clasificador o un
Rol de un clasificador) a lo largo del tiempo lineal. El uso ms comn es mostrar el
cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o
estmulos aceptados. Los eventos que se reciben se anotan, a medida que muestran
cundo se desea mostrar el evento que causa el cambio en la condicin o en el estado.9

E) Metodologa XP
La metodologa XP (Extreme Programming) tiene como principal objetivo adaptarse a los
cambios de requisitos en cualquier punto de la vida del proyecto.10
Caractersticas:
Desarrolladores y usuarios se comunican directamente para establecer los requisitos
del sistema.
Los diseos elaborados en el sistema deben ser sencillos para un fcil uso del
usuario.
Se puede realizar retroalimentaciones a los procesos, aunque ya se haya iniciado.
Se puede reutilizar el cdigo, para ello se puede crear patrones de forma estndar.
Fases
Fase 1: Planificacin del Proyecto
a. Historias de usuario: En primer lugar se debe definir las historias de usuario con los
interesados. Estas historias tienen el mismo propsito que los casos de uso pero con
diferencias. El tiempo ideal para crear una historia de usuario es de 1 a 3 semanas.
b. Release planning: Es la fase en la cual los desarrolladores y usuarios decretan los
tiempos de implementacin ideales de las historias de usuario, el orden en el que sern
implementadas y cules sern las historias que se implementaran en cada versin del
sistema.
c. Iteraciones: Al comienzo de cada iteracin los clientes seleccionaran que historias de
usuario de las que definieron anteriormente van a ser implementadas. Las historias de

http://es.wikipedia.org/wiki/Diagrama_de_tiempos
Beck, Kent. Planning Extreme Pogramming.Addison Wesley; 2000.

10

- 31 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

usuario se dividen en tareas entre 1 a 3 das de duracin cada una, y se asignarn a los
programadores.
d. Velocidad del proyecto: Es una cantidad que representa la rapidez con la que se
desarrolla el proyecto; para estimarla se debe contar el nmero de historias de usuario
que pueden llegar a ser implementadas en una iteracin; as se sabr el nmero de
historias pueden ser desarrolladas en las diferentes iteraciones.
e. Programacin en pareja: Involucra a dos programadores trabajando equipo; mientras
uno de ellos codifica centrndose ms en la calidad de la funcin o mtodo que est
implementando, el otro analiza si ese mtodo o funcin est bien diseado y es
adecuado. Gracias a esto se consigue un cdigo y diseo con gran calidad.
f. Reuniones diarias: Es importante que los programadores se renan diariamente y
presenten sus problemas, soluciones e ideas en conjunto.

Fase 2: Diseo
a. Diseos simples: Se debe pretender hacer todo el anlisis lo menos complejo posible
para conseguir un diseo sencillamente entendible e implementable.
b. Glosarios de trminos: Usar glosarios de trminos y una correcta especificacin de los
nombres de mtodos y clases ayudar a comprender el diseo y facilitar sus
posteriores ampliaciones y la reusabilidad del cdigo.
Funcionalidad extra: No se debe agregar funcionalidades extras al sistema, por ms
que se piense que luego sern utilizadas, ya que solo el 10% de ellas ser utilizado, lo
que manifiesta que el desarrollo de una funcionalidad adicional es un mal uso de
tiempo y recursos.
c. Refactorizar: Pretende evaluar de nuevo los cdigos para asegurar su ptimo
funcionamiento.
d. Tarjetas CRC: El uso de las tarjetas CRC (Class, Responsabilities and Collaboration)
permiten al desarrollador centrarse y apreciar la programacin orientada a objetos.
Fase 3: Codificacin
Crear pruebas que evalen el funcionamiento de los distintos cdigos implementados nos
ayudara a desarrollar dicho cdigo. Crear estas pruebas antes nos permitir saber qu es
claramente lo que tiene que hacer el cdigo que debemos implementar y aseguraremos que
una vez implementado aprobar dichas pruebas sin problemas.

- 32 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Fase 4: Pruebas
Uno de los pilares de la metodologa XP es el uso de pruebas para evaluar el
funcionamiento del cdigo que se est desarrollando.

Figura 08. Diagrama de pruebas.

F) ICONIX
Es un proceso simplificado en comparacin con otros procesos ms tradicionales, que
unifica un conjunto de mtodos de orientacin a objetos con el objetivo de englobar todo el
ciclo de vida de un proyecto.
ICONIX est adaptado a los patrones y ofrece el soporte de UML, dirigido por casos de
usos y es un proceso iterativo e incremental que est entre la complejidad del RUP y la
simplicidad y pragmatismo del XP (Extreme Programming), sin eliminar las tareas de
anlisis y de diseo que XP no contempla. Presenta claramente las actividades de cada fase
y exhibe una secuencia de pasos que deben ser seguidos.11
Caractersticas:
Iterativo e incremental: Diversas iteraciones suceden entre el desarrollo del modelo
del dominio y la identificacin de los casos de uso. El modelo esttico es
incrementalmente refinado por los modelos dinmicos.
Trazabilidad: cada paso est referenciado por algn requisito. Se define trazabilidad
como la capacidad de seguir una relacin entre los diferentes artefactos producidos.
Dinmica del UML: La metodologa ofrece un uso dinmico del UML como los
diagramas del caso de uso, diagramas de secuencia y de colaboracin.

11

Rosenberg, Doug. 2005. Agile Development with ICONIX. s.l. : Apress, 2005.

- 33 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Fases:
Anlisis de Requerimientos
a. Requerimientos funcionales: Define lo que el sistema debe ser capaz de hacer. En el
inicio del proyecto, junto con el cliente, los usuarios finales, y las diversas partes
interesadas del proyecto, se debe crear un gran documento lleno con los requisitos
funcionales.
b. Modelo de Dominio: Su objetivo es asegurarse de que todos en el proyecto
comprendan el espacio del problema en trminos sin ambigedades. El modelo de
dominio define el alcance y forma base sobre la que se deben construir sus casos de
uso. Es un diagrama con los objetos que existen relacionados con el proyecto y sus
relaciones.

Figura 09. Modelo de Dominio.


c. Modelo de Casos de Uso: Est compuesto por los actores, el mismo sistema y los
casos de uso. Aqu se establece como debe interactuar el usuario con el sistema,
para precisar qu informacin desean intercambiar y describir lo que desean
obtener como resultado.

- 34 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Figura 10. Modelo de Caso de Uso.

Anlisis y diseo preliminar


d. Descripcin de Casos de Uso: Los casos de uso describen el comportamiento de un
sistema bajo la forma de acciones y reacciones desde el punto de vista de un usuario;
adems permiten definir los lmites del sistema y las relaciones que existen entre el
sistema y el entorno del mismo.
e. Diagramas de Robustez: En el cual se ilustran grficamente las interacciones entre
aquellos objetos participantes de un caso de uso. Los que pueden ser; Objetos de
interfaz, Objetos entidad, Objetos de Control.

Figura 11.Diagrama de Robustez.

- 35 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Diseo detallado
a. Diagrama de Secuencia: Es el centro del modelo dinmico del sistema y muestra
los caminos alternos que pueden tomar los casos de uso, a la vez se especifica el
comportamiento y las representaciones que se concentran sobre la expresin de las
interacciones. Este diagrama est compuesto de 4 elementos que son: el curso de
accin, los objetos, los mensajes y los mtodos.
b. Diagrama de clases Final: se revisa el diagrama de clases anterior y de acuerdo a
ello se mejora para elaborar el diagrama de clases final que se utilizar para la
implementacin.

Figura 12. Diagrama de Secuencia.


Implementacin
a. Generar el Cdigo: Lo importante de la interactividad, la accesibilidad y la navegacin
en el sistema harn que el usuario se sienta cmodo y seguro al hacer uso de la
aplicacin sin problemas. Pero adems se debe tener en cuenta la extensibilidad, la
confiabilidad y la reusabilidad del sistema.
Pruebas: Para garantizar esto se realizan diferentes tipos de pruebas que permitirn
verificar la aceptacin de los resultados.12
12

Rosenberg, Doug. 2005. Agile Development with ICONIX. s.l. : Apress, 2005.

- 36 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Figura 13. Fases de la Metodologa ICONIX.

G) Proceso de Gestin de Activos Fsicos TI


Proceso
Un proceso es un conjunto de actividades planificadas que implican la participacin de un
nmero de personas y de recursos materiales coordinados para conseguir un objetivo
previamente identificado. Se estudia la forma en que el Servicio disea, gestiona y mejora
sus procesos (acciones) para apoyar su poltica y estrategia y para satisfacer plenamente a
sus clientes y otros grupos de inters.
Puede informalmente entenderse como un programa en ejecucin. Formalmente un
proceso es "Una unidad de actividad que se caracteriza por la ejecucin de una secuencia
de instrucciones, un estado actual, y un conjunto de recursos del sistema asociados".
Para entender lo que es un proceso y la diferencia entre un programa y un proceso, A. S.
Tanenbaum propone la analoga "Un cientfico computacional con mente culinaria hornea
un pastel de cumpleaos para su hija; tiene la receta para un pastel de cumpleaos y una
cocina bien equipada con todos los ingredientes necesarios, harina, huevo, azcar, leche,
etctera." Situando cada parte de la analoga se puede decir que la receta representa el
programa (el algoritmo), el cientfico computacional es el procesador y los ingredientes
Rosenberg, Doug y Stephens, Matt. 2007. Use Case Driven Object Modeling with UML. s.l. : Addison-Wesley, 2007.

- 37 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

son las entradas del programa. El proceso es la actividad que consiste en que el cientfico
computacional vaya leyendo la receta, obteniendo los ingredientes y horneando el pastel.13
Mantenimiento de Computadoras
Cuando se habla de mantenimiento a una computadora, se refiere a las medidas y acciones
que se toman para mantenerla funcionando adecuadamente, sin que se cuelgue (trabe) o
emita mensajes de errores con frecuencia. Existen dos tipos de mantenimiento que se le
puede aplicar a una computadora:
Mantenimiento Preventivo: Aquel que se le aplica a una PC para evitar futuros errores y
problemas tcnicos, como por ejemplo: buscar y eliminar virus del disco duro, buscar y
corregir errores lgicos y fsico en el disco, desfragmentar el disco, limpiar la tarjeta madre
y dems tarjetas para evitar fallas tcnicas por el polvo, etc.
Mantenimiento Correctivo: Aquel que est orientado al diagnstico y reparacin del
equipo cuando se presenta un problema tcnico.14
Proceso de Gestin de Activos Fsicos TI
El procedimiento de Gestin mantenimiento equipos de tecnologa, se realiza en la Oficina
de Registro de Instrumentos Pblicos, ubicada en crculo registral de la ciudad, donde al
ciudadano se le brinda el acceso al servicio pblico registral con oportunidad, efectividad,
transparencia, seguridad y cobertura.
El Registro y Mantenimiento de Proveedores es un directorio de los posibles
proveedores interesados en ofrecer bienes o servicios a la Universidad.
Todo proveedor a ser seleccionado en el proceso de adquisicin deber estar registrado en
la ficha de Proveedores. Es requisito indispensable para la inscripcin en la ficha de
Proveedores de la universidad anexar los siguientes recaudos: fotocopia del Registro
Mercantil, fotocopia del RIF y NIT, balance general y sus anexos, solvencias de: impuesto
sobre la renta, SSO, INCE e impuestos municipales.
Quedar descalificado un proveedor que no cumpla con los requisitos mnimos exigidos.
Se eliminar un proveedor en los casos que incumplan regularmente con las normas
establecidas por ambas partes en la calidad y la entrega de los bienes, materiales o
servicios ofrecidos.15

13

Oscar Casasola Romero. Introduccin a UML. Programacin en Castellano. Espaol; 2010.

14

http://www.proulex.com/computo/oe/doc/mantenimiento-win7.pdf

15

http://www.ucv.ve/fileadmin/user_upload/vrad/documentos/DPP/Manuales/Manuales/Adquisicion__Bienes_SIAF.pdf

- 38 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

2.3 ELECCIN DE LA METODOLOGA

Para la eleccin de la metodologa a utilizar y evitar la subjetividad, se asignar


valores del rango de 1 a 5 para los criterios de evaluacin seguidamente detallados:

Bibliografa: Mide la existencia de informacin con relacin a la descripcin y


aplicacin de la metodologa

Flexibilidad: Se refiere a que si la metodologa puede adaptarse a cualquier


situacin o entorno y ver si se puede hacer variantes de acuerdo al problema.

Compatibilidad: Si el desarrollo de la metodologa puede ser aplicado a otros


proyectos relacionados con el mismo tema.

Requerimientos: Si la metodologa captura los requerimientos adecuados y


correctos de los usuarios.

Costo: Se refiere a cunto costar desarrollar esa metodologa

Tiempo de desarrollo: Se refiere al tiempo que demanda realizar el desarrollo de


la metodologa.

El presente cuadro tiene como finalidad evaluar las metodologas para el desarrollo de
esta investigacin, por lo cual se han tenido en cuenta la siguiente escala de
puntuacin:

5 - Excelente
4 - Bueno
3 - Regular
2 - Malo
1 - Deficiente

- 39 -

CAP. II: MARCO REFERENCIAL

R. Arteta - A. Justo

Valorizacin de las Metodologas


Criterios de Evaluacin

RUP

XP

ICONIX

Bibliografa

Flexibilidad

Compatibilidad

Requerimientos

Costo

Tiempo de desarrollo

TOTAL

25

26

27

* Los puntajes han sido obtenidos de la encuesta aplicada a expertos en desarrollo de sistemas (Anexo 3).

Conclusin de la Eleccin:
La metodologa a utilizar ser ICONIX debido a que nos da mayor flexibilidad,
compatibilidad y demandar menos tiempo en el desarrollo; todo ello sin dejar de lado
que es menos costosa y que se puede obtener los requerimientos de los usuarios de
manera ptima.

- 40 -

CAPTULO III
DESARROLLO DEL SISTEMA
WEB

El aprendizaje es experiencia, todo lo dems es


informacin.
Albert Einstein

-41-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.1 GENERALIDADES
La Construccin del Sistema Web para la Gestin de Activos Fsicos TI en la Universidad
Autnoma del Per, se ha basado en la metodologa ICONIX, que consta de cuatro fases.
3.1.1 Primera Fase: Anlisis de Requerimientos
En esta etapa se realizar los requerimientos funcionales, el modelo de dominio donde
contiene objetos de la vida real de los cuales se debe almacenar su comportamiento o
datos, los modelos de casos de uso donde se establezca la interaccin del usuario con
el sistema.
3.1.2 Segunda Fase: Anlisis de Diseo Preliminar
Se describir los casos de uso percibidos entre los usuarios y el sistema, se disear
etapas para identificar los que sean de alta prioridad, despus se iniciar la gestin de
recursos segn la evaluacin.
Luego se realizar el diagrama de robustez cuyo objetivo ser

agregar nuevas

relaciones a los diagramas de clase, donde se obtendr una estructura aceptable de la


arquitectura.
Segn los pasos realizados en esta fase, se mejorar dejando listo para el diagrama de
clases para la siguiente fase
3.1.3 Tercera Fase: Diseo Detallado
En esta fase se crear los diagramas de secuencia, los cuales derivan de la descripcin
de casos de uso. Despus de finalizado el diagrama y mejorar lo de la fase anterior
sobre el diagrama de clases.
3.1.4 Cuarta Fase: Implementacin
En esta ltima fase se realizan plan de pruebas mediante dos tcnicas, caja negra y caja
blanca.
Donde la tcnica de caja negra, realiza pruebas sobre los casos de uso evaluados segn
su prioridad, tambin pruebas de clases de equivalencia sobre lo que el sistema realiza
y las fallas que presentara en caso de malos ingresos.
La tcnica de caja blanca, realiza pruebas mediante los casos de uso del sistema segn
las validaciones del cdigo e identificacin de nodos como tambin la prueba de
caminos bsicos para la identificacin del cdigo en el sistema web.

- 42-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.2 ESTUDIO DE FACTIBILIDAD


3.2.1 Factibilidad Tcnica
Este proyecto es factible tcnicamente, ya que la Universidad Autnoma del Per
cuenta con la tecnologa necesaria para la implementacin del Sistema Web.
Cuenta con el apoyo de servidores actualizados para el manejo de la base de datos y
que puedan verificar mediante la web.
3.2.2 Factibilidad Operativa
Este proyecto es factible operativamente, porque se tiene conocimientos previos de la
implementacin a realizar.
Adems, se sigue investigando para mejor desenvolvimiento dentro y fuera del
proyecto de investigacin.
La Universidad Autnoma del Per S.A.C, nos facilitar toda la informacin que se
requiera, y colocar con todos los aspectos necesarios para la satisfactoria culminacin
del mismo.
3.2.3 Factibilidad Econmica
Este proyecto es factible econmicamente, ya que el rea de soporte tcnico muestra
conformidad con la implementacin del proceso de registro y mantenimiento de
computadoras para la implementacin de una nueva tecnologa en la Universidad
Autnoma del Per.
Tabla 02.Inversin en Hardware.
Recursos

Descripcin

Cantidad

Precio
Unitario (S/.)

Total ( S/.)

Modelo: Hp COMPAQ
6200
Computadora

Procesador: Core i5 2.5


Ghz

2,500.00

2,500.00

200.00

200.00

Memoria RAM: 4 Gb
Disco Duro: 500 GB
Impresora

Hp Deskjet 2050
Costo Total

- 43-

2,700.00

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Tabla 03. Inversin en Software.


tem

Descripcin

Licencia

Cantidad

Costo (S/.)

Total (S/.)

Windows 7 Professional

Incluida

1000.00

1000.00

Antivirus

Incluida

100.00

100.00

Incluida

900.00

900.00

Empresa

0.00

0.00

Empresa

0.00

0.00

Microsoft Office
Professional 2013
Microsoft Visual Studio
2012
Microsoft SQL Server
2012

2000.00

Costo Total
Tabla 04.Inversin en Personal.
Personal

Cantidad

N de Meses

Pago Mensual

Total

Programador

2,500.00

5,000.00

Costo Total

3.3

5,000.00

MODELAMIENTO DEL NEGOCIO

3.3.1 Descripcin del Negocio


La Universidad Autnoma del Per se crea gracias a la gestin de su Promotora,
Asociacin Civil Intelectus, en mrito a un proyecto concebido y elaborado en
cumplimiento de las normas establecidas por el Consejo Nacional para la Autorizacin de
Funcionamiento de Universidades CONAFU.
El proyecto se present en enero de 2006 y luego de un riguroso proceso de evaluacin, se
emite la Resolucin N 335 2007 CONAFU que autoriza por unanimidad el
funcionamiento de nuestra Universidad, para formar profesionales en las carreras de
Administracin, Contabilidad, Derecho, Ingeniera de Sistemas y Psicologa.
La Universidad Autnoma del Per se dise para atender la formacin de profesionales
en el mbito geogrfico pluricultural de Lima Metropolitana. Tiene como perspectiva la
Acreditacin Universitaria sobre la base de una elevada cultura de calidad, teniendo como
eje la inclusin acadmica, cientfica y profesional, para constituirse en valioso referente
del desarrollo del talento humano.

- 44-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Misin:
Formamos personas y profesionales ntegros, responsables y competitivos, capaces de
resolver problemas en un entorno globalizado, participando activamente en el desarrollo de
la sociedad y de la ciencia, contribuyendo a una sociedad justa y equitativa a travs de una
educacin de calidad basada en propuestas innovadoras en el marco de principios y valores
universales y en la generacin de recursos propios.
Visin:
La Universidad Autnoma del Per ser reconocida en la formacin de personas y
profesionales ntegros, lderes, competitivos e innovadores, segn los estndares
internacionales de calidad, para contribuir al desarrollo sostenido.
Servicios, Competidores y Clientes:
Servicios: Educacin
Garantizar la calidad de enseanza a los alumnos y todo esto es posible gracias a su
Sistema de instruccin modular avanzada, Sistema nico y exclusivo de la nuestra
universidad, el cual involucra una educacin interactiva entre docentes y alumnos a
travs de la utilizacin de equipos multimedia en el 100% de las aulas y laboratorios
de clase.

Figura 14. Servicio de Educacin de la Universidad Autnoma del Per.

- 45-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Competidores:
Universidad Cientfica del Sur, Untecs, UPIG, Universidad Ricardo Palma, UPC

Clientes:
Personas que han terminado la secundaria, por segunda profesin, personas por
convalidacin, traslado externo.

- 46-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

ORGANIGRAMA DE LA UNIVERSIDAD AUTNOMA DEL PER:

Figura 15. Organigrama de la Universidad Autnoma del Per.

- 47-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

STAKEHOLDERS INTERNOS Y EXTERNOS:

Figura 16. Stakeholders Internos y Externos.

- 48-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

CADENA DE VALOR: EDUCACIN - UNIVERSIDAD AUTNOMA DEL PER:

- 49-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.4 ANLISIS DE REQUERIMIENTOS


3.4.1 Requerimientos del Sistema
3.4.1.1 Visin del sistema
A. Introduccin
A continuacin se describen las necesidades de los usuarios e interesados en el
Sistema Web para la Gestin de Activos Fsicos TI a la Universidad Autnoma
del Per, y las caractersticas que debe tener.

B. Descripcin de Usuarios e interesados


Tabla 05.Usuarios e Interesados.
ROL
Personal de Soporte
Jefe de Soporte

DESCRIPCIN
Es el interesado de gestionar y registrar los componentes.
Es el interesado de consultar informacin sobre los registros
de componentes.

C. Necesidades de Usuarios e Interesados


Tabla 06. Resumen de las necesidades de Usuarios e Interesados.
ID
NEC-01

DESCRIPCIN
El Sistema deber permitir registrar las fechas de bajas de los componentes
TI.

NEC-02

El Sistema deber registrar las reas de los componentes de mantenimiento.

NEC-03

El Sistema deber registrar el usuario de donde se realiz el mantenimiento.

NEC-04

El sistema deber permitir consultar e informar sobre las actividades segn lo


requerido.

NEC-05

El Sistema deber permitir ingresar los datos de os componentes TI.

NEC-06

El Sistema deber permitir grabar.

NEC-07

El Sistema deber permitir consultar los registros.

NEC-08

El Sistemas deber permitir generar en PDF interno y envi a un correo


especfico.

-50-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

D. Caractersticas generales
Tabla 07. Caractersticas generales de los requerimientos.
ID
Car-01

DESCRIPCIN
El Sistema debe mostrar al Jefe de Soporte

las fechas del registro de

mantenimiento.

Car-02

El Sistema debe mostrar el registro de componentes.

Car-03

El sistema debe mostrar el lugar donde se realiza el mantenimiento.

Car-04

Car-05

El Sistema deber permitir registrar las condiciones de los componentes TI


(Proyector).
El Sistema deber permitir registrar los documentos de garanta de
componentes.

Car-06

El Sistema deber grabar y generar un PDF interno.

Car-07

El Sistema deber permitir mostrar un catlogo.

Car-08

El Sistema deber permitir avisar la aproximacin de los proyectores.

Car-09

El Sistema deber permitir ingresar el rea donde se realiza el mantenimiento.

Car-10
Car-11
Car-12

El Sistema deber permitir revisar seleccionar el rea donde se realiza el


mantenimiento.
El Sistema deber permitir enviar al corporativo (soporte).
El Sistema deber permitir Consultar al jefe de Soporte mostrar donde se
realiz el mantenimiento.

E. Casos de Uso derivados de las caractersticas


Tabla 08. Casos de Uso.
Car-01
CU-01
Car-01
CU-02

Consultar fecha de mantenimiento.

Registrar Componentes TI.

Car-03 Car 12 Car -10 CU-03

Gestionar Consultas

Car04- Car05

Registrar condiciones de garanta de los

Cu- 04

componentes TI.

- 51-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Car 06 Car 11

Visualizar un PDF interno y enviar al correo

CU-05

corporativo (soporte).

Car 07

Gestionar catlogo de componentes TI.

CU-06
Car08

Alertar aproximacin de horas de los proyectores

CU-07

3.4.2 Modelo de Dominio


class Domain Model

Recurso
Personal Soporte
-

0..* -

Registra

Usuario: varchar
Contrasea: int

Descripcion: varchar
Tipo: int
Ubicacion: int
Catalogo
-

0..*

Descripcion: int

0..1

Registra
0..*

0..*

0..*
Visualiza

Consulta
Consulta
-

Descripcion: int
Fecha: int

Pertenece
1

Pertenece

Jefe Soporte
0..*

Pertenece
Recibe
1
Componentes
-

Nombre: varchar
Mantenimiento: int

Anuncio (PDF)

1
1

Pertenece

Descripcion: int

0..*

Figura 16. Modelo de Dominio.

- 52-

0..*

Usuario: int
Contrasea: int

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.4.3 Modelo de Casos de Uso


uc Use Case Model

Consultar Catalogo

Registrar los
Componentes TI
Consular Fecha

Registrar Condicion y
Garantia de Componentes TI

Jefe de Soporte

Personal de Soporte
Consultar Lugar

Visualizar un PDF y Env iar al


correo corporativ o
Registrar y Alertar
aproximacion de horas de
los proyectores

Figura 17. Modelo de Casos de Uso.

3.5 ANLISIS Y DISEO PRELIMINAR


3.5.1 Descripcin de casos de uso
Para la descripcin de casos de uso y las siguientes etapas de anlisis y diseo
se realizaran los dos casos de uso de alta prioridad, para lo cual se ha evaluado
segn la siguiente tabla de priorizacin:
Tabla 09.Criterios priorizacin de casos de uso.
CRITERIO

PESO

RANGO

RI: Riesgo; Tecnolgico , complejo ,nuevo, etc.

03

S.A: Significativo para la arquitectura

03

NC: Naturaleza critica de valor para el negocio

03

Segn estos criterios se ha evaluado los casos de uso de acuerdo a las


necesidades expresadas por los usuarios del sistema, asignndose las siguientes
calificaciones:

- 53-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Tabla 10.Puntajes de priorizacin de casos de uso.


Requisito

RI

SA

NC

Puntaje

Registrar Componentes TI.

18

Gestionar catlogo de componente TI.

15

Consultar lugar de mantenimiento.

Gestionar consultas.

10

Iniciar Sesin.

Consultar alertas.

Generar PDF.

Enviar Correo Electrnico.

Segn esta evaluacin se ha dividido los casos de uso en Alta Media o Baja
prioridad:

Tabla 11. Puntajes de priorizacin de casos de uso.


Prioridad

Requisito

Comentario

Registrar Componentes TI
Implementacin de mayor
dificultad, su prioridad en
ALTA

Gestionar Catlogo de Componentes TI

la estructura del sistema y


la necesidad por parte de
los usuarios es alta

Gestionar consultas

MEDIA

Procesos

Consultar alertas

medianamente

importantes, con

- 54-

CAP. III: DESARROLLO DEL SISTEMA WEB

Prioridad

R. Arteta - A. Justo

Requisito

Comentario
dificultad de

Generar PDF

implementacin media.

Enviar Correo: Corporativo

Consultar lugar de mantenimiento


BAJA

De fcil implementacin,
efecto

mnimo

en

la

estructura del sistema

Iniciar Sesin

De acuerdo a esta evaluacin se comienza la descripcin de los casos de uso de alta


prioridad:
IDENTIFICADOR:

NOMBRE:

R:CU-02

Registrar Componentes TI

CATEGORA:

COMPLEJIDAD:

PRIORIDAD:

Core

Alta

Alta

ACTORES:
Personal de Soporte
Jefe de Soporte
PROPSITO:
Permite gestionar el registro de los componentes, modificar las cantidades de componentes.
PRECONDICIN:
El caso de uso Iniciar sesin debe haberse ejecutado.
El caso de uso Consultar el mantenimiento realizado por rea,
FLUJO BSICO:
B1. El actor selecciona la opcin Registrar
B2. El sistema muestra una ventana con una lista de componentes guardados de acuerdo al
registro.

- 55-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

IDENTIFICADOR:

NOMBRE:

R:CU-02

Registrar Componentes TI

POSCONDICION:
El sistema muestra caractersticas de cada componente.
El sistema registra los componentes
El sistema genera y enva al correo corporativo (Soporte)
FLUJOS ALTERNATIVOS:
A1. Gestionar recurso de componentes TI
A1.1. Luego del paso B2 del flujo bsico, personal de Soporte o el Jefe soporte
seleccione una de las carpetas existentes donde desee guardar un registro (el personal de
soporte no podr emitir reporte)
A1.2. El sistema muestra en una nueva pantalla los campos que deben llenar para
registrar (descripcin de cada componentes, como tambin los mantenimientos
realizados por reas.
A1.3. El personal de Soporte o el Jefe de Soporte ingresan las descripciones de los
componentes.
A1.4. El Sistema grabara al ingresar los datos correspondientes
A1.5. El Flujo retorna al paso B2 del Flujo bsico
A2. Modificar estado del registro
A2.1. Luego del paso B2 del flujo bsico, el personal de soporte o jefe de soporte
seleccione un recurso.
A2.2 El Sistema muestra una ventana con las propiedades del componente TI
A2.3. El actor seleccionara un generador para PDF y poder enviar el correo Corporativo
A2.4. El sistema actualiza el estado del recurso
A2.5. El flujo retorna al paso B2 flujo bsico
A3. Eliminar y Modificar los componentes TI
A3.1. Luego del paso B2 del flujo bsico, el personal de soporte o jefe de soporte
seleccione un componente
A3.2. El sistema muestre una ventana con las propiedades del componente (marca
modelo registrar los mantenimientos de Pcs por rea y aulas)
A3.3. El actor selecciona la opcin eliminar, modificar.
A3.4. El sistema elimina / modifica el componente TI

- 56-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

IDENTIFICADOR:

NOMBRE:

R:CU-02

Registrar Componentes TI

A3.5. El flujo retorna al paso B2 del flujo bsico.

PROTOTIPO EXPLORATORIO

IDENTIFICADOR:

NOMBRE:

R:CU-06

Gestionar Catlogo de Componentes TI

CATEGORA:

COMPLEJIDAD:

PRIORIDAD:

Core

Alta

Alta

ACTORES:
Personal de Soporte
Jefe de Soporte
PROPSITO:
Permite gestionar el registro de nuevos y antiguos componentes por rea.
PRECONDICIN:
El caso de uso Iniciar sesin debe haberse ejecutado.
El caso de uso Consultar Registro,
FLUJO BSICO:

- 57-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

IDENTIFICADOR:

NOMBRE:

R:CU-06

Gestionar Catlogo de Componentes TI

B1. El actor selecciona Catalogo


B2. El sistema muestra una ventana de registro
POSCONDICION:
El sistema muestra el registro
El sistema registra
El sistema modifica
El sistema elimina
FLUJOS ALTERNATIVOS:
A1.1 Luego del paso B2 del flujo bsico, el jefe de personal de soporte selecciona la opcin.
A1.2 El sistema genera un PDF con el registro de los componentes TI.
PROTOTIPO EXPLORATORIO

- 58-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

IDENTIFICADOR:

NOMBRE:

R:CU-03

Gestionar Consulta

CATEGORA:

COMPLEJIDAD:

PRIORIDAD:

Core

Alta

Alta

ACTORES:
Personal de Soporte
Jefe de Soporte
PROPSITO:
Permite gestionar consultas de los componentes TI y generar a un PDF.
PRECONDICIN:
El caso de uso Iniciar sesin realizar consultas correspondientes.
El caso de querer mandar un correo con las consultas genera un PDF y se habilita para poder
enviar un correo,
FLUJO BSICO:
B1. El actor selecciona la opcin Consultar datos
B2. El sistema muestra una venta de las caractersticas de la consulta.
POSCONDICION:
El sistema muestra caractersticas de cada componente TI y los trabajos de mantenimiento
realizados.
El sistema genera un PDF para poder informar los trabajos realizados.
FLUJOS ALTERNATIVOS:
A1.1 Gestiona las consultas de los recursos de los componentes..
A1.2 Gestionar la consulta de los mantenimientos realizados por rea.
A1.3 Aproximar las horas de los proyectores para poder realizar a tiempo el mantenimiento
necesario..
A1.4 Gestionara un PDF para informar las acciones realizadas. (Enviar correo)

- 59-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.5.2 Diagrama de Robustez


class Data Model

Interfaz Registro

Propiedades de
Mantenimiento

Interfaz Mantenimiento

Personal Soporte

Gestionar
Mantenimiento

Gestionar
Mantenimiento

Consultar
Componentes

Gestionar
Componentes

Componentes

Componentes

Consultar Garantia de
Componentes
Registro de
Componentes

Jefe deSoporte

Interfaz de
Mantenimiento

Figura 18. Diagrama de Robustez: Registrar Componentes TI.

- 60-

Genera PDF

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.6 DISEO DETALLADO


3.6.1 Diagrama de Secuencia
a) Caso de Uso : Registrar Componentes TI

Figura 19. Registrar Componentes TI.

- 61-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

b) Caso de Uso : Gestionar Catlogos de Componentes TI

Figura 20. Gestionar Catlogos de Componentes TI.

- 62-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

c) Caso de Uso : Gestionar Consultar

Figura 21. Gestionar Consultar

- 63-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.6.2 Diagrama de Clases Final

Figura 22. Diagrama de Clases Final.

- 64-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.6.3 Diagrama de Componentes

cmp Component Model

library
Seuss.dll

Fuente.aspx.v b
Interface
Dal_Soporte

BdDatos

Figura 23. Diagrama de Componentes.

3.6.4 Diagrama de Despliegue


deployment Diagrama de Despliegue

Serv idor Web

Internet Information
Serv ices
Serv idor de Base de Datos

Interface
BDDatos
TCP/IP

DAL_Soporte.v b

Figura 24. Diagrama de Despliegue.

-65-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

3.7 IMPLEMENTACIN
3.7.1 Pruebas del Sistema
3.6.1.1 Plan de Pruebas
Se realizarn dos tipos de pruebas para dar validez a la gestin de activos fsicos
TI, las cuales se detallan a continuacin:
A. Prueba Funcional Tcnica de Caja Negra
Prueba P01: Caso de uso Registrar Componentes TI
Esta funcionalidad del sistema permite tanto al personal de soporte como al jefe
de soporte registrar componentes TI dentro del interfaz. El registro puede ser por
Modelo, Marca, Serie, Tipo, Sub-Tipo.
Adems para registrar un componente TI debe ingresar obligatoriamente todos
los datos requeridos para que se guarde.

Figura 25. Pantalla de Registro de Componentes TI

- 66-

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Clases de equivalencia P01:


Tabla 12. Clases de equivalencia Prueba P01.
CONDICIN

CLASE VLIDA

CLASE NO VLIDA

Si se selecciona en la opcin 1: Cualquier opcin que 2: Cualquier opcin nueva


de empresa, este se debe tenga
seleccionar

de que

del Per S.A.C.

Si se selecciona la Marca, se 3:
debe seleccionar una opcin.

tenga

seleccionar

Cualquier

un

nombre

Universidad

Autnoma del Per S.A.C.


opcin 4: No se selecciona ninguna

seleccionado.

Si se selecciona el Modelo, 5:
debe

nombre

Universidad Universidad Autnoma diferente

Autnoma del Per S.A.C.

se

el

opcin.

Cualquier

opcin 6: No se selecciona ninguna

una seleccionado.

opcin.

opcin.
El N de Serie es una cadena 7: Cualquier cadena del 8: Cualquier descripcin del
de un carcter como mnimo N de serie que tenga N de Serie que tenga ms de
y con un mximo de 20 como mnimo un carcter 20 caracteres o sea un campo
caracteres,

y 20 como mximo.

vaco.

Si se seleccin una fecha, 9: Cualquier fecha que 10: Cualquier fecha que no
este

debe

ser

segn

el tenga el calendario.

tenga el calendario.

calendario mostrado.
Si se selecciona el estado, se 11:
debe seleccionar una opcin.

debe

seleccionar

opcin 12: No se selecciona ninguna

seleccionado.

Si se selecciona la condicin, 13:


se

Cualquier

opcin.

Cualquier

opcin 14: No se selecciona ninguna

una seleccionado.

opcin.

condicin segn el estado.


Si se presiona el botn 15:

Guarda,

Guardar, debe cumplir con completado

los

solo 16:

No

Guarda,

falta

datos completar datos en la interfaz.

los requisitos de completar requeridos por el sistema.


todos los datos.
Si se registra una descripcin 17: cualquier descripcin 18: Cualquier descripcin del
de asociado, este debe tener del asociado que tenga asociado que tenga ms de 12
un mximo de 12 caracteres como mnimo un carcter caracteres numricos o sea un
numricos.

y 12 como mximo.

- 67-

campo vaco.

CAP. III: DESARROLLO DEL SISTEMA WEB

R. Arteta - A. Justo

Si presiona el botn Buscar, 19: Buscar, solo habiendo 20: No Busca, falta los datos,
debe relacionarse o tener datos en la asociacin.

para la asociacin.

datos en asociado para poder


realizar la bsqueda.
Si se presiona el botn 21:
asociar,
con

debe

relacionarse habiendo

Asociada

bsqueda

Asociar,

para

solo 22:

No

relacionado relacionar.

la Asociado a, Buscar.

poder

registrar lo asociado.

- 68-

Asocia,

falta

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Casos de Prueba P01:


Tabla 13. Casos de Prueba P01.

-69-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Prueba P02: Caso de uso de Catlogos de Componentes TI


Esta funcionalidad del sistema permite al Jefe de Soporte Tcnico realizar consulta sobre
los catlogos de componentes TI. Como tambin poder agregar, modificar y eliminar
componentes que sean necesarios.

Figura 26. Pantalla de Catlogos de Componentes TI

-70-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Clases de equivalencia P02:


Tabla 14. Casos de Prueba P02.

CONDICIN

CLASE VLIDA

CLASE NO VLIDA

Si se selecciona en la opcin 1: Cualquier opcin que 2: Cualquier opcin nueva


de empresa, este se debe tenga
seleccionar

el

nombre

de que

tenga

Universidad Universidad Autnoma del diferente

Autnoma del Per S.A.C.

Per S.A.C.

Si selecciona una de las 3:

un

nombre

Universidad

Autnoma del Per S.A.C.

Cualquier

opcin 4: No se selecciona ninguna

opciones de Maquinarias y seleccionado.

opcin.

Equipos y otras unidades, se


puede modificar o eliminar.
Si se registra un nuevo 5: Cualquier descripcin que 6: Cualquier descripcin que
correlativo,
ingresar

tiene
la

se

descripcin

como

nueva carcter

descripcin.
Si

que tenga

mnimo
mximo

un tenga ms de 20 caracteres o
20 no

caracteres.
modifica
del

se

ingrese

ninguna

descripcin.

una 7: cualquier descripcin que 8: Cualquier descripcin que

catlogo, tenga

como

mnimo

un tenga ms de 20 caracteres,

este debe tener un mximo carcter y 20 caracteres o que sea igual al que tena
de 12 caracteres.

como

mximo,

que

sea anteriormente.

diferente al anterior.
Si se selecciona una opcin 9:
del estado

opcin 10:

seleccionado.

Si se modifica la opcin 11:


correlativo.

Cualquier

No

se

selecciona

ninguna opcin.

cualquier

nuevo 12:

Cualquier

nuevo

correlativo que tenga como correlativo que tenga ms de


mnimo un carcter y 20 12 caracteres, o que sea
caracteres como mximo, igual
que sea diferente al anterior.

Si se elimina un componente 13:


TI.

Cualquier

seleccionado.

al

que

anteriormente.

opcin 14:

No

se

ninguna opcin.

- 71-

tena

selecciona

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Casos de Prueba P02:


Tabla 15. Casos de Prueba P02.

- 72-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

B. Prueba Funcional Tcnica de Caja Blanca


Prueba P03: Caso de uso Registrar Componentes TI:
El siguiente mtodo se ejecuta al hacer click en Grabar, aqu se realizan las
validaciones ya especificadas en la Prueba P01:

function Grabar_Registro_Partes() {
var cPerJuridica = $("#cboFilial").val();
var cMarca = $("#CboMarca").val();
var cModelo = $("#CboModelo").val();
var cNumeroSerie = $("#TxtNumeroSerie").val();
var cFechaInicio = $("#TxtFechaInicio").val();
var nEstado = $("#CboEstado").val();
var nCondicion = $("#CboCondicion").val();
if (cPerJuridica == -1) {
msgbox("Alerta", "Seleccione una Empresa", "alerta");
} else if (cMarca == -1) {
msgbox("Alerta", "Seleccione una Marca", "alerta");
} else if (cModelo == -1) {
msgbox("Alerta", "Seleccione un Modelo", "alerta");
} else if (cNumeroSerie.length == 0) {
msgbox("Alerta", "Ingrese un Numero de Serie al Registro de Partes", "alerta");
} else if (cFechaInicio.length == 0) {
msgbox("Alerta", "Ingrese un Fecha de Inicio de Funciones al Registro de Partes",
"alerta");
} else if (nEstado == -1) {
msgbox("Alerta", "Seleccione un Estado del Registro de Partes", "alerta");
} else if (nCondicion == -1) {
msgbox("Alerta", "Seleccione una Condicion del Registro de Partes", "alerta");
} else {
//progressbar(cDivNombre);
$.ajax({
type: "POST",
url: "Patrimonio/Pa_Marcas.aspx/RegistrarPartes",
data: "{nIntCodigo:" + nIntCodigo + ",nIntClase:" + nIntClase + ",cIntJerarquia:'" +
cIntJerarquia + "',cIntNombre:'" + cIntNombre + "',cIntDescripcion:'" + cIntDescripcion +
"',nIntTipo:" + nIntTipo + ",cPerJuridica:'" + cPerJuridica + "',cIntJerarquiaAnterior:'" +
cIntJerarquiaAnterior + "',cIntDescripcionAnterior:'" + cIntDescripcionAnterior + "',nOperacion:"
+ nOperacionUpdate + ",nOpcion:" + nOpcion + "}",
contentType: "application/json; charset=utf-8",
dataType: "json",
async: false,
success: function (data) {
if (data.d == 0) {
msgbox("Exito", "El Registro de Partes Se ha Actualizado con Exito", "exito");
Actualiza_Transaccion(nOperacionUpdate, "Registro de Partes: " +
cIntDescripcion)
} else if (data.d == 1) {
msgbox("Alerta", "El Registro de Partes ya tiene Registrados varias Partes de la
Misma Caracteristica", "alerta");
} else if (data.d == 2) {
msgbox("Alerta", "El Registro de Partes no Tiene Ninguna Caracteristica

-73-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Especial", "alerta");
} else {
msgbox("Error", "La operacin de Registro de Partes no se ha realizado", "error");
}
},
error: function (msg) { msgbox("Error", "UAWEB a detectado un error. Consulte con el
administrador del sistema", "error"); }
});
}
}

Identificacin de nodos:
function Grabar_Registro_Partes() {
var cPerJuridica = $("#cboFilial").val();
var cMarca = $("#CboMarca").val();
var cModelo = $("#CboModelo").val();
var cNumeroSerie = $("#TxtNumeroSerie").val();
var cFechaInicio = $("#TxtFechaInicio").val();
var nEstado = $("#CboEstado").val();
var nCondicion = $("#CboCondicion").val();
1
if (cPerJuridica == -1) {
msgbox("Alerta", "Seleccione una Empresa", "alerta");
2
} else if (cMarca == -1) {
msgbox("Alerta", "Seleccione una Marca", "alerta");
3
} else if (cModelo == -1) {
msgbox("Alerta", "Seleccione un Modelo", "alerta");
4
} else if (cNumeroSerie.length == 0) {
msgbox("Alerta", "Ingrese un Numero de Serie al Registro de Partes", "alerta");
5
} else if (cFechaInicio.length == 0) {
msgbox("Alerta", "Ingrese un Fecha de Inicio de Funciones al Registro de Partes",
"alerta");
6
} else if (nEstado == -1) {
msgbox("Alerta", "Seleccione un Estado del Registro de Partes", "alerta");
} else if (nCondicion == -1) {
7
msgbox("Alerta", "Seleccione una Condicion del Registro de Partes", "alerta");
} else {
//progressbar(cDivNombre);
$.ajax({
type: "POST",
url: "Patrimonio/Pa_Marcas.aspx/RegistrarPartes",
data: "{nIntCodigo:" + nIntCodigo + ",nIntClase:" + nIntClase + ",cIntJerarquia:'" +
cIntJerarquia + "',cIntNombre:'" + cIntNombre + "',cIntDescripcion:'" + cIntDescripcion +
"',nIntTipo:" + nIntTipo + ",cPerJuridica:'" + cPerJuridica + "',cIntJerarquiaAnterior:'" +
cIntJerarquiaAnterior + "',cIntDescripcionAnterior:'" + cIntDescripcionAnterior + "',nOperacion:"
+ nOperacionUpdate + ",nOpcion:" + nOpcion + "}",
contentType: "application/json; charset=utf-8",
dataType: "json",
async: false,
success: function (data) {
8
if (data.d == 0) {
msgbox("Exito", "El Registro de Partes Se ha Actualizado con Exito", "exito");
Actualiza_Transaccion(nOperacionUpdate, "Registro de Partes: " +
cIntDescripcion)
9
} else if (data.d == 1) {

- 74-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

msgbox("Alerta", "El Registro de Partes ya tiene Registrados varias Partes de la


Misma Caracteristica", "alerta");
10
} else if (data.d == 2) {
msgbox("Alerta", "El Registro de Partes no Tiene Ninguna Caracteristica
Especial", "alerta");
11
} else {
msgbox("Error", "La operacin de Registro de Partes no se ha realizado", "error");
}
},
error: function (msg) { msgbox("Error", "UAWEB a detectado un error. Consulte con el
administrador del sistema", "error"); }
});
}
}

Figura 27. Nodos prueba P03.

Dibujo del grafo de flujo:


6

11

10

3
4

Figura 29. Grafo de Flujo Prueba P03.

Calcular la Complejidad Ciclomtica:


A: Representa el nmero de aristas.
N: La cantidad de nodos.

M=a-n+2
M = 14 13 + 2
M=3

- 75-

CAP. III: DESARROLLO DE SISTEMA WEB

R. Arteta - A. Justo

Encontrar los caminos bsicos


C1: 1 2 6 11
C2: 1 2 3 4 5 6 7 8 9 -10 11
C3: 1 2 3 4 5 9 10 11

Tabla 16. Casos de Prueba P03.


Nro.

Camino

Condicin

CP01

C1

Evaluar que se haya


seleccionado Empresa, Marca y
Estado

CP02

C2

Evaluar el Registro de
Componentes TI

C3

Evaluar que se haya


seleccionado Empresa, Marca,
Modelo, Nro. de Serie.

CP03

- 76-

Valores de
entrada
Universidad
Autnoma del Per
S.A.C
Epson
Malo
Universidad
Autnoma del Per
S.A.C
Epson
S5
xyzabcdef
10/11/2013
Malo
Lmpara
Universidad
Autnoma del Per
S.A.C
Epson
S5
xyzabcdef

Resultado
Esperado
Se muestra el
mensaje: Ingrese
Modelo

Se Registra el
Componente TI

Se muestra
mensaje:
Complete datos
obligatorios

CAPTULO IV
ANLISIS DE RESULTADOS Y
CONTRASTACIN DE LA
HIPTESIS

La mejor estructura no garantizar los resultados


ni el rendimiento.
Pero la estructura equivocada es una garanta de fracaso.
Peter Drucker

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

4.1 UNIVERSO Y MUESTRA


4.1.1 Universo
Son todas las Gestiones de Activos Fsicos TI del rea de Soporte Tcnico en la
Universidad Autnoma del Per.
N = Indefinido
4.1.2 Muestra
Proceso de Gestin de Activos Fsicos TI en el rea de Soporte Tcnico.
n = 30 Gestin de Activos Fsicos TI.16
4.2 NIVEL DE CONFIANZA
El nivel de confianza ser de 95 % dada la inexperiencia del investigador.
4.3 ANLISIS E INTERPRETACIN DE RESULTADOS
4.3.1 Resultados Genricos
A) Anlisis de Requerimientos
Requerimientos del Sistema.
Modelo de Dominio.
Modelo de Casos de Uso.
B) Anlisis y Diseo Preliminar
Descripcin de Casos de Uso.
Diagrama de Robustez.
C) Diseo Detallado
Diagrama de Secuencia.
Diagrama de Clases Final.
Diagrama de Componentes.
Diagrama de Despliegue.
D) Implementacin
Pruebas del Sistema.
Prueba Funcional Tcnica de Caja Negra.
Prueba Unitaria - Tcnica de Caja Blanca.
4.3.2 Resultados Especficos
A continuacin se muestra los valores de los indicadores de la Post- Prueba (Gc) y
Post-Prueba (Ge).

16

Pande, P., Las Claves Practicas de Six Sigma, Ed. MCGraw-Hill, New York, 2004, pp. 135-136.

-78-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

-79-

R. Arteta - A. Justo

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

4.3.3 Resultados Numricos


A continuacin se presentan las medias de los KPIs para la Post- Prueba (Gc) y Post
Prueba (Ge):

Tabla 17. Promedio de los indicadores de la Post-Prueba (Gc) y Post-Prueba (Ge).


Indicador

Post-Prueba (Gc)
(Media: )

Post-Prueba (Ge)
(Media: )

Comentario

Tiempo del
Personal en generar
reportes

47 min.

3 min.

Nmero reportes
solicitados por ciclo

7 reportes/ciclo

11 reportes/ciclo

93%

2.50%

No contrastado.

Porcentaje en la
exactitud de
informacin
Porcentaje de malas
decisiones tomadas
Satisfaccin del
Usuario

50%
55%
-

En las siguientes tablas se muestra los resultados de la Post-Prueba y Post-Prueba.


Adems se resalta los valores de los KPIs medidos, en la Post-Prueba, que son mejores
(menores o mayores) que los KPIs promedio en la Post-Prueba (fondo verde), los que son
menores que la meta planeada (fondo azul), y los que son menores que los KPIs promedio
en la Post-Prueba (fondo rojo).
Se realiza, a continuacin, un anlisis detallado de los datos de cada de una de las tablas.

- 80-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

A. Indicador Tiempo para Generar Reportes: KPI1


Tabla 18. Resultados de Post-Prueba (Gc) y Post-Prueba (Ge) para el KPI 1.
Post-prueba (Gc)
40
42
49
55
53
55
41
41
45
50
53
49
45
47
48
51
50
50
44
42
46
50
50
50
51
52
55
48
47
49
Promedio
Meta Planteada
N menor a Promedio
%

2
3
2
1
3
3
3
4
5
3
2
3
3
3
4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3

Post-prueba (Gc)
2
3
2
1
3
3
3
4
5
3
2
3
3
3
4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3

48.24

2
3
2
1
3
3
3
4
5
3
2
3
3
3
4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3

3.17
20
66.66

3.5
20
66.66

30
100

El 66,66% de los Tiempos del Personal en generar reportes en la Post-Prueba (Gc)


fueron menores que su tiempo promedio.
El 66.66% de los Tiempos del Personal en generar reportes en la Post-Prueba (Ge)
fueron menores que la meta planteada.
El 100% de los Tiempos del Personal en generar Reportes en la Post-Prueba (Ge)
fueron menores que el tiempo promedio en la Post-Prueba (Gc).

- 81-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Resumen para el Tiempo del Personal en Generar Reportes


A nderson-Darling N ormality Test

A -S quared
P -V alue <

1.35
0.005

M ean
S tDev
V ariance
S kew ness
Kurtosis
N

3.1667
0.9855
0.9713
0.107215
-0.170292
30

M inimum
1st Q uartile
M edian
3rd Q uartile
M aximum

1.0000
2.7500
3.0000
4.0000
5.0000

95% C onfidence Interv al for M ean


2.7987

3.5347

95% C onfidence Interv al for M edian


3.0000

3.7713

95% C onfidence Interv al for S tDev


9 5 % C onfidence Inter vals

0.7849

1.3249

Mean
Median
2.8

3.0

3.2

3.4

3.6

3.8

Los datos tienen un comportamiento poco normal debido a que el Valor p


(0,005)< (0,05), pero son valores cercanos, lo cual se confirma al observarse que
los intervalos de confianza de la Media y la Mediana se traslapan.

La distancia promedio de las observaciones individuales de los Tiempos en


realizar los reportes con respecto a la media es de 0.93%.

Alrededor del 95% de los Tiempos en realizar los reportes estn dentro de 2
desviaciones estndar de la media, es decir entre 2,79 y 3,53 minutos.

La Kurtosis = -0,17 indica que hay valores de tiempo con picos muy bajos.

La Asimetra = 0,10 indica que la mayora de los tiempos en realizar reportes son
altas.

El Primer Cuartil (Q1) = 2.75 minutos indica que el 25% de los Tiempos en realizar
reportes son altas.

El Tercer Cuartil (Q3) = 4 minutos indica que el 75% de los Tiempos en realizar los
reportes es menor que o igual a este valor.

- 82-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

B. Indicador Nmero de Reportes solicitados por ciclo: KPI 2


Tabla 19: Resultados de Post-Prueba (Gc) y Post-Prueba (Ge) para el KPI 2.

Promedio
Meta Planteada
N mayor a Promedio
%

Post-prueba (Gc)
3
6
4
6
7
9
8
10
6
9
9
10
6
7
8
7
8
10
8
6
6
10
7
9
10
6
10
10
7
7
8

Post-prueba (Gc)
11
11
11
11
10
10
11
11
12
12
12
12
10
10
11
11
12
12
10
10
10
10
11
11
12
12
12
12
10
10
10
10
12
12
12
12
10
10
10
10
11
11
11
11
11
11
10
10
12
12
12
12
10
10
12
12
12
12
11
11
11.03
11.5
11
11
36.66
36.66

11
11
10
11
12
12
10
11
12
10
10
11
12
12
10
10
12
12
10
10
11
11
11
10
12
12
10
12
12
11

30
100

El 36.66% de los Porcentajes de Nmero de reportes solicitados por ciclo en la PostPrueba (Gc) fueron mayores que su Nmero de Reportes Solicitados.
El 36.66% de los Porcentajes de Nmero de reportes solicitados por ciclo en a PostPrueba (Ge) fueron mayores que la meta planeada.
El 100,00% de los Porcentajes de Nmero de reportes solicitados por ciclo en la PostPrueba (Ge) fueron mayores que el tiempo promedio en la Post-Prueba (Gc)

- 83-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Resumen de Nmeros de Reportes Solicitados por Ciclo


A nderson-Darling N ormality Test

10

11

A -S quared
P -V alue <

2.50
0.005

M ean
S tDev
V ariance
S kew ness
Kurtosis
N

11.033
0.850
0.723
-0.06598
-1.63257
30

M inimum
1st Q uartile
M edian
3rd Q uartile
M aximum

12

10.000
10.000
11.000
12.000
12.000

95% C onfidence Interv al for M ean


10.716

11.351

95% C onfidence Interv al for M edian


10.229

12.000

95% C onfidence Interv al for S tDev


9 5 % C onfidence Inter vals

0.677

1.143

Mean
Median
10.0

10.5

11.0

11.5

12.0

Los datos tienen un comportamiento poco normal debido a que el Valor p (0,005) <
(0,005), pero son valores cercanos, lo cual se confirma al observarse que los
intervalos de confianza de la Media y la Mediana se traslapan.

La distancia promedio de las observaciones individuales de los nmeros de


reportes solicitados por ciclo con respecto a la media es de 13,93%.

Alrededor del 95% del nmero de reportes solicitados por ciclo estn dentro de 2
desviaciones estndar de la media, es decir entre 10,716 y 11,351 reportes /ciclo.

La Kurtosis = -1.63 indica que hay valores de Nmero de Reportes Solicitados con
picos muy bajos.

La Asimetra = -0,06 indica que la mayora de Nmeros de Reportes Solicitados


por ciclo son altas.

El 1er Cuartil (Q1) = 10 reportes indica que el 25% de los Nmeros de Reportes
Solicitados por ciclo es menor que o igual a este valor.

El 3er Cuartil (Q3) = 12 reportes indica que el 75% de los Nmeros de Reportes
Solicitados por ciclo es menor que o igual a este valor.

- 84-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

C. Indicador Porcentaje en la Exactitud de Informacin: KPI3


Tabla 20: Resultados de Post-Prueba (Gc) y Post-Prueba (Ge) para el KPI3

Promedio
Meta Planteada
N mayor a Promedio
%

Post-prueba (Gc)
41
42
42
49
48
44
40
48
50
54
60
59
59
42
42
44
40
60
58
56
55
51
40
40
45
60
47
46
40
45
48.23333333

Post-prueba (Gc)
90
90
93
93
92
92
92
92
92
92
90
90
95
95
94
94
90
90
91
91
91
91
92
92
94
94
90
90
95
95
93
93
93
93
93
93
92
92
94
94
95
95
95
95
90
90
91
91
92
92
94
94
91
91
90
90
92
92
94
94
92.33
93
13
9
30
43.33
30
100
90
93
92
92
92
90
95
94
90
91
91
92
94
90
95
93
93
93
92
94
95
95
90
91
92
94
91
90
92
94

El 43.33% de los Porcentajes de exactitud de informacin en la Post-Prueba (Gc)


fueron mayores que su exactitud promedio.

El 30% de los Porcentajes de exactitud de informacin en la Post-Prueba (Ge)


fueron mayores que la meta planteada.

El 100,00% de los Porcentajes de exactitud de informacin en la Post-Prueba (Ge)


fueron mayores que la exactitud promedio en la Post-Prueba (Gc).

- 85-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Resumen del Porcentaje en la Exactitud de Informacin


A nderson-Darling N ormality Test

90

91

92

93

94

A -S quared
P -V alue

0.81
0.032

M ean
S tDev
V ariance
S kew ness
Kurtosis
N

92.333
1.709
2.920
0.10533
-1.18630
30

M inimum
1st Q uartile
M edian
3rd Q uartile
M aximum

95

90.000
91.000
92.000
94.000
95.000

95% C onfidence Interv al for M ean


91.695

92.971

95% C onfidence Interv al for M edian


91.229

93.000

95% C onfidence Interv al for S tDev


9 5 % C onfidence Inter vals

1.361

2.297

Mean
Median
91.0

91.5

92.0

92.5

93.0

Los datos tienen un comportamiento poco normal debido a que el Valor p (0,032) <
(0,05), pero son valores cercanos, lo cual se confirma al observarse que los
intervalos de confianza de la Media y la Mediana se traslapan.

La distancia promedio de las observaciones individuales del Porcentaje de


exactitud de informacin con respecto a la media es de 3.161%.

Alrededor del 95% del Porcentaje de exactitud de informacin estn dentro de 2


desviaciones estndar de la media, es decir entre 91,695% y 92,971%.

La Kurtosis = -1,186 indica que hay valores de tiempo con picos muy bajos.

La Asimetra = 0,105 indica que la mayora de los Porcentajes de exactitud de


informacin son altas.

El 1er Cuartil (Q1) = 91% indica que el 25% de los Porcentajes de exactitud de
informacin es menor que o igual a este valor.

El 3er Cuartil (Q3) = 94% indica que el 75% de los Porcentajes de exactitud de
informacin es menor o igual a este valor.

- 86-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

D. Indicador Porcentaje de Malas Decisiones Tomadas: KPI4


Tabla 21: Resultados de Post-Prueba (Gc) y Post-Prueba (Ge) para el KPI 4.

Promedio
Meta Planteada
N menor a Promedio
%

Post-prueba (Gc)
51.40
50.53
54.02
60.00
59.44
53.16
53.11
52.71
50.45
60.15
59.60
59.55
55.50
56.13
53.33
51.14
50.83
60.03
60.32
59.43
58.65
50.10
50.34
51.16
52.50
53.10
52.54
58.30
56.94
55.90
55.01

4.30
4.10
2.20
3.00
3.50
1.70
2.70
1.60
4.80
0.90
4.50
2.80
1.60
3.60
1.90
1.50
2.50
3.10
1.40
0.90
2.30
4.10
2.20
3.20
3.70
1.30
2.20
1.10
0.80
2.50

17
56.66

Post-prueba (Gc)
4.30
4.3
4.10
4.1
2.20
2.2
3.00
3
3.50
3.5
1.70
1.7
2.70
2.7
1.60
1.6
4.80
4.8
0.90
0.9
4.50
4.5
2.80
2.8
1.60
1.6
3.60
3.6
1.90
1.9
1.50
1.5
2.50
2.5
3.10
3.1
1.40
1.4
0.90
0.9
2.30
2.3
4.10
4.1
2.20
2.2
3.20
3.2
3.70
3.7
1.30
1.3
2.20
2.2
1.10
1.1
0.80
0.8
2.50
2.5
2.53
2
11
30
36.66
100.0

El 56,66% de los Porcentajes de malas decisiones tomadas en la Post-Prueba (Gc)


fueron menores que su Porcentaje de Malas Decisiones Tomadas.

El 36,66% de los Porcentajes de malas decisiones tomadas en la Post-Prueba (Ge)


fueron menores que la meta planteada.

El 100% de los Porcentajes de malas decisiones tomadas en la Post-Prueba (Ge)


fueron menores que el tiempo promedio en la Post-Prueba (Gc).

- 87-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Resumen de Porcentajes de Malas Decisiones Tomadas


A nderson-Darling N ormality Test

A -S quared
P -V alue

0.35
0.459

M ean
S tDev
V ariance
S kew ness
Kurtosis
N

2.5333
1.1604
1.3464
0.304586
-0.943461
30

M inimum
1st Q uartile
M edian
3rd Q uartile
M aximum

0.8000
1.5750
2.4000
3.5250
4.8000

95% C onfidence Interv al for M ean


2.1000

2.9666

95% C onfidence Interv al for M edian


1.7457

3.0771

95% C onfidence Interv al for S tDev


9 5 % C onfidence Inter vals

0.9241

1.5599

Mean
Median
1.8

2.0

2.2

2.4

2.6

2.8

3.0

Los datos tienen un comportamiento poco normal debido a que el Valor p (0,459)
> (0,05), pero son valores cercanos, lo cual se confirma al observarse que los
intervalos de confianza de la Media y la Mediana se traslapan.

La distancia promedio de las observaciones individuales del Porcentaje de malas


decisiones tomadas con respecto a la media es de 1,212%

Alrededor del 95% del Porcentaje de exactitud de informacin estn dentro de 2


desviaciones estndar de la media, es decir entre 2,100% y 2,966%.

La Kurtosis = -0,943 indica que hay valores de tiempo con picos muy bajos.

La Asimetra = 0,304 indica que la mayora de los Porcentajes de malas decisiones


tomadas son bajas.

El 1er Cuartil (Q1) =1,5750% indica que el 25% de los Porcentajes de Malas
Decisiones Tomadas es menor que o igual a este valor.

El 3er Cuartil (Q3) = 3,525% indica que el 75% de los Porcentaje de Malas
Decisiones Tomadas es menor que o igual a este valor.

- 88-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

E. Indicador Satisfaccin del Jefe de Soporte: KPI5


Valores de Post-Prueba (Gc)

Nro.
Medicin
Valor

Regular
11
Regular
21
Regular

Bajo
12
Regular
22
Bajo

Regular
13
Bajo
23
Regular

Estado

Frecuencia

Bajo

16

Regular

12

Alto

Estado

Frecuencia

Comprensible

No - Comprensible

28

Bajo Regular
14
15
Bajo Regular
24
25
Bajo
Alto

10

Bajo
16
Bajo
26
Regular

Bajo
17
Regular
27
Bajo

Regular
18
Bajo
28
Bajo

Bajo
19
Alto
29
Regular

Bajo
20
Bajo
30
Bajo

El 40 % de las veces de Satisfaccin del usuario de los reportes fue catalogada


como Regular por el Jefe de Soporte Tcnico.

Solo el 53% de las veces de Satisfaccin del usuario de los reportes fue catalogada
como Bajo por el Jefe de Soporte Tcnico.

Se determina que solo el 6% de las veces de Satisfaccin del usuario de los reportes
es Comprensible.

Se determina que solo el 94% de las veces de Satisfaccin del usuario de los
reportes es No Comprensible.

- 89-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Valores de Post-Prueba (Ge)

Nro.
1
2
3
4
5
Medicin
Valor
Regular
Alto
Regular
Alto
Regular
11
12
13
14
15
Regular Regular
Alto
Alto
Regular
21
22
23
24
25
Regular
Alto
Alto
Regular
Alto

Estado

Frecuencia

Bajo

Regular

15

Alto

14

Estado

Frecuencia

Comprensible

29

No - Comprensible

6
Alto
16
Alto
26
Alto

Regular
Bajo
17
18
Regular
Alto
27
28
Regular Regular

10

Alto
19
Alto
29
Alto

Regular
20
Regular
30
Regular

Solo el 3% de las veces de Satisfaccin del usuario de los reportes fue catalogada
como Bajo por el Jefe de Soporte Tcnico.

Ahora el 50% de las veces de Satisfaccin del usuario de los reportes fue
catalogada como Regular por el Jefe de Soporte Tcnico.

Se determina que solo el 97% de las veces Satisfaccin del usuario de los reportes
es Comprensible

Se determina que solo el 3% de las veces de Satisfaccin del usuario de los reportes
es No Comprensible

- 90-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

4.4 CONTRASTACIN DE LA HIPTESIS


A. Contrastacin para el Indicador KPI1: Tiempo del Personal en Generar
Reportes
Se debe validar el impacto que tiene la Implementacin de Sistema Web en el Tiempo
para Generar Reportes en el proceso de Gestin de Activos Fsicos TI en el rea de
Soporte Tcnico, llevado a cabo en la muestra. Se realiza una medicin antes de la
Implementacin de Sistema Web (Post-Prueba (Gc)) y otra despus de la
Implementacin de Sistema Web (Post-Prueba (Ge)). La tabla contiene los Porcentajes
de exactitud de informacin para las dos muestras.

Post-Prueba (Gc)

Post-Prueba (Ge)

40

42

49

55

53

55

41

41

45

50

53

49

45

47

48

51

50

50

44

42

46

50

50

50

50

52

55

48

47

49

Hi: La implementacin de Sistema Web disminuir el Tiempo del Personal en Generar


Reportes (Post-Prueba (Ge)) con respecto a la muestra a la que no se aplic (PostPrueba (Gc)).
Solucin:
a)

Planteamiento de la hiptesis:

1 = Media del Tiempo del Personal en Generar Reportes en la Post-Prueba (Gc).


2 = Media del Tiempo del Personal en Generar Reportes en la Post-Prueba (Ge).
Ho: 1 2
Ha: 1 > 2

- 91-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

b)

R. Arteta - A. Justo

Criterios de Decisin:
Distribution Plot
T, df=58

0.4

Density

0.3

0.2

0.1
0.05
0.0

c)

0
X

1.672

Clculo: Prueba t para prueba de medias de las dos muestras:

Para visualizar los resultados de la contrastacin, primero se selecciona los datos de la


muestra Post-Prueba (Gc) y luego los datos de la muestra Post-Prueba (Ge), con un nivel
de confianza del 95%.

Al ingresar los datos se obtiene los siguientes resultados:


Post Prueba (Gc)

Post Prueba (Ge)

Media ( )

48.27

3.167

Desviacin Estndar (S)

4.27

0.986

Observaciones (n)

30

30

Diferencia hipottica de las


medias

45.100

T calculado: tc

56.31

p-valor (dos colas)

0.000

- 92-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

d)

R. Arteta - A. Justo

Decisin estadstica:

Puesto que el valor-p=0,000 < =0,05, los resultados proporcionan suficiente evidencia
para rechazar la hiptesis nula (Ho), y la hiptesis alterna (Ha) es cierta.
La prueba result ser significativa.

B. Contrastacin para el Indicador KPI2: Nmero de Reportes Solicitados por


Ciclo
Se debe validar el impacto que tiene la Implementacin de Sistema Web en el Nmero
de Reportes Solicitados por Ciclo en el proceso de Gestin de Activos Fsicos TI en el
rea de Soporte Tcnico, llevado a cabo en la muestra. Se realiza una medicin antes
de la Implementacin de Sistema Web (Post-Prueba (Gc)) y otra despus de la
Implementacin de Sistema Web (Post-Prueba (Ge)). La tabla contiene los Porcentajes
de exactitud de informacin para las dos muestras.

Post-Prueba (Gc)

Post-Prueba
(Ge)

10

10

10

10

10

10

10

11

11

10

11

12

12

10

11

12

10

10

11

12

12

10

10

12

12

10

10

10

10

10

10

Hi: La implementacin de Sistema Web aumentar el Nmero de Reportes Solicitados


por Ciclo (Post-Prueba (Ge)) con respecto a la muestra a la que no se aplic (PostPrueba (Gc)).
Solucin:
a)

Planteamiento de la hiptesis:

1 = Media del Nmero de Reportes Solicitados por Ciclo en la Post-Prueba (Gc).


2 = Media del Nmero de Reportes Solicitados por Ciclo en la Post-Prueba (Ge).
Ho: 1 2
Ha: 1 < 2

- 93-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

b)

R. Arteta - A. Justo

Criterios de Decisin:
Distribution Plot
T, df=58

0.4

Density

0.3

0.2

0.1
0.05
0.0

c)

-1.672

0
X

Clculo: Prueba t para prueba de medias de las dos muestras:

Para visualizar los resultados de la contrastacin, primero se selecciona los datos de la


muestra Post-Prueba (Gc) y luego los datos de la muestra Post-Prueba (Ge), con un nivel
de confianza del 95%.

Al ingresar los datos se obtiene los siguientes resultados:


Post Prueba (Gc)

Post Prueba (Ge)

Media ( )

7.63

11.033

Desviacin Estndar (S)

1.88

0.850

Observaciones (n)

30

30

Diferencia hipottica de las


medias

-3.400

T calculado: tc

-9.01

p-valor (dos colas)

0.000

- 94-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

d)

R. Arteta - A. Justo

Decisin estadstica:

Puesto que el valor-p=0,000 < =0,05, los resultados proporcionan suficiente evidencia
para rechazar la hiptesis nula (Ho), y la hiptesis alterna (Ha) es cierta.
La prueba result ser significativa.

C. Contrastacin para el Indicador KPI3: Porcentaje en la exactitud de


Informacin

Se debe validar el impacto que tiene la Implementacin de Sistema Web en el


Porcentaje de exactitud de Informacin en el proceso de Gestin de Activos Fsicos TI
en el rea de Soporte Tcnico, llevado a cabo en la muestra. Se realiza una medicin
antes de la Implementacin de Sistema Web (Post-Prueba (Gc)) y otra despus de la
Implementacin de Sistema Web (Post-Prueba (Ge)). La tabla contiene los Porcentajes
de exactitud de informacin para las dos muestras.

Post-Prueba (Gc)

Post-Prueba (Ge)

41

42

42

49

48

44

40

48

50

54

60

59

59

42

42

44

40

60

58

56

55

51

40

40

45

60

47

46

40

45

90

93

92

92

92

90

95

94

90

91

91

92

94

90

95

93

93

93

92

94

95

95

90

91

92

94

91

90

92

94

Hi: La implementacin de Sistema Web aumentar el Nmero de Reportes Solicitados


por Ciclo (Post-Prueba (Ge)) con respecto a la muestra a la que no se aplic (PostPrueba (Gc)).

- 95-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Solucin:
a)

Planteamiento de la hiptesis:

1 = Media del Nmero de Reportes Solicitados por Ciclo en la Post-Prueba (Gc).


2 = Media del Nmero de Reportes Solicitados por Ciclo en la Post-Prueba (Ge).
Ho: 1 2
Ha: 1 < 2
b)

Criterios de Decisin

Distribution Plot
T, df=58

0.4

Density

0.3

0.2

0.1
0.05
0.0

c)

-1.672

0
X

Clculo: Prueba t para prueba de medias de las dos muestras:

Para visualizar los resultados de la contrastacin, primero se selecciona los datos de la


muestra Post-Prueba (Gc) y luego los datos de la muestra Post-Prueba (Ge), con un nivel
de confianza del 95%.

- 96-

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

R. Arteta - A. Justo

Post Prueba (Gc)

Post Prueba (Ge)

Media ( )

48.23

92.33

Desviacin Estndar (S)

7.20

1.71

Observaciones (n)

30

30

Diferencia hipottica de las


medias

-44.10

T calculado: tc

-32.64

p-valor (dos colas)

0.000

Al ingresar los datos se obtiene los siguientes resultados:


d)

Decisin estadstica:

Puesto que el valor-p=0,000 < =0,05, los resultados proporcionan suficiente evidencia
para rechazar la hiptesis nula (Ho), y la hiptesis alterna (Ha) es cierta.
La prueba result ser significativa.

D. Contrastacin para el Indicador KPI4: Porcentaje de Malas Decisiones


Tomadas
Se debe validar el impacto que tiene la Implementacin de Sistema Web en el
Porcentaje de Malas Decisiones Tomadas en el proceso de Gestin de Activos Fsicos
TI en el rea de Soporte Tcnico, llevado a cabo en la muestra. Se realiza una
medicin antes de la Implementacin de Sistema Web (Post-Prueba (Gc)) y otra
despus de la Implementacin de Sistema Web (Post-Prueba (Ge)). La tabla contiene
los Porcentajes de exactitud de informacin para las dos muestras.
Post-Prueba
(Gc)

51.4

50.53 54.02

60

59.60

59.55 55.50 56.13 53.33 51.14 50.83 60.03

60.32

59.43

58.65

50.1

56.94

55.9

50.34 51.16

- 97-

59.44 53.16 53.11 52.71 .50.45 60.15

52.5

53.1

52.54

58.3

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

PostPrueba
(Ge)

R. Arteta - A. Justo

4.30

4.10

2.20

3.00

3.50

1.70

2.70

1.60

4.80

0.90

4.50

2.80

1.60

3.60

1.90

1.50

2.50

3.10

1.40

0.90

58.65

50.10

50.34

51.16

52.50

53.10

52.54

58.30

56.94

55.90

Hi: La implementacin de Sistema Web disminuir el Nmero de Reportes Solicitados


por Ciclo (Post-Prueba (Ge)) con respecto a la muestra a la que no se aplic (PostPrueba (Gc)).
Solucin:
a)

Planteamiento de la hiptesis:

1 = Media del Tiempo del Personal en Generar Reportes en la Post-Prueba (Gc).


2 = Media del Tiempo del Personal en Generar Reportes en la Post-Prueba (Ge).
Ho: 1 2
Ha: 1 > 2
b)

Criterios de Decisin
Distribution Plot
T, df=58

0.4

Density

0.3

0.2

0.1
0.05
0.0

0
X

- 98-

1.672

CAP. IV: ANLISIS DE RESULTADOS Y CONTRASTACIN DE LA HIPTESIS

a)

R. Arteta - A. Justo

Clculo: Prueba t para prueba de medias de las dos muestras:

Para visualizar los resultados de la contrastacin, primero se selecciona los datos de la


muestra Post-Prueba (Gc) y luego los datos de la muestra Post-Prueba (Ge), con un nivel
de confianza del 95%.

Al ingresar los datos se obtiene los siguientes resultados:


Post Prueba (Gc)

Post Prueba (Ge)

Media ( )

55.01

2.53

Desviacin Estndar (S)

3.69

1.16

Observaciones (n)

30

30

Diferencia hipottica de las


medias

51.284

T calculado: tc

74.31

p-valor (dos colas)

0.000

b)

Decisin estadstica:

Puesto que el valor-p=0,000 < =0,05, los resultados proporcionan suficiente evidencia
para rechazar la hiptesis nula (Ho), y la hiptesis alterna (Ha) es cierta.
La prueba result ser significativa.

- 99-

CAPTULO V
CONCLUSIONES Y
RECOMENDACIONES

El que aprende y aprende y no practica lo que sabe, es como


el que ara y ara y no siembra.
Platn

CAP. V: CONCLUSIONES Y RECOMENDACIONES

R. Arteta - A. Justo

5.1 CONCLUSIONES

a. Con los resultados obtenidos en la presente investigacin se mejora la Gestin de


Activos fsicos TI en la Universidad Autnoma del Per
b. Se comprueba que ICONIX es una buena metodologa para desarrollar un sistema
web.
c. Se elabor el Anlisis de requerimientos para la identificacin de casos de uso y
modelo de dominio.
d. Se realiz el Anlisis y diseo preliminar para la descripcin de casos de uso y el
Diagrama de Robustez.
e. Se efectu el Diseo detallado, donde se identific el diagrama de secuencia,
diagrama de clases final, diagrama de componentes y el diagrama de despliegue.
f. Se realiz la fase de implementacin mediante las pruebas del sistema, donde se
aplic las tcnicas de caja negra y caja blanca.
g. Se verifica que los inventarios de los Activos Fsicos TI, ha sido de manera
automatizada mediante un sitio web para dar a conocer en mayor detalle y en forma
ordenada.
h. Se comprueba, que el personal de Soporte Tcnico podr desarrollar los informes
de manera adecuada, rpida y sencilla al no tener que generar informacin en forma
manual.
i. Se mejora, la calidad del servicio, incrementando la satisfaccin del jefe y personal
de soporte, as como la reduccin del tiempo para registrar activos fsicos TI.

- 101-

CAP. V: CONCLUSIONES Y RECOMENDACIONES

R. Arteta - A. Justo

5.2 RECOMENDACIONES

a. Se sugiere, continuar implementando la metodologa Iconix para la implementacin


de aplicaciones Web, para las dems reas de la Universidad Autnoma del Per.
b. Se recomienda, realizar un manual de usuario para la debida capacitacin del nuevo
Personal conforme ingrese al rea.
c. Capacitar al Personal de Soporte Tcnico para el buen uso del Sistema Web.
d. Se recomienda seguir implementando el Sistema Web con los nuevos
requerimientos segn los problemas presentados en un futuro prximo dentro del
rea.
e. Se recomienda que el aplicativo sea actualizado de manera permanente por el
personal de Soporte Tcnico, ya que de una actualizacin constante este software
buscara satisfacer la necesidad encontradas en el manejo de Gestin de Activos
Fsicos TI y permitir disminuir esfuerzos como tambin ahorrar tiempo en los
reportes requeridos.
f. Se aconseja investigar la Gestin de Activos Fsicos TI segn ITIL, para una mayor
administracin y conocimientos dentro del rea de Soporte Tcnico.
g. Se recomienda la confidencialidad al personal de Soporte Tcnico, con la
informacin del rea.

- 102-

REFERENCIAS BIBLIOGRFICAS
Tesis:
[1] Suniaga, J. (2009). Desarrollo de una Aplicacin Web basada en Tecnologa Helpdesk
para ofrecer servicios de Soporte Tcnico e Inventario en la Gerencia de Informtica de la
empresa C.A. Hidrolgica del Centro, en Valencia Estado Carabobo . Tesis pre-grado,
Universidad de Oriente, Barcelona, Espaa.
[2] Polanco, V. (2007). Desarrollo de una aplicacin WEB para soporte de gestin de
negocio y manejo de inventario para la empresa INVERSIONES VPL, C.A.. Tesis pregrado no publicada, Universidad Nueva Esparta, Caracas, Venezuela.
[6] Alva, J., Paredes, N. (2005). Desarrollo e Implementacin de un Sistema Web para el
Control Acadmico en el Instituto Superior Pblico Chocope. Tesis pre-grado,
Universidad Csar Vallejo, Trujillo.
[4] Guerra, T. (2007). Desarrollo de un Aplicativo Web basado en Ajax para el Control de
Inventarios Mobiliarios de la Institucin Educativa Pronoe Galileo. Tesis Pre-Grado,
Universidad Nacional del Santa, Chimbote.

Libros:
[5] Carrin, P., Huamn, L. (2005). Sistema Informtico y Web para los Servicios
Acadmicos del Instituto Superior Pedaggico Privado Talara basadas en Tecnologas
.net. Madrid: Banesto Fundacin Cultural. Trujillo.
[13] Rosa Menndez Mueras. Construccin de Software Orientado Objetos con el Proceso
Unificado y UML, un punto de vista prctico. Lima: Consejo Editorial UCCI; 2005.
[21] Oscar Casasola Romero. Introduccin a UML. Programacin en Castellano. Espaol;
2010.
[8] Sergio Lujn Mora. Programacin de aplicaciones web: historia, principios bsicos y
clientes web. San Vicente: Editorial Club Universitario; 2002.
[7] Kenneth C. Laudon, Jane P. Laudon. Sistemas de Informacin Gerencial. Mxico:
Pearson Education; 2004.
[18] Beck, Kent. Planning Extreme Pogramming.Addison Wesley; 2000.
[19] Rosenberg, Doug. 2005. Agile Development with ICONIX. s.l. : Apress, 2005.

- 103-

[20] Rosenberg, Doug y Stephens, Matt. 2007. Use Case Driven Object Modeling with
UML. s.l. : Addison-Wesley, 2007.

Monografas en Internet:
[12]

Bermeo,

F.

(2010).

RUP.

Obtenida

el

27

de

Mayo

de

2013,

de

http://fabianbermeop.blogspot.com/2010/12/metodologia-rup-desarrollo-de-software.html
[10] Tipos de sistemas para empresas. (2007) Obtenida el 30 de Mayo de 2013, de
http://www.informatica-hoy.com.ar/aprender-informatica/Tipos-de-sistemas-paraempresas-ERP-CRM-B2B-y-mas.php
[9] Guayms, H. (N.D). Caractersticas de un Sistema Web. Obtenida el 30 de Mayo de
2013, de https://sites.google.com/site/hguaymas/servicios3
[11]

Guzmn,

L.

(2012).

RUP.

Obtenida

el

27

de

Mayo

de

2013,

de

http://es.scribd.com/doc/51486224/rup
[14.1] Proceso (Informtica). (2013). Obtenida el 7 de Junio de 2013, de
http://es.wikipedia.org/wiki/Proceso_(inform%C3%A1tica)
[22] Manual de Mantenimiento de PCs e Introduccin a Redes. (N.D). Obtenida el 7 de
Junio de 2013, de http://www.proulex.com/computo/oe/doc/mantenimiento-win7.pdf
[23] Manual de Normas y Procedimientos Registro y Adquisicion de Bienes. (2004).
Obtenida el 7 de Junio de 2013, de
http://www.ucv.ve/fileadmin/user_upload/vrad/documentos/DPP/Manuales/Manuales/Adq
uisicion__Bienes_SIAF.pdf
[15] Universidad Fermn Toro (N.D). Diagrama de Estructura Compuesta UML 2.
Obtenida el 14 de Julio de 2013, de
https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=19&cad=rja&v
ed=0CHUQFjAS&url=http%3A%2F%2Fdsuft.wikispaces.com%2Ffile%2Fview%2FDiagrama%2Bde%2BEstructura%2BCompuesta
%2BUML%2B2.doc&ei=AxHoUZJc0uXgA6KMgNgI&usg=AFQjCNFDn_bLiTDbYBxv
Llkfyf9VsTMMVA&sig2=Vouu4TS0hQpqth58vOloWA&bvm=bv.49478099,d.dmg
[16] Diagrama de Paquetes. (2013). Obtenida el 14 de Julio de 2013, de
http://es.wikipedia.org/wiki/Diagrama_de_paquetes
[17] Diagrama de Tiempos. (2013). Obtenida el 14 de Julio de 2013, de
http://es.wikipedia.org/wiki/Diagrama_de_tiempos

- 104-

-105-

-106-

APNDICE 02: ENCUESTA 01


1. El manejo de control de Activos Fsicos TI, utilizado en rea de Soporte Tcnico
es:
a) Excelente
b) Bueno
c) Regular
d) Deficiente
2. La Gestin de activos fsicos TI esta automatizado:
a) Si
b) No
3. Considera usted que la implementacin de un Sistema Web mejorar el tiempo de
respuesta en el momento de solicitar un reporte?
a) Si
b) No
4. Estima que el tiempo de respuesta al realizar el inventario en existencia es rpido y
eficaz:
a) Si
b) No
5. Cules son los inconvenientes ms comunes a la hora de controlar la Gestin de
Activos TI?
a) Falta de control en la Gestin de Activos Fsicos TI.
b) Falta de control en los reportes.
c) Poco conocimiento sobre los Activos Fsicos TI.
d) Todas las anteriores.
6. Cree usted que los procedimientos actuales utilizados para realizar la Gestin de
Activos Fsicos TI es el ms ptimo:
a) Si
b) No
7. Considera usted que deben realizarse cursos de capacitacin para el manejo del
Sistema Web:
a) Si
b) No

-107-

APNDICE 03: ENCUESTA 02 - PARA SELECCIN DE LA METODOLOGA


ENCUESTA DE EVALUACIN DE METODOLOGAS DE DESARROLLO DE
SISTEMAS

Nombre: ______________________________
Cargo: ______________________________

Universidad: ___________________

Asigne el puntaje que usted considere conveniente para cada criterio de las siguientes
metodologas de desarrollo, la escala es de 1 5, donde 1 es Deficiente y 5 es Excelente

Criterios de Evaluacin

RUP

XP

ICONIX

Bibliografa
Flexibilidad
Compatibilidad
Requerimientos
Costo
Tiempo de desarrollo

TOTAL

* Descripcin de los criterios:

Bibliografa: Mide la existencia de informacin con relacin a la descripcin y aplicacin de la


metodologa
Flexibilidad: Se refiere a que si la metodologa puede adaptarse a cualquier situacin o entorno
y ver si se puede hacer variantes de acuerdo al problema.
Compatibilidad: Si el desarrollo de la metodologa puede ser aplicado a otros proyectos
relacionados con el mismo tema.
Requerimientos: Si la metodologa captura los requerimientos adecuados y correctos de los
usuarios.
Costo: Se refiere a cunto costar desarrollar esa metodologa
Tiempo de desarrollo: Se refiere al tiempo que demanda realizar el desarrollo de la
metodologa.

-108-

APNDICE 04: Artculo

DESARROLLO DE UN SISTEMA WEB PARA LA GESTIN DE ACTIVOS FSICOS TI EN


LA UNIVERSIDAD AUTNOMA DEL PER
WEB DEVELOPMENT OF A SYSTEM FOR PHYSICAL ASSET MANAGEMENT IT IN
THE AUTONOMOUS UNIVERSITY OF PERU

Reynaldo Arteta Montoya Angel Justo


Universidad Autnoma del Per
Facultad de Ciencias de Gestin
jpierre.arteta@gmail.com - angel.jp.147@gmail.com

RESUMEN
En la actualidad, en el Per existe una Gestin de Activos Fsicos TI en el bajo control de informacin sobre
activos fsicos ti, debido a que en el rea no pueden tener un control ms seguro y exacto mediante un
sistema. El proyecto tiene como finalidad brindar un Sistema Web que se desarrolla para la Gestin de
Activos Fsicos TI en la Universidad Autnoma del Per, que le permite llevar un mejor control de las
actividades del rea de Soporte Tcnico y administrativas que se realizan en la Universidad; as como
tambin proteger los datos y disponer de informacin oportuna y confiable que sea de utilidad para el rea.
La metodologa que se utiliz fue ICONIX, est es una metodologa de desarrollo del software que
se halla a medio camino entre un RUP y un XP, esta metodologa deriva directamente del RUP y su
fundamento es el hecho de que un 80% de los casos pueden ser resueltos tan solo con un uso del 20% del
UML, con lo cual se simplifica muchsimo el proceso sin perder documentacin al dejar solo aquello que es
necesario.
ICONIX se gua a travs de casos de uso y sigue un ciclo de vida iterativo e incremental. El objetivo
es que a partir de los casos de uso se obtenga el sistema final.
La finalidad al implementar el sistema web en el rea de soporte de la universidad autnoma del Per es
contar con una herramienta que interacte con el personal de soporte tcnico. Y est Gestin de activos
fsicos TI.
Palabras Claves: Sistema Web, RUP, ICONIX, Soporte Tcnico, Gestin de Activos Fsicos TI, Ciclo de
Vida Iterativo e Incremental.

ABSTRACT
Today, in Peru there is a Physical Asset Management in IT under control of information on physical assets
you, because in the area can not be more safe and precise control through a system . The project aims to
provide a Web system that is developed for IT Physical Asset Management at the Autonomous University of
Peru , which allows you to keep better track of the activities of the area of Technical and Administrative
Support performed in the University; as well as protect data and provide timely and reliable information that
is useful for the area.
The methodology used was ICONIX, is a methodology for software development that is halfway
between RUP and XP, this methodology derives directly from the RUP and its foundation is the fact that 80
% of cases can only be solved with a use of 20% of the UML, which greatly simplifies the process without
losing documents leaving only what is necessary.
ICONIX is guided by use cases and follows a cycle of iterative and incremental life. The aim is that
from the use cases for the final system.
Order to implement the system in web support area of the Autonomous University of Peru is to have
a tool to interact with the support staff . And it's IT Physical Asset Management .
Key words: Web, RUP, ICONIX, Technical Support, IT Physical Asset Management , Life Cycle Iterative
and Incremental System.

-109-

la complejidad del RUP y la simplicidad y


pragmatismo del XP (Extreme Programming), sin
eliminar las tareas de anlisis y de diseo que XP
no contempla. Presenta claramente las actividades
de cada fase y exhibe una secuencia de pasos que
deben ser seguidos.

1.- INTRODUCCIN
El presente trabajo de investigacin tiene como
objetivo principal desarrollar un Sistema Web,
utilizando la metodologa de Iconix, para mejorar
el proceso de Gestin de Activos Fsicos TI en la
Universidad Autnoma del Per.
En todas las organizaciones se realiza la Gestin
de Activos Fsicos TI, donde tienen un registro de
forma manual o en Excel, teniendo en cuenta que
requieren reducir la entrega de reportes, numero
de reportes solicitados, porcentaje en la exactitud,
porcentaje de malas decisiones tomadas y
satisfaccin del usuario. Es importante tambin la
visin histrica de todas las variables analizadas y
el anlisis de los datos del entorno. Estos
requerimientos no son difciles de resolver dado
que la informacin esta efectivamente en el
Sistema Web, puesto que cualquiera de las
actividades que realiza la organizacin est
reflejada en forma minuciosa en la base de datos.
Es fundamental que en toda empresa los procesos
estn definidos. Las herramientas que permiten
que los procesos de la empresa puedan ser
integrados satisfactoriamente son las Tctiles,
sino que no sera posible manipulacin de los
datos (Sql Server 2012)
El
presente
proyecto
consiste
en
la
implementacin de la Gestin de Activos TI a la
Universidad Autnoma del Per, que le permita
mejorar el manejo de informacin del rea. Esto
conlleva a que las personas que toman decisiones.
Las limitaciones encontradas en la fase de
desarrollo de la aplicacin del Sistema Web fue
que el tiempo para la implementacin y por eso
hubo un retraso en la realizacin de las encuestas
y/o entrevistas.

Caractersticas:

Iterativo
e
incremental:
Diversas
iteraciones suceden entre el desarrollo del
modelo del dominio y la identificacin de
los casos de uso. El modelo esttico es
incrementalmente refinado por los
modelos dinmicos.
Trazabilidad: cada paso est referenciado
por algn requisito. Se define trazabilidad
como la capacidad de seguir una relacin
entre los diferentes artefactos producidos.
Dinmica del UML: La metodologa
ofrece un uso dinmico del UML como
los diagramas del caso de uso, diagramas
de secuencia y de colaboracin.

2.2 Pasos de la Metodologa


Anlisis de Requerimientos
a.

Requerimientos funcionales: Define lo


que el sistema debe ser capaz de hacer. En
el inicio del proyecto, junto con el cliente,
los usuarios finales, y las diversas partes
interesadas del proyecto, se debe crear un
gran documento lleno con los requisitos
funcionales.

b.

Modelo de Dominio: Su objetivo es


asegurarse de que todos en el proyecto
comprendan el espacio del problema en
trminos sin ambigedades. El modelo de
dominio define el alcance y forma base
sobre la que se deben construir sus casos
de uso. Es un diagrama con los objetos que
existen relacionados con el proyecto y sus
relaciones.

c.

Modelo de Casos de Uso: Est compuesto


por los actores, el mismo sistema y los
casos de uso. Aqu se establece como debe
interactuar el usuario con el sistema, para

2.- CONTENIDO
Se ha integrado teoras referentes al Sistema Web,
con la metodologa Iconix. Adems teora sobre la
Gestin de Activos Fsicos TI en el rea de
soporte tcnico y los indicadores para medir el
desempeo del proceso de Gestin de Activos
Fsicos TI.
2.1 Fundamentacin Terica
Qu es Iconix?
Es un proceso simplificado en comparacin con
otros procesos ms tradicionales, que unifica un
conjunto de mtodos de orientacin a objetos con
el objetivo de englobar todo el ciclo de vida de un
proyecto.
ICONIX est adaptado a los patrones y ofrece el
soporte de UML, dirigido por casos de usos y es
un proceso iterativo e incremental que est entre

-110-

precisar
qu
informacin
desean
intercambiar y describir lo que desean
obtener como resultado.

Implementacin
h.

Generar el Cdigo: Lo importante de la


interactividad, la accesibilidad y la
navegacin en el sistema harn que el
usuario se sienta cmodo y seguro al hacer
uso de la aplicacin sin problemas. Pero
adems se debe tener en cuenta la
extensibilidad, la confiabilidad y la
reusabilidad del sistema.

i.

Pruebas: Para garantizar esto se realizan


diferentes tipos de pruebas que permitirn
verificar la aceptacin de los resultados.

Anlisis y Diseo Preliminar


d.

e.

Descripcin de Casos de Uso: Los casos


de uso describen el comportamiento de un
sistema bajo la forma de acciones y
reacciones desde el punto de vista de un
usuario; adems permiten definir los
lmites del sistema y las relaciones que
existen entre el sistema y el entorno del
mismo.
Diagramas de Robustez: En el cual se
ilustran grficamente las interacciones
entre aquellos objetos participantes de un
caso de uso. Los que pueden ser; Objetos
de interfaz, Objetos entidad, Objetos de
Control.

3.- APLICACIN DE ICONIX


3.1 Stakeholders internos externos

Diseo Detallado
f.

g.

Diagrama de Secuencia: Es el centro del


modelo dinmico del sistema y muestra los
caminos alternos que pueden tomar los
casos de uso, a la vez se especifica el
comportamiento y las representaciones que
se concentran sobre la expresin de las
interacciones.
Este
diagrama
est
compuesto de 4 elementos que son: el
curso de accin, los objetos, los mensajes y
los mtodos.

3.2 Cadena de Valor

Diagrama de clases Final: se revisa el


diagrama de clases anterior y de acuerdo a
ello se mejora para elaborar el diagrama de
clases final que se utilizar para la
implementacin.

-111-

3.3 Flujograma Actual


C. Necesidades de Usuarios e Interesados

ID

DESCRIPCIN

NEC01

El Sistema deber permitir registrar las fechas


de bajas de los componentes TI.

NEC02

El Sistema deber registrar las reas de los


componentes de mantenimiento.

NEC03

El Sistema deber registrar el usuario de donde


se realiz el mantenimiento.

NEC04

El sistema deber permitir consultar e informar


sobre las actividades segn lo requerido.

NEC05
NEC06
NEC07
NEC08

El Sistema deber permitir ingresar los datos de


os componentes TI.

3.4. ANLISIS DE REQUERIMIENTOS


3.4.1 Requerimientos del Sistema
ID

DESCRIPCIN

Car
-01
Car
-02
Car
-03

El Sistema debe mostrar al Jefe de Soporte las


fechas del registro de mantenimiento.
El Sistema debe mostrar el registro de
componentes.
El sistema debe mostrar el lugar donde se
realiza el mantenimiento.
El Sistema deber permitir registrar las
condiciones de los componentes TI
(Proyector).
El Sistema deber permitir registrar los
documentos de garanta de componentes.
El Sistema deber grabar y generar un PDF
interno.
El Sistema deber permitir mostrar un
catlogo.
El Sistema deber permitir avisar la
aproximacin de los proyectores.
El Sistema deber permitir ingresar el rea
donde se realiza el mantenimiento.
El Sistema deber permitir revisar seleccionar
el rea donde se realiza el mantenimiento.
El Sistema deber permitir enviar al
corporativo (soporte).
El Sistema deber permitir Consultar al jefe de
Soporte mostrar donde se realiz el
mantenimiento.

Car
-04
B) Descripcin de Usuarios e interesados

DESCRIPCIN

Personal de
Soporte

Es el interesado de gestionar y
registrar los componentes.

Jefe de
Soporte

Es el interesado de consultar
informacin sobre los registros
de componentes.

El Sistema deber permitir consultar los


registros.
El Sistemas deber permitir generar en PDF
interno y envi a un correo especfico.
D. Caractersticas generales

3.4.1.1 Visin del sistema


A) Introduccin
A continuacin se describen las
necesidades de los usuarios e interesados
en el Sistema Web para la Gestin de
Activos Fsicos TI a la Universidad
Autnoma del Per, y las caractersticas
que debe tener.

ROL

El Sistema deber permitir grabar.

Car
-05
Car
-06
Car
-07
Car
-08
Car
-09
Car
-10
Car
-11
Car
-12

-112-

3.4.3. Modelo de Casos de Uso

E. Casos de Uso derivados de las


caractersticas

3.5. ANLISIS Y DISEO PRELIMINAR


3.5.1 Descripcin de casos de uso

Car-01

Consultar fecha de

CU-01

mantenimiento.

Car-01

Registro de

CU-02

componentes TI.

Car-03 Car

Consultar lugar donde

uc Use Case Model

Consultar Catalogo

12 Car -10

se realiz el

CU-03

mantenimiento.

Registrar los
Componentes TI
Consular Fecha

Registrar Condicion y
Garantia de Componentes TI

Consultar Lugar

Visualizar un PDF y Env iar al


correo corporativ o
Registrar y Alertar
aproximacion de horas de
los proyectores

Registrar condiciones

Car04- Car05

de garanta de los

Cu- 04

componentes TI.

Para la descripcin de casos de uso y las


siguientes etapas de anlisis y diseo se realizaran
los dos casos de uso de alta prioridad, para lo cual
se ha evaluado segn la siguiente tabla de
priorizacin:

Visualizar un PDF

Car 06 Car

interno y enviar al

11

Segn estos criterios se ha evaluado los


casos de uso de acuerdo a las necesidades
expresadas por los usuarios del sistema,
asignndose las siguientes calificaciones:

correo corporativo

CU-05

(soporte).

Car 07

Mostrar catlogo de

CU-06

componentes TI.
Alertar aproximacin

Car08

CRITERIO

de horas de los

CU-07

RI: Riesgo; Tecnolgico

proyectores

, complejo ,nuevo, etc.

3.4.2 Modelo de Dominio

S.A: Significativo para la


class Domain Model

arquitectura

Recurso
Personal Soporte
-

0..* -

Registra

Usuario: varchar
Contrasea: int

Descripcion: varchar
Tipo: int
Ubicacion: int
Catalogo
-

0..*

NC: Naturaleza critica de

Descripcion: int

0..1

valor para el negocio

Registra
0..*

0..*

0..*
Visualiza

Consulta
Consulta
-

Descripcion: int
Fecha: int

Pertenece
1

Pertenece

Jefe Soporte
0..*

Usuario: int
Contrasea: int

Pertenece
Recibe
1
Componentes
-

Jefe de Soporte

Personal de Soporte

Nombre: varchar
Mantenimiento: int

Anuncio (PDF)

1
1

Pertenece

Descripcion: int

0..*

0..*

-113-

PESO RANGO
3

03

03

03

Requisito
Gestionar recursos de
componentes TI.
Gestionar catlogo de
componente TI.
Consultar lugar de
mantenimiento.

RI

SA

NC

Puntaje

18

15

Gestionar consultas.

10

Iniciar Sesin.

Consultar alertas.

Generar PDF.

Enviar Correo
Electrnico.

IDENTIFICAD
OR:
R:CU-02
CATEGORA:
Core

ACTORES:
Personal de Soporte
Jefe de Soporte

PROPSITO:
Permite gestionar el registro de los componentes,
modificar las cantidades de componentes.
PRECONDICIN:
El caso de uso Iniciar sesin debe haberse
ejecutado.
El caso de uso Consultar el mantenimiento
realizado por rea,

Segn esta evaluacin se ha dividido los casos de


uso en Alta Media o Baja prioridad:
Prioridad

ALTA

Requisito

MEDIA

FLUJO BSICO:
B1. El actor selecciona la opcin Registrar
B2. El sistema muestra una ventana con una lista
de componentes guardados de acuerdo al registro.

Comentario

Gestionar recursos de Implementacin


de mayor
componentes TI
dificultad, su
Gestionar catlogo de prioridad en la
campo TI
estructura del
sistema y la
necesidad por
Gestionar consulta
parte de los
usuarios es alta
Consultar alertas
Generar PDF
Enviar Correo:
Corporativo
Consultar lugar de
mantenimiento

BAJA
Iniciar Sesin

NOMBRE:
Gestionar recursos de
Componentes TI
COMPLEJID PRIORID
AD:
AD:
Alta
Alta

POSCONDICIN:
El sistema muestra caractersticas de cada
componente.
El sistema registra los componentes
El sistema genera y enva al correo corporativo
(Soporte)

Procesos
medianamente
importantes, con
dificultad de
implementacin
media.
De fcil
implementacin,
efecto mnimo
en la estructura
del sistema

De acuerdo a esta evaluacin se comienza la


descripcin de los casos de uso de alta prioridad.

-114-

Diagrama de Robustez

IDENTIFICAD NOMBRE:
Gestionar recursos de
OR:
R:CU-02
Componentes TI
FLUJOS ALTERNATIVOS:
A1. Gestionar recurso de componentes TI
A1.1. Luego del paso B2 del flujo bsico,
personal de Soporte o el Jefe soporte
seleccione una de las carpetas existentes
donde desee guardar un registro (el personal
de soporte no podr emitir reporte)
A1.2. El sistema muestra en una nueva
pantalla los campos que deben llenar para
registrar (descripcin de cada componentes,
como
tambin
los
mantenimientos
realizados por reas.
A1.3. El personal de Soporte o el Jefe de
Soporte ingresan las descripciones de los
componentes.
A1.4. El Sistema grabara al ingresar los
datos correspondientes
A1.5. El Flujo retorna al paso B2 del Flujo
bsico
A2. Modificar estado del registro
A2.1. Luego del paso B2 del flujo bsico, el
personal de soporte o jefe de soporte
seleccione un recurso.
A2.2 El Sistema muestra una ventana con
las propiedades del componente TI
A2.3. El actor seleccionara un generador
para PDF y poder enviar el correo
Corporativo
A2.4. El sistema actualiza el estado del
recurso
A2.5. El flujo retorna al paso B2 flujo
bsico
A3. Eliminar y Modificar los componentes TI
A3.1. Luego del paso B2 del flujo bsico, el
personal de soporte o jefe de soporte
seleccione un componente
A3.2. El sistema muestre una ventana con
las propiedades del componente (marca
modelo registrar los mantenimientos de pcs
por rea y aulas)
A3.3. El actor selecciona la opcin eliminar,
modificar.
A3.4. El sistema elimina / modifica el
componente TI
A3.5. El flujo retorna al paso B2 del flujo
bsico.

class Data Model

Interfaz Registro

Interfaz Mantenimiento

Personal Soporte

Propiedades de
Mantenimiento

Gestionar
Mantenimiento

Gestionar
Mantenimiento

Consultar
Componentes

Gestionar
Componentes

Componentes

Componentes

Consultar Garantia de
Componentes
Registro de
Componentes

Jefe deSoporte

Genera PDF

Interfaz de
Mantenimiento

3.6.. DISEO DETALLADO


3.6.1.. Diagrama de Secuencia
a.- Caso de Uso: Gestionar Registro de
Componentes TI

b.- Caso de Uso: Gestionar Catlogos de


Componentes TI

-115-

c.- Caso de Uso: Gestionar Consultar

Tanto en ausencia como en presencia del Sistema


Web.
Al finalizar la prueba se espera que los resultados
del grupo O1 sean mejores que el O2.
5.- RESULTADOS
A continuacin se presentan las medias de los
KPIs para la Post-Prueba (Gc) y Post-Prueba
(Ge): Resultados numricos.

Indicado
r

PostPrueba
(Gc)
(Media: )

PostPrueba
(Ge)
(Media: )

Comenta
rio

Tiempo
para
47 min.
3 min.
generar
reportes
Nmero
reportes
11
7
solicitado
reportes/ci
reportes/ci
s por
clo
clo
ciclo
Porcentaj
e en la
exactitud
93%
de
50%
informaci
n
Porcentaj
e de
malas
2.50%
decisione
55%
s
tomadas
Satisfacci
No
n del
contrastad
Usuario
o.
Indicador Tiempo para generar reportes: KPI1

4.- DISEO DE INVESTIGACIN


Ge X O1
Gc O2
Dnde:
Ge = Grupo Experimental: Es el grupo
de estudio al que se aplicar el estmulo
(Sistema Web).
X = Sistema Web: Estmulo o condicin
experimental.
Gc = Grupo de Control: Es un grupo de
control al que no se aplicar el estmulo
(Sistema Web).
O1 = Datos de la Post-Prueba para los
indicadores de la Variable Dependiente
una vez implementado el Sistema Web:
Mediciones Post-Prueba del grupo
experimental.
O2 = Datos de la Post-Prueba para los
indicadores de la Variable Dependiente
una vez implementado el Sistema Web:
Mediciones Post-Prueba del grupo de
control.
- = Falta de estmulo o condicin
experimental.
Descripcin:
Se trata de escoger de forma intencional de un
grupo experimental (Ge), al que se aplicar un
Sistema Web (X), el cual se les aplica a
trabajadores del rea de Soporte Tcnico de la
Universidad Autnoma del Per (O1); en un
segundo grupo (Gc), conformado de manera
intencional por trabajadores del rea de Soporte
Tcnico de la Universidad Autnoma del Per,
donde no se le aplicar el estmulo, sirviendo slo
como grupo de control; en forma simultnea se le
aplica una prueba (O2).
Los dos grupos estn constituidos de forma
intencional pero representativa estadsticamente.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-116-

Post-prueba
(Gc)
40
42
49
55
53
55
41
41
45
50
53
49
45
47

Post-prueba (Gc)
2
3
2
1
3
3
3
4
5
3
2
3
3
3

2
3
2
1
3
3
3
4
5
3
2
3
3
3

2
3
2
1
3
3
3
4
5
3
2
3
3
3

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

48
51
50
50
44
42
46
50
50
50
51
52
55
48
47
49
48.24

Promedio
Meta
Planteada
N menor a
Promedio
%

4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3

4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3
3.17

4
5
4
4
4
3
2
4
3
2
3
3
2
4
5
3

La distancia promedio de las observaciones


individuales de los Tiempos en realizar los reportes
con respecto a la media es de 0.93%.
Alrededor del 95% de los Tiempos en realizar los
reportes estn dentro de 2 desviaciones estndar de
la media, es decir entre 2,79 y 3,53 minutos.
La Kurtosis = -0,17 indica que hay valores de
tiempo con picos muy bajos.
La Asimetra = 0,10 indica que la mayora de los
tiempos en realizar reportes son altas.
El Primer Cuartil (Q1) = 2.75 minutos indica que el
25% de los Tiempos en realizar reportes son altas.
El Tercer Cuartil (Q3) = 4 minutos indica que el
75% de los Tiempos en realizar los reportes es
menor que o igual a este valor.

CONCLUSIONES

3.5
20
66.66

a.

20
66.66

30
100
b.

El 66,66% de los Tiempos del Personal en


generar reportes en la Post-Prueba (Gc) fueron
menores que su tiempo promedio.
El 66.66% de los Tiempos del Personal en
generar reportes en la Post-Prueba (Ge) fueron
menores que la meta planteada.
El 100% de los Tiempos del Personal en
generar Reportes en la Post-Prueba (Ge)
fueron menores que el tiempo promedio en la
Post-Prueba (Gc).

c.

d.

e.

f.
Los datos tienen un comportamiento poco normal
Resumen para el Tiempo del Personal en Generar Reportes
A nderson-Darling N ormality Test

A -S quared
P -V alue <

1.35
0.005

M ean
StDev
V ariance
Skew ness
Kurtosis
N

3.1667
0.9855
0.9713
0.107215
-0.170292
30

M inimum
1st Q uartile
M edian
3rd Q uartile
M aximum

g.

1.0000
2.7500
3.0000
4.0000
5.0000

h.

95% C onfidence Interv al for M ean


2.7987

3.5347

95% C onfidence Interv al for M edian


3.0000

3.7713

95% C onfidence Interv al for StDev


9 5 % Confidence Inter vals

0.7849

1.3249

Mean

i.

Median
2.8

3.0

3.2

3.4

3.6

3.8

debido a que el Valor p (0,005)< (0,05), pero son


valores cercanos, lo cual se confirma al observarse
que los intervalos de confianza de la Media y la
Mediana se traslapan.

-117-

Con los resultados obtenidos en la presente


investigacin se mejora la Gestin de
Activos fsicos TI en la Universidad
Autnoma del Per
Se comprueba que ICONIX es una buena
metodologa para desarrollar un sistema
web.
Se realiz el Anlisis de requerimientos para
la identificacin de casos de uso y modelo
de dominio.
Se realiz el Anlisis y diseo preliminar
para la descripcin de casos de uso y el
Diagrama de Robustez.
Se realiz el Diseo detallado, donde se
identific el diagrama de secuencia,
diagrama de clases final, diagrama de
componentes y el diagrama de despliegue.
Se realiz la fase de implementacin
mediante las pruebas del sistema, donde se
aplic las tcnicas de caja negra y caja
blanca.
Se verifica que los inventarios de los
Activos Fsicos TI, ha sido de manera
automatizada mediante un sitio web para dar
a conocer en mayor detalle y en forma
ordenada.
Se comprueba, que el personal de Soporte
Tcnico podr desarrollar los informes de
manera adecuada, rpida y sencilla al no
tener que generar informacin en forma
manual.
Se mejora, la calidad del servicio,
incrementando la satisfaccin del jefe y
personal de soporte, as como la reduccin
del tiempo para registrar activos fsicos TI.

[13] Rosa Menndez Mueras. Construccin de


Software Orientado Objetos con el Proceso
Unificado y UML, un punto de vista prctico.
Lima: Consejo Editorial UCCI; 2005.
[21] Oscar Casasola Romero. Introduccin a
UML. Programacin en Castellano. Espaol;
2010.
[8] Sergio Lujn Mora. Programacin de
aplicaciones web: historia, principios bsicos y
clientes web. San Vicente: Editorial Club
Universitario; 2002.
[7] Kenneth C. Laudon, Jane P. Laudon. Sistemas
de Informacin Gerencial. Mxico: Pearson
Education; 2004.
[18]
Beck,
Kent.
Planning
Extreme
Pogramming.Addison Wesley; 2000.
[19] Rosenberg, Doug. 2005. Agile Development
with ICONIX. s.l. : Apress, 2005.
[20] Rosenberg, Doug y Stephens, Matt. 2007.
Use Case Driven Object Modeling with UML. s.l.
: Addison-Wesley, 2007.

AGRADECIMIENTOS
Agradezco a Dios, a mis padres y mis hermanas
por ser mis guas y estar pendientes siempre de
m; porque sin su ayuda no habra sido posible
realizar este proyecto ni ser alguien en la vida.
Una mencin ultima pero sin menos importante
agradezco al Ingeniero Jusein Quevedo Cabrera
por su apoyo y tiempo incondicional, durante el
proceso de desarrollo de este Proyecto.

Reynaldo Jean Pierre Arteta Montoya

Agradezco a Dios, a mis padres por el apoyo


constante e incondicional durante la realizacin
de este proyecto, a mis hermanos por el apoyo y
compresin por sus consejos para seguir adelante
en mi vida profesional

[12] Bermeo, F. (2010). RUP. Obtenida el 27 de


Mayo
de
2013,
de
http://fabianbermeop.blogspot.com/2010/12/meto
dologia-rup-desarrollo-de-software.html
[10] Tipos de sistemas para empresas. (2007)
Obtenida el 30 de Mayo de 2013, de
http://www.informatica-hoy.com.ar/aprenderinformatica/Tipos-de-sistemas-para-empresasERP-CRM-B2B-y-mas.php
[9] Guayms, H. (N.D). Caractersticas de un
Sistema Web. Obtenida el 30 de Mayo de 2013,
de
https://sites.google.com/site/hguaymas/servicios3
[11] Guzmn, L. (2012). RUP. Obtenida el 27 de
Mayo
de
2013,
de
http://es.scribd.com/doc/51486224/rup
[14.1] Proceso (Informtica). (2013). Obtenida el
7
de
Junio
de
2013,
de
http://es.wikipedia.org/wiki/Proceso_(inform%C3
%A1tica)
[22] Manual de Mantenimiento de PCs e
Introduccin a Redes. (N.D). Obtenida el 7 de
Junio
de
2013,
de
http://www.proulex.com/computo/oe/doc/manteni
miento-win7.pdf
[23] Manual de Normas y Procedimientos
Registro y Adquisicion de Bienes. (2004).
Obtenida el 7 de Junio de
2013, de
http://www.ucv.ve/fileadmin/user_upload/vrad/do
cumentos/DPP/Manuales/Manuales/Adquisicion_
_Bienes_SIAF.pdf
[15] Universidad Fermn Toro (N.D). Diagrama
de Estructura Compuesta UML 2. Obtenida el 14
de
Julio
de
2013,
de
https://www.google.com.pe/url?sa=t&rct=j&q=&
esrc=s&source=web&cd=19&cad=rja&ved=0CH
UQFjAS&url=http%3A%2F%2Fds-

Angel Bylly Justo Paipay

REFERENCIAS BIBLIOGRFICAS
[1] Suniaga, J. (2009). Desarrollo de una
Aplicacin Web basada en Tecnologa Helpdesk
para ofrecer servicios de Soporte Tcnico e
Inventario en la Gerencia de Informtica de la
empresa C.A. Hidrolgica del Centro, en Valencia
Estado Carabobo . Tesis pre-grado, Universidad
de Oriente, Barcelona, Espaa.
[2] Polanco, V. (2007). Desarrollo de una
aplicacin WEB para soporte de gestin de
negocio y manejo de inventario para la empresa
INVERSIONES VPL, C.A.. Tesis pre-grado no
publicada, Universidad Nueva Esparta, Caracas,
Venezuela.
[6] Alva, J., Paredes, N. (2005). Desarrollo e
Implementacin de un Sistema Web para el
Control Acadmico en el Instituto Superior
Pblico Chocope. Tesis pre-grado, Universidad
Csar Vallejo, Trujillo.
[4] Guerra, T. (2007). Desarrollo de un
Aplicativo Web basado en Ajax para el Control
de Inventarios Mobiliarios de la Institucin
Educativa Pronoe Galileo. Tesis Pre-Grado,
Universidad Nacional del Santa, Chimbote.
[5] Carrin, P., Huamn, L. (2005). Sistema
Informtico y Web para los Servicios Acadmicos
del Instituto Superior Pedaggico Privado Talara
basadas en Tecnologas .net. Madrid: Banesto
Fundacin Cultural. Trujillo.

-118-

uft.wikispaces.com%2Ffile%2Fview%2FDiagram
a%2Bde%2BEstructura%2BCompuesta%2BUM
L%2B2.doc&ei=AxHoUZJc0uXgA6KMgNgI&u
sg=AFQjCNFDn_bLiTDbYBxvLlkfyf9VsTMM
VA&sig2=Vouu4TS0hQpqth58vOloWA&bvm=b
v.49478099,d.dmg
[16] Diagrama de Paquetes. (2013). Obtenida el
14
de
Julio
de
2013,
de
http://es.wikipedia.org/wiki/Diagrama_de_paquet
es
[17] Diagrama de Tiempos. (2013). Obtenida el
14
de
Julio
de
2013,
de
http://es.wikipedia.org/wiki/Diagrama_de_tiempo
s

-119-

GLOSARIO DE TRMINOS
A
Activo: Bien o derecho que tiene el valor econmico positivo para la empresa. Conjunto
de bienes y crditos pertenecientes a una persona o empresa.

Activo Fsico: Todo objeto o bien que posee una persona natural o jurdica, tales como
maquinarias, equipos, edificios, muebles, vehculos, materias primas, productos en
proceso, herramientas, etc.

Anlisis de Requerimientos: La etapa en que se estudian los requerimientos para verificar


que estn correctamente adecuados a las caractersticas mencionadas. En la misma se
enfocan e intentan solucionar las deficiencias que los requerimientos puedan tener.

Arista: Las flechas son llamadas aristas y representan el grafo de flujo. Una arista debe
terminar en un Nodo, incluso aunque no represente ninguna secuencia procedimental.

Apndice: Cosa adjunta o aadida a otra, especialmente el anexo o suplemento que se


incluye al final de un libro, de una obra o de un trabajo de investigacin.

B
Base de Datos: Conjunto de datos pertenecientes a un mismo contexto y almacenados
sistemticamente para su posterior uso.

C
Cadena de Valor: Desarrollan las acciones y actividades de una empresa. En base a la
definicin de cadena, es posible hallar en ella diferentes eslabones que intervienen en un
proceso econmico: se inicia con la materia prima y llega hasta la distribucin del producto
terminado. En cada eslabn, se aade valor, en trminos competitivos, est entendido como
la cantidad que los consumidores estn dispuestos a abonar por un determinado producto o
servicio.

-120-

Complejidad Ciclomtica: Entendemos el valor obtenido tras el recuento del nmero de


caminos lgicos individuales que un programa debe evaluar hasta obtener un resultado o,
dicho de otro modo, es el clculo metdico de la complejidad lgica de un programa.

Control de Activos: Controlar los movimientos de los activos tangibles adquiridos,


construidos o en proceso de construccin, los cuales pueden ser empleados en la
produccin o suministro de otros bienes y servicios, o en la administracin del negocio.

Cuartil: Son los tres valores que dividen al conjunto de datos ordenados en cuatro partes
porcentualmente iguales.

D
Diseo: Actividad o proceso que identifica requerimientos y entonces define una solucin
que es capaz de alcanzar dichos requerimientos.
Diagrama de Actividades: Representa los flujos de trabajo paso a paso de negocio y
operaciones de los componentes de un sistema. Un Diagrama de Actividad muestra el flujo
de control general.
Diagrama de Clases: Representan la estructura esttica en trminos de clases y relaciones.
Diagrama de Despliegue: Es un tipo de diagrama del Lenguaje unificado que se utiliza
para modelar el hardware utilizado para la implementacin de sistemas y las relaciones
entre sus componentes.
Diagrama de Estados: Son tcnicas para describir el comportamiento de un sistema.
Describen todos los estados posibles en los que se puede entrar un objeto en particular y la
manera en que cambia el estado del objeto.
Diseo de Investigacin: Es la estructura a seguir en una investigacin ejerciendo el
control de la misma a fin de encontrar resultados confiables y su relacin con los
interrogantes surgidos de la hiptesis.

Grafo de Flujo: Se puede establecer caminos de ejecucin y tambin caminos entre la


declaracin y el uso de un dato, de donde surgen diversos mtodos de prueba.

-121-

Grupo Experimental: Grupo al que se le aplica el programa que est evaluando.


Grupo de Control: Grupo al que no se le aplica el programa que est evaluando.

H
Hiptesis:Afirmacin que se considera lo suficientemente fiable o creble como para basar
sobre ella una tesis o teora demostrada o confirmada con datos reales.

I
Iconix: Es un proceso simplificado en comparacin con otros procesos ms tradicionales,
que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de englobar
todo el ciclo de vida de un proyecto.
ICONIX est adaptado a los patrones y ofrece el soporte de UML, dirigido por casos de
usos y es un proceso iterativo e incremental que est entre la complejidad del RUP y la
simplicidad y pragmatismo del XP (Extreme Programming), sin eliminar las tareas de
anlisis y de diseo que XP no contempla. Presenta claramente las actividades de cada fase
y exhibe una secuencia de pasos que deben ser seguidos.

Indicador: Dato o informacin que sirve para conocer o valorar las caractersticas y la
intensidad de un hecho o para determinar su evolucin futura.

Interfaces: Las interfaces web tienen ciertas limitaciones en las funcionalidades que se
ofrecen al usuario.
Inventario: Por inventario se define al registro total de los bienes y dems cosas
pertenecientes a una persona o comunidad, hecho con orden y precisin.

M
Metodologa: Conjunto de mtodos que se siguen en una investigacin cientfica o en una
exposicin doctrinal.
Muestra: Parte o cantidad pequea de una cosa que se considera representativa del total y
que se toma o se separa de ella con ciertos mtodos para someterla a estudio, anlisis o
experimentacin.

-122-

N
Nodo: Los crculos son llamados Nodos y representan una o ms acciones. Un solo nodo
puede corresponder a una secuencia de cuadros de proceso.
P
Proceso: Secuencia de pasos para realizar alguna actividad e incluye la descripcin de
entradas, salidas, procedimientos, herramientas, responsabilidades y criterios de salida.

Prioridad: Categora empleada para identificar la importancia relativa de un incidente,


problema o cambio. La prioridad se basa en el impacto y la urgencia, y es utilizada para
identificar los plazos requeridos para la realizacin de las diferentes acciones.
Prototipo: Puede ser un modelo del ciclo de vida del software.

R
Reportes: Es aquel documento que se utilizar cuando se quiera informar o dar noticia
acerca de una determinada cuestin. Puede emplearse internamente dentro de una empresa.

RUP: El Proceso Unificado Rational (Rational Unified Proccess en Ingls, conocido como
RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de
Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis,
implementacin y documentacin de sistemas orientados a objetos.

S
Sistema de Informacin (SI): Es considerado como un conjunto de componentes
interrelacionados que recuperan, procesa, almacenan y distribuyen informacin para
soportar la toma de decisiones, la coordinacin y el control de una organizacin.
Stakeholders Interno: La mayora de los stakeholders claves son personas que laboran
dentro de la organizacin sobre la cual se va a desarrollar el proyecto.
Stakeholders Externo: Los de este grupo tienen inters intrnseco en el proyecto ms,
aunque no formen parte de la organizacin.

Sistema Web: Son aquellos que no son desarrollados sobre una plataforma o sistema
operativo, sino que se administra en un servidor sobre una Intranet y/o Internet.
-123-

SQL: El lenguaje de consultas estructuradas o SQL es un lenguaje declarativo de acceso a


bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas.

T
TI: Tecnologa de Informacin, conjunto de tcnicas que permiten la captura,
almacenamiento, transformacin, transmisin y presentacin de la informacin generada o
recibida a partir de procesos, de manera que pueda ser organizada y utilizada en forma
consistente y comprensible por los usuarios que estn relacionados con ella. Incluye
elementos de hardware, software, telecomunicaciones y conectividad.
U
UML: Es una tcnica de modelado, no una metodologa o el caso de modelamiento
Arquitect, muchas personas tienen esa confusin, espero despus de esta clara explicacin
no haya lugar a dudas.

V
Variable: Factor o caracterstica que puede variar en un determinado grupo de individuos
o hechos, especialmente cuando se analizan para una investigacin o un experimento.

Visual Studio: Es un entorno de desarrollo integrado (IDE, por sus siglas en ingls) para
sistemas operativos Windows. Soporta mltiples lenguajes de programacin tales como
C++, C#, Visual Basic .NET, F#, Java, Python, Ruby, PHP; al igual que entornos de
desarrollo web como ASP.NET MVC, Django, etc.
Tambin pueden crear aplicaciones que se comuniquen entre estaciones de trabajo, pginas
web, dispositivos mviles, dispositivos embebidos, consolas, etc.
X
XP: La metodologa XP (Extreme Programming) tiene como principal objetivo adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto

-124-

S-ar putea să vă placă și