FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS...

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


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



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



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:


Fuente: Fuente: http:/calidadysoftware.com

Creado por:

Revisado por:


25

CUADRO N. 4

FORMATOS DE REGISTRO DE RESULTADOS POR TIPO DE PRUEBA



CUADRO N. 5

FORMATOS DE REGISTRO DE RESULTADOS GENERALES PORCENTUAL

Aprobado por:

Revisado por:

Aprobado por: Fecha:



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



Creado por:

Revisado por:


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


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




general.


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


general de la carrera donde indica que si procede la anulacin el digitador

ingresa al sistema y anula la materia.






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.




general.


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


general de la carrera donde indica que si procede el cambio de paralelo el

digitador ingresa al sistema y anula la materia.






31

GRFICO N. 5

MAPA DE PROCESO CAMBIO DE PARALELO


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.


requerimiento de matrcula por tercera vez, en la misma indica el nombre

de la materia y el paralelo solicitado.




general.


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





GRFICO N. 6

MAPA DE PROCESO MATRICULA POR TERCERA VEZ


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.


requerimiento de homologacin, en la misma indica el nombre de las

materia a homologar.



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.






34

GRFICO N. 7

MAPA DE PROCESOS DE HOMOLOGACIN



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.


requerimiento de matrcula por tercera vez, en la misma indica el nombre

de la materia y el paralelo solicitado.




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.


general de la carrera el digitador ingresa al sistema a realizar la peticin.






GRFICO N. 8 MAPA DE PROCESOS DE MATRICULA ESPECIAL


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


requerimiento de homologacin, en la misma indica el nombre de las

materia a homologar.




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



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.


requerimiento de homologacin, en la misma indica el nombre de la

materia de donde el examen sugiere ser recalificado.




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.






41

GRFICO N. 10

MAPA DE PROCESOS DE RECALIFICACIN


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

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS...

Documents

Transcript of FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS...