I
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMTICAS Y FSICAS
CARRERA DE INGENIERA EN SISTEMAS
COMPUTACIONALES
METODOLOGA DE PRUEBAS DEL MDULO DE TRMITES PARA LA IMPLEMENTACIN DEL PROTOTIPO DEL
SISTEMA ACADMICO DE LA UNIVERSIDAD DE GUAYAQUIL
TESIS DE GRADO
Previa a la obtencin del Ttulo de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR: JESSICA ALEXANDRA SNCHEZ
SOLRZANO
TUTOR: ING. SOL LOPEZDOMINGUEZ R. MAE.
GUAYAQUIL ECUADOR
2015
II
REGISTRO DE TESIS
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGA
FICHA DE REGISTRO DE TESIS
TITULO: METODOLOGA DE PRUEBAS DEL MDULO DE TRMITES PARA LA IMPLEMENTACIN DEL PROTOTIPO DEL SISTEMA ACADMICO DE LA UNIVERSIDAD DE GUAYAQUIL
AUTOR: JESSICA ALEXANDRA SNCHEZ SOLRZANO
REVISORES
INSTITUCIN: UNIVERSIDAD DE GUAYAQUIL
FACULTAD: CIENCIAS MATEMTICAS Y FSICAS
CARRERA: INGENIERA EN SISTEMAS COMPUTACIONALES
FECHA DE PUBLICACIN: AGOSTO 2015
N.- DE PGINAS: 99
REA TEMTICA : EDUCATIVA
PALABRAS CLAVES
RESUMEN La Universidad de Guayaquil ha ido evolucionando continuamente automatizando cada
uno de su proceso acadmicos para mejorar sus servicios y brindar una atencin de calidad al
estudiante. Es por esta razn que se busca automatizar el proceso de solicitudes y certificados ya que
actualmente este proceso se lo realiza manualmente ocasionando un inconveniente tanto al alumnado
como al personal administrativo al momento de tener que procesar una gran cantidad de solicitudes y
certificados, es por esto que es muy importante tener un dato exacto de cuantas solicitudes se han
atendido con un reporte en Excel., as como tambin plan de pruebas para evaluar cada una de las
opciones que brinde este mdulo de trmites. Esto a su vez realizara pruebas de cada uno de los sub
mdulos, permitiendo dejar un software libre de errores que al final cuenten con la plena satisfaccin
del usuario.
N.- DE REGISTRO N.- DE CLASIFICACIN:
DIRECCIN URL
ADJUNTO PDF SI X NO
CONTACTO CON AUTOR: Jessica Alexandra Snchez Solrzano
Telfono: 2574433
E-mail: [email protected]
CONTACTO DE LA INSTITUCIN: Universidad de Guayaquil
Nombre: Ab. Juan Chvez Atocha
Telfono: 2307729
II
APROBACIN DEL TUTOR
En mi calidad de Tutor del trabajo de investigacin, METODOLOGA DE
PRUEBAS DEL MDULO DE TRMITES PARA LA IMPLEMENTACIN
DEL PROTOTIPO DEL SISTEMA ACADMICO DE LA UNIVERSIDAD
DE GUAYAQUIL elaborado por la Srta.
Jessica Alexandra Snchez Solrzano, egresado de la Carrera de
Ingeniera en Sistemas Computacionales, Facultad de Ciencias
Matemticas y Fsicas de la Universidad de Guayaquil, previo a la
obtencin del Ttulo de Ingeniero en Sistemas, me permito declarar que
luego de haber orientado, estudiado y revisado, la Apruebo en todas sus
partes.
Atentamente
Ing. Sol Lopezdominguez
TUTOR
Atentamente
Ing.
TUTOR
III
DEDICATORIA
Dedico esta tesis a mi mama la Sra. Luca Solrzano Loor quien ha sido el pilar fundamental para culminar esta etapa de mi vida, a mi papa al Sr. Guido Snchez Lara quien se convirti en mi ngel para toda mi vida.
IV
AGRADECIMIENTO
Principalmente a Dios por darme vida y salud para culminar una etapa ms de mi vida, a mi mama por creer en m y por su apoyo de todos estos aos, a mis hermanas por su apoyo incondicional, a cada uno de mis familiares, amigos compaeros y maestros que fueron participes de este logro.
V
TRIBUNAL DE GRADO
Ing. Eduardo Santos Baquerizo, M.Sc.
DECANO DE LA FACULTAD
CIENCIAS MATEMTICAS Y
FSICAS
Ing. Inelda Martillo Alcvar, Mgs
DIRECTORA
CISC, CIN
Ing. Sol Lopezdominguez
DIRECTOR DE TESIS
Nombre y Apellidos
PROFESOR DEL REA -
TRIBUNAL
Ab. Juan Chvez A.
SECRETARIO
VI
DECLARACIN EXPRESA
La responsabilidad del contenido de esta Tesis de Grado, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL
JESSICA ALEXANDRA SNCHEZ SOLRZANO
VII
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMTICAS Y FSICAS
CARRERA DE INGENIERA EN SISTEMAS
COMPUTACIONALES
METODOLOGA DE PRUEBAS DEL MDULO DE TRMITES
PARA LA IMPLEMENTACIN DEL PROTOTIPO
DEL SISTEMA ACADMICO DE LA
UNIVERSIDAD DE GUAYAQUIL
Tesis de Grado que se presenta como requisito para optar por el ttulo de
INGENIERO EN SISTEMAS COMPUTACIONALES
Auto/a: Jessica Snchez Solrzano
C.I.2000059945
Tutor: Ing. Lopezdominguez R. MAE.
Guayaquil, Julio del 2015
VIII
CERTIFICADO DE ACEPTACIN DEL TUTOR
En mi calidad de Tutor de Tesis de Grado, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemticas y Fsicas de la Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Grado presentado por la estudiante Jessica Alexandra Snchez Solrzano, como requisito previo para optar por el ttulo de Ingeniero en Sistemas Computacionales cuyo problema es: El tiempo de respuesta para la entrega de solicitudes no automatizadas del proceso de trmites en la Carrera de Ingeniera en Sistemas Computacionales de la Universidad de Guayaquil, pruebas del mdulo de trmites.
Considero aprobado el trabajo en su totalidad.
Presentado por:
Snchez Solrzano Jessica Alexandra Cdula de ciudadana N 2000059945
Tutor: Ing. Sol Lopezdominguez R. MAE
Guayaquil, Julio del 2015
IX
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMTICAS Y FSICAS
CARRERA DE INGENIERA EN SISTEMAS COMPUTACIONALES
Autorizacin para Publicacin de Tesis en Formato Digital 1. Identificacin de la Tesis
Nombre Alumno: Jessica Snchez Solrzano
Direccin: Sauces 9 Mz. 533 V12
Telfono: 2574433 E-mail: [email protected]
Facultad: Matemticas y Fsica
Carrera: Ingeniera en Sistemas Computacionales
Ttulo al que opta: Ingeniera en Sistemas Computaciones
Profesor gua: Ing. Sol Lopezdominguez R. MAE.
Temas Tesis: Metodologa de pruebas del mdulo de trmites para la implementacin del prototipo del sistema acadmico de la Universidad de Guayaquil.
2. Autorizacin de Publicacin de Versin Electrnica de la Tesis A travs de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemticas y Fsicas a publicar la versin electrnica de esta tesis. Publicacin electrnica:
Inmediata Despus de 1 ao X
Firma Alumno:
3. Forma de envo:
El texto de la Tesis debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imgenes que la acompaen pueden ser: .gif, .jpg o .TIFF.
DVD ROM CD-ROM
X
NDICE GENERAL
Aprobacin de tutor II
Dedicatoria III
Agradecimiento IV
Tribunal de grado V
Declaracin expresa VI
Certificado de aceptacin del tutor VIII
ndice general X
Abreviaturas XIV
ndice de cuadros XV
ndice de grficos XVII
Resumen XX
Abstract XXI
Introduccin 1
CAPITULO I EL PROBLEMA 2
Planteamiento del Problema 2
Ubicacin del Problema en un Contexto 2
Situacin Conflicto Nudos Crticos 3
Causas y Consecuencias del Problema 4
Delimitacin del Problema 5
Formulacin del Problema 5
Evaluacin del Problema 5
Objetivos 7
Objetivo General 7
Objetivos Especficos 7
Alcance del Problema 7
Justificacin e Importancia 8
CAPITULO II MARCO TERICO 10
Antecedentes del Estudio 10
Fundamentacin Terica 11
Calidad del Software 11
Principio de Calidad 12
Proceso de Trmites 12
XI
Usuarios Involucrados en el Proceso de Trmites 13
FODA 14
Objetivo de un Anlisis de FODA 14
Anlisis Interno de la Organizacin de FODA 14
Anlisis Externo de la Organizacin de FODA 14
Diagrama de Ishikawa o Diagrama Causa-Efecto 15
Importancia del Diagrama de Ishikawa 15
Pasos a seguir de Ishikawa 16
Software 17
Errores de Software 17
Pruebas de Software 18
Requisitos antes de realizar Pruebas 18
Plan de Pruebas 19
Aplicacin de las Pruebas de Software 19
Consecuencias al no aplicar un Plan de Pruebas 20
Beneficios de las Pruebas 20
Estratgia de Pruebas 20
Casos de Pruebas 21
Pruebas al Sistema 21
Pruebas Unitarias 21
Pruebas de Caja Negra 22
Pruebas de Regresin 22
Pruebas de Interface 22
Pruebas de Recuperacin 22
Formatos de Casos de Prueba 23
Metodologas giles 26
Las Principales Metodologas giles 26
Mapa de procesos actual de Solicitudes 27
Proceso de Inclusin de Materia 27
Proceso de Anulacin de Materia 28
Proceso de Cambio de Paralelo 30
Proceso de Matrcula por Tercera Vez 31
Proceso de Homologacin 33
Proceso de Matrcula Especial 34
XII
Proceso de Homologacin 35
Proceso de Recalificacin 37
Fundamentacin Legal 41
Reglamento de Rgimen Acadmico de Educacin Superior 41
Ley de la Propiedad Intelectual 43
Normas iso y Estndares ieee Asociadas al Software 45
Hiptesis preguntas a contestarse 47
Variables de la Investigacin 47
Variable Independiente 47
Variable Dependiente 48
Definiciones Conceptuales 48
CAPITULO III METODOLOGA 49
Antecedentes del Estudio 49
Anlisis de las Encuestas 50
Proceso de Pruebas de Software 54
Gestin de Tareas de Pruebas 54
Anlisis Situacin con FODA 55
Diagrama de Causa Efecto 57
Gestin de Calidad 62
Diagrama de Procesos de Solicitudes del Mdulo de Trmites 63
Inclusin de Materia 63
Cambio de Paralelo 64
Anulacin de Inscripcin 65
Dejar sin Efecto Materia 66
Cambio de Jornada 67
Cambio de Modalidad 68
Cambio de Vez 69
Proceso general mejorado del Mdulo de Tramites 70
Metodologa de Pruebas 71
Planeacin de Pruebas 71
Plan de Pruebas 71
Metodologa en V 73
Requisitos de Ambiente de Pruebas 73
Requisitos de Software 74
XIII
Requisitos de Hardware 74
Tipos de Pruebas a realizarse en el Mdulo de Trmites 74
Pruebas Funcionales 74
Pruebas de Interfaz y Contenido 75
Elementos a ser Probados 76
Elementos que no sern sujetos a prueba 76
Criterios de suspensin de prueba y condiciones de reanudarla 76
Diseo de Casos de Pruebas 77
Ejecucin de Pruebas 77
Equipo de trabajo requerido 77
Resultado de Ejecucin de Pruebas 78
Identificacin de Perfiles del Mdulo de Trmites 78
Estratgia de Pruebas 86
Resultados de Estratgia de Pruebas Aplicada 90
CAPITULO IV MARCO ADMINISTRATIVO 94
Cronograma 94
Presupuesto 95
CAPITULO V - CONCLUSIONES Y RECOMENDACIONES 96
Conclusiones 96
Recomendaciones 98
Bibliografa 99
XIV
ABREVIATURAS UG Universidad de Guayaquil CISC Carrera de Ingeniera en Sistemas Computacionales CINT Carrera de Ingeniera en Networking y Telecomunicaciones FTP Archivos de Transferencia Ing. Ingeniero C.M.F Facultad de Ciencias Matemticas y Fsicas MAE. Master en Administracin de Empresas MER. Modelo de Entidad y Relacin CMMI Integracin de modelos de madurez de capacidades CP Caso de Prueba
XV
NDICE DE CUADROS Pg.
CUADRO N. 1: CAUSAS Y CONSECUENCIAS ........................................................................... 4 CUADRO N. 2: CASO DE PRUEBAS FUNCIONALES .............................................................. 23 CUADRO N. 3: FORMATOS DE PRUEBAS DE INTERFAZ ...................................................... 24 CUADRO N. 4: FORMATOS DE REGISTRO DE RESULTADOS .............................................. 25 CUADRO N. 5: FORMATOS DE REGISTROS GENERALES .................................................... 25 CUADRO N. 6: DESCRIPCION DE ACTIVIDADES DE PRUEBAS EN EL MDULO DE TRMITES ........................................................................................................ 54 CUADRO N. 7: FODA ................................................................................................................ 55 CUADRO N. 8: PERFILES DE USUARIOS ................................................................................ 87 CUADRO 9: ACTIVIDADES REALIZADAS EN EL CICLO 1 .................................................. 87 CUADRO N. 10: ACTIVIDADES REALIZADAS EN EL CICLO 2 .................................................. 88 CUADRO N. 11: ACTIVIDADES REALIZADAS EN EL CICLO 3 .................................................. 89 CUADRO N. 12: ACTIVIDADES REALIZADAS EN EL CICLO 4 .................................................. 90 CUADRO N. 13: PLANTILLA DE RESULTADOS ....................................................................... 950 CUADRO N. 14: PRUEBAS FUNCIONALES ............................................................................. 950 CUADRO N. 15: PRUEBAS DE INTERFAZ ............................................................................... 951
XVI
CUADRO N. 16: INFORME MODULAR ..................................................................................... 953 CUADRO N. 17: CRONOGRAMA DE ACTIVIDADES .................................................................. 95 CUADRO N. 18: INGRESOS ........................................................................................................ 96 CUADRO N. 19: INGRESOS ........................................................................................................ 96
XVII
NDICE DE GRFICOS GRFICO N. 1: PROCESO DE TRMITES ................................................................................ 12 GRFICO N. 2: DIAGRAMA DE CAUSA Y EFECTO .................................................................. 17 GRFICO N. 3: MAPA DE PROCESO DE INCLUSION DE MATERIA ....................................... 28 GRFICO N. 4: MAPA DE PROCESO ANULACION DE MATERIA ............................................ 29 GRFICO N. 5: MAPA DE PROCESO CAMBIO DE PARALELO ............................................... 31 GRFICO N. 6: MAPA DE PROCESO MATRICULA POR TERCERA VEZ ................................ 32 GRFICO N. 7: MAPA DE PROCESO DE HOMOLOGACIN ................................................... 34 GRFICO N. 8: MAPA DE PROCESO DE MATRICULA ESPECIAL .......................................... 35 GRFICO N. 9: MAPA DE PROCESO DE CAMBIO DE CARRERA ........................................... 36 GRFICO N. 10: MAPA DE PROCESO DE RECALIFICACION ................................................... 41 GRFICO N. 11: PREGUNTA N.1 CANTIDAD DE SOLICITUDES SEGN ETAPA ..................... 50 GRFICO N. 12: PREGUNTA N.2 TIEMPO DE RESPUESTA DE SOLICITUDES ....................... 50 GRFICO N. 13: PREGUNTA N.3 HORAS EXTRAS PARA SOLICITUDES ................................ 51 GRFICO N. 14: PREGUNTA N.4 CANTIDAD DE SOLICITUDES QUE SE PROCESAN ...................................................................................................... 52 GRFICO N. 15 PREGUNTA N.5 APLICAR PROPUESTA ......................................................... 53
XVIII
GRFICO N. 16: DIAGRAMA CAUSA EFECTO ........................................................................... 61 GRFICO N. 17: PROCESO INCLUIR MATERIA ......................................................................... 63 GRFICO N. 18: PROCESO CAMBIO DE PARALELO ................................................................ 64 GRFICO N. 19: PROCESO ANULACION DE INSCRIPCIN ..................................................... 65 GRFICO N. 20: PROCESO DEJAR SIN EFECTO ...................................................................... 66 GRFICO N. 21: PROCESO CAMBIO DE JORNADA .................................................................. 67 GRFICO N. 22: PROCESO CAMBIO DE MODALIDAD .............................................................. 68 GRFICO N. 23: PROCESO CAMBIO DE VEZ ............................................................................ 69 GRFICO N. 24: PROCESO MEJORADO GENERAL DEL MDULO DE TRMITES ................. 70 GRFICO N. 25: PERFILES DE USUARIOS DEL MDULO DE TRMITES ............................... 79 GRFICO N. 26: PANTALLA DE BANDEJA DE TRABAJO .......................................................... 80 GRFICO N. 27: PANTALLA DETALLE TRMITE ....................................................................... 81 GRFICO N. 28: PANTALLA BANDEJA DE TRABAJO SOLICITUDES ....................................... 81 GRFICO N. 29: PANTALLA DETALLE TRMITE ....................................................................... 82 GRFICO N. 30: PANTALLA GENERAR TRMITE ..................................................................... 82 GRFICO N. 31: PANTALLA DETALLE TRMITE - TIPO CERTIFICADO ................................... 83 GRFICO N. 32: PANTALLA DETALLE TRMITE INGRESADO ................................................. 83
XIX
GRFICO N. 33: PANTALLA DETALLE TIPO SOLICITUD .......................................................... 84 GRFICO N. 34: PANTALLA SOLICITUD CAMBIO DE PARALELO ............................................ 84 GRFICO N. 35: PANTALLA GENERAR TRMITE ..................................................................... 85 GRFICO N. 36: PANTALLA DETALLE TRMITE INGRESADO ................................................. 85 GRFICO N. 37: ESTRATGIA DE PRUEBAS ............................................................................ 86
XX
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMTICAS Y FSICAS
CARRERA DE INGENIERA EN SISTEMAS COMPUTACIONALES
METODOLOGA DE PRUEBAS DEL MDULO DE TRMITES PARA LA IMPLEMENTACIN DEL PROTOTIPO DEL SISTEMA ACADMICO DE
LA UNIVERSIDAD DE GUAYAQUIL.
RESUMEN La carrera de Ingeniera en Sistemas Computacionales y Networking de la
facultad de Ciencias Matemticas y Fsicas de la Universidad de Guayaquil ha
evolucionado continuamente automatizando cada uno de su proceso
acadmicos para mejorar sus servicios y brindar una atencin de calidad al
estudiante. Es por esta razn se busca automatizar el proceso de solicitudes y
certificados ya que actualmente este proceso se lo realiza manualmente
ocasionando inconvenientes al personal estudiantil y administrativo al momento
de tener que procesar una gran cantidad de solicitudes y certificados, es por esto
que es importante tener una informacin exacta y fidedigna de cuantas
solicitudes se han atendido con un documento informtico. Se realiza una
Estratgia de pruebas aplicando una metodologa de pruebas que valide el
proceso que se realiza para la obtencin de solicitudes, as como tambin plan
de pruebas para evaluar cada una de las opciones que brinde este mdulo de
trmites, la Estratgia nos permite demostrar una mejora en el tiempo realizar las
pruebas para mostrar un software libre de errores que al final cuenten con la
plena satisfaccin del usuario.
Autor: Jessica Snchez Solrzano Tutor: Ing. Sol Lopezdominguez R. MAE.
XXI
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMTICAS Y FSICAS
CARRERA DE INGENIERA EN SISTEMAS COMPUTACIONALES
METODOLOGA DE PRUEBAS DEL MDULO DE TRMITES PARA LA IMPLEMENTACIN DEL PROTOTIPO DEL SISTEMA ACADMICO DE
LA UNIVERSIDAD DE GUAYAQUIL.
ABSTRACT
The Engineering in Computer Systems and Networking Faculty of Mathematics
and Physical Sciences at the University of Guayaquil has been evolving
continuously automating each of its academic processes to improve the services
and provide quality to the student process. This is the reason that seeks to
automate the process of applications and licenses as currently this process is
done manually causing an inconvenience to both students and administrative
staff due to having to process a large number of applications and licenses,
automating these processes significantly improves response time and have an
exact figure of how many applications have been approved and how many have
been denied. That is why a test strategy implemented methodology to improve
the process performed to obtain applications, as well as test plan to evaluate
each of the options that provide this module paperwork is done, the strategy will
demonstrate us improvement of response time you get to the process of
applications and licenses, it should be emphasized that applications are what the
student makes for an internal process and certificates are to acquire documents
for later use inside or outside the University.
1
INTRODUCCIN
En la actualidad uno de los problemas con que cuenta la poblacin es no contar
con un software de calidad, comprendiendo a la definicin de calidad como a la
satisfaccin que tendr el usuario final despus de su interaccin, en muchas
empresas existen inconvenientes de rendimiento y es por esto que se busca la
necesidad de ofrecer un producto que sea realmente fiable para brindar un buen
servicio al usuario que son las personas a las cuales va dirigido el producto.
Es por este inconveniente que me he visto en la necesidad de aplicar un proceso
de calidad utilizando una Estratgia de pruebas al mdulo de trmites del
sistema acadmico de la Universidad de Guayaquil, ya que al utilizar un sistema
educativo se involucra a una gran parte de la poblacin y es importante su
satisfaccin al momento de interactuar con el software predispuesto. Al contar
con un software que ha pasado por un proceso de pruebas aplicando
metodologas idneas es poco probable que existan inconvenientes al atender
un proceso.
De la misma manera ayudar al estudiante a interactuar con un software que no
implique procesos errneos dentro del sistema acadmico y por tanto tengan
que ser atendidos de manera manual interviniendo en el tiempo de respuesta, a
medida que surgen inconvenientes en un software la credibilidad de las
empresas bajan ya que estos inconvenientes causan perdidas econmicas que
desnivela su presupuesto, demostrando en este proyecto el bajo egreso
econmico que se involucra.
El desarrollo de este proyecto se elabora mediante una metodologa de pruebas
aplicando una Estratgia basados en los casos de uso y generados desde los
casos de pruebas para minimizar los errores que tenga el mdulo de trmites del
prototipo del sistema acadmico.
2
CAPTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicacin del Problema en un Contexto
Una de las funciones del sistema de educacin superior de acuerdo a la Ley
Orgnica de Educacin Superior en el Art. 13 busca promover la creacin,
desarrollo, transmisin y difusin de la ciencia, la tecnologa, y es por esto que
buscamos la manera de buscamos estar al nivel tecnolgico actualizado.
Actualmente en la Universidad de Guayaquil se realizan varios procesos
educativos, uno de ellos y no menos importante que otros es el proceso que se
realiza para la adquisicin de solitudes y certificados, cabe recalcar que la
cantidad de trmites que se maneja dentro de la universidad es bastante
numerosa esto involucra el flujo que cada una de las solicitudes y certificados
debe seguir para atender el requerimiento y su posterior entrega.
Al momento de atender las solicitudes existen personas que se encuentran
involucradas para la realizacin de este proceso causando un tiempo de
respuesta de cada solicitud extenso por la cantidad que se deben procesar o en
ocasiones el perfil de la persona no es el correcto e impiden atender de manera
idnea, siendo este un proceso manual.
Al momento de decidir hacer este proceso de la generacin de trmites de
manera automtica mediante la integracin de un mdulo de trmites al sistema
acadmico de la Universidad de Guayaquil, al desarrollar este mdulo y
3
ausentarse una metodologa de previos con su Estratgia de pruebas no se
lograr validar el software desarrollado de manera correcta.
Al no contar con las validaciones correspondientes se acarrean problemas
legales e inconvenientes internos en el proceso estudiantil, ya que algunas de
las solicitudes deben ser validadas previo a un proceso de matriculacin, de no
ser atenderlas pierden cupos para su respectiva inscripcin y as el derecho al
estudio por no contar con cupos disponibles para el curso deseado.
Es por esto que caemos en el mal criterio de la mala atencin pblica que
brindan las instituciones del Ecuador.
Situacin Conflicto Nudos Crticos
La problemtica surge que a medida de que la cantidad de solicitudes por
atender previo al inicio de una matriculacin o al finalizar un semestre en el
departamento encargado de la Universidad de Guayaquil aumenta, se crea
discrepancia y malestar debido a que la cantidad de solicitudes influye mucho en
el tiempo de respuesta para procesarlas como tambin las validaciones que este
tenga, de la misma manera puede correr el riego que el documento en fsico se
extrave por la gran cantidad que existen, con esto el tiempo de entrega cuando
el alumno se acerca por su solicitud aumenta ya que la bsqueda que realizan
para la entrega es extensa.
El flujo para cada solicitud que la Universidad de Guayaquil realiza es diferente
ya que las validaciones se dirigen a varios departamentos de la carrera, esto
tambin surge que hay carreras que fsicamente no se encuentran dentro de su
facultad y algunas de las solicitudes se las debe dirigir al decano de cada
facultad lo que toma tiempo en ser atendidas.
Todos los desarrolladores buscan la finalidad de no cometer errores y lograr su
objetivo pero al aplicar los casos de pruebas se puede identificar que si los
cometen y al evaluarlos a tiempo se evitara costos de tiempo al momento de
entregar el producto final del mdulo de trmites de la Universidad de Guayaquil.
4
Debido a que es un nuevo mdulo a implementarse al sistema acadmico de la
Universidad de Guayaquil, implica que ste podra estar propenso a contener
errores y a su vez impida que se realicen los trmites de manera correcta en el
tiempo adecuado, afectando la calidad de servicio que proporcione a los
estudiantes que necesiten realizar estos procesos.
Causas y Consecuencias del Problema
Al analizar las causas y consecuencias he concluido en los que detallo a
continuacin en el cuadro N 1.
CUADRO N. 1:
CAUSAS Y CONSECUENCIAS DEL PROBLEMA
CAUSAS CONSECUENCIAS
Inexistencia de metodologas y
Estratgia de pruebas que certifique
mejorar la calidad del mdulo de
trmite.
El mdulo de trmites puede
contener grandes cantidades
errores que no permitan presentar
el mdulo en produccin.
Una mala elaboracin del plan de
pruebas.
Las pruebas no cumplirn con el fin
por el cual fueron seleccionadas.
Elegir una Estratgia de pruebas no
adecuada para el mdulo de
trmites.
No obtener los resultados
esperados en la ejecucin de
pruebas.
Casos de Uso no cumplen con las
especificaciones adecuadas para el
desarrollo de los casos de pruebas.
Casos de pruebas mal elaborados.
La mala ejecucin de pruebas. Mdulo de trmites con errores.
Casos de uso no disponibles Retraso en la elaboracin de casos
de pruebas.
Elaborado por: Jessica Snchez Solrzano Fuente: Jessica Snchez Solrzano
5
Delimitacin del Problema
Campo: Universidad de Guayaquil, Facultad de Matemticas y Fsicas, Carrera
de Ingeniera en Sistemas y Networking, Educacin Superior
rea: Pruebas del desarrollo de software del buen funcionamiento del nuevo
mdulo de trmites correspondiente al sistema acadmico de la Universidad de
Guayaquil.
Aspecto: Estratgias de Calidad
Tema: Metodologa de pruebas del mdulo de trmites para la implementacin
del prototipo del sistema acadmico de la Universidad de Guayaquil.
El problema surge en la adquisicin de solicitudes en ventanilla para la
aprobacin de requerimientos de los alumnos, existiendo una gran cantidad de
solicitudes al iniciar un proceso de matriculacin como tambin al finalizar un
periodo estudiantil, por ende el tiempo de respuesta es a donde queremos llegar
para definir una Estratgia de pruebas.
Formulacin del Problema
La correcta elaboracin de una Estratgia de pruebas, garantizar que se
validen todos los requerimientos planteados para el mdulo de trmites en el
sistema acadmico de la Universidad de Guayaquil?
Evaluacin del Problema
Los aspectos generales de evaluacin son:
Delimitado: En el aspecto delimitado se considera que la aplicacin de una
Estratgia de pruebas del mdulo de trmites, para la Universidad de Guayaquil.
Original: Actualmente no existe una Estratgia de pruebas para evaluar el
proceso de solicitudes en la carrera de Ingeniera en Sistemas Computacionales
y Networking que permita validar el desarrollo del mdulo, as como tambin no
existe metodologa gil aplicada a los procesos.
6
Claro: La Estratgia pruebas permite evaluar el proceso interno que se realiza
para la obtencin de solicitudes para mejorar el tiempo de respuesta de cada
solicitud o certificado que solicita en alumno en cualquier momento que se
encuentre el proceso acadmico ya sea inicio o finalizacin de semestre.
Evidente: Es notorio el malestar e inconformidad del personal estudiantil y
personal administrativo de la carrera de Ingeniera en Sistemas y Networking de
la facultad de Matemticas y Fsicas pertenecientes a la Universidad de
Guayaquil al momento de contar con una gran cantidad de solicitudes por
atender, que se da al inicio de un proceso de matriculacin como tambin al
finalizar un periodo acadmico ya sea un semestre o ao lectivo.
Factible: Al aplicar la Estratgia de pruebas permite evaluar y corregir los
procesos que se evalen para su posterior aplicacin ya que dentro de la carrera
respecto al estado fsico se encuentran en su mayora en un mismo lugar que es
factible evaluar cada proceso que se realiza por solicitud, as como tambin la
solucin a las interferencias para la atencin de una solicitud o certificado.
Identifica los productos esperados: La Estratgia de pruebas permite analizar
el proceso para la mejora de respuesta, as como tambin corroborar el perfil de
cada persona involucrada dentro del proceso, permitiendo ofrecer un mdulo de
calidad que permita una idnea comunicacin con el personal administrativo
como tambin con el personal acadmico que son los alumnos los perfiles
importantes en este proceso de adquirir un trmite en la carrera de Ingeniera en
Sistemas Computacionales y Networking.
Concreto: La Estratgia evaluar el funcionamiento del mdulo de trmites para
certificar que con la automatizacin de este proceso se mejora el tiempo de
respuesta que el alumno espera en el proceso de solicitudes o certificados que
en la carrera para continuar con su proceso acadmico ya sea este de
matriculacin o cualquier otro que el alumno desee hacer despus de obtener su
certificado o solicitud.
7
OBJETIVOS
Objetivo general
Disear Estratgia de pruebas del mdulo de trmites para establecer el
funcionamiento del sistema en pre produccin mediante la ejecucin de los
casos de prueba.
Objetivos especficos
Elaborar el plan de pruebas para el mdulo de trmites de la carrera de
Ingeniera en Sistemas Computaciones de la Universidad de Guayaquil.
Verificar los perfiles de usuarios que se involucren dentro del proceso de
solicitudes para demostrar el anlisis de sus roles en el mdulo de trmites.
Realizar el informe de pruebas mediante la ejecucin de los casos de pruebas
para determinar el avance del mdulo.
ALCANCE DEL PROBLEMA
Tomando en consideracin que la cantidad de alumnos aumenta en la
Universidad de Guayaquil y por ende la cantidad de trmites, tendremos como
resultado el desarrollo de un mdulo de trmites que permita atender los
requerimientos de los alumnos como sern los certificados y solicitudes dentro
de la Universidad de Guayaquil, as como tambin evaluar los procesos que
implican para la obtencin de un trmite en la carrera de Ingeniera en Sistemas
Computacionales & Networking.
La generacin de un plan de pruebas implica el anlisis de los procesos para su
posterior elaboracin de pruebas al mdulo de trmites en el cual se aplican dos
niveles: pruebas funcionales y pruebas de interfaz permitindome presentar un
software de calidad.
Definicin de la Estratgia de pruebas que permita realizar una correcta
validacin del mdulo de trmites para el sistema acadmico de la Universidad
de Guayaquil.
8
Verificar el perfil de cada usuario con las pantallas desarrolladas en la cual
podrn cumplir su rol, as como tambin constatar que los roles de cada perfil
que est involucrado dentro de los proceso de trmites, de esta manera se
efectivizara que estn acorde al requerimiento institucional y poder canalizar con
mayor rapidez el proceso de solicitudes.
JUSTIFICACIN E IMPORTANCIA
Este mdulo de trmites del prototipo de sistema acadmico para la
Universidad de Guayaquil es desarrollado con la finalidad de ayudar al personal
administrativo y estudiantil, certificando que se entrega un proyecto dinmico,
amigable y veraz para la interaccin con el usuario final, el enfoque se lo realiza
en pasar al proceso por una Estratgia de pruebas.
El motivo por el cual se busc la manera de aplicar una Estratgia de pruebas
al mdulo de trmites de la Universidad de Guayaquil es por el tiempo de
respuesta que actualmente cuenta una solicitud procesada para ser utilizada
previo o al final de un periodo lectivo en la carrera que se encuentren inscritos.
As como tambin el tras papeleo de documentos que en ocasiones surge en
los departamentos encargados por la cantidad de solicitudes atendidas o por
atender en el proceso de matriculacin que es donde ms ingresan.
La importancia de este mdulo permite interactuar a docentes, alumnos y
personal administrativo de la Universidad de Guayaquil, en el cual se atendern
todos los requerimientos que cada uno de estos actores deseen utilizar y as
tener relacin cada una de sus funciones que realicen deseen desempear
durante su tiempo acadmico en la institucin.
La aplicacin de una Estratgia de pruebas permite mejorar los procesos
acadmicos con eficiencia segn cambio estipulados en la Ley de Educacin
Superior, de esta manera mejorara el tiempo de respuesta de cada solicitud.
Permitir un mejor desempeo del personal administrativos dentro de sus
9
actividades laborales con el tiempo disponible y segn sea su perfil con el rol
designado accediendo a desarrollar otras actividades que se encuentren dentro
de su perfil del cual fueron asignados en su lugar de trabajo.
Es importante el convertir un proceso manual en un proceso automatizado de
calidad mediante el cual permita agilitar procesos internos de Universidad de
Guayaquil.
10
CAPTULO II
MARCO TERICO
Antecedentes del estudio
(Universidad de Guayaquil, 2015) seala que:
En la Universidad de Guayaquil se analizaron los inconvenientes y falencias que tena el personal estudiantil as como el personal administrativo con el sistema que se cuenta para la realizacin de procesos acadmicos, estos anlisis nos demostr que no ha sido bien estructurado y no ha abarcado todos los procesos que los alumnos lo solicitan a diario ocasionando inconvenientes para ser atendidos, se defini que metodologa usar para comprobar la efectividad y calidad de un sistema con una nueva arquitectura que nos permita atender de manera idnea a los implicados en este sistema.
En 1867, el Congreso Nacional, presidido por Pedro Carbo decreta la fundacin de la Junta Universitaria del Guayas, que se instala el primero de Diciembre y que tiene el privilegio de otorgar grados y ttulos, por lo que se considera sta la fecha de la fundacin de la Universidad de Guayaquil. La primera Facultad en instalarse fue la de Jurisprudencia en 1868. La Universidad de Guayaquil fue creada como tal por Pedro Carbo, Jefe Supremo del Guayas en 1883, pero este decreto no fue ratificado por la Asamblea Constituyente de 1884; sin embargo, el pueblo ya no dej de llamar Universidad de Guayaquil a la modesta Junta Universitaria del Guayas. Con el triunfo de la Revolucin Liberal se dict en 1897 la Ley que cre la Universidad de Guayaquil, y fue una de las primeras en acoger la Reforma Universitaria de Crdova de 1918 que se levant bajo la consigna de "Una sociedad mejor para una educacin mejor". (Universidad de Guayaquil, 2015)
11
Fundamentacin terica
El anlisis que se realiza en los procesos de la carrera de Ingeniera en Sistemas
Computacionales de la Facultad de Ciencias Matemticas y Fsicas de la
Universidad de Guayaquil sobre el levantamiento de informacin en la parte de
solicitudes y Certificados los cuales cumplen su finalidad de manera idnea
basados en las leyes estipuladas para la educacin superior, as como tambin
reglamentos internos de la institucin.
Este mdulo es dirigido a la comunidad estudiantil el cual permite en sus
opciones atender requerimientos para el buen funcionamiento del proceso
acadmico de la Universidad de Guayaquil, ofreciendo una funcionalidad de
calidad a los estudiantes y personal administrativo.
Calidad del Software
(Pressman, 1992) seala que: Concordancia con los requisitos funcionales y de
rendimiento explcitamente establecidos con los estndares de desarrollo
explcitamente documentados y con las caractersticas implcitas que se espera
de todo software desarrollado profesionalmente. (Pressman 1992)
La calidad del software enfoca a la parte principal de un sistema tecnolgico
principalmente elaborando, un plan de calidad que estipule lo que se va a
realizar o a donde se enfocara permite evaluar la veracidad y calidad.
En el estudio de este proyecto la calidad es la herramienta principal para evaluar
el mdulo de trmites donde se efectivizara que cada uno de los proceso
involucrados estn correctamente probados siento este prototipo un servicio de
calidad que la carrera de Ingeniera en Sistemas Computacionales ofrezca al
personal estudiantil y administrativo para su posterior interaccin dentro o fuera
de la Universidad.
12
Principio de calidad
Mario Tribus, La Calidad nunca es tu Problema, la Calidad es la Solucin a tu
problema.
Proceso de trmites
El proceso que se realiza en la universidad de Guayaquil de solitudes involucra
varios subprocesos que detallo a continuacin.
GRFICO N. 1
PROCESO DE TRMITES
Elaborado por: Jessica Snchez Solrzano Fuente: Secretaria de CISC&CINT
13
USUARIOS INVOLUCRADOS EN EL PROCESO DE TRMITES
Alumno:
Es la persona solicitante de un requerimiento en este caso ya sea solicitud o
certificados y realizan la peticin mediante una hoja impresa con un formato
predispuesto dirigido a la Directora de la Carrera y lo entregan en el
Departamento de Recepcin.
Recepcin:
En este departamento se encuentra la persona encargada de recibir los
requerimientos que los usuarios hacen a la institucin para despus ser dirigidos
al departamento especfico, llevando en una bitcora los registros de los
documentos ingresados.
Secretaria digitador uno:
Los funcionarios del departamento de secretaria cuentan con el perfil de
digitador segn contratos o nombramientos establecidos, el cual cumple la
funcin de verificar lo que el alumno solicita en el documento impreso previo a
esto el director autoriza la verificacin, posterior es enviada al secretario de la
carrera.
Secretaria secretario general:
Persona que valida y autoriza los requerimientos determinados en la carrera
previo a una verificacin del requerimiento cumpliendo cada uno de los requisitos
previos a cada requerimiento.
Secretaria Digitador dos:
Llamado digitador dos en este grfico a la persona encargada que realiza en
ingreso al sistema del requerimiento autorizado por el secretario general de la
carrera previo a una validacin.
14
FODA
(Cryterium, 2015) seala que:
Determina que antes de tomar cualquier decisin estratgica, es imprescindible realizar un diagnstico de nuestra organizacin. El anlisis FODA es el mtodo ms sencillo y eficaz para decidir sobre el futuro. Nos ayudar a plantear las acciones que deberamos poner en marcha para aprovechar las oportunidades detectadas y a preparar a nuestra organizacin contra las amenazas teniendo conciencia de nuestras debilidades y fortalezas.
"Tomar decisiones o adoptar Estratgias en el actual mundo cambiante en el que nos desenvolvemos puede ser como jugar a la ruleta rusa si no lo hacemos basndonos en cifras, hechos y datos". (Cryterium, 2015)
Objetivo de un anlisis FODA
(Cryterium, 2015) seala que:
El principal objetivo de un anlisis FODA es ayudar a una organizacin a encontrar sus factores estratgicos crticos, para una vez identificados, usarlos y apoyar en ellos los cambios organizacionales: consolidando las fortalezas, minimizando las debilidades, aprovechando las ventajas de las oportunidades, y eliminando o reduciendo las amenazas.
El anlisis FODA se basa en dos pilares bsicos: el anlisis interno y el anlisis externo de una organizacin.
Anlisis Interno de la organizacin
Fortalezas:
Describe los recursos y las destrezas que ha adquirido la empresa, en qu nos diferenciamos de la competencia?, Qu sabemos hacer mejor?
Debilidades:
Describe los factores en los cuales poseemos una posicin desfavorable respecto a la competencia. Para realizar el anlisis interno se han de considerar anlisis de recursos, de actividades y de riesgos.
Anlisis Externo de la organizacin
Oportunidades:
Describen los posibles mercados, nichos de negocio... que estn a la vista de todos, pero si no son reconocidas a tiempo significa una prdida de ventaja competitiva.
Amenazas:
Describen los factores que pueden poner en peligro la supervivencia de la organizacin, si dichas amenazas son reconocidas a tiempo pueden esquivarse o ser convertidas en oportunidades. Para realizar el anlisis interno se han de considerar anlisis del entorno,
15
grupos de inters, aspectos legislativos, demogrficos y polticos. (Cryterium, 2015)
DIAGRAMA DE ISHIKAWA O DIAGRAMA CAUSA-EFECTO
(Ana Rojo, 2015) seala que:
El diagrama de Ishikawa o diagrama de causa y efecto es una de las herramientas clave para llevar a cabo la gestin eficaz de la calidad en la empresa. A la hora de encontrar las causas, tanto negativas como positivas, de un resultado que se est estudiando, esta herramienta se convierte en un potente aliado ya que permite determinar un conjunto de causas probables que delimitan el campo de actuacin o revisin para comprender los orgenes del aspecto estudiado.
Importancia del diagrama de Ishikawa
El diagrama de causa y efecto fue creado a principios de los aos 40 por Kaoru Ishikawa como una herramienta que permite la identificacin, clasificacin de los distintos aspectos en categoras tiles y muestra, gracias a todo lo anterior, un conjunto de posibles causas que han provocado un problema o efecto. Este diagrama tambin es conocido como diagrama de Ishikawa en honor a su creador y diagrama de espina de pescado debido a la imagen visual que adopta una vez finalizado y que se asemeja, utilizando un poco de imaginacin, a la espina de un pescado comn.
De esta forma se convierte en una herramienta muy eficaz que permite a aquel que lo utilice poder identificar con un simple vistazo todas las posibles interrelaciones existentes entre un efecto y sus posibles causas. Sus utilidades son infinitas ya que no debemos solamente centrarnos en los aspectos negativos, es decir, no puede ser concebido nicamente como un instrumento para buscar las posibles causas de un problema o una situacin no deseada, sino que tambin se puede emplear para identificar todos aquellos posibles factores que llevaron a una situacin exitosa o a un triunfo.
No debemos olvidar que es igual de importante conocer las causas del xito tanto como las causas de un fracaso o problema, aunque en muchas situaciones tendemos a concentrarnos ms en este ltimo debido a la necesidad imperiosa de conocer las causas para atajarlas, y corregirlas y as evitar que vuelvan a producirse.
Aunque este diagrama de Ishikawa aporta importantes ventajas en su utilizacin como la potenciacin del consenso y la concentracin, el refuerzo de los conocimientos existentes y la fluidez de la informacin, potencia la participacin, etc., no es todo la panacea.
16
Y es que a pesar de todo lo anteriormente comentado, hay que tener muy claro a la hora de utilizar el diagrama de Ishikawa o diagrama de causa y efecto que nunca va a poder reemplazar la comprobacin emprica, ya que esta herramienta solo permite mostrar de una forma estructurada, clara y concisa las posibles hiptesis que se pueden barajar sobre las causas, efectos o situaciones que se estn analizando.
Es por esa razn que todos aquellos que deseen ir ms all de determinar los diversas causas probables y busquen conocer con absoluta certeza cul es la causa de fondo, deben centrarse en utilizar otra herramienta ya que esta no es la adecuada debido a que solamente va a determinar la posible direccin sobre la que se encuentra la causa pero no la va a sealar.
Pasos a seguir:
A la hora de implantar esta herramienta se debe adaptar a las necesidades del grupo o la empresa, sin embargo siempre hay que tener claros una serie de puntos o pasos que se deben seguir y que, de forma genrica, nos permitirn que se forme la tan caracterstica espina de pescado que caracterstica este diagrama de Ishikawa o diagrama de causa y efecto. Los pasos a seguir son:
1. Definir de forma clara, sencilla y concisa el efecto o problema del que se quieren definir las causas. Con ello formamos la espina central.
2. Se identifican las causas que van a contribuir al efecto o problema. 3. Se seleccionan las causas principales que constituyen las ramas
principales del diagrama. 4. Se asocia, a las ramas principales anteriormente identificadas, las causas
que se han determinado para el efecto principal asociado. 5. Se aaden causas sub diarias que contribuyen a las causas del punto
anterior. Este punto junto con los dos anteriores van a formar las espinas laterales y van a dibujar la forma de espina de pescado tan caracterstica.
6. Se verifica la lgica del diagrama que se ha conseguido y su utilidad real y, por ltimo, se extraen conclusiones sobre lo detallado.
El diagrama de Ishikawa proporciona una imagen visual y muy grfica de todas las posibles causas que han provocado el efecto estudiado. (Ana Rojo, 2015)
17
GRFICO N. 2:
DIAGRAMA DE CAUSA Y EFECTO
Elaborado por: Jessica Snchez Solrzano Fuente: tecnologiaycalidad.galeon.com
SOFTWARE
(Sommerville, 2005) seala que: Programas de ordenador y la documentacin
asociada. Los productos de software se pueden desarrollar para algn cliente en
particular o para un mercado general. (Sommerville, 2005)
En el mercado actual la poblacin interacta a menudo con la tecnologa ya que
la mayora de transacciones o procesos se los realiza con la ayuda de un
aplicativo que permita el fcil acceso para su realizacin.
Errores de software
(Jiantao, 1999) seala que:
Los errores de software casi siempre van a existir en cualquier mdulo de software con tamao moderado: no porque los programadores son descuidados o irresponsables, sino porque la complejidad del software es generalmente intratable y los seres humanos tienen una capacidad limitada para manejar la complejidad. Tambin es cierto que para cualquier sistema complejo, defectos de diseo nunca se pueden descartar. (Jiantao, 1999)
(Dijkastra, 1970) seala que: Las pruebas de software pueden ser usadas para
mostrar la presencia de errores pero nunca su ausencia. (Dijkastra, 1970)
18
Los errores que cometen los desarrolladores es algo que se ha vuelto tan
cotidiano, no por voluntad propia sino ms bien por la complejidad que el
software tenga ya que a medida que transcurre el tiempo los usuarios finales son
ms exigentes al momento de solicitar un software para optimizar sus procesos,
cabe recalcar que los errores se convierten en inconformidades para los que
requieren este proceso ya que no muestra lo que el inicialmente solicito para su
utilizacin, y en ocasiones no aceptan lo que se le entrega como producto final
por no cumplir con lo solicitado.
PRUEBAS DE SOFTWARE
(Pressman, 2002) seala que:
La prueba es el proceso de ejecutar un programa con intencin de encontrar defectos. Es un proceso destructivo que determina el diseo de los casos de prueba y la asignacin de responsabilidades.
El desarrollador encargado de programar un software desde un caso de uso no busca cometer errores sino ms bien interpretar lo que el usuario necesita y presentarlo de manera entendible para su utilizacin, a su vez para comprobar la calidad del producto final se desarrollan casos de pruebas que me permitan comportarme como un usuario buscando las cuantiosas situaciones en las que pude caer, para lograr obtener un software de calidad revisamos minuciosamente cada una de las partes del software. (Pressman, 2002)
REQUISITOS ANTES DE REALIZAR PRUEBAS
(Pressman, 2002) indica que : Antes de realizar pruebas debemos conocer la estructura, as como tambin contar con todos los programas que impliquen el funcionamiento del software para su posterior aplicacin de pruebas. Las consideraciones para generar un plan de pruebas son:
Mtodos de prueba,
Infraestructura (para desarrollo de software de prueba y ejecucin de las pruebas.
Automatizacin de las pruebas
Software de apoyo
Riesgos.
19
Se requiere un plan global, y uno detallado para cada actividad de prueba pruebas unitarias, de integracin, de facilidad de uso, funcionales, de sistema y de aceptacin. (Pressman, 2002)
PLAN DE PRUEBAS
(Microsoft, 2015) indica que:
Un plan de pruebas permite especificar lo que desea probar y cmo ejecutar dichas pruebas. Un plan de pruebas se puede aplicar a una iteracin concreta de su proyecto. Se puede tener solo un conjunto de pruebas predeterminado para sus casos de prueba o puede crear una jerarqua de conjuntos de pruebas para comprobar la calidad. (Microsoft, 2015)
(Burnstein, 2002) seala que:
Planes de prueba para proyectos de software son documentos muy complejos y detallados. El planificador de generalmente incluye lo siguiente lo primordial:
Los Objetivos de las pruebas globales. Como probadores, por qu estamos probando, lo que dice ser?
Alcance de las pruebas, y cules son los riesgos asociados con las pruebas de este producto?
Quin pondr a prueba? Quines son las personas responsables de las pruebas?
Cmo probar? Qu Estratgias, mtodos, hardware, herramientas de software y tcnicas se van a aplicar? Qu documentos de prueba se entregarn?
Cuando se realizan las pruebas. Cules son los horarios de las pruebas? Qu necesito que est disponible?
Cuando se detienen las pruebas. No es econmicamente factible o
prctico planificar para probar hasta que todos los defectos han sido
revelados. (Burnstein, 2002)
Aplicacin de las pruebas de software
Las pruebas de software por lo general se las aplica al final de desarrollo pero de
la misma manera lo podemos realizar a medida que se va programando cada
una de sus fases para evaluar la calidad de lo que se est entregando
20
comparando con lo que se solicit de manera inicial, realizar los casos de
pruebas nicamente al final del proceso toma tiempo volver a corregir errores o
interferencias que tenga el software.
Consecuencias al no aplicar un plan de pruebas
Al no aplicar pruebas en un sistema corremos el riesgo en que se entregue un
producto con errores y comprobar que quedaremos con clientes o usuario finales
insatisfechos ya que no se podr corroborar la calidad de este software,
implicando que el usuario no podr acceder a lo requerido impidiendo realizar
procesos que en un tiempo determinado o procesos incompletos que involucren
incertidumbre a los usuarios.
Las instituciones no se arriesgan a presentar un software sus clientes sin que
este haya sido pasado por un plan de pruebas que permita corroborar su
calidad, ya que puede causar prdidas econmicas o de prestigio al entregar un
sistema que en vez de causar automatizacin cause inconformidades a sus
instituciones.
BENEFICIOS DE LAS PRUEBAS
El beneficio principal de cada una de las pruebas lograr identificar cada una uno
de los errores que este tenga y poder entregar un producto de calidad y
amigable que satisfaga al usuario final.
Al contar con un software de calidad la institucin o empresa que lo ofrecer o
desarrollara gana prestigio y competencia en el mercado local as atribuyendo
ganancias para la misma, ya que se contara con clientes satisfechos al
momento de acceder al software que permitir realizar procesos de un
determinado lugar.
ESTRATGIA DE PRUEBAS
(Pressman, 2005) indica que:
Una Estratgia de prueba del software integra los mtodos de diseo de caso de pruebas del software en una serie bien planteada de paso que desembocar en la eficaz construccin de software. La Estratgia
21
proporciona un mapa que describe los pasos que se darn como parte de la prueba, indica cuando se planean y cuando se dan estos pasos, adems de cunto esfuerzo, tiempo y recursos consumirn. Por tanto, cualquier Estratgia de prueba debe incorporar la planeacin de pruebas, el diseo de casos de pruebas, la ejecucin de pruebas y la recoleccin y evaluacin de los datos resultantes. (Pressman, 2005)
CASOS DE PRUEBAS
(Mndez, 2007) seala que: Los CP reflejan trazabilidad con los CU
(Funcionalidad), ya que estos muestran una secuencia ordenada de eventos, al
describir flujos bsicos, flujos alternos, precondiciones y pos condiciones.
(Mndez, 2007)
Los casos de prueba se basan principalmente en los Casos de uso donde nos
muestra la funcionalidad del software, permitiendo conocer que se solicit
desarrollar y que se est entregando como producto final, es aqu donde al
realizar las pruebas demostramos si cumple o no con el requerimiento solicitado
por el cliente, ya que esto permitir corroborar la calidad del software, no se
afirma que un software saldr libre de errores pero s que en su mayora
demostrara que se minimiza errores antes de salir a produccin donde los
usuarios finales harn uso del mismo.
Pruebas al sistema (Niveles):
(Sommerville, 2005) dice que: Las pruebas del sistema implican integrar dos o
ms componentes que implementan funciones del sistema o caractersticas y a
continuacin se prueba este sistema integrado. (Sommerville, 2005)
Pruebas unitarias:
(Pressman, 2005) seala que: La prueba de unidad se concentra en el esfuerzo
de verificacin de la unidad ms pequea del diseo del software: el
componente o mdulo de software. Tomando como gua la descripcin del
diseo a nivel de componentes. (Pressman, 2005)
22
Pruebas de caja negra:
(Sommerville, 2005) Se seala que: Las pruebas de entrega son el proceso de
probar una entrega del sistema que ser distribuida a los clientes. El principal
objetivo de este proceso es incrementar la confianza del suministrador en que el
sistema satisface sus requerimientos. (Sommerville, 2005)
Pruebas de Regresin:
(Colomo, 2008) seala que: Las pruebas de regresin tratan de eliminar el
efecto onda, es decir, comprobar que los cambios sobre un componente de un
sistema de informacin, no introducen un comportamiento no deseado o errores
adicionales en otros componentes no modificados. (Colomo, 2008)
Pruebas de interface:
(Sommerville, 2005) define que: Muchos componentes en un sistema no son
simples funciones u objetos, sino que son componentes compuestos formados
por varios objetos que interactan, se accede a la funcionalidad de estos
componentes a travs de sus interfaces definidas. (Sommerville, 2005)
Las pruebas son aplicados y siendo estos llamados casos de pruebas los cuales
para las pruebas de interfaz usaremos el formato de la figura N.3
Pruebas de Recuperacin:
(Pressman, 2005) seala que:
Es una prueba del sistema que obliga al software a fallar de varias maneras ya verificar que la recuperacin se realice apropiadamente. Si la recuperacin es automtica debe evaluarse que sea correcta la re inicializacin, los mecanismos de respaldo del sistema, recuperacin de datos y el nuevo arranque. (Pressman, 2005)
23
FORMATOS DE CASOS DE PRUEBA Para la ejecucin de pruebas se utilizara los siguientes formatos de casos de
pruebas para determinar el avance del mdulo de trmites.
CUADRO N. 2:
CASO DE PRUEBAS FUNCIONALES
NOMBRE CASO DE PRUEBA: TIPO DE USUARIO:
DESCRIPCIN DE CASO DE PRUEBA: DESCRIPCIN
1. Ingresar al Sistema de la carrera 2. Seleccionar la Universidad-facultad-carrera 3. Ingresar su usuario y su clave segn perfil (Solicitar clave al administrador de pruebas) 4. Visualizar el men 5. Navegar al men: Matriculacin\turno para proceder
6. Clic en el botn Nuevo 7. Da Paso a un mensaje flotante Datos de turno 8. Se inhabilitara la pantalla anterior 9. Ingreso de la descripcin del turno que se va a generar
ESCENARIOS INGRESO SALIDA ESPERADA
Ingreso de Texto Ingreso de Nmeros Ingreso de Caracteres especiales
Turno inicial 123456 %%/)
Texto Turno Inicial Texto 123456
Texto %%/) Observaciones: El textbox debe permitir ingresar cualquier carcter ya sea mayscula o minscula para poder poner nombre al turno que se quiere generar.
Elaborado: Jessica Snchez Solrzano
Fuente: http:/calidadysoftware.com
Creado por:
Revisado por:
Modificado por: Fecha: 02 de Mayo
24
CUADRO N. 3:
FORMATOS DE PRUEBAS DE INTERFAZ
NOMBRE CASO DE PRUEBA
TIPO DE USUARIO
DESCRIPCIN DE CASO DE PRUEBA:
1. Ingresar al Sistema de la carrera
2. Seleccionar la Universidad-facultad-carrera
3. Ingresar su usuario y su clave segn perfil (Solicitar clave al administrador de pruebas)
4. Visualizar el men
5. Navegar al men: Matriculacin\turno para proceder
6. Clic en el botn Nuevo
CAMPO
TIPO DE COMPONENTE PARMETROS
Boton
Caja de
Texto
Caja de
combo
Tipo Fech
a
Tipo Hora
Caja de Verificacin
Seleccin Tipo Dato
Obligatorio
Activa Inactivo SI NO
DESCRIPCIN X
FECHA INICIO X X
FECHA FIN X
HORA INICIO X X
HORA FIN X
CUPO X X
ESTADO
X X
ASIGNACIN TURNO
X
SALIR X
GUARDAR X
Observacin:
Elaborado: Jessica Snchez Solrzano
Fuente: Fuente: http:/calidadysoftware.com
Creado por:
Revisado por:
Modificado por: Fecha: 02 de Mayo
25
CUADRO N. 4
FORMATOS DE REGISTRO DE RESULTADOS POR TIPO DE PRUEBA
Elaborado: Jessica Snchez Solrzano
Fuente: Fuente: http:/calidadysoftware.com
CUADRO N. 5
FORMATOS DE REGISTRO DE RESULTADOS GENERALES PORCENTUAL
Aprobado por:
Revisado por:
Aprobado por: Fecha:
Elaborado: Jessica Snchez Solrzano
Fuente: Fuente: http:/calidadysoftware.com
PRUEBAS FUNCIONALES
MDULO:
CASO DE USO CASO DE PRUEBA RESULTADOS DE LAS
PRUEBAS
Nombre de Caso de Uso 1 Nombre de Caso de Prueba 1 OK
Nombre de Caso de Uso 2 Nombre de Caso de Prueba 2 OK
Nombre de Caso de Uso 3 Nombre de Caso de Prueba 3 OK
Creado por:
Revisado por:
Modificado por: Fecha: 02 de Mayo
INFORME MODULAR
MDULO: MATRICULACIN OPCIN TIPO DE PRUEBA PORCENTAJE DE CUMPLIMIENTO
Nombre de Submdulo 1
Funcionales
Interfaz
Nombre de Submdulo 2
Funcionales
Interfaz
26
METODOLOGAS GILES
(Raya, 2014) seala que:
Las metodologas giles son una serie de tcnicas para la gestin de proyectos que han surgido como contraposicin a los mtodos clsicos de gestin como CMMI. Aunque surgieron en el mbito del desarrollo de software, tambin han sido exportadas a otro tipo de proyectos.
Todas las metodologas que se consideran giles cumplen con el manifiesto gil que no es ms que una serie de principios que se agrupan en cuatro valores:
1. Los individuos y su interaccin, por encima de los procesos y las herramientas.
2. El software que funciona, frente a la documentacin exhaustiva. 3. La colaboracin con el cliente, por encima de la negociacin contractual. 4. La respuesta al cambio, por encima del seguimiento de un plan.
Inicialmente, mucha gente asocia metodologas giles con falta de documentacin o control sobre el proyecto, pero esto es totalmente falso! Lo que se desea es minimizar el impacto de las tareas que no son totalmente imprescindibles para conseguir el objetivo del proyecto. Se pretende aumentar la eficiencia de las personas involucradas en el proyecto y, como resultado de ello, minimizar el coste.
Llegados a este punto, nos preguntamos si son mejores las metodologas giles que las tradicionales. La respuesta es que no. Entonces, son mejores las tradicionales frente a las giles? Tampoco. Como otras muchas cosas en la vida, depende del tipo de proyecto en el que se apliquen y aqu es donde tienen su punto de unin con los principios Lean Startup. (Raya, 2014)
Las principales metodologas giles
(Raya, 2014) seala que:
Uno de los principales focos de aplicacin de las metodologas giles son los proyectos tecnolgicos. Cada una de ellas tiene sus fortalezas y sus debilidades, pero no son excluyentes. En cada proyecto podemos adoptar una, o varias, en funcin de las caractersticas del propio proyecto y del equipo.
27
Entre las metodologas giles ms usadas se encuentran:
SCRUM.- Es un marco de trabajo que nos proporciona una serie de herramientas y roles para, de una forma iterativa, poder ver el progreso y los resultados de un proyecto.
KANBAN.- Se basa en una idea muy simple. sta es que el trabajo en curso (Work In Progress, WIP) debera limitarse y slo deberamos empezar con algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra funcin posterior de la cadena.
XP.- Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores y propiciando un buen clima de trabajo. (Raya, 2014)
MAPA DE PROCESOS ACTUAL DE SOLICITUDES
Para continuar con el anlisis a continuacin se muestran los mapas de
procesos de un determinado nmero de las solicitudes que se realizan dentro de
la carrera de Ingeniera en Sistemas Computacionales.
Proceso de inclusin de materia: Esta solicitud la realizan los alumnos que
deseen incluir una materia a su registro de matrcula antes que inicie el semestre
y dentro del proceso de matriculacin indicado dicho proceso en el grafico N. 3,
en el proceso se realizan los siguientes subprocesos:
1. El alumno ingresa un documento en fsico en recepcin donde consta la
inclusin de materia, en la misma indica el nombre de la materia y el
paralelo de la cual desea incluir en su registro.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados a la asistente del secretario
general.
3. La asistente del secretario con autorizacin del secretario general verifica
el cupo disponible del curso de la cual solicita el alumno para la inclusin
y este es enviado al secretario para que autorice el ingreso del
requerimiento el digitador.
http://es.wikipedia.org/wiki/Scrumhttp://es.wikipedia.org/wiki/Kanban_(desarrollo)http://es.wikipedia.org/wiki/Extreme_programming
28
4. El secretario valida la inclusin y autoriza al digitador atender el
requerimiento.
5. Una vez de que la solicitud se encuentre autorizada por el secretario
general de la carrera donde indica que si procede la inclusin el digitador
ingresa al sistema y registra el requerimiento.
6. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
GRFICO N. 3
MAPA DE PROCESO INCLUSIN DE MATERIA
Elaborado: Jessica Snchez Solrzano
Fuente: Secretaria CISC
Proceso de anulacin de materia: La anulacin de materia es dejar sin
efecto una materia en la cual se ha registrado el alumno ya sea que se
encuentre legalizada o no su matrcula y deber ser fuera del proceso de
matrcula y el proceso que se realiza lo mostramos en el grfico N.4.
1. El alumno ingresa un documento en fsico en recepcin donde consta la
anulacin de materia, en la misma indica el nombre de la materia y el
paralelo de la cual desea anular en su registro con el respectivo motivo.
29
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados a la asistente del secretario
general.
3. La asistente del secretario con autorizacin del secretario general verifica
si el alumno ha anulado la materia en semestres anteriores ya que se
puede anular una materia nicamente dos veces en todo el periodo
estudiantil y este es enviado al secretario para que autorice la anulacin
del requerimiento al digitador.
4. El secretario valida la inclusin y autoriza al digitador atender el
requerimiento
5. Una vez de que la solicitud se encuentre autorizada por el secretario
general de la carrera donde indica que si procede la anulacin el digitador
ingresa al sistema y anula la materia.
6. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
GRFICO N. 4
MAPA DE PROCESO ANULACIN DE MATERIA
Elaborado: Jessica Snchez Solrzano Fuente: Secretaria CISC
30
Proceso de cambio de paralelo: El cambio de paralelo es la asignacin en
un nuevo paralelo diferente del que se inscribi en el momento de realizar su
registro de materias dicho proceso est reflejado en la imagen N.5 el cual pasa
por subprocesos para autorizar el cambio.
1. El alumno ingresa un documento en fsico en recepcin donde consta el
cambio de paralelo, en la misma indica el nombre de la materia, el
paralelo en el cual fue inscrito como tambin el paralelo al que se quiere
cambiar.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados a la asistente del secretario
general.
3. La asistente del secretario con autorizacin del secretario general verifica
si existe cupo al cual el alumno desea cambiarse de paralelo y este es
enviado al secretario para que autorice la anulacin del requerimiento al
digitador.
4. El secretario valida el cambio de paralelo y autoriza al digitador atender el
requerimiento
5. Una vez de que la solicitud se encuentre autorizada por el secretario
general de la carrera donde indica que si procede el cambio de paralelo el
digitador ingresa al sistema y anula la materia.
6. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
31
GRFICO N. 5
MAPA DE PROCESO CAMBIO DE PARALELO
Elaborado: Jessica Snchez Solrzano Fuente: Secretaria CISC
Proceso de matrcula por tercera vez: Esta matrcula es solicitada por los
alumnos que no aprobaron una o varias materias que se encontraban
estudiando por segunda vez y el proceso lo reflejamos en el grafico N. 6.
1. El alumno ingresa un documento en fsico en recepcin donde consta el
requerimiento de matrcula por tercera vez, en la misma indica el nombre
de la materia y el paralelo solicitado.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados a la asistente del secretario
general.
3. La asistente del secretario con autorizacin del secretario general verifica
si la solicitud se puede procesar este es enviado al secretario.
4. El secretario valida la peticin de la matricula por tercera vez realiza el
informe que ser enviado a direccin que firmar el documento que ser
enviado al decanato de la facultad.
5. En direccin la directora firma el documento de la peticin y es enviado al
decanato con el mensajero de la carrera.
32
6. El decano recibe la solicitud de requerimiento y este es autorizado y
enviado nuevamente al rectorado de la carrera para que contine con el
proceso.
7. Una vez de que la solicitud se encuentre autorizada por el decano el
secretario general de la carrera autoriza la matrcula para que el digitador
lo ingrese al sistema.
8. El alumno recibe la respuesta en las ventanillas de secretaria donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
GRFICO N. 6
MAPA DE PROCESO MATRICULA POR TERCERA VEZ
Elaborado: Jessica Snchez Solrzano Fuente: Secretaria CISC
33
Proceso de homologacin: Son las solicitudes que alumnos de otras
universidades o carreras desean homologar a la nueva carrera que ingresan por
materias ya vistas anteriormente en otra institucin este proceso esta mostrado
en el grfico N. 7.
1. El alumno ingresa un documento en fsico en recepcin donde consta el
requerimiento de homologacin, en la misma indica el nombre de las
materia a homologar.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados al departamento de direccin.
3. La directora autoriza proceso y enva al secretario para que inicie el
proceso para la homologacin de materias.
4. El secretario valida la peticin de la homologacin y realiza el informe
que ser enviado a subdireccin de la carrera para que verifiquen el
pensum acadmico de las materias a homologar.
5. El subdirector procede a coordinar con los directores de rea para
verificar si la homologacin procede respecto al pensum acadmico de la
carrera y una vez concluido envan el informe al secretario general.
6. Una vez de que el informe del subdirector es el secretario autoriza al
digitador que proceda con la homologacin.
7. La digitadora recibe el documento autorizado por el secretario y procede
a realizar la homologacin.
8. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
34
GRFICO N. 7
MAPA DE PROCESOS DE HOMOLOGACIN
Elaborado: Jessica Snchez Solrzano
Fuente: Secretaria CISC
Proceso de matrcula especial: Este proceso de solicitudes se lo realiza a
los alumnos que no se pudieron matricular en el periodo de matriculacin
establecido y est reflejado este proceso en el grafico N. 8.
1. El alumno ingresa un documento en fsico en recepcin donde consta el
requerimiento de matrcula por tercera vez, en la misma indica el nombre
de la materia y el paralelo solicitado.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados a la asistente del secretario
general.
3. El secretario valida la peticin de la matricula por tercera vez realiza el
informe que ser enviado a direccin que firmar el documento que ser
enviado al decanato de la facultad.
4. En direccin la directora firma el documento de la peticin y es enviado al
vicerrectorado de la Universidad de Guayaquil con el mensajero de la
carrera.
5. El Vicerrector recibe peticin y autoriza que se proceda la matrcula.
35
6. El secretario recibe solicitud con la aprobacin del vicerrectorado y
autoriza a digitador a ingresar al sistema.
7. Una vez de que la solicitud se encuentre autorizada por el secretario
general de la carrera el digitador ingresa al sistema a realizar la peticin.
8. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
GRFICO N. 8 MAPA DE PROCESOS DE MATRICULA ESPECIAL
Elaborado: Jessica Snchez Solrzano Fuente: Secretaria CISC
Proceso de homologacin: Son las solicitudes que alumnos de otras
universidades o carreras desean homologar a la nueva carrera que ingresan por
materias ya vistas anteriormente en otra institucin este proceso esta mostrado
en el grfico N. 9.
36
1. El alumno ingresa un documento en fsico en recepcin donde consta el
requerimiento de homologacin, en la misma indica el nombre de las
materia a homologar.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados al departamento de direccin.
3. El secretario valida la peticin del cambio de carrera y realiza el informe
que ser enviado a subdireccin de la carrera para que canalice el
cambio.
4. Asistente de subdirector realiza informe donde enva a secretario a que
firmar el informe.
5. Secretario analiza el cambio de carrera y autoriza cambio.
6. El informe es enviado al asistente del subdirector y este es presentado a
subdirector para que firme el informe y posterior a esto ingresa en el
sistema para realizar el cambio de carrera.
7. El alumno recibe la respuesta en subdireccin donde notifican si fue o no
procesado el requerimiento, en la misma es atendido por un digitador.
GRFICO N. 9
MAPA DE PROCESOS DE CAMBIO DE CARRERA
Elaborado: Jessica Snchez Solrzano
Fuente: Secretaria CISC
37
Proceso de recalificacin: Este proceso lo realizan los alumnos que no
estn de acuerdo con la calificacin que el docente asent en exmenes ya sea
finales o suspensos el mismo proceso est reflejado en la figura N. 10.
1. El alumno ingresa un documento en fsico en recepcin donde consta el
requerimiento de homologacin, en la misma indica el nombre de la
materia de donde el examen sugiere ser recalificado.
2. Realiza informe de solicitudes ingresadas en una bitcora registrando el
nombre del alumno el tipo de solicitud como tambin se le asigna un
cdigo de trmite y estos son enviados al departamento de direccin.
3. La directora autoriza proceso y enva al secretario para que inicie el
proceso para la recalificacin del examen.
4. El subdirector procede a coordinar con los directores de rea para que se
realice la recalificacin y realizar el reporte de la nota final despus de la
recalificacin y esta es enviada al secretario
5. El secretario recibe examen con el informe de la recalificacin y autoriza
para que realicen el cambio de nota en el departamento de software con
el programador encargado.
6. La programador procede a realizar el cambio recibe el documento
autorizado por el secretario y procede a realizar la homologacin.
7. El alumno recibe la respuesta en las ventanillas de subdireccin donde
notifican si fue o no procesado el requerimiento, en la misma es atendido
por un digitador, en ocasiones y en proceso de matrcula el alumno retira
su solicitud con la respuesta en el departamento que coordinan que
proceda la solicitud.
41
GRFICO N. 10
MAPA DE PROCESOS DE RECALIFICACIN
Elaborado: Jessica Snchez Solrzano Fuente: Secretaria CISC
FUNDAMENTACIN LEGAL
El desarrollo de este proyecto est respaldado en base al marco legal de la Ley
Orgnica de Educacin Superior y del Reglamento de Matrculas y Tasas de la
Universidad de Guayaquil.
Reglamento de rgimen acadmico codificado del consejo de educacin superior
Que, el artculo 26 de la Ley Orgnica De Educacin Superior, establece: La
educacin es un derecho de las personas a lo largo de su vida y un deber
ineludible e inexcusable del Estado. Constituye un rea prioritaria de la poltica
pblica y de la inversin estatal, garanta de la igualdad e inclusin social y
condicin indispensable para el buen vivir. [];
42
Que, el artculo 356 de la Constitucin de la Repblica del Ecuador, prescribe
que la educacin pblica ser gratuita hasta el tercer nivel. El ingreso a las
instituciones pblicas de educacin superior se regular a travs de un sistema
de nivelacin y admisin, definido en la ley. La gratuidad se vincular a la
responsabilidad acadmica de las estudiantes y los estudiantes.
Que, el Art. 71 de la Ley Orgnica De Educacin Superior, establece que el
principio de igualdad de oportunidades consiste en garantizar a todos los actores
del Sistema de Educacin Superior las mismas posibilidades en el acceso,
permanencia, movilidad y egreso del sistema, sin discriminacin de gnero,
credo, orientacin sexual, etnia, cultura, preferencia poltica, condicin
socioeconmica o discapacidad.
Que, el Art. 80 de la Ley Orgnica De Educacin Superior, prescribe que se
garantiza la gratuidad de la educacin superior, prescribe que se garantiza la
gratuidad de la educacin superior pblica hasta el tercer nivel, la misma que
observar el criterio de responsabilidad acadmica de los y las estudiantes ().
Que, el Art. 84 de la Ley Orgnica De Educacin Superior, establece los
requisitos para aprobacin de cursos y carreras y seala que los requisitos de
carcter acadmico y disciplinario necesarios para la aprobacin de cursos y
carreras, constaran en el Reglamento de Rgimen Acadmico, en los
respectivos estatutos, reglamentos y dems normas que rigen al Sistema de
Educacin Superior. Solamente en casos establecidos excepcionalmente en el
estatuto de cada institucin, un estudiante podr matricularse hasta por tercera
ocasin en una misma materia o en el mismo ciclo, curos o nivel acadmico.
En la tercera matrcula de la materia, curso o nivel acadmico no existir opcin
a examen de gracia o de mejoramiento.
Que, el Art. 33 de la Ley Orgnica De Educacin Superior, seala que la
matrcula es el acto de carcter acadmico-administrativo, mediante el cual una
persona adquiere la condicin de estudiante, a travs del registro de las
asignaturas, cursos o sus equivalentes, en un periodo acadmico determinado y
conforme a los procedimientos internos de una IES. La condicin de estudiante
43
se mantendr hasta el inicio del nuevo periodo acadmico ordinario o hasta su
titulacin.
Que, el Art. 34 del reglamento ibdem establece los tipos de matrcula y seala
que dentro del Sistema de Educacin Superior, se establecen los siguientes
tipos de matrcula: a. Matrcula ordinaria.- Es aquella que se realiza en el plazo
establecido por la IES para el proceso de matriculacin, que en ningn caso
podr ser mayor a 15 das. B. Matricula extraordinaria.- Es aquella que se realiza
en el plazo mximo de 15 das posteriores a la culminacin del periodo de
matrcula ordinaria. C. Matrcula Especial.- Es aquella que, en casos individuales
excepcionales, otorga el rgano colegiado acadmico superior de las
universidades y escuelas politcnicas, as como el organismo de gobierno de los
institutos y conservatorios superiores, para quien, por circunstancias de caso
fortuito o fuerza mayor debidamente documentadas, no se haya podido
matricular de manera ordinaria o extraordinaria. Esta matrcula se podr realizar
hasta dentro de quince das posteriores a la culminacin del periodo de matrcula
extraordinaria.
Para los programas de postgrado, las Universidades y Escuelas Politcnicas
establecern nicamente periodos de matrcula ordinaria y extraordinaria.
Se considera como inicio de la carrera o programa la fecha de la matriculacin
de la primera cohorte de los mismos.
Que, es necesario que la normativa de matrculas y tasas vele por el principio de
igualdad de oportunidades y garantice a todos los estudiantes las mismas
posibilidades en el acceso, permanencia, movilidad y egreso del sistema de
educacin.
Ley de la Propiedad Intelectual
Art. 29. Es titular de un programa de ordenador, el productor, esto es la persona
natural o jurdica que toma la iniciativa y responsabilidad de la realizacin de la
obra. Se considerar titular, salvo prueba en contrario, a la persona cuyo nombre
conste en la obra o sus copias de la forma usual.
44
Dicho titular est adems legitimado para ejercer en nombre propio los derechos
morales sobre la obra, incluyendo la facultad para decidir sobre su divulgacin.
El productor tendr el derecho exclusivo de realizar, autorizar o prohibir la
realizacin de modificaciones o versiones sucesivas del programa, y de
programas derivados del mismo. Las disposiciones del presente artculo podrn
ser modificadas mediante acuerdo entre los autores y el productor.
Art. 30. La adquisicin de un ejemplar de un programa de ordenador que haya
circulado lcitamente, autoriza a su propietario a realizar exclusivamente:
Una copia de la versin del programa legible por mquina (cdigo objeto) con
fines de seguridad o resguardo;
Fijar el programa en la memoria interna del aparato, ya sea que dicha fijacin
desaparezca o no al apagarlo, con el nico fin y en la medida necesaria para
utilizar el programa; y,
Salvo prohibicin expresa, adaptar el programa para su exclusivo uso personal,
siempre que se limite al uso normal previsto en la licencia. El adquirente no
podr transferir a ningn ttulo el soporte que contenga el programa as
adaptado, ni podr utilizarlo de ninguna otra forma sin autorizacin expresa,
segn las reglas generales.
Se requerir de autorizacin del titular de los derechos para cualquier otra
utilizacin, inclusive la reproduccin para fines de uso personal o el
aprovechamiento del programa por varias personas, a travs de redes u otros
sistemas anlogos, conocidos o por conocerse.
Art. 31. No se considerar que exista arrendamiento de un programa de
ordenador cuando ste no sea el objeto esencial de dicho contrato. Se
considerar que el programa es el objeto esencial cuando la funcionalidad del
objeto materia del contrato, dependa directamente del programa de ordenador