T1360

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
SISTEMA DE GESTIÓN ACADÉMICA Y SEGUIMIENTO

PSICOSOCIAL SIGASP
Trabajo realizado para el Centro de Capacitación

Técnica Sarantañani CCTS
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERIA DE SISTEMAS INFORMÁTICOS
Postulante: Daniel Hugo Chaoca Callizaya

Tutor: Lic. Efraín Silva Sánchez
Revisora: Lic. Celia Elena Tarquino Peralta
LA PAZ – BOLIVIA
2006
DEDICATORIA
Para tí, madre, por brindarme tanto

cariño y por las miles de maneras en
que iluminas mi vida.
AGRADECIMIENTOS
En primer lugar agradecer a Dios por la fuerza que me brinda en cada momento de
mi vida y en especial para el logro de este proyecto.
Agradezco a mi familia; a mi madre, mis hermanas y hermano quienes me alientan y

apoyan continuamente para mi realización personal y profesional.
A mi docente Tutor Lic. Efraín Silva Sánchez, que fue un guía a lo largo de la
elaboración del desarrollo de todo mi proyecto, con su orientación y consejos
oportunos.
Mi eterna gratitud a mi Revisora Lic. Celia Tarquino Peralta, quien me brindo su

tiempo, sus conocimientos y experiencia para enriquecer mi proyecto.
Mi reconocimiento a los docentes de la Carrera de Informática, por los conocimientos

que me brindaron en todos mis años de estudio. Asimismo, al personal administrativo
que trabaja en la carrera, que siempre están prestos a colaborar con los estudiantes.
Agradecer al Centro de Capacitación Técnica Sarantañani, a su Director Jorge Domic

y en especial al Prof. Jaime Zamudio, quien fue el principal impulsor en la correcta
realización de este proyecto.
También mi más sincero agradecimiento a todos mis amigos y amigas por su

desinteresada amistad y compañerismo, quienes fueron un apoyo durante toda mi
carrera universitaria.
RESUMEN
El Proyecto Sistema de Gestión Académica y Seguimiento Psicosocial SIGASP, fue

desarrollado para el Centro de Capacitación Técnica Sarantañani, dependiente del
área socioeducativa de la Fundación La Paz. Dicho Centro está orientado a
beneficiar a jóvenes y señoritas de escasos recursos económicos, con el fin de
integrarlos a la sociedad con una especialidad técnica, para que éstos tengan
mayores oportunidades de trabajo.
Este Centro de Capacitación realizaba la mayoría de sus actividades de gestión

académica de forma manual, es por esta razón que con este sistema de software se
pretende obtener información rápida y consistente, a fin de maximizar la eficiencia en
la administración de información.
La metodología adoptada para el desarrollo del software fue el Proceso Unificado de

Rational RUP, que tiene como base el Lenguaje de Modelado Unificado UML, el cual
modela las distintas etapas de evolución del nuevo sistema de software. Las
herramientas utilizadas para la implementación, son el lenguaje de programación
Visual Basic .NET 2003 y el gestor de base de datos SQL Server 2000.
Los módulos principales del sistema desarrollado son: módulo para el proceso de
inscripción de participantes, seguimiento y evaluación académica, seguimiento
psicosocial, generación de informes estadísticos y reportes personalizados sobre
algunos aspectos importantes que se presentan durante la gestión académica.
Una vez desarrollado el software se realizaron pruebas de funcionamiento, con las

que se pudo constatar que el sistema responde a los requerimientos institucionales,
posibilitando la reducción de tiempo y costos en la administración de información,
además de la obtención de datos confiables y oportunos.
ÍNDICE
CONTENIDO Pág.
CAPÍTULO PRIMERO
INTRODUCCIÓN
1. INTRODUCCIÓN..................................................................................................... 2
1.2. ANTECEDENTES ............................................................................................... 4
1.2.1. Antecedentes de Sistemas de Seguimiento Académico y Psicosocial ......... 4
1.2.2. Antecedentes del Centro de Capacitación Técnica Sarantañani, CCTS ...... 6
1.3. PRESENTACIÓN DEL PROBLEMA.................................................................... 8
1.3.1. Definición del problema .............................................................................. 11
1.4. OBJETIVO GENERAL ....................................................................................... 11
1.5. OBJETIVOS ESPECÍFICOS .............................................................................. 11
1.6. JUSTIFICACIONES ........................................................................................... 12
1.6.1. Justificaciones económicas ........................................................................ 12
1.6.2. Justificaciones sociales .............................................................................. 12
1.6.3. Justificaciones técnicas .............................................................................. 12
1.7. ALCANCES........................................................................................................ 14
1.8. METODOLOGÍA................................................................................................. 17
1.9. APORTES .......................................................................................................... 17
CAPÍTULO SEGUNDO
MARCO TEÓRICO
2.1. INGENIERIA DEL SOFTWARE ......................................................................... 20

2.2. PROYECTOS DE SISTEMAS DE INFORMACIÓN ........................................... 20
2.3. PARADIGMA ORIENTADO A OBJETOS ......................................................... 22
2.4. EL LENGUAJE DE MODELADO UNIFICADO UML ......................................... 23
2.4.1. Vistas UML .............................................................................................. 23
a) Vista de Casos de Uso ........................................................................ 23
b) Vista Lógica ......................................................................................... 24
c) Vista de Componentes......................................................................... 24
d) Vista de Implantación .......................................................................... 24
e) Vista de Concurrencia ......................................................................... 25
2.5. EL PROCESO UNIFICADO DE RATIONAL RUP ............................................. 25
2.5.1. Dirigido por casos de uso ......................................................................... 25
2.5.2. Centrado en la arquitectura ...................................................................... 25
2.5.3. Iterativo e incremental .............................................................................. 26
2.6 FASE DE INICIO ................................................................................................. 27
2.6.1. Plan de desarrollo del software................................................................. 27
2.6.2. Modelado del negocio............................................................................... 27
a) Modelo de casos de uso del negocio ................................................... 28
b) Descripción de los actores del negocio ................................................ 28
c) Descripción del modelo de casos de uso del negocio ......................... 29
i
d) Modelo de dominio ............................................................................... 29
2.7. FASE DE ELABORACIÓN ................................................................................ 29
2.7.1. Captura de requisitos................................................................................ 29
a) Funciones del sistema ........................................................................... 30
b) Diagrama de casos de uso de alto nivel ................................................ 30
c) Casos de uso expandidos...................................................................... 30
d) Prototipo de interfaz de usuario............................................................. 31
e) Glosario ................................................................................................. 31
2.7.2. Análisis del sistema .................................................................................. 32
a) Diagramas de secuencia ...................................................................... 32
b) Diagrama de estados ........................................................................... 33
2.8. FASE DE CONSTRUCCIÓN .............................................................................. 33
2.8.1. Diseño del sistema .................................................................................. 34
a) Diagrama de despliegue...................................................................... 34
b) Diagrama de colaboración................................................................... 34
c) Diagrama de clases ............................................................................. 35
2.8.2. Implementación del sistema .................................................................... 36
a) Diagrama de componentes.................................................................. 37
2.9. FASE DE TRANSICIÓN ..................................................................................... 37
2.9.1. Pruebas del sistema ................................................................................. 38
2.10. MODELO DE BASES DE DATOS RELACIONALES ...................................... 39
2.11. NOTACIÓN UML PARA MODELAR ENTIDAD/ RELACIÓN .......................... 40
2.12. ARQUITECTURA CLIENTE / SERVIDOR ....................................................... 42
2.12.1. SQL Server 2000 .................................................................................. 42
2.13. MÉTRICAS DE CALIDAD DEL SOFTWARE .................................................. 43
2.13.1. Funcionalidad ....................................................................................... 44
2.13.2. Confiabilidad ......................................................................................... 44
2.13.3. Mantenibilidad....................................................................................... 45
2.13.4. Portabilidad........................................................................................... 46
2.14. SEGURIDAD DE LOS SISTEMAS DE INFORMACIÓN .................................. 46
2.15. GESTIÓN ACADÉMICA................................................................................... 48
2.16. SEGUIMIENTO PSICOSOCIAL ....................................................................... 48
CAPÍTULO TERCERO
CONSTRUCCIÓN DEL SOFTWARE
3.1. CONSTRUCCIÓN DEL SOFTWARE................................................................. 50

3.2. FASE DE INICIO ................................................................................................ 50
3.2.1. Modelado del CCTS ................................................................................ 51
a) Modelo de casos de uso para el CCTS ............................................... 51
b) Descripción de los actores del CCTS .................................................. 52
c) Descripción de los casos de uso del CCTS ......................................... 53
d) Modelo de dominio del CCTS.............................................................. 54
3.3. FASE DE ELABORACIÓN ................................................................................ 55
3.3.1. Captura de requisitos del SIGASP............................................................ 55
ii
a) Funciones del SIGASP............................................................................. 55
b) Casos de uso del SIGASP................................................................... 57
c) Descripción detallada de los casos de uso expandidos del SIGASP... 58
d) Definir prototipo de interfaz.................................................................. 61
e) Términos del glosario .......................................................................... 63
3.3.2. Análisis del SIGASP ................................................................................. 64
a) Diagramas de secuencia ..................................................................... 64
b) Diseñar diagramas de estados ............................................................ 67
3.4. FASE DE CONSTRUCCIÓN .............................................................................. 68
3.4.1. Diseño del SIGASP .................................................................................. 68
a) Diseño de la arquitectura del SIGASP.................................................. 68
b) Diseño del diagrama de colaboración .................................................. 69
c) Diseño del diagrama de clases............................................................. 70
d) Diagrama Entidad - Relación................................................................ 71
e) Descripción del diagrama Entidad – Relación ...................................... 72
3.4.2. Implementación del sistema ..................................................................... 73
a) Definición de los diagramas de componentes ...................................... 73
b) Implementación del SIGASP ................................................................ 74
3.5. FASE DE TRANSICIÓN ..................................................................................... 76
3.5.1. Resultados obtenidos ............................................................................... 79
3.6. CALIDAD DEL SIGASP..................................................................................... 80
3.6.1. Funcionalidad ........................................................................................... 80
3.6.2. Mantenibilidad........................................................................................... 84
3.6.3. Portabilidad............................................................................................... 85
3.6.4. Confiabilidad ............................................................................................. 85
CAPÍTULO CUARTO
CONCLUSIONES Y RECOMENDACIONES
4.1 CONCLUSIONES................................................................................................ 88
4.2. RECOMENDACIONES ....................................................................................... 90
REFERENCIA BIBLIOGRAFICA ............................................................................... 91

REFERENCIAS WEB................................................................................................. 92
ANEXOS
ANEXO I: Árbol de Problemas, Árbol de Objetivos y Marco Lógico.
ANEXO II: Organigrama del Área Socioeducativa de la Fundación La Paz.
ANEXO III: Descripción de Casos de Uso Expandidos, Diagramas de Secuencia,
Diagramas de Estado, Diagramas de Colaboración, Diagramas de Componentes.
ANEXO IV: Algunos de los Formularios que genera el Sistema de Gestión
Académica y Seguimiento Psicosocial, SIGASP.
ANEXO V: Documentos.
iii
ÍNDICE DE FIGURAS
Figura Nº Pág.
Figura 1.1: Organigrama del CCTS, línea intensiva ................................................... 6

Figura 1.2: Distribución de los equipos en un ambiente C/S .................................... 16
Figura 2.1: Vistas UML ............................................................................................. 23
Figura 2.2: Organización del Proceso Unificado de Rational................................... 26
Figura 2.3: Representación del actor y el caso de uso ............................................. 28
Figura 2.4: Ejemplo de interfaz de usuario, pagar factura ........................................ 31
Figura 2.5: Representación de un diagrama de secuencia...................................... 32
Figura 2.6: Representación de un diagrama de estado ............................................ 33
Figura 2.7: Representación de un diagrama de despliegue ..................................... 34
Figura 2.8: Representación de un diagrama de colaboración .................................. 35
Figura 2.9: Tipos de asociaciones ............................................................................ 35
Figura 2.10: Representación de agregación y composición ..................................... 36
Figura 2.11: Ejemplo de generalización.................................................................... 36
Figura 2.12: Representación de un diagrama de componentes ............................... 37
Figura 2.13: Notación UML para modelar E-R.......................................................... 41
Figura 3.1: Casos de uso del CCTS ......................................................................... 51
Figura 3.2: Modelo de dominio. ................................................................................ 54
Figura 3.3: Casos de uso del SIGASP...................................................................... 57
Figura 3.4: Caso de uso inscripción de participantes ............................................... 58
Figura 3.5: Caso de uso evaluación académica ....................................................... 59
Figura 3.6: Caso de uso seguimiento psicosocial..................................................... 60
Figura 3.7: Prototipo de interfaz, caso de uso inscripción de participantes .............. 61
Figura 3.8: Prototipo de interfaz, caso de uso evaluación académica. ..................... 62
Figura 3.9: Diagrama de secuencia, seguimiento psicosocial .................................. 64
Figura 3.10: Diagrama de secuencia, inscripción de participantes ........................... 65
Figura 3.11: Diagrama de secuencia, evaluación académica................................... 66
Figura 3.12: Diagrama de estado, inscripción de participante .................................. 67
Figura 3.13: Diagrama de estado, evaluación académica ........................................ 67
Figura 3.14: Diagrama de estado, seguimiento psicosocial...................................... 67
Figura 3.15: Diagrama de despliegue....................................................................... 68
Figura 3.16: Diagrama de colaboración, inscripción de participantes....................... 69
Figura 3.17: Diagrama de colaboración, seguimiento psicosocial ........................... 69
Figura 3.18: Diagrama de clases del SIGASP.......................................................... 70
Figura 3.19: Diagrama entidad – relación................................................................. 71
Figura 3.20: Diagrama de componentes, inscripción de participantes ..................... 73
Figura 3.21: Diagrama de componentes, evaluación académica. ............................ 73
Figura 3.22: Diagrama de componentes, seguimiento psicosocial........................... 74
Figura 3.23: Interfaz gráfica para el ingreso al sistema ............................................ 74
Figura 3.24: Interfaz gráfica para del menú principal del sistema............................. 75
Figura 3.25: Interfaz grafica para la inscripción de participantes.............................. 75
Figura 3.26: Prueba de ingreso al sistema ............................................................... 76
Figura 3.27: Ingreso al menú del sistema y módulo de inscripción. ......................... 77
Figura 3.28: Caso de prueba, evaluación académica............................................... 78
iv
ÍNDICE DE TABLAS
Tabla Nº Pág.
Tabla 1.1: Número de participantes por año ............................................................... 7

Tabla 1.2: Hardware para el servidor del sistema .................................................... 13
Tabla 1.3: Hardware para los equipos de los usuarios ............................................ 13
Tabla 1.4: Hardware para la red local ....................................................................... 14
Tabla 1.5: Software para el equipo servidor ............................................................. 14
Tabla 2.1: Ejemplo, descripción de caso de uso expandido ........................................................... 30
Tabla 3.1. Cronograma del desarrollo del software................................................... 50
Tabla 3.2: Requisitos funcionales del sistema .......................................................... 55
Tabla 3.3: Descripción del caso de uso, inscripción de participantes ....................... 58
Tabla 3.4: Descripción del caso de uso, evaluación académica ............................... 59
Tabla 3.5: Descripción del caso de uso, seguimiento psicosocial............................. 60
Tabla 3.6: Resultados obtenidos............................................................................... 79
Tabla 3.7: Cálculos del punto función ....................................................................... 82
Tabla 3.8: Ponderación para el ajuste....................................................................... 83
Tabla 3.9: Ajuste de complejidad .............................................................................. 83
Tabla 3.10: Resultados sobre una muestra de diez fallas......................................... 84
v
Sistema de Gestión Académica y Seguimiento Psicosocial Introducción
1
1. INTRODUCCIÓN
Actualmente se vive en una época en la cual los procesos de comunicación e

información es requerida de manera ágil y oportuna con el fin de ahorrar tiempo,
recursos y costos, esta necesidad ha llevado a que diversas empresas e instituciones
tomen la decisión de desarrollar e implantar sistemas de software para la eficiente
administración de la información. Es el caso de los centros educativos como:
escuelas, colegios, universidades públicas y privadas, institutos técnicos entre otros.
Dentro del ámbito educativo, las Organizaciones No Gubernamentales (ONG’s) y sin

fines de lucro juegan un rol importante, en el potenciamiento del capital humano a
través de la capacitación. Estas organizaciones junto al avance de la tecnología
informática han ido generando la idea de contar con sistemas de software, que les
permitan administrar la información de la población beneficiaria, de manera más
eficaz y eficiente. Es el caso del Centro de Capacitación Técnica Sarantañani, CCTS,
que tiene como objetivo la especialización técnica de jóvenes y señoritas de escasos
recursos económicos, a fin de que tengan mayores oportunidades laborales y de
integración a la sociedad.
La necesidad de desarrollar e implementar una tecnología informática para el CCTS,

surge como una tarea esencial para automatizar y ahorrar tiempo en los procesos
de administración de información, lo que a su vez favorecerá al desempeño de
funciones del personal de la institución, quienes podrán ofrecer un servicio más ágil
y oportuno a los jóvenes y señoritas participantes.
Con el propósito de dar respuesta a esta necesidad, se ha construido un Sistema de

Gestión Académica y Seguimiento Psicosocial, SIGASP. Se utilizó el Proceso
Unificado de Rational, como metodología para diseñar el ciclo de vida de desarrollo
del sistema de software. Las herramientas utilizadas para la implementación fueron
el lenguaje de programación Visual Basic .NET 2003 y el MS SQL Server 2000,
como sistema administrador de base de datos, el mismo es una herramienta muy
poderosa para la implementación de sistemas cliente / servidor.
2
En este sentido, el presente documento refleja el desarrollo del sistema de software

para el CCTS, estructurado en cuatro capítulos:
En el capítulo inicial, a fin de contextualizar la elaboración del proyecto, se hace

referencia a los antecedentes de algunos sistemas de seguimiento académico
desarrollados en el ámbito internacional, así como a aquellos diseñados dentro de la
Carrera de Informática de la Universidad Mayor de San Andrés.
También se hace una reseña de los antecedentes del Centro de Capacitación

Técnica Sarantañani; para luego pasar al análisis y planteamiento del problema, es
decir, las limitaciones y deficiencias en la administración de la información en la
entidad, antes de la implementación del proyecto. Seguidamente se plantean los
objetivos que se constituyen en alternativas de solución y que dan origen al sistema
de software. Además se presentan las justificaciones sociales, económicas, técnicas,
alcances y aportes del presente proyecto.
En el segundo capitulo se hace una breve definición de todas la teorías que

fundamentan el desarrollo del proyecto de software. Entre algunas de las teorías
mencionadas están: proyectos de sistemas de información, el Lenguaje de Modelado
Unificado, el Proceso Unificado de Rational, pruebas de software, métricas de
calidad, modelos de bases de datos relacionales y seguridad de sistemas de
información.
El capítulo tercero abarca básicamente la aplicación del Proceso Unificado de

Rational RUP, cuyas fases comprende: inicio, elaboración, construcción y transición
del sistema construido. Finalmente se hace referencia a las métricas de calidad que
permiten demostrar: la funcionalidad, confiabilidad, mantenibilidad y portabilidad del
software.
El último capítulo del proyecto corresponde a las conclusiones a las que se llegaron a
partir de la implementación del proyecto, además de recomendaciones que se
consideran importantes para la evolución del sistema dentro de la institución.
3
1.2. ANTECEDENTES
1.2.1. Antecedentes de Sistemas de Seguimiento Académico y Psicosocial
Los sistemas de seguimiento académico tienen la finalidad de administrar toda la

información que se pueda generar durante una gestión académica, como ser:
inscripción de alumnos nuevos y antiguos, registro de calificaciones, emisión de
boletas de calificaciones o certificados de notas, record académico y otros. Estos
sistemas pueden ser implementados y utilizados sobre una red local o sobre la red
Internet. A continuación mencionamos algunos sistemas de seguimiento académico
desarrollados fuera de nuestras fronteras.
SIGA, Sistema Integrado de Gestión Académica. Es un software comercial,

desarrollado por la empresa de software DARA de España. Cuyo sistema está
destinado a conservatorios, academias, colegios, institutos o universidades. También
a centros de formación de empresas, masteres, postgrado, colegios oficiales,
escuelas oficiales de idiomas y turismo, etc. Sus principales módulos son:
matriculación de alumnos, preinscripciones, reservas, listados por conceptos,
ingresos y gastos, módulo económico, inventario, horarios. [REF-W07]
Control Escolar GES. Sistema comercial desarrollado por el Grupo GES, de

México. Control Escolar GES es una herramienta informática, de apoyo para las
Instituciones Educativas que desean mejorar sus niveles de eficiencia en las áreas
de control escolar, académico, administrativo y de cobranza. Su propósito es simple,
aumento de eficiencia. Sus módulos comunes son: control de alumnos, control de
documentos entregados por el alumno, control de planes de estudio, elaboración de
horarios, registro de calificaciones, control de padres, manejo de becas, estado de
cuentas, múltiples reportes administrativos y estadísticos. [REF-W08]
Dentro de la Carrera de Informática de la Universidad Mayor de San Andrés, se han

ido presentado variados Proyectos de Grado, orientados al seguimiento académico
para distintas entidades educativas como ser: escuelas, colegios, institutos normales,
4
institutos técnicos, universidades públicas y privadas. También se han encontrado

proyectos orientados al seguimiento psicosocial. De estos proyectos se puede
mencionar los siguientes:
Sistema de Seguimiento Psicosocial, desarrollado por Rojas Valencia Dulfredo, el

año 1997, para el Servicio Universitario de Salud Mental, dependiente de la Facultad
de Medicina de la UMSA. El objetivo principal fue desarrollar un sistema
computarizado que determine y diagnostique las variables del comportamiento en
busca de mejorar el rendimiento humano. Los módulos principales para la
construcción del sistema fueron: registro de datos personales, aspectos
pedagógicos, socios económicos, estado de salud físico mental, seguimiento de
consultas y resultados de tests que abarquen diferentes aspectos.
Sistema de Seguimiento Académico – Psicológico, trabajo elaborado por Laura

Ticona Gladis B. el año 2000 en el Instituto de Educación Bancaria. El objetivo fue
desarrollar el sistema SISAP, que realice un seguimiento académico y evaluación
psicológica para identificar y apoyar psicológicamente al estudiante problema. Los
principales módulos realizados fueron: registro e inscripción de alumnos,
seguimiento académico, seguimiento psicológico y el módulo docentes.
Seguimiento académico para el Colegio Santa Maria CENAFI, Efectuado por

Peñalosa Nina Antonio, el año 2002. Dicho sistema tiene como objetivo facilitar la
comunicación entre los diferentes niveles involucrados, y así mejorar el uso de
recursos humanos y económicos. Dentro de sus módulos principales están:
inscripción de alumnos, cobro de mensualidades, informes estadísticos, elaboración
de libretas, boletines y control de acceso.
Sistema de seguimiento académico ISEC. Proyecto desarrollado por Nicols Iriarte

Rosalin el año 2002, cuyo objetivo fue implementar el sistema para el mejor uso de
los servicios de seguimiento académico. Sus objetivos específicos eran: incrementar
5
la velocidad del proceso de datos de alumnos, reducir costo de procesamiento de

datos e incrementar la eficiencia en el trabajo del personal.
1.2.2. Antecedentes del Centro de Capacitación Técnica Sarantañani, CCTS
El Centro de Capacitación Técnica Sarantañani dependiente del Área Socioeducativa

de la Fundación La Paz, se encuentra ubicada en la zona de Villa Copacabana de la
ciudad de La Paz. Inició su funcionamiento el 16 de junio de 1992, como un proyecto
alternativo para la capacitación de mano de obra calificada, dirigida a adolescentes y
jóvenes comprendidos entre los 14 y 22 años de edad, que viven y/o trabajan en la
calle (lustra calzados, lava y cuida coches, aguateros, comercio y ayudantes de
transporte) y que debido a limitaciones económicas o problemas familiares, no tienen
acceso a otros espacios de formación.
Las actividades que se desarrollan en este Centro de Capacitación, en el área

académica, parten de la formación técnica en siete especialidades, como se gráfica a
continuación:
Figura 1.1: Organigrama del CCTS, línea intensiva
CENTRO DE CAPACITACION
TECNICA SARANTAÑANI
ESPECIALIDADES
MAQUINAS
MECANICA CONFECCIONES MARROQUINE - COMPUTACIÓN METAL CARPINTERIA HERRAMIENTAS
AUTOMOTRIZ RIA MECANICA
DPS RIBUTRA
Fuente: Memoria institucional CCTS, 2004
La siguiente tabla muestra el número de jóvenes y señoritas por año, que han sido
participes de los proyectos ofrecidos por este Centro de Capacitación. Se puede
6
apreciar un total de 1436 jóvenes y señoritas, con un progresivo incremento anual del
número de participantes.
Tabla 1.1: Número de participantes por año.
1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
48 50 49 66 67 79 70 117 120 124 122 116 134 140 134
Fuente: Memoria institucional CCTS, 2004
Las fuentes financiadoras de este proyecto son: Agro Acción Alemana, Kassel,
Global, Freundeskreis, Prefectura de La Paz (Convenio Interinstitucional) y el
Programa Mundial de Alimentos PMA (Convenio Interinstitucional).
Además se cuenta con convenios firmados con algunas entidades para el desarrollo
de este proyecto los cuales son: Prefectura del Departamento de La Paz (becas
alimenticias), Honorable Alcaldía de la ciudad de La Paz (desayuno escolar),
Ministerio de Educación (6 ítems para instructores), Ministerio de Salud (Convenio
con Postas y Hospitales), Universidad Católica Boliviana (horas prácticas),
Universidad Mayor de San Andrés. (horas prácticas)
Los participantes de los diferentes cursos de capacitación, que han sufrido algún tipo
de maltrato físico o psicológico cuentan con el proyecto RIBUTRA, el cual inicia sus
actividades el 27 de marzo del 2002, con el objetivo de contribuir a la prevención y
atención del maltrato infantil y de abuso sexual, para esto se han desarrollado
estrategias educativas que promuevan el buen trato y que generen mecanismos de
control social y estructurando espacios de atención psicoterapéutica especializada.
Para lograr sus objetivos ofrecen talleres de auto cuidado y prevención del abuso
sexual a niños y adolescentes, orientados a padres de familia. Otros talleres están
destinados a profesores y profesoras de escuelas en los cuales se expone
capacitación en la filosofía y metodología del buen trato con equipos técnicos de
7
otras instituciones y atención psicoterapéutica en el consultorio de Villa Copacabana

y Kupini.
1.3. PRESENTACIÓN DEL PROBLEMA
A partir de una reflexión con el personal de la institución en cuanto a la

administración de la información académica y seguimiento psicosocial, se
identificaron los siguientes problemas:
El registro de los datos generales de los participantes es llenada en más

de un formulario, lo que ocasionaba redundancia en la información
almacenada. Cada adolescente, joven o señorita que ingresa a este Centro,
debe poseer un formulario de datos personales, además de los datos de los
padres o tutores, los cuales son llenados por la secretaria. Dicho formulario
posee un número importante de campos, los cuales eran registrados de forma
manual. Estos mismos datos eran registrados por los psicólogos de la
institución y del programa RIBUTRA en otros formularios, lo que ocasionaba
gran volumen de información almacenada e innecesaria y también generaba
un gasto en formularios, esta situación a su vez hacia deducir la no existencia
de coordinación entre el personal de la institución.
El seguimiento de la evaluación académica es registrada y evaluada de

forma manual. Todos los instructores a la finalización de cada bimestre o
trimestre deben registrar en una ficha de evaluación, valorando distintos
aspectos del participante. También se califica el Desarrollo Personal y Social,
dicha evaluación está a cargo de la psicóloga de la institución. Con estas
calificaciones se deben generar: la boleta de evaluación, resumen bimestral o
trimestral de evaluación y horas/aula; además del resumen anual de
evaluación y horas/ aula. Estos reportes eran realizados por el personal de
forma manual, lo cual requería de muchos cálculos matemáticos, en los que
podían existir inconsistencias en los datos calculados, además que su
elaboración era morosa.
8
Los pagos realizados por los participantes son controlados de forma

manual por el personal. Todos los inscritos deben cancelar ciertos montos
por concepto de: “control de salud”, “certificados”, “carnet de salud” y “carnet
de estudiante”, los mismos deben ser cancelados durante su inscripción. Otros
cobros que se realizan, son las mensualidades que cancelan los alumnos
inscritos en la especialidad de computación. La institución no contaba con una
tecnología informática para controlar que alumnos han cancelado todas sus
deudas y que alumnos aún tienen alguna cuenta pendiente.
Dificultad en la generación de reportes e informes estadísticos por parte

del personal de la institución. Durante una gestión académica se presentan
diferentes aspectos importantes que son motivo de generación de informes
estadísticos en relación al número de hombres y mujeres, número de inscritos
por especialidad, alumnos retirados, grado de escolaridad, edad y otros, los
cuales son necesarios para realizar estudios comparativos con anteriores
gestiones. El proceso se realizaba de forma semi-manual, ya que la
recolección de los datos debía ser examinada en los fólderes de cada uno de
los estudiantes, posteriormente estos datos eran evaluados y procesados en
un editor de texto u hoja electrónica para los respectivos informes. Este
método resultaba ser lento e inconsistente en los resultados obtenidos.
La gran cantidad de información almacenada y desactualizada generaban

un inadecuado monitoreo de los participantes del programa RIBUTRA.
Para la realización de este seguimiento es necesaria la organización de los
datos de la familia e historial sobre algún trauma de maltrato físico o
psicológico, que es apuntada en formularios de forma manual por el personal
a cargo. Una vez obtenida esta información se realiza un seguimiento por
medio de consultas regulares a los participantes y a otros involucrados
dependiendo de la situación (familiares, profesores y otros). La gran cantidad
9
de formularios almacenados dificultaba la búsqueda y seguimiento adecuado

de casos por participante.
Los problemas anteriormente descritos generaban otros tipos de dificultades dentro

de la administración de la documentación.
Fenómenos medio ambientales y el constante manipuleo de la

documentación almacenada, ocasionaban el deterioro de la misma,
generando perdida de datos. Toda la documentación de los participantes
era archivada en fólderes y esta a su vez almacenada en gavetas y/o
estantes, dicha forma de almacenamiento contrae sus dificultades, ya que la
humedad existente o los cambios de temperatura aceleran el deterioro de los
formularios. Otra razón para la perdida de información es el constante
manipuleo a la que se ve sometida dicha documentación, la cual era solicitada
para la realización de reportes u otros estudios, también podía ocurrir perdida
de algún formulario, lo cual ocasionaba la desactualización de la
documentación.
Lento acceso a la información almacenada por parte del personal y los

participantes. Desde la creación de esta institución, se ha ido acumulando
bastante documentación en los estantes y gavetas, lo que ocasionaba un lento
acceso a los documentos de años anteriores.
La corrección y/o actualización de datos en un formulario, ocasionaba el

llenado de un nuevo formulario o realización de enmiendas en éste. El
registro manual de formularios o actualización de datos con bolígrafos
ocasionaba errores en el llenado de los mismos, lo cual obligaba a su vez al
llenado reiterado de formularios, produciendo perdidas innecesarias de
formularios.
10
1.3.1. Definición del problema
A partir del análisis de las dificultades y limitaciones en cuanto al manejo de

información en el CCTS, se realiza la definición del problema:
¿El seguimiento y evaluación de información generada en el Centro de Capacitación

Técnica Sarantañani, es administrada de forma manual lo que ocasiona lentitud e
inconsistencia en el procesamiento y generación de datos?
1.4. OBJETIVO GENERAL
Desarrollar un Sistema de Gestión Académica y Seguimiento Psicosocial, que

permita obtener información rápida y consistente, a fin de maximizar la eficiencia en
la administración de información.
1.5. OBJETIVOS ESPECÍFICOS
Desarrollar un subsistema para el proceso de inscripción de participantes.
Construir un módulo para el seguimiento y evaluación académica.
Desarrollar un módulo para el registro de pagos.
Desarrollar un subsistema para el seguimiento psicosocial de los

adolescentes, jóvenes y señoritas participantes.
Desarrollar un módulo para generar informes estadísticos y reportes

personalizados, sobre algunos aspectos importantes que se presentan
durante la gestión académica
11
1.6. JUSTIFICACIONES
1.6.1. Justificaciones económicas
Con la implementación del Sistema de Gestión Académica y Seguimiento

Psicosocial, en el Centro de Capacitación Técnica Sarantañani, se minimizará el
tiempo de acceso y procesamiento de datos, además de la creación automática de
reportes e informes estadísticos. Con el sistema se pretende reducir los gastos que
representaban los costos de material de escritorio.
El espacio que representaba el almacenamiento de la documentación en gavetas o

estantes se reduce al registro de toda la información recopilada en una base de
datos controlada por un administrador de sistema.
1.6.2. Justificaciones sociales
El Centro de Capacitación Técnica Sarantañani, esta íntegramente relacionada al

servicio social y de asistencia, para aquella población que vive en situación de
pobreza, es por esta razón que la implementación de un sistema de información,
será de gran utilidad para que el mismo cuente con información actualizada y
oportuna a fin de brindar sus servicios de mejor manera y a su vez favorecer al
cumplimiento de sus objetivos y metas trazadas.
Con el sistema serán beneficiados directamente el personal que trabaja en la

institución, ya que se agilizará sus labores diarias con respecto a los procesos de
administración, gestión y acceso a información actualizada. También serán
favorecidos los jóvenes y señoritas participantes, ya que sus reportes u otra
información requerida por los mismos será entregada de forma inmediata.
1.6.3. Justificaciones técnicas
Para la implementación del sistema de Gestión Académica y Seguimiento

Psicosocial, SIGASP, la institución cuenta con los requerimientos técnicos de
hardware y software, los cuales se detallan a continuación:
12
El Hardware del equipo de computación que será utilizado como servidor de base de
datos y de administración del sistema, posee las siguientes características:
Tabla 1.2: Hardware para el servidor del sistema

Nº Hardware Cantidad
1 Microprocesador Pentium IV (2 Mhz o superior) o 1

equivalentes de otras marcas, con las siguientes
características :
• Memoria RAM 512 Mb.
• Disco Duro de 60 Gb.
Tarjeta de Red.
Los equipos de computación para los usuarios poseen las siguientes características:
Tabla 1.3: Hardware para los equipos de los usuarios
1 Microprocesador Pentium IV (1Mhz o superior) 7

o equivalentes de otras marcas, con las
siguientes características :
• Memoria RAM 256 Mb.

• Disco Duro de 40 Gb
• Monitor policromático SVGA 17” .
Tarjeta de Red.
13
Tabla 1.4: Hardware para la red local
1 Impresora HP Láser jet 2200DN 19ppm, 1

resolución de 1200DPI, 8 Mb de RAM, 2
bandejas de entrada y con tarjeta de red.
2 SWITCH 16 puertos 1
3 Cable UTP, Cat. 5 100 mts.
4 20
Conectores RJ45.
El Software, del equipo de computación que será utilizado como servidor del sistema,
cuenta con las siguientes características:
Tabla 1.5: Software para el equipo servidor
Nº Software Cantidad
1 Windows server 2000 1

2 Windows XP Profesional 1
3 Office XP 1
4 SQL Server 2000 1
5 Visual Basic .NET 2003 1
1.7. ALCANCES
Desarrollar un subsistema para el proceso de inscripción de participantes. En
este subsistema se registran los datos generales de los participantes, lista
de documentos entregados, nombre de la especialidad escogida y de
forma opcional se podrá cargar la fotografía del participante, también se
registra los datos de los padres o tutores y familiares, además de generar
14
el documento de compromiso de estudio y el formulario de inscripción.

También se registran las causas del abandono de los alumnos retirados
durante la gestión académica.
Construir un módulo para el seguimiento y evaluación académica. Cada

instructor registra la evaluación bimestral de su especialidad, la psicóloga
evaluará el Desarrollo Personal y Social, DPS y el instructor de
computación calificará la materia de computación. La evaluación en la
especialidad de computación se realizara de acuerdo a los paquetes que
llevan por trimestre. También se podrá ingresar las calificaciones
correspondientes a los alumnos libres (son alumnos que pasan la
materia de computación por el lapso de un trimestre). Como reportes se
generan de forma automática: la boleta de evaluación, resumen bimestral
o trimestral de calificaciones y horas/ aula y el resumen anual de
calificaciones y horas/aula.
Desarrollar un módulo para el registro de pagos. Se registran los pagos

cancelados por los participantes al momento de su ingreso al Centro y
los pagos realizados mensualmente por los alumnos inscritos en la
especialidad de computación, además de registrar cualquier otro pago
hecho durante el tiempo de capacitación. Cada uno de los pagos
efectuados tiene la emisión de su recibo correspondiente.
Desarrollar un subsistema para el seguimiento psicosocial de los participantes.

Una parte del subsistema compete al llenado de la ficha psicosocial de
todos los participantes inscritos tanto de comunidad y de institución. La
otra parte corresponde al área de RIBUTRA, que registra los datos
particulares y el seguimiento por medio de consultas regulares que se
realizan a los participantes que hayan sufrido algún tipo de maltrato.
15
Desarrollar un módulo para generar reportes e informes estadísticos

pertenecientes a la gestión académica. Entre los reportes están: lista
general de alumnos inscritos, lista de alumnos por especialidad, lista
de alumnos retirados por especialidad y otros reportes personalizados
generados por el usuario. Entre los informes estadísticos se tiene los
reportes por edad, género, grado de escolaridad, número de inscritos
por especialidad, tipo de participante y programa de procedencia.
Por la distribución de las áreas que comprende la institución y por el número

de usuarios que manipularan el sistema, se ha considerado necesario la
implementación de una arquitectura cliente servidor (C/S), con el cual el
sistema y la base de datos esta controlado por un usuario el mismo administra
el acceso al sistema de los demás clientes.
Figura 1.2: Distribución de los equipos en un ambiente C/S
BD
Secretaria
Instructor
Servidor
Psicólogo
Instructor
Instructor
Psicóloga
Coordinador
Fuente: Elaboración propia
16
Implementar un módulo de registro de usuarios del sistema. Este módulo es

de uso exclusivo del usuario administrador del sistema, el cual registra los
datos personales del usuario para luego asignarles un nivel de acceso,
un nombre de usuario y contraseña, con la cual pueden ingresar y hacer
uso del sistema.
Implementar un módulo para crear copias de seguridad de la Base de Datos.

La importancia que tienen los datos almacenados requiere que se haga una
copia de seguridad de forma regular, para que no se corra el riesgo de
perder dichos datos. Este mismo módulo tiene la facultad de restaurar toda
copia de seguridad almacenada.
1.8. METODOLOGÍA
La metodología utilizada es el Proceso Unificado de Rational, RUP (Rational

Unified Process), es un proceso de desarrollo de software que junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada para
el análisis, implementación y documentación de sistemas orientados a objetos. (Ver
Cáp. 2, sección 2.5)
1.9. APORTES
Con la implementación del Sistema en el Centro de Capacitación Técnica

Sarantañani, se obtuvieron los siguientes aportes:
Un control más preciso de los estudiantes inscritos y retirados.
Un seguimiento más eficiente en la evaluación académica y control de

horas/aula
17
Verificación rápida sobre pagos realizados por los alumnos inscritos.
Llenado interactivo de los formularios por parte del personal de la institución.
Automatización en la construcción de reportes, lo que representa ahorro de

tiempo y consistencia en la generación de los mismos.
Seguridad en los datos almacenados, lo cual brinda a los usuarios mayor

confiabilidad en la información.
Disponibilidad inmediata de la información.
Reducción del papeleo que representaba el almacenamiento de los

formularios llenados manualmente.
Inclusión de gráficas en los informes estadísticos, que reflejen de manera

cuantitativa datos importantes en una gestión académica.
18
Sistema de Gestión Académica y Seguimiento Psicosocial Marco Teórico
19
2.1. INGENIERIA DEL SOFTWARE
La ingeniería de software es un área de la informática o ciencias de la computación,

que ofrece métodos y técnicas para desarrollar y mantener sistemas de software de
calidad. Según Roger Pressman, “la ingeniería del software es entendida como el
análisis, diseño, construcción, verificación y gestión de entidades”. [REF-B03]
La Ingeniería del software tiene por objetivos:
Mejorar la calidad de los productos de software.

Aumentar la productividad y el trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases, para construir software de alta
calidad en una forma eficiente.
Definir una disciplina que garantice la producción y el mantenimiento de los
productos de software desarrollados en el plazo fijado y dentro del costo
estimado.
La ingeniería del software es una tecnología que consta de tres capas: proceso,
métodos y herramientas. El proceso del software es un marco de trabajo para las
actividades que se requieren en la construcción de software de calidad. El proceso
es importante ya que proporciona estabilidad, control y organización a una actividad.
Los productos que se obtienen del proceso del software son: programas,
documentos y datos que se producen como consecuencia de las actividades de
ingeniería del software, se establecen hitos, se asegura la calidad y el cambio se
gestiona adecuadamente.
2.2. PROYECTOS DE SISTEMAS DE INFORMACIÓN
Los proyectos de Sistemas de Información SI, basados en computadoras sirven para

diversas finalidades que van desde el procesamiento de las transacciones de una
empresa, hasta proveer de la información necesaria para decidir sobre asuntos que
se presentan diariamente. Los SI tienen las siguientes características:
20
Capacidad, las actividades de la organización están afectadas por la capacidad de

ésta, para procesar información con rapidez y eficiencia. Los SI mejoran esta
capacidad en tres formas.
Aumentan la velocidad de procesamiento, eliminan la necesidad de cálculos

tediosos y comparaciones repetitivas.
Aumento en el volumen, incrementan de gran manera el volumen de
información procesada.
Recuperación más rápida de la información, toda la información almacenada
puede ser recuperada cuando esta sea requerida de forma rápida y confiable.
Costo, los SI mejoran la administración de los costos ya que permiten la:
Vigilancia de los costos, verifica que la entidad cumpla con sus objetivos de
acuerdo con sus costos presupuestados.
Reducción de costos, los sistemas ayudan a disminuir los costos, ya que toman
ventaja de las capacidades de cálculo automático y de recuperación de datos que
están incluidos en procedimientos de programas en computadora.
Control
Mayor seguridad de información, el acceso a la información puede estar

controlado por un complejo sistemas de contraseñas, limitado a ciertas áreas o
personal, si está bien protegido, es difícil de acceder.
Menor margen de error, cada proceso se lleva a cabo de la misma manera, con
exactitud y consistencia.
Comunicación, amplían la comunicación y facilitan la integración entre distintos

usuarios.
Interconexión, las organizaciones desarrollan mayores vías de comunicación,

por medio de redes que les permiten acelerar el flujo de información dentro de
sus oficinas, departamentos y otras dependencias.
21
Competitividad, Los Sistemas de Información son un instrumento estratégico, con el

cual pueden trasformar a la empresa o institución, en una más competitiva en el
mercado, sólo con un procesamiento adecuado de la información almacenada.
2.3. PARADIGMA ORIENTADO A OBJETOS
La idea de los objetos apareció como un mecanismo eficaz para representar los
módulos en los cuales se descomponen complejos sistemas, surgió de manera casi
simultánea en varios dominios de la informática, como en la arquitectura de las
computadoras, lenguajes de programación y metodologías de programación.
El paradigma orientado a objetos ha sido un tema de estudio por muchos

investigadores, tres autores han hecho grandes contribuciones al desarrollo de este
paradigma, estos investigadores son: Ivar Jacobson, Grady Booch y James
Rumbaugh, que inicialmente trabajaron de forma individual creando su propio
método orientado a objetos, para que finalmente reunieran sus investigaciones y
originaran del Lenguaje Unificado de Modelado y el Proceso Unificado de Desarrollo.
Algunos conceptos de orientación a objetos son los siguientes:
El término orientado a objetos significa que el sistema se organiza como una

colección de objetos que interactúan entre sí, además poseen estructuras de datos y
un comportamiento.
La clase es un conjunto de objetos con similares características.
Los Objetos son las cosas físicas y conceptuales que encontramos en el universo
alrededor de nosotros, hardware, software, documentos, seres humanos, los
conceptos son todos los ejemplos de los objetos. Los objetos con la misma
estructura de datos (atributos) y comportamiento (operaciones) se reúnen para
formar una clase. Los objetos tienen las siguientes características:
El encapsulamiento, oculta los detalles de la implementación de métodos,

típicamente la estructura de un objeto se encuentra oculta y la implantación de sus
métodos es visible.
22
La persistencia, es una propiedad que indica que una vez creado el objeto, éste
sobrevive.
La herencia, permite que una subclase herede los atributos y operaciones de la

clase genérica.
El polimorfismo, son dos o más funciones que poseen el mismo nombre pero
código diferente.
2.4. EL LENGUAJE DE MODELADO UNIFICADO UML
El Lenguaje Unificado de Modelado, UML “es un lenguaje de modelado visual, que

permite especificar, visualizar, construir y documentar los componentes que forman
parte de un sistema de software orientado a objetos”. [REF-B04]
2.4.1. Vistas UML
La descripción de los sistemas se realiza en UML a través de vistas, las mismas

están compuestas a su vez por distintos diagramas, ya que un solo diagrama no
puede mostrar toda la información que se requiere para describir un sistema. Es por
esta razón que es necesario, utilizar conjuntos separados de las vistas, para
representar proyecciones del sistema relacionadas con aspectos particulares
funcionales y no funcionales.
Figura 2.1: Vistas de UML
Vista de Vista lógica

componente
Vista de
casos de uso
Vista de Vista de
implantación concurrencia
Fuente: [REF-B04]
a) Vista de Casos de Uso
La vista de casos de uso hace el papel de enlace, pues esta constituye el hilo
conductor de todo el proceso de desarrollo, ya que es la única que no describe
23
aspectos de la construcción del sistema, sino de su comportamiento. La vista de

casos de uso, esta compuesta por los diagramas de casos de uso y diagramas de
actividad, que muestran la funcionalidad del sistema.
b) Vista lógica
Muestra el diseño de la funcionalidad del sistema en sus dos aspectos esenciales: El

primer aspecto es la estructura, es decir los comportamientos que lo integran, para lo
cual utiliza los diagramas de clases y objetos. El segundo aspecto es el
comportamiento del sistema, expresado en términos de la dinámica de interacción de
dichos componentes, utiliza los diagramas de estado, secuencia, colaboración y
actividad. La vista lógica es aplicada durante la fase de diseño y desarrollo del
sistema.
c) Vista de Componentes
Mediante la Vista de Componentes se muestra la organización del código y demás

archivos que hacen parte del sistema, tanto los que han sido desarrollados (código
fuente, ejecutables, etc.) como los que han sido adquiridos (bibliotecas de funciones
o de servicios, componentes reutilizados, etc.); además, muestra también las
relaciones de dependencia que existen entre ellos. Es utilizado por el grupo de
desarrollo y consiste en diseñar los diagramas de componentes.
d) Vista de Implantación
Muestra la implantación del sistema en la arquitectura física, indicando dónde se

localizan los ejecutables del sistema y cómo se comunican entre sí. Para ello, se
utiliza una descripción de los nodos del sistema, que son los computadores donde
éste se ejecuta, y los dispositivos periféricos relevantes. Es utilizado por los grupos
de desarrollo, integración y pruebas. La vista de implantación consistente en diseñar
el diagrama de despliegue.
24
e) Vista de Concurrencia
Es una combinación de la Vista Lógica, de Componentes y de Implantación, en la

que se muestra el manejo de los aspectos de afluencia en el sistema, especialmente
los de comunicación y sincronización. Para la descripción de la implementación se
diseñan los diagramas de componentes e implantación, así mismo para la
descripción dinámica se utilizan los diagramas de estado, secuencia, colaboración y
actividad.
2.5. EL PROCESO UNIFICADO DE RATIONAL RUP
El Proceso Unificado de Rational, es un conjunto de actividades necesarias para

transformar los requisitos del usuario en un sistema de software. Sin embargo, “el
proceso unificado es más que un simple proceso; es un marco de trabajo genérico
que puede especializarse para una gran variedad de proyectos de software, para
diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y tamaños
de proyecto”. [REF-B07]
El RUP, utiliza el Lenguaje Unificado de Modelado, para preparar todos los

esquemas de un sistema de software. De hecho, UML es una parte esencial del
proceso unificado. Los aspectos sobresalientes de éste, se resumen en tres frases
claves que son: dirigido por casos de uso, centrado en la arquitectura e iterativo e
incremental, esto es lo que hace que esta metodología sea única.
2.5.1. Dirigido por casos de uso
Los casos de uso le dan al sistema los requisitos funcionales, es decir, que es lo que
debe realizar el software. Lo que significa que los casos de uso, guían la arquitectura
del sistema y éste a su vez influye en la selección de los casos de uso.
2.5.2. Centrado en la arquitectura
La arquitectura del sistema se basa en aspectos dinámicos y estáticos, más

significativos que estarán reflejados en los casos de uso, los cuales deben
evolucionar de forma paralela con la arquitectura, la misma se representa mediante
25
vistas de un sistema, la cual contribuirá a desarrollar y documentar la arquitectura

del software. La arquitectura ayuda a comprender el sistema por parte de los
desarrolladores y clientes, también contribuye a organizar el desarrollo en
subsistemas e interfaces bien definidas.
2.5.3. Iterativo e incremental
Las iteraciones hacen referencia al flujo de trabajo (requisitos, análisis, diseño,

implementación y transición) y los incrementos en el crecimiento del producto. Las
iteraciones deben estar controladas; esto significa que deben seleccionarse y
ejecutarse de una forma planificada.
El Proceso Unificado, se repite a lo largo de una serie de ciclos que constituyen la

vida de un sistema. Cada ciclo consta de cuatro fases: inicio, elaboración,
construcción y transición. Cada fase se subdivide a su vez en iteraciones, como se
dijo anteriormente, cada ciclo produce una nueva versión del sistema y cada versión
es un producto preparado para su entrega.
Figura 2.2: Organización del Proceso Unificado de Rational
Fuente: [REF-B07]
A continuación se hace referencia a cada una de las cuatro fases que compre el RUP
y al flujo de trabajo de cada una de estas.
26
2.6. FASE DE INICIO
El objetivo de esta fase es delimitar el alcance del proyecto y elaborar el estudio de

factibilidad. Para ello, se deben identificar todas las entidades externas con las
cuales el producto va a interactuar (actores) y definir la naturaleza de estas
interacciones a un alto nivel. Esto implica la identificación de todos los casos de uso
y la descripción de los más significativos. El estudio de factibilidad incluye factores de
éxito, evaluación de riesgos, estimación de los recursos requeridos y la planeación
de las fases estableciendo las fechas de los hitos principales.
Para cumplir con el propósito de esta fase, se debe avanzar sustancialmente en los
componentes de Modelado del negocio y Captura de Requisitos. El hito de esta fase
es la definición de los objetivos y alcance del sistema, además del estudio de
factibilidad. Con base en este estudio, la dirección de la empresa a cargo del
desarrollo del proyecto, deberá tomar la decisión acerca de si el proyecto es viable, o
debe ser cancelado o re-planteado a fondo.
Teniendo en cuenta los requerimientos del presente proyecto, se toma como primera
actividad el plan de desarrollo del software y como primer flujo de trabajo el
modelado del negocio.
2.6.1. Plan de desarrollo del software
Es diseñar un plan de desarrollo de software basado en la metodología RUP, de

acuerdo a las características del presente proyecto, se organizó las siguientes
tareas: elaboración del plan de desarrollo del proyecto e informe preliminar. Dicho
plan contempla la organización del tiempo y el número de iteraciones que se llevarán
a cabo para cada una de las fases que contempla la metodología RUP. El informe
preliminar es la descripción de la actual situación de la organización y una visión
general de las características del sistema a desarrollar.
2.6.2. Modelado del negocio
El modelado del negocio consiste en la identificación y documentación de la

estructura y funcionamiento de la organización, en la cual funcionará el sistema a
27
desarrollar. Su objetivo es brindar un entendimiento a clientes y desarrolladores

sobre cuál es el problema de la organización, identificar mejoras potenciales y
establecer el impacto que el sistema a desarrollar tendría sobre la organización. Las
tareas a realizar dentro de este flujo de trabajo son: modelo de casos de uso del
negocio, descripción de los actores del negocio, descripción de los casos de uso del
negocio y modelo de dominio.
a) Modelo de casos de uso del negocio
Este modelado se lo realiza a través de los diagramas de casos de uso, se utilizan

para representar la funcionalidad de manera proporcional las funciones de los
usuarios, en este diagrama no se diferencian entre los procesos manuales y los
automatizados, por lo cual esta representación esta centrada en los procesos que el
negocio realiza y los actores que interactúan con el negocio.
b) Descripción de los actores del negocio
Los actores representan terceros fuera del sistema desarrollado, los cuales
colaboran con el funcionamiento de este último. Una vez identificado todos los
actores del sistema, tenemos identificado el entorno externo del sistema.
Un actor es una idealización de una persona externa, de un proceso o de una cosa

que interactúan con un sistema, un subsistema, o una clase. Un actor caracteriza las
interacciones que los usuarios exteriores pueden tener con el sistema.
Figura 2.3: Representación del actor y el caso de uso
Fuente: Elaboración propia.
28
c) Descripción del modelo de casos de uso del negocio
A medida que los analistas van identificando los casos de uso, desarrollan un
bosquejo inicial, con unas pocas palabras explican las actividades que realizan los
actores y más tarde elaboran una descripción paso a paso de lo que el sistema
necesita hacer cuando interactúa con sus actores.
d) Modelo de dominio
Un modelo de dominio captura los diferentes tipos de objetos más importantes

existentes en el contexto del sistema. Los objetos de dominio representan las cosas
que estén o los eventos que suceden en el entorno en el que trabaja el sistema.
Muchos de los objetos de dominio o clases pueden obtenerse de una especificación
de requisitos o mediante la entrevista con los expertos del dominio. El objetivo del
modelado de dominio es comprender y describir las clases más importantes dentro
del contexto del sistema.
2.7. FASE DE ELABORACIÓN
El propósito de esta fase es: analizar el dominio del problema, establecer una sólida
base arquitectónica, desarrollar el plan del proyecto, revisar de forma detallada sus
objetivos, alcances y eliminando los elementos de más alto riesgo del proyecto.
Puede afirmarse que la fase de elaboración es la más crítica de las cuatro, ya que
durante la misma se toma la decisión de si se realizan o no las fases de construcción
y transición. De acuerdo a los requerimientos del presente proyecto, los flujos de
trabajo utilizados en esta fase serán: la captura de requisitos y el análisis del sistema.
2.7.1. Captura de requisitos
El propósito de la captura de requisitos es determinar la funcionalidad del sistema y

lograr un acuerdo entre el equipo de desarrollo y el cliente. La captura de requisitos
se realiza durante la fase de inicio y elaboración. Asimismo comprende la realización
de las siguientes tareas: establecer las funciones del sistema, definir casos de uso de
alto nivel, definir casos de uso expandidos, especificar prototipo de interfaz y
glosario.
29
a) Funciones del sistema
Son todas aquellas funciones que deberá realizar el software desarrollado, las
mismas deben estar diferenciadas entre aquellas que son funciones evidentes de
aquellas que son ocultas.
b) Diagrama de casos de uso de alto nivel
Sirve para describir las interacciones del sistema con su entorno, identificando los
actores, que representan las diferentes actividades desempeñadas por los usuarios
del sistema y los casos de uso corresponden a la funcionalidad que el sistema
ofrece a los usuarios, explicada desde el punto de vista de éstos.
c) Casos de uso expandidos
Describen las interacciones con mayor detalle que los de alto nivel, enumerando
paso a paso los eventos que se presentan durante una ocurrencia típica del caso de
uso. El siguiente ejemplo ilustra el formato para la descripción de los casos de uso
expandidos:
Tabla 2.1: Ejemplo descripción de caso de uso expandido

Caso de uso Hacer reserva
Actores Monitor (iniciador)
Propósito: Asignar a un lector un libro para que pueda retirarlo mas tarde.
Resumen: El monitor ingresa la información del lector y del libro solicitado. El
sistema verifica la información del ítem y del lector, verifica e
informa la disponibilidad del libro solicitado, y modifica el estado del
ítem, asignándolo al lector.
Tipo primario y abstracto
Referencias Funciones: R1.1, R1.6 .Casos de uso: Control de acceso, hacer
cruzadas consulta.
Fuente: [REF-W03]
Algunas observaciones sobre la descripción de los casos de uso expandidos:
En la información general, cuando se declaran los actores, debe señalarse cuál es el

actor iniciador del caso de uso.
30
En el resumen puede usarse la descripción del caso de uso de alto nivel

correspondiente.
Las referencias cruzadas indican con cuáles funciones del sistema y con que otros
casos de uso existe relación. Las funciones se nombran utilizando la etiqueta que se
les asigna en la tabla de funciones del sistema, elaborada durante la captura de
requerimientos.
d) Prototipo de interfaz de usuario
Las interfaces son un elemento de mucha importancia para la construcción de

sistemas bien estructurados, los cuales juegan el papel de contratos entre los
usuarios de los servicios ofrecidos por una clase o un subsistema y sus
implementaciones. Se diseña la interfaz de usuario para que permita llevar a cabo los
casos de uso de manera eficiente. Esta actividad comienza con los casos de uso que
intentamos comprender. El resultado final de esta actividad es un conjunto de
esquemas de interfaces de usuario, que especifican la apariencia de las interfaces de
cada caso de uso.
Figura 2.4: Ejemplo de interfaz de usuario, pagar factura

Cuenta
. Saldo previsto
Factura
. Fecha de vencimiento.
. Cantidad a pagar.
. Cuenta destino
Fuente: [REF-B07]
e) Glosario
El glosario se utiliza para definir los términos más comunes e importantes que los
analistas y otros desarrolladores utilizan al describir el sistema. Un glosario es muy
útil para alcanzar un consenso entre los desarrolladores, relativos a la definición de
31
los diversos conceptos y nociones, para reducir en general el riesgo de confusiones.

Habitualmente se puede obtener un glosario a partir de un modelo de negocio o de
un modelo de dominio.
2.7.2. Análisis del sistema
Se analizan los requerimientos que se describieron en la captura de requisitos,

refinándolos y estructurándolos. El objetivo es conseguir una comprensión más
precisa de los requisitos y una descripción de los mismos, que sea fácil de mantener
y que ayude a estructurar el sistema entero. El análisis proporciona una visión
general del sistema. El estudio del análisis es de mayor importancia durante la fase
de elaboración, comprende las siguientes tareas: definir diagramas de secuencia y
diagramas de estados.
a) Diagramas de secuencia
Un Diagrama de Secuencias contribuye a la descripción de la dinámica del sistema

en términos de la interacción entre sus objetos. Esta interacción se lleva a cabo a
través de mensajes, el cual generalmente se implementa mediante la invocación de
una operación desde la clase "fuente" a la clase "destino". Este diagrama es útil para
observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles
errores del modelo estático, que imposibiliten el flujo de información o de llamadas
entre los componentes del sistema.
Figura 2.5: Representación de un diagrama de secuencia
32
b) Diagrama de estados
Un diagrama de estados muestra la secuencia de estados por los que pasa un caso
de uso de un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué
eventos hacen que se pase de un estado a otro y cuáles son las respuestas y
acciones que genera. En cuanto a la representación, un diagrama de estados es un
grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas
con los nombres de los eventos. Un estado se representa como una caja redondeada
con el nombre del estado en su interior. Una transición se representa como una
flecha desde el estado origen al estado destino.
Figura 2.6: Representación de un diagrama de estado
2.8. FASE DE CONSTRUCCION

El objetivo de esta fase es refinar la arquitectura básica de manera incremental
conforme se vaya construyendo, paralelamente se realiza la documentación del
sistema en cuanto a su construcción y manejo. Al empezar esta fase se debe fijar los
criterios de evaluación de acuerdo a los requerimientos especificados en los casos
de uso, detallados en la fase anterior. De acuerdo a lo mencionado la mayor parte
del trabajo será realizar la programación y pruebas de los módulos que se vayan
desarrollando.
El hito de esta fase es la obtención de un producto operacional, listo para ponerlo en

manos de los usuarios finales, a la vez que se verifica que su sitio de instalación y
usuarios estén listos para empezar la operación. A menudo, a esta entrega del
producto se le denomina “versión beta”. Los flujos de trabajo utilizados de acuerdo a
33
los requerimientos del presente proyecto son: el diseño del sistema e implementación
del sistema.
2.8.1. Diseño del sistema
El diseño modela el sistema de tal forma que contenga todos los requisitos, de
acuerdo al análisis realizado con anterioridad y de acuerdo a los requisitos
establecidos por los usuarios. El diseño del sistema es el centro de atención al final
de la fase de elaboración y en el comienzo de las iteraciones de construcción. En
este flujo de trabajo tomamos en cuenta las siguientes actividades: diseñar diagrama
de despliegue, diagrama de colaboración y diagrama de clases.
a) Diagrama de despliegue
En el modelado de un sistema cliente/ servidor, la división entre clientes y servidor es

complicada ya que implica tomar algunas decisiones sobre dónde colocar
físicamente sus componentes software, qué cantidad de software debe residir en el
cliente, etc. Para modelar un sistema cliente/servidor se realizan las siguientes
tareas:
Identificar los nodos que representan los procesadores cliente y servidor.
Destacar los dispositivos relacionados con el comportamiento del sistema.
Proporcionar señales visuales para esos procesadores y dispositivos a través
de estereotipos.
Figura 2.7: Representación de un diagrama de despliegue

b) Diagrama de colaboración
Este diagrama muestra a una serie de objetos con enlaces entre los mismos y con
mensajes que se intercambian entre objetos. Los mensajes son flechas que van junto
al enlace por el que circulan y con el nombre del mensaje y los parámetros (si los
34
tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál
es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no
lleva número de secuencia.
Figura 2.8: Representación de un diagrama de colaboración
c) Diagrama de clases
Una clase es la abstracción de un grupo de objetos con características similares, con

las mismas se organiza el diagrama de clases. Este diagrama muestra un conjunto
de objetos del sistema y las diversas relaciones que existen entre ellos. Dicho
diagrama es estático ya que no describe el comportamiento del sistema dependiente
del tiempo. Las relaciones existentes entre clases son:
Ligación y asociación, una ligación es la relación entre objetos, una asociación es

una descripción de una relación de ligaciones.
Figura 2.9: Tipos de asociaciones
Clase A Clase B
1 1
Relación 1 a 1
Clase A Clase B
n n
Relación n a n
Clase A Clase B
0 1
Relación 0 a 1
(Opcional)
35
Agregación, es un tipo especial de asociación representado por un relacionamiento

de la estructura del todo y sus partes.
Composición, se da cuando un objeto contiene un número de otros objetos, y

cuando el objeto contenedor es eliminado, entonces los objetos dependientes
también desaparecen.
Figura 2.10: Representación de agregación y composición
Clase A Clase B
n Agregación
Clase A Clase B
n
Composición
Generalización, es la relación que mantiene una clase A y otra clase B, cuando la

clase B es el ejemplo más específico de la clase A.
Figura 2.11: Ejemplo de generalización
Persona
Medico Policía
2.8.2. Implementación del sistema
Se implementa el sistema en términos de componentes, es decir, ficheros de código

fuente, scripts, ficheros de código binario, ejecutables y similares. La implementación
es la principal actividad durante las iteraciones de construcción. En este flujo de
36
trabajo diseñamos los diagramas de componentes e implementamos el código fuente

del sistema.
a) Diagrama de componentes
Un diagrama de componentes muestra la organización y las dependencias entre

distintos componentes del sistema, el cual se representa como un conjunto de nodos
y arcos entre estos.
Figura 2.12: Representación de un diagrama de componentes
2.9. FASE DE TRANSICIÓN
Esta fase se inicia cuando la línea de base del producto está suficientemente madura
para ser implantada en los ambientes de la organización. Esto normalmente requiere
que se haya completado los módulos del sistema, con un nivel de calidad aceptable y
que la documentación de usuario esté disponible, de manera que la transferencia al
usuario produzca resultados positivos para todas las partes. Esto incluye:
La realización de “pruebas beta” para validar el nuevo sistema con respecto a

.las expectativas de los usuarios.
La operación en paralelo con el sistema que se va a reemplazar.
La conversión de las bases de datos en operación.
El entrenamiento de los usuarios y el personal de mantenimiento.
La presentación del sistema a los equipos de mercadeo, distribución y ventas.
37
El hito de esta fase es la obtención de la satisfacción de los usuarios. En este punto

se establece si los objetivos fueron logrados y si se debería iniciar un nuevo
desarrollo del producto.
2.9.1. Pruebas del sistema
Los datos que se utilizan para la pruebas deben ser los más usuales por los clientes
y si es posible se recomienda realizar con datos reales para ejercitar las pruebas,
dichos datos son monocordes, es decir, si va con uno va con todos. También es
importante identificar qué rangos de datos pueden alterar el comportamiento del
programa y así definir zonas de trabajo. Es imprescindible pasar pruebas con al
menos un dato de cada zona, tanto si el programa debe funcionar como si debe dar
un mensaje de error. También es importante la validación de datos ingresados ya
que podrían ocurrir desbordes y producir terribles errores en el sistema.
Las pruebas se llevan a cabo sobre todo cuando la construcción es sometida a

pruebas de integración y de sistema, esto quiere decir que las pruebas se centran en
la fase de elaboración, cuando el grueso del sistema esta implementado. Estas
verificaciones tienen el objetivo de detectar todo posible malfuncionamiento antes de
que éste entre en funcionamiento. Un posible error detectado posteriormente podría
ser costoso en su reparación; siempre es preferible que el error se presente al
desarrollador que al usuario.
El conjunto de pruebas que se realizan al sistema, será de mayor calidad cuando

queden menos errores por descubrir tras haberlas realizado. Y viceversa, si un,
programa aún tiene muchas fallas tras haber superado el conjunto de pruebas,
entonces se dirá que esta es de poca calidad. Normalmente en un sistema de
software existen bastantes datos de entrada y si pudiéramos probarlas todas
tendríamos una prueba perfecta, sin embargo casi nunca es posible probar todos los
casos, en consecuencia es necesario elegir los casos de uso más críticos.
Una alternativa para realizar las verificaciones del sistema es la prueba de la caja
negra, la misma se basa en comprobar los requisitos funcionales del sistema. Esta
38
prueba intenta encontrar errores en: funciones incorrectas, interfaz, estructuras de

datos, rendimiento e inicialización y terminación.
2.10. MODELO DE BASES DE DATOS RELACIONALES
Este modelo tiene como objetivo, mantener la independencia de la estructura lógica

respecto al modo de almacenamiento y a otras características de tipo físico. Dicho
modelo esta formado por las siguientes partes:
Parte estructural, el modelo de datos relacional representan los datos en forma de

tablas o relaciones. Esta tabla consiste en filas y columnas de datos. Donde cada
columna representa un campo o atributo y una fila es un registro. En cada tabla
existe un conjunto de atributos claves que pueden ser primaria o foráneas, las
primeras son un conjunto de atributos no vacíos que identifica unívoca y
mínimamente cada registro que cumple un esquema de relación. Las claves foráneas
resultan ser la clave primaria perteneciente a otra tabla.
Parte manipulativa, es un conjunto de operadores que permiten manejar la parte

estructural del modelo relacional, para esto se hace mención del álgebra relacional y
el cálculo relacional. Dichos lenguajes teóricos manipulan relaciones en una base de
datos relacional, basándose en sus características lógicas y sin considerar la
estructura física usada para la implementación.
Implementación relacional con SQL (Lenguaje Estructurado de Consulta), La

manipulación de datos incluye todas las capacidades del álgebra relacional aunque
su formulación original esta basada en la estructura del cálculo relacional. Con SQL
se define un esquema relacional de la base de datos, donde se pueden formular
consultas de variada complejidad, además de: insertar, actualizar y borrar datos a
través de sentencias SQL.
Teoría de las dependencias funcionales y de normalización, se estudia las

dependencias entre los atributos y proporcionan métodos para el diseño de bases de
datos relaciónales. La normalización se encarga de obtener los datos agrupados en
39
tablas distintas, siguiendo una serie de tareas, de tal manera, que los datos
obtenidos tienen una estructura óptima para su implementación, gestión y
explotación desde distintas aplicaciones futuras.
2.11. NOTACIÓN UML PARA MODELAR ENTIDAD/ RELACIÓN
El diagrama de clases presenta un mecanismo de implementación neutral para

modelar los aspectos de almacenamiento de datos del sistema. Las clases
persistentes, sus atributos y sus relaciones pueden ser implementados directamente
en una base de datos orientada a objetos. Aún así, el entorno de desarrollo de base
de datos relacional, es el método más usado para el almacenamiento de datos.
El diagrama de clases puede ser utilizado para modelar ciertos aspectos del diseño
de bases de datos relacionales, pero no cubre toda la semántica involucrada en el
modelado relacional. Para capturar esta información, un diagrama entidad relación se
utilizara como extensión a UML. Asimismo el diagrama de clase puede ser utilizado
para modelar la estructura lógica de la base de datos, independientemente de si es
orientada a objetos o relacional, con clases representando tablas y atributos de clase
representado columnas. Si el método de implantación es una base de datos
relacional, entonces el diagrama de clase puede ser referenciado a un diagrama de
relación de entidad lógico.
Las clases persistentes y sus atributos hacen referencia a las entidades lógicas y a
sus atributos, el modelar dispone de varias opciones sobre como inferir asociaciones
en relaciones entre entidades. Las relaciones de herencia son referenciadas
directamente a súper - sub relaciones entre entidades en un diagrama ER. En el
diseño ER, el modelador empieza determinando cómo el modelo relacional encaja, y
qué atributos son claves primarias, secundarias y claves externas, basadas en
relaciones con otras entidades. La idea es construir un modelo lógico que sea
conforme a las reglas de normalización de datos.
El diagrama físico puede ser renormalizado para lograr un diseño de base datos que
tiene tiempos eficientes de acceso a datos. Las relaciones súper – sub entre
entidades se resuelven por las estructuras de tablas actuales. Además, el diagrama
40
físico se usa para modelar propiedades específicas de cada fabricante para el

RDBMS. Los creadores de UML asocian aspectos de relaciones que pueden ser
aplicables no sólo al contexto de la base de datos, sino también a la programación.
Se plantea la siguiente comparación para lograr una transformación de un modelo de
objetos en diagramas entidad-relación.
Figura 2.13: Notación UML para modelar E-R
Notación E - R Notación UML
Nombre Customer
ID Calle
Entidades y Nombre
ID
atributos Customer Calle
Rol1 Rol2
Rol1 R Rol2
E1 R E2 E1 E2
Relaciones
a1 a2 R
a1
a2
Cardinalidad E1 Rol1 Rol2
E2 E1 Rol1 Rol2
E2
R
entre
entidades
Rol1 Rol2 Rol1 R Rol2
E1 R E2 E1 E2
Persona Persona
Generalización
ISA
y
especificación
Customer Empleado Customer Empleado
Fuente: [REF-W01]
41
2.12. ARQUITECTURA CLIENTE / SERVIDOR
La arquitectura cliente/servidor es una red de computadoras en la que una o más

terminales ofrecen servicios, de ahí el nombre de servidores, las restantes
computadoras de la red, son clientes de estos servidores. Los servidores se
optimizan para que lleven de manera más eficiente sus funciones específicas dentro
de la red. Los servicios de bases de datos suelen ser los más frecuentes en un
sistema de información. Por otro lado los sistemas clientes se optimizan para la
entrada y presentación de los datos, por lo tanto, estos incluyen normalmente
interfaces graficas agradables a los usuarios.
Los servidores de bases de datos, son equipos de computación que almacenan

grandes cantidades de información o datos. En una arquitectura cliente/servidor los
clientes envían sus consultas al servidor de base de datos, por medio de una interfaz
grafica. Dichas consultas se envían al servidor en un lenguaje llamado SQL. El
servidor de base de datos lee este lenguaje y lo interpreta y realiza la petición y
devuelve la respuesta al cliente. El software intermedio entre los clientes y servidores
esta compuesto por el protocolo TCP/IP y esta asociado a los servicios que requieren
los clientes y el servidor.
2.12.1. SQL Server 2000

Es un sistema de gestión de bases de datos relacionales (SGDBR o RDBMS:
Relational Database Management System) diseñado para trabajar con grandes
cantidades de información y la capacidad de cumplir con los requerimientos de
proceso de información para aplicaciones comerciales y de sitios Web. SQL Server
2000 ofrece el soporte de información para las tradicionales aplicaciones
Cliente/Servidor, las cuales están conformadas por una interfaz a través de la cual
los clientes acceden a los datos por medio de una red local.
SQL Server 2000 está diseñado para trabajar con dos tipos de bases de datos: OLTP
(Online Transaction Processing) Son bases de datos caracterizadas por mantener
una gran cantidad de usuarios conectados paralelamente, realizando ingresos y/o
42
modificación de datos, por ejemplo: entrada de pedidos en línea, inventario,

contabilidad o facturación.
OLAP (online Analytical Processing) Son bases de datos que almacenan grandes
cantidades de datos que sirven para la toma de decisiones, como por ejemplo las
aplicaciones de análisis de ventas.
SQL Server puede ejecutarse sobre redes basadas en Windows Server así como
sistema de base de datos de escritorio en máquinas Windows NT Workstation,
Windows ME y Windows XP. Los entornos Cliente/Servidor, están implementados de
tal forma que la información se guarde de forma centralizada en un computador
central, siendo el servidor responsable del mantenimiento de la relación entre los
datos, asegurarse del correcto almacenamiento de los datos, establecer restricciones
que controlen la integridad de datos.
Del lado cliente, este corre típicamente en distintas computadoras las cuales
acceden al Servidor a través de una aplicación, para realizar la solicitud de datos los
clientes emplean el Lenguaje Estructurado de Consulta, dicho lenguaje tiene un
conjunto de comandos que permiten especificar la información que se desea
recuperar o modificar.
2.13. MÉTRICAS DE CALIDAD DEL SOFTWARE
La calidad del software es “la concordancia con los requisitos funcionales y de

rendimiento explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se espera de
todo software desarrollado profesionalmente”. [REF-B03]
Para medir la calidad del software, se hace uso de un conjunto de métricas de

calidad, las mismas poseen la finalidad de evaluar las distintas características que
posee el sistema para definir la calidad del mismo. La norma estándar ISO 9126
define un conjunto de métricas de calidad. Por las características del presente
43
proyecto se hace uso de las siguientes métricas: funcionalidad, confiabilidad,

mantenibilidad y portabilidad
2.13.1. Funcionalidad
La funcionalidad se puede definir como la capacidad del producto software para

proporcionar funciones que satisfagan las necesidades especificadas. Esta métrica
no puede ser medida directamente es por eso que su cálculo debe derivar
indirectamente de otras medidas directas. Una de estas medidas es el punto función
que fue propuesta por Albretch.
El primer paso para el cálculo de esta métrica es determinar los valores de cinco
características de dominios de información, los cuales son: número de entradas de
usuario, salidas de usuario, peticiones de usuario, archivos e interfaces de usuario.
Después de haber recopilado estos datos se asocia a un valor de complejidad, dicho
valor puede ser simple, medio o complejo. Finalmente se hace uso de la siguiente
relación para el cálculo del punto función:
PF = Cuenta _ total * [0.65 + 0.01*∑ Fi]
Donde cuenta total, es la suma de todas las entradas punto función PF, 0.65 es el
valor de ajuste de complejidad mínimo, 0.01 es el factor de conversión, es decir, un
error del 1% y [0.65 + 0.01*∑ Fi] resulta ser el factor de ajuste de complejidad
máximo.
2.13.2. Confiabilidad
La confiabilidad representa la cantidad de tiempo que el software esta disponible

para su uso, es decir, que la confiabilidad es la probabilidad de operación libre de
fallas de un programa de software en un entorno establecido, durante un periodo
determinado de tiempo. El cálculo de la confiabilidad del sistema se calcula con la
siguiente ecuación:
P(T>=t) = 1- F(t)
44
Donde F(t ) es la confiabilidad del sistema, t representa el periodo de tiempo en el

que se pone a prueba el sistema y 1-F(t) es la probabilidad de ejecución sin fallas.
La probabilidad de falla del sistema F(t) se calcula en el periodo t, para calcular esta
probabilidad se hace uso de la función exponencial dada por :
(-λ* t)
F(t)= f * e
Donde f es la funcionalidad del sistema, lambda es la probabilidad de fallo en un

periodo de tiempo y t es el tiempo total en el que se hace el cálculo de fallo.
2.13.3. Mantenibilidad
La mantenibilidad es la capacidad del producto software para soportar

modificaciones, las mismas pueden incluir correcciones, mejoras o adaptación del
software a cambios en el entorno, relativo a los requisitos o especificaciones
funcionales. El mantenimiento puede ser correctivo o adaptativo, el primero hace
referencia a errores durante el desarrollo del producto, mientras que el
mantenimiento adaptativo, es cuando las normas o políticas de la entidad cambian y
el software debe adaptarse a estas.
Para el cálculo de la mantenibilidad del sistema se hará uso de la siguiente ecuación:
TMEF = TMDF + TMC

Donde:
TMEF: Tiempo Medio Entre Fallas

TMDF: Tiempo Medio de Falla
TMC: Tiempo Medio de Cambio.
El TMC es el tiempo que se tarda en realizar los cambios respectivos de

actualización del sistema y la prueba de estos. El TMC se calcula con la siguiente
relación:
TMC = TMAC + TMIC + TMPC + TMDC
Donde: TMAC: Tiempo Medio de Analizar los Cambios.

TMIC: Tiempo Medio de Implementación de Cambios.
45
TMPC: Tiempo Medio de Probar los Cambios.

TMDC: Tiempo medio en distribuir los cambios.
2.13.4. Portabilidad
La capacidad del producto software para ser transferido de un entorno a otro, es

decir la facilidad del producto de software para ser instalado en un ambiente
determinado.
2.14. SEGURIDAD DE LOS SISTEMAS DE INFORMACIÓN
La seguridad de los sistemas de información, mantiene la integridad de la

información almacenada en la base de datos, ya que la seguridad esta orientada a
prevenir alteraciones o eliminaciones no autorizadas, mantener la confidencialidad
de datos e inaccesibilidad de la información cuando se necesita.
Estos aspectos se relacionan con las tres características que debe cubrir un sistema
de información seguro: confidencialidad, integridad y disponibilidad. Ya que
preservar estas tres características de la información, constituye el objetivo de la
seguridad. Cuando se trata de seguridad de la información, se tienen tres conceptos
que entran en el tema, los cuales son: vulnerabilidad, amenazas y contramedidas.
Vulnerabilidades, punto del sistema susceptible a ser atacado o de dañar la

seguridad del mismo, las vulnerabilidades pueden ser:
Vulnerabilidad física, relacionado con el entorno físico que rodea al sistema, es decir,
la posibilidad de acceder al sistema para robar, modificar o destruir el mismo.
Vulnerabilidad natural, se refiere a los fenómenos naturales que puedan afectar el

sistema, como ser inundaciones, rayos, terremotos, fallas eléctricas, humedad y
temperatura.
Vulnerabilidad del hardware y software, desperfectos en algún dispositivo de

hardware y problemas que pueda tener el sistema operativo.
46
Vulnerabilidad de las comunicaciones, esta referido con la instalación de las redes

existentes en la organización. Dado que se corre el riesgo de que la información sea
interceptada por causa de penetraciones al sistema a través de la red.
Vulnerabilidad humana. Los usuarios también representan una vulnerabilidad, ya que

todo el sistema descansa sobre el administrador del sistema.
Amenazas, Las amenazas al SI pueden también clasificarse desde varios puntos de

vista.
Intercepción, cuando una persona o programa logra el acceso a una parte del
sistema a la que no esta autorizada.
Modificación, una vez que se ha tenido acceso al sistema, se empieza a hacer

modificaciones no autorizadas.
Interrupción, interrumpir mediante algún método el funcionamiento del sistema, como

es la saturación de la memoria, destruir algún dispositivo de hardware.
Generación, añadir información o programas no autorizados en el sistema.
Amenazas involuntarias, son aquellas relacionadas con el uso descuidado del equipo
por falta de entrenamiento.
Medidas de seguridad, las medidas de seguridad están orientadas a proteger el

sistema, y para aplicar las mismas, se debe realizar un previo análisis y
cuantificación de las vulnerabilidades que presente el sistema. El resultado de esta
actividad consiste en planificar una política de seguridad, implementando una serie
de medidas, las cuales pueden ser:
Medidas físicas, mecanismos para impedir el acceso directo o físico no autorizado al

sistema.
Medidas lógicas, se refiere a la protección de los datos almacenados, incluye las

medidas de acceso a los recursos de la información y al uso correcto de los mismos,
47
así como a la distribución de las responsabilidades entre los usuarios. Algunos

medidas lógicas son: política de control de accesos, definición de una política de
instalación y copia del software, uso de criptografía para proteger la información, uso
de cortafuegos, política de copias de seguridad.
Medidas administrativas, son aquellas que deben ser tomadas por las personas
encargadas de definir la política de seguridad para ponerla en práctica, hacerla viable
y vigilar su correcto funcionamiento. Algunas medidas son: Documentación y
publicación de la política de seguridad.
2.15. GESTIÓN ACADÉMICA
La gestión académica comprende todas las actividades que se realizan durante un

año en una institución académica, como son: los conservatorios, academias,
colegios, institutos privados, normales y universidades. Entre las actividades
académicas más importantes están la: gestión de documentación, matriculación de
alumnos, preinscripciones, reservas, listados por conceptos, ingresos y gastos,
inventario, horarios, registro de pensiones, asociación de padres de familia, registro
de calificaciones, elaboración de horarios, manejo de becas, estado de cuentas,
múltiples reportes administrativos, estadísticos y otros.
2.16. SEGUIMIENTO PSICOSOCIAL
El termino psicosocial se refiere a la conducta humana en su aspecto social o

relacionado con ella. El seguimiento psicosocial dentro del programa RIBUTRA es el
registro y evaluación de los antecedentes de maltrato físico o psicológico que haya
sufrido el participante y a partir de esos datos planificar una serie de talleres y/o
consultas regulares que realiza el psicólogo con los involucrados.
48
Sistema de Gestión Académica y Seguimiento Psicosocial Desarrollo del Software
49
3.1. CONSTRUCCIÓN DEL SOFTWARE
La construcción de un software debe partir de un proceso de planificación, para

definir quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo, lo
cual proporciona normas para la construcción eficiente de un sistema de calidad. En
este sentido, para el desarrollo del Sistema de Gestión Académica y Seguimiento
Psicosocial SIGASP, para el Centro de Capacitación Técnica Sarantañani, se aplicó
la metodología del Proceso Unificado de Rational RUP, cuyas fases comprende:
inicio, elaboración, construcción y transición, las cuales permiten organizar el flujo de
trabajo como se expone a continuación.
3.2. FASE DE INICIO
Como primera tarea en esta fase se planificó un cronograma de actividades que

contempla las cuatro fases de la metodología RUP. La construcción del proyecto fue
desarrollada en un lapso de 6 meses, como se refleja en la siguiente tabla.
Tabla 3.1: Cronograma del desarrollo del software
Fases Junio Julio Agosto Septiembre Octubre Noviembre

Inicio
Elaboración
Construcción
Transición
En esta etapa se recopiló información acerca de los procesos de administración de

información, en cuanto al seguimiento y evaluación académica y psicosocial, por
medio de entrevistas y documentación. El flujo de trabajo que se llevó adelante fue
el modelado del negocio, el cual comprendió las siguientes actividades: modelo de
casos de uso del CCTS, descripción de los casos de uso del CCTS, descripción de
los actores del CCTS y el modelo de dominio. La elaboración de estas actividades
duro cuatro semanas, cuyo resultado se detalla a continuación.
50
3.2.1. Modelado del CCTS
a) Modelo de casos de uso para el CCTS

La gráfica muestra las actividades e interacciones que realizan los usuarios en el
CCTS, con relación a la administración de información.
Figura 3.1: Casos de uso del CCTS
51
b) Descripción de los actores del CCTS
Participante. Adolescente, joven o señorita que se inscribe en el Centro de

Capacitación. El inscrito puede clasificarse como participante de comunidad o de
institución. El participante de comunidad es aquel que proviene de alguna zona o
villa cercana a la institución. El participante de Institución proviene de algún
Programa perteneciente o no a la Fundación La Paz.
Tutor. Es la persona responsable del participante, ésta puede ser el padre, madre,
tíos, hermanos, abuelos, u otra persona que sea familiar o no del inscrito. Todos sus
datos personales son almacenados en el sistema.
Secretaria. Persona que forma parte del plantel administrativo del Centro de
Capacitación. Generalmente es encargada de la inscripción de los participantes y del
control de pagos, además de generar los listados de inscritos y otros relacionados
con la administración de la documentación que hubiese en el Centro.
Instructor. Persona responsable de brindar la respectiva enseñanza de una

especialidad a los participantes y de evaluar a los mismos, durante el periodo que
dure la gestión académica. Registra la ficha de evaluación y genera el resumen
bimestral de asistencia y horas/aula.
Coordinador. Como su nombre lo indica es el encargado de organizar y administrar

toda la gestión académica, una de sus tareas es la planificación del calendario
académico de gestión, elaboración de la boleta de evaluación bimestral además del
resumen anual de evaluación y horas/aula.
Psicólogos. Personal encargado de realizar el respectivo seguimiento psicosocial a

los participantes, además de evaluar el desarrollo personal y social de los mismos.
52
c) Descripción de los casos de uso del CCTS
Los participantes registran una solicitud de ingreso al CCTS, posteriormente la

secretaria de la institución llena la ficha de inscripción con todos los datos generales,
seguidamente se registran los datos de los padres o tutores, los cuales se
comprometen a la regular asistencia del inscrito. Luego, el participante cancela
determinados montos en efectivo por concepto de carnet de estudiante, carnet de
salud, certificados y atención médica.
Como se mencionó anteriormente existen dos tipos de inscritos, que son los
participantes de institución y los de comunidad. Por lo cual existen dos distintos
formularios psicosociales, los cuales son registrados por la psicóloga de la
institución, estos formularios son importantes para la generación de reportes
estadísticos, al final de cada gestión académica.
La evaluación de los alumnos en la mayoría de las especialidades es bimestral y está

a cargo de un instructor, él es el encargado de registrar el formulario de evaluación.
La psicóloga evalúa el Desarrollo Personal y Social DPS, del alumno y el instructor
de computación evalúa su materia.
A diferencia de las otras especialidades existentes, la especialidad de computación

es evaluada trimestralmente y los participantes están en la obligación de cancelar
mensualmente un monto determinado por la utilización del equipo de computación.
Esta especialidad carece de la calificación en Desarrollo Personal y Social, ya que el
número de horas asistidas es menor a las otras especialidades.
Para ambas formas de evaluación se debe crear un resumen de calificación y horas

asistidas bimestralmente o trimestralmente, dicha tarea es un reporte creado por los
instructores de cada especialidad. Posteriormente estos reportes son entregados al
coordinador de la institución, para que éste realice el resumen anual de evaluación y
horas asistidas de cada una de las especialidades del CCTS. Otra de las tareas del
53
coordinador es la de crear boletas de evaluación, que son entregados a cada uno de

los inscritos.
El seguimiento psicosocial está a cargo de los psicólogos de RIBUTRA (Rincón del

Buen Trato) que como se mencionó anteriormente realizan un monitoreo a aquellos
participantes con problemas de maltrato físico o psicológico. Para esto registran los
antecedentes de maltrato que sufren o hayan sufrido por parte de familiares,
profesores u otros cercanos a él. Una vez llenados esto datos se realizan talleres o
consultas con el participante y con los involucrados en el maltrato.
A la conclusión de cada gestión académica se realizan informes estadísticos,

relacionados con los datos generados durante la gestión, como ser: edades, género,
participantes retirados, inscritos por especialidad y otros.
d) Modelo de dominio del CCTS.

Figura 3.2: Modelo de dominio
CCTS Inscripción de alumnos
Control pagos Evaluación académica Seguimiento psicosocial
Generación de recibo Generación de reportes Generación de informes
54
3.3. FASE DE ELABORACIÓN

Para esta etapa ya se tiene reunida todo lo referente a la administración de
información académica y psicosocial del Centro de Capacitación Técnica
Sarantañani, la cual se constituye en la base para realizar la descripción del sistema.
El primer flujo de trabajo contempla la captura de requisitos en el cual se definen: las
principales funciones del sistema, casos de uso, descripción detallada de los casos
de uso y finalmente se define el primer prototipo de interfaz. El segundo flujo de
trabajo comprende la realización del análisis del sistema, lo cual implica efectuar un
estudio de los casos de uso, utilizando para ello los diagramas de secuencia y
diagramas de estado. A la finalización de esta fase se tiene una visión detallada del
sistema a construir.
3.3.1. Captura de requisitos del SIGASP

a) Funciones del SIGASP
Luego de identificar las tareas que realiza el personal del CCTS, y de realizar el
modelo de la institución, se ha concretado una lista de las principales funciones con
las que debe contar el sistema. Dicha lista es un acuerdo con los usuarios y el
desarrollador del proyecto.
Tabla 3.2: Requisitos funcionales del sistema
Ref. Función del sistema Categoría
R1 Implementar un formulario para registrar el calendario Evidente

académico (gestión académica, bimestres, trimestres)
R2 Implementar un formulario para la inscripción de alumnos. Evidente
R3 Generar el reporte “compromiso de estudio”. Evidente
R4 Implementar un formulario para registrar a padres o tutores. Evidente
R5 Implementar un formulario donde se registre las causas del Evidente

retiro de alumnos durante la gestión académica.
R6 Implementar un formulario de registro de pagos que realizan Evidente

los alumnos, además de generar el recibo de los mismos.
55
R7 Implementar formularios para almacenar las fichas Evidente

psicosociales de los participantes de comunidad y de
institución.
R8 Diseñar un formulario para registrar la ficha de evaluación Evidente

bimestral, trimestral y de alumnos libres. Además de generar
de la misma su boleta de evaluación.
R9 Diseñar formularios para registrar las calificaciones de Evidente

computación y Desarrollo Personal y Social.
R10 Generar reportes pertenecientes al resumen de control Evidente

bimestral o trimestral de asistencia horas/aula y evaluación
para los alumnos regulares.
R11 Generar reportes pertenecientes a resumen anual de Evidente

horas/aula y evaluación bimestral o trimestral para los
alumnos regulares.
R12 Implementar un formulario para registrar las especialidades Evidente

técnicas existentes en el Centro de Capacitación.
R13 Implementar módulos para registrar la ficha psicosocial de los Evidente

participantes de institución y de comunidad.
R14 Implementar un módulo para el seguimiento psicosocial. Evidente
R15 Generar listados de los participantes por gestión, Evidente

especialidad y participantes retirados.
R16 Generar reportes estadísticos por sexo, grado de escolaridad, Evidente

edad, tipo de participante, programa de procedencia, número
de inscritos por especialidad y participantes retirados.
R17 Diseñar reportes personalizados donde se generan informes Evidente

sobre sexo, edad, grado de escolaridad, tipo de participante y
programa de procedencia.
Implementar un formulario para registrar los datos generales

R18 de los usuarios, nombre de usuario, contraseña y un nivel de Evidente
acceso al sistema controlado por un inicio de sesión.
R19 Implementar un formulario para la creación de copias de oculto

seguridad y restauración de la base de datos.
56
b) Casos de uso del SIGASP
Una vez identificados los actores y teniendo el modelo del CCTS, se identifican los
casos de uso del SIGASP, junto con los usuarios que llevarán a cabo dichos
procesos. Como se podrá observar a continuación, se ha sintetizado los casos de
uso de la institución, para entender las funciones principales con las que debe contar
el sistema.
Figura 3.3: Casos de uso del SIGASP
57
c) Descripción detallada de los casos de uso expandidos del SIGASP
Figura 3.4: Caso de uso, inscripción de participantes
Tabla 3.3: Descripción del caso de uso, inscripción de participantes
Caso de uso Inscripción de participantes.
Actores Participante, padres o tutor, secretaria.
Propósito Registrar los datos del participante y del padre o tutor.
Resumen La secretaria selecciona la opción “INSCRIPCIÓN”, busca la

gestión actual y adiciona nuevo registro. Introduce los datos
personales del participante y seguidamente los datos del
tutor. Una vez grabados y almacenados los datos, la
secretaria genera el documento de compromiso de estudio,
para que éste pueda ser firmado por el tutor y el inscrito.
Tipo Primario y esencial
Referencia cruzada R1, R2, R3
58
Figura 3.5: Caso de uso, evaluación académica
Tabla 3.4: Descripción del caso de uso, evaluación académica
Caso de uso Evaluación académica
Actores Instructores, psicóloga, coordinador
Propósito Registrar las calificaciones obtenidas por el inscrito

El instructor realiza el listado de alumnos por especialidad y registra
Resumen de cada uno su evaluación ya sea bimestral o trimestral. La misma
tarea realiza la psicóloga con la materia de DPS y el instructor de
computación. Una vez registradas todas las calificaciones el
coordinador se encarga de generar las boletas de calificación para
los estudiantes. Todo instructor al termino de registrar sus notas
debe presentar un reporte de la evaluación de su especialidad, para
esto genera un resumen bimestral o trimestral de evaluación. Al final
de la gestión el coordinador genera el resumen anual de evaluación.
Referencia R8, R9 , R10, R11, R12, R13, R14

cruzada
59
Figura 3.6: Caso de uso, seguimiento psicosocial
Tabla 3.5: Descripción del caso de uso, seguimiento psicosocial
Caso de uso Seguimiento psicosocial
Actores Participante, Psicólogo
Propósito Realizar un seguimiento a participantes con problemas de

maltrato físico o psicológico.
Resumen Cada psicólogo atiende un número determinado de

participantes, para los cuales registra sus datos particulares
(estos datos son historial familiar, tipo de maltrato, personas
implicadas, y otros) Una vez almacenada esta información se
realiza un seguimiento por medio de consultas periódicas,
dichas consultas son registradas y almacenadas para luego
generar un informe de todas las consultas realizadas.
Referencia R2, R16

cruzada
Los restantes casos de uso se detallan en el ANEXO III.
60
d) Definir prototipo de interfaz
Para esta actividad se han diseñado esquemas aproximados de la configuración de

elementos de las interfaces de usuario, las cuales resultan útiles para entender el
funcionamiento del sistema.
Figura 3.7: Prototipo de interfaz, caso de uso inscripción de participantes
Pantalla de entrada Pantalla Principal Inscripción
.Inscripción Inscrip- Nuevo

Nombre usuario Continuar ción Familiar
.Evaluación académica
.Control pagos. Compromiso de estudio
Contraseña Formulario de inscripción
.Control asistencia
Pagos
... Salir
Aceptar Salir
Nuevo () Familiar ()
Genera
Compromiso
Participante Datos del Tutor Compromiso de estudio
Introducir datos Introducir datos Despliega el documento

generales del personales del tutor compromiso de estudio
participante
Grabar . Imprimir
Grabar() Cancelar . Actualizar
Cancelar() Salir
Grabar
Grabar
Mensaje
Mensaje
Muestra el resultado
del almacenamiento Muestra el resultado
del almacenamiento
Aceptar
Aceptar
61
La siguiente figura muestra la interfaz de usuario para el caso de uso evaluación

académica.
Figura 3.8: Prototipo de interfaz, caso de uso evaluación académica
Pantalla de entrada Pantalla principal Evaluación académica

Nombre usuario .Inscripción
Continuar
Contraseña .Evaluación académica
.Control pagos Evaluación académica
.control asistencia
Aceptar .Seguimiento Lista de inscritos por
psicosocial especialidad.
..
. Ev. Especialidad
. Ev. Computación.
. Ev. DPS
. Boleta de Evaluación
Evaluación . Resumen Bimestral
Evaluación especialidad Evaluación
. Resumen anual.
DPS Computación
. Salir
Evaluación DPS Evaluación especialidad Evaluación Computación
. Nombre participante . Nombre participante . Nombre participante

. Bimestre . Nombre especialidad . Bimestre o trimestre
. Introduce calificación . Introducir evaluación . Introduce calificaciones
. Grabar . Grabar . Grabar

. Salir . Salir . Salir
Generar
Generar resumen Generar resumen
boleta
anual Bimestral o trimestral
Boleta de evaluación Resumen anual Resumen de evaluación
Despliega el reporte de Despliega el reporte del Despliega el reporte del

la boleta de evaluación resumen anual de resumen bimestral o
evaluación. trimestral de evaluación.
. Imprimir . Imprimir
. Actualizar Imprimir . Actualizar
. Salir . Salir
62
e) Términos del glosario
Inscripción de participantes. Caso de uso, en el cual la actividad principal es el

registro de los datos generales del inscrito y el almacenamiento de los mismos en la
base de datos.
Registro de pagos. Caso de uso, en el cual se registran todos los pagos realizados
por los inscritos durante una gestión académica.
Seguimiento psicosocial. Caso de uso. Es la actividad que realizan los psicólogos,

la cual consiste en realizar un monitoreo de los participantes con problemas de
maltrato físico o psicológico.
Seguimiento académico. Caso de uso, dicha actividad esta a cargo de los

instructores del CCTS, cuya tarea principal es la de evaluar regularmente a los
inscritos en las distintas especialidades.
Reportes. Salida del SIGASP, consiste en una hoja electrónica con el resultado del
procesamiento interno de los datos (informes, reportes, listados).
Prototipo. Modelos iniciales del sistema. Dichos modelos específicamente estarán

orientados a las interfaces gráficas e implementación del sistema.
Salidas de usuario. Es la información orientada a la aplicación que se proporciona

al usuario. En este contexto la salida se refiere a informaciones, pantallas, mensajes
de error y otros.
Entradas de usuario. Es la información orientada a la aplicación que registra el

usuario a través de las interfaces gráficas del sistema.
63
3.3.2. Análisis del SIGASP
Una vez identificada las funciones del SIGASP, se realizó una descripción detallada
de cada uno de los casos de uso, con el fin de identificar los objetos del sistema,
mediante el diagrama de secuencia y el diagrama estado.
a) Diagramas de secuencia
Figura 3.9: Diagrama de secuencia, seguimiento psicosocial
64
Figura 3.10: Diagrama de secuencia, inscripción de participantes
65
Figura 3.11: Diagrama de secuencia, evaluación académica
66
b) Diseñar diagramas de estados
Figura 3.12: Diagrama de estado, inscripción de participante
Figura 3.13: Diagrama de estado, evaluación académica
Figura 3.14: Diagrama de estado, seguimiento psicosocial
Los restantes diagramas de estado se detallan en el ANEXO III.
67
3.4. FASE DE CONSTRUCCIÓN
Teniendo ya definidos las interacciones y funciones del sistema requerido por el

CCTS, se elabora el diseño de software, a través del modelado del sistema, de forma
que contenga todos los requisitos de acuerdo al análisis realizado y los
requerimientos establecidos por la institución. Dentro de esta fase, el primer flujo de
trabajo corresponde al diseño del sistema, que a su vez contempla las siguientes
actividades: diseño de la arquitectura del SIGASP, diseño de los diagramas de
colaboración y diseño del diagrama de clases. El segundo flujo de trabajo abarca la
implementación del sistema, cuyas actividades a desarrollar son: definición del
diagrama de componentes e implementación del prototipo del SIGASP.
3.4.1. Diseño del SIGASP
a) Diseño de la arquitectura del SIGASP

El diseño de la arquitectura se la realiza mediante el diagrama de despliegue.
Figura 3.15: Diagrama de despliegue
Secretaria Coordinador Administrador

del sistema
Servidor
Usuarios SIGASP
SIGASP Red local
Conexión
Psicólogos ADO .NET
Base de
Datos
Instructores
EL diagrama anterior refleja una arquitectura de tres capas, correspondiente a una

arquitectura cliente/servidor: la primera capa pertenece a la interfaz gráfica en la que
68
los usuarios interactuaran con el SIGASP. La segunda capa corresponde a la interfaz

lógica, que esta dada por el control de acceso que tienen los usuarios al servidor del
sistema, por medio de un nombre de usuario y contraseña. La última capa es la
interfaz de acceso a datos comprendida por el gestor de base de datos.
b) Diseño del diagrama de colaboración

El diagrama de colaboración permite modelar las distintas interacciones y enlaces
existentes entre los objetos.
Figura 3.16: Diagrama de colaboración inscripción de participantes
Figura 3.17: Diagrama de colaboración, seguimiento psicosocial
Los restantes diagramas de colaboración se encuentran en el ANEXO III.
69
c) Diseño del diagrama de clases
Figura 3.18: Diagrama de clases del SIGASP
70
d) Diagrama Entidad - Relación

Utilizando el diagrama de clases, diseñamos el diagrama entidad – relación, para
implementar la base de datos del SIGASP. La misma será implementada en un
gestor de base de datos relacional, como es el SQL Server 2000 y no una orientada
a objetos como lo requiere el diagrama de clases.
Figura 3.19: Diagrama entidad – relación
1, 1 Gestión - n, 1
Gestión Bimestre
bimestre
1, n n, 1
n, 1
Personal
Evaluación
1, n
trimestral
Inscritos Evalua
Dicta
do
1, n 1, n
0,1
n, 1 Participante 1, n 1, 1 Especialidad
Inscrito
1, n 1, 1 1, 1
1,1 Datos
ISA Posee
particulares
1, 1
Participante
Tutor
Ficha_Psico Ficha_Psico
Institucion Seguimiento
comunidad
n, 1
n, 1
n, 1
Recibo Pagos Tutor Consultas
71
e) Descripción del diagrama Entidad – Relación. A continuación se detallan cada

una de las entidades identificadas con sus respectivos atributos. Las claves
primarias son los campos subrayados y resaltados con negrita, las claves foráneas
sólo están subrayadas).
Participante (participanteID, gestionID, Paterno, Materno, Nombres, fecha_nac,

foto, sexo, dirección, ci, teléfono, grado de escolaridad, curso, año, colegio)
Gestión (gestionID, fechaIni, fechaFin)
Bimestre (bimestreID, GestionID, tipoevaluacion, numbimestre, fechaini, fechafin,

días)
Evaluacion (bimestreID, ParticipanteID, programa, proyecto, teoría, práctica, dps,

computación)
Evaluacion_trimestral (bimestreID, ParticipanteID, dactilografia, ensamblaje,

mantenimiento, dos, windows, word, excel, powerp)
Ficha_psico_comunidad (participanteID, tipofamilia, numeropersonas, ingresofam,

tipovivienda, serviciosbasicos, material, num_habit, idioma, util_servicio,
obs_medicas)
Ficha_psico_institucion (participanteID, comp_fam, Idioma_util, servicio_inst,

obs_medicas, asp_imp, rel_fam, llevaban_en_casa, compartian, existian_rel, religión,
contacto_act, pers_confianza, procedencia, motivo, como_llego, conducta_prog,
tiempo, descripcion)
Datos_particulares (participanteID, derivado_por, instancia, nom_ins,

fecha_primer_contacto, participantes, apariencia, actitud, historia_familiar,
situación_acutal)
Consultas (consultaID, ParticipanteID, fecha, participantes, acuerdos, informe, obs,

otros)
Tutor (tutorID, ParticipanteID, parentesco, paterno, materno, nombre, fechanac,

ocupacion)
Personal (personalID, EspecialidadID, paterno, materno, nombres, fecha_nac,

direccion, telefono, ocupación, cargo)
Especialidad (especialidadID, tipoevaluacion, aula, horas_aula)
Recibo (ReciboID, ParticipanteID, fecha)
72
Pagos (PagoID, ReciboID, descripción, mes, a_cuenta, saldo, moneda)
3.4.2. Implementación del sistema

Se diseña los diagramas de componentes, para la identificación de módulos del
SIGASP y las relaciones entre estos.
a) Definición de los diagramas de componentes

Figura 3.20: Diagrama de componentes, inscripción de participantes
Figura 3.21: Diagrama de componentes, evaluación académica
73
Figura 3.22: Diagrama de componentes, seguimiento psicosocial
Los restantes diagramas de componentes se detallan en el ANEXO III.
b) Implementación del SIGASP

En la siguiente ventana el cliente realiza su identificación como usuario del sistema.
Dicha identificación consiste en registrar su nombre de usuario y contraseña. Si los
datos proporcionados son validos, entonces podrá ingresar al menú principal del
sistema.
Figura 3.23: Interfaz gráfica para el ingreso al sistema
74
La siguiente ventana corresponde al menú principal del sistema, en la cual se

pueden identificar los casos de uso especificados anteriormente.
Figura 3.24: Interfaz gráfica del menú principal del sistema.
La siguiente ventana corresponde a la interfaz gráfica, en la que se registran los

nuevos participantes.
Figura 3.25: Interfaz gráfica para la inscripción de participantes
75
3.5. FASE DE TRANSICIÓN
En esta fase se realizó las pruebas de la versión beta del SIGASP, las mismas se
centraran en verificar los requisitos funcionales del sistema. El primer caso de prueba
fue el control de ingreso al sistema y conexión a la base de datos, cuyo resultado se
muestra a continuación:
Figura 3.26: Prueba de ingreso al sistema
El usuario ingresa su login

y contraseña
Mensaje del sistema

que indica que hubo un
error en la conexión a la
base de datos.
Mensaje del sistema

que indica que los datos
introducidos son
incorrectos o
inexistentes.
76
La segunda prueba consiste en ingresar al formulario de inscripción y realizar la

adición de un nuevo participante, como se detalla a continuación:
Figura 3.27: Ingreso al menú del sistema y módulo de inscripción.
1. Ingresar al menú del sistema
2. Elegir la opción INSCRIPCIÓN
3. Adicionar nuevo participante
Formulario de inscripción
4. Grabar el archivo
5. Resultado de grabación
6. Registramos padre, madre o tutor
7. Generamos compromiso de estudio
77
La tercera prueba consiste en realizar el registro de calificaciones en la especialidad

de computación, los resultados son los siguientes:
Figura 3.28: Caso de prueba, evaluación académica
Formulario de evaluación académica
1. El ingreso al formulario de
evaluación académica es a
través de menú del sistema
2. A partir de esta ventana

escogemos la especialidad y
seguidamente al estudiante.
3. Presionar el siguiente botón
5. Presionar el botón
4. Registrar una nueva

evaluación y grabar.
78
3.5.1. Resultados obtenidos
Las pruebas de caja negra, permitieron corregir los errores producidos durante la
programación. Al finalizar la etapa de pruebas se pudo constatar que el sistema
desarrollado, responde satisfactoriamente a los requerimientos institucionales,
superando así, las limitaciones existentes antes de la puesta en marcha del sistema
de software. A la conclusión de dichas pruebas se ha obtenido los siguientes
resultados:
Tabla 3.6: Resultados obtenidos
MANEJO DE LA SISTEMA MANUAL SIGASP

INFORMACIÓN (ANTES) (AHORA)
Registro de formularios. Llenado de formularios Llenado dinámico de

manualmente. formularios en el cual se
pueden realizar
revisiones posteriores.
Actualización de la Realizar borrones en los Buscar el registro,

información almacenada. formularios o registrar en actualizarlo y guardarlo.
un nuevo formulario.
Búsqueda de datos. Búsquedas en fólderes y Ingreso de algunos datos

gavetas que podía tardar u opciones que puede
varios minutos. tardar no más de un
segundo.
Generación de reportes Revisar los formularios Elegir opciones y generar

académicos. académicos y generar el reporte de forma
resultados de forma automática.
manual.
Generación de Informes Búsqueda de datos en la Generación de informes

estadísticos. documentación estadísticos generales
almacenada. con inclusión de graficas.
79
Acceso a la información. Acceso libre a toda la Control de acceso a los

documentación usuarios del sistema por
académica y restringida medio de contraseña y
al área psicosocial. nombre de usuario.
Manteniendo la
confidencialidad en el
área psicosocial.
Comunicación entre Poca comunicación, lo Mayor comunicación

usuarios. cual ocasionaba entre usuarios e
redundancia de inexistencia de datos
información almacenada. duplicados.
Almacenamiento de la Documentación guardada Almacenamiento de la

información. en gavetas, lo que información en una base
representa gran volumen de datos de acceso ágil y
de información confiable.
almacenada, con un lento
acceso a la misma.
Seguridad de la Acceso libre al personal Control de acceso al

información almacenada. de la institución. personal por medio de un
nombre de inicio de
sesión y generación de
copias de seguridad por
parte del administrador
del sistema.
3.6. CALIDAD DEL SIGASP
El control de calidad del Sistema de Gestión Académica y Seguimiento Psicosocial,

se lo realizó mediante cuatro métricas de calidad, las cuales se especifican a
continuación:
3.6.1. Funcionalidad
Para el cálculo de esta métrica se hará uso de la medida de punto función.

Primero. Determinar las cinco características de dominio de información (número de
entradas de información, salidas de usuario, peticiones de usuario, archivos e
interfaces de usuario.)
80
Número de entradas de información
Datos de los usuarios

Datos de la gestión académica
Datos de los bimestres o trimestres
Datos de las especialidades
Datos de los participantes
Datos de los familiares o tutores
Datos de los participantes retirados
Datos de los pagos
Datos de la evaluación por especialidades (bimestral)
Datos de la evaluación en DPS (bimestral)
Datos de la evaluación en la materia de computación (bimestral)
Datos de la evaluación en la especialidad de computación (Trimestral)
Datos de la evaluación de los alumnos libres (un trimestre)
Datos de la ficha psicosocial de comunidad
Datos de la ficha psicosocial de programa
Datos particulares de los participantes
Datos de las consultas del seguimiento psicosocial.
Número de salidas de usuario
Reporte del formulario de inscripción

Reporte de compromiso de estudio
Recibo de pagos
Reporte de boleta de evaluación especialidades (bimestral)
Reporte de boleta de evaluación, especialidad computación (Trimestral)
Reporte boleta de evaluación, alumnos libres.
Reporte resumen de control bimestral y horas/aula y evaluación
Reporte resumen de control trimestral y horas/aula y evaluación.
Reporte resumen de control trimestral de evaluación para alumnos libres.
Reporte resumen anual de evaluación bimestral y horas/aula.
Reporte resumen anual de evaluación trimestral y horas/aula.
Reporte de ficha psicosocial de comunidad.
Reporte de ficha psicosocial de programa.
Reporte de datos generales de participante para el seguimiento psicosocial.
Reporte de datos particulares para del seguimiento psicosocial.
Reporte alumnos inscritos por gestión.
Reporte alumnos inscritos por especialidad.
Reporte alumnos retirados por especialidad.
Reporte estadístico número de hombres y mujeres inscritos.
Reporte estadístico tipo de participante (de comunidad o programa)
Reporte estadístico por edad de los participantes.
Reporte estadístico número de inscritos por especialidad.
Reporte estadístico grado de escolaridad de inscritos.
Reporte estadístico número de inscritos retirados y regulares.
Reporte estadístico número de participantes por programa de procedencia.
81
Número de peticiones de usuario
Lista de pagos realizados por el participante.

Lista de participantes de comunidad con ficha psicosocial llenada.
Lista de participantes de comunidad con ficha psicosocial no llenada.
Lista de participantes de programa con ficha psicosocial llenada.
Lista de participantes de programa con ficha psicosocial no llenada.
Lista de consultas realizadas en el seguimiento psicosocial.
Informes personalizados por sexo y edad de participantes.
Informes personalizados por sexo y grado de escolaridad de participantes.
Informes personalizados por sexo y tipo de participante de participantes.
Informes personalizados por sexo y programa de procedencia.
Número de archivos del sistema
15 Tablas en la Base de Datos

23 Formularios
30 Archivos de reportes
12 Archivos de módulos de resguardo interno
Número de interfaces externas
Disco.
Copias de seguridad.
Mensajes del sistema.
Segundo. Cálculos de punto función, es el resultado de la suma de todas las

características del sistema, halladas en el anterior punto, las mismas son
multiplicadas por un factor de ponderación medio, cuyo resultado se muestra a
continuación:
Tabla 3.7: Cálculos del punto función
FACTOR DE
PARÁMETROS DE CUENTA PONDERACIÓN TOTALES
MEDICIÓN MEDIO
Número de entradas de 17 * 4 = 68
usuario
Número de salidas de usuario 25 * 5 = 125
Número de consultas de 10 * 4 = 40
usuario
Número de archivos 80 * 10 = 800
Número de interfaces externas 3 * 7 = 21
Cuenta total 1047
82
Tabla 3.8: Ponderación para el ajuste
No influencia 0
Incidencia 1
Moderado 2
Medio 3
Significativo 4
Esencial 5
Tercero. Contestar las siguientes preguntas.
Tabla 3.9: Ajuste de complejidad
VALORES DE AJUSTE VALOR

¿Requiere el sistema copias de seguridad de recuperación
1 fiables? 5
2 ¿Se requiere comunicación de datos? 5
3 ¿Existen funciones de procesamiento distribuido? 3
4 ¿Es crítico el rendimiento? 3
¿Se ejecutará el sistema en un entorno operativo existente y
5 fuertemente utilizado? 3
6 ¿Requiere el sistema entrada de datos interactiva? 4
¿Requiere la entrada de datos interactiva y que las transacciones
de entrada se lleven a cabo sobre múltiples pantallas u
7 operaciones? 3
8 ¿Se actualizan los archivos maestros de forma interactiva? 5
¿Son complejos las entradas, las salidas, los archivos o las
9 peticiones? 4
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 conversión y la instalación? 4
¿Se ha diseñado el sistema para soportar múltiples instalaciones
13 en diferentes organizaciones? 4
¿Se ha diseñado la aplicación para facilitar los cambios y para ser
14 fácilmente utilizada por el usuario? 3
TOTAL 53
Cuarto. Reemplazar los valores hallados en la ecuación del punto función.
PF = 1047*[0.65+0.01*53]
PF = 1235.46
83
El punto función con un ajuste de complejidad máximo da:
PF_max = 1413.45
Quinto. Dividir el punto función hallado entre el punto función de complejidad

máxima.
PF/PF_max = 1235.46/1413.45 = 0.87
Con lo que se concluye que la funcionalidad es del 87% lo que significa que
el SIGASP ofrece funciones que satisfacen las necesidades especificadas.
3.6.2. Mantenibilidad
El cálculo de la facilidad de mantenimiento del sistema, se lo realizó tomando en

cuenta diez fallas de considerable magnitud, las cuales fueron analizadas,
implementadas, verificadas y distribuidas. Los datos obtenidos se detallan a
continuación:
Tabla 3.10: Resultados sobre una muestra de diez fallas.
Nº de muestra TMDF TMAC TMIC TMPC TMDC

1 20 1 3 2 1
2 15 4 5 2 2
3 10 5 4 2 1
4 10 4 3 4 1
5 14 7 4 3 2
6 12 3 5 2 1
7 14 4 3 4 1
8 14 5 7 4 1
9 14 4 5 2 2
10 10 4 5 1 1
TMC 13.3 4.1 4.4 2.6 1.3
84
Cálculo del Tiempo Medio de Cambio TMC.
TMC = TMAC + TMIC + TMPC +TMDC

11.8 = 4.1+ 4.4 + 2.6 + 1.3
El resultado de la anterior tabla muestra un promedio de doce días del Tiempo Medio
de Cambio TMC, lo que significa que el tiempo en el que se tarda en identificar un
fallo hasta implantar el cambio, tiene un costo de doce días aproximadamente.
Finalmente se halla el Tiempo Medio Entre Fallas TMEF, el cual se calcula de la

siguiente forma:
TMEF = TMDF + TMC
Remplazando datos tenemos: TMEF = 12 + 13 = 25
El resultado obtenido indica que el mantenimiento correctivo debe ser cada 25

días, desde la implantación del sistema en la institución.
3.6.3. Portabilidad
Visual Basic. Net posee herramientas con las cuales se puede crear fácilmente un
archivo instalador del sistema, mediante el cual se facilita la distribución del
programa entre las diferentes terminales de los usuarios. El programa desarrollado
SIGASP funciona bajo plataforma Windows 2000 profesional y Server, Windows ME,
Windows XP. El archivo instalador del sistema es bastante pequeño, comparado a
todos los archivos que componen el código fuente y su instalación es muy simple, ya
que no requiere de configuraciones complejas.
3.6.4. Confiabilidad
Recordando que la confiabilidad representa el tiempo que el software esta disponible

para su uso, se calculará la probabilidad de ejecución del sistema libre de fallos en
una gestión académica, para lo cual se hará uso de la función de confiabilidad dada
por:
(-λ/10* t)
F(t)= f * e
85
La funcionalidad del sistema es del 87% y t representa el tiempo que dura una
gestión académica, lambda es la probabilidad de error que pueda tener el sistema,
donde diez es el numero de ejecuciones del sistema durante un mes. Reemplazando
datos tenemos:
F(t) = 0.87 * e(-1/10*12)
0.87 * e(-1/10*12) = 0.25
Por lo tanto la probabilidad de que existan fallas en el sistema es del 25%
La probabilidad de operación del sistema libre de fallos en una gestión académica

será calculada con las siguientes expresiones.
F(t) = 1-[0.87 * e(-1/10*t)]

F(t) = 1-[0.87 * e(-1/10*12)]
Realizando las operaciones respectivas, obtenemos:
1-[0.87 * e(-1/10*12)] =0.75
La confiabilidad o inexistencia de fallas en el sistema durante una gestión

académica es del 74%
86
Sistema de Gestión Académica y Seguimiento Psicosocial Conclusiones
87
4.1 CONCLUSIONES
A partir del proceso de construcción del proyecto de software, Sistema de Gestión

Académica y Seguimiento Psicosocial, para el Centro de Capacitación Técnica
Sarantañani se hace necesario hacer referencia a las conclusiones y
recomendaciones que se generan de los resultados alcanzados en función a los
objetivos planteados.
La metodología Proceso Unificado de Rational que plantea fases (inicio, elaboración,

construcción y transición) en la realización del software, ha permitido organizar
adecuadamente el flujo de trabajo del presente proyecto en fechas y tiempos
previstos en el cronograma inicial. Es importante señalar que durante todas las
etapas de desarrollo del sistema, existió una estrecha relación entre el personal de la
institución y el desarrollador, lo cual favoreció a que el proyecto responda a las
necesidades y requerimientos del CCTS.
A continuación se establecen las conclusiones de acuerdo a cada uno de los

objetivos específicos formulados.
Se desarrolló un subsistema para el registro de participantes. El módulo de

inscripción de nuevos participantes mejora considerablemente el acceso inmediato a
los datos generales de cualquier inscrito, así también la generación de reportes
estadísticos sobre los mismos. Además elimina la redundancia de datos, que antes
existía dentro de la institución, de esta manera se reduce el costo en cuanto a la
utilización de formularios.
La construcción de un módulo para registrar el seguimiento y la evaluación

académica, permite que todas las calificaciones obtenidas por los participantes
durante la gestión académica, ahora sean almacenadas en una base de datos, con lo
cual se tendrá un ágil e inmediato acceso a los mismos, además de generar sus
88
reportes de forma instantánea en el momento que lo requieran, lo que a su vez

implica un ahorro significativo de tiempo.
El desarrollo del módulo de registro de pagos, contribuirá a controlar cada uno

de los pagos que realiza el estudiante durante la gestión académica, de esta forma
serán beneficiados los inscritos y la propia institución, ya que el sistema brindará
información actualizada y de manera oportuna.
El subsistema construido, para el seguimiento psicosocial de los adolescentes,

jóvenes y señoritas participantes, disminuye la gran cantidad de formularios
almacenados, el cual dificultaba la búsqueda y seguimiento adecuado de casos por
participante. La automatización de la administración de información, posibilita el
acceso personalizado a cada uno de los registros de los participantes, guardando
absoluta confidencialidad de la valoración psicosocial de cada estudiante, con la
utilización de códigos por el personal del área de RIBUTRA; de este modo el
seguimiento psicosocial mantiene la seguridad que requieren los psicólogos que
llevan adelante su trabajo.
La emisión de datos estadísticos de manera automática, reduce el tiempo que

representaba la elaboración manual de estos informes. La generación de reportes
personalizados de forma instantánea, son creados con la simple elección de datos
de entrada, lo cual agiliza su elaboración y principalmente se obtienen datos
confiables.
Por lo tanto, se concluye que el desarrollo del sistema de gestión académica y

seguimiento psicosocial en el Centro de Capacitación Técnica Sarantañani, ha
maximizado la eficiencia, posibilitando la reducción de tiempo y costos en la
administración de información, además de la obtención de información oportuna y
confiable.
89
4.2. RECOMENDACIONES
La seguridad e integridad de la información almacenada por el sistema dependerá en

gran parte del administrador del sistema, ya que él es el directo encargado de
asignar correctamente los controles de acceso a los usuarios y generar regularmente
las copias de seguridad de la base de datos, por otra parte, los usuarios deben estar
capacitados para la correcto manejo del sistema.
La Fundación La Paz cuenta con diferentes Programas y Proyectos sociales como el

Centro de Capacitación Técnica Sarantañani, como se podrá observar en el
organigrama del Anexo II, sería necesario que cada uno de estos Programas cuenten
con un sistema vía Web, con los registros de cada uno de los participantes dentro de
dichos Programas, a fin de que la Fundación, tenga un registro exacto y actualizado
de toda la población beneficiaria.
Realizar módulos para que todos los reportes que genera el SIGASP, puedan ser
accedidos también por medio de páginas Web, esto contribuiría a que los
participantes del Centro de Capacitación y sus padres o tutores tengan acceso
inmediato a la evaluación académica.
También se recomienda implementar sistemas de información que manejen la

información contable y la administración de activos fijos, dentro del Centro de
Capacitación Técnica Sarantañani.
A partir de la experiencia adquirida durante la construcción de este software, se cree

importante mencionar que el modelado de un proyecto de software debe estar
orientado a reducir el tiempo de trabajo manual de los usuarios, es decir, no
aumentar el trabajo que han estado realizando, caso contrario si su trabajo aumenta
o el manejo del sistema es complejo, entonces el sistema será rechazado y el
programador deberá rehacer gran parte de su proyecto, retrazando así la entrega del
mismo.
90
REFERENCIA BIBLIOGRÁFICA
[REF-B01] CCT ”S”: Memoria Institucional, 2004, Centro de Capacitación Técnica

“Sarantañani”, Área Socioeducativa Fundación La Paz, Bolivia.
[REF-B02] Senn, J; “Análisis y Diseño de Sistemas de Información”, Ed. Mac Graw-

Hill, México.1992.
[REF-B03] Pressman R.”Ingeniería del Software: Un Enfoque Practico”. 5ª Edición.

Ed. Mc Graw-Hill. México. 2001
[REF-B04] Rumbaugh James; Jacobson Ivar; Grady. Booch. “El Lenguaje Unificado
de Modelado, Manual de Referencia”. Ed. Addison Wesley. España. 1999.
[REF-B05] W. Hansen; G. Hansen; V. James. “Diseño y Administración de Bases de

Datos”. 2ª Edición. Ed. Prentice Hall. España. 1997.
[REF-B06] Larman C. “UML Y Patrones”.1ª Edición. Ed. Prentice Hall, México. 1999.
[REF-B07] Rumbaugh James; Jacobson Ivar; Booch Grady. “El Proceso Unificado de
Desarrollo de software”. Ed. Addison Wesley, España. 1999
[REF-B08] C.J. DATE. “Sistemas de Bases de Datos”. 5ª Edición. Ed. Adison Wesley.
España.
[REF-B09] Balena F. “Programando Visual Basic .Net Versión 2003”. Ed. Microsoft
Press.
91
REFERENCIAS WEB
[REF-W01] “Diseño de Bases de Datos Relacionales -- Una extensión informal de

UML”. es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x332.html.
Fecha de ingreso 10/06/06
[REF-W02] Alonso Amo. http://ls.fi.upm.es/mdp/si/metodorup.pdf. Fecha de ingreso

20/06/06.
[REF-W03] Alonso Amo: http://ls.fi.upm.es/mdp/si/introrup.pdf. Fecha de ingreso

20/06/06.
[REF-W04] “Ejemplo completo sobre la utilización del método RUP”.

www.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/index.html. Fecha de ingreso
01/07/06.
[REF-W05] José A. Mañas: “Calidad de pruebas en los sistemas de información”

www.upv.es/protel/usr/jotrofer/pascal/testing.htm. Fecha de ingreso 15/07/06.
[REF-W06] Dra. Coral Calero Muñoz. “Métricas de calidad del software”

alarcos.inf-cr.uclm.es/doc/calidadSI/Metodos%20De%20Calidad.ppt. Fecha de
ingreso 20/07/06
[REF-W07] Sistema Integrado de Gestión Académica. www.dara.es/siga/sigainf.htm.

Fecha de ingreso 20/07/06
[REF-W08] Sistema para el Control Escolar, del grupo GES de México:

http://www.grupoges.com.mx/sceover.htm. Fecha de ingreso 20/08/06
92
ANEXO I
ÁRBOL DE PROBLEMAS
ÁRBOL DE OBJETIVOS
MARCO LÓGICO
ÁRBOL DE PROBLEMAS
Fenómenos medio Inconsistencia en los La corrección y/o

Lento acceso a la
ambientales y el constante reportes e informes actualización de datos en un
información
manipuleo de la estadísticos. formulario, ocasiona el
almacenada por
documentación almacenada, llenado de un nuevo
parte del personal
ocasionan el deterioro de la formulario o realización de
y los participantes.
misma, generando perdida de enmiendas en éste.
datos.
El seguimiento y evaluación de información generada en el Centro de

Capacitación Técnica Sarantañani, es administrada de forma manual
lo que ocasiona lentitud e inconsistencia en el procesamiento y
generación de datos.
Gran cantidad de información Dificultad en la generación de El registro de los datos

almacenada y desactualizada reportes e informes estadísticos generales de los participantes
generan un inadecuado monitoreo por parte del personal de la es llenada en más de un
de los participantes del programa formulario, lo que ocasiona
institución.
RIBUTRA. redundancia en la información
almacenada.
El seguimiento de la evaluación académica Los pagos realizados por los

es registrada y evaluada de forma manual. participantes son controlados
de forma manual por el
personal.
ÁRBOL DE OBJETIVOS
Menor riesgo de Acceso a la Menor volumen en Consistencia en los Llenado dinámico

información de forma la información reportes e informes de formularios en el
pérdidas de
inmediata y sencilla almacenada y estadísticos de la cual se pueden
datos
almacenados actualizada institución. realizar revisiones
posteriores.
Desarrollar un Sistema de Gestión Académica y Seguimiento

Psicosocial, que permita obtener información rápida y
consistente, a fin de maximizar la eficiencia en la administración
de información.
Desarrollar un módulo para

generar informes estadísticos y Desarrollar un subsistema
Desarrollar un subsistema para el
reportes personalizados, sobre para el proceso de
seguimiento psicosocial de los
adolescentes, jóvenes y señoritas algunos aspectos importantes que inscripción de participantes.
se presentan durante la gestión
participantes.
académica.
Construir un módulo para el Desarrollar un módulo

seguimiento y evaluación para el registro de
académica. pagos.
MARCO LÓGICO
RESUMEN NARRATIVO INDICADORES MEDIOS DE VERIFICACION SUPUESTOS
Fin:
Implementación de sistemas de
seguimiento, evaluación y control, en • Memoria anual del área
todas las unidades pertenecientes al socioeducativa, Fundación La
Se considerara que en cinco años el Cada unidad perteneciente al área
área socioeducativo de la Fundación Paz.
25% de las unidades del área socioeducativa realiza esfuerzos
La Paz, a fin que estas automaticen • Memorias institucionales anuales
socioeducativa, cuenten con un para la implantación de un sistema
los procesos de gestión de correspondientes a cada una de
sistema de información. de información en su unidad.
información, reduzcan el volumen de las unidades del área
información almacenada y tengan socioeducativa.
accesibilidad rápida a los datos.
Propósito:
Desarrollar un Sistema de Gestión
Informe de la dirección del centro de
Académica y Seguimiento Afines del mes de octubre el
capacitación, dando validez y Se han ido realizando pruebas
Psicosocial, que permita obtener sistema estará implementado en
conformidad al desarrollo del periódicas con datos reales dentro
información rápida y consistente, a un 80% en esta institución.
fin de maximizar la eficiencia en la sistema. de la institución.
administración de información.
Componente
. Desarrollar un subsistema para El 80% del subsistema de inscripción Entrevistas al personal El personal realizó algunas pruebas
el proceso de inscripción de es entregado a fines del mes de administrativo. y se esta familiarizando con el
participantes. septiembre. Reportes de los instructores. sistema.
El 90% de este módulo fue verificado Informes por parte de los instructores Correcciones y mejorías en el
. Construir un módulo para el
y aceptado por el personal, afines del y coordinador. sistema, fruto de las
seguimiento y evaluación
mes de octubre recomendaciones por parte de los
académica
usuarios.
El 80 % de este módulo fue diseñado Entrevista al personal admistrativo.
. Desarrollar un módulo para el e implementado a fines del mes de
septiembre.
Pruebas del personal administrativo.
registro de pagos
. Desarrollar un subsistema para El 90% del módulo de seguimiento Entrevistas al personal de programa
RIBUTRA, dando fe que se esta
El personal del programa RIBUTRA
el seguimiento psicosocial de los psicosocial, está implantado a realiza verificaciones y
adolescentes, jóvenes y principios del mes de noviembre. llevando acabo la implementación del observaciones al módulo de
señoritas participantes. módulo. seguimiento psicosocial.
. Desarrollar un módulo para EL 90% del módulo de generación de Los reportes e informes pueden ser Se realizan pruebas con datos reales
generar informes estadísticos y informes estadísticos está impresos para su respectiva para comprobarlos y verificar si
reportes personalizados, sobre implementado y listo para las observación y corrección. existen errores.
algunos aspectos importantes pruebas, a principios del mes de
que se presentan durante la noviembre.
gestión académica.
. Formularios de la institución y El personal esta de acuerdo con el

Actividades 1. 4 semanas/hombre 300 $us. entrevistas al personal.
desarrollo del proyecto, el cual se
1.- Fase de inicio 2. 6 semanas/hombre 500 $us. . Manual de usuario. compromete a prestar la
colaboración respectiva para que el
2.- Fase de elaboración 3. 10 semanas/hombre 1200 $us
3.- Fase de construcción. 4. 4 semanas /hombre 300 $us.
. Manual técnico. sistema se desarrolle con total
normalidad.
4.- Fase de transición 5. 4 semanas/ hombre 200 $us . Documento del desarrollo del
sistema, siguiendo la
5.- Capacitación al personal. metodología RUP.
El tiempo total de realizar estas
Aval de la institución, confirmando
actividades es de 28 semanas,
la realización completada del
con un costo total 2500 $us.
proyecto.
ANEXO II
ORGANIGRAMA DEL ÁREA SOCIOEDUCATIVA DE LA
FUNDACIÓN LA PAZ
YANAPASIÑANI
PRODUCCION
UNIDAD DE
CONTABILIDAD
TUKUY
NINCHIS
TALLERES
CCT”S”
UNIDAD DE CAPACITACION Y FORMACION
AULA
DEPOSITO DE ALIMENTOS
LIBRE
DEPOSITO GENERAL
ADMINISTRACION
BECARIOS BECARIOS Q’HNA

MARCANDO ARU SARANTA
HUELLAS
Fuente: Memoria institucional 2004, CCTS

AYNI
BECARIOS
Indepen.
desarrollado el
ÁREA SOCIOEDUCATIVA
unidad fue
CENTRO DE Para esta
SIGASP.
CAPACITACION
TECNICA
SARANTAÑANI
JISKA
PANKARA
UNIDAD DE PROTECCION
OQHARIKUNA
OQHARIKUNA
(III ETAPA)
(II ETAPA)
SARANTAÑANI
RESIDENCIAL
JUVENIL
SARANTAÑANI SARANTAÑANI NIÑO

NIÑO DE LA CALLE
DE LA CALLE III ETAPA
SARANTAÑANI
NIÑO TAHUANTINSUYO
TRABAJADOR EL ALTO
CEDIN
I
CEDIN
V. COPACABANA
II
UNIDAD DE ATENCION
PAMPAHASI
RIBUTRA
(OF.)
V. COPACABANA
WAWAUTA
(OF.)
JILAÑATAQUI
(OF)
ANEXO III
DESSCRIPCCIÓN DE LOS CASOS DE USO EXPANDIDOS

DIAGRAMAS DE SECUENCIA
DIAGRAMAS DE ESTADO
DIAGRAMAS DE COLABORACIÓN
DIAGRAMAS DE COMPONENTES
III.1. DESCRIPCIÓN DE CASOS DE USO EXPANDIDOS
Figura III.1: Caso de uso, registro de pagos
Tabla III.1: Descripción del caso de uso, registro de pagos
Caso de uso Registro de pagos
Actores Secretaria
Propósito Registrar los pagos realizados por el participante.
Resumen Una vez inscrito el participante, debe cancelar los montos

por carnet de salud, carnet de estudiante, certificados y
salud. La secretaria registra los montos y genera el
respectivo recibo. Los estudiantes inscritos en la
especialidad de computación realizan el pago de cierto
monto mensualmente, el cual también es registrado por la
secretaria.
Referencia cruzada R2, R6

Figura III.2: Caso de uso, elaboración del calendario académico
Tabla III.2: Descripción del caso de uso, elaboración del calendario académico
Caso de uso Elaboración del calendario académico.
Actores Coordinador
Propósito Construir el calendario académico.
Resumen Al inicio de cada gestión, se debe planificar un cronograma

de trabajo para todo el año. Una gestión académica debe
estar organizado en bimestres y trimestres. El coordinador
del Centro es el principal responsable de generar dicho
calendario. Registra las fechas de inicio y finalización de
cada bimestre y trimestre.

Figura III.3: Caso de uso, registro de participantes retirados
Tabla III.3: Descripción de caso de uso, registro de participantes retirados
Caso de uso Registro de participantes de retirados
Actores Participante, Secretaria.
Propósito Registrar causas del retiro.
Resumen La secretaria busca los datos del participante que se va a

retirar en el formulario de inscripción. Una vez encontrados
dichos datos, registra en un nuevo formulario las causas del
de abandono. Vale la pena mencionar que los datos del
alumno no son borrados, si no que quedan almacenados
como historial del participante.

Figura III.4. Caso de uso, registro del formulario psicosocial
Tabla III.4: Descripción del caso de uso, registro del formulario psicosocial
Caso de uso Registro del formulario psicosocial
Actores Participante de comunidad o institución, Psicóloga.
Propósito Registro de la ficha psicosocial.
Resumen Existen dos tipos de inscritos, que son los participantes de

institución y los de comunidad. Por lo cual existen dos
distintos formularios psicosociales, los cuales son registrados
por la psicóloga de la institución, estos formularios son
importantes para la generación de reportes estadísticos, al
final de cada gestión académica.

III.2. DIAGRAMAS DE SECUENCIA
Figura III.5: Diagrama de secuencia, registro de pagos
Figura III.6: Diagrama de secuencia, registro de formulario psicosocial

III.3. DIAGRAMAS DE ESTADOS
Figura III.7: Diagrama de estado, registro de pagos
Figura III.8: Diagrama de estado, registro de formulario psicosocial
III.4. DIAGRAMAS DE COLABORACIÓN
Figura III.9: Diagrama de colaboración, registro de pagos

III.5. DIAGRAMAS DE COMPONENTES
Figura III.10: Diagrama de componente, registro de pagos
Figura III.11: Diagrama de componente, registro del formulario psicosocial

ANEXO IV
ALGUNOS DE LOS FORMULARIOS QUE GENERA EL
SISTEMA DE GESTIÓN ACADÉMICA Y SEGUIMIENTO PSICOSOCIAL
SIGASP
FORMULARIO DE INSCRIPCIÓN
COMPROMISO DE ESTUDIO
RECIBO DE PAGO
BOLETA DE EVALUACIÓN, PARA ESPECIALIDADES EVALUADAS

BIMESTRALMENTE.
RESUMEN DE CONTROL BIMESTRAL DE ASISTENCIA HORAS/AULA Y

EVALUACIÓN.
BOLETA DE EVALUACIÓN PARA LA ESPECIALIDAD DE COMPUTACIÓN
INFORME ANUAL INSCRITOS POR ESPECIALIDAD

FORMULARIO DE INSCRIPCIÓN
DATOS DEL/LA ALUMNO/A CODIGO: TMG-112980-2000-0001
TORREZ MAMANI GUSTAVO

AP. PATERNO AP. MATERNO NOMBRES
PROVINCIA MURILLO LA PAZ 11/29/1980 25 AÑOS

LUGAR DE NACIMIENTO FECHA DE NACIMIENTO EDAD
4858361 LP 456982
CARNET DE IDENTIDAD TELEFONO CELULAR
GRADO DE ESCOLARIDAD BACHILLER
CURSO TURNO NOMBRE COLEGIO
ULTIMO CURSO AÑO

DIRECCION COMPLETA VILLA SAN ANTONIO
DATOS DE LA VIVIENDA
SERVICIOS BASICOS LUZ AGUA ALCANTARILLADO
DOCUMENTOS ENTREGADOS
FORMULARIO DE INSCRIPCIÓN LIBRETA DEL ÚLTIMO
COMPROMISO DE ESTUDIO CERTIFICADO DE EGRESO
CERTIFICADO DE NACIMIENTO TITULO DE BACHILLER
CERTIFICADO DE ESTUDIO CARNET DE IDENTIDAD
OTROS DOCUMENTOS
DATOS DE LOS PADRES
MADRE MAMANI SALAZAR JUANA 56
PATERNO MATERNO NOMBRES EDAD
LUGAR DE TRABAJO
TELEFONO CELULAR
LA PAZ, Lunes, 08 de Enero de 2007
FIRMA
FIRMA FIRMA FIRMA
PADRE/MADRE/TUTOR
ALUMNO(A) SECRETARIA COORDINADOR
COMPROMISO DE ESTUDIO
PRIMERO: YO TORREZ MAMANI GUSTAVO NACIDA/O EN

PROVINCIA MURILLO EL 11/29/1980 DE 25 AÑOS DE EDAD: HIJA/O DE
MADRE : MAMANI SALAZAR JUANA
SOLICITO MI INSCRIPCIÓN EN EL CENTRO DE CAPACITACIÓN TÉCNICA SARANTAÑANI, EN LA ESPECIALIDAD
DE : CARPINTERIA
LA INSCRIPCIÓN ME DARÁ DERECHO A:

* RECIBIR LA CAPACITACIÓN POR EL PERIDO DE 1200 HORAS, DE 5 HORAS/AULA DÍA EN EL HORARIO DE 8:00
12: 30 (LUNES A VIERNES), DESDE EL 29/11/2000 HASTA EL 29/11/2000
* RECIBIR TODOS LOS MATERIALES DE APRENDIZAJE NECESARIOS PARA LA CAPACITAÓN.

* PARTICIPAR EN TODAS LAS ACTIVIDADES ORGANIZADAS POR EL C.C.T."S" Y/O LA DIRECCIÓN
EN LA CAPACITACIÓN ME COMPROMETO A:
* ASISTIR REGULAR, PUNTUAL Y OBLIGATORIAMENTE A LAS CLASES DE CAPACITACIÓN EN LOS HORARIOS
ESTABLECIDOS DE LA MAÑANA,HORARIO DE LA TARDE DE ACUERDO A REQUERIMIENTO.
* CUIDAR LAS HERRAMIENTAS Y MATERIALES DE TRABAJO QUE SE ME ASIGNEN.
* UTILIZAR DE MANERA ADECUADA LOS IMPLEMENTOS DE SEGURIDAD INDUSTRIAL, COMO TAMBIEN CUMPLIR
CON LAS NORMAS ESTABLECIDAS EN EL TALLER Y EN EL CENTRO. EL C.C.T."S" NO ASUMIRÁ
RESPONSABILIDAD EN CASO DE ACCIDENTES POR DESCUIDO O INCUMPLIMINETO DE LAS
CUMPLIR DE MANERA OBLIGATORIA LAS PASANTÍAS EN LA EMPRESA O TALLER QUE SE ME ASIGNE, LOS
MESES DE SEPTIEMBRE, OCTUBRE Y NOVIEMBRE.
SEGUNDO: YO MAMANI SALAZAR JUANA , MADRE
CON C.I: 245698 LP ME COMPROMETO Y GARANTIZO:
a) EL CUMPLIMIENTO DE LA SOLICITUD DE INSCRIPCION DE MI HIJO/A: TORREZ MAMANI

GUSTAVO
b) LA ASISTENCIA PUNTUAL DURANTE LA PRESENTE GESTIÓN DE CAPACITACIÓN
c) EN CASO DE ABANDONO DE MI GARANTIZADO/A, EN CUALQUIER MOMENTO DEL PROCESO DE SU

FORMACIÓN COMPROMETO A CANCELAR TODO EL COSTO DE LA CAPACITACIÓN HASTA EL MOMENTO
DE SU RETIRO.
DECLARAMOS NUESTRA CONFORMIDAD Y ASUMIMOS UN COMPROMISO CONJUNTO, FIRMANDO EL PRESENTE
DOCUMENTO DE COMPROMISO
INTERESADA/O
MADRE
CI: 245698 LP C.:I 4858361 LP
LA PAZ, Lunes, 8 Enero, 2007

RECIBO
APELLIDOS Y NOMBRES TORREZ MAMANI GUSTAVO CODIGO TMG-291180-2000-0001
CODIGO RECIBO REC-0003 FECHA 08/01/200
Nº DESCRIPCION MES A CUENTA SALDO
1 SALUD 25,00 0,00 Bs

2 CARNET SALUD 40,00 0,00 Bs
Total 65,00 Bs. Total Saldo 0,00 Bs.
SON: SESENTA Y CINCO 00/100 BOLIVIANOS
FIRMA CAJA SELLO CCTS

BOLETA DE EVALUACIÓN
APELLIDOS Y NOMBRES: TORREZ MAMANI GUSTAVO CODIGO: CCD-291180-2000-0001

ESPECIALIDAD: CARPINTERIA
BIMESTRE: B-I-2000 PROYECTO: LA PAZ
ÁREA DE CONOCIMIENTO
ASPECTOS EVALUADOS NUMERAL LITERAL

CAPACITACION TECNICA 75 SETENTA Y CINCO
DESARROLLO PERSONAL Y SOCIAL 10 DIEZ
COMPUTACION 3 TRES
CALIFICACION BIMESTRE 88 OCHENTA Y OCHO
COSTO BIMESTRE 500 QUINIENTOS 00/100 BOLIVIANOS
ÁREA DE RESPONSABILIDAD
ASPECTOS EVALUADOS
DIAS TRABAJADOS EN EL BIMESTRE 40
DIAS DE ASISTENCIA PUNTUAL 20
FALTAS CON LICENCIA 20
FALTAS SIN LICENCIA 0
ATRASOS 0
HORAS AULA EN EL BIMESTRE: MAÑANA 100 TARDE: 0 TOTAL 100
COORDINADOR(A) INSTRUCTOR DE LA ESPECIALIDAD PADRE/MADRE/TUTOR
NOTAS COMPLEMENTARIAS

RESUMEN DE CONTROL BIMESTRAL DE ASISTENCIA HORAS/AULA Y EVALUACION
ESPECIALIDAD CARPINTERIA GESTION ACADEMICA 2000
PERIODO DE EVALUACION B-I-2000 FECHA DE INICIO 01/08/2000 FECHA FIN 02/31/2000 DIAS TRABAJADOS 40
DATOS DEL PARTICIPANTE ASISTENCIA HORAS/AULA EVALUACIÓN
No A.P. P F. A.T. Tarde Mañana TOTAL N.C.T DPS COM N. GRAL

PATERNO MATERNO NOMBRES
1
ALANOCA CALLIZAYA ADELA 20 20 0 0 0 100 100 75 10 3 88
2 TORREZ MAMANI GUSTAVO 38 2 0 0 0 190 190 70 8 4 82
AP. ASISTENCIA PUNTUAL

P. : PERMISOS LA PAZ, Lunes, 8 Enero, 2007
F. :FALTAS
A.T. : ATRASOS
N.C.T. NOTA CAP. TECNICA
INSTRUCTOR RESPONSABLE ACADEMICO

BOLETA DE EVALUACIÓN
APELLIDOS Y NOMBRES: MORA ESTIGARRIVIA RUBEN CODIGO MER-080185-2000-0003

ESPECIALIDAD COMPUTACION PRIMER TURNO TRIMESTRE T-I-2000
AREA DE CONOCIMIENTO
ASPECTOS EVALUADOS NUMERAL LITERAL
DACTILOGRAFIA 80 OCHENTA
ENSAMBLAJE 56 CINCUENTA Y SEIS
SETENTA Y CINCO
MANTENIMIENTO 75
PROMEDIO SETENTA
70
COMPUTACION 54 CINCUENTA Y CUATRO
PROMEDIO GENERAL 62 SESENTA Y DOS
AREA DE RESPONSABILIDAD
DIAS TRABAJADOS EN EL TRIMESTRE 40

ASISTENCIA PUNTUAL 30
PERMISOS 10
FALTAS
0
ATRASOS 0
HORAS MAÑANA 60 HORAS TARDE 0 TOTAL 60
TRIMESTRE I TRIMESTRE II TRIMESTRE III
D.O.S 52 CINCUENTA Y DOS WORD 0 POWER P. 0

WINS 56 CINCUENTA Y SEIS EXCEL 0
COORDINADOR(A) INSTRUCTOR DE LA ESPECIALIDAD PADRE/MADRE/TUTOR
NOTAS COMPLEMENTARIAS

INFORME ANUAL INSCRITOS POR ESPECIALIDAD
GESTION 2000 08/01/2007
Nº DE INSCRITOS
ESPECIALIDAD
CARPINTERIA
3
COMPUTACIÓN
1
CONFECCIONES 4
MÁQUINAS HERRAMIENTAS 1
MARROQUINERIA 1
MECÁNICA AUTOMOTRIZ 0
METAL MECÁNICA 1
ANEXO V
DOCUMENTOS
AVAL DOCENTE TUTOR
AVAL DOCENTE REVISOR
AVAL CENTRO DE CAPACITACIÓN TÉCNICA

SARANTAÑANI

T1360

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

T1360

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

SISTEMA DE GESTIÓN ACADÉMICA Y SEGUIMIENTO

Trabajo realizado para el Centro de Capacitación

Postulante: Daniel Hugo Chaoca Callizaya

Para tí, madre, por brindarme tanto

Agradezco a mi familia; a mi madre, mis hermanas y hermano quienes me alientan y

Mi eterna gratitud a mi Revisora Lic. Celia Tarquino Peralta, quien me brindo su

Mi reconocimiento a los docentes de la Carrera de Informática, por los conocimientos

Agradecer al Centro de Capacitación Técnica Sarantañani, a su Director Jorge Domic

También mi más sincero agradecimiento a todos mis amigos y amigas por su

El Proyecto Sistema de Gestión Académica y Seguimiento Psicosocial SIGASP, fue

Este Centro de Capacitación realizaba la mayoría de sus actividades de gestión

La metodología adoptada para el desarrollo del software fue el Proceso Unificado de

Una vez desarrollado el software se realizaron pruebas de funcionamiento, con las

2.1. INGENIERIA DEL SOFTWARE ......................................................................... 20

3.1. CONSTRUCCIÓN DEL SOFTWARE................................................................. 50

REFERENCIA BIBLIOGRAFICA ............................................................................... 91

Figura 1.1: Organigrama del CCTS, línea intensiva ................................................... 6

Tabla 1.1: Número de participantes por año ............................................................... 7

Actualmente se vive en una época en la cual los procesos de comunicación e

Dentro del ámbito educativo, las Organizaciones No Gubernamentales (ONG’s) y sin

La necesidad de desarrollar e implementar una tecnología informática para el CCTS,

Con el propósito de dar respuesta a esta necesidad, se ha construido un Sistema de

En este sentido, el presente documento refleja el desarrollo del sistema de software

En el capítulo inicial, a fin de contextualizar la elaboración del proyecto, se hace

También se hace una reseña de los antecedentes del Centro de Capacitación

En el segundo capitulo se hace una breve definición de todas la teorías que

El capítulo tercero abarca básicamente la aplicación del Proceso Unificado de

Los sistemas de seguimiento académico tienen la finalidad de administrar toda la

SIGA, Sistema Integrado de Gestión Académica. Es un software comercial,

Control Escolar GES. Sistema comercial desarrollado por el Grupo GES, de

Dentro de la Carrera de Informática de la Universidad Mayor de San Andrés, se han

institutos técnicos, universidades públicas y privadas. También se han encontrado

Sistema de Seguimiento Psicosocial, desarrollado por Rojas Valencia Dulfredo, el

Sistema de Seguimiento Académico – Psicológico, trabajo elaborado por Laura

Seguimiento académico para el Colegio Santa Maria CENAFI, Efectuado por

Sistema de seguimiento académico ISEC. Proyecto desarrollado por Nicols Iriarte

la velocidad del proceso de datos de alumnos, reducir costo de procesamiento de

1.2.2. Antecedentes del Centro de Capacitación Técnica Sarantañani, CCTS

El Centro de Capacitación Técnica Sarantañani dependiente del Área Socioeducativa

Las actividades que se desarrollan en este Centro de Capacitación, en el área

Tabla 1.1: Número de participantes por año.

48 50 49 66 67 79 70 117 120 124 122 116 134 140 134

Fuente: Memoria institucional CCTS, 2004

otras instituciones y atención psicoterapéutica en el consultorio de Villa Copacabana

1.3. PRESENTACIÓN DEL PROBLEMA

A partir de una reflexión con el personal de la institución en cuanto a la

El registro de los datos generales de los participantes es llenada en más

El seguimiento de la evaluación académica es registrada y evaluada de

Los pagos realizados por los participantes son controlados de forma

Dificultad en la generación de reportes e informes estadísticos por parte

La gran cantidad de información almacenada y desactualizada generaban

de formularios almacenados dificultaba la búsqueda y seguimiento adecuado

Los problemas anteriormente descritos generaban otros tipos de dificultades dentro

Fenómenos medio ambientales y el constante manipuleo de la

Lento acceso a la información almacenada por parte del personal y los

La corrección y/o actualización de datos en un formulario, ocasionaba el

1.3.1. Definición del problema

A partir del análisis de las dificultades y limitaciones en cuanto al manejo de

¿El seguimiento y evaluación de información generada en el Centro de Capacitación

1.4. OBJETIVO GENERAL

Desarrollar un Sistema de Gestión Académica y Seguimiento Psicosocial, que

1.5. OBJETIVOS ESPECÍFICOS