UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y

NATURALES CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

“SISTEMA WEB PARA EL REGISTRO Y ADMINISTRACIÓN DE

DOCUMENTOS DE NIÑOS PATROCINADOS
CASO: CDI BO - 132”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN

INFORMÁTICA MENCIÓN: INGENIERÍA DE SISTEMAS

INFORMÁTICOS

POSTULANTE: LÍA ISABEL CORTEZ CUSI

TUTOR METODOLÓGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO
ASESOR: Lic. GROVER ALEX RODRÍGUEZ RAMÍREZ

LA PAZ – BOLIVIA

2014
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN
ANDRÉS AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
Dedicatoria:
A toda mi familia, en especial a mi querida madre
María Cusi Cusi, quien es la principal inspiración de
superación y fortaleza en mi vida quien supo
forjarme con buenos valores y principios, a mi
hermano Brian Juan Cortez Cusi por el ánimo y la
ayuda que me brindo.

Con mucho cariño

Lía Isabel
 Agradecimientos
Principalmente a nuestro Dios sobre todas las cosas por concederme la vida y la salud
para culminar una etapa más en mi vida.

Agradecer a mi mamá por darme todo su apoyo y comprensión incondicional para que
salga adelante, a mi papá que aunque no esté a mi lado sé que siempre me ha estado
cuidando, a mi hermano Brian, por su ánimo y apoyo, a mi esposo por su comprensión
y soportarme a cada momento, al Rev. Elías Emilio Quint Marin por sus
oraciones.

Al M. Sc. Aldo Ramiro Valdez Alvarado tutor metodológico, por sus consejos y por
guiarme a lo largo del desarrollo de este proyecto.

Al Lic. Gover Alex Rodríguez Ramírez, docente asesor, por brindarme su apoyo
incondicional, tiempo dedicado y por su paciencia, que me ayudaron a culminar
este proyecto.

A los docentes de la carrera de Informática.

Agradecer también al Ministerio Roca Eterna y al Centro de Desarrollo Integral BO-

132, por darme la oportunidad de realizar este proyecto.

A mis amigos que siempre me han estado apoyando con sus ánimos.

De todo corazón muchas gracias a todos. . . .

 RESUMEN

El presente proyecto fue desarrollado en el Centro de Desarrollo Integral de Bolivia Bo-132

en área de patrocinio, que realiza los procesos de registro de postulante, registro de
patrocinado, control de documentación requerida, las actualizaciones de la información
registrada.

El área de patrocinio no cuenta con un sistema de información automático es decir todo lo

realizan manualmente lo que ocasiona volúmenes de papelería con información.

Por lo mencionado anteriormente se desarrolló un Sistema Web para el registro y

administración de documentos de niños patrocinados CDI BO-132, optimizando el trabajo
en el tiempo de procesos y además llevar un control adecuado de la información.

Este proyecto fue realizado con la metodología de desarrollo de software del Proceso
Unificado Ágil denotado por el acrónimo AUP, para el análisis y diseño del sistema, para el
modelado del sistema se utilizó la propuesta de Ingeniería Web basado en OOHDM,
utilizando la herramienta case Enterprise Architect, para representar los diferentes objetos o
diagramas necesarios para el modelado del sistema.

El área de patrocinio, trabaja sobre la plataforma Windows, es por este motivo, que el
sistema fue desarrollado con lenguaje de programación PHP 5.5.12 y como gestor de base
de datos se utilizó MySql server 2005.

La calidad del sistema fue medida con la norma ISO 9126 con todas las características
necesarias, también se efectuó una descripción de las amenazas del sistema y la aplicación
de medidas de seguridad para el funcionamiento adecuado del sistema.
 ÍNDICE

CAPITULO I: MARCO INTRODUCTORIO

1.1. INTRODUCCIÓN…………………………………………………………………………..……………………………… 1
1.2. ANTECEDENTES…………………………………………………………………………..……………………………… 2
1.2.1. ANTECEDENTES INSTITUCIONALES…………………………………………..…………………………….. 2
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES……………………………..…………………………….. 5
1.3. PLANTEAMIENTO DEL PROBLEMA………………………………………………..……………………………. 7
1.3.1. PROBLEMA CENTRAL………………………………………………………………..……………………………. 7
1.3.2. PROBLEMAS SECUNDARIOS……………………………………………………..…………………………….. 8
1.4. DEFINICIÓN DE OBJETIVOS………………………………………………………….. 8
…………………………….. 4.1. OBJETIVO GENERAL…………………………………………………………………….. 8
……………………………. 4.2. OBJETIVOS ESPECÍFICOS……………………………………………………………….. 9
………………………….. 1.5. JUSTIFICACIÓN……………………………………………………………………………….. 9
………………………….. 1.5.1. JUSTIFICACIÓN ECONÓMICA……………………………………………………….. 9
…………………………. 1.5.2. JUSTIFICACIÓN 10
SOCIAL…………………………………………………………………..……………………….. 1.5.3. 10
JUSTIFICACIÓN TECNOLÓGICA………………………………………………………..………………………. 1.6. 10
ALCANCES Y LÍMITES…………………………………………………………………………..………………………. 1.6.1. 10
ALCANCES………………………………………………………………………………………..……………………… 1.6.2. 11
LÍMITES……………………………………………………………………………………………..……………………. 1.7. 12
APORTES………………………………………………………………………………………………..…………………… 1.7.1. 12
PRÁCTICO…………………………………………………………………………………………..…………………… 1.7.2. 12
TEÓRICO……………………………………………………………………………………………..………………….. 1.8. 12
METODOLOGÍA………………………………………………………………………………………..………………….
CAPITULO II: MARCO TEÓRICO 15
2.1. INGENIERÍA DEL SOFTWARE……………………………………………………………………. 16
………………….
16
2.2. METODOLOGÍAS DE DESARROLLO DE SOFTWARE…………………………………….…………………
17
2.2.1. METODOLOGÍAS AGILES………………………………………………………………………….………………
19
2.2.2. PROCESO UNIFICADO ÁGIL (AUP)…………………………………………………………….……………..
19
2.2.3. PRINCIPIOS DE LA AUP……………………………………………………………………………….……………
2.2.4. CARACTERÍSTICAS DE LA AUP……………………………………………………………………….………..
2.2.5. FASES DE LA AUP…………………………………………………………………………………………..………… 21
[Link]. PRIMERA FASE: CONCEPCIÓN……………………………………………………………………………… 21
[Link]. SEGUNDA FASE: ELABORACIÓN…………………………………………………………………………… 22
[Link]. TERCERA FASE: CONSTRUCCIÓN……………………………………………………………………….… 22
[Link]. CUARTA FASE: TRANSICIÓN………………………………………………………………………………... 23
2.2.6. DISCIPLINAS DE AUP…………………………………………………………………………………………….... 23
[Link]. DISCIPLINA DE MODELADO………………………………………………………………………………... 23
[Link]. DISCIPLINA DE LA IMPLEMENTACIÓN………………………………………………………………..… 26
[Link]. DISCIPLINA DE PRUEBA……………………………………………………………………………………….. 28
[Link]. DISCIPLINA DE DESPLIEGUE………………………………………………………………………………... 30
[Link].DISCIPLINA DE ADMINISTRACIÓN DE LA CONFIGURACIÓN………………………………….. 32
[Link].DISCIPLINA DE LA ADMINISTRACIÓN DEL PROYECTO………………………………………….. 33
[Link]. DISCIPLINA DEL AMBIENTE………………………………………………………………………………….. 35
2.2.7. ITERACIONES E INCREMENTOS DE TIEMPO…………………………………………………………... 37
2.2.8. ROLES DEL EQUIPO…………………………………………………………………………………………………. 37
2.2.9. ENTREGABLES………………………………………………………………………………………………………… 39
2.3. INGENIERÍA WEB………………………………………………………………………………………………………. 42
2.3.2. INGENIERÍA DE 42
SOFTWARE…………………………………………………………………………………….. 2.3.3. APLICACIONES 43
WEB.………………………………………………………………………………………………. 46
2.4. METODOLOGÍA DE MODELADO OOHDM…………………………………………………………………… 47
2.4.1. FASE CONCEPTUAL…………………………………………………………………………………………………. 48
2.4.2. FASE NAVEGACIONAL…………………………………………………….………………………………………. 50
2.4.3. FASE DE INTERFAZ 51
ABSTRACTA………………………………………………………………………………. 2.4.4. FASE 52
IMPLEMENTACIÓN………………………………………………………………………………………… 2.5. 54
FACTORES DE CALIDAD NORMA ISO 9126………………………………………………………………….. 55
2.6. MODELO CONSTRUCTIVO DE COSTOS (COCOMO II)…………………………………………………… 55
2.7. TÉCNICAS DE PRUEBAS DE SOFTWARE………………………………………. 56
………………………………. 2.7.1. FACILIDAD DE PRUEBA…………………………………………………………….
………………………………. 2.8. SEGURIDAD………………………………………………………………………………..
………………………………. CAPITULO III: MARCO APLICATIVO

ii
3.1. INTRODUCCIÓN…………………………………………………………………………………………..……………… 58
3.2 FASE DE INICIO……………………………………………………………………………………………..……………… 60
3.2.1 MODELADO DEL NEGOCIO………………………………………………………………………..……………… 60
3.2.1.1MODELADO DE CASOS DE USO DEL NEGOCIO………………………………………..……………… 60
3.2.1.2DESCRIPCIÓN DE ACTORES DEL CASO DE USO DE NEGOCIO…………………..……………… 62
3.2.2 MODELADO DE REQUERIMIENTOS……………………………………………………………..……………. 63
3.2.2.1DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE NEGOCIOS……………………..………….. 63
3.2.2.2DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE USUARIO………………………..………….. 63
3.2.2.3DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE SISTEMA…………………………..………… 64
3.2.2.4DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL TÉCNICOS……………………………..…………. 64
3.3 FASE DE ELABORACIÓN……………………………………………………………………………………..………… 64
3.3.1 MODELADO DE ANÁLISIS……………………………………………………………………………….. 65
………… [Link] MODELO DE CASOS DE 65
USO………………………………………………………………………..………… 65
[Link]. DIAGRAMA DE CASOS DE USO DE ALTO NIVEL…………………………………………..………… 66
[Link] DESCRIPCIÓN DE CASOS DE USO………………………………………………………………….. 76
………. [Link]. DIAGRAMA DE 76
PAQUETES……………………………………………………………………………..…….. [Link]. DIAGRAMA DE 77
DESPLIEGUE…………………………………………………………………………..…….. [Link]. DIAGRAMA DE 82
SECUENCIA……………………………………………………………………………..…… 3.3.2. MODELO DE 82
DISEÑO………………………………………………………………………………………..……. [Link]. DIAGRAMA DE 83
CLASES…………………………………………………………………………………..…….. [Link]. DIAGRAMA 84
ENTIDAD RELACIÓN……………………………………………………………………..……. [Link]. MODELO 86
FÍSICO……………………………………………………………………………………………………. [Link].MODELO DE 86
NAVEGACIÓN……………………………………………………………………………..……. 87
[Link] MODELO DE NAVEGACIÓN DE MENÚS……………………………………………………………..…… 89
[Link] MODELO DE PRESENTACIÓN……………………………………………………………………………..…. 90
3.4. FASE DE CONSTRUCCIÓN………………………………………………………………………………………..…. 90
3.4.1 DISEÑO DE INTERFAZ ABSTRACTA………………………………………………………………………..…. 91
[Link]. AUTENTIFICACIÓN……………………………………………………………………………………………..… 92
[Link]. PANTALLA
PRINCIPAL…………………………………………………………………………………………..
[Link]. MENÚ INICIO……………………………………………………………………………………………………..…
[Link]. ADMINISTRACIÓN DE USUARIO…………………………………………………………………………… 92
[Link]. REGISTRAR USUARIO……………………………………………………………………………………………. 93
[Link]. MODIFICACIÓN DE USUARIO………………………………………………………………………………... 95
[Link]. ELIMINACIÓN DE USUARIO…………………………………………………………………………………... 96
[Link]. REGISTRO POSTULANTE……………………………………………………………………………………….. 97
[Link]. EVALUACIÓN DE POSTULANTE…………………………………………………………………………….... 98
[Link]. REGISTRO DE PATROCINADO……………………………………………………………………………... 99
[Link]. ELIMINACIÓN DE PATROCINADO……………………………………………………………………….. 100
[Link]. BÚSQUEDA DE PATROCINADO……………………………………………………………………..……… 101
[Link]. REGISTRO DE HISTORIAL……………………………………………………………………………….……. 102
[Link]. BUSCAR Y EDICIÓN DE HISTORIAL………………………………………………………………………. 103
[Link]. REPORTE POSTULANTE……………………………………………………………………………………….. 104
[Link]. REPORTE HISTORIAL DE PATROCINADO…………………………………………………………..…. 104
3.5. FASE DE TRANSICIÓN………………………………………………………………………………………………..… 106
3.5.1. IMPLEMENTACIÓN………………………………………………………………………………………………….. 106
[Link]. PRUEBAS DEL SISTEMA…………………………………………………………………………………………. 106
[Link]. PRUEBAS DE SEGURIDAD……………………………………………………………………………………… 110
3.5.2. RESTRICCIONES DEL SISTEMA………………………………………………………………………………..… 111
3.5.3. CAPACITACIÓN……………………………………………………………………………………………………..… 111
CAPITULO IV: CALIDAD DE SOFTWARE Y SEGURIDAD
4.1. INTRODUCCIÓN…………….................................................................................................. 112
4.2. CARACTERÍSTICAS PROPUESTAS POR ISO-9126………………………………………………………..…. 112
4.2.1. CONFIABILIDAD……………………………………………………………………………………………………..… 114
4.2.2. FUNCIONALIDAD…………………………………………………………………………………………………..…. 116
[Link]. NÚMERO DE ENTRADAS DE USUARIO……………………………………………………………..……. 117
[Link]. NÚMERO DE SALIDAS DE USUARIO…………………………………………………………………..….. 118
[Link]. NÚMERO DE PETICIONES DE USUARIO…………………………………………………………..…….. 118
[Link]. NUMERO DE ARCHIVOS…………………………………………………………………………………..……. 119
[Link]. NUMERO DE INTERFACES EXTERNAS………………………………………………………………..….. 119
[Link]. PONDERACIÓN………………………………………………………………………………………………….…. 119
4.2.3. MANTENIBILIDAD………………………………………………………………………………………………….... 122
4.2.4. PORTABILIDAD………………………………………………………………………………………………………... 123
[Link]. NIVEL DE APLICACIONES………………………………………………………………………………………. 124
[Link]. NIVEL DEL SISTEMA OPERATIVO…………………………………………………………………………... 124
[Link]. NIVEL DE HARDWARE…………………………………………………………………………………………... 125
4.2.5. USABILIDAD…………………………………………………………………………………………………………….. 125
[Link]. LA COMPLEJIDAD DE LA DESCRIPCIÓN………………………………………………………………….. 125
[Link]. CONSISTENCIA OPERACIONAL……………………………………………………………………………….. 126
[Link]. CONSISTENCIA OPERACIONAL EN EL USO…………………………………………………………….. 126
4.3. RESULTADO FINAL……………………………………………………………………………………………………… 127
CAPITULO V: ANÁLISIS DE COSTO/BENEFICIO
5.1. INTRODUCCIÓN…………………………………………………………………………………………………………. 128
5.2. ANÁLISIS DE COSTOS………………………………………………………………………………………………….. 128
5.3. ANÁLISIS DE BENEFICIOS…………………………………………………………………………………………….. 133
CAPITULO VI: CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES………………………………………………………………………………………………………….. 135
6.2. RECOMENDACIONES………………………………………………………………………………………………….. 136
REFERENCIAS……………………………………………………………………………………………………………………. 137
 ÍNDICE DE FIGURAS
Figura 2.1: Fases y Disciplinas del AUP……………………………………………………………………………………….. 18
Figura 2.2: Dirigido por Casos de Uso…………………………………………………………………………………………. 20
Figura 2.3: Dinámica del Proceso……………………………………………………………………………………………….. 20
Figura 2.4: Desarrollo Iterativo…………………………………………………………………………………………………… 21
Figura 2.5: Flujo de trabajo de la disciplina del modelo……………………………………………………………… 24
Figura 2.6: Flujo de trabajo de la disciplina de la 26
implementación……………………………………………… Figura 2.7: Flujo de trabajo de la disciplina de 28
prueba……………………………………………………………….. Figura 2.8: Flujo de trabajo de la disciplina de 30
despliegue………………………………………………………….. Figura 2.9: Flujo de trabajo de la 32
disciplina de administración de la configuración…………………….. Figura 2.10: Flujo de trabajo 34
de la disciplina de administración del proyecto…………………………….. Figura 2.11: Flujo de 36
trabajo de la disciplina del ambiente…………………………………………………………. Figura 2.12: Iteraciones 37
Production Release………………………………………………………………………………. Figura 2.13: Estilo 47
incremental iterativo del proceso de oohdm..………………………………………………. Figura 2.14: Un 48
posible diseño de clases.………………………………………………………………………………….. Figura 2.15: Un 49
posible diseño navegacional……………………………………………………………………………… Figura 2.16: Un 50
posible diseño de interfaz abstracta....………………………………………………………………. Figura 3.1: Aup y 58
Oohdm……………………………………………………………………………………………………………. Figura 3.2: 59
Combinación Aup y Oohdm………………………………………………………………………………………. Figura 3.3: 61
Diagramas de casos de uso del negocio……………………………………………………………………. Figura 65
3.4: Diagramas de casos de uso del sistema de registro y administración……………………….. 66
Figura 3.5: Casos de uso: administrar usuario……………………………………………………………………………. 68
Figura 3.6: Diagrama de casos de uso: administrar postulación…………………………………………………. 70
Figura 3.7: Diagramas de caso de uso: administrar patrocinado………………………………………………… 72
Figura 3.8: Diagramas de caso de uso: administrar historial de patrocinado……………………………… 74
Figura 3.9: Diagramas de caso de uso: reportes…………………………………………………………………………. 76
Figura 3.10: Diagrama de paquetes………………………………………………………………………………………….. 77
Figura 3.11: Diagrama de despliegue……………………………………………………………………………………….. 78
Figura 3.12: Diagrama de secuencia: autentificación…………………………………………………………………. 78
Figura 3.13: Diagrama de secuencia: administrar usuario…………………………………………………………..
Figura 3.14: Diagrama de secuencia: administrar postulante…………………………………………………….. 79
Figura 3.15: Diagrama de secuencia: administrar patrocinado…………………………………………………… 80
Figura 3.16: Diagrama de secuencia: administrar historial…………………………………………………………. 81
Figura 3.17: Diagrama de secuencia: reportes…………………………………………………………………………… 82
Figura 3.18: Diagrama de 83
clases…………………………………………………………………………………………………. Figura 3.19: Diagrama 84
entidad relación……………………………………………………………………………………… Figura 3.20: Modelo 85
físico de la base de datos…………………………………………………………………………… Figura 3.21: Modelo de 86
navegación…………………………………………………………………………………………… Figura 3.22: Modelo de 87
navegación: acceso de usuarios……………………………………………………………. Figura 3.23: Modelo 88
de presentación: página principal……………………………………………………………… Figura 3.24: Modelo 89
de presentación: administrador………………………………………………………………… Figura 3.25: Adv: 90
autenticación…………………………………………………………………………………………………. Figura 3.26: Adv: 91
principal…………………………………………………………………………………………………………. Figura 3.27: Adv: 92
menú inicio………………………………………………………………………………..…………………… Figura 3.28: Adv: 93
menú usuario…………………………………………………………………………………………………. Figura 3.29: Adv: 94
registro usuario………………………………………………………………………………………………. Figura 3.30: Adv: 95
modificación usuario………………………………………………………………………………………. Figura 3.31: Adv: 96
eliminación usuario………………………………………………………………………………………… Figura 3.32: Adv: 97
registro postulante…………………………………………………………………………………………. Figura 3.33: Adv: 98
evaluación postulante……………………………………………………………………………………. Figura 3.34: Adv: 99
registro patrocinado………………………………………………………………………………………. Figura 3.35: Adv: 100
eliminación patrocinado…………………………………………………………………………………. Figura 3.36: Adv: 101
búsqueda patrocinado……………………………………………………………………………………. Figura 3.37: Adv: 102
registro historial……………………………………………………………………………………………… Figura 3.38: Adv: 103
búsqueda y modificación de historial……………………………………………………………… Figura 3.39: Adv: 104
reporte postulante…………………………………………………………………………………………. Figura 3.40: Adv: 105
reporte historial patrocinado…………………………………………………………………………. Figura 3.41: 107
Prueba de caja negra……………………………………………………………………………………………… Figura 108
3.42: Pueba de estrés: informe agregado……………………………………………………………………….. 109
Figura 3.43: Prueba de estrés: grafico………………………………………………………………………………………..
Figura 4.1: Norma ISO-9126………………………………………………………………………………………………………. 113
Figura 4.2: Modelo web de registro y administración de documentos………………………………………. 114
 ÍNDICE DE TABLAS

Tabla 2.1: Convergencia y divergencia entre las principales metodologías agiles….. 17

…………………..
25
Tabla 2.2: Fases de la disciplina del modelo……………………………………………………………………………….
27
Tabla 2.3: Fases de la disciplina de la
29
implementación………………………………………………………………. Tabla 2.4: Fases de la disciplina de
31
prueba………………………………………………………………………………… Tabla 2.5: Fases de la disciplina de
33
despliegue…………………………………………………………………………... Tabla 2.6: Fases de la
34
disciplina de administración de la configuración……………………………………... Tabla 2.7: Fases de
36
la disciplina de administración del proyecto..……………………………………………. Tabla 2.8: : Fases
38
de la disciplina del ambiente…………………………………………………………………………. Tabla 2.9:
41
Descripción de roles de equipo…………………………………………………………………………………. Tabla 2.10:
45
Productos mínimos de entrega ………………………………………………………………………………. Tabla 2.11:
46
Requisitos de cada propuesta…………………………………………………………………………………. Tabla 2.12:
53
Orientación de propuesta………………………………………………………………………………………. Tabla 2.13:
62
Factores de calidad de software……………………………………………………………………………… Tabla 3.1:
67
Descripción de actores de caso de uso del negocio………………………………………………….. Tabla 3.2:
69
Descripción de casos de uso: administrar usuario…………………………………………………….. Tabla 3.3:
71
Descripción de casos de uso: administrar postulación…………………………………………….. Tabla
73
3.4: Descripción de casos de uso: administrar patrocinado…………………………………………….
75
Tabla 3.5: Descripción de casos de uso: administrar historial de
115
patrocinado………………………….. Tabla 3.6: Descripción de casos de uso:
117
reportes…………………………………………………………………….. Tabla 4.1: Cálculo de
118
confiabilidad……………………………………………………………………………………………. Tabla 4.2: Entrada de
118
usuario…………………………………………………………………………………………………… Tabla 4.3: Salida de
119
usuario………………………………………………………………………………………................. Tabla 4.4: Petición
119
de usuario………………………………………………………………………………………………….. Tabla 4.5:
120
Archivos…………………………………………………………………………………………………………………… Tabla 4.6:
120
Interfaces externas………………………………………………………………………………………………….. Tabla 4.7:
121
Cálculos de punto función ajustados……………………………………………………………………….. Tabla 4.8:
127
Ponderaciones…………………………………………………………………………………………………………. Tabla 4.9:
Valores de ajuste de complejidad…………………………………………………………………………….
Tabla 4.10: Resultado final……………………………………………………………………………………………………….
ix
Tabla 5.1: Procesamiento de datos punto función…………………………………………………………………… 128
Tabla 5.2: Procesamiento de datos punto función ajustada…………………………………………………….. 129
Tabla 5.3: Conversión de puntos de función……………………………………………………………………………. 130
 CAPITULO I

1.1. INTRODUCCIÓN

Desde nuestros antepasados tener información correcta fue una gran solución a todos los
problemas que el hombre requería administrar. A través del tiempo el hombre crea maneras
de tener un control, sobre la averiguación de datos mediante varios tipos de instrumentos,
donde podía plasmar su mensaje.

A través de los años el conocimiento del hombre llego a desarrollarse cada vez más, ya que
antes y en este tiempo se tiene la necesidad de la toma de decisiones para una buena
administración, pero al recabar información se llega a tener un incremento notable en los
datos y a su vez se hace muy difícil poder administrarlo.

Actualmente en Bolivia la información es muy importante para instituciones privadas y

públicas, tal es el caso de algunas instituciones que trabajan con muchos datos de personas
y llegan a tener falencias para poder manejar y obtener cierta noticia acerca de los datos de
una persona.

Algunas instituciones de ONG´s todavía siguen recepcionando información manualmente o

en programas obsoletos que ya están acostumbrados, causándoles muchas molestias
principalmente en la pérdida de tiempo al recabar esta, como en obtener un reporte
específico.

El presente proyecto se basa en solucionar los problemas que actualmente tiene la

institución CDI BO-132(Centro de Desarrollo Integral de Bolivia), donde se presta ayuda a
niños, adolescentes y jóvenes de bajos recursos, y que en estos momentos viene tropezando
con dificultades en la gestión de información sobre patrocinados que manipulan para tener
en orden toda su documentación y posteriormente realizar decisiones para el bien estar de
los niños, adolescentes y jóvenes acogidos
El CDI BO-132 para su mejor funcionamiento se dividió en varias áreas, pero el siguiente
proyecto solo tomara en cuenta el área de patrocinio que dará solución a los problemas que
actualmente sufre la institución.

Por este motivo se requiere desarrollar un sistema de gestión de información sobre

patrocinados que dará respuesta a todas éstas necesidades, diseñando y construyendo un
sistema especializado de acuerdo con las demandas y requerimientos, presentados por la
institución CDI BO-132.

[Link]
1.2.1. ANTECEDENTES INSTITUCIONALES

El CDI BO-132(Centro de Desarrollo Integral de Bolivia), inicio sus actividades en el año

1997 aproximadamente por los meses de marzo y abril con 21 patrocinados entre las edades
de 5 y 7 años, siendo la primera tutora la Hna. Rogelia Sirpa, cocinera Hna. Felicidad de
Justo y el director el Hno. Félix Mamani llegando a dirigir por cuatro años y medio el
centro CDI BO-132.

Desde entonces el centro creció llegando a tener a niveles por programas con los
triunfadores desde los 3 a 13 años y los restauradores de 14 a 18 años, también existe un
programa para jóvenes, que se ejecuta después de haber culminado el programa de ayuda
que presta el CDI BO-132, que se inicia a los 5 años de edad y culmina a los 18 años,
haciendo un acto de graduación, posteriormente es cuando ingresan al siguiente programa
que es el ELDP. El trabajo que realiza está dividido en tres áreas:

Formación cristiana con el enfoque bíblico, valores de acuerdo a fichas elaboradas, Salud
que toma en cuenta la salud del niño, hábitos de alimentación e higiene
Apoyo escolar donde se evidencia las estrategias de aprendizaje, nivel educativo escolar,
donde las dudas escolares son reforzadas por sus respectivos tutores.

2
En el siguiente organigrama de la institución se puede ver el personal que trabaja
actualmente (Ver Figura 1.1)
CDI BO-132
Centro de Desarrollo Integral

PASTOR PRESIDENTE
Rev. Willy Aliaga

COMITÉ FISCALIZADOR

Hno. Jaime Canaza Hno. Clemente Huanca Hno. Nilton Agno

ADMINISTRACIÓN
Hna. Maribel Quenta

RESPONSABLE DE RESPONSABLE DE
PROGRAMAS PATROCINIO
Hno. Sonia Chipana Hna. Yolanda Ríos

TUTORES

Hna. Hna. Lidia Hno. José Hna. Lidia

Antonia Mamani Pomacosi Luis Valdez Quispe de Agno

COCINERAS

Hna. Hna. Hna.

Germania Mamani Máxima Churqui Rosmery Quelca

Figura 1.1. Organigrama CDI BO-132

Fuente: Elaboración Propia
El CDI cuenta como brazo social de la iglesia Ministerio Roca Eterna, que va desarrollando
un trabajo de desarrollo integral con los niños y adolescentes, aplicando programas, valores
y principios bíblicos, para formar individuos de carácter de servicio. Beneficiando a los
niños y adolescentes con desventaja social y económica, frente a cualquier tipo de maltrato,
con valores cristo céntricos en integridad y humildad, que reflejan a la comunidad del reino
de Dios.

El centro cuenta actualmente con más de 540 niños y adolescentes de los cuales están
divididos por edades y en dos paralelos de lunes a miércoles y de jueves a sábado, un turno
en la mañana y otro en la tarde. Los requisitos para el ingreso son de acuerdo a
cronogramas y revisión de documentos, niños de familias de bajos recursos de acuerdo a un
estudio social, tener edades entre 3 a 8 años.

El CDI BO-132 tiene en la actualidad 12 años de funcionamiento pasando por sus

direcciones dos directores: Hno. Félix Mamani en los años 1997 y primer semestre del
2001, Hno. Mateo Vargas segundo semestre del 2001 hasta el 2007 y en la actualidad Hna.
Maribel Quenta.

La administración del CDI BO-132 actualmente cuenta con un director, un responsable del
área de patrocinio, un responsable de trabajo social, los cuales interactúan de acuerdo al
trabajo realizado.

Para empezar se hace un pre registro donde se recepciona la solicitud de ingreso al CDI, en
donde el responsable del área de patrocinio verifica los datos, incorporando una ficha social
a cada registro, el responsable de trabajo social registra la ficha social de evaluación y
posteriormente el director emite un informe a las oficinas centrales.

Una vez aceptado el niño a patrocinar se efectúa el proceso de registro habiendo recabado
la documentación pertinente, lo cual se hace moroso ya que se lo realiza en planillas de
Excel, la cual no está bien especificada al momento de hacer la entrada de datos de cada
requisito. Una vez llenado fácilmente no se la puede llegar a actualizar, por lo que al
momento de hacer
la búsqueda de información de un patrocinado, este se hace inexistente o la documentación
del niño se encuentra incompleta, además que el responsable del área de patrocinio no
puede llegar a tener con exactitud un reporte puntual y actualizado, para dar un informe a la
administración.

En todas las direcciones anteriores, se tuvo muchas falencias en cuanto a información de

patrocinados, actualmente se tiene una herramienta diseñada en Excel, pero se presentan
nuevos problemas como ser:
 Perdida de información.
 No se llega a actualizar debidamente.
 La administración de datos es retardada.
 Nueva recopilación de documentación.
 No se pueden sacar reportes actuales ni a tiempo.
 No se presentan alertas de aviso, para que el responsable pueda anunciar al
patrocinado que es lo que le falta entregar en cuanto a documentación.

Por este motivo es que la institución ve como necesidad inmediata desarrollar un sistema de
gestión de información sobre patrocinados, que podrá solucionar de gran manera estos
problemas, por otro lado los padres podrán ver anuncios, que la institución requiera
informar, como también lo referido a cada uno de sus hijos, de manera inmediata sin la
necesidad de presentarse en la institución, además de que el sistema brindará rapidez en la
atención, otorgando mayor prestigio a la institución.

1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES

En la universidad Mayor de San Andrés, carrera de Informática se puede verificar la

existencia de algunos proyectos de grado realizados anteriormente relacionados con el
presente proyecto.

Los proyectos que se asimilan al presente son los siguientes:

 Sistema web de administración de la información y la comunicación para la
gestión educativa del colegio Internacional del sur, elaborado por Mamani Sullcata,
Marco Antonio, publicado en 18-Sep-2012. La educación demanda de la tecnología
herramientas de acción para la gestión. La flexibilidad de las Tecnologías de la Información
y Comunicación brindan la posibilidad, a la gestión educativa, de contar con información
oportuna para el análisis de resultados, anticipar y predecir posibles campos de acción, la
innovación tecnológica y la toma de decisiones contribuyendo al desarrollo de una
educación de calidad. El presente proyecto, plantea una herramienta de solución a los
requerimientos de la gestión educativa. En base a información clara, flexible y concisa,
permite realizar el seguimiento y control del rendimiento de los estudiantes y las
actividades del proceso de enseñanza y aprendizaje, centrando los datos sobre los actores
educativos. El capítulo I, es el marco referencial donde se realiza el análisis de la
problemática y fundamentado en los antecedentes se plantean los objetivos y límites para el
desarrollo del proyecto. En el capítulo II, se presenta el análisis de los fundamentos teóricos
que permiten llevar a cabo el desarrollo del proyecto. El capítulo III, se realiza la
construcción, implementación y evaluación del sistema propuesto. Finalmente el capítulo
IV presenta las conclusiones del trabajo desarrollado y las recomendaciones para la
implementación de futuros proyectos del ámbito.
 Sistema web de registro, control y seguimiento de los procesos de auditoría
interna CASO: SENAPE Servicio Nacional de Patrimonio del Estado, elaborado por
Quispe Apaza, Santos, publicado en 29-Oct-2012. Hoy en día, resulta casi indiscutible
considerar que el estado Plurinacional y las Entidades Públicas cumplen un papel
fundamental en todo el proceso de cambio de un país. Muchas veces debe liderar los
procesos de cambio, transformándose en una especie de Usuario – Modelo. El presente
Proyecto de Grado titulado “Sistema web de registro, control y seguimiento de los procesos
de Auditoria Interna” ha sido desarrollado en SENAPE (Servicio Nacional de Patrimonio
del Estado) para la Unidad de Auditoria Interna, con el objetivo de automatizar los procesos
y optimizar los tiempos de insumo en una auditoria ya que en gestiones pasadas los
procesos se hacían de forma manual. Para el desarrollo del proyecto se utilizó la
metodología Ágil SCRUM, que propone un modelo de proceso incremental, basado en
iteraciones y revisiones continuas.
También se utilizó en cada una de las 4 iteraciones la metodología UWE, que se especializa
en el diseño de Aplicaciones Web. Para la conclusión del desarrollo de sistema Web se
utilizó como herramienta primordial el lenguaje de programación PHP, con el gestor de
base de datos Postgres y con la ayuda principal del Servidor Apache para la función
correcta del sistema.
 Sistema de información vía web CASO: Institución GAMMA, elaborado por
Ayoroa Ocaña, Juan Cesar, publicado en 28-Nov-2012. El desarrollo del presente proyecto
aplica los aportes que tienen el uso de nuevas tecnologías, y el uso de reglas semánticas
para la búsqueda de información dentro de una base de datos, por otra parte tiene un porte
muy significativo hacia la sociedad y el mundo de la agroecología, así haciendo que esta
información sea compartida con el resto de personas muy acordes a la temática, como
estudiantes. No podemos dejar de lado los términos de seguridad y las diferentes ISOS a
cumplir para que el proyecto sea de calidad y cumpla con todas las normativas planteadas
por ley, como también hay que resaltar que el sistema es muy intuitivo para el uso de
cualquier tipo de usuario, esto debido a que el sistema está más orientado a las personas
dedicadas al agro, esto gracias a las nuevas herramientas de diseño como el uso de CSS y la
Hipermedia, que además de dar un buen diseño facilitan la actualización o cambios para
tener una mejor navegabilidad. Por otra parte la información publicada en este sistema es
precisa y oportuna debido a que el contenido es actualizado de manera dinámica, como
también la administración se la lleva de la misma manera, ya que cuenta con una base de
datos adecuada a la institución.

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. PROBLEMA CENTRAL

El problema que atraviesa la institución CDI BO-132 en estos momentos, es la falta de un

sistema, donde se puede solucionar, la deficiencia y demora sobre un registro,
administración y búsqueda de información acerca de cada patrocinado.

En consideración en lo expuesto anteriormente se plantea el siguiente problema.

¿De qué manera se puede ayudar y mejorar el registro y administración de la
información de niños patrocinados de la institución CDI BO-132, para que sea de
manera puntual y actualizada?

1.3.2. PROBLEMAS SECUNDARIOS

De esta manera y en función al árbol de problemas (Ver Anexo A) se puede evidenciar los
siguientes problemas como ser:

 Pérdida de tiempo al momento de recabar información de cada patrocinado ya

almacenado, recolectando esta nuevamente.
 Duplicidad de datos de los patrocinados al momento de hacer un registro
provocando una confusión al momento de extraer un reporte.
 Documentación de los beneficiados a este centro, desactualizados que conduce a un
mal conocimiento y la mala manipulación de ellos.
 Gran cantidad de referencia de patrocinados almacenada, provocando una gran
congestión y demora al momento del registro.
 Demora en la búsqueda de detalles específicos del niño o adolescente, produciendo
pérdida de tiempo al momento de volver a recabar nueva documentación.
 Inexistencia de informes oportunos o alertas tempranas causando un listado
incorrecto de documentación faltante del patrocinado.

1.4. DEFINICIÓN DE OBJETIVOS

1.4.1. OBJETIVO GENERAL

De acuerdo a los problemas que se tienen actualmente en el centro de desarrollo integral, se

llega a generar lo siguiente:

Desarrollar un sistema web para el registro y administración de documentos de niños

patrocinados para la institución CDI BO-132, que ayude a tener una información de
manera puntual, actualizada y además mejorando el tiempo de procesamiento.
1.4.2. OBJETIVOS ESPECÍFICOS

 Construir un módulo de registro de la información del postulante, patrocinado y

registrar está en una base de datos para determinar los datos adecuados, que
mejorara la organización, registro de documentación y reportes.
 Efectuar un módulo de eliminación, para descartar duplicidad de datos del
patrocinado al momento de hacer un registro, mejorando el control de todo lo
recabado y evitando perdida de datos.
 Elaborar el módulo de historial, para mantener la documentación de los
beneficiados, actualizada sistematizada y automatizada, provocando facilidad al
momento de realizar una búsqueda.
 Desarrollar un módulo de búsqueda y así minimizar la redundancia de referencia de
patrocinados y exceso de documentación, para luego tener una mayor facilidad en la
obtención de datos específicos.
 Eliminar errores cometidos al momento de transcripción y actualizar las mismas
teniendo un mejor control en las actualizaciones.
 Realizar un módulo de reportes e informes precisos y oportunos generando toda la
documentación.

1.5. JUSTIFICACIÓN
1.5.1. JUSTIFICACIÓN ECONÓMICA

Al implementar un sistema web para el registro y administración de documentos de niños

patrocinados, este minimizará el costo asociado al tiempo de obtención de datos de los
mismos, mediante una herramienta útil mejorando el control y toma de decisiones,
reduciendo la cantidad de papeles que se genera en el proceso de recolección doble de
documentación por información perdida, que da como resultado una eficaz administración
de los recursos económicos, que son destinados a distintas actividades y reduciendo gastos
innecesarios además del tiempo de trabajo de los administradores del área de patrocinio.
1.5.2. JUSTIFICACIÓN SOCIAL
El CDI BO-132(Centro de Desarrollo) es una institución netamente de carácter social
reconocido por la comunidad por la excelencia en la aplicación de los programas y
servicios dirigidos a los niños con necesidad.
Por lo que el presente sistema mejorara las condiciones de trabajo del personal
administrativo que maneja el área de patrocinio como también a los patrocinados haciendo
más fácil el proceso de entrega de documentación como el seguimiento de desarrollo del
niño o joven, plan de vida, salud y otros. Además que se podrá adecuar a las demás
instituciones que desprenden de Compassion Internacional que trabaja en más de 20 países.

1.5.3. JUSTIFICACIÓN TECNOLÓGICA

En el mundo, la tecnología avanza cada vez más y es ilógico estar al margen de este
avance, es por eso que la institución contara con este sistema. Actualmente la institución
cuenta con equipos informáticos en ambientes propios de los administradores, para el
desarrollo del presente sistema que ayudara al mejor desempeño de la institución como del
personal administrativo y favorecer a la sociedad involucrada para un mejor servicio.

1.6. ALCANCES Y LÍMITES

1.6.1. ALCANCES

El alcance del Sistema de gestión de Información sobre patrocinados del CDI BO-132,
comprende los siguientes módulos que se esclarecerán a continuación:

 Módulo de Usuarios que contendrá la administración del sistema, en donde se

podrá realizar:
 Registro de usuario.
 Modificación de usuario.
 Eliminación de usuario.
 Módulo de Registro Postulante que será donde se registrara por primera vez al
postulante, donde se podrá realizar lo siguiente:
  Registro de Postulante.
 Evaluación Postulante.

 Módulo de Registro Patrocinado que será donde se registrara por primera vez al
patrocinado, donde se podrá realizar lo siguiente:
 Actualización de datos.
 Búsqueda de patrocinado.
 Eliminación de patrocinado.

 Módulo de Reportes que será donde se evidenciará las observaciones que

brindaran información oportuna relacionada con los datos generales del patrocinado.
 Impresión de datos del Postulante.
 Impresión de datos del historial del patrocinado.
 Datos estadísticos.

 Módulo de historial para cada patrocinado que contendrá información referente al

seguimiento de desarrollo de que cada patrocinado.
 Registro de historial.
 Edición de Historial.
 Búsqueda de Historial.

1.6.2. LÍMITES
El presente proyecto, está limitado al manejo de información del área de patrocinio, en este
momento lo siguiente es lo que el sistema no llega a realizar:

 No tiene la finalidad de aumentar la confiabilidad y prestigio del CDI, en los

procesos de gestión de información del patrocinado.
 No permite al administrador interactuar y actualizar datos del niño y/o adolescente
mediante mecanismos. No se garantiza confidencialidad de la información de estos
en forma segura.
  El patrocinado y sobre todo los padres, no están informados sobre la
documentación, que mantiene en ejecución en forma continua.

1.7. APORTES
1.7.1. PRÁCTICO

El principal aporte que aquí se tiene, es el sistema de gestión de información sobre

patrocinados, donde se realizara los diferentes módulos, para su respectiva utilización en la
institución, donde se podrá evidenciar los reportes para las tomas de decisiones, de acuerdo
a los objetivos planteados en la institución. Además que se contara con la seguridad en el
manejo de información, automatización y agilización de los documentos entregados en los
procesos manuales, respuestas inmediatas de acuerdo a los distintos requerimientos,
reducción de tiempo al momento de un respectiva búsqueda y una respectiva capacitación
al personal necesario.

1.7.2. TEÓRICO

En el presente proyecto el aporte que generara, será el de establecer un métrica de

automatización la cual permitirá comprender en que media el programa anterior se ha
automatizado al nuevo sistema informático, mediante dos variables tiempo y esfuerzo del
procesamiento de la información, además que será novedoso en realizar alertas al
administrador que saltaran a la vista para que fácilmente pueda evidenciar que es lo que no
se está actualizando en la información de un patrocinado, donde será fácilmente
comprobado.

1.8. METODOLOGÍA

El objetivo del análisis es el de desarrollar un modelo de funcionamiento del sistema

informático donde se satisfaga las necesidades del CDI BO-132.
Metodología de investigación científica
Tiene como finalidad el alcance de la efectiva técnica mediante el ajuste de las ideas que van
a los hechos, para lo cual utiliza las entrevistas y encuestas.
Tipo de Investigación
El tipo de investigación es descriptiva, ya que conoce la descripción, registro, análisis e
interpretación del medio actual, en donde la intención es la de presentar una definición
correcta del objeto de estudio.

AUP (Proceso Unificado Ágil de Scott Ambler) se preocupa especialmente de la gestión de

riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso
de desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean y
mantienen listas identificando los riesgos desde etapas iníciales del proyecto.
Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables durante la
base de elaboración del producto, donde se demuestre la validez de la arquitectura para los
requisitos clave del producto y que determinan los riesgos técnicos.

El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que
reúne en una única disciplina las disciplinas de Modelado de Negocio, Requisitos y
Análisis y Diseño. El resto de disciplinas (Implementación, Pruebas, Despliegue, Gestión
de Configuración, Gestión y Entorno) coinciden con las restantes de RUP.

Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de manera
consecutiva y que acaban con hitos claros alcanzados:

 Incepción (Concepción).
 Elaboración.
 Construcción.
 Transición.

Las disciplinas se llevan a cabo de manera sistemática, y estas son:

 Modelo.
 Aplicación
 Prueba
 Despliegue
 Gestión de configuración
 Gestión de proyectos.
 Entorno

OOHDM (Object Oriented Hypermedia Design Methodology), se aplica el modelo para

la parte Web, la misma que propone 4 etapas para su proceso:

a) Diseño Conceptual Se construye los objetos de dominio o clases (Modelo

Entidad/Relación) y las relaciones entre objetos.

b) Diseño Navegacional Se define las clases navegacionales (nodos, enlaces y

estructuras de acceso)

c) Diseño de interfaces abstractas Se desarrollan los objetos de interfaz, que

activarán la navegación y el resto de funcionalidades de la aplicación web.

d) Implementación Etapa donde se hace corresponder los objetos de interfaz con los
objetos de implementación.

Los sistemas pueden variar el entorno y las relaciones que existe entre personas, por lo que
es sumamente necesario identificar a todas las personas que interactúan y verificar las
necesidades que tienen, se pueden evidenciar diferentes técnicas para obtener los requisitos
del usuario como por ejemplo:

Entrevistas: que son más efectivas ya que no se da la entrevista a todos sino solamente a un
respectivo sector que sería a los que interactuarán con el sistema.

Encuestas: que por lo general son llenadas a mano pero donde se utilizan preguntas
cerradas para un determinar un respectivo rango en la información recepcionada.

El lenguaje de programación a utilizar será PHP, base datos MYSQL, y algunas

herramientas de programación como java script.
 CAPITULO II

MARCO TEÓRICO

En el presente capitulo, se dará a conocer los fundamentos teóricos, para la realización del
actual proyecto, donde se definira conceptos, se establecerá método, metodología, técnicas
y herramientas convenientes en el desarrollo del sistema.

2.1. INGENIERÍA DEL SOFTWARE

Se define al término de ingeniería en el DRAE como el “conjunto de conocimientos y

técnicas que permiten aplicar el saber científico a la utilización de la materia y de las
fuentes de energía”. [PRESS, 03]

Software según la definición del Institute of Electrical and Electronics Enginieers (IEEE),
“es la suma total de todos los programas de computadora, procedimientos, reglas la
documentación asociada y los datos que pertenecen a un sistema de cómputo” y “un
producto de software es un producto diseñado para un usuario”.

En este contexto la “ingeniería de software es la rama de la ingeniería que aplica los

principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-
efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software”, es
decir, “permite elaborar consistentemente productos correctos, utilizables y costo-
efectivos”.

La evolución de la disciplina de ingeniería de software ha traído consigo propuestas

diferentes para mejorar los resultados del proceso de construcción. Las metodologías
tradicionales haciendo énfasis en la planeación, mientras las metodologías agiles haciendo
énfasis en la adaptabilidad del proceso, delinean las principales propuestas presentes en la
literatura.

De manera paralela, el tema de modelos para el mejoramiento de procesos de desarrollo

ocupa un lugar muy importante en la búsqueda de la metodología adecuada para producir
software de calidad en cualquier contexto de desarrollo. [Letelier P, Penades Carmen,
2005]
2.2. METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y

ayudas a la documentación para el desarrollo de productos de software. Es como un libro de
recetas de cocina, en el que se van mostrando paso a paso todas las actividades a realizar
para lograr el producto informático deseado, indicando además que personas deben
participar en el desarrollo de las actividades y que papel deben desempeñar. Además se
detalla la información que se debe producir de una cierta actividad y la información
necesaria para comenzarla.

Se puede mencionar los métodos que están dentro de las metodologías de desarrollo de
software como ser: iterativos, evolutivos y agiles.

2.2.1. METODOLOGÍAS AGILES

Las metodologías ágiles de desarrollo de software, conocidos anteriormente como

metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las
metodologías tradicionales enfocándose en la gente y los resultados.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en

el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de
desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de
tiempo. Las metodologías de desarrollo de software agiles son vistas de la siguiente
manera:

 El software desarrollado en una unidad de tiempo es llamado una iteración, la cual

debe durar de una a cuatro semanas.
 Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos,
diseño, codificación, revisión y documentación.
 Una iteración no debe agregar demasiada funcionalidad para justificar el
lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al
final de cada iteración.
 Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.
Los métodos Agiles enfatizan principalmente:
 Las comunicaciones cara a cara en vez de la documentación.
 La mayoría de los equipos Agiles están localizados en una simple oficina abierta, a
veces llamadas "plataformas de lanzamiento" (bullpen en inglés).
 La oficina debe incluir revisores, diseñadores de iteración, escritores de
documentación y ayuda y directores de proyecto.
 El software funcional es la primera medida del progreso.

Combinado con la preferencia por las comunicaciones cara a cara, generalmente los
métodos ágiles son criticados y tratados como "indisciplinados" por la falta de
documentación técnica.

En la siguiente tabla se puede observar la convergencia y divergencia entre las principales

metodologías agiles. (Ver Tabla 2.1)

Tabla 2.1. Convergencia y Divergencia entre las principales metodologías agiles.

Fuente: J. Muñoz, 2000

2.2.2. PROCESO UNIFICADO ÁGIL (AUP)

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible

que puede ser adaptado a organizaciones o proyectos específicos. [Ambler S, 2005]
AUP nace en 2005 en manos del desarrollador Scott W. Ambler el cual lo define de la
siguiente manera: El proceso unificado ágil (AUP) es un desarrollo de programas basado en
el proceso unificado racional de IBM (RUP). El ciclo vital de AUP es en serie en lo grande,
iterativo en lo pequeño, entregando productos incrementales en un cierto plazo.

Es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una
manera simple y fácil de entender la forma de desarrollar aplicaciones de software de
negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP
aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas.

En la siguiente figura se observa las fases, disciplinas e iteraciones correspondientes. (Ver

Figura 2.1).

Figura 2.1. Fases y Disciplinas del AUP

Fuente: Ambler S, 2005
2.2.3. PRINCIPIOS DEL AUP

El AUP es ágil, porque está basada en los siguientes principios:

 El personal sabe lo que está haciendo: La gente no va a leer detallado el proceso

de documentación, pero algunos quieren una orientación de alto nivel y / o
formación de vez en cuando. La AUP producto proporciona enlaces a muchos de los
detalles, si usted está interesado, pero no obliga a aquellos que no lo deseen.
 Simplicidad: Todo se describe concisamente utilizando poca cantidad de páginas,
no miles de ellos.
 Agilidad: Se ajusta a los valores y a los principios de la Alianza Ágil.
 Poner importancia a actividades de alto valor: La atención se centra en las
actividades que se ve que son esenciales para el de desarrollo, no todas las
actividades que suceden forman parte del proyecto.
 Independencia de la herramienta: Usted puede usar cualquier conjunto de
herramientas que usted desea con el ágil UP. Lo aconsejable es utilizar las
herramientas que son las más adecuadas para el trabajo, que a menudo son las
herramientas simples o incluso herramientas de código abierto.
 Adaptación de este producto para satisfacer sus propias necesidades: La AUP
producto es de fácil acomodo común a través de cualquier herramienta de edición
de HTML. No se necesita comprar una herramienta especial, o tomar un curso, para
adaptar la AUP.

2.2.4. CARACTERÍSTICAS DE LA AUP

Se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser
iterativo e incremental.

 Dirigido por Casos de Uso Se centra en la funcionalidad que el sistema debe

poseer para satisfacer las necesidades de un usuario (persona, sistema externo,
dispositivo) que interactúa con él. Casos de uso como el hilo conductor que orienta
las actividades de Desarrollo. (Ver Figura 2.2)
 Figura 2.2: Dirigido por Casos de Uso
Fuente: Ambler S, 2005

 Centrado en la Arquitectura Concepto similar a la arquitectura de un edificio,

arquitectura en software, arquitectura: determina la forma del sistema, casos de uso:
determinan la función del sistema.
 Iterativo e Incremental. Descomposición de un proyecto grande en mini-proyectos,
cada mini-proyecto es una iteración, las iteraciones deben estar controladas, cada
iteración trata un conjunto de casos de uso
 Dimensión Dinámica del proceso

Hito: punto en el tiempo donde se evalúan los objetivos logrados y se pueden tomar
decisiones críticas. (Ver Figura 2.3)

Figura 2.3: Dinámica del proceso

Fuente: Ambler S, 2005
 Desarrollo Iterativo se puede observar en la siguiente figura los pasos a seguir para el
desarrollo. (Ver Figura 2.4)

Figura 2.4: Desarrollo Iterativo

Fuente: Ambler S, 2005

2.2.5. FASES DEL AUP

AUP cuenta con las siguientes fases:

[Link]. PRIMERA FASE: CONCEPCIÓN

Identificar el alcance inicial del proyecto, proveer una arquitectura potencial para el sistema,
y obtener un financiamiento inicial del proyecto y la aceptación de los stakeholders.

 Visión = QUÉ + PARA QUÉ + CUÁNTO

• Actividades
 Especificación de los criterios de éxito del proyecto
 Definición de los requisitos
 Estimación de los recursos necesarios
 Cronograma inicial de fases.

• Artefactos (Pieza de información producida, modificada y utilizada en un Proceso)

 Documento de definición del

proyecto Hito: Objetivos del ciclo de vida

(LCO).
[Link]. SEGUNDA FASE: ELABORACIÓN

Obtener la arquitectura del sistema.

• Actividades
 Análisis del dominio del problema

 Definición de la arquitectura básica

 Análisis de riesgos

 Planificación del proyecto

• Artefactos
 Modelo del dominio

 Modelo de procesos

 Modelo funcional de alto nivel

 Arquitectura básica

Hito: Arquitectura del ciclo de vida (LCA).

[Link]. TERCERA FASE: CONSTRUCCIÓN

Implementar un software sobre una base incremental la que debe estar relacionada con los
objetivos de los involucrados.

Actividades
 Análisis
 Diseño
 Implementación / Codificación
 Pruebas (individuales, de
integración) Hito: Capacidad operacional
inicial (IOC).
[Link]. CUARTA FASE: TRANSICIÓN

Validar y entregar el sistema en un ambiente de producción.

El sistema se lleva a los entornos de preproducción donde se somete a pruebas de validación

y aceptación y finalmente se despliega en los sistemas de producción.

Actividades
 Test del sistema
 Test de usuarios
 Retrabajo del sistema
 Instalación del sistema

Hito: Lanzamiento del producto (PR).

2.2.6. DISCIPLINAS DEL AUP

Definen actividades que el equipo de desarrolladores debe realizar para construir, validar y
entregar un software que satisfaga las necesidades de los stakeholders.

Las disciplinas son ejecutadas en una forma iterativa, definiendo las actividades que el
equipo de desarrollo ejecuta para construir, aprobar y liberar software funcional, el cual
cumple con las necesidades del usuario.

[Link]. DISCIPLINA DEL MODELADO

Su objetivo principal es identificar una estrategia de arquitectura viable, entrada crítica

dentro del plan del proyecto tanto como en el esfuerzo de implementación. La mejor forma
de trabajo es poner personal técnico, incluyendo algunos sino todos los desarrolladores,
juntos en un lugar para desarrollar una estrategia de arquitectura que se discute en las
pizarras creando diagramas de estilo libre quizás algún tipo de forma inicial de modelo de
despliegue.

De los cuales se llega a observar dos casos como ser el flujo de trabajo y la fase por fase, a
continuación se detalla lo mencionado.
a) Flujo de Trabajo

Figura 2.5. Flujo de trabajo de la Disciplina del modelado

Fuente: Ambler S, 2005
a) Fase por Fase

En la siguiente tabla se muestra la disciplina del modelado. (Ver Tabla 2.2)

Fases Actividades
 Explorar el uso de casos de uso.
 Identifique los procesos del negocio para la creación de diagramas de flujo
de datos (DFDs).
 Identifique las entidades principales del negocio y sus relaciones
Inicio

trabajando con modelos de dominio livianos.

 Identifique las principales reglas del negocio y requerimientos técnicos
 Inicie el desarrollo de un glosario que describa términos importantes
técnicos y del negocio.
Elaboración

 Identificar riesgos técnicos.

 Modelado de la Arquitectura
 Prototipito de interfaces de usuario.

Análisis de modelo de lluvia de ideas.

 Participación activa de interesados y modelado inclusivo que usan
técnicas y herramientas simples que son críticas para su negocio.
 Si lo desea, puede profundizar en los detalles de sus casos de uso.
 Explore las reglas del negocio y los requerimientos técnicos en la misma
forma.
 Puede que necesite hacer interfaces de activos legados tales como
sistemas actuales o una base de datos.
 En lugar de las descripciones de casos de uso, de reglas del negocio y de
requerimientos técnicos, usted puede encontrar más efectivo simplemente
escribir casos de prueba de aceptación.
 Mantenga su glosario del proyecto actualizado si lo tiene.
 Diagrama de secuencia de UML.
 Modelo de despliegue.
 Diagramas de estilo libre.
 Documentos de resumen del sistema típicamente incluyen diagramas de
estilo libre.
 Modelo de amenazas de seguridad.
 Modelo físico de datos.
 Documento crítico decisiones de diseño.
 Transición
Modelado de lluvia de ideas.
Finalice la documentación de resumen del sistema

Tabla 2.2: Fases de la disciplina del modelado

Fuente: Ambler S, 2005

[Link]. DISCIPLINA DE LA IMPLEMENTACIÓN

Transformar los modelos en código ejecutable y aplicar pruebas básicas en unidades

particulares de prueba.

a) Flujo de Trabajo

Figura 2.6: Flujo de Trabajo de la Disciplina de la implementación

Fuente: Ambler S, 2005
b) Fase por Fase

Fases Actividades

Inicio Prototipado técnico

Prototipado de Interfaces de Usuario. Para más usuarios las interfaces
de usuario (UI) -- pantallas, reportes, y manuales-- en el sistema.

Elaboración Probar la arquitectura. Las actividades críticas dentro de la fase de

Elaboración es identificar la arquitectura potencial y luego probar que esta
arquitectura funcione a través del desarrollo de la arquitectura del prototipo
extremo a extremo para su sistema, y a la vez mitigando gran parte de los riegos
técnicos en su proyecto.

Construcción Primeras pruebas. Obtenga un acercamiento de la base del Desarrollo Dirigido

por Pruebas (TDD) para todos los aspectos de la aplicación.

Construya constantemente. Creaciones diarias son un buen comienzo, pero

idealmente usted quiera construir su sistema cada vez que el código fuente
cambie.

Evolución de la lógica de dominio. Implemente su lógica del negocio in sus

clases de negocio/dominio.

Evolucionar las interfaces de usuario. La interface de usuario es el sistema

para la mayoría de usuarios.

Evolucionar el esquema de datos. Su esquema de datos debe ir evolucionado

en conjunto con su dominio y código de interfaces de usuario.

Desarrollo de interfaces de activos existentes. Necesitará acceder

frecuentemente a la funcionalidad dentro de los sistemas existente.

Generar el script de conversión de datos. Deberá a menudo acceder a las

fuentes de datos actuales.

Transición Corregir defectos. Concéntrese en la corrección de defectos encontrados como

resultado de las pruebas.

Tabla 2.3: Fases de la disciplina de implementación

Fuente: Ambler S, 2005
[Link]. DISCIPLINA DE PRUEBA

Realizar una evaluación objetiva para asegurar la calidad. Esto incluye encontrar defectos,
validar que el sistema funcione como fue diseñado, y verificar que los requerimientos estén
abordados por las funcionalidades.

a) Flujo de Trabajo

Figura 2.7: Flujo de Trabajo de la disciplina de Prueba

Fuente: Ambler S, 2005
b) Fase por Fase

Fases Actividades

Inicio Planificación inicial de pruebas. Deben ser a muy alto nivel al principio.

Exanimación inicial de los productos de trabajo del proyecto

Exanimación inicial de modelos. A un alto nivel

Elaboración Validación de la Arquitectura. Usted debe tomar un enfoque de desarrollo
controlado por pruebas (TDD) para construir su prototipo técnico el cual
compruebe la arquitectura de su sistema.

Evoluciones su modelo de pruebas. Su equipo deberá desarrollar un paquete

de pruebas de regresión.
Construcción Pruebas de software. Además de las unidades de prueba de los
desarrolladores deberá hacer pruebas de instalación del script de despliegue o
liberación, sistema de pruebas de esfuerzos tales como la carga / pruebas de
tensión y las pruebas de función, y sus pruebas de aceptación de
usuario. Debido a que su sistema evoluciona a través de sus proyectos, su
paquete de pruebas también lo hará. Lo más común es que promueva su
código en un ambiente de pruebas de pre-producción, lo mejor de la fase de
Transición serán las actividades de prueba.

Evolucione su modelo de pruebas. Ver arriba.

Transición
Validación del sistema. Usted se concentrará en las "grandes pruebas" de
actividades tales como las del sistema, las de integración y las de aceptación,
y las pruebas piloto/beta. Su objetivo es probar completamente el sistema
dentro del ambiente de pruebas de pre-producción.

Validación de la documentación. Su documentación de sistema (vista

general del sistema, usuarios, soporte, y documentación de operaciones), y
sus materiales de capacitación necesitará validarlos. Todo esto puede ser
hecho por medio de las revisiones o mejor aún como parte de sus pruebas
piloto/betas.

Analice su modelo de pruebas. Va a tener que seguir ejecutando de paquete

de pruebas de regresión y actualizarlo tanto como necesite, hasta que su
sistema esté listo para ser desplegado en producción.

Tabla 2.4: Fases de la disciplina de prueba

Fuente: Ambler S, 2005
[Link]. DISCIPLINA DE DESPLIEGUE

Planificar la entrega del sistema y ejecutar el plan para que el sistema esté disponible para
los usuarios.

a) Flujo de trabajo En la siguiente figura se describe todo el flujo de trabajo de la

disciplina de despliegue. (Ver Figura 2.8)

Figura 2.8: Flujo de trabajo de la disciplina de Despliegue

Fuente: Ambler S, 200
 b) Fase por Fase

Fases Actividades
Inicio Identificar el rango liberación potencial. Por ejemplo, se le solicita entregar su
sistema antes de que finalice el año.

Comience con un plan de entregables de alto nivel. Este esfuerzo se debe

enfocar en planificar los entregables de su sistema, identificando el rango de
liberación potencial.
Elaboración Actualizar el plan de implementación. Una parte importante de definir la
arquitectura es definir la configuración de los entregables del sistema.
Construcción Desarrollar el script de instalación. Como desarrolla el sistema debe también
escribir y probar el script de instalación necesario para entregarlo en el pre
producción del ambiente de pruebas.

Desarrollar notas del entregable. Sus notas de entregables deben resumir los
avances que posee el entregable actual del sistema que actualmente está
construyendo.

Desarrollar documentación inicial. Además de entregar software funcional,

también se debe entregar la documentación del sistema (operaciones, soporte,
visión general, y la documentación al usuario), así como su material de
formación.

Actualice su plan. De manera cómo progrese el desarrollo del sistema, debe

avanzar su plan de implementación.

Implementar el sistema en entornos de pre-producción. Debe entregar

regularmente el sistema en un ambiente de pre-producción para efectuar pruebas
y llevar a cabo el control de calidad necesario, así como realizar demostraciones
a los involucrados.
Transición Concluir el proceso de implementación. Para concluir este proceso debe
definir una línea base de entrega como referencia, las actividades de la
administración de la configuración, y realizar una "última" revisión de software,
así como la implementación del flujo de trabajo.

Finalizar la documentación. La mayor parte de la documentación del sistema

(operaciones, soporte, visión general, y la documentación al usuario) es
generalmente realizada durante esta etapa, debido a que la funcionalidad del
sistema se estabiliza en este momento.

Anunciar la implementación. Se debe anunciar el calendario de

implementación de manera anticipada e incluyendo las fechas estimadas de
capacitación e instalación. Debe instruir también su equipo de operación, soporte
y la comunidad de usuarios según proceda en esta fase.
 Capacitar el personal. Capacitar los clientes o usuarios de su proyecto, así
como a la administración.

Puesta en producción. En este punto se debe realizar cualquier conversión o

migración de datos, y puede ser todo de una vez, un trabajo por lotes o una
conversión gradual de los datos, conforme lo requieran los usuarios.

Tabla 2.5: Fases de la disciplina de despliegue

Fuente: Ambler S, 2005

[Link]. DISCIPLINA DE ADMINISTRACIÓN DE LA CONFIGURACIÓN

Administrar el acceso a los artefactos del proyecto. Esto no solo incluye los seguimientos de
las versiones de los artefactos, sino también controlar y administrar los cambios sobre ellos.

a) Flujo de Trabajo En la siguiente figura observamos el flujo de trabajo de la disciplina

de administración de la configuración. (Ver Figura 2.9)

Figura 2.9: Flujo de trabajo de la disciplina de Administración de la Configuración

Fuente: Ambler S, 2005
b) Fase por Fase

Fases Actividades
Inicio Establecer la configuración del ambiente. Usted tiene que hacer varias
cosas:
 La estructura de directorios apropiada, la cual debe seguir los
lineamientos corporativos, necesita ser creada para el equipo del
proyecto.
 Los miembros del equipo del proyecto necesitan tener acceso al
folder o directorios del proyecto y cualquier otro software cliente
instalados en sus ordenadores
 Los miembros del equipo del proyecto también necesitan ser
entrenados con los conceptos básicos de CM y las herramientas
necesarios.
 Su repositorio de CM necesitará ser instalado si este aún no se ha
instalado.
Ponga todos los productos del trabajo bajo el control de CM. Cada uno
debe poner su trabajo bajo el control de CM en una base regular,
verificar las entradas y salidas en cada caso, resolver conflictos de
actualización cuando se requiera, y presupuestar los productos del
proyecto cuando las versiones más actualizadas estén aprobadas.
Elaboración Poner todos productos del proyecto sobre el control de Configuración del
Manager.
Construcción Poner todos productos del proyecto sobre el control de CM.
Transición Poner todos productos del proyecto sobre el control de CM.

Tabla 2.6: Fases de la disciplina de Administración de la Configuración

Fuente: Ambler S, 2005

[Link]. DISCIPLINA DE LA ADMINISTRACIÓN DEL PROYECTO

Dirigir las actividades que forman parte del proyecto. Esto incluye administración de
riesgos, dirigir personas y coordinar personas con sistemas que están fuera del alcance del
proyecto.

a) Flujo de Trabajo En la siguiente figura, se observa todo el flujo de trabajo que se

tiene en la disciplina a de la administración del proyecto, para lo cual es necesario
tomar en cuenta, todos los aspectos que se demuestran en esta, para llegar a
comprender mejor el flujo que se tiene en esta disciplina, para esto se muestra la
siguiente figura. (Ver Figura 2.10)
 Figura 2.10: Flujo de trabajo de la disciplina de Administración del Proyecto
Fuente: Ambler S, 2005

b) Fase por Fase

Fases Actividades
Inicio Inicie conformando el equipo. En este punto necesitará alguien con
habilidades de modelado
Crear relaciones con sus involucrados del proyecto. El soporte a los
usuarios y la participación es crítica para su éxito.
Determinar. El proyecto debe ser financiera, técnica, operacional, y
políticamente viable.
Desarrollar un cronograma de alto nivel para todo el proyecto. El
cronograma del proyecto debe mostrar su proyecto organizado en
iteraciones.
Desarrollar un plan detallado de iteración para la siguiente
iteración. La planificación detallada se realiza basada en el principio
justo a tiempo.
Manejo del riesgo. Siempre hay riesgos en un proyecto de desarrollo
de software: técnicos y organizacionales.
 Obtener financiamiento y apoyo de los involucrados. Tendrá que
demostrar que usted entiende el alcance, que el proyecto es viable.
Cerrar esta fase. Debe ejecutar la Revisión de los entregables de los
objetivos del ciclo de vida.
Elaboración Construya el equipo. Conforme su proyecto tome forma y crezca,
necesitará agregar miembros al equipo.
Proteger el equipo. Las políticas de empresa son una realidad y un
buen administrador de proyectos protegen a sus equipos lo mejor
posible.
Obtener recursos. Su equipo necesita financiación, instalaciones
hardware, software, y así sucesivamente para hacer su trabajo.
Manejo del riesgo. Continúe los esfuerzos de administración del riesgo.
Actualice el plan del proyecto. Continúe las actividades planeadas tal
y como las describió.
Cerrar esta fase. Tendrá que ejecutar la revisión del ciclo de vida de la
arquitectura.
Construcción Administre el equipo. Continúe desarrollando el equipo, manténgase
protegiéndolos y proveyéndoles los recursos que necesitan.
Manejo del riesgo. Continúe los esfuerzos de administración del riesgo.
Actualizar su plan de proyecto. Durante la fase de construcción
necesitará asegurar que tiene identificadas las principales dependencias
involucradas en el desarrollo exitoso de su sistema.
Cerrar esta fase. Tendrá que ejecutar la revisión de la capacidad
operativa inicial.
Transición Administrar el equipo. Debe incluir en el equipo de desarrolladores,
encargados de pruebas e implementadores.
Cerrar esta fase. Tendrá que ejecutar la revisión de los productos
entregables
Iniciar el próximo ciclo del proyecto. Los sistemas se desarrollan y se
ponen en producción de manera incremental.

Tabla 2.7: Fases de la disciplina de Administración del Proyecto

Fuente: Ambler S, 2005

[Link]. DISCIPLINA DEL AMBIENTE

En la disciplina del ambiente, el objetivo principal es el de facilitar todo el entorno que

permita el normal desarrollo del proyecto, para lo cual se observa el flujo de trabajo y la
fase por fase que se tiene en cada punto.

a) Flujo de Trabajo En la siguiente figura se observa el flujo de trabajo, que tiene la

disciplina del ambiente. (Ver Figura 2.11 )
 Figura 2.11: Flujo de trabajo de la disciplina del Ambiente
Fuente: Ambler S, 2005

b) Fase por Fase

Fases Actividades
Inicio Configure el entorno de trabajo. Esta será una tarea permanente ya que hay
gente que se añade al equipo en el tiempo.

Identifique la categoría del proyecto. Muchas organizaciones desarrollan

varias versiones de sus procesos de software, por ejemplo uno para equipos
pequeños, uno para remplazar sistemas legales, otro para sistemas de plataforma
comercial,
etc.
Elaboración Evolucionar el entorno de trabajo. Su proyecto progresa a medida que se
entiende la evolución de los requisitos, la estrategia de la arquitectura, y su
enfoque general. Ajuste de los procesos de materiales. Se debe ajustar AUP
para cumplir con las necesidades del equipo.
Construcción Apoyar al equipo. Miembros del equipo del proyecto necesita ayuda para
utilizar y / o la configuración de diversas herramientas para satisfacer sus
necesidades.

Evolucionar el entorno de trabajo. Ver elaboración.

 Establecer el ambiente de capacitaciones. A medida que progrese en el plan de
despliegue o liberación se debe descubrir que se necesita entrenar al usuario,
personal de soporte y el personal de operación.
Transición Configuración de las operaciones y soporte de los entornos. Personal de
soporte, y algunas veces personal de operación, frecuentemente se necesita una
versión del sistema configurada que se use para simular reportes de defectos en
una forma segura.

Recobrar licencias de software. A medida que su proyecto llega a la

conclusión puede ser necesario desinstalar las licencias de software los equipos
que ya no
necesitan el software para que las licencias puedan estar disponibles a los demás
dentro de su organización.

Tabla 2.8: Fases de la disciplina del ambiente

Fuente: Ambler S, 2005

2.2.7. ITERACIONES E INCREMENTOS DE TIEMPO

Los equipos del AUP entregan típicamente lanzamientos del desarrollo en el final de cada
iteración. Como se puede observar en la siguiente figura el primer reléase puede tomar más
tiempo que el segundo, eso se debe en que en primera instancia hay más imprevistos a
resolver que en las instancias futuras. Como se puede observar en la siguiente figura lo que
propone AUP es que a medida que el proyecto avanza las iteraciones se vuelvan más cortas.
(Ver Figura 2.12)

Figura 2.12: Iteraciones Production Release

Fuente: Ambler S, 2005

2.2.8. ROLES DEL EQUIPO

Los roles del equipo sobre los que se basan AUP son:
 Las roles pueden llevarse a cabo por varias personas.
 Una persona puede adquirir roles múltiples.
 Un rol no es una posición.
En la siguiente tabla se muestra la descripción de los roles del equipo. (Ver Tabla 2.9)

Rol Descripción Disciplina(s)

DBA Ágil Un administrador de bases de datos (DBA) que Implementación
trabaja de manera colaborativa con los integrantes del
equipo del proyecto para diseñar, probar y brindar
soporte a
los diferentes esquemas de datos.
Modelador Ágil Alguien que cree y desarrolle modelos, ya sean Modelado
dibujos, tarjetas, o archivos complejos realizados con Implementación
herramientas CASE, de manera colaborativa y
evolutiva
Cualquiera Cualquier otra persona en otro rol distinto. Administración
de la
Configuración
Administración
del Proyecto
Administrador Un administrador de configuración se encarga de Administración
de la proporcionar la infraestructura y crear el medio de la
configuración ambiente para el equipo de desarrollo. Configuración
Implementador Un implementador es responsable de poner en Desarrollo
disponer el sistema en los ambientes de pre-
producción y producción.
Desarrollador Es quien escribe código, realiza pruebas y construye el Modelado
software. Implementación
Desarrollo
Especialista del Desarrolla, adapta y apoya el material de los procesos Entorno
proceso de la organización (descripción de procesos, plantillas,
guías, ejemplos, entre otros).
Administrador Administra los miembros de los equipos de trabajo, Modelado
del proyecto crea relaciones con los involucrados, coordina las Pruebas
interacciones con los involucrados, planea, administra Desarrollo
y dispone recursos, enmarca prioridades y mantiene Administración
el del Proyecto
equipo enfocado.
Examinador Evalúa los productos del proyecto, inclusive "el Pruebas
trabajo en progreso", suministrando retroalimentación
al equipo de trabajo.
Involucrado Un involucrado es cualquiera que sea usuario directo, Modelado
usuario indirecto, administrador de usuarios, Implementación
administrador, miembro de equipo de operación o Pruebas
soporte, desarrolladores que trabajan en otros Desarrollo
sistemas que se integran o interactúan con el sistema Administración
implementado, en fin todo aquel que se vea afectado del Proyecto
de una u otra forma con el proyecto.
Documentador Es responsable de producir documentación para los Desarrollo
técnico involucrados, tal como: materiales de capacitación,
documentación de operaciones, documentación de
mantenimiento, y documentación de usuario.
 Administrador El administrador de pruebas es el responsable del éxito Pruebas
de pruebas de las pruebas, incluye planificar la administración, y
promover las pruebas y las actividades de calidad.
Equipo de El equipo de pruebas es responsables de ejecutar las Pruebas
pruebas pruebas y documentar los resultados que proyecten.
Especialista en Es responsable de seleccionar, adquirir, configurar y Ambiente
herramientas brindar mantenimiento al equipo requerido.
Tabla 2.9: Descripción de roles del equipo
Fuente: Ambler S, 2005

2.2.9. ENTREGABLES

AUP clasifica los entregables en tres tipos:

Productos a entregar mínimos: es la documentación mínima requerida para realizar el

proyecto.

Otros productos del trabajo de proyecto: es la documentación no esencial según AUP.

Productos del trabajo de la empresa: son los entregables que la empresa debe realizar
para el proyecto.

1. Mantenga sus productos de trabajos tan simples y concisos como sea posible.

2. Usted necesita menos documentación de la que cree.

3. Trabaje cerca de las personas con las cuales usted está creando el producto de trabajo
para que haga sólo lo que ellos necesitan.

4. Documentos Ágiles son los suficientemente buenos para la tarea en cuestión.

5. Producir un documento es la peor forma de comunicar información, muchas personas

paradas frente a una pizarra hablando es la mejor manera.

6. Use herramientas simples como una pizarra (antigua), hojas de papel, y wikis para
modelar y capturar documentación.
 7. Considere adoptar las plantillas de código abierto como base de partida para crear su
propio trabajo. Estas tienen, probablemente más de lo que usted necesita, pero son un
buen comienzo.

Los productos mínimos a entregar se lo prioriza en la siguiente tabla. (Ver Tabla 2.10)

Entregable Descripción Sugerencias

Sistema El software de trabajo, el Hay más en su sistema que sólo el
hardware y la software que se escribe.
documentación para ser
liberada a producción.
Código fuente El código de programa para Siga las directrices de
su sistemas codificación común.
Suite de Pruebas de Una colección de casos de Automatice sus pruebas.
Regresión prueba, y el código para
correrlas en un orden Ejecútelas tan frecuentemente
adecuado. como sea posible, sobre todo
cuando ocurre algún cambio.
Scripts de Instalación Código para instalar su Necesitará un script, o scripts,
sistema su ambiente de para instalarlo en un ambiente de
pre- producción. pre-producción tan exacto como
el de producción.

Probablemente deba desinstalar

los scripts si su instalación falla.

Documentación del La documentación liberada Mantenga su documentación tan

Sistema como una parte del sistema liviana como sea posible.
para ayudar al usuario al
trabajar con él, y a los
desarrolladores para
mantenerlo actualizado.
Notas Sus notas deben resumir Una lista puntual es a menudo
"las buenas cosas a saber" suficiente.
acerca de las versiones
actuales que se están
construyendo.
Modelado de Describe los requisitos que Su objetivo es entender y luego
requerimientos su sistema debe cumplir. construir lo que sus usuarios
quienes, no escribir montículos
de documentación.

No necesita mantener todos los

aspectos para su modelo de
requerimientos, sólo la porción
que resuma el alcance de su
sistema. Considere mantener:

 Diagramas de Procesos
del Negocio(s).
 El glosario del proyecto.
 Cualquier otro requisito
de productos.
 Pruebas de aceptación
para requerimientos
implementados.

Modelo de Diseño Describe el diseño de su Mantenga su modelo tan simple

sistema. Consta de una como sea posible, y descarte en
variedad de productos de cuanto le sea posible una vez que
trabajo, incluye haya extraído el valor de ellos.
potencialmente un modelo
de despliegue, un modelo El mejor lugar para documentar
de objetos, un modelo de es en su unidad de pruebas y
datos físico (PDM), un código fuente.
modelo de seguridad de
amenazas, un documento Mantenga el documento de
de resumen del sistema, y resumen del sistema y el modelo
un modelo de interface de físico de datos para
usuario. documentación
permanente. Debe también
mantener unos pocos diagramas
de diseño detallados, tales como
diagramas de secuencia o
diagramas de las máquinas de
estado.

Tabla 2.10: Productos mínimos a entrega

Fuente: Ambler S, 2005
2.3. INGENIERÍA WEB
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y
cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad
en la World Wide Web.

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está
ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la
información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a
realizar todas sus actividades por esta vía.

Desde que esto empezó a suceder el internet se volvió más que una diversión empezó a ser
tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la
web se volviera como un desafío para los (ingeniería del software) ingenieros del software,
a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde
tuvieron en cuenta aspectos específicos de este nuevo medio.

2.3.2. INGENIERÍA DE SOFTWARE

Permite aplicar un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo,

Operación y mantenimiento del software. La Ingeniería del Software es una tecnología de
múltiples capas compuesta de: Un enfoque de calidad, procesos, métodos y herramientas.
[Pressman, 2002]

La aplicación de una aproximación sistemática, disciplinada y cuantificable al desarrollo,

operación y mantenimiento de aplicaciones basadas en la Web o la aplicación de la
ingeniería al software basado en la Web [Murugesan, 2001]

 Los procesos son los que mantienen juntas las capas de la tecnología y que permite
un desarrollo racional y oportuno de la ingeniería del software.
 Los métodos de la ingeniería de software indican como construir técnicamente el
software, abarcan una gama de tareas como el análisis de requisitos, diseño,
construcción de programas, pruebas y mantenimiento.
  Las herramientas suministran un soporte automático o semiautomático para el
proceso y los métodos [Pressman, 2002].

2.3.3. APLICACIONES WEB

Las aplicaciones Web son un sistema de información donde una gran cantidad de datos,
altamente estructurados, son consultados, procesados y actualizados mediante navegadores.

Categorías de las aplicaciones Web

Las aplicaciones Web se categorizan en:

 Informativa. Contenido solo de lectura con navegación y enlaces simples.

 Descarga. Se descarga información desde un servidor apropiado.
 Personalizable. Se puede cambiar el contenido a necesidades específicas.
 Interacción. La comunicación entre una comunidad de usuarios ocurre mediante un
espacio chat (charla), anuncios o mensajería.
 Entrada del usuario. Entrada basada en formularios.
 Orientada a transacciones. Realización de una solicitud que es completada por la
aplicación Web.
 Orientado a servicios. Proporción de un servicio al usuario.
 Portal. La aplicación canaliza al usuario llevándolo a otros contenidos o servicios
Web fuera del dominio de la aplicación del portal.
 Acceso a bases de datos. El usuario consulta en una base de datos grande y extrae
información.
 Almacenes de datos. El usuario consulta en una colección de base de datos grande
y extrae información.

Tecnologías Web

El diseño y la implementación de sistemas basados en Web incorporan tres tecnologías, el

desarrollo basado en componentes, la seguridad y los estándares de Internet.
  Desarrollo basado en componentes. Proporcionan una infraestructura que permite
a los que diseñan emplear y personalizar componentes de terceras partes
permitiéndoles así comunicarse unos con otros y con servicios en el ámbito de
sistemas, estándares como JavaBeans.
 Seguridad. Mediante la infraestructura de red se proporciona una variedad de
medidas de seguridad, tales como encriptación, cortafuegos y otras.
 Estándares de Internet. Estándares para la creación del contenido y la estructura
de la aplicación Web como ser, HTML y XML.

Modelo de proceso de ingeniería Web

Las Aplicaciones Web necesitan de un marco de trabajo de Ingeniería Web que acompañe a
un modelo de proceso.

El proceso de Ingeniería Web comienza con la Formulación, actividad que identifica las
metas y los objetivos de las Aplicaciones Web. La Planificación evalúa los riesgos
asociados con el esfuerzo del desarrollo. El Análisis establece los requisitos técnicos e
identifica los elementos del contenido que se van a incorporar. La actividad de ingeniería
incorpora dos tareas paralelas, el Diseño del Contenido y la Producción, son tareas llevadas
a cabo por personas no técnicas. El objetivo de estas tareas es diseñar, producir y/o adquirir
todo el contenido de texto, gráfico y vídeo que se vayan a integrar en la Aplicación Web.
Al mismo tiempo se lleva a cabo un conjunto de tareas de diseño. Cada incremento
producido como parte del proceso de Ingeniería Web se revisa durante la actividad de
evaluación del cliente.

Existen diversas metodologías para el desarrollo de sitios Web, como ser:

 WSDM: Web Site Design Method [TROYER & LEUNE, 1997]. Es una propuesta
para el desarrollo de sitios Web, en la que el sistema se define en base a los grupos
de usuarios. Su proceso de desarrollo se divide en cuatro fases: modelo de usuario,
diseño conceptual, diseño de la implementación e implementación.
 SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology [LEE,
LEE & YOO, 1998]. Presenta la necesidad de disponer de un proceso que permita
 capturar las necesidades del sistema. Para ello, propone el uso de escenarios, cada
escenario describe el proceso de interacción entre el usuario y el sistema.
 HFPM: Hypermedia Flexible Process Modeling [OLSINA, 1998]. Describe un
proceso detallado que cubre todo el ciclo de vida de un proyecto software, propone
un total de trece fases para las cuales se especifican a su vez una serie de tareas.
 UWE: UML-Based Web Engineering (HENNICKER & KOCH, 2000], [KOCH,
2001]. Es una propuesta metodológica basada en UML para el desarrollo de
aplicaciones Web. UWE cubre todo el ciclo de vida de este tipo de aplicaciones.
 W2000 (BARESI, GARZOTTO & PAOLINI, 2001). Supone una propuesta que
amplía la notación de UML con conceptos para modelar elementos de multimedia.
El proceso de desarrollo de se divide en tres etapas: análisis de requisitos, diseño de
hipermedia y diseño funcional.
 UWA: Ubiquituos Web Applications. Ha nacido de la colaboración entre diferentes
grupos de trabajo, por lo que resulta realmente una agrupación de propuestas y
técnicas. En concreto, la propuesta de W2000 se encuentra incluida en UWA.
 NDT: Navigational Development Techniques [ESCALONA, TORRES & MEJÍAS,
2002]. Es una técnica para especificar, analizar y diseñar el aspecto de la
navegación en aplicaciones Web.

A continuación se presenta una comparativa de requisitos y de orientación:

Tabla 2.11: Requisitos de cada propuesta

Fuente: ESC, 2002
 Tabla 2.12: Orientación de cada propuesta
Fuente: ESC, 2002

Donde:

Orientación al proceso: describe claramente los pasos a seguir (+), describe el proceso sin
detallarlo (o), no describe ningún proceso (-).

Orientación a la técnica: describe claramente las técnicas y la forma de aplicarlas (+),

enumera las técnicas a aplicar (o), no propone ninguna técnica concreta o referencia a
técnicas generales (-).

Orientación al producto: describe claramente la estructura del producto a obtener (+),

describe el contenido del producto sin entrar en detalle de su estructura (o), no comenta
nada sobre el producto resultante (-).

2.4. METODOLOGÍA DE MODELADO OOHDM

El modelo OOHDM u Object Oriented Hypermedia Design Methodology, para diseño de

aplicaciones hipermedia y para la Web, fue diseñado por D. Schwabe, G. Rossi, and S. D. J.
Barbosa y es una extensión de HDM con orientación a objetos, que se está convirtiendo en
una de las metodologías más utilizadas. Ha sido usada para diseñar diferentes tipos de
aplicaciones hipermedia como galerías interactivas, presentaciones multimedia y, sobre todo,
numerosos sitios web.

Este método se inspira en el modelo HDM, pero lo que le distingue claramente, es el

proceso de concepción orientado a objetos y abarca las cuatro actividades que se realizan en
una mezcla de estilo incremental, iterativo como se muestran en la siguiente (Ver Figura
2.13).

Figura 2.13: Estilo incremental iterativo del proceso de oohdm

Fuente: Pinto, 1627

2.4.1. FASE CONCEPTUAL

Durante esta actividad se construye un esquema conceptual representado por los objetos del
dominio, las relaciones y colaboraciones existentes establecidas entre ellos.

En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son

modificados durante la ejecución, se podría usar un modelo de datos semántico estructural
(como el modelo de entidades y relaciones).
De este modo, en los casos en que la información base pueda cambiar dinámicamente o se
intenten ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del
modelo de objetos.

En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas.

Las clases son descritas como en los modelos orientados a objetos tradicionales.

Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas
diferentes de las mismas entidades del mundo real. (Ver Figura 2.14)

Figura 2.14: Un posible diseño de clases

Fuente: Pinto, 1627

2.4.2. FASE NAVEGACIONAL

Se debe tener en mente que la generación de aplicaciones Web fue pensada para realizar
navegación a través del espacio de información, utilizando un simple modelo de datos de
hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño
aplicaciones.

Un modelo navegacional es construido como una vista sobre un diseño conceptual,

admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de
usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual.

En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos,

enlaces y estructuras de acceso. Un contexto navegacional es un conjunto de nodos,
enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados).

Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros.
Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados
sobre el concepto de contextos anidados.

Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en

un orden particular y que deberían ser definidos como caminos para ayudar al usuario a
lograr la tarea deseada.(Ver Figura 2.15)

Figura 2.15: Un posible diseño navegacional

Fuente: Pinto, 1627
2.4.3. FASE DE INTERFAZ ABSTRACTA

Se debe tener las estructuras navegacionales son definidas, se deben especificar los aspectos
de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden
aparecer, de cómo los objetos de interfaz activarán la navegación y el resto de la
funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo
es necesario realizarlas.

Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite
construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado
de independencia de la tecnología de interfaz de usuario.

El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las

aplicaciones Web) es un punto crítico en el desarrollo que las modernas metodologías
tienden a descuidar.

En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario
de la aplicación de hipermedia. El modelo de interfaz ADVs (Vista de Datos Abstracta)
especifica la organización y comportamiento de la interfaz, pero la apariencia física real o
de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son
hechas en la fase de implementación.

Figura 2.16: Un posible diseño de interfaz abstracta

Fuente: Pinto, 1627
2.4.4. FASE IMPLEMENTACIÓN

Se tendrá en cuenta que el diseñador debe ya implementar el diseño. Hasta ahora, todos los
modelos fueron construidos en forma independiente de la plataforma de implementación;
en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación.
Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de
información que son parte del dominio del problema. Debe identificar también, cómo son
organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz
debería ver y cómo debería comportarse. A fin de implementar todo en un entorno Web, el
diseñador debe decidir además qué información debe ser almacenada

En los diagramas de clases navegacionales corresponden a vistas del esquema conceptual y

los esquemas de contexto modelan el espacio de navegación incluyendo estructuras de
acceso y contextos (que corresponde a un conjunto de instancias de una clase
navegacional). Se podrían crear vistas parciales por usuario agrupando los contextos a
partir de los tipos de usuarios que tienen acceso a los mismos. Las vistas por módulos o
subsistemas no las modela de manera explícita, pero en los esquemas de contextos pueden
modelarse fácilmente submódulos.

Construir la interfaz de una aplicación Web es también una tarea compleja; no sólo se
necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados,
sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación.

Esta metodología propone dedicar un tiempo importante en las fases previas a la

implementación.

Esta inversión de tiempo está ampliamente justificada no sólo porque simplifica el proceso
de desarrollo, facilitando el trabajo del equipo encargado de cada capa de la aplicación, sino
también durante su mantenimiento y eventual e0xtensión.

Son quizás estas últimas tareas las más difíciles de lograr con tecnologías tradicionales, y
aún imposibles en muchos casos donde no existe diseño detallado y la implementación
concentra conceptos heterogéneos muy difíciles de modificar.
OOHDM propone un conjunto de tareas que en principio pueden involucrar mayores
costos de diseño, pero que a mediano y largo plazo reducen notablemente los tiempos
de desarrollo al tener como objetivo principal la reusabilidad de diseño, y así simplificar la
evolución y el mantenimiento.

2.5. FACTORES DE CALIDAD NORMA ISO 9126

Define la Calidad del Software como: “La totalidad de características de un producto de

software que se manifiesta en su habilidad para satisfacer necesidades establecidas o
implícitas”.

Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación de la
calidad de software, llamado “Information technology-Software product evaluation-Quality
characteristics and guidelines for their use”; o también conocido como ISO 9126 (o
ISO/IEC 9126). Este estándar describe 6 características generales: Funcionalidad,
Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y Portabilidad. A continuación se
describe las características de la norma iso 9126. (Ver Tabla 2.13)

Descripción Sub atributos

Funcionalidad es la capacidad del software de cumplir • Adecuación.
FUNCIONALIDAD

y proveer las funciones para satisfacer las necesidades • Seguridad

explícitas e implícitas cuando es utilizado en • Interoperabilidad
condiciones específicas. A continuación se muestra la • Conformidad de la
característica de Funcionalidad y las subcaracterísticas funcionabilidad.
que cubre • Exactitud.
(𝟏) 𝑅(𝑡) = 𝑒−𝜆𝑡
(𝟐) R = Ri ∗ Rs
(𝟑) Rs(t) = 1 − {(1 − R2(t)) ∗ (1 − R3(t)) ∗ … ∗
(1 − Rn−1(t)) ∗ (1 − Rn(t))}
La confiabilidad es la capacidad del software para • Madurez.
CONFIABILIDAD

asegurar un nivel de funcionamiento adecuado cuando

• Tolerancia a
es utilizando en condiciones específicas. En este caso a
la confiabilidad se amplía sostener un nivel errores.
especificado de funcionamiento y no una función
• Conformidad de
requerida.
(𝟏) PF = cuenta total ∗ (0.65 + 0.01 ∗ ∑ Fi) confiabilidad.
 • Recuperabilidad.

La usabilidad es la capacidad del software de ser • Entendimiento.

USABILIDAD

entendido, aprendido, y usado en forma fácil y • Aprendizaje.

atractiva. Algunos criterios de funcionalidad, fiabilidad • Operabilidad.
y eficiencia afectan la usabilidad, pero para los • Atracción.
propósitos de la ISO/IEC 9126 ellos no clasifican • Conformidad de
como usabilidad. usabilidad.
𝐴
(𝟏 ) 𝑋 =
𝐵
La eficiencia del software es la forma del desempeño • Comportamiento
EFICIENCIA

adecuado, de acuerdo a al número recursos utilizados de tiempos.

según las condiciones planteadas. Se debe tener en • Utilización de
cuenta otros aspectos como la configuración de recursos.
hardware, el sistema operativo, entre otros. • Conformidad de
eficiencia.
La capacidad de mantenimiento es la cualidad que • Capacidad de ser
MANTENIBILIDA

tiene el software para ser modificado. Incluyendo analizado.

correcciones o mejoras del software, a cambios en el • Cambiabilidad.
entorno, y especificaciones de requerimientos • Estabilidad.
funcionales. • Facilidad de
[𝑀𝑇 − (𝐹𝑎 + 𝐹𝑏 prueba.
+ 𝐹𝑐)] • Conformidad de
(𝟏) IMS =
𝑀𝑇 mantenibilidad.
La capacidad que tiene el software para ser trasladado • Adaptabilidad.
PORTABILIDAD

de un entorno a otro. • Facilidad de

CT instalación.
(𝟏) GP = 1 − ( )
CRD • Coexistencia.
• Remplazabilidad.
• Conformidad de
portabilidad.

Tabla 2.13. Factores de Calidad de software

Fuente: CODE25,, 2004
2.6. MODELO CONSTRUCTIVO DE COSTOS (COCOMO II)

COCOMO (Constructive Cost Model) modelo constructivo de costos, es uno de los

modelos de costos más conocidos, desarrollado en los 70’s por Barry Boehm, actualmente
ha evolucionado en COCOMO II, originalmente, es un conjunto de tres modelos diferentes
con complejidades y nivel de detalle en incremento Desarrollado en la década del ’70 por
Boehm, que son los siguientes [Cocomo, 2000]

• Básico: aplicable cuando se conoce muy poco del proyecto

• Intermedio: aplicable luego de la especificación de requerimientos
• Avanzado: aplicable cuando se termina el diseño.

Todos los modelos utilizan la misma fórmula:

= 𝑎𝑏(KLDC)𝑏𝑏

D = 𝑐𝑏𝐷𝑑𝑏

Donde:

E: Esfuerzo aplicado en personas por mes.

D: Tiempo de desarrollo en meses cronológicos.

KLDC: Número estimado de líneas de código distribuidas (en miles).

• Orgánicos: involucra procesamiento de datos, uso de bases de datos y se focaliza en

transacciones y recuperación de datos. Ejemplo: sistema de facturación
• Semi acoplado: contiene software de tiempo real que es una parte integral de un
sistema mayor basado en hardware. Ejemplo: control de ascensores
• Empotrado: entre orgánico y embebido U presenta mayor ˝ procesamiento de
transacciones. Ejemplo: Monitoreo de una red.

Cuando se conoce muy poco del proyecto, se utiliza COCOMO básico con F = 1, cuando se
conoce un poco más el lenguaje, herramientas a utilizar se puede aplicar COCOMO
intermedio.
Se eligen los factores de ajustes de una tabla que presenta 15 puntos. Tratan de capturar el
impacto del entorno del proyecto en el costo de desarrollo de un análisis estadístico de más
de 100 factores que influencian el costo, Boehm retuvo 15 de ellos para COCOMO.

La importancia de cada factor de ajuste es clasificada en una escala ordinal con seis puntos:
Muy Baja, Baja, Nominal, Alta, Muy Alta, Extra Alta

2.7. TÉCNICAS DE PRUEBAS DE SOFTWARE

Concretamente las técnicas de evaluación dinámica o pruebas de software se puede definir
como una actividad en la cual un sistema o uno de sus componentes se ejecuta en
circunstancias previamente especificadas (configuración de la prueba), registrándose los
resultados obtenidos.

Seguidamente se realiza un proceso de Evaluación en el que los resultados obtenidos se

comparan con los resultados esperados para localizar fallos en el software. Estos fallos
conducen a un proceso de Depuración en el que es necesario identificar la falta asociada
con cada fallo y corregirla, pudiendo dar lugar a una nueva prueba. Como resultado final se
puede obtener una determinada Predicción de Fiabilidad, tal como se indicó anteriormente,
o un cierto nivel de confianza en el software probado.

Los objetivos de las pruebas son:

 La prueba es el proceso de ejecución de un programa con la intención de descubrir

un error.

 Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces.

 Una prueba tiene éxito si descubre un error no detectado hasta entonces.

2.7.1. FACILIDAD DE PRUEBA

La experiencia indica que donde hay un defecto hay otros, las pruebas son una tarea
creativa como el desarrollo de software. La siguiente lista muestra las características que
llevan a un software fácil de probar:
  Operatividad

 Observabilidad

 Controlabilidad

 Capacidad de descomposición

 Simplicidad

 Estabilidad

 Facilidad de comprensión

Debe tener una alta probabilidad de encontrar un error, no debe ser redundante, debe ser la
mejor de todas las posibles, no debe ser ni demasiado sencilla ni demasiado compleja.
[Press, 2005]. Entre las que mencionaremos son:

 Prueba de caja negra.

 Prueba de caja blanca.

2.7. SEGURIDAD

En la actualidad, las organizaciones son cada vez más dependientes de sus redes
informáticas y un problema que las afecte, por mínimo que sea, puede llegar a
comprometer la continuidad de las operaciones.

La falta de medidas de seguridad en las redes es un problema que está en crecimiento, cada
vez es mayor el número de ataques y cada vez están más organizados, por lo que van
adquiriendo día a día habilidades más especializadas que permiten obtener mayores
beneficios.

Tampoco deben subestimarse las fallas de seguridad provenientes del interior mismo de la
organización. Para prevenir tales ataques y/o posibles fallas en la administración de la red
es necesario un buen sistema de seguridad en redes, esto mantiene la provisión de
información libre de riesgos y que brinda servicios para un determinado fin.
Si queremos darle una definición a seguridad en redes podríamos decir: Seguridad en redes
es mantener bajo protección los recursos y la información con se cuenta en la red, a través
de procedimientos basados en una política de seguridad tales que permitan un control
adecuado.

Información que debe ser protegida de manera que nos podamos sentir seguros al momento
de utilizar redes de comunicación dentro y fuera de una organización.

Es muy probable que cuando abandona la oficina al final del día, active el sistema de
alarma y cierre la puerta para proteger los equipos y la oficina también pueda que disponga
de una caja fuerte o de un armario con llave para guardar los documentos confidenciales de
la empresa. Su red de ordenadores necesita el mismo tipo de seguridad.

Las tecnologías de seguridad de red protegen su red contra robos y el uso incorrecto de
información confidencial de la empresa, sin ningún tipo de seguridad en su red, su empresa
se enfrenta a intrusos no autorizados, periodos de inactividad de red.

La seguridad de red no se basa en un método concreto, si no que utiliza un conjunto de

barreras que defienden su negocio de diferentes formas. Incluso si falla una solución, se
mantendrán otras que protegerán la empresa y sus datos de una gran variedad de ataques a
la red.
 CAPITULO III

MARCO APLICATIVO

3.1. INTRODUCCIÓN

La finalidad de este capítulo, es establecer el análisis y diseño del “SISTEMA WEB PARA
EL REGISTRO Y ADMINISTRACIÓN DE DOCUMENTOS DE NIÑOS
ROCINADOS CASO: CDI BO - 132”, que se desarrollara utilizando para este fin, la
odología de desarrollo ágil AUP y siguiendo las fases del modelado OOHDM, como se observa en la siguiente figura. (Ver Figura

Figura 3.1: AUP Y OOHDM

Fuente: Elaboración Propia

Se plantea una estructura gráfica, organizativa de herramientas y metodologías que

intervienen directamente en el presente proyecto.

Esta estructura grafica nos guiara durante todo el desarrollo del capítulo III, mediante una
serie de fases en las cuales podremos analizar, diseñar e implementar en una aplicación los
métodos descritos. (Ver Figura 3.2)
 CASOS DE USO DE NEGOCIO
MODELADO DE NEGOCIOS

DESCRIPCION CASOS DE USO

FASES DE DESARROLLO AUP con OOHDM

INICIO

A NIVEL NEGOCIO
MODELADO DE A NIVEL USUARIO
REQUERIMIENTOS A NIVEL SISTEMA
A NIVEL TECNICOS

DIAGRAMA DE CASOS DE USO PROPUESTO

MODELADO DE ANALISIS DIAGRAMA DE PAQUETES DIAGRAMA DE SECUENCIA

ELABORACION DISEÑO CONCEPTUAL OOHDM

DIAGRAMA DE CLASES DIAGRAMA ENTIDAD-RELACION MODELO FISICO

MODELADO DE DISEÑO

DISEÑO NAVEGACIONAL
OOHDM
CONSTRUCCION DISEÑO DE INTERFACES

DISEÑO DE INTERFAZ
ABSTRACTA OOHDM

TRANSICION IMPLEMENTACION OOHDM

Figura 3.2: Combinación AUP y OOHDM

Fuente: Elaboración Propia

59
3.2 FASE DE INICIO

El objetivo principal de la fase de iniciación es archivar el consenso de los interesados del

proyecto en relación a los objetivos del proyecto para obtener el financiamiento. Las
principales actividades de esta fase incluyen:

1. Definir el alcance del proyecto. Esto incluye la definición, a un alto nivel, de qué
es lo que hará el sistema.

2. Estimación de costos y calendario. En un nivel alto, el calendario y el costo del

proyecto son estimados.

3. Definición de Riegos. La lista de riegos es una compilación en vivo que cambiará

en el tiempo cuando los riesgos serán identificados, mitigados, evitados y / o
materializados o exterminados

4. Determinar la factibilidad del proyecto. Su proyecto debe tener sentido desde la

perspectiva técnica, operacional y del negocio

5. Preparar el entorno del proyecto. Esto incluye la reserva de áreas de trabajo para
el equipo.

3.2.1 MODELADO DEL NEGOCIO

Con el modelado del negocio, se logrará entender mejor el funcionamiento y los respectivos
procesos que el personal del centro de desarrollo integral BO- 132 realiza en dicha
institución.

[Link] MODELADO DE CASOS DE USO DEL NEGOCIO

En el diagrama de caso de uso del negocio (Ver Figura 3.3 ) se muestra la operación que se
realizan en la postulación, cuando se presenta la convocatoria para la postulación el
responsable de patrocinio es la persona que se encargara de recibir los requisitos que se
piden, posteriormente se le facilita al padre de familia una ficha social el cual debe ser
llenado correctamente al finalizar la recepción de estos, el responsable de patrocinio se
encargara

60
posteriormente de revisar los documentos y datos recibidos, el director y el comité
fiscalizador se encargaran de evaluar estos documentos para luego dar el visto bueno a la
postulación del nuevo patrocinado, como también se muestra la apertura del registro, la
responsable de patrocinio estará encomendada a realizar el registro de los datos y
documentos que se recabaron en la postulación, como también tendrá el deber de ejecutar
bienales, registrar mensualidades, proporcionar reporte de mensualidades, en cabio el
responsable de programas será el encargado de supervisar el desarrollo curricular del niño.

uc Actors

Sistema

COMITE FISCALIZADOR ev aluar documentos para V.B

PADRE DE FAMILA

recibir requisitos

DIRECTOR

llenar ficha social

rev isar documentos y datos

realizar registro

RESPONSABLE DE PATROCINIO
ej ecutar bienales

registra mensualidad
PATROCINADO

RESPONSABLE DE PROGRAMA
proporciona reporte de mensualidades

superv isar dessarrollo curricular

Figura 3.3: Diagrama de casos de uso del negocio

Fuente: Elaboración Propia
[Link] DESCRIPCIÓN DE ACTORES DEL CASO DE USO DE NEGOCIO

Descripción de los actores de los diagramas de caso de uso del negocio que son
respectivamente descritos en la siguiente tabla. (Ver Tabla 3.1)

ACTOR DESCRIPCIÓN

Persona comisionada de la dirección del

CDI-BO132, además de supervisar las
DIRECTOR
áreas de patrocinio y programas.

Persona encargada de la postulación,

registro de datos del patrocinado,
RESPONSABLE DE PATROCINIO
recolectar mensualidades y asistencia a
reuniones.

RESPONSABLE DE PROGRAMAS Es la responsable de todo el desarrollo

curricular, planificación y evaluación del
programa que se sigue en el centro.

Son las personas encargadas, de evaluar y

dar el visto bueno conjuntamente con la
COMITÉ FISCALIZADOR
dirección, a cada decisión que se tome
dentro del centro.

Es la persona que se encarga del amparo

y atención del niño patrocinado, que debe
PADRE DE FAMILIA
cumplir con los requisitos impuestos del
CDI.

Es el niño o niña que se posee un

patrocinador y se encuentra inscrito en el
PATROCINADO
CDI-BO132, el cual debe cumplir con lo
que se le asigna en su plan de estudios.

Tabla 3.1. Descripción de actores de casos de uso del negocio

Fuente: Elaboración Propia
3.2.2 MODELADO DE REQUERIMIENTOS

El modelado de requerimientos, es un proceso de descubrimiento, refinamiento, modelado

y especificación que nos permite conocer los elementos necesarios para definir un proyecto
de software.

Es la fase más crítica del desarrollo de un proyecto de software, indica la interfaz del
software con otros elementos del sistema y establece las restricciones que debe cumplir el
sistema.

Consta de una variedad de productos de trabajo, como ser: requerimientos técnicos,

requerimientos de usuario, requerimientos a nivel de negocio. Los requerimientos son la
parte final de la fase de inicio.

[Link] DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE NEGOCIOS

Desarrollar un sistema web para el registro y administración de documentos de niños

patrocinados para la institución CDI BO-132.

[Link] DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE

USUARIO U1.- Registrar los datos personales de un postulante.

U2.- Registrar información personal y documentación entregada del patrocinado.

U3.- Administrar los datos del niño/a, donde se pueda adicionar eliminar, buscar y modificar

una determinada información.

U4.- Mantener actualizada la documentación entregada.

U5.- Registrar usuario de administración para mantener la información segura

U6.- Registrar patrocinados para tener acceso a todos los datos que se refiere a este.

U7.- Generar historial para tener claro que datos y documentos se necesita actualizar o

entregar del niño/a.

U8.- Emitir reportes de los datos y documentación recabada.

[Link] DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL DE SISTEMA

S1.- El sistema debe poseer una interfaz para el registro de los datos personales del
postulante

S2.- El sistema debe tener una interfaz que nos permita elegir entre adicionar, eliminar,

buscar y modificar la información del niño/a.

S3.- El sistema debe poseer una interfaz para el registro de toda la información personal del

patrocinado.

S4.- El sistema debe de contener una interfaz para registrar el historial de cada niño

patrocinado.

S5.- El sistema tendrá la opción de imprimir los reportes generados por el postulante y el

Patrocinado.

[Link] DESCRIPCIÓN DE REQUERIMIENTOS A NIVEL TÉCNICOS

Se tiene los requerimientos a nivel hardware y software.

T1.- La codificación será efectuada sobre la plataforma de Microsoft, utilizando Php

5.5.12, MySql 5.6.17.

T2.- Para realizar los reportes se utilizará plugins de php.

T3.- Para el servidor local se utiliza WampServer 2.5

3.3 FASE DE ELABORACIÓN

El principal objetivo de la fase de elaboración es probar la arquitectura del sistema a

desarrollar.

En esta fase se determinan las soluciones técnicas del proyecto durante la cual se elabora
los modelos de análisis, diseño, navegación e implementación, de los cuales se
desarrollaran los respectivos diagramas.
3.3.1 MODELADO DE ANÁLISIS

[Link] MODELO DE CASOS DE USO PROPUESTO

Los casos de uso propuesto, representan una descripción específica de acciones e

interacciones entre los actores y el sistema que proporciona valor a un actor en particular,
que define un conjunto de instancias de casos de uso.

[Link] DIAGRAMA DE CASOS DE USO DE ALTO NIVEL

Los diagramas de casos de uso de alto nivel es donde se trata de realizar una descripción
breve de las acciones del caso de uso. (Ver Figura 3.4)

uc caso de uso propuesto

Sistema para el Registro y administracion de

documentos

Administrar Usuarios

Administar
Postulante

RESPONSABLE DE Administrar
PATROCINIO Patrocinado

Administrar Historial

Elaborar Reportes

PATROCINADO

Figura 3.4. Diagrama de casos de uso del sistema de registro y administración

Fuente: Elaboración Propia
[Link] DESCRIPCIÓN DE CASOS DE USO

A continuación, se describen los diagramas de casos de uso de la figura 3.4, estos

diagramas proporcionan una guía para los siguientes flujos de trabajo y su descripción,
desde el diseño hasta las pruebas.

A) CASO DE USO: ADMINISTRAR USUARIOS

Administrar usuarios, consiste en la asignación de usuarios al personal que tiene un rol en

el sistema, la modificación de usuario en caso de haber cometido algún error al habilitar a
algún empleado y finalmente la eliminación de algún usuario que se lo realiza cuando la
persona deja de pertenecer al centro. La persona a cargo de estos procesos es el director
administrativo. En la siguiente figura se muestra todo lo mencionado. (Ver Figura 3.5)

uc caso de uso propuesto

Sistema web para el registro y administracion de niños

patrocinados CDI BO-132

Registrar Usuario

«include»

Administrar Usuario

RESPONSABLE DE
PATROCINIO
«extend»
«include»

Modificar Usuario
Eliminar Usuario

Figura 3.5. Casos de uso de administrar usuario

Fuente: Elaboración Propia
Descripción del diagrama de Casos de Uso: Administrar Usuario

Nombre: Administrar Usuario

Autor: Lía Isabel Cortez Cusi

Descripción:
Permitir al director administrativo registrar, modificar y eliminar
usuario.
Actores:
Responsable de Patrocinio
Precondiciones:
El responsable debe ser usuario del sistema y tener el rol de
administrador.
Flujo Normal:
Actor Sistema
1. Autentificación del actor en el 2. Verifica datos introducidos
sistema. en la base de datos.
5. Registra los datos
3. Elegir la opción introducidos en la base de
administración de usuario. datos.
4. Elegir la opción de
adicionar, eliminar y
modificar usuario
6. Salir del sistema.
Flujo Alternativo:
En caso de cometer algún error en la administración del usuario, el
sistema informara dicho error.
Post condicione:
El sistema guardara el registro en el inicio de postulación.
Tabla 3.2. Descripción de caos de uso administrar usuario
Fuente: Elaboración Propia
B) CASO DE USO: ADMINISTRAR POSTULACIÓN

Administrar postulación, consiste en registrar los datos principales, que no es más que
introducir todos los datos personales y aspectos esenciales para la evaluación, como ser un
código de referencia, nombres, apellidos, dirección, teléfonos entre otros, tanto como del
niño/a como también de los padres de familia, posteriormente se realiza la revisión de estos
requisitos sacando un reporte por cada uno de ellos, para luego revisarlos juntamente con la
dirección y el comité de fizcalizacion. La persona encargada de estos procesos, es la
responsable de patrocinio que su labor consistirá en recabar información de los postulantes
en la ficha social. A continuación se detalla lo mencionado en la siguiente figura. (Ver
Figura 3.6)

class Use Case Mo...

Sistema web para el registro y administracion de niños

patrocinados CDI BO-132

Verificar registro

«include»

Administrar
Postulacion

RESPONSABLE DE
PATROCINIO
«include» «include»

Registrar Postulante Registrar Ev aluacion

Figura 3.6. Diagrama de casos de uso de administrar postulación

Fuente: Elaboración Propia
 Descripción del diagrama de Casos de Uso: Administrar Postulación

Nombre: Administrar Postulación

Autor: Lía Isabel Cortez Cusi

Descripción:
Permitir al responsable de patrocinio registrar datos y evaluación.
Actores:
Responsable de Patrocinio
Precondiciones:
El responsable debe ser usuario del sistema y tener el rol correspondiente.
Flujo Normal

Actor Sistema
1. Elegir la opción de registrar 2. Almacena la información
o evaluar postulante. introducida en la base de
datos.
3. Salir del sistema.
Flujo Alternativo:
En caso de cometer algún error en el proceso de registro el sistema
informara dicho error.
Post condicione:
El sistema guardara el registro en el inicio de postulación.

Tabl
a 3.3. Descripción de casos de uso administrar postulación
Fuente: Elaboración Propia

C) CASO DE USO: ADMINISTRAR PATROCINADO

La administración del patrocinado, consiste en el registro del patrocinado que será la

adición del nuevo niño/a y para esto se debe introducir todos los datos de este, además que
en el nivel de postulante ya se tuvo recabado algunos de sus datos y aquí solamente se jalan
esos
datos, la modificación se realiza en caso de tener algún cambio de información después de
haber realizado el registro, la búsqueda se realizara para verificar algún error que se
cometió al momento del registro y finalmente la cancelación de un patrocinado que se
realiza después de que el patrocinado cumpla con el plan de ayuda que brinda el centro. La
persona encargada de estos procesos es el responsable de patrocinio, que desempeñara la
labor de administrar los datos y documentos del patrocinado. En la siguiente figura se
muestra lo mencionado. (Ver Figura 3.7)

class Use Case Mo...

Sistema web para el registro y administracion de niños patrocinados CDI BO-132

Modificar Patrocinado Cancelar Patrocinado

Buscar Patrocinado

«include»«include» «include»

Administrar Patrocinado

RESPONSABLE DE PATROCINIO

«include»

registrar patrocinado

Figura 3.7. Diagrama de casos de uso administrar patrocinado

Fuente: Elaboración Propia
Descripción del diagrama de Casos de Uso: Administrar Patrocinado

Nombre: Administrar Patrocinado

Autor: Lía Isabel Cortez Cusi

Descripción:
Permitir al responsable de patrocinio registrar, buscar, modificar y eliminar
patrocinado.
Actores:
Responsable de Patrocinio
Precondiciones:
El responsable debe ser usuario del sistema y tener el rol correspondiente.
Flujo Normal:
Actor Sistema
1. Autentificación del actor 3. Se guardara todos los datos
en el sistema. introducidos en la base de datos si
2. Elegir la opción de es el caso de registrar.
adicionar, buscar, 4. Se rebuscara en la base de datos y
modificar y cancelar mostrara toda la información
patrocinado. registrada, para modificar o
cancelar.
5 Salir del sistema
Flujo Alternativo:
En caso de cometer algún error en el proceso de registro el sistema
informara dicho error.
Post condiciones:
El sistema guardara el registro en administrar datos y documentos.

Tabla 3.4. Descripción de casos de uso administrar patrocinado

Fuente: Elaboración Propia
D) CASO DE USO: ADMINISTRAR HISTORIAL

Administrar historial, consiste en el registro del nuevo historial que se le asignara al

patrocinado, en donde se jalaran los datos personales del niño/a, de los padres de familia y
final mente los datos del patrocinador que se le asignó al momento de registrarse como
usuario, que se encuentran guardados de la base de datos, . El encargado de estos procesos
es el responsable de patrocinio que su labor será el de registrar mensualidades, reuniones y
multas respectivas. En la siguiente figura, se puede observar todo lo detallado
anteriormente. (Ver Figura 3.8)

class Use Case Mo...

Sistema web para el registro y administracion de niños

patrocinados CDI BO-132

Modificar Historial de
Patrocinado

«include»

Administrar Historial

RESPONSABLE DE
PATROCINIO
«include»

Registrar Historial de
Patrocinado

Figura 3.8. Diagrama de casos de uso registrar historial de patrocinado.

Fuente: Elaboración Propia
Descripción del diagrama de Casos de Uso: Administrar Historial
de Patrocinado

Nombre: Administrar Historial de Patrocinado

Autor: Lía Isabel Cortez Cusi

Descripción:
Permitir al responsable de patrocinio registrar y modificar el historial
de un patrocinado.
Actores:
Responsable de Patrocinio
Precondiciones:
El responsable debe ser usuario del sistema y tener el rol
correspondiente.
Flujo Normal:

1. Autentificación del actor 3. Se almacenara los datos

en el sistema. introducidos en a base de
2. Elegir la opción de datos.
registrar, modificar 4. Buscará el código y
historial. desplazara la información
registrada.
5 Salir del sistema.
Flujo Alternativo:
En caso de cometer algún error en el proceso de registro el sistema
informara dicho error.
Post condicione:
El sistema guardara el registro en operar mensualidades y asistencias.

Tabla 3.5. Descripción de casos de uso registrar historial de patrocinado

Fuente: Elaboración Propia
E) CASO DE USO: ELABORAR REPORTES

Elaborar reportes, consiste en imprimir los datos del postulante, información del historial
del patrocinado, donde también se encuentra la documentación entregada de este, se realiza
una búsqueda, introduciendo el código referencial si se trata de un postulante, si el caso es
de un patrocinado se introduce el código actual de este, el sistema buscara estos datos y
desplazara la información correspondiente, además de un reporte de estadísticas sobre los
patrocinados. De estos procesos se encarga el responsable de patrocinio, coma también el
patrocinado accediendo al sistema podrá verificar estos datos. A continuación se puede
observar la siguiente figura donde se describen los procesos explicados anteriormente. (Ver
Figura 3.9)

uc caso de uso propuesto

Sistema web para el registro y

administracion de niños patrocinados
CDI BO-132

Imprimir Postulante

Imprimir Historial
patrocinado

Patrocinado
RESPONSABLE DE
PATROCINIO

Imprimir estadisticas

Figura 3.9. Casos de uso de reportes

Fuente: Elaboración Propia
Descripción del diagrama de Casos de Uso: Elaborar Reportes

Nombre: Elaborar Reportes

Autor: Lía Isabel Cortez Cusi

Descripción:
Permitir al responsable de patrocinio imprimir los datos del postulante,
historial del patrocinado, como también estadísticas.
Actores:
Responsable de Patrocinio, patrocinado

Precondiciones:
El responsable y el patrocinado, deben ser usuarios del sistema y tener el rol
correspondiente.
Flujo Normal:
Actor Sistema
1. Autentificación del actor en el 2. Verificara datos introducidos para
sistema. acceder al sistema.
3. Elegir la opción de imprimir 4. Se buscara el código desplazando la
postulante, historial del información y para imprimir
patrocinado y estadísticas.
5. Salir del sistema.
Flujo Alternativo:
En caso de cometer algún error en el proceso de registro el sistema informara
dicho error.
Post condicione:
El sistema guardara el registro en el inicio de postulación e historial.

Tabla 3.6 Descripción de caos de uso de reportes

Fuente: Elaboración Propia
[Link] DIAGRAMA DE PAQUETES

El diagrama de paquetes muestra la forma en la que el Sistema web para el registro y

administración, está dividido en agrupaciones lógicas mostrando la dependencia entre ellas,
los diagramas de paquetes muestran la descomposición jerárquica lógica de un sistema, es
decir se muestra un esquema de los módulos que comprende nuestro sistema. A
continuación se muestra el diagrama de paquetes en la figura para entender la organización
del sistema. (Ver Figura 3.10)

pkg Diagrama de Paquetes

Administrar Postulacion

Administrar Usuario

Administrar Datos y Documentos

Componentes Comunes

Elaborar Reportes
Administrar Mensualidades y Asistencias

Figura 3.10 Diagrama de paquetes del sistema de registro y administración de documentos

Fuente: Elaboración Propia

[Link]. DIAGRAMA DE DESPLIEGUE

El diagrama de despliegue representa, como y donde se instalara el sistema para el registro

y administración de documentos, que está realizada en forma física, para este caso se
presenta el servidor, la base de datos, el responsable de patrocinio, la dirección y el
patrocinado, los
cuales tendrán el acceso al sistema para el registro y administración de documentos de
niños patrocinados la figura 3.11 nos ilustra una configuración básica.

Fuente 3.11. Diagrama de Despliegue

Fuente: Elaboración Propia

[Link]. DIAGRAMA DE SECUENCIA

El diagrama de secuencia del sistema muestra de manera gráfica los eventos que propician
los actores directos con el sistema. Para su elaboración deberá haberse elaborado,
previamente los casos de uso específicos, de los cuales se obtiene el curso normal de
eventos, teniendo en cuenta los cursos opcionales más interesantes. [LARM, 1999].

Autentificación.- Empieza cuando un usuario ingresa a la página de autentificación del

sistema. El sistema muestra una pantalla donde pide introducir usuario y contraseña, una
vez digitados los datos por el usuario, el sistema verifica estos y dependiendo del usuario
muestra las pantallas de interfaz y el usuario puede acceder al sistema. En la siguiente
figura se muestra este proceso. (Ver Figura 3.12)
 class Digrama de Secuencia

Usuario Sistema

[Autentificaion (Usuario, Contraseña)]

[Desplaza Interfaz]

Figura 3.12. Diagrama de Secuencia: Autentificación

Fuente: Elaboración Propia

Administración de Usuarios.- Cuando el Responsable de patrocinio ya está accediendo al

sistema, puede administrar usuarios, registrando modificando o eliminando, en la siguiente
figura se observa este procedimiento. (Ver Figura 3.13)
class Digrama de Secuencia

Responsable de Sistema
Patrocinio

[Ingresa informacion usuario]

[Termina Registro]

[Busca Usuario]

[Desplaza informacion de usuario]

[Elige modificar o eliminar]

[Devuelve resultados]

Figura 3.13. Diagrama de Secuencia: Administración Usuarios

Fuente: Elaboración Propia
Administración Postulante.- El responsable de patrocinio una vez autentificado, elije
registrar postulante, llenando todos los campos requeridos, una vez terminado presionara
registrar, para la evaluación del postulante si se queda o no, que lo realizara mediante la
opción buscar postulante y lo hará por código referencial, el sistema devolverá los datos
ingresados en el registro, el responsable de patrocinio elegirá modificar o eliminar, según lo
que se quedó en la evaluación del postulante. En la siguiente figura se observa este proceso.
(Ver Figura 3.14)

class Digrama de Secuencia

Responsable Patrocinio Sistema

[Registrar Postulante]

[Finalizar Inscripcion(Datos)]

[Busca Usuario]
[Devuelve resultados]

[Elige modificar o eliminar]

Figura 3.14. Diagrama de Secuencia: Administrar Postulante

Fuente: Elaboración Propia

Administración de Patrocinado.- El responsable de patrocinio después de haberse

autentificado, antes de acceder a la administración de patrocinado, luego podrá actualizar
los datos del patrocinado aceptado, buscándolo por código, el sistema desplegara toda esta
información ya antes registrada. En la figura 3.15 se muestra este proceso.
 class Digrama de Secuencia

Responsable Sistema
Patrocinio

[Busca Patrocinado]

[Devuelve informacion registrada]

[elige eiminar o modificar]

Figura 3.15. Diagrama de Secuencia: Administrar Patrocinado

Fuente: Elaboración Propia

Administración Historial.- El responsable de patrocinio es el que se encarga de esta parte

una vez pasado el nivel de registro de patrocinado, el podrá registrar sus documentos en el
historial, este elegirá la opción de registrar historial, el sistema desplegara una tabla donde
pedirá la cedula del patrocinador, el sistema devolverá los datos completos del
patrocinador, luego pedirá el código del patrocinado, igualmente el sistema devolverá toda
la información registrada en la base de datos, después de todo esto, el responsable de
patrocinio empezara a registrar los documentos que son requeridos como ser el carnet de
vacunas, certificado de nacimiento además de los documentos de los padres del niño/a, y
finalizara con la opción de registrar.

También el responsable podrá elegir la opción de editar el historial por x motivos, por el
que tendrá la opción de buscar por código, el sistema desplegara la información registrada
en el historial, donde logrará modificar datos por otros a su vez actualizarlos. En la
siguiente figura se observa lo mencionado. (Ver Figura 3.16
 class Digrama de Secuencia

Responsable Sistema
Patrocinio

[Registrar Historial]

[Devuelve informacion registrada]

[Finaliza registro]

[Busca codigo]

[devuelve informacion registrada]

[elige modificacio]

Figura 3.16. Diagrama de Secuencia: Administración Historial

Fuente: Elaboración Propia

Administración Reporte.- En este módulo podrán tener acceso tanto como el responsable
de patrocinio y como el patrocinado, previamente su autentificación, llegaran a tener acceso
a esta parte, el responsable de patrocinio podrá realizar un reporte tanto como del
postulante, como del historial del patrocinado, este elegirá la opción de búsqueda por
código, e sistema desplegara todos los datos registrados en la base de datos, el responsable
de patrocinio elegirá la opción de imprimir, el sistema devolverá la información en formato
pdf. Si el patrocinado es el que tiene acceso al sistema automáticamente el sistema
desplegara sus datos más la documentación entregada, elegirá la opción de imprimir, el
sistema devolverá los datos registrados en formato pdf. De los cuales tanto como
responsable de patrocinio y patrocinado podrán imprimir esta información.

Además se cuenta con la opción de estadísticas de patrocinados inscritos, donde lo podrán

ver el patrocinado y el responsable de patrocinio, para tener un panorama más claro de los
registros de cada año. (Ver Figura 3.17)
 class Digrama de Secuencia

Patrocinado Responsable Sistema

Patrocinio

[desplaza datos]

[elige imprimir]

[Busca Postulante o Patrocinado]

[Devuelve informacion registrada]

[elige imprimir]

[elige estadisticas]
[devuelve reporte estadistica]

Figura 3.17. Diagrama de Secuencia: Elaboración de Reportes

Fuente: Elaboración Propia

3.3.2. MODELO DE DISEÑO

El modelo de diseño refleja decisiones en cuanto a asignación de responsabilidades entre

las operaciones, muestra cómo se relacionan componentes de software para resolver el
problema planteado es el paso previo a la implementación.

[Link]. DIAGRAMA DE CLASES

Estos diagramas representan los objetos fundamentales del sistema, es decir los que percibe
el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o
de un modelo de programación.

La clase define el ámbito de definición de un conjunto de objetos, cada objeto pertenece a

una clase, los objetos s e crean por instanciación de las clases. Un diagrama de clases está
compuesto por los siguientes elementos: nombre de la clase, atributos, operaciones, sus
relaciones son de herencia, composición, agregación, asociación y uso.
Este es el diagrama principal para el análisis y diseño, en la figura se representan las
relaciones entre las clases, atributos y sus operaciones para representar la información del
sistema. Después de haber realizado el análisis para la base de datos e identificar todas las
entidades que intervienen en el sistema, se elabora el diagrama de clases como se muestra a
continuación. (Ver Figura 3.18)

class Diagrama de Clases

PERSONAL
REPORTES
USUARIO
ci: int
NombrePer: char Nro_Reporte: long
Id_Usuario: char ApPaternoPers: char Tipo_Reporte: char
Cuenta_Usuaio: char ApMaternoPers: char Fecha_Emision: char
Contraseña: char 1*
Direccion: char
Estado: char Telefono: long
11 + Reportes() : void
TipoPers: char
+ Usuario() : void *1

+ Personal() : void
PATROCINADO
POSTULANTE Codigo_patrocinado: char
Nombre_Patrocinado: char
NombrePost: char ApPaterno_Patrocinado: char
ApPaterno: char DOCUMENTOS ApMaterno_Patrocinado: char
ApMaterno: char Edad_Patrocinado: int
Edad: int Nro_Doc: int Sexo: char
Sexo: char Tipo_Doc: char *1 Direccion: char
1 *
Direccion: char
+ Documetos() : void

1 + Patrocinado() : void
+ Postulante() : void *
11 1
1 PADRE_DE_FAMILIA
NombrePadre: char 1
ApPaternoPadre: char
ApMaternoPadre: char
CiPadre: char
1 HISTORIAL
NombreMadre: char id_his: int
ApPaternoMadre: char codigo: char
ApMaternoMadre: char fec_gen: char
CiMadre: char observ: char
doc: DOCUMENTOS

+ Padre() : void
+ Historial() : void

Figura 3.18. Diagrama de clases del sistema de registro y administración

Fuente: Elaboración Propia

[Link]. DIAGRAMA ENTIDAD RELACIÓN

El diagrama Entidad/Relación se basa en entidades y en las interrelaciones que se

establecen entre estas entidades y pone énfasis en el tipo de interrelaciones y la cardinalidad
que hay entre los elementos. (Ver Figura 3.19)
analysis modelo entidad-relacion

sexo

edad
tipo_rep Reporte Postulante
dispone
1..* 1 ap_materno

nro_rep 1..*

ap_paterno
codigo_refnombre
tipousuario contraseña
adquiere

codigo usuario
obtiene
1

nombre 1
1
1
Patrocinado tiene
ap_paterno 1
Area de Patrocinio
1

ap_materno

posee nombre ap_paterno ap_materno

1 Historial
edad

sexo
id_hist codigofec_gendocumobserv

Figura 3.19. Modelo Entidad Relación

Fuente: Elaboración Propia

[Link].MODELO FÍSICO

En esta parte el objetivo es transformar el esquema conceptual obtenido en la fase previa,

adaptándola al modelo de datos (relacional) que se va a utilizar y de acuerdo a un sistema
de gestión de base de datos particular.

La meta de esta fase es producir un esquema físico donde muestre las llaves primarias y los
atributos respectivos, que sea eficiente para las operaciones de consulta y actualización en
el sistema. En la siguiente figura se observa todo lo mencionado. (Ver Figura 3.20)
Figura 3.20. Modelo físico de base de datos
Fuente: Elaboración Propia
[Link].MODELO DE NAVEGACIÓN

En la figura se muestra el área de navegación que detalla los objetos que logran ser visitados
mediante la navegación de los usuarios, especificados por el rol que poseen.

En el siguiente diagrama de navegación se observa dos usuarios: el director administrativo,

el responsable de patrocinio y en cada uno de los usuarios se percibe su respectiva
navegación. (Ver Figura 3.21)

Figura 3.21. Modelo de espacio de navegación

Fuente: Elaboración Propia

[Link] MODELO DE NAVEGACIÓN DE MENÚS

La navegación de menús es un diseño de cómo se exhibe nuestro sistema, obviamente

dependiendo del usuario que acceda, es decir dependiendo el rol que presente el usuario.
En la figura 3.21 se llega a observar los accesos del menú que posee el respectivo usuario,
cada usuario que requiera ingresar al sistema, deberá previamente autenticarse antes de
ingresar.

Si el usuario ingresado es administrador, tiene la opción de administrar usuarios, como el

de registro, modificación y eliminación, administrar postulante, como el de registrar y
evaluar, también puede administrar patrocinado como actualizar y buscar, además de
administrar historial de registro, edición y búsqueda, el administrador también estará
encargado de imprimir reportes, si el caso es patrocinado, este solo tendrá acceso a los
reportes.

Figura 3.22 Modelo de navegación acceso de usuarios

Fuente: Elaboración Propia

[Link] MODELO DE PRESENTACIÓN

El modelo de presentación nos permite mostrar en forma abstracta la interfaz de usuario

(UI) del sistema, expresando el contenido y estructura de nodos simples. Primeramente se
muestra el modelo de presentación de la página principal del sistema. (Ver Figura 3.23)
class modelo de presentacion

Pantalla Principal

Logo CDI BO-132

Inicio Usuario Postulante Patrocinado Historial Reporte

Area de Contenido

Pie de Pagina

Figura 3.23. Modelo de presentación: página principal

Fuente: Elaboración Propia

En la figura 3.24 se muestra el acceso que tiene el administrador, puede llegar a todas las
opciones sin restricción alguna, aparte de tener sus funciones como el de administrar
usuarios, administrar postulante, administrar patrocinado, administrar historial, administrar
reportes.
 class modelo de presentacion

Pantalla Principal

Logo CDI BO-

132

Inicio Usuario Postulante Patrocinado Historial Reportes

administrar

Postulante
Registro
Usuario Registro Patrocinado
patrocinado
Modificar Usuario Historial
Evaluacion Actualizacion
Patrocinado Registrar Reportes
Eliminar Usuario Historial
Postulante
Buscar Editar
Patrocinado Historial
Patrocinado
Eliminar
Historial Historial

Figura 3.24. Modelo de presentación: administrador

Fuente: Elaboración Propia

3.4. FASE DE CONSTRUCCIÓN

El objetivo de esta fase consiste en desplegar el sistema hasta el punto en que esté listo para
pre producción de pruebas, abordaremos el diseño de interfaces abstractas que es parte de la
metodología oohdm.
3.4.1 DISEÑO DE INTERFAZ ABSTRACTAS

Una vez finalizado el diseño navegacional, será necesario especificar las diferentes
interfaces de la aplicación. El diseño de interfaz se desarrolló siguiendo el modelado de
requerimientos y el modelado de diseño

[Link]. AUTENTIFICACIÓN

El usuario que desee acceder al sistema debe de tener previamente, su cuenta de usuario y
contraseña, que son asignados por el administrador del sistema, para el caso será el
responsable de patrocinio. (Ver Figura 3.25)

custom ADV Autentificacion

LOGO CABECERA

ADV AUTENTIFICACION

ADV VERIFICACION

PIE DE PAGINA

Figura 3.25. ADV: Autentificación del sistema

Fuente: Elaboración Propia
[Link]. PANTALLA PRINCIPAL

Una vez que el usuario ha ingresado al sistema con su usuario y contraseñas respectivas, el
sistema le permite el acceso a la página principal, donde dependerá del usuario ingresado,
el acceso a diferentes opciones del menú del sistema que se muestra a continuación. (Ver
Figura 3.26)

custom ADV Pantalla principal

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV PRINCIPAL

LISTA DE IMAGENES

PIE DE PAGINA

Figura 3.26. Pantalla Principal del Sistema

Fuente: Elaboración Propia
[Link]. INICIO

El menú inicio nos despliega dos opciones que son el de volver a la pantalla principal y
también el de salir del sistema, como se observa en la siguiente figura. (Ver Figura 3.27)

custom ADV Menu Ini...

LOGO CABECERA

ADV INICIO

ADV PRINCIPAL

ADV SALIR

PIE DE PAGINA

Figura 3.27. ADV: Menú Inicio del sistema

Fuente: Elaboración Propia

[Link]. ADMINISTRACIÓN DE USUARIO

La administración de usuario se realiza al desplegar el menú de usuario, donde se muestra

tres opciones de elección, que son el de registro de usuario, modificación de usuario y
eliminación de este, la siguiente figura muestra estos detalles. (Ver figura 3.28)
 custom ADV ADMINISTRAR USUARIO

LOGO CABECERA

ADV USUARIO

ADV REGISTRAR USUARIO

ADV MODIFICAR USUARIO

ADV ELIMINAR USUARIO

PIE DE PAGINA

Figura 3.28. ADV: Menú usuario del sistema

Fuente: Elaboración Propia

[Link]. REGISTRAR USUARIO

Al desplegar la opción usuario, se elige la opción de registro de usuario en donde se llenan

los datos respectivos del usuario, como ser nombre, usuario, contraseña, tipo de usuario, y
se elige la opción de registrar y limpiar, además si este es de tipo usuario se sabe que es un
patrocinado entonces se debe pone también los datos de su patrocinador que son: cedula del
patrocinador, país de procedencia, posterior mente se elige la opción de registrar y limpiar,
en la siguiente figura se observa el detalle. (Ver Figura 3.29)

custom ADV Registrar Usuario

LOGO CABECERA

OPCIONES DE ADMINISTRACION

REGISTRO USUARIO

ADV REGISTRAR

PIE DE PAGINA

Figura 3.29. ADV: Registro de usuario

Fuente: Elaboración Propia

Después de registrar los datos respectivos en el sistema, nos muestra en un recuadro

amarillo que es el respectivo mensaje de que el usuario fue ingresado correctamente y no
existe ningún error, esto muestra que el procedimiento se realizó satisfactoriamente y se
llegó a registrar en la base de datos todo lo introducido
[Link]. MODIFICACIÓN DE USUARIO

En la modificación de usuario el administrador podrá realizar los cambios que son

requeridos como equivocaciones para el respectivo usuario, como ser nombre, usuario,
contraseña, o simplemente cambiar los datos, esto para una mayor seguridad en el sistema,
la administración y para el mismo usuario que utiliza el sistema de registro y
administración de documentos. (Ver Figura 3.30)

custom ADV Modificar Usua...

LOGO CABECERA

OPCIONES DE ADMINISTRACION

MODIFICAR USUARIO

ADV BUSCAR
Usuario: T ext

ADV MODIFICAR

PIE DE PAGINA

Figura 3.30. Modificación de Usuario

Fuente: Elaboración Propia
[Link]. ELIMINACIÓN DE USUARIO

Para la eliminación de usuarios se debe buscar por nombre de usuario o por usuario, así se
accede a la página de eliminación verificando datos se procede con lo decidido. (Ver Figura
3.31)

obj ect ADV Eliminar Usua...

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ELIMINAR USUARIO

ADV BUSCAR

Usuario: text Buscar

ADV ELIMINAR

PIE DE PAGINA

Figura 3.31. Eliminación de Usuario

Fuente: Elaboración Propia
[Link]. REGISTRO POSTULANTE

La administración se encarga del registro del postulante, es ahí donde se ingresa los
primeros datos del que será o no el nuevo patrocinado o patrocinada se debe llenar
obligatoriamente todos los datos, además de eso se debe llenar los datos de los padres de
familia su estado civil, la ocupación que ejercen en el momento, sus nombres y apellidos,
grado de estudio y lo más importante el número de referencia, donde se los pueda ubicar si
existiera alguna urgencia o simplemente para constancia acerca del patrocinado, llenado
todos los datos se escoge la opción de registrar donde muestra un mensaje de registro
correcto en la siguiente figura se muestra todo lo anterior. (Ver Figura 3.32)

custom ADV Registrar Usuario

LOGO CABECERA

OPCIONES DE AMINISTRACION

ADV REGISTRAR POSTULANTE

ADV REGISTRAR

PIE DE PAGINA

Figura 3.32. ADV: Registro de Postulante

Fuente: Elaboración Propia
[Link]. EVALUACIÓN DE POSTULANTE

La opción de evaluación de postulante es para admitir o no al postulante dentro del centro

de desarrollo integral, según lo que acordaron previamente dirección y comité fiscalizador
una vez evaluado los requisitos entregados, los resultados se muestran en el sistema,
responsable de esto el área de patrocinio que ingresara a la opción específica para admitir o
rechazar al postulante, en la siguiente figura se observa este proceso. (Ver Figura 3.33)

custom ADV EVALUACION POSTULANTE

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV EVALUACION POSTULANTE

ADV BUSCAR

Usuario: T ext

ADV ACTUALIZAR
ADV ELIMINAR

PIE DE PAGINA

Figura 3.33. Evaluación del Postulante

Fuente: Elaboración Propia
[Link]. REGISTRO DE PATROCINADO

El registro de patrocinado simplemente es el llenado de los datos faltantes y necesarios q un

patrocinado/a debe de tener, así q se actualizan los datos sobre la información ya ingresada
en la postulación, una vez ingresado los datos se escoge la opción de registrar la siguiente
figura nos muestra este caso. (Ver Figura 3.34)

custom ADV REGISTRO PATROCINADO

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REGISTRO PATROCINADO

ADV BUSCAR
Usuario: Text

ADV GUARDAR
ADV ELIMINAR

PIE DE PAGINA

Figura 3.34. Registro de Patrocinado

Fuente: Elaboración Propia
[Link]. ELIMINACIÓN DE PATROCINADO

Una vez que el patrocinado llega a culminar su desarrollo en el centro la dirección tiene el
deber de dar de baja a este porque ya se cumplió el término que se estableció, así que el
patrocinado deja de serlo una vez que se elimine de las listas. En la siguiente figura 3.35 se
representa esta eliminación

custom ADV ELIMINAR PATROCINADO

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REGISTRO PATROCINADO

ADV BUSCAR
Usuario: T ext

ADV ACTUALIZAR
ADV ELIMINAR

PIE DE PAGINA

Figura 3.35. Eliminación de Patrocinado

Fuente: Elaboración Propia

100
[Link]. BÚSQUEDA DE PATROCINADO

Al elegir la opción de búsqueda, primero se debe ingresar el código asignado del

patrocinado/a y se despliega todos sus datos registrados, así el administrador verifica los
datos para sus respectiva administración, además que se puede elegir la opción de actualizar
datos, por si alguno de ellos cambio algún dato como ser la dirección o el teléfono de
referencia, en la siguiente figura se observa lo mencionado. (Ver Figura 3.36)

custom ADV BUSQUEDA PATROCINADO

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REGISTRO PATROCINADO

ADV BUSCAR
Usuario: T ext

ADV ACTUALIZAR

PIE DE PAGINA

Figura 3.36. Búsqueda de Patrocinado

Fuente: Elaboración Propia
[Link]. REGISTRO DE HISTORIAL

Al momento de realizar el registro de historial los datos introducidos anteriormente, se

despliegan automáticamente, siendo más fácil el llenado de los demás datos para la
administración, en esta sección se introducen los documentos que también son requeridos,
como ser el certificado de vacunas y el certificado de nacimiento del patrocinado, además
de las fotocopias de carnet de identidad de los padres de familia, un croquis, y las
fotocopias de agua y luz, una vez introducidos estos datos, se va a la opción de registrar
donde nos mostrara el mensaje respectivo de correcto o incorrecto, o si los datos
introducidos son incorrectos, la siguiente figura no detalla este proceso. (Ver Figura 3.37)

custom ADV Registrar Historial

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REGISTRO HISTORIAL PATROCINADO

ADV REGISTRAR

PIE DE PAGINA

Figura 3.37. ADV: Registro de Historial

Fuente: Elaboración Propia
[Link]. BÚSQUEDA Y EDICIÓN DE HISTORIAL

En la opción buscar historial, se tiene que ingresar el código de patrocinado, para generar
los datos correspondientes, una vez ingresado, podrá realizar los cambios adecuados de la
información extraída del patrocinado, una vez realizado los cambios este mandara un
mensaje que dirá que los datos fueron actualizados correctamente. En la figura 3.38 se
representa el proceso anterior. La edición de historial se encarga de modificar y actualizar
los datos registrados en el sistema para una mayor administración además de notificar al
patrocinado que es lo que le está faltando entregar para su respectivo registro, en la
siguiente figura se muestra el proceso de edición de historial del sistema.

custom ADV Edicion Historial

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV EDICION HISTORIAL PATROCINADO

ADV BUSCAR

Patrocinado: T
ext

ADV MODIFICAR

PIE DE PAGINA

Figura 3.38. ADV: Búsqueda y modificación de historial

Fuente: Elaboración Propia
[Link]. REPORTE POSTULANTE

El reporte de postulante, permite informar a la administración como a los padres de familia

sobre los datos que se recabaron sobre el postulante, así mismo poder tener documentación
legible a la vista, para que la administración y el comité fiscalizador puedan evaluar dicha
información, que se presentara impresa. La figura 3.39 muestra este detalle.

custom ADV Reporte Postulante

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REPORTE POSTULANTE

ADV BUSCAR
Patrocinado: Text

ADV IMPRIMIR

PIE DE PAGINA

Figura 3.39. ADV: Reporte del postulante

Fuente: Elaboración Propia

[Link]. REPORTE HISTORIAL

Así mismo esta opción detallara el historial completo del patrocinado, como ser sus datos
personales, datos de los padres de familia, datos del patrocinador, además de la
documentación entregada, que es una manera de ver si a este le falta entregar
documentación que debe ser completada. El reporte de patrocinado, permite informar a la
administración como a los padres de familia sobre los datos que se recabaron sobre el
patrocinado, así mismo poder tener documentación legible a la vista, además de poder
enviar esta información a los que son responsables de mandar esta información al
patrocinador del niño, para que este se entere de quien es el patrocinado. La figura 3.40
muestra este detalle.

custom ADV Reporte Historial Patrocinado

LOGO CABECERA

OPCIONES DE ADMINISTRACION

ADV REPORTE POSTULANTE

ADV BUSCAR

Patrocinado: Text

ADV IMPRIMIR

PIE DE PAGINA

Figura 3.40. ADV: Reporte del Patrocinado

Fuente: Elaboración Propia
3.5. FASE DE TRANSICIÓN

La fase de transición se dirige en liberar el sistema en producción para clausurar esta fase se
cumple, con la aprobación y visto bueno del diseño e implementación del sistema que será
por parte de los usuario y el área de patrocinio del centro de desarrollo integral BO-132, los
cuales harán las pruebas necesarias.

3.5.1. IMPLEMENTACIÓN

Para esto se aplica pruebas extensivas a lo largo de esta fase, una buena afinación del
proyecto tiene lugar aquí, incluyendo modificaciones a los defectos significativos, se
destaca las pruebas de caja blanca y caja negra, con el objeto de descubrir defectos que
tiene el sistema.

”La prueba no puede asegurar la ausencia de defectos, solo puede demostrar que existe
defectos en el software” [PRESSMAN, 2005].

[Link]. PRUEBAS DEL SISTEMA

El motivo de la elección de este método, es la utilidad que tiene para probar software. La
prueba de caja negra intenta descubrir errores en las siguientes categorías:

1) Funciones incorrectas o ausentes.

2) Errores de interfaz.
3) Errores en la estructura de datos o acceso a base de datos externas.
4) Errores de rendimiento.
5) Errores en la inicialización y terminación.

El mismo consiste en catalogar las entradas y salidas del sistema, primeramente en forma
global y después en forma consecutiva en cada uno de sus componentes que se encuentran
elaborados.

Esto se lo realiza en forma independiente y la manera en que estas son transformadas, para
tener un mejor y buen comprendimiento del objetivo de cada uno de los distintos
componentes. (Ver Figura 3.41)
 Figura 3.41. Prueba de caja negra
Fuente: Elaboración Propia

 Se realizó pruebas unitarias, es decir cada módulo en el momento de la construcción

previamente puesta en producción.
 La prueba de integración se realiza cuando todos los módulos, están diseñados y
desarrollados, para luego integrarlos y posteriormente realizar pruebas de todo el
sistema.
 Las pruebas del software se realiza una vez integrado los módulos, se procede a las
pruebas con datos reales.
 Las pruebas de implantación, se realiza en forma incremental, es decir que ya parte
del sistema está en plena producción acorde a la metodología AUP.
 Las pruebas de aceptación, después del periodo de pruebas, se espera que el sistema
sea aceptado por los usuarios finales.

[Link]. PRUEBAS DE ESTRÉS

Conocidas como “stress testing”, muchas veces engloban de forma errónea al resto de
pruebas mencionadas anteriormente. El objetivo de estas pruebas es obtener datos, sobre la
carga del sistema, que ayuden a realizar el dimensionamiento del sistema o “capacity
planning”. Esta prueba genera carga en el sistema hasta hacerlo inutilizable. Una vez que la
aplicación ha dejado de funcionar, nuestros consultores se centran en distintos objetivos,
como por ejemplo: verificar la calidad de los mensajes de error del sistema o establecer
alertas para poder anticipar un fallo total del sistema. Las pruebas de estrés son uno de los
 últimos tipos de pruebas que se deben ejecutar, ya que, por su carácter poco realista, podría
darse el caso de que la situación de carga simulada nunca se diera en la vida real.

Las pruebas de rendimiento son ejecutadas por medio de scripts automatizados, éstos se
encargan de emular las acciones que realizaría un usuario final sobre la aplicación bajo
pruebas. Los scripts se ejecutan en paralelo, cada uno de ellos emulando un “usuario
virtual”, de esta forma, anticipando la carga esperada cuando el sistema pase a producción.
Durante la ejecución de las pruebas, nuestros consultores se encargan de vigilar el sistema,
de indicadores de rendimiento, esta acción es comúnmente llamada monitorización del sistema.
iza la herramientaque recibe
de Apache-jmeter, con el cual se pudo sacar los siguientes resultados, como se observa en la siguiente figura

Figura 3.42. Apache JMeter: Informe Agregado

Fuente: Elaboración Propia

Se tiene una tabla con una fila para cada petición realizada. Se observa que las peticiones
todas los campos se han repetido 30 veces (columna Muestras): esto es porque existían 3
muestras de peticiones a esas URL`s en diferentes momentos de la Prueba. Aquí salen
agrupadas.

Los valores están calculados tomando el tiempo total que ha tardado la prueba (la ejecución
de mis 10 usuarios), por lo tanto, cuantas más muestras haya más tiempo total de ejecución;
influye en cada línea de la tabla. Para cada línea (petición) tenemos:

 el máximo de tiempo invertido por una petición (columna Max).

 el mínimo de tiempo invertido por una petición (columna Min).
 la media de tiempo invertido por una petición (columna Media).
 la mediana de tiempo invertido por una petición: significa que el 50% de las
muestras tardaron menos del valor reflejado.
 El tanto por ciento de respuestas con error.
 El rendimiento (thoughput): número de peticiones procesadas en una unidad de
tiempo, que puede ser segundos, minutos y horas.
 El rendimiento en Kb/segundo: igual que la anterior pero con cantidad de datos en
lugar de peticiones
Por lo que se puede concluir, que el servidor es capaz de responder a 2.2 peticiones por
minuto a la página de login (primera muestra), o que la petición a “imprimir reportes de
estadísticas”, es la que más tarda en procesarse con respecto a la media. En la siguiente
figura se muestra el gráfico en barras (Ver Figura 3.43)

Figura 3.43. Apache JMeter: Grafico de barras

Fuente: Elaboración Propia
[Link]. PRUEBAS DE SEGURIDAD

La seguridad es responsabilidad de todos aquellos que están en contacto con el sistema. La

cual lo enfocamos desde tres aspectos interrelacionados entre sí: físico, lógico y conductual

SEGURIDAD FÍSICA

 El servidor debe ser manejado por el personal autorizado, en este caso sería la
responsable de patrocinio, para una buena administración de base de datos. En caso
de mantenimiento técnico, este deberá consultar al administrador del sistema.
 A la oficina de patrocinio, se debe restringir, el acceso físico de otras personas, que
nos son propios de esta oficina, para una mayor seguridad.
 El personal de limpieza debe estar consciente de las restricciones de seguridad.

SEGURIDAD LÓGICA

Se especifica, al acceso delos usuarios, a los recursos y a la información que dispone en un

ordenador, como también al uso correcto de los mismos. Cuando se utilizan, permiten al
usuario entrar al sistema o a una parte particular de una base de datos con una contraseña
correcta, entre las cuales se destacan:

 Seguridad del motor Sql Manger of MySql, contraseña de acceso a base de datos.
 Seguridad del sistema, mediante el manejo de usuarios del sistema y contraseñas.
 Se puede utilizar Back Up de la base de datos, solo por usuarios con este rol de
manejo de sistemas.
 Sistema de encriptación de contraseñas, para que el usuario confié en el sistema.
 Se puede realizar restauración del sistema en caso de eventualidades, es decir
recuperar una copia anterior.

SEGURIDAD CONDUCTUAL

 Crear conciencia en el manejo de información de patrocinados a través de

capacitaciones planificaciones, para que os mismos reconozcan el valor que tiene la
información.

110
  Identificación de personal que eventualmente tendrán acceso a la computadora,
datos e información para asegurar que sus intereses son consistentes con los interese
del centro CDI BO-132 y que entienden por completo la importancia de llevar a
cabo los procedimientos de seguridad.
 Se crea un manual de funciones, que describan las políticas con respecto a la
seguridad, para que los patrocinados estén totalmente conscientes de las
expectativas y responsabilidades que se deben asumir.

3.5.2. RESTRICCIONES DEL SISTEMA

 El sistema funciona dentro del entorno de Windows XP adaptable a sus

siguientes versiones.
 El sistema funciona en un entorno de red intranet, pero se tiene previsto, para
que pueda ser utilizado desde la web, una vez se adquiera su respectivo
dominio, de acuerdo a las políticas que el centro adopte.

3.5.3. CAPACITACIÓN

La capacitación del personal del Centro de Desarrollo Integral CDI BO-132, que maneja el
sistema para el registro y administración de documentos, se realiza de la siguiente manera:

 Instalación del sistema.

 Back Up y restauración de la base de datos del sistema.
 Altas de usuarios, postulantes, patrocinados e historiales.
 Ubicación física de equipos.
 Políticas de manejo de usuarios y patrocinados.
 Ingreso al sistema.
 Registro, modificación y eliminación de usuarios.
 Registro y evaluación de postulantes,
 Registro, actualización y búsqueda de patrocinados.
 Registro, edición y búsqueda de historial.
 Elaboración de reportes de postulantes, patrocinados e historiales.
 CAPITULO IV

CALIDAD DE SOFTWARE Y SEGURIDAD

4.1. INTRODUCCIÓN

La calidad del software es la concordancia con los requerimientos funcionales y de

rendimiento directamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se esperan de todo software
desarrollado profesionalmente.

Un producto de alta calidad requiere menos mantenimiento y facilita tanto el desarrollo

como el mantenimiento de la productividad. Con la medición de la calidad se pueden lograr
estos objetivos. En lo que se refiere al mantenimiento, la medición de la calidad del
software ayuda a identificar problemas de confiabilidad y a mejorar las técnicas para
identificar las necesidades de mantenimiento. A continuación se detallan los factores de
calidad con el objeto de evaluar la calidad del software.

Al termino del Sistema Web para el Registro y administración de Documentos, se debe

medir la calidad del producto, existe dos tipos de medición directa e indirecta. En el
presente proyecto se aplicara las medidas indirectas planteada por la norma ISO 9126

4.2. CARACTERÍSTICAS PROPUESTAS POR ISO-9126

La necesidad de comparar productos motiva el trabajo para la definición de un modelo

estándar.

ISO 9126 entrega la definición de las características y los procesos de evaluación de calidad
asociados para usar cuando se especifican los requisitos y la evaluación de los productos de
software a lo largo de su vida útil.

Los factores relacionados con la norma ISO 9126, están representados por seis los cuales
son: funcionalidad, confiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad, a
continuación se muestra en la siguiente figura 4.1 las preguntas usuales que se hacen en cada
factor.

FUNCIONALIDAD
Las funciones
requeridas están
disponibles en
el software?

MANTENIBILIDAD
Qué tan fácil de CONFIABILIDAD
modificar es el Qué tan confiable
software?
ISO es el software?

PORTABILIDAD
9126
Qué tan fácil USABILIDAD
es transferir el Es fácil de
software a usar el
otro entorno? software?
EFICIENCIA
Qué tan
eficiente es
el software?

Figura 4.1: Norma ISO-9126

Fuente: Elaboración Propia

Funcionalidad: conjunto de atributos que soporta la existencia de un conjunto de

funciones y sus propiedades específicas. Las funciones son tales que satisfacen las
necesidades implícitas o establecidas.

Confiabilidad: El conjunto de atributos que soporta la capacidad del software para

mantener su nivel de rendimiento bajo condiciones establecidas por un periodo de tiempo
establecido.

Usabilidad: El conjunto de atributos que soporta el esfuerzo necesario para el uso y la

evaluación individual de tal uso mediante un conjunto de usuarios establecidos e implícitos.
Eficiencia: el conjunto de atributos que soporta las relaciones entre el nivel de rendimiento
del software y el monto de recursos empleados, bajo condiciones establecidas.

Mantenibilidad: El conjunto de atributos que soporta el esfuerzo necesario para realizar

modificaciones especificadas

Portabilidad: El conjunto de atributos que soporta la habilidad del software para

transferirlo de un entorno a otro.

4.2.1. CONFIABILIDAD

La confiabilidad de un sistema es una unidad muy importante en su calidad general. Para

comprobar la confiabilidad se toma en cuenta las fallas que se producen en el sistema en un
tiempo determinado, también es el grado en que el sistema responde bajo las condiciones
definidas durante un intervalo de tiempo dado. En primer lugar se considera la confiablidad
de cada módulo independientemente. Para esto se requiere el modelo del sistema, que se
observa en la siguiente figura 4.2.

obj ect Modelo del Siste...

R2
Administracion
del Sistema

R3
Administracion
de Postulante

R4
[u(t)] R1 [y(t)]
Autentificacion Administracion
de Usuarios de
Initial Patrocinados Final

R5
Reportes

R6
Planillas

Figura 4.2: Modelo del Sistema Web de Registro y Administración de Documentos

Fuente: Elaboración Propia
Se toma en cuenta la siguiente relación:

𝑅(𝑡) = 𝑒−𝜆𝑡 ………………….. (1)

Donde:

R(t) = Confiabilidad de un componenete o subsistema t.

e−λt = Probabilidad de falla de un componente o subsistema en

tiempo t. T = Tiempo de trabajo sin falla.

λ = Tasa constante de fallos.

t = Periodo de operacion de tiempo.

Posteriormente se realiza los cálculos para cada módulo utilizando la ecuación (1).

MÓDULOS 𝛌 T R(t)
1 Autenticación de Usuario 0.02 2 Hrs. 0.96
2 Administración del Sistema 0.03 3 Hrs. 0.91
3 Administración del Postulante 0.04 3 Hrs. 0.89
4 Administración del Patrocinado 0.03 3 Hrs. 0.91
5 Reportes 0.04 3 Hrs. 0.89
6 Planillas 0.03 3 Hrs. 0.92

Tabla 4.1: Calculo de Confiabilidad

Fuente: Elaboración Propia

En la figura 4.1 se muestra claramente que el modelo del sistema tiene una conexión inicial
en serie y posteriormente una conexión en paralelo, por lo que realizando los cálculos se
obtiene:

R = Ri ∗ Rs ……………........(2)

Donde Ri = R1 = 0.96
Rs(t) = 1 − {(1 − R2(t)) ∗ (1 − R3(t)) ∗ … ∗ (1 − Rn−1(t)) ∗ (1 − Rn(t))}
……. (3)

Remplazando los datos en la ecuación 3 se obtiene:

Rs(t) = 1 − {(0.09) ∗ (0.11) ∗ (0.09) ∗ (0.11) ∗

(0.08)} Rs(t) = 0.9999922

Reemplazando en la ecuación 2 se tiene:

R = 0.96 ∗ 0.9999922

R = 96%

Interpretación

Con el resultado obtenido anteriormente, se puede decir que el “Sistema Web para el
Registro y Administración de Documentos de niños patrocinados caso CDI BO-132”,
demuestra que del 100% un 96% es confiable y un 4% de que cualquiera de los
componentes falle

4.2.2. FUNCIONALIDAD

Es preciso evaluar un conjunto de características y capacidades del sistema, ya que la

funcionalidad no se mide directamente. El sistema debe ser apto, para proveer las funciones
que cumplan con las necesidades explicitas e implícitas, cuando es utilizado en la
condiciones especificadas por el cliente.

Para el procesamiento de datos de la funcionalidad utilizaremos la métrica de punto

función, para esto se debe determinar cinco características de dominios de información,
donde se proporciona las cuentas en la posición apropiada a la tabla. Los valores de
dominio de información se definen de la siguiente forma:

 Número de entradas de Usuario.

 Número de salidas de Usuario.
 Número de peticiones de Usuario.
  Número de archivos.
 Número de interfaces externas.

Para el procesamiento de datos de punto función se utiliza la siguiente ecuación:

PF = cuenta total ∗ (0.65 + 0.01 ∗ ∑ Fi)………………………….. (1)

Dónde:

PF = Medida de Funcionalidad.

Cuenta Total = Es la suma de todas las entradas obtenidas en Nro de entradas, Nro de
salidas, Nro de peticiones, Nro de archivos, Nro de interfaces externas.

∑ Fi= Son los valores de ajuste de complejidad según las respuestas a preguntas destacadas
en la siguiente tabla.

Con todos estos pasos tomados en cuenta se prosigue con el cálculo del punto función.

[Link]. NÚMERO DE ENTRADAS DE USUARIO

Es todos los datos que vienen desde el exterior, que tiene una sola dirección, que es del
exterior al interior. En la siguiente tabla 4.2 se observa las entradas de usuario que tiene el
sistema.

Nº ENTRADAS DE USUARIO

1 Pantalla de Ingreso al Sistema.

2 Registro de Usuario.
3 Registro de Postulante.
4 Registro de Patrocinado.
5 Registro de Historial.

Tabla 4.2. Entrada de Usuarios

Fuente: Elaboración Propia
[Link]. NÚMERO DE SALIDAS DE USUARIO

Es la información elaborada por el sistema que son transmitidas al usuario, también

actualizan algunos archivos, tiene una sola dirección del interior al exterior. En la siguiente
tabla 4.3 se puede observar las salidas del usuario.

Nº SALIDA DE USUARIO
1 Detalle del Postulante
2 Detalle del Historial de Patrocinado
3 Reporte de estadísticas de registro

Tabla 4.3. Salidas de usuario

Fuente: Elaboración Propia

[Link]. NÚMERO DE PETICIONES DE USUARIO

Es una entrada interactiva que produce la generación de algunas respuestas del sistema
inmediata en forma interactiva. Se puede observar las peticiones de usuario en la siguiente
tabla 4.4.

Nº PETICIONES DE USUARIO

1 Autentificación de Usuario

2 Modificación de Usuario

3 Modificación de Postulante

4 Modificación de Patrocinado

5 Modificación de Historial

6 Listado de Postulantes

7 Listado de Patrocinados

Tabla 4.4. Petición de Usuario

Fuente: Elaboración Propia
[Link]. NUMERO DE ARCHIVOS

Es un grupo lógico de datos, que puede llegar a ser una parte de una gran base de datos o un
archivo independiente. En la siguiente tabla 4.5 se puede observar el número de archivos.

Nº ARCHIVOS
1 Usuario
2 Patrocinado
3 Postulante
4 Patrocinador
5 Reporte
6 Historial

Tabla 4.5. Archivos

Fuente: Elaboración Propia

[Link]. NUMERO DE INTERFACES EXTERNAS

Son todas las interfaces legibles por la computadora que se utilizan para transmitir
información a otro sistema. Una vez que se ha seleccionado los datos anteriores, a la cuenta
se asocia un valor de complejidad. En la siguiente tabla 4.6 se puede observar las interfaces
externas.

Nº INTERFACES EXTERNAS

1 Internet

2 Intranet

Tabla 4.6. Interfaces Externas

Fuente: Elaboración Propia

[Link]. PONDERACIÓN

En seguida se reúne todos los datos encontrados, para su respectiva ponderación. Para
realizar puntos de función es necesario elegir un criterio de ponderación, que en el caso se
utiliza el factor medio. En la siguiente tabla 4.7 detallamos lo explicado.
 Parámetro de Medición Cuenta FACTORES DE PONDERACIÓN
Simple Medio Complejo Total
Nº de entradas de Usuario 5 * 3 4 6 = 20

Nº de salidas de Usuario 3 * 4 5 7 = 15

Nº de peticiones de Usuario 7 * 3 4 6 = 28

Nº de archivos 6 * 7 10 15 = 60

Nº de interfaces externas 2 * 5 7 10 = 14

Cuenta total 137

Tabla 4.7. Cálculos de puntos de Función no ajustados

Fuente: Elaboración Propia

Para el ajuste del modelo en función de la complejidad del proceso es necesario analizar las
características propias del proceso, respondiendo 14 preguntas utilizando la siguiente tabla
4.8

GRADO DESCRIPCIÓN

0 No está presente o no influye

1 Influencia Mínima

2 Influencia Moderada

3 Influencia Promedio

4 Influencia Significativa

5 Influencia Fuerte

Tabla 4.8. Ponderaciones

Fuente: Elaboración Propia

Las 14 preguntas a responder se muestran en la tabla 4.9.

120
 FACTOR
Nº CARACTERÍSTICAS
Fi
1 ¿Requiere el sistema copias de seguridad y de recuperación 5
fiables?
2 ¿Se requiere comunicación de datos? 5
3 ¿Existen funciones de procesamiento distribuido? 2
4 ¿Es crítico el rendimiento? 2
5 ¿Se ejecutaría el sistema en un entorno operativo existente y 4
fuertemente utilizado?
6 ¿Requiere el sistema entrada de datos interactiva? 3
7 ¿Requiere la entrada de datos interactiva que las transacciones de 4
entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8 ¿Se actualizan los archivos maestros de forma interactiva? 2
9 Son complejas las entradas, las salidas, los archivos o las 3
peticiones?
10 ¿Es complejo el procesamiento interno? 4
11 ¿Se ha diseñado el código para ser reutilizable? 3
12 ¿Están incluidas en el diseño la conversi6n y la instalaci6n? 5
13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones 5
en diferentes organizaciones?
14 14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para 4
ser fácilmente utilizada por el usuario?
Factor de Ajuste de Complejidad 51

Tabla 4.9. Valores de Ajuste de Complejidad

Fuente: Elaboración Propia

Remplazando los datos anteriores en la fórmula de punto función de la ecuación 1, se tiene:

PF = 137 ∗ (0.65 + 0.01 ∗ 51)

El punto función del Sistema Web de Registro y Administración de Documentos de niños

Patrocinados caso: CDI BO-132, es:

PF = 180
Luego comparando los valores de funcionalidad del sistema con el punto función, máximo
que se puede alcanzar es:

PF = 137 ∗ (0.65 + 0.01 ∗ 70)

PF = 190

Por lo que la funcionalidad del Sistema Web de Registro y Administración de Documentos

de niños Patrocinados caso: CDI BO-132, será:

180
Funcionalidad = (
190) ∗ 100

%
Funcionalidad = 94.73

Interpretación:

De un 100% un 94.73% del sistema se concluye que es funcionable, pero un 6% puede

llegar a no ser funcionable.

4.2.3. MANTENIBILIDAD

Para el procesamiento de datos de la mantenibilidad del sistema, utilizaremos las medidas

directas proporcionadas por la IEEE 982.1 – 1998, el cual propone un índice de madurez
del sistema, que consisten en los cambios que producen, en cada versión del producto, para
lo dicho se tiene la siguiente ecuación.
[𝑀𝑇−(𝐹𝑎+𝐹𝑏+𝐹𝑐)]
IMS = ………………………….. (1)
𝑀𝑇

Donde:

IMS = Índice de madurez del sistema

MT = Número de módulos en la version actual.

Fa = Número de módulos en la version actual que se han cambiado.

Fb = Número de módulos en la versión actual que se han añadido.

Fc = Número de módulos en la versión anterior que se han borrado en la versión actual.

Si el valor del IMS se aproxima a 1, el sistema empieza a estabilizarse.

Por lo tanto los valores encontrados son:

MT = 6

Fa = 0

Fb = 0

Fc = 0

Reemplazando estos valores en la ecuación 1 se obtiene:

[6 − (0 + 0 +
IMS = 0)]
6

IMS = 1 ∗ 100

IMS = 100%

Interpretación:

Por lo tanto se deduce que el índice de madurez del sistema en un 100% tiende a
estabilizarse, lo que indica es el sistema es estable.

4.2.4. PORTABILIDAD

Es la capacidad del software para ser transferido de un ambiente de operaciones a otro. La

portabilidad del software se enfoca en tres aspectos: a nivel de aplicaciones, a nivel de
sistema operativo y adaptación al cambio. Dado por la siguiente fórmula:
CT
GP = 1 − ( ) ……………………….. (1)
CRD

Dónde:

GP = Grado de portabilidad.
CT = Costo de Transportar.

CRD = Costo de Re-Desarrollo.

• Es > 0, la portabilidad es mas rentable que el

re- desarrollo.
Si GP • Es = 1, la portabilidad es perfecta.
• Es < 0, el re-desarrollo es mas rentable que
la portabilidad.

Reemplazando en la ecuación 1, tenemos:

75
GP = 1 − ( )
2000

GP =
0.96258
Interpretación:

Por lo tanto del 100% de grado de portabilidad del sistema puede movilizarse de un entorno
a otro en un 96%, que es más rentable que el re-desarrollo y un 4% puede llegar a no tener
portabilidad.

[Link]. NIVEL DE APLICACIONES

El sistema es desarrollado en el lenguaje de PHP, utilizando Dreamweaer CS4 como su

editor de código. Con su gestor de base de datos Mysql, utilizano el servidor Wampserver,
en cuanto al sistema desarrollado es portable, ya que el sistema puede ser distribuido en CD
´s, memory flash.

[Link]. NIVEL DEL SISTEMA OPERATIVO

El sistema llega a ser portable para los sistemas operativos de Windows como ser: Windows
2000, Windows XP, Windows Vista, Windows Seven.
[Link]. NIVEL DE HARDWARE

En el nivel de hardware, se puede ver que el sistema es portable, es decir que se lo puede
implantar fácilmente en cualquier momento y aptas para todas las computadoras mayores o
iguales a la tecnología Pentium IV.

4.2.5. USABILIDAD

La usabilidad, es el grado en el que el software es fácil de usar, y viene manifestado por la:
facilidad de comprensión, facilidad de aprendizaje y operatividad. Para calcular la
usabilidad del sistema se utiliza las siguientes tres métricas:

[Link]. LA COMPLEJIDAD DE LA DESCRIPCIÓN

Que se encuentra dada por la fórmula:

𝐴
𝑋 = ……………………….. (1)
𝐵

Dónde:

A= Número de funciones (casos de uso) o tipos de funciones explicadas en la descripción

del producto.

B= Número total de funciones (casos de uso).

11
𝑋=
12

𝑋=
0.92
Interpretación:

Por lo tanto el 100% del sistema presenta un 92% de entendimiento por parte de los
usuarios finales respecto a la capacidad del producto y un 8% les falta un poco más de
entendimiento acerca del sistema.
[Link]. CONSISTENCIA OPERACIONAL

Dada por la fórmula:

𝐴
𝑋 = 1 − ………………….. (2)
𝐵

Dónde:

A= Número de instancias con operaciones con comportamiento inconsistente.

B= Número total de operaciones.

Reemplazando en la ecuación 2 tenemos:

1
𝑋=1−
12

𝑋 = 0.92
Interpretación:

Por lo que el sistema muestra de un 100% un 92% de no instancias de operaciones con

comportamiento inconsistente y en un 8% presentan instancias inconsistentes.

[Link]. CONSISTENCIA OPERACIONAL EN EL USO

El cual está dado por la fórmula:

𝐴
𝑋 = 1 − …………………….. (1)
𝐵

Dónde:

A= Número de funciones que el usuario encontró inaceptables, inconsistentes según sus

expectativas.

B= Número de funciones usadas por el usuario durante el periodo de prueba.

Reemplazando en la ecuación 2 tenemos:

 1
𝑋=1−
18

𝑋=
0.96
Interpretación:

Por lo tanto de un 100% del sistema, el usuario encuentra un 4% del sistema inaceptable, en
el periodo de prueba, de acuerdo a los resultados obtenidos anteriormente, el usuario se
encuentra satisfecho con la consistencia operacional del uso del sistema.

[Link]. RESULTADO FINAL

En la siguiente tabla 4.10 se despliega el resultado de los factores de la norma iso 2196.

FACTORES RESULTADO
Confiabilidad 96
Funcionalidad 94.73
Mantenibilidad 100
Portabilidad 96
Usabilidad 93
EVALUACIÓN DE CALIDAD TOTAL 95.95

Tabla 4.10. Resultado total

Fuente: Elaboración Propia

De un usuario que acceda al sistema en su totalidad tendrá un grado de satisfacción del 96%
al utilizarla.
 CAPITULO V

ANÁLISIS DE COSTO/BENEFICIO

5.1. INTRODUCCIÓN

Unas de las tareas más importantes en la planificación de los proyectos de software es la

estimación, el cual consiste en determinar, con cierto grado de certeza, los recursos de
hardware y software, costos, tiempo y esfuerzo necesarios para el desarrollo de los mismo .
En este presente capitulo examinaremos estos términos costos – beneficios, mediante
COCOMO II, modelo de estimación de costos, mediante el obtendremos el esfuerzo,
tiempo y personal necesarios para el desarrollo del software, también utilizaremos los
modelos del VAN, TIR y C/B para obtener los beneficios a los que incurriría la empresa.

En las secciones siguientes examinaremos diversos aspectos de los cálculos de

costo/beneficio:

 Análisis de costos.
 Análisis de beneficios.
 Como expresar los ahorros.
 Análisis de riesgos.

5.2. ANÁLISIS DE COSTOS

Se debe calcular todos los costos pronosticados asociados al sistema. Para establecer el
costo del software desarrollado, se utiliza el modelo constructivo COCOMO II, que están
orientados a los puntos de función. En la siguiente tabla 5.1 se observa la estimación de
puntos de función:

Parámetro de Medición Cuenta Factor de Total

Ponderación
Nº de entradas de usuario 5 4 20
 Nº de salidas de usuario 3 5 10
Nº de peticiones de usuario 7 4 28
Nº de archivos 6 10 60
Nº de interfaces externas 2 7 14
Cuenta Total 135

Tabla 5.1. Calculo de punto función

Fuente: Elaboración Propia

Para el cálculo del factor de complejidad técnica TCF, se toma en cuenta la tabla 5.2, para
considerar la siguiente formula

TCF = (0.65+0.01*51)

TCF = 1.16

FACTOR
Nº CARACTERÍSTICAS
Fi
1 ¿Requiere el sistema copias de seguridad y de recuperación 5
fiables?
2 ¿Se requiere comunicación de datos? 5
3 ¿Existen funciones de procesamiento distribuido? 2
4 ¿Es crítico el rendimiento? 2
5 ¿Se ejecutaría el sistema en un entorno operativo existente y 4
fuertemente utilizado?
6 ¿Requiere el sistema entrada de datos interactiva? 3
7 ¿Requiere la entrada de datos interactiva que las transacciones de 4
entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8 ¿Se actualizan los archivos maestros de forma interactiva? 2
9 Son complejas las entradas, las salidas, los archivos o las 3
peticiones?
10 ¿Es complejo el procesamiento interno? 4
11 ¿Se ha diseñado el código para ser reutilizable? 3
12 ¿Están incluidas en el diseño la conversi6n y la instalaci6n? 5
 13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones 5
en diferentes organizaciones?
14 14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para 4
ser fácilmente utilizada por el usuario?
Factor de complejidad Técnica 51

Tabla 5.2. Calculo de punto de función ajustada

Fuente: Elaboración Propia

El procesamiento de datos del punto función se basa en la formula siguiente:

PF = Cuenta Total * TCF

PF = 135 * 1.16

PF = 156.6

n de los puntos de función a KLDC

minar el esfuerzo nominal en el modelo COCOMO II los puntos función no
tienen que ser convertidos a miles de líneas de código fuente considerando el lenguaje de implementación que se muestra en l

LENGUAJE NIVEL FACTOR LDC/PF

C 2.5 128
Ansi Basic 5 64
Java 6 53
Ansi Cobol 3 107
Visual Basic 7 46
ASP 9 36
PHP 11 29
Visual C++ 9.5 34

Tabla 5.3. Conversión de puntos de función.

Fuente: Elaboración Propia

LDC = PF * Factor LDC/PF

130
 LDC = 156.6* 29

LDC = 4591.98

Las líneas de código en su totalidad son 4440.48, entonces el número estimado de líneas de
código distribuidas en miles es:

KLCD = LCD / 1000

KLDC = 4591.98 / 1000 = 4.6

Por tanto existen 4.6 líneas de código distribuidas para el proyecto.

Ahora se aplican las formulas básicas de esfuerzo, tiempo calendario y personal requerido.

Las ecuaciones del COCOMO básico tienen la siguiente forma:

E = 𝑎𝑏(KLDC)𝑏𝑏 ………………. (1)

D = 𝑐𝑏𝐷𝑑𝑏 …………………….. (2)

Donde:

E: Esfuerzo aplicado en personas por mes.

D: Tiempo de desarrollo en meses cronológicos.

KLDC: Número estimado de líneas de código distribuidas (en miles).

Proyecto de software ab bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semi – acoplado 3 1.12 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32

Tabla 5.4. Relación de valores del modelo COCOMO

Fuente: Elaboración Propia

En la tabla 5.4 se muestran los tipos de proyectos de software, como este es un proyecto
intermedio, en tamaño y complejidad, se elige semi-acoplado.
Reemplazando los datos en la ecuación 1 se tiene:

E = 3(4.6)1.12
E = 16.57 [programadores/mes]

D = 2.5(16.57)0.35

D = 6.68 [meses]

El personal requerido, en este caso el número de programadores (Nº Prog) se obtiene con la
siguiente fórmula:

Nº Prog = E/D

Nº Prog = 16.57 / 6.68

Nº Prog = 2.48

Nº Prog = 2 [programadores]

El salario de un programador puede oscilar entre los 2166 $us, cifra que es tomada en cuenta
para la estimación siguiente:

Costo del software desarrollado por persona = Numero de programadores * salario de un

programador

Costo del software desarrollado por persona = 2 * 2166 $us

Costo del software desarrollado por persona = 4332 $us

Costo total del software desarrollado = 4332* 2

Costo total del software desarrollado = 8664 $us

De donde concluimos que para el desarrollo del “Sistema Web para el Registro y
Administración de documentos de niños patrocinados caso: CDI BO-132”, es necesario
contar con 2 programadores durante 7 meses para su respectivo desarrollo, el tendrá un
costo de 8664$us en bolivianos seria 60648 Bs.

5.3. ANÁLISIS DE BENEFICIOS

Para evaluar los beneficios que se obtendrá al implementar el proyecto se calcula con el
método VAN y el TIR.

El VAN (Valor Actual Neto) es un indicador financiero que mide los flujos de los futuros
ingresos y egresos que tendrá el proyecto, para determinar si luego de descontar la
inversión inicial quedara alguna ganancia. Si el resultado es positivo, el proyecto es viable.

Para hallar el VAN del proyecto de inversión se requiere tres valores de acuerdo a la
siguiente fórmula:

VAN = ∑ 𝑔𝑎𝑛𝑎𝑐𝑖𝑎𝑠 − ∑
𝑐𝑜𝑠𝑡𝑜𝑠
(1 + 0.10)𝑛 (1 + 0.10)𝑛

VAN = ∑ 15000 − ∑
8664
(1 + 0.10)5 (1 + 0.10)5

VAN = 12550 $us

La regla del VAN, que indica qué decisión tomar, es:

 Si el VAN es mayor que cero, se debe aceptar.

 Si el VAN es igual a cero, se debe ser indiferente.
 Si el VAN es menor que cero, se debe rechazar.

Entonces con VAN es mayor a cero, podemos decir que el proyecto sea aceptado.

Luego:

CostoBeneficio = ∑ ganancias
∑ costos

∑ 15000
CostoBeneficio =
∑ 8664
 CostoBeneficio = 1.73 $us

De donde se concluye que por cada 1 $us invertido ganamos 0.73 $us, lo cual significa que
el proyecto es una decisión adecuada.

El TIR (Tasa Interna de Retorno) es la tasa de descuento TD de un proyecto de inversión

que permite que el BNA sea igual a la inversión (VAN igual a 0). La TIR es la máxima TD
que puede tener un proyecto para que sea rentable.

La regla de la TIR, que indica qué decisión tomar, es:

 Si la TIR es mayor que la tasa de descuento, se debe aceptar.

 Si la TIR es igual a la tasa de descuento, se debe ser indiferente.
 Si la TIR es menor que la tasa de descuento, se debe rechazar.

∑ ganancias −
TIR =
costos (1 +
0.10)𝑛

∑ 15000 −
TIR = 8664
(1 + 0.10)5

TIR = 3934.17

Por lo tanto la rentabilidad que el presente proyecto está proporcionando es de 3934.17 $us,
como es mayor a la tasa de descuento, se acepta el proyecto.
 CAPITULO VI
CONCLUSIONES Y RECOMENDACIONES

6.1. CONCLUSIONES

Una vez culminado todos los puntos propuestos para el desarrollo del proyecto, se llega a la
conclusión que fue factible lograr el mismo, al haberse elaborado el Sistema web para el
registro y administración de documentos de niños patrocinados caso CDI BO-132, el cual
puede ser susceptible de realizar ajustes, de acuerdo a los nuevos requerimientos que se
tenga en el proceso de puesta en marcha del sistema, con esto se puede concluir que:

 Se logró centralizar y almacenar la información principal de postulantes y

patrocinados, para llegar a tener un acceso inmediato.
 Se desarrolló un sistema con interfaz amigable para el usuario y de fácil manejo de
manera q no exista duplicidad de datos, ni perdida de la información.
 El producto obtenido cuenta con todas las características, requeridas por los
usuarios, resultando una herramienta de ayuda para los procesos que se efectúen en
el área de patrocinio.
 Con la implementación del sistema de registro y administración de documentos será
de gran apoyo para el desempeño de las funciones que lleva el área de patrocinados.
 El sistema un control de todos los movimientos y cambios de usuario, asi de esta
manera poder hacer un seguimiento de los registros y cambios que se realizan
durante el proceso de postulación y patrocinio.
 Con el módulo de administración del sistema se obtendrá la información de los
usuarios que se encuentran activos. Y con los módulos de administración de
postulante y patrocinado se verificara la información de estos y si no tienen nada
más por entregar a la responsable de patrocinio para que su documentación se
encuentre actualizada y con sus respectivos reportes.
De manera que se cumplieron satisfactoriamente los objetivos mismos que fueron
sometidos a pruebas por la institución y los usuarios finales, sistema que se desenvolvió
satisfactoriamente al momento de las pruebas de rigor después de haberse corregido las
observaciones.

6.2. RECOMENDACIONES

Una vez finalizado el proyecto de grado, a continuación se procede a detallar las

recomendaciones a tomar en cuenta para ampliar y mejorar el presente proyecto.

Realizar un análisis más profundo e incorporar la parte mensualidades, de esta manera se

podrá saber quiénes se encuentran al día en sus pagos y quienes no para su respectiva
sanción o multa según se convenga.

 A partir del sistema se recomienda incorporar paulatinamente todas las áreas del
CDI BO-132 y de esta manera tener un sistema general propio del centro de
desarrollo integral.
 Se recomienda cambiar las contraseñas semanal o mensualmente para dar mayor
seguridad al sistema.
 Se deberá implementar normas y políticas del sistema.
 Buscar la persona adecuada para el mantenimiento y desarrollo de las mejoras del
sistema
 Elaborar un sistema de inventario que permita automatizar el manejo de los recursos
y sus activos.
 Diseñar un módulo para la distribución de horarios y asistencia de los niños
patrocinados.
 Elaborar el modulo del control y administración de la biblioteca del centro.
 REFERENCIAS
LIBROS

 CAMPDERRICH Flagueras Benet, 2003: Ingeniería de Software, Eureca Media,

UOC, Barcelona.

 FOWLER Martín, 1999: UML gota a gota, Addison Wesley Longman, México
S.A., México, D. F.

 HERNÁNDEZ Roberto y FERNÁNDEZ Carlos., 1998: Metodología de la

Investigación, McGraw-Hill Interamericana, México, D.F.

 LARMAN G., 1999: Análisis y Diseño Orientado a Objetos UML y patrones, 1a.
ed. Prentice-Hall, México.

 PRESSMAN Roger, 2002: Ingeniería de Software, 5a. ed., McGraw-Hill.

 RAMOS Salavert Isidro, LOZANO Pérez Dolores, 2000: Ingeniería del Software y
Base de datos, Tendencias Actuales, 1ra. ed., Universidad de Castillas – La Mancha,
España.

 BOOCH & JACOBSON, “Proceso Unificado de Desarrollo de Software”, 1999.

 PRESSMAN, R. S. “INGENIERÍA DE SOFTWARE” Un Enfoque Práctico, 2006,

sexta edición, McGraw-Hill, Madrid.
PROYECTOS DE GRADO

 Mamani Sullcata, Marco Antonio, SISTEMA WEB DE ADMINISTRACIÓN DE

LA INFORMACIÓN Y LA COMUNICACIÓN PARA LA GESTIÓN
EDUCATIVA DEL COLEGIO INTERNACIONAL DEL SUR, Universidad Mayor
de San Andrés, Facultad de Ciencias Puras y Naturales, Carrera de informática, 18
de Septiembre [Link] paz Bolivia.

 Quispe Apaza, Santos, SISTEMA WEB DE REGISTRO, CONTROL Y

SEGUIMIENTO DE LOS PROCESOS DE AUDITORÍA INTERNA CASO:
SENAPE SERVICIO NACIONAL DE PATRIMONIO DEL ESTADO,
Universidad Mayor de San Andrés, Facultad de Ciencias Puras y Naturales, Carrera
de Informática, 29 Octubre 2012, La Paz Bolivia.

 Ayoroa Ocaña Juan Cesar SISTEMA DE INFORMACIÓN VÍA WEB CASO:

INSTITUCIÓN GAMMA, , Universidad Mayor de San Andrés, Facultad de
Ciencias Puras y Naturales, Carrera de Informática, 28 de Noviembre 2012. La Paz
Bolivia.

SITIOS DE INTERNET

 ASSI , 2007, Asociación de investigación en software inteligente (ASSI): Ingeniería

Web [en línea ], < [Link] [Link] >, [consulta: 14 de agosto 2014].

 AMBLER, 2000, Metodologías de proceso ágil, [en línea], < [Link]

[Link] >, [consulta: 4 de Junio 2014].
 IEEE, Norma IEEE estándar, [en línea], < [Link] [Link] >, [consulta: 15 de
Octubre 2014].

 SCOTT, 2005, El proceso unificado ágil, [en línea]

<[Link] >, [consulta: 10 de Octubre 2014].

 PINTO, 1627, Modelo Oohdm: el nuevo concepto dela cultura en la imagen, [en
línea], <[Link] [consulta: 20 de
Septiembre 2014].

 J. MUÑOZ, 2000, Metodologías Agiles, [en línea],

<[Link]
desarrollo-de-software>, [consulta: 4 de mayo 2014].

 ESC, 2002, Metodologías web, [en línea] <[Link]

ingeniera-web-7367015>, [consulta: 10 de junio 2014].