005X1060

UNIVERSIDAD TECNICA PARTICULAR DE LOJA
ESCUELA DE INFORMATICA
TESIS DE GRADO PREVIA A LA OBTENCION DEL

TITULO DE INGENIERO DE INFORMATICA
TEMA:
IMPLEMENTACION SOFTWARE DE NOMINA PARA LA

UNIVERSIDAD TECNICA DE MACHALA
AUTOR:
BETTY MARLENE PACHUCHO HERNANDEZ
DIRECTORA DE TESIS:
ING. AUDREY ROMERO
2009
“Implementación Software de NOMINA para la Universidad Técnica de Machala”
__________________________________________________________________________________
Universidad Técnica Particular de Loja
CERTIFICACION
Ing. Audrey Romero
DIRECTORA DE TESIS
Certifica:
Que el presente trabajo de investigación ha sido, supervisado y revisado en

todas sus fases, constatando que cumple con los requisitos establecidos por
la Escuela de Ciencias de la Computación, en consecuencia autoriza su
presentación.
Loja, mayo del 2009
__________________
Ing. Audrey Romero
DIRECTORA DE TESIS
__________________________________________________________________________________
CESION DE DERECHOS
El autor, declaro conocer y aceptar las disposiciones del Art. 67 del Estatuto
orgánico de la Universidad Técnica Particular de Loja que en su parte
pertinente textualmente dice: “Forma parte del patrimonio de la Universidad,
la propiedad intelectual, de investigación, trabajos científicos o técnicos y
tesis de grado que se realicen a través o con el apoyo financiero, académico
o institucional (operativo) de la Universidad”.
_____________________________
Betty Marlene Pachucho Hernández
Autora
__________________________________________________________________________________
AUTORIA
Los conceptos, ideas y opiniones expuestas en el presente proyecto de

tesis, son de exclusive responsabilidad de la autora.
La información de otros autores empleado en el presente trabajo de

investigación está especificada en fuentes de referencia y apartados
bibliográficos.
_______________________
Betty Marlene Pachucho Hernández

__________________________________________________________________________________
AGRADECIMIENTO
Mi agradecimiento a la Universidad Técnica Particular de Loja y a través de

ella a los docentes de la Escuela de Ciencias de la Computación por
compartir sus conocimientos y coadyuvar a la cristalización de mi carrera
profesional.
Mi sentimiento de profunda gratitud a la Ing. Audrey Romero directora de

tesis por su apoyo y su oportuna guía en el desarrollo de este proyecto y al
Ing. Juan Carlos Espinoza codirector.
Gracias a la Lcda. Lidia Villacís secretaria de la Escuela de Ciencias de la

Computación y a las personas que han estado a mi lado para ayudarme, y
que hacen suyo también este triunfo.
LA AUTORA
__________________________________________________________________________________
DEDICATORIA
A mi familia, a mis padres y hermanos por la confianza depositada en mí.
A mi esposo Juan Carlos, por su apoyo incondicional.
A mis hijos Juan Carlos y Kevin Darío, que representan mi mejor logro
Betty
__________________________________________________________________________________
Contenido
1 ANTEPROYECTO ............................................................................................... 1
1.1 Justificación ............................................................................................................. 1
1.2 Problemática Actual ................................................................................................ 2
1.3 Propuesta presentada .............................................................................................. 3
1.4 Objetivos del Proyecto ............................................................................................ 3
1.4.1 Objetivo General: ........................................................................................................... 3
1.4.2 Objetivos Específicos: .................................................................................................... 3
1.5 Metodología de desarrollo ...................................................................................... 3
1.6 Fases del Proyecto.................................................................................................... 4
1.7 Validación de resultados y del producto................................................................ 5
1.8 Recursos ................................................................................................................... 6
1.8.1 Recursos materiales ...................................................................................................... 6
1.8.2 Recursos hardware ....................................................................................................... 6
1.8.3 Recursos software ......................................................................................................... 6
1.8.4 Recursos humanos ........................................................................................................ 6
2 Fase 1: VISIONAMIENTO DEL SOFTWARE ................................................. 7
2.1 Introducción ............................................................................................................. 7
2.2 Proceso Unificado como metodología de desarrollo de software ........................ 7
2.2.1 Proceso Unificado .......................................................................................................... 7
2.2.2 Breve historia del Proceso Unificado ............................................................................. 8
2.2.3 Características del Proceso Unificado ............................................................................ 8
2.2.4 Fases del Proceso Unificado ........................................................................................... 9
2.2.5 Ventajas y desventajas del Proceso Unificado ............................................................. 14
2.3 Análisis de Requisitos ............................................................................................ 15
2.3.1 Recolección de hechos de información ........................................................................ 15
2.3.3 Diagramas del proceso requerido ................................................................................. 18
2.4 Visión del sistema .................................................................................................. 19
2.5 Aprendizajes de la Fase......................................................................................... 20
2.6 Bibliografía............................................................................................................. 21
3. Fase 2: DISEÑO DE LA ARQUITECTURA.................................................... 22
3.1 Introducción ........................................................................................................... 22
3.2 Herramientas de Modelado .................................................................................. 22
3.3 Arquitectura del Software .................................................................................... 23
3.3.1 Arquitectura de la Solución ....................................................................................... 23
3.4 Plataforma de Desarrollo ...................................................................................... 24
3.4.1 Plataforma de la Base de Datos ................................................................................. 24
3.4.2 Lenguaje de Programación ........................................................................................ 24
3.5 Metodología de Programación ............................................................................. 25
3.6 Diseño de Interfaces .............................................................................................. 26
3.6.1 Diseño general de interfases del sistema ................................................................... 26
3.6.2 Prototipo de pantallas ................................................................................................ 27
3.7 Aprendizaje de esta Fase....................................................................................... 29
3.8 Bibliografía............................................................................................................. 30
__________________________________________________________________________________
4. Fase 3: DESARROLLO DE LA SOLUCION ................................................... 32

4.1 Introducción ........................................................................................................... 32
4.2 Implementación de la base de datos..................................................................... 33
4.2.1 Funcionalidades del SGBD Oracle ............................................................................... 33
4.2.2 Análisis inicial del SGBD Oracle ................................................................................. 33
4.2.3 Pasos a seguir para crear una base de datos Oracle ...................................................... 34
4.2.4 Scripts de creación de la base de datos ......................................................................... 35
4.3 Implementación del framework de trabajo......................................................... 35
4.3.1 Ventajas de utilizar un Framework de trabajo .............................................................. 35
4.3.2 Especificación de rutinas y su descripción ................................................................... 35
4.4 Gestión de versiones del software......................................................................... 36
4.4.1 Plan de Gestión de Versiones de Software ............................................................... 36
4.4.2 Beneficios de la Gestión de Versiones ....................................................................... 36
4.4.3 Clasificación de las Versiones .................................................................................... 37
4.4.4 Estrategia de Control de Versiones de Software ..................................................... 37
4.5 Construcción de la aplicación ............................................................................... 38
4.5.1 Objetivo ....................................................................................................................... 38
4.5.2 Consideraciones Importantes .................................................................................... 38
4.5.3 Código fuente depurado ............................................................................................. 38
4.6 Aprendizajes en esta fase ...................................................................................... 38
5. Fase 4: CONTROL DE CALIDAD Y ESTABILIZACION .......................... 40
5.1 Introducción ........................................................................................................... 40
5.1.1 Calidad y Software ..................................................................................................... 40
5.1.2 Obtención de un software con calidad ...................................................................... 40
5.2 Prueba de Software ............................................................................................... 41
5.2.1 Razones para que un programa contenga errores ................................................... 41
5.2.2 Verificación y Validación ........................................................................................... 41
5.2.3 Plan de Validación del Software de Nómina para la Universidad Técnica de
Machala 42
5.3 Bibliografía............................................................................................................. 42
6. Fase 5: IMPLANTACION DEL SOFTWARE ................................................. 43
6.1 Introducción ........................................................................................................... 43
6.2 Implementación de la aplicación .......................................................................... 44
6.2.1 CD instalador del software ........................................................................................ 44
6.2.2 Lista de requerimientos básicos ................................................................................ 44
6.2.3 Instrucciones de instalación ....................................................................................... 44
6.3 Documentación de usuario.................................................................................... 44
6.3.1 Introducción ................................................................................................................ 44
6.3.2 Objetivos ..................................................................................................................... 45
6.3.3 Importancia del manual de usuario .......................................................................... 45
6.3.4 Funcionalidades documentadas ................................................................................ 45
6.3.5 Manual de Usuario ..................................................................................................... 46
6.4 Capacitación a usuarios ........................................................................................ 46
6.4.1 Plan de capacitación ................................................................................................... 46
6.4.2 Informe de capacitación ............................................................................................. 46
6.5 Gestión del soporte del software........................................................................... 47
6.5.1 Plan de soporte y mantenimiento del software ........................................................ 47
6.6 Aprendizajes en esta fase ...................................................................................... 47
7. Fase 6: CONCLUSIONES Y RECOMENDACIONES.................................... 48
__________________________________________________________________________________
7.1 Conclusiones........................................................................................................... 48
7.2 Recomendaciones................................................................................................... 49
ANEXOS ................................................................................................................... 1
ANEXO 1 – ENTREVISTAS ............................................................................................ 1
ANEXO 2 – DOCUMENTO VISION.............................................................................. ix
ANEXO 3 – PROCESO ACTUAL ................................................................................... x
ANEXO 4 – PROCESO PROPUESTO ......................................................................... xiii
ANEXO 5 – DIAGRAMA DE CASOS DE USO ........................................................ xviii
ANEXO 6 – DIAGRAMA DE SECUENCIA ................................................................ xix
ANEXO 7 – DOCUMENTO DE ARQUITECTURA ................................................... xx
ANEXO 8 – PLAN DE PRUEBAS ................................................................................ xxi
ANEXO 9 – CASOS DE PRUEBA ............................................................................... xxii
ANEXO 10 – PRUEBAS DE ACEPTACION............................................................. xxiii
ANEXO 11 – PLAN DE CAPACITACION................................................................ xxiv
ANEXO 11 – Plan de Capacitación .............................................................................. xxv
ANEXO 12 – INFORME DE CAPACITACION ...................................................... xxvii
ANEXO 13 – PLAN DE SOPORTE Y MANTENIMIENTO ................................. xxxiv
__________________________________________________________________________________
1 ANTEPROYECTO
1.1 Justificación
La automatización de los procesos críticos de una empresa o

institución es de suma importancia para ejercer controles adecuados y
ayudar al personal a desarrollar su trabajo de modo más seguro y
eficiente. Siendo necesario y posible de ejecutar gracias al avance
tecnológico experimentado en los últimos años y a la reducción de los
costos del equipamiento que sirve de soporte para el desarrollo y la
implantación de sistemas de información; se puede aprovechar
adecuadamente estas posibilidades para dar a la entidad una ventaja
estratégica y convertir los sistemas de información en un factor crítico
de éxito para el desarrollo de sus actividades.
La Universidad Técnica de Machala (UTM) una institución que centra
su actividad en la formación integral de estudiantes en el ámbito
científico-técnico articulando crítica, innovadora y creativamente la
docencia, investigación y proyección social, para formar profesionales
creativos, solventes y solidarios. Cuenta con 7500 alumnos, 310
docentes Y 276 administrativos.
La Universidad cuenta con dos sistemas informáticos: un sistema
contable y un sistemas Nómina que al carecer de un sistema de
recursos humanos se registran los datos requeridos Y los roles de
pago se generan de todos los tipos de tanto docente como
administrativo, contratado o con nombramiento definitivo, manejo en
base a presupuesto fiscal o por autogestión; se plantea entonces la
necesidad de construir, con base sólida, un proceso regular y continuo.
Las actividades el módulo de nómina en el sistema destinado para su
efecto no cubre a todos los empleados de la institución, si no que
funciona solo para el personal de planta. A continuación se comenta
brevemente las actividades que se realizan según el tipo de contrato
del personal:
Personal contratado (docentes y administrativos)
El proceso para la generación de pagos en este caso es

manual.
En cada facultad se registra el tiempo de trabajo y se envía al
Departamento de Recursos Humanos (RRHH) certificaciones
del tiempo de trabajo y se especifica la modalidad de pago:
Profesores por módulos o cátedras y Administrativos pago
mensual hasta una fecha determinada.
RRHH valida la información y envía las certificaciones al
Departamento de Remuneraciones para la liquidación o
emisión de rol de pagos según sea el caso. Antes de la
1
__________________________________________________________________________________
ejecutar el pago se solicita al Departamento de Contabilidad

informes de anticipos y descuentos que deban aplicarse al
personal contratado.
Los roles de pagos son elaborados en una Hoja de Cálculo
Excel por lo que se carece de información histórica que se
pueda consultar fácilmente.
Personal de planta (docentes y administrativos)
Para el personal de planta se registra la información a través

del módulo de Roles de pago que está desarrollado en
FOXPRO para DOS, y permite registrar los rubros de ingresos
y egresos que se deben considerar para la generación de roles
de pago del personal.
Además se elaboran detalles de pago por concepto de
bonificaciones institucionales en los meses: Febrero, Abril,
Mayo, Junio Septiembre, Noviembre y Diciembre.
1.2 Problemática Actual

Los procesos que se llevan actualmente presentan los siguientes
inconvenientes:
No se dispone de un sistema de Recursos Humanos del personal

de UTM.
Los docentes están clasificados por facultad, pero no se puede

controlar su historia en el caso de que se cambie de una a otra.
Se carece de información histórica respecto a licencias,

suspensiones, renuncias, fallecimientos en un sistema de
información; por lo que la generación de reportes y el cálculo de
bonificaciones es totalmente manual. Esto da indicios de que la
información resultante es imprecisa y sujeta a errores humanos;
además que genera un trabajo operativo innecesario.
La información del módulo de Roles de pago no está integrada
con el sistema contable, esto ocasiona pérdida de tiempo y
recursos pues mensualmente los asientos de diario toman hasta
una semana en ingresarlos contablemente.
La información del personal que pertenece al presupuesto de

autogestión es procesada con otro módulo de Roles de Pago
independiente del de los empleados de planta.
En el proceso de liquidación del Rol hay intervención del personal

de cómputo para sacar un backup de la base de datos antes de
procesado y luego de detectar los errores que hubieron volver a
recuperar la base de datos para corregirlos.
2
__________________________________________________________________________________
Los procesos manuales y los sistemas no integrados de los que se

dispone dan lugar a desperdicio de recursos de todo tipo.
1.3 Propuesta presentada
Tomando en cuenta las prioridades de la UTM respecto a sus

requerimientos, en el presente proyecto se plantea:
Identificar e implementar los componentes mínimos del módulo de
recursos humanos que interactúan con el módulo de nómina.
Implementar el módulo de nómina para la UTM, donde se genera

roles de pago, liquidaciones y demás componentes de este
módulo.
Implementar de políticas y procesos de operación del módulo de

nómina para la UTM.
Integrar el módulo de nómina con el sistema contable de la UTM.
1.4 Objetivos del Proyecto
1.4.1 Objetivo General:
Implementar el Software para la Gestión de Nómina del personal

de la Universidad Técnica de Machala.
1.4.2 Objetivos Específicos:
Identificar e implementar los componentes mínimos del módulo

de recursos humanos que interactúan con el módulo de nómina.
Reducir los recursos empleados para la gestión de nómina de

todo el personal de la UTM.
Reducir el riesgo de problemas de operación del módulo de

nómina por procesos no definidos ó definidos informalmente.
Minimizar el esfuerzo y recursos aplicados para la generación de

asientos contables por concepto de roles de pagos del personal
de la UTM.
1.5 Metodología de desarrollo

La metodología de desarrollo a emplearse será proceso unificado.
El proceso unificado es más que un simple proceso; es un marco de
trabajo genérico que puede especializarse para una gran variedad de
3
__________________________________________________________________________________
sistemas software, para diferentes áreas de aplicación, diferentes tipos

de organizaciones, diferentes niveles de aptitud y diferentes tamaños
de proyecto.
La presencia de un proceso bien definido y bien gestionado es una
diferencia esencial entre proyectos productivos y otros que fracasan. El
Proceso Unificado de Desarrollo es una solución al problema de
software, pues presenta las siguientes ventajas:
Permite trabajar de una forma coordinada
Integra las múltiples facetas del desarrollo
Proporciona una guía para ordenar las actividades de un

equipo
Dirige las tareas de cada desarrollador por separado
Especifica los artefactos que deben desarrollarse
Ofrece criterios para el control y la medición de los productos y

actividades del proceso.
Las características del proceso unificado son:
 Guiado por lo casos de uso: Los casos de uso son el

instrumento para validar la arquitectura del software y
extraer los casos de prueba.
 Centrado en la arquitectura: Los modelos son
proyecciones del análisis y el diseño constituye la
arquitectura del producto a desarrollar.
 Iterativo e incremental: Durante todo el proceso de
desarrollo se producen versiones incrementales (que se
acercan al producto terminado) del producto en desarrollo.
1.6 Fases del Proyecto

Las fases que se han contemplado en el desarrollo del presente
proyecto son las generales del desarrollo de sistemas, y los
entregables se generan en base a la metodología de desarrollo
aplicada.
Fase 1: Visionamiento del software
En esta etapa se analizarán todos los componentes
necesarios para el desarrollo del software.
Fase 2: Diseño de la arquitectura
Se analizará y seleccionarán las herramientas
necesarias para el desarrollo del software, como: base
de datos, lenguaje de programación, etcétera. Además
se diseñará los componentes arquitectónicos en los que
se basará el desarrollo del software.
4
__________________________________________________________________________________
Se incluye el diseño de interfaces del sistema.

Fase3: Desarrollo de la solución
Corresponde al desarrollo de los componentes
necesarios para la solución. Además se incluye
aquí posibles refinamientos que se tenga que realizar
al visionamiento y diseño de arquitectura.
Fase 4: Control de calidad y estabilización
Se incluye la etapa de pruebas y estabilización con la
finalidad de revisar los aspectos claves en la calidad
del producto.
Fase 5: Implantación del Software
Corresponde a la puesta en marcha del sistema y
liberación de los documentos necesarios para el
funcionamiento del sistema. Además de incluyen
elementos de control de versiones y cambios para
asegurar el correcto manejo del software en el
futuro.
Fase 6: Conclusiones y Recomendaciones
En base al trabajo realizado se realiza una síntesis de
la experiencia del desarrollo del software de nómina y
de la proyección del tema.
1.7 Validación de resultados y del producto
El software para la gestión de nómina del personal de la UTM una vez

implementado debe haber generado los siguientes indicadores:
Grado aceptable de eficiencia del sistema, proporcionado por los
directivos de las áreas involucradas.
Nivel aceptable de usabilidad del sistema, proporcionado por los

usuarios del software.
Porcentaje de optimización de recursos respecto al sistema actual.
5
__________________________________________________________________________________
1.8 Recursos
1.8.1 Recursos materiales
Recurso Cantidad Costo Unitario Costo Total

estimado Estimado
Computador Pentium IV 1600 horas 1 dólar / hora 1600
Impresora 1000 hojas 5 ctvos/hoja 50
CD RW 10 1 dólas/Cd 10
CD R 10 80 ctvos/CD 8
Resmas de papel A4 / 75 g. 3 3.50/resmas 9
Materia de Oficina 1 50 dólares 50 dólares
TOTAL RECURSOS 1727 dólares
MATERIALES
1.8.2 Recursos hardware

estimado Estimado
Computador 1 950 950
Impresora inyección 1 90 90
TOTAL RECURSOS 1040
HARDWARE
1.8.3 Recursos software

estimado Estimado
Licencia Base de Datos Oracle 1 3000 3000
Licencia Oracle Cliente 6 1500 9000
Licencia Visual Basic 6.0 1 300 300
TOTAL RECURSOS 12300
SOFTWARE
1.8.4 Recursos humanos

estimado Estimado
Asesor 20 horas 5 dólares / hora 100
Investigador 10 meses 250 dólares/mes 2500
TOTAL RECURSOS 2600
HUMANOS
6
__________________________________________________________________________________
2 Fase 1: VISIONAMIENTO DEL SOFTWARE
2.1 Introducción
El desarrollo de Software es un proceso complejo para el que se debe

elegir metodologías que permitan organizar los procesos y llegar a la
culminación exitosa de proyectos. Para el presente proyecto se ha
definido utilizar el Proceso Unificado de Desarrollo de Software, por
sus características especialmente: Iterativo e Incremental que el
presente es parte de una de las iteraciones que se desarrollarán para
la UTM, que permitirá la gestión integral de la importante información
que aquí se mantiene.
Cabe señalar que el Proceso Unificado basado en RUP puede

resultar bastante amplio y para el presente se han considerado
aquellos procesos más relevantes.
Para capturar los requisitos de manera eficaz, necesitamos un

conjunto de técnicas y artefactos que ayude a obtener una visión
suficientemente buena del sistema para avanzar en los flujos de las
fases subsiguientes, constituyéndose de esta manera en la base del
desarrollo.
2.2 Proceso Unificado como metodología de desarrollo de

software
2.2.1 Proceso Unificado
El Proceso Unificado es una metodología de desarrollo de software,

que indica un conjunto de procesos y actividades necesarias para
transformar los requisitos de un usuario en un sistema software
(Figura 2.1). Es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas software, para
diferentes áreas de aplicación, diferentes tipos de organizaciones,
diferentes niveles de aptitud y diferentes tamaños de proyecto [1].
Figura 2.1 Un proceso de desarrollo de software [1]
7
__________________________________________________________________________________
La utilización del Proceso Unificado como metodología de desarrollo

de software permitirá obtener un producto de calidad que se ajuste a
las necesidades de la Institución, lo cual se logrará dado que el
Proceso Unificado se basa en la comunicación con el cliente que es
quien en realidad conoce hasta donde llegar con el software,
diseñando un modelo de arquitectura fácil de ajustar a posibles
cambios futuros.
2.2.2 Breve historia del Proceso Unificado
A partir de la difusión de los métodos y lenguajes de programación

orientados a objetos surgió también una amplia variedad de análisis y
diseño orientados a objetos pero ningún método fue adoptado sino
hasta el año de 1990 cuando James Rumbaugh, Grady Booch e Ivar
Jacobson empezaron a trabajar en un método unificador que
cambiaría las mejores características de cada uno de sus métodos
individuales y adoptaría características adicionales que propusieran
otros expertos. El resultado fue el Lenguaje de Modelo Unificado
(UML), el cual para 1997 se convirtió en estándar de la industria para
el desarrollo de software orientado a objetos.
El UML proporciona la tecnología necesaria para apoyar la práctica de

la ingeniería del software orientada a objetos, pero no provee el
marco de trabajo del proceso que guíe a los equipos en la aplicación
de la tecnología, fue entonces cuando estos mismos hombres
Jacobson, Rumbaugh y Booch desarrollaron el Proceso Unificado, un
marco de trabajo para la ingeniería del software orientada a objetos,
mediante la utilización del UML. En la actualidad, el Proceso Unificado
y el UML se emplean de forma amplia en los proyectos OO de todos
los tipos. [5]
2.2.3 Características del Proceso Unificado
El Proceso Unificado actúa como un modelo que puede adaptarse a

cualquier tipo de proyecto y empresa, sea esta grande o pequeña.
Las características del Proceso Unificado son: [2]
Dirigido por casos de usos.- Un sistema de software se crea

para servir a sus usuarios. Por lo tanto, para construir un
sistema exitoso se debe conocer que es lo que quieren y
necesitan los usuarios prospectos, estos requerimientos al ser
capturados forman los Casos de Uso.
Los Casos de Uso son desarrollados a la par conforme avanza
el diseño de la arquitectura del sistema; es decir, que los casos
de uso dirigen la arquitectura del sistema y la arquitectura del
sistema a su vez influencia la elección de los casos de uso. Por
lo tanto, la arquitectura del sistema y los casos de uso maduran
conforme avanza el ciclo de vida.
8
__________________________________________________________________________________
Centrado en la arquitectura.- El concepto de arquitectura de

software involucra los aspectos estáticos y dinámicos más
significativos del sistema. El modelo de la arquitectura surge de
las necesidades de la Institución, tal y como las interpretan los
usuarios, y tal como están reflejadas en los casos de uso. Sin
embargo, también está influenciada por muchos otros factores,
tales como la plataforma de software en la que se ejecutará, la
disponibilidad de componentes reutilizables, consideraciones
de instalación.
La arquitectura es la vista del diseño completo con las
características más importantes hechas más visibles y dejando
los detalles de lado. Ya que lo importante depende en parte del
criterio, el cual a su vez viene con la experiencia, el valor de la
arquitectura depende del personal asignado a esta tarea. Sin
embargo, el proceso ayuda al arquitecto a enfocarse en las
metas correctas, tales como claridad, flexibilidad en los
cambios futuros y reuso.
Iterativo e incremental.- El proceso iterativo permite una
comprensión creciente de los requerimientos a la vez que se va
haciendo crecer el sistema. El Proceso Unificado es un marco
de desarrollo iterativo e incremental compuesto de cuatro fases
denominadas Inicio, Elaboración, Construcción y Transición.
Cada una de estas fases es a su vez dividida en una serie de
iteraciones. Estas iteraciones ofrecen como resultado un
incremento del producto desarrollado que añade o mejora las
funcionalidades del sistema en desarrollo.
Las iteraciones hacen referencia a pasos en el flujo de trabajo,
y los incrementos, al crecimiento del producto. Para una
efectividad máxima, las iteraciones deben estar controladas;
esto es, deben seleccionarse y ejecutarse de una forma
planificada. Es por esto por lo que son mini-proyectos.
2.2.4 Fases del Proceso Unificado
RUP divide el proceso en cuatro fases: Inicio, Elaboración,

Construcción y Transición; dentro de cada fase, los directores o los
desarrolladores pueden descomponer adicionalmente el trabajo en
iteraciones con sus incrementos resultantes. Cada fase termina con
un hito. Cada hito se determina por la disponibilidad de un conjunto de
artefactos; es decir, ciertos modelos o documentos han sido
desarrollados hasta alcanzar un estado predefinido. [5]
La Figura 2.2 muestra las fases del Proceso Unificado (PU) y su
relación con las actividades genéricas clásicas del ciclo de vida del
software.
9
__________________________________________________________________________________
Elaboración
Inicio
Construcción
Transición
Lanzamiento
Incremento del Software
Producción
Figura 2.2 Fases del Proceso Unificado. [6]
Fase de Inicio
La Fase de Inicio del PU abarca la comunicación con el cliente

y las actividades de planeación. “Durante esta fase se
desarrolla una descripción del producto final a partir de una
buena idea y se presenta el análisis de negocio para el
producto”. [1]
Esencialmente, en esta fase se identifican los requisitos para el

software, los mismos que se consiguieron gracias a las
entrevistas (Anexo 1) efectuadas a los usuarios involucrados,
la información recabada sirvió de base para la elaboración de
los productos entregables de esta fase que son:
10
__________________________________________________________________________________
o Documento Visión.- En este documento se resume las

características del producto así como las necesidades,
problemas y expectativas de los usuarios. (Anexo 2)
o Modelo actual del Negocio.- Con ayuda de las
entrevistas se pudo obtener una idea clara de cómo y
donde interviene cada usuario, permitiendo con ello
diseñar el diagrama del proceso actual. (Anexo 3)
o Modelo del negocio propuesto.- Teniendo claro el
proceso actual y lo que el usuario espera obtener con el
desarrollo del software se diseñó el diagrama del
proceso propuesto. (Anexo 4)
Fase de elaboración
En esta fase se refina y expande los casos de uso

preliminares que se desarrollaron como una parte de la fase de
inicio; además, expande la representación arquitectónica para
incluir cinco visiones diferentes del software: el modelo de
casos de uso, el modelo de análisis, el modelo de diseño, el
modelo de implementación y el modelo de despliegue.[5]
Estas visiones del software están definidas en los siguientes

entregables de esta fase:
o Diagramas de Casos de Uso.- Es la representación

gráfica de los actores y los casos de uso del software.
(Anexo 5)
o Diagramas de Secuencia.- “Muestra cómo el control

pasa de un objeto a otro a medida que se ejecuta el
caso de uso y a medida que se envían mensajes entre
objetos del diseño” [1] Los diagramas de secuencia
parten de la identificación clara de los casos de uso y el
comportamiento del proceso. (Anexo 6).
o Documento de Arquitectura.- Este documento contiene

una descripción detallada de la arquitectura del software
(Anexo 7). Incluye los siguientes puntos:
- Representación Arquitectónica.-
- Casos de Uso
- Vista Lógica, en donde se describe el diagrama
de vista lógica, diagrama de clases y modelo
entidad relación
- Vista Física
- Vista de Implementación
- Diseño Físico de la Base de Datos
11
__________________________________________________________________________________
o Plan de Pruebas.- Con el propósito de verificar el buen

funcionamiento del software y determinar que cubre con
las expectativas de los usuarios de la Universidad
Técnica de Machala se estableció un plan de pruebas
en donde se detalla los métodos y técnicas a emplear
(Anexo 8).
Al final de la fase de elaboración, estaremos en disposición de

asegurar que el ámbito, los riesgos y los datos entregados aún
son razonables. Y si existe algún ajuste es aquí en donde se
los debe realizar.
Fase de construcción
La Fase de Construcción evoluciona la descripción inicial
hasta convertirse en el sistema completo, en un producto listo
para ser entregado a los usuarios finales.
En esta fase la arquitectura es estable, sin embargo se pueden
encontrar mejores alternativas para estructurar el sistema las
mismas que se podrán aplicar siempre y cuando estos
cambios arquitectónicos sean de menor importancia y no
afecten al sistema en sí, obligando además a actualizar los
diagramas productos de la fase anterior.
Puede suceder que en esta fase el sistema no esté
completamente libre de defectos. Muchos de estos defectos se
descubrirán y solucionarán durante la fase de transición. [1]
La codificación de los módulos involucrados en el sistema
están desarrollados en el lenguaje de programación orientado
a objetos Visual Basic .NET 2005 con un motor de base de
datos Oracle 10g Release 2, lo cual garantiza la seguridad de
la información y su integración con el sistema contable.
Como producto entregable de esta fase tenemos:
o Instalador del Sistema Nómina (SNP)
o Manual del Programador.- Contiene una descripción de
las tablas y campos de la base de datos, scripts de
creación de tablas, scripts de creación de paquetes y
procedimientos, especificación de rutinas. Este
documento es de gran importancia para el
mantenimiento del sistema.
Fase de Transición
En esta Fase se entrega el software a los usuarios finales para
que realicen las pruebas y puedan reportar tanto defectos
como cambios necesarios. El software es entregado al usuario
junto con ayudas como es el manual del usuario en donde se
describe la funcionalidad del sistema.[5]
12
__________________________________________________________________________________
Para poder entregar el software al usuario previamente fue

necesario realizar sesiones de adiestramiento impartidas por el
desarrollador.
El producto entregable de esta fase es el Manual de Usuario
(documento anexo).
Fase de Producción
“La Fase de Producción del PU coincide con la actividad de
despliegue del proceso genérico. Durante esta fase se
monitorea el uso subsiguiente del software, se proporciona el
soporte para el ambiente operativo (infraestructura), y se
reciben y evalúan los informes de defectos y los
requerimientos de cambios” [5]
Figura 2.3 Ilustración de relaciones entre los productos del proyecto
La Figura 2.3 muestra la relación de cada producto de cada fase en la

consecución del producto (software) deseado. Parte desde la fase de
13
__________________________________________________________________________________
inicio con la especificación del glosario inicial del proyecto hasta

concluir con el producto (software) deseado y puesta en marcha, fase
de transición.
2.2.5 Ventajas y desventajas del Proceso Unificado
Entre las ventajas podemos anotar las siguientes:

Mediante este proceso de desarrollo de software hay varias
oportunidades para revisar el sistema a desarrollar hasta que
sea correcto. Se pueden encontrar errores y corregirlos.
Adaptabilidad del desarrollo a nuevos requisitos o nuevos
cambios
Se define una arquitectura sólida en etapas tempranas del
desarrollo. La arquitectura de un sistema se define como un
conjunto de componentes y las interacciones entre ellas. De
este modo este tipo de ciclo de vida debe ser ampliable, por lo
que el sistema es robusto y tiene facilidad de mantenimiento.
Se reducen los riesgos de no obtener el producto deseado
En cada momento hay una versión del sistema funcionando
que se modifica según las necesidades y deseos del cliente.
Progreso visible en las primeras etapas
Reducir la redundancia e incrementa la productividad, un
software bien diseñado evita la duplicidad del código con lo
cual se obtiene un software robusto.
Fácil ejecución del proceso de elaboración del sistema
software, ya que describen como está estructurado el sistema
desde diferentes perspectivas orientadas a los diferentes
involucrados en un proyecto
El proceso es comprensible
La metodología de PU es más adaptable para proyectos de
largo plazo
Entre las desventajas tenemos:

El método de PU requiere costos de dedicación altos por lo que
no es conveniente usarlo en procesos de un proyecto pequeño.
Si el proceso no se aplica bien desde el inicio el PU se puede
volver muy grande y difícil, tanto para aprender como para
administrar
Una cantidad sustancial de tiempo se gasta en tratar de
adecuar el PU a cada proyecto. Aquí, también, se corre el
riesgo de volverse un esclavo del proceso y perder de vista la
razón del proceso.
14
__________________________________________________________________________________
Es un proceso pesado
Se basa mucho en la documentación
Dado que los procesos a ser manejados por el software de Nómina de
la UTM son medianamente grandes es necesario tener un proceso de
desarrollo bien definido y bien gestionado para lograr un proyecto
productivo en lugar de otro que fracase al poco tiempo.
Conseguirlo no es tarea fácil, si no se emplea una metodología de
desarrollo adecuada, es por ello que luego de analizar los pro y contra
se escogió el Proceso Unificado como la mejor alternativa, permite
tener comunicación constante con los usuarios involucrados
minimizando de este modo errores al final del proceso y además nos
permite verificar desde las primeras etapas la calidad del producto,
todo esto compensa con el hecho de que el proceso sea un poco
pesado y requiera mucha documentación, tareas que indudablemente
son necesarias.
2.3 Análisis de Requisitos
Constituye la tarea de averiguar lo que se desea construir obteniendo

información de los interesados con el fin de conseguir la información
correcta con la interpretación adecuada. Es imprescindible saber
identificar los requerimientos y en base a ello poder determinar el
producto a desarrollar. El presente proyecto tiende a satisfacer las
necesidades actuales, sin embargo, no determina que será la única
versión existente sino por el contrario con el tiempo se la irá
mejorando de acuerdo a nuevas tendencias.
2.3.1 Recolección de hechos de información
Comprende el análisis de la situación actual de la Universidad para

identificar los nuevos requerimientos que dan origen al nuevo sistema.
Para lograr este objetivo se tienen algunas técnicas de recolección de

información que se aplicarán según las necesidades de obtención de
información.
La Entrevista.- [3].
Es una de las técnicas más utilizadas sobre todo al inicio del

proyecto, se trata de una conversación que se establece entre
el investigador y los usuarios o directivos de la empresa con el
fin de obtener la opinión del entrevistado y sus sentimientos
acerca del estado actual del sistema, los objetivos de la
organización y los procedimientos informales.
15
__________________________________________________________________________________
Toda entrevista por pequeña que parezca debe ser

debidamente preparada, pero siempre debemos pensar en un
paso al que le podríamos llamar el paso cero, que es el
analizarse a si mismo y buscar sus preferencias y sus
perjuicios, esto le ayudará a evitar que se paralice frente a los
hechos. Recordemos que quien tiene que hablar es el
entrevistado no nosotros.
Además es importante recordar que la persona entrevistada

conoce los hechos mucho mejor que nosotros, pero por
tratarse de opiniones a veces subjetivas, debemos verificar la
veracidad de las respuestas recibidas para lo cual podemos
valernos de registros, en todo caso no podemos dejar de lado
las opiniones ya que de estas podemos obtener información
relacionadas con los objetivos del sistema y de las cosas que
está causando preocupación u agrado al sistema.
La entrevista se la realiza bajo los siguientes aspectos:

o Las opiniones ayudan a ver que es lo que el
entrevistado piensa del sistema y cual es su posición
frente a la realidad de la empresa.
o Los objetivos muestran las necesidades de cambio que
se pretenden alcanzar con el proyecto.
o Los sentimientos pueden darnos la pauta de las áreas
en donde hay problemas
o Los procedimientos informales son la manera de
resolver las cosas utilizada por los usuarios aunque esta
no esté documentada en el manual de procedimientos
de la empresa.
El realizar una entrevista no es tan fácil, se debe tener facilidad

para comunicarse con el entrevistado, hay que ser capaces de
reorientar la entrevista en caso de que se estén desviando los
temas, mucha capacidad de retención de detalles relacionados
con los gestos, con la manera de vestir del entrevistado, con el
tipo de orden de la oficina, etc.
Todos estos puntos fueron tomados en cuenta al realizar las
entrevistas a los usuarios del proceso actual, que son
precisamente los usuarios del nuevo software. Fue difícil hacer
que las personas suspendan sus labores y acepten la
entrevista, es por ello que me dirigí a los jefes inmediatos de
cada uno de ellos y explicar lo importante que es para la
institución la realización del presente trabajo y solicitar a la vez
el permiso para que puedan atenderme, estas personas
accedieron favorablemente y autorizaron a su personal para
que me atiendan.
16
__________________________________________________________________________________
Con el permiso respectivo pude hacer las entrevistas en el

Departamento de Recursos Humanos a: Ing. Rosa
Campoverde Muñoz, Sra. María del Cisne Pacheco Carvajal;
en el Departamento de Remuneraciones a: Ing. Amparito
Delgado Súarez, Ing. Adelaida Gía Bustamante, Lcda. Pilar
Plaza Criollo; y en el Departamento de Contabilidad a la Ing.
Martha Pizarro Aguirre. El desenvolvimiento de las entrevistas
se resumen en el Anexo 1.
La Observación
Consiste en observar a las personas cuando efectúan su

trabajo. Como técnica de investigación, la observación tiene
amplia aceptación científica. El propósito de la observación es
múltiple: permite al analista determinar que se está haciendo,
como se está haciendo, quien lo hace, cuando se lleva a cabo,
cuanto tiempo toma, dónde se hace y por que se hace.
El analista de sistemas puede observar de tres maneras

básicas. Primero, puede observar a una persona o actitud sin
que el observado se de cuenta y su interacción por parte del
propio analista. Quizá esta alternativa tenga poca importancia
para el análisis de sistemas, puesto que resulta casi imposible
reunir las condiciones necesarias. Segundo, el analista puede
observar una operación sin intervenir para nada, pero estando
la persona observada enteramente consciente de la
observación. Por último, puede observar y a la vez estar en
contacto con las personas observadas. La interacción puede
consistir simplemente en preguntar respecto a una tarea
específica, pedir una explicación, etc.
Esta es la manera más adecuada por lo tanto es la que

utilizamos en el desarrollo de la observación.
Para poder proponer el software nuevo es necesario conocer el

actual y es por ello que a más de las entrevistas realicé
observación de las tareas que los usuarios efectúan y al mismo
tiempo preguntar cómo y porqué realizan tal o cual tarea. De
esto pude determinar que los procesos que realizan
manualmente son muchos, lo cual hace que las tareas sean
repetitivas. Por ejemplo cuando ingresa un empleado nuevo se
registran sus datos en el Departamento de Recursos Humanos
y luego estos papeles son transferidos al Departamento de
Remuneraciones en donde nuevamente registran los mismos
datos.
Otra característica importante de la observación es que me

transmitió una idea más clara del proceso pues una cosa es
entender solo con la explicación del cliente y otra muy diferente
es complementar lo dicho con la práctica misma. Además
17
__________________________________________________________________________________
ayuda a percibir en una etapa temprana ciertos errores y tratar

de no cometerlos en el desarrollo del nuevo.
2.3.2 Diagramas del proceso actual
Un proceso se define como un conjunto de tareas, actividades o

acciones interrelacionadas entre sí que, a partir de una o varias
entradas de información, materiales o de salidas de otros procesos,
dan lugar a una o varias salidas. (Anexo 3)
A través de entrevistas y la observación directa se ha identificado el

proceso actual de generación de nómina de la UTM
Como ya se ha mencionado, el proceso que actualmente sigue la

UTM en su mayoría se basa en tareas manuales lo que hace que
existan actividades repetitivas dando origen a errores los cuales se
producen especialmente en el registro de datos de los empleados,
pues, a pesar de tener los mismos documentos se pueden equivocar
en el ingreso de datos en uno de los dos Departamentos (Recursos
Humanos o Remuneraciones) lo que hace que no exista uniformidad
en la información. Por ejemplo: el Departamento de Recursos
Humanos se equivocó y envió los documentos asignado a dos
personas diferentes un mismo número de cédula en el momento en
que el Departamento de Remuneraciones realiza la transferencia para
el pago del sueldo, por tener el mismo número se sumó los dos
sueldos y se acreditó a una sola persona.
La nómina de pagos del personal contratado se elaboran en Excel, los

errores que suelen suceder son: fórmulas mal aplicadas, se dañan los
archivos y consecuentemente se pierde la información, trabajo muy
tedioso.
El usuario de Contabilidad para hacer el asiento de diario y luego su

contabilización tiene que ingresar todos los valores que afectaron en
la remuneración mensual a partir del balance general entregado por el
departamento de Remuneraciones. Duplicidad de trabajo.
Es importante entonces la implementación de un software nuevo que

supere todos los inconvenientes antes indicados.
2.3.3 Diagramas del proceso requerido
La información recogida nos dio una clave para diseñar un proceso

propuesto que sea más óptimo y que se acople a las nuevas
necesidades se ha determinado el siguiente proceso requerido para la
generación de nómica de la UTM. (Anexo 4)
El proceso requerido propuesto es el resultado del interés por
solucionar la generación de la nómina de pago de los empleados de la
18
__________________________________________________________________________________
UTM tomando como base el proceso actual y los requerimientos de

los interesados.
Dentro de las ventajas que se obtendrán tenemos:
Eliminación de procesos repetidos
Automatización de procesos manuales
Exactitud de la información
Actualización de datos de empleados a través de nuevo módulo
de RR. HH.
Agilidad en los procesos
Entre las mejoras realizadas al proceso se puede anotar:
Integración de la información, los tres departamentos (Recursos
Humanos, Remuneraciones y Contabilidad) tendrán acceso a la
misma información.
Permitir al usuario de Contabilidad contabilizar el asiento de
diario sin necesidad de volver a digitar todos los movimientos.
Dejar abierta la posibilidad de integrar el sistema con las
secretarías de las facultades para el registro de valores por
concepto de multas.
2.4 Visión del sistema

El proyecto de implementación del software de Nómina nace de la
evaluación objetiva de las necesidades y potencialidades de la
Universidad Técnica de Machala. Dicha evaluación parte de los
puntos de vista individuales o departamentales que se han
identificado como con impacto sobre lo desarrollado, no escatimando
esfuerzos en ningún momento para lograr la inclusión de todos los
requisitos que de estos puntos de vista se desprenden.
El tener contacto con el usuario es la mejor manera de saber lo que el

usuario desea y a donde debe orientarse el desarrollo del proyecto, es
por ello que lo más relevante en la elaboración de este proyecto es el
lograr percibir el deseo grande que tienen los usuarios de que se les
provea de una herramienta de trabajo ágil, segura y fácil de manejar
para poder dejar de lado la duplicidad de tareas.
El presente proyecto nace para atender la situación particular de

emitir la Nómina de Pagos, y atacar problemas y oportunidades
específicos, que no solo justifican el esfuerzo sino que le dan forma y
dirección al proyecto.
Después de indagar en los retos y oportunidades que motivan el

desarrollo del sistema, es posible hacer un recuento de las personas
involucradas en el proyecto, esto es: relacionar cada una de las
problemáticas y oportunidades con una persona o grupo de personas.
19
__________________________________________________________________________________
Por ello, se hace una descripción detallada de cada uno de los grupos
involucrados, haciendo mención de cual va a ser su participación
dentro del proyecto. Luego de indagar se anota un recuento de las
necesidades encontradas tendientes a solucionar la problemática de
cada uno de ellos, esto permitirá definir mejor las características del
sistema.
Para lograr el producto deseado es necesario tener presente

consideraciones importantes que aseguren la satisfacción de las
necesidades implícitas y que lleven a prevenir problemas conocidos
para lo cual se detalla los requerimientos del sistema y los
requerimientos del producto en sí. Existen además necesidades que
se desprenden de la elaboración del software por lo es necesario
anotarlas como Requerimientos no contemplados, lo cual deja abierta
la posibilidad de implementarlo después. Además, esta visión inicial
podría ser actualizada si se evalúa algún requerimiento nuevo que
amerite ser contemplado.
2.5 Aprendizajes de la Fase
Es de suma importancia elegir la metodología adecuada, así como las

herramientas de implementación adecuadas, es por ello que para el
desarrollo del presente proyecto se ha seleccionado la metodología
de Proceso Unificado, la misma que nos proporciona todas las
bases para llevar al éxito la elaboración del software, y se ha
combinado con técnicas de desarrollo tradicionales.
En pocas palabras puedo decir que el PU es una metodología que

intenta integrar todos los aspectos a tener en cuenta durante todo el
ciclo de vida del software a desarrollar. El presente documento nos
proporciona las guías para poder conocer todo el camino a recorrer
desde antes de empezar la implementación, con lo que se asegura la
calidad del producto final, así como también el cumplimiento en la
entrega del mismo.
Esta metodología se basa en un modelo incremental en el que se

definen cuatro fases: Inicio, Elaboración, Construcción y Transición; y
en cada una de ellas podemos obtener productos parciales
permitiéndonos determinar si los productos están teniendo relación
con la solución a la cual queremos llegar.
El usar esta metodología me ha significado una gran ayuda pues ha

permitido ir corrigiendo desde el inicio alguna idea mal concebida, y
no esperar hasta la fase de implementación para hacerlo, lo que es
sin duda alguna una pérdida de tiempo.
20
__________________________________________________________________________________
Cometeríamos un gran error el pensar que crear un software implica

desarrollar su código y nada más, hoy se ha demostrado que es muy
importante una investigación preliminar en donde el usuario o cliente
es el actor principal puesto que es quien, a través de la entrevista y la
observación, ha permitido recabar la información de las necesidades
del usuario para esquematizar el producto a desarrollar. Todos los
datos proporcionados por el usuario han sido resumidos en el
documento de visión.
Si al principio tenía mis dudas de si el usar esta metodología era

buena idea, hoy concluyo que el Proceso Unificado de Desarrollo de
Software es un medio útil para aprender las mejores prácticas
actuales en el desarrollo de software.
2.6 Bibliografía
[1] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James; (2004): El

Proceso Unificado de Desarrollo de Software (en linea)[citado
el 12 de Noviembre 2008). Adison Wesley-España. Disponible en
http://awl.com/cseng/otseries/.
[2] OLGUIN ESPINOZA, José Martín; (2007): Proyectos de Investigación

(en línea) [citado el 12 de Noviembre del 2008]. Disponible en
http://yaqui.mxl.uabc.mx/ molguin/as/RUP.htm
[3] ABAD, Patricio: (2003): Guía Didáctica Sistemas I. Universidad Técnica

Particular de Loja.
[4] SG SOFTWARE GURU; (2009): Desarrollo de Software (en línea)

[citado el 13 de Noviembre del 2008]. Disponible en
http://www.sg.com.mx/content/view/4/11/
[5] PRESSMAN, Roger S.; (2006): Ingeniería del Software (en linea)
[citado el 15 de Noviembre 2008). McGraw-Hill Interamericana -
México. Disponible en http://awl.com/cseng/otseries/.
21
__________________________________________________________________________________
3. Fase 2: DISEÑO DE LA ARQUITECTURA
3.1 Introducción
“El Diseño se define como el proceso de aplicar ciertas técnicas y

principios con el propósito de definir un sistema, con suficientes
detalles como para permitir su interpretación y realización física” [1].
En esta fase se estructura y formaliza la acción y quedan establecidos

los rasgos definitivos del proyecto. Para esta fase se toman como
partida los análisis realizados en la fase de identificación
La importancia del diseño de la arquitectura se puede definir en una

sola palabra Calidad, dentro del diseño es donde se fomenta la
calidad del Proyecto. El diseño debe proporcionar una completa idea
de lo que es el Software, enfocando los dominios de datos, funcional y
comportamiento desde el punto de vista de la Implementación.
3.2 Herramientas de Modelado
“El Lenguaje Unificado de Modelado (UML) es un lenguaje estándar

de modelado para software, permite a los desarrolladores visualizar
los resultados de su trabajo en esquemas o diagramas
estandarizados” [3].
Todos los esquemas del software de Nómina han sido preparados

basados en el UML, pues es el lenguaje que utiliza el Proceso
Unificado, además de que proporciona una semántica clara y
universal lo que facilita la representación de los datos tanto para el
desarrollador actual como para los que deseen conocer o darle
mantenimiento.
El UML es un lenguaje para la visualización, especificación,

construcción y documentación de los productos del sistema
obteniendo los siguientes diagramas:
Casos de Uso.- Una descripción de un conjunto de secuencias

de acciones
Diagramas de secuencia.- Un diagrama de interacción que
hace énfasis en la ordenación temporal de los mensajes.
Diagrama de clases.- Un diagrama que muestra un conjunto de
clases, interfaces
Diagrama de físicos o de implementación.- Diagrama que
muestra un conjunto de nodos y sus relaciones
22
__________________________________________________________________________________
3.3 Arquitectura del Software
“La arquitectura del software de un programa o sistema de cómputo es

la estructura o las estructuras del sistema, que incluyen los
componentes del software, las propiedades visibles externamente de
esos componentes y las relaciones entre ellos” – Bass, Clement y
Kazman. [5]
“La arquitectura no es el software operativo. En cambio, es una

representación que permite que un ingeniero de software: 1) analice la
efectividad del diseño para cumplir con los requisitos establecidos, 2)
considere opciones arquitectónicas en una etapa en que aún resulta
relativamente fácil hacer cambios al diseño, y 3) reduzca los riesgos
asociados con la construcción del software” [5]
3.3.1 Arquitectura de la Solución
La arquitectura elegida para desarrollar la solución del SNP es una de

Tres Capas, la misma que facilita el desarrollo, mantenimiento y
mejora el rendimiento. La estructura de la arquitectura de tres capas
es la siguiente:
Capa de Presentación
Capa Lógica
Capa de Datos
En el Anexo No. 7 se hace referencia a la representación

arquitectónica del SNP, así como la estructura de cada capa dentro
del software.
La figura 3.1 muestra la estructura de al Arquitectura de Tres Capas.
23
__________________________________________________________________________________
Figura 3.1 Estructura de Arquitectura de Tres Capas
3.4 Plataforma de Desarrollo
3.4.1 Plataforma de la Base de Datos
Dado que la Universidad Técnica de Machala cuenta con un sistema

contable que está trabajando sobre el gestor de base de datos
ORACLE 10g Release 2, se ha definido que el Software a
implementar utilice el mismo motor y además porque se considera a
Oracle como uno de los sistemas de bases de datos más completos
destacándose por su:
Soporte de transacciones
Estabilidad
Escalabilidad
Soporte Multiplataforma
Entre las ventajas más importantes podemos anotar:
Puede ejecutarse en todas las plataformas

Seguridad de la información
Compatibilidad con diferentes sistemas operativos
Permite implementar diseños activos, con triggers y
procedimientos almacenados
3.4.2 Lenguaje de Programación
En el desarrollo de la presente solución se ha utilizado el lenguaje de

programación Visual Basic 2005 por cuanto la UTM tiene aplicaciones
basadas en este lenguaje y de esta manera mantener uniformidad en
24
__________________________________________________________________________________
el lenguaje. Además por considerar ésta como la herramienta más

productiva para crear aplicaciones que se ejecutan en el sistema
operativo Windows .
Entre las principales ventajas encontradas para utilizar este lenguaje

tenemos:
Lenguaje orientado a objetos.

Lenguaje sencillo y popular, la compilación en segundo plano
proporciona información al instante y señala los errores.
Control más avanzado para los desarrolladores, permite
acceder con facilidad a los proyectos más recientemente y
presenta un cuadro de herramientas ampliado en donde
muestra una vista dinámica de los componentes del proyecto.
Plantillas y asistentes que permiten ahorrar tiempo
Ayuda disponible al instante
Funciones de programación ampliadas, la herencia permite
reutilizar el código de cualquier lenguaje basado en .Net. El
control de excepciones estructurado proporciona un código de
control de errores fácil de mantener
3.5 Metodología de Programación
“Una metodología de programación es un conjunto o sistema de

métodos, principios y reglas que permiten enfrentar de manera
sistemática el desarrollo de un programa que resuelve un problema
algorítmico” [7]
En el desarrollo del SNP se ha utilizado la programación orientada a

objetos, en razón de que el problema es examinado de acuerdo al
análisis en un conjunto de objetos que interactúan entre sí.
Las principales características del la programación orientada a objetos

se centran en la abstracción, el encapsulamiento, la herencia y
algunos aspectos derivados del diseño estructurado [8].
Abstracción.- Es la representación de una realidad en forma de

objetos, dividiendo sistemas complejos en conjunto de subsistemas.
Encapsulamiento.- Permite a los objetos elegir la información que va

a ser publicada y la que la va a mantener oculta con respecto al resto
de los objetos. Para lograrlo los objetos presentan sus métodos como
interfaces públicas y sus atributos como datos privados siendo de
esta manera inaccesible desde otro objeto.
Herencia.- Significa que las clases no están aisladas, sino que se

relacionan entre sí. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen. Permite la
creación de nuevas clases a partir de otra ya existente permitiendo
25
__________________________________________________________________________________
compartir su comportamiento sin tener que volver a implementarlo.

Cuando un objeto hereda de más de una clase se dice que hay
herencia múltiple.
3.6 Diseño de Interfaces
El diseño de interfaces es una tarea que ha adquirido relevancia en el

desarrollo de un sistema. La calidad de la interfaz de usuario puede
ser uno de los motivos que conduzca al sistema al éxito o al fracaso.
Los principios que se presentan son de utilidad para creación de
interfaces funcionales y de fácil operación [9].
La interfaz de usuario de un programa es un conjunto de elementos

hardware y software de una computadora que presentan información
al usuario y le permiten interactuar con la información y con el
computador. Si la interfaz de usuario está bien diseñada, el usuario
encontrará la respuesta que espera a su acción. Si no es así puede
ser frustrante su operación, ya que el usuario habitualmente tiende a
culparse a sí mismo por no saber usar el objeto.
En el desarrollo del SNP se ha tomado en cuenta el hecho de que los

programas son usados por usuarios con distintos niveles de
conocimientos, desde principiantes hasta expertos, orientando
entonces su diseño a satisfacer al usuario en general.
3.6.1 Diseño general de interfases del sistema
Antes de implementar los formularios y los informes, hay que diseñar

su aspecto. Es por ello que para el diseño de interfaces de usuario del
Sistema de Nómina para la Universidad Técnica de Machala se ha
tenido en cuenta las siguientes recomendaciones:
Se ha utilizado títulos que sean significativos, es decir; que

identifican el propósito del informe o formulario.
Las instrucciones dadas son breves y fáciles de entender.
Los campos se han agrupado de una forma lógica y secuencial.
Se ha hecho que el aspecto del informe o formulario sea
atractivo a la vista.
Para etiquetar los campos se ha utilizado nombres familiares.
Se ha utilizado una terminología y abreviaturas consistentes.
Se ha hecho un uso razonable y consistente de los colores.
Los datos de entrada están presentados en un espacio visible y
delimitado.
Se ha permitido un uso sencillo y adecuado del cursor.
Se ha facilitado la corrección ya sea carácter por carácter y de
campos completos.
Se presentan mensajes de error para los valores incorrectos.
Se ha marcado los campos obligatorios.
26
__________________________________________________________________________________
La validación de los datos se hará al final, después que todos

los datos han sido ingresados, indicando con un mensaje el
campo cuyos datos no están de acuerdo.
3.6.2 Prototipo de pantallas
Los prototipos de pantalla permiten a los usuarios y analistas evaluar

la posición de la información sobre la pantalla, la conveniencia de los
encabezados y la utilidad de mensajes e instrucciones también
proporcionan una manera para obtener las reacciones de los usuarios
hacia la cantidad de información presentada sobre la pantalla de
visualización.
3.6.2.1 Descripción de componentes
PANTALLA PRINCIPAL.
Barra de Título: se utiliza para desplegar el título de la pantalla

desplegada, que es el nombre del sistema Nómina y el sello de la
Universidad, la barra del título tendrá un color diferente al resto de las
ventanas desplegadas.
Menú Principal: contiene un conjunto de botones que permiten

desplegar la totalidad de las pantallas del sistema. Además indica el
nombre del usuario que está utilizando el sistema, el cual ha sido
previamente ingresado con una contraseña como requisito para
acceder al sistema y también contiene el botón de cerrar o reinicio de
sesión.
Año de Proceso o Ejercicio Fiscal: Indica el año del ejercicio fiscal en

el cual está trabajando, el mismo que previamente ha sido ingresado
por el usuario.
Area de Trabajo: es el lugar donde se despliegan las pantallas que

son activadas a través del Menú Principal.
Maximizar /Restaurar Ventana: botón que se utiliza para ampliar o

reducir el tamaño de la pantalla.
Minimizar Ventana: control que se utiliza para quitar de primer plano

de trabajo una ventana, sin cerrarla.
Cerrar Ventana: control que se usa para cerrar una ventana.
27
__________________________________________________________________________________
Usuario del
Cerrar Minimizar
Barra de Sistema
Sesión Ventana
Titulo
Maximizar
Ventana
Menú
Principal Cerrar
Ventana
Área de
Trabajo
Año de
Proceso
Figura 3.2 : Formato de la pantalla principal
PANTALLA DE MANTENIMIENTO.
Barra de Título del Formulario: se utiliza para desplegar el título del

formulario desplegado, que es el nombre de la Opción a la cual se
accede.
Botón de Avanzar y Retroceder: permite recorrer los registros uno por

uno o directamente al inicio o al final de la tabla de datos.
Botón de Añadir: al presionar este botón se presentará la pantalla con

los campos vacíos listos para ser ingresados.
Botón de Modificar: mostrará en pantalla todos los datos permitiendo

seleccionar y corregir solo el campo deseado.
Botón de Borrar: eliminará los datos previa una confirmación de la

acción.
Botón de Buscar: para las opciones de modificar, y borrar es

necesario primero buscar el registro, esta búsqueda permitirá
recuperar el registro y mostrarlo en pantalla.
28
__________________________________________________________________________________
Area de detalle de Campos: es el lugar donde se despliegan los datos

que son activados a través de los botones.
Maximizar /Restaurar Ventana: botón que se utiliza para ampliar o

reducir el tamaño de la pantalla.
Minimizar Ventana: control que se utiliza para quitar de primer plano

de trabajo una ventana, sin cerrarla.
Cerrar Ventana: control que se usa para cerrar una ventana.
Barra de
Titulo Minimizar
Botón Botón Botón Botón Ventana
Formulario Añadir Modificar Borrar Buscar Maximizar
Ventana
Botón de
avanzar y Cerrar
retroceder Ventana
Detalle de
Campos
Figura3.3 Formato de la pantalla mantenimiento
El encadenamiento de las pantallas está determinado a partir de la

pantalla principal del sistema, permitiendo desplegar cualquiera de las
pantallas utilizadas para las operaciones.
3.7 Aprendizaje de esta Fase
La meta principal de este proyecto se enfoca hacia el desarrollo de un

software de alta calidad, viable y efectivo, para alcanzarlo es
necesario la integración de los principios, prototipos y heurísticas de
evaluación que se logra precisamente durante el proceso de diseño de
la arquitectura.
29
__________________________________________________________________________________
Está demostrado claramente a lo largo del desarrollo de esta fase que

sin un buen diseño de los casos de uso, de la base de datos, la
creación de interfaces, resulta realmente imposible conseguir el
modelo deseado por el usuario, el cual es el punto más importante
para garantizar la aceptación del sistema.
Lo que como programadores queremos es siempre ir directamente al

código y en el camino ir solucionando problemas que a la larga
resultan en el fracaso del proyecto, invertir tiempo en diseñar no es
pérdida sino más bien significa un ahorro en el sentido de que no
perdemos demasiado tiempo al final sino poco tiempo al inicio. Y esto
es precisamente lo que he aprendido, diseñar desde lo más mínimo
como es una pantalla hasta la completa base de datos. Al igual que un
arquitecto con el plano en mano es mucho más fácil iniciar la
construcción, en nuestro caso con todo definido es indudable que la
programación resultará rápida y sencilla.
3.8 Bibliografía
[1] ENCICLOPEDIA LIBRE; (2009): Diseño de la Arquitectura (en línea)

[citado el 15 de Noviembre del 2008). Disponible en
http://es.wikipedia.org/wiki
[2] MICROSOFT VIRTUALIZATION; (2009): Diseño de Arquitectura (en

línea) [citado el 4 de Diciembre del 2008]. Disponible en
http://www.clikear.com
[3] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James; (2004): El

Proceso Unificado de Desarrollo de Software (en linea)[citado
el 12 de Noviembre 2008). Adison Wesley-España. Disponible en
http://awl.com/cseng/otseries/.
[4] SILBERSCHATZ, Abraham; KORTH, Henry; SUDARSHAN, S; (1999):

Fundamentos de Bases de Datos [citado el 12 de Noviembre del
2008). McGraw-Hill-España.
[5] PRESSMAN, Roger S.; (2006): Ingeniería del Software (en linea)
[citado el 15 de Noviembre 2008). McGraw-Hill Interamericana -
México. Disponible en http://awl.com/cseng/otseries/.
[6] ALARCON HERRERA, Erika; CROVETTO HUERTA, Christian; (2004):

Visual Basic 2005. Megabyte S.A.C
[7] UNIVERSIDAD NACIONAL DE COLOMBIA; (2005): Introducción a la

Programación (en línea) [citado el 20 de Mayo del 2009]. Visual Basic.
Colombia Disponible en
http://www.virtual.unal.edu.co/cursos/ingenieria/.
30
__________________________________________________________________________________
[8] MEYER, Bertrand; (1999): Construcción de Software Orientado a

Objetos. Prentice Hall-Madrid.
[9] PIATTINI VELTHUIS, Mario G; MANZANO VILLALON, José Antonio;

CERVERA BRAVO, Joaquín, FERNANDEZ SANZ, Luis; (2000):
Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión.
Alfaomega grupo Editor S.A. México D.F.
31
__________________________________________________________________________________
4. Fase 3: DESARROLLO DE LA SOLUCION
4.1 Introducción
En los últimos años el software se ha convertido en un componente

vital para el desarrollo de las instituciones, un arma competitiva muy
importante para lograr el éxito. Es por ello que se ha tomado muy en
cuenta para el desarrollo del Software de Nómina para la Universidad
Técnica de Machala un lenguaje de programación actual (Visual Basic
2005) utilizando además técnicas y metodologías estandarizadas con
el objetivo de obtener una solución de desarrollo de calidad elevada y
capaz de ajustarse a los requerimientos de la Universidad.
Para llevar a cabo el desarrollo de la solución ha sido necesario

asegurarnos de los requerimientos del usuario y de que éstos se
puedan implementar. Así, el objetivo principal es producir un modelo o
representación del sistema que se va a construir. El proceso del
desarrollo de la solución se lleva a cabo mediante la intuición y la
experiencia, así como mediante un conjunto de criterios que permiten
determinar la calidad del producto.
La fase de desarrollo expresa como ha progresado el desarrollo del

software y cuanto desarrollo puede requerir. Cada versión importante
del sistema pasa generalmente a través de una etapa en la que se
agregan las nuevas características (etapa alfa), después una etapa en
donde se eliminan errores activamente (etapa beta), y finalmente una
etapa en donde se han quitado todos los bugs importantes (etapa
estable). Las etapas intermedias pueden también ser reconocidas. Las
etapas se pueden anunciar y regular formalmente a medida que
avanza el desarrollo, pero los términos se utilizan a veces de manera
informal para describir el estado del producto.
32
__________________________________________________________________________________
4.2 Implementación de la base de datos

Entre la base de datos física (el almacenamiento real de los datos) y
los usuarios de sistema existe un medio o interfaz de software que
recibe el nombre de Gestor de Base de Datos (SGBD) y que es el
responsable de tratar todas las peticiones de información de los
usuarios, por lo tanto es un conjunto de programas de propósito
general que permite controlar el acceso y la utilización de la base de
datos por los usuarios, para incluir, modificar o recuperar información,
incluyendo estaciones para conseguir la independencia, la integridad y
la seguridad de los datos y la ocurrencia de usuarios. Las formas de
almacena información en una computadora son variadas y ello da
lugar a distintos modelos de organización de la base de datos:
jerárquico, red, relacional y orientado a objetos.
En nuestro caso utilizaremos al SGBD Oracle ya que éste está

concebido con el fin de manejar grandes cantidades de información,
además de admitir conexiones concurrentes de multitud de usuarios
(entorno multiusuario) hacia los mismos datos. Oracle aporta un
SGBD que está ubicado en un hardware específico (Servidor Compaq
Proliant 370) y bajo un sistema operativo determinado (Windows
Server 2003).
4.2.1 Funcionalidades del SGBD Oracle
Las principales funcionalidades aportadas por todo el SGBD Oracle

son:
Soporte y tratamiento de una gran cantidad de datos (Gbytes)

Soporte de una gran cantidad de usuarios accediendo
concurrentemente a los datos
Seguridad de acceso a los datos, restringiendo dicho acceso
según las necesidades de cada usuario.
Integridad referencial en su estructura de base de datos
Conectividad entre las aplicaciones de los clientes en sus
puestos de trabajo y el servidor de datos Oracle
Portabilidad
Compatibilidad
4.2.2 Análisis inicial del SGBD Oracle
Para establecer el entorno de trabajo en Oracle necesitamos:
Software Oracle para Servidor: Una versión determinada

específicamente diseñada para sistema operativo Windows
33
__________________________________________________________________________________
Server 2003. Este software incluye los ejecutables para el

funcionamiento del propio gestor de la base de datos, un
conjunto de herramientas para e tratamiento de la información y
un software específico para que sean posibles las conexiones
de los usarios al servidor.
Software Oracle para cliente: Este software se ubicará en los
puesto de trabajo de los usuarios, el cual estará formado por un
conjunto de herramientas específicas.
Archivos de base de datos: La base de datos en sí, los cuales
serán creados a través de herramientas como el Oracle
Maestro, Enterprise Manager o directamente con comandos
específicos de Oracle. La ubicación de la base de datos es
sobre discos del propio servidor donde se ha establecido el
Oracle Server Software
Recursos suficientes en nuestro servidor: Determinar los
recursos como cantidad de memoria, discos y unidades
centrales de proceso que van a ser necesarias para un correcto
funcionamiento.
4.2.3 Pasos a seguir para crear una base de datos Oracle
Para crear la base de datos Oracle se siguen los siguientes pasos

Decidir nombre único para la instancia, nombre de base de
datos, tamaño del bloque oracle, set de caracteres, número
máximo de archivos de datos, y número máximo de archivos
de redolog
Decidir la estructura de almacenamiento físico de la base de
datos (File system).
Copiar y editar el archivo de parámetros (ini.ora) que permita
inicializar la instancia oracle
Configurar las variables apropiadas del sistema operativo
(ORACLE_SID), otras variables tales como ORACLE_HOME,
ORACLE_BASE deben estar previamente definidas
Crear el archivo de password
Invocar el SQLPLUS y conectarse a la base de datos como
sysdba.
Iniciar la instancia en estado NOMOUNT. En este estado se
crea una base de datos nueva.
Crear la base de datos. Con ayuda de los asistentes se puede
definir: los esquemas, los tablespace, tablas, índices y
secuencias.
34
__________________________________________________________________________________
4.2.4 Scripts de creación de la base de datos
Los conjuntos de instrucciones utilizados para creación de tablas,

paquetes y procedimientos de la base de datos NOMINA son como
se muestran en el Manual del Programador.
4.3 Implementación del framework de trabajo

El Framework representa a una estructura de software compuesta de
componentes personalizables e intercambiables para el desarrollo de
una aplicación. En otras palabras, un framework se puede considerar
como una aplicación genérica incompleta y configurable a la que
podemos añadirle las últimas piezas para construir una aplicación
correcta.
Los objetivos principales que persigue un framework son: acelerar el

proceso de desarrollo, reutilizar código ya existente y promover
buenas prácticas de desarrollo como el uso de patrones.
4.3.1 Ventajas de utilizar un Framework de trabajo
Entre unas de las ventajas tenemos:
El programador no necesita plantearse una estructura global de

la aplicación, sino que el framework le proporciona, podríamos
decirlo así, un esqueleto que hay que llenar.
Facilita la colaboración. Todos sabemos lo difícil que es tratar
de entender el código fuente de otro programador y más aún
poderlo modificar; por tanto, todo lo que sea definir y
estandarizar va a ahorrar tiempo y trabajo a los desarrolladores
que vendrán después.
Es más fácil encontrar herramientas adaptadas al framework
concreto para facilitar el desarrollo
4.3.2 Especificación de rutinas y su descripción
Para la realización del conjunto de rutinas es necesario, en forma

previa, revisar cuales serán los requerimientos a satisfacer. Para esto,
se partirá de la base que dichas rutinas deben ser lo suficientemente
flexibles como para trabajar en cualquier aplicación,
independientemente del tipo de algoritmo de aprendizaje y operación
que se utilice. Con este fin se ha definido rutinas para: buscar, añadir,
borrar, modificar, centrar ventanas, entre otras en donde solo se
cambian los nombres de las tablas a las cuales se quiere accesar.
Véase el Manual del Programador.
35
__________________________________________________________________________________
4.4 Gestión de versiones del software
Durante el trayecto que significa llegar al desarrollo completo de la

solución, han ido surgiendo cambios que son controlados de tal
manera que facilite la administración de cada una de ellas median un
control de versiones.
El haber concluido con el desarrollo del SNP no quiere que es lo

último, no, por el contrario es el inicio quizás de nuevas versiones que
irán surgiendo a medida que la universidad lo requiera.
Por lo tanto una manera de llevar este control es a través de una

biblioteca de software definitivo, donde se guardan copias de todo el
software en producción.
4.4.1 Plan de Gestión de Versiones de Software
La Gestión de Versiones es la gestión de los diversos cambios que se

realizan sobre el código fuente, es por ello que una vez implantado el
Software de Nómina en la Universidad Técnica de Machala, las
versiones que se han ido e irán construyendo se rigen de acuerdo al
siguiente plan de Gestión de Versiones:
Antes de empezar a trabajar en los cambios al sistema se

deberá tener un documento legalmente autorizado por el Jefe
del área que solicita la actualización al SNP.
Antes de implementar, se deberá analizar que elementos de
configuración se verán directa o indirectamente implicados
durante y tras el lanzamiento de la nueva versión.
Implementar las nuevas versiones de software en el entorno de
producción tras su verificación en un entorno realista de
pruebas.
Garantizar que el proceso de cambio cumpla las
especificaciones de la petición de cambio correspondiente.
Asegurar, que todos los cambios se ven correctamente
reflejados en la biblioteca de actualizaciones
Archivar copias idénticas del software en producción, así como
de toda su documentación asociada, para en determinado
momento si fuera necesario revertir la actualización.
4.4.2 Beneficios de la Gestión de Versiones
Los beneficios que se espera obtener luego de aplicar el plan de

control de versiones se resumen en:
El proceso de cambio se realizará sin deterioro de la calidad de

servicio.
36
__________________________________________________________________________________
Las nuevas versiones deben cumplir con los objetivos

propuestos.
Se reduce el número de incidentes por incompatibilidades con
otro software o hardware instalado.
El proceso de pruebas asociado no sólo permite asegurar la
calidad del software a instalar sino que también permite
conocer la opinión de los usuarios sobre la funcionalidad y
usabilidad de las nuevas versiones.
El correcto mantenimiento de la Biblioteca de Software
Definitivo impide que se pierdan (valiosas) copias de los
archivos fuente.
Protección contra virus y problemas asociados a versiones de
software incontroladas.
4.4.3 Clasificación de las Versiones
La referencia o código que utilizará el SNP para definir a cada una de

las versiones será de acuerdo a la importancia o incidencia de los
cambios, y será:
Si los cambios son mayores: Nomina V1.0, Nomina V2.0,

etc.
Si los cambios son menores: Nomina V1.1, Nomina 1.2, etc.
Cambios pequeños de emergencia: Nomina V1.1.1, Nomina
1.1.2, etc
Por cada cambio de versión se elaborará un informe que permitan

evaluar el rendimiento de la versión
4.4.4 Estrategia de Control de Versiones de Software
La estrategia que estamos usando es el versionado, cada vez que se

realiza un cambio se genera una nueva versión del sistema
almacenándose un histórico de versiones lo que facilita la
administración de las distintas, esto es la recuperación de una versión
anterior en caso de ser necesario. El Visual Basic 2005 es una
herramienta que permite, cada vez que se realiza modificaciones al
proyecto, tener una nueva versión para lo cual genera
automáticamente una secuencia de versiones, actualmente la última
versión del software de Nómina para la Universidad Técnica de
Machala es la NOMINA v.10
El almacenamiento de las versiones se las realiza en un Repositorio

en el disco duro del Servidor, el cual permite ahorrar espacio de
almacenamiento, evitando guardar por duplicado elementos comunes
37
__________________________________________________________________________________
a varias versiones o configuraciones y tener un registro de las fechas

y el tipo de cambios realizados.
El desarrollo de este y todos los software siempre es progresivo y

este desarrollo evolutivo debe ser controlado para lo cual, al momento
de generar una nueva versión, se tomará en cuenta lo anotado en el
plan de control de versiones
4.5 Construcción de la aplicación
4.5.1 Objetivo
El objetivo de este manual es dar a conocer los listados del código

fuente del programa realizado, anotando una breve descripción de las
clases, funciones y proyectos; información necesaria para que el
desarrollador entienda los aspectos más relevantes del diseño.
4.5.2 Consideraciones Importantes
En caso de ser revisado el software por otro desarrollador debe tener

en cuenta lo siguiente:
El lenguaje de desarrollo es Visual Basic 2005

Base de Datos Oracle Versión 10g Release 2
La Base de Datos es NOMINA
Las tablas están identificadas con las siglas SNP
La metodología de desarrollo es orientada a objetos
4.5.3 Código fuente depurado
Después de haber pasado por varias pruebas el código depurado es

como se muestra en el Manual del Programador.
4.6 Aprendizajes en esta fase
Durante esta Fase he podido observar como iba progresando el

desarrollo del software y determinar que ciertos procesos tuvieron que
ser desarrollados de una manera diferente a la concebida inicialmente
por necesidades del usuario o como resultado de la validación y
corrección de errores.
Esta ha sido además la Fase del enriquecimiento del conocimiento

pues hubo muchos aspectos en los cuales fue necesaria la
investigación como por ejemplo la instalación del motor de la base de
datos, la definición de paquetes y procedimientos en Oracle, las
cadenas de conexión con la base de datos, entre otros. Todo
38
__________________________________________________________________________________
contribuyó a alimentar la experiencia profesional y poderla aplicar

luego en el campo laboral.
La meta de esta Fase es obtener el producto deseado y

satisfactoriamente se puede dar como tarea cumplida con un alto
grado de satisfacción dada por el usuario. Además se deja sentadas
las bases para posibles actualizaciones las cuales se podrán realizar
tomando en cuenta el plan de gestión de versiones.
39
__________________________________________________________________________________
5. Fase 4: CONTROL DE CALIDAD Y ESTABILIZACION
5.1 Introducción
“Técnicas y actividades de carácter operativo, utilizadas para

satisfacer los requisitos relativos a la calidad, centradas en dos
objetivos fundamentales: mantener bajo control un proceso y eliminar
las causas de defectos en las diferentes fases del ciclo de vida” [1].
El Control de la Calidad en general, son las actividades parea evaluar

la calidad de los productos desarrollados, para asegurar la continua
satisfacción de los usuarios. Está orientado a la prevención.
5.1.1 Calidad y Software
“Calidad es el grado con el que un sistema, componente o proceso

cumple:
Los requisitos especificados
Las necesidades o expectativas del cliente o usuario” [1]
La calidad es sinónimo de eficiencia, flexibilidad, corrección,

confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad.
5.1.2 Obtención de un software con calidad
La obtención de un software de calidad implica la utilización de

metodologías o procedimientos estándares para el análisis, diseño,
programación y prueba del software.
El desarrollo del SNP ha sido concebido en la satisfacción de las

necesidades planteadas por el usuario, basándose en la eficiencia,
confiabilidad, seguridad e integridad. Además de un control o
evaluación continua por la asesora de este proyecto Ing. Audrey
Romero y tomando en consideración los siguientes aspectos:
El SNP ha sido pensado, diseñado y desarrollado como un

producto sujeto a normas de calidad.
El SNP es un producto desarrollado en la comunicación del
usuario con el desarrollador
El énfasis puesto en el proceso de desarrollo ha asegurado un
producto adecuado a los requisitos de los usuarios.
El interés por la calidad no termina con el fin del desarrollo del SNP,
sino que crecerá de forma continua, a medida que el usuario se vuelva
40
__________________________________________________________________________________
más selectivo y comience a rechazar el producto si es poco fiable o

definitivamente no responde a sus necesidades.
5.2 Prueba de Software
La Prueba de Software es un conjunto de herramientas, técnicas y

métodos que hacen a la excelencia del desempeño de un programa.
Las técnicas para encontrar problemas en un programa son
extensamente variadas y van desde el uso del ingenio por parte del
personal de prueba hasta herramientas automatizadas que ayudan a
aliviar el peso y el costo de tiempo de esta actividad. Pero de nada
serviría conocer todas las técnicas de prueba de software, ya que
sería como buscar una aguja en un pajar; sino se define todo el
trabajo previo de control de calidad en el desarrollo de software, ya
que sabemos que mucho mejor que encontrar y solucionar un
problema es prevenir que no ocurra.
5.2.1 Razones para que un programa contenga errores
Arreglar u corregir un problema después que sale a luz es una tarea

relativamente sencilla, ya que se conoce el foco del problema, el
inconveniente está en corregir un error que no está visible o no ha
sucedido todavía.
Los errores se pueden dar por:
Poca o falta de comunicación entre diferentes aplicaciones

(Requerimientos de las aplicaciones).
Complejidad del software
Errores de programación
Requerimiento de cambio en el sistema
Estas consideraciones son las que se han tomado en cuenta en la

revisión previa a la verificación y validación completa del SNP.
5.2.2 Verificación y Validación
Se ha realizado la verificación del SNP mediante la revisión de los

planes, del código, de los requerimientos, de la documentación y las
especificaciones y posteriormente una reunión del desarrollador con
los usuarios para evaluar dichos documentos.
La validación del SNP incluye las pruebas del software y comienza

después que la verificación esté completa.
La verificación y validación del software se lo realiza mediante un plan

de pruebas.
41
__________________________________________________________________________________
5.2.3 Plan de Validación del Software de Nómina para la Universidad

Técnica de Machala
Para lograr un software de calidad como hemos visto es necesario

conocer el producto que se desea obtener para ello debe ser sometido
a un riguroso proceso de pruebas.
Para realizar la validación del SNP, se llevaron a cabo las siguientes

actividades:
Diseño de un Plan de Pruebas (Anexo 8).

Diseño de bitácora de Casos de Prueba, la cual está basada
en la definición de los casos de uso, con los cuales se validan
los requerimientos funcionales del sistema y ayudan a verificar
las expectativas de los usuarios. (Anexo 9).
Pruebas de funcionamiento mediante la cual se verifica la
aceptación adecuada de los datos, procesamiento y
recuperación de los mismos
Pruebas de aceptación, las cuales se llevaron a cabo mediante
encuestas realizadas a los usuarios y las que permitieron
determinar el grado de aceptación de sistema y confirmar que
el producto es el deseado. (Anexo 1)
5.3 Bibliografía
[1] PIATTINI VELTHUIS, Mario G; MANZANO VILLALON, José Antonio;

CERVERA BRAVO, Joaquín, FERNANDEZ SANZ, Luis; (2000):
Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión.
Alfaomega grupo Editor S.A. México D.F.
42
__________________________________________________________________________________
6. Fase 5: IMPLANTACION DEL SOFTWARE
6.1 Introducción
El objetivo de la implantación del Software de Nómina no es

solamente poner el software en producción, sino optimizar e integrar
los procesos utilizando la tecnología de la información.
Antes de empezar a desarrollar el software fue necesario conocer bien

el proceso. El sistema de Nómina interfiriere en las estructuras
administrativas y en el comportamiento de la institución, obligando a
rever las estrategias de acciones. Es preciso identificar lo que la
Universidad necesita controlar, y cual es la información necesaria para
tal control. El Sistema de Nómina está hecho para automatizar los
procesos y no solamente para alcanzar un resultado.
La implantación del software sin la revisión de los procesos podría

resultar en frustraciones posteriores. El software debe suplir la
necesidad de hacer la gestión más dinámica, mejorar la productividad
y generar resultados confiables. Para eso es necesario detallar todo el
trabajo de los departamentos, entender cada requisito.
La implantación del software de Nómina es el resultado de las

actitudes de la Universidad y específicamente de los departamentos
de Recursos Humanos, Remuneraciones y Contabilidad rumbo a la
automatización. Se trata de una transformación del los departamentos
y no solamente de un cambio tecnológico. Será el principal
instrumento de gestión de la Universidad, por eso su selección debe
ser criteriosa y su implementación debe ser considerada una inversión
y no un costo.
Una vez instalado, el software controlará todo el proceso para la

obtención del rol de Nómina de pago, desde el ingreso de un
empleado hasta el registro contable del asiento del la nómina. Cada
nuevo ingreso de datos será registrado y procesado por el sistema,
que distribuirá la información en tiempo real a los departamentos
involucrados. La diferencia es que, por ser integrados y actualizados,
esos datos serán más confiables, claros y seguros.
La Implementación del software de Nómina afectará a la Universidad

como un todo, entonces es importante que el software se adapte a la
Universidad y no la Universidad al software
43
__________________________________________________________________________________
6.2 Implementación de la aplicación
6.2.1 CD instalador del software
El CD adjunto contiene la aplicación completa junto con la base de

datos.
6.2.2 Lista de requerimientos básicos
Computador Pentium 4, 256 MB memoria física, disco duro de

80 gb
.Net framework2.0
Motor de base de datos Oracle 10g release 2
Crystal Reports 8.0
6.2.3 Instrucciones de instalación
6.2.3.1 Instalación de Base de Datos en el Servidor
Instalar y configurar el software administrador del servidor de

Oracle
Base de Datos = UTM
Servicio = UTM
Usuario = usrnomina
Clave = usrnomina
Importar la Base de Datos de Oracle

imp usrnomina/usrnomina@utm file=c:\archivo.dmp full=yes;
6.2.3.2 Instalación de la aplicación cliente
Instalar el administrador del cliente del software de Oracle

Ejecutar desde el CD de instalación el archivo SETUP.EXE
Es importante que la persona que realiza la instalación tenga

conocimientos básicos de Oracle y sea el encargado de comprobar
que exista la conexión entre el computador cliente y el servidor.
6.3 Documentación de usuario
6.3.1 Introducción
La documentación de usuario es el conjunto de información que nos

dice que hacen los sistemas, cómo lo hacen y para quien lo hace.
La documentación consiste en material que explica la operación del

sistema. Es esencial para proporcionar entendimiento de un sistema
para enseñar a los usuarios como interactuar con el sistema.
44
__________________________________________________________________________________
El manual de usuario expone los procesos que el usuario puede

realizar con el sistema implantado. Para lograr esto, es necesario que
se detallen todas y cada una de las características que tiene los
programas y la forma de acceder e introducir información. Permite a
los usuarios conocer el detalle de qué actividades ellos deberán
desarrollar para la consecución de los objetivos del sistema. Reúne la
información, normas y documentación necesaria para que el usuario
conozca y utilice adecuadamente la aplicación desarrollada.
6.3.2 Objetivos
Que el usuario conozca cómo preparar los datos de entrada

Que el usuario aprenda a obtener los resultados y los datos de
salida
Servir como manual de aprendizaje
Servir como manual de referencia
Definir las funciones que debe realizar el usuario
Informar al usuario de la respuesta a cada mensaje de error.
6.3.3 Importancia del manual de usuario
El manual de usuario facilita el conocimiento de:
Los documentos a los que se puede dar entrada por

computadora
Los formatos de los documentos
Las operaciones que utiliza de entrada y salida de los datos
EL orden del tratamiento de la computadora con los datos
introducidos
El momento en que se debe solicitar una operación deseada
Los resultados de las operaciones realizadas a partir de los
datos introducidos
6.3.4 Funcionalidades documentadas
El Sistema de Nómina ha sido creado con el objetivo de integrar

Recursos Humanos, Remuneraciones y Contabilidad. El módulo de
Recursos Humanos permite el registro, procesamiento y recuperación
de datos de los empleados, con el propósito de mecanizar los
procesos que conllevan el hecho de plasmar movimientos históricos o
acciones de personal de cada uno de sus miembros que conforman la
planta docente y administrativa de la Universidad, de esta manera
permite tener actualizada la información a nivel local. En este módulo
se podrá consultar información de los empleados por cada una de las
facultades y tener un mejor de los datos de cada uno de ellos.
El módulo de Remuneraciones implica el cálculo de la remuneración
mensual, para ello realiza el ingreso de todos los rubros que inciden
45
__________________________________________________________________________________
en el cálculo, así como también la acumulación de todos los valores

para el cálculo de décimo tercer sueldo, décimo cuarto, cálculo de
impuesto a la renta y aportación al seguro social. Estos valores serán
contabilizados mediante el proceso de elaboración del asiento de
diario que será generado de manera automática.
El departamento de contabilidad también manejará el sistema con el
control de los préstamos que universidad hace a los empleados.
6.3.5 Manual de Usuario
El Manual de Usuario ha sido elaborado y redactado de forma clara y

sencilla para que lo entienda cualquier tipo de usuario, explicando
como se puede utilizar las cualidades del software. Véase en el
Manual de Usuario del Software de Nómina para la Universidad
Técnica de Machala.
6.4 Capacitación a usuarios
A lo largo del ciclo de vida del desarrollo del sistema los usuarios han
estado involucrados, por lo que ahora debemos poseer una valoración
adecuada de los usuarios que deben ser capacitados. Uno de los
valores más preciados que se puede dar a cualquier situación de
capacitación es la capacidad de ver el sistema desde el punto de vista
del usuario. Nunca se debe olvidar qué es el enfrentar un nuevo
sistema. Esto puede ayudar a empalizar con el usuario y facilite su
capacitación.
6.4.1 Plan de capacitación
La meta perseguida con la implantación del plan de capacitación es

conseguir que el usuario aprenda a usar y aprovechar las bondades
del software de Nómina para la Universidad Técnica de Machala, con
este propósito se ejecutó el plan de capacitación de acuerdo a como
se muestra en el Anexo 11.
6.4.2 Informe de capacitación
Es importante saber el grado de satisfacción de los usuarios con

respecto a la capacitación recibida, pues de ello depende también la
aceptación del software implantado.
El resultado de este informe será entregado a los jefes de cada área

involucrada así como a las autoridades de la Universidad, Rector y
Vicerrector Administrativo.
El informe de la capacitación se muestra en el Anexo 12.
46
__________________________________________________________________________________
6.5 Gestión del soporte del software
6.5.1 Plan de soporte y mantenimiento del software
El software desarrollado quedará instalado en el servidor de

aplicaciones del Departamento de Sistemas de la Universidad Técnica
de Machala, por lo tanto el soporte técnico de los usuarios serán las
personas que laboran en el departamento. Sin embargo, puede
suceder que los requerimientos de los usuarios excedan a la
capacidad de los técnicos en cuyo caso el soporte se extenderá a la
desarrolladora de la aplicación, convirtiéndose entonces el soporte de
la Universidad en el canal de comunicación que es quien debe captar
la solución y aplicarla a los demás usuarios. El plan de soporte técnico
y mantenimiento lo podemos observar en el Anexo 13.
El mantenimiento al igual que el soporte también lo darán los

programadores del Departamento de Sistemas, pues contarán con el
manual técnico como ayuda. Sin embargo, dado que el
mantenimiento del software también involucra corregir defectos que
podría darse a través del uso se llamará al soporte externo
(desarrolladora del proyecto) para dar el correspondiente
mantenimiento correctivo del software.
Para el mantenimiento preventivo será de responsabilidad de la UTM.
6.6 Aprendizajes en esta fase
La implantación del Software es la fase más completa en donde se

conjuga o se integran las demás, desde la visión del sistema hasta la
actual que es la integración con el usuario.
He aprendido que capacitar al usuario no es solamente indicar

brevemente el funcionamiento del software, sino, comprende un
conjunto de tareas bien organizadas detalladas al máximo, para poder
conocer si el software implantado satisface o no los requerimientos
planteados por el usuario y la Universidad en sí.
La implantación debe también garantizar el funcionamiento y

mantenimiento oportuno del sistema, de igual manera comprende
realizar un plan de soporte del software que consiste en la vinculación
permanente del desarrollador con los usuarios y consecuentemente
con la aplicación implantada.
Lo importante es entonces, no dejar que el usuario se enfrente solo en

el manejo del sistema, su interés será latente si observa la
preocupación del desarrollador (equipo informático) en hacer que la
implantación del sistema sea todo un éxito.
47
__________________________________________________________________________________
7. Fase 6: CONCLUSIONES Y RECOMENDACIONES
7.1 Conclusiones
El principal objetivo de este trabajo, ha sido obtener una solución de

calidad y eficiencia para automatizar el proceso, control y ejecución de
la Nómina de Pagos para la Universidad Técnica de Machala, con la
culminación del desarrollo del sistema y la puesta en producción,
puedo concluir lo siguiente:
La implementación del módulo de Recursos Humanos ha

permitido una reestructuración de procesos administrativos
además de eliminar la duplicidad de tareas.
El resultado con la implementación del Sistema de Nómina es

satisfactorio en razón de que ha permitido cumplir con uno de
los objetivos, que es la generación del rol de manera segura
evitando la intervención del personal de Sistemas durante el
proceso.
La implementación del Sistema de Nómina ha disminuido en un

50 % el uso de documentos físicos en el envío de información al
departamento de Remuneraciones
Se han reducido en un 99% los errores en cálculo de sueldos de

nómina El 1% restante corresponden a errores de tipeo.
Se ha eliminado por completo el esfuerzo y recursos empleados

en el ingreso y generación del asiento contable de las
remuneraciones mensuales de los empleados de la UTM
El tiempo requerido para el proceso de generación del rol de

pago ha disminuido de cinco a dos días.
Según resultados de encuestas aplicadas en la evaluación de la

capacitación a los usuarios, éstos manifestaron en un 100%
estar satisfechos con la implementación del Sistema de Nómina
de Pago.
48
__________________________________________________________________________________
7.2 Recomendaciones
De las experiencias obtenidas durante el desarrollo del presente
proyecto de tesis me permito hacer las siguientes recomendaciones:
Se recomienda adoptar Proceso Unificado como metodología

de desarrollo de proyectos, que de acuerdo a la experiencia
obtenida ha proporcionado un marco de trabajo ordenado y
completo, permitiendo llegar a buen término el presente
proyecto.
Se ha desarrollado un módulo básico de Recursos Humanos

con los puntos más relevantes para proveer información para la
generación del rol de pago. Se recomienda completar su
desarrollo en un proyecto futuro de la UTM.
Se recomienda el uso de los nuevos componentes de

integración que tanto Oracle como Microsoft distribuyen de
forma gratuita que se puede encontrar en la siguiente dirección:
http://www.oracle.com/technology/tech/dotnet/index.html
Para la creación de reportes se recomienda utilizar el Crystal

Reports (herramienta integrada con el Visual Studio) que
garantizará la creación de reporte de manera ágil.
49
Anexo 1: “Entrevistas”
______________________________________________________________________________
ANEXOS
1
______________________________________________________________________________
ANEXO 1 – ENTREVISTAS
1
______________________________________________________________________________
Anexo 1 – Entrevistas
ENTREVISTA Nº # 1
Registro de Entrevista
15 de Octubre del 2008
Sistema de Nómina Machala
Solicitado por: Betty Pachucho Hernández
Asistentes: Rosa Liliana Campoverde Muñoz
Notas Entrevista realizada en el Departamento de Recursos Humanos. Responsable de receptar los datos de
los empleados y registrarlos en sus respectivas tarjetas, elaboración de informes manuales.
Tema Detalle
¿Cómo ve los objetivos de este departamento?
Proceso Son claros y bien definidos receptar todos lo documentos de los empleados y llevar su ficha
Actual personal al día, las funciones realizadas por cada uno de nosotros van encaminadas a ello, sin
embargo no se pueden cumplir a cabalidad porque todo el trabajo, aunque se lo realiza en
computadora en Word o Excel, no permite tener ágiles resultados pues yo mismo diseño
cuadros, digito datos para los reportes. Cosa diferente sería con un programa que permita el
ingreso una sola vez de los datos y sirva para en base a ello sacar los reportes y otros
procesos que se necesite.
¿Qué pasos sigue para gestionar el ingreso de un empleado?
1. Secretaría General envía el oficio firmado por el Rector en donde se autoriza el ingreso
del empleado
2. El empleado nuevo deja en las oficinas de Recursos Humanos su carpeta con todos los
documentos personales
3. Con todos estos datos más una fotografía actualizada se llena la ficha personal de forma
manual
4. Si el empleado es de contrato se elabora el contrato de prestación de servicios y con la
firma del Rector y el empleado contratado se envía una copia de este documento al
departamento de Remuneraciones
5. Si el nuevo empleado es con nombramiento definitivo se elabora una acción de personal
que igualmente firmados por las autoridades se envía al departamento de
Remuneraciones para que sean ingresados a su programa para elaborar los roles de
pago.
¿Cuáles son los procesos que usted realiza?
Yo llevo la ficha personal de cada empleado sea este docente o administrativo, para ello
recibo las notificaciones de ingresos, actualizaciones o renuncias de los mismos. Elaboro las
acciones de personal, tengo en Excel los datos de todos los empleados, cuando necesitan un
reporte por ejemplo de todos los docentes con el cargo de tiempo exclusivo selecciono los de
ese tipo y los imprimo.
¿Existe problemas en el proceso?
El problema es me toma mucho tiempo por la mayor parte lo hago manualmente,. También los
reportes tengo que yo mismo ver que datos imprimo. Sería más fácil que el programa me diera
esos resultados de manera ágil.
La implementación de un sistema computarizado le parecería que ¿no es necesario, si es
necesario o le da lo mismo?
Si es muy necesario por todo lo que ya le he manifestado
¿Aportaría con ideas en caso de ser necesario?
Claro que sí, estaré dispuesta a colaborar pues confío en que ayudará a mi trabajo.
Sugerencias Que en la Ficha del empleado se pueda visualizar su fotografía
para el nuevo Se pueda tener información de las acciones de personal efectuadas por facultad y por rango
sistema de fecha
Tema Conclusión
Se siente aburrida ingresando los datos manualmente en la ficha personal, se ve bastante interesada
con la idea de la implementación de un módulo de recursos humanos
2
______________________________________________________________________________
ENTREVISTA Nº # 2
Asistentes: María del Cisne Pacheco Carvajal
Entrevista
Notas Entrevista realizada en el departamento de Recursos Humanos. Se encarga de receptar las novedades
de las facultades con respecto a inasistencias, atrasos, suspensiones. Resúmenes manuales para informar al
departamento de remuneraciones.
Tema Detalle
Proceso
Recibo los reportes de novedades de las diferentes facultades con respecto a las
Actual
inasistencias, atrasos, informes de labores, sanciones, avisos de enfermedad,
informes de horas extras.
¿Cuáles son algunos de los errores comunes que se cometen en la captura de
datos en este departamento?
La tabulación de las horas o días no laborados las realizo manualmente, como son
alrededor de 280 empleados y 300 docentes el trabajo es grande y a veces me
equivoco en la revisión.
La implementación de un sistema computarizado le parecería que ¿no es
necesario, si es necesario o le da lo mismo?
En nuestro departamento es muy necesario, ya que la mayor parte del trabajo aún
lo realizamos manualmente.
Desde luego que sí, pues yo sé que es para mi propio beneficio
¿Está al día con su trabajo?
No lo estoy, para tener una idea actualmente estoy terminando de revisar el mes de
agosto y eso que me quedo después de las horas normales de trabajo.
¿Hay tareas que le corresponde realizar pero que por falta de tiempo no las ha
realizado?
Si, me corresponde el ingreso de novedades de los empleados al programa en
Internet del IESS
Sugerencias Que permita un ingreso rápido y eficaz de las novedades que envían las facultades
para el nuevo El sistema emita los reportes con los números de horas o días no laborados por los
sistema empleados, quienes están suspendido, con vacaciones o licencias dependiendo de
los datos que ingreso
Automáticamente las novedades sirvan también para que el departamento de
remuneraciones elabore la nómina de pago sin necesidad de enviar los reportes
manuales.
Conclusiones
Tema Conclusión
Está muy interesada, será una apoyadora/facilitadora entusiasta para el nuevo sistema.
Inclusive quiere ser la primera en utilizar el sistema.
3
______________________________________________________________________________
ENTREVISTA Nº # 3
Asistentes: Amparito Delgado Suárez
Notas Jefe del departamento de Remuneraciones. Encargada del ingreso de novedades enviadas por el
departamento de recursos humanos y otros departamentos para la elaboración de roles de pago del personal
definitivo de la universidad, así como también la revisión de todos los pagos por concepto de sueldos que se
realizan.
Tema Detalle
¿Cuál es su opinión del sistema de computadora actual?
Proceso El programa que usamos actualmente para elaboración de roles del personal definitivo
Actual funciona pero no como quisiera, todos las novedades tenemos que ingresarlas aquí es por
eso que el rol mensual lo empezamos a elaborar el día 20 de cada mes, de gran ayuda sería
que se las ingrese en el departamento que ocurren; por ejemplo los ingresos nuevos de
empleados, multas u otros los ingrese el departamento de recursos humanos, o que los
descuentos por préstamos y anticipos sean ingresados por el departamento de contabilidad y
así. Además siempre tengo que estar pidiendo a alguien de sistemas que respalde la
información y que procese el rol, lo cual es difícil porque a veces no están o a veces mi horario
de trabajo se extiende hasta la noche porque las autoridades quieren la nómina de pagos
antes de fin de mes,
¿Cuáles son algunos de los problemas que experimenta para recibir la información a tiempo?
Este es un gran problema y es el que precisamente no recibo la información a tiempo, tengo
que estar llamando a los departamentos o facultades para que envíen todas las novedades,
descuentos que van a entrar al rol y a veces hasta ha resultado que no se realiza un
descuento o empleados quedan fuera del rol porque no enviaron los documentos habilitantes a
tiempo.
Tengo problemas cuando elaboro los roles de las bonificaciones ya que estas no se pagan a
todos los empleados sino solo a los de nombramiento definitivo y a los que están trabajando
en el mes de pago de dicha bonificación, el programa actual no los saca del rol, entonces la
revisión que tengo que hacer es manual y eliminarlos o corregir el número de meses
trabajados.
La implementación de un sistema nuevo le parecería que ¿no es necesario, si es necesario o
le da lo mismo?
Es necesario pero que se corrija los inconvenientes del actual
¿Qué datos se requiere habitualmente para generar un reporte de nómina?
Las novedades de empleados en caso de que alguno no deba salir en el rol o lo contrario la
notificación de los nuevos e informe de las horas extras, reporte de descuentos: préstamos,
anticipos, comisariato, asociaciones, multas, jubilación indexada, ayudas económicas.
¿Existen distintos procedimientos de generación de rol?
Si, los de nombramiento definitivo, los empleados por contrato y los docentes que cobran
como honorarios profesionales
¿Cuántos roles de nómina realiza?
Dos, los del personal definitivo y los de contrato
¿Qué tantos reportes genera en un mes?
Roles de firmas, detalles de pago, reportes de todos los descuentos realizados y distribuidos a
los departamentos, planillas del iess, liquidaciones de pago de honorarios.
Sugerencias Los descuentos sean ingresados en el departamento respectivo y a través del sistema
para el nuevo recuperarlos
sistema No depender tanto del centro de cómputo
Los datos se guarden bien de tal manera que los resultados sean reales y no tener que
corregir tanto como para la elaboración del pago de bonificaciones
Que también se integre el departamento financiero
Conclusiones
4
______________________________________________________________________________
Tema Conclusión
El usuario se encuentra muy contrariado pues el trabajo que realiza es arduo y teme que con el nuevo
sea igual.
5
______________________________________________________________________________
ENTREVISTA Nº # 4
Asistentes: Adelaida Gía Bustamante
Entrevista
Notas Departamento de Remuneraciones. Recepción de contratos enviados por el departamento de
recursos humanos para la elaboración de los pagos por concepto de honorarios profesionales en el
programa actual desarrollado en FOXPRO
Tema Detalle
Proceso
Es un programa sencillo de manejar que me ayuda bastante en la elaboración de
Actual
las liquidaciones de pago, me permite tener un control de las liquidaciones que
se ha realizado por empleado e inclusive me permite controlar las fechas de
caducidad de las facturas presentadas.
El volumen de trabajo de este departamento cada día crece, pues todo lo
relacionado a pagos se concentra aquí
Recibo los contratos de honorarios profesionales del departamento de
remuneraciones y solicito a contabilidad información respecto a si tiene el
empleado anticipos para efectuar el respectivo descuento. Luego emito la
liquidación con todos los datos del contrato y los descuentos de aportes al IESS,
renta y otros si existen,
A veces en contabilidad no me informan a tiempo si tiene anticipos o no
¿Cuáles son algunos de los errores comunes que se cometen en la captura de
datos en este departamento?
Los contrato vienen mal elaborados, asignaturas cambiadas, número de horas o
valor de hora equivocados. También ocasiona problema el hecho de que los
datos de los empleados no están en un solo lugar, pues para roles definitivos
tiene un código, para los contratados otro y para liquidaciones otro
La implementación de un sistema nuevo le parecería que ¿no es necesario, si es
Sería bueno si esto permitirá integrarnos a recursos humanos, que es el
problema
Sugerencias Esté relacionado con contabilidad para que automáticamente los descuentos se
para el nuevo puedan realizar y no se quede ninguno sin descontar
sistema Que el sistema sea uno solo para todo el departamento
Conclusiones
Tema Conclusión
No tiene mayores problemas con el sistema actual lo importante es la integración con los
demás departamentos involucrados así como el suyo propio pues los mismos datos son
igresados más de una vez. El sistema deberá entonces basarse en la integración.
6
______________________________________________________________________________
ENTREVISTA Nº # 5
Asistentes: Pilar Plaza Criollo
Entrevista
Notas Departamento de Remuneraciones. Genera los roles del personal contratado tanto de autogestión
como del presupuesto de la Universidad.
Tema Detalle
Proceso El sistema actual con el cual trabajo realiza por separado la elaboración de los roles del
Actual personal contratado de autogestión y los de presupuesto de la Universidad. No funciona
correctamente por ejemplo cuando los descuentos exceden a los haberes le sale valor a
recibir una cantidad negativa cuando lo correcto sería que salga cero. La codificación de los
empleados a veces se duplica, es decir, un mismo código para dos empleados diferentes y
esto se debe a que no están integrados los datos.
Al igual que para el trabajo de mis compañeras las novedades provienen de las facultades,
departamento de recursos humanos y departamento de contabilidad con cuyos datos se
procede a liquidar el rol.
Para que pueda cumplirlos necesita un buen programa
Elaboración de roles mensuales, décimos y bonificaciones del personal contratado,
liquidaciones por término de contrato, planillas de aportes al IESS, cálculo de fondos de
reserva, cálculo de impuesto a la renta
El programa tiene el inconveniente que solo genera el rol cuando el cálculo es de un mes
completo, cuando un empleado ha laborado menos tiempo no lo procesa por lo que tengo
que realizar el rol en un documento Excel. Y esto genera problema para el cálculo del XIII
sueldo y renta pues los valores deben ser ingresados manualmente para que se acumulen al
valor de los sueldos generados con el programa.
La implementación de un sistema nuevo le parecería que ¿no es necesario, si es necesario o
le da lo mismo?
Es muy necesario
¿Existen distintos procedimientos de generación de rol?
Si, para los de contrato de autogestión es un proceso y para los de presupuesto de la
Universidad, otro.
Desde luego que sí. Porque así el programa estará hecho para nuestra necesidades
¿A qué procesos les daría la más alta prioridad?
Al de generación de roles
Según su óptica ¿qué espera del trabajo que estoy realizando?
Que elabore un programa que ejecute todos los procesos que actualmente los hago en Excel
y que los resultados sean veraces y la información se maneje de forma segura
Sugerencias Que permita generar el rol de nómina aunque el empleado no haya trabajado el mes
para el nuevo completo
sistema Que los resultados sean reales, no cantidades negativas
Que el programa sea uno solo, pero que controle todos los procesos
Que todos los valores emitidos se acumulen para los cálculos de fin de año.
Conclusiones
Tema Conclusión
El trabajo lo realiza casi manualmente ya que lleva control de los acumulados en una hoja de cálculo.
La automatización de dichos procesos es impresindible.
7
______________________________________________________________________________
ENTREVISTA Nº # 6
Asistentes: Martha Pizarro Aguirre
Entrevista
Notas Departamento de Contabilidad. Ingreso de los asientos contables de los roles de pago procesados
Tema Detalle
Proceso
Actual
Realizo la contabilización de los roles de pago que son enviados por el
departamento de remuneraciones
¿Cuáles son algunos de los problemas que experimenta para recibir la información
a tiempo?
El problema es el volumen de información que tengo que ingresar, lo cual me toma
a veces hasta una semana
La implementación de un sistema nuevo le parecería que ¿no es necesario, si es
Me parece muy necesario y oportuno
¿Está al día con su trabajo?
No
¿Hay tareas que le corresponde realizar pero que por falta de tiempo no las ha
realizado?
Si, a mi me corresponde también hacer comprobantes de pago, pero no los puedo
hacer pues el tiempo no me da.
Según su óptica ¿qué espera del trabajo que estoy realizando?
Que permita agilitar el proceso de contabilización
Sugerencias Que el sistema esté integrado al de contabilidad y yo pueda recuperar los datos lo
para el nuevo cual haría que la contabilización del asiento sea casi inmediata
sistema
Conclusiones
Tema Conclusión
Ahorro de tiempo y esfuerzo pues los asientos resultan en ocasiones hasta 30 páginas
8
Anexo 2: “Documento Visión”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 2 – DOCUMENTO VISION
ix
Anexo 3: “Proceso Actual”
---------------------------------------------------------------------------------------------------------------------------------------
--------- Universidad Técnica Particular de Loja
ANEXO 3 – PROCESO ACTUAL
x
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 3 – Proceso Actual
INGRESO EMPLEADO
RECTORADO REMUNERACIONES RECURSOS HUMANOS
Emitir Orden Receptar datos

Oficio autorizado
de Ingreso personales
Revisar datos
No
Empleado es
Documentos
contratado?
Novedades Si
Elaborar
contrato en
Word
Contrato
DETALLE
1. El Rector emite la orden para el ingreso de un empleado y envía esa orden al departamento de RR.HH.
2. RR. HH: revisa la información y en caso de que el ingreso se deba a un empleado por contrato se elabora el contrato en word
y se remite una copia de este documento al departamento de Remuneraciones
3. En caso de que el nuevo empleado no sea contratado significa que es empleado de planta en cuyo caso no se elabora ningún
documento sino que después de ser registrados los datos son enviados al departamento de Remuneraciones.
xi
---------------------------------------------------------------------------------------------------------------------------------------
GENERAR PAGOS
RECURSOS HUMANOS REMUNERACIONES PROGRAMA CONTABILIDAD
Novedades
Registrar datos
Docente Si Generar Pago

Honorarios
Contratado?
Profesionales
No
Contabilizar el
asiento
Administrativo Si Generar Rol
Contratado? contratados
No Generar rol
empleados de
planta
DETALLE
1. RR. HH. entrega todas las novedades que tenga que ver con pagos a Remuneraciones para que se elaboren los roles de pago.
2. En caso de que sea docente contratado el pago se lo hace a través de la ejecución del programa de honorarios profesionales pues a ellos se les
cancela luego de terminado el dictado de las clases.
3. En administrativos contratados y personal de planta se elaboran roles de pago, pero cada uno con programas diferentes; es decir, funciona el uno
independiente del otro
4. El departamento de remuneraciones envía las liquidaciones de honorarios profesionales y los roles de pago tanto de administrativos contratados
como empleados de planta para que se realice la contabilización del documento, esto es la asignación del código contable y presupuestario a cada
cuenta según corresponda, con éstos datos se ingresa el asiento al sistema contable y una vez cuadrado se procede a su mayorizar el asiento.
xii
Anexo 4: “Proceso Propuesto”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 4 – PROCESO PROPUESTO
xiii
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 4 – Proceso Propuesto
Nómina – Ingreso de empleados
RECTORADO RRHH
Emitir ingreso Orden de ingreso

de empleados Carpeta empleado
Receptar
ingreso de
empleados
Ingresar datos
empleados
DETALLE
1. El Rector emite la orden para el ingreso de un empleado y envía esa orden al
departamento de RR.HH.
2. RR. HH: revisa la información y luego ingresa al sistema todos los datos de los
empleados en el caso de uno nuevo y dependiendo del tipo de personal se obtendrán
los reportes.
xiv
---------------------------------------------------------------------------------------------------------------------------------------
Nómina – Generación de pagos
RRHH REMUNERACIONES CONTABILIDAD
Datos de Registrar
empleados préstamos y
anticipos
Registrar Revisar y
novedades validar
empleados novedades
Generar
nómina de
pago
DETALLE
1. Al departamento de RR.HH llega información del rectorado, otros departamentos y facultades, respecto a
novedades que tienen que ver con empleados y sus remuneraciones.
2. RR. HH: ingresa las novedades mensuales de los empleados.
3. Contabilidad registra en el sistema los prestamos y anticipos de sueldo que los empleados realizan
4. Remuneraciones antes de procesar cualquier rol primero revisa los datos ingresados por RRHH y
Contabilidad, pues todas las novedades de ingresos nuevos empleados, reubicaciones, sanciones, etc. Serán
enviadas a Remuneraciones con documentos que legalicen el trámite evitando así cualquier anomalía en el
ingreso. Esta observación se la ha anotado a pedido de la Ing. Amparito Delgado, Jefe del dpto. de
Remuneraciones.
xv
---------------------------------------------------------------------------------------------------------------------------------------
Nómina – Contabilización
REMUNERACIONES CONTABILIDAD
Procesar Datos Contabilizacion
Generar
nómina de
pago
DETALLE
1. El departamento de Remuneraciones procesa los datos y de acuerdo al rol que se vaya a liquidar. Puede ser contratado o
de nombramiento definitivo, inclusive se debe poder realizar reliquidaciones de sueldo, esto se da cuando hay conquistas
laborales y consejo universitario aprueba por ejemplo un alza del sueldo con carácter de retroactivo desde tal mes entonces
se vuelve a liquidar el sueldo por la diferencia no percibida.
2. Con todos los datos ingresados y verificados se procede a generar la nómina de pago, que consistirá en establecer el
monto a recibir de cada empleado, y si el empleado sale con saldo en contra determinar automáticamente en que conceptos
no alcanzó a descontar y que estos queden listos para descontarse en el siguiente mes. Además debe contemplar la opción
de revertir de proceso en caso de que exista algún error.
3. Los datos quedarán en el sistema listos para que cuando se desee se realice la contabilización, esto es la asignación de
los valores a las cuentas contables respectivas. Este proceso será automático ya que previamente como parámetros se
definirán las cuentas a las cuales deberá aplicarse cada rubro que interviene en la nómina de pago, quedando de esta
manera el asiento listo para su mayorización.
xvi
---------------------------------------------------------------------------------------------------------------------------------------
Nómina – Anticipos y préstamos
CONTABILIDAD REMUNERACIONES
Registrar Revisar datos de

préstamos y prestamos y
anticipos anticipos
Memorándum
con valor total
Realizar
de prestamos y
Descuento
anticipos a
descontar
DETALLE
1. Los anticipos y préstamos otorgados a los empleados por Rectorado son registrados por Contabilidad para que se emita
el pago. En el caso de préstamos se indica el número de meses de aplicación del descuento.
2. Remuneraciones revisará que los datos ingresados cuadren con el valor total reportado en el memorándum enviado por
contabilidad
3. El sistema automáticamente aplicará el descuento si corresponde al mes y tipo de rol que se va a procesar. Los anticipos
además de aplicarse al sueldo también se pueden aplicar a una de las bonificaciones o décimos que paga la Universidad,
puede tener tantos anticipos como se desee siempre y cuando sea autorizado. Además se controlará que el empleado solo
podrá tener un préstamo a la vez.
xvii
Anexo 5: “Diagrama de Casos de Uso”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 5 – DIAGRAMA DE CASOS DE USO
xviii
Anexo 6: “Diagrama de Secuencia”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 6 – DIAGRAMA DE SECUENCIA
xix
Anexo 7: “Documento de Arquitectura”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 7 – DOCUMENTO DE ARQUITECTURA
xx
Anexo 8: “Plan de Pruebas”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 8 – PLAN DE PRUEBAS
xxi
Anexo 9: “Casos de Prueba”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 9 – CASOS DE PRUEBA
xxii
Anexo 10: “Pruebas de Aceptación”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 10 – PRUEBAS DE ACEPTACION
xxiii
Anexo 11: “Plan de Capacitación”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 11 – PLAN DE CAPACITACION

---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 11 – Plan de Capacitación
PLAN DE CAPACITACION A USUARIOS DEL SOFTWARE DE NOMINA DE LA

1. OBJETIVO
Capacitar a funcionarios y usuarios del sistema del área de Recursos Humanos y

área Financiera de la Universidad Técnica de Machala.
2. IDENTIFICACION DE USUARIOS
Los funcionarios a capacitar son:
Ing. María Castillo Valarezo; Jefe de Personal

Ing. Ramiro Pérez Bermeo; Jefe Financiero
Ing. Francisco Alejandro Escobar; Contador General
Los usuarios del módulo de Recursos Humanos:
Ing. Liliana Campoverde

Sra. María del Cisne Pacheco Carvajal
Los usuarios del módulo de Remuneraciones:
Ing. Amparito Delgado Suárez

Ing. Adelaida Gía Cuenca
Lcda. Pilar Plaza Criollo
Usuario del módulo de Contabilidad:
Ing Martha Pizarro

Lcdo. Julio Granda Mancuello
3. ORIENTACION TEMATICA
Las temáticas que enfatizan como necesarias de considerar dentro de un plan de

capacitación son:
Temáticas Propuestas Contenidos Enfoque de la capacitación

Introducción a la Conceptos básicos:
computación encendido/apagado de la Básico
máquina, partes del
computador, funcionalidad
de las teclas, operatividad
del Mouse
Manejo Utilitarios: Word, Introducción al manejo de las
Excel hojas Word y Excel, Básico
explicación botones básico
(copiar, pegar, eliminar, entre
otros).
Manejo del Sistema de Explicación de cada opción,
Nómina ejemplos con datos reales,
qué hacer en caso de errores Avanzado
comunes, búsqueda de fallas
básicas, terminar captura de
datos.
---------------------------------------------------------------------------------------------------------------------------------------
4. LUGAR DE CAPACITACION
La capacitación se realizará dentro de la Universidad, separando a los usuarios:
Los funcionarios serán capacitados en la oficina de la dirección Financiera por su

amplio espacio.
Los usuarios serán capacitados en el mismo departamento del área a la cual

pertenece el módulo.
La capacitación tendrá lugar fuera del horario de trabajo, para evitar distracciones y
falta de concentración completa en la capacitación.
5. TIPOS DE PARTICIPACION
En los eventos de capacitación el tipo de participación será DIRECTA mediante el

desarrollo de Talleres con el propósito de enfatizar el análisis de casos reales o
simulados de situaciones probables, por lo que la preparación es muy importante
para evitar problemas de última hora.
6. METODOS DE CAPACITACION
Todos los usuarios coinciden es que se aprende mejor viendo, pero dado a que no
se dispone de mucho tiempo se va a combinar el método de viendo y haciendo, lo
cual permite dar una asistencia personalizada a unos usuarios mientras los otros
observan.
Se ha divido la capacitación en cuatro grupos de acuerdo a su vinculación con los

módulos.
7. RECURSOS
Antes de empezar la capacitación se entregará a cada asistente una copia del

manual del usuario para que de esta manera se vaya familiarizando con el sistema
y pueda adaptarse fácilmente a él.
Debido a que la comprensión del sistema por parte del usuario depende de ellos,
este manual debe estar escrito con claridad, con un mínimo de vocabulario especial
y disponible para cualquiera que los necesite.
8. AGENDA
Capacitación a los funcionarios de la Institución:
Lunes 8 y Martes 9 de Diciembre de 14h00 a 16h00
Capacitación a los usuarios del módulo de Recursos Humanos:
Miércoles 10 , Jueves 11 y Viernes 12 de Diciembre de 16h00 a 18h00
Capacitación a los usuarios del módulo de Remuneraciones:
Lunes 15 , Martes 16 y Miércoles 17 de Diciembre de 16h00 a 18h00
Capacitación a los usuarios del módulo de Contabilidad:
Jueves 18 y Viernes 19 de Diciembre de 16h00 a 18h00

Anexo 12: “Informe de Capacitación”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 12 – INFORME DE CAPACITACION

---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 12 – Informe de Capacitación
INFORME DE CAPACITACION EN EL MANEJO DEL SOFTWARE DE NOMINA PARA LA

1. INTRODUCCION
Desde el 8 al 19 de Diciembre se llevó a cabo la capacitación a funcionarios y

usuarios involucrados en el sistema de Nómina de la Universidad Técnica de
Machala.
Según lo indicado en el plan de capacitación, se contará con la participación de 10

personas las cuales estarán dividas en grupos de acuerdo a sus funciones. Sin
embargo, debido al interés presentado se sumó a la capacitación la Auditora
General de la Universidad, uniéndose al grupo de los funcionarios.
2. ANTECEDENTES
A sabiendas del interés y el apoyo de las máximas autoridades en el tema de la

capacitación, la jefatura Financiera gestionó el apoyo económico con lo cual se
pudo brindar un refrigerio a los asistentes.
Por sugerencia de los usuarios mismos se amplió el horario de capacitación en

lugar de 16h00 a 18h00 se dio de 14H00 a 18H00.
3. ACTIVIDADES
En esta sesión, en forma muy amplia la desarrolladora del software explicó a los
participantes sobre el nuevo sistema de Nómina de Pago para la Institución y las
ventajas que representa el implantarlo, resaltando el ahorro de tiempo y la velocidad
de respuesta de la información solicitada frente al proceso actual antes de la
implantación.
Algo muy importante de recalcar es la predisposición de los usuarios pues con sus
preguntas manifestaron el claro interés y el deseo de utilizar el nuevo software. Así
como también la colaboración de los jefes inmediatos quienes dispusieron se
capacite al personal con el consecuente compromiso de aplicarlo inmediatamente.
---------------------------------------------------------------------------------------------------------------------------------------
Temáticas impartidas Contenidos Nivel de

Aprendizaje
Introducción a la - Pasos para encender el
computación a los usuarios computador Alto
del sistema de todos los - Pasos para apagar el
módulos computador
- Explicación de las partes
de un computador y sus
funciones
- Ejercicio desarrollado por
los asistentes
Introducción Manejo - Escribir un documento en
Utilitarios: Word, Excel Word Alto
- Aplicar botones: guardar,
copiar, pegar, eliminar,
buscar, insertar
- Ejercicio
Manejo del Sistema de - Ingreso al sistema
Nómina mediante clave y
contraseña Alto
- Explicación de cada
módulo con las opciones
de cada uno
- Explicación de solución a
errores frecuentes
- Opciones alternativas en
caso de problemas.
4. EVALUACION DE LA CAPACITACION
El día 5 de Enero del 2009 se entregó la evaluación de satisfacción de la

capacitación a usuarios del Software de Nómina de la Universidad Técnica de
Machala. El objetivo de esta evaluación fue conocer el nivel de satisfacción de los
usuarios y emprender acciones de corrección y mejora al proceso.
4.1 Metodología de Evaluación
El instrumento de evaluación que he utilizado consta de una serie de preguntas de

carácter cerrado, las cuales tienen por objeto estandarizar el criterio de evaluación
para los distintos ítems evaluados. Para la evaluación de cada pregunta se utilizó
una escala de satisfacción del usuario en orden ascendente, la escala fue la
siguiente:
---------------------------------------------------------------------------------------------------------------------------------------
1 Deficiente 2 Regular 3 Bueno 4 Excelente
SATISFACCION
- +
4.2 Preguntas Cerradas
El resultado de la encuesta de la capacitación da una nota de promedio de 4.

Resultado que es considerado como “Excelente”.
Se han agrupado las preguntas, clasificándolas en cuatro temas, de acuerdo a la

siguiente tabla:
TEMA PREGUNTAS Nota Promedio

Requisitos del Usuario 1 4
Diseño 2,3 4
Reportes 4,5,6,7 4
Equipo de usuarios 8,9,10 4
El Resultado de la evaluación por temas se aprecia en el siguiente cuadro:

---------------------------------------------------------------------------------------------------------------------------------------
RESUMEN DE ENCUESTA A
USUARIOS DEL SISTEMA DE NOMINA
4,5
3,5
2,5
1,5
0,5
Figura 1. Resumen
Requisit os del Usuario
de Encuesta a usuarios
Diseño Report es
del SNP Equipo de usuarios
Se observa que todos los temas evaluados han sido calificados como “Excelentes”.
4.3 Detalle de resultados de la encuesta
No, ASPECTOS CALIFICACION

1 El sistema cumple los
requisitos definidos por usted 4
como usuario
2 El desarrollador a cargo del
sistema tiene disposición a 4
enfrentar mejoras al sistema
3 Las sugerencias e
instrucciones entregadas por
usted como usuario son 4
acogidas y aplicadas en
forma oportuna
4 La información es entregada
oportunamente por el sistema 4
5 Los informes entregados por
el sistema guardan 4
coherencia entre sí
6 La información recibida por
usted como usuario se ajusta 4
a los requerimientos
solicitados
7 Es pertinente la información
presentada por el sistema 4
8 Cómo es la competencia de
los demás usuarios
asociados al sistema del cual 4
es usted también usuario
---------------------------------------------------------------------------------------------------------------------------------------
9 Cómo es el nivel de
comunicación con los demás 4
usuarios del sistema.
10 Es fácil la integración y el
compartir información con los 4
demás usuarios
El resultado por pregunta se presenta en el siguiente gráfico:
ENCUESTA A USUARIOS DEL SISTEMA NOMINA
0
1 2 3 4 5 6 7 8 9 10
El resultado promedio de las preguntas evaluadas es de 4 “Excelente”.
5. CONCLUSIONES
La evaluación al sistema de capacitación, arroja conclusiones de carácter positivo

Entre las que podemos anotar:
- Es necesario establecer nuevos horarios y reestructuración de las tareas

para el ingresos de datos iniciales al sistema
- El Software de Nómina es un instrumento valioso de apoyo y de
conocimiento para el control de los empleados y sus remuneraciones
- La dificultad que hasta ahora se tenía era la ejecución de procesos
manualmente
- La colaboración y aceptación de las autoridades ha sido una de las partes
fundamentales para la gestión del sistema
---------------------------------------------------------------------------------------------------------------------------------------
- Se siente la necesidad de respaldar y apoyar los procesos por parte de los

usuarios
- Es necesario mantener los procesos acorde a las necesidades de la
Institución de acuerdo a los temas vistos en la capacitación, como por
ejemplo integración con el departamento de Secretaría General.
- Solicitar a las máximas autoridades gestionar la implementación de nuevas
áreas.
- La importancia de realizar una evaluación de los cursos de capacitación,
una vez que estos han finalizado, pues son las encuestas de satisfacción
las que nos permite conocer cual ha sido la aplicabilidad de lo aprendido
por los usuarios.
Anexo 13: “^Plan de Soporte y Mantenimiento”
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 13 – PLAN DE SOPORTE Y

MANTENIMIENTO
---------------------------------------------------------------------------------------------------------------------------------------
ANEXO 13 – Plan de Soporte y Mantenimiento

Plan Básico
Teléfono y mail de reporte de incidencias:

o Se designa un teléfono de reporte de incidencias:
072962305
o Se designa un mail de reporte de incidencias:
bpachucho@yahoo.com
Soporte vía e-mail y telefónico ilimitado.

o La incidencia reportada siguiendo los métodos
anteriormente descritos se intenta solucionar vía
teléfono o mail en primera instancia.
Asistencia técnica on-line vía software de conexión remota

ilimitada.
o Siempre que la incidencia lo permita se intentará la
solución inmediata vía conexión remota.
Tiempo máximo de respuesta 48 horas.

o Se estipula el tiempo máximo de actuación para
asistencias críticas para el usuario en un máximo de 48
horas a partir de la recepción de la incidencia.
Auditoria inicial y elaboración de inventario del parque

informático.
o Análisis de la estructura informática para un posterior
estudio de mejora y optimización. Expedimos al usuario
un informe detallado de la situación, corrección y
prevención de las incidencias en los procesos diarios de
trabajo en referencia a: Comunicaciones y Redes,
Sistemas (Hardware y Software), y Seguridad.
o Se realizara una auditoria de sistemas de información al
inicio de este trabajo junto con un inventario del parque
informático, el cual se mantendrá y actualizará durante
la duración del presente desarrollo.
o Se obliga al usuario a comunicarme cualquier cambio de
ubicación, alta o baja tanto de los ordenadores como
periféricos, los cuales estén descritos dentro del
inventario realizado.
Plan Standard
Incluye todos los beneficios del Plan Básico

Asistencia técnica presencial ilimitada.
o La asistencia técnica presencial se realiza a través de
los siguientes modos:
---------------------------------------------------------------------------------------------------------------------------------------
 Mantenimiento Preventivo:
El objetivo de este servicio es realizar un
control sobre la infraestructura informática y
operatividad de la misma a fin de reducir la
probabilidad de futuros problemas y garantizar
la correcta adecuación a las necesidades de
los usuarios y la empresa. Este servicio se
brinda a través de visitas trimestrales
rutinarias y se realizará tanto las tareas
rutinarias preventivas, como la resolución de
problemas reportados.
 Mantenimiento Correctivo:
Hardware: Asistencia técnica (remota y/o
presencial) necesaria para realizar:
 Instalación de equipos: ordenadores
personales, impresoras, escáneres.
 Ampliaciones de equipos.
 Reparación de todo tipo de averías
informáticas que se produzcan, el
servicio no incluye el coste del
hardware a cambiar.
 Desinstalación e instalación de
equipos en traslados.
 Soporte en la compra de nuevo
equipamiento.
 Software: asistencia para solucionar un problema

software en los siguientes ámbitos:
 Software de comunicaciones.
Instalación y configuración de las
aplicaciones de comunicaciones de
uso habitual, para el uso de los
siguientes servicios de red:
Acceso a servidores de red.
Impresión a través de la red.
Correo electrónico.
Outlook, Navegador Web.
(Internet Explorer, Nestcape).
 Software Propietario.
Apoyo en el manejo del software
específico de la UTM Sistema de
Nómina de Pago
 Conexión a red.
Instalación y configuración de la
tarjeta de red y el software de la
tarjeta.
Instalación y configuración de los
protocolos básicos de red.
 Antivirus.
---------------------------------------------------------------------------------------------------------------------------------------
Instalación y configuración de
antivirus, así como resolución de
problemas relacionados con la
existencia de virus.
Realización de mantenimiento preventivo trimestralmente.

o Elaboración de un calendario anual con los días de
mantenimiento preventivo trimestrales prefijados el
primer mes de cada año.
Tiempo de respuesta inmediata.
o Las llamadas recibidas por incidencias serán
respondidas inmediatamente dando la solución de la
incidencia vía telefónica o vía software de control
remoto.
Tiempo de actuación presencial en estaciones inferior a
24h.
o Se estipula el tiempo máximo de actuación in-situ de
asistencias críticas para el usuario en un máximo de 24
horas para estaciones de trabajo a partir de la recepción
de la incidencia.

005X1060

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

005X1060

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD TECNICA PARTICULAR DE LOJA

TESIS DE GRADO PREVIA A LA OBTENCION DEL

IMPLEMENTACION SOFTWARE DE NOMINA PARA LA

BETTY MARLENE PACHUCHO HERNANDEZ

ING. AUDREY ROMERO

Ing. Audrey Romero

Que el presente trabajo de investigación ha sido, supervisado y revisado en

Loja, mayo del 2009

Ing. Audrey Romero

Betty Marlene Pachucho Hernández

Los conceptos, ideas y opiniones expuestas en el presente proyecto de

La información de otros autores empleado en el presente trabajo de

Betty Marlene Pachucho Hernández

Mi agradecimiento a la Universidad Técnica Particular de Loja y a través de

Mi sentimiento de profunda gratitud a la Ing. Audrey Romero directora de

Gracias a la Lcda. Lidia Villacís secretaria de la Escuela de Ciencias de la

A mi familia, a mis padres y hermanos por la confianza depositada en mí.

A mi esposo Juan Carlos, por su apoyo incondicional.

4. Fase 3: DESARROLLO DE LA SOLUCION ................................................... 32

La automatización de los procesos críticos de una empresa o

Personal contratado (docentes y administrativos)

El proceso para la generación de pagos en este caso es

ejecutar el pago se solicita al Departamento de Contabilidad

Personal de planta (docentes y administrativos)

Para el personal de planta se registra la información a través

1.2 Problemática Actual

No se dispone de un sistema de Recursos Humanos del personal

Los docentes están clasificados por facultad, pero no se puede

Se carece de información histórica respecto a licencias,

La información del personal que pertenece al presupuesto de

En el proceso de liquidación del Rol hay intervención del personal

Los procesos manuales y los sistemas no integrados de los que se

1.3 Propuesta presentada

Tomando en cuenta las prioridades de la UTM respecto a sus

Implementar el módulo de nómina para la UTM, donde se genera

Implementar de políticas y procesos de operación del módulo de

Integrar el módulo de nómina con el sistema contable de la UTM.

1.4 Objetivos del Proyecto

1.4.1 Objetivo General:

Implementar el Software para la Gestión de Nómina del personal

1.4.2 Objetivos Específicos:

Identificar e implementar los componentes mínimos del módulo

Reducir los recursos empleados para la gestión de nómina de

Reducir el riesgo de problemas de operación del módulo de

Minimizar el esfuerzo y recursos aplicados para la generación de

1.5 Metodología de desarrollo

sistemas software, para diferentes áreas de aplicación, diferentes tipos

Integra las múltiples facetas del desarrollo

Proporciona una guía para ordenar las actividades de un

Dirige las tareas de cada desarrollador por separado

Especifica los artefactos que deben desarrollarse

Ofrece criterios para el control y la medición de los productos y

Las características del proceso unificado son:

 Guiado por lo casos de uso: Los casos de uso son el

1.6 Fases del Proyecto

Se incluye el diseño de interfaces del sistema.

1.7 Validación de resultados y del producto

El software para la gestión de nómina del personal de la UTM una vez

Nivel aceptable de usabilidad del sistema, proporcionado por los

Porcentaje de optimización de recursos respecto al sistema actual.

Recurso Cantidad Costo Unitario Costo Total

1.8.2 Recursos hardware

Recurso Cantidad Costo Unitario Costo Total

1.8.3 Recursos software