Priyecto

UNIVERSIDAD ANDRES BELLO
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA
INGENIERIA EN COMPUTACIN E INFORMTICA

PROYECTO DE SOFTWARE PARA GESTIONAR LA HABILITACIN DE PUERTOS
DE IPs DE SERVIDORES DENTRO DE LA ARMADA DE CHILE

SERGIO ORELLANA JARAMILLO
MARIO ANDRES VIROT JARA

VIA DEL MAR, CHILE
2013

HABILITACIN PUERTOS PARA IPs Pgina 2

Dedicado a nuestras familias por el
el apoyo incondicional, el cual sin ellos
no hubiera sido posible enfrentar este camino
de nuevas experiencias para la obtencin
de logros personales y profesionales.


AGRADECIMIENTOS

A nuestros docentes de la Universidad Nacional Andrs Bello por
acrecentar nuestro conocimiento profesional y
la excelente disposicin durante todos estos aos.
Al Sr. Vctor Sanhueza por confiar y brindarnos la
responsabilidad para el desarrollo
de este proyecto.


Resumen

El objetivo de la presente tesis es documentar los procesos el cual llevaron al
desarrollo del proyecto donde nos permitir evaluar y detectar de forma concreta los
pasos seguidos, las deficiencias y las mejoras para el producto solicitado.
La Armada de Chile est constituida por diferentes reparticiones y direcciones
tcnicas, el cual permite otorgar solucin a las diferentes actividades y roles de la
organizacin, la entidad encargada de correcto funcionamiento de la red WAN Armada
e implantacin de tecnologas de la Informacin dentro de la institucin, es la Direccin
de Telecomunicaciones e Informtica de la Armada (DIRECTELINF).
La misin de esta direccin tcnica es enfrentar el desarrollo tecnolgico
presente y futuro en el mbito de las tecnologas de la informacin, alcanzando
soluciones eficientes y que den respuesta a las necesidades de esta organizacin.
En la institucin existen diferentes aplicaciones Web las cuales son
administradas por reparticiones o direcciones tcnicas, estas permiten ejercer
actividades relacionadas con la funcin especfica del funcionario dependiendo su
grado y especialidad.
Sin embargo, la habilitacin de los puertos para las diferentes aplicaciones son
efectuada por la direccin tcnica DIRECTELINF, mediante un proceso de mensajera
naval, el cual involucra varias personas para la confeccin de dicho medio de
comunicacin y por consiguiente los tiempos de tramitacin superan los 3 das para dar
respuesta a las solicitudes, adems el almacenado de este documento posee un tiempo
de expiracin, el cual provoca perdida del historial almacenado de habilitaciones.
Se propone desarrollar una aplicacin Web el, cual permita tramitar y gestionar la
habilitacin de puertos de IPs desde la reparticin duea de la aplicacin hasta
DIRECTELINF como responsable red WAN Armada.


El sistema a desarrollar ser accesado por diferentes funcionarios todos
relacionados en el mbito de los cargos de Red WAN en las diferentes reparticiones o
direcciones tcnicas.
El Modelo Incremental fue la metodologa elegida como gua para el proceso
desarrollo de software, caracterizado por la combinacin de elementos del modelo lineal
Secuencial con filosofa iterativa de construccin de prototipos, produciendo en cada
Secuencia un Incremento del software.
La arquitectura utilizada para el proyecto a desarrollar consiste en una
arquitectura de tres capas, albergados en una granja compuesto por un servidor WEB y
uno de datos.
Las tecnologas utilizadas fueron Rational Rose, el cual es una Herramienta
para modelar un sistema mediante el lenguaje unificado de modelado (UML), el cual,
nos permiti especificar y describir mtodos o procesos del sistema, los flujos de trabajo
de cada fase de elaboracin del software y Microsoft Visual Studio 2010 Professional,
Herramienta IDE (ambiente integrado de desarrollo) esencial para los desarrolladores
con mltiples lenguajes, usado para este proyecto el lenguajes de programacin Visual
C#, montado en entornos de desarrollo Web como ASP.NET y con motor de base datos
incluida SQL Server.
Para las pruebas fueron definidas por cada funcionalidad del sistema, divididos
en los diferentes mdulos que la componen.
La entrega del proyecto de acuerdo a la metodologa escogida basados en los
Incrementos operacionales, fue dividida en la composicin estructural de la aplicacin,
considerando 4 mdulos principales relacionadas con los perfiles de los usuarios
El resultado final del proyecto, fue de acuerdo a los objetivo planteados y a la
correcta planeacin, basados en los buenos requerimientos entregados por el cliente, el
cual signific tener el sistema de informacin terminado y funcionando.


INDICE
1. Captulo I ....................................................................................................... 12
Introduccin ................................................................................................................. 12
1.1 Introduccin ............................................................................................................... 13
2. Captulo II ...................................................................................................... 14
Fundamentacin del Tema ......................................................................................... 14
2.1 Identificacin de la Organizacin. ................................................................................ 15
2.2 Situacin Actual .......................................................................................................... 16
2.3 Identificacin del problema. ....................................................................................... 19
2.3.1 Mtodo de Anlisis Situacin Actual ........................................................................................ 20
2.4 Solucin Propuesta. .................................................................................................... 21
2.4.1 Arquitectura de Solucin propuesta ......................................................................................... 24
2.5 Diagrama de Paquete. ................................................................................................ 25
2.6 Diagrama de Componente .......................................................................................... 27
2.7 Diagrama de Despliegue. ............................................................................................ 28
2.8 Diagrama de Actividad de los Casos de Usos ................................................................ 29
2.9 Diagrama de Clases ..................................................................................................... 30
2.10 Enfoque de la Solucin................................................................................................ 31
2.10.1 Enfoque Funcional ...................................................................................................................... 31
2.11 Objetivos .................................................................................................................... 32
2.11.1 Objetivo Principal ........................................................................................................................ 32
2.11.2 Objetivos Especficos ................................................................................................................. 32
2.12 Alcance del Proyecto .................................................................................................. 33
2.12.1 Supuestos del Alcance del Proyecto ....................................................................................... 33
2.12.2 Limitacin al Alcance del Proyecto ........................................................................................... 33
2.12.3 Factores Crticos de xito .......................................................................................................... 34
2.12.4 Especificacin de Requerimientos ...................................................................................35
2.12.5 Requerimientos Funcionales ..................................................................................................... 35
2.12.6 Requerimientos No Funcionales ............................................................................................... 36
2.13 Actores del Sistema .................................................................................................... 37
2.14 Evaluacin del Proyecto .............................................................................................. 40


2.14.1 Factibilidad Tcnica .................................................................................................................... 40
2.14.2 Factibilidad Econmica .............................................................................................................. 40
2.14.2.1 Costo Hardware / Software ..............................................................................................40
2.14.2.2 Costo Recurso Humano ...................................................................................................41
2.14.2.3 Costos Totales ..................................................................................................................42
2.14.2.4 Anlisis Costo Beneficio ................................................................................................42
2.14.2.5 Beneficio Proyecto ............................................................................................................47
2.14.3 Factibilidad Legal ..............................................................................................................47
3. Captulo III ..................................................................................................... 48
Materiales y Mtodos .................................................................................................. 48
3.1 Enfoque Metodolgico ............................................................................................... 49
3.2 WBS (Work Breakdown Structure) .............................................................................. 51
3.3 Puntos de Funcin de Casos de Uso ............................................................................. 52
3.3.1 Estimacin de Esfuerzo Proyecto Completo ........................................................................... 53
3.4 Cronograma de Tareas. ............................................................................................... 55
3.5 Organigramas, Roles y Responsabilidad del proyecto (Depende de metodologa) ........ 57
3.5.1 Organizacin ................................................................................................................................ 57
3.5.2 Equipo de Trabajo ....................................................................................................................... 58
3.6 Matriz de Entregables ................................................................................................. 60
3.7 Gestin de Riesgo ....................................................................................................... 62
3.7.1 Matriz de Riesgo del Proyecto .................................................................................................. 62
4. Captulo IV ..................................................................................................... 64
Resultados y Discusin .............................................................................................. 64
4.1 Mapa del Sitio ............................................................................................................ 65
4.2 Desarrollo Incrementos .............................................................................................. 66
4.2.1 Desarrollo Incrementos 1 ........................................................................................................... 66
4.2.2 Desarrollo Incremento 2 ............................................................................................................ 79
4.2.3 Desarrollo Incremento 3 ............................................................................................................ 87
4.2.4 Desarrollo Incremento 4 ............................................................................................................. 99
4.3 Experiencias del proyecto ......................................................................................... 108
4.3.1 Pruebas. ..................................................................................................................................... 108
4.3.1.1 Casos de Prueba Mdulo Login. ....................................................................................109
4.3.1.2 Casos de Prueba Mdulo Solicitante. ............................................................................110
4.3.1.3 Casos de Prueba Mdulo Jefe Departamento ...............................................................110
4.3.1.4 Casos de Prueba Mdulo Administrador........................................................................111


4.3.1.5 Casos de Prueba Mdulo Operador ...............................................................................112
4.3.2 Discusin plan SQA .................................................................................................................. 112
4.3.3 Gestin y Control de los Riesgos. .......................................................................................... 113
4.3.4 Control de Estimacin de Esfuerzo Planificado v/s Real .................................................... 116
4.3.5 Comparacin Ambiente de Desarrollo y Pruebas. ............................................................... 117
4.3.6 Manual de Utilizacin ............................................................................................................... 118
4.3.7 Mantencin ................................................................................................................................. 118
5. Captulo V .................................................................................................... 122
Conclusiones.............................................................................................................. 122
5.1 Lecciones Aprendidas. .............................................................................................. 122
5.2 Conclusiones Generales ............................................................................................ 124
Bibliografa ................................................................................................................. 126
Anexos ........................................................................................................................ 128
Anexo A ........................................................................................................................... 129
Base Datos ................................................................................................................................................. 129
Anexo B .............................................................................................................................. 132
Anexo C .............................................................................................................................. 154
Registro de Pruebas locales .................................................................................................... 154
Anexo D .............................................................................................................................. 158
Definiciones, Acrnimos y Abreviatura ................................................................................... 158
Anexo E .............................................................................................................................. 159
Prototipo ............................................................................................................................... 159
Anexo F .............................................................................................................................. 164
5.3 Matriz de Pendientes ................................................................................................ 120
5.4 Seguimiento y Control .............................................................................................. 119

ndice de Tablas
Tabla 1.0 Proceso Manual. ................................................................................. 19 - 19
Tabla 1.1 Riesgo Descriptivo ..................................................................................... 34


Tabla 1.2 Roles y Responsabilidades Stakeholders ........................................... 26 - 58
Tabla 1.3 Roles y Responsabilidad. ..................................................................... 28 - 60
Tabla 2.0 Proceso Futuro ............................................. Error! Bookmark not defined.
Tabla 2.1 Enfoque Funcional ....................................... Error! Bookmark not defined.
Tabla 2.2 Requerimientos Funcionales. ..................................................................... 36
Tabla 2.3 Requerimientos No Funcionales. ............................................................... 36
Tabla 2.4 Descripcin de los Actores del Sistema. ................................................... 40
Tabla 2.5 Funcin Actores del Sistema. ................................................................... 39
Tabla 2.6 Etapas mtodo P.C.U ................................................................................ 53
Tabla 2.7 Estimacin de Esfuerzo Proyecto Completo .............................................. 53
Tabla 2.8 Distribucin de Esfuerzo por Actividades. .................................................. 54
Tabla 3.0 Seguimiento y Control. ................................. Error! Bookmark not defined.
Tabla 3.1 Matriz de Entregables. .......................... 56 - Error! Bookmark not defined.
Tabla 3.2 Matriz de Pendientes. .................................. Error! Bookmark not defined.
Tabla 3.3 Matriz de Riesgo del Proyecto ............................................................ 59 - 60
Tabla 3.4 Costo Hardware / Software .......................... Error! Bookmark not defined.
Tabla 3.5 Costo Personal ............................................. Error! Bookmark not defined.
Tabla 3.6 Costo Totales .............................................. Error! Bookmark not defined.
Tabla 3.7 Anlisis Costo / Beneficio Proceso Manual. . Error! Bookmark not defined.
Tabla 3.8 Anlisis Costo / Beneficio Proceso Automatizado. ...... Error! Bookmark not
defined.
Tabla 4.0 Clculo Estimacin de Esfuerzo Incremento 1 ........................................... 68
Tabla 4.1 Mdulo de Solicitud. ................................................................................... 70
Tabla 4.2 Arquitectura de Componentes del Incremento 1 ....................................... 72
Tabla 4.3 Entidades. .................................................................................................. 80
Tabla 4.4 Atributos de la Entidad Personal Usuario. .............................................. 80
Tabla 4.5 Atributos de la entidad Reparticin. ......................................................... 77
Tabla 4.6 Atributos de la entidad Solicitud. .............................................................. 77
Tabla 4.7 Clculo Estimacin de Esfuerzo Incremento 2 ........................................... 81


Tabla 4.8 Mdulo Jefe Departamento ........................................................................ 83
Tabla 4.9 Arquitectura de Componente Incremento 2................................................ 85
Tabla 4.10 Clculo Estimacin de Esfuerzo Incremento 3 ......................................... 89
Tabla 4.11 Mdulo Administrador. ............................................................................. 91
Tabla 4.12 Arquitectura de Componente Incremento 3.............................................. 93
Tabla 4.13 Clculo Estimacin de Esfuerzo Incremento 4 ....................................... 101
Tabla 4.14 Mdulo Operador. ................................................................................. 103
Tabla 4.15 Arquitectura de Componente Incremento 4........................................... 105
Tabla 4.16 Casos de Prueba Mdulo Login ............................................................. 110
Tabla 4.17 Casos de Prueba Mdulo Solicitante ..................................................... 110
Tabla 4.18 Casos de Prueba Mdulo Jefe Departamento. ...................................... 111
Tabla 4.19 Casos de Prueba Mdulo Administrador ....................................... 114 - 111
Tabla 4.20 Casos de Prueba Mdulo Operador ....................................................... 112
Tabla 4.21 Cambios a los Requerimientos ..................................................... 118 - 116
Tabla 4.22 Estimacin de Esfuerzo Planificado v/s Real ......................................... 117

ndice de Figuras
Figura 1.0 Proceso Actual ........................................................................................... 17
Figura 1.1 Diagrama Causa / Efecto ........................................................................... 21
Figura 1.2 Organigrama de Clientes Asociados al Proyecto. ..................................... 57
Figura 1.3 Organigrama del Equipo de Trabajo. ........................................................ 59
Figura 2.0 Proceso Futuro .......................................... Error! Bookmark not defined.
Figura 2.1 Secuencia Incrementos ............................................................................ 50
Figura 2.2 Arquitectura Proyecto.................................. Error! Bookmark not defined.
Figura 2.3 Diagrama Caso de Uso Alto Nivel ............................................................ 38
Figura 2.5 Diagrama de Paquete. ............................................................................. 26
Figura 2.6 Diagrama de Componente. ....................................................................... 27
Figura 2.7 Diagrama de Despliegue........................................................................... 28


Figura 2.8 Diagrama de Actividad de Caso Uso ........................................................ 29
Figura 2.9 Diagrama de Clases. ................................................................................ 50
Figura 3.0 Work Breakdown Structure ......................... Error! Bookmark not defined.
Figura 3.1 Carta Gantt Proyecto. ................................. Error! Bookmark not defined.
Figura 4.0 Mapa del sitio. ........................................................................................... 66
Figura 4.1 Cronograma Incremento 1. ....................................................................... 67
Figura 4.2 Casos de Uso Mdulo de Solicitud ........................................................... 69
Figura 4.3 Diagrama Secuencia Mdulo de Solicitud................................................. 71
Figura 4.4 Mdulo Solicitante ..................................................................................... 73
Figura 4.5 Diagrama Entidad Relacin. ..................................................................... 74
Figura 4.6 Diagrama Relacional. ................................................................................ 75
Figura 4.7 Cronograma Incremento 2 ........................................................................ 80
Figura 4.8 Interfaz Nivel de Usuario ........................................................................... 82
Figura 4.9 Diagrama Caso de Uso Mdulo Jefe Departamento. ................................ 82
Figura 4.10 Diagrama de Secuencia Mdulo Jefe Departamento. ............................. 84
Figura 4.11 Interfaz Nivel de Usuario (Jefe Departamento.) ...................................... 90
Figura 4.12 Mdulo Jefe de Departamento. .............................................................. 87
Figura 4.13 Cronograma Incremento 3 ...................................................................... 88
Figura 4.14 Caso de Uso Mdulo Administrador ....................................................... 90
Figura 4.15 Diagrama Secuencia Mdulo Administrador. .......................................... 92
Figura 4.16 Mdulo Administrador ............................................................................. 94
Figura 4.17 Interfaz Administrador Solicitudes. .......................................................... 95
Figura 4.18 Interfaz Administrador Consulta ........................................................... 100
Figura 4.19 Interfaz Administrador Usuarios .............................................................. 97
Figura 4.20 Interfaz Administrador Modificacin Usuarios ........................................ 98
Figura 4.21 Cronograma Incremento 4 .................................................................... 100
Figura 4.22 Caso de Uso Mdulo del Operador. ...................................................... 102
Figura 4.23 Diagrama Secuencia Mdulo Operador. ............................................... 104
Figura 4.24 Mdulo del Operador ............................................................................ 106


Figura 4.25 Interfaz Detallada del Operador ............................................................ 107

1. Captulo I
Introduccin


1.1 Introduccin

DIRECTELINF es la entidad encargada del correcto funcionamiento de la red
WAN e implantacin de tecnologas dentro de la institucin, esta direccin tcnica nos
ha solicitado presentar una solucin que permitir optimizar el proceso de solicitud de
habilitacin de puertos de IPs a los Administradores de aplicaciones de la institucin.
Este informe reflejar el proceso evolutivo del desarrollo del sistema a
implementar, los requerimientos entregados por el cliente generaron el correcto anlisis,
con el fin obtener la solucin apropiada a la problemtica.
La metodologa aplicada Modelo Incremental sus caractersticas sern
explicadas durante el desarrollo de este informe, los cuales fueron los cimientos
primordiales para el xito de este proyecto, sin embargo durante los Incrementos
desarrollados surgieron nuevas ideas para la optimizacin y ampliacin del sistema a
desarrollar para esto se fue registrando, objeto permitir una modernizacin o ampliacin
de la aplicacin a futuro.
Mediante conceptos de gestin de los proyectos informticos como la
planificacin, seguimiento y control de las actividades, permitieron culminar dentro del
alcance, tiempo y costos definidos.
Finalmente DIRECTELINF, posee las caractersticas de una organizacin
estructurada y ordenada en todos los ambientes de trabajo, por tanto brinda las
condiciones necesarias para el desarrollo del sistema, permitiendo la buena
comunicacin entre el equipo desarrollador y el cliente, obteniendo un buen desarrollo y
culminacin exitosa del proyecto.
Ac el resumen de todos los captulos pero mximo 2 pginas


2. Captulo II
Fundamentacin del Tema


2.1 Identificacin de la Organizacin.

Nombre completo : Direccin de Telecomunicaciones e Informtica de la Armada de
Chile (DIRECTELINF).
Direccin : Gran Bretaa N 354 Playa Ancha, Valparaso.
Nombre Contacto : Gabriel Reyes Sanhueza.
Cargo : Jefe Red WAN Armada.
e-mail : greyessan@armada.cl

DIRECTELINF es la entidad pblica responsable del correcto funcionamiento y
administracin de la red WAN alrededor de todas las reparticiones y direcciones
tcnicas en el pas y extranjero.
La misin de esta Direccin tcnica es enfrentar el desarrollo tecnolgico
presente y futuro en el mbito de las tecnologas de la informacin, alcanzando
soluciones eficientes y que den respuesta a las necesidades de la institucin.
El rea de negocio de la empresa est orientada a:
Administracin red WAN Armada. Ejemplos: Video conferencia, administracin
de base de datos, acceso remoto y accesos aplicaciones Web.
Administracin y Mantencin de servidores de correo.
Evaluacin y desarrollo de la nuevas TI.


2.2 Situacin Actual

Actualmente el proceso de habilitacin de todos los puertos de IPs de las
reparticiones y direcciones tcnicas Administradoras de aplicaciones es efectuado por
DIRECTELINF. El procedimiento se hace a travs de un sistema administrativo de
envo de documentos llamado Mensajes naval, el cual, se escribe el requerimiento
mediante un formato establecido, la tramitacin tarda de 3 a 5 das sin considerar
inconveniente de algn funcionario dentro del proceso de tramitacin del mensaje
naval.
Mediante notacin para el modelado de procesos de negocio (BPMN),
describimos el proceso actual ver Figura 1.0 donde el Solicitante genera el mensaje de
requerimiento, este es enviado al Jefe de Departamento, el cual, deber autorizar o
rechazar para posteriormente entregar al Jefe de Turno de mensajera e incorporar el
documento a la carpeta de mensajes objeto obtener la autorizacin del comandante de la
reparticin solicitadora.
Una vez autorizado el documento, es transmitido por el Jefe de Turno de
mensajera al DIRECTELINF el cual es recibido por el Jefe de Turno de esta direccin
tcnica y mostrado al comandante y Jefe de la Red WAN Armada, donde se autoriza la
habilitacin del puerto y se da las instrucciones respectivas al Operador de la red WAN.
Una vez efectuada la habilitacin, se enva un mensaje respuesta generado por
el Jefe Red WAN a la reparticin solicitadora a travs del Jefe de Turno y autorizado por
comandante DIRECTELINF.
La reparticin solicitadora recibe mensaje respuesta a travs del Jefe de Turno
mostrando el documento al comandante y Jefe Departamento llegando al archivo del
cargo por parte del Solicitante.


Figura 1.0 Proceso Actual


En la tabla 1.0, se muestra el proceso actual, el cual est compuesto por los
diferentes funcionarios involucrados de la reparticin o direccin tcnica solicitadora y
DIRECTELINF.

Actividad del Procesos Insumos Stakeholders
Solicitante crea mensaje naval para obtener
habilitacin del puerto a una aplicacin.
Computador
Impresora
Papel Lpiz
- Solicitante
Obtener firma de oficial divisin y Jefe
Departamento para transmitir mensaje.
Papel
Lpiz
- Solicitante
- Oficial Divisin
- Jefe Departamento
Solicitante entrega Mensaje a oficina
mensajera.
Papel
- Solicitante
- Jefe de Turno oficina
mensajera.
Mensajero Radio debe obtener firma del Oficial
Telecomunicacin y Comandante para transmitir
Mensaje.
Papel
Lpiz
mensajera.
- Oficial Telecomunicacin.
- Comandante.
Una vez firmado por Comandante y Oficial
Telecomunicacin el Mensaje se transmite a
DIRECTELINF.
Papel
Computador
mensajera.
Se recibe mensaje en DIRECTELINF, que lo
recibe el Jefe de Turno oficina mensajera de
esta direccin tcnica.
Computador
Papel
Lpiz
mensajera DIRECTELINF.
Jefe de Turno oficina mensajera, imprime
mensaje para firma de Comandante
DIRECTELINF.
Papel
Impresora
Computador
Comandante firma mensaje y da instrucciones
para el Jefe red WAN Armada.
Papel
Lpiz
- Comandante.
- Jefe red WAN Armada.
Jefe red WAN Armada lo ingresa a su control
manual y da instrucciones de habilitacin y
respuesta al mensaje del Solicitante.
Papel - Jefe red WAN Armada.


Una vez firmado por Comandante y Oficial.
Telecomunicacin, Mensaje respuesta es
transmitido.
Papel
Computador
Se recibe mensaje en Reparticin solicitadora
Computador
Papel
Lpiz
mensajera.
Jefe de Turno, imprime mensaje para firma de
Comandante.
Papel Impresora
Computador
mensajera.
Comandante firma mensaje y se entrega al
cargo de informtica de la reparticin
solicitadora para su archivo.
Papel
Lpiz
- Comandante
- Oficial Informtico
- Solicitante

Tabla 1.0 Proceso Manual.

2.3 Identificacin del problema.

Dentro de la institucin, existen reparticiones y direcciones tcnicas con
funciones administrativas las cuales otorgan servicios mltiples y administran
aplicaciones con informacin a los diferentes funcionarios de acuerdo a la funcin
especfica que cumplen.
En forma continua existen requerimientos desde la entidad Administradora de la
aplicacin Web a DIRECTELINF, para la habilitacin de puertos de IPs a un terminal de
trabajo en una reparticin o direccin tcnica.
En la condicin actual, el sistema es solicitado a travs de un documento con
un formato especfico, cuyo tiempo aproximado en la tramitacin es de 3 a 5 das
hbiles, desafortunadamente esta tramitacin impide un servicio expedito. Existe
prdida de horas hombres, intentando satisfacer los requerimientos en forma manual
por las diferentes personas involucrados en el proceso, adems no se lleva un historial


a largo plazo de las IPs habilitadas debido a la perdida de vigencia del documento y su
posterior destruccin.
La solicitud efectuada a travs del documento pertenece a los documentos
oficiales de la institucin, lo cual significa que el requerimiento previamente efectuado
fue visado por el Jefe del rea de informtica de la reparticin y direccin tcnica.
El requerimiento una vez llegado al DIRECTELINF es recibido por el Jefe red
WAN Armada. Esta informacin es revisada y autorizada para dar ejecucin a la
habilitacin del requerimiento por algn Operador, donde se enva nuevamente el
documento oficial de respuesta a la reparticin o direccin tcnica solicitadora con una
tardanza 3 a 5 das informando requerimiento satisfecho o rechazado.

2.3.1 Mtodo de Anlisis Situacin Actual

Mediante una representacin grfica Ishikawa Figura 1.1 hemos determinado
relaciones mltiples de causa - efecto entre las diversas entidades que intervienen en el
proceso, para lo cual nuestras variables fueron el personal, el mtodo, los procesos
actuales y el deficiente historial, donde se determin el tiempo excesivo en respuesta
solicitudes de acceso a aplicaciones y la no existencia de historial por perdida de
vigencia del documento papel.


Figura 1.1 Diagrama Causa / Efecto

2.4 Solucin Propuesta.

Se propone desarrollar una aplicacin Web el cual permita tramitar y gestionar
la habilitacin de puertos de IPs entre el Administrador de la aplicacin y l de la red
WAN Armada.


Desarrollando los mdulos, el cual tendrn acceso de acuerdo al perfil en las
funciones dentro del proceso de habilitacin, con el fin de otorgar la veracidad y
seguridad al documento original de tramitacin, se instaurar la certificacin mediante
de flujo de trabajo (Flujo de trabajo).
Objeto mitigar los tiempos excesivos en la tramitacin de acuerdo a la evolucin
de la tramitacin se generar en forma automtica un correo informando a los actores
involucrados en el proceso, el requerimiento solicitado.
Toda la informacin recepcionada va aplicacin Web, se almacenar en una
base de datos por un tiempo determinado a criterio del Administrador, con el fin de
otorgar el historial de la habilitaciones de puertos de los diferentes usuarios e IPs.
Mediante notacin para el modelado de procesos de negocio (BPMN),
describimos el proceso futuro ver Figura 2.0. Donde el requerimiento comienza cuando
un Solicitante o Jefe de Departamento efecta una tramitacin a travs de la aplicacin
Web, llenando todos los campos, posteriormente es enviado para el visado o rechazo del
Jefe de Departamento de Informtica de la reparticin o direccin tcnica una vez
tomada la accin se enva al Jefe Red WAN en DIRECTELINF el cual revisar el
requerimiento y mediante la misma aplicacin autorizar o rechazar la habilitacin, de
acuerdo a los privilegios de Administrador, el Jefe Red WAN podr efectuar consultas,
insertar, eliminar, modificar informacin de la base de datos.
Una vez autorizado el requerimiento por el Jefe Red WAN, el Operador
efectuada la habilitacin y seleccionar en la aplicacin Requerimiento Satisfecho
objeto informar va correo electrnico automticamente al usuario Solicitante.


Figura 2.0 Proceso Futuro


En la tabla 2.0 se muestra el proceso futuro, el cual est compuesto por los
diferentes funcionarios involucrados de la reparticin o direccin tcnica solicitadora y
DIRECTELINF.

Actualidad Insumos Stakeholders
Solicitante ingresa a la aplicacin Web
para solicitar habilitacin de puerto.
Se genera un mail por automtico para su
Jefe directo
Computador
- Solicitante
- Jefe Departamento

Requerimiento ser visado o no visado por
Jefe Departamento.
Se genera un mail por automtico para Jefe
de Red WAN Armada o Solicitante
dependiendo la resolucin.
Computador
- Jefe Departamento

Jefe de Red WAN Armada autoriza o no
autoriza el requerimiento.
Se genera un mail por automtico al
Operador Red WAN o Solicitante
dependiendo la resolucin.
Computador - Jefe de Red WAN
El Operador Red WAN generara un mail al
Solicitante y Jefe Departamento informando
situacin de su requerimiento.
Requerimiento queda almacenada con el
estado Efectuado en BB.DD.
Computador
Servidor
- Operador WAN

Tabla 2.0 Proceso Futuro

2.4.1 Arquitectura de Solucin propuesta

La figura 2.2 representa la arquitectura utilizada para el proyecto a desarrollar el
cual consiste en una arquitectura de tres capas, con un reparto claro de funciones, una


capa para la presentacin (Mdulos de usuarios), otra para el intercambio de
informacin donde se establecen todas las reglas que deban cumplirse (modelado el
negocio) y otra para el almacenamiento (BB.DD)

Figura 2.2 Arquitectura Proyecto.

2.5 Diagrama de Paquete.

La figura 2.5 muestra el diagrama de paquetes cmo un sistema dividido en
agrupaciones lgicas mostrando las dependencias entre ellas.
SISTEMA PARA LA HABILITACIN DE PUERTOS DE IPS DE
SERVIDORES
CAPA PRESENTACIN CAPA LGICA CAPA DATOS


Figura 2.5 Diagrama de Paquete.


2.6 Diagrama de Componente

En la figura 2.6 representa cmo el sistema de software es dividido en
componentes, basado en el campo de la arquitectura del software muestra sus
dependencias.

Figura 2.6 Diagrama de Componente.

CAPA DE PRESENTACIN
CAPA DE NEGOCIO
CAPA DE DATOS


2.7 Diagrama de Despliegue.

En la capa de presentacin est la interfaz grfica para los actores que se
comunicaran con el servidor Web donde la informacin de acuerdo al perfil del usuario
es guardada en la base de datos.

Figura 2.7 Diagrama de Despliegue.


2.8 Diagrama de Actividad de los Casos de Usos

La figura 2.8 permite visualizar el flujo del sistema, de acuerdo al del perfil
ingresado por cada actor dependiendo de la Rut ingresado se ejecutan las siguientes
actividades:

Figura 2.8 Diagrama de Actividad de Caso Uso

MDULO
SOLICITANTE
MDULO
JEFE DPTO.
MDULO
ADMINISTRADOR
MDULO
OPERADOR WAN


2.9 Diagrama de Clases

La figura 2.9 representa los objetos fundamentales de un sistema, con los que
percibe el usuario y con los que espera tratar para cumplir las tareas.

Figura 2.9 Diagrama de Clases.


2.10 Enfoque de la Solucin

2.10.1 Enfoque Funcional

En la siguiente tabla se muestra las funciones que debern poseer los mdulos
de la aplicacin para los diferentes perfiles de usuarios.
Mdulo Aplicacin Funcin
Mdulo de Solicitante
Ingresar requerimiento
Recibir aceptacin o rechazo requerimiento va mail.
Mdulo Jefe de Departamento
Poseer dualidad de perfil (Solicitante y Jefe
Departamento)
Visualizar los requerimientos
Autorizar (visar) requerimientos
Rechazar requerimientos
Recibir aceptacin o rechazo requerimiento va mail.
Mdulo Administrador (Jefe Red
WAN DIRECTELINF)
Visualizar requerimientos visados.
Autorizar requerimientos visados.
Rechazar los requerimientos
Generar reporte.
Ingresar, Modificar, Eliminar Usuarios en general.
Mdulo Operador Red WAN
Visualizar los requerimientos Autorizados.
Una vez efectuada la habilitacin, cambiar estado de la


solicitud a Efectuado, al guardar se enva en forma
automtica mail con la aceptacin al Solicitante y Jefe
Departamento.

Tabla 2.1 Enfoque Funcional

2.11 Objetivos
En este punto se presentarn los objetivos del PROYECTO SOFTWARE
PARA GESTIONAR LA HABILITACIN DE PUERTOS DE IPs DE SERVIDORES
DENTRO DE LA ARMADA DE CHILE que dar solucin a la problemtica atacando
sus principales causas ya identificadas.
2.11.1 Objetivo Principal

El objetivo principal es desarrollar un proyecto software, el cual permita
automatizar el proceso de solicitudes de habilitacin de puertos de IPs para
DIRECTELINF que permita mitigar los tiempos en la tramitacin, proporcionar un
historial de solicitudes facilitando las consultas por el Administrador de la aplicacin e
identificar cuellos de botella y oportunidades de mejora.

2.11.2 Objetivos Especficos
Reducir costo de impresin y almacenamiento de documento.
Permitir el control de todas las solicitudes.
Mejorar la Comunicacin y evitar la desatencin de los actores en el Proceso.
Agilizar el proceso de habilitacin.


Evitar los errores de formato en la tramitacin del documento.
Eliminar los problemas de impresin en el proceso de habilitacin.
2.12 Alcance del Proyecto
Generacin y control de solicitudes.
Generacin de registro de usuarios.
Visualizacin de datos en detalle por parte del Administrador.
Implementacin de base de datos.
Generacin de mail en forma automtica a usuarios y/o Administrador en las
diferentes etapas de la solicitud.
Capacitacin al Administrador y tutorial a usuarios.
Respuesta y almacenado de los requerimientos de habilitacin de puertos.
2.12.1 Supuestos del Alcance del Proyecto

El sistema ser desarrollado en idioma Espaol.
El personal de usuarios del DIRECTELINF posee las competencias necesarias para
la utilizacin del sistema.
El Administrador har los respaldos necesarios para el resguardo de los datos.
DIRECTELINF proporcionar toda la informacin necesaria para el desarrollo del
sistema.

2.12.2 Limitacin al Alcance del Proyecto

El proyecto no contempla migracin de datos ni implementacin automtica de
polticas de respaldo.


2.12.3 Factores Crticos de xito

En la tabla 1.1 definimos los factores el cual puedan afectar a la solucin o
desarrollo exitoso del proyecto.
Factores Descripcin
Errores en la estimacin de los tiempos Mala definicin de los tiempos en la etapa de
planificacin
Mala toma de requerimientos. El cliente no entrega toda la informacin requerida y
no se toma buenos requerimientos.
Diseo inadecuado. Diseo no se ajusta a los requerimientos del sistema
a desarrollar
Mal diseo de las pruebas. Que no se hayan usado criterios y herramientas en
forma adecuada..
Inexperiencia del equipo en la
implementacin del proyecto
Que los integrantes hayan sido puestos en
actividades sin el mayor Conocimiento.
Pobre dedicacin por parte del Cliente y
usuario, para la correcta definicin de
requisitos del proyecto.
Se requiere que el personal tenga participacin
activa en el Desarrollo del proyecto.
Dificultad de comunicacin entre los
miembros del equipo de trabajo.
Mala integracin del grupo de trabajo
Renuncia de un integrante del equipo de
trabajo.
Faltante de un integrante del grupo de trabajo

Tabla 1.1 Riesgo Descriptivo


2.12.4 Especificacin de Requerimientos
A continuacin se presentan los requerimientos funcionales (Tabla 2.2) el cual
se describen las transformaciones que el sistema realiza sobre las entradas para
producir salidas y los requerimientos no funcionales (Tabla 2.3) donde representa los
atributos del ambiente del sistema que no estn relacionados directamente con los
requisitos funcionales.

2.12.5 Requerimientos Funcionales
# Funcin Categora
R1 Validar el ingreso desde cuatro perfiles del sistema Evidente
R2
Comparar el identificador de usuario y contrasea digitados por
los usuarios, con los datos almacenados en la base de datos.
Oculta
R3 Permitir aprobar o rechazar solicitud Evidente
R4
Permitir agregar, eliminar o modificar Usuarios en la BB.DD a
travs de perfil de Administrador.
Personalizado
R5
Permitir notificar va email automticamente a los usuarios si se
aprob o rechaz el requerimiento.
Oculta
R6
Efectuar consultas, de acuerdo a parmetros pre-establecido
con perfil de Administrador.
Evidente
R7 Permitir restablecer contrasea. Oculta


R8 Obligar al Solicitante llenar todos los campos. Oculta
R9 Permitir dualidad de perfil al Jefe Departamento Evidente

Tabla 2.2 Requerimientos Funcionales.

2.12.6 Requerimientos No Funcionales

Atributo Descripcin
Requerimiento de
conectividad
El sistema debe accederse a travs de un ambiente Web.
Requerimiento de
calidad
Consistencia, exactitud, mantenimiento, pruebas.
Requerimiento de
disponibilidad
Debe ser una aplicacin 24x7.
Requerimiento
factibilidad de uso
Mdulos de fcil entendimiento.
Requerimiento de
optimizacin del
proceso.
Disminucin del tiempo de respuesta en un 90%.

Tabla 2.3 Requerimientos No Funcionales.


2.13 Actores del Sistema

En la siguiente tabla se presentan los actores que participarn en el sistema a
desarrollar, donde son distribuidos de acuerdo a la actividad que desempaan,
asignando el perfil correspondiente para el funcionamiento primordial del sistema.

Actores Rol
Solicitante
Personal tcnico rea informtica de la Reparticin
o direccin tcnica.
Jefe Departamento
Jefe del rea informtica de la Reparticin o
direccin tcnica.
Administrador Red WAN
Jefe de la Red WAN Armada, ubicado en
DIRECTELINF.
Operador Red WAN Personal tcnico rea informtica DIRECTELINF.

Tabla 2.4 Descripcin de los Actores del Sistema.


El diagrama C.U de alto nivel presentado a continuacin (figura 2.3), se puede
apreciar los diferentes actores, donde el Solicitante y Jefe de Departamento pueden
efectuar requerimientos con el fin de obtener la habilitacin de puerto, el Administrador
y Operador WAN son los actores participantes perteneciente a DIRECTELINF en donde
se autoriza y se enva la notificacin a los Solicitantes del requerimiento efectuado
conforme.

Sistema de solicitud para habilitacin puerto de IPs

Figura 2.3 Diagrama Caso de Uso Alto Nivel.


La tabla 2.5 se muestra los roles de los actores, representado en el diagrama de
C.U de alto nivel (Figura 2.3)

Solicitante
Ingreso al sistema mediante Rut / Password.
Efecta la realizacin del requerimiento.
Jefe Departamento
Efecta la realizacin del requerimiento (opcional).
Autoriza/Rechaza solicitud(estado de visado / no visado)
Administrador Red WAN
Autoriza/Rechaza solicitud
Operador Red WAN
Efecta cambio de estado Efectuado generando mail
automticamente a los requirentes.

Tabla 2.5 Funcin Actores del Sistema.


2.14 Evaluacin del Proyecto

Los siguientes puntos enmarcados en la evaluacin del proyecto producir la
informacin para la mejor toma de decisiones, orientada a mejorar la eficacia del
proyecto y promover la asignacin de recursos donde permitir optimizar la gestin del
proyecto.
2.14.1 Factibilidad Tcnica

DIRECTELINF posee la infraestructura apropiada para alojar el sistema en
desarrollo, el proyecto considera la adquisicin de un servidor de rack de 19 y la
adquisicin de la licencia Visual Studio 2010 contemplada en los costos cubiertos por el
cliente.
La mantencin del sistema ser efectuada por el personal del DIRECTELINF
considerando que es una organizacin con las competencias apropiadas para tal
efecto.

2.14.2 Factibilidad Econmica

Costo Hardware / Software 2.14.2.1

Con el fin de albergar la aplicacin en un servidor dedicado a la habilitacin de
puertos de IPs, se debi adquirir un servidor de rack y la licencia correspondiente para
el desarrollo de la aplicacin, el tabla 3.4 se muestra los costos asociados en la
adquisicin del hardware.


Detalle Valor Total
Servidor de rack 19 $ 1.870.000
Visual Studio 2010 Professional $ 270.000
TOTAL $ 2.140.000
Fuente: www.pcfactory.cl
Tabla 3.4 Costo Hardware / Software

Costo Recurso Humano 2.14.2.2

Para calcular el esfuerzo necesario expresado en horashombre para la
realizacin del proyecto, se utiliz la mtrica de Puntos de Casos de Uso, que arroj
como resultado que el esfuerzo total requerido para terminar el proyecto es de 356
horas-hombre.
A su vez el esfuerzo se distribuy de acuerdo a las actividades relacionadas
con el desarrollo de software. La tabla 3.5 se basa en la distribucin de las actividades
calculada a travs de los Puntos de Casos de Uso, pero se le incluye la gestin del
proyecto, que es responsabilidad del Jefe de Proyecto y que debe estar presente a lo
largo de todo el ciclo de vida del proyecto.
% HHS COSTO HH (UF) VALOR $
Jefe Proyecto
40
10 89 0,45 $921.000
Analista/Diseador 30 267 0,24 $1.473.840
Desarrollador BB.DD
20
10 89 0,22 $450.340
Desarrollador Programador 10 89 0,22 $450.340


Tester 40 40 356 0,21 $1.719.480
Total 890 $ 5.022.000
Fuente: www.mifuturo.cl
Tabla 3.5 Costo Personal

Costos Totales 2.14.2.3
Los costos totales es el resultado de lo calculado mediante la estimacin de
esfuerzo y el gasto por concepto de adquisicin de hardware y software, la tabla 3.6
presenta el costo total del proyecto.
VALOR $
Costos Personales $5.022.000
SUB TOTAL $5.022.000
Total Costo Hardware/software $2.140.000
TOTAL PROYECTO $ 7.162.000
Tabla 3.6 Costo Totales

Anlisis Costo Beneficio 2.14.2.4

Para este proyecto se usar la metodologa de evaluacin Costo anual
uniforme equivalente (CAUE) y razn de beneficio costo, estos mtodos de evaluacin
toman en cuenta el valor del dinero a travs del tiempo pero sus aplicaciones son
distintas de la evaluacin de proyecto.
El proyecto en desarrollo corresponde a una organizacin gubernamental por
tanto los beneficios como los costos no se cuantifican como hace un proyecto de


inversin privada, sino que se toman los beneficios en cuenta sociales y de
optimizacin de procesos gubernamentales. (Baca Urbina IV edicin).
A continuacin se detalla el clculo para el proyecto

Determinacin del CAUE (Costo Anual Uniforme Equivalente)

Para determinar el CAUE se usarn dos valores:
Valores Proyecto actual forma manual correspondiente al proceso funcionando
hoy en da el cual se va automatizar.

Valor Proyecto automatizado correspondiente al proceso con la implantacin del
sistema.

En la tabla 3.7 y 3.8 se muestran las valorizaciones involucradas en el proceso
manual y automatizado

Proceso Manual.


Tabla 3.7 Anlisis Costo / Beneficio Proceso Manual.

Para este clculo el Valor Proyecto actual forma manual (VP actual manual) es
de $1.421.820.- en un ao, cabe mencionar que este clculo est hecho para una
reparticin que solicita un requerimiento de aplicacin por mes en un perodo de un ao
al DIRECTELINF.
Proceso Automatizado
Descripcion Valor mensual Costo Anual
I-Proceso de Firma Autorizante Mensaje
Hacer Mensaje Naval 15 minutos
Impresin Mensaje Naval 3 minutos
HH en obtener firmas promedio 60 minutos
HH en enviar mensaje 240 minutos
Total HH 318 Minutos 5,2 HH 31.200 $
Cinta / Toner Impresora 30 $
Papel 5 $
Lapiz 30 $
Electricidad 30 $
Sub Total 31.295 $ 375.540 $
II-Recepcion Mensaje (Directelinf)
Imprimir Mensaje Naval 3 Minutos
HH Lectura Mensaje Naval (Firmas) 240 Minutos
Instrucciones para nuevo Mensaje 7 Minutos
Transcribir Mensaje 15 Minutos
HH en enviar mensaje 240 minutos
Papel 5 $
Lapiz 30 $
Electricidad 30 $
Sub Total 56.495 $ 677.940 $
III-Recepcion Mensaje (Reparticin Destino)
Imprimir Mensaje Naval 3 Minutos
HH Lectura Mensaje Naval (Firmas) 240 Minutos
Total HH 303 5,1 HH 30.600 $
Papel 5 $
Lapiz 30 $
Electricidad 30 $
Sub Total 30.695 $
Total 118.485 $ 1.421.820 $
Proceso Manual
CALCULO PARA UN
REQUERIMIENTO POR
MES DURANTE UN AO


Tabla 3.8 Anlisis Costo / Beneficio Proceso Automatizado.

Para este clculo el Valor Proyecto actual forma automatizada es de $181.080,
considerando un requerimiento por mes durante un ao.
Nuestra aplicacin est pensada para 5 aos, por lo tanto haremos el clculo
para estos aos. Para clculos de Valor Proyecto (VP), usaremos un TMAR (Tasa
Mnima Aceptable de Retorno) de 5% basndose en la tasa de crecimiento del pas
publicado por la CEPAL, ya que este es un proyecto sin fines de lucro, que ser
Descripcion Valor mensual Costo Anual Costo unica vez
I-Proceso de Solicitud
Ingresar sitio Web y llenar formulario 5 minutos
Lectura de requerimiento por jefe dpto 5 minutos
Verificacin y autorizacin Jefe Informatica 240 minutos
Ejecuta Requerimiento Op. Wan 5 minutos
Lectura de mail operador 5 minutos
Lectura de mail jefe dpto 5 minutos
Lectura de mail reparticin involucrada app 5 minutos
Electricidad 90 $
Sub Total 15.090 $ 181.080 $
II.- Compra de Hardware / Software
Servidor 1.870.000 $
Visual Basic 2010 Professional 270.000 $
Sub Total 2.140.000 $
III.- Costo Creacin de la Aplicacin
Jefe proyecto 921.000 $
Analista 743.920 $
Diseador 736.920 $
Desarrollador BB.DD. 450.340 $
Desarrollador Programador 450.340 $
Tester 1 429.870 $
Tester 2 429.870 $
Tester 3 429.870 $
Tester 4 429.870 $
Mano de obra Total 5.022.000 $
Total 7.343.080 $
Proceso Automatizado
CALCULO PARA UN
REQUERIMIENTO POR
MES DURANTE UN AO


implementado en una entidad pblica y es la tasa mnima a usar en el mundo
financiero.

VP actual manual = 1421820 + 1421820 + 1421820 + 1421820 + 1421820 = $ 6.155.737.-
(1,05) (1,05)
2
(1,05)
3
(1,05)
4
(1,05)
5

Para este valor hay que considerar:

$ 7.343.080 - $ 181.080 (costo anual) = $ 7.162.000.-

VP automatizado = 7162000 + 181080 + 181080 + 181080 + 181080 + 181080 =
(1,05) (1,05)
2
(1,05)
3
(1,05)
4
(1,05)
5

VP automatizado = $ 7.945.982.-

Ahora determinaremos el CAUE actual y automatizado

CAUE actual = VP actual [
))
)
)
]=6155737*((0,05*(1+0,05)
5
)/((1+0,05)
5
-1) =

CAUE actual = $ 1.421.820.-

CAUE automatizado = VP automatizado[
))
)
)
] = 7945982*((0,05*(1+0,05)
5
)/((1+0,05)
5
-1) =

CAUE automatizado = $ 1.835.322.-
El CAUE automatizado es mayor al CAUE actual, de acuerdo a estos nmeros
no es rentable nuestro proyecto, sin embargo el clculo fue efectuado por un
requerimiento de una reparticin en particular, sin embargo DIRECTELINF como
Administrador de la Red WAN Armada recibe un promedio de 45 solicitudes por mes
(informacin otorgada por el cliente).
Considerando el promedio de requerimientos mensuales nuestro proyecto se
transforma en un sistema rentable para la organizacin.


Beneficio Proyecto 2.14.2.5

Beneficios Tangibles
Los beneficios asociados a la implementacin del sistema es la reduccin de los
costos del material de oficina y Horas Hombres, este ltimo se relaciona con la escritura
y envo y recibo del mansaje Naval de acuerdo al proceso de Autorizaciones (Flujo de
trabajo) necesario para el envo de este tipo de documento.
Otro beneficio importante es la reduccin de espacio y bodegaje destinado al
archivo de papeles.
Beneficios Intangibles
La implementacin del sistema, siendo un aporte contribuyente para el objetivo
principal de la Organizacin DIRECTELINF, permite un beneficio en los tiempos de la
solicitud y respuestas, lo que permite una asistencia directa efectiva ante un
requerimiento de las Unidades y Reparticiones.

2.14.3 Factibilidad Legal
Para la realizacin de este proyecto no existen restricciones legales que
impidan su implementacin, ya que es una organizacin que trabaja con servicio
informticos, por tanto se enmarca en todo lo que constituye la legalidad en cuanto a
licencias y adquisicin de hardware.
Para el desarrollo de este proyecto, est basado en lenguaje Asp.Net C# por
tanto la obtencin de la licencia es parte del presupuesto presentado al cliente.


3. Captulo III
Materiales y Mtodos


3.1 Enfoque Metodolgico

El modelo incremental fue el modelo utilizado para este proyecto. Se basa en la
filosofa iterativa de construccin de prototipos, genricamente est dividido en 4 fases,
Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se
usa el principio de trabajo en cadena, utilizado en muchas otras formas de
programacin.
Esta metodologa utilizada posee un enfoque realista en el desarrollo de
software destacando, que los requisitos no pueden definirse completamente al principio,
las iteraciones controladas reduce el riesgo a los costos de un solo Incremento y
retrasos en el calendario, enfrentando los riesgos ms importantes primero.
La eleccin de este modelo de desarrollo permiti mantener al cliente en
constante contacto con los resultados obtenidos en cada Incremento. Fue el cliente que
incluy o desech elementos al final de cada Incremento a fin de que el software se
adapte mejor a sus necesidades reales.
Unas de las caractersticas de nuestro cliente es poseer gran capacidad de
cooperacin con todos los proyectos de desarrollo para su empresa, el trabajo en
equipo y la correcta direccin de actividades dentro su organizacin.
Considerando los requerimientos solicitados por el cliente, dentro de cada
iteracin esta metodologa permiti la entrega de un producto completamente
operacional y de esta forma el tiempo de entrega se redujo considerablemente.
De acuerdo a la planificacin del modelado de software, dividimos los
Incrementos de la siguiente manera:


Figura 2.1 Secuencia Incrementos

Incremento 1: El Incremento est definido por el desarrollo del modelamiento de la
base datos y el mdulo del Solicitante, el cual nos permiti generar solicitudes para
desarrollar los prximos mdulos y poder efectuar el traspaso de la informacin
solicitada.

Incremento 2: De acuerdo a los requerimientos ingresados en mdulo anterior y el
sistema Flujo de trabajo a implementar en nuestra aplicacin, nos permiti efectuar los
cambios de estados del requerimiento y la duplicidad de ingreso del Jefe de
Departamento objeto permita generar solicitudes y visar o rechazar.
Para el desarrollo del mdulo de Administrador se dar inicio al ingreso de usuarios y
verificacin de grilla de solicitudes pendientes.

Incremento 3: Desarrollo enfocado en la generacin de reportes de acuerdo al estado
de las solicitudes, personal registrado, todo de acuerdo a parmetros pre-establecidos.

INCREMENTO 1
MODELAMIENTO BB.DD / MDULO SOLICITANTE
INCREMENTO 2
MDULO JEFE DEPARTAMENTO

INCREMENTO 3
MDULO ADMINISTRADOR
INCREMENTO 4
MDULO ADMINISTRADOR / MDULO OPERADOR


Incremento 4: Desarrollo del mdulo del Operador, principalmente enfocado a efectuar
cambios de estado de solicitud y desarrollo del envo de correo en forma automtica.

3.2 WBS (Work Breakdown Structure)

El WBS constituye una herramienta fundamental en la gestin de proyectos, la
figura 3.0 muestra la descomposicin del trabajo, jerrquicamente orientada al
entregable y ejecutado por el equipo de proyecto, con el fin de cumplir con los objetivos
de ste y crear los entregables requeridos.


Figura 3.0 Work Breakdown Structure

3.3 Puntos de Funcin de Casos de Uso

Para la estimacin de esfuerzo del proyecto, nos basamos en la tcnica de
puntos de casos de uso (P.C.U), el cual es unas metodologas orientadas a objetos,
especficamente en el modelo de casos de uso.
La tabla 2.6 muestra las etapas que componen para efectuar el clculo del
mtodo punto casos.

UUCP
Clculo punto caso de usos sin
ajustar.
Permite tener una idea un poco ms precisa de la
dificultad de los casos de uso
UAW
Factores de peso de los actores
sin ajustar
Evaluacin de la complejidad de los actores con los
que tendr que interactuar el sistema.
UUCW
Factor de peso de los casos de
usos sin ajustar
Determina el nivel de complejidad se puede realizar
mediante dos mtodos: basado en transacciones o
basado en clases de anlisis.
UCP
Clculo de Puntos de Casos de
Uso ajustados
Se obtiene al multiplicar el UUCP el TCF y el EF
TCF Factores de complejidad Tcnica
Evalan la complejidad de los mdulos del sistema
que se desarrolla
EF Factor de ambiente
estn relacionados con las habilidades y experiencia
del grupo de personas involucradas con el desarrollo
del proyecto


E Clculo Esfuerzo

Tabla 2.6 Etapas mtodo P.C.U

3.3.1 Estimacin de Esfuerzo Proyecto Completo

La tabla 2.7 muestra el resultado de los clculos para la obtencin de la
estimacin de esfuerzo del proyecto completo, sin embargo de acuerdo a nuestra
metodologa aplicada, se complement con los clculos en forma independiente por
Incrementos (tablas 4.0, 4.7, 4.10 y 4.13 respectivamente)

Clculo estimacin de esfuerzo proyecto completo.
TCF Factor de complejidad Tcnica 0,99
EF Factor de ambiente 0,545
UUCP Punto casos de Uso sin ajustar 25
AW Factor de peso de los actores/ ajustar 8
UCP Punto Caso de Usos 17,8
PHM Horas Hombre por C.U 20

E Horas - Hombres 356

Tabla 2.7 Estimacin de Esfuerzo Proyecto Completo


De acuerdo a los resultados obtenidos (356 horas-hombres), los clculos
corresponden al 40% del proyecto total por tanto el proyecto considera 890 Horas
Hombre.
Se ha considerado que los integrantes del grupo trabajen 6 horas diarias de
lunes a viernes, por un periodo de 148 das, equivalente a 7,4 meses para terminar el
proyecto.
Las actividades relacionadas con el desarrollo del software estn distribuidas en
la tabla 2.8, el cual aplicando una distribucin del esfuerzo ms comn utilizada en
desarrollo de software es la regla 40-20-40, donde cuarenta por ciento del esfuerzo
general del proyecto se asigna al anlisis y el diseo, el mismo porcentaje se aplica a
poner a prueba los sistemas de salida y por lo que el porcentaje restante es asignado a
la codificacin, que no se le da tanto nfasis.
Este enfoque es slo una distribucin de referencia, las caractersticas de cada
proyecto deben dictar la distribucin del esfuerzo

Tabla 2.8 Distribucin de Esfuerzo por Actividades.

% Trabajo Das
ANALISIS
40 % 59
DISEO
IMPLEMENTACIN 20 % 29
PRUEBAS
40 % 60
DOCUMENTACION
TOTAL 100 % 148 DIAS


3.4 Cronograma de Tareas.

En el cronograma de proyecto se detallan las acciones e hitos que se deben
llevar a cabo a lo largo del desarrollo, la planificacin se gener de acuerdo mediante a
la propuesta tcnica y los requerimientos generales entregados por el cliente, donde se
define la problemtica y se determinan los objetivos del proyecto.
De acuerdo a la metodologa utilizada hemos dividi nuestro proyecto en cuatro
Incrementos donde se siguen los pasos de ingeniera de software para cada
Incremento.
Los hitos definidos, fueron determinados en las entregas operativas de cada
Incremento finalizando con la prueba final y entrega del proyecto logrando determinar
el avance operativo.
Para cada etapa de anlisis se efecto a una reunin con el cliente con el fin de
tomar los requerimientos detallados de cada etapa del desarrollo, objeto optimizar los
tiempos y la disminucin de errores.
En la figura 3.1 se muestra la planificacin del proyecto representado en una
herramienta grfica Gantt Project cuyo objetivo es mostrar el tiempo de dedicacin
previsto para diferentes tareas.


Figura 3.1 Carta Gantt Proyecto.

(Das)


3.5 Organigramas, Roles y Responsabilidad del proyecto (Depende de
metodologa)

En los siguientes puntos se presenta los organigramas, roles y
responsabilidades que se utilizan en el proyecto, para este caso se expone la
organizacin que existe tanto de parte del cliente como del equipo de trabajo (Figura
1.2 y 1.3) y los roles de cada uno de los participantes (Tabla 1.2 y 1.3).

3.5.1 Organizacin

Figura 1.2 Organigrama de Clientes Asociados al Proyecto.

JEFE DIV. INFORMTICA
RED WAN ARMADA
OPERADOR
(MODIFICACIONES DE RED)
DEPARTAMENTO TI


Roles Responsabilidades
Jefe divisin Informtica red
WAN Armada
Entreg requerimientos del proyecto.
Recibi los reportes por parte del Jefe del
proyecto.
Monitore del desarrollo del proyecto.
Autoriz y rechaz las solicitudes en el proceso
final del proyecto.
Verific las pruebas locales e integracin.
Operador
Recibe instrucciones del Jefe red WAN Armada.
Efecta cambio de estado de la solicitud de
Autorizado, Efectuada, Expirada.

Tabla 1.2 Roles y Responsabilidades Stakeholders

3.5.2 Equipo de Trabajo

Jefe de Proyecto
Desarrollador/Programador
Tester
Analista Diseador


Figura 1.3 Organigrama del Equipo de Trabajo.

# ROL RESPONSABILIDAD REPRESENTADO
1
JEFE DE
PROYECTO
Es responsable del proyecto ante el cliente.
Realiza los planes para la correcta direccin del
proyecto.
Determina los entregables del proyecto.
Aprobar los modelos y diseos realizados por el
Analista y Diseador.
Planificacin y formalizacin del inicio del proyecto.
Realizar el seguimiento al cumplimiento oportuno
de todas las actividades que conforman el servicio.
Evala las pruebas del producto.
Supervisar que la calidad de los entregables se
cumpla y realiza las gestiones necesarias para
superar situaciones que puedan paralizar el normal
desarrollo de las actividades.
Es responsable de gestionar los controles de
cambio y supervisar la satisfaccin del cliente por
los servicios entregados.
Sergio Orellana J.
Mario Virot J.
2
ANALISTA /
DISEADOR
Gestor de los Requerimientos.
Encargado de realizar los cambios de las
observaciones obtenidas en cada entrega de
Incremento.
Realiza el modelamiento y diseos de los mdulos.
Determina y analiza los procesos actuales del
cliente.
Captar los requerimientos del cliente y plasmarlo en
Sergio Orellana J.
Mario Virot J.
Desarrollador/Base de
Datos


un documento de anlisis.
3
DESARROLLADOR
/ PROGRAMADOR
Encargado de desarrollar los componentes de
software.
Implementar los casos de uso entregados por el
diseador.
Codificar y realizar las pruebas unitarias de los
componentes.
Externalizado
4
DESARROLLADOR
BBDD
Encargado de modelar e implementar la base de datos
segn el anlisis y diseo detallado.
Sergio Orellana J.
Mario Virot J.
5 TESTER
Crea, planifica y ejecuta los planes de pruebas para
asegurar que los estndares definidos se estn
cumpliendo, posteriormente se presentan al Jefe de
proyecto objeto preparar la entrega al cliente.
Sergio Orellana J.
Mario Virot J.

Tabla 1.3 Roles y Responsabilidad.

3.6 Matriz de Entregables

La siguiente tabla muestra de acuerdo a lo planificado las entregas realizada a
al cliente, separadas por cada Incremento.
Id Hito Etapa Actividad
Fecha
Entrega
Comentarios
E1
Incremento
1
Anlisis Entrega De Prototipo 23/07/12
En la entrevista con cliente,
entrega la idea en papel el cual
se confeccion prototipo.
E2 Pruebas Entrega Incremento 1 07/09/12
Entrega de primer avance.
Pendiente integracin con


mdulo Jefe de Departamento.
E3 Documentacin 1 11/09/12
E4
Incremento
2
Anlisis
Entrega de Prototipo
Final
12/09/12
Afinamiento definitivo prototipo.
E5
Pruebas
Entrega Incremento 2 19/10/12
Mejoramiento del primer
Incremento y entrega del
segundo avance.
Integracin mdulo Solicitante
con el Mdulo Jefe de
Departamento
Pendiente integracin Jefe de
Departamento con mdulo
Administrador.
E7 Incremento
3
Pruebas
Entrega de tercer avance.
Integracin Mdulo Jefe de
Departamento con el Mdulo
Administrador.
Pendiente desarrollo interfaz de
consulta y usuario.
E9 Incremento
4
Pruebas
Entrega de cuarto y final
avance.
Pruebas a interfaces de
consulta y usuario mdulo
Administrador.
Integracin mdulo de
Administrador con el Mdulo
Operador
Pruebas proyecto completo.
E11 Entrega sistema
Entrega e implantacin
del sistema


E12
Entrega
documentacin
Entrega documentacin
del sistema

Tabla 3.1 Matriz de Entregables.

3.7 Gestin de Riesgo
Consiste en Estimar el Riesgo, entendindose este como una combinacin de
la probabilidad y de las consecuencias, el cual se deben clasificar de acuerdo
siguientes niveles.

3.7.1 Matriz de Riesgo del Proyecto
En la tabla 3.3 se presentan las diferentes actividades de riesgos estimadas
durante la evolucin del proyecto, impactando en forma diferentes dependiendo en la


etapa de desarrollo, para lo cual es necesario considerar los planes de mitigacin objeto
evitar la ocurrencia y el plan de contingencia para cuando ocurra.
N Riesgo Etapa Impacto
Probabilidad
ocurrencia
Acciones
Mitigatorias
Plan de
Contingencia
R01
Errores en la estimacin
de los tiempos.

Anlisis
Incremento 1-2
Medio
Posible
Control semanal
v/s planificado
Reordenar el esfuerzo
para enfocarse a las
actividades Principales
pendientes.
Anlisis
Incremento 3
Catastrfico

R02
Cambio de los
requerimientos iniciales.
Anlisis
Incremento 1-2
Critico
Posible
Gestionar reunin
cliente y Jefe
proyecto objeto no
iterar en
requerimientos
errneos.
Reevaluar y considerar
como mejora del proyecto. Anlisis
Incremento 3
Catastrfico
R03 Diseo inadecuado.
Diseo
Incremento 1
Critico
Poco probable
Iteraciones
continuas con el
cliente objeto
verificar el diseo
previo a la
implementacin.
Realizar un nuevo diseo
que abarque el
requerimiento o la manera
desacoplarlo al proyecto
durante lo que queda de
tiempo, para considerar
como mejora del proyecto.
Diseo
Incremento 2
Catastrfico
R04
Mal diseo de las
pruebas.
Diseo
Incremento 1
Medio Poco probable
Estar
constantemente
capacitndose en
las herramientas
que nos facilita el
buen diseo.
Rehacer la planificacin y
verificar la eficacia de las
herramientas.
R05
Inexperiencia del equipo
en la implementacin
del proyecto.
Cdigo
Incremento 1
Medio
Posible
Cada integrante
del equipo debe
estar en constante
capacitacin.
Evaluar personal
apropiado en el equipo
trabajo objeto apoyar al de
falta experiencia.

Efectuar la contratacin de
un integrante nuevo.
Cdigo
Incremento 2-3
Critico
Cdigo
Incremento 4
Catastrfico
R06
Pobre dedicacin por
parte del Cliente y
usuario, para la correcta
definicin de requisitos
del proyecto.
Transversal Catastrfico Poco probable
Coordinacin de
Reuniones
mensuales con el
cliente y el usuario
correspondiente.
Iteraciones continuas en
presentacin del proyecto
al cliente
R07
Dificultad de
comunicacin entre los
miembros del equipo de
trabajo.
Transversal Critico Posible
Mantener una
constante
comunicacin y
confianza entre
los integrantes del
equipo.
Reunin con Jefe de
proyecto por apoyo.
R08
Renuncia de un
integrante del equipo de
trabajo.
Transversal
Incremento 1-2
Critico
Posible
Reprogramar
grupo de trabajo
Efectuar la contratacin de
un integrante nuevo. Transversal
Incremento 3-4
Catastrfico


Tabla 3.3 Matriz de Riesgo del Proyecto

4. Captulo IV
Resultados y Discusin


4.1 Mapa del Sitio

En la figura 4.0 se muestra el mapa del sitio el cual est compuesto por los
cuatro perfiles actores de nuestra aplicacin, donde el ingreso lo hacen a travs del
mdulo de seguridad con el RUT y clave, desplegando el mdulo correspondiente al
perfil ingresado.


Figura 4.0 Mapa del sitio.

4.2 Desarrollo Incrementos

4.2.1 Desarrollo Incrementos 1

Objetivo Incremento 1 4.2.1.1
Desarrollar el modelamiento BB.DD y el mdulo solicitud permitiendo generar
requerimientos y optimizando las pruebas para el desarrollo de los prximos mdulos y
poder efectuar el traspaso de la informacin solicitada.

Requerimientos Incremento 1 4.2.1.2

- Acceso de acuerdo a perfiles de Solicitante y Jefe de Departamento.
- Campos deben ser llenados en su totalidad.
- Generacin de un nmero de solicitud por automtico.
- Envi de mail informando requerimiento, para el visado o rechazo del Jefe de
Departamento.
- Registro de actores participantes en el mdulo de solicitud en BB.DD.

Cronograma del Incremento 1 4.2.1.3

En la figura 4.1 se visualiza la planificacin del Incremento 1, correspondiente al
desarrollo del mdulo Login, Solicitante y modelamiento de la base de datos, finalizando
con el hito 1 en la entrega del producto al cliente.


Figura 3.1 Cronograma Incremento 1

Figura 4.1 Cronograma Incremento 1.


Clculo Estimacin de Esfuerzo del Incremento 1 4.2.1.4
Los clculos para el Incremento 1 arrojaron una estimacin de esfuerzo de 120
horas-hombre equivalente al 40% para la etapa de desarrollo, por tanto la estimacin de
esfuerzo (E) del Incremento corresponde a 300 HH, objeto obtener la cantidad de das
se deber dividir por 6 horas las cuales fueron las consideradas por una jornada de
trabajo, el tiempo estimado para el Incremento 1 corresponde a 50 das.
En la tabla 4.0 se muestran los resultados calculados para la definicin de
estimacin de esfuerzo mediante la herramienta punto caso de uso.

Clculo estimacin de esfuerzo Incremento 1
TCF Factor de complejidad Tcnica 1
AW Factor de peso de los actores CU s/ ajustar 1
UCP Punto Caso de Usos 6

E Horas Hombres (E= UCP * PHM) 120

Tabla 4.0 Clculo Estimacin de Esfuerzo Incremento 1


Diagrama Casos de Usos Mdulo de Solicitud. 4.2.1.5

En la figura 4.2 se muestra el mdulo de solicitud con los actores Solicitante y
Jefe de Departamento relacionados al C.U, el cual ambos proporcionan los datos de
llenado de los campos del requerimiento y al trmino se enviar un correo informativo al
Jefe de Departamento para el visado y no visado del requerimiento.

Figura 4.2 Casos de Uso Mdulo de Solicitud

La tabla 4.1 muestra una descripcin del mdulo de solicitud, donde se puede
apreciar las condiciones previas que debe poseer los actores con el fin de tener acceso
al mdulo, como as tambin se muestra el flujo normal y alternativo de acuerdo al flujo
de trabajo.

MDULO DE SOLICITUD


Nombre Mdulo de solicitud
Autor Mario Virot - Sergio Orellana
Descripcin
El Solicitante o Jefe de Departamento inicia sesin con su Rut y Password
posteriormente realiza un requerimiento a travs de la aplicacin Web llenando todos
los campos solicitados sin omisin.
Actores Solicitante Jefe Departamento.
Precondiciones
Usuario debe estar registrado con el respectivo perfil.
Los datos ingresados por el usuario deben ser de acuerdo al requerimiento previo
recibido mediante documento.
Flujo Normal
1. El actor ingresa su Rut y clave.
2. El Actor completa los campos del mdulo** y realiza la solicitud.
3. La solicitud es enviada va mail para ser visada desde el mdulo jefe de
departamento.
4. El Sistema almacena el requerimiento con el estado de Solicitado.
Post. condiciones
Se informar al Solicitante y Jefe de Departamento cuando la solicitud tenga
observacin.
Se informar al Solicitante y Jefe de Departamento requerimiento se haya ejecutado
Flujo Alternativo
1. El actor al ingresar errneamente Rut o clave, el sistema alerta el error de inicio de
sesin el cual se debe ingresar nuevamente, en caso de olvidar clave se puede
solicitar una nueva clave por automtico.
2. En caso de no completar un campo, al momento de solicitar el mdulo indicar los
campos faltantes.
3. En caso de ser rechazada la solicitud, deber recibir un correo del rechazo con la
observacin correspondiente, el Solicitante o Jefe de Departamento deber a generar
una nueva solicitud.
** Campos Mdulos
Reparticin
Aplicacin.
IP de Origen.
IP de destino.
Puerto.
Vigencia.
Motivo acceso
Observaciones (opcional)

Tabla 4.1 Mdulo de Solicitud.


Diagrama Secuencia Mdulo de Solicitud. 4.2.1.6

La figura 4.3 muestra el diagrama Secuencia del Mdulo de solicitud, donde se
puede apreciar la interaccin del conjunto de objetos en la primera etapa de ejecucin
de la aplicacin a travs del tiempo y los actores como el Solicitante y Jefe de
Departamento el cual poseen el perfil para generar requerimientos.

Figura 4.3 Diagrama Secuencia Mdulo de Solicitud.

** (API) Interfaz de programacin de aplicaciones.


Arquitectura de Componentes del Incremento 1 4.2.1.7

En la tabla 4.2 se muestra la arquitectura con los componentes involucrados y
sus funciones, el cual debe ser implementada para el actor Solicitante.

Arquitectura Componentes Funciones Clasificacin
Capa de Presentacin Mdulo Solicitante
Los campos debern ser
completados con los datos
solicitados excepto cdigo de
solicitud y estado.
Evidente
Capa Negocio
Gestin
requerimiento.
Ingresar al sistema.
ingresar requerimiento.
Cdigo Solicitud entrega por
automtico.
Estado del requerimiento, por
defecto deber ser Solicitada
Oculto
Gestin seguridad
Validar el ingreso al sistema.
Verificar existencia de registro.
Notificador
Envo mail de notificacin de
requerimiento.
Capa de Datos componente BB.DD.
Almacenar los registros
completados en la capa de
presentacin.
Oculto

Tabla 4.2 Arquitectura de Componentes del Incremento 1


Interfaz Mdulo de Solicitante 4.2.1.8

En la figura 4.4 se muestra el mdulo de solicitud, el cual es accesado por el
Solicitante o Jefe de Departamento, un cdigo de solicitud es generado
automticamente al ingreso de la aplicacin, la seleccin de reparticin se encuentra
listada predefinida en el dropdownlist, la forma de transferencia de este requerimiento
por defecto es enviada presionando el botn Solicitar con el estado predefinido de
Solicitada.
El resto de campos deben ser llenados en forma obligatoria en caso contrario
la aplicacin alertar los faltantes con su respectivo mensaje y marcacin.

Figura 4.4 Mdulo Solicitante.


Modelamiento Base Datos. 4.2.1.9

El Modelado de datos determina la estructura lgica de una base de datos y
fundamentalmente determina el modo de almacenar, organizar y manipular los datos.
Se consider en la etapa del Incremento 1 el modelado de todos los datos con
el fin de facilitar el desarrollo de las pruebas de los mdulos restantes del proyecto.

4.2.1.9.1 Diagrama Entidad Relacin.
En la figura 4.5 se muestra las entidades relevantes del proyecto con sus
relaciones y propiedades.

Figura 4.5 Diagrama Entidad Relacin.


4.2.1.9.2 Diagrama Relacional.

En la figura 4.6 se muestra el modelo de datos del proyecto con sus respectivas
relaciones, este tipo de modelo posee la ventaja de gran flexibilidad debido a que no
posee una estructura jerrquica, de fcil entendimiento para la utilizacin por usuarios
no expertos en la administracin de la informacin.

Figura 4.6 Diagrama Relacional.


4.2.1.9.3 Implementacin de Datos.

En las siguientes tablas (4.3, 4.4, 4.5, 4.6) se muestra las entidades y atributos con
su respectiva descripcin de la base de datos DatabasePuerto.mdf.

Entidad Descripcin
Personal Usuario Personal o Actores que tienen acceso al sistema.
Reparticiones Corresponde a todas las reparticiones de la institucin.
Solicitud Requerimiento efectuado, estado de la solicitud.

Tabla 4.3 Entidades.

Entidad Personal Usuario
Atributo Descripcin Tipo
IdRut Numero identificador de usuario nvarchar (13)
Nombre Nombre usuario nvarchar (15)
Apellido Apellido Usuario nvarchar (15)
Password Clave de acceso usuario nvarchar (10)
Perfil_Usuario Categora dentro del Flujo de trabajo nvarchar (13)
Nivel_Usuario Relacionado con el perfil, numricamente tinyint
Reparticion_Origen Reparticin Administradora de App. nvarchar(15)
Mail_Usuario Correo electrnico usuario nvarchar(20)

Tabla 4.4 Atributos de la Entidad Personal Usuario.


Entidad Reparticin
Cod_Reparticion Nmero de reparticiones int
Nombre_Reparticion Reparticin que solicita la habilitacin nvarchar (20)

Tabla 4.5 Atributos de la entidad Reparticin.

Entidad Solicitud
Cod_Solicitud Numero de requerimiento int
Puerto Puerto habilitar int
Fecha_Activacion Fecha activacin date
IP_Origen IP de App. nvarchar (16)
IP_Destino IP de Terminal a Habilitar nvarchar (16)
Motivo_Acceso Motivo del Requerimiento nvarchar (50)
Fecha_Expiracion Fecha trminos acceso date
Fecha_solicitud Fecha efectuado el requerimiento date
Estado Estado del requerimiento de acuerdo al Flujo de
trabajo.
nvarchar(15)
Observaciones Observaciones nvarchar(max)
Cod_Reparticiondestino Nmero Reparticin habilitar int

Tabla 4.6 Atributos de la entidad Solicitud.


Etapa de Cdigo. 4.2.1.10
Las tecnologas utilizadas para el modelado y desarrollo del sistema fueron las
herramienta Rational Rose el cual permite modelar un sistema mediante el lenguaje
unificado de modelado (UML) y Microsoft Visual Studio 2010 Professional, herramienta
integrado de desarrollo (IDE), esencial para desarrolladores con mltiples lenguajes
(ASP NET + C #) y motor de base de datos incluidas (SQL SERVER).

Pruebas 4.2.1.11

Para la etapa de pruebas, se efectu basado en un anlisis operacional del
mdulo, utilizando la ruta de flujo normal y alternativo, el protocolos, reportes hallados y
el detalle al plan de liberacin de los Incrementos se encuentran en el anexo B y C
(pruebas de aceptacin y pruebas locales respectivamente).


4.2.2 Desarrollo Incremento 2

Desarrollar interfaz de seleccin nivel de usuario y mdulo de Jefe de
Departamento, permitiendo al actor Jefe de Departamento dualidad de perfil.


- Acceso de acuerdo al perfil Jefe de Departamento.
- Desarrollar un Mdulo de seleccin nivel de usuario.
- Muestreo de las solicitudes en una grilla, en orden de acuerdo al nmero de
solicitud.
- Autorizar o Rechazar el requerimiento, cambiando el estado de solicitada a
Visado o no visado respectivamente.
- permitir ingreso de Observaciones.
- Envi de los requerimientos para la autorizacin o rechazo del Administrador.


En la figura 4.7 se visualiza la planificacin del Incremento 2, correspondiente al
desarrollo de la interfaz de nivel usuario y del mdulo Jefe de Departamento, finalizando
con el hito 2 en la entrega del producto al cliente.










Diagrama Caso de Uso Modulo Jefe de Departamento. 4.2.2.5

En las figuras 4.8 y 4.9 se muestra la interfaz de seleccin nivel usuario y el
mdulo Jefe de Departamento, el actor el cual interacta en esta parte del sistema
corresponde al Jefe de Departamento, el cual tiene dos perfiles de ingreso selectables
en la interfaz de nivel usuario, permitiendo el ingreso al mdulo del Solicitante objeto
generar solicitudes y al mdulo del Jefe de Departamento para el visado y no visado de
los requerimientos.


Figura 4.8 Interfaz Nivel de Usuario

Figura 4.9 Diagrama Caso de Uso Mdulo Jefe Departamento.

La tabla 4.8 muestra una descripcin del mdulo Jefe de Departamento, donde
se puede apreciar las condiciones previas que debe poseer el actor con el fin de tener
acceso al mdulo, como as tambin se muestra el flujo normal y alternativo de acuerdo
al flujo de trabajo implementado.

INTERFAZ NIVEL USUARIO
MDULO JEFE DE DEPARTAMENTO


Tabla 4.8 Mdulo Jefe Departamento

Diagrama de Secuencia Mdulo Jefe Departamento. 4.2.2.6

En el Diagrama Secuencia del Mdulo de Jefe de Departamento Figura 4.10, se
muestra la interaccin del conjunto de objetos en la segunda etapa de desarrollo de la
Nombre. Mdulo Jefe Departamento
Descripcin

Jefe Departamento autorizar o rechazar el requerimiento en el estado de
Solicitado.
Actores Jefe Departamento.
Precondiciones
Usuario debe estar registrado con el respectivo perfil.
El Jefe de Departamento deber corroborar los datos ingresados de
acuerdo al documento solicitado.
Flujo Normal
El Actor ingresa su Rut y clave.
Visualiza la grilla con los requerimientos.
El Actor Visa la solicitud y se enva el requerimiento al Administrador.
El Sistema almacena el requerimiento con el estado de Visado.
Post. Condiciones
Se informar al Administrador va mail, cuando el requerimiento se haya
visado.
Flujo Alternativo
El actor al ingresar errneamente Rut o clave, el sistema alerta el error de
inicio de sesin el cual se debe ingresar nuevamente, en caso de olvidar
clave se puede solicitar una nueva clave por automtico.
Se informar al usuario va mail cuando el requerimiento se haya
rechazado con la respectiva observacin, el cual deber generar una
nuevo requerimiento.
En caso de ser rechazada la solicitud por el Administrador, deber recibir
un correo con la observacin correspondiente, el Solicitante o Jefe de
Departamento deber a generar una nueva solicitud.


aplicacin a travs del tiempo, donde el Jefe de Departamento autoriza el
requerimiento posteriormente se enva un mail al Administrador en el estado de
Visada.

Figura 4.10 Diagrama de Secuencia Mdulo Jefe Departamento.




sus funciones, el cual debe ser implementada para el actor Jefe de Departamento.

Arquitectura Componentes funciones Clasificacin
Capa de Presentacin
Mdulo Solicitante.
En el Mdulo Solicitante los
campos debern ser completados
con los datos solicitados excepto
cdigo de solicitud y reparticin.
Evidente
Mdulo Jefe de
Departamento.
En el Mdulo Jefe de
Departamento. deber mostrar los
datos en una grilla, posteriormente
autorizar o rechazar el
requerimiento.
Capa Negocio
Gestin
requerimiento.
ingresar datos del requerimiento
(Mdulo Solicitante).
Cdigo Solicitud entrega por
automtico (Mdulo Solicitante).
Cambiar estado del requerimiento.
Oculto
Gestin seguridad
Validar el ingreso al sistema.
Notificador
Envo notificacin requerimiento.
Capa de Datos Componente
BB.DD.
Almacena el cambio de estado.
Oculto

Tabla 4.9 Arquitectura de Componente Incremento 2.


Interfaz Nivel de Usuario Jefe Departamento 4.2.2.8

En la Figura 4.11 se muestra la interfaz de nivel de usuario el cual permite
selectar los mdulos de Solicitante o Jefe de Departamento.

Figura 4.11 Interfaz Nivel de Usuario (Jefe Departamento.)

Mdulo Jefe Departamento 4.2.2.9

La figura 4.12 corresponde al mdulo del Jefe de Departamento, donde se
muestra una grilla con todas las solicitudes en el estado de solicitadas, esta deber ser
autorizadas o rechazadas, para los casos anteriores al ser autorizada se enviar mail al
Administrador de la red WAN Armada y en caso de ser rechazada es informar al
usuario generador de la solicitud, el cual deber efectuar un nuevo requerimiento.


Figura 4.12 Mdulo Jefe de Departamento.

Pruebas 4.2.2.10



Desarrollar el mdulo del Administrador el cual deber cumplir la funcin de
generar ingreso, modificacin y eliminacin de usuarios, autorizar o rechazar de las
solicitudes, generadas por personal de las Direcciones tcnicas o reparticiones.



- Acceso de acuerdo al perfil de Administrador.
- Desarrollar los Mdulo de solicitud, consulta y usuario.
- Muestreo de las solicitudes en grilla, en orden de acuerdo al nmero de solicitud.
- Despliegue de la grilla selectada para la autorizacin o rechazo.
- Envo de la solicitud al Operador en el estado de autorizado, para su ejecucin.

En la figura 4.13 se visualiza la planificacin del Incremento 3, correspondiente
al desarrollo del mdulo del Administrador, finalizando con el hito 3 en la entrega del
producto al cliente.









Diagrama Caso de Uso Mdulo Administrador 4.2.3.5

En la figura 4.14 se muestra el diagrama de caso de usos correspondiente al
Administrador, el cual al ingresar a su mdulo visualiza el requerimiento para su
autorizacin o rechazo, esto se produce una vez la solicitud es autorizada por el Jefe
de Departamento.
El Administrador tambin posee la facultad de efectuar consultas a travs de la
interfaz de consulta objeto monitorear las reparticiones de destino con los diferentes
estados de los requerimientos (solicitada, no visada, visada, autorizada, rechazada,
efectuada, expirada o todas)
A travs de un filtro con el Rut o apellido en la interfaz de usuario, el
Administrador podr listar los usuarios con sus respectivos perfiles y reparticiones, el
cual podr modificar, eliminar o ingresar uno nuevo.

Figura 4.14 Caso de Uso Mdulo Administrador

MDULO ADMINISTRADOR


La tabla 4.11 muestra una descripcin del mdulo del Administrador, donde se
puede apreciar las condiciones previas que debe poseer el actor con el fin de tener
al Flujo de trabajo implementado.
Nombre Mdulo Administrador
Descripcin
El Administrador Red WAN efectuar la autorizacin o rechazo de la
solicitud, podr hacer consultas objeto ver el estado de las solicitudes y
manejo de perfiles de usuarios.
Actores Administrador Red WAN.
Precondiciones El Actor debe estar registrado con el respectivo perfil.
Flujo Normal
Visualiza grilla de solicitudes solo estado de Visadas.
Selecciona la solicitud y se despliega mdulo con el detalle de la solicitud
para su verificacin posteriormente autoriza o rechazo.
Presiona el botn guardar, para generar el cambio y envo de mail al
Operador.
Flujo Opcional
Selecta mdulo consulta objeto obtener reporte de estado de solicitudes
por reparticin de destino.
Selecta mdulo usuario objeto consultar por Rut o apellido con el fin de
modificar, eliminar o ingresar nuevo usuario.
Flujo Alternativo
Se informar al Solicitante y Jefe de Departamento va mail cuando el
requerimiento se haya rechazado con la respectiva observacin, el cual
deber generar una nuevo requerimiento.

Tabla 4.11 Mdulo Administrador.


Diagrama Secuencia Mdulo Administrador 4.2.3.6

En el Diagrama Secuencia del Mdulo Administrador figura 4.15, se muestra la
interaccin del conjunto de objetos en la tercera etapa de desarrollo de la aplicacin a
travs del tiempo, donde el Jefe de Departamento en el flujo normal autoriza el
requerimiento posteriormente se enva un mail al Operador de la red WAN en el estado
de Autorizada.

Figura 4.15 Diagrama Secuencia Mdulo Administrador.




sus funciones, el cual debe ser implementada para el actor Administrador.

Capa de Presentacin
Mdulo
Administrador
Deber mostrar los datos en una
grilla, posteriormente desplegar el
requerimiento detallado selectado.
Muestra opcin de autorizar o
rechazar el requerimiento.
En interfaz de consulta muestra
estado de requerimientos por
reparticin de destino.
Interfaz de usuario muestra,
caracterstica del perfil de usuario
por RUT o apellido.
Evidente
Capa Negocio
Gestin
requerimiento.
Consulta por reparticin destino,
estado de solicitud, RUT o
apellido.
Modifica, elimina o inserta
usuarios.
Oculto
Gestin seguridad
Validar el ingreso al sistema
Notificador
Envo mail notificacin
requerimiento.
BB.DD.
Almacena usuario.

Oculto



Mdulo Administrador 4.2.3.8

El mdulo del Administrador est compuesto por tres interfaces denominadas
solicitudes, consulta y usuarios, el cual permitir efectuar las autorizaciones y rechazos
de solicitudes, consultas de estados de solicitudes de acuerdo a su reparticin de
destino e ingreso, modificacin y eliminacin de usuarios.

Interfaz de Solicitud. 4.2.3.9

Al ingresar al mdulo del Administrador se desplegar una grilla (figura 4.16) el
cual se deber seleccionar una con el fin de mostrar el detalle del requerimiento (figura
4.17), una vez autorizada o rechazada, se presiona guardar objeto se produzca la
Secuencia correspondiente al flujo de trabajo de la solicitud.
Si la solicitud es rechazada o autorizada es enviado un mail notificador a los
respectivos actores, originador u Operador red WAN respectivamente.

Figura 4.16 Mdulo Administrador


Figura 4.17 Interfaz Administrador Solicitudes.

Interfaz de Consulta. 4.2.3.10

La interfaz de consulta (figura 4.18) permitir visualizar todos los requerimientos
vigentes de una reparticin de destino, el cual se podr consultar por un estado
especfico (solicitada, visada, no visada, autorizada, rechazada, efectuada, expirada) o
por todas de una sola vez pertenecientes a dicha reparticin.


Figura 4.18 Interfaz Administrador Consulta

Interfaz de Usuarios 4.2.3.11

El Administrador puede efectuar consultas por RUT, apellido o reparticin de
destino ver figura 4.19, esto con el fin de poder visualizar datos de los usuarios
habilitados con el perfil correspondiente, al seleccionar en la grilla nos permitir insertar
o eliminar un usuario, al querer modificar se desplegar el detalle del usuario ver figura
4.20 donde podr modificar todos los datos requeridos.


Figura 4.19 Interfaz Administrador Usuarios


Figura 4.20 Interfaz Administrador Modificacin Usuarios

Pruebas 4.2.3.12




Desarrollar el mdulo Operador el cual deber visualizar en una grilla todas las
solicitudes en el estado de Autorizada, una vez efectuada la accin de habilitacin del
puerto, cambiar el estado ha Efectuado y envo de mail notificador al Solicitante y Jefe
de Departamento de la direccin o reparticin requirente.


- Acceso de acuerdo al perfil de Operador.
- Muestreo de las solicitudes en una grilla, en orden de acuerdo al nmero de
solicitud.
- Despliegue de la grilla selectada para la visualizacin del requerimiento.
- Al seleccionar el botn efectuado, cambiar el estado final de la solicitud y generar
el envo de mail al Solicitante y Jefe de Departamento informando el
requerimiento Efectuado.
- Seleccionar Expirado: Una vez informado por el Jefe Red WAN la expiracin de
la fecha de habilitacin, se debe cambiar al estado de Expirado y envo de mail
informando a los usuarios Solicitantes.



En la figura 4.21 se visualiza la planificacin del Incremento 4, correspondiente
al desarrollo del mdulo del Operador, finalizando con el hito 4 en la entrega e
implantacin del producto al cliente.



Clculo Estimacin de Esfuerzo Incremento 4 4.2.4.4



E Horas Hombres(E= UCP * PHM) 91

Tabla 4.13 Clculo Estimacin de Esfuerzo Incremento 4.


Diagrama Caso de Uso Mdulo Operador 4.2.4.5

En la figura 4.22 se muestra el mdulo del Operador, el actor relacionado con el
C.U es el Operador red WAN Armada, el cual visualizar los requerimientos en el
estado de Autorizados enviados por el Administrador, una vez ejecutada la accin de
habilitacin el Operador cambia el estado a Efectuado enviando por automtico mail al
Solicitante y Jefe de Departamento.

Figura 4.22 Caso de Uso Mdulo del Operador.

MDULO OPERADOR


La tabla 4.14 muestra una descripcin del mdulo del Operador, donde se
puede apreciar las condiciones previas que debe poseer el actor con el fin de tener
al Flujo de trabajo implementado.

Tabla 4.14 Mdulo Operador.

Nombre Mdulo Operador
Descripcin

El Operador Red WAN enviar a travs de la aplicacin Web la conformidad de
la ejecucin Solicitud.
Actores Operador Red WAN.
Precondiciones El Actor debe estar registrado con el respectivo perfil.
Flujo Normal
El Actor visualiza las grillas de requerimiento.
El actor selecciona grilla objeto detallar requerimiento.
Cambia estado del requerimiento ha efectuado.
Envo automtico mail al Solicitante y Jefe de Departamento solicitud
Efectuada conforme.
Post. Condiciones El Sistema almacena el requerimiento con el estado de Efectuado
Flujo Alternativo


Diagrama Secuencia Mdulo Operador 4.2.4.6

En el Diagrama Secuencia del Mdulo del Operador figura 4.23 se muestra la
interaccin del conjunto de objetos de la cuarta etapa de desarrollo de la aplicacin a
travs del tiempo, donde el Operador posteriormente a efectuar la ejecucin de la
habilitacin del puerto, cambia estado y enva mail al Solicitante y Jefe de
Departamento con el requerimiento efectuado.

Figura 4.23 Diagrama Secuencia Mdulo Operador.




En la tabla 4.15se muestra la arquitectura con los componentes involucrados y
sus funciones, el cual debe ser implementada para el actor Operador red WAN.

Capa de Presentacin
Mdulo Operador
Deber mostrar los datos en una
grilla, posteriormente desplegar el
requerimiento detallado selectado.
En interfaz desplegada muestra
botn de requerimiento efectuado.
Evidente
Capa Negocio
Gestin
requerimiento.
Oculto
Gestin seguridad
Validar el ingreso al sistema
Notificador
Envo mail notificacin
requerimiento Efectuado.
BB.DD.
Oculto



Mdulo del Operador red WAN 4.2.4.8

El Operador, posee una grilla en su pgina de entrada a la aplicacin (figura
4.24), el cual indica todas las solicitudes pendientes en el estado de autorizada
(Administrador), una vez existido un requerimiento se debe presionar el botn detallar
objeto verificar todos los datos correspondientes al requerimiento (figura 4.25),
posteriormente de ejecutada la accin de habilitacin del puerto, se debe responder al
Solicitante su requerimiento efectuado conforme, presionando el botn Efectuado
informacin enviada automticamente va mail al Solicitante y Jefe Departamento.

Figura 4.24 Mdulo del Operador


Figura 4.25 Interfaz Detallada del Operador.

Pruebas 4.2.4.9



4.3 Experiencias del proyecto

4.3.1 Pruebas.

Las pruebas efectuadas al sistema fueron sostenidas en la funcionalidad e
integracin de los diferentes mdulos del proyecto, para tal efecto se ejecutaron en
forma conjunta, sin embargo la determinacin no fue la ms apropiada debido a que
cuando se debi probar en ciertos casos, especficamente en el desarrollo entre el
mdulo del Solicitante y el Jefe de Departamento, Mdulo Jefe de Departamento y el


Administrador y finalmente entre el Mdulo Administrador y el Mdulo Operador no fue
posible ejecutar en forma inmediata la integracin ya que no estaba desarrollada.

Para tal efecto de acuerdo a la planificacin de cada Incremento las
observaciones fueron corregidas en forma inmediata al comienzo del siguiente,
incluyendo al inicio de las pruebas del Incremento a entregar, sin embargo es
importante destacar que la metodologa nos permiti tanto al grupo de trabajo como
cliente mantener un control absoluto de la evolucin del proyecto, entregando por cada
finalizacin de Incremento un producto operacional del punto de vista local, ya que el
cliente no poda utilizarlo hasta el trmino del sistema.

Lo hallazgos detectados bsicamente se orientan al funcionamiento lgico del
sistema, ver reporte anexo B esto se transformaron en algunas circunstancias como un
requerimiento nuevo posible de solucionar y en otras circunstancias quedando como
mejoras del proyecto.

Para la obtencin de resultados, se debi poblar la base de datos (ver anexo A)
con una reparticin Administradora de aplicacin en la institucin y personal de usuario
con los perfiles correspondientes.
En las siguientes tablas se presenta un resumen del plan de pruebas
funcionales e integracin, clasificacin de los hallazgos encontrados se encuentran en
la tabla 4.21 (cambios de requerimientos)

Casos de Prueba Mdulo Login. 4.3.1.1
# Mdulo Tipo de Prueba Objetivo de La Prueba
1
Mdulo Login
Funcional Verificar validacin de campos de ingreso
2
Funcional
Verificar completado de datos


3
Funcional
Verificar validacin del Rut
4
Integracin
Ingreso de perfiles

Integracin
Recuperacin de clave
Tabla 4.16 Casos de Prueba Mdulo Login

Casos de Prueba Mdulo Solicitante. 4.3.1.2

1
Mdulo
Solicitante
Funcional Verificar Cdigo de solicitud automtico
2
Funcional
Validacin de IP
4
Funcional
Validacin del campo de ingreso del Puerto
5
Funcional
Validacin campo de vigencia
6
Funcional
Verificar campos obligatorios.
7
Integracin
Solicitar requerimientos
8
Integracin
Verificar envo de mail notificador
Tabla 4.17 Casos de Prueba Mdulo Solicitante
Casos de Prueba Mdulo Jefe Departamento 4.3.1.3
# Mdulo Tipo de Prueba Objetivo de la Prueba
1
Mdulo Jefe
Departamento.
Integracin
Verificar el ingreso de perfil de usuario y Jefe
Departamento.
2
Integracin
Verificar Rechazo del requerimiento
3
Integracin
Verificar autorizacin del requerimiento
5
Funcional
Verificar estado No visado en BB.DD
6
Funcional
Verificar estado Visado en BB.DD


7
Funcional
Cerrado de Sesin

Tabla 4.18 Casos de Prueba Mdulo Jefe Departamento.

Casos de Prueba Mdulo Administrador 4.3.1.4

1
Administrador
(interfaz
Solicitudes)
Integracin Verificar en grilla, solicitud estado Visado
2 Funcional Desplegar requerimiento detallado.
3 Integracin Verificar Autorizacin de solicitud
4
Integracin
Verificar rechazo solicitud
5
Funcional
Verificacin de campos sin acceso
6
Funcional
Verificacin de botn volver
7
Administrador
(interfaz
Consultas)
Integracin
Generar reportes estado
6
Administrador
(Interfaz de
Usuario)
Integracin
Bsqueda de usuario por Rut
7
Integracin
Bsqueda por apellido o letra
8
Integracin
Bsqueda por reparticin Origen
9
Administrador
(Control de
Usuario)
Integracin
Eliminar
10
Integracin
Modificar
11
Integracin
Ingresar
12
Funcional
Verificacin de Paginas

Tabla 4.19 Casos de Prueba Mdulo Administrador.


Casos de Prueba Mdulo Operador 4.3.1.5

1
Mdulo
Operador
Funcional Verificar estado de autorizada en grilla
2
Integracin
Muestra detallada de la solicitud
3
Funcional Verificacin de campos sin acceso
4
Funcional
Requerimiento efectuado
5 Integracin Verificar Autorizacin de solicitud
6
Funcional
Verificacin de botn volver

Tabla 4.20 Casos de Prueba Mdulo Operador.

4.3.2 Discusin plan SQA

Software Quality Assurance, es un conjunto de actividades sistemticas,
planeadas para asegurar que los procesos y productos del SW cumplan con los
requerimientos, estndares y procedimientos, con el propsito de obtener la visibilidad
sobre el producto que genera.


A nuestra aplicacin adaptaremos el plan SQA, que se realiza durante el ciclo
de vida del proyecto, el cual consistir poder efectuar pruebas a la aplicacin Web y
poder apreciar la calidad de la aplicacin, en cuanto a reconocer errores, el sistema de
flujo de trabajo, fluya sin inconvenientes, la aplicacin sea 24x7, una base de datos
confiable y sin problema de escalabilidad.
Las tareas de SQA a realizar sern;
Panorama general de tareas
Revisin de especificacin del sistema.
Revisin del plan de proyecto de la aplicacin Web.
Revisiones de cumplimiento de requerimientos.
Revisin del diseo de datos.
Revisin del diseo arquitectnico.
Revisin del diseo de interfaz grfica (GUI) en los diferentes mdulos.
Revisin del diseo de componentes.
Revisin de cdigo.
Revisin de la especificacin de pruebas.
Revisin de documentacin del proyecto.
Revisin de reportes de deficiencias en diferentes iteraciones.
Actividades de mejora del proceso de software como conclusiones planteadas al
cliente.
4.3.3 Gestin y Control de los Riesgos.

En la gestin y control de los riesgo de nuestro proyecto, evaluamos 8
probabilidades de riesgos (ver tabla 3.3), sin embargo durante el desarrollo del proyecto
hubieron riesgo que no se activaron y otro que no fueron considerados, a continuacin
se describen los resultados obtenidos.


R01 Errores en la estimacin del tiempo, fase Incremento 3

En el caso del riesgo 01 considerados originalmente, fue activado en el
Incremento 3 debido a la magnitud del mdulo del Administrador a desarrollar en
comparacin con los otros mdulos del proyecto, sin embargo el impacto considerado
fue menor al descrito, debido a la oportuna reorganizacin de los tiempos modificando
la estimacin del mdulo restante correspondiente al mdulo del Operador red WAN.
El plan de mitigacin y contingencia consideradas, fueron los adecuados
permitiendo darnos cuenta de la propuesta errnea a la distribucin del tiempo del
mdulo a desarrollar, sin embargo la estimacin mayor de tiempo al mdulo del
Operador nos permiti readecuar el desarrollo del proyecto.

R02 Cambio de los requerimientos inciales.

En el caso del riesgo 02 mediantes las acciones de mitigacin y contingencia
obtuvimos cambios que en algunos casos fueron modificaciones menores el cual se
detectaron mientras el proyecto avanzaba en sus Incremento o se efectuaban pruebas
sin embargo hubieron modificaciones el cual se debieron considerar como una mejora
del proyecto.
En la tabla 4.21 se muestra las modificaciones efectuada a los requerimientos
inciales entregados por el cliente clasificado como cosmtico y nuevos requerimiento
abordable durante el desarrollo del proyecto.
Mdulo Requerimiento nuevo Descripcin Clasificacin
Login Restablecer contrasea
En muchas oportunidades nos
vimos obligados a verificar la
BB.DD, objeto obtener una
contrasea, por tanto fue
necesario generar una clave por
automtico.
Requerimiento nuevo


Cambio de clave
asignada
Los usuarios no pueden efectuar
cambio de clave, una vez
asignada.
Mejora del sistema
Jefe de
Departamento
Interfaz de Nivel de
Usuario
El cliente solicito que los Jefes de
Departamento puedan generar
solicitud, por tanto deber poseer
dualidad de perfil.
Requerimiento nuevo
Indicar nmero de
solicitud
En la grilla, debera aparecer el
nmero de solicitud.
Requerimiento nuevo
Paginacin de grilla
Ordenamiento de la grilla en
forma lgica.
Cosmtico
Administrador
Crear estado de
expirada
(interfaz de consulta)
Se debi crear un estado de
expirada y objeto deshabilitar
aquellos puertos que se
encuentren fuera del plazo
solicitado.
Requerimiento nuevo
Seleccin de todas
(interfaz de consulta)
Adicionar condicin de todas en
la interfaz de consulta, con el fin
de ver todos los estados de las
solicitudes en una reparticin.
Requerimiento nuevo
Autocompletacin
(interfaz de usuario)
Permitir la Autocompletacin del
campo, de acuerdo a los registro.
Cosmtico
Eliminacin de
Solicitante.
Los usuarios no se pueden
eliminar debido a que existe una
solicitud asignada al RUT.
Mejora del sistema
General
Confirmacin de
seleccin
Efectuar confirmacin de
seleccin a las diferentes
acciones de los actores.
Requerimiento nuevo
Seguimiento por nmero
de solicitud
Efectuar el seguimiento por el
Solicitante, Jefe de
Departamento y Administrador de
una solicitud por su nmero.
Requerimiento nuevo


Tabla 4.21 Cambios a los Requerimientos

R03 Diseo inadecuado.
En el caso del riesgo 03, tuvimos que efectuar modificacin a los diseos
inciales, bsicamente por la diferentes atribuciones que debieran tener los actores en
cada perfil, sin embargo esto fue detectado con las reuniones de coordinacin y entrega
de cada comienzo en cada Incremento.

R05 Inexperiencia del equipo en la implementacin del proyecto.
Para el caso del riesgo 05, fue el que se activ al momento de desarrollar el
sistema por la falta de experiencia del equipo, el plan mitigador no fue lo suficiente para
llevar a cabo el proyecto en forma normal, sin embarg se tuvo que complementar con
plan de contingencia considerado para este riesgo, donde se debi pedir apoyo de una
persona que efecte programacin en Visual Studio en lenguaje C#.

4.3.4 Control de Estimacin de Esfuerzo Planificado v/s Real

En la tabla 4.22 se muestra la comparacin de estimacin de esfuerzo calculada
v/s lo real, sin embargo podemos comentar que durante la evolucin del desarrollo del
proyecto fue finalizado dentro el periodo programado, sin embargo hubo una
modificacin desde el Incremento 3 en adelante debido a que el mdulo del
Administrador llev mayor tiempo dado por la magnitud del desarrollo.
La manera de abordar el problema de estimacin, fue distribuyendo el tiempo en
complemento con el Incremento 4 el cual fue de menor complejidad debido a la


experiencia adquirida en la interfaz de solicitud desplegada del mdulo del
Administrador.
Planificado Real
Incremento Detalle Das
planificados
Das
Reales
1 Modelamiento BB.DD
Mdulo Solicitante
50 Modelamiento BB.DD
Mdulo Solicitante.
45
2 Mdulo Jefe de
Departamento.
31 Mdulo Jefe de
Departamento.
15
3 Mdulo Administrador 30 Mdulo Administrador 30
4 Mdulo Operador 38 Mdulo Administrador
Mdulo Operador
52

Total das 149 142

Tabla 4.22 Estimacin de Esfuerzo Planificado v/s Real

4.3.5 Comparacin Ambiente de Desarrollo y Pruebas.

El desarrollo fue efectuado en IDE (Interface Developer Enviroment) Visual
Studio en su versin 2010, la cual nos presenta versiones reducidas del Administrador
de base de datos MS-SQL Server y la posibilidad de utilizar servidores WEB virtuales,
donde se efectuaron todas las pruebas funcionales y de integracin entre los mdulos
desarrollados.
Posteriormente en perodo de implantacin del sistema se debi migrar las
paginas ASP.NET que componen el sitio al servidor adquirido por DIRECTELINF para


este proyecto, como tambin la base de datos denominada DatabasePuerto la que
almacena todos los registros para el funcionamiento de la aplicacin.
Una vez instalado el sistema en los servidores DIRECTELINF se procedi a
realizar las pruebas dinmicas, estableciendo un perodo de pre-produccin de quince
das, equivalente a la gestin de veinticinco solicitudes aproximadamente, con el fin de
verificar el funcionamiento correcto de la aplicacin.
Comparativamente las pruebas en ambiente de desarrollo y produccin no
defirieron en su resultado, pero s en el tiempo de procesamiento, debido al propio
trabajo en red y disponibilidad de los usuarios al autorizar los requerimientos, para lo
cual fue necesario orientar a un grupo de usuarios en la utilizacin y as poder verificar
el flujo de trabajo de la solicitud.

4.3.6 Manual de Utilizacin

El sistema fue realizado para uso WEB y esta optimizado para internet Explorer
y Firefox en ambiente intranet, actualmente de uso generalizado en la organizacin.
El manual de utilizacin fue representado en un tutorial orientado a los usuarios
Solicitantes y Jefe de Departamento.

4.3.7 Mantencin

La aplicacin no fue requerida con mantencin externa, por acceso restringido a
los servidores del cliente, sin embargo se instruy al Administrador de la Red WAN
Armada la revisin de las anotaciones de sistemas (Logs) de la base de datos y del
servidor WEB con el objeto de verificar los reportes y as ante alguna anormalidad esta
sea informada para analizar su comportamiento.


4.4 Seguimiento y Control

En la tabla 3.0 se muestra los procesos realizados en la etapa de ejecucin del
proyecto con el fin de identificar en forma oportuna los problemas potenciales y adoptar
medidas cuando sea necesario.
Etapa F. Inicio F. Termino Actividades % Avance
Propuesta Tcnica 4/07/12 21/07/12 Entrevista cliente 100%
Incremento 1 4/07/12 11/09/12
Anlisis 100%
Diseo 100%
Cdigo 100%
Prueba 100%
Incremento 2 11/09/12 24/10/12
Anlisis 100%
Diseo 100%
Cdigo 100%
Prueba 100%
Incremento 3 25/10/12 6/12/12
Anlisis 100%
Diseo 100%
Cdigo 100%
Prueba 100%
Incremento 4 6/12/12 26/01/13
Anlisis 100%
Diseo 100%
Cdigo 100%
Prueba 100%

Tabla 3.0 Seguimiento y Control.


4.5 Matriz de Pendientes
En la tabla 3.2 se muestra el registro de las actividades pendientes que fueron
efectuadas posteriormente a la fecha planificada.
Descripcin de Actividad Fecha de
Inicio
Fecha de
Trmino
Plan de Actividades Asociado
Pruebas de integracin
Mdulo Solicitante /
Mdulo Jefe de
Departamento
4/07/12
25/10/12
Espera integracin de mdulos,
hasta el desarrollo Incremento
siguiente.

Mdulo Jefe de
Departamento / Mdulo
Administrador
12/09/12
06/12/12
Mdulo Administrador con
interfaces de consulta y
usuario
25/10/12
23/01/13
Mdulo Administrador /
Mdulo Operador
25/10/12
23/01/13
Entrega e implantacin
sistema.
24/01/13
26/01/13
Implantacin del proyecto en el
servidor cliente
Entrega documentacin
sistema
24/01/13
26/01/13 Entrega informe final.

Tabla 3.2 Matriz de Pendientes.



5. Captulo V
Conclusiones

5.1 Lecciones Aprendidas.

Durante la ejecucin de este proyecto, se obtuvieron experiencias el cual
debemos tomar en cuenta para cada desarrollo de un proyecto, donde pensamos que
son esenciales para la unin el grupo humano, tanto para el equipo desarrollador y el
cliente, finalmente esto llevara al xito del objetivo planteado.
Definimos ciertos puntos primordiales para una buena ejecucin de un
proyecto por el equipo de trabajo:


No se debe estimar un proyecto de manera fcil sin efectuar un anlisis de todos
los requerimientos solicitados por el cliente, ya que cada requerimiento posee
una dificultad diferente.

Mientras ms detalladamente se conozcan sus requerimientos, mejor se podr
llevar acabo el desarrollo de este y a la vez menos incertidumbre existir.

En cada cronograma de desarrollo del proyecto, dejar una holgura o reserva de
tiempo en tareas para posibles soluciones inesperadas.

Hacer un seguimiento constante en el Desarrollo del Proyecto.

En las reuniones con el cliente que vaya siempre la misma gente que
comenzaron el proyecto, claro que por supuesto siempre existir el riesgo de
cambio de algn integrante del proyecto ya sea como cliente y ejecutantes, ya
que siendo las mismas personas no se harn nuevos cambios al proyecto.

La tabla de riesgos con sus respectivos planes de mitigacin y contingencia, son
de vital importancia, objeto no retrasar el desarrollo del proyecto.

La constante comunicacin con el cliente permite un mejor manejo del proyecto.

Los requerimientos deben quedar bien definidos objeto el proyecto no se
transforme interminable.

Se debe plantear siempre dentro la propuesta el hardware y software necesario
para el desarrollo del proyecto.


Los planes de prueba deben ser programado por etapas, dependiendo la
metodologa utilizada, para el caso de nosotros se debe dividir las pruebas
locales con las de integracin.

Para la confeccin de los diseos es recomendable estar siempre en contacto
con el cliente, con el fin de optimizar el tiempo ante la eventualidad de problemas
en el desarrollo y pruebas del sistema.

5.2 Conclusiones Generales

La Armada de Chile perteneciente como institucin del Ministerio de Defensa,
posee sitios con acceso restringido con la clasificacin de Reservada y Confidencial,
estos sitios poseen aplicaciones Web el cual, son administrados por organizaciones
dentro de la institucin.


Las aplicaciones son especficas de trabajos para ciertas reas, por tanto se
hace necesario limitar, controlar y autorizar el acceso de cierto personal para que
tengan acceso a ellas.
En la situacin actual se hace lento e ineficiente el trmite por todas las normas
establecidas para la tramitacin de documentacin dentro de la institucin, con la
aplicacin Web desarrollada se eliminar el uso del documento en papel y permitir que
el proceso sea ms eficiente para solicitar un acceso a algn servicio de Intranet.
La tramitacin est basada bajo la estructura flujo de trabajo, automatizando la
Secuencia de acciones, actividades o tareas utilizadas para la ejecucin del proceso de
solicitud y autorizaciones, el medio de comunicacin automatizado con la aplicacin
Web ser va correo electrnico donde permitir a los actores atenderse en el breve
plazo a un requerimiento o dar respuesta a una solicitud.
En un servidor de datos se efectuar el almacenamiento de las solicitudes y
personal autorizado para la gestin en el proceso, esto permitir efectuar consultas de
los estados de los requerimientos, reparticiones Solicitantes, ingresos, modificaciones y
eliminacin de personal involucrado.
Mediante una asignacin password permitir dar los niveles de acceso
correspondiente a cada funcionario.
Finalmente este proyecto dar solucin total en la habilitacin, control y manejo
de los diferentes puertos en aplicaciones Web utilizados en la Institucin.


Bibliografa


Revistas, boletines y papers:

- Gua para el desarrollo de aplicaciones WEB basada industria de software
MoProSoft.

- Durn, S. E. 2003, Puntos por Funcin. Una mtrica estndar para establecer el
tamao del software

Libros:

- Baca, Gabriel Urbina 2004, Formulacin evaluacin de proyecto 4ta edicin.
- Baca, Gabriel Urbina Formulacin evaluacin de proyecto 5ta edicin.
- Roger S. Pressman - Ingeniera del Software; un enfoque prctico. V Edicin
- Roger S. Pressman - Ingeniera del Software; un enfoque prctico. VI Edicin
- Gua de losFundamentos de la Direccin de ProyectosTercera Edicin (Gua
del PMBOK)
- Gua de losFundamentos de la Direccin de Proyectos Quinta Edicin (Gua
del PMBOK)
- UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)


Anexos


Anexo A

Base Datos
Para efectuar las pruebas descritas en el punto anterior se debi poblar la base
de datos objeto ir obteniendo los resultados en las pruebas de integracin del sistema.

Tabla Personal Usuario


Tabla Reparticin



Anexo B
Pruebas de aceptacin























Anexo C
Registro de Pruebas locales
Prueba Incremento 1
Conforme
Si / No
Observaciones
1.- Mdulo Login
Ingresar Rut existente en BB.DD. con password existente en
BB.DD.
Si

Ingresar Rut no existente en BB.DD. con password existente
en BB.DD.
Si

Ingresar Rut existente sin puntos sin guion con password
existente en BB.DD.
Si

Ingresar Rut existente sin puntos con guion con password
existente en BB.DD.
Si

Ingresar Rut existente con puntos sin guion con password
existente en BB.DD.
Si

Ingresar Rut existente con puntos con guion con password
existente en BB.DD.
Si

Solo ingresar password existente en BB.DD. Si
Solo ingresar Rut existente en BB.DD. Si
2.- Mdulo Solicitante
Se enva solicitud con falta de llenar 1 o ms campos. No
Se enva solicitud con todos los campos llenados. Si
Revisin de datos en BB.DD. Si
Los nmeros de solicitud son correlativos. Si
Se genera el mail de informacin de efectuada la solicitud. Si


Prueba Incremento 2
Conforme
Si / No
Observaciones
3.- Interfaz Nivel de Usuario
Al selectar Solicitante lo direcciona a este mdulo. Si
Al selectar Jefe Departamento lo direcciona a este mdulo. Si
4.- Mdulo Jefe Departamento
Revisin de datos en BB.DD. Si
Visa en forma correcta Si
Al selectar No Visada no pasa al mdulo Administrador Si
Se genera el mail de informacin de visada la solicitud. Si
Informa accin efectuada al visar o rechazar la solicitud Si

Prueba Incremento 3 / 4
Conforme
Si / No
Observaciones
5.- Mdulo Administrador
Al ingresar al mdulo despliega grilla con solicitudes visadas. Si
Al ingresar seleccionar fila de solicitud esta se marca Si
Al presionar mostrar esta muestra detalles de la solicitud. Si
Al selectar Rechazada y luego guardar esta produce proceso
inverso hacia el Jefe Departamento y Solicitante.
Si

Al selectar Autorizada y luego guardar esta continua con flujo de
trabajo.
Si

El campo observaciones es opcional para llenar. Si
El botn volver vuelve a grilla de solicitudes. Si
Al selectar Autorizada y luego guardar esta genera mail
informante al Operador.
Si

Al selectar pestaa consulta en grilla de inicio del Administrador,
aparece nueva ventana con esta seleccin.
Si


En interfaz Consulta, funciona filtro de bsqueda por Reparticin. Si
En interfaz Consulta, funciona filtro de bsqueda por estado Si
Al selectar pestaa usuario en grilla de inicio del Administrador,
aparece nueva ventana con esta seleccin.
Si

En interfaz usuario funciona filtro de bsqueda por Nombre. Si
En interfaz usuario funciona filtro de bsqueda por Apellido. Si
En interfaz usuario al selectar modificar, se pueden modificar
datos de un usuario.
Si

En interfaz usuario al selectar eliminar, se pueden eliminar datos
o un usuario.
Si
Se debe crear
estado usuario.
(Mejora del
sistema)
En interfaz usuario al selectar insertar, se pueden insertar nuevos
usuario.
Si

Prueba Incremento 4
Conforme
Si / No
Observaciones
5.- Mdulo Operador Red WAN.
Al ingresar a este mdulo aparece grilla con solicitudes
Autorizadas.
Si

Al presionar botn detallar muestra datos de solicitud
selectada.
Si

En esta ventana, al presionar botn efectuado, contina el
flujo de trabajo.
Si

En esta ventana, al presionar botn efectuado, se genera
mail a Solicitante y Jefe Departamento.
Si

Al presionar botn volver, vuelve a pgina principal del
Mdulo del Operador.
Si


Prueba
Conforme
Si / No
Observaciones
6.- Otros
En los diferentes mdulos aparece el nombre de la persona
una vez ingresada con su password y Rut.
Si

Durante el flujo de trabajo se produjeron excepciones. Si
En la integracin,
al no desarrollar el
mdulo siguiente.
Durante el flujo de trabajo se cay el sistema. Si
Debido a falta de
validacin de datos.
En los diferentes Mdulos el botn salir realmente lo extrae
de la aplicacin.
Si


Anexo D
Definiciones, Acrnimos y Abreviatura

Palabra Descripcin
DIRECTELINF
Direccin de Telecomunicaciones e Informtica de la Armada de
Chile.
Reparticin Edificio o Instalaciones Terrestres de la Armada.
Direccin Tcnica Organizacin a cargo de un rea en especfica de la Armada.
Mensaje Documento oficial de la Institucin.
Jefe Turno oficina de
mensajera
Oficina Distribuidora de Mensajes y Documentacin.
Flujo de trabajo
Flujos de trabajo, automatizacin de Secuencia de acciones,
actividades o tareas.
SQA Software Quality Assurance


Anexo E
Prototipo

El usuario hace ingreso a travs de su Rut y Password, posteriormente se abre
la interfaz de requerimiento donde aparecen los datos del Solicitante y Jefe
Departamento con su respectivo Mail para ser enviada la solicitud al presionar el botn
Solicitar.

El Jefe una vez recibido la informacin de requerimiento por mail, deber
ingresar a la aplicacin con su Rut y Password, el cual podr abrir la interfaz de
Autorizacin donde aparece la solicitud pendiente, se podr rechazar o autorizar
enviando mail al usuario o al Administrador de red WAN respectivamente segn sea el
caso.


Para el caso de rechazo solo se enviar la observacin por mail con la
observacin respectiva.

El Administrador se informa a travs de mail los requerimientos pendientes, por
tanto ingresa a la interfaz de autorizacin con su Rut y password, la ventana tiene dos
botones uno de Solicitudes el cual se puede apreciar el global de solicitudes pendiente,
cada una solicitud se pueden detallar con el fin de autorizar o rechazar, en el caso que
sea rechazada se observar el motivo y se enviara al usuario Solicitante.


El segundo botn de Consulta abre la ventana objeto buscar informacin
dependiendo el dato ingresado por el cual se quiere consultar.


El Operador red WAN se informa a travs de mail los requerimientos
pendientes, por tanto ingresa a la interfaz de autorizacin con su Rut y password, se
abre la ventana de ejecucin el cual se detallan todos los requerimientos.


Con el botn de detalle visualiza los datos correspondientes y una vez
efectuada la accin de Habilitacin del puerto; presionando el botn Efectuado se
almacenan los datos en la BB.DD y se enva un mail al usuario respectivo informando
su Requerimiento Efectuado Conforme


Anexo F
ACTA DE REUNION N1
Propsito de la reunin: Determinacin de los Objetivos, definicin del problema.
Lugar: DIRECTELINF
Fecha: 04/07/2012
ASISTENTES CARGO/EMPRESA
Sergio Orellana J. Jefe Proyecto
Mario Virot J. Diseador
Gabriel Reyes Sanhueza. Jefe Red WAN Armada,
DIRECTELINF.
DETALLE DE LO ACORDADO
- De acuerdo a los antecedentes entregados por el cliente se analizaron las causante dando
como resultado la definicion de la problemtica, el cual fue informada al cliente.
Tiempo excesivo e inexistencia estadistica en solicitudes y respuesta a los
requerimientos de habilitacion de puertos a IPs de una aplicacin de servidor.
- Determinacin de los objetivos generados por el cliente:
- Eliminar la utilizacin del documento escrito.
- Informar va correo electrnico, cuando se tome alguna accin en proceso de
habilitacin.
- Crear una base datos el cual permita el control de todos los requerimientos
efectuados.
- Validar el requerimiento, mediante flujo de trabajo, dependiendo del cargo que ostenta.


OBSERVACIONES
- Se confeccionar prototipo al cliente para afinar la idea del producto.
De acuerdo a los terminos acordado, toma conocimiento
Jefe de Proyecto Sergio Orellana J.
Diseador Mario Virot J.
Jefe Red WAN
Armada
Gabriel Sanhueza R.


ACTA DE REUNION N2
Propsito de la reunin: Detallar Incremento 1.
Lugar: DIRECTELINF
Fecha: 23/07/2012
Mario Virot J. Anaiista / Diseador
Victor Sanhueza R. Jefe Red WAN Armada, DIRECTELINF.
- Toma de Requerimientos, Mdulo Login, Solicitante y base de datos.
- Definicin diseo Incremento 1.
- Se estable plan de pruebas locales e integracin de los diferentes mdulos.
- Entrega Prototipo Inicial
OBSERVACIONES
- Protocolo de pruebas se entregar al trmino del Incremento 1.
- Pruebas dinmica se considerar por un tiempo de 15 das posterior a la implantacin.

- Base Datos:
- No contempla datos histricos efectuados en forma manual.
- Poblacion de los diferentes perfiles reales, ser efectuada por el cliente.
- Nombre de reparticiones y direcciones tecnicas de la organiizacion ser provistas por el
cliente.
De acuerdo a los terminos acordado, toma conocimiento
Jefe de Proyecto
Sergio Orellana J.

Anaiista / Diseador
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N3
Propsito de la reunin: Entrega Incremento N1
Lugar: DIRECTELINF
Fecha: 10/09/2012
Mario Virot J. Tester
Gabriel Reyes Sanhueza. Jefe Red WAN Armada, DIRECTELINF.
- Entrega Incremento N1
- Se efectua pruebas locales e integracin al mdulo del Login y Solicitante.
- Definicin de Observaciones al Incremento.
OBSERVACIONE
- Queda pendiente pruebas de integracin con mdulo del Jefe de deparatamento hasta su
desarrollo.
- Observaciones al Incremento:
- Restablecer contrasea.
- Cambio de clave asignada.
- Una vez analisadas las observaciones, se evaluar la factibilidad de corregir o gnerar una
mejora del proyecto.
De acuerdo a los trminos acordado, toma conocimiento
Jefe de Proyecto
Sergio Orellana J.

Tester
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N4
Propsito de la reunin: Detallar Incremento 2.
Lugar: DIRECTELINF
Fecha: 12/09/2012
- Se present soluciones a observaciones presentadas en pruebas Incremento 1.
- Entrega de Prototipo Final, de acuedo a instrucciones del cliente.
- Ajuste de Requerimientos, a Mdulo de Jefe de Departamento.
- Ajuste de Diagramas de Casos de Usos.
OBSERVACIONES
- Observacin presentada en el Incremento 1, relacionada al cambio de clave asignada en forma
automatica, quedar como mejor del proyecto en una futura actualizacin de la aplicacin.

- De los ajustes a los requerimientos del mdulo a desarrollar, el cliente solicit que los Jefes de
Departamento puedan generar solicitud, por tanto deber poseer dualidad de perfil, para acceder esto se
defini el desarrollo de una nueva interfaz el cual permitir el ingreso a los mdulos Solicitante y Jefe de
Departamento.

- Se efecta prueba de integracin con mdulo del Solicitante, pendiente del Incremento 1.
Jefe de Proyecto
Sergio Orellana J.

Anaiista / Diseador
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N5
Lugar: DiRECTELINF
Fecha: 23/10/2012
Gabriel Reyes Sanhueza . Jefe Red WAN Armada, DIRECTELINF.
- Se efectua pruebas locales e integracin al Jefe de Departamento.
OBSERVACIONES
- Indicar nmero de solicitud
- Paginacin de grilla
- Queda pendiente pruebas de integracin con mdulo del Administrador hasta su desarrollo.

Jefe de Proyecto
Sergio Orellana J.

Tester
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N6
Propsito de la reunin: Detallar Incremento 3
Lugar: DiRECTELINF
Fecha: 25/10/2012
- Ajuste de Requerimientos al mdulo del Administrador
OBSERVACIONES
- En la observaciones al Incremento 2 se incorporo la paginacion de las grillas y numeracion de
la solicitud para el seguimiento.
- Debido a la magnitud del mdulo del Administrador, se debi dividir el desarrollo por las
interfaces que lo componen, en esta etapa se desarrollar la interfaz de solicitudes y consulta,
quedando pendiente para el Incremento 4 la interfaz de usuarios.
Jefe de Proyecto
Sergio Orellana J.

Anaiista / Diseador
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N7
Lugar: DiRECTELINF
Fecha: 03/12/2012
- Se efectua pruebas locales e integracin al Mdulo del Administrador hasta las interfaz de
solicitud y consulta.
OBSERVACIONES
- No existe un estado el cual se deba deshabilitar una solicitud una vez que expire la fecha de
autorizacin de habilitacin.
- En la interfaz de consulta por reparticin de destino no se puede verificar el estado de todas las
solicitudes.
- Se efecta prueba de integracin con mdulo del Jefe de Departamento, quedando pendiente la
integracin con el Mdulo del Operador.
Jefe de Proyecto
Sergio Orellana J.

Tester
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N8
Propsito de la reunin:
Detallar Incremento 4
Lugar:
DiRECTELINF
Fecha: 06/12/2012
- Ajuste de Requerimientos interfaz de usuario mdulo Administrador y mdulo Operador
OBSERVACIONES
En la observaciones al Incremento 3
- se debi crear un estado de expirada y objeto deshabilitar aquellos puertos que se encuentren
fuera del plazo solicitado.

- Adicionar condicin de todas en la interfaz de consulta, con el fin de ver todos los estados de las
solicitudes en una reparticin.

Jefe de Proyecto
Sergio Orellana J.

Anaiista / Diseador
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


ACTA DE REUNION N9
Lugar: DiRECTELINF
Fecha: 03/12/2012
- Se efectua pruebas locales e integracin del sistema completo.
- Definicin de Observaciones al Incremento:
- Permitir la Autocompletacin del campo, de acuerdo a los registro.
- Los usuarios no se pueden eliminar debido a que existe una solicitud asignada al RUT.

OBSERVACIONES
Observaciones al Incremento:
- Se efectu la correccin en forma inmediata, respecto a la Autocompletacin del registro, sin
embargo la eliminacin de los usuarios con solitud asignada al RUT se considerar como mejora
del sistema, asignando un estado a cada perfil de la aplicacin como solucin.
Jefe de Proyecto
Sergio Orellana J.

Tester
Mario Virot J.

Jefe Red WAN Armada
Gabriel Sanhueza R.


Priyecto

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Priyecto

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD ANDRES BELLO

Das könnte Ihnen auch gefallen