Proyecto de Grado "Sistema de Control de Personal Y Planillas de Pago"

UNIVERSIDAD MAYOR DE SAN ANDRES
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMATICA
PROYECTO DE GRADO
“SISTEMA DE CONTROL DE PERSONAL Y
PLANILLAS DE PAGO”
PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA
MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
GOBIERNO MUNICIPAL DE VIACHA
POSTULANTE : Rogelio Rodríguez Carhuani
TUTOR : MSc. Mario Loayza Molina
REVISOR : Lic. Roberto Vargas Blacutt
LA PAZ – BOLIVIA
2009
1
DEDICATORIA
El presente trabajo va dedicado con

mucho cariño a mis padres y
hermanos por el apoyo incondicional
que me brindaron en cada momento.
2
AGRADECIMIENTOS
Ante todo a Dios, por su bendición.
Para poder realizar este proyecto de la mejor manera posible fue necesario del apoyo de muchas
personas a las cuales quiero agradecer.
A mi tutor Lic. Mario Loayza Molina por su valioso asesoramiento y apoyo para la
culminación de mi proyecto de grado. Gracias por su colaboración.
A mi revisora Lic. Roberto Vargas Blacutt a quien le debo el hecho de que este Proyecto de Grado se haya
ejecutado satisfactoriamente. Gracias por sus consejos y orientación..
A mis padres Toribio Rodriguez Mendoza y Teodora carhuani , quienes han sido un apoyo moral
y económico para lograr este fin. Gracias por su paciencia.
A mis hermanos Wilma, Jose Lui, Richard, Vanessa, Nelly por las palabras de aliento que me
brindaron y a mi hermano Raul ” en el cielo” que en vida me apoyo incondicionalmente .
A mis docentes, compañeros y amigos de la carrera.
Muchas gracias…
e-mail conan.bo@gmail.com
3
RESUMEN
La necesidad de optimizar y realizar un buen control de asistencias de manera única del

personal, del Gobierno Municipal de Viacha exige a implementar una serie de métodos;
hoy en día los Sistemas de Control de Personal, están basados en mecanismo de
identificación a partir de lectores de cinta magnética, lectores de código de barras,
lectores biométricos de huella digital y otros, la gama puede ser variada.
Un Sistema de Control de Personal debe ser capaz de interactuar con estos dispositivos
haciendo posible la interpretación de los datos para ser transformados en información útil
y confiable como ser: asistencias, tiempo de llegada y de salida, retrasos, días y horas
trabajadas.
Viendo esta necesidad se llevo a cabo este proyecto implementando un sistema

informático que permita optimizar eficazmente lo mencionado en el párrafo anterior,
utilizando elementos tecnológicos que permitan satisfacer las necesidades planteadas
como es el lector biométrico.
El proyecto de grado titulado “Sistema de Control del Personal y Planillas de Pago” ha

sido desarrollado e implementado utilizando recursos y herramientas de tecnología
informática, basándose en la metodología RUP y la guía GRAPPLE.
El producto final se desarrollo en el lenguaje de programación Visual Basic y el motor de

base de datos que se utilizo fue SQLServer 2000
4
INDICE
CAPITULO I
INTRODUCCION
1.1 INTRODUCCION………………………………………………………………………….. 2
1.2 ANTECEDENTES…………………………………………………………………………. 2
1.2.1 BASE LEGAL DE CREACIÓN DE VIACHA………………………………. 2
1.2.2 ESTRUCTURA DEL GOBIERNO MUNICIPAL DE VIACHA……………. 2
1.3 PLANTEAMIENTO DEL PROBLEMA………………………………………………….. 5
1.3.2 FORMULACION DEL PROBLEMA…………………………………………. 7
1.4 OBJETIVOS……………………………………………………………………………….. 8
1.4.1 Objetivo general……………………………………………………………… 8
1.4.2 Objetivos específicos……………………………………………………….. 8
1.5 JUSTIFICACION…………………………………………………………………………... 8
1.5.2 Justificación Técnica………………………………………………………... 8
1.5.3 Justificación Social………………………………………………………….. 9
1.5.4 Justificación Económica…………………………………………………… 9
1.6 LIMITES Y ALCANCES………………………………………………………………….. 9
1.6.1 Límites…………………………………………………………………………. 9
1.6.2 Alcances……………………………………………………………………… 9
5
CAPITULO II
MARCO DE REFERENCIA
2.2 MARCO CONCEPTUAL……………………………………………………………...... 11
2.2.1 CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A OBJETOS………. 11
2.2.2 EL LENGUAJE MODELADO UML…………………………………………. 13
2.2.3 MODELO CLIENTE – SERVIDOR………………………………………..... 22
2.2.4 BASE DE DATOS RELACIONAL………………………………………… 23
3.3 MARCO TEÓRICO………………………………………………………………………. 25
3.3.1 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE…….. 25
3.3.2 GUÍA PARA LA INGENIERÍA DE APLICACIONES RAPIDAS GRAPLLE
(GUIDELINES FOR RAPID APPLICATION ENGINEERING)……………… 26
a) Recopilación de necesidades……………………………………………… 26
b) Análisis……………………………………………………………………….. 27
c) Diseño………………………………………………………………………… 28
d) Modelo y Diseño de la Base de datos …………………………………... 28
3.3.3 REQUERIMIENTO DE SOFTWARE Y HARDWARE………………………. 29
3.3.4 IMPLEMENTACIÓN……………………………………………………………….. 29
3.3.5 PRUEBAS………………………………………………………………………….. 30
3.3.6 MANTENIMIENTO DEL SISTEMA……………………………………………... 30
3.3.7 CALIDAD DE SOFTWARE………………………………………………………... 31
6
CAPITULO III
MARCO PRÁCTICO
3.1 INTRODUCCION………………………………………………………………………… 33
3.2 RECOPILACION DE NECESIDADES………………………………………………… 33
3.3 ANALISIS………………………………………………………………………………… 36
3.3.1 Análisis del sistema actual………………………………………………….. 36
3.3.2 Análisis del nuevo sistema…………………………………………………... 40
3.4 DISEÑO…………………………………………………………………………………... 56
3.5 REQUERIMIENTO DE HARDWARE Y SOFTWARE……………………………….. 64
3.6 IMPLEMENTACION…………………………………………………………………….. 64
3.6.1 Interfaz del usuario………………………………………………………….. 65
3.7 PRUEBAS………………………………………………………………………………... 72
3.8 FACTORES DE CALIDAD ISO 9126…………………………………………………. 73
3.9 CALIDAD EL SOFTWARE……………………………………………………………... 75
CAPITULO IV
CONCLUSIONES Y RECOMENDACIONES
4.1 INTRODUCCION………………………………………………………………………… 83
4.2 Conclusiones……………………………………………………………………………... 83
4.3 Recomendaciones……………………………………………………………………….. 84
7
ANEXOS
ANEXO A
ARBOL DE PROBLEMAS………………………………………………………………….. 86
ARBOL DE OBJETIVOS……………………………………………………………………. 87
MATRIZ DEL MARCO LOGICO…………………………………………………………… 88
ANEXO B
Tabla (3.3) Actor, Responsable de la Dirección Administrativa………………………… 91
Tabla (3.4) Actor, Responsable de la Dirección Contrato........................................... 91
Tabla (3.5) Actor, Responsable de Caja………………………………........................... 92
Referencias bibliográficas…………………………………………………………………... 93
8
INDICE DE FIGURAS
Fig (3.1) identificación de actores del sistema actual……………………………………. 36
Fig (3.2) diagrama de casos de uso del sistema actual…………………………………. 38
Fig (3.3) Diagrama de actividad del sistema actual…………………………………....... 39
Fig (3.4) Definición de actores del nuevo sistema……………………………………...... 40
Fig (3.5) Diagrama de casos de uso del nuevo sistema……………………………....... 42
Fig (3.6) Diagrama de casos de uso para el paquete Recursos Humanos…………… 43
Fig (3.7) Diagrama de casos de uso para el paquete Auxiliar contable……………….. 47
Fig (3.8) Diagrama de clases………………………………………………………………... 49
Fig (3.9) Diagrama de actividades del nuevo sistema…………………………………… 51
Fig (3.10) Diagrama de secuencias: Control de vacaciones……………………………. 52
Fig (3.11) Diagrama de secuencias: Evaluación del personal………………………….. 53
Fig (3.12) Diagrama de colaboración: Registro del personal…………………………… 54
Fig (3.13) Diagrama de colaboración: Control del personal…………………………….. 54
Fig (3.14) Diagrama de colaboración: Control y asignación de comisiones……......... 55
Fig (3.15) Diagrama de colaboración: Evaluación del personal……………………....... 55
Fig (3.16) Diagrama de actividad: Registro del personal……………………………...... 56
Fig (3.17) Diagrama de actividad: Control de vacaciones………………………………. 57
Fig (3.18) Diagrama de actividad: Asignación de comisión……………………………... 58
Fig (3.19) Diagrama de componentes del sistema……………………………………….. 59
Fig (3.20) Diagrama de despliegue o de distribución del sistema…………………........ 60
Fig (3.21) Diagrama de interfaces del sistema…………………………………………… 61
9
INDICE DE TABLAS
Tabla (3.1) Actor, auxiliar contable…………………………………………………………. 37
Tabla (3.2) Actor, Responsable de Recursos Humanos………………………………… 37
Tabla (3.6) Actor, Auxiliar contable……………………………………………………….... 40
Tabla (3.7) Actor, Recursos humanos……………………………………………………… 41
Tabla (3.8) Actor, Responsable de Caja…………………………………………………... 41
Tabla (3.9) Descripción de caso de uso autenticación del usuario……………………. 44
Tabla (3.10) Descripción de caso de uso Registrar nuevo personal…………………. 44
Tabla (3.11) Descripción de caso de uso asignación y control de comisiones……….. 45
Tabla (3.12) Descripción de caso de uso asignación y control de vacaciones………... 45
Tabla (3.13) Descripción de caso de uso evaluación del personal……………………. 46
Tabla (3.14) Descripción de caso de uso modifica y elimina personal………………… 46
Tabla (3.15) Descripción de caso de uso ver reportes del personal…………………… 47
Tabla (3.16) Descripción de caso de uso generar planillas……………………………… 48
Tabla (3.17) Resumen de servicio que proporcionan los subsistemas del sistema…….63
Tabla (3,18) Procesos donde se utilizaron las pruebas………………………………….. 65
Tabla 3.19) Matriz punto función……………………………………………………………. 88
Tabla (3.20) Punto función…………………………………………………………………… 89
Tabla (4.1) Resumen de resultados obtenidos…………………………………………… 95
10
CAPITULO I
INTRODUCCION
11
1.1 INTRODUCCION
Actualmente empresas de distintos rubros y tamaños tropiezan con algunos problemas de

Gestión y Control de Personal tales como el Gobierno Municipal de Viacha,
particularmente en el tema de la asistencia y cumplimiento de horarios de trabajo, los
sistemas de control tradicionales están basados en un control manual o registro escrito.
En estos casos es probable que Recursos Humanos requiera de ciertos mecanismos de

control de asistencia. Recalcar que cada empresa es diferente y por tanto los
requerimientos de control de personal también lo son, de ahí la importancia de contar con
diversas alternativas de Sistemas de Control de Personal.
Hoy en día los Sistemas de Control de Personal, están basados en mecanismo de

identificación a partir de lectores de cinta magnética, lectores de código de barras,
lectores biométricos de huella digital y otros, la gama puede ser variada.
Un Sistema de Control de Personal debe ser capaz de interactuar con estos dispositivos
haciendo posible la interpretación de los datos para ser transformados en información útil
y confiable como ser: asistencias, tiempo de llegada y de salida, retrasos, días y horas
trabajadas.
La herramienta principal a utilizar en el proceso de desarrollo de este proyecto será UML

dentro de las directrices GRAPPLE (Guides to Rapid Application Engineering - Guías para
la Ingeniería de Aplicaciones Rápidas) que aunque no sean consideradas una
metodología como tal, si son una guía de las mejores prácticas en el desarrollo moderno
de aplicaciones.
1.2 ANTECEDENTES
1.2.1 BASE LEGAL DE CREACIÓN DE VIACHA
Viacha es considerada como la Ciudad Industrial del Departamento de La Paz

perteneciente a la Primera Sección de la PROVINCIA INGAVI, provincia del
Departamento de La Paz, aquella que en su época fue cuna de la importante civilización
Aymará.
La Provincia Ingavi, según documentos oficiales gubernamentales, fue creada mediante

Decreto Supremo del 18 de noviembre de 1842, a objeto de solemnizar la Batalla de
12
INGAVI, dicho decreto en su artículo segundo establece que su capital se trasladará al
pueblo, que en adelante se titulará Villa Viacha.
La provincia Ingavi está conformada por las siguientes secciones: Viacha, Guaqui,
Tiahuanaco, Desaguadero, San Andrés de Machaca, Jesús de Machaca y Taraco.
A través de la promulgación del 5 de diciembre de 1906, en la presidencia de Ismael

Montes, se eleva a Viacha al rango de Ciudad y en la actualidad es la sede del Gobierno
Municipal de la Primera Sección.
El Municipio de Viacha es la Primera Sección de la Provincia Ingavi del Departamento de

La Paz, ubicada al Sud-Oeste de la ciudad de La Paz a 39 Km. de distancia de la sede de
Gobierno y 20 Km de la ciudad de El Alto. La parte central del entorno Urbanístico está
asentada sobre una pendiente no muy perceptible.
Viacha se encuentra a una altitud de 3.850 m.s.n.m., siendo su situación geográfica 16°
18’ de altitud sud y 68° 28’ de longitud oeste, bordeada por el río Pallina en el extremo
sur y el riachuelo de Kellkata por el extremo norte.
1.2.2 ESTRUCTURA DEL GOBIERNO MUNICIPAL DE VIACHA
La estructura del Gobierno Municipal consta del Concejo Municipal (Nivel Legislativo) y el
Alcalde con su apoyo técnico (Nivel Ejecutivo). El relacionamiento que se pretende
conseguir y mantener entre el Consejo Municipal y el Alcalde es el de una comunicación y
coordinación permanente, logrando de esta manera que se cumplan las funciones de
fiscalización y de ejecución evitando de esta manera el posible surgimiento de conflictos
sociales internos en el Municipio.
El Municipio de Viacha se encuentra en la Categoría "C", cuyas funciones, obligaciones y

responsabilidades son similares a las Capitales de Departamento, por lo que se requiere
personal académico y especializado.
La estructura básica del Municipio de Viacha, se la ha diseñado en base a las

necesidades reales y recomendaciones de la Contraloría General de la República,
Ministerio de Hacienda, Prefectura y el Ministerio de Desarrollo Sostenible, la misma se
detalla en el siguiente Organigrama por finalidad de funciones en página anexa.
13
Estructura Organizacional – Gobierno Municipal de Viacha
CONCEJO
MUNICIPAL
ALCALDE
MUNICIPAL
SECRETARIA
GENERAL
OFICIALIA ADMINISTRATIVA OFICIALIA MAYOR OFICIALIA DE

DESARROLLO HUMANO
FINANCIERA TECNICA
SUB ALCALDIA SUB ALCALDIA SUB ALCALDIA SUB ALCALDIA

DISTRITO 1 DISTRITO 2 DISTRITO 3 DISTRITO 7
Actualmente el Gobierno Municipal de Viacha cuenta con 220 funcionarios, incluyendo al

personal que trabajo por contratos.
La Dirección de gestión de Recursos Humanos del gobierno Municipal de Viacha, está

compuesta de varias áreas de las cuales sólo se tomaran encuentra dos para este
proyecto;
Control del personal, que cumple la función de supervisar y efectuar el control

de entradas, salidas, asistencia, atrasos y permanencia en el puesto de trabajo
del personal en el municipio.
Planillas de pago, que cumple la función de elaborar y procesar planillas
conforme las normas y leyes establecidas, y elaborar boletas de pago.
El control del personal es uno de los motores principales de esta unidad, debido a que las
planillas se realizan de acuerdo a los datos registrados por este control.
14
En la carrera de informática existen proyectos de grado similares al proyecto que se
propone, las cuales han sido desarrollados en semestres anteriores tales como el”
sistema BIOMETRICO DE CONTROL DE ASISTENCIA Y PLANILLA DE PAGO” [Tola
Flores, 2007].
1.3 PLANTEAMIENTO DEL PROBLEMA
Control del personal
Actualmente el control del personal se realiza mediante planillas impresas y un marcador

mecánica de tarjetas, que en muchas ocasiones es susceptible a la alteración de la
información o a la suplantación de la identidad del funcionario, dicho de otro modo un
compañero de trabajo bien puede marcarle la tarjeta de salida o llegada a otro compañero
de trabajo, o firmar por él.
En muchos casos puede suceder que los funcionarios lleguen tarde, o simplemente se
olvidan de firmar la planilla al ingreso o marcar la tarjeta, sin embargo estos fuera del
horario de inicio o al terminar las actividades igual pueden firmar la planilla de asistencia.
Otro problema que se presenta, es que para manejar 220 funcionarios se requiere
planificar las vacaciones, lo que se complica con los permisos a cuenta vacación que
solicitan los funcionarios. Las vacaciones del personal son programados a comienzos de
gestión, es decir que cada funcionario presenta la fecha tentativa para su asignación
correspondiente siempre y cuando tenga como mínimo un año de antigüedad. Además un
personal no puede escoger la misma fecha en que saldrá el otro y no todos los
funcionarios salen la fecha indicada en su asignación de vacaciones, si no que lo pueden
hacer en cualquier momento previa autorización, sacando una boleta como cuenta
vacación ya sea un medio día, media tarde, un día o dos días lo que exige una adecuada
planificación de vacaciones de esta manera requiriendo un buen control del goce físico,
además del control de vacaciones atrasadas y pendientes.
Con respecto a la evaluación del personal que trabaja en el Gobierno Municipal de Viacha
(G.N.V.), este proceso es el más importante, pues a medida que los funcionarios van
desempeñando sus labores estos son evaluados cada cuatrimestre, a fin de ver el
rendimiento y capacidad del personal, y es un problema pues no es posible ver un
informe detallado a destiempo u oportunamente la información requerida para un pronta
toma de decisiones bajo los siguientes criterios de evaluación:
15
a) Evaluar a los servidores públicos de carrera en el desempeño de sus funciones y
registrar la productividad de los funcionarios públicos que no están sujetos a la
carrera.
b) Servir como un parámetro de otorgamiento de incentivos.
c) Proveer de información para mejorar el desempeño de la entidad en términos de
eficiencia, honestidad, efectividad y calidad en el servicio.
d) Constituir el instrumento para detectar necesidades de capacitación.
e) Identificar los casos de desempeño no satisfactorio para tomar medidas
correctivas, mismas que podrán determinar la separación de los funcionarios
públicos de carrera conforme al artículo 39 de la Ley del Estatuto de Funcionario
Público.
Como consecuencia de las evaluaciones los servidores públicos, podrán recibir

incentivos económicos y psicosociales con base en los resultados de las evaluaciones
de su desempeño que reflejen indicadores de excelencia, idoneidad, capacidad,
motivación y eficiencia. La evaluación del desempeño para los funcionarios no
comprendidos tiene carácter referencial y de registro.
 La evaluación del desempeño de los funcionarios de carrera tiene carácter

obligatorio según el artículo 27 de la Ley del Estatuto del Funcionario Público, se
realizará en forma periódica y se fundará en aspectos de igualdad de participación,
oportunidad, ecuanimidad, publicidad, transparencia, mensurabilidad y
verificabilidad.
 Los procesos de evaluación del desempeño se realizan para funcionarios.
Las fechas y bases para la evaluación del desempeño deben estar registradas
previamente en la Superintendencia del Servicio Civil y ser de conocimiento de los
servidores públicos.
 El incumplimiento de los procesos de evaluación, generará responsabilidad
administrativa a la máxima autoridad ejecutiva de la entidad.
Planillas de pago
La información obtenida del conteo mensual del registro de asistencias es enviada al
auxiliar contable para la elaboración de las planillas de pago, con la información obtenida
realiza los cálculos siguientes: descuentos por sanciones (Atrasos y Faltas) y los
descuentos por aportes (Caja Nacional de Salud, RC-IVA, AFP Futuro, AFP-BBVA,
16
Subsidios). Este proceso de cálculo demora alrededor de 5 a 8 minutos por cada
funcionario los que implica una demora aproximada de seis semanas.
Los problemas que generalmente se cometen son de transcripción de datos, es decir que
al realizar la planilla se introduce cifras en celdas del formulario que no corresponden a un
determinado funcionario.
3.2 FORMULACION DEL PROBLEMA
En base a las dificultades y deficiencias descritas anteriormente se plantea implementar

un sistema que permita agilizar la elaboración de las planillas de pago y realice un control
estricto del personal a través del uso de un lector biométrico.
Mediante diferentes consultas directas a los funcionarios de la Unidad de control del

personal y en base a las observaciones de las tareas que estos realizan, se detectaron
los siguientes problemas que conlleva a esta Unidad:
Dificultad en el intercambio de información con respecto al registro de los

funcionarios del municipio, entre la unidad de contratación y la unidad de
control de personal, ocasionando ineficiencia laboral.
No se cuenta con una adecuada organización de los informes de la evaluación
del personal, retrasando de alguna manera la asignación de nuevos puestos.
Si bien se tiene un determinado tiempo en la elaboración de planillas de pago
para el cobro respectivo de cheques, este proceso sigue siendo excesivo y
demoroso para el funcionario encargado de la elaboración de las planillas, lo
cual le cuesta por lo menos una semana subsanar este retardo.
Existe una demora en la elaboración de informes sobre las asistencias del
funcionario de la alcaldía, generando molestias y enojos al personal en el
momento en que deben justificar las salidas, el motivo del retraso en sus
actividades o en todo caso el por qué de la falta a sus funciones.
Se evidencia cierto retardo en la búsqueda de información correspondiente a
un determinado funcionario como ser el departamento en donde trabaja.
En el proceso de selección de personal se realizará la comparación del perfil
del puesto con la capacidad de los postulantes para lograr los resultados
específicos y continuos a través de: evaluación curricular, de capacidad técnica
y de cualidades personales. El cual implica un buen control de evaluación
17
4 OBJETIVOS
4.1 Objetivo general
Implementar un sistema de control de personal y planillas de pago, que pueda

mantenerse sincronizado con un lector biométrico; además con la automatización de las
planillas se mejorará la elaboración de las mismas de manera rápida y efectiva, logrando
mayor seguridad en el manejo de información y se brindará un mayor servicio al
funcionario.
4.2 Objetivos específicos
Para solucionar las necesidades de la unidad de control y asistencia del personal, se

plantean los siguientes objetivos específicos.
Eliminar errores en la generación de planillas de pago.

Analizar y diseñar una base de datos para el control del personal.
Implementar los procedimientos de registro de los funcionarios del municipio.
Implementar los procedimientos de evaluación del personal.
Implementar los procedimientos necesarios para una adecuada asignación de
vacaciones.
Optimizar el tiempo de procesamiento de datos para obtener las planillas de
pago.
Contar con un registro detallado de asistencias del personal.
5 JUSTIFICACION
5.2 Justificación Técnica
El proyecto de grado se justifica desde el puto de vista técnico porque:
Preparando y aplicando mis conocimientos y científicos adquiridos en la universidad como

es la Ingeniería del software, análisis y diseño de bases de datos, preparación y
evaluación de proyectos y lógicas de computación, para tal propósito me apoyare en la
metodología de desarrollo de software Rational Unified Process (RUP), que se caracteriza
por estar complementado por la herramienta UML (Lenguaje de Modelado Unificado)
dentro de las directrices GRAPPLE (Guides to Rapid Application Engineering - Guías para
la Ingeniería de Aplicaciones Rápidas).
18
5.3 Justificación Social
La calidad de servicio que brinde el sistema, beneficiara directamente a la comunidad del

Gobierno Municipal de Viacha, en particular al responsable de la unidad de control del
personal y el responsable de elaboración de planillas de pagos, de tal manera que
tendrán acceso a la información pertinente con mayor rapidez, eficacia y confiabilidad.
5.4 Justificación Económica
El proyecto de grado se justifica económicamente al proponer un software de aplicación

como producto final, para mejorar el procedimiento y manejo de la información el cual
reducirá el tiempo de elaboración de las planillas y un buen control del personal.
Con la optimización del tiempo de elaboración de las planillas de pago ahora el

responsable de esta área podrá disponer de su tiempo para poder realizar otras
actividades pendientes que tiene en la unidad.
6 LIMITES Y ALCANCES
6.1 Límites
El sistema se realizara para Unidad de Control y asistencia del Personal para el Municipio
de Viacha.
6.2 Alcances
Para este proyecto es necesario hacer un estudio profundo de estructura de la unidad de

control del personal de la Alcaldía de Viacha.
Registro de personal.
Control y asignación de vacaciones.
Generación de planillas de pago, aportes patronales, subsidios.
Generar un historial de asistencias del personal.
Control de evaluación del personal (evaluación curricular, de capacidad técnica
y de cualidades personales)
19
CAPITULO II
MARCO DE REFERENCIA
20
2.1 INTRODUCCIÓN
En este capítulo se hace una descripción del marco conceptual y del marco teórico
necesario para implementar el proyecto.
El marco conceptual es una serie de ideas o conceptos coherentes organizados de tal

manera que sean fáciles de comunicar a los demás sobre el desarrollo del proyecto.
El marco teórico es la etapa en que reunimos información documental para confeccionar

el diseño metodológico de la investigación, describiendo la conceptualización de las
metodologías RUP y las directrices GRAPPLE para el desarrollo del proyecto, además de
detallar cada flujo de trabajo del ciclo de vida como: recopilación de necesidades, análisis,
diseño, modelo del sistema, requerimiento de software y hardware, implementación,
pruebas, mantenimiento del sistema y calidad del software.
2.2 MARCO CONCEPTUAL
2.2.1 CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A OBJETOS
a). OBJETOS: Un objeto es la representación de una entidad sea real o conceptual. Un

objeto puede representar algo concreto (una persona, un auto, una computadora, etc.), o
un concepto (un proceso químico, una transacción bancaria, una orden de compra, etc.).
Un objeto tiene tres características:
 Estado: Representado por una colección de propiedades o atributos, por

ejemplo el objeto Curso puede estar en uno de dos estados: “Abierto” o
“Cerrado”.
 Conducta: Representa todo lo que el objeto puede hacer (Operaciones),

por ejemplo un curso disponible podría tener las operaciones:
AgregarEstudiante() y EliminarEstudiante()
 Identidad: Representa la unicidad de un objeto con respecto a otros

objetos.
b). CLASES: Una clase es una descripción de un grupo de objetos la cual consta de:
propiedades comunes (los atributos), conductas comunes(los funcionamientos),
relaciones comunes y semántica común. Así una clase es una plantilla para crear objetos.
21
Cada objeto es una instancia de alguna clase u objeto. Por ejemplo, la clase “Curso
Disponible” puede definirse con las siguientes características:
 Atributos: ubicación, horas disponibles.
 Operaciones: recuperar ubicación, recuperar horas al día, agregar

estudiante.
En UML, las clases se representan con rectángulos divididos en tres partes.
c). ENCAPSULACIÓN: En los sistemas basados en objetos, la combinación y

empaquetamiento de fragmentos de información y conducta específica en un objeto se
llama encapsulación.
Los objetos encapsulan sus operaciones y su estado.
 El comportamiento del objeto está definido por las operaciones.
 El estado está definido por los datos o atributos del objeto. La encapsulación
es un concepto de orientación a objetos que escribe la vinculación de unas
operaciones y estado a un objeto particular. La encapsulación está
íntimamente relacionada con la ocultación de la información, definiendo qué
partes de un objeto son visibles y qué partes están ocultas.
 La encapsulación abarca a la ocultación de la información:
 Algunas partes son visibles (el interfaz público)
 Otras partes son ocultas (o privadas)

d). HERENCIA: Es un mecanismo que le permite crear nuevos objetos basados en otros
creados con anterioridad como por ejemplo: un niño hereda las características de un
objeto padre. Uno de los mayores beneficios de la herencia es la facilidad de
mantenimiento. Por ejemplo: cuando algunos cambios afectan a todos los mamíferos, solo
se efectuara el cambio en el objeto padre y los objetos hijo heredaran los cambios
automáticamente. Si los mamíferos de repente se convirtieran en seres de sangre fría,
solo el objeto mamífero necesitaría ser modificado. El gato, perro, humano, ballena, y
otros hijos heredaran automáticamente la característica de seres de sangre fría.
22
e). POLIMORFISMO: Significa tener muchas formas o aplicaciones de una funcionalidad
particular. Como con la herencia, el polimorfismo puede verse en el mundo natural.
Ejemplo dada la orden o función “Hable()”, un humano puede contestar “Como esta usted”
o probablemente el mensaje sea ignorado.
En condiciones de un sistema basado en objetos, esto significa que nosotros podemos
tener muchas aplicaciones de una funcionalidad particular.
2.2.2 EL LENGUAJE MODELADO UML
Siglas de Unified Modeling Language(Lenguaje Unificado de Construcción de modelos).
UML es un lenguaje de modelado estandarizado que consiste en un conjunto de

diagramas, tiene el objetivo de colaborar a los diseñadores de productos de software en el
desarrollo de sistemas de información, realizando las siguientes tareas: especificación,
visualización, plan de la arquitectura, construcción, simulación y documentación [Larman,
1999]
UML es el estándar para el modelado orientado a objetos siendo solo un lenguaje y por lo
tanto parte de un método de desarrollo de software independiente del proceso. UML esta
compuesto por diversos elementos gráficos que se combinan para conformar diagramas,
debido a que es un lenguaje de modelado, cuenta con reglas para combinar tales
elementos. La finalidad de los diagramas es presentar diversas perspectivas en un
sistema, a los cuales se lo conoce como modelo [Jacobson, Booch y Rumbaugh, 1999]
a) SIMBOLOGÍA
Paquetes
Permiten dividir un modelo, reagrupar y encapsular los elementos de modelado y
se representa con una carpeta con nombre. Gráficamente un paquete viene
representado como se indica en la Figura:
23
Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo
que las personas puedan trabajar con una cantidad de información limitada, a la
vez y de modo que los equipos de trabajo no interfieran con el trabajo de los otros.
Los paquetes ofrecen un mecanismo general para la organización de los

modelos/subsistemas agrupando elementos de modelado. Cada paquete
corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes
son unidades de organización jerárquica de uso general de los modelos de UML.
Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión de
la configuración y la construcción de bibliotecas que contengan fragmentos
reutilizables del modelo.
Casos De Uso
Un Caso de Uso es representado por una elipse y es una descripción de la
secuencia de interacciones que se producen entre un actor y el sistema, cuando el
actor usa el sistema para llevar a cabo una tarea específica.
24
Representan la funcionalidad del sistema y los requisitos del sistema desde la
perspectiva del personal. Los objetivos de los casos de uso son los siguientes:
 Capturar los requisitos funcionales del sistema y expresarlos desde el punto

de vista del usuario.
 Guiar todo el proceso de desarrollo del sistema de información. Los casos

de uso proporcionan, por tanto, un modo claro y preciso de comunicación
entre cliente y desarrollador. Desde el punto de vista del cliente
proporcionan una visión de “caja negra” del sistema, esto es, cómo aparece
el sistema desde el exterior sin necesidad de entrar en los detalles de su
construcción. Para los desarrolladores, suponen el punto de partida y el eje
sobre el que se apoya todo el desarrollo del sistema en sus procesos de
análisis y diseño.
Actores
Un actor es una entidad externa al sistema que realiza algún tipo de interacción
con el mismo. Se representa mediante una figura humana dibujada con palotes.
Cliente
Esta representación sirve tanto para actores que son personas como para otro tipo
de actores (otros sistemas, censores, etc.).
Si se habla de personas, un actor es el papel que puede llevar a cabo en cuanto a
su forma de interactuar con el sistema, es decir, un único actor puede representar
a muchas personas diferentes y de la misma forma, un personal puede actuar
como actores diferentes.
25
Relaciones
Las relaciones pueden tener lugar entre actores y casos de uso o entre casos de
uso. La relación entre un actor y un caso de uso es una relación de comunicación,
que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta
información para la realización de un caso de uso o recibe información como
resultado de la realización del mismo, por ello, esta relación puede ser
unidireccional o bidireccional, aunque generalmente se muestra como
bidireccional, ya que no es necesario especificar en detalle estas relaciones.
Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o caso
de uso a otra operación (caso de uso). Dicha relación se denota con una flecha
simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase depende
de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha
punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de
uso (y no para actores).
Extend: Se recomienda utilizar cuando un caso de uso es similar a otro

(características). Uses: Se recomienda utilizar cuando se tiene un conjunto de
características que son similares en más de un caso de uso y no se desea
mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y
modelamiento de clases, en donde esta la duda clásica de usar o heredar. La
26
relación entre casos de uso es una relación unidireccional. Esta relación puede
presentar uno de los dos siguientes tipos: “usa” y “extiende”.
La relación “include” (incluye). Una instancia del Caso de uso origen incluye
también el comportamiento descrito por el Caso de Uso destino. «include»
reemplazó al denominado «uses», por ejemplo: si un actor realiza una interacción
con un caso de uso A, automáticamente lo hará con el caso de uso B.
La relación “extend” (extiende). Se utiliza cuando se quiere reflejar un

comportamiento opcional de un caso de uso. Por ejemplo, se tiene el caso de uso
a que representa un comportamiento habitual del sistema. Sin embargo,
dependiendo de algún factor, este caso de uso puede presentar un
comportamiento adicional o ligeramente diferente, que se podría reflejar en un
caso de uso B. En este caso, habrá una relación “extiende” del caso de uso B al A.
b) DIAGRAMAS
UML permite a las personas desarrollar diferentes tipos de diagramas visuales que
representan varios aspectos de los sistemas, cada diagrama tiene un propósito y una
intencionalidad. Object Domain apoya el desarrollo de la mayoría, de tales como:
Diagrama de caso de uso del negocio
27
Los diagramas de Caso de Uso de negocio se usan para representar la funcionalidad
proporcionada en conjunto por una organización.
Estos diagramas se usan extensivamente durante las actividades de modelado del

negocio, no solo para analizar el contexto del sistema sino también para fundamentar
el por que de la creación de los casos de uso. Estos diagramas no diferencian entre
los procesos manuales y automatizados; mientras que los Diagramas de Caso de Uso
si se enfocan en los procesos automatizados.
Diagrama de casos de uso
Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de
una aplicación o sistema y cómo se relaciona con su entorno (personals u otras
aplicaciones). Los diagramas de caso de uso hacen que se muestren las interacciones
entre los casos de uso y los actores.
Se muestra como ilustración los casos de uso de la máquina de café.
28
Diagrama de actividades
Los diagramas de actividad ilustran el flujo de funcionalidad en un sistema. Estos
diagramas definen donde empieza y donde acaba el flujo del negocio y así conocer
que actividades ocurren durante el flujo y en que orden ocurren. Sirven para
representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos
externos. Generalmente modelan los pasos de un algoritmo.
Los principales elementos que debe tener en cuenta conforme avance a través de un
flujo de trabajo:
 Las actividades son representadas por rectángulos redondeados.
 Hay un estado de arranque o “star state” que representa el inicio del flujo
de trabajo y un estado “end state” que representa el final del flujo de trabajo.
 Los puntos de decisión son representados por rombos.
29
Diagrama de secuencias
Los diagramas de secuencia se usan para mostrar el flujo de la funcionalidad a través
de un caso de uso. Un diagrama de secuencia muestra la interacción de un conjunto
de objetos en una aplicación a través del tiempo.
Esta descripción es importante porque puede dar detalle a los casos de uso,
aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el
uso de los mensajes de las clases diseñadas en el contexto de una operación.
Diagrama de colaboración
30
Un diagrama de colaboración es una forma de representar interacción entre objetos. A
diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación
(cuáles objetos son atributos, cuáles temporales,...) y ciclos en la ejecución.
Diagrama de clases
El diagrama de clases recoge las clases de objetos y sus asociaciones. En este
diagrama se representa la estructura y el comportamiento de cada uno de los objetos
del sistema y sus relaciones con los demás objetos, pero no muestra información
temporal.
Diagrama de estados
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una
aplicación, junto con los cambios que permiten pasar de un estado a otro. Mientras el
diagrama de clases muestra un cuadro estático de las clases y sus relaciones, lo
diagramas de estado se usan para modelar la conducta dinámica del sistema.
31
En un diagrama de estado encontramos dos estados especiales, el estado de
arranque “Start” y el estado de parada “Stop”. El estado de arranque es representado
por un punto negro, e indica el estado del objeto cuando es creado por primera vez. El
estado de parada es representada por un punto negro encerrado en un circulo, y
muestra el estado del objeto justo antes de que se destruya.
Diagrama de componentes
El diagrama de componentes proporciona una visión física del modelo, Muestra la
organización de los componentes software, sus interfaces y las dependencias entre
ellos.
Hay dos tipos de componentes en el diagrama: los componentes ejecutables y las
bibliotecas de código Un componente es un módulo de software que puede ser código
fuente, código binario, un ejecutable, o una librería con una interfaz definida. Una
interfaz establece las operaciones externas de un componente, las cuales determinan
una parte del comportamiento del mismo.
Además se representan las dependencias entre componentes o entre un componente
y la interfaz de otro, es decir uno de ellos usa los servicios o facilidades del otro.
32
Diagrama de despliegue
El objetivo de estos diagramas es mostrar la disposición de las particiones físicas del
sistema de información y la asignación de los componentes software a estas
particiones. Es decir, las relaciones físicas entre los componentes software y hardware
en el sistema a entregar.
2.2.3 MODELO CLIENTE – SERVIDOR
Esta arquitectura consiste básicamente en que un programa -el cliente- que realiza
peticiones a otro programa -el servidor- que le da respuesta. Aunque esta idea se puede
aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un
sistema operativo multipersonal distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los
servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la
33
centralización de la gestión de la información y la separación de responsabilidades, lo que
facilita y clarifica el diseño del sistema.
Modelo 3 capas
El modelo de 3 capas es un método que se utiliza en la ingeniería de software,

para dividir una aplicación en diferentes capas, el modelo de tres capas se divide
en: capa cliente, capa intermedia o de aplicación y capa del servidor o datos del
negocio.
El desarrollo del proyecto se realizara a través del modelo de tres capas el cual
proporcionará las siguientes ventajas.
 Separación de funciones, todo lo relacionado con la interfaz del usuario va

en una capa, las reglas de negocio en otra y el manejo de datos en una
tercera capa.
 Reutilización, el código perteneciente a una capa puede ser reutilizado,
para mejorar el modulo.
 Escalabilidad, sabiendo donde está el código correspondiente a cada capa,
pueden realizarse modificaciones dentro de una capa para mejorar o
aumentar el tamaño del sistema, con un mismo impacto en las capas
restantes.
 Faci9liodad de mantenimiento, mediante esta división, es mucho más
sencillo localizar errores en el código o efectuar mejoras.
2.2.4 BASE DE DATOS RELACIONAL
Existen varias formas de almacenar información en las computadoras, lo que genera

distintos modelos de organización de Bases de Datos: jerárquico, red, relacional y
orientado a objetos.
Los sistemas relacionales son muy importantes, por que ofrecen muchos tipos de
procesos de datos como: simplicidad y generalidad, facilidad de uso para el personal final,
periodos cortos de aprendizaje y las consultas de información se especifican de forma
sencilla.
34
Una base de datos relacional parte del "modelo relacional de base de datos", en el cual
los datos son ordenados jerárquicamente, mediante "ordenamiento de burbuja.
Una base de datos relacional es un conjunto de relaciones normalizadas. Para

representar el esquema de una base de datos relacional se debe dar el nombre de sus
relaciones, los atributos de éstas, los dominios sobre los que se definen estos atributos,
las claves primarias y las claves ajenas.
Características
Una base de datos relacional se compone de varias tablas o relaciones.

No pueden existir dos tablas con el mismo nombre.
Cada tabla es a su vez un conjunto de registros, filas o tuplas.
Cada registro representa un objeto del mundo real.
Cada una de estos registros consta de varias columnas, campos o
atributos.
No pueden existir dos columnas con el mismo nombre en una misma tabla.
Los valores almacenados en una columna deben ser del mismo tipo de
dato.
Todas las filas de una misma tabla poseen el mismo número de columnas.
No se considera el orden en que se almacenan los registros en las tablas.
No se considera el orden en que se almacenan las tablas en la base de
datos.
La información puede ser recuperada o almacenada por medio de
sentencias llamadas «consultas».
Las bases de datos relacionales pasan por un proceso al que se le conoce como
normalización, el resultado de dicho proceso es un esquema que permite que la base de
datos sea usada de manera óptima.
Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si,

el contenido de todos los registros [Stalling, 2000].
2.3 MARCO TEÓRICO
2.3.1 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
El proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo
35
de software es un conjunto de actividades necesarias para transformar los requisitos de
un personal en un sistema de Software.
El proceso Unificado no es tan sólo un proceso; es un marco de trabajo genérico que

permite especializarse para una gran variedad de sistemas software, para diferentes
áreas de aplicación, diferentes tipo de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyectos.
El proceso Unificado está basado en componentes, lo cual quiere decir que el sistema
software en construcción está formado por componentes software interconectados a
través de interfaces bien definidas.
El proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling

Lenguaje, UML) para preparar todos los esquemas de software.
El proceso Unificado se define en tres aspectos claves: Dirigido por Casos de Uso,
Centrado en la Arquitectura y es Interactivo e Incremental.
El Proceso Unificado está dirigido por Casos de Uso, quiere decir que el proceso de
desarrollo sigue un hilo, es decir, avanza a través de una serie de flujos de trabajo que
parten de los casos de uso. Los casos de uso se especifican, se diseñan y los casos de
uso finales son la fuente a partir de la cual se construyen los casos de prueba.
El Proceso Unificado está centrado en la arquitectura, quiere decir que la arquitectura, en

un sistema de software se describe mediante vistas del sistema en construcción. Incluye
también los aspectos estáticos y dinámicos más significativos del sistema, reflejados en
los casos de uso y otros factores como la plataforma en que funcionará el software,
sistema operativo, gestor de bases de datos, herramientas case y otros.
El Proceso Unificado es Iterativo e Incremental, quiere decir que el desarrollo de un

producto software comercial supone un gran esfuerzo que podría durar 6 meses o hasta
un año o más. Es práctico dividir el trabajo en partes pequeñas o sub-proyectos. Cada
sub-proyecto es una iteración que resulta en un incremento. Las iteraciones hacen
referencia a pasos en el flujo de trabajo y los incrementos al crecimiento del producto.
Estas iteraciones controladas traen muchos beneficios:
Reduce el coste del riesgo a los costes de un solo incremento.
Reduce el riego de no sacar al mercado el producto en el calendario previsto.
Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los
36
desarrolladores trabajan de manera eficiente para obtener resultados claros a
corto plazo.
Cada iteración persigue un objetivo concreto, reconoce una realidad que a

menudo se ignora.
2.3.2 GUÍA PARA LA INGENIERIA DE APLICACIONES RAPIDAS GRAPLLE

(GUIDELINES FOR RAPID APPLICATION ENGINEERING)
La guía para la ingeniería de aplicaciones rápidas es un conjunto de ideas adaptables y

flexibles, es una herramienta para el UML dentro de un contexto, y no así una férrea
metodología.
Consta de cinco segmentos, cada segmento consta de diversas acciones, cada acción
trae consigo un producto del trabajo, y cada acción es responsable de un jugador.
Se encausa a los sistemas orientados a objetos, por ello las acciones dentro de
cada segmento se orientan a crear productos de trabajo de una manera orientada
a objetos, [Schmuller, 1997]. Utiliza los siguientes segmentos:
e) Recopilación de necesidades
Consiste en la recolección de información y datos de la forma más estructurada

posible. En esta fase se establece la planificación del proyecto y su alcance. Para
esto se describe los procesos de negocio, se realiza un análisis de dominio, se
identifican los sistemas cooperativos, se describe las necesidades del sistema y se
presenta la identificación del producto. Los siguientes puntos ayudan la
recopilación de necesidades.
Descubrir los procesos de negocio.
Realizar un análisis del dominio.
Describir las necesidades del sistema.
Representación de resultados
f) Análisis
En este segmento se profundiza la información obtenida en la Recopilación de

necesidades, el análisis del sistema se relazará con los siguientes etapas:
37
Comprensión del uso del sistema, en esta etapa se describirán los actores que
iniciaran cada caso de uso del sistema, comprendiendo el uso que el personal
realizara en el sistema, los actores son los diferentes usuarios y el rol que representan
dentro del sistema.
Diagrama de casos de uso, un caso de uso representa todo lo que el personal

puede realizar dentro del sistema, en esta etapa se hace realidad los casos de uso,
realizando las secuencias de pasos para cada caso de uso. La notación es la
siguiente:
Diagrama de clases, es una colección de elementos (estáticos) declarativos de un

modelo, en esta etapa se realiza el análisis, modelo y depuración de los diagramas de
clases, se debe de llenar los nombres de las asociaciones, clases abstractas,
multiplicidades, generalizaciones y agregación.
Analizar cambios de estado en los objetos (diagrama de estados), nos

permiten describir el comportamiento de un objeto, mostrando la secuencia de estados
por la que pasa a lo largo de su vida. En esta etapa se describen todos los estados
posibles en los que puede entrar un objeto en particular.
Definir la comunicación entre objetos (diagrama de secuencia), en esta etapa

se modela los objetos y permite ilustrar las acciones de los actores y las operaciones
iniciadas por ellos. Un diagrama de secuencia representa la interacción entre las
clases, se modela para cada caso de uso.
Analizar la integración con los diagramas de colaboración, en esta etapa se

debe describir todos los detalles específicos del sistema, de ser necesario realizar los
diagramas de distribución detallada, los diagramas de colaboración permiten modelar
interacciones entre objetos en el sistema y se centra a estudiar todos los efectos de un
objeto durante un escenario.
g) Diseño
38
En este segmento se trabaja con los resultados del segmento anterior para diseñar la
solución, las tares a realizarse en esta etapa son:
Desarrollo y depuración de los diagramas de objetos, en esta etapa se

debe dar vida a los objetos mediante el análisis de cada operación y el
desarrollo de un diagrama de actividades.
Desarrollo de los diagramas de componentes, el producto de esta etapa

son el diagrama de componentes, los cuales distribuyen los elementos
físicos del sistema y sus relaciones. Muestran las opciones de realización
incluyendo código fuente, binario y ejecutable.
Planeación de la distribución, en esta etapa se desarrolla los diagramas

de distribución los cuales muestran un despliegue de nodos (locales y
remotos), en la organización del sistema, mostrando el lugar donde se
encuentran los componentes.
Diseño y prototipos de la interfaz del sistema, en esta etapa se diseñan

las interfaces con que contara el producto final del proyecto.
h) Modelo y Diseño de la Base de datos
Los sistemas pueden dividirse en pequeños componentes o subsistemas, los cuales

colaboran y ayudan a comprender mejor el sistema general.
Para el diseño de Base de Datos se utiliza la técnica de conversión al modelo

Entidad/Relación, tomando la información de los diagramas de clases.
2.3.3 REQUERIMIENTO DE SOFTWARE Y HARDWARE
Para el desarrollo del siguiente proyecto se utilizaran, un conjunto de herramientas de

software y hardware, de manera que esta herramientas coadyuven en le desarrollo del
sistema en sus diferentes etapas, se hará uso de herramientas case, como Rational
Rose para el diseño del sistema y el entrono de desarrollo Visual Basic 2005 y
SqlServer 2000, para la programación del software y otras herramientas que se
describen en el siguiente capítulo de este documento.
3.3.4 IMPLEMENTACIÓN
39
Para realizar la implementación se debe agrupar todos los elementos que intervienen
en el desarrollo del sistema, incluyendo el manual del sistema, archivos de
configuración, archivos de datos, componentes de software, etc.
El manual del sistema tiene la finalidad de proporcionar la información del sistema, a

nivel de análisis de manera que permita realizar los cambios, codificaciones y
eliminaciones.
La implementación es una colección de componentes y elementos del software, estos

componentes incluyen: ficheros ejecutable, ficheros de código fuente, y otros
necesarios para la implementación y despliegue del sistema,
En esta sección se realizara las siguientes tareas:
Generación de código.
Verificación de código.
Generación de interfaces del personal.
Manual de personal.
3.3.5 PRUEBAS
Las pruebas de software, es un proceso usado para identificar posibles fallas de

implementación, calidad o usabilidad del sistema. El objetivo de las pruebas es
encontrar el mayor número de posibles errores con una cantidad razonable de esfuerzo
realizado, aplicando sobre un determinado tiempo realista [Pressman, 2002].
En el presente proyecto se utilizaran las pruebas de estrategia del modelo espiral, por
su flexibilidad y por el máximo número de pruebas a realizar en el desarrollo del
prototipado.
Fases del modelo espiral
Planteamiento de objetivos.
40
Identificación y reducción de riesgos.
Desarrollo y validación.
Planeación.
3.3.6.- MANTENIMIENTO DEL SISTEMA
El mantenimiento de software es una de las actividades más comunes en la ingeniería de

Software y es el proceso de mejora y optimización del software desplegado (es decir;
revisión del programa), así como también corrección de los defectos.
Tipos de mantenimiento
A continuación se señalan los tipos de mantenimientos existentes:
Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de
los sistemas en cualquiera de sus aspectos: reestructuración del código,
definición más clara del sistema y optimización del rendimiento y eficiencia.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias
en un producto software para cubrir la expansión o cambio en las necesidades
del personal.
Adaptativo: son las modificaciones que afectan a los entornos en los que el
sistema opera, por ejemplo, cambios de configuración del hardware, software
de base, gestores de base de datos, comunicaciones, etc.
Correctivo: son aquellos cambios precisos para corregir errores del producto
software.
3.3.7.- CALIDAD DE SOFTWARE
La calidad de software es asegurar que los requerimientos del diseño estén satisfechos y
que el producto resultante cumpla los estándares funcionales y los requisitos funcionales.
Factores de calidad
Portabilidad, facilidad de transportar productos de software a varios ambientes de

hardware. Se mide probando el sistema en varios sistemas operativos.
41
Performance, es el desempeño con respecto al rendimiento de la computadora, un
sistema operativo o un programa. La evaluación se hace utilizando datos reprueba
o reales, de manera de verificar el rendimiento y los resultados del sistema.
Confiabilidad, es la certeza de que un componente, equipo o producto software

realiza su función prevista si incidentes por un periodo de tiempo. Para determinar la
confiabilidad de cualquier sistema es necesario definir, la función del sistema al igual
que las situaciones o condiciones que hacen perder la funcionalidad del sistema.
Funcionalidad, se refiere a representar la forma en que un componente, un dispositivo

o un equipo funciona; es decir, los mecanismos o secuencias de eventos que hacen
que el objeto realice cierta función.
La métrica del punto función, es un método para medir el tamaño del software.
Pretende medir la funcionalidad entregada al personal independientemente de la
tecnología utilizada para la construcción y explotación del software.
42
CAPITULO III
DESARROLLO DEL SISTEMA
43
3.1 INTRODUCCION
Este capítulo se enmarca en el flujo de trabajo fundamental, donde se especifican los

requerimientos del producto, desarrollo, construcción, implementación, pruebas,
actividades de mantenimiento y métricas del sistema.
3.2 RECOPILACION DE NECESIDADES
Se requiere optimizar el proceso de elaboración de las planillas de pago para que el

funcionario encargado de esta unidad lo pueda realizar en menor tiempo y sin riesgo de
errores que se iban cometiendo, como por ejemplo un mal cálculo en los descuentos que
efectúa para los aportes de cada funcionario, es decir se le pudo haber hecho un
descuento por motivo de RCIVA a un funcionario que no corresponde.
R.R.H.H proporciona una planilla de asistencia a la Dirección Financiera (Unidad

contable), para la elaboración de planillas de pago, para el personal de planta planilla de
sueldos y para el personal que trabajo por contratos o consultorías planilla de salarios.
Las planillas de pago son remitidas de la Dirección Financiera hacia R.R.H.H. para que
cada funcionario recoja su boleta, previa presentación de un informe de actividades
mensuales , luego de recoger las boletas se dirigen a caja para el cobro de su sueldo. En
caso de contratos la Dirección Financiera emite los cheques.
Los permisos por motivo de salud y cuenta vacación son registrados en R.R.H.H con 24
hrs. de anticipación, en caso de problemas de salud si el funcionario no pudo solicitar su
permiso de salida; este puede regularizar su falta presentando el comprobante de baja
médica de la Caja Nacional de Salud.
Las comisiones son registradas en un libro de actas donde se detalla la hora de salida,
retorno, destino y quien autoriza, el sistema propuesto tendrá un modulo que permita el
registro de las horas de entrada y salidas de comisión que será supervisado por el
encargado de R.R.H.H
44
Descubrir los procesos de negocio
A continuación se descubren los cargos del personal encargado del control y elaboración
de planillas de pago.
Auxiliar contable, es el encargado de la elaboración de planillas de pago

realizando una tarea minuciosa, con los atrasos, faltas y aportes para luego
efectuar el descuento según el reglamento interno del Gobierno.
Recursos Humanos, es el encargado del control de todo el personal, también se
encarga de las evaluaciones del personal, control de las vacaciones y permisos.
Responsable de dirección administrativa, se encarga de la cotización y
presupuesto del nuevo personal según el cargo o requerimiento del G.M.V.
Personal de caja, se encarga de la emisión de cheques.
Responsable de contratos, realizan los contratos de personal que no son de
planta, a solicitud de los distintos departamentos según el trabajo a realizar.
Realizar un análisis del dominio
Descripción de actividades de la unidad de control del personal en la Alcaldía de Viacha.
Las principales operaciones y funciones que desempeña la unidad de control de personal

se detalla a continuación.
Registro, cuando un nuevo personal es contratado, se registran todos sus datos

personales en un acta de contratos o acta de personal de planta.
Elaboración de las planillas de pago, la unidad contable realiza una planilla de
sueldos con los datos que proporciona la unidad de control, realiza una tarea
minuciosa en el cálculo de los descuentos que se realiza al personal ya sea por
sanciones (Atrasos y Faltas) o los descuentos por aportes (Caja Nacional de
Salud, RC-IVA, AFP Futuro, AFP-BBVA, Subsidios).
Elaboración de boletas de salidas a comisión, recursos humano realiza las
boletas de salida cuando un personal es asignado a una comisión, también
elabora las boletas de cuenta vacación y permisos.
Control manual y marcador mecánico, el personal marca su hora de entrada y
hora de salida en un reloj digital, a la vez firma una planillas de asistencia, para la
elaboración de las planillas de pago.
45
Describir las necesidades del sistema
Luego del estudio preliminar, se identifico demora en la elaboración de planillas de pago y

la información que brinda la unidad de control es poco fiable, esto porque no se cuenta
con un sistema de información que automatice los procesos y manejo de la información,
por ello se propone un sistema de control de personal y planillas de pago que mejore los
proceso que se realizan actualmente.
Identificación del producto
El software tiene como nombre Sistema de Control de Personal y Planillas de Pago.
¿Qué hará el sistema?
El sistema a desarrollarse tendrá los módulos de: registro de personal, generación de

planillas de pago, evaluación del personal, control de vacaciones.
El sistema procesara automáticamente los cálculos monetarios necesarios para la

elaboración de las planillas como ser los descuentos al personal (Atrasos, Faltas, Aportes
a la Caja Nacional de Salud, RC-IVA, AFP Futuro, AFP-BBVA, Subsidios).
Beneficios
Este producto software ayudara en las actividades básicas de la unidad e control y

recursos humanos, ayudará en el almacenamiento correcto de los datos del personal, a
demás de brindar información periódica y correcta de cada proceso.
3 .3 ANALISIS
3.3.1 Análisis del sistema actual
Para obtener una visión completa de cómo se ejecuta el trabajo, es necesario realizar una
descripción de cada uno de los procesos que se realiza en la unidad de control del
personal, del Gobierno Municipal de Viacha.
Compresión del uso del sistema
La siguiente figura muestra los actores que intervienen en el actual sistema de la unidad
de control del personal.
46
Fig (3.1) identificación de actores del sistema actual
Una de las técnicas utilizadas para recopilar la información acerca del funcionamiento de
la unidad de control, fue la entrevista, la cual proporciono información cualitativa, cabe
mencionar que sólo se entrevisto al personal que utilizara el sistema.
A continuación se detalla el funcionamiento, con las entrevistas realizadas. El resto del

detalle se encuentra el anexo B.
Descripción: Es el encargado de la parte contable realizando las siguientes

funciones:
Elaborar las planillas de pago

Realizar descuentos de acuerdo a datos de la asistencia
Brinda información general del estado actual del personal, a respecto de sus
aportes.
Todas estas tareas son realizadas manualmente con la ayuda de la hoja de
cálculo Excel.
Tabla (3.1) Actor, auxiliar contable
47
Descripción: Es el encargado del manejo y control del personal, realizando las
siguiente funciones.
Coordina y supervisa las labores del personal con las demás unidades.
Mantiene informado al personal de las actividades y disposiciones del
municipio.
Administra reportes del personal.
Realiza el registro de nuevo personal.
Extiende permisos y boletas de salida.
Regulariza las faltas y atrasos con descargos.
Realiza las evaluaciones por cada departamento u oficialía.
Controla las vacaciones del personal.
Tabla (3.2) Actor, Responsable de Recursos Humanos
48
Diagrama de casos de uso del sistema actual
Fig (3.2) diagrama de casos de uso del sistema actual
Elaboración de los cambios de estado del objeto
Los diagramas de actividades nos muestran como se ejecuta el trabajo, proporcionando

una descripción de los actos que se realizan en la unidad e control.
49
Diagrama de actividad relacionado con el sistema actual.
Fig (3.3) Diagrama de actividad del sistema actual
El sistema manual que se lleva a cabo, es para proporcionar información a Recursos

Humanos en la unidad de control de personal, al auxiliar contable de la unidad de
contabilidad, para que lleven un control de asistencia, atrasos y facilitar la elaboración de
las planillas de pago, como también las evaluaciones del personal.
Para hacer las consultas y reportes deben acudir a la base de datos que tienen en Excel
el cual se realiza con demoras pues no es fácil identificar el campo del personal a buscar,
para dicho reporte.
El estudio realizado revela que los datos deben estar al alcance del personal para atender
los requerimientos de información de manera rápida y confiable.
50
3.3.2 Análisis del nuevo sistema
Compresión del uso del sistema
Como una primera aproximación identificaremos a los actores que intervienen con el
sistema.
Responsable
de RRHH
Caja
Sistema de control
actual GMV.
Auxiliar contable
Responsable de
dirección administrativa
Responsable de
contratación
Fig (3.4) Definición de actores del nuevo sistema
Se definen los actores y roles que desempeñan en el sistema: Los actores en la

descripción de requisitos son: Recursos humanos y Auxiliar contable.
Descripción: Realiza las planillas de pago y los reportes de aportes que tiene el
personal.
Caso de Uso
Ver reporte de los aportes, las faltas y atrasos del personal.
Elaborar planillas.
Tabla (3.6) Actor, Responsable Auxiliar contable
51
Descripción: Se encarga de registrar al nuevo personal, lleva el control de
entrada/salida de los mismos, genera reportes y permisos.
Caso de Uso:
Autenticación del personal Recursos Humanos
Registro de nuevo personal.
Asignar vacaciones.
Actualizar y ajustar las salidas de comisiones.
Preparar las evaluaciones.
Permisos y comisión.
Modifica, elimina personal.
Tabla (3.7) Actor, Responsable Recursos humanos
Descripción: Se encarga de verificar al personal que lleva acabo el cobro deche o

efectivo.
Caso de Uso:
Autenticación del Responsable de caja
Verificación del personal
Tabla (3.8) Actor, Responsable de Caja
52
Diagramas de casos de uso del nuevo sistema
El diagrama de casos de uso muestra la información general del sistema. A continuación

se muestra el modelo de casos de uso general identificado, en el cual se observa las
interacciones que hay entre un actor y un caso de uso.
Fig (3.5) Diagrama de casos de uso del nuevo sistema
53
Fig (3.6) Diagrama de casos de uso para el paquete Recursos Humanos
54
A continuación se procede a describir la funcionalidad de los diagramas de caso de uso
presentados, para ello se emplea la ficha de descripción.
Nombre de caso de uso: “Autenticación de personal”.
Actor: Personal (Recursos Humanos), personal (Auxiliar contable), personal

(Responsable caja).
Flujo de eventos
Eventos del actor Eventos del sistema
1. El personal ingresa su nombre de 3. El sistema muestra la interfaz

usuario y login. grafica de la pantalla principal.
2. El personal autenticado realiza las

opciones que el sistema le nuestra.
Precondiciones: El usuario debe estar registrado
Postcondiciones: El usuario es reconocido por la aplicación
Tabla (3.9) Descripción de caso de uso autenticación del usuario
Nombre de caso de uso: “Registrar nuevo personal”.
Actor: Personal (Recursos Humanos).
Flujo de eventos
1. El responsable de Recursos 3. El sistema muestra la interfaz

Humanos adiciona un nuevo grafica que le permite realizar el
personal. registro del nuevo personal
2. El responsable de RRHH elige la 4. El sistema registra al personal

opción de guardar
Precondiciones: Validar el nuevo personal
Postcondiciones:
Tabla (3.10) Descripción de caso de uso Registrar nuevo personal
55
Nombre de caso de uso: “Asignación y control de comisiones”.
Flujo de eventos
1. El responsable de Recursos 4. El sistema muestra la interfaz

Humanos elige la opción de grafica que le permite realizar la
asignación de comisiones y asignación de comisiones y registra
adiciona el destino, quien autoriza y al personal, la hora de salida, y la
observaciones. fecha
5. El sistema almacena los datos
2. El responsable de RRHH elige la

opción de guardar
6. El sistema almacena la hora de
3. El responsable de RRHH elige la retorno del personal
opción de actualizar
Precondiciones: El personal debe existir en la base de datos
Postcondiciones: Registrar la horas de salidas y llegadas de las comisiones
Tabla (3.11) Descripción de caso de uso asignación y control de comisiones
Nombre de caso de uso: “Asignación y control de vacaciones”.
Flujo de eventos
1. El responsable de RRHH elige la 5. El sistema muestra la interfaz

opción de asignación de vacaciones grafica que le permite realizar la
asignación de comisiones
6. El sistema almacena las fechas y

2. El responsable de Recursos realiza una organización y selección
Humanos adiciona las fechas del personal que debe gozar de su
tentativas de salidas de vacaciones vacación si choque de fechas
del personal.
7. El sistema muestra la información
3. El responsable de RRHH elige la del personal, la función que
opción de ver al personal que saldrá desempeña y a la unidad que
56
de vacaciones corresponde
4. El responsable de RRHH emite el

memorándum correspondiente
Postcondiciones: Planificar vacación
Tabla (3.12) Descripción de caso de uso asignación y control de vacaciones
Nombre de caso de uso: “Evaluación del personal”.
Flujo de eventos

opción de evaluar personal grafica que le permite realizar el
registro del control de evaluación
del personal
2. El responsable de RRHH elige la 5. El sistema muestra el test
opción de ver resultados de la correspondiente según (evaluación
evaluación curricular, de capacidad técnica y
de cualidades personales)
6. El sistema muestra la información

3. El responsable de RRHH emite el del personal, junto con la
memo correspondiente al personal puntuación obtenida
Postcondiciones: Evaluar personal
Tabla (3.13) Descripción de caso de uso evaluación del personal
57
Nombre de caso de uso: “Modifica y elimina personal”.
Flujo de eventos

opción de modificar personal grafica que le permite realizar la
modificación y eliminación del
2. El responsable de RRHH elige al personal
opción de eliminar
4. El sistema realiza las
modificaciones introducidas
Postcondiciones: Modificar personal
Tabla (3.14) Descripción de caso de uso modifica y elimina personal
Fig (3.7) Diagrama de casos de uso para el paquete Auxiliar contable
58
A continuación se procede a describir la funcionalidad de los diagramas de caso de uso
presentados en el paquete Personal (Auxiliar contable).
Nombre de caso de uso: “Ver reporte general del personal”.
Actor: Personal (Auxiliar contable).
Flujo de eventos
1. El personal ingresa su nombre de 4. El sistema muestra la interfaz

usuario y login grafica que le permite realizar el
reporte de planillas e imprimir las
planillas
2. El auxiliar contable elige la opción 5. El sistema despliega la información
de reportes e imprimir planillas
3. El auxiliar contable elige al opción

de salir
Postcondiciones: Mostrar reporte
Tabla (3.15) Descripción de caso de uso ver reportes del personal
Nombre de caso de uso: “Generar Planillas”.
Actor: Personal (Auxiliar contable).
Flujo de eventos
1. El auxiliar contable elige la opción 2. El sistema muestra la interfaz

imprimir planillas grafica que le permite realizar el
reporte de planillas e imprimir las
planillas
Postcondiciones: Generar Planilla
Tabla (3.16) Descripción de caso de uso generar planillas
59
Elaboración de los diagramas de clases
Cada clase se definirá mediante un fichero de cabecera propio y otro fichero con la
definición de sus métodos.
Diagrama de clases del sistema el cual contiene los datos suficientes para realizar el
desarrollo.
Fig (3.8) Diagrama de clases
60
Modelo y diseño de la base de datos
El producto software a desarrollarse requiere el proceso de conversión de la base de

datos, por la utilización del método orientado a objetos (RUP) y el uso de un gestor de
base de datos SqlServer 2000. A continuación describiremos el diagrama entidad relación
del sistema.
61
Elaboración de los cambios de estado de objetos
Los diagramas de actividad son en esencia diagramas de flujo, con algunos elementos
adicionales que nos, permiten expresar conceptos como la concurrencia y la división del
trabajo [Elizondo, 2005].
Los diagramas de actividades nos indican cómo se ejecuta el trabajo, proporcionando una
descripción detallada de cada uno de los actos que realiza la unidad de control del
personal de Recursos Humanos en el GMV.
Fig (3.9) Diagrama de actividades del nuevo sistema
62
Definición de la comunicación entre objetos.
En esta fase se elaboran los diagramas de secuencia.
Un diagrama de secuencia contribuye a la descripción de la dinámica del sistema en

términos de interacción de objetos.
A continuación se muestran escenarios para cada caso de uso identificado
Diagrama de secuencia Control de Vacaciones
Fig (3.10) Diagrama de secuencias: Control de vacaciones
63
Diagrama de secuencia evaluación del personal
Fig (3.11) Diagrama de secuencias: Evaluación del personal
Análisis e integración de los diagramas de colaboración
En esta fase haremos uso de los diagramas de colaboración los cuales nos permiten
modelar interacciones entre objetos.
64
Diagrama de colaboración de registro de personal
:Guarda datos
Registrar nuevo usuario Ingresa nuevos datos
Introduce usuario y contraceña

Verifica los datos
del nuevo usuario
Modifica datos
: Ventana de registro
: Unidad de sesion : Actualiza registro
de nuevo personal
RR.HH.
Muestra datos registrados Muesta opción registrar o cancelar operación
: Confirmar registro
Fig (3.12) Diagrama de colaboración: Registro del personal
Diagrama de colaboración de control de vacaciones
Fig (3.13) Diagrama de colaboración: Control del personal
65
Diagrama de colaboración de control y asignación de comisión
Fig (3.14) Diagrama de colaboración: Control y asignación de comisiones
Diagrama de colaboración de evaluación del personal
Fig (3.15) Diagrama de colaboración: Evaluación del personal
66
3.4 DISEÑO
Desarrollo y depuración de los diagramas de objeto
Para resolver el problema y construir una solución se aplica la estrategia de alto nivel, el
cual nos permite generar los diagramas de actividades, los cuales funcionarán como base
para el desarrollo del sistema.
A continuación veremos los diagramas de actividades correspondientes al caso de estudio

registro de nuevo personal.
Fig (3.16) Diagrama de actividad: Registro del personal
67
Fig (3.17) Diagrama de actividad: Control de vacaciones
68
Diagrama de actividad para
asignación de comisiones
Inicio Solicitud de datos

del nuevo usuario
Comprobación
de existencia del usuario
Existe No existe
Fin
Asignar destino
de comisión
Recabar datos
específicos del usuario
Ver si los datos

son correctos
Si No
Almacenar Información
información incorrecta
Fin
Fig (3.18) Diagrama de actividad: Asignación de comisión
69
Desarrollo de los diagramas de componentes
Los diagramas de componentes proporcionan una visión física de la construcción del

sistema, muestra la organización de los componentes software y las dependencias entre
ellos.
Diagrama de componentes
Fig (3.19) Diagrama de componentes del sistema
70
Planeación de la distribución
En el diagrama de distribución se diseña la parte lógica y física del sistema, donde

interactúan los componentes y hardware del sistema.
Diagrama de despliegue o distribución del sistema
Fig (3.20) Diagrama de despliegue o de distribución del sistema
71
Diseño y Prototipo de la interfaz del usuario
Según la metodología mostrada, el modelo de distribución modela el aspecto estático y

dinámico de la presentación de un sistema.
A continuación veremos el diagrama de interfaces.
Diagrama de interfaces
Fig (3.21) Diagrama de interfaces del sistema
72
Un subsistema es un entorno operativo único y predefinido a través del cual el sistema
coordina el flujo de trabajo y la utilización de recursos, cada subsistema proporciona una o
más interfaces con el objeto de ser lo independiente posible del resto de los subsistemas,
a continuación se describe la funcionalidad de los subsistemas.
El subsistema control de personal, se utiliza para actualizar las asistencias del

personal, regularizar las hojas de salidas que el personal debe presentar parta que
en la base de datos no figure como falta o abandono.
El subsistema formulario principal, soporta toda la funcionalidad del sistema,
acogiendo a los demás subsistemas.
El subsistema reporte, proporciona reportes de manera rápida y confiable sobre
el manejo de la información en el sistema.
El subsistema registro nuevo personal, se utiliza para registrar los datos del
personal nuevos que llegan a trabajar en el GNV.
El subsistema planillas de pago, se usa para generar las respectivas planillas de
pago del personal este módulo está directamente relacionado con el módulo
control del personal.
El subsistema vacaciones, se utiliza para ve que personal puede tener
vacaciones y al ves otorgar dicha vacación,
El subsistema evaluación del personal, se utiliza para poder evaluar al personal
generando preguntas de selección.
El subsistema asignación de comisión, se encarga de asignar las comisiones al
personal que trabajan fuera de la alcaldía.
La presente tabla muestra un resumen de los servicios que proporcionan cada subsistema
por medio de las operaciones que especifican las interfaces y los elementos sobre los que
actúan.
73
Subsistema Operación Elemento
Autenticación de Identificación de personal Personal (RR.HH.),

personal Personal (Auxiliar de
contabilidad).
Formulario principal Acceso a todas las funciones Personal (RR.HH.),

activadas de acuerdo a los Personal (Auxiliar de
privilegios asignado a cada contabilidad).
personal
Registrar nuevo Nuevo Personal (RR.HH.).

personal
Eliminar
Modificar
Grabar
Cancelar
Reportes Historial del personal Personal (RR.HH.),

Personal (Auxiliar de
Reporte de asistencias contabilidad).
Reporte de comisiones
Reporte de aportes
Control del personal Registrar hora de Personal (RR.HH.).

entrada/salida
Registrar faltas y abandonos
Asignación de Proceso de asignación de Personal (RR.HH.).

comisiones comisión
Asignación de Proceso de asignación de Personal (RR.HH.).

vacaciones vacaciones
Evaluación del Proceso de evaluación del Personal (RR.HH.).

personal personal
Planillas de pago Proceso de generación de Personal (Auxiliar de

planillas de pago contabilidad).
Tabla (3.17) Resumen de servicio que proporcionan los subsistemas del sistema
74
3.5 REQUERIMIENTO DE HARDWARE Y SOFTWARE
Para el desarrollo del siguiente proyecto, se hará uso del siguiente requerimiento.
Requerimiento de software.
Sistema operativo Windows 98, 2000, XP.
Entrono de desarrollo Visual Basic 2005
Base de datos SqlServer 2000.
Requerimiento de hardware:
Para las áreas de la unidad de control del personal de recursos humanos se requiere
las siguientes características mínimas de hardware.
Procesador P-III o superior
Memoria RAM de 64 MB o superior.
Bus ISA o PCI.
Disco duro de 1GB.
Monitor VGA color.
3.6 IMPLEMENTACION
En esta etapa se establece todo los elementos necesarios para ensamblar y hacer
disponible el sistema físico, el manual de personal, archivos de configuración, archivos de
datos, componentes de software.
3.6.1 Interfaz del usuario
En esta sección se muestran todos los procesos entre ordenador y personal, a demás de
exponer las necesidades y características del sistema como zonas de selección, íconos y
botones.
El sistema presenta un entorno gráfico amigable, fácil de usar, brindando los contenidos
textuales y gráficos
75
INTERFAS DEL USUARIO
Ventana de control de acceso al sistema
Donde se debe indicar:
Login: palabra que identifica a cada usuario
Password: palabra clave de cada usuario.
Una vez autenticado el usuario se despliega la siguiente ventana del menú principal.
76
DESCRIPCION DEL MENU PRINCIPAL
Configuración.- Es la opción que permite realizar el registro de parámetros

generales de la Institución.
Personal.- opción que permite realizar el registro de los datos personales del
funcionario.
Item,- El Item salarial permite estructurar las planillas salariales de los
funcionarios.
Planillas.- Permite realizar el registro de información de cada funcionario con
respecto al control de asistencia, descuentos, aportes patronales, aguinaldos, RC-
IVA y aportes patronales.
Control de vacaciones.- Permite planificar y procesar el tiempo de vacaciones.
Subsidios.- Esta opción permite registrar al personal que recibe los beneficios por
concepto de maternidad y mortalidad según sea el tipo: Lactancia, prenatal y
sepelio.
Reportes
Opciones a las que se puede acceder con el mouse.
Adicionar Modificar. Eliminar. Grabar. Cancelar o volver. Imprimir. Salir.
PARAMETROS GENERALES
Esta opción permite registrar las características de la institución, es decir que permite
ingresar información particular de la Empresa, que estas serán utilizadas como
información base, para el procesamiento de los datos de las planillas para así poder
obtener las planillas de pago.
77
Periodo. Mes actual laborable.
Porcentaje RC-IVA. En este campo se ingresa el importe del impuesto al Valor agregado
normado por la ley 843.
Mínimo Nacional. Ingrese en este campo el importe del sueldo mínimo nacional.
Tipo de Cambio. Escriba en este campo el tipo de cambio del día. (Moneda nacional
valuada en comparación al dólar).
UFV Y UFV de Cierre Ingresa las Unidades del Fondo a las Vivienda actuales en el mes
78
REGISTRO DE USUSARIOS
Esta opción permite Registrar a los usuarios que Utilizaran el sistema y se despliega en la
siguiente ventana:
Para ingresar a nuevos Usuario presione sobre la opción Adicionar, se desplegara la

siguiente ventana:
En la ventana Abierta se debe introducir El Nombre del usuario, Identificación, Password,

como también El rol de Usuarios.
79
PERSONAL
Permite realizar el registro de los datos personales de todos los funcionarios de la

Institución.
La ventana siguiente muestra el listado de los funcionarios de la Institución.
En al aparte inferior de la ventana se observa el siguiente recuadro:
En el cual se puede observar las siguientes opciones:
 Todos: esta opción muestra la lista de todos los funcionarios de la Institución

 Código: opción que permite buscar al funcionario de acuerdo al Código de
Identificación que se le otorga a cada persona de la Institución, por el cual se lo
puede identificar.
 Fecha de Ingreso: opción que permite buscar al funcionario de acuerdo a la fecha
de ingreso.
 C.I: opción que busca al funcionario a partir del documento de identidad.
80
Para ingresar datos, acceda a la opción “Adicionar”, se desplegará la ventana
donde cada “Pestaña”, presenta una ventana diferente que le permite adicionar
información de los funcionarios.
DATOS PERSONALES
Luego de llenar los datos presionar en el icono de guardar.
PLANILLA.
En esta opción se asignan los Items definidos al Personal de la Institución. Se despliega

la siguiente ventana:
81
PLANILLA SALARIAL
Opción que muestra la planilla salarial del personal de la Institución, despliega la siguiente
ventana:
Empresa, Gestión, Mes. Muestran: el nombre de la Institución, la Gestión y Mes de

trabajo, al ingresar se verán gestión – mes vigentes
Tipo de Planilla – Programa – Apertura Programática. Se debe elegir de las listas el Tipo
de Planilla, el Programa y la Apertura Programática que se quiera procesar las planillas,
de acuerdo al rol que desempeñan los funcionarios.
82
3.7 PRUEBAS
La etapa de pruebas de un sistema presenta un elemento crítico para la garantía de la

calidad del software, y representa una revisión final de las especificaciones del diseño y la
codificación [Pressman. 2002].
Para hacer las pruebas del sistema se hará uso de las pruebas d prototipado rápido,
utilizando el modelo espiral.
Prueba de bajo nivel
La estrategia de prueba de bajo nivel empieza cuando se utiliza la ingeniería del software,
empezando por el análisis de los requerimientos del software, el diseño del sistema y
finalmente la codificación. Para desarrollar las pruebas damos vuelta en espiral hacia el
interior probando cada proceso de ingeniería de software.
Prueba espiral de unidad
La prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del

software. La prueba avanza al movernos fuera del espiral, validando los requisitos de
cada proceso, finalmente se prueba el todo del software y otros elementos del sistema.
La siguiente tabla muestra los procesos donde se utilizaron las pruebas y se hicieron la
validación correspondiente utilizando el modelo espiral.
Proceso de Proceso de Proceso de Proceso de Proceso de

asignación de asignación de evaluación del generación de mantenimiento
vacación comisión personal planillas de pago del sistema
Proceso de Proceso de Proceso de Proceso de Proceso de

registro de ejecutar la registro del operaciones registro de
vacación boleta de salida personal aritméticas. nuevo personal
a comisión evaluado.
Proceso de Proceso de Reporte de la Proceso de

actualización cálculo de planilla de sueldos seguimiento del
puntuación. personal
Reportes de Reportes de Proceso de Reportes de

comisión personal elaboración de la personal y
planilla de sueldos planillas.
Tabla (3.18) Procesos donde se utilizaron las pruebas
83
3.9 FACTORES DE CALIDAD ISO 9126
Calidad
La confiabilidad del sistema es directamente proporcional a la calidad de sus

componentes.
Rj(t)= e –s*t
Donde:
R(t) = Función de confiabilidad de un componente en le tiempo t
s = Tasa constante de fallo.
T = Periodo de operación de tiempo.
Teorema 1. Si n componentes, funcionan independientemente conectados en serie y el i-

esimo componente tiene confiabilidad Rj(t), entonces la confiabilidad total esta dada por:
R(t)= R1(t) *R2(t) *R3(t) * … Rn(t)
Teorema 2. Si n componentes funcionan independientemente y actúa en paralelo y en i-

esimo componente tiene confiabilidad Rj(t), entonces la confiabilidad esta dada por:
R(t)= 1-[1-R1(t)] *[1-R2(t)] *[1-R3(t)] * … *[1-Rn(t)]
84
Se tiene el siguiente diagrama de transferencia:
Diagrama de transferencia Fuente: elaboración propia
Luego obtenemos la siguiente tabla
Rj () s t[hrs] e –s*t
R1 () 0.01 10 0.90
R2 () 0.005 10 0.95
R3 () 0.01 10 0.90
R4 () 0.01 10 0.90
R5 () 0.005 10 0.95
R6 () 0.01 10 0.90
R6 () 0.01 10 0.90
Tabla: calculo de confiabilidad. Fuente elaboración propia
85
Utilizando los teoremas 1 y 2 calculamos:
Rt = {1-[1-R3(t)] *[1-R4(t)] *[1-R5(t)] *[1-R6(t)] *[1-R9(t)} * R1(t) *R2(t) * R7(t)
Rt = {1-[1-0.90] *[1-0.90] *[1-0.95] *[1-0.90]} * 0.90 *0.95 *0.90
R(t)= 0.73
Confiabilidad = R(t) * 100%=73%
El desarrollo del sistema es realizado teniendo mucho en cuenta, la facilidad

administración y mantenimiento, ya que algunos procesos del sistema no sufren cambios.
Para le mantenimiento se cuenta con el manual del sistema, el cual provee información
detallada sobre el mantenimiento correctivo, adaptativo y preventivo.
3.9 CALIDAD EL SOFTWARE
Hacer uso de todos los requerimientos, procedimientos, técnicas e instrumentos del

software implica la calidad del software, para que un producto software cumpla los
estándares predefinidos durante el ciclo de desarrollo del producto.
Para medir la calidad de software utilizaremos la métrica orientada a la función,

portabilidad, confiabilidad y performance.
Portabilidad
El sistema de control del personal y planillas de pago, caso Gobierno Municipal de Viacha,
utiliza un gestor de base de datos SqlServer 2000 y el sistema operativo bajo plataforma
Windows o Linux, por lo que el sistema es 99% portable.
Performance
Utilizando datos reales para los procesos de registro de información listado de reportes y
procesos interactivos (consultas en la interfaz del personal) es menos de cuatro
segundos, por lo tanto se concluye un óptimo performance del sistema.
Funcionalidad
El punto función es una métrica orientada a la función del software y del proceso por el
cual se desarrolla. Se centra en la funcionalidad o utilidad del programa, los puntos
86
función se calculan realizando una serie de actividades comenzando por determinar los
siguientes números:
 Numero de entrada de usuarios, se cuenta cada entrada de usuario que

proporciona al software diferentes datos orientados a la aplicación.
 Numero de salidas de Usuario, estas se refieren a informes, mensajes de
error y toda forma de interacción con el usuario.
 'Numero de peticiones de usuario, una petición esta definida como una
entrada interactiva que resulta de la generación de algún tipo de respuesta
en forma de salida interactiva.
 Numero de archivos, se cuenta cada archivo maestro lógico.
 Numero de interfaces externas, se cuenta todas las interfaces legibles por
el ordenador que son solicitados para transmitir información a otro sistema.
De acuerdo a lo mencionado es que se tiene los resultados en la siguiente tabla:
Registro de funcionario
Registro de subsidio
Registro de descuento
Numero de entrada de Usuario Registro de RC-IVA
Registro de bonos
Registro de horarios
Registro de comisiones
Registro de evaluaciones
Consultas
Reporte de planillas de pago
Reporte marcado de asistencia
Numero de Salida de Usuarios Reporte de comisiones
Reporte de evaluaciones
Reporte de sanciones por faltas y atrasos
87
Menú principal del sistema
Numero de peticiones del usuario Búsquedas de: funcionario, historial planillas,

historial de asistencia, actualizaciones.
Numero de archivos Vacaciones, marcas, subsidios, personal,

comisión, aportes, rc_iva, planilla, descuentos,
evaluación, registro_salidas
Flash, cd, copias de respaldo(bakups), información

de respaldo
Numero de interfases externas
Características del dominio de la información del sistema.
Matriz de punto función
Factor de
Parámetros de
Cuenta Multiplicado por Ponderación Igual Total
Medición
Media
Entradas de usuario 9 * 4 = 36
Salidas de usuario 5 * 5 = 25
Consultas de usuario 6 * 4 = 24
Numero de archivos 11 * 10 = 111
Interfaces externas 4 * 7 = 28
Cuenta Total 200
Tabla (3.19) Matriz punto función
88
Punto función
Significativ
importanci
Moderado
Prudente
Esencial
Medio
Escala
Sin
o
a
Factor 0 1 2 3 4 5
Requiere le sistema copias de seguridad

√
Y de recuperación fiable.
Se requiere comunicación de datos. √
Existen funciones de procesos

√
distribuidos.
Es crítico el rendimiento. √
Será ejecutado el sistema en un S.O.

√
existente.
Requiere el sistema entrada interactiva. √
Requiere entrada de datos interactiva

√
sobre múltiples ventanas.
Se actualiza los archivos maestros en

√
forma interactiva.
Son complejas las salidas, los archivos a

√
petición.
Es complejo el proceso interno. √
Se ha diseñado el código para ser

√
reutilizable.
Están incluidas en el diseño, la

√
conversión y la instalación.
E ha diseñado el sistema para hacer

√
múltiples instalaciones.
Se ha diseñado la aplicación para facilitar

los cambios y para ser fácilmente √
utilizada por el personal.
89
Tabla (3.20) Punto función
Los resultados obtenidos con j=14, y los valores de la tabla punto función, se tiene el
siguiente valor ∑ Fj = 45, valor que remplazamos en la fórmula de punto función.
Con la obtención de los anteriores datos y considerando un grado de confiabilidad mínimo

del 65% es que a continuación calculamos el valor de PF:
Remplazamos en la ecuación, para un nivel de confianza del 65%
PF=CUENTA_TOTAL *(GRADO_DE_CONFIABILIDAD+TASA_DE_ERROR* ΣFi)
PF=200*(0.65+0.01 *45)
PF=220
Ahora calculamos para un nivel de confianza del 100%
PF=CUENTA_TOTAL*(GRADO_DE_CONFIABILIDAD+TASA_DE_ERROR* ΣFi)
PF=200*(1+0.01 *45)
PF=290
El porcentaje de funcionalidad cera como sigue
PF = PFREAL/PFESPERADO
PF = 220/290 = 0.76
Por lo tanto la funcionalidad del sistema es de 76% tomando en cuenta el punto función
máximo.
90
Mantenibilidad.
 Mantenimiento Correctivo.
Que se realiza para corregir errores encontrados por el usuario final. Para hallar un tiempo
media entre fallas que pueden ocurrir en el software utilizamos la siguiente relación.
TMEF= TMDF+TMC
Donde:
TMEF: tiempo medio entre fallas que pueden ocurrir
TMDF: tiempo media de fallas que ocurrirán
TMC: tiempo medio de cambio que se tarda
Para encontrar el valor de TMC se tiene la siguiente ecuación:
TMC= TMAC+TMIC+ TMPC+ TMDC
Donde:
TMAC: tiempo media de analizar cambios a realizar
TMIC: tiempo media de implementar los cambios a realizar
TMPC: tiempo media de probar los cambios realizados
TMDC: tiempo media de distribuir tos cambios
Para la obtención de los valores de las anteriores variables se realizo una muestra
durante los últimos 15 días, es decir que la unidad de medida de tiempo serán los días, y
los resultados obtenidos son los que se muestran a continuación en la tabla:
91
TMDF 15
TMAC 3
TMIC 3
TMPC 2
TMDC 2
Tabla de Valores obtenidos en 15 días.
Entonces tenemos en la ecuación:
TMC= TMAC+ TMIC+ TMPC+ TMDC
TMC=10
Entonces el valor de TMEF será:
TMEF=15+10
TMEF=25
Lo cual significa que 25 días es el tiempo estimado medio en el que pueden ocurrir fallas y
realizar las respectivas correcciones a estas.
 Mantenimiento Adoptivo.
El mantenimiento adoptivo ocurrirá cuando:
 Se cambien las políticas

 Se cambie la estructura organizacional
 Se cambie el personal
Modificaciones que harán que el sistema cambien en poca o gran magnitud, cambios para
los cuales el sistema esta preparado para adaptarse a algunos de estos ajustes en la
institución, pero para otros mas complejos, se deberá hacer una revisión de los procesos
y su adaptación con los nuevos cambios que se generen.
 Mantenimiento Perfectivo.
El sistema esta completamente abierto a añadir o adicionar nuevas funcionalidades de
acuerdo a los nuevos requerimientos del cliente, siempre y cuando sean relacionados con
el servicio e información que brinda el sistema.
92
Facilidad de Uso.
La medición de la facilidad de uso se puede entender como la facilidad que el usuario

tiene para conocer al sistema, tanto como para comprenderlo, aprenderlo y operarlo. A
continuación presentamos en la siguiente tabla los resultados obtenidos en pequeños
talleres de capacitación a los usuarios.
USUARIOS Facilidad de compresión Facilidad de aprendizaje Facilidad de Operación
Recursos humanos 100% 95% 100%
Auxiliar contable 90% 88% 90%
caja 80% 90% 100%
PROMEDIO 95% 92.6 93.6
Tabla de Valores en porcentajes de Facilidad de Uso
Por lo tanto de acuerdo a los resultados obtenidos, se puede apreciar que se tuvo una
facilidad de uso del sistema del 93.6%.
93
CAPITULO IV
CONCLUSIONES Y RECOMENDACIONES
94
4.1 INTRODUCCION
En este punto se detallaran las conclusiones y recomendaciones que contiene el presente

documento. Para llevar a cabo este trabajo se recabo información exhaustiva del proceso
de desarrollo de software, áreas de conocimiento de ingeniería de sistemas y otras
disciplinas dentro de la informática, se leyó bibliografía de temas como control biométrico
de personal, proyectos de grado similares y páginas web relacionados con el tema.
4.2 CONCLUSIONES
Una primera conclusión es que los objetivos que se propusieron al inicio del presente
proyecto se han logrado de manera satisfactoria.
Se ha desarrollado e implementado una herramienta software para el control del personal

y planillas de pago en el Gobierno Municipal de Viacha.
Se cuenta con un sistema de información que permite el registro de personal,

control y elaboración de planilla de pago de los funcionarios que trabajan en la
Alcaldía.
Los administradores del sistema pueden acceder a la información del sistema
implementado de manera confiable y segura.
Se tiene acceso a datos del historial de los funcionarios para brindar informes
periódicos al personal administrativo de la institución, para una toma de
decisiones.
Los procesos y resultados obtenidos se resumen en la siguiente tabla:
Requerimiento Situación anterior Situación actual Parametrización
Registro del Variaba 10 a 15 Varia de 3 a 5 Reduce un 33% de

personal minutos minutos tiempo de registro.
Informes para el Variaba entre 15 a Varia de 3 a 5 Reduce un 65% de

área administrativa 20 minutos minutos tiempo de consulta.
Generación de Variaba entre 1 a 2 Varia de 30 a 45 Reduce un 100%

planillas para todo semanas minutos de tiempo de
el personal trabajo.
95
Control de Información no Consultas que Tiempo aproximado
comisiones automatizada entrega informes de 1 minuto.
sobre las salidas a
comisiones del
personal
Control de Información no Consultas Tiempo aproximado

vacaciones automatizada específicas para le de 5 minutos.
filtrado de
asignación de
vacaciones
Evaluación del Información no Consultas Tiempo aproximado

personal automatizada específicas para el de 5 minutos.
filtrado de de
puntuaciones de la
evaluación
Tabla (4.1) Resumen de resultados obtenidos
4.3 RECOMENDACIONES
El software esta desarrollado y orientado al uso de personas que tengan conocimiento del
área contable, esto con el fin de mantener la integridad de la información.
Si bien el sistema cuenta con un mayor nivel de confiabilidad y seguridad, es necesario

realizar acciones para permitir mantener la madurez del sistema, para ello se recomienda:
Incorporar todo el sistema en una red de información a través de un servidor como

es el SqlServer 2000 con esto se podrá obtener información en tiempo real para
poder facilitar el envío de la información al departamento de contratación, dirección
administrativa, en si a todas las unidades que tengan relación con Recursos
Humanos.
Se recomienda realizar un mantenimiento adaptativo y correctivo periódicamente,
esto con el fin de permitir mejoras funcionales del sistema.
96
ANEXOS
97
ANEXO A
ARBOL DE PROBLEMAS
EFECTOS
Falta de Retraso en Falta de un Perdida de Dificultad en Pérdida de

coordinación la Banco de información la tiempo en las
de las elaboración Datos para de las contratación operaciones
unidades de planillas la obtención evaluaciones de nuevo administrativas
de pago de reportes personal
PROBLEMA Baja productividad operativa falta de

CENTRAL sistematización inexistencia de un
registro único de trabajadores , falta
de reportes
CAUSAS
El manejo de la No se cuenta No se tiene No se cuenta con No se cuenta

información con un banco acceso rápido a un sistema que con un orden de
de datos ade- la información maneje y correcto del os
Se realiza cuado para el administre la procesos
manualmente almacenamiento información
de registros de
los funcionarios
98
ARBOL DE OBJETIVOS
FINES
Disponibilidad de Disponibilidad de
reportes e información completa de
información de las planillas e pago
los empleados evaluaciones del
del Gobierno personal, control del
Municipal de personal y asignaciones
Viacha de comisión
Analizar, diseñar e implementar un

OBJETIVO sistema informático que sistematice
los procedimientos de registro,
PRINCIPAL control de personal, elaboración de
las planillas de pago, proporcione
reportes y evaluación del personal
que sea confiable y oportuna
MEDIOS
El sistema El sistema permite el El sistema El sistema elabora

permite registrar control del personal proporciona las respectivas
al nuevo en las asistencias, informes de planillas de pago
personal que se permisos, faltas, evaluación
de los funcionarios
integra al sanciones y los portes personal y las
Municipio que este mismo realiza comisiones de los de la Alcaldía de
funcionarios Viacha
99
MATRIZ DEL MARCO LOGICO
SISTEMA DE CONTROL DEL PERSONAL Y PLANILLAS DE PAGO
Resumen narrativo Identificadores Medios de Supuestos
de objetivos verificables verificación
objetivamente
FIN Medidas del logro El software y los Contar con los
Registrar los nuevos funcionarios,

Del FIN manuales son materiales y
elaborar
El municipio brinda atribuidos al herramientas para el
planillas de pago,
evaluación todo el material para responsable de la desarrollo de las
del personal y realizar
el registro, control, unidad de control actividades
un control correctivo
evaluación y del personal
del personal.
las planillas de pago
PROPOSITOS Condiciones que De los resultados Que afectan el enlace
Analizar, diseñar e indiquen que el del proyecto Propósito-Fin

implementar
propósito se ha Informe del  Personal
un sistema informático que
logrado Dispuesto y
proyecto al
sistematice los
procedimientos  Información capacitado para
encargado de
exacta sobre el
de registro, control de adoptar el nuevo
personal, recursos humanos
registro del personal
trabajo
elaboración de las planillas  Disponibilidad
de pago,
de reportes e infor-
proporcione reportes
mación de comisiones
estadísticos
de los funcionarios del
y evaluación del personal
municipio.
que se confiable y
oportuna  El personal de
la unidad de control del
personal cuenta con
información
suficiente para
100
realizar el control
PRODUCTOS El software se Se implementa el
 Un software verifica mediante modulo de registro

implementado en
la implementación de empleados.
la unidad de
en al unid de Se implementa el
control de
control del módulo de
Municipio de
personal elaboración de
Viacha
planillas.
 Una base de
Se implementa el
datos con la
módulo de evaluación
información de
del personal
todo el personal
Se implementa el
 Personal
capacitado en el módulo de control
uso y manejo del de personal
sistema
PLAN DE Informes y
ACTIVIDADES entrevistas
1. Analizar y
diseñar una
Análisis del
aplicación
sistema a
computacional
desarrollar
2. Analizar y
diseñar el
Control del avance
subsistema de
del sistema
reportes e
información
101
estadística Aprobación de las
3. Desarrollar las pruebas de

aplicaciones bajo
funcionamiento
una plataforma
orientado a objetos
4. Implementación
y prueba del
sistema de
información
5. Elaboración de
manuales de
usuario y
operación del
sistema
6. Capacitación
del personal
Insumos
para cumplir con las
actividades necesarias
se necesitan:
 Un equipo de
computación P4 ó
superior
 Datos
personales para la
base de datos
 Mterial de
escritorio
102
ANEXO B
Descripción: Se encarga de la cotización y presupuesto del nuevo personal según el

cargo o requerimiento del G.M.V.
Coordina con el responsable de recursos humanos y el responsable de

contratos para la incorporación de un nuevo personal.
Planifica y monitorea el monto a desembolsarse para el personal contratado.
Realiza el registro del monto desembolsado al nuevo personal contratado de
planta o eventual.
Regulariza un informe de cuanto personal se contrato y en qué áreas o
unidades.
Tabla (3.3) Actor, Responsable de la Dirección Administrativa
Descripción: Realiza los contratos de personal que no son de planta, a solicitud de

los distintos departamentos según el trabajo a realizar.
Coordina con el responsable de recursos humanos y la unidad solicitante para

la ejecución del contrato.
Planifica y monitorea los documentos personales de los postulantes.
Realiza la verificación del personal seleccionado bajo la obtención de un
examen realizado por la unidad solicitante.
Tabla (3.4) Actor, Responsable de la Dirección Contratos
103
Descripción: Se encarga de la emisión de cheques al personal de contratos.
Realiza la verificación del personal contratado, que solicita recoger el cheque

en el libro de actas.
Hace la entrega de cheques.
Realiza la entrega de sueldos y salarios del personal de planta.
Tabla (3.5) Actor, Responsable de Caja
104
Referencias bibliográficas
[Tola, 2007] Sistema de control biométrico de personal
Univ. Egberto tola.
[Larman, 1999] UML y patrones, Larman Carig, Mexico 1999
Ira Edición.
[Pressman, 2002] Ingeniería de software, Roger S. Presman,
Editorial Concepción Fernández.
[Sabino, 1994] Como hacer una tesis, Carlos Sabino,
Editorial Panapo, Caracas, 1194, 240 pag.
[Schmuller, 1997] Aprendiendo UML en 24 horas, Joseph Schmuller,
Editorial Pretice, España, pp 103.
Referencia WEB
[Desarrollo orientado a http://www.clikear.com/manuales/uml/
Objetos con UML] 2004 Xavier Ferré Grau
[Modelo de sistemas http://es.tldp.ortg/Tutoriales/doc-modelado-sistemas-
Con UML] UML/mulptiple-html/index.html
Popkin Software and Systems
[Ingeniería de sistemas] http://www.dsi.uclm.es/asignaturas/42541/
Profesor. Jesús Damián Garcia
105
DOCUMENTOS
106

Proyecto de Grado "Sistema de Control de Personal Y Planillas de Pago"

Cargado por

Información del documento

Título original

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

Proyecto de Grado "Sistema de Control de Personal Y Planillas de Pago"

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

MENCION: INGENIERIA DE SISTEMAS INFORMATICOS

GOBIERNO MUNICIPAL DE VIACHA

POSTULANTE : Rogelio Rodríguez Carhuani

TUTOR : MSc. Mario Loayza Molina

REVISOR : Lic. Roberto Vargas Blacutt

El presente trabajo va dedicado con

Ante todo a Dios, por su bendición.

A mis docentes, compañeros y amigos de la carrera.

La necesidad de optimizar y realizar un buen control de asistencias de manera única del

Viendo esta necesidad se llevo a cabo este proyecto implementando un sistema

El proyecto de grado titulado “Sistema de Control del Personal y Planillas de Pago” ha

El producto final se desarrollo en el lenguaje de programación Visual Basic y el motor de

1.2.1 BASE LEGAL DE CREACIÓN DE VIACHA………………………………. 2

1.2.2 ESTRUCTURA DEL GOBIERNO MUNICIPAL DE VIACHA……………. 2

1.3 PLANTEAMIENTO DEL PROBLEMA………………………………………………….. 5

1.3.2 FORMULACION DEL PROBLEMA…………………………………………. 7

1.4.1 Objetivo general……………………………………………………………… 8

1.4.2 Objetivos específicos……………………………………………………….. 8

1.5.2 Justificación Técnica………………………………………………………... 8

1.5.3 Justificación Social………………………………………………………….. 9

1.5.4 Justificación Económica…………………………………………………… 9

1.6 LIMITES Y ALCANCES………………………………………………………………….. 9

2.2 MARCO CONCEPTUAL……………………………………………………………...... 11

2.2.1 CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A OBJETOS………. 11

2.2.2 EL LENGUAJE MODELADO UML…………………………………………. 13

2.2.3 MODELO CLIENTE – SERVIDOR………………………………………..... 22

2.2.4 BASE DE DATOS RELACIONAL………………………………………… 23

3.3 MARCO TEÓRICO………………………………………………………………………. 25

3.3.1 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE…….. 25

3.3.2 GUÍA PARA LA INGENIERÍA DE APLICACIONES RAPIDAS GRAPLLE

(GUIDELINES FOR RAPID APPLICATION ENGINEERING)……………… 26

d) Modelo y Diseño de la Base de datos …………………………………... 28

3.3.3 REQUERIMIENTO DE SOFTWARE Y HARDWARE………………………. 29

3.3.6 MANTENIMIENTO DEL SISTEMA……………………………………………... 30

3.3.7 CALIDAD DE SOFTWARE………………………………………………………... 31

3.2 RECOPILACION DE NECESIDADES………………………………………………… 33

3.3.1 Análisis del sistema actual………………………………………………….. 36

3.3.2 Análisis del nuevo sistema…………………………………………………... 40

3.5 REQUERIMIENTO DE HARDWARE Y SOFTWARE……………………………….. 64

3.6.1 Interfaz del usuario………………………………………………………….. 65

3.8 FACTORES DE CALIDAD ISO 9126…………………………………………………. 73

3.9 CALIDAD EL SOFTWARE……………………………………………………………... 75

MATRIZ DEL MARCO LOGICO…………………………………………………………… 88

Tabla (3.3) Actor, Responsable de la Dirección Administrativa………………………… 91

Tabla (3.4) Actor, Responsable de la Dirección Contrato........................................... 91

Tabla (3.5) Actor, Responsable de Caja………………………………........................... 92

Fig (3.1) identificación de actores del sistema actual……………………………………. 36

Fig (3.2) diagrama de casos de uso del sistema actual…………………………………. 38

Fig (3.3) Diagrama de actividad del sistema actual…………………………………....... 39

Fig (3.4) Definición de actores del nuevo sistema……………………………………...... 40

Fig (3.5) Diagrama de casos de uso del nuevo sistema……………………………....... 42

Fig (3.6) Diagrama de casos de uso para el paquete Recursos Humanos…………… 43

Fig (3.7) Diagrama de casos de uso para el paquete Auxiliar contable……………….. 47

Fig (3.8) Diagrama de clases………………………………………………………………... 49

Fig (3.9) Diagrama de actividades del nuevo sistema…………………………………… 51

Fig (3.10) Diagrama de secuencias: Control de vacaciones……………………………. 52

Fig (3.11) Diagrama de secuencias: Evaluación del personal………………………….. 53

Fig (3.12) Diagrama de colaboración: Registro del personal…………………………… 54

Fig (3.13) Diagrama de colaboración: Control del personal…………………………….. 54

Fig (3.14) Diagrama de colaboración: Control y asignación de comisiones……......... 55

Fig (3.15) Diagrama de colaboración: Evaluación del personal……………………....... 55