Ejemplo de Tesis XP

INSTITUTO SUPERIOR DEL MINISTERIO DEL INTERIOR
ELISEO REYES RODRÍGUEZ – “CAPITÁN SAN LUIS”
Facultad # 3 Informática
FILIAL UNIVERSITARIA PROVINCIAL DEL MININT

“COMANDANTE LUIS ARTEMIO CARBÓ RICARDO”
SISTEMA INFORMÁTICO PARA LA GESTIÓN DE SERVICIOS DE TELEFONÍA FIJA DEL

DEPARTAMENTO DE TELECOMUNICACIONES EN LA DIRECCIÓN DE TECNOLOGÍAS
Y SISTEMAS
Trabajo de Diploma para optar por el título de Ingeniero en Informática
Autor: Tte. Omar Montero Alfaro

Dirección de Tecnologías y Sistemas
Tutoras Ing. Cap. Suahil Pérez Cabrera
: Dirección de Tecnologías y Sistemas
Ing. 1er Tte. Annia Mailyn Arrechea
Turro
Dirección de Tecnologías y Sistemas
La Habana, Cuba
2019
“La tecnología ha avanzado más en los últimos treinta años que en los últimos doscientos. El
avance exponencial sólo continuará.”
Niels Bohr.
Declaración de la auditoría
Declaro que soy el único autor del “Sistema informático para la gestión de servicios de telefonía
fija del Departamento de Telecomunicaciones en la Dirección de Tecnologías y Sistemas” y
autorizo al Minint para que haga el uso que estime pertinente de la investigación desarrollada.
Para que así conste firmo la presente a los 23 días del mes de junio del 2019.
_______________________ ______________________
Tutora: Cap. Ing. Suahil Pérez Autor: Tte. Omar Montero Alfaro
________________________
Tutora: Tte. Ing. Annia Mailyn Arrechea Turro

Agradecimientos
Agradezco de todo corazón a las personas que me brindaron apoyo y ayuda incondicional para
mi investigación, a mi familia que confió plenamente en mí, en especial a mi madre por
exigirme cada día metas mayores.
A mis tutoras y oponente por su tiempo y dedicación, en especial a mi tutora Suahil Pérez
Cabrera por haberme brindado la oportunidad de recurrir a su capacidad y conocimiento
científico, así como también haber tenido toda la paciencia del mundo para guiarme durante
todo el desarrollo de la tesis.
A Raúl Denis López por la preocupación sobre mi desempeño académico a lo largo de la

carrera y por dedicarme su valioso tiempo repasándome y brindándome sus conocimientos.
A mi pareja Maricelys Palacio López por apoyarme y creer en mí en todos los momentos de la
realización de este trabajo de diploma.
A mi jefa Martha Piñera Delgado por darme animo cuando más lo necesitaba y por su
preocupación.
A Mónica María Cuellar Céspedes por ayudarme a la hora de la confección de este documento.
A todos los que compartieron mi vida estudiantil en la universidad, a mis compañeros de aula
que nunca olvidaré ya que cada uno forma parte de mí.
A los profesores que dedicaron horas y días de atención. Gracias por su tiempo y
conocimiento.
Por lo pronto, por medio de esta página y temiendo que se me quede alguien, extiendo a todos
mi más sincera gratitud.
1
Dedicatoria
Dedico mi Trabajo de Diploma a mi madre María Victoria Alfaro Amigó, de manera

especial por brindarme su apoyo incondicional en todo momento para que
mis sueños se hicieran realidad, por enseñarme el camino a seguir y servirme
de guía con su ejemplo, por ser mi eterna compañera y amiga.
2
Resumen:
Actualmente el Ministerio del Interior (MININT), cuenta con la necesidad de adquirir y

brindar varios servicios referentes a la telefonía fija. Estos servicios garantizan las
comunicaciones entre las entidades militares y no militares. La implementación,
soporte y mantenimiento de estos servicios recae sobre la Dirección de Tecnologías y
Sistemas (DTS) que delega esta función al Departamento de Telecomunicaciones
(DTEL) como rector de esta actividad.
En la actualidad las solicitudes de estos servicios llegan, en disimiles formatos, a un

solo especialista de telefonía fija, luego se requiere la autorización del jefe del DTEL;
una vez aprobada, el especialista la procesa y encamina hacia las unidades ejecutoras
para su solución. Los jefes constantemente exigen datos estadísticos referentes a la
información registrada sobre las solicitudes, para facilitar la futura toma de decisiones.
Dado el incremento en cuanto a la petición de servicios y un grupo de problemáticas
que serán expuestas posteriormente en este documento, resulta necesario contar con
un sistema informático que facilite la gestión de solicitudes de estos servicios en el
DTEL. Para esto utilizaremos el lenguaje PHP y bases de datos en MySQL.
Palabras claves: Dirección de Tecnologías y Sistemas Departamento de

Telecomunicaciones, Gestión de solicitudes.
3
Abstract:
Currently the Ministry of the Interior (MININT), has the need to acquire and provide
various services related to fixed telephony. These services guarantee communications
between military and non-military entities. The implementation, support and
maintenance of these services falls on the Department of Technologies and Systems
(DTS), which delegates this function to the Telecommunications Department (DTEL) as
rector of this activity.
At present the requests for these services arrive, in dissimilar formats, to a single
specialist of fixed telephony, then the authorization of the head of the DTEL is required;
Once approved, the specialist processes it and directs it to the executing units for its
solution. Bosses constantly demand statistical data regarding recorded information
about applications, to facilitate future decision making. Given the increase in the
request for services and a group of problems that will be exposed later in this
document, it is necessary to have a computer system that facilitates the management of
requests for these services in the DTEL. For this we will use the PHP language and
databases in MySQL.
Keywords: Technology and Systems Department, Telecommunications Department,

Application Management.
4
Índice General
Capítulo 2 Análisis y diseño de la solución 8
1 8
2 8
3.1 Introducción 8
3.2 Breve descripción del sistema 8
3.3 Personal relacionado con el sistema 8
3.4 Captura de Requisitos 9
2.4.1 Requisitos no Funcionales 9
3.5 Historias de usuario 12
3.6 Estimación de esfuerzo por historias de usuarios 14
3.7 Plan de iteraciones 15
3.8 Plan de duración de las iteraciones 16
3.9 Plan de entrega por iteraciones 17
3.10 Modelo Físico de datos 18
3.11 Diagrama de despliegue 19
3.12 Conclusiones parciales 20
Capítulo 3 Implementación y prueba 21
3.1 Introducción 21
3.2 Patrón arquitectónico 21
2.2.1 La capa del Modelo 21
2.2.2 La capa de la Vista 22
2.2.3 La capa del Controlador 22
3.3 Diseño 23
3.4 Diagrama de diseño 23
3.5 Patrón de diseño 23

5
2.5.1 Patrones GRASP 23
3.6 Tarjetas Clase, Responsabilidad y Colaboración (CRC) 24
3.7 Tareas de ingeniería por Historias de usuario(HU)27
3.8 Pruebas de aceptación 29
Conclusiones Generales 33
Referencias bibliográficas 34
Bibliografía 35
Anexo 1 37
Anexo 2 46
INTRODUCCIÓN 1
Capítulo 1 Fundamentos teóricos 6
1.1 Introducción 6
1.2 Objetivos Estratégicos de la Organización 6
1.2.1 Flujo actual de los procesos 7
1.3 Análisis crítico de la ejecución de los procesos 7
1.4 Proceso de objeto de automatización7
1.5 Sistemas Automatizados existentes vinculados al campo de acción 8
1.5.1 Sistemas Internacionales 8
1.5.2 Sistemas Nacionales 9
1.6 Fundamentación de los objetivos 9
1.7 Tendencias y tecnologías actuales 9
1.7.1 Metodologías de Desarrollo 10
1.7.2 Comparación entre metodologías Ágiles y Metodologías Tradicionales

10
1.7.3 Selección del tipo de metodología de desarrollo a utilizar 10
1.8 Metodologías Ágiles de desarrollo 11

6
1.8.1 Programación Extrema (XP) 11
1.8.1 SCRUM 12
1.8.2 Selección de la Metodología de Desarrollo a utilizar 12
1.9 Fundamentación del Lenguaje de Modelado 12
1.9.1 Lenguaje de Modelado Unificado (UML) 12
1.9.2 Modelo de Notación del Proceso de Negocio (BPMN) 13
1.9.3 Selección del Lenguaje de Modelado 13
1.9.4 Fundamentación de la Herramienta CASE 13
1.9.5 Visual Parading 14
1.9.6 Rational Rose 15
1.9.7 Selección de la Herramienta CASE 16
1.10 Fundamentación del Lenguaje de programación 17
1.10.1 PHP 17
1.10.2 Lenguaje Python 17
1.10.3 ASP 18
1.10.4 ASP.NET 18
1.10.5 Selección del Lenguaje de programación 19
1.11 Fundamentación del Framework de desarrollo 19
1.11.1 CakePHP 20
1.11.2 Codeigniter 20
1.11.3 Yii 20
1.11.4 Symfony 21
1.11.5 Selección de Framework de desarrollo 21
1.12 Fundamentación del sistema de Gestor de Base de Datos 22
1.12.1 MySQL 22
1.12.2 Oracle 22
7
1.12.3 PostgreSQL 22
1.12.4 Selección del Sistema Gestor de Base de Datos 23
1.13 Fundamentación de los Servidores Web 23
1.13.1 Apache 23
1.13.2 Internet Information Server(IIS)24
1.13.3 Selección del Servidor Web 25
1.14 Análisis crítico de las fuentes y bibliografías utilizadas 25
1.15 Conclusiones Parciales 25
2 Capítulo 2 Análisis y diseño de la solución 27
2.2 Breve descripción del sistema 27
2.3 Personal relacionado con el sistema 27
2.4 Captura de Requisitos 28
2.4.1 Requisitos Funcionales 28
2.4.2 Requisitos no Funcionales 31
2.5 Historias de usuario 34
2.6 Estimación de esfuerzo por historias de usuarios 36
2.7 Plan de iteraciones 37
2.8 Plan de duración de las iteraciones 38
2.9 Plan de entrega por iteraciones 39
2.10 Diseño de Base de datos 40
2.11 Diagrama de despliegue 41
3 Capítulo 3 Implementación y prueba 43
3.2 Patrón arquitectónico 43

8
3.2.1 La capa del Modelo 43
3.2.2 La capa de la Vista 44
3.2.3 La capa del Controlador 44
3.3 Diseño 45
3.4 Diagrama de diseño 45
3.5 Patrón de diseño 45
3.5.1 Patrones GRASP 45
3.6 Tarjetas Clase, Responsabilidad y Colaboración (CRC) 46
3.7 Tareas de ingeniería por Historias de usuario(HU)48
3.8 Pruebas de aceptación 50
Referencias bibliográficas 53
Bibliografía 54
Anexo 1 55
Anexo 2 62
Índice de Tablas
Tabla 1: Niveles de acceso al sistema........................................................................26

Tabla 2: HU Gestionar unidad organizativa................................................................30
Tabla 3: HU Gestionar solicitudes de servicios.........................................................31
Tabla 4: HU gestionar cartera de inmediatez de servicio .........................................31
Tabla 5: HU Gestionar cartera de servicios suplementarios....................................32
Tabla 6: Estimación de esfuerzo por historias de usuarios.....................................32
Tabla 7: Plan de iteraciones.........................................................................................33
Tabla 8: Plan de duración de las iteraciones.............................................................34
Tabla 9: Plan de entrega...............................................................................................35
Tabla 10: Tarjeta CRC SolicitudesController.............................................................43
Tabla 11: Tarjeta CRC ClientesController...................................................................44
Tabla 12: Tarjeta CRC EventualesController..............................................................44
Tabla 13: Iteraciones y tareas correspondientes a cada historia de usuario .........45
Tabla 14: Caso de prueba, Gestionar Solicitudes de Servicios ...............................48
Tabla 15: Caso de prueba, Gestionar Clientes..........................................................48
Tabla 16: Caso de prueba, Gestionar unidad organizativa ......................................49
Tabla 17: HU Gestionar cantera de servicios.............................................................55
Tabla 18: HU Gestionar cuenta bancaria....................................................................55
9
Tabla 19: HU Gestionar notificaciones y alarmas.....................................................56

Tabla 20: HU Gestionar clientes..................................................................................56
Tabla 21: HU Gestionar usuarios.................................................................................57
Tabla 22: HU Cuenta de usuario..................................................................................57
Tabla 23: HU Asociar clientes a usuarios...................................................................58
Tabla 24: HU Gestionar roles.......................................................................................58
Tabla 25: HU Gestionar permisos................................................................................59
Tabla 26: HU Gestionar permisos por roles...............................................................59
Tabla 27: HU Autenticar usuario..................................................................................60
Tabla 28: HU Cambiar contraseña...............................................................................60
Tabla 29: HU Mostrar trazas.........................................................................................61
Tabla 30: HU Salva y restauración del sistema.........................................................61
Tabla 31: HU Reportes..................................................................................................62
Tabla 32: Tarjeta CRC DashboardsController............................................................63
Tabla 33: Tarjeta CRC InmediateserviciosController ................................................63
Tabla 34: Tarjeta CRC PagesController......................................................................64
Tabla 35: Tarjeta CRC SecurityAppController...........................................................64
Tabla 36: Tarjeta CRC ServiciosController.................................................................64
Tabla 37: Tarjeta CRC ServiciosSolicitudesController .............................................65
Tabla 38: Tarjeta CRC ServiciosuplementariosController ........................................65
Tabla 39: Tarjeta CRC ServiciosuplementariosSolicitudesController ....................66
Tabla 40: Tarjeta CRC UosController..........................................................................66
Índice de Ilustraciones
10
Ilustración 1: Modelo de datos 37

Ilustración 2: Diagrama de despliegue. 38
Ilustración 3: El ciclo de una petición en CakePHP 41
INTRODUCCIÓN
La acelerada evolución de las tecnologías de la información (TI) y su impacto en

el ámbito profesional y cotidiano, ha hecho indispensable el uso de las mismas.
Un elemento importante en el desarrollo de cualquier país lo constituye la
gestión de la información, desempeñando las TI un papel fundamental en estos
procesos al permitir la rápida comunicación e intercambio.
Cuba, no ha quedado rezagada en los avances tecnológicos impulsados por el

desarrollo de las TI, siendo el Ministerio de Comunicaciones el órgano rector en
esta esfera. En lo concerniente al Ministerio del Interior (Minint), es de
competencia de la Dirección de Tecnologías y Sistemas (DTS) la
implementación, sostenimiento y desarrollo de las tecnologías de la informática
y las comunicaciones, siendo asumida esta última especialidad por el
Departamento de Telecomunicaciones (DTEL).
Una de las secciones de este Departamento, corresponde a Planeamiento y

Servicios, encargada de: Normar, gestionar y controlar los servicios de
telecomunicaciones nacionales e internacionales del Minint, estableciendo o
proponiendo su implementación en función de las prioridades y capacidades
existentes; dirigir la explotación de la infraestructura técnica, los soportes de
transmisión, la gestión de las redes de telecomunicaciones, sistemas de
radiocomunicaciones y red de pizarras telefónicas privadas; controlar y
dictaminar el empleo de los sistemas y recursos de la especialidad
estableciendo programas de modernización y expansión de los servicios, así
como adición, supresión o modificación de los índices de calidad para cumplir
los requerimientos del Minint en correspondencia con los parámetros
establecidos por el Mincom.
11
Dentro de esta sección, se encuentra la especialidad de telefonía fija, que brinda

servicios como teléfono automático o extensión Minint, con la modalidad de
eventual o permanente, donde además se asocian, de forma opcional, servicios
suplementarios.
Para solicitar los servicios antes mencionados, se realiza el proceso de atención

a las solicitudes, las cuales poseen una serie de limitaciones que dan lugar a
situaciones problemáticas:
No está definido un formato único para las solicitudes de los servicios.

Existe diversidad en los canales de recepción de la información, estos pueden
ser vía telefónica, solicitud digital o impresa.
El procesamiento de las solicitudes se realiza de forma manual.
El personal que intervienen en la ejecución de la solicitud se encuentra
geográficamente distante del Departamento.
La jefatura del departamento no cuenta con un acceso oportuno a la información.
No existe una retroalimentación, por parte del área ejecutora, cuando finaliza la
ejecución de la solicitud.
El registro histórico de estas solicitudes debido a la diversidad de formatos de
entrega no se encuentra centralizada.
Atendiendo a las problemáticas antes expuestas, se evidencia la dificultad para

recopilar, gestionar y controlar las solicitudes recibidas, lo cual resulta en el
problema a resolver: ¿Cómo mejorar la gestión de solicitudes de servicios de
telefonía fija en el DTEL?, partiendo del objeto de estudio: proceso de gestión de
las solicitudes de servicios de telecomunicaciones, y del campo de acción:
gestión de solicitudes de servicios de telefonía fija en el DTEL.
Para la solución de dicho problema se plantea como objetivo general:

desarrollar un sistema informático para mejorar la gestión de solicitudes de
servicios de telefonía fija en el DTEL. Además, se proyectan los objetivos
específicos y sus tareas correspondientes:
Analizar lo referentes teóricos que sustentan la gestión de las solicitudes de

servicios de telecomunicaciones.
12
Analizar los procesos de negocio de la entidad.

Realizar el análisis de las herramientas, lenguajes y tecnologías actuales
vinculadas al campo de acción.
Diseñar el sistema para la gestión de solicitudes de telefonía fija en DTEL.
Realizar el levantamiento de requisitos funcionales y no funcionales.
Documentar las historias de usuarios.
Elaborar el diagrama de despliegue.
Implementar las funcionalidades del sistema de gestión de solicitudes de
telefonía fija
Elaborar las tarjetas CRC.
Elaborar las tarjetas de ingeniería por historias de usuarios
Realizar un juego de datos que permita la evaluación el sistema.
Por lo que se plantea como idea a defender: Con el desarrollo de un sistema

informático se mejora la gestión de solicitudes de servicios de telefonía fija en el
DTEL.
El principal valor práctico de esta aplicación es que facilitará el trabajo de

administración y análisis de las solicitudes de servicios en la sección de
Telefonía fija del DTEL de la Dirección de Tecnologías y Sistemas, a través de
una forma más rápida y sencilla de gestionar la información referente a las
solicitudes.
Esta aplicación garantiza la existencia de un mecanismo eficiente para la

retroalimentación de información con los jefes y especialistas que la soliciten,
una plataforma para publicar información de interés sobre las solicitudes a los
usuarios finales y la posibilidad de buscar de forma instantánea una mayor
cantidad de información a analizar para facilitar la toma de decisiones. La
información no se deteriorará, ni se perderá con salvas eventuales.
Para desarrollar la investigación, se utilizaron varias modalidades de métodos

científicos incluidos en las clasificaciones de los Teóricos (o lógicos) y los
Empíricos. Permitiendo de forma organizada, sistemática de estudiar el mundo
13
circundante para llegar al conocimiento y comprensión de los objetos,

fenómenos y procesos que lo constituyen.
Métodos teóricos:
Histórico–Lógico: Para realizar un estudio histórico sobre otros sistemas

informáticos y herramientas utilizadas, alcanzando un mayor incremento del
conocimiento de las herramientas y tecnologías a utilizar, para poder
aplicarlo en la solución del problema científico de la investigación.
Inductivo-Deductivo: Para desarrollar el planteamiento del objetivo general, la

idea a defender.
Analítico – sintético: Para analizar toda la información relacionada con el

estudio de las diferentes herramientas y conceptos asociados al trabajo, que
permitan plasmar, de manera sintetizada, los elementos fundamentales de la
investigación.
Métodos empíricos:
Análisis del documento: Para realizar un estudio de documentos referentes al

diseño e implementación de la solución informática.
Criterios de especialistas: Para obtener diversos juicios que permitan guiar la

investigación por el camino correcto.
Entrevista: Para realizar entrevistas a los especialistas que permitan

comprender los nuevos requerimientos funcionales y no funcionales, así
14
como el levantamiento de las no conformidades.
El presente documento está estructurado en tres capítulos, los cuales abarcan

desde la investigación inicial hasta la propuesta de solución al
problema planteado.
En el Capítulo 1: Fundamentos teóricos, se comprende una descripción general

del objeto de estudio y del flujo actual de los procesos vinculados a la gestión de
solicitudes de servicio, así como un análisis crítico de cómo se ejecutan
actualmente esos procesos, los problemas que presentan y sus consecuencias.
Se determinan cuáles son los procesos que serán objeto de informatización, de
los cuales se brinda una breve descripción. Se dan a conocer los softwares
existentes vinculados al campo de acción. Se describen las tendencias y
tecnologías actuales sobre las que se apoya la propuesta presentada en el
presente trabajo.
En el Capítulo 2: Análisis y diseño de la solución. Se realiza una propuesta de

solución del sistema a realizar, se describe cómo debe funcionar y se destacan
sus características distintivas. Se describen además el análisis y diseño del
sistema donde se especifican los principales artefactos que se generan según la
metodología de desarrollo a utilizar.
En el Capítulo 3: Implementación y prueba. Se define el tipo de codificación y

estándares que se utilizará en el código de la aplicación. Se implementarán las
funcionalidades previstas, así como se les realizarán pruebas de aceptación a la
aplicación.
15
Capítulo 1 Fundamentos teóricos
Introducción
En este capítulo se muestra una explicación detallada de los principales

elementos teóricos que sustentan la investigación y el desarrollo del Sistema
para la gestión de solicitudes de Servicios de Telefonía Fija del DTEL en la
Dirección de Tecnologías y Sistemas.
Objetivos Estratégicos de la Organización
La DTS, como dirección impulsora de las tecnologías en el Minint, posee entre

sus departamentos el DTEL, donde una de sus secciones es la de Planeamiento
y Servicios. Entre sus funciones principales podemos mencionar:
Establecer, regular y controlar los programas de calidad, modernización y

expansión de los servicios. Introducir, eliminar o modificar los índices de calidad
para cumplir los requerimientos del Minint en correspondencia con los
parámetros establecidos por el Mincom, para evaluar y verificar su cumplimiento.
Normar, gestionar y controlar los servicios de telecomunicaciones nacionales e

internacionales del Minint. Proponer o establecer la implementación de estos
servicios en función de las prioridades.
Controlar y dictaminar el empleo y comportamiento de los sistemas y recursos

de la especialidad. Realizar análisis periódicos de la infraestructura y los
servicios de telecomunicaciones, elaborando las propuestas que permitan elevar
continuamente su eficiencia, vitalidad y disponibilidad.
Dirigir la explotación de la infraestructura técnica, los soportes de transmisión

por cable de cobre, fibra óptica, radioenlace e inalámbrica, la gestión de las
redes de telecomunicaciones, sistemas de radiocomunicaciones convencionales,
troncalizados y red de pizarras telefónicas privadas.[1]
16
Flujo actual de los procesos
El jefe de la DTS o las fuerzas designadas en el resto de los órganos y provincias del
Minint, pueden solicitar un nuevo servicio al DTEL. Esta solicitud es recibida por el
especialista de Telefonía fija en la sección de Planeamiento de Servicios mediante
correo electrónico, mensajería, llamada telefónica, o por decisión del propio jefe de la
DTS. Los solicitantes pueden escoger dos tipos de nuevos servicios: permanentes o
eventuales, pudiéndose en este último, pedir prórroga una vez finalizado su tiempo de
uso estipulado. Una vez recibida la solicitud, el especialista contacta con la Dirección
de Atención a Gobierno número 6 (DAG-6) para analizar niveles de disponibilidad de
servicio que permitan darle solución a la misma.
La solicitud se modifica dependiendo de la respuesta del área ejecutora dando a

conocer si existe disponibilidad o no. Para su aprobación, la solicitud se le entrega el
jefe del DTEL y una vez aprobada, se le entrega nuevamente al especialista, el cual
tramita con el área ejecutora la solución aprobada.
Análisis crítico de la ejecución de los procesos
Como resultado del estudio realizado, pudimos constatar que todos los procesos que
se llevan a cabo en el DTEL, con relación a las solicitudes de telefonía fija, presenta un
conjunto de deficiencias, tales como:
No está definido un formato único para las solicitudes de los servicios.

Existe diversidad en los canales de recepción de la información, estos pueden ser vía
telefónica, solicitud digital o impresa.
El procesamiento de las solicitudes se realiza de forma manual.
El personal que interviene en la ejecución de la solicitud se encuentra geográficamente
distante del departamento.
La jefatura del departamento no cuenta con un acceso oportuno a la información.
Proceso de objeto de automatización
La solución informática se encargará de la informatización de los procesos:

17
Creación y envió de las solicitudes
Validación de solicitudes
Aprobación de solicitudes
Ejecución de solicitudes
Cierre de las solicitudes
Sistemas Automatizados existentes vinculados al campo de acción
Dentro de los sistemas que se vinculan al campo se acción, existen un conjunto de

soluciones con implementaciones similares a la que se propone:
Sistemas Internacionales
Service desk de TI: El service desk de TI (tecnología de información) está diseñado

para ser el punto principal de interacción entre las organizaciones de TI y los usuarios.
De acuerdo a los principios de ITIL (Biblioteca de Infraestructura de Tecnologías de la

Información) según sus siglas en inglés, el service desk es el punto único de contacto
(SPOC, del inglés Single Point of Contact) entre el proveedor de servicio de TI y los
usuarios para las actividades diarias.
Un service desk típico gestiona incidentes (perturbaciones del servicio) y solicitudes de

servicio (tareas rutinarias relacionadas con los servicios), además de manejar las
comunicaciones con los usuarios para cosas tales como cortes y cambios planificados
en los servicios. Tiene un enfoque amplio y está diseñado para ofrecer al usuario un
único lugar al que acudir para todas sus necesidades de TI.
El resultado final es que el service desk desempeña un papel fundamental en facilitar la

integración de los procesos del negocio con el ecosistema tecnológico y la
infraestructura más amplia de gestión de servicios, además tiene como desventaja que
posee licencia no gratuita, dificultándole al Minint la adquisición de la misma por no
existir posibilidades ,ni mecanismos para efectuar el pago.[2]
18
El SoftExpert Solicitud: es un sistema enfocado en la gestión de solicitudes de

servicio. El software ofrece recursos proyectados para administrar el ciclo de vida
completo del pedido, desde su inicio a su fin. Además, ofrece controles de aprobación,
eficacia del servicio, análisis, encuestas e informes que permiten que los usuarios
tengan una visión general de todas las solicitudes.
La solución simplifica el trabajo en equipo a través de un mecanismo poderoso que

controla y notifica automáticamente vía e-mail a los individuos responsables por tareas.
Eso garantiza que los gestores y sus equipos tengan un control simple y eficaz sobre
sus objetivos y prioridades, optimizando el cumplimiento de plazos y resultados.
A través de un único banco de datos central que almacena todas las informaciones y
documentos, el SoftExpert Solicitud automatiza el ciclo de vida del pedido con base en
todas las demandas de servicio por diferentes departamentos de la empresa. De esta
forma, las tareas diarias concluidas por la organización son registradas y pueden ser
monitoreadas, además tiene como desventaja que posee licencia.[3]
Sistemas Nacionales
Etecsa utiliza un sistema para la gestión de solicitudes referente a la telefonía fija pero
el mismo es privado y confidencial.
Fundamentación de los objetivos
Es de gran interés para los desarrolladores estar actualizados sobre la evolución y

mejora de las diferentes tecnologías y herramientas que permiten el desarrollo de
soluciones informáticas, ya que de ello dependerá que el resultado final sea un
producto de calidad.
A continuación, se hace referencia a algunas tecnologías, herramientas y metodologías

de desarrollo de software que se puedan emplear para la elaboración de un sistema
informático para la gestión de solicitudes de servicios de telefonía fija del
Departamento de telecomunicaciones en la Dirección de Tecnologías y Sistemas.
Tendencias y tecnologías actuales

19
A la hora de desarrollar un software no se debe pasar por alto cómo se comporta la

actualidad tecnológica, por lo que se debe estar informado sobre el avance y el
surgimiento de nuevas tecnologías, así como llegar a dominar las ya existentes.
A continuación, se explican las herramientas y tecnologías que se utilizarán para

desarrollar el sistema para la gestión de solicitudes de telefonía fija, así como la
metodología utilizada en su desarrollo.
Metodologías de Desarrollo
Avison y Fitzgerald (1995) nos presentan una definición de las Metodologías de

desarrollo muy clara, destacando sus principales componentes, fases, herramientas y
técnicas. “Una metodología es una colección de procedimientos, técnicas,
herramientas y documentos auxiliares que ayudan a los desarrolladores de software en
sus esfuerzos por implementar nuevos sistemas de información. Una metodología está
formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarán a
los desarrolladores de sistemas a elegir las técnicas más apropiadas en cada momento
del proyecto y también a planificarlo, gestionarlo, controlarlo y evaluarlo”[4]
Comparación entre metodologías Ágiles y Metodologías Tradicionales
Las metodologías ágiles están basadas en heurísticas provenientes de prácticas de

producción de código, especialmente preparadas para cambios durante el proyecto. En
estas metodologías no existe contrato tradicional o al menos existe un contrato
prefijado, lo cual es bastante flexible. El cliente es parte del equipo de desarrollo y está
diseñada para grupos pequeños (<10 integrantes) trabajando en el mismo sitio con
pocos artefactos y pocos roles.
Las metodologías tradicionales están basadas en normas provenientes de

estándares seguidos por el entorno de desarrollo. Presenta cierta resistencia a los
cambios. Existe un contrato prefijado. El cliente interactúa con el equipo de desarrollo
mediante reuniones. Los equipos son grandes y posiblemente distribuidos. Presentan
más artefactos y más roles.[5]
Selección del tipo de metodología de desarrollo a utilizar

20
Se decidió utilizar la metodología ágil de desarrollo ya que están especialmente

indicada en proyectos con requisitos poco definidos o cambiantes.
Estas metodologías se aplican bien en equipos pequeños que resuelven problemas

concretos, lo que no está reñido con su aplicación en el desarrollo de grandes
sistemas, ya que una correcta modularización de los mismos es fundamental para su
exitosa implantación. Dividir el trabajo en módulos abordables minimiza los fallos y el
coste. Las metodologías ágiles presentan diversas ventajas, entre las que podemos
destacar:
Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo
Entrega continua y en plazos breves de software funcional
Trabajo conjunto entre el cliente y el equipo de desarrollo
Importancia de la simplicidad, eliminado el trabajo innecesario
Atención continua, a la excelencia técnica y al buen diseño
Mejora continua de los procesos y el equipo de desarrollo [5]
Al ser un trabajo que debe ser diseñado e implementado por una sola persona en
un tiempo corto es necesario desarrollarlo mediante una metodología ágil.
Metodologías Ágiles de desarrollo
Las metodologías ágiles constituyen un nuevo enfoque en el desarrollo de software.

Estas son mejor aceptadas por los desarrolladores que las metodologías
convencionales por la flexibilidad de sus reglas, su orientación a equipos de desarrollo
de pequeño tamaño, su adaptabilidad a los cambios y su idea de colaboración.[6]
1.8.1 Programación Extrema (XP)

21
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como

clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo,
preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima
de trabajo.
XP se basa en la retroalimentación continua cliente - equipo de desarrollo, propiciando

una comunicación fluida entre todos los participantes, así como simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. Esta metodología es
adecuada para proyectos con requisitos imprecisos y muy cambiantes donde existe un
alto riesgo técnico.
Los equipos de XP normalmente trabajan con iteraciones muy cortas (1 ó 2 semanas),

aceptan los cambios con más facilidad en sus iteraciones siempre y cuando el equipo
no haya empezado a trabajar en un requerimiento en particular, dando a lugar que un
nuevo requerimiento de un tamaño similar que puede ser cambiado por otro
equivalente en la iteración.
Los equipos de XP trabajan en un orden estricto, los requerimientos que serán

desarrollados son priorizados por el cliente y el equipo debe desarrollar los
requerimientos en ese orden específico. Exige buenas prácticas, particularmente en el
desarrollo basado en pruebas, diseño simple, entre otros. [7]
SCRUM
La metodología Scrum para el desarrollo ágil de software es un marco de trabajo

diseñado para lograr la colaboración eficaz de equipos en proyectos, que emplea un
conjunto de reglas y artefactos y define roles que generan la estructura necesaria para
su correcto funcionamiento.
22
Los equipos de Scrum normalmente trabajan en iteraciones (llamadas sprints) con una
duración de 2 semanas a un mes, no permiten cambios en sus sprints. Una vez que el
sprint planning meeting ha concluido y se llegó a una acuerdo para elegir los product
backlog items, estos no pueden recibir cambios, por lo menos hasta el final del sprint,
el product owner de Scrum prioriza los product backlog pero el equipo determina el
orden en el que serán desarrollados.[8]
Selección de la Metodología de Desarrollo a utilizar
Se decidió utilizar la metodología de desarrollo XP ya que es especialmente adecuada

para proyectos con requisitos imprecisos y muy cambiantes donde existe un alto
riesgo técnico, los equipos de desarrollos de esta metodología trabajan con
iteraciones muy cortas (1 o 2 semanas) y aceptan los cambios con más facilidad en
sus iteraciones. XP exige buenas prácticas, particularmente en el desarrollo basado
en pruebas, diseño simple, entre otros. En cambio, Scrum no es tan flexible a
cambios, las iteraciones son más largas, entre otras desventajas.
Fundamentación del Lenguaje de Modelado
El lenguaje de modelado de objetos es un conjunto estandarizado de símbolos y de

modos de disponerlos para modelar (parte de) un diseño de software orientado a
objetos.[9]
Lenguaje de Modelado Unificado (UML)
UML es un lenguaje de modelado unificado que brinda la tecnología para apoyar la

práctica de la ingeniería de software orientada a objetos, pero no da la estructura del
proceso que guíe a los equipos del proyecto cuando aplican la tecnología.
23
Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, estructura para la

ingeniería de software orientado a objetos que utiliza UML. Actualmente, el proceso
unificado (PU) y el UML se usan mucho en proyectos de toda clase orientados a
objetos. El modelo iterativo e incremental propuesto por el PU, puede y debe adaptarse
para que satisfaga necesidades específicas del proyecto.[10]
Modelo de Notación del Proceso de Negocio (BPMN)
El objetivo primario del lenguaje estándar BPMN fue proveer una notación que sea
legible y entendible para todos los usuarios de negocios, desde los analistas que
realizan el diseño inicial de los procesos a los responsables de desarrollar la tecnología
que ejecutará estos procesos. BPMN es una colección de elementos gráficos
especializados para representar un proceso y cómo es ejecutado. Los principales
elementos son: actividades (activities), eventos (event), puertas de enlace (gateway) y
flujo de secuencia (secuence flow).[11]
Selección del Lenguaje de Modelado
Se decidió utilizar el lenguaje de modelado UML ya que facilita a los desarrolladores la

especificación, visualización y documentación de modelos de sistemas de software.
Está dirigido en líneas generales a los arquitectos de software e ingenieros de
software.
UML aporta elementos valiosos como la identificación inmediata de las

responsabilidades de los trabajadores del negocio y el comportamiento dependiente
del estado de las entidades del negocio que en BPMN, si bien es posible, resulta
impráctico, sin embargo, BPMN y UML usan enfoques diferentes para modelarlos.
En general, este lenguaje, ofrece un enfoque orientado a objetos para modelar

aplicaciones, mientras que BPMN toma un enfoque centrado en los procesos.
Fundamentación de la Herramienta CASE

24
CASE(Computer Aided Software Engineering), conjunto de programas y ayudas que

dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos
los pasos del ciclo de vida de desarrollo de un software. Este puede ser generalmente
aplicado a cualquier sistema o colección de herramientas que ayudan a automatizar el
proceso de diseño y desarrollo de software.[12]
Visual Parading
Visual Parading es una de las herramientas UML CASE del mercado, considerada
como muy completa y fácil de usar, con soporte multiplataforma y que proporciona
facilidades de interoperabilidad con otras aplicaciones.
Fue creada para el ciclo vital del desarrollo de software que lo automatiza y acelera,
permitiendo la captura de requisitos, análisis, diseño e implementación. Tiene la
capacidad de crear el esquema de clases a partir de una base de datos y crear la
definición de base de datos a partir del esquema de las clases.
Esta herramienta permite invertir código fuente de programas, archivos ejecutables y

binarios en modelos UML al instante, creando de manera simple toda la
documentación. Está diseñada para usuarios interesados en sistemas de software de
gran escala con el uso del acercamiento orientado a objeto, además, apoya los
estándares más recientes de las notaciones de Java y de UML. Incorpora el soporte
para trabajo en equipo que permite que varios desarrolladores trabajen a la vez en el
mismo diagrama y vean en tiempo real los cambios hechos por sus compañeros.
Características
Producto de calidad
Soporta aplicaciones Web.
Varios idiomas.
Generación de código para Java y exportación como HTML.
Fácil de instalar y actualizar.

25
Compatibilidad entre ediciones.
Se integra con las siguientes herramientas Java:
Eclipse/IBM WebSphere.
Jbuilder.
NetBeans IDE.
Oracle Jdeveloper.
BEA Weblogic.
Ventajas
Apoya todo lo básico en cuanto a artefactos generados en las etapas de definición de

requerimientos y de especificación de componentes.
Tiene apoyo adicional en cuanto a generación de artefactos automáticamente.
Genera modelos VP-UML instantáneamente a partir de código binario .Net.
Generación de documentación en formatos HTML y PDF.
Disponibilidad en múltiples plataformas: Microsoft Windows (98, 2000, XP, o Vista),

Linux, Mac OS X, Solaris o Java.
Brinda la posibilidad de intercambiar información mediante la importación y exportación

de ficheros con aplicaciones, como, por ejemplo, Visio y Rational Rose.
Generación de código e ingeniería inversa: brinda la posibilidad de generar código a

partir de los diagramas, para las plataformas como .Net, Java y PHP, así como obtener
los diagramas a partir del código.
Generación de documentación: brinda la posibilidad de documentar todo el trabajo sin

necesidad de utilizar herramientas externas.
Desventajas
26
Las imágenes y reportes generados, no son de muy buena calidad.[12]
Rational Rose
Rational Rose Enterprise Edition. Es una herramienta CASE (Computer – Arded

Software Engineering), traducido al español como Ingeniería Asistida por
Computadora, desarrollada por Rational Corporation basada en el Lenguaje Unificado
de Modelación (UML), que permite crear los diagramas que se van generando durante
el proceso de Ingeniería en el Desarrollo del Software.[13]
Características principales:
Entre las características principales de Rational se pueden destacar:
Admite como notaciones: UML, OMT y Booch.
Permite el desarrollo multiusuario.
Genera documentación del sistema.
Disponible en múltiples plataformas.
Funciones:
Soporte a modelos de análisis, ANSI C++, RoseJ y Visual C++ según el documento
"Design Patterns: Elemts of Reusable Object – Oriented Software".
Los componentes del modelo se pueden controlar independientemente, lo que permite

una gestión y un uso de modelos más granular.
Soporte para compilación y descompilación de las construcciones más habituales de

Java 1.5.
Generación de código en lenguaje Ada, ANSI C++, C++, CORBA, Java y Visual Basic,
con funciones configurables de sincronización entre los modelos y el código.
Soporte para Enterprise Java Beans 2.0.

27
Funciones de análisis de calidad de código.
Complemento de modelado Web que incluye funciones de visualización, modelado y

herramientas para desarrollar aplicaciones Web.
Modelado en UML para diseñar bases de datos, que integra los requisitos de datos y
aplicaciones mediante diseños lógicos y analíticos.
Creación de definiciones de tipo de documentos DTD en XML.
Integración con otras herramientas de desarrollo de IBM Racional.
Integración con cualquier sistema de control de versiones compatibles con SSC, como
IBM Rational ClearCase.
Posibilidad de publicar en las Web modelos e informes para mejorar la comunicación

entre los miembros del equipo.[13]
Selección de la Herramienta CASE
Se decidió utilizar Visual Parading por ser un producto de calidad que soporta
aplicaciones Web, fácil de instalar y actualizar, compatibilidad entre ediciones, genera
documentos en formatos HTML y PDF, posee generación de código e ingeniería
inversa: brinda la posibilidad de generar código a partir de los diagramas para las
plataformas como .Net, Java y PHP, así como obtener los diagramas a partir del código
y la posibilidad de documentar todo el trabajo sin necesidad de utilizar herramientas
externas.
Fundamentación del Lenguaje de programación
Un lenguaje de programación es aquella estructura que, con una cierta base sintáctica
y semántica, imparte distintas instrucciones a un programa de computadora.[14]
PHP
28
Es un lenguaje enfocado en la creación de webs dinámicas. Sus scripts son

interpretados por el servidor y genera código HTML. Requiere Apache o IIS con
librerías de PHP. Hereda su sintaxis de C, Java y Perl.
Como principales ventajas se puede apreciar que es un lenguaje fácil de aprender y

muy rápido. Soporta la orientación a objetos y utiliza un lenguaje multiplataforma.
Además, puede conectarse con una gran cantidad de base de datos: MySQL,
PostgreSQL, Oracle, MS SQL Server. No necesita que se definan los tipos de
variables. Uno de sus aspectos más llamativos es que está diseñado con el fin de ser
un lenguaje muy seguro para escribir CGI, más que Perl o C.
Es el lenguaje base que utilizan la mayoría de CMS o gestores de contenidos más

extendidos como WordPress, PrestaShop, Drupal o Joomla. [15]
Lenguaje Python
Considerado por muchos el lenguaje más limpio a la hora de programar, el código, al

igual que JavaScript, es interpretado y no compilado.
Algo curioso en este lenguaje es que permite a los programadores elegir un estilo de
programación concreto (objetos, estructurado, funcional), debido a que es un lenguaje
de programación multiplataforma.
Como ventajas de Python, destacamos que es libre, fácil de programar y de fuente

abierta, de propósito general. Cuenta con muchas funciones y librerías y es
multiplataforma. Por otro lado, una de sus desventajas es que la curva de aprendizaje
para la creación de sitios web no es sencilla y la mayoría de los servidores no soportan
a Payton, y si lo soportan, la configuración es un poco difícil.
Lenguaje Java
Java es un lenguaje de programación que fue diseñado para ser de propósito general,
corre del lado del servidor aunque también se puede utilizar para aplicaciones de
escritorio y móviles.
29
La idea detrás de Java es que los programadores desarrollen una versión de su

proyecto y puedan correrlo en cualquier dispositivo, la cual es una de sus mayores
ventajas.
Es por ello que los creadores decidieron hacer Java un lenguaje compilado, pero a la
vez interpretado, es decir que Java es compilado a una lenguaje intermedio llamado
bytecode, que después es interpretado por el JRE(Java Runtime Environment), el cual
se encarga de interpretarlo.
Una de las características más importantes es que con Java, al ser de propósito
general, puedes crear aplicaciones tanto para web como de escritorio, y además es el
lenguaje preferido en cuanto a desarrollo móvil se trata, siendo el utilizado en la
plataforma Android.
Otro detalle muy importante a destacar es que es un lenguaje robusto y seguro,

aunque por su contra se dice que es también un lenguaje bastante complejo y utilizado
más bien por desarrolladores profesionales.
El costo de desarrollo de una aplicación realizada por java no es bajo, ni posee un

mayor rendimiento ni un fácil aprendizaje, comparado con otros lenguajes como PHP.
[16]
Selección del Lenguaje de programación
Se decidió utilizar el lenguaje de programación PHP ya que es un lenguaje enfocado

en la creación de webs dinámica, es un lenguaje fácil de aprender y muy rápido,
Soporta la orientación a objetos y utiliza un lenguaje multiplataforma. Además, puede
conectarse con una gran cantidad de base de datos como MySQL, PostgreSQL, Oracle
y no necesita que se definan los tipos de variables.
Fundamentación del Framework de desarrollo
Un framework es un conjunto de bibliotecas, herramientas y normas a seguir que

ayudan a desarrollar aplicaciones. Las aplicaciones pueden escribirse de manera más
eficaz si utilizamos un framework adaptado al proyecto, lo cual resulta muy útil.[17]
30
CakePHP
Cake PHP es un marco de desarrollo gratuito para el desarrollo en PHP. Es un

framework seguro y ayuda a autenticar a usuarios con facilidad, es fácil de aprender y
ayuda en el desarrollo simplificado de aplicaciones, es útil para grandes sitios y
aplicaciones, ya que es impulsado por MVC (Modelo Vista Controlador). La ubicación y
la configuración del sitio son todas hechas por el framework automáticamente, solo
debemos conectar la base de datos.
Una de las principales ventajas de Cake PHP es que proporciona plantillas listas para
usar, esto hace que el proceso de desarrollo de aplicaciones web sea ágil, es fácil de
administrar e incluso un desarrollador menos experimentado puede trabajar con
facilidad, proporciona características de prueba personalizadas que hacen que la tarea
de prueba sea rápida y simple para los desarrolladores.[18]
Codeigniter
Codeigniter es un framework especialmente creado para desarrolladores de PHP.

El marco proporciona un conjunto de herramientas simples para crear aplicaciones web
con todas las funciones. Proporciona un amplio conjunto de bibliotecas para tareas
comunes, la estructura de las bibliotecas es simple de entender y usar, minimiza la
cantidad de código necesario para cada tarea, el marco es más rápido y más confiable
que otros marcos, es un marco liviano y ayuda en la eliminación fácil de errores en el
sitio. Los programas modulares se pueden utilizar fácilmente con Codeigniter, la
plataforma es compatible en todos los sistemas operativos, servidores y
plataformas[18]
Yii
Yii también es un framework de desarrollo liviano con un potente almacenamiento en

caché. Ayuda a crear sitios más rápidos ya que usa la técnica de carga diferida, tiene
un rendimiento mucho mejor que otras plataformas en cuanto a una cantidad de
solicitudes que puede realizar por segundo.
31
Las características de seguridad de Yii incluyen la prevención de scripting entre sitios,

la prevención de falsificación de solicitudes entre sitios y la prevención de ataque de
cookies. La plataforma tiene una autenticación incorporada que ayuda a mejorar la
seguridad del sitio web, es compatible con códigos de terceros.[18]
Symfony
Symfony es un marco de desarrollo para PHP desarrollado completamente con PHP,

diseñado para optimizar el desarrollo de las aplicaciones web. Separa la lógica de
negocio, la lógica de servidor y la presentación de la aplicación web (MVC).
Proporciona varias herramientas y clases encaminadas a reducir el tiempo de
desarrollo de una aplicación web compleja. Además, automatiza las tareas más
comunes, permitiendo al desarrollador dedicarse por completo a los aspectos
específicos de cada aplicación. Es sencillo de usar y fácil de instalar y configurar en
muchas plataformas.
Este marco de desarrollo, es independiente del sistema gestor de bases de datos,

flexible para adaptarse a los casos complejos, preparado para aplicaciones
empresariales y adaptable a las políticas y arquitecturas propias de cada empresa,
además de ser lo suficientemente estable como para desarrollar aplicaciones a largo
plazo. Tiene un código fácil de leer que incluye comentarios de phpDocumentor y que
permite un mantenimiento muy sencillo, fácil de extender, permitiendo su integración
con librerías desarrolladas por terceros[19]
Selección de Framework de desarrollo

32
Se decidió utilizar el framework CakePHP ya que proporciona plantillas listas para usar,
esto hace que el proceso de desarrollo de aplicaciones web sea muy ágil. La ubicación
y la configuración del sitio son todas hechas por el framework automáticamente,
proporciona características de prueba personalizadas que hacen que la tarea de
prueba sea rápida y simple para los desarrolladores, las validaciones se hacen de
forma interactiva y todo esto permite flexibilidad/agilidad a la hora de hacer proyectos.
Fundamentación del sistema de Gestor de Base de Datos
Se trata de un conjunto de programas no visibles al usuario final que se encargan de la

privacidad, la integridad, la seguridad de los datos y la interacción con el sistema
operativo. Proporciona una interfaz entre los datos, los programas que los manejan y
los usuarios finales.
Cualquier operación que el usuario hace contra la base de datos está controlada por el
gestor. El gestor almacena una descripción de datos en lo que llamamos diccionario de
datos, así como los usuarios permitidos y los permisos. Tiene que haber un usuario
administrador encargado de centralizar todas estas tareas.[20]
MySQL
Es un sistema de base de datos relacional, multihilo y multiusuario, publicado bajo una

licencia GLP, esto quiere decir que es un software propietario y está sustentado por un
empresa privada que posee el copyright de la mayor parte del código. Es desarrollado
en su mayor parte por ANCI estándar para el lenguaje de programación C. Fue
comercializado por primera vez en 1981 por IBM. Es gratuito, multiplataforma, tiene
una mayor velocidad al realizar operaciones, no necesita muchos requerimientos de
sistema, se instala de manera muy sencilla, tiene mayor seguridad y no es muy
intuitivo.[21]
Oracle
33
Es un sistema de base de datos relacional que fue desarrollado por Oracle corporation,
se considera como uno de los sistemas de base de datos más completos. Hace
algunos años su dominio en el mercado era casi total, en la actualidad debido a la gran
competitividad que existe ya no lo es tanto. Surge a finales de los 70. Las últimas
versiones de Oracle han sido certificadas para poder trabajar bajo GNL/Linux, es el
más usado a nivel mundial, multiplataforma, permite el uso de particiones, fácil de usar,
tiene un elevado precio, las versiones más recientes contienen muchos errores.[21]
PostgreSQL
Es un sistema de base de datos relacional, orientada a objetos, que está publicado

bajo una licencia BSD. Es un proyecto de código libre y debido a estas características,
sus mejoras han sido un poco más rápidas en comparación con otros sistemas de base
de datos. Originalmente este programa se llamaba postgre, posteriormente cambio su
nombre postgres95 hasta llegar a ser llamado PostgreSQL, como es conocido en la
actualidad.
PostgreSQL es gratuito, hace más sencillo el análisis de datos, tiene mejor soporte que
los proveedores comerciales, diseñado para ambientes de alto volumen, herramientas
gráficas de diseño y administración de base de datos, tiene una mayor seguridad, es
multiplataforma, la velocidad de repuesta es relativamente lenta y no es muy utilizada.
[21]
Selección del Sistema Gestor de Base de Datos
Se decidió utilizar MySql ya que es tiene una buena velocidad al realizar operaciones,

no necesita muchos requerimientos de sistema, es gratuito, muy usado y se instala de
manera sencilla, además de ser multiplataforma.
Fundamentación de los Servidores Web

34
La definición más sencilla de servidor web es que es un programa especialmente

diseñado para transferir datos de hipertexto, es decir, páginas web con todos sus
elementos (textos, widgets, baners, etc). Estos servidores web utilizan entre sus
protocolos el http.
Los servidores web están alojados en un ordenador que cuenta con conexión de red.
El servidor web, se encuentra a la espera de que algún navegador le haga alguna
petición, como, por ejemplo, acceder a una página web y responde a la petición,
enviando código HTML mediante una transferencia de datos en red.
Apache
Apache es una popular y eficiente alternativa que ofrece servicios web. Este web
server es uno de los logros más grandes del software libre y la punta de lanza del
mundo de las páginas web.
Apache es un poderoso servidor web, cuyo nombre proviene de la frase inglesa “a

patchy server” y es completamente libre, ya que es un software Open Source y con
licencia GPL. Una de las ventajas más grandes de Apache, es que es un servidor web
multiplataforma, es decir, puede trabajar con diferentes sistemas operativos y mantener
su excelente rendimiento.
Desde el año 1996, es el servidor web más popular del mundo, debido a su estabilidad
y seguridad. Apache sigue siendo desarrollado por la comunidad de usuarios
desarrolladores que trabaja bajo la tutela de Apache Software Foundation. Posee
soporte de seguridad SSL y TLS, puede realizar autentificación de datos utilizando un
sistema de gestor de base de datos (SGDB), puede dar soporte a diferentes lenguajes,
como Perl, PHP, Python entre otros.
Apache es utilizado principalmente, para realizar servicio a páginas web, ya sean

estáticas o dinámicas. Este estupendo servidor se integra a la perfección con otras
aplicaciones, creando el famoso paquete XAMP con Perl, Python, MySQL y PHP, junto
a cualquier sistema operativo, que por lo general es Linux, Windows o Mac OS.[22]
Internet Information Server(IIS)

35
IIS es un conjunto de servicios para servidores usando Microsoft Windows. Es

especialmente usado en servidores web y actualmente es el segundo más popular
sistema de servidor web funciona en el 35% de los servidores de todos los sitios web.
IIS viene integrado con Windows NT 4.0. Dado que el IIS está tan íntimamente
integrado con el sistema operativo, es relativamente fácil de administrar. Sin embargo,
actualmente el IIS está disponible sólo para el uso en la plataforma Windows NT,
mientras que los servidores Web de Netscape corren en la mayoría de las plataformas,
incluyendo Windows NT, OS/2 y UNIX.
Una de las características más importantes es la presencia del protocolo HTTP que
ofrece sensibles mejoras de las prestaciones, disminuyendo los tiempos de respuesta
en la transmisión.
Las noveDefaults del protocolo HTTP residen en algunos de los elementos que lo
componen, tales como el Pipeling, las conexiones persistentes, las transferencias por
bloques chunked y el soporte para el proxy[23]. Su licencia no es gratuita, no es
multiplataforma y el código fuente es propietario.[24]
Selección del Servidor Web
Se decidió utilizar Apache ya que es el servidor de aplicaciones nativo del lenguaje

php, además de ser multiplataforma, de código abierto y posee amplia documentación.
Además, existen herramientas ligeras para desarrollo local como xampp, wampp, entre
otras que lo incluyen.
Análisis crítico de las fuentes y bibliografías utilizadas

36
Para dar cumplimiento a los objetivos propuestos en el trabajo, se realizó una

búsqueda de información referente al objeto y campo de acción de la investigación.
Dicha indagación se realizó en diversas fuentes bibliográficas, entre las que se
encuentran: libros digitales y artículos de sitios en Internet. También fue utilizado
material complementario de las asignaturas estudiadas en la carrera, conferencias y
clases prácticas. La mayoría de las fuentes bibliográficas fueron elaboradas por
especialistas reconocidos en el plano nacional e internacional confirmando la
confiabilidad y utilidad que tienen en el ámbito estudiado.
Conclusiones Parciales
En este capítulo se establecieron los principales flujos de trabajo a través de la

metodología de la investigación para lograr un mayor conocimiento sobre el tema. Se
realizó un estudio de las herramientas, lenguajes y metodologías de desarrollo de
software para realizar una buena selección a la hora de diseñar y construir la solución
informática definiendo cuál utilizar: para el desarrollo de la aplicación se decidió hacer
una aplicación web, en la cual se empleen como herramienta de desarrollo el Visual
Paradigm en su versión 8.0 y como lenguaje modelado UML, el servidor web apache,
el lenguaje de programación PHP, para lo cual se seleccionó como framework de
desarrollo CakePHP 2.7.3.
Con el objetivo de guiar el desarrollo de la aplicación, se emplea como metodología de

desarrollo de software el XP y para el almacenamiento de todos los datos se utilizará
como SGBD MySQL.
37
Capítulo 2 Análisis y diseño de la solución
2
3.1 Introducción
En este capítulo se describirá la propuesta del Sistema de Gestión de Solicitudes de

Telefonía Fija en el DTEL, analizando sus funcionalidades y elementos principales
utilizando la metodología ágil XP. De esta última, se incluyen requisitos no funcionales,
así como historias de usuarios. Igualmente se incluirán la estimación de esfuerzos,
plan de iteraciones y plan de duración de las iteraciones por historias de usuario, así
como la descripción del Diseño de Datos del sistema y diagrama de despliegue.
Breve descripción del sistema
3.2 El Sistema para la Gestión de Solicitudes de Servicios de Telefonía Fija del

DTEL en la Dirección de Tecnología y Sistemas, sin dudas resolvería muchos
de los problemas existentes ya que en estos momentos la información no se
encuentra no se encuentra de forma digital, por lo que no se puede, de forma
sencilla, realizar reportes y estadísticas, no existe una forma única de realizar
las solicitudes sin que se dificulte su confección, la información que perdura
en el tiempo provoca grandes cúmulos de papel, dificultando la consulta de
información. Este módulo junto a los otros tres funcionará en una red Minint,
permitiendo informatizar aquellos procesos que presentan problemas.
3.3
3.4 Personal relacionado con el sistema
El personal relacionado con el sistema no es más que aquéllos usuarios que pueden o
van a interactuar con el sistema.
Tabla 1: Niveles de acceso al sistema
Nivel del Usuario Nivel de acceso
Administrador Se encarga de la administración del sistema.
Especialista Recepciona las solicitudes de un nuevo servicio,

38
modifica campos de la solicitud y se la entrega al

jefe del DTEL para su aprobación, una vez
aprobada se la entrega al área ejecutora. Genera
reportes.
Jefe DTEL Es el que aprueba o no las nuevas solicitudes

generadas. Genera reportes.
Ejecutor Da solución a la solicitud e informan del estado de

la mismas a los especialistas. Son las unidades
ejecutoras, AG6.
Cliente Es el encargado de crear las solicitudes, puede

generar reportes y estadísticas.
3.5 Captura de Requisitos
El proceso de captura de requerimientos es una etapa de suma importancia dentro del

proceso de desarrollo de software y se hace notoriamente importante llevar a cabo
esta actividad con la mayor eficiencia posible, porque una mala captura de requisitos
puede traer consigo numerosos problemas en etapas de desarrollo posteriores. Éste
se encarga de descubrir y analizar las necesidades del usuario para el sistema a
construir.
Se plantea que existen dos tipos de requisitos (funcionales y no funcionales). Como

cualquier otro desarrollo de software, la implementación de una solución de gestión de
información, que apoya el proceso de toma de decisiones parte de un levantamiento
de requisitos, pues en esta etapa se definen los requisitos no fundamentales que se
darán a visualizar en el mismo, a través de los cuales se pueden obtener información
útil.
2.5.1
39
2.5.2 Requisitos no Funcionales
 Apariencia o interfaz externa:
RNF1: El color predominante es el verde que identifican a la entidad.

RNF2: El sistema tendrá una interfaz amigable, sugerente, intuitiva, interactiva y
entendible; cumpliendo con las pautas de diseño de la DTS.
RNF3: La interfaz debe presentar solamente las funcionalidades del rol que esté
utilizando el Sistema, para lograr la concentración del usuario en las actividades que
esté realizando.
RNF4: Mostrar de forma diferenciada los formatos de la información que se presenta.
RNF5: En el caso del buscador, permitir el acceso a la información relacionada.
 Rendimiento:
RNF6: El sistema con el uso de las tecnologías Web debe garantizar la rapidez

de respuesta ante la solicitud del usuario, al igual que la velocidad de
procesamiento de la información.
 De seguridad:
RNF7: Deberá proveer administración de usuarios.

RNF8: Deberá contar con un modelo de autenticación.
RNF9: La aplicación no deberá permitir peticiones anónimas. La información que
brinda el sistema estará protegida contra el acceso de usuarios no autorizados.
RNF10: Se empleará el control de acceso basado en roles utilizando permisos simples
y dinámicos para la autorización. El usuario solo puede acceder a las funcionalidades
que le corresponden según su rol.
RFN11: Se usarán mecanismos de cifrado de información en la base de datos para el
caso de las contraseñas.
40
RNF12: La aplicación deberá chequear la fortaleza de las contraseñas, además

deberá permitir cambios de contraseña.
RFN13: Debe poseer una correcta validación de datos de entrada a la aplicación tanto
texto como ficheros.
RNF14: La aplicación debe contar con un correcto mecanismo de manejo de sesiones.
RNF15: Las cuentas de usuario no pueden ser compartidas.
RNF16: Debe contar con un mecanismo de recolección de trazas.
RNF17: El usuario para consultas regulares a la base de datos posee solo los
privilegios mínimos e indispensables para el correcto funcionamiento de la aplicación.
RNF18: Posee un manejo de excepciones. No se brinda información de los errores de
la aplicación a los usuarios.
 Requisitos de integridad:
RNF19: Se debe garantizar que los datos contenidos en la base de datos no deberán
ser redundantes o falsos.
RNF20: Se validan los formularios para la correcta entrada de datos.
RNF21: Se tratan los errores para que el sistema evitando que el sistema quede
deshabilitado en caso de que ocurra alguno
 Requisitos de portabilidad:
RNF22: El sistema podrá ser desplegado en servidores con sistemas operativos

Windows o Linux.
 Requisitos del software:
RNF23: Las estaciones clientes deben tener un navegador con posibilidades de

solicitar y visualizar contenido HTML, se recomienda utilizar Mozilla Firefox V36 o
superior, o Internet Explorer V8 o superior.
 Requisitos del hardware:
RNF24: El sistema debe ejecutarse eficientemente como mínimo en un servidor Dual

Core a 3.0GHz.
41
RNF25: El sistema debe correr eficientemente como mínimo en una configuración con
un procesador Dual Core a 2.6GHz con 1GB RAM.
 Legales:
RNF26: El sistema debe tener la aprobación de la Dirección de Tecnologías y

Sistemas (DTS), entidad a la cual pertenece el Departamento de Telecomunicaciones.
RNF27: La aplicación debe responder a los intereses de la entidad según las
resoluciones y regulaciones que intervienen en el proceso de atención a solicitudes,
por lo cual no debe ser utilizado fuera del organismo ni ser comercializado.
3.6 Historias de usuario
Las Historias de Usuarios (HU), se utilizan para estimar el tiempo que puede
demorarse el desarrollo de la parte del sistema que en ella se describe. Estas son
elaboradas por el cliente donde él mismo describe brevemente lo que desea obtener
del producto. Cada HU corresponde a cada característica principal del sistema por lo
que se emplean en la fase de pruebas para verificar si el programa cumple con lo que
especifica la HU.
En la fase de planificación fueron definidas 18 HU que representan cada funcionalidad

que el módulo debe cumplir. A continuación, se describen cuatro de ellas y el resto
pueden ser observadas en el Anexo 1.
Tabla 2: HU Gestionar unidad organizativa
Historia de usuario
Número: HU01 Usuario: Administrador
Nombre de HU: Gestionar unidad organizativa
Modificación de HU número: Ninguna
Referencia: RF1
Programador: Omar Montero Alfaro Iteración asignada:1

Prioridad en Negocio: Alto Puntos Estimados (días): 1
42
Riesgo en desarrollo: Bajo Puntos Reales (días): 1
Descripción: Esta funcionalidad permitirá gestionar las unidades organizativas a la cual

pertenecen todos los usuarios del sistema.
Tabla 3: HU Gestionar solicitudes de servicios
Historia de usuario
Número: HU02 Usuario: Cliente, Especialista.
Nombre de H_U: Gestionar Solicitudes de servicios
Modificación de H_U número: Ninguna
Referencia: RF8

Descripción: Esta funcionabilidad permitirá al cliente y al especialista crear solicitudes, para

que el especialista las revise y el jefe la apruebe.
Tabla 4: HU gestionar cartera de inmediatez de servicio
Historia de usuario
Número: HU03 Usuario: Especialista
Nombre de H_U: Gestionar cartera de inmediatez de servicio
Referencia: RF6

Riesgo en desarrollo: Alto Puntos Reales (días): 20
Descripción: Esta funcionalidad permitirá al especialista gestionar las inmediateces de

43
servicio para que el cliente al crear una solicitud pueda darle una prioridad en cuanto a
tiempo de ejecución por parte del Ejecutor.
Tabla 5: HU Gestionar cartera de servicios suplementarios
Historia de usuario
Nombre de H_U: Gestionar cartera de servicios suplementarios
Referencia: RF7

Descripción: Esta funcionalidad permitirá gestionar los disíimiles servicios suplementarios

que pueden ser solicitados por el cliente a la hora de crear una solicitud.
3.7 Estimación de esfuerzo por historias de usuarios
Una vez confeccionadas las historias de usuario, se procedió a realizar una estimación
del esfuerzo asociado a la implementación de cada una de dichas historias de usuarios
que se definieron para un correcto desarrollo de la aplicación propuesta, a
continuación, se muestran los resultados de la estimación:
Tabla 6: Estimación de esfuerzo por historias de usuarios
Historia de Usuario Punto de estimación (semanas)
Gestionar unidad organizativa 1

Gestionar Solicitudes de servicios 2
Gestionar cantera de inmediatez de servicio 1
Gestionar cantera de servicios 1
suplementarios
Gestionar cantera de servicios 1
44
Gestionar cuenta bancaria 1

Gestionar notificaciones y alarmas 3
Gestionar clientes 1
Gestionar usuarios 1
Cuenta de usuario 1
Asociar clientes a usuarios 1
Gestionar roles 1
Gestionar permisos 1
Gestionar permisos por roles 1
Autenticar usuario 1
Cambiar contraseña 1
Mostrar trazas 1
Salva y restauración del sistema. 3
Reportes 5
Total 28
3.8 Plan de iteraciones

El plan de iteraciones presenta no solo el tiempo en el que se realizan las misma sino
la culminación de cada una. A continuación, se muestra el plan de iteraciones
propuesto:
Tabla 7: Plan de iteraciones

Iteración Historia de usuario a Inicio Fin
implementar
Gestionar unidad organizativa 20/06/2018 27/06/2018
1 Gestionar Solicitudes de 27/06/2018 12/07/2018
servicios
Gestionar cantera de 12/07/2018 19/07/2018
inmediatez de servicio
Gestionar cantera de servicios 19/07/2018 28/07/2018
suplementarios
45
Gestionar cantera de servicios 28/07/2018 04/08/2018

Gestionar notificaciones y 04/08/2018 25/08/2018
alarmas
Gestionar clientes 02/09/2018 09/09/2018
2 Gestionar usuarios 09/09/2018 26/09/2018
Cuenta de usuario 26/09/2018 03/10/2018
Asociar clientes a usuarios 03/10/2018 10/10/2018
Gestionar roles 10/10/2018 17/10/2018
Gestionar permisos 17/10/2018 24/10/2018
Gestionar permisos por roles 24/10/2018 31/10/2018
Autenticar usuario 31/10/2018 07/11/2018
3 Cambiar contraseña 10/11/2018 17/11/2018
Mostrar trazas 17/11/2018 24/11/2018
4 Salva y restauración del 01/12/2018 22/12/2018
sistema.
5 Reportes 02/1/2019 06/02/2019
3.9 Plan de duración de las iteraciones

Teniendo en cuenta el estimado de tiempo que implica la realización de cada historia
de usuario, se decide dividir la implementación del sistema en diferentes iteraciones
una vez consultada la opinión del cliente y definidas las principales funcionalidades;
para ello se establece el plan de duración de las iteraciones. Este plan define
exactamente cuáles historias de usuario serán implementadas para cada iteración. Se
desarrolló un solo plan de iteraciones, en el cual se decide realizar el sistema en una
iteración y debido a que existe un único equipo de desarrollo.
Tabla 8: Plan de duración de las iteraciones

Iteración Historia de usuario a implementar Duración de la iteración
Gestionar unidad organizativa
1 Gestionar Solicitudes de servicios
Gestionar cantera de inmediatez de 10 semanas
servicio
46
Gestionar cantera de inmediatez de

servicio
Gestionar cantera de servicios
Gestionar notificaciones y alarmas
Gestionar clientes
2 Gestionar usuarios
Cuenta de usuario 8 semanas
Asociar clientes a usuarios
Gestionar roles
Gestionar permisos
Gestionar permisos por roles
Autenticar usuario
3 Cambiar contraseña 2 semanas
Mostrar trazas
4 Salva y restauración del sistema. 3 semanas
5 Reportes 5 semanas
3.10 Plan de entrega por iteraciones

El plan de entrega es un cronograma con las funcionalidades del sistema que se
deben desarrollar en cada iteración, con las propuestas de las fechas en las que
serán entregadas las versiones al culminar cada iteración.
Se presenta el plan de entrega, elaborado con las fechas en que serán liberadas las
historias de usuario.
Tabla 9: Plan de entrega

Iteración Historia de usuario a implementar Fecha de entrega
Gestionar unidad organizativa
1 Gestionar Solicitudes de servicios 25/08/2018
Gestionar cantera de inmediatez de
servicio
Gestionar cantera de servicios
Gestionar notificaciones y alarmas
47
Gestionar clientes
2 Gestionar usuarios
Cuenta de usuario 7/11/2018
Asociar clientes a usuarios
Gestionar roles
Gestionar permisos
Gestionar permisos por roles
Autenticar usuario
3 Cambiar contraseña 24/11/2018
Mostrar trazas
4 Salva y restauración del sistema. 22/12/2018
5 Reportes 06/02/2019
Modelo Físico de datos
Para cualquier aplicación en la cual se gestione información, la base de datos siempre

desempeña un papel esencial. Es la encargada de almacenar de forma coherente y
organizada los datos para evitar que dicha información se pierda. Se realiza el diseño
de la (BD) con el objetivo de lograr la persistencia de los datos de los usuarios, así
como la información de los recursos que se gestionan por los mismos, controlando que
esta información no tenga redundancia y no existan datos innecesarios que no
cumplan ningún objetivo al ser guardados.
48
Ilustración 1: Modelo Físico de datos
3.11 Diagrama de despliegue
El diagrama de despliegue define la arquitectura de la implantación del sistema,

distribuido en términos de nodos físicos y sus conexiones, especifica los
requerimientos de distribución del sistema, así como la topología y configuración de la
red. A continuación, se muestra el diagrama del modelo de despliegue correspondiente
con la investigación.
49
Ilustración 2: Diagrama de despliegue.

3.12 Conclusiones parciales
En este capítulo se describió el sistema que se propone como solución. Se mostraron

los elementos fundamentales correspondientes a las fases de análisis y diseño de la
aplicación que se propone, tomando como base la propuesta de la metodología XP
para cada una de las fases.
Se confeccionaron las historias de usuario para definir el tiempo y el riesgo que implica
la implementación de las funcionalidades que estas describen, los requisitos
funcionales y no funcionales; las estimaciones de esfuerzo por historias de usuarios,
plan de iteración, de duración y entrega de las mismas, modelo de despliegue y el
correspondiente diseño dela base de datos para definir la estructura que tendrá la
información manejada por la aplicación.
50
Capítulo 3 Implementación y prueba
3.13 Introducción
En este capítulo se realizará la codificación de las HU que se definieron en el plan de
entrega con sus respectivas tareas de ingeniería TI, que serán definidas en el
transcurso de este capítulo, para que una vez terminada la implementación de las
funcionalidades del sistema, se pueda pasar a realizar las pruebas de aceptación
pertinente del producto utilizando los tipos, niveles y métodos de pruebas conocidos
para poder evaluar el producto, dando así por concluido el objetivo general.
3.14 Patrón arquitectónico
Los patrones arquitectónicos se utilizan para expresar una estructura de organización

base o esquema para un software. Proporcionando un conjunto de sub-sistemas
predefinidos, especificando sus responsabilidades, reglas, directrices que determinan
la organización, comunicación, interacción y relaciones entre ellos.
Los patrones arquitectónicos heredan mucha de la terminología y conceptos de

patrones de diseño, pero se centran en proporcionar modelos y métodos reutilizables
específicamente para la arquitectura general de los sistemas de información. En otras
palabras, a diferencia de los patrones de diseño, estas son plantillas incompletas y no
se pueden aplicar directamente al código con modificaciones meramente
contextuales. [25]
Para el desarrollo de la aplicación se emplea el patrón Modelo-Vista-Controlador

(MVC) ya que es el utilizado por el framework CakePHP, permitiendo realizar la
programación multicapa, separando la aplicación en tres partes principales.
2.14.1 La capa del Modelo
El modelo representa la parte de la aplicación que implementa la lógica de negocio.

Esto significa que es responsable de la recuperación de datos convirtiéndolos en
conceptos significativos para la aplicación, así como su procesamiento, validación,
asociación y cualquier otra tarea relativa a la manipulación de dichos datos.
51
2.14.2 La capa de la Vista
La vista hace una presentación de los datos del modelo estando separada de los
objetos del modelo. Es responsable del uso de la información de la cual dispone para
producir cualquier interfaz de presentación de cualquier petición que se presente.
Por ejemplo, como la capa de modelo devuelve un conjunto de datos, la vista los
usaría para hacer una página HTML que los contenga, o un resultado con formato XML
para que otras aplicaciones puedan consumir.
La capa de la Vista no se limita únicamente a HTML o texto que represente los datos,
sino que puede ser utilizada para ofrecer una amplia variedad de formatos en función
de sus necesidades tales como videos, música, documentos y cualquier otro formato.
2.14.3 La capa del Controlador
La capa del controlador gestiona las peticiones de los usuarios. Es responsable de

responder la información solicitada con la ayuda tanto del modelo como de la vista.
Los controladores pueden ser vistos como administradores cuidando de que todos los
recursos necesarios para completar una tarea se deleguen a los trabajadores más
adecuados. Espera peticiones de los clientes, comprueba su validez de acuerdo a las
normas de autenticación o autorización, delega la búsqueda de datos al modelo y
selecciona el tipo de respuesta más adecuado según las preferencias del cliente.
Finalmente delega este proceso de presentación a la capa de la Vista.
El ciclo de una petición típica en CakePHP comienza cuando un usuario solicita una
página o un recurso de la aplicación. Esta solicitud es procesada por un despachador
que selecciona el controlador correcto para manejarlo. Una vez que la solicitud llega al
controlador, éste se comunicará con la capa del Modelo para cualquier proceso de
captación de datos o el guardado de los mismos según se requiera. Una vez finalizada
esta comunicación el controlador procederá a delegar en el objeto de vista correcto la
tarea de generar una presentación resultante de los datos proporcionada por el
modelo. Finalmente, cuando esta presentación se genera, se envía de inmediato al
usuario.[26]
52
3.15 Diseño
La metodología XP sugiere que hay que conseguir diseños simples y sencillos,

procurando hacerlo todo lo menos complicado posible para conseguir un diseño fácil
de entender y programar que costará menos tiempo y esfuerzo. Otra propuesta de esta
metodología es usar glosarios de términos, si es necesario, y una correcta
especificación de los nombres de métodos y clases; pues esto ayudará a comprender
el diseño y facilitará sus posteriores ampliaciones y la reutilización del código.
3.16 Diagrama de diseño
Ilustración 3: El ciclo de una petición en CakePHP
3.17 Patrón de diseño
Un patrón de diseño es una abstracción de una solución en un nivel alto. Los patrones
solucionan problemas que existen en muchos niveles de abstracción. Hay patrones
que abarcan las distintas etapas del desarrollo.
2.17.1 Patrones GRASP
Lo esencial de un diseño de objetos lo constituye el diseño de las interacciones de

objetos y la asignación de responsabilidades. Las decisiones que se tomen pueden
influir profundamente en la extensibilidad, claridad y mantenimiento del sistema de
software de objetos, además en el grado y calidad de los componentes reutilizables.
53
 Alta cohesión: Es un principio evaluativo que aplica un diseñador mientras

evalúa todas las decisiones de diseño. Indica la relación que existe entre los
elementos de un mismo módulo. Es la medida de la relación funcional de los
elementos de un módulo. El objetivo es organizar estos elementos de manera
que los que tengan una mayor relación a la hora de realizar una tarea
pertenezcan al mismo módulo, y los elementos no relacionados, se encuentren
en módulos separados.
 Bajo acoplamiento: Impulsa la asignación de responsabilidades de manera que
su localización no incremente el acoplamiento hasta un nivel que nos lleve a los
resultados negativos que puede producir un acoplamiento alto. Es el grado de
interdependencia entre los módulos. Un buen diseño se caracteriza por un
acoplamiento mínimo, es decir, unos módulos tan independientes los unos de
los otros como sea posible.
 Controlador: Proporciona guías acerca de las opciones generalmente
aceptadas y adecuadas para manejar eventos. Es conveniente utilizar la misma
clase controlador para todos los eventos del sistema de un caso de uso, de
manera que es posible manejar la información acerca del estado del caso de
uso en el controlador.
 Creador: Guía la asignación de responsabilidades relacionadas con la creación
de objetos, una tarea muy común. La intención básica del patrón es encontrar
un creador que necesite conectarse al objeto creado en alguna situación.
 Experto: Se utiliza con frecuencia en la asignación de responsabilidades; es un
principio de guía básico que se utiliza continuamente en el diseño de objetos.
Expresa la intuición común de que los objetos hacen las cosas relacionadas con
la información que tienen.[27]
3.18 Tarjetas Clase, Responsabilidad y Colaboración (CRC)
Estas tarjetas describen las clases utilizadas en la programación de una historia, estas
se dividen en tres secciones que contienen la información del nombre de las clases,
sus responsabilidades y sus colaboraciones. Una clase es cualquier persona, evento,
54
concepto, pantalla o reporte y sus responsabilidades son los métodos relacionados con
esta clase y sus atributos. Las colaboraciones de una clase son las demás clases con
las que trabaja en conjunto para llevar a cabo sus responsabilidades.
La utilización de estas tarjetas reduce al mínimo la complejidad del diseño. Esto logra
que el programador se centre en el diseño de las bases fundamentales de la clase y le
impide entrar en detalles de su funcionamiento interno que en un momento pueden
llegar a ser contraproducentes. A continuación, se describen dos de ellas; en el Anexo
2 se muestran el resto de las tarjetas CRC por cada HU del módulo.
Tabla 10: Tarjeta CRC SolicitudesController
Tarjeta CRC
Clase: SolicitudesController
Responsabilidades: Colaboraciones:
view() Solicitude
add()
edit()
create_by_cliente()
create_step_one()
ejecutar()
index()
index_by_rols()
standartoolbar()
standartoolbar_by_rol()
55
Tabla 11: Tarjeta CRC ClientesController
Tarjeta CRC
Clase: ClientesController
view() Cliente
add()
edit()
index()
cantera()
show_cuentas_by_ou()
standartoolbar()
Tabla 12: Tarjeta CRC EventualesController
Tarjeta CRC
Clase: CuentabancariasController
view() Cuentabancaria
add()
edit()
delete()
index()
show_clientes_by_ou()
standartoolbar()
56
3.19 Tareas de ingeniería por Historias de usuario(HU)
Las (TI) son tarjetas que se elaboran para ayudar y simplificar la programación de una
(HU). Por cada una de las (HU) se definen una serie de tareas que se llevaron a cabo
para elaborar la funcionalidad que describe dicha historia. Las tareas pueden ser de
desarrollo, de corrección o de mejora. En la descripción de cada tarea se especifica la
fecha de inicio y fin de la misma, el programador responsable de cumplirla y una breve
descripción de lo que hace la tarea. Teniendo en cuenta las iteraciones determinadas
para la implementación del sistema se exponen en la siguiente tabla las tareas
correspondientes a cada (HU).
Tabla 13: Iteraciones y tareas correspondientes a cada historia de usuario

Iteración Historia de usuario Tareas de Ingeniería
HU01: Gestionar unidad TI1: El especialista es el
organizativa encargado de actualizar las
1
unidades organizativas, agregar y
eliminar.
HU02: Gestionar Solicitudes TI2: Esto permite que los
de servicios solicitantes soliciten un nuevo
servicio.
HU03: Gestionar cantera de TI3: Esto permite que los
inmediatez de servicio solicitantes y jefes soliciten un
nuevo servicio permanente.
HU04: Gestionar cantera de TI4: Esto permite que los
servicios suplementarios solicitantes y jefes soliciten un
nuevo servicio eventual.
HU05: Gestionar cantera de TI5: El especialista es el
servicios encargado de actualizar la cantera
de servicio.
HU06: Gestionar cuenta TI6: El especialista es el
bancaria encargado de actualizar la cantera
de servicio.
HU07: Gestionar TI7: Esto permite que los usuarios
notificaciones y alarmas del sistema se le muestren
mensajes sobre las operaciones
realizadas
57
HU08: Gestionar clientes TI8: El usuario con el rol de

administrador es el encargado de
2 agregar, modificar o eliminar los
clientes del sistema.
HU09: Gestionar usuarios TI9: El usuario con el rol de
agregar, modificar o eliminar los
usuarios del sistema.
HU10: Cuenta de usuario TI10: El usuario con el rol de
agregar, modificar o eliminar las
cuentas de usuarias.
HU11: Asociar clientes a TI11: El usuario con el rol de
usuarios administrador es el encargado de
asociar clientes a los usuarios para
que se puedan autenticar al
sistema.
HU12: Gestionar roles TI12: El usuario con el rol de
administrador es el encargado
asignarle el rol a los usuarios del
sistema.
HU13: Gestionar permisos TI13: El usuario con el rol de
agregar, modificar o eliminar los
permisos del sistema.
HU14: Gestionar permisos TI14: El usuario con el rol de
por roles administrador es el encargado de
asignarle a los roles del sistema
los permisos según los niveles de
acceso.
HU15: Autenticar usuario TI15: Todos los usuarios del
sistema deben autenticarse para
poder acceder al mismo.
3 HU16: Cambiar contraseña TI16: Todos los usuarios del
sistema pueden realizar cambios
en sus credenciales.
HU17: Mostrar trazas TI17: El administrador del sistema
puede visualizar trazas, para
realizar auditoría.
4 HU18: Salva y restauración TI18: El administrador del sistema
del sistema. realiza salvas para poder restaurar
58
en caso de fallas.
5 HU19: Reportes TI19: Todos los usuarios del
sistema pueden generar reportes
de las solicitudes realizadas.
3.20 Pruebas de aceptación
Es necesario definir el conjunto de pruebas que se aplicarán para verificar que el

sistema cumpla con las funcionalidades que precisa el cliente. El desarrollador
describe las pruebas realizadas según la historia de usuario seleccionada para realizar
la comprobación y validar las funcionalidades del sistema y de esta forma, saber si está
apto para ser liberado.
En las tablas de las Pruebas de Aceptación, se incluyen los siguientes campos:
 Código Caso de Prueba, contiene el identificador de caso de prueba (en el

caso de las presentes, se utiliza el identificador de la HU, al que se le
adiciona ‘-P’ y un número consecutivo).
 Nombre Historia de Usuario, que contiene el nombre de la HU
correspondiente a este caso de prueba.
 Nombre de la persona que realiza la prueba, que contiene el nombre del
responsable que realiza la prueba.
 Descripción de la Prueba, que contiene una breve descripción de la prueba
realizada.
 Condiciones de Ejecución, en donde se incluyen las condiciones necesarias
para que se pueda realizar la prueba.
 Entrada/Pasos de ejecución, que contiene una serie de pasos enumerados
para lograr realizar la prueba de esta HU.
 Resultado Esperado, contiene la descripción de lo que se espera luego de
realizar la prueba (cumplimiento de las restricciones del producto).
 Evaluación de la Prueba, muestra si la prueba fue satisfactoria o
insatisfactoria.
59
Tabla 14: Caso de prueba, Gestionar Solicitudes de Servicios

Caso de Prueba de Aceptación
Código del Caso de Prueba: Nombre Historia de Usuario: Gestionar Solicitudes
HU02-P1 de Servicios
Descripción de la Prueba: Se introduce al sistema toda la información referente a la
solicitud de servicio y después se procede a modificarla y eliminarla para comprobar que
estén correctas todas estas funcionalidades.
Nombre de la persona que realiza la prueba: Omar Montero Alfaro.
Condiciones de Ejecución: Conexión con la base de datos.
Entrada / Pasos de ejecución:
1-Ingresar datos de forma incorrecta.
2-Se ingresan los datos de forma correcta.
3-Se modifica la información de la solicitud.
3-Se elimina la solicitud del sistema.
Resultado Esperado: El sistema alerta cuando se introducen incorrectamente los datos en
el formulario o se dejan campos vacíos, una vez que se ingresa correctamente la
información queda guardada pudiéndose modificar y eliminar.
Evaluación de la Prueba: Satisfactoria
Tabla 15: Caso de prueba, Gestionar Clientes

Código del Caso de Prueba: Nombre Historia de Usuario: Gestionar Clientes
HU08-P2
Descripción de la Prueba: Se introduce al sistema toda la información referente al Cliente y
después se procede a modificarla y eliminarla para comprobar que estén correctas todas
estas funcionalidades.
información, queda guardada pudiéndose modificar y eliminar.
60
Tabla 16: Caso de prueba, Gestionar unidad organizativa

Código del Caso de Prueba: Nombre Historia de Usuario: Gestionar unidad
HU01-P2 organizativa
Descripción de la Prueba: Se introduce al sistema toda la información referente a la unidad
organizativa y después se procede a modificarla y eliminarla para comprobar que estén
correctas todas estas funcionalidades.
información, queda guardada pudiéndose modificar y eliminar.
3.21 Conclusiones parciales
En este capítulo a partir de los estudios realizados se presentaron las especificaciones

de las clases para este sistema, en las que se contemplan sus atributos y
funcionalidades, las relaciones entre ellas, dependencia, entre otros elementos; el
diseño y la arquitectura fueron formados con el establecimiento del patrón de
arquitectura Modelo-Vista –Controlador y el patrón de diseño GRASP, lo cual permitió
obtener la descripción del sistema informático propuesto como solución.
61
Conclusiones Generales
A partir del análisis del estado del arte se constató la necesidad de desarrollar un
sistema para la gestión de solicitudes de telefonía fija para lo cual se definió las
metodologías, herramientas y lenguajes de desarrollo, seleccionándose las más
adecuadas para el cumplimiento del objetivo general propuesto. El análisis y diseño del
sistema, posibilitó determinar los requerimientos necesarios del mismo para su correcto
funcionamiento, desarrollándose el sistema informático para la gestión de solicitudes,
que permite centralizar información, realizar búsqueda oportuna y unificar los formatos
de envíos de la solicitud.
62
Referencias bibliográficas
[1] InvGate, «InvGate Service Desk – Mucho más que gestión de solicitudes». [En
línea]. Disponible en: https://www.invgate.com/es/service-desk/other-capabilities/.
[Accedido: 18-feb-2019].
[2] «Software para Gestión de Solicitudes de Servicios | SoftExpert Solicitud»,
SoftExpert. .
[3] O. Tinoco Gómez, P. P. Rosales López, y J. Salas Bacalla, «Criterios de selección
de metodologías de desarrollo de software», Industrial Data, vol. 13, n.o 2, 2010.
[4] S. D. Amaro Calderón y J. C. Valverde Rebaza, «Metodologías ágiles», Escuela de
Informática. Trujillo: Universidad Nacional de Trujillo, 2007.
[5] A. N. Cadavid, J. D. F. Martínez, y J. M. Vélez, «Revisión de metodologías ágiles
para el desarrollo de software», Prospectiva, vol. 11, n.o 2, pp. 30-39, 2013.
[7] R. S. Pressman y J. M. Troya, «Ingeniería del software», 1988.
63
[8] R. Giandini, G. Pérez, y C. Pons, «Un lenguaje de Transformación específico para

Modelos de Proceso del Negocio», en XXXVI Conferencia Latinoamericana de
Informática (CLEI 2010), 2010, vol. 18.
[9] «CASE - EcuRed». [En línea]. Disponible en: https://www.ecured.cu/CASE.
[10] «Rational Rose Enterprise Edition - EcuRed». [En línea]. Disponible en:
https://www.ecured.cu/Rational_Rose_Enterprise_Edition. [Accedido: 13-feb-2019].
[11] «Definición de lenguaje de programación — Definicion.de», Definición.de. [En
línea]. Disponible en: https://definicion.de/lenguaje-de-programacion/. [Accedido:
14-feb-2019].
[12] piensa, «Principales lenguajes de programación para el desarrollo web», Blog
Piensa Solutions, 19-oct-2017. .
[13] «Los diferentes lenguajes de programación para la web», Maestros del Web, 02-
nov-2007. .
[14] M. A. E. Mina y A. Y. S. Cedeño, Análisis Comparativo entre ASP. NET y PHP,
No 4., vol. 3. 2018.
[15] J. Lafosse, Struts 2: El framework de desarrollo de aplicaciones Java EE.
Ediciones Eni, 2010.
[16] I. B y G, «¿ Por qué CakePHP ? Comparando Frameworks», Blog de Informatica
B&G, 05-sep-2018. .
[17] J. Eguiluz, «Desarrollo web ágil con Symfony2», Recuperado de http://symfony.
es/libro, 2013.
[18] DesarrolloWeb.com, «Sistemas gestores de bases de datos»,
DesarrolloWeb.com. [En línea]. Disponible en:
http://www.desarrolloweb.com/articulos/sistemas-gestores-bases-datos.html.
[19] «Diferencia Entre PostgreSQL MySQL Oracle», Scribd. [En línea]. Disponible en:
https://es.scribd.com/doc/36570454/Diferencia-Entre-PostgreSQL-MySQL-Oracle.
[20] «¿Qué es Apache?», Culturación, 09-feb-2011. .
[21] «IIS Vs Apache ¿que servidor utilizo?», Miguel Angel López WEB, 20-ene-
2015. .
[22] «IIS (Internet Information Server)», WiWi Weblog, 07-oct-2008. .
[23] ingeniods, «Patrones Arquitectónicos», Ingenio DS, 16-sep-2013. .
[24] «Entendiendo el Modelo - Vista - Controlador - 2.x». [En línea]. Disponible en:
https://book.cakephp.org/2.0/es/cakephp-overview/understanding-model-view-
controller.html. [Accedido: 08-mar-2019].
[25] G. L. G. Gómez, J. F. Acevedo, y D. A. Moreno, «Una ontología para la
representación de conceptos de diseño de software», Avances en Sistemas e
Informática, vol. 8, n.o 3, pp. 103-110, 2011.
64
Bibliografía
[1] «Manual de Funcionamiento interno de la Dirección de Comunicaciones». .
[2] InvGate, «InvGate Service Desk – Mucho más que gestión de solicitudes». [En
línea]. Disponible en: https://www.invgate.com/es/service-desk/other-capabilities/.
[3] «Software para Gestión de Solicitudes de Servicios | SoftExpert Solicitud»,
SoftExpert. .
[4] O. Tinoco Gómez, P. P. Rosales López, y J. Salas Bacalla, «Criterios de selección
de metodologías de desarrollo de software», Industrial Data, vol. 13, n.o 2, 2010.
[5] S. D. Amaro Calderón y J. C. Valverde Rebaza, «Metodologías ágiles», Escuela de
Informática. Trujillo: Universidad Nacional de Trujillo, 2007.
[6] «Manifiesto por el Desarrollo Ágil de Software». [En línea]. Disponible en:
http://agilemanifesto.org/iso/es/manifesto.html. [Accedido: 12-jun-2019].
[9] «¿Qué es el lenguaje unificado de modelado (UML)? | Lucidchart». [En línea].
Disponible en: https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-
de-modelado-uml. [Accedido: 22-may-2019].
[10] R. S. Pressman y J. M. Troya, «Ingeniería del software», 1988.
[11] R. Giandini, G. Pérez, y C. Pons, «Un lenguaje de Transformación específico
para Modelos de Proceso del Negocio», en XXXVI Conferencia Latinoamericana de
Informática (CLEI 2010), 2010, vol. 18.
[12] «CASE - EcuRed». [En línea]. Disponible en: https://www.ecured.cu/CASE.
[13] «Rational Rose Enterprise Edition - EcuRed». [En línea]. Disponible en:
https://www.ecured.cu/Rational_Rose_Enterprise_Edition. [Accedido: 13-feb-2019].
[14] «Definición de lenguaje de programación — Definicion.de», Definición.de. [En
línea]. Disponible en: https://definicion.de/lenguaje-de-programacion/. [Accedido:
14-feb-2019].
[15] piensa, «Principales lenguajes de programación para el desarrollo web», Blog
Piensa Solutions, 19-oct-2017. .
[16] Sabrina, «PHP vs Java: ¿Cuál debo elegir? ¿En qué se diferencian?», Guiadev,
04-feb-2019. [En línea]. Disponible en: https://guiadev.com/php-vs-java/. [Accedido:
12-jun-2019].
[17] J. Lafosse, Struts 2: El framework de desarrollo de aplicaciones Java EE.
Ediciones Eni, 2010.
[18] I. B y G, «¿ Por qué CakePHP ? Comparando Frameworks», Blog de Informatica
B&G, 05-sep-2018. .
[19] J. Eguiluz, «Desarrollo web ágil con Symfony2», Recuperado de http://symfony.
es/libro, 2013.
[20] DesarrolloWeb.com, «Sistemas gestores de bases de datos»,
DesarrolloWeb.com. [En línea]. Disponible en:
http://www.desarrolloweb.com/articulos/sistemas-gestores-bases-datos.html.
65
[21] «Diferencia Entre PostgreSQL MySQL Oracle», Scribd. [En línea]. Disponible en:
https://es.scribd.com/doc/36570454/Diferencia-Entre-PostgreSQL-MySQL-Oracle.
[22] «¿Qué es Apache?», Culturación, 09-feb-2011. .
[23] «IIS Vs Apache ¿que servidor utilizo?», Miguel Angel López WEB, 20-ene-
2015. .
[24] «IIS (Internet Information Server)», WiWi Weblog, 07-oct-2008. .
[25] ingeniods, «Patrones Arquitectónicos», Ingenio DS, 16-sep-2013. .
[26] «Entendiendo el Modelo - Vista - Controlador - 2.x». [En línea]. Disponible en:
https://book.cakephp.org/2.0/es/cakephp-overview/understanding-model-view-
controller.html. [Accedido: 08-mar-2019].
[27] G. L. G. Gómez, J. F. Acevedo, y D. A. Moreno, «Una ontología para la
representación de conceptos de diseño de software», Avances en Sistemas e
Informática, vol. 8, n.o 3, pp. 103-110, 2011.
66
Anexo 1
Tabla 17: HU Gestionar cantera de servicios
Historia de usuario
Nombre de H_U: Gestionar cantera de servicios
Referencia: RF5

Descripción: Esta funcionalidad permitirá gestionar los servicios que pueden ser
solicitados por el Cliente.
Tabla 18: HU Gestionar cuenta bancaria
Historia de usuario
Nombre de H_U: Gestionar cuenta bancaria
Referencia: RF4

Descripción: Esta funcionalidad permitirá gestionar los datos referentes a las cuentas
bancarias que son utilizadas en las solicitudes para el pago de la misma.
67
Tabla 19: HU Gestionar notificaciones y alarmas
Historia de usuario
Nombre de H_U: Gestionar notificaciones y alarmas
Referencia: RF9

Prioridad en Negocio: Medio Puntos Estimados (días): 15
Riesgo en desarrollo: Alta Puntos Reales (días): 20
Descripción: Esta funcionalidad permitirá a los usuarios visualizar las notificaciones y

alarmas para los casos tales como errores de entrada de datos, solicitudes creadas,
aprobadas, etc.
Tabla 20: HU Gestionar clientes
Historia de usuario
Nombre de H_U: Gestionar clientes
Referencia: RF2

Descripción: Esta funcionalidad permitirá gestionar los clientes que podrán realizar
solicitudes.
68
Tabla 21: HU Gestionar usuarios
Historia de usuario
Nombre de H_U: Gestionar usuarios
Referencia: RF11

Descripción: Esta funcionalidad permitirá gestionar los usuarios que tendrán acceso al
sistema clasificados por roles.
Tabla 22: HU Cuenta de usuario
Historia de usuario
Número: HU10 Usuario: Administrador, Cliente, Especialista, Jefe DTEL,
Ejecutor
Nombre de H_U: Cuenta de usuario
Referencia: RF13

Prioridad en Negocio: Bajo Puntos Estimados (días): 1
Descripción: Esta funcionalidad permite cerrar la sesión del usuario.

69
Tabla 23: HU Asociar clientes a usuarios
Historia de usuario
Nombre de H_U: Asociar clientes a usuarios
Referencia: RF3

Descripción: Esta funcionalidad permitirá que a partir de un cliente se cree un usuario del
sistema.
Tabla 24: HU Gestionar roles
Historia de usuario
Nombre de H_U: Gestionar roles
Referencia: RF15

Riesgo en desarrollo: Medio Puntos Reales (días): 3
Descripción: Esta funcionalidad permitirá gestionar roles que serán asignados a los
usuarios.
70
Tabla 25: HU Gestionar permisos
Historia de usuario
Nombre de H_U: Gestionar permisos
Referencia: RF16

Descripción: Esta funcionalidad permite gestionar permisos que serán asignados a los
usuarios.
Tabla 26: HU Gestionar permisos por roles
Historia de usuario
Nombre de H_U: Gestionar permisos por roles
Referencia: RF17

Descripción: Esta funcionalidad permitirá asignarle a los roles, los permisos para que los
71
usuarios solo puedan acceder a los recursos del sistema que tengan permitido.
Tabla 27: HU Autenticar usuario
Historia de usuario
Ejecutor.
Nombre de H_U: Autenticar usuario
Referencia: RF14

Descripción: Esta funcionalidad permitirá que para entrar al sistema el usuario tenga que
poner usuario y contraseña para verificar su identidad.
Tabla 28: HU Cambiar contraseña
Historia de usuario
Ejecutor.
Nombre de H_U: Cambiar contraseña
Referencia: RF12

72
Descripción: Esta funcionalidad permitirá que los usuarios del sistema puedan cambiar
sus credenciales.
Tabla 29: HU Mostrar trazas
Historia de usuario
Nombre de H_U: Mostrar trazas
Referencia: RF18

Descripción: Esta funcionalidad permitirá mostrar las trazas por eventos, de las acciones
que realicen los usuarios.
Tabla 30: HU Salva y restauración del sistema
Historia de usuario
Nombre de H_U: Salva y restauración del sistema.
Referencia: RF19

73
Descripción: Esta funcionalidad permitirá hacer salvas periódicas del sistema y su base
de datos.
Tabla 31: HU Reportes
Historia de usuario
Ejecutor.
Nombre de H_U: Reportes
Referencia: RF9

Descripción: Esta funcionalidad permitirá generar reportes y estadísticas de varios tipos.

74
Anexo 2
Tabla 32: Tarjeta CRC DashboardsController
Tarjeta CRC
Clase: DashboardsController
view() Dashboard
index()
rpt_solicitudes()
standartoolbar()
Tabla 33: Tarjeta CRC InmediateserviciosController
Tarjeta CRC
Clase: InmediateserviciosController
view() Inmediateservicio
add()
edit()
index()
75
standartoolbar()
Tabla 34: Tarjeta CRC PagesController
Tarjeta CRC
Clase: PagesController
home ()
home_cliente ()
home_ejecutor ()
home_especialista ()
home_jefe ()
Tabla 35: Tarjeta CRC SecurityAppController
Tarjeta CRC
Clase: SecurityAppController
76
SecurityApp
Tabla 36: Tarjeta CRC ServiciosController
Tarjeta CRC
Clase: ServiciosController
view() Servicio
add()
edit()
index()
add_sup()
cantera()
standartoolbar()
Tabla 37: Tarjeta CRC ServiciosSolicitudesController
Tarjeta CRC
Clase: ServiciosSolicitudesController
view() ServiciosSolicitude
add()
edit()
index()
77
standartoolbar()
Tabla 38: Tarjeta CRC ServiciosuplementariosController
Tarjeta CRC
Clase: ServiciosuplementariosController
view() Serviciosuplementario
add()
edit()
index()
standartoolbar()
show_suplementario_by_servicio()
cantera()
Tabla 39: Tarjeta CRC ServiciosuplementariosSolicitudesController
Tarjeta CRC
78
Clase: ServiciosuplementariosSolicitudesController
view() ServiciosuplementariosSolicitude
add()
edit()
index()
Tabla 40: Tarjeta CRC UosController
Tarjeta CRC
Clase: UosController
view() Uo
add()
edit()
index()
standartoolbar()
cantera()

Ejemplo de Tesis XP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ejemplo de Tesis XP

Cargado por

Copyright:

Formatos disponibles

INSTITUTO SUPERIOR DEL MINISTERIO DEL INTERIOR

ELISEO REYES RODRÍGUEZ – “CAPITÁN SAN LUIS”

FILIAL UNIVERSITARIA PROVINCIAL DEL MININT

SISTEMA INFORMÁTICO PARA LA GESTIÓN DE SERVICIOS DE TELEFONÍA FIJA DEL

Trabajo de Diploma para optar por el título de Ingeniero en Informática

Autor: Tte. Omar Montero Alfaro

Tutora: Tte. Ing. Annia Mailyn Arrechea Turro

A Raúl Denis López por la preocupación sobre mi desempeño académico a lo largo de la

Dedico mi Trabajo de Diploma a mi madre María Victoria Alfaro Amigó, de manera

Actualmente el Ministerio del Interior (MININT), cuenta con la necesidad de adquirir y

En la actualidad las solicitudes de estos servicios llegan, en disimiles formatos, a un

Palabras claves: Dirección de Tecnologías y Sistemas Departamento de

Keywords: Technology and Systems Department, Telecommunications Department,

Capítulo 2 Análisis y diseño de la solución 8

3.2 Breve descripción del sistema 8

3.3 Personal relacionado con el sistema 8

3.4 Captura de Requisitos 9

2.4.1 Requisitos no Funcionales 9

3.5 Historias de usuario 12

3.6 Estimación de esfuerzo por historias de usuarios 14

3.7 Plan de iteraciones 15

3.8 Plan de duración de las iteraciones 16

3.9 Plan de entrega por iteraciones 17

3.10 Modelo Físico de datos 18

3.11 Diagrama de despliegue 19

3.12 Conclusiones parciales 20

Capítulo 3 Implementación y prueba 21

3.2 Patrón arquitectónico 21

2.2.1 La capa del Modelo 21

2.2.2 La capa de la Vista 22

2.2.3 La capa del Controlador 22

3.4 Diagrama de diseño 23

3.5 Patrón de diseño 23

2.5.1 Patrones GRASP 23

3.6 Tarjetas Clase, Responsabilidad y Colaboración (CRC) 24

3.7 Tareas de ingeniería por Historias de usuario(HU)27

3.8 Pruebas de aceptación 29

3.9 Conclusiones parciales 32

Capítulo 1 Fundamentos teóricos 6

1.2 Objetivos Estratégicos de la Organización 6

1.2.1 Flujo actual de los procesos 7

1.3 Análisis crítico de la ejecución de los procesos 7

1.4 Proceso de objeto de automatización7

1.5 Sistemas Automatizados existentes vinculados al campo de acción 8

1.5.1 Sistemas Internacionales 8

1.5.2 Sistemas Nacionales 9

1.6 Fundamentación de los objetivos 9

1.7 Tendencias y tecnologías actuales 9

1.7.1 Metodologías de Desarrollo 10

1.7.2 Comparación entre metodologías Ágiles y Metodologías Tradicionales

1.7.3 Selección del tipo de metodología de desarrollo a utilizar 10

1.8 Metodologías Ágiles de desarrollo 11

1.8.1 Programación Extrema (XP) 11

1.8.2 Selección de la Metodología de Desarrollo a utilizar 12

1.9 Fundamentación del Lenguaje de Modelado 12

1.9.1 Lenguaje de Modelado Unificado (UML) 12

1.9.2 Modelo de Notación del Proceso de Negocio (BPMN) 13

1.9.3 Selección del Lenguaje de Modelado 13

1.9.4 Fundamentación de la Herramienta CASE 13

1.9.5 Visual Parading 14

1.9.6 Rational Rose 15

1.9.7 Selección de la Herramienta CASE 16

1.10 Fundamentación del Lenguaje de programación 17

1.10.2 Lenguaje Python 17