Talento Humano Informe Final

PROYECTO INTEGRADOR
TEMA:
DESARROLLO E IMPLEMENTACIN DE UNA APLICACIN WEB QUE

AUTOMATICE LAS TAREAS DE GESTIN DEL DEPARTAMENTO DE
TALENTO HUMANO DEL INSTITUTO TECNOLGICO SUPERIOR
SUDAMERICANO DE LA CIUDAD DE LOJA.
INTEGRANTES:
Jorge Luis Robles Jimenez

Denys Israel Jumbo Guamn
CICLO:
Quinto Cliclo
ASIGNATURAS:
INGENIERA DE SOFTWARE: Ing. Lorena Pucha

PROGRAMACIN: Ing. Alex Yunga
LOJA ECUADOR
2017
2. TEMA:
DESARROLLO E IMPLEMENTACIN DE UNA APLICACIN WEB QUE

AUTOMATICE LAS TAREAS DE GESTIN DEL DEPARTAMENTO DE TALENTO
HUMANO DEL INSTITUTO TECNOLGICO SUPERIOR SUDAMERICANO DE
LA CIUDAD DE LOJA.
3. INTRODUCCIN
En la actualidad la informacin es la parte ms importante que existe hoy en da
con respecto a grandes, medianas, pequeas empresas y tambin en nuestro diario vivir
ya que forma parte de nuestra evolucin. En tiempos remotos el trato de la informacin
se haca de forma manual lo cual conduca a mucha desventaja, con gran probabilidad
de que se pierda ya que es muy complicado manipularla, tambin se puede deteriorar
porque el papel es muy frgil contra el ambiente, ocupan gran espacio, los proceso se
ejecutaban con mayor toma de tiempo y muchos ms problemas que se tena al
momento de tratar la informacin. Por este gran inconveniente surgen los sistemas de
informacin que se refiere a la clasificacin de la misma de una forma ordenada, ms
segura dando confianza a la hora de realizar alguna manipulacin de datos.
El departamento de Talento Humano del Instituto Tecnolgico Superior
Sudamericano realiza varios procesos con respecto a la gestin de tareas de los
docentes, esa informacin la maneja y lleva de forma manual haciendo el trabajo un
poco tedioso y muy cansado a la hora de realizar reportes de cada docente. La nica
herramienta digital que utiliza aparte de hojas fsicas es una hoja de clculo de Excel la
cual le permite realizar los respectivos reportes que necesita presentar en un periodo de
tiempo lo cual es muy complicado ya que tiene que revisar cada una las hojas de su
registro fsico y transcribir esos datos por cada uno de los docentes del ITSS.
Nosotros buscamos mejorar ese tratamiento de la informacin automatizando todos
los procesos que realiza de forma manual, en una aplicacin que le proporcione agilizar
dichos procesos en su trabajo diario. Aportando confianza a la hora de manipular toda
esta informacin la misma que influye mucho al crecimiento de la institucin, tambin
al mejoramiento de todos los docentes y estudiantes a nivel acadmico. La aplicacin
permitir facilitar la creacin de los reportes automticamente segn el encargado
necesite ya sea diaria, mensual o por periodo lectivo. Esto le ayudara en su labor diario
hacindolo menos cansado, ms seguro y con ms eficiencia y eficacia.

4. NDICE DE CONTENIDOS
2. TEMA:.......................................................................................................................2
3. INTRODUCCIN.....................................................................................................3
4. NDICE DE CONTENIDOS.....................................................................................5
5. INDICE DE FIGURAS..............................................................................................6
6. INDICE DE TABLAS................................................................................................7
7. ANTECEDENTES.....................................................................................................8
8. PROBLEMATIZACIN..........................................................................................10
9. JUSTIFICACIN....................................................................................................12
10. OBJETIVOS.........................................................................................................13
11. MARCO TERICO.............................................................................................15
12. METODOLOGA.................................................................................................45
12.2.1. ARBOL DE ARCHIVOS..............................................................................49
13. PROPUESTA DE ACCIN O DESARROLLO..................................................56
13.1. INGENIERA DE SOFTWARE.......................................................................56
13.1.1. DESCRIPCIN DE LA EMPRESA.............................................................56
13.1.2. AMBITO.......................................................................................................57
13.1.2.1. FUNCIONES................................................................................................57
13.1.2.2. RENDIMIENTO...........................................................................................62
13.1.2.3. RESTRICCIONES........................................................................................63
13.1.2.4. INTERFACES...............................................................................................64
13.1.3. MODELO DE INGENIERIA DE SOFTWARE...........................................64
13.1.4. PLANIFICACIN O CRONOGRAMA......................................................72
13.1.5. RECURSOS..................................................................................................73
13.1.6. IDENTIFICACIN DE RIESGOS...............................................................74
14. RESPONSABLES Y PARTICIPANTES..............................................................83
15. CRONOGRAMA.................................................................................................84
16. PRESUPUESTO...................................................................................................85
17. CONCLUCIONES...............................................................................................86
18. RECOMENDACIONES......................................................................................86
19. BIBLIOGRAFA..................................................................................................87
20. ANEXOS..............................................................................................................88
5. INDICE DE FIGURAS
Ilustracin 1(fases del modo lineal secuencial)...............................................................18

Ilustracin 2(etapas del modelo de prototipo).................................................................21
Ilustracin 3(sistema basado en prototipo)......................................................................23
Ilustracin 4(modelo espiral)...........................................................................................24
Ilustracin 5(modelo de desarrollo por etapas)...............................................................27
Ilustracin 6(modelo incremental)..................................................................................30
Ilustracin 7(modelo de desarrollo rpido de aplicaciones)............................................35
Ilustracin 8(medidas mtricas e indicadores)................................................................37
Ilustracin 9(modelo cliente servidor).............................................................................40
Ilustracin 10...................................................................................................................43
Ilustracin 11...................................................................................................................45
Ilustracin 12(metodologa XP)......................................................................................46
Ilustracin 13...................................................................................................................50
Ilustracin 14...................................................................................................................51
Ilustracin 15...................................................................................................................51
Ilustracin 16...................................................................................................................51
Ilustracin 17...................................................................................................................52
Ilustracin 18...................................................................................................................52
Ilustracin 19...................................................................................................................52
Ilustracin 20...................................................................................................................53
Ilustracin 21...................................................................................................................53
Ilustracin 22...................................................................................................................53
Ilustracin 23...................................................................................................................54
Ilustracin 24...................................................................................................................54
Ilustracin 25...................................................................................................................55
Ilustracin 26...................................................................................................................56
Ilustracin 27(login)........................................................................................................65
Ilustracin 28(principal)..................................................................................................65
Ilustracin 29(tablas).......................................................................................................66
Ilustracin 30(tablas).......................................................................................................66
Ilustracin 31(caratula)....................................................................................................67
Ilustracin 32...................................................................................................................73
Ilustracin 33 (cronograma de actividades)....................................................................85
6. INDICE DE TABLAS
Tabla 1 (funciones del sistema).......................................................................................62

Tabla 2(rendimiento).......................................................................................................63
Tabla 3(riesgos)...............................................................................................................76
Tabla 4(riesgo 1)..............................................................................................................76
Tabla 5(riesgo 2)..............................................................................................................77
Tabla 6(riesgo 3)..............................................................................................................77
Tabla 7(riesgo 4)..............................................................................................................78
Tabla 8(riesgo 5)..............................................................................................................78
Tabla 9(riesgo 6)..............................................................................................................79
Tabla 10(riesgo 7)............................................................................................................80
Tabla 11(riesgo 8)............................................................................................................80
Tabla 12(riesgo 9)............................................................................................................80
Tabla 13(riesgo 10)..........................................................................................................81
Tabla 14(riesgo 11)..........................................................................................................82
Tabla 15(riesgo 12)..........................................................................................................82
Tabla 16(riesgo 13)..........................................................................................................83
Tabla 17 (presupuesto del sistema)..................................................................................86
7. ANTECEDENTES
Actualmente en el Instituto Tecnolgico Sudamericano como Institucin Educativa
para la aprobacin de cada uno de sus ciclos tiene asignaturas tericas y prcticas, las
cuales ayudan a formar el conocimiento del profesional en las diferentes carrearas que
ofrece. Una de las herramientas usada para evaluar las materias tericas de
Programacin en Internet I e Ingeniera de Software es mediante la elaboracin y
presentacin de proyectos integradores.
Los proyectos proyecto integradores se diferencian por diferentes categoras:
Sencillos (un proyecto por materia), interdisciplinarias (Un proyecto por varias materia),
multidisciplinario (un proyecto por varios ciclos de un misma carrera),
intermultidisiplinario (un proyecto en contiene varias carreras).
Actualmente los trabajos cientficos que elaboran los estudiantes deben estar sujetos
a un conjunto de normas aceptadas y consensuadas. El Instituto Tecnolgico
Sudamericano se ha basado en los estilos APA (2016) que se originaron en 1929, para
establecer una gua que permita elaborar de forma fcil y comprensible trabajos
integradores.
Los proyectos integradores son requisito fundamental para la aprobar cada ciclo,
para lo cual se ha realizado el desarrollo e implementacin de una aplicacin web para
el departamento de talento humano del instituto tecnolgico superior sudamericano de
la ciudad de Loja, con la finalidad de dar solucin a un proceso manual automatizndolo

y as brindar un servicio ms gil, eficiente y seguro. Ya que en la actualidad las
personas buscamos un servicio ms rpido y de calidad, por lo cual las empresas que
utilizan procesos manuales tienden a ser menos eficientes ya que usan mucho tiempo
para realizar uno o varios procesos.
Esta aplicacin ser web lo cual la har portable y podr extenderse a futuras
actualizaciones, lo cual facilitara su implementacin en cualquier entorno de trabajo o
computador.
8. PROBLEMATIZACIN
Los sistemas automatizados hoy en da se los utiliza diariamente, estos nos ayudan
hacer nuestra vida ms fcil y menos complicada a la hora de realizar un trabajo,
actividad o necesidad que debemos realizar en nuestro medio que nos desempeamos
da a da. Tambin nos ayudan a ahorrar un recurso muy valioso como es el tiempo
haciendo todo ya no manualmente como antes, sino automatizando todos los procesos,
dndonos la oportunidad de hacer nuestro trabajo de una forma rpida, eficaz y
eficiente. Al mismo tiempo nos da la accesibilidad de tiempo para poder realizar otras
actividades adicionales que deseemos realizar.
En el Instituto Tecnolgico Superior Sudamericano (ITSS) la mayora de trabajos en las
distintas reas ya estn automatizados pero conforme pasa el tiempo van apareciendo
nuevas necesidades, y algunos casos donde se necesita facilitar trabajos y reducir el
tiempo que se tarda en realizarlos. El departamento de talento humano es uno de ellos
donde realiza muchos procesos de forma manual lo cual lo hace complicado, confuso,
lleva mucho tiempo y tambin no cuenta con una herramienta donde toda la
informacin este totalmente guardada y segura en caso de necesitarla.
El desarrollo e implementacin de La aplicacin web para el departamento de talento
humano del ITSS de la ciudad de Loja, tiene como fin automatizar todos los procesos
realizados por el mismo, hacindolo ms sencillo, practico y seguro que le permita al
encargado del departamento facilitar su trabajo y tener toda la informacin

correspondiente de forma ordenada y ms fcil de manipular a la hora de presentar los
respectivos reportes segn la necesidad que requiera.
La aplicacin permitir reducir el trabajo del encargado del departamento a una medida
muy adaptable y fcil de usar, de una forma interactiva que tenga pleno alcance a las
necesidades que se requiere, para realizar el respectivo control de los docentes como
verificar su presentacin, la forma de dictar sus clases, recursos que utiliza, puntualidad,
cumple con las reglas de la institucin, verificar si el docente realiza actividades que no
son de clases, rendimiento que tiene, metodologas que aplica. Todos estos procesos
realizan en este departamento ayudndole a sacar porcentajes e informes de cada
docente facilitndole automticamente el desarrollo de los reportes diariamente,
mensualmente o por periodo lectivo, segn sea la necesidad que tenga y que se le
solicite.
El sistema tambin contara con usuarios estndares conformado por los coordinadores
de cada carrera donde ellos tendrn habilitado un formato donde evaluaran el
rendimiento mensual de los docentes que conforman su carrera en el trabajo de equipo.
Luego permitir enviar este formato al encargado del departamento y ayudara al mismo
a sacar sus respectivos porcentajes para su reporte.
Otra opcin que contara el sistema son los usuarios invitados donde estar conformado
por las autoridades que necesitan visualizar toda esta informacin presentndoles
automticamente los reportes adecuados que necesiten y tener todo esto de una forma
ms rpida y en cualquier momento que los requieran.
Esta aplicacin dar un gran aporte al Instituto Sudamericano, especialmente al
departamento de talento humano realizando un trabajo fiable, con excelente

presentacin y de forma rpida en cualquier momento y lugar que se encuentre.
Aportando al crecimiento institucional y acercndonos un poco ms a la visin
planteada de la institucin.
9. JUSTIFICACIN
El presente proyecto es importante en el mbito acadmico ya que es un requisito

fundamental para aprobar las asignaturas de Ingeniera de Software y Programacin en
Internet I, y a la vez ser promovidos del quinto ciclo de la carrera de Sistemas de
Automatizacin; as tambin se cumplir con lo establecido en el Reglamento Interno
del Instituto Tecnolgico Superior Sudamericano el cual indica que para aprobar las
asignaturas prcticas es necesario elaborar un Proyecto Integrador con la finalidad de
vincular los conocimientos adquiridos en clase con la aplicacin prctica de los mismos.
En el mbito tecnolgico el presente proyecto beneficiara a la provincia de Loja

facilitndole nueva tecnologa a las empresas. Ya su vez ayudaremos a dar realce a la
zona 7 del pas.
El desarrollo del presente proyecto ayudar a demostrar los conocimientos

adquiridos en las materias mencionadas anteriormente, y as tambin acceder y hacer
uso de diferentes lenguajes de programacin que actualmente se encuentran en auge y a
su vez utilizar metodologas ordenadas para el desarrollo de aplicaciones.
10. OBJETIVOS
10.1. OBJETIVO GENEAL
Dar a conocer y proporcionar una herramienta de gestin para el
control de docentes en el departamento de Talento Humano del
Instituto Tecnolgico Superior Sudamericano, en primer lugar
desarrollando la fase de Anlisis y diseo. Y posteriormente
implementarlo, a modo de hacer de esta funcin rutinaria ms
sencilla, la cual permita realizar de las actividades diarias de la
empresa de forma ms gil, eficiente y segura.
10.2. OBJETIVOS ESPECIFICOS
Implementar los conocimientos adquiridos durante el ciclo en la
elaboracin de un sistema administrativo de gestin de procesos
con respecto al control de docentes.

Proporcionar una utilidad de la cual muchas empresas carecen en
el mbito tecnolgico para un mejor desempeo laboral y
controlar as las utilidades de dicha empresa.

Reconocer la utilidad y la necesidad de automatizar procesos en la
empresa.
Crear sistema de control de docentes con la finalidad de mejorar el
trabajo del departamento de Talento Humano.

Garantizar la eficiencia del sistema de control de docentes
automatizado.
Organizar el sistema de control de docentes de tal manera que se
tenga disponible los respectivos reportes necesarios.

Analizar un sistema de control de docentes para la elaboracin de
su respectivo manual de usuario en el cual estar documentada su
correcto funcionamiento y todo detalle que pudiese ser de
importancia para su usuario o empleado.

11. MARCO TERICO
11.1. INGENIERIA DEL SOFTWARE
Qu es un Mtodo?
Un Mtodo se compone de diversos aspectos que nos permitirn conseguir una meta o
lograr un objetivo. Se define ms claramente como un conjunto de herramientas, las
cuales utilizadas mediante las tcnicas correctas, permiten la ejecucin de procesos que
nos llevarn a cumplir los objetivos que buscamos. En pocas palabras, es un conjunto de
herramientas, tcnicas y procesos que facilitan la obtencin de un objetivo. (HOSTING,
2016)
Qu es una Metodologa?
En el desarrollo de software, una metodologa hace cierto nfasis al entorno en el cul
se plantea y estructura el desarrollo de un sistema. Existe una gran cantidad de
metodologas de la programacin que se han utilizado desde los tiempos atrs y que con
el paso del tiempo han ido evolucionando. Esto se debe principalmente a que no todos
los sistemas de la informacin, son compatibles con todas las metodologas, pues el
ciclo de vida del software puede ser variable. Por esta razn, es importante que
dependiendo del tipo de software que se vaya a desarrollar, se identifique la
metodologa para el diseo de software idnea. (HOSTING, 2016)
En qu consisten las Metodologas de Desarrollo de Software?

Una Metodologa de desarrollo de software, consiste principalmente en hacer uso de
diversas herramientas, tcnicas, mtodos y modelos para el desarrollo. Regularmente
este tipo de metodologa, tienen la necesidad de venir documentadas, para que los
programadores que estarn dentro de la planeacin del proyecto, comprendan
perfectamente la metodologa y en algunos casos el ciclo de vida del software que se
pretende seguir. Aunque actualmente existen mucha variedad en metodologas de
programacin. La realidad es que todas estn basadas en ciertos enfoques generalistas
que se crearon hace muchos aos, algunos tipos de metodologas de desarrollo de
software que se utilizaron e inventaron al principio de nuestra era tecnolgica.
(HOSTING, 2016)
Qu son las metodologas agiles?
El software de desarrollo Agile se refiere a un grupo de metodologas aplicadas en la
creacin de software que basa su desarrollo en un ciclo iterativo, en el que las
necesidades y soluciones evolucionan a travs de la colaboracin entre los diferentes
equipos involucrados en el proyecto, por norma general promueven una gestin de
proyectos disciplinada que fomenta la constante inspeccin del cdigo y la adaptacin
de ste, un sistema organizado que permite y facilita el trabajo en equipo, la auto-
organizacin y favorece el rendimiento del tiempo de desarrollo. Adems fijan un
conjunto que comprende las mejores prcticas de desarrollo para optimizar los tiempos
de entrega del software. As siempre se cuenta con la mxima calidad en el producto
final, ya que desde el primer momento el equipo de programadores cuenta con un punto
de vista de negocio en consonancia con las necesidades del cliente y los objetivos
impuestos a la empresa. (A., 2016)

MODELOS DE DESARROLLO DE SOFTWARE
Existen varios modelos, paradigmas y filosofas de desarrollo, en los cuales se
apoya la ingeniera de software para la construccin del software, entre ellos se
puede citar:
Modelo en Cascada
Tambin llamado Lineal secuencial, es el enfoque metodolgico que ordena
rigurosamente las etapas del proceso para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.
Fases del Modelo

Ilustracin 1(fases del modo lineal secuencial)
Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificacin de requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos. Es
importante sealar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose
requerir nuevos resultados a mitad del proceso de elaboracin del software.
Diseo del Sistema

Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseo del Software), que contiene la descripcin de
la estructura relacional global del sistema y la especificacin de lo que debe hacer
cada una de sus partes, as como la manera en que se combinan unas con otras. Es
conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo
detallado. El primero de ellos tiene como objetivo definir la estructura de la
solucin (una vez que la fase de anlisis ha descrito el problema) identificando
grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus
relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo
define los algoritmos empleados y la organizacin del cdigo para comenzar la
implementacin.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento
de los requerimientos del usuario, as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos,
as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de
programacin y su versin se crean las bibliotecas y componentes reutilizables
dentro del mismo proyecto para hacer que la programacin sea un proceso mucho
ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Existen varios tipos de Pruebas:
Pruebas de unidad
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Modelos Prototipos
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en
los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo
que se necesita as como tambin la solucin que se propone para dicha necesidad y
de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo
se encarga del desarrollo de diseos para que estos sean analizados y prescindir de
ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto
de objetivos generales para el software a desarrollarse sin delimitar detalladamente
los requisitos de entrada procesamiento y salida, es decir cuando el responsable no

est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la
forma en que interacta el hombre y la mquina. Este modelo se encarga
principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor
manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.
El paradigma de construccin de prototipos tiene tres pasos:
1. Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los
objetivos globales, se identifican los requisitos conocidos y las reas donde es
obligatorio ms definicin.
2. Construir y revisar la maqueta (prototipo).
3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.
Este modelo es til cuando:
El cliente no identifica los requisitos detallados.

El responsable del desarrollo no est seguro de la eficiencia de un algoritmo,
sistema operativo o de la interface hombre-mquina.
Etapas para la elaboracin del Modelo de Prototipo.

Ilustracin 2(etapas del modelo de prototipo)
Ciclo de Vida de un Sistema basado en Prototipo.
Una maqueta o prototipo de pantallas muestra la interfaz de la aplicacin, su cara
externa, pero dicha interfaz est fija, esttica, no procesa datos. El prototipo no
tiene desarrollada una lgica interna, slo muestra las pantallas por las que ir
pasando la futura aplicacin.
Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que
satisface los requisitos y necesidades que se han entendido claramente. Realiza, por
tanto, un proceso real de datos, para contrastarlo con el usuario. Se va modificando
y desarrollando sobre la marcha, segn las apreciaciones del cliente.
Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el
software est constantemente variando, pero, a la larga, genera un producto ms
seguro, en cuanto a la satisfaccin de las necesidades del cliente.
Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las
necesidades del cliente y despus no se va a aprovechar ni total ni parcialmente en

la implementacin del sistema final se habla de un prototipo desechable.
Para que la construccin de prototipos sea posible se debe contar con la
participacin activa del cliente.
Ilustracin 3(sistema basado en prototipo)
Ventajas del Modelo de Prototipo.
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debera tomar la interaccin humano-mquina.
Modelo Espiral
El modelo en espiral, propuesto originalmente por Boehm, es un modelo de
proceso de software evolutivo que conjuga la naturaleza iterativa de construccin

de prototipos con los aspectos controlados y sistemticos del modelo lineal
secuencial. Proporciona el potencial para el desarrollo rpido de versiones
incrementales del software. En el modelo espiral, el software se desarrolla en una
serie de versiones incrementales. Durante las primeras iteraciones, la versin
incremental podra ser un modelo en papel o un prototipo. Durante las ltimas
iteraciones, se producen versiones cada vez ms completas del sistema diseado.
El modelo en espiral se divide en un nmero de actividades de marco de
trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis
regiones de tareas.
Ilustracin 4(modelo espiral)
Comunicacin con el cliente: Las tareas requeridas para establecer
comunicacin entre el desarrollador y el cliente.

Planificacin: Las tareas requeridas para definir recursos, el tiempo y otra
informacin relacionadas con el proyecto.
Anlisis de riesgos: Las tareas requeridas para evaluar riesgos tcnicos y de
gestin.
Ingeniera: Las tareas requeridas para construir una o ms representaciones de
la aplicacin.
Construccin y accin: Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario (por ejemplo: documentacin y prctica).
Evaluacin del cliente: Las tareas requeridas para obtener la reaccin del
cliente segn la evaluacin de las representaciones del software creadas durante
la etapa de ingeniera e implementada durante la etapa de instalacin.
Cada una de las regiones est compuesta por un conjunto de tareas del trabajo,
llamado conjunto de tareas, que se adaptan a las caractersticas del proyecto que va
a emprenderse. Para proyectos pequeos, el nmero de tareas de trabajo y su
formalidad es bajo. Para proyectos mayores y ms crticos cada regin de tareas
contiene tareas de trabajo que se definen para lograr un nivel ms alto de
formalidad. En todos los casos, se aplican las actividades de proteccin (por
ejemplo: gestin de configuracin del software y garanta de calidad del software).
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software
gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por
el centro. El primer circuito de la espiral puede producir el desarrollo de una
especificacin de productos; los pasos siguientes en la espiral se podran utilizar

para desarrollar un prototipo y progresivamente versiones ms sofisticadas del
software. Cada paso por la regin de planificacin produce ajustes en el plan del
proyecto.
El coste y la planificacin se ajustan con la realimentacin ante la evaluacin
del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de
iteraciones requeridas para completar el software.
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de
software a gran escala. Como el software evoluciona, a medida que progresa el
proceso el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en
cada uno de los niveles evolutivos.
El modelo en espiral demanda una consideracin directa de los riesgos tcnicos
en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los
riesgos antes de que se conviertan en problemticos. Pero al igual que otros
paradigmas, el modelo en espiral no es la panacea. Puede resultar difcil convencer
a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque
evolutivo es controlable.
Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con
esta habilidad para el xito. Si un riesgo importante no es descubierto y gestionado,
indudablemente surgirn problemas. Finalmente, el modelo no se ha utilizado tanto
como los paradigmas lineales secuenciales o de construccin de prototipos. Todava

tendrn que pasar muchos aos antes de que se determine con absoluta certeza la
eficacia de este nuevo e importante paradigma.
Modelo de Desarrollo por Etapas
El modelo de desarrollo de software por etapas es similar al Modelo de
prototipos ya que se muestra al cliente el software en diferentes estados sucesivos
de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle
al inicio del proyecto y por tanto se van desarrollando simultneamente con las
diferentes versiones del cdigo.
Ilustracin 5(modelo de desarrollo por etapas)
Pueden distinguirse las siguientes fases que se van repitiendo en cada etapa del diseo.
Especificacin conceptual
Anlisis de requisitos
Diseo inicial
Diseo detallado, codificacin, depuracin y liberacin.
Este modelo estipula que el software ser desarrollado en sucesivas etapas:

1. Plan operativo: Etapa donde se define el problema a resolver, las metas del
proyecto, las metas de calidad y se identifica cualquier restriccin aplicable al
proyecto.
2. Especificacin de requisitos Permite entregar una visin de alto nivel sobre
el proyecto, poniendo nfasis en la descripcin del problema desde el punto de
vista de los clientes y desarrolladores. Tambin se considera la posibilidad de
una planificacin de los recursos sobre una escala de tiempos.
3. Especificacin funcional Especifica la informacin sobre la cual el software a
desarrollar trabajar.
4. Diseo Permite describir como el sistema va a satisfacer los requisitos. Esta
etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de
detalle generalmente describen los componentes o mdulos que formarn el
software a ser producido. Los niveles ms bajos, describen, con mucho
detalle, cada mdulo que contendr el sistema.
5. Implementacin Aqu es donde el software a ser desarrollado se codifica.
Dependiendo del tamao del proyecto, la programacin puede ser distribuida
entre distintos programadores o grupos de programadores. Cada uno se
concentrar en la construccin y prueba de una parte del software, a menudo
un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas
las funciones estn correctamente implementadas dentro del sistema.
6. Integracin Es la fase donde todos los subsistemas codificados
independientemente se juntan. Cada seccin es enlazada con otra y, entonces,
probada. Este proceso se repite hasta que se han agregado todos los mdulos y
el sistema se prueba como un todo.

7. Validacin y verificacin Una vez que el sistema ha sido integrado, comienza
esta etapa. Es donde es probado para verificar que el sistema es consistente
con la definicin de requisitos y la especificacin funcional. Por otro lado, la
verificacin consiste en una serie de actividades que aseguran que el software
implementa correctamente una funcin especfica. Al finalizar esta etapa, el
sistema ya puede ser instalado en ambiente de explotacin.
8. Mantenimiento El mantenimiento ocurre cuando existe algn problema
dentro de un sistema existente, e involucrara la correccin de errores que no
fueron descubiertos en las fases de prueba, mejoras en la implementacin de
las unidades del sistema y cambios para que responda a los nuevos requisitos.
La mantencin se puede clasificar en: correctiva, adaptativa, perfectiva y
preventiva.
Modelo de Desarrollo Iterativo y Creciente o Iterativo e Incremental
El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el
enfoque incremental de desarrollo como una forma de reducir la repeticin del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo
se conoce tambin bajo las siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con

la filosofa interactiva de Construccin de Prototipos. Como se muestra en la
Figura 6, el modelo incremental aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software. El primer incremento generalmente es un producto
esencial denominado ncleo.
Ilustracin 6(modelo incremental)
Sin embargo, para la produccin del Software, se usa el principio de trabajo en
cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha
elementos al final de cada incremento a fin de que el software se adapte mejor a sus
necesidades reales. El proceso se repite hasta que se elabora el producto completo. De
esta forma el tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo es
particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los
primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se aadir personal, de ser necesario. Por otro lado, los incrementos se
pueden planear para gestionar riesgos tcnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al
final terminar siendo la solucin completa requerida por el cliente, pero stas partes
no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este
necesitando con ms urgencia, de los puntos ms importantes del proyecto, los
requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se
deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada
versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que
podr ser entregada al cliente para que ste pueda trabajar en ella y el programador
pueda considerar las recomendaciones que el cliente efecte para hacer mejoras en el
producto. Estas nuevas mejoras debern esperar a ser integradas en la siguiente
versin junto con los dems requerimientos que no fueron tomados en cuenta en la
versin anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa
del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su
propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus
interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo,
sino nicamente correccin de errores. Dado que la arquitectura completa se
desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al
comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de
requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son ms importantes. Con las funcionalidades priorizadas, se puede
confeccionar un plan de incrementos, donde en cada incremento se indica un
subconjunto de funcionalidades que el sistema entregar. La asignacin de
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento.
Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.
Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que
se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
Modelo de Desarrollo Rpido de Aplicaciones
El RAD es un proceso de desarrollo de software, desarrollado inicialmente por
James Martin en 1980. El mtodo comprende el desarrollo iterativo, la construccin
de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rpido de
aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de
ejecucin.
El Desarrollo Rpido de Aplicaciones (DRA) (Rapid Application Development
RAD) es un modelo de proceso del desarrollo del software lineal secuencial que
enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptacin a Alta
velocidad en el que se logra el desarrollo rpido utilizando un enfoque de
construccin basado en componentes. Si se comprenden bien los requisitos y se limita
el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un
sistema completamente funcional dentro de periodos cortos de tiempo. Cuando se

utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA
comprende las siguientes fases:
Modelado de gestin: el flujo de informacin entre las funciones de gestin se
modela de forma que responda a las siguientes preguntas: Qu informacin
conduce el proceso de gestin? Qu informacin se genera? Quin la genera?
A dnde va la informacin? Quin la proceso?
Modelado de datos: el flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para
implementar una funcin de gestin. Las descripciones del proceso se crean para
aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin
entre los objetos.
Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar componentes de
programas ya existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas automticas
para facilitar la construccin del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.

Ilustracin 7(modelo de desarrollo rpido de aplicaciones)
Obviamente la limitacin de tiempo impuesto en un proyecto DRA demanda
mbito en escalas. Si una aplicacin de gestin puede modularse se forma que
permita completarse cada una de las funciones principales en menos de tres meses
(utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de
las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un
solo conjunto.
Algunos inconvenientes:
Para proyectos grandes, aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el nmero correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rpidas
actividades necesarias para completar un sistema en un marco de tiempo
abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los
proyectos DRA fracasaran.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se
puede modernizar adecuadamente. La construccin de los componentes necesarios
para DRA ser problemtico. Si est en juego el alto rendimiento, y se va a conseguir
el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA
puede que no funcione. DRA no es adecuado cuando los riesgos tcnicos son altos.
Esto ocurre cuando una nueva aplicacin hace uso de tecnologas nuevas, o cuando el
nuevo software requiere un alto grado de interoperabilidad con programas de
computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La
reutilizacin es la piedra angular de las tecnologas de objetos, y se encuentra en el
modelo de proceso de ensamblaje.
Ventajas de RAD
1. Comprar puede ahorrar dinero en comparacin con construir.
2. Los entregables pueden ser fcilmente trasladados a otra plataforma.
3. El desarrollo se realiza a un nivel de abstraccin mayor.
4. Visibilidad temprana.
5. Mayor flexibilidad.
6. Menor codificacin manual.
7. Mayor involucramiento de los usuarios.
8. Posiblemente menos fallas.
9. Posiblemente menor costo.
10. Ciclos de desarrollo ms pequeos.
11. Interfaz grfica estndar.
MEDIDAS METRICAS E INDICADORES
Ilustracin 8(medidas mtricas e indicadores)
Las mtricas del software se refieren a un amplio elenco de mediciones para el
software de computadora. La medicin se puede aplicar al proceso del software con el
intento de mejorarlo sobre una base continua. Se puede utilizar en el proyecto del
software para ayudar en la estimacin, el control de calidad, la evaluacin de
productividad y el control de proyectos. Finalmente, el ingeniero de software puede

utilizar la medicin para ayudar a evaluar la calidad de los resultados de trabajos
tcnicos y para ayudar en la toma de decisiones tctica a medida que el proyecto
evoluciona.
En el contexto de gestin de proyectos de software, existe una gran preocupacin
por las mtricas de productividad y de calidad -medidas de salida (finalizacin) del
desarrollo del software, basadas en el esfuerzo y tiempo empleados, y medidas de la
utilidad del producto obtenido.
Medimos para mejorar cuando recogemos la informacin cuantitativa que nos
ayuda a identificar obstculos, problemas de raz, ineficiencias y otras oportunidades
para mejorar la calidad del producto y el rendimiento del proceso.
Mediciones del Software
Mtricas Directas: Aquellas que no depende de ninguna mtrica de otro
atributo.
Ejemplo: costo, esfuerzo, lneas de cdigo, velocidad de ejecucin, nmero de
Defectos
Mtricas Indirectas: Son aquellas que se obtienen a partir de mtricas
directas.
Ejemplo: productividad, calidad, complejidad, eficiencia, fiabilidad, etc.
11.2. PROGRAMACION EN INTERNET
Django
Django es un framework para aplicaciones web gratuito y open source, escrito en
Python. Es un WEB framework - un conjunto de componentes que te ayudan a
desarrollar sitios web ms fcil y rpidamente.
Vers, cuando ests construyendo un sitio web, frecuentemente necesitas un
conjunto de componentes similares: una manera de manejar la autenticacin de
usuarios (registrarse, iniciar sesin, cerrar sesin), un panel de administracin para tu
sitio web, formularios, una forma de subir archivos, etc.
Por suerte para ti, hace tiempo varias personas notaron que los desarrolladores
web enfrentan problemas similares cuando construyen un sitio nuevo, por eso juntaron
cabezas y crearon frameworks (Django es uno de ellos) que te ofrecen componentes
listos para usarse.
Los frameworks existen para ahorrarte tener que reinventar la rueda y ayudarte a
aliviar la carga cuando construyes un sitio.
Por qu necesitas un framework?
Para entender para que es Django, necesitamos mirar ms de cerca a los
servidores. Lo primero es que el servidor necesita saber que quieres que te sirva una
pgina web.
Imagina un buzn (puerto) el cual es monitoreado por cartas entrantes (peticiones).
Esto es realizado por un servidor web. El servidor web lee la carta, y enva una
respuesta con una pgina web. Pero cuando quieres enviar algo, tienes que tener algn
contenido. Y Django es algo que te ayuda a crear el contenido.
Arquitectura de la aplicacin
Una aplicacin web es proporcionada por un servidor web y utilizada por usuarios
que se conectan desde cualquier punto va clientes web (browsers o navegadores). La
arquitectura de un sitio web tiene tres componentes principales:
Un servidor Web
Una conexin de red
Uno o ms clientes
El servidor Web distribuye pginas de informacin formateada a los clientes que
las solicitan. Los requerimientos son hechos a travs de una conexin de red, y para
ello se usa el protocolo HTTP. Una vez que se solicita esta peticin mediante el
protocolo HTTP y la recibe el servidor Web, ste localiza la pgina Web en su sistema
de archivos y la enva de vuelta al navegador que la solicit.
Ilustracin 9(modelo cliente servidor)
Las aplicaciones Web estn basadas en el modelo Cliente/Servidor que gestionan
servidores web, y que utilizan como interfaz pginas web.

Las pginas Web son el componente principal de una aplicacin o sitio Web. Los
browsers piden pginas (almacenadas o creadas dinmicamente) con informacin
a los servidores Web. En algunos ambientes de desarrollo de aplicaciones Web,
las pginas contienen cdigo HTML y scripts dinmicos, que son ejecutados por el
servidor antes de entregar la pgina.
Una vez que se entrega una pgina, la conexin entre el browser y el servidor Web
se rompe, es decir que la lgica del negocio en el servidor solamente se activa por la
ejecucin de los scripts de las pginas solicitadas por el browser (en el servidor, no en
el cliente). Cuando el browser ejecuta un script en el cliente, ste no tiene acceso
directo a los recursos del servidor. Hay otros componentes que no son scripts, como
los applets (una aplicacin especial que se ejecuta dentro de un navegador) o los
componentes ActiveX. Los scripts del cliente son por lo general cdigo JavaScript o
VBSscript, mezclados con cdigo HTML.
La coleccin de pginas son en una buena parte dinmicas (ASP, PHP, etc.), y
estn agrupadas lgicamente para dar un servicio al usuario. El acceso a las pginas
est agrupado tambin en el tiempo (sesin). Los componentes de una aplicacin Web
son:
1. Lgica de negocio.
Parte ms importante de la aplicacin.
Define los procesos que involucran a la aplicacin.

Conjunto de operaciones requeridas para proveer el servicio.
2. Administracin de los datos.
Manipulacin de BD y archivos.
3. Interfaz
Los usuarios acceden a travs de navegadores, mviles, PDAs, etc.
Funcionalidad accesible a travs del navegador.
Limitada y dirigida por la aplicacin.
Las aplicaciones web se modelan mediante lo que se conoce como modelo de
capas, Una capa representa un elemento que procesa o trata informacin. Los tipos
son:
Modelo de dos capas: La informacin atraviesa dos capas entre la interfaz
y la administracin de los datos.
Modelo de n-capas: La informacin atraviesa varias capas, el ms habitual es el
modelo de tres capas.
Modelo de dos Capas.
Gran parte de la aplicacin corre en el lado del cliente (fat client).
Las capas son:
Cliente (fat client): La lgica de negocio est inmersa dentro de la aplicacin que
realiza el interfaz de usuario, en el lado del cliente.
Servidor: Administra los datos.

Las limitaciones de este modelo son.
Es difcilmente escalable
Nmero de conexiones reducida
Alta carga de la red.
La flexibilidad es restringida
La funcionalidad es limitada.
Ilustracin 10
Modelo de tres Capas.
Est diseada para superar las limitaciones de las arquitecturas ajustadas al
modelo de dos capas, introduce una capa intermedia (la capa de proceso) Entre
presentacin y los datos, los procesos pueden ser manejados de forma separada a
la interfaz de usuario o y a los datos, esta capa intermedia centraliza la lgica de
negocio, haciendo la administracin ms sencilla a, los datos se pueden integrar de
mltiples fuentes, las aplicaciones web actuales se ajustan a este modelo.
Las capas de este modelo son:

1. Capa de presentacin (parte en el cliente y parte en el servidor)
Recoge la informacin del usuario y la enva al servidor (cliente)
Manda informacin a la capa de proceso para su procesado
Recibe los resultados de la capa de proceso
Generan la presentacin
Visualizan la presentacin al usuario (cliente)
2. Capa de proceso (servidor web)
Recibe la entrada de datos de la capa de presentacin
Interacta con la capa de datos para realizar operaciones
Manda los resultados procesados a la capa de presentacin
3. Capa de datos (servidor de datos)
Almacena los datos
Recupera datos
Mantiene los datos
Segura la integridad de los datos

Ilustracin 11
12. METODOLOGA
12.1. MODELO DE INGENIERA DE SOFTWARE
Metodologa XP
Ilustracin 12(metodologa XP)
La metodologa XP es posiblemente la ms destacada de las metodologas giles y esto

se debe a su gran capacidad de adaptacin ante cualquier tipo de imprevisto que surja.
Pues la idea no es mantener ciertos requisitos desde que se est elaborando el proyecto,
sino que durante el proceso, estos vayan cambiando o vayan evolucionando
gradualmente sin complicaciones. Se podra decir que la metodologa XP o metodologa
de programacin extrema, como tambin se le conoce. Es la combinacin de las dems
metodologas, solamente que se van utilizando de acuerdo a como sea necesario, por eso
es considerada como la ms destacada de las metodologas giles. (HOSTING, 2016)
Valores de la Metodologa XP
Como toda metodologa, la programacin extrema cuenta con algunos valores que son
fundamentales para que se lleve a cabo como debe ser. En algunas otras metodologas
estos puntos los conocamos como principios bsicos, es realmente lo mismo solo que
ac los mencionan como valores. (HOSTING, 2016)
Comunicacin. El cdigo fuente de los programadores debe transmitir esa

comunicacin a todo el equipo, por eso las variables amigables. De igual forma,
se deben documentar las cosas ms relevantes, independientemente de que sean
comentadas en el cdigo, pero es importante tener un documento extra para
explicaciones extensas, de lo contrario el cdigo se ver infestado de escrito. En
cuando a la comunicacin entre personas, los programadores se comunican
constantemente ya que trabajan en parejas, la comunicacin que se tiene con el
cliente debe ser constante, pues recordemos que incluso el forma parte del
equipo de trabajo y es responsabilidad del cliente, comunicarnos algunas
actualizaciones que requiera en el proceso, nuevas ideas, soluciones a problemas
o sencillamente algn problema que el vea. Todo debe ser comunicado, esta
parte es realmente fundamental para el desarrollo de un producto exitoso.
(HOSTING, 2016)
Simplicidad. El primero de los valores de la metodologa de programacin XP,
es la simplicidad. Puesto que la idea es que el desarrollo sea veloz, por lo cual
todas las cuestiones de diseo se simplifican al mximo, lo mismo sucede con
las lneas de cdigo, si se pueden simplificar, se hacen, adems de que
regularmente el mismo cdigo es donde va la documentacin comentada, de esta
forma nos evitamos el estar haciendo documentacin extra. Por esta razn,
adems es importante que en el ciclo de desarrollo de software mediante la
metodologa XP, las variables, mtodos y clases, tengan nombres amigables y
relacionados, de este modo no solamente se ayuda el equipo de trabajo, el cual
de por s ya se debe conformar de dos personas por equipo, sino que adems,
cuando una persona nueva ingrese al proyecto, ser muy rpida su adaptacin.
(HOSTING, 2016)
Retroalimentacin. El hecho de que el cliente se encuentre involucrado en el
proyecto, ayudar inicialmente con la retroalimentacin. Pues conforme pasan
los das y se va analizando el cdigo por pequeas etapas, el cliente puede ir
corrigiendo, agregando, quitando o excluyendo algunas cosas, esa es la ventaja
de la programacin por periodos cortos de tiempo, es decir, imagina que llevas
varios meses desarrollando el proyecto y cuando vas con el cliente, el proyecto
no le gusta y desea hacer tantos cambios que te llevar una eternidad.
Precisamente eso es lo que se trata de evitar con la metodologa XP, que se tiren
varios meses de trabajo a la basura y mejor se vaya optimizando en pequeos
lapsos de tiempo. Pues gracias a que podemos realizar diversas pruebas
unitarias, podremos ver la salud de nuestro cdigo, una gran ventaja, pues si hay
problemas o errores, siempre estaremos a tiempo de realizar modificaciones y
soluciones. (HOSTING, 2016)
Valenta. Hay elementos donde el coraje o la valenta de los programadores ser
fundamental. Por ejemplo el dar solucin a los problemas frente a los cuales se
enfrente. El pasar por la eliminacin de cdigo fuente en el programa
desarrollado, aun cuando todo ese cdigo haya tomado una gran cantidad de
tiempo en hacerse o que tal el hecho de disear para hoy y no para maana.
Muchos lo hacen con esa idea en ocasiones, pero con un poco de valenta y
coraje que forman parte de los valores de la metodologa, seguramente el xito
llegar de manera anticipada. (HOSTING, 2016)
Respeto. Es importante para que haya una buena comunin entre los
programadores del equipo. Nunca hay que denigrar a nadie ni agregar u ofender,
pues un autoestima alto en el equipo garantizar un trabajo mucho ms eficiente.
Por esta razn, cosas como el cdigo fuente, las modificaciones, los fallos
obtenidos, los problemas o la solucin de problemas, son procesos que se deben
respetar para que el ambiente de trabajo tambin sea ptimo. (HOSTING, 2016)
Caractersticas que componen la metodologa XP
Tipo de Desarrollo Iterativo e Incremental. El mtodo est basado en lo que

son las mejoras continuas, a base de iteraciones y por supuesto un desarrollo
incremental al estilo espiral.
Pruebas Unitarias. Se utiliza software de codificacin eso s, dependiendo del
lenguaje que estemos usando es la herramienta que nos corresponde, pero de
este modo se analiza el cdigo y solucionan errores, antes de validarlo y darlo
por bueno.
Trabajo en Equipo. Es el trabajo en parejas, el objetivo es que el enfoque en
parejas sea mayor, las distracciones son menores y el aprendizaje del uno con el
otro permite que el avance del proyecto sea mucho ms eficiente que cuando una
persona es la encargada.
Alguien del equipo trabaja con el cliente. Es fundamental que el cliente
intervenga en el desarrollo, pero obviamente el no estar en la sala de desarrollo,
se debe asignar a una persona que sea le encargada de tener las reuniones con el
cliente de forma constante. El ser quien comunique al equipo los cambios o el
seguimiento del proyecto.
Correccin de Errores. Algo importante, el hecho de que la metodologa XP
sea realmente rpida para el desarrollo, no significa que se pasen por alto los
errores, de hecho primero se le tiene que dar correccin a los errores antes de
seguir avanzando en el proyecto.
Reestructuracin del Cdigo. La idea es clara una re facturacin del cdigo
siempre se debe realizar. Con esto lo que haremos es simplificar el cdigo pero
no las funciones. Pues regularmente cuando desarrollamos, agregamos algunas
cosas que pueden ser innecesarias y que no afectan en el funcionamiento del
sistema, estas son precisamente las que hay que re facturar.
El Cdigo es de todos. Realmente aunque se trabaje en equipos, al final todos
tendrn la posibilidad de ver el cdigo, proponer cambios o incluso hacerlos. La
idea es que si uno no detecta un error, otro lo podr hacer, por eso el cdigo
fuente es compartido entre todos.
Cdigo simple es la clave. Algo importante con la metodologa extrema, es que
la simplicidad siempre llevar la ventaja. Principalmente porque cuando se
requiera hacer un cambio, si el cdigo fuente es muy complejo, posiblemente
lleve muchas horas realizar los cambios e incluso una alternativa seria ya no
hacer ningn cambio para no perder tiempo. Esta es precisamente la razn por la
cual el cdigo simple, es fundamental en la metodologa.
Bsicamente, lo que es la simplicidad y la comunicacin van de la mano. Puesto que a

mayor simplicidad, la comunicacin necesaria ser menor. Haciendo que la eficiencia se
incremente y la prdida de tiempo en comunicacin sea menor. (HOSTING, 2016)
Equipo de Trabajo dentro de una Metodologa XP
Programador. Es el encargado del cdigo del sistema y adems de hacer las

pruebas unitarias que se solicitan.
Tester. Bsicamente es el encargado de las pruebas del desarrollo. Lo que se
vaya implementando, el teste lo prueba y le comunica al cliente las pruebas
funcionales, para posteriormente comunicarle al equipo los resultados.
Cracker. El seguimiento ser lo suyo. Ser el encargado de realizar las
comparaciones entre los tiempos estimados antes de empezar un desarrollo y los
tiempos reales que se obtuvieron. Tratando siempre de mantener al tanto al
equipo para que traten de mejorar los tiempos.
Entrenador. Este elemento es realmente importante, puesto que es el
responsable del proyecto bsicamente y precisamente hace las funciones de un
entrenador. Se encarga de guiar al equipo por el camino que deben seguir.
Consultor. Va siendo un externo, pero que cuenta con conocimientos especficos
y que ser capaz de ayudar en la solucin de problemas.
Gestor. Posiblemente el lder ms alto. Si se trata de unir a los clientes con los
programadores, el gestor es el intermedio, es decir. Es el encargado de vincular e
interrelacionar al cliente con los programadores. (HOSTING, 2016)
12.2. PROGRAMACIN EN INTERNET I

12.2.1. ARBOL DE DIRECTORIO DE LA APLICACIN
Ingresamos a Este equipo
Ingresamos a la unidad
(C:) de nuestro equipo en
donde se encuentra
alojado nuestro proyecto.
Ilustracin 13
Dentro ya de la unidad C:\

Ingresamos a la carpeta
ProyectosPython donde
encontraremos los
proyectos que estemos
desarrollando.
Ilustracin 14
C: \ProyectosPython, encontramos todos los proyectos
Ingresamos en la
carpeta de nuestro
proyecto que en este
caso tiene el nombre
de ProjectITSS
Ilustracin 15
C:\ProyectosPython\ProjectITSS
Dentro de la carpeta principal

de nuestro proyecto
encontraremos un archivo el
cual es manage.py el cual nos
permite levantar el servidor
para nuestro proyecto
Ilustracin 16
C:\ProyectosPython\ProjectITSS\Principal
Los siguientes archivos que
encontramos son
indispensables para la
aplicacin y a nivel de ellos
encontramos archivos que
permite visualizar y asignar las
rutas especficas las cuales son
views.py y urls.py
Ilustracin 17
C:\ProyectosPython\ProjectITSS\Principal\migrations
En la carpeta
migrations encontramos
la conexin de django y
python
Ilustracin 18
C:\ProyectosPython\ProjectITSS\Principal\static
En la carpeta static se
encuentran las subcarpetas que
contienen las imgenes,
estilos, fuentes y los
JavaScript de nuestro proyecto
Ilustracin 19
C:\ProyectosPython\ProjectITSS\Principal\static\css
En la carpeta css
encontramos todos los
estilos que
implementaremos en el
proyecto.
Ilustracin 20
C:\ProyectosPython\ProjectITSS\Principal\static\fonts
En la carpeta fonts
encontramos todas las
fuentes que le
agregamos a nuestro
proyecto.
Ilustracin 21
C:\ProyectosPython\ProjectITSS\Principal\static\images
En la carpeta images
encontraremos las
imgenes que vamos a
utilizar en el proyecto.
Ilustracin 22
C:\ProyectosPython\ProjectITSS\Principal\static\js
En la carpeta js
encontramos los efectos
que le darn un atractivo a
nuestro proyecto
Ilustracin 23
C:\ProyectosPython\ProjectITSS\Principal\templates\Principal
En la carpeta templates
y luego en una
subcarpeta Principal
encontramos los
archivos cada uno de los
Ilustracin 24
12.2.2. INTERFACES DEL ANTES Y DESPUES DE LA PLANTILLA
Plantilla Inicial
Ilustracin 25
Plantilla Final
Ilustracin 26
13. PROPUESTA DE ACCIN O DESARROLLO

13.1. INGENIERA DE SOFTWARE
13.1.1. DESCRIPCIN DE LA EMPRESA
El Seor Manuel Alfonso Manitio Conumba, crea el Instituto Tcnico Superior

Particular Sudamericano, para la formacin de Tecnlogos, por lo que se hace el trmite
respectivo en el Ministerio de Educacin y Cultura, y con fecha 4 de junio de 1996,
autoriza con resolucin Nro. 2403, la creacin y el funcionamiento de este Instituto
Superior. Con resolucin Nro. 971 del 21 de septiembre de 1999, resuelve el Ministerio
de Educacin y Cultura, elevar a la categora de INSTITUTO TECNOLGICO
SUPERIOR SUDAMERICANO (ITSS).
Esta Institucin cuenta con ms de 20 aos de experiencia que lo ha hecho

convertirse en una institucin muy prestigiosa a nivel nacional en el mbito de la
educacin atrayendo a muchos estudiantes provenientes especialmente del cantn Loja;
sin embargo otra gran poblacin es procedente de cantones como: Cariamanga, Macar,
Amaluza, Zumba, Zapotillo, Catacocha, Olmedo, Macar, Saraguro y de otras
provincias como: El Oro, Zamora Chinchipe, Azuay e incluso de la Regin Insular
Galpagos. Se encuentra ubicado la ciudad de Loja en las calles Miguel Riofro 14-15
entre Sucre y Bolvar. Entre las carreras que permite esta institucin especializarse se
encuentran: Tcnicos en Sistemas de Automatizacin, Secretariado Ejecutivo, Finanzas
y Banca, Electrnica, Gestin Ambiental, Dise Grafico y Publicidad, Gastronoma, y
Administracin Turstica.
Misin: Formar gente de talento con calidad humana, acadmica, basada en

principios y valores, cultivando pensamiento crtico, reflexivo eh investigativo, para
que comprendan que en la vida es la bsqueda de un permanente aprendizaje.
Visin: Ser el mejor Instituto Tecnolgico del Pas, con una proyeccin
internacional, para entregar a la sociedad hombres y mujeres ntegros, profesionales
excelentes, lderes en todos los campos, con espritu emprendedor, con libertad de
pensamiento y accin.
Valores: Libertad, Responsabilidad, Disciplina, Constancia, Estudio.
13.1.2. AMBITO
13.1.2.1. FUNCIONES
REQUERIMIENTOS FUNCIONALES DE LA APLICACIN WEB QUE

AUTOMATICE LAS TAREAS DE GESTIN DEL DEPARTAMENTO DE
TALENTO HUMANO
REF. FUNCIN CATEGORIA

R1 Administracin de Usuarios
R1.1 El sistema deber permitir registrar un nuevo Usuario, EVIDENTE
con un id_Usuario secuencial, que se incrementara
automticamente al momento de registrar el usuario.
R1.2 El sistema deber permitir consultar todos los EVIDENTE
Usuarios que estn registrados en el sistema.
R1.3 El sistema deber permitir buscar un usuario y activar EVIDENTE
sus campos para modificarlos en caso de que se
requiera realizar algn cambio en el registro.
R1.4 El sistema deber permitir Dar de baja registro de EVIDENTE
usuario, en caso de que se desee inactivarlo.
R2 Gestin de docentes
docentes que estn registrados en el Web server del
Instituto.
R3 Administracin de registro diario
R3.1 El sistema deber permitir registrar un nuevo Rdiario, EVIDENTE
con un id_Rdiario secuencial, que se incrementara
automticamente al momento de registrar el docente.
R3.2 El sistema deber permitir consultar todos los Rdiario EVIDENTE
que estn registrados en el sistema.
R3.3 El sistema deber permitir buscar un Rdiario y activar EVIDENTE
sus campos para modificarlos en caso de que se
requiera realizar algn cambio en el registro.
Rdiario, en caso de que se desee inactivarlo.
R3.5 El sistema deber permitir consultar y seleccionar el EVIDENTE
docente deseado que este registrado en el web server
del Instituto Tecnolgico Sudamericano.
R3.6 El sistema deber permitir seleccionar el horario EVIDENTE
correspondiente al docente ya sea diurno, nocturno o
fin de semana.
R3.7 El sistema deber permitir seleccionar la puntualidad EVIDENTE
de cada docente seleccionando si llego tarde y qu
tiempo de atraso tiene.
R3.8 El sistema deber permitir seleccionar si el docente EVIDENTE
lleva correctamente utilizado el uniforme de la
Institucin.
utiliza el infocus en su clase y durante qu tiempo.
realiza el uso del celular y las redes sociales en clases.
R3.11 El sistema deber permitir seleccionar que tipo de EVIDENTE
clase est realizando el docente ya sea clase magistral,
trabajo grupal, trabajo individual o ninguna.
R3.12 El sistema deber permitir ingresar alguna EVIDENTE
observacin sobre la clase del docente.
R3.13 El sistema deber permitir imprimir registro de EVIDENTE
Rdiario, en caso de que lo desee.
R4 Gestin de registro mensual
Rmensual que estn registrados en el sistema.
R4.2 El sistema deber permitir imprimir registro de EVIDENTE
Rmensual, en caso de que lo desee.
R4.3 El sistema deber permitir modificar nombres de EVIDENTE
emisores, receptores y detalle del informe del
Rmensual si es necesario.
R5 Administracin de control acadmico.
R5.1 El sistema deber permitir registrar un nuevo EVIDENTE
Racademico, con un id_Racademico secuencial, que
se incrementara automticamente al momento de
registrar el docente.
Racademico que estn registrados en el sistema.
R5.3 El sistema deber permitir buscar un Racademico y EVIDENTE
activar sus campos para modificarlos en caso de que
se requiera realizar algn cambio en el registro.
Racademico, en caso de que se desee inactivarlo.
R5.6 El sistema deber permitir seleccionar el rea y EVIDENTE
asignatura en donde el docente est dictando su clase.
R5.7 El sistema deber permitir seleccionar si el docente ha EVIDENTE
cargado datos en el EVA del PEA, planificaciones
semanales y clases dictadas.
realiza el cumplimiento de la planificacin que tiene
la asignatura.
R5.9 El sistema deber permitir seleccionar si el docente en EVIDENTE
su hora de clase tiene la gua o materiales de apoyo en
forma digital, fsica o ninguna.
R5.10 El sistema deber permitir seleccionar si el docente en EVIDENTE
su hora de clase tiene registro de calificaciones
parciales en digital, fsico o no tiene.
tiene en su hora de clase el registro de asistencia en
digital, fsico o no tiene.
R5.12 El sistema deber permitir seleccionar en que EVIDENTE
categora se encuentra el uso de recursos y estrategias
del docente en su hora de clases ya sea Buena,
Regular o Mala.
R5.13 El sistema deber permitir seleccionar en que EVIDENTE
categora se encuentra la metodologa que aplica el
docente en su hora de clases ya sea Buena, Regular o
Mala.
cumple sus horas de Vinculacin y Practicas Pre-
Profesionales
realiza el cumplimiento de firmas diarias en registros
de avance de materia.
R5.16 El sistema deber permitir imprimir el registro de EVIDENTE
control acadmico deseado.
R5 Administracin de registro de coordinadores
R5.1 El sistema deber permitir registrar un nuevo EVIDENTE
Rcoordinador, con un id_Rcoordinador secuencial,
que se incrementara automticamente al momento de
registrar el Rcoordinador.
Rcoordinador que estn registrados en el sistema.
R5.3 El sistema deber permitir buscar un Rcoordinador y EVIDENTE
activar sus campos para modificarlos en caso de que
se requiera realizar algn cambio en el registro.
Rcoordinador, en caso de que se desee inactivarlo.
R5.6 El sistema deber permitir seleccionar el porcentaje EVIDENTE
que tenga el docente en los aspectos cuantitativos,
desarrollo de actividades por coordinador(a) en los
tems como Reuniones de carrera (RC), Practicas
Preprofecionales (PPP), Vinculacin con Colectividad
(VC), Proyecto integrador (PI).
R5.7 El sistema deber permitir seleccionar el porcentaje EVIDENTE
que tenga el docente en los aspectos cualitativos,
Cooperacin en la carrera para lograr sus objetivos en
los tems de Responsabilidad y Puntualidad (RP),
Eficiencia y Eficacia (EEF), Actitud y Compromiso
Institucional (ACI), Ausencia de fallos y coherencia
en aporte de los contenidos (AFC).
R5.8 El sistema deber calcular el total de porcentaje de los OCULTO
valores ingresados de cada docente.
R5.9 El sistema deber calcular la categora de Evaluacin OCULTO
del docente en rango y escala segn total de los
resultados obtenidos y lo calificara si el porcentaje
est en 100%-96% EXCELENTE, 95%-86% MUY
BUENO, 85%-70 ACEPTABLE, 69%-50%
MONITORIADO, 49%-0% NO ACEPTABLE.
Tabla 1 (funciones del sistema)
13.1.2.2. RENDIMIENTO
Objeto de Descripcin
rendimiento
Verificar El porcentaje del tiempo es de 0.25 milisegundos que es

usuario y tiempo de procesador consumido por la base de datos. Al
contrasea comparar el usuarios y contraseas que sean correctas.
Cargar El porcentaje de tiempo es de 0.5 milisegundos La

registros cantidad de memoria que se utiliza activamente por la
diarios base de datos en los informes diarios, mensuales
realizados con anterioridad. Aunque el desarrollador de
aplicaciones tiene el mximo control sobre cmo se
consume la memoria por la aplicacin, los
administradores del sistema pueden tener un impacto
significativo ajustando el tiempo de espera de la sesin.
Cargar El porcentaje de tiempo es de 5 milisegundos Al analizar
reportes el rendimiento con una carga artificialmente generada,
este contador le permite comprobar que las solicitudes se
tratan tan rpidamente como se envan.
Guardar El porcentaje de tiempo es de 0.1 milisegundos. Este

registros contador busca la base de datos donde debe almacenar
los registros generados.
Buscar El porcentaje de tiempo es de 0.5 milisegundos. Este
registros contador busca la base de datos donde se encuentra
almacenado el registro deseado.
Modificar El porcentaje de tiempo es de 0.5 milisegundos. Este

registro contador busca la base de datos donde se encuentra
almacenado el registro deseado y abre con campos a
modificarse.
Tabla 2(rendimiento)
13.1.2.3. RESTRICCIONES
Uso del Sitio
Esta aplicacin web pertenece al Instituto Tecnolgico Superior Sudamericano y a sus

autores. Tiene como fin automatizar procesos exclusivamente del departamento de
talento humano y no para uso comercial.
Contenido de Terceros
Cualquier opinin, declaracin, servicio, oferta u otra informacin o contenido
expresado o disponible en esta aplicacin por terceros pertenecen a sus respectivos
autores o distribuidores y no a la Institucin.
Informacin del Usuario.

En el curso del uso que usted haga de la aplicacin web y/o de los servicios puestos a su
disposicin en o a travs de la misma, se le pedir que nos proporcione su cuenta y
clave para poder ingresar al sistema y utilizar cierta informacin personalizada.
Informacin Privada o Delicada en Foros Pblicos.
La aplicacin realizara un guardado muy seguro donde todos los datos seleccionados
estarn ah e influirn en gran parte con los reportes que se presentaran con un lapso de
tiempo determinado. Ms bien realizar correctamente el uso de los datos para evitar
posibles inconvenientes utilice datos claros y precisos para un excelente reporte
solicitado.
13.1.2.4. INTERFACES
Ilustracin 27(login)
Ilustracin 28(principal)
Ilustracin 29(tablas)
Ilustracin 30(tablas)
Ilustracin 31(caratula)
13.1.3. MODELO DE INGENIERIA DE SOFTWARE

13.1.3.1. FASE DE PLANEACIN
Proceso: Recoleccin de Datos, Obtencin de permisos.
Recursos Involucrados: Ing. Lorena Pucha, Ing. Alex Yunga.
Herramientas utilizadas:
Entrevistas:
Departamento de Talento Humano (Ing. Marco Pachar)
Objetivo: Recolectar datos y permisos que intervienen en el desarrollo del sistema de

control de docentes.
Actividad:
Reunin general con el encargado del departamento de talento humano para

determinar procesos a automatizar.
Investigar sobre la metodologa a emplear en el sistema de software.
Investigar bibliografa (internet) sobre conceptos bsicos y lenguaje de
programacin HTML, CSS.
Resultados:
Obtencin de procesos deseados a automatizar.

Obtencin de dificultades que se presentan en el desarrollo del sistema.
Obtencin de restricciones en el sistema.
Obtencin de requerimientos funcionales y no funcionales del sistema.
Obtencin de posibles riesgos del sistema.
Obtencin de permisos para tener acceso a la informacin de la empresa para
desarrollar el sistema.
Entregables:
Diagrama del proceso actual del sistema.

Requerimientos funcionales y no funcionales.
Restricciones que se debe tomar en cuenta para el sistema.
Gestin de Riesgos del sistema.
Duracin:
Recoleccin de informacin para el sistema: 1 semana
Determinacin de requerimientos funcionales y no funcionales del sistema: 2
semanas.
Determinacin de gestin de riesgos: 1 semana
13.1.3.2. FASE DE DISEO
Proceso: Diseo de la Base de datos, Diseo de interfaces.
Recursos Involucrados: Sistema de recurso Humano, formatos de procesos.
Objetivo: Disear la base de datos y las interfaces del sistema para definir diseo de la
aplicacin.
Actividad:
Obtencin de las entidades, atributos de la base de datos para el sistema de

control de docentes.
Obtencin del diseo del diagrama de la base de clases del sistema.
Obtencin del diseo de del diagrama entidad-relacin del sistema.
Obtencin del diseo de los prototipos para el sistema.
Resultados:
Diseo de los diagramas de secuencia.

Diseo de los diagramas de colaboracin.
El diseo de la base de datos para el sistema.
El diagrama de clases del sistema.
El diagrama entidad relacin del sistema.
El diseo de los prototipos del sistema.
Revisin de los diseos de interfaces del sistema.
Entregables:
Diseo de la base de datos del sistema de control de docentes

Diagrama entidad-relacin del sistema.
Diagrama de secuencia del sistema.
Diagrama de colaboracin del sistema.
Interfaces del sistema.
Duracin:
Dise de la base de datos modelo para el sistema: 3 semanas.
Diseo y prueba de prototipos: 3 semanas
13.1.3.3. FASE DE CODIFICACIN
Proceso: Codificacin de los procesos, conexin de interfaces.
Recursos Involucrados: Sistema de procesos, interfaces.
Objetivo: Codificar toda la conexin de las interfaces para q empiecen a interactuar

entre ellas y codificacin de los procesos que va a automatizar la aplicacin.
Actividad:
Obtencin de programas necesarios para la codificacin de la aplicacin.

Obtencin de interfaces de la aplicacin.
Obtencin de procesos a automatizar en la aplicacin.
Obtencin de datos necesarios.
Resultados:
Programas listos para codificar la aplicacin.

Interconexin de las interfaces de la aplicacin
Codificacin de procesos automatizados.
Cargar la base de datos necesaria para el sistema.
Entregables:
Aplicacin de control de docentes automatizando procesos.
Duracin:
Obtencin de programas para la codificacin de la aplicacin: 1 semana.

Interconexin de interfaces de la aplicacin: 2 semanas.
Codificacin de los procesos a realizar por la aplicacin: 4 semanas.
Cargar la base de datos al sistema: 1 semana
13.1.3.4. FASE DE PRUEBA
Proceso: Implementar aplicacin.
Recursos Involucrado: Ing. Marco Pachar encargado del departamento de Talento

Humano.
Objetivo: Implementar la aplicacin de control de docentes y que todos los procesos

sean automatizados correctamente cumpliendo los requerimientos necesarios.
Actividad:
Reunin con el encargado del departamento de talento humano para la

respectiva indicacin de la aplicacin.
Empezar a cargar datos respectivos sobre la aplicacin con datos verdicos
acerca del control de docentes.
Resultados:
La aplicacin cumple con todos los procesos de automatizacin correctamente

como se esperaba.
El usuario est satisfecho con el producto entregado.
Entregables:
Aplicacin correctamente entregada con toda la documentacin y ya

funcionando en su ambiente de trabajo.
Duracin:
Capacitacin del manejo de la aplicacin: 1 semana.

Implementacin de la aplicacin: 1 mes.
13.1.3.5. FASE DE INCREMENTO DEL SOFTWARE
Proceso: Incremento de nueva fase a la aplicacin.
Recursos Involucrado: procesos a mejorar o implementar.
Objetivo: Realizar un nuevo incremento a la aplicacin de control de docentes con

nuevos requisitos o procesos a automatizar implementando nuevos mdulos.
Actividad:
Entrevista con el encargado del departamento de talento humano para la

respectiva comunicacin sobre nuevas versiones de la aplicacin.
Realizar el respectivo anlisis de los nuevos requerimientos.
Resultados:
Obtener informacin necesaria sobre los cambios para la nueva versin.

Disear interfaces para los nuevos procesos.
Codificar el incremento del mdulo para la aplicacin.
Implementar nuevo mdulo para mejorar la aplicacin de control de docentes.
Entregables:
Nuevo mdulo correctamente implementado con toda la documentacin y con

funcionamiento correcto en su ambiente de trabajo.
Duracin:
Anlisis del nuevo mdulo : 1 semana

Dise de interfaces para el nuevo mdulo: 2 semanas.
Codificacin del mdulo: 1 mes.
Pruebas del mdulo: 2 semanas.
Implementacin del nuevo mdulo: 1 mes.
13.1.4. PLANIFICACIN O CRONOGRAMA
Ilustracin 32
13.1.5. RECURSOS
RECURSOS HUMANOS
Dos personas:
Sr. Denys Israel Jumbo Guamn
Sr. Jorge Luis Robles Jimnez.
RECURSOS DE COMPONENTES REUTILIZABLES
Componentes ya desarrollados:
Diseo fsico de formatos de los procesos a automatizar.
RECURSO DEL ENTORNO
Hardware:
Un computador porttil o escritorio, Tablet o celular.
Software:
Navegador Web
Acceso a internet
1 IDENTIFICACIN DE RIESGOS
13.1.6. RIESGOS 13.1.7. ca 13.1.8. 13.1.9. 13.1.10.

tego p i R
ra
13.1.11. 13.1.12. El cliente piensa en una velocidad de 13.1.13. Cl 13.1.14. 13.1.15. 13.1.16.
desarrollo que el personal de desarrollo ient 7 c
no puede alcanzar. e
13.1.17. 13.1.18. Direccin o marketing insisten en 13.1.19. Or 13.1.20. 13.1.21. 13.1.22.
tomar decisiones tcnicas que alargan la gani 5 M
planificacin. zaci
n o
Gest
in
13.1.23. 13.1.24. Los usuarios finales insisten en nuevos 13.1.25. U 13.1.26. 13.1.27. 13.1.28.
requisitos. suari 8 c
os
Final
es
13.1.29. 13.1.30. Los ciclos de revisin/decisin del 13.1.31. Cl 13.1.32. 13.1.33. 13.1.34.
cliente para los planes, prototipos y ient 6 c
especificaciones son ms lentos de lo e
esperado.
13.1.35. 13.1.36. El cliente intenta controlar el proceso 13.1.37. Cl 13.1.38. 13.1.39. 13.1.40.
de desarrollo, con lo que el progreso es ient 5 C
ms lento de lo esperado. e
13.1.41. 13.1.42. Los requisitos se han adaptado, pero 13.1.43. R 13.1.44. 13.1.45. 13.1.46.
continan cambiando. equi 4 C
sitos
13.1.47. 13.1.48. El desarrollo de una interfaz de usuario 13.1.49. Pr 13.1.50. 13.1.51. 13.1.52.
inadecuada requiere volver a disearla y oduc 3 M
a implementarla. to
13.1.53. 13.1.54. La falta de un seguimiento exacto del 13.1.55. Pr 13.1.56. 13.1.57. 13.1.58.
progreso hace que se desconozca que el oces 6 M
proyecto est retrasado hasta que est o
muy avanzado.
13.1.59. 13.1.60. El tiempo de comunicacin del cliente 13.1.61. Cl 13.1.62. 13.1.63. 13.1.64.
es ms lento de lo esperado. ient 4 D
e
13.1.65. 13.1.66. Las partes del proyecto que no se han 13.1.67. R 13.1.68. 13.1.69. 13.1.70.
especificado claramente consumen ms equi 3 M
tiempo del esperado. sitos
13.1.71. 13.1.72. Un diseo demasiado sencillo no cubre 13.1.73. Di 13.1.74. 13.1.75. 13.1.76.
las cuestiones principales, con lo que hay seo 5 C
que volver a disear e implementar. e
Impl
eme
ntac
in
13.1.77. 13.1.78. Los componentes desarrollados por 13.1.79. Di 13.1.80. 13.1.81. 13.1.82.
separado no se pueden integrar de forma seo 2 M
sencilla, teniendo que volver a disear y e
repetir algunos trabajos. Impl
eme
ntac
in
13.1.83. 13.1.84. Las herramientas de desarrollo no 13.1.85. A 13.1.86. 13.1.87. 13.1.88.
funcionan como se esperaba, el personal mbi 3 C
de desarrollo necesita tiempo para ente
resolverlo o adaptarse a las nuevas /Infr
herramientas. aest
ruct
ura
de
Des
arrol
lo
13.1.89. Tabla 3(riesgos)
13.1.90.
13.1.91.
13.1.92.
13.1.93. 13.1.94. RSGR
13.1.95. 13.1.96. ESTR 13.1.97. ESTRA 13.1.98. ES 13.1.99.

RIESGO ATEGIA TEGIAS TRAT R
S DE DE EGIA
REDUC SUPERVI S DE
CION SION GEST
ION
13.1.100. 13.1.101. 13.1.102. * 13.1.103. 13.1.104.
El cliente * Indicar al * Notificar
piens cliente Controlar con
a en la el avance tiem
una planific de po
veloc acin acuerdo situa
idad que se con lo cione
de va a planifica s
desar realizar do. perti
rollo y su * Realizar nent
que comple un es
el jidad a seguimie que
perso la hora nto a lo afect
nal de ir planifica en al
de avanza do el desa
desar ndo. cual no rrollo
rollo * Ir afecte al del
no trabaja tiempo proy
pued ndo de de ecto.
e la desarroll
alcan mano o.
zar. del *
cliente Consider
para ar
luego opiniones
no de
aument especiali
ar con stas las
el que
tiempo ayuden a
de mejorar
desarro con el
llo por avances
imprevi del
stos proyecto
urgente
s.
*
Contar
con
person
al
califica
do al
desarro
llo del
proyect
o.
13.1.105. Tabla 4(riesgo 1)
13.1.106. 13.1.107. RSGR

2
13.1.108. 13.1.109. 13.1.110. E 13.1.111. 13.1.112.
RIESGO ESTRATEGIAS STRATEGI ESTRATEGI R
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.113. 13.1.114. 13.1.115. * 13.1.116. 13.1.117.
Direccin o * Planificar y * Notificar
mark organiz Controlar con
eting ar de la toma tiem
insist manera de po
en en que decisione situa
toma todos s cione
r los urgentes s
decisi integra inespera perti
ones ntes damente nent
tcni aporten las es
cas en su cuales que
que respect alargan afect
alarg ivo con lo ya en y
an la momen planifica alarg
plani to. do. uen
ficaci *Tener con
n. una el
buena tiem
comuni po
cacin de
con los desa
involuc rrollo
rados .
en el
desarro
llo del
proyect
o.
13.1.119. 13.1.120. RSGR

3
13.1.121. 13.1.122. 13.1.123. E 13.1.124. 13.1.125.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.126. 13.1.127. 13.1.128. * 13.1.129. 13.1.130.
Los * Desde un En cada * Notificar
usuar principi avance con
ios o respectiv tiem
finale tomar o indicar po
s en al situa
insist cuenta usuario si cione
en en cada tiene s
nuev detalle informaci perti
os y n nent
requi anticip reciente es
sitos. ar a las con la que
necesid que afect
ades aportar. en al
de los * Tener desa
usuario un rrollo
s seguimie del
finales. nto proy
* Tener permane ecto.
en nte a lo
claro lo planifica
que el do en
usuario cuestin
desea que al
como finalizar
product no se
o e ir tenga
indican inconveni
do entes.
como
puede
mejorar
lo.
* Tomar
en
cuenta
cada
uno de
los
requeri
miento
s sean
vlidos
o no.
13.1.132. 13.1.133. RSGR

4
13.1.134. 13.1.135. 13.1.136. E 13.1.137. 13.1.138.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.139. 13.1.140. 13.1.141. * 13.1.142. 13.1.143.
Los ciclos * El cliente Estar en * Notificar
de debe comunic con
revisi estar acin tiem
n/de ms continua po
cisin compro con el cualq
del metido cliente uier
client en para duda
e cada poder ir que
para uno de avanzan veng
los los do en el a por
plane ciclos desarroll parte
s, del o del de
proto desarro proyecto. los
tipos llo de invol
y proyect ucra
espec o. dos
ificaci * Por en el
ones parte proy
son del ecto.
ms cliente
lento el
s de tiempo
lo que se
esper tome a
ado. las
revision
es
deben
ser lo
ms
pronto
posible.
* El
cliente
debe
tener
en
claro
de
cmo
quiere
que
este la
estruct
ura del
sistema
.
13.1.145. 13.1.146. RSGR

5
13.1.147. 13.1.148. 13.1.149. E 13.1.150. 13.1.151.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.152. 13.1.153. 13.1.154. * 13.1.155. 13.1.156.
El cliente * Identificar * Notificar
inten los Controlar con
ta requisit cada tiem
contr os y proceso po
olar anticip de situa
el ar desarroll cione
proce proces o a su s
so de os debido perti
desar futuros tiempo nent
rollo, que del cual es
con afecten no afecte que
lo al en afect
que desarro tiempo en al
el llo. de desa
progr * desarroll rrollo
eso Indicar o. del
es al * El proy
ms cliente proceso ecto.
lento que de
de lo antes revisin
esper de ir por el
ado. avanza cliente
ndo debe ser
cada lo ms
fase se pronto
lleva posible y
determi entendie
nados ndo cada
proces uno de
os a sus ciclos
seguir. realizado
s.
13.1.158. 13.1.159. RSGR

6
13.1.160. 13.1.161. 13.1.162. E 13.1.163. 13.1.164.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.165. 13.1.166. 13.1.167. * 13.1.168. 13.1.169.
Los * Cada Tener * Notificar
requi requisit claro los con
sitos o por procesos tiem
se mnimo principal po
han que es que situa
adapt seas debe cione
ado, debe realizar s
pero ser la perti
conti tomado aplicaci nent
nan en n. es
camb cuenta * Revisar que
iando para el cada afect
. desarro ciclo de en al
llo lo desarroll desa
cuan oy rrollo
no percatars del
impliqu e de que proy
e manera ecto.
retraso puede
s luego mejorar
ya en en el
el desarroll
desarro o.
llo.
*
Desarro
llar un
proyect
o en el
cual
permita
increm
entar
nuevos
mdulo
s de
mejora
miento
al
product
o.
*
13.1.171. 13.1.172. RSGR

7
13.1.173. 13.1.174. 13.1.175. E 13.1.176. 13.1.177.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.178. 13.1.179. 13.1.180. * 13.1.181. 13.1.182.
El * No realizar Tener un * Notificar
desar interfac control con
rollo es que respectiv tiem
de destaq o junto po
una uen a con el situa
interf las cliente cione
az de dems de cada s
usuar sino desarroll perti
io que o de una nent
inade satisfag interfaz es
cuad a la cual que
a necesid vaya de afect
requi ades y acuerdo en al
ere manejo a lo desa
volve para planifica rrollo
ra una do desde del
dise mejor un proy
arla y acogid principio. ecto.
a a de
imple las
ment mismas
arla. * No
sobrec
argar el
diseos
de las
interfac
es ya
que los
espacio
s son
muy
peque
os.
*
Realiza
r
diseos
con la
menor
cantida
d de
pasos
posible
sa
seguir
para
llegar a
realizar
alguna
accin.
13.1.183. Tabla 10(riesgo 7)
13.1.184. 13.1.185. RSGR

8
13.1.186. 13.1.187. 13.1.188. E 13.1.189. 13.1.190.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.191. 13.1.192. 13.1.193. * 13.1.194. 13.1.195.
La falta de * El equipo de En cada * Notificar
un trabajo avance con
segui debe respectiv tiem
mient dar un o indicar po
o consta al situa
exact nte usuario si cione
o del seguim tiene s
progr iento a informaci perti
eso cada n nent
hace proces reciente es
que oa con la que
se realizar que afect
desco o ya aportar. en al
nozca realiza * Tener desa
que d. un rrollo
el * seguimie del
proye Conoce nto proy
cto r que permane ecto.
est se nte a lo
retra debe ir planifica
sado desarro do en
hasta llando cuestin
que en que al
est cada finalizar
muy avance no se
avan del tenga
zado. proyect inconveni
o antes entes.
de que
ya no
se
puede
realizar
rectific
aciones
.
13.1.196. Tabla 11(riesgo 8)
13.1.197. 13.1.198. RSGR

9
13.1.199. 13.1.200. 13.1.201. E 13.1.202. 13.1.203.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.204. 13.1.205. 13.1.206. * 13.1.207. 13.1.208.
El tiempo * Desde un Junto * Notificar
de inicio la con el con
comu comuni cliente ir tiem
nicaci cacin revisand po
n con el o cada situa
del cliente etapa cione
client debe desarroll s
e es ser ada y perti
ms buena constatar nent
lento para que por es
de lo agilizar parte del que
esper los cliente afect
ado. proces est todo en al
os y claro y desa
retarda de esa rrollo
rlos. manera del
* Tener poder proy
una avanzar ecto.
comuni en
cacin nuevas
clara etapas
con el del
cliente proyecto.
de
manera
que se
le
facilite
la
revisin
de
avance
s del
proyect
o.
13.1.209. Tabla 12(riesgo 9)
13.1.210. 13.1.211. RSGR

10
13.1.212. 13.1.213. 13.1.214. E 13.1.215. 13.1.216.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.217. 13.1.218. 13.1.219. * 13.1.220. 13.1.221.
Las partes * Todo Revisar * Notificar
del requisit detallada con
proye o mente tiem
cto present cada uno po
que ado de los situa
no se desde requisito cione
han un s lo cual s
espec comien luego no perti
ificad zo tome nent
o debe ms es
clara estar tiempo que
ment especifi de los afect
e cado y esperado en al
cons entendi . desa
umen do lo rrollo
ms cual no del
tiemp tome proy
o del tiempo ecto.
esper para
ado. una
nueva
revisin
del
mismo.
* Los
requisit
os
deben
estar
claros
primer
amente
por
parte
de
quien
los
emite
para
quien
los
recibe
tenga
una
clarida
d del
mismo.
13.1.222. Tabla 13(riesgo 10)
13.1.223. 13.1.224. RSGR

11
13.1.225. 13.1.226. 13.1.227. E 13.1.228. 13.1.229.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.230. 13.1.231. 13.1.232. * 13.1.233. 13.1.234.
Un diseo * Asemejar El * Tener
dema los cliente medi
siado diseos debe das
sencil para estar de de
lo no que acuerdo resp
cubre cubran con cada aldo
las con fase de que
cuest caracte diseo pued
iones rsticas que se an
princi de uso vaya ser
pales y realizand aplic
, con manejo o. ables
lo de los * Se por
que usuario deben si
hay s inspeccio hay
que finales nar y incon
volve al aportar venie
ra momen en el ntes.
dise to de desarroll
ar e implem o del
imple entar el diseo y
ment sistema no tener
ar. . * inconveni
Los entes en
diseos etapas
deben posterior
cumplir es.
con lo
especifi
cado
desde
un
principi
o (ni
muy
extrava
gante
ni muy
sencillo
).
13.1.235. Tabla 14(riesgo 11)
13.1.236. 13.1.237. RSGR

12
13.1.238. 13.1.239. 13.1.240. E 13.1.241. 13.1.242.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.243. 13.1.244. 13.1.245. * 13.1.246. 13.1.247.
Los * Si no se Si en * Verificar
comp tiene la algunas si es
onent experie etapas reco
es ncia de es mejor men
desar haber trabajo dabl
rollad trabaja algunos e
os do compone traba
por compo ntes por jar
separ nentes separado los
ado por verificar com
no se separa que pone
pued do irlo luego ntes
en realiza puedan por
integ ndo de ser sepa
rar manera adaptabl rado
de ordena es al para
form da con sistemas lueg
a todo lo en que o
sencil ya estamos pode
la, previst trabajand r se
tenie o lo o integ
ndo cual no rado
que impliqu s sin
volve e ning
ra prdida n
dise de probl
ar y tiempo ema.
repet en
ir atapas
algun de
os desarro
traba llo
jos. superio
res.
13.1.248. Tabla 15(riesgo 12)
13.1.249. 13.1.250. RSGR

13
13.1.251. 13.1.252. 13.1.253. E 13.1.254. 13.1.255.
DE AS DE AS
REDUC SUPERVI DE
CION SION GEST
ION
13.1.256. 13.1.257. 13.1.258. * 13.1.259. 13.1.260.
Las * Desde un En cada * Aplicar
herra comien etapa de medi
mient zo desarroll das
as de selecci o de
desar onar verificar resp
rollo herrami si todo aldo
no entas est de por
funci que acuerdo si en
onan sirvan a lo etap
como para el requerido as de
se inicio y y no se desa
esper final va a rrollo
aba, del tener algo
el desarro problema no
perso llo del s al va
nal sistema momento de
de . de su acue
desar * impleme rdo
rollo Depend ntacin. con
neces iendo lo
ita del tipo requ
tiemp de erido
o sistema .
para que se
resol est
verlo por
o realizar
adapt tener
arse en
a las cuenta
nuev si va a
as ser
herra funcion
mient al con
as. las
herrami
entas
que se
va a
trabaja
r desde
un
comien
zo.
13.1.261. Tabla 16(riesgo 13)
14. RESPONSABLES Y PARTICIPANTES
Jorge Luis Robles Jimenez

Denys Israel Jumbo Guaman
15. CRONOGRAMA
Ilustracin 33 (cronograma de actividades)

16. PRESUPUESTO
RECURSOS HUMANOS
Cantida Nombre del Descripcin VALOR UNITARIO VALO
d Recurso R
TOTAL
3 Tutores Docentes que guiaron en --- ---
la ejecucin del Proyecto
4 Autores del Estudiantes que --- ---

proyecto desarrollan el proyecto
Integrador.
RECURSOS TECNOLGICOS
d Recurso. R
TOTAL
2 Computador Necesario para la 10.00 10.00
porttil realizacin del proyecto
2 Necesario para realizar 10.00 10.00
Internet consultas
bibliogrficas
RECURSOS LOGSTICOS
d Recurso R
TOTAL
.... Impresiones Necesario para la 10.00 10.00
presentacin final del
proyecto
1 Necesario para el 2.00 2.50
Anillados mejoramiento esttico
del proyecto
1 Proyector Necesario para la .
defensa del proyecto
1 CD Necesario para 2.00 2.00
constancia del proyecto
en forma digital
TOTAL 34.50
Tabla 17 (presupuesto del sistema)

17. CONCLUCIONES
Los sistemas de automatizacin los utilizan la mayora de empresas, ya que facilita llevar la informacin de forma ordenada,
sistemtica y segura.
El sistema de control de docentes permite ingresar todos los parmetros de control y entregar un reporte diario, mensual y por
periodo lectivo, segn se requiera y al mismo tiempo guardar un respaldo con toda la informacin dando seguridad al mismo y a la
empresa.
Este sistema de control de docentes ayuda al crecimiento de la empresa con la optimizacin de procesos ahorrando tiempo y
mejorando la presentacin de reportes con ms eficiencia y eficacia.
18. RECOMENDACIONES
Se debe utilizar los sistemas de automatizacin en todo tipo de empresa, ya que es muy efectivo facilitando trabajo, tiempo y dinero y
cuenta con seguridad para evitar la prdida de informacin.
Utilizar estos sistemas evita la redundancia de informacin y facilita el tratamiento de la misma.
Es factible tener en cuenta claves y nombres de usuarios del sistema, ya que son muy importantes para poder manejar la informacin.
19. BIBLIOGRAFA
A., E. (17 de mayo de 2016). openwebinars.net. Obtenido de https://openwebinars.net/blog/que-es-la-metodologia-agile/
HOSTING, O. (2016). okhosting.com. Obtenido de http://okhosting.com/blog/metodologias-del-desarrollo-de-software/

20. ANEXOS

Talento Humano Informe Final

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Talento Humano Informe Final

Caricato da

Copyright:

Formati disponibili

PROYECTO INTEGRADOR

DESARROLLO E IMPLEMENTACIN DE UNA APLICACIN WEB QUE

Jorge Luis Robles Jimenez

INGENIERA DE SOFTWARE: Ing. Lorena Pucha

DESARROLLO E IMPLEMENTACIN DE UNA APLICACIN WEB QUE

En la actualidad la informacin es la parte ms importante que existe hoy en da

ya que forma parte de nuestra evolucin. En tiempos remotos el trato de la informacin

de que se pierda ya que es muy complicado manipularla, tambin se puede deteriorar

ejecutaban con mayor toma de tiempo y muchos ms problemas que se tena al

informacin que se refiere a la clasificacin de la misma de una forma ordenada, ms

segura dando confianza a la hora de realizar alguna manipulacin de datos.

El departamento de Talento Humano del Instituto Tecnolgico Superior

Sudamericano realiza varios procesos con respecto a la gestin de tareas de los

docentes, esa informacin la maneja y lleva de forma manual haciendo el trabajo un

dichos procesos en su trabajo diario. Aportando confianza a la hora de manipular toda

esta informacin la misma que influye mucho al crecimiento de la institucin, tambin

al mejoramiento de todos los docentes y estudiantes a nivel acadmico. La aplicacin

permitir facilitar la creacin de los reportes automticamente segn el encargado

hacindolo menos cansado, ms seguro y con ms eficiencia y eficacia.

Ilustracin 1(fases del modo lineal secuencial)...............................................................18

Tabla 1 (funciones del sistema).......................................................................................62

Actualmente en el Instituto Tecnolgico Sudamericano como Institucin Educativa

Programacin en Internet I e Ingeniera de Software es mediante la elaboracin y

presentacin de proyectos integradores.

Los proyectos proyecto integradores se diferencian por diferentes categoras:

multidisciplinario (un proyecto por varios ciclos de un misma carrera),

intermultidisiplinario (un proyecto en contiene varias carreras).

a un conjunto de normas aceptadas y consensuadas. El Instituto Tecnolgico

para lo cual se ha realizado el desarrollo e implementacin de una aplicacin web para

el departamento de talento humano del instituto tecnolgico superior sudamericano de

la ciudad de Loja, con la finalidad de dar solucin a un proceso manual automatizndolo

para realizar uno o varios procesos.

actualizaciones, lo cual facilitara su implementacin en cualquier entorno de trabajo o

hacer nuestra vida ms fcil y menos complicada a la hora de realizar un trabajo,

dndonos la oportunidad de hacer nuestro trabajo de una forma rpida, eficaz y

actividades adicionales que deseemos realizar.

En el Instituto Tecnolgico Superior Sudamericano (ITSS) la mayora de trabajos en las

nuevas necesidades, y algunos casos donde se necesita facilitar trabajos y reducir el

tiempo que se tarda en realizarlos. El departamento de talento humano es uno de ellos

informacin este totalmente guardada y segura en caso de necesitarla.

El desarrollo e implementacin de La aplicacin web para el departamento de talento

realizados por el mismo, hacindolo ms sencillo, practico y seguro que le permita al

encargado del departamento facilitar su trabajo y tener toda la informacin

respectivos reportes segn la necesidad que requiera.

realizan en este departamento ayudndole a sacar porcentajes e informes de cada

docente facilitndole automticamente el desarrollo de los reportes diariamente,

de cada carrera donde ellos tendrn habilitado un formato donde evaluaran el

rendimiento mensual de los docentes que conforman su carrera en el trabajo de equipo.

a sacar sus respectivos porcentajes para su reporte.

ms rpida y en cualquier momento que los requieran.

Esta aplicacin dar un gran aporte al Instituto Sudamericano, especialmente al

departamento de talento humano realizando un trabajo fiable, con excelente

Aportando al crecimiento institucional y acercndonos un poco ms a la visin

El presente proyecto es importante en el mbito acadmico ya que es un requisito

En el mbito tecnolgico el presente proyecto beneficiara a la provincia de Loja

El desarrollo del presente proyecto ayudar a demostrar los conocimientos

10.1. OBJETIVO GENEAL

Dar a conocer y proporcionar una herramienta de gestin para el

control de docentes en el departamento de Talento Humano del

Instituto Tecnolgico Superior Sudamericano, en primer lugar

desarrollando la fase de Anlisis y diseo. Y posteriormente

implementarlo, a modo de hacer de esta funcin rutinaria ms

sencilla, la cual permita realizar de las actividades diarias de la

empresa de forma ms gil, eficiente y segura.