UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

Diseño del sistema web para la gestión de aspirantes para la

“Escuela De Formación De Oficiales y Tropa” de la

Comisión de Transito del Ecuador, en las

etapas de Reclutamiento, Formación,

Especialización y Ascenso.

PROYECTO DE TITULACION

Previa a la obtención del Título de:

INGENIERO EN SISTEMAS COMPUTACIONALES

AUTOR:

Andrea Cecilia Zorrilla Molina

Gonzalo Eduardo Lara Gavilánez

TUTOR: Ing. Mary Cabanilla Burgos, Msc

GUAYAQUIL – ECUADOR

2016

I

REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA

FICHA DE REGISTRO DE PROYECTO DE TITULACION

TÍTULO: “DISEÑO DEL SISTEMA WEB PARA LA GESTIÓN DE ASPIRANTES PARA LA “ESCUELA DE FORMACIÓN DE OFICIALES Y TROPA” DE LA COMISIÓN DE TRANSITO DEL ECUADOR, EN LAS ETAPAS DE RECLUTAMIENTO, FORMACIÓN, ESPECIALIZACIÓN Y ASCENSO”

AUTORES:

ANDREA CECILIA ZORRILLA MOLINA

GONZALO EDUARDO LARA GAVILANEZ

REVISORES:

ING. BERNARDO IÑIGUEZ

LCDA. BEATRIZ CABRERA

INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL

FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA: INGENIERÍA EN SISTEMAS COMPUTACIONALES

FECHA DE PUBLICACIÓN: Año 2016 N° DE PÁGS.: 87

ÁREA TEMÁTICA: DISEÑO DE SOFTWARE Y BASE DE DATOS

PALABRAS CLAVES: UML, gestión de aspirantes, Comisión de Tránsito del Ecuador

RESUMEN: El presente trabajo de titulación tiene como objetivo diseñar los modelos correctos, completos,

concretos y sin ambigüedades de lo que sería el sistema web para la gestión de aspirantes para la Escuela de Formación de Oficiales y Tropa de la Comisión de Tránsito del Ecuador, siguiendo el paradigma de desarrollo de software orientado a objetos ya que, actualmente, todos los procesos de la institución se hacen manualmente o con el apoyo básico de programas ofimáticos, lo que causa diversos tipos de problemas en términos de seguridad y disponibilidad de la información. Estos modelos servirán para que, en un posterior proyecto, el equipo de desarrollo de software pueda tomar los diagramas diseñados y construir el sistema en base a la información que se presenta en este documento. Los beneficiarios de este trabajo serán, principalmente, la Escuela de Formación de Oficiales y Tropa de la Comisión de Tránsito del Ecuador ya que no tendrá que invertir en un estudio previo al desarrollo del sistema y, posterior a la implementación, el personal administrativo y los mismos aspirantes ya que toda la interacción con la institución se realizará a través del sistema, mejorando su productividad y la seguridad de la información. Para el desarrollo del trabajo se realizaron visitas en las instalaciones de la escuela donde se desarrollaron reuniones de trabajo con los diferentes niveles administrativos y de dirección de la institución para obtener la información adecuada e identificar las necesidades que debe cumplir el sistema. El sistema propuesto abarca los procesos de reclutamiento, formación, especialización y ascenso del personal que ingresa a la EFOT. Como principal resultado destacamos los modelos desarrollados en lenguaje UML mediante los cuales se representan todos los aspectos del sistema en cuanto a su estructura y funcionamiento, que han sido desarrollados siguiendo los estándares del lenguaje de modelado mencionado.

N° DE REGISTRO(en base de datos): N° DE CLASIFICACIÓN: Nº

DIRECCIÓN URL (tesis en la web):

ADJUNTO PDF x SI NO

CONTACTO CON AUTOR: ANDREA ZORRILLA – GONZALO LARA

Teléfono: 0996627829

E-mail: Andreazorrillam@gmail.com

CONTACTO DE LA INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL

Nombre:

Teléfono: 2318067

II

CARTA DE ACEPTACIÓN DEL TUTOR

En mi calidad de Tutor del trabajo de investigación, “Diseño del sistema web para

la gestión de aspirantes para la “ESCUELA DE FORMACIÓN DE OFICIALES Y

TROPA” DE LA COMISIÓN DE TRANSITO DEL ECUADOR, EN LAS ETAPAS DE

RECLUTAMIENTO, FORMACIÓN, ESPECIALIZACIÓN Y ASCENSO” elaborado por

los Sres. ANDREA CECILIA ZORRILLA MOLINA, GONZALO EDUARDO LARA

GAVILÁNEZ, egresados de la Carrera de Ingeniería en Sistemas

Computacionales, Facultad de Ciencias Matemáticas y Físicas de la Universidad

de Guayaquil, previo a la obtención del Título de Ingeniero en Sistemas, me

permito declarar que luego de haber orientado, estudiado y revisado, la Apruebo

en todas sus partes.

Atentamente

_______________________________________

ING. CABANILLA BURGOS MARY MSC.

TUTOR

III

CERTIFICACIÓN DE GRAMATÓLOGA

Quien suscribe el presente certificado, se permite informar que después de haber leído

y revisado gramaticalmente el contenido de la tesis de grado de: Andrea Cecilia Zorrilla

Molina y Gonzalo Eduardo Lara Gavilánez. Cuyo tema es: “Diseño del sistema web para

la gestión de aspirantes para la “Escuela De Formación De Oficiales y Tropa” de la

Comisión de Transito del Ecuador, en las etapas de Reclutamiento, Formación,

Especialización y Ascenso”.

Certifico que es un trabajo de acuerdo a las normas morfológicas, sintácticas y

simétricas vigentes.

ATENTAMENTE,

____________________________

Lcda. Beatriz Cabrera Rosero Licenciada.

IV

DEDICATORIA

El presente trabajo de titulación va dedicado

especialmente a mis amados padres Janny

Molina Bravo y José Zorrilla Sancán, quienes

han sido el motivo de mi esfuerzo diario y han

permanecido como el pilar fundamental durante

toda mi vida. Su esfuerzo y sacrificio me han

motivado para superar cualquier obstáculo y dar

siempre el mayor esfuerzo para lograr mis

objetivos. A mis amigos por su incondicional

apoyo, comprensión y soporte en todo este

tiempo de estudio y, especialmente al amor de

mi vida que ha sido parte de este logro.

Andrea Zorrilla Molina

El presente trabajo de titulación va dedicado a

mis queridos padres Fanny Leonor Gavilanez y

Aníbal Gonzalo Lara Lara quienes con su

ejemplo, dedicación, esfuerzo y trabajo honesto

nos han guiado por la senda del bien,

alentándonos a conseguir todas nuestras metas

planteadas y entre ellas la de llegar a ser un

buen profesional.

Gonzalo Eduardo Lara Gavilanez

V

AGRADECIMIENTO

Agradezco, en primer lugar a Dios todo poderoso

por darme salud y fuerzas para culminar esta

etapa de mi vida, donde me formé como

profesional y persona. A mis padres por su

perseverancia y consejos, además de su apoyo

económico y motivación cuando ya las fuerzas

parecían desvanecer. A mis profesores que con

su paciencia me enseñaron lecciones

profesionales pero también de vida. A mis locos

amigos que me acompañaron en este proceso,

llenos de esperanza y confianza de que íbamos a

llegar a nuestra meta.

Andrea Zorrilla Molina

Agradezco a Dios por darme las fuerzas

necesarias para cumplir con uno de los objetivos

más importantes de mi vida, a mis padres y

hermanos por su respaldo incondicional y

especialmente a la Comisión de Tránsito del

Ecuador a través de Sub-Pref. MSc. Oscar

Sabando Chumo por permitirme realizar este

proyecto en la escuela de Formación de Oficiales

y Tropa.

Gonzalo Lara Gavilanez

VI

TRIBUNAL PROYECTO DE TITULACIÓN

Ing. Eduardo Santos Msc. Ing. Inelda Martillo Alcívar Msc. DECANO DE LA FACULTAD DIRECTORA CIENCIAS MATEMÁTICAS CISC Y FÍSICAS

Ing. Mary Cabanilla Burgos Msc. Ing. Bernardo Iñiguez Muñoz Msc. DIRECTOR DEL PROYECTO PROFESOR DEL ÁREA - DE TITULACIÓN TRIBUNAL

Lcda. Beatriz Cabrera Rosero

PROFESOR DEL ÁREA – TRIBUNAL

Ab. Juan Chávez Atocha

SECRETARIO

VII

DECLARACIÓN EXPRESA

“La responsabilidad del contenido de este

proyecto de titulación, nos corresponden

exclusivamente; y el patrimonio intelectual de la

misma a la UNIVERSIDAD DE GUAYAQUIL”.

ANDREA CECILIA ZORRILLA MOLINA

GONZALO EDUARDO LARA GAVILANEZ

VIII

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERIA EN SISTEMAS

COMPUTACIONALES

“ DISEÑO DEL SISTEMA WEB PARA LA GESTIÓN DE

ASPIRANTES PARA LA “ESCUELA DE FORMACIÓN

DE OFICIALES Y TROPA” DE LA COMISIÓN DE

TRANSITO DEL ECUADOR, EN LAS ETAPAS

DE RECLUTAMIENTO, FORMACIÓN,

ESPECIALIZACIÓN Y ASCENSO”

Proyecto de Titulación que se presenta como requisito para optar por el título de

INGENIERO en SISTEMAS COMPUTACIONALES.

Autora: Andrea Cecilia Zorrilla Molina

C.I. 0925518235

Autor: Gonzalo Eduardo Lara Gavilánez

C.I. 0923682348

Tutor: Ing. Mary Cabanilla Burgos Msc.

Guayaquil, Marzo del 2016.

IX

CERTIFICADO DE ACEPTACIÓN DEL TUTOR

En mi calidad de Tutor de Proyecto de Titulación, nombrado por el Consejo

Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de

Guayaquil.

CERTIFICO:

Que he analizado el Proyecto de Grado presentado por los estudiantes

ANDREA CECILIA ZORRILLA MOLINA Y GONZALO EDUARDO LARA

GAVILÁNEZ, como requisito previo para optar por el título de Ingeniero en

Sistemas Computacionales cuyo problema es:

DISEÑO DEL SISTEMA WEB PARA LA GESTIÓN DE ASPIRANTES PARA LA

“ESCUELA DE FORMACIÓN DE OFICIALES Y TROPA” DE LA COMISIÓN DE

TRANSITO DEL ECUADOR, EN LAS ETAPAS DE RECLUTAMIENTO,

FORMACIÓN, ESPECIALIZACIÓN Y ASCENSO.

Considero aprobado el trabajo en su totalidad.

Presentado por:

Andrea Cecilia Zorrilla Molina

C.I ,0925518235

Gonzalo Eduardo Lara Gavilánez

C. I. 0923682348

Tutor: Ing. Mary Cabanilla Burgos Msc.

Guayaquil, Marzo del 2016.

X

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERIA EN SISTEMAS

COMPUTACIONALES.

Autorización para Publicación de Tesis en Formato Digital

1. Identificación de la Tesis

Nombre Alumno: Andrea Cecilia Zorrillla Molina

Dirección: Bastión Popular Bl 1b Mz. 514 Sl.13

Teléfono: 0996627829 E-mail: andreazorrillam@gmail.com

Nombre Alumno: Gonzalo Eduardo Lara Gavilánez

Dirección: Guasmo Norte, Coop. Río Guayas Mz. 45 Sl. 12

Teléfono: 0996360665 E-mail:

goedlaragavilanez@gmail.com

Facultad: Ciencias Matemáticas y Físicas

Carrera: Ingeniería en Sistemas Computacionales

Título al que opta: Ingeniería en Sistemas Computacionales

Profesor guía: Msc. Mary Cabanilla

Título del Proyecto de Titulación:

Diseño del sistema web para la gestión de aspirantes para la “Escuela De

Formación De Oficiales y Tropa” de la Comisión de Transito del Ecuador, en

las etapas de Reclutamiento, Formación, Especialización y Ascenso.

Temas del Proyecto de Titulación:

XI

2. Autorización de Publicación de Versión Electrónica del Proyecto de

Titulación

A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a

la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de

este Proyecto de Titulación.

Publicación electrónica:

Inmediata X Después de 1 año

Firma Alumnos: Andrea Cecilia Zorrilla Molina

Gonzalo Eduardo Lara Gavilanez

3. Forma de envío:

El texto de la Tesis debe ser enviado en formato Word, como archivo .Doc.

O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif,

.jpg o .TIFF.

Documentación X

XII

ÍNDICE DE CONTENIDO

CARTA DE ACEPTACIÓN DEL TUTOR ................................................... II

DEDICATORIA ......................................................................................... IV

AGRADECIMIENTO .................................................................................. V

DECLARACIÓN EXPRESA ..................................................................... VII

ÍNDICE DE CONTENIDO ........................................................................ XII

ABREVIATURAS ................................................................................. XVIII

RESUMEN ............................................................................................. XIX

ABSTRACT ............................................................................................ XX

INTRODUCCIÓN ....................................................................................... 1

CAPÍTULO I............................................................................................... 3

EL PROBLEMA ......................................................................................... 3

PLANTEAMIENTO DEL PROBLEMA ...................................................... 3

Ubicación del Problema en un Contexto ............................................... 3

Situación Conflicto Nudos Críticos ........................................................ 6

Causas y Consecuencias del Problema ................................................. 7

Delimitación del Problema ...................................................................... 8

Formulación del Problema ..................................................................... 8

Evaluación del Problema ........................................................................ 8

Objetivos ................................................................................................ 11

Objetivo general ..................................................................................... 11

Objetivos específicos ............................................................................ 11

Alcances del problema .......................................................................... 12

RECLUTAMIENTO ............................................................................... 12

FORMACIÓN / ESPECIALIZACIÓN / ASCENSO ................................ 13

SEGURIDAD ........................................................................................ 14

Justificación e importancia ................................................................... 15

Metodología del Proyecto ..................................................................... 16

Obtención de Requerimientos. ......................................................... 16

Análisis ............................................................................................. 16

Diseño............................................................................................... 17

CAPITULO II ............................................................................................ 18

XIII

MARCO TEÓRICO .................................................................................. 18

Antecedentes del Estudio ..................................................................... 18

Fundamentación Teórica ...................................................................... 19

El proceso de software ......................................................................... 20

Modelo en cascada. ............................................................................. 20

Modelo del proceso de software ........................................................... 21

Desarrollo Evolutivo ............................................................................. 22

Ingeniería de Software basado en componentes ................................. 23

Iteración de Procesos ........................................................................... 24

Actividades del proceso de software .................................................... 26

Especificación del software .................................................................. 26

Diseño e implementación de software ................................................. 28

Validación del software ........................................................................ 32

Evolución del software ......................................................................... 33

UML (Lenguaje de Modelado Unificado) .............................................. 34

Diagrama de casos de uso ............................................................... 35

Diagrama de clases. ......................................................................... 35

Diagrama de estado. ........................................................................ 36

Diagrama de actividades .................................................................. 36

Diagrama de Secuencia de actividades ............................................ 37

Aplicaciones web .............................................................................. 37

CALIDAD DEL SOFTWARE ................................................................. 40

FUNDAMENTACIÓN LEGAL ............................................................... 42

VARIABLES DE LA INVESTIGACIÓN ................................................. 55

DEFINICIONES CONCEPTUALES ...................................................... 56

CAPÍTULO III ........................................................................................... 58

PROPUESTA TECNOLÓGICA ............................................................... 58

Análisis de Factibilidad ......................................................................... 58

Factibilidad Operacional ....................................................................... 58

Factibilidad técnica ............................................................................... 59

Factibilidad Legal ................................................................................. 60

Factibilidad Económica ........................................................................ 61

LEVANTAMIENTO DE PROCESOS .................................................... 62

Procesos actuales. ........................................................................... 63

XIV

Procesos propuestos. ....................................................................... 69

MODELOS DE ANÁLISIS .................................................................... 74

1. Diagramas de casos de uso .................................................... 74

2. Diagrama de Clases .............................................................. 163

3. Diseño de interfaz .................................................................. 166

4. Diseño de datos ..................................................................... 172

5. Diseño modular ..................................................................... 176

6. Arquitectura del sistema ........................................................ 181

7. Control de Acceso ................................................................. 182

Entregables del proyecto .................................................................... 189

CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ............................ 189

CAPÍTULO IV ......................................................................................... 190

CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO ...... 190

CONCLUSIONES Y RECOMENDACIONES ..................................... 191

CONCLUSIONES ........................................................................... 191

RECOMENDACIONES ................................................................... 192

Anexos ................................................................................................... 193

PLAN DE DESARROLLO................................................................... 194

1. Introducción .............................................................................. 194

2. Visión general del proyecto ....................................................... 196

3. Organización del Proyecto. ....................................................... 198

4. Gestión del proyecto ................................................................. 200

5. Plan del proyecto ...................................................................... 201

6. Infraestructura necesaria .......................................................... 202

CRONOGRAMA DE ACTIVIDADES .................................................. 204

BIBLIOGRAFÍA ...................................................................................... 210

Bibliografía ............................................................................................. 210

XV

INDICE DE TABLAS

Tabla 1 - Causas y Consecuencias del Problema .............................................. 7 Tabla 2 - Tabla de costos – inversión ................................................................ 61 Tabla 3 - Costos de inversión ........................................................................... 61 Tabla 4 - Usuario .............................................................................................. 76 Tabla 5 - Cosultar usuario ................................................................................ 77 Tabla 6 – Mantenimiento Usuario ...................................................................... 78 Tabla 7 - Bloquear usuario ................................................................................ 79 Tabla 8 - desbloquear usuario ........................................................................... 80 Tabla 9 - Cambiar Contraseña .......................................................................... 82 Tabla 10 - Crear parámetros ............................................................................. 84 Tabla 11 – Buscar parámetros .......................................................................... 85 Tabla 12 – Mantenimiento de parámetros ......................................................... 86 Tabla 13 – Crear módulo ................................................................................... 88 Tabla 14 - Buscar Módulos ............................................................................... 89 Tabla 15 – Mantenimiento de Módulos .............................................................. 90 Tabla 16 – Crear Roles ..................................................................................... 92 Tabla 17 - Buscar Roles ................................................................................... 93 Tabla 18 – Mantenimiento de roles ................................................................... 94 Tabla 19 – Asigna roles - usuarios ................................................................... 95 Tabla 20 – Mantenimiento Roles - Usuarios ..................................................... 96 Tabla 21 – Crear Privilegios .............................................................................. 98 Tabla 22 – Buscar Privilegios ............................................................................ 99 Tabla 23 – Asignar privilegios usuario ............................................................. 100 Tabla 24 – Mantenimiento Privilegios usuarios ................................................ 101 Tabla 25 – Asignar privilegios roles ................................................................. 102 Tabla 26 – Mantenimiento de Privilegios - rol .................................................. 103 Tabla 27 – Mantenimiento de privilegios ......................................................... 104 Tabla 28 – Crear Proceso de Formación ......................................................... 106 Tabla 29 – Buscar proceso de formación ........................................................ 107 Tabla 30 – Mantenimiento de proceso de formación ....................................... 108 Tabla 31 – Crear pruebas ................................................................................ 110 Tabla 32 - Buscar pruebas ............................................................................. 111 Tabla 33 - Mantenimiento de pruebas ............................................................ 112 Tabla 34 – Crear etapa.................................................................................... 114 Tabla 35 – Buscar etapa ................................................................................. 115 Tabla 36 – Mantenimiento etapas ................................................................... 116 Tabla 37 – Crear Requerimientos .................................................................... 118 Tabla 38 – Buscar requerimientos ................................................................... 119 Tabla 39 – Mantenimiento de requerimientos ................................................. 120 Tabla 40 - Crear convocatoria ........................................................................ 122 Tabla 41 – Buscar convocatoria ...................................................................... 123 Tabla 42 - Mantenimiento de Convocatoria .................................................... 124 Tabla 43 - Registro de pruebas ...................................................................... 126 Tabla 44 - Mantenimiento de registro de notas ............................................... 127 Tabla 45 - Registro web de aspirante ............................................................. 129 Tabla 46 - Carga de requisitos ....................................................................... 130 Tabla 47 - Buscar aspirante............................................................................ 131 Tabla 48 – Mantenimiento aspirante................................................................ 132 Tabla 49 – Califica aspirante ........................................................................... 133

XVI

Tabla 50 – Recuperar contraseña ................................................................... 134 Tabla 51 – Crear Paralelo ............................................................................... 136 Tabla 52 – Buscar paralelo .............................................................................. 137 Tabla 53 – Mantenimiento paralelo ................................................................. 138 Tabla 54 – Crear docente ................................................................................ 140 Tabla 55 – Buscar docente .............................................................................. 141 Tabla 56 – Mantenimiento docente ................................................................. 142 Tabla 57 – Registra estudiante ....................................................................... 144 Tabla 58 – Buscar Estudiante.......................................................................... 145 Tabla 59 – Mantenimiento estudiante .............................................................. 146 Tabla 60 - Crear materia ................................................................................ 148 Tabla 61 – Buscar Materia .............................................................................. 149 Tabla 62 – Mantenimiento de materia ............................................................. 150 Tabla 63 – Crear malla .................................................................................... 152 Tabla 64 – Buscar malla .................................................................................. 153 Tabla 65 – Mantenimiento malla ...................................................................... 154 Tabla 66 – Registro de notas........................................................................... 156 Tabla 67 - Consulta de notas.......................................................................... 157 Tabla 68 - Mantenimiento de notas ................................................................ 158 Tabla 69 – Genera actas ................................................................................. 159 Tabla 70 – Consulta de reportes ..................................................................... 161 Tabla 71 – Generar reportes ........................................................................... 162 Tabla 72 - Control de acceso: Académico ....................................................... 182 Tabla 73 - Control de Acceso: Académico (2) ................................................. 183 Tabla 74 - Control de Acceso: Reportes .......................................................... 184 Tabla 75 - Control de Acceso: Convocatoria (1) .............................................. 185 Tabla 76 - Control de Acceso: Convocatoria (2) .............................................. 186 Tabla 77 - Control de Acceso: Administración (1) ............................................ 187 Tabla 78 - Control de Acceso: Administración (2) ............................................ 188 Tabla 79 – Organización del proyecto ............................................................. 198 Tabla 80 – Gestión del proyecto ...................................................................... 200 Tabla 81 – Fases ............................................................................................. 201 Tabla 82 - Descripción de fases ..................................................................... 201 Tabla 83 – Infraestructura ............................................................................... 203

XVII

ÍNDICE DE IMÁGENES

Imagen 1 - Modelo de cascada de desarrollo de software ................................. 21 Imagen 2 - Modelo de desarrollo de software Evolutivo .................................... 22 Imagen 3 - Ingeniería de Software basado en componentes ............................. 24 Imagen 4 - Entrega Incremental ........................................................................ 25 Imagen 5 - Modelo espiral ................................................................................ 26 Imagen 6 - Ingeniería de Requerimientos ......................................................... 28 Imagen 7 - Actividades de Diseño ..................................................................... 30 Imagen 8 Flujo del proceso de convocatoria - Actual ........................................ 63 Imagen 9 - Flujo de proceso de reclutamiento ................................................... 64 Imagen 10 Flujo de proceso de Formación ...................................................... 65 Imagen 11 Flujo de Proceso de Especialización ............................................... 66 Imagen 12 Flujo de proceso de Ascenso .......................................................... 67 Imagen 13 Flujo de proceso Convocatoria - Propuesto ..................................... 69 Imagen 14 Flujo de Proceso Reclutamiento - Propuesto ................................... 70 Imagen 15 Flujo de proceso Formación- Propuesto .......................................... 71 Imagen 16 Flujo de proceso Especialización - Propuesto ................................ 72 Imagen 17 Flujo de proceso Ascenso - Propuesto ............................................ 73 Imagen 18 - (Caso de uso - Sistema Integrado EFOT)...................................... 74 Imagen 19 - (Caso de uso - Usuarios) ............................................................... 75 Imagen 20 - (Caso de uso – cambiar contraseña) ............................................. 81 Imagen 21 - (Caso de uso – Parámetros).......................................................... 83 Imagen 22-(Casos de uso - Módulos) ............................................................... 87 Imagen 23 - (Caso de uso - Roles).................................................................... 91 Imagen 24 - (Caso de uso - Privilegios) ............................................................ 97 Imagen 25 - (Caso de uso – Proceso de formación) ....................................... 105 Imagen 26 - (Caso de uso - Pruebas) ............................................................. 109 Imagen 27 - (Caso de uso - Etapas) ................................................................ 113 Imagen 28 - (Caso de uso – requerimientos) .................................................. 117 Imagen 29- (Caso de uso – convocatoria) ....................................................... 121 Imagen 30- (Caso de uso – Evaluaciones) ...................................................... 125 Imagen 31- (Caso de uso – Aspirante) ............................................................ 128 Imagen 32- (Caso de uso – Paralelo) .............................................................. 135 Imagen 33- (Caso de uso – Docente) .............................................................. 139 Imagen 34- (Caso de uso – Estudiante) .......................................................... 143 Imagen 35- (Caso de uso – Materia) ............................................................... 147 Imagen 36- (Caso de uso – Malla) .................................................................. 151 Imagen 37- (Caso de uso – Notas) ................................................................. 155 Imagen 38- (Caso de uso – Reportes) ............................................................ 160 Imagen 39 - Diagrama de Clases: Académico ............................................... 163 Imagen 40 - Diagrama de Clases: Convocatorias .......................................... 164 Imagen 41 - Diagrama de Clases: Seguridad .................................................. 165 Imagen 42 - Pantalla Principal......................................................................... 166 Imagen 43 - Menú principal ............................................................................ 167 Imagen 44 – Inicio de sesión ........................................................................... 168 Imagen 45 – Convocatorias ............................................................................ 169 Imagen 46 - Registro de aspirantes................................................................. 170 Imagen 47 – Nuevo Usuario ............................................................................ 171 Imagen 48 - Modelo Entidad Relación (Global) ............................................... 172

XVIII

Imagen 49 - Modelo Entidad Relación (Seguridad) ......................................... 173 Imagen 50 - Modelo Entidad Relación: Convocatorias .................................... 174 Imagen 51 - Modelo Entidad Relación: Académico ......................................... 175 Imagen 52 - Módulos – Visión General ........................................................... 176 Imagen 53 - Módulo Administración ................................................................ 177 Imagen 54 - Módulo convocatorias ................................................................. 178 Imagen 55 - Módulo académico ...................................................................... 179 Imagen 56 - Módulo Reportes ......................................................................... 180 Imagen 57 - Arquitectura del sistema .............................................................. 181 Imagen 58 - Calendario ................................................................................... 202 Imagen 59 – Cronograma 1 ............................................................................ 204 Imagen 60 – Cronograma 2 ............................................................................ 205 Imagen 61 – Cronograma 3 ............................................................................ 206 Imagen 62 – Cronograma 4 ............................................................................ 207 Imagen 63 – Cronograma 5 ............................................................................ 208 Imagen 64 – Cronograma 6 ............................................................................ 209

ABREVIATURAS

ABP Aprendizaje Basado en Problemas

UG Universidad de Guayaquil

FTP Archivos de Transferencia

g.l. Grados de Libertad

Html Lenguaje de Marca de salida de Hyper Texto

http Protocolo de transferencia de Hyper Texto

Ing. Ingeniero

CC.MM.FF Facultad de Ciencias Matemáticas y Físicas

ISP Proveedor de Servicio de Internet

Mtra. Maestra

Msc. Master

URL Localizador de Fuente Uniforme

www world wide web (red mundial)

XIX

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

“DISEÑO DEL SISTEMA WEB PARA LA GESTIÓN DE ASPIRANTES PARA LA “ESCUELA DE FORMACIÓN

DE OFICIALES Y TROPA” DE LA COMISIÓN DE TRANSITO DEL ECUADOR, EN LAS ETAPAS

DE RECLUTAMIENTO, FORMACIÓN, ESPECIALIZACIÓN Y ASCENSO”

Autor: Andrea Zorrilla Molina Gonzalo Lara Gavilanez

Tutor: Ing. Mary Cabanilla Msc.

RESUMEN

El presente trabajo de titulación tiene como objetivo diseñar los modelos correctos, completos, concretos y sin ambigüedades de lo que sería el sistema web para la gestión de aspirantes para la Escuela de Formación de Oficiales y Tropa de la Comisión de Tránsito del Ecuador, siguiendo el paradigma de desarrollo de software orientado a objetos ya que, actualmente, todos los procesos de la institución se hacen manualmente o con el apoyo básico de programas ofimáticos, lo que causa diversos tipos de problemas en términos de seguridad y disponibilidad de la información. Estos modelos servirán para que, en un posterior proyecto, el equipo de desarrollo de software pueda tomar los diagramas diseñados y construir el sistema en base a la información que se presenta en este documento. Los beneficiarios de este trabajo serán, principalmente, la Escuela de Formación de Oficiales y Tropa de la Comisión de Tránsito del Ecuador ya que no tendrá que invertir en un estudio previo al desarrollo del sistema y, posterior a la implementación, el personal administrativo y los mismos aspirantes ya que toda la interacción con la institución se realizará a través del sistema, mejorando su productividad y la seguridad de la información. Para el desarrollo del trabajo se realizaron visitas en las instalaciones de la escuela donde se desarrollaron reuniones de trabajo con los diferentes niveles administrativos y de dirección de la institución para obtener la información adecuada e identificar las necesidades que debe cumplir el sistema. El sistema propuesto abarca los procesos de reclutamiento, formación, especialización y ascenso del personal que ingresa a la EFOT. Como principal resultado destacamos los modelos desarrollados en lenguaje UML mediante los cuales se representan todos los aspectos del sistema en cuanto a su estructura y funcionamiento, que han sido desarrollados siguiendo los estándares del lenguaje de modelado mencionado.

XX

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

"WEB DESIGN MANAGEMENT SYSTEM FOR CANDIDATES

TO THE “TRAINING SCHOOL RANKS” TRANSIT

COMMISSION OF ECUADOR, IN STAGES OF

RECRUITMENT, TRAINING,EXPERTISE

AND PROMOTION"

Autor: Andrea Zorrilla Molina Gonzalo Lara Gavilanez

Tutor: Ing. Mary Cabanilla Msc.

ABSTRACT The project assist aims to design degree correct, complete, specific and unambiguous what would be the web management system for candidates for the Training School ranks of the Transit Commission of Ecuador models, following the software development paradigm of object-oriented because, currently, all processes of the institution do manually or with basic office software support, causing various types of problems in terms of security and availability of information. These models can be assist in a subsequent project, the software development team can make diagrams designed and build the system based on the information presented here in. The beneficiaries are Training School ranks of the Transit Commission of Ecuador does not longer have to invest in a previous study system development and post-implementation, administrative staff and Applicants same as all interaction with the institution will be made through the system, improving its productivity and information security. For development work visits were made to the school premises where meetings took place with the various administrative levels and address of the institution to obtain adequate information and identify the needs to be met by the system. The proposed system covers recruitment, training, specialization and promotion of staff entering the Efot. The main result UML models developed in language by which represent all aspects of the system in terms of its structure and operations, which have been developed following the standards mentioned include modeling language

Keywords: UML, management aspirants Transit Commission of Ecuador

1

INTRODUCCIÓN

La Comisión de Tránsito del Ecuador es una institución pública amparada en la

Constitución y Leyes de la República la cual tiene como misión “dirigir y controlar

la actividad operativa de los servicios de transporte terrestre, tránsito y seguridad

vial, en la red vial estatal y sus troncales nacionales y demás circunscripciones

territoriales que le fueren delegadas por los Gobiernos Autónomos

Descentralizados, con sujeción a las regulaciones emanadas por la ANT, la

investigación de accidentes de tránsito y la formación del Cuerpo de Vigilantes y

de Agentes Civiles de Tránsito”.

Para cumplir con su misión, la institución forma a su personal uniformado de

manera profesional en cuanto a las áreas científicas, jurídicas, de investigación de

accidentes de tránsito, movilidad, seguridad vial, etc. para brindar un servicio

eficiente a la ciudadanía.

Para la formación profesional de Agentes de Tránsito, la Comisión de Tránsito del

Ecuador cuenta con la Escuela de Formación de Oficiales y Tropa (EFOT),

ubicada en la avenida de las Américas al lado de la terminal terrestre de

Guayaquil.

La misión de la EFOT es de “Formar y capacitar agentes de tránsito con las

habilidades científicas, técnicas y humanísticas, con personal profesional en

materias en tránsito y transporte terrestre, para garantizar la seguridad vial y

movilidad sostenible”. Lo que permite contar con el personal altamente capacitado

para cumplir las tareas encomendadas por las leyes de la república.

Para ingresar a la Comisión de Tránsito del Ecuador, los aspirantes deben pasar

por el procesos de selección y aprobar los cursos de formación que la institución

pone a disposición de la juventud ecuatoriana, según los planes operativos de la

institución y de acuerdo a las necesidades de personal que se van dando en el

transcurso de los años a través de la escuela de Formación de Oficiales y Tropa.

2

Esta formación está definida por el programa de estudios aprobada para dicho

propósito.

La Comisión de Tránsito cuenta con diferentes áreas en las cuales los uniformados

con las aptitudes necesarias pueden especializarse en cada una de ellas, si

cumplen con los requisitos previamente establecidos según las normas y políticas

de la institución.

Las áreas en las que los uniformados se pueden especializar son:

- UREM (Unidad de Rescate y Emergencias Médicas.)

- UCTP (Unidad de Control de Transporte Público.)

- OIAT (Oficina de Investigación de Accidentes de tránsito)

Para ascender al grado inmediato superior, los agentes de tránsito deben realizar

los cursos de ascenso de acuerdo al tiempo de servicio en el grado ya sea oficiales

o tropa.

3

CAPÍTULO I EL PROBLEMA

PLANTEAMIENTO DEL PROBLEMA Ubicación del Problema en un Contexto

La Comisión de Tránsito del Ecuador posee la Escuela de Formación de Oficiales

y Tropa, en la cual se realizan cursos para formar los nuevos agentes de tránsito,

cursos de ascenso, capacitación y especialización según las necesidades

institucionales existentes.

De acuerdo a la cantidad de cursantes la EFOT cuenta con un establecimiento

anexo ubicado en el Km. 10 ½ vía a Daule, el mismo que está regido, regulado y

controlado por las autoridades de la EFOT.

La problemática se da al momento en que la institución pone a disposición de la

ciudadanía el llamamiento a cursos de formación, sea este para oficiales o tropa,

ya que los interesados deben registrarse en la página web institucional, a través

de un formulario de ingreso de datos que es básico, para luego reunir la

documentación solicitada, la misma que deberá ser enviada a través de una

compañía de servicio de correos que la institución designe.

El departamento de selección tiene la responsabilidad de recibir los documentos

de manera física, los cuales son revisados y verificados, de tal forma que se

procede a rechazar o aceptar las carpetas, cabe recalcar que en la actualidad no

se hace ningún comparativo entre la documentación enviada y la información

ingresada durante el registro previo en la página web institucional. En los casos

que la documentación está incompleta, se envía un correo electrónico al

postulante indicándole que documento hace falta, el cual puede enviarlo en un

plazo establecido por la institución a través de la misma compañía de servicios de

correo establecida y podrá continuar con el proceso normal.

4

Con la documentación de las carpetas aprobadas por el departamento de

selección se crea una hoja de cálculo (Excel). Con este listado se da inicio a las

pruebas establecidas por la institución, en dicho listado se procede a registrar

manualmente las calificaciones obtenidas por los postulantes en cada una de las

pruebas que deben ser evaluados, las mismas que son:

Prueba psicológica

Ficha medica

Prueba física

Entrevista personal

En los últimos procesos de selección para la prueba psicológica, ficha médica y

prueba física se han realizado convenios con otras instituciones como FFAA y FAE

para que evalúen a los postulantes de acuerdo a los parámetros establecidos en

el convenio interinstitucional con la Comisión de Tránsito del Ecuador. Las

instituciones mencionadas proceden a enviar los resultados por medio físico

plasmado en un documento firmado por el responsable de dicha evaluación

además, se envía por medio magnético un archivo Excel. Con estos documentos,

el departamento de selección procede a actualizar la hoja de cálculo que maneja

y notificar a los postulantes a través de la página web institucional los resultados

obtenidos.

Si el resultado obtenido por el aspirante es de aprobación se le notifica fecha, hora

y lugar para la siguiente prueba o proceso que deberá desarrollar.

Finalmente, la entrevista personal es realizada por los directivos civiles y

uniformados de la CTE, en las instalaciones de la EFOT con el objetivo de evaluar,

en última instancia, la idoneidad de los aspirantes a integrar las filas de la CTE.

5

Para la formación, Capacitación, Especialización y Ascensos, la Escuela de

Formación de Oficiales y Tropa consta con varios departamentos para un

funcionamiento óptimo, los cuales son:

Departamento de personal

Departamento de Evaluación

Departamento de Planificación y estudios

Departamento de Cultura Física y Deportes

Una vez que los postulantes culminaron y aprobaron el proceso de selección se

acuartelan en la EFOT, iniciando así los estudios teórico - práctico según la malla

curricular correspondiente al curso establecido ya sea este para oficial o tropa,

coordinado por el Departamento de Planificación y Estudios.

La política de calificación actual establecido por el Departamento de Evaluación

para los cursos de formación, Capacitación, Especialización y Ascensos, es sobre

20 puntos, divididos en 7 puntos académicos (asistencia, actuaciones en clase,

deberes, aportes, etc.) y 13 puntos correspondientes a una evaluación objetiva.

Cada uno de los catedráticos, una vez culminadas sus horas asignadas, entregan

al Departamento de Evaluación el reporte de notas por medio de un documento

con su firma de responsabilidad.

Todos los procesos descritos anteriormente son manuales por lo que pueden

tomar mucho tiempo y existe una gran probabilidad de que las personas que

actualizan el archivo electrónico puedan cometer errores de digitación o que

trabajen con archivos desactualizados causando problemas en cuanto a la

idoneidad de la información contenida y publicada.

Tomando en cuenta que la Comisión de Tránsito del Ecuador se ha caracterizado

por estar a la par con los avances tecnológicos, se presenta la propuesta para

realizar el diseño de un sistema informático adecuado para gestionar de manera

eficiente la información de estos cursos de formación,, actualización, ascenso y

especialización que desarrolla la EFOT.

6

Situación Conflicto Nudos Críticos

Todos los procesos de inscripción, registro de notas y todo lo relacionado a los

cursos de formación, profesionalización, ascenso, etc. son realizados por el

personal administrativo utilizando formularios impresos y la ayuda de las

herramientas ofimáticas básicas (hojas de cálculo, procesadores de texto) y son

almacenados en archivos digitales en el computador de cada uno de los

funcionarios designados para los procesos mencionados. La falta de un sistema

informático produce que, cuando las autoridades de la institución requieran cierta

información acerca de los procesos educativos de los cursos que están

desarrollándose o de los anteriores, los funcionarios deben comenzar a buscar

archivo por archivo para poder recopilar la información.

En el proceso de Reclutamiento de Aspirantes, uno de los nudos críticos que

afecta a la institución es el registro de la documentación del personal que aspira a

formar parte de la Comisión de Tránsito del Ecuador, ya que el Departamento de

Personal archiva las carpetas con todos los documentos que son entregadas por

las empresas de correos, a través de las cuales se hacen llegar toda la

documentación, pero no existe un lugar adecuado para almacenar la gran cantidad

de archivos existentes, por lo que después de ser registrados en una hoja de

cálculo son almacenados en lugares improvisados en los que pueden deteriorarse

muchos documentos.

Otro nudo crítico es la falta de una base de datos que registre la información básica

de los postulantes, notas de evaluaciones, conducta, etc. Con la cual se permitiría

una consulta histórica de los postulantes, toda esta información se conserva en la

hoja de cálculo en el equipo informático del funcionario que realiza la actividad de

mantenimiento y con el tiempo pueden ser eliminados ya que no existe una política

de respaldo de dicha información.

7

Causas y Consecuencias del Problema

Tabla 1 - Causas y Consecuencias del Problema

Causas Consecuencias

Verificación deficiente de la

documentación recibida por parte de

los postulantes.

Luego de la inscripción en la página web

institucional, los datos ingresados no son

comparados con la documentación recibida a

través de la empresa de correos.

En el momento de presentarse

inconsistencias puede ocasionar que se

extienda el tiempo del proceso de revisión de

carpetas generando insatisfacción por parte

de los postulantes.

Registro manual de datos de los

postulantes.

El ingreso de datos de forma manual de la

gran cantidad de carpetas, puede ocasionar

errores involuntarios por parte de los

digitadores esto posteriormente genera

inconsistencias.

Pone al descubierto una mala administración

de datos, por eso es necesaria la

automatización de los procesos.

Gran cantidad de documentación

física.

Almacenar la gran cantidad de carpetas en

bodegas o áreas improvisadas para el efecto

sin una seguridad adecuada.

La información personal de los postulantes

estaría expuesta a personas no autorizadas,

sus documentos se podrían traspapelar,

deteriorarse o ser hurtados.

Autor: Investigadores Fuente: Desarrollo de la investigación

8

Delimitación del Problema

El proyecto se limita al diseño del Sistema Web para la gestión de la información

en las etapas de reclutamiento, formación, especialización y ascensos de la

Escuela de Formación de Oficiales y Tropa de la CTE.

Campo: Gestión de Información

Área: Sistemas.

Aspecto: Ingeniería de Software

Tema: “DISEÑO DEL SISTEMA WEB PARA LA GESTIÓN DE ASPIRANTES

PARA LA “ESCUELA DE FORMACION DE OFICIALES Y TROPA” DE LA

COMISION DE TRANSITO DEL ECUADOR, EN LAS ETAPAS DE

RECLUTAMIENTO, FORMACIÓN, ESPECIALIZACIÓN Y ASCENSO”.

Formulación del Problema

¿Si desarrollamos los modelos de software correcto, completo y consistente de un

sistema web para la administración de los procesos de reclutamiento, formación y

ascenso del personal en la Escuela de Formación de Oficiales y Tropa permitirá

ofrecer los diseños adecuados para una implementación efectiva?

Evaluación del Problema

Para el presente trabajo de titulación de acuerdo al problema planteado, vamos a

evaluar los siguientes aspectos:

Delimitado: El problema planteado se limita al diseño de la aplicación informática

que permitirá la gestión de la información de los aspirantes a integrar las filas de

la Comisión de Tránsito del Ecuador así como la de los miembros de la institución

que deben someterse a los diferentes cursos de ascenso y/o especialización que

realizan a lo largo de su carrera profesional dentro de la institución.

9

Claro: El diseño de la aplicación desarrollará todos los modelos definidos por la

Ingeniería de Software en cuanto a las etapas de Ingeniería de Requerimientos,

Análisis y Diseño que corresponden a las primeras fases del proceso de software.

Evidente: Con el mantenimiento de un archivo digital y al no tener las políticas de

almacenamiento, conservación y/o respaldo de la información de los aspirantes y

miembros de la institución que se someten a los diferentes cursos, se vuelve

evidente la necesidad de contar con un sistema adecuado para la gestión de dicha

información y, para llegar a dicho sistema, se debe realizar el modelado del

sistema considerando todos los aspectos o necesidades de la Escuela de

Formación.

Concreto: El proyecto se limita a desarrollar los modelos necesarios siguiendo

una metodología de desarrollo de software en sus primeras etapas, con la finalidad

de que sirva como insumo a los futuros desarrolladores del sistema informático y

que sirva como una guía detallada en el proceso de desarrollo, implementación y

pruebas que deberá realizarse posterior a la conclusión del presente trabajo de

titulación.

Relevante: El diseño y posterior implementación de un sistema web para la

gestión de la información de los aspirantes y miembros de la Comisión de Tránsito

del Ecuador que realizan los cursos, resulta de una gran importancia ya que toda

la información estará respaldada en una plataforma de base de datos,

administrada por personal capacitado y tendrá políticas de preservación y

respaldo adecuadas con la finalidad de mantener toda la información para los

casos que sean necesarios.

Original: El desarrollo del presente trabajo de titulación supone la investigación

de herramientas de modelado y desarrollo de aplicaciones web acordes al

desarrollo tecnológico actual y que tenga la capacidad de poder mantenerse en

funcionamiento correcto durante varios años, permitiendo la escalabilidad y la

flexibilidad adecuada en caso de cambios estructurales o legales que se den en

el transcurso del tiempo.

10

Contextual: el presente trabajo de titulación esta contextualizado ya que se

enfoca exclusivamente a las primeras etapas del proceso de software donde se

realiza el análisis y diseño de la solución que se presenta como propuesta para

resolver el problema planteado. Se contextualiza al recurrir a las metodologías de

desarrollo de sistemas informáticas descritas en la Ingeniería de software.

Factible: El proyecto presentado en el trabajo de titulación es factible ya que,

aplicando la metodología de desarrollo de software, en el transcurso del tiempo

del proyecto se ejecutan las primeras etapas denominadas, Obtención de

requerimientos, también conocida como Ingeniería de Requerimientos, el análisis

y el diseño de la solución propuesta. El análisis y diseño corresponden a la

representación a través de modelos descriptivos de software que posteriormente

serán implementados en un lenguaje de programación definido.

Productos esperados: Al finalizar el trabajo de titulación se presentará como

resultado los documentos de definición de requerimientos, el documento de

análisis que contendrá todo el desarrollo analítico de la información obtenida y el

documento de diseño de la aplicación propuesta que podrá ser trasladado

posteriormente a un lenguaje de programación( codificación) para su ejecución

posterior.

Variables: En el desarrollo del presente trabajo se analizarán las siguientes

variables.

Independiente: Procesos de reclutamiento, formación, capacitación y ascenso del

personal de la CTE, organizados por la EFOT

Dependiente

Análisis y diseño de un sistema web para la gestión de los procesos de

reclutamiento, formación, capacitación y ascenso del personal de la CTE,

organizados por la EFOT

11

Objetivos

Objetivo general

Desarrollar los modelos de software, para la aplicación web, en base al

levantamiento de información de las diferentes áreas, con el fin de automatizar los

procesos de la Escuela de Formación de Oficiales y Tropa de la Comisión de

Tránsito del Ecuador, en las etapas de reclutamiento, formación, especialización

y ascenso.

Objetivos específicos

Identificar los requerimientos levantando los procesos de reclutamiento

y formación de aspirantes, en la Escuela de Formación de Oficiales y

Tropa de la Comisión de Tránsito del Ecuador para diseñar el sistema

web.

Elaborar el diseño de la aplicación Web utilizando la notación UML para

automatizar los procesos levantados.

Validación del diseño de la aplicación Web con los usuarios para

garantizar que la aplicación cumpla con los requerimientos de los

procesos levantados.

Elaborar el plan de desarrollo que permita dimensionar los costos y

recursos necesarios para la implementación del producto en la CTE.

12

Alcances del problema

1. Realizar el levantamiento de información con el personal administrativo que

manejan los procesos de reclutamiento, formación, especialización y ascenso

de la Escuela de Formación de Oficiales y tropa para identificar los

requerimientos funcionales y no funcionales del sistema web que se propone

Se desarrollará el documento de especificación de requerimientos

ordenados y priorizados en base a la información obtenida siguiendo

una metodología de desarrollo de software.

Para obtener la información se ejecutarán encuestas, entrevistas,

visitas a las oficinas administrativas, observación, etc.

2. Desarrollar el modelo de análisis y diseño de la aplicación donde consten todos

los diagramas que sean pertinentes en base a la metodología de desarrollo de

software y documentarlos de manera detallada y que deberá contener, en

primera instancia, por lo menos los siguientes elementos:

RECLUTAMIENTO

1. Iniciar del Proceso de inscripción.

a. Ingreso de datos para el proceso.

b. Carga documentación digital.

c. Definir estándar para aprobar la inscripción de un aspirante.

2. Aprobar inscripción del aspirante.

a. Asignación aleatoria de fechas para realizar la pruebas.

b. Asignación aleatoria de lugares para realizar las pruebas.

c. Asignación aleatoria de fecha para realizar entrevista

3. Configurar métricas para cada prueba.

a. Definir mínimo de aprobación según el tipo de pruebas.

b. Definir un perfil personal, según las normas de la institución.

4. Reportes

a. Generar reportes de calificaciones

b. Generar reportes de avances en proceso.

13

FORMACIÓN / ESPECIALIZACIÓN / ASCENSO

5. Asignación de instructores

a. Registro en la base de datos de los instructores asignados para los

diferentes tipos de cursos de formación especialización o ascenso.

b. Permitir la actualización de datos de los instructores.

c. Asignación de docentes que impartirán las materias establecidas

para el respectivo curso de formación especialización o ascenso.

d. Definir el rango de ponderación para aprobar las diversas pruebas

en las que serán evaluados los postulantes.

e. Generar los diferentes tipos de reporte según los requerimientos.

6. Definir las mallas curriculares para los diferentes tipos de cursos de

formación.

a. Crear las materias que serán impartidas durante el periodo de

formación.

b. Permitir Anular materias de acuerdo a requerimientos.

c. Permitir actualizar materias de acuerdo a requerimientos.

7. Determinar los paralelos.

a. Configuración de cursos según la cantidad de estudiantes.

b. Asignación de estudiantes para cada paralelo de acuerdo al código

establecido por la EFOT.

c. Asignación de docentes.

d. Asignación de horario para cada paralelo.

e. Control de asistencia.

f. Registro de notas directamente al sistema.

g. Generar Reporte de notas según los requerimientos.

8. Definir Horarios de acuerdo a las necesidades del curso formación,

especialización o ascenso.

a. Crear de horarios de cada paralelo.

b. Permitir actualización de horarios de los paralelos según los

requerimientos.

c. Permitir eliminar horarios de los paralelos según los

requerimientos.

d. Distribución del horario / curso.

14

SEGURIDAD

a. Configurar los diferentes tipos de roles, para controlar el acceso al

sistema.

b. Asignar roles según el rango o responsabilidad de los instructores.

c. Modificar roles de instructores según los requerimientos.

d. Eliminar roles de instructores según los requerimientos.

e. Crear usuarios para acceder al sistema.

f. Modificar usuarios para acceder al sistema.

g. Eliminar usuarios para acceder al sistema.

h. Crear Módulos para los cursos de formación especialización o

ascenso, que van a realizar.

i. Modificar Módulos en caso de ser necesario para los cursos de

formación especialización o ascenso.

j. Eliminar Módulos en caso de ser necesario para los cursos de

formación especialización o ascenso.

k. Asignar Usuarios por Módulos según los requerimientos.

l. Modificar Usuarios por Módulos en caso de ser necesario.

m. Eliminar Usuarios por Módulos en caso de ser necesario.

n. Asignar Roles por Módulos.

o. Modificar Roles por Módulos.

p. Eliminar Roles por Módulos.

3. Desarrollar los documentos de validación y verificación del software donde se

identifique los escenarios de prueba necesarios para asegurar que, una vez

que hayan desarrollado la aplicación, se ejecute el proceso de verificación que

acredite el correcto funcionamiento del sistema en términos de funcionalidad

y calidad del mismo.

Se identifica los controles que se debe realizar previo a la puesta en

producción de la aplicación para un correcto funcionamiento.

15

Justificación e importancia La Comisión de Tránsito del Ecuador a través de la Escuela de Formación de

Oficiales y Tropa forma de manera profesional a los elementos uniformados de la

institución. En primera instancia para poder acceder al grado de “Vigilantes de

tránsito” en el caso del personal de tropa, o “Subteniente” en el caso de oficiales,

deben aprobar el curso de formación para el cual se hace un llamamiento público

a todos los jóvenes interesados en pertenecer a las filas de la institución. Para

registrar los datos de los aspirantes, se realiza un proceso de “Reclutamiento” a

través de la web por medio de un formulario básico en el cual los interesados

registran toda la información solicitada por la institución y, posteriormente los

funcionarios de la escuela de formación, descarga los datos en un archivo digital

que es gestionado por un programa de hoja de cálculo en sus computadores.

Durante el proceso de pruebas y calificaciones el personal administrativo realiza

las actualizaciones correspondientes sobre este archivo digital por lo cual se

vuelve muy sensible a alteraciones de diferente índole y puede, inclusive,

desaparecer si el computador donde se encuentra la información llega a dañarse

ya que la institución no cuenta con políticas de respaldo de los documentos que

almacenas las computadoras.

Se vuelve imprescindible mantener una administración adecuada de la

información que es suministrada por los interesados ya que en cada uno de los

llamados públicos que hace la institución han ido aumentando la cantidad de

aspirantes que quieren acceder a formar parte de las filas de la CTE y los mismos

provienen de todos los rincones del Ecuador, esto último promovido, entre otras

cosas, por el alcance que tiene actualmente la institución en cuanto a sus

competencias en materia de tránsito y seguridad vial en todo el país.

Siendo una institución uniformada histórica en la provincia del Guayas y al tener

la competencia del tránsito y seguridad vial a nivel nacional, los tiempos modernos

y el avance de la tecnología, entre ellas la informática, exige a la institución que

se modernice y que sus procesos que actualmente los realiza de manera manual

se vayan realizando apoyándose en la tecnología, con lo que se contribuirá a

obtener resultados adecuados de manera eficiente. Los sistemas informáticos

ayudan a las instituciones a realizar sus actividades de manera eficiente

16

Metodología del Proyecto

En el presente trabajo de titulación se ha seguido el paradigma de desarrollo de

software orientado a objetos por lo que se han seguido las etapas del proceso de

software que ha permitido obtener la información adecuada y plasmar dicha

información en modelos concretos representados en lenguaje de modelado

unificado (UML) en los diferentes aspectos del sistema como lo son su estructura

y comportamiento correspondiente.

Para desarrollar este trabajo se siguieron las etapas que siguen:

Obtención de Requerimientos.

Esta primera etapa fue desarrollada con la colaboración del personal uniformado

y civil que labora en la Escuela de Formación de Oficiales y Tropa que están

designados a realizar todos los procesos administrativos que tienen que ver con

los cursos de formación, ascenso y profesionalización que realiza la escuela.

Durante esta etapa se realizaron las entrevistas al personal involucrado en los

procesos mencionados y se obtuvo la información precisa acerca de las

características que debería cumplir el sistema propuesto así como el

funcionamiento que debe tener en cada uno de los escenarios que se presenten.

También se realizaron visitas a cada uno de los funcionarios que ejecutan las

actividades relacionadas a los procesos de formación, especialización y ascenso

para observar las actividades que ellos realizan en cada etapa. Estas actividades

nos dieron como resultado un listado de requerimientos que el sistema debe

cumplir, brindando la base para realizar los modelos de software

correspondientes.

Análisis

Durante la etapa de análisis se desarrollaron los modelos de software utilizando

el Lenguaje de Modelado Unificado (UML) en base a la información obtenida

previamente. Los diagramas UML desarrollados presenta el sistema visualizado

en los tres aspectos básicos o vistas que son:

17

Vista de Usuario: Son todas las funciones o acciones que el usuario espera

poder realizar con el apoyo del sistema informático. Es una descripción de

lo que el usuario espera realizar con el sistema y está representado con el

diagrama de casos de uso y su descripción correspondiente.

Vista de su estructura: Presenta los elementos del sistema y sus relaciones

correspondientes. En esta vista de UML se obtiene cada componente en

términos de clases y las relaciones de herencia, asociación, agregación que

forman parte del sistema. Cada elemento del sistema, sus atributos y

comportamiento correspondiente son representados a través del diagrama

de clases.

Vista de su comportamiento: En esta vista se representa la parte dinámica

del sistema en cuanto a las actividades que deberá desarrollar de acuerdo

a los casos de uso definidos en las etapas previas. En esta vista se define

las acciones o el comportamiento del sistema ante entradas de datos

específicas.

Diseño

En esta etapa se definió la correspondencia entre el hardware y software

necesario para que el sistema pueda funcionar de manera correcta por lo que se

definió los siguientes elementos:

Arquitectura del sistema

Descomposición modular

Diseño de datos

Diseño de la interfaz

La política de control de acceso

18

CAPITULO II

MARCO TEÓRICO

Antecedentes del Estudio

Con la aparición y posterior auge de la computación desde la década de los 50 se

han venido desarrollando equipos con una capacidad de procesamiento

impresionante, que hacen que los dispositivos electrónicos o digitales aprovechen

su capacidad al máximo. Los sistemas informáticos son programas que contienen

sentencias o instrucciones que, al ejecutarlos, ordena a los dispositivos a realizar

un sin número de tareas matemáticas, lógicas, de almacenamiento, etc.

Los programas que se desarrollan para que controlen los dispositivos electrónicos

o computadoras, ya sean estos personales o corporativos (servidores) se

clasifican en programas de base y de aplicación. Los programas base son aquellos

programas que le proveen de la plataforma necesaria a los programas de

aplicación para que puedan ejecutarse, denominados generalmente “sistemas

operativos”. Los programas de aplicación son aquellos que fueron desarrollados

para realizar una tarea o actividad específica de un área de la institución que lo

requiere. Entre los programas de aplicación podríamos citar algunos como por

ejemplo sistemas financieros, bancarios, contables, de gestión de personal, de

nómina, de ventas, etc.

En los primeros periodos de la computación se debía tomar una consideración

muy especial al hardware o dispositivos electrónicos con el cual contaba el

computador y sobre esa base construir los sistemas informáticos. Posteriormente,

al pasar de los años y la evolución de los componentes físicos del computador, la

plataforma de hardware ya no es un impedimento para poder construir programas

altamente eficientes ya que los dispositivos electrónicos y digitales de la época

pueden realizar muchas tareas en una pequeña cantidad de tiempo, ejecutando

una gran cantidad de transacciones de manera eficiente.

19

Para el desarrollo de software se deben seguir algunos pasos necesarios para,

entender el negocio, realizar un bosquejo de la solución planteada, presentar el

diseño de dicha solución y, posteriormente programar las instrucciones necesarias

para que esta solución pueda ser ejecutada y utilizada. A este grupo de pasos que

se debe seguir se la denomina “proceso de software” y, para desarrollar sistemas

informáticos necesariamente deben ejecutar los pasos necesarios.

Fundamentación Teórica

El software son todas las instrucciones escritas por un ser humado en un lenguaje

de programación y que pueden ser ejecutadas por el procesador de un

computador o dispositivo electrónico o digital (PC, laptop, dispositivo móvil),

denominados habitualmente “programas”, toda la documentación relacionada y

la configuración de los datos necesarios para su correcto funcionamiento

(Sommerville, 2005). Estas instrucciones están almacenadas en la memoria del

dispositivo y pueden ser ejecutadas en el momento en que el usuario lo solicite, lo

que provoca que los dispositivos realicen las actividades que se definieron.

Según (Sommerville, 2005, pág. 21) la Ingeniería de software es “es una disciplina

de la ingeniería cuya meta es el desarrollo costeable de sistemas de software.

Éste es abstracto e intangible. No está restringido por materiales, o gobernado por

leyes físicas o por procesos de manufactura. De alguna forma, esto simplifica la

ingeniería del software ya que no existen limitaciones físicas del potencial del

software”. La meta de la ingeniería de software es desarrollar programas de

calidad que cumplan con las necesidades identificadas y que esta solución

cumpla con el presupuesto económico planificado. Adicionalmente la solución

deberá haberse entregado en el tiempo establecido.

Esta combinación de tres factores (costo – calidad – tiempo) suponen un nivel de

complejidad para todo el equipo de desarrollo de software ya que, si se no se toma

en consideración de manera adecuada uno o varios de estos aspectos, podría

llevar al fracaso al proyecto de desarrollo del sistema planteado. Adicional a los

componentes descritos se presentan (antes o durante el desarrollo) eventos,

acciones u omisiones que pueden afectar de manera negativa al proyecto. A estos

20

eventos se los denomina “riesgos” y deben ser considerados de manera adecuada

para poder controlar sus efectos en caso de que lleguen a materializarse.

Sin embargo, (Sommerville, 2005), menciona adicionalmente que “no hay un

enfoque «ideal» a la ingeniería del software. La amplia diversidad de diferentes

tipos de sistemas y organizaciones que usan estos sistemas significa que

necesitamos una diversidad de enfoques al desarrollo de software. Sin embargo,

las nociones fundamentales de procesos y la organización del sistema son la base

de todas estas técnicas, y éstas son la esencia de la ingeniería del software”.

Bajo esta premisa podemos deducir que no existe una “receta” para el desarrollo

de software, sin embargo la disciplina denominada “Ingeniería de software” nos

provee de ciertos métodos, modelos, metodologías, herramientas que nos

permiten tener un enfoque claro acerca del desarrollo de software y que se pueden

aplicar en los diversos proyectos de desarrollo, considerando los niveles de

complejidad que éstos presenten.

El proceso de software

Un proceso del software es un conjunto de actividades y resultados asociados que

producen un producto de software. Estas actividades son llevadas a cabo por los

ingenieros de software. Existen cuatro actividades fundamentales de procesos

que son comunes para todos los procesos del software (Sommerville, 2005)

Especificación del software

Desarrollo del software

Validación del software

Evolución del software

Modelo en cascada.

Considera las actividades fundamentales del proceso de software separadas en

fases, ordenadas de manera secuencial y la característica principal es que una

vez que alcance una fase no podrá retroceder en el desarrollo de las actividades

de las fases previas (Sommerville, 2005, pág. 61). Así mismo (Breugge & Allen,

21

2002, pág. 473) dice que el modelo de cascada “lo describió por primera vez

Royse [Roy se, 1970]. El modelo de cascada es un modelo del ciclo de vida

centrado en actividad que prescribe una ejecución secuencial de un subconjunto

de los procesos de desarrollo y administrativos”.

Imagen 1 - Modelo de cascada de desarrollo de software PROCESO DE

INICIO DEL PROYECTO

PROCESO DE EXPLORACION DE CONCEPOS

PROCESO DE ASIGNACION DEL SISTEMA

PROCESO DE REQUERIMIENTO

PROCESO DE DISEÑO

PROCESO DE IMPLEMENTACION

PROCESO DE VERIFICACION Y VALIDACION

PROCESO DE INSTALACION

PROCESO DE OPERACIÓN Y

SOPORTE Fuente: Ingeniería de Software Orientado a Objetos -

Autor: Breugge Bernd

El Objetivo del modelo de cascada es “nunca regresar una vez que se termina

una actividad. La característica principal de este modelo es la actividad de

verificación constante que asegura que cada actividad de desarrollo no introduzca

requerimientos no deseados o elimine los obligatorios” (Breugge & Allen, 2002).

Este modelo “mide el avance por el número de tareas que se han terminado

durante el proceso y asume que el desarrollo de software puede calendarizarse

como un proceso gradual que transforma en código las necesidades del usuario”

(Breugge & Allen, 2002, pág. 474)

Modelo del proceso de software

Según (Sommerville, 2005) el modelo de los procesos de software “es una

representación abstracta de un proceso del software. Cada modelo de proceso

representa un proceso desde una perspectiva particular, y así proporciona sólo

22

información parcial sobre ese proceso”. Se pueden definir ciertos modelos

generales los cuales son abstracciones que se pueden utilizar para explicar

diferentes enfoques para el desarrollo de software. Estos modelos generales nos

proporcionan una perspectiva de alto nivel sobre los pasos a seguir y el marco de

trabajo para el desarrollo de software.

Los modelos del proceso de software generales son:

Modelo en cascada

Desarrollo evolutivo

Ingeniería de software basada en componentes

Desarrollo Evolutivo

(Sommerville, 2005, pág. 61) describe este modelo como un proceso “que

entrelaza las actividades de especificación, desarrollo y validación. Un sistema

inicial se desarrolla rápidamente a partir de especificaciones abstractas. Este se

refina basándose en las peticiones del cliente para producir un sistema que

satisfaga sus necesidades”

Imagen 2 - Modelo de desarrollo de software Evolutivo

Esbozo de la descripción

ESPECFICACION

DESARROLLO

VALIDACION

VERSION INCIAL

VERSION FINAL

VERSIONES INMEDIATAS

ACTIVIDADES CONCURRENTES

Fuente:Ingeniería de Software Orientados a Objetos

Autor: Sommerville Ian

El modelo evolutivo se basa en la idea de desarrollar una implementación inicial

del sistema, exponiendola a los comentarios de los usuarios y redefiniendola a

traves de varias versiones hasta obtener el sistema adecuado de acuerdo a las

23

necesidades del cliente. Esto permite que al desarrollar las versiones inmediatas

los usuarios vayan desarrollando una mejor concepción del sistema lo que permite

que cada versión sea un sistema más acorde a la resolución de los problemas

planteados en la institución.

El desarrollo evolutivo puede ser de dos tipos:

1. Desarrollo exploratorio: El objetivo del proceso es “trabajar con el cliente

para explorar sus requerimientos y entregar un sistema final. El desarrollo

empieza con las partes del sistema que se comprenden mejor. El sistema

evoluciona agregando nuevos atributos propuestos por el cliente”.

(Sommerville, 2005, pág. 64).

2. Prototipos desechadles: El objetivo del proceso de desarrollo evolutivo

es “comprender los requerimientos del cliente y entonces desarrollar una

definición mejorada de de los requerimientos para el sistema. El prototipo

se centra en experimentar con los requerimientos del cliente que no se

comprenden del todo”. (Sommerville, 2005, pág. 64).

La ventaja de un proceso del software que se basa en un enfoque evolutivo es

que “la especificación se puede desarrollar de forma creciente. Tan pronto como

los usuarios desarrollen un mejor entendimiento de su problema, éste se puede

reflejar en el sistema software”. (Sommerville, 2005, pág. 64).

Ingeniería de Software basado en componentes

Este enfoque basado en la reutilización se compone de una gran base de

componentes software reutilizables y de algunos marcos de trabajo de integración

para éstos. Algunas veces estos componentes son sistemas por sí mismos.

(Sommerville, 2005). Este modelo tiene la ventaja de desarrollar menor cantidad

de software reduciendo los costos, tiempos de implementación y riesgos

asociados.

Las etapas del proceso de software bajo este modelo son:

1. Especificación de requerimientos

2. Análisis de componentes

24

3. Modificación de requerimientos

4. Diseño del sistema con reutilización

5. Desarrollo e integración

6. Validación del sistema

Imagen 3 - Ingeniería de Software basado en componentes

ESPECIFICACION DE REQUERIMIENTOS

ANALISIS DE COMPONENTES

MODIFICACION DE REQUERIMIENTOS

DISEÑO DE SISTEMA CON REUTILIZACION

DESARROLLO E INTEGRACION

VALIDACION DEL SISTEMA

Fuente: Ingeniería de Software Autor: Ian Sommerville

Iteración de Procesos

Los cambios son inevitables en el desarrollo de proyectos de software grandes ya

que pueden cambiar los requerimientos del sistema por factores internos o

externos de la institución que requiere el sistema. Si cambia el estilo

administrativo, el entorno legal, las estrategias empresariales, las herramientas

tecnológicas, los diseños, etc, harán que los requerimientos del sistema se

modifiquen. Por lo anterior el proceso del software “no es un proceso único; más

bien, las actividades del proceso se repiten regularmente conforme el sistema se

rehace en respuesta a peticiones de cambios”. (Sommerville, 2005, pág. 66).

Según (Sommerville, 2005), “el desarrollo iterativo es fundamental para el

desarrollo de software y se pueden presentar en dos modelos que son”:

1. Entrega incremental. La especificación, el diseño y la implementación del

software se dividen en una serie de incrementos, los cuales se desarrollan

por turnos;

2. Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia fuera,

empezando con un esbozo inicial y terminando con el desarrollo final del

mismo.

En la entrega incremental “los clientes identifican, a grandes rasgos, los servicios

que proporcionará el sistema. Identifican qué servicios son más importantes y

25

cuáles menos. Entonces, se definen varios incrementos en donde cada uno

proporciona un subconjunto de la funcionalidad del sistema” (Sommerville, 2005,

pág. 66).

Imagen 4 - Entrega Incremental

DEFINIR ESBOZO DE REQUERIMIENTOS

ASIGNAR REQUERIMIENTOS A LOS INCREMENTOS

DISEÑAR LA ARQUITECTURA DEL SISTEMA

DESARROLLAR INCREMENTOS DEL SISTEMA

VALIDAR INCREMENTOS

INTEGRAR INCREMENTOS

VALIDAR SISTEMA

SISTEMA FINALSISTEMA INCOMPLETO

Fuente: Ingeniería de Software

Autor: Ian Sommerville

El modelo en espiral de desarrollo de software “fue originalmente propuesto por

Boehm (Boehm, 1988). Más que representar el proceso del software como una

secuencia de actividades con retrospectiva de una actividad a otra, se representa

como una espiral”. Cada uno de los ciclos de la espiral representa una fase del

proceso de software. Cada ciclo de la espiral se divide en cuatro sectores

(Sommerville, 2005):

1. Definición de objetivos Se definen los objetivos específicos. Se

identifican las restricciones del proceso y el producto, y se traza un plan

detallado de gestión. Se identifican los riesgos del proyecto

2. Evaluación y reducción de riesgos: Se lleva a cabo un análisis detallado

para cada uno de los riesgos del proyecto identificados. Se definen los

pasos para reducir dichos riesgo.

3. Desarrollo y validación: Después de la evaluación de riesgos, se elige un

modelo para el desarrollo del sistema

4. Planificación: El proyecto se revisa y se toma la decisión de si se debe

continuar con un ciclo posterior de la espiral. Si se decide continuar, se

desarrollan los planes para la siguiente fase del proyecto.

26

Imagen 5 - Modelo espiral

Fuente: Ingeniería de software

Autor: Ian Sommerville

La diferencia principal del modelo espiral con el resto de modelos radica en la

concepción explicita del riesgo en el modelo. Basicamente un riesgo es algo que

puede ocurrir que pueda afectar al proyecto.

Actividades del proceso de software

Especificación del software

Según (Sommerville, 2005) “la especificación del software o ingeniería de

requerimientos es el proceso de comprensión y definición de qué servicios se

requieren del sistema y de identificación de las restricciones de funcionamiento y

desarrollo del mismo”. Esta etapa es particularmente crucial ya que si se cometen

errores en la definición del software generará problemas en el desarrollo e

implementación del sistema haciendo que los costos de desarrollo aumenten o

que la calidad del software, identificado como la característica de que el sistema

cumpla con las necesidades de los usuarios, se vea afectada.

27

Dentro de esta primera etapa de desarrollo podemos encontrar algunas

actividades básicas que son:

1. Estudio de viabilidad. En esta actividad se realiza un estudio acerca de que

si las necesidades planteadas por el usuario se pueden realizar con las

herramientas tecnológicas de hardware y software actuales. Adicionalmente

se realiza el análisis de la rentabilidad o el beneficio económico o estratégico

que tendrá el sistema planteado y si los recursos de la institución que propone

el sistema son suficientes para emprender el desarrollo de la aplicación. Esta

primera actividad definirá si se debe continuar con las siguientes etapas ya

que, si el producto esperado no cumple con las expectativas estratégicas,

operacionales o económicas, no se deberá continuar su análisis. Como

resultado de esta actividad se tendrá el documento denominado “Informe de

viabilidad del sistema”.

2. Obtención y análisis de requerimientos. Esta actividad permite obtener

información adecuada de las necesidades de los clientes también

denominados requerimientos. Esta obtención de requerimientos se puede

realizar desarrollando actividades de observación en el área requerida,

seguimiento del proceso operativo, reuniones con el personal involucrado,

análisis de tareas, análisis de documentación técnica, administrativa y/o legal,

para tener la mayor cantidad de información válida. Esta etapa se puede

apoyar en la elaboración de uno o más modelos o prototipos que permitan al

ingeniero de software comprender el sistema que se va a especificar.

3. Especificación de requerimientos. Es la actividad en la cual se traduce la

información recopilada durante la actividad de obtención y análisis y produce

un documento donde se definen los requerimientos. Estos requerimientos se

pueden clasificar en requerimientos del usuario y requerimientos del sistema.

Los primeros son declaraciones abstractas de lo que el cliente desea que el

software realice, en cambio que los requerimientos del sistema son

declaraciones detalladas de la funcionalidad del sistema.

4. Validación de requerimientos. Esta actividad comprueba la veracidad,

consistencia y completitud de los requerimientos. Durante este proceso,

inevitablemente se descubren errores en el documento de requerimientos.

28

Una vez desarrolladas las cuatro primeras actividades tenemos como resultado

un documento detallado con todos los requerimientos del sistema lo que permite

al equipo tener una base fundamental para las siguientes etapas de desarrollo.

Sin embargo, durante el proceso de software pueden exponerse nuevos

requerimientos o requerimientos que no fueron considerados de manera inicial por

lo cual todos los proyectos de software deberán tener la consideración de tratar

de manera adecuada esos nuevos requerimientos o, si alguno de los analizados

y detallados en el documento ha cambiado durante el proceso.

Imagen 6 - Ingeniería de Requerimientos

ESTUDIO DE VIABILIDAD

OBTENCION YANALISIS DE

REQUERIMIENTOS

ESPECIFICACIONES DE REQUERIMIENTOS

VALIDACIONES DE REQUERIMIENTOS

INFORME DE VIABILIDAD

MODELOS DEL SISTEMA

REQUERIMIENTOS DELUSUARIO Y DEL SISTEMA

DOCUMENTO DE REQUERIMIENTOS

Fuente: Ingeniería de Software

Autor: Ian Sommerville

Diseño e implementación de software

El diseño e implementación de software es “el proceso de convertir una

especificación del sistema en un sistema ejecutable” (Sommerville, 2005, pág. 71).

Durante esta etapa se consideran todos los requerimientos obtenidos durante la

etapa previa y se convierten en programas, a través de un lenguaje de

programación seleccionado, que pueda ser ejecutado por un sistema

29

computacional. Estos programas deben cumplir con todos los requerimientos

planteados por los usuarios.

“Un diseño de software es una descripción de la estructura del software que se va

a implementar ,los datos que son parte del sistema, las interfaces entre los

componentes del sistema y, algunas veces, los algoritmos utilizados”

(Sommerville, 2005, pág. 71). Este diseño debe considerar todos los aspectos del

sistema propuesto y las perspectivas de cada uno de los involucrados.

Considérese a los involucrados como todas aquellas personas o instituciones que

se ven afectados (positiva o negativamente) por la implementación del sistema.

(Sommerville, 2005) Señala que “el proceso de diseño puede implicar el desarrollo

de varios modelos del sistema con diferentes niveles de abstracción. Mientras se

descompone un diseño, se descubren errores y omisiones de las etapas previas”.

Estos modelos permiten representar el sistema en diferentes aspectos o

perspectivas con la mayor cantidad de detalle posible lo que permite tener una

visión del futuro sistema sin tener que haber desarrollado el programa. Como

consecuencia, "el resultado final del proceso son especificaciones precisas de los

algoritmos y estructuras de datos a implementarse” (Sommerville, 2005, pág. 71).

La etapa de diseño produce un conjunto de productos tangibles necesarios que

se incorporan al producto final que es el programa computacional. Estos productos

son los documentos y modelos que nos sirven para definir el software propuesto.

(Sommerville, 2005) Plantea algunos productos de esta etapa que son:

Arquitectura del sistema

Especificación del software

Especificación de la interfaz

Especificación de componentes

Especificación de la estructura de datos

Especificación de algoritmos

30

Imagen 7 - Actividades de Diseño

ESPECIFICACION DE REQUERIMIENTO

DISEÑO ARQUITECTONICO

ESPECIFICACION ABSTRACTA

DISEÑO DE LA INTERFAZ

DISEÑO DE COMPONENTES

DISEÑO DE LA ESTRUCTURA

DE DATOS

DISEÑO DEALGORITMO

ARQUITECTURA DEL SISTEMA

ESPECIFICACION DEL SOFTWARE

ESPECIFICACION DE LA INTERFAZ

ESPECIFICACION DE COMPONENTES

ESPECIFICACION DE LA ESTRUCTURA

DE DATOS

ESPECIFICACION DE ALGORITMO

ACTIVIDADES DE DISEÑO

Fuente: Ingeniería de Software Autor: Ian Sommerville

Las actividades de diseño se pueden definir de la siguiente manera (Sommerville,

2005):

Diseño arquitectónico. Los subsistemas que forman el sistema y sus

relaciones se Identifican y documentan.

Especificación abstracta. Para cada subsistema se produce una

especificación abstracta de sus servicios y las restricciones bajo las

cuales debe funcionar.

Diseño de la interfaz. Para cada subsistema se diseña y documenta

su interfaz con otros subsistemas. Esta especificación de la interfaz

debe ser inequívoca ya que permite que el subsistema se utilice sin

conocimiento de su funcionamiento. En esta etapa pueden utilizarse

los métodos de especificación formal.

Diseño de componentes. Se asignan servicios a los componentes y

se diseñan sus interfaces.

Diseño de la estructura de datos. Se diseña en detalle y especifica

la estructura de datos utilizada en la implementación del sistema.

Diseño de algoritmos. Se diseñan en detalle y especifican los

algoritmos utilizados para proporcionar los servicios.

Cuando se utilizan métodos ágiles de desarrollo, “las salidas del proceso de diseño

no serán documentos de especificación separados, sino que estarán

representadas en el código del programa” (Sommerville, 2005). Es decir que los

elementos del diseño se irán incorporando al programa en el transcurso del tiempo

según se va avanzando en el desarrollo del software, tal como lo describen estas

metodologías. (Sommerville, 2005) Menciona adicionalmente que en este tipo de

31

metodologías de desarrollo, “una vez diseñada la arquitectura de un sistema, las

etapas posteriores del diseño son increméntales. Cada incremento se representa

como código del programa en vez de como un modelo de diseño”.

Sin embargo existe el enfoque “tradicional” de desarrollo de software denominado

estructurado el cual “se basa en la producción de modelos gráficos del sistema y,

en muchos casos, código automáticamente generado desde estos modelos”

(Sommerville, 2005). Estos métodos estructurados “se inventaron en los años 70

en apoyo del diseño orientado a funciones. Se propusieron varios modelos

competentes de apoyo al diseño orientado a objetos y éstos se unificaron en los

años 90 para crear el Lenguaje Unificado de Modelado (UML) y el proceso

unificado de diseño asociado” (Sommerville, 2005).

(Sommerville, 2005) Resalta que “un método estructurado incluye un modelo del

proceso de diseño, notaciones para representar el diseño, formatos de informes,

reglas y pautas de diseño”. (pág. 72). Es así que los métodos estructurados en la

práctica “son realmente notaciones estándar que comprenden prácticas

aceptables. Si se siguen estos métodos y se aplican las pautas, puede obtenerse

un diseño razonable” (Sommerville, 2005).

El desarrollo del programa es una actividad posterior al diseño y consiste en que

el programador escriba las instrucciones necesarias para que el programa realice

las acciones correspondientes. Este desarrollo debe seguir las pautas, reglas y

condiciones impuestas en el diseño previamente elaborado. Según (Sommerville,

2005) “la programación es una actividad personal y no existe un proceso general

que se siga comúnmente”. Este proceso básicamente depende de las habilidades

y conocimientos de los programadores y, según su estilo, desarrollará los

componentes descritos en el orden y secuencia que considere o le sea más

entendible.

32

Validación del software

“La validación del software o, de forma más general, la verificación y validación (V

& V) se utiliza para mostrar que el sistema se ajusta a su especificación y que

cumple las expectativas del usuario que lo comprará” (Sommerville, 2005).

Básicamente se verifica que las funcionalidades desarrolladas en el proceso

previo y los resultados obtenidos de la interacción de los usuarios con el sistema

se ajuste a los que se solicitó en las primeras etapas del proceso de software a

través de los requerimientos que se realizó.

Esta validación no se realiza de manera monolítica y específicamente en los

proyectos de software grandes se deben desarrollar algunos tipos de pruebas para

verificar que todos los elementos cumplan con las funciones para las cuales fueron

desarrolladas. (Sommerville, 2005) Divide las pruebas en tres etapas:

Prueba de componentes (o unidades). Se prueban los componentes

individuales para asegurarse de que funcionan correctamente. Cada

uno se prueba de forma independiente, sin los otros componentes del

sistema. Los componentes pueden ser entidades simples como

funciones o clases de objetos, o pueden ser agrupaciones coherentes

de estas entidades.

Prueba del sistema. Los componentes se integran para formar el

sistema. Este proceso comprende encontrar errores que son el

resultado de interacciones no previstas entre los componentes y su

interfaz. También comprende validar que el sistema cumpla sus

requerimientos funcionales y no funcionales y probar las propiedades

emergentes del sistema. Para sistemas grandes, esto puede ser un

proceso gradual en el cual los componentes se integran para formar

subsistemas que son probados individualmente antes de que ellos

mismos se integren para formar el sistema final.

Prueba de aceptación. Es la etapa final en el proceso de pruebas

antes de que se acepte que el sistema se ponga en funcionamiento.

Este se prueba con los datos proporcionados por el cliente más que

con datos de prueba simulados. Debido a la diferencia existente entre

los datos reales y los de prueba, la prueba de aceptación puede revelar

33

errores y omisiones en la definición de requerimientos del sistema.

También puede revelar problemas en los requerimientos donde los

recursos del sistema no cumplen las necesidades del usuario o donde

el desempeño del sistema es inaceptable.

Habitualmente, las pruebas de componentes se realizan durante el proceso de

desarrollo ya que el programador es el que conoce en detalle cada uno de los

componentes que se está desarrollando, el comportamiento que debe tener cada

uno de ellos y los escenarios de prueba que se deben considerar para validar que

el componente realice las acciones para la cual ha sido desarrollado. “Si se utiliza

un enfoque incremental de desarrollo, cada incremento debe ser probado cuando

se desarrolla, con estas pruebas basadas en los requerimientos de ese

incremento”. (Sommerville, 2005).

Evolución del software

La evolución del software radica en que las necesidades del cliente o las

características del negocio para el cual se desarrolló un software casi nunca

permanecen estáticos y es necesario ajustar los sistemas a estas nuevas

realidades. Habitualmente algunos autores aseguran que el proceso de software

termina en la puesta en producción de un nuevo sistema partiendo de los

conceptos o ideas iniciales. Sin embargo en los últimos años se ha evidenciado

que muy rara vez los nuevos sistemas arrancan de cero y que muchos de este

software corresponde a evolución de sistemas existentes.

La evolución del software también responde a los objetivos institucionales y las

estrategias de las empresas en cuanto a la consecución de dichos objetivos. Los

sistemas son un componente importante en la consecución de los objetivos

institucionales al ser el apoyo tecnológico importante en la estrategia corporativa.

Además (Sommerville, 2005, pág. 76) asegura que “esta distinción entre el

desarrollo y el mantenimiento es cada vez más irrelevante. Hoy en día, pocos

sistemas software son completamente nuevos, lo que implica que tiene más

sentido ver el desarrollo y el mantenimiento como actividades continuas”. Lo

anterior destaca la importancia de la evolución como un proceso continuo en el

proceso de software.

34

UML (Lenguaje de Modelado Unificado)

Según (Breugge & Allen, 2002) “las notaciones nos permiten formular ideas

complejas en forma resumida y precisa. En los proyectos que involucran a muchos

participantes, a menudo con diferentes conocimientos técnicos y culturales, la

precisión y claridad son críticas conforme se incrementa rápidamente el costo de

la falta de comunicación”. Estas notaciones permiten a todos los involucrados en

el proceso de software identificar de manera clara todos los elementos y

funcionalidades del sistema.

El Lenguaje de Modelado Unificado permite la comunicación adecuada y precisa

de todos los aspectos del sistema. UML nace como resultado de la unificación de

la técnica de modelado de objetos (OMT por sus siglas en inglés) y la Ingeniería

de Software orientado a objetos (OOSE por sus siglas en ingles). Este lenguaje

ha sido desarrollado para un amplio rango de aplicaciones por lo cual, a través de

UML se puede definir cualquier sistema informático con distintas aplicaciones.

(Breugge & Allen, 2002) Define que el desarrollo de sistemas utilizando el

Lenguaje de Modelado Unificado se puede hacer en tres tipos de modelos

diferentes que son:

Modelo Funcional

Modelo de objetos

Modelo dinámico.

El modelo funcional representa el sistema en términos de todas las acciones que

se pueden ejecutar y los participantes que interactúan con cada una de las

operaciones. Este modelo se representa a través del “Diagrama de casos de uso”,

el cual se desarrolla en base a la información proporcionada por los usuarios en

la etapa de obtención de requerimientos y deberá ser validado en conjunto con los

mismos.

El modelo de objetos representa la estructura del sistema en términos de cada

uno de sus componentes, sus relaciones y operaciones. Define la arquitectura del

35

sistema y las responsabilidades de cada uno de los elementos. Este modelo está

definido por el “Diagrama de Clases” que representa la estructura del sistema en

términos de objetos, atributos, asociaciones y operaciones.

El modelo dinámico representa al sistema en términos del comportamiento interno

del mismo y define las acciones/actividades que deben realizarse para cumplir los

objetivos de cada una de las funcionalidades descritas previamente. Este modelo

está definido por los diagramas de actividades, de secuencia y de estado.

Diagrama de casos de uso

Los casos de uso se utilizan en las etapas de obtención de requerimientos y

análisis con la finalidad de representar la funcionalidad del sistema. Los casos de

uso describen el comportamiento del sistema desde el punto de vista externo o

del usuario. Este diagrama proporciona una visión de las funciones que debe tener

el sistema que produzcan un resultado visible para los usuarios. (Breugge & Allen,

2002).

Componentes del diagrama de casos de uso:

Actores

Caso de uso

Relaciones

o De asociación ( entre actor y caso de uso)

o De inclusión ( entre casos de uso )

o De extensión ( entre casos de uso )

Diagrama de clases.

Los diagramas de clase son utilizados para describir la estructura del sistema. Las

clases son abstracciones que especifican la estructura y comportamiento común

de un conjunto de objetos. Así también, los objetos son “instancias” de la clase

que se crean y destruyen durante la ejecución del sistema. (Breugge & Allen,

2002).

36

Componentes de un diagrama de clases.

Clase

o Atributos

o Métodos

Relaciones

o Generalización / Especialización

o Composición / Agregación

o Asociación

Cardinalidad

Los atributos son las características comunes del conjunto de objetos analizados.

Estos características son parte del modelo en función de la información necesaria

que el sistema debe estar en la capacidad de almacenar. Cada característica de

la clase responde a un tipo de dato definido en el proceso de análisis.

Los métodos representan la funcionalidad del objeto que se instancie en base a la

clase definida. Los métodos son los únicos que pueden modificar el valor de los

atributos de la clase.

Diagrama de estado.

Los diagramas de estado definen el comportamiento individual de un objeto

independiente en términos de estados y las transiciones entre cada uno de ellos.

Llámese estado al conjunto de valores que un objeto posee en sus características

en un determinado tiempo. Las transiciones representan el estado futuro al cual

pasará el objeto individual.

Diagrama de actividades

Un diagrama de actividad representa un sistema desde el punto de vista de las

actividades que realiza. Las actividades son estados que representa la ejecución

de un conjunto de operaciones. La terminación de estas operaciones dispara una

transición hacia otra actividad. (Breugge & Allen, 2002). Los diagramas de

actividades definen las operaciones que se llevan a cabo dentro de cada uno de

los casos de uso identificados en las etapas previas.

37

Diagrama de Secuencia de actividades

Los diagramas de secuencia se usan para formalizar el comportamiento del

sistema y para visualizar la comunicación entre objetos. Son útiles para identificar

objetos adicionales que participan en los casos de uso. (Breugge & Allen, 2002).

Aplicaciones web

Las aplicaciones web son tipos de programas de software en los cuales no es

necesario la instalación de los componentes lógicos en cada una de las máquinas

o equipos informáticos que van a utilizar el sistema. El programa se instala en un

equipo central denominado “Servidor Web” al cual los clientes le realizan

peticiones, a través de la red de comunicaciones a través del protocolo http o https,

y el programa responde con los resultados adecuados. La característica principal

de este tipo de programas es que la comunicación (requerimiento – respuesta) se

realiza utilizando lenguaje Html( HiperText Markup Language) que significa

Lenguaje de marcas de hipertexto, que es un lenguaje para el desarrollo de

páginas web y está compuesto por una serie de etiquetas que el explorador

web(cliente) también llamado navegador interpreta y presenta en su interface el

contenido de las respuestas.

Estas aplicaciones web permiten mantener el control de los sistemas de manera

centralizada ya que toda la lógica de negocio reside en el componente instalado

en el servidor web (Componente central del sistema). Adicionalmente tiene la

ventaja que los clientes siempre accederán a la última versión del programa.

Adicionalmente podemos destacar que los equipos informáticos de los clientes no

deben poseer características de procesamiento o almacenamiento altas ya que

toda la lógica del negocio la ejecuta el servidor y, el cliente a través del explorador

web, solamente interpreta las marcas html y las presenta en la interfaz adecuada.

Adicionalmente este tipo de desarrollo de software nos permite mantener

separadas las “capas” del sistema permitiendo a cada uno de los componentes

dedicarse exclusivamente a la tarea para la cual ha sido desarrollado. Por ejemplo

38

la capa “interfaz” del lado del cliente se especializa en la interacción entre el

usuario final y la interfaz de comunicación con el sistema permitiendo al usuario

realizar los requerimientos que considere pertinente. La capa de “negocio” es la

parte central y está instalado en el servidor de aplicaciones en la cual se ejecutan

todas las operaciones básicas del sistema. Finalmente tenemos la capa de

“acceso a datos” que nos permite administrar toda la interacción del sistema con

los datos que se deben registrar en los dispositivos de almacenamiento masivo;

este componente permite tener independencia entre la plataforma de desarrollo

del sistema de los diferentes programas de administración de base de datos. Esta

arquitectura se presenta en la siguiente figura:

Imagen N° 1 - Arquitectura de Aplicaciones web

Fuente: Introducción a las tecnologías web

Autor: Jimenez Luis Marco

Así mismo, (Mateu, 2009), Un servidor web “es un programa que atiende y

responde a las diversas peticiones de los navegadores, proporcionándoles los

recursos que solicitan mediante el protocolo HTTP o el protocolo HTTPS (la

versión segura, cifrada y autenticada de HTTP)”. Este servidor es el encargado de

esperar las peticiones de los clientes a través del protocolo de comunicación,

invoca al módulo correspondiente del sistema y envía, en html, el resultado de la

petición.

39

Las aplicaciones web tienen algunas ventajas sobre otros tipos de software, los

cuales (Palacios & Puente, 2014) los describen de la siguiente manera:

Compatibilidad:

o Las aplicaciones web utilizan el navegador del cliente como interfaz

de usuario

o El lenguaje HTML garantiza la compatibilidad en distingas

plataformas

Accesibilidad

o Acceso remoto es un pre-requisito de diseño

o Los dispositivos móviles están generalmente soportados

o Hay muchas soluciones a nivel de navegador para personas con

discapacidad:

o Lectores automáticos de texto

Gran variedad de dispositivos de entrada (teclados,

ratones)

Tamaños y colores de texto ajustables

40

CALIDAD DEL SOFTWARE

El termino calidad puede ser definido por un sinnúmero de apreciaciones, sin

embargo tomaremos la de la (ISO-8402), que luego se repite en otras (por ejemplo

en ISO-14598): “La totalidad de aspectos y características de un producto o

servicio que tienen que ver con su habilidad para satisfacer las necesidades

declaradas o implícitas”. Las necesidades de los usuarios del sistema fueron

recopiladas en las primeras etapas del proceso de software donde se realizó la

definición de los requerimientos funcionales y no funcionales que debe cumplir el

sistema desarrollado. Así mismo, (Bertoa, Troya, & Vallecillo, 2010) menciona que

“la calidad no es el objetivo último del producto sino satisfacer las necesidades del

cliente. También es importante señalar que esto implica que la calidad de un

producto software no se puede referir únicamente a obtener un producto sin

errores”.

No existe una definición globalmente aceptada para definir y clasificar las

características de calidad de un producto de software sin embargo, “por

característica de calidad de un producto software a un conjunto de propiedades

mediante las cuales se evalúa y describe su calidad. Una característica se puede

refinar en múltiples niveles de sub-características. Ejemplos de características son

la funcionalidad, la fiabilidad o la facilidad de uso”. (Bertoa, Troya, & Vallecillo,

2010). Estos componentes deben ser parte de un modelo de aseguramiento de la

calidad y deben estar definidas las sub características que deben ser cumplidas.

Así mismo debemos definir que la medición se realiza a los atributos del sistema,

entendiéndose como aquello a “una propiedad de calidad a la que puede

asignársele una métrica, entendiendo por métrica un procedimiento que examina

un componente y produce un dato simple, un símbolo (por ejemplo Excelente, Sí,

No) o un número. Hay que tener en cuenta que no todas las propiedades son

medibles (por ejemplo la demostrabilidad)”. (Bertoa, Troya, & Vallecillo, 2010).

Esto parámetros deben ser analizados en la etapa de validación y verificación

previo a la puesta en producción del sistema. Adicionalmente, en el ambiente

41

productivo el sistema deberá someterse a la verificación de los estándares

definidos para confirmar su real cumplimiento.

Este modelo de calidad se puede definir como “un conjunto de características y

sub-características, junto con las relaciones que existen entre ellas” (Bertoa,

Troya, & Vallecillo, 2010). Sin embargo estos modelos de calidad son

directamente proporcionales al producto que se desea evaluar. No

necesariamente un modelo general se podría aplicar a todos los tipos de

productos de software.

(Fernández, 2011) Clasifica la calidad en tres aspectos esenciales que son:

Calidad del producto: Significa la calidad del producto según el usuario y

según el desarrollador. Corresponde a que si cumple con las

especificaciones para las cuales fue construido el sistema.

Calidad del proceso: Si todas las actividades desarrolladas en el proceso

de construcción del software has sido ejecutadas según la metodología

aprobada y cumpliendo los estándares generalmente aceptados.

Calidad de uso: Se relaciona al uso del sistema en los ambientes

productivos en los cuales se verifica el cumplimiento de las características

solicitadas.

La calidad total depende de la calidad con la cual se lleve a cabo todo el proceso

- las cinco etapas del ciclo de vida de un desarrollo de software (análisis, diseño,

implementación, pruebas e implantación)- y cada subproceso o fase o etapa del

proyecto, adicionalmente, es indispensable contar con los siguientes

componentes: claridad, involucración, planeamiento, estándares entrenamiento,

experiencia, controles, documentación, soporte y finalización. (López, Cabrera, &

Valencia, 2008).

42

FUNDAMENTACIÓN LEGAL

“CONSTITUCIÓN DE LA REPÚBLICA DEL ECUADOR”

Sección quinta

Educación

Art. 26.- La educación 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

política pública y de la inversión estatal, garantía de la igualdad e inclusión social

y condición indispensable para el buen vivir.

Las personas, las familias y la sociedad tienen el derecho y la responsabilidad de

participar en el proceso educativo.

Art. 27.-La educación se centrará en el ser humano y garantizará su desarrollo

holístico, en el marco del respeto a los derechos humanos, al medio ambiente

sustentable y a la democracia; será participativa, obligatoria, intercultural,

democrática, incluyente y diversa, de calidad y calidez; impulsará la equidad de

género, la justicia, la solidaridad y la paz; estimulará el sentido crítico, el arte y la

cultura física, la iniciativa individual y comunitaria, y el desarrollo de

competencias y capacidades para crear y trabajar. La educación es

indispensable para el conocimiento, el ejercicio de los derechos y la construcción

de un país soberano, y constituye un eje estratégico para el desarrollo nacional.

Art. 28.-La educación responderá al interés público y no estará al servicio de

intereses individuales y corporativos. Se garantizará el acceso universal,

permanencia, movilidad y egreso sin discriminación alguna y la obligatoriedad en

el nivel inicial, básico y bachillerato o su equivalente. Es derecho de toda persona

y comunidad interactuar entre culturas y participar en una sociedad que aprende.

El Estado promoverá el diálogo intercultural en sus múltiples dimensiones.

El aprendizaje se desarrollará de forma escolarizada y no escolarizada. La

educación pública será universal y laica en todos sus niveles, y gratuita hasta

el tercer nivel de educación superior inclusive.

43

Sección segunda

Administración pública

Art. 227.-La administración pública constituye un servicio a la colectividad que se

rige por los principios de eficacia, eficiencia, calidad, jerarquía,

desconcentración, descentralización, coordinación, participación, planificación,

transparencia y evaluación.

Art. 228.-El ingreso al servicio público, el ascenso y la promoción en la carrera

administrativa se realizarán mediante concurso de méritos y oposición, en

la forma que determine la ley, con excepción de las servidoras y servidores

públicos de elección popular o de libre nombramiento y remoción. Su

inobservancia provocará la destitución de la autoridad nominadora.

Sección tercera

Servidoras y servidores públicos

Art. 229.- Serán servidoras o servidores públicos todas las personas que en

cualquier forma o a cualquier título trabajen, presten servicios o ejerzan un

cargo, función o dignidad dentro del sector público. Los derechos de las

servidoras y servidores públicos son irrenunciables. La ley definirá el organismo

rector en materia de recursos humanos y remuneraciones para todo el sector

público y regulará el ingreso, ascenso, promoción, incentivos, régimen

disciplinario, estabilidad, sistema de remuneración y cesación de funciones de

sus servidores. Las obreras y obreros del sector público estarán sujetos al

Código de Trabajo.

La remuneración de las servidoras y servidores públicos será justa y equitativa,

con relación a sus funciones, y valorará la profesionalización, capacitación,

responsabilidad y experiencia.

44

Capítulo Tercero

Gobiernos autónomos descentralizados y regímenes especiales

Art. 264.- Los gobiernos municipales tendrán las siguientes competencias

exclusivas sin perjuicio de otras que determine la ley:

6. Planificar, regular y controlar el tránsito y el transporte público dentro de

su territorio cantonal.

TÍTULO VII

RÉGIMEN DEL BUEN VIVIR

Capítulo Primero

Sección primera

Educación

Art. 343.-El sistema nacional de educación tendrá como finalidad el desarrollo

de capacidades y potencialidades individuales y colectivas de la población, que

posibiliten el aprendizaje, y la generación y utilización de conocimientos, técnicas,

saberes, artes y cultura. El sistema tendrá como centro al sujeto que aprende, y

funcionará de manera flexible y dinámica, incluyente, eficaz y eficiente.

Art. 352.-El sistema de educación superior estará integrado por universidades y

Escuelas politécnicas; institutos superiores técnicos, tecnológicos y pedagógicos;

y conservatorios de música y artes, debidamente acreditados y evaluados.

Estas instituciones, sean públicas o particulares, no tendrán fines de lucro

Art. 355.-El Estado reconocerá a las universidades y escuelas politécnicas

autonomía académica, administrativa, financiera y orgánica, acorde con los

objetivos del régimen de desarrollo y los principios establecidos en la Constitución.

Se reconoce a las universidades y escuelas politécnicas el derecho a la

autonomía, ejercida y comprendida de manera solidaria y responsable.

Dicha autonomía garantiza el ejercicio de la libertad académica y el derecho a la

búsqueda de la verdad, sin restricciones; el gobierno y gestión de sí mismas, en

consonancia con los principios de alternancia, transparencia y los derechos

políticos; y la producción de ciencia, tecnología, cultura y arte.

45

Sus recintos son inviolables, no podrán ser allanados sino en los casos y términos

en que pueda serlo el domicilio de una persona.

Sección duodécima

Transporte

Art. 394.-El Estado garantizará la libertad de transporte terrestre, aéreo,

marítimo y fluvial dentro del territorio nacional, sin privilegios de ninguna

naturaleza. La promoción del transporte público masivo y la adopción de una

política de tarifas diferenciadas de transporte serán prioritarias. El Estado

regulará el transporte terrestre, aéreo y acuático y las actividades aeroportuarias

y portuarias.

“LEY ORGÁNICA DE SERVICIO PÚBLICO”

Art. 83.- Servidoras y servidores públicos excluidos de la carrera del servicio

público.-Exclúyase del sistema de la carrera del servicio público, a:

a) Quienes tienen a su cargo la dirección política y administrativa del Estado:

a.1 Las o los ministros, viceministros y subsecretarios de Estado;

a.2 Las o los titulares de los organismos de Transparencia y Control Social,

de Control y Regulación y las segundas autoridades de estos organismos;

a.3 Las o los secretarios y subsecretarios comprendidos en el nivel

jerárquico superior;

a.4 Las o los puestos de coordinadores y subcoordinadores

nacionales;

a.5 Las o los directores y gerentes, subdirectores y subgerentes en todas

sus categorías y niveles;

a.6 Las o los presidentes y vicepresidentes ejecutivos;

a.7 Las o los secretarios generales y prosecretarios;

a.8 Las o los intendentes de control;

a.9 Las o los asesores;

a.10 Las o los procuradores síndicos;

a.11 Las o los gobernadores;

46

a.12 Las o los intendentes, subintendentes, comisarios de policía y

comisarios de la mujer y la familia;

a.13 Las o los jefes y tenientes políticos;

a.14 Las o los coordinadores generales e institucionales; y,

a.15 Las o los directivos de las instituciones educativas públicas del

Sistema Nacional de Educación;

b) Las o los que ejerzan funciones con nombramiento a período fijo por mandato

legal;

c) Las o los dignatarios elegidos por votación popular;

d) Las o los servidores en todas sus clasificaciones que pertenecen a la Carrera

Judicial, los Fiscales que pertenecen a la Carrera Fiscal, los Defensores Públicos

que pertenecen a la Carrera de la Defensoría, las vocales y los vocales del

Consejo de la Judicatura y sus suplentes, las Juezas y Jueces de la Corte Nacional

de Justicia, la Fiscal o el Fiscal General del Estado, la Defensora Pública General

o el Defensor Público General, la Procuradora General del Estado o el Procurador

General del Estado y la Contralora General del Estado o el Contralor General del

Estado, las Notarias y Notarios; y, quienes presten sus servicios en las notarías;

e) Las o los miembros del Consejo Nacional Electoral y miembros del Tribunal

Contencioso Electoral;

f) Las o los miembros de la Corte Constitucional;

g) Las o los miembros en servicio activo de las Fuerzas Armadas, de la Policía

Nacional y la Comisión de Tránsito del Guayas;

h) Las o los servidores de libre nombramiento y remoción, y de nombramiento

provisional;

i) Las servidoras y servidores públicos sujetos a la Ley Orgánica de Servicio

exterior;

j) Las dignatarias y dignatarios, autoridades o miembros de cuerpos colegiados o

de corporaciones a cuyo cargo corre el gobierno de las instituciones del Estado;

k) El personal de las empresas sujetas a la Ley Orgánica de Empresas

Públicas;

l) Las o los docentes e investigadores de las instituciones educativas públicas del

Sistema de Educación Superior; y,

m) El personal docente comprendido dentro del Sistema Nacional de Educación.

47

Las servidoras y servidores comprendidos en los literales de este artículo, no

estarán sujetos a los procesos de evaluación de desempeño determinados en esta

Ley, respecto de lo cual aplicarán sus propias leyes, en donde se contemplarán

sus procesos de evaluación. La servidora o servidor de carrera que de cualquier

modo o circunstancia ocupare uno de los puestos previstos en los literales a) y

b) de este artículo, perderá su condición de carrera y podrá ser libremente

removido, salvo que se desempeñe por encargo, subrogación o nombramiento

provisional. Lo establecido en los capítulos 2 y 3 del Título II de esta ley será de

observancia obligatoria bajo todos los regímenes previstos en la misma.

"LEY DE PERSONAL DEL CUERPO DE VIGILANCIA DE LA

COMISIÓN DE TRÁNSITO DEL GUAYAS"

Título I GENERALIDADES

Capítulo I

FINALIDADES DE ESTA LEY

Art. 1.- La ley de Personal del Cuerpo de Vigilancia de la Comisión de Tránsito del

Guayas tiene por objeto: regular la actividad profesional de sus miembros,

garantizar su estabilidad y propender a su perfeccionamiento y superación.

Capítulo II DE LA CLASIFICACIÓN DEL PERSONAL

Art. 2.- El personal del Cuerpo de Vigilancia de la comisión de Tránsito del Guayas

se divide en oficiales y tropa; los oficiales a su vez se dividen en oficiales

subalternos; y, la tropa en clases y vigilantes.

Art. 3.- El grado determina la función del personal de acuerdo a la clasificación

siguiente:

1.- OFICIALES SUPERIORES

a) Prefecto Comandante

b) Prefecto Jefe

c) Sub Prefecto

2.- OFICIALES SUBALTERNOS

a) Inspector

b) Sub Inspector 1o

c) Sub Inspector 2o

3.- ASPIRANTES A OFICIALES

a) Cadetes de Tránsito

48

4.- TROPA CLASES

a) Sub Oficial Primero

b) Sub Oficial Segundo

c) Sargento Primero

d) Sargento Segundo

e) Cabo Primero

f) Cabo Segundo

5.- VIGILANTES

a) Vigilantes de Tránsito

6.- ASPIRANTES A VIGILANTES

a) Aspirantes Oficial, es la denominación genérica que distingue al

personal que posee grado de Sub Inspector 2º a, Prefecto Comandante.

Cadete de Tránsito, es la denominación que corresponde al personal que

se incorpora a los cursos de la Escuela de Formación de Oficiales. Tropa,

es la denominación genérica que distingue al personal que posee grado de

Vigilante a Sub Oficial 1º de Tránsito.

Aspirante a Vigilante, es la denominación que corresponde al personal que

se incorpora a los cursos de la Escuela de Formación de Vigilantes de

Tránsito.

Art. 4.- El grado caracteriza a los Oficiales y Miembros de Tropa que han sido

dados de alta como tales por el Directorio de la Comisión de Tránsito del Guayas

y publicado en la Orden General del Cuerpo.

Art. 5.- El alta otorga carácter profesional permanentemente a los miembros del

Cuerpo de Vigilancia y les da derecho a pertenecer al Orgánico del Cuerpo. Este

carácter se lo pierde únicamente:

a) Por renuncia de la nacionalidad ecuatoriana;

b) Por traición a la Patria declarada ilegalmente; y,

c) Por dejar de pertenecer al Orgánico del Cuerpo, sin haberse hecho

acreedor a su retiro de acuerdo a esta Ley y sus reglamentos.

El Oficial que fuere dado de alta recibirá el despacho correspondiente de acuerdo

a su grado.

49

Art. 6.- El Alta que acredita grado en el Cuerpo de Vigilancia de la Comisión de

Tránsito del Guayas, únicamente se concederá al ciudadano ecuatoriano por

nacimiento y será otorgado por el Directorio de la Institución.

Art. 7.- Son miembros del Cuerpo de Vigilancia, los egresados de la Escuela de

Formación, cuya función específica es dirigir, controlar y organizar el tránsito

terrestre en la Provincia del Guayas.

Capítulo V

DE LA SELECCIÓN Y DEL INGRESO

Art. 14.- El ingreso al Orgánico del Cuerpo de Vigilancia de la Comisión de

Tránsito del Guayas, se hará únicamente por incorporación de los alumnos

egresados de la Escuela de Formación y Capacitación para Oficiales y Tropa de

dicho curso, según su reglamento. Será requisito indispensable para ingresar a la

Escuela de Formación tener un mínimo de 21 y un máximo de 25 años de edad.

El ingreso será por el sistema de alta y la separación o retiro, por el sistema de

baja.

Art. 15.- El Comando del Cuerpo seleccionará los candidatos para ingresar a la

Escuela de Formación y Capacitación del Cuerpo de Vigilancia, pero el único

facultado para resolver definitivamente, es el Directorio de la Institución, previo

informe de la Comisión de Estudio, Becas y Sanciones.

Art. 16.- Para llenar las vacantes de oficiales y miembros de tropa del Cuerpo de

Vigilancia, se tomará en cuenta a los aspirantes que hayan reunido todos los

requisitos establecidos por esta Ley y los reglamentos respectivos.

Art. 17.- Para ser oficial de fila, se requiere por lo menos, título de Bachiller y para

ser Vigilante de fila, haber terminado el Ciclo Básico.

Art. 18.- Los aspirantes que aprobaren el curso para Oficiales de fila, egresarán

con el grado de Sub Inspector 2º de Tránsito. Los que aprobaren el Curso de

Vigilantes de fila, egresarán con el grado de Vigilantes de Tránsito. Para ingresar

en calidad de músico de la Institución, dada su especialidad será necesario por lo

menos un curso de dos meses sobre conocimientos de leyes y reglamentos

institucionales sin perjuicio de presentar su título de músico y cumplir con los

demás requisitos establecidos en esta Ley y en el reglamento de la Escuela de

Formación.

50

Art. 19.- Los miembros del Cuerpo de Vigilancia, egresados de la Escuela de

Formación dados de alta como tales, estarán obligados a prestar sus servicios a

la Comisión de Tránsito del Guayas por un tiempo mínimo de tres años, sin cuya

base no podrán ser dados de baja por solicitud voluntaria.

Art. 20.- Los oficiales y miembros de tropa recién ingresados al Cuerpo de

Vigilancia, pasarán por un período de prueba de un año, ganando todos los

emolumentos de acuerdo a su grado, durante el cual y si mediante una evaluación

razonada de sus servicios, demuestran incompetencia profesional o mala

conducta comprobada, conforme a lo establecido en el Reglamento de Disciplina

y Reglamento de Régimen Interno, el Comando solicitará la baja por intermedio

del Concejo de Disciplina. Pasado el tiempo de prueba, se estará a lo dispuesto

en el artículo anterior. Los emolumentos comprenderán, sueldo, rancho, viáticos,

subsidio familiar, subsidio de antigüedad, subsidio el costo de la vida y más

beneficios económicos a que todo miembro del Cuerpo de Vigilancia tiene derecho

de acuerdo a las leyes y reglamentos vigentes.

Art. 21.- El personal de tropa podrá ingresar a la Escuela de Formación y

Capacitación de Oficiales, sujetándose a las normas y requerimientos que

contemplaren para estos casos los reglamentos respectivos.

Art. 22.- No podrán reingresar al Cuerpo de Vigilancia quienes por cualquier

motivo hubieren dejado de pertenecer a él. Capítulo VI DEL ADIESTRAMIENTO

DEL PERSONAL

Art. 23.- El adiestramiento es el perfeccionamiento que se les da a los miembros

del Cuerpo de Vigilancia, con el objeto de alcanzar mayor eficacia en los servicios,

tanto física como intelectual.

Art. 24.- Habrá dos clases de adiestramiento y especialización en técnicas de

tránsito: a) Las que impartan los superiores a los subordinados en el trabajo

práctico; y, b) El que reciban los oficiales y miembros de tropa en los cursos

organizados con ese fin, sea en la Escuela de Formación y Capacitación, como

en otros lugares de la ciudad, del país o del extranjero.

Art. 25.- Los cursos a que se refiere el artículo anterior, son de asistencia

obligatoria para los miembros del Cuerpo de Vigilancia que hayan sido

seleccionados y durante ellos percibirán emolumentos establecidos en el

Presupuesto de la Institución.

51

Art. 26.- Al Directorio de la Institución le corresponde aprobar estos cursos de

acuerdo al reglamento de la materia, previo informe de la Comisión de Estudios,

Becas y Sanciones a solicitud del Comando.

Art. 27.- El Comando del Cuerpo de Vigilancia está obligado a instruir a todo el

personal con respecto a sus deberes, derechos y prohibiciones que competa a

cada jerarquía de oficiales y tropa de acuerdo al Reglamento de Disciplina y de

Régimen interno del Cuerpo de Vigilancia.

Art. 28.- La Comisión de Tránsito del Guayas, procurará enviar al exterior oficiales

y miembros de tropa en giras de observación o seminarios a través de becas o

intercambios, para recibir cursos de especialización en materia de tránsito, con el

fin de obtener un mejor nivel técnico profesional dentro del ámbito que les tocare

desempeñar.

Art. 29.- Los miembros del Cuerpo de Vigilancia que se hicieren acreedores a las

becas, serán propuestos por el Comando del Cuerpo de Vigilancia, tomando en

consideración la antigüedad, los méritos que hubieren demostrado durante su

carrera profesional y con aprobación de la Comisión de Estudios y Becas y del

Directorio de la Comisión de Tránsito del Guayas. Anualmente se organizarán

cursos para el Cuerpo de Vigilancia, los mismos que serán dictados por los

oficiales y miembros de tropa que hubieren viajado al exterior becados y se

propiciará la presencia de técnicos extranjeros en materia de tránsito, así mismo,

para el cumplimiento de lo establecido en éste artículo, deberá fijarse anualmente

una partida en el presupuesto de la Institución. Los oficiales y miembros de tropa

que se hubieren beneficiado con las disposiciones del Art. 28, deberán

permanecer al servicio de la Institución, por lo menos 4 años subsiguientes a la

aprobación del curso de especialización.

Capítulo VII DE LA CALIFICACIÓN

Art. 30.- La calificación anual es la evaluación de la constancia y de las cualidades

y rendimiento profesional de los miembros del Cuerpo de Vigilancia como requisito

previo a su selección de acuerdo a lo previsto en esta Ley y sus reglamentos.

Art. 31.- Los miembros del Cuerpo de Vigilancia serán calificados por su

capacidad profesional.

52

Art. 32.- Los miembros del Cuerpo de Vigilancia que se encuentren en servicio de

fila, serán calificados por los jefes de escuadrones; los que laboran

administrativamente serán calificados por el Jefe de Departamento; los oficiales

superiores y los jefes departamentales serán calificados por el Comando.

Art. 33.- Las vacantes que se produjeren en el Cuerpo de Vigilancia, serán

llenadas conforme a las disposiciones de esta Ley y su reglamento.

Art. 34.- En los cursos para ascensos al nuevo grado o en la prueba que disponga

la Comisión de Estudios, Becas y Sanciones, es indispensable la plena

comprobación de la capacidad profesional.

Art. 35.- El tiempo de servicio en el grado para los Oficiales se computará de

acuerdo a lo establecido en el Art. 34 de esta Ley y se hará sobre la siguiente

escala:

a)Sub Inspector Segundo 6 años

b)Sub Inspector Primero 6 años

c)Inspector 6 años

d) Sub Prefecto 5 años

e)Prefecto 4 años

f)Prefecto Jefe 4 años

g)Prefecto Comandante 4 años

En el grado de Prefecto Comandante, cumplido el tiempo de servicio señalado en

esta Ley (4 años) será automáticamente colocado en transitoriedad por el

Ministerio de la Ley, previo su retiro del Orgánico del Cuerpo.

Art. 36.- El tiempo de servicio para la tropa se computará de acuerdo a lo

establecido en el Art. 34 de esta Ley, se hará sobre la siguiente escala:

a)Vigilante 6 años

b)Cabo Segundo 6 años

c)Cabo Primero 5 años

d)Sargento Segundo 5 años

e)Sargento Primero 5 años

f)Sub Oficial Segundo 4 años

g)Sub Oficial Primero 4 años

53

Art. 37.- Entre Miembros del Cuerpo de Vigilancia ascendidos en igual fecha a un

mismo grado, se conservará la antigüedad obtenida en el grado inmediato inferior;

la antigüedad obtenida como egresado de la Escuela de Formación no se perderá,

excepto en caso de ser reprobado en los exámenes de ascenso. Art. 38.- El

miembro del Cuerpo de Vigilancia que no haya alcanzado a completar el puntaje

mínimo para ascender en la primera oportunidad, tendrá una segunda oportunidad

para intentarlo, luego de lo cual, si no aprueba será colocado en transitoriedad por

la capacidad profesional. No se contará como oportunidad, cuando el miembro del

Cuerpo de Vigilancia no se haya podido presentar a los exámenes por razones de

imposibilidad física comprobada o de fuerza mayor

LEY DE COMERCIO ELECTRÓNICO, FIRMAS ELECTRÓNICAS Y

MENSAJES DE DATOS"

Art.1.-Objeto de la Ley.-Esta Ley regula los mensajes de datos, la firma

electrónica, los servicios de certificación, la contratación electrónica y telemática,

la prestación de servicios electrónicos, a través de redes de información, incluido

el comercio electrónico y la protección a los usuarios de estos sistemas.

Art.2.- Reconocimiento jurídico de los mensajes de datos.- Los mensajes de datos

tendrá igual valor jurídico que los documentos escritos. Su eficacia, valoración y

efectos se someterá al cumplimiento de lo establecido en esta Ley y su

reglamento.

Art.3.- Incorporación por remisión.-Se reconoce validez jurídica a la información

no contenida directamente en un mensaje de datos, siempre que figure en el

mismo, en forma de remisión o de anexo accesible mediante un enlace electrónico

directo y su contenido sea conocido y aceptado expresamente por las partes.

Art.4.- Propiedad Intelectual.- Los mensajes de datos estarán sometidos a las

leyes, reglamentos y acuerdos internacionales relativos a la propiedad intelectual.

Art.5.- Confidencialidad y reserva.- Se establecen los principios de

confidencialidad y reserva para los mensajes de datos, cualquiera sea su forma,

medio o intención. Toda violación a estos principios, principalmente aquellas

referidas a la intrusión electrónica, transferencia ilegal de mensajes de datos o

violación del secreto profesional, será sancionada conforme a lo dispuesto en esta

Ley y demás normas que rigen la materia.

54

Art.6.- Información escrita.- Cuando la Ley requiera u obligue que la información

conste por escrito, este requisito quedará cumplido con un mensaje de datos,

siempre que la información que éste contenga sea accesible para su posterior

consulta.

Art.7.- Información original.- Cuando la Ley requiera u obligue que la

información sea presentada o conservada en su forma original, este requisito

quedará cumplido con un mensaje de datos, si siendo requerido conforme a la

Ley, puede comprobarse que ha conservado la integridad de la información, a

partir del momento en que se generó por primera vez en su forma definitiva, como

mensaje de datos.

PREGUNTAS A CONTESTARSE

¿El diseño de una aplicación web para gestionar la información de los aspirantes

para ingresar a la Comisión de Tránsito del Ecuador a través de Escuela de

Formación de Oficiales y tropa, mejorará el proceso de selección de los aspirantes

a vigilantes u oficiales?

¿El diseño de una aplicación web para gestionar las actividades académicas de

la EFOT permitirá posteriormente desarrollar de manera clara el sistema?

¿Los modelos desarrollados en la presente investigación servirán de insumo a los

desarrolladores para desarrollar e implementar el sistema?

55

VARIABLES DE LA INVESTIGACIÓN

Variable independiente

Proceso de selección de aspirantes para formar parte de la Comisión de Tránsito

del Ecuador.

Variable dependiente

Gestión de los datos de los aspirantes a oficiales y vigilantes a través de un

sistema web.

Gestión de los datos académicos en los procesos de capacitación y ascenso a

través de un sistema web.

56

DEFINICIONES CONCEPTUALES

Sistema: Conjunto de elementos que tienen una función específica y que

interactúan entre sí para alcanzar una meta común.

Software: parte lógica de un sistema computacional. Conjunto de instrucciones

lógicamente estructurados que desarrollan diversas actividades de tratamiento de

datos y que han sido escritos en un lenguaje de programación específico.

Conjunto de programas computacionales que realizan la gestión de datos de un

sistema.

Hardware. Todos los componentes físicos sobre el cual se instalan los programas

necesarios para realizar ciertas actividades diversas.

Proceso. Conjunto de pasos/ actividades lógicamente ordenados que permiten

transformar entradas (insumos, materia prima) en salidas (productos o servicios).

Modelo: Representación gráfica de un elemento real donde se elimina las

ambigüedades o los elementos que no son relevantes para el propósito específico

de análisis.

Método: Un método de ingeniería del software es un enfoque estructurado para

el desarrollo de software cuyo propósito es facilitar la producción de software de

alta calidad de una forma costeable

CASE (Ingeniería del Software Asistida por Computadora): comprende un

amplio abanico de diferentes tipos de programas que se utilizan para ayudar a

las actividades del proceso del software, como el análisis de requerimientos, el

modelado de sistemas, la depuración y las pruebas.

Atributo: Característica que forma parte de un objeto o conjunto de objetos y que

puede tomar un valor en un instante específico de tiempo.

57

Método “funcionalidad de la clase”: Funcionalidad de un objeto que modifica

los atributos de otro objeto o ejecuta cierta lógica que le compete a los objetos al

cual pertenece.

58

CAPÍTULO III

PROPUESTA TECNOLÓGICA

Análisis de Factibilidad

Factibilidad Operacional

El diseño de una aplicación web, para la gestión de la información de los

aspirantes a ingresar a la comisión de tránsito del Ecuador que permita

informatizar el proceso de reclutamiento, selección y formación en todos los

aspectos supone para el personal técnico y administrativo de la Escuela de

Formación de oficiales y Tropa una buena noticia ya que facilitaría, cuando se

implemente, las actividades que realizan recurrentemente en cada una de las

convocatorias.

El personal académico y administrativo a cargo de los procesos de capacitación y

ascenso mostraron su complacencia en la idea de desarrollar una aplicación que

les permita informatizar todos los componentes académicos que les permita

manejar toda su información a través de un sistema. Al realizar los procesos de

calificación, emisión de actas, calificaciones etc. de manera manual, estos se

pueden tornar largos y tediosos.

Una aplicación de este tipo aporta, según la información de los directivos de la

EFOT, en los resultados de eficiencia administrativa ya que los funcionarios

podrán dedicar su tiempo de manera adecuada en otras tareas importantes dentro

de la institución ya que el sistema realizará todas las actividades que no necesiten

la participación humana de manera permanente. Los responsables de la Escuela

de Formación han participado de manera activa en el levantamiento de

información por lo cual se considera que promoverán el desarrollo de la aplicación

planteada.

59

Factibilidad técnica

Para la implementación del proyecto se necesita tener en la institución un servidor

web con las siguientes características mínimas.

Procesador Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz

Memoria RAM 16.0 GB (15.8 GB Usable)

Disco Duro de 1 TB

Adicionalmente, se necesita un servidor de base de datos con las siguientes

características:

Procesador Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz

Memoria RAM 16.0 GB (15.8 GB Usable)

Disco Duro de 2 TB

Para poder gestionar de manera adecuada los archivos que vas a ser subidos por

los aspirantes se requiere de un servidor de documentos el cual debe tener las

siguientes características mínimas.

Procesador Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz

Memoria RAM 16.0 GB (15.8 GB Usable)

Disco Duro de 4 TB

La Escuela de Formación de Oficiales y Tropa no posee un centro de datos ni los

equipos necesarios para alojar una aplicación de este tipo sin embargo, utiliza los

servicios informáticos de la Comisión de Tránsito del Ecuador que tiene su propia

infraestructura tecnológica administrada por la dirección de Tecnologías de la

Información la que le podría proveer de la infraestructura requerida para la

implementación de este proyecto.

Los departamentos administrativos poseen computadores personales para

realizar su trabajo diario. Así mismo todo el personal está capacitado en el uso de

las herramientas ofimáticas básicas que utilizan diariamente. Estas computadoras

poseen las licencias de ®Microsoft para el sistema operativo Windows 7 y el

60

paquete de office 2010. Estos computadores serán utilizados como clientes en la

estructura propuesta.

En cuanto a software, para la implementación del proyecto se necesitan de los

siguientes programas computacionales y/o servicios:

Sistema Operativo Linux Centos

Servidor de aplicaciones (Apache Tomcat)

Servidor de correos

Servidor de Archivos

Factibilidad Legal

El sistema planteado no incumple con ninguna normativa legal vigente en el

Ecuador y permite a la institución proveer servicios, en este caso el registro de los

aspirantes a través de la web está alineada a las políticas del estado ecuatoriano

en el sentido que las instituciones públicas, haciendo uso de las herramientas

informáticas, deben poner a disposición de la ciudadanía consultas y servicios a

través del internet. El estado ecuatoriano a través del Plan Nacional de Gobierno

electrónico busca promover el uso de las Tecnologías de la Información y

Telecomunicación en beneficio de los ciudadanos y hacer de las instituciones

públicas entidades eficientes en el uso de sus recursos.

La implementación del proyecto no viola leyes, estatutos, reglamentos internos,

políticas institucionales de la Comisión de Tránsito del Ecuador ni de la Escuela

de Formación de Oficiales y Tropa.

61

Factibilidad Económica

El diseño de la aplicación propuesta no implica costos operativos ni de inversión

para la Escuela de Formación de Oficiales y Tropa, ya que ha sido desarrollado

como parte de un proyecto de titulación y los autores de dicho estudio no van a

tener un emonumento de parte la institución. Los costos relacionados al estudio

de la presente propuesta se pueden resumir en la siguiente tabla.

Tabla 2 - Tabla de costos – inversión

EGRESOS DÓLARES

Suministros de oficina $ 50,00

Fotocopias e impresiones $100,00

Libros y documentos $100,00

Investigadores( horas de trabajo ) $2800,00

Empastado, anillado de tesis de grado $100,00

TOTAL $3150,00

Elaborado: Investigadores. Fuente: Datos de la investigación.

Tomando en consideración los equipos y licencias necesarias para la

implementación del proyecto se han proyectado los costos de inversión que se

resumen en la siguiente tabla:

Tabla 3 - Costos de inversión

IMPLEMENTACIÓN

EGRESOS DÓLARES POR

UNIDAD

CANTIDAD TOTAL

Servidor HP ProLiant ML310e Gen8 v2 - Servidor (3.1 GHz, Intel Xeon, E3-1220, 2000 GB, 1000 GB, SATA)

$3.000 3

$9.000

Procesador Intel® Core™ i5-6200U (3M Cache, up to 2.80 GHz) memoria RAM 8gb Adv ECC, Disco Duro 500GB 7.2K RPM SATA 3.5" Hot Plug Hard Drive, DVD-ROM, SATA, Internal, tarjeta de red Embedded Broadcom® NetXtreme II 5709 Gigabit Ethernet NIC

$1.100 4 $4.400

Licencia del sistema operativo 0 0 0

TOTAL $ 4.100 $ 13.400

Elaborado: Investigadores Fuente: Datos de la investigación.

62

LEVANTAMIENTO DE PROCESOS

Como parte del proyecto de titulación se realizaron visitas a las instalaciones de

la Escuela de formación de Oficiales y Tropa, lugar donde se realizan todas las

actividades administrativas y la ejecución de los procesos que permiten formar,

capacitar y especializar al personal uniformado de la Comisión de Tránsito del

Ecuador, para obtener la información de las tareas que se realizan dentro de la

institución. Se realizaron entrevistas con el personal administrativo y con los

directivos, haciendo posteriormente el seguimiento de cada uno de los procesos

para definir detalladamente cada una de las tareas que se realizan para poder

cumplir con los objetivos institucionales.

La cadena de valor de la Escuela de Formación de Oficiales y Tropa, se

caracteriza por los siguientes macro procesos:

En el proceso de “Reclutamiento” se encuentra inmersa la “convocatoria” en la

cual, los directivos de la institución disponen la comunicación pública en los

medios de comunicación masivos y los canales de comunicación con los que

cuenta la institución (página web, carteleras, redes sociales) a través de la cual la

Escuela de Formación de Oficiales y Tropa invita a los jóvenes ecuatorianos a ser

parte del personal uniformado de la Comisión de Tránsito del Ecuador.

Reclutamiento Formación Especialización Ascenso

63

Procesos actuales.

Convocatoria

Imagen 8 Flujo del proceso de convocatoria - Actual

Fuente: Investigación Autor: Investigadores

En el proceso de convocatoria, el Director de la Escuela de Formación dispone

iniciar el proceso de selección para los aspirantes a formar parte de la Comisión

de Tránsito del Ecuador e iniciar el proceso de registro, envío de documentación,

validación y calificación de los jóvenes interesados en participar como aspirantes

del proceso.

Cabe destacar que actualmente el registro se hace a través de un formulario web

básico publicado en la página web de la Escuela de Formación y que la

documentación es remitida a la institución a través de Correos del Ecuador. La

verificación y validación de la documentación la realiza personal uniformado

especializado en dichas investigaciones de campo.

El proceso debe ser cumplido en el plazo estipulado por la disposición de las

autoridades de la Comisión de Tránsito del Ecuador y el Director de la escuela de

Formación definida en la convocatoria correspondiente.

64

Proceso de Reclutamiento

Imagen 9 - Flujo de proceso de reclutamiento

Fuente: Investigación Autor: Investigadores

El proceso de reclutamiento es ejecutado para que los aspirantes que fueron

declarados aptos en la etapa de convocatoria, puedan someterse a las distintas

pruebas que permitirá verificar que cumplen con los requisitos físicos,

académicos, médicos y psicológicos que requiere la Comisión de Tránsito del

Ecuador.

En este proceso los aspirantes a ingresar a la escuela de formación se someten

a las distintas pruebas que son:

Médicas

Físicas

Psicológicas (entrevista personal)

Cada uno de los profesionales que son designados para realizar las pruebas a los

aspirantes realizan un informe escrito que es enviado a la/las asistentes

administrativas que van actualizando un archivo digital que se almacena en las

computadoras en las cuales trabajan. Esta actualización está expuesta al

cometimiento de errores humanos por cuanto deben leer el informe de los

profesionales y registrar la nota correspondiente en el archivo.

Una vez completada cada una de las pruebas se realiza un informe al director de

la Escuela de Formación de Oficiales y Tropa para que autorice la ejecución de la

65

siguiente etapa. Al finalizar el proceso, el director de la Escuela informa a las

autoridades de la Comisión de tránsito del Ecuador con los resultados finales.

Proceso de Formación

Imagen 10 Flujo de proceso de Formación

Fuente: Investigación Autor: Investigadores

El proceso de formación de Oficiales y tropa inicia una vez que ya se ha

comunicado acerca de los resultados de la etapa de reclutamiento y se han

definido los aspirantes que fueron declarados aptos para acceder al

proceso de formación. En este proceso se realiza el acuartelamiento de los

aspirantes y durante el tiempo establecido en las normas internas se dicta

clases formativas en las diferentes áreas del conocimiento que se

encuentra aprobados en las mallas curriculares de cada uno de los cursos.

Durante el tiempo que dura el calendario académico, se dictan clases de

formación académica y legal de todos los aspectos que los aspirantes

deben conocer para el desarrollo de sus actividades profesionales.

El calendario académico está formado por un conjunto de materias que son

dictadas por profesionales de cada campo que son los encargados de

evaluar los conocimientos adquiridos por los aspirantes e informar a las

autoridades de la institución, mediantes actas de calificación, los resultados

académicos correspondientes.

66

Al finalizar el proceso, el Director de la Escuela de Formación de Oficiales

y Tropa informa a las autoridades de la Comisión de Tránsito del Ecuador

acerca de los resultados de la formación, de acuerdo a las normas internas

de aprobación correspondiente.

Especialización

Imagen 11 Flujo de Proceso de Especialización

Fuente: Investigación Autor: Investigadores

El proceso de especialización tiene como objetivo el de preparar a los

uniformados, miembros de la Comisión de Tránsito del Ecuador, en áreas

específicas en los que se debe aplicar los conocimientos teóricos y técnicos que

tienen que ver con el transporte, movilidad, seguridad vial, e investigación de

accidentes de tránsito, entre otras áreas.

Para lograr lo anterior, las autoridades de la Escuela de Formación de Oficiales y

Tropa, previa disposición de las autoridades de la Comisión de Tránsito del

Ecuador, dispone la apertura de los cursos de especialización los cuales deben

estar previamente aprobados. Los uniformados que quieren acceder a estos

cursos, actualmente se registran en las instalaciones de la EFOT y en base a esta

información la/las asistentes administrativas realizan los paralelos

correspondientes para cubrir la demanda. La Escuela de Formación define la

cantidad de cupos que se apertura en cada uno de los cursos de especialización.

67

Una vez que los uniformados se han registrado y entregado los documentos

solicitados, deberán asistir a las clases teóricas – prácticas planificadas de

acuerdo al calendario académico. Las clases son dictadas por especialistas, los

cuales evalúan y califican el rendimiento académico de los uniformados lo cual es

informado a las autoridades de la escuela a través de las actas de calificación

correspondientes.

Al finalizar el curso, el director de la Escuela de Formación informa a las

autoridades de la Comisión de Tránsito del Ecuador acerca de los resultados del

mismo.

Ascenso

Imagen 12 Flujo de proceso de Ascenso

Fuente: Investigación Autor: Investigadores

El proceso de ascenso tiene como propósito cumplir con lo que dispone la

reglamentación correspondiente en cuanto a la promoción y grados que deben ir

adquiriendo los uniformados de la CTE en base a sus méritos. El proceso de

ascenso inicia con el pedido del Director de la Escuela de Formación a la Dirección

de Recursos Humanos de la CTE para que se emita el listado de uniformados de

la institución que han cumplido con los plazos y que están aptos para optar por la

promoción de su grado.

68

Una vez que se tiene el listado, se realiza una convocatoria a todos los

uniformados declarados aptos para acceder al ascenso, los cuales tienen que

pasar por el proceso de reclutamiento que desarrolla las pruebas médicas, físicas

y psicológicas al personal.

Los uniformados que aprueben la fase de reclutamiento, pasan a un curso donde

se les dicta una serie de materias teóricas y prácticas las cuales son de obligatoria

aprobación para poder cumplir con la normativa vigente. Las clases son dictadas

por profesionales expertos en el área del conocimiento específico según la catedra

e informan a las autoridades, a través de las actas de calificaciones, el rendimiento

de cada uno de los uniformados.

Al finalizar el curso de ascenso, el director de la Escuela de Formación de Oficiales

y Tropa informa a las autoridades de la CTE los resultados que se ha obtenido de

este proceso para los trámites de ley correspondientes.

69

Procesos propuestos.

Convocatoria

Imagen 13 Flujo de proceso Convocatoria - Propuesto

Fuente: Investigación Autor: Investigadores

Se propone ajustar el proceso de convocatoria para que sean los aspirantes

quienes registren toda la información requerida por la Escuela de formación

y, adicionalmente, suba los documentos digitalizados a través del sistema

web.

Para acceder a este registro web el aspirante deberá obtener una cuenta

en el sistema, un funcionario deberá validar los documentos básicos

personales y luego de aquello se le dará una clave con la cual podrá

acceder a todos los servicios en línea de la institución y, entre ellos, el

registro a una convocatoria.

Las actividades de verificación documental e investigación en sitio se

mantienen y se provee a los funcionarios de una interfaz para registrar los

resultados de la validación e investigación.

70

Reclutamiento

Imagen 14 Flujo de Proceso Reclutamiento - Propuesto

Fuente: Investigación Autor: Investigadores

El proceso de reclutamiento sufre cambios en el aspecto de que cada uno

de los responsables de realizar las evaluaciones (médicas, físicas,

psicológicas) tendrá un usuario y contraseña para poder acceder al sistema

y ellos podrán registrar el resultado de la prueba. Con este cambio se

disminuye la carga de trabajo de la/las asistentes administrativas y evitaría

errores de digitación por la cantidad de evaluaciones que antes ingresaban.

Así mismo, cada uno de los responsables de realizar las pruebas podrán

consultar las evaluaciones por el realizada para confirmar las notas u

observaciones registradas.

Los resultados finales del proceso serán obtenidos del sistema y este

servirá para realizar el informe de resultados que el Director de la Escuela

de Formación debe enviar a las autoridades de la Comisión de Tránsito del

Ecuador para los trámites de ley.

71

Formación

Imagen 15 Flujo de proceso Formación- Propuesto

Fuente: Investigación Autor: Investigadores

El proceso de formación sufre cambios en cuanto a que, una vez que ya se

tienen los aspirantes aprobados para el ingreso al proceso de formación,

estos se asignan a los paralelos correspondientes que se creen, según la

capacidad de cada uno de ellos que se haya configurado en el sistema.

Adicionalmente todas las comunicaciones de la institución con los

aspirantes antes y después del proceso, se realizará a través de

notificaciones del sistema informático.

El docente que dicta cada una de las materias tendrá un usuario y una clave

con lo cual podrá registrar a través de su interfaz correspondiente las notas

de los estudiantes, que podrán ser visualizadas una vez que se culmine el

ingreso, por las autoridades o personal autorizado a visualizar los reportes

de notas de los aspirantes.

Al finalizar el proceso, se desarrollará un informe que debe ser enviado por

el Director de la Escuela de Formación a las autoridades de la Comisión de

Tránsito del Ecuador que tendrá como sustento la información almacenada

en el sistema.

72

Especialización

Imagen 16 Flujo de proceso Especialización - Propuesto

Fuente: Investigación Autor: Investigadores

Este proceso sufre cambios en lo que se refiere al registro ya que, una vez que

los uniformados que quieran acceder a estos cursos deberán realizar su

inscripción a través de la web con el mismo usuario y clave que ya poseen.

Adicionalmente, los docentes que imparten las clases también poseen una clave

para acceder al sistema por lo cual podrán registrar las asistencias y notas de

cada estudiante directamente, aliviando la carga de trabajo de la/las asistente

administrativo que hasta ahora es la encargada de asentar las notas con la

posibilidad de cometer errores de ingreso de información a sus archivos.

Adicionalmente se agrega la comunicación que se realizará a través del sistema

en los pasos en los que se requiera comunicar al aspirante del curso de

especialización alguna novedad.

La información que sirve de insumo para que el Director de la Escuela de

Formación de oficiales y Tropa informe a las autoridades de la Comisión de

Tránsito del Ecuador, será obtenida del sistema a través de los reportes

correspondientes.

73

Ascenso

Imagen 17 Flujo de proceso Ascenso - Propuesto

Fuente: Investigación Autor: Investigadores

El proceso de ascenso utiliza el proceso de reclutamiento propuesto, es

decir que los encargados de realizar las pruebas médicas, físicas y

psicológicas serán los encargados de registrar el resultado de la evaluación

respectiva. Adicionalmente, se agrega la notificación automática a los

aspirantes de los eventos que ocurren en la aplicación.

Así mismo, el registro de notas y los reportes correspondientes a dichas

calificaciones se los obtiene a través del sistema para que el director de la

Escuela de Formación pueda informar a las autoridades de la Comisión de

Tránsito del Ecuador sobre los resultados finales para los trámites de ley.

74

MODELOS DE ANÁLISIS

1. Diagramas de casos de uso

Imagen 18 - (Caso de uso - Sistema Integrado EFOT)

ADMINISTRADOR

GESTIONAR USUARIOS Y PERMISOS

GESTIONAR PROCESOS

GESTIONAR REPORTES

GESTIONAR REGISTRO WEB

OPERADORDE EFOT

GESTION RECLUTAMIENTO

PROFESOR INSTRUCTOR

ASPIRANTE

GESTION ACADEMICA

Fuente: Investigación Autor: Investigadores

75

1.1 ADMINISTRACION

1.1.1 Usuarios

Imagen 19 - (Caso de uso - Usuarios)

ADMINISTRADOR

Asignar rol

Crear Usuario

Buscar usuario

<<incluir>>

Bloquear usuario

Mantenimiento usuario

<<incluir>><<incluir>>

OPERADOR EFOT

Desbloquear usuario

<<incluir>>

Fuente: Investigación Autor: Investigadores

76

Tabla 4 - Usuario

CU001 CREAR USUSARIOS

CASO DE USO CREAR USUARIOS

ACTORES Usuario Administrador

OBJETIVO Crear y dar mantenimiento de los usuarios del sistema.

DESCRIPCION Crear nuevos usuarios y dar mantenimiento de los usuarios del sistema existentes.

PRECONDICIONES

POSTCONDICIONES Usuario creado

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo Usuario.

2. El sistema muestra el formulario con los datos que necesita para crear el nuevo usuario.

3. El sistema valida los datos ingresados por el usuario.

4. El Usuario Administrador introduce el número de cédula.

5. El sistema valida que el número de cédula sea válido. Valida que no se haya creado previamente en el sistema.

6. El sistema genera una contraseña aleatoria 7. El sistema cifra la contraseña del nuevo

usuario. 8. El sistema obtiene la contraseña cifrada del

usuario. 9. El sistema emite un correo electrónico con

la contraseña del nuevo usuario.

FLUJO ALTERNATIVO

(3.1). En caso de existir datos inválidos, el sistema muestra una alerta. (4.1). En caso de existir el usuario en el sistema, se muestra una alerta. (4.2). en caso que el número de cedula no sea válido, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

77

Tabla 5 - Cosultar usuario

CU002 CONSULTAR USUSARIO

CASO DE USO CONSULTAR USUARIO

ACTORES Usuario Administrador

OBJETIVO Buscar datos del usuario, para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del usuario, dar mantenimiento de usuario seleccionado a nivel de administrador

PRECONDICIONES Seleccionar un usuario.

POSTCONDICIONES Mostar los datos del usuario. Mantenimiento del usuario realizado.

FLUJO NORMAL

1. El usuario selecciona un usuario del sistema, le da clic en el botón consultar.

2. El sistema muestra los datos completos del usuario, además sus roles y permisos.

3. El sistema permite al administrador realizar las siguientes opciones: Asignar roles. Permisos. Editar datos del usuario. Eliminar usuario. Bloquear usuario. Cambiar contraseña. Desbloquear usuario.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el usuario consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

78

Tabla 6 – Mantenimiento Usuario

CU003 MANTENIMIENTO DE USUARIO

CASO DE USO MANTENIMIENTO USUARIO

ACTORES Administrador, Operador EFOT

OBJETIVO Mantenimiento de los usuarios del sistema.

DESCRIPCION Actualizar datos de un usuario de sistema.

PRECONDICIONES Seleccionar un usuario del sistema

POSTCONDICIONES Datos del usuario actualizados

FLUJO NORMAL

1. El operador EFOT selecciona su usuario del sistema, le da clic en el botón consultar.

2. El sistema muestra los datos completos del operador.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del usuario. Cambiar contraseña.

4. El operador EFOT no tiene acceso a otros usuarios para modificar su información.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el usuario consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

79

Tabla 7 - Bloquear usuario

CU004 BLOQUEAR USUARIO

CASO DE USO BLOQUEAR USUARIO

ACTORES Usuario Administrador

OBJETIVO Bloquear un usuario del sistema.

DESCRIPCION Bloquear un usuario del sistema para impedir su acceso al mismo.

PRECONDICIONES Seleccionar un usuario habilitado

POSTCONDICIONES Bloqueo del usuario

FLUJO NORMAL

1. El administrador selecciona un usuario habilitado del listado de usuarios del sistema.

2. El administrador selecciona la opción “Bloquear usuario”.

3. El sistema muestra un mensaje de confirmación.

4. El Usuario Administrador confirma la acción. 5. El sistema se encarga se inhabilitar el

usuario, lo cambia a estado de “Bloqueado”. 6. El sistema muestra el usuario seleccionado

como bloqueado, se habilita la opción “Desbloquear usuario”

FLUJO ALTERNATIVO

(4.1). En caso de cancelar acción, el sistema termina la acción sin efectuar cambios. (5.1). En caso de existir un error, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

80

Tabla 8 - desbloquear usuario

CU005 DESBLOQUEAR USUARIO

CASO DE USO DESBLOQUEAR USUARIO

ACTORES Usuario Administrador

OBJETIVO Desbloquear un usuario del sistema.

DESCRIPCION Desbloquear un usuario del sistema para permitir su acceso al sistema.

PRECONDICIONES Seleccionar un usuario inhabilitado

POSTCONDICIONES Desbloqueo del usuario

FLUJO NORMAL

1. El administrador selecciona un usuario inhabilitado del listado de usuarios del sistema.

2. El administrador selecciona la opción “Desbloquear usuario”.

3. El sistema muestra un mensaje de confirmación.

4. El Usuario Administrador confirma la acción. 5. El sistema se encarga se habilitar el usuario,

lo cambia a estado de “Desbloqueado”. 6. El sistema muestra el usuario seleccionado

como desbloqueado, se habilita la opción “Bloquear usuario”

FLUJO ALTERNATIVO

(4.1). En caso de cancelar acción, el sistema termina la acción sin efectuar cambios. (5.1). En caso de existir un error, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

81

1.1.2 Editar contraseña

Imagen 20 - (Caso de uso – cambiar contraseña)

Modificar conraseña

ADMINISTRADOR

OPERADOR DE EFOT

PROFESOR /INSTRUCTOR

ASPIRANTE

Fuente: Investigación Autor: Investigadores

82

Tabla 9 - Cambiar Contraseña

CU006 CAMBIAR CONTRASEÑA

CASO DE USO CAMBIAR CONTRASEÑA

ACTORES Usuario Administrador, operador EFOT, aspirante, profesor/instructor.

OBJETIVO Cambiar contraseña de un usuario

DESCRIPCION Cambiar contraseña de un usuario seleccionado.

PRECONDICIONES Seleccionar usuario.

POSTCONDICIONES Nueva contraseña

FLUJO NORMAL

1. El administrador selecciona un usuario del listado de usuarios del sistema.

2. El usuario selecciona la opción “Modificar Contraseña”.

3. El sistema muestra el formulario para cambiar la contraseña.

4. El usuario introduce la nueva contraseña. 5. El usuario confirma la nueva contraseña. 6. El usuario confirma acción. 7. El sistema cifra la nueva contraseña. 8. El sistema modifica la contraseña del

usuario

FLUJO ALTERNATIVO

(5.1) En caso de (contraseña no valida) el sistema

muestra una alerta.

(6.1). En caso de (cancelar acción) el sistema

termina la acción sin cambios.

(8.1). En caso de (coincidir el usuario seleccionado

con el usuario de acceso) tras modificar

contraseña, el sistema cierra sesión para que

acceda con la nueva contraseña.

(8.2). En caso de (error de actualización) el sistema

muestra una alerta.

Fuente: Investigación

Autor: Investigadores

83

1.1.3 Parámetros

Imagen 21 - (Caso de uso – Parámetros)

ADMINISTRADOR

Permiso usuario

Crear Parámetros

Buscar Parámetros

<<incluir>>

Mantenimiento Parametros

<<incluir>>

<<incluir>>

OPERADOR EFOT

Fuente: Investigación

Autor: Investigadores

84

Tabla 10 - Crear parámetros

CU007 CREAR PARAMETROS

CASO DE USO CREAR PARAMETROS

ACTORES Usuario Administrador

OBJETIVO Crear parámetros.

DESCRIPCION Crear nuevos parámetros para uso del sistema de los usuarios del sistema existentes.

PRECONDICIONES

POSTCONDICIONES Parámetro creado

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo Parámetro.

2. El sistema muestra el formulario con los datos que necesita para crear el nuevo parámetro.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el parámetro ya exista, el sistema muestra una alerta. (5.1). En caso de (error de actualización) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

85

Tabla 11 – Buscar parámetros

CU008 BUSCAR PARAMETROS

CASO DE USO CREAR PARAMETROS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar datos de parámetros, para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del usuario, dar mantenimiento de usuario seleccionado a nivel de administrador

PRECONDICIONES Seleccionar un parámetro.

POSTCONDICIONES Mostar los datos del parámetro. Mantenimiento del parámetro realizado.

FLUJO NORMAL

1. El usuario selecciona un parámetro del sistema, le da clic en el botón consultar.

2. El sistema muestra los datos completos del parámetro.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del parámetro. Eliminar parámetro.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el parámetro consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

86

Tabla 12 – Mantenimiento de parámetros

CU009 MANTENIMIENTO PARAMETROS

CASO DE USO MANTENIMIENTO DE PARAMETROS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de los parámetros del sistema.

DESCRIPCION Actualizar datos de un parámetro de sistema.

PRECONDICIONES Seleccionar un parámetro del sistema

POSTCONDICIONES Datos de un parámetro actualizados

FLUJO NORMAL

1. El operador EFOT selecciona un parámetro del sistema, le da clic en el botón consultar parámetro.

2. El sistema muestra los datos completos del operador.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del parámetro. Eliminar parámetro.

4. El operador EFOT puede no tener acceso a todos los parámetros para modificar su información.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el usuario consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

87

1.1.4 Módulos

Imagen 22-(Casos de uso - Módulos)

ADMINISTRADOR

Permiso Módulo

Crear Módulo

Buscar Módulo

<<incluir>>

Mantenimiento Módulo

<<incluir>>

<<incluir>>

OPERADOR EFOT

Fuente: Investigación

Autor: Investigadores

88

Tabla 13 – Crear módulo

CU010 CREAR MODULOS

CASO DE USO CREAR MODULO

ACTORES Usuario Administrador

OBJETIVO Crear modulo.

DESCRIPCION Crear nuevos módulos para uso del sistema.

PRECONDICIONES

POSTCONDICIONES Módulo creado

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo Módulo.

2. El sistema muestra el formulario con los datos que necesita para crear el nuevo módulo.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el módulo ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

89

Tabla 14 - Buscar Módulos

CU011 BUSCAR MODULOS

CASO DE USO BUSCAR MODULOS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar datos de módulo, para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del módulo, dar mantenimiento de módulo seleccionado a nivel de administrador

PRECONDICIONES Seleccionar un módulo.

POSTCONDICIONES Mostar los datos del módulo. Mantenimiento del módulo realizado.

FLUJO NORMAL

1. El usuario selecciona un módulo del sistema, le da clic en el botón consultar.

2. El sistema muestra los datos completos del módulo.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del módulo. Eliminar módulo.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el módulo consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

90

Tabla 15 – Mantenimiento de Módulos

CU012 MANTENIMIENTO MODULOS

CASO DE USO MANTENIMIENTO DE MODULOS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de los módulos del sistema.

DESCRIPCION Actualizar datos de los módulos de sistema.

PRECONDICIONES Seleccionar un módulo del sistema

POSTCONDICIONES Datos de un módulo actualizados

FLUJO NORMAL

1. El operador EFOT selecciona un módulo del sistema, le da clic en el botón consultar módulo.

2. El sistema muestra los datos completos del operador.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del módulo.

4. El operador EFOT puede no tener acceso a todos los módulos para modificar su información.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el módulo consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

91

1.1.5 Roles

Imagen 23 - (Caso de uso - Roles)

ADMINISTRADOR

Crear Roles

Buscar Roles

Mantenimiento Roles

<<incluir>>

<<incluir>>

AsignaRoles - Usuario

<<incluir>>

Mantenimiento Roles - Usuario

<<incluir>>

Fuente: Investigación

Autor: Investigadores

92

Tabla 16 – Crear Roles

CU013 CREAR ROLES

CASO DE USO CREAR ROLES

ACTORES Usuario Administrador

OBJETIVO Crear roles.

DESCRIPCION Crear nuevos roles para uso de los usuarios del sistema.

PRECONDICIONES

POSTCONDICIONES Roles creados

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo Rol. 2. El sistema muestra el formulario con los

datos que necesita para crear el nuevo rol. 3. El sistema valida los datos ingresados por el

usuario. 4. El sistema emite un mensaje de

confirmación. 5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el rol ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

93

Tabla 17 - Buscar Roles

CU014 BUSCAR ROLES

CASO DE USO BUSCAR ROLES

ACTORES Usuario Administrador

OBJETIVO Buscar un rol para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del rol, dar mantenimiento de rol seleccionado a nivel de administrador

PRECONDICIONES Seleccionar un rol.

POSTCONDICIONES Mostar los datos del rol.

FLUJO NORMAL

1. El usuario selecciona un rol del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del rol.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del rol. Eliminar rol. Asignar rol – usuario Editar rol – usuario Eliminar rol - usuario

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el rol consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

94

Tabla 18 – Mantenimiento de roles

CU015 MANTENIMIENTO ROLES

CASO DE USO MANTENIMIENTO DE ROLES

ACTORES Usuario Administrador

OBJETIVO Mantenimiento de los módulos del sistema.

DESCRIPCION Actualizar datos de los módulos de sistema.

PRECONDICIONES Seleccionar un rol del sistema

POSTCONDICIONES Datos de un rol actualizado

FLUJO NORMAL

1. El administrador selecciona un rol del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del operador.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del módulo.

4. El administrador tiene acceso a otros usuarios para modificar su información.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el módulo consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

95

Tabla 19 – Asigna roles - usuarios

CU016 ASIGNACION DE ROLES - USUARIOS

CASO DE USO ASIGNACION DE ROLES - USUARIO

ACTORES Usuario Administrador

OBJETIVO Asignar roles a los usuarios.

DESCRIPCION Asignar rol a un usuario específico del sistema.

PRECONDICIONES Seleccionar un rol y un usuario

POSTCONDICIONES Rol asignado a un usuario

FLUJO NORMAL

1. El administrador selecciona un rol del sistema y un usuario de la lista de usuarios activos del sistema, selecciona la opción Asignar Rol.

2. El sistema muestra el formulario con los datos que necesita para asignar un rol

3. El sistema permite al administrador realizar las siguientes opciones: Asignar Rol – Usuario Editar Rol –Usuario

4. Solo el administrador puede asignar roles a todos los usuarios del sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el usuario con el mismo

rol) el sistema no continua el proceso y debe

Mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

96

Tabla 20 – Mantenimiento Roles - Usuarios

CU017 MANTENIMIENTO DE ROLES - USUARIOS

CASO DE USO MANTENIMIENTO DE ROLES - USUARIO

ACTORES Usuario Administrador

OBJETIVO Dar mantenimiento de roles a los usuarios.

DESCRIPCION Dar mantenimiento rol a un usuario específico del sistema.

PRECONDICIONES Seleccionar un usuario o un rol

POSTCONDICIONES Cambiar o elimina un rol de un usuario

FLUJO NORMAL

1. El administrador selecciona un rol del sistema o un usuario de la lista de usuarios activos del sistema, selecciona la opción consultar.

2. El sistema muestra el formulario con los datos del valor consultado (usuario o rol)

3. El sistema permite al administrador realizar las siguientes opciones: Editar Rol – Usuario Eliminar Rol –Usuario Agregar Rol – Usuario

4. Solo el administrador puede realizar estas acciones en el sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el usuario con el mismo

rol) el sistema no continua el proceso y debe

Mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

97

1.1.6 Privilegios

Imagen 24 - (Caso de uso - Privilegios)

ADMINISTRADOR

Crear Privilegio

Buscar Privilegio

Mantenimiento Privilegios

<<incluir>>

<<incluir>>

AsignarPrivilegio - Usuario

<<incluir>>

AsignarPrivilegio - Rol

<<incluir>>

Mantenimiento Privilegios - Rol

Mantenimiento Privilegios - Usuario

<<incluir>>

<<incluir>>

Fuente: Investigación

Autor: Investigadores

98

Tabla 21 – Crear Privilegios

CU018 CREAR PRIVILEGIOS

CASO DE USO CREAR PRIVILEGIOS

ACTORES Usuario Administrador

OBJETIVO Crear privilegios.

DESCRIPCION Crear nuevos privilegios para uso de los usuarios del sistema.

PRECONDICIONES

POSTCONDICIONES Privilegios creados

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo Privilegio.

2. El sistema muestra el formulario con los datos que necesita para crear el nuevo Privilegio.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el privilegio ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

99

Tabla 22 – Buscar Privilegios

CU019 BUSCAR PRIVILEGIOS

CASO DE USO BUSCAR PRIVILEGIOS

ACTORES Usuario Administrador

OBJETIVO Buscar un privilegio para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del privilegio, dar mantenimiento de privilegio seleccionado a nivel de administrador

PRECONDICIONES Seleccionar un privilegio.

POSTCONDICIONES Mostar los datos del privilegio.

FLUJO NORMAL

1. El usuario selecciona un privilegio del sistema, selecciona la opción consultar

2. El sistema muestra los datos completos del privilegio.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del privilegio. Eliminar privilegio. Asignar privilegio – usuario. Editar privilegio – usuario. Eliminar privilegio – usuario. Asignar privilegio – rol. Editar privilegio – rol. Eliminar privilegio – rol.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el privilegio consultado, el sistema muestra una alerta. (3.1). En caso de no existir el privilegio para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

100

Tabla 23 – Asignar privilegios usuario

CU020 ASIGNACION DE PRIVILEGIOS - USUARIOS

CASO DE USO ASIGNACION DE PRIVILEGIO - USUARIO

ACTORES Usuario Administrador

OBJETIVO Asignar privilegio a los usuarios.

DESCRIPCION Asignar privilegio a un usuario específico del sistema.

PRECONDICIONES Seleccionar un privilegio y un usuario

POSTCONDICIONES privilegio asignado a un usuario

FLUJO NORMAL

1. El administrador selecciona un privilegio del sistema y un usuario de la lista de usuarios activos del sistema, selecciona la opción Asignar privilegio.

2. El sistema muestra el formulario con los datos que necesita para asignar un privilegio

3. El sistema permite al administrador realizar las siguientes opciones: Asignar privilegio – Usuario Editar privilegio –Usuario

4. Solo el administrador puede asignar privilegios a todos los usuarios del sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el usuario con el mismo

privilegio) el sistema no continua el proceso y

debe mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

101

Tabla 24 – Mantenimiento Privilegios usuarios

CU021 MANTENIMIENTO DE PRIVILEGIOS - USUARIOS

CASO DE USO MANTENIMIENTO DE PRIVILEGIOS - USUARIO

ACTORES Usuario Administrador

OBJETIVO Dar mantenimiento de privilegios de los usuarios.

DESCRIPCION Dar mantenimiento privilegios a un usuario específico del sistema.

PRECONDICIONES Seleccionar un usuario o un privilegio

POSTCONDICIONES Cambiar o elimina un privilegio de un usuario

FLUJO NORMAL

1. El administrador selecciona un privilegio del sistema o un usuario de la lista de usuarios activos del sistema, selecciona la opción consultar.

2. El sistema muestra el formulario con los datos del valor consultado (usuario o privilegio).

3. El sistema permite al administrador realizar las siguientes opciones: Editar privilegio – Usuario Eliminar privilegio –Usuario Agregar privilegio – Usuario

4. Solo el administrador puede realizar estas acciones en el sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el usuario con el mismo

privilegio) el sistema no continua el proceso y

debe mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

102

Tabla 25 – Asignar privilegios roles

CU022 ASIGNACION DE PRIVILEGIOS - ROLES

CASO DE USO ASIGNACION DE PRIVILEGIO - ROLES

ACTORES Usuario Administrador

OBJETIVO Asignar privilegio a los roles.

DESCRIPCION Asignar privilegio a un rol específico del sistema.

PRECONDICIONES Seleccionar un privilegio y un rol

POSTCONDICIONES privilegio asignado a un rol

FLUJO NORMAL

1. El administrador selecciona un privilegio del sistema y un rol de la lista de usuarios activos del sistema, selecciona la opción Asignar privilegio.

2. El sistema muestra el formulario con los datos que necesita para asignar un privilegio

3. El sistema permite al administrador realizar las siguientes opciones: Asignar privilegio – rol Editar privilegio – rol

4. Solo el administrador puede asignar privilegios a todos los roles del sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el rol con el mismo

privilegio) el sistema no continua el proceso y

debe mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

103

Tabla 26 – Mantenimiento de Privilegios - rol

CU023 MANTENIMIENTO DE PRIVILEGIOS - ROL

CASO DE USO MANTENIMIENTO DE PRIVILEGIOS - ROL

ACTORES Usuario Administrador

OBJETIVO Dar mantenimiento de privilegios de los roles.

DESCRIPCION Dar mantenimiento privilegios a un rol específico del sistema.

PRECONDICIONES Seleccionar un rol o un privilegio

POSTCONDICIONES Cambiar o elimina un privilegio de un usuario

FLUJO NORMAL

1. El administrador selecciona un privilegio del sistema o un rol de la lista de roles del sistema, selecciona la opción consultar.

2. El sistema muestra el formulario con los datos del valor consultado (rol o privilegio).

3. El sistema permite al administrador realizar las siguientes opciones: Editar privilegio – rol Eliminar privilegio – rol Agregar privilegio – rol

4. Solo el administrador puede realizar estas acciones en el sistema.

5. El sistema valida los datos ingresados por el administrador.

6. El sistema emite un mensaje de confirmación.

7. El usuario confirma la acción

FLUJO ALTERNATIVO

(5.1). En caso de (existir el rol con el mismo

privilegio) el sistema no continua el proceso y

debe mostrar una alerta.

(7.1). En caso de (error de almacenamiento) el

sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

104

Tabla 27 – Mantenimiento de privilegios

CU024 MANTENIMIENTO PRIVILEGIOS

CASO DE USO MANTENIMIENTO DE PRIVILEGIOS

ACTORES Usuario Administrador

OBJETIVO Mantenimiento de los privilegio del sistema.

DESCRIPCION Actualizar datos de los privilegio de sistema.

PRECONDICIONES Seleccionar un privilegio del sistema

POSTCONDICIONES Datos de un privilegio actualizado

FLUJO NORMAL

1. El administrador selecciona un privilegio del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del privilegio.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del privilegio.

4. El administrador tiene acceso para modificar la información de cualquier privilegio.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el privilegio consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

105

1.2 Convocatoria

1.2.1 Proceso de formación

Imagen 25 - (Caso de uso – Proceso de formación)

ADMINISTRADOR

Buscar Parámetros

Crear Proceso formación

Buscar Proceso formación

Mantenimiento Proceso de formación

<<incluir>>

OPERADOR EFOT

<<extender>>

Fuente: Investigación

Autor: Investigadores

106

Tabla 28 – Crear Proceso de Formación

CU025 CREAR PROCESO DE FORMACION

CASO DE USO CREAR PROCESO DE FORMACION

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear procesos de formación.

DESCRIPCION Crear nuevos proceso de formación para registra los datos de los nuevos aspirantes, relacionar docentes, mallas, etc.

PRECONDICIONES

POSTCONDICIONES Nuevo proceso de formación creado

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo proceso de formación.

2. El sistema muestra el formulario con los datos que necesita para crear el nuevo proceso de formación, existen datos obligatorios:

Fecha inicio Fecha fin Inicio de reclutamiento Inicio pruebas

3. El operador o administrador, puede seleccionar parámetros previamente configurados, y relacionarlos al proceso que se está creando.

4. El sistema valida los datos ingresados por el usuario.

5. El sistema emite un mensaje de confirmación.

6. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el rol ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

107

Tabla 29 – Buscar proceso de formación

CU026 BUSCAR PROCESO DE FORMACION

CASO DE USO BUSCAR PROCESO DE FORMACION

ACTORES Usuario Administrador, operador’ EFOT

OBJETIVO Buscar un proceso de formación para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del proceso de formación, dar mantenimiento de proceso de formación seleccionado.

PRECONDICIONES Seleccionar un proceso de formación.

POSTCONDICIONES Mostar los datos del proceso de formación.

FLUJO NORMAL

1. El usuario selecciona un proceso de formación del sistema, selecciona la opción consultar

2. El sistema muestra los datos completos del proceso de formación.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del proceso de formación. Eliminar proceso de formación, (solo

el administrador). Asignar parámetros.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el proceso de formación consultado, el sistema muestra una alerta. (3.1). En caso de no existir el privilegio para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

108

Tabla 30 – Mantenimiento de proceso de formación

CU027 MANTENIMIENTO PROCESO DE FORMACION

CASO DE USO MANTENIMIENTO DE PROCESO DE FORMACION

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de los proceso de formación del sistema.

DESCRIPCION Actualizar datos de los procesos de formación de sistema.

PRECONDICIONES Seleccionar un proceso de formación del sistema

POSTCONDICIONES Datos de un proceso de formación actualizado

FLUJO NORMAL

1. El administrador selecciona un proceso de formación del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del proceso de formación.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del proceso de formación. Eliminar proceso de formación,

4. El administrador tiene acceso para eliminar un proceso de formación.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el proceso de formación consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

109

1.2.2 Pruebas

Imagen 26 - (Caso de uso - Pruebas)

ADMINISTRADOR

Crear Pruebas

Buscar Pruebas

MantenimientoPruebas

<<incluir>>OPERADOR

EFOT

Fuente: Investigación

Autor: Investigadores

110

Tabla 31 – Crear pruebas

CU028 CREAR PRUEBAS

CASO DE USO CREAR PRUEBAS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear pruebas.

DESCRIPCION Crear nuevas pruebas para uso de los usuarios del sistema.

PRECONDICIONES

POSTCONDICIONES pruebas creadas

FLUJO NORMAL

1. El usuario selecciona la opción Nueva prueba.

2. El sistema muestra el formulario con los datos que necesita para crear la prueba.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema selecciona un tipo de prueba 5. El sistema emite un mensaje de

confirmación. 6. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la prueba ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

111

Tabla 32 - Buscar pruebas

CU029 BUSCAR PRUEBAS

CASO DE USO BUSCAR PRUEBAS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una prueba para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la prueba, dar mantenimiento de prueba,

PRECONDICIONES Seleccionar una prueba.

POSTCONDICIONES Mostrar los datos de la prueba.

FLUJO NORMAL

1. El usuario selecciona una prueba del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la prueba.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de la prueba. Eliminar prueba (solo administrador). Asignar tipo de prueba. Desvincular tipo de prueba.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la prueba consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

112

Tabla 33 - Mantenimiento de pruebas

CU030 MANTENIMIENTO PRUEBAS

CASO DE USO MANTENIMIENTO DE PRUEBAS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de pruebas del sistema.

DESCRIPCION Actualizar datos de las pruebas configuradas en el sistema.

PRECONDICIONES Seleccionar una prueba del sistema

POSTCONDICIONES Datos de una prueba actualizado

FLUJO NORMAL

1. El administrador selecciona una prueba del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la prueba.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos de la prueba. Eliminar prueba (solo administrador). Asignar tipo de prueba.

4. Solo el administrador tiene acceso a eliminar una prueba.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la prueba consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

113

1.2.3 Etapas

Imagen 27 - (Caso de uso - Etapas)

ADMINISTRADOR

Crear etapa

Buscar etapa

Mantenimientoetapa

<<incluir>>OPERADOR

EFOT

Fuente: Investigación

Autor: Investigadores

114

Tabla 34 – Crear etapa

CU031 CREAR ETAPA

CASO DE USO CREAR ETAPA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear etapa.

DESCRIPCION Crear nuevas etapa para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES etapas creadas

FLUJO NORMAL

1. El usuario selecciona la opción Nueva etapa. 2. El sistema muestra el formulario con los

datos que necesita para crear la etapa. 3. El sistema valida los datos ingresados por el

usuario. 4. El sistema emite un mensaje de

confirmación. 5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la etapa ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

115

Tabla 35 – Buscar etapa

CU032 BUSCAR ETAPA

CASO DE USO BUSCAR ETAPA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una etapa para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la etapa, dar mantenimiento de etapa,

PRECONDICIONES Seleccionar una etapa.

POSTCONDICIONES Mostrar los datos de la etapa.

FLUJO NORMAL

1. El usuario selecciona una etapa del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la etapa.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de la etapa. Eliminar etapa (solo administrador).

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la etapa consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

116

Tabla 36 – Mantenimiento etapas

CU033 MANTENIMIENTO ETAPAS

CASO DE USO MANTENIMIENTO DE ETAPAS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de etapa del sistema.

DESCRIPCION Actualizar datos de las etapas configuradas en el sistema.

PRECONDICIONES Seleccionar una etapa del sistema

POSTCONDICIONES Datos de una etapa actualizado

FLUJO NORMAL

1. El administrador selecciona una etapa del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la etapa.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos de la etapa. Eliminar etapa (solo administrador).

4. Solo el administrador tiene acceso a eliminar una etapa.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la etapa consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

117

1.2.4 Requerimientos

Imagen 28 - (Caso de uso – requerimientos)

ADMINISTRADOR

Crear Requerimientos

Buscar Requerimientos

MantenimientoRequerimientos

<<incluir>>OPERADOR

EFOT

Fuente: Investigación

Autor: Investigadores

118

Tabla 37 – Crear Requerimientos

CU034 CREAR REQUERIMIENTOS

CASO DE USO CREAR REQUERIMIENTOS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear requerimiento.

DESCRIPCION Crear nuevos requerimientos para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES requerimiento creados

FLUJO NORMAL

1. El usuario selecciona la opción Nuevo requerimiento.

2. El sistema muestra el formulario con los datos que necesita para crear el requerimiento.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema selecciona un tipo de requerimiento

5. El sistema emite un mensaje de confirmación.

6. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que el requerimiento ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

119

Tabla 38 – Buscar requerimientos

CU035 BUSCAR REQUERIMIENTOS

CASO DE USO BUSCAR REQUERIMIENTOS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar un requerimiento para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del requerimiento, dar mantenimiento de prueba,

PRECONDICIONES Seleccionar un requerimiento.

POSTCONDICIONES Mostrar los datos del requerimiento.

FLUJO NORMAL

1. El usuario selecciona un requerimiento del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del requerimiento.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos del requerimiento. Eliminar requerimiento (solo

administrador). Asignar tipo de requerimiento. Desvincular tipo de requerimiento.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el requerimiento consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

120

Tabla 39 – Mantenimiento de requerimientos

CU036 MANTENIMIENTO REQUERIMIENTOS

CASO DE USO MANTENIMIENTO DE REQUERIMIENTOS

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de requerimiento del sistema.

DESCRIPCION Actualizar datos de los requerimientos configurados en el sistema.

PRECONDICIONES Seleccionar una requerimiento del sistema

POSTCONDICIONES Datos de una prueba actualizado

FLUJO NORMAL

1. El administrador selecciona un requerimiento del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la prueba.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del requerimiento. Eliminar requerimiento (solo

administrador). Asignar tipo de requerimiento.

4. Solo el administrador tiene acceso a eliminar un requerimiento .

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la requerimiento consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

121

1.2.5 Convocatorias

Imagen 29- (Caso de uso – convocatoria)

ADMINISTRADOR

Crear Convocatoria

Buscar Convocatoria

MantenimientoConvocatoria

<<incluir>>OPERADOR

EFOT

Fuente: Investigación

Autor: Investigadores

122

Tabla 40 - Crear convocatoria

CU037 CREAR CONVOCATORIA

CASO DE USO CREAR CONVOCATORIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear convocatoria.

DESCRIPCION Crear nuevas convocatoria para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES convocatoria creada

FLUJO NORMAL

1. El usuario selecciona la opción Nueva convocatoria.

2. El sistema muestra el formulario con los datos que necesita para crear la convocatoria.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la convocatoria ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

123

Tabla 41 – Buscar convocatoria

CU038 BUSCAR CONVOCATORIA

CASO DE USO BUSCAR CONVOCATORIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una convocatoria para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la etapa, dar mantenimiento de convocatoria,

PRECONDICIONES Seleccionar una convocatoria.

POSTCONDICIONES Mostrar los datos de la convocatoria.

FLUJO NORMAL

1. El usuario selecciona una convocatoria del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la convocatoria.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de la convocatoria. Eliminar convocatoria (solo

administrador). 4. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la convocatoria consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

124

Tabla 42 - Mantenimiento de Convocatoria

CU039 MANTENIMIENTO CONVOCATORIA

CASO DE USO MANTENIMIENTO DE CONVOCATORIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de convocatoria del sistema.

DESCRIPCION Actualizar datos de las convocatorias configuradas en el sistema.

PRECONDICIONES Seleccionar una convocatoria del sistema

POSTCONDICIONES Datos de una convocatoria actualizado

FLUJO NORMAL

1. El administrador selecciona una convocatoria del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la convocatoria.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos de la convocatoria. Eliminar convocatoria (solo

administrador). 4. Solo el administrador tiene acceso a

eliminar una convocatoria. 5. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la convocatoria consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

125

1.2.6 Evaluaciones

Imagen 30- (Caso de uso – Evaluaciones)

Buscar Prueba

Buscar Aspirante

Registrar resultados Prueba

OPERADOR EFOT

PROFESOR/INSTRUCTOR

Mantenimiento de resultados

<<incluir>>

Fuente: Investigación

Autor: Investigadores

126

Tabla 43 - Registro de pruebas

CU040 REGISTRO DE RESULTADOS PRUEBA

CASO DE USO REGISTRO DE RESULTADOS PRUEBA

ACTORES Operador EFOT, profesor / instructor

OBJETIVO Registrar resultados de la pruebas.

DESCRIPCION Registrar el resultado de las pruebas realizadas a los aspirantes antes de iniciar el proceso de formación.

PRECONDICIONES Seleccionar una prueba y seleccionar un aspirante.

POSTCONDICIONES Resultados de pruebas registrados en el sistema

FLUJO NORMAL

1. El profesor /instructor selecciona una un aspirante y una prueba del sistema, selecciona la opción consultar.

2. El sistema muestra el formulario para registrar los resultados.

3. Los resultados deben ser ingresados por el instructor o profesor.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de ya existir registro de la prueba para el aspirante, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

127

Tabla 44 - Mantenimiento de registro de notas

CU041 MANTENIMIENTO DE REGISTRO DE RESULTADOS PRUEBA

CASO DE USO MANTENIMIENTO DE REGISTRO DE RESULTADOS PRUEBA

ACTORES Operador EFOT

OBJETIVO Modificar resultados de la pruebas.

DESCRIPCION Modificar el resultado de las pruebas realizadas a los aspirantes antes de iniciar el proceso de formación.

PRECONDICIONES Seleccionar una prueba y seleccionar un aspirante.

POSTCONDICIONES Resultados de pruebas registrados en el sistema

FLUJO NORMAL

1. El operador selecciona una un aspirante y una prueba del sistema, selecciona la opción consultar.

2. El sistema muestra el formulario para modificar los resultados.

3. Los resultados deben ser ingresados por el operador,

4. .los resultados de una prueba solo pueden ser modificados por el operador, solo si ha sido autorizado para hacerlo.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

128

1.2.7 Aspirante

Imagen 31- (Caso de uso – Aspirante)

Resgistro WebAspirante

Busca convocatoria

OPERADOR EFOT

ASPIRANTE

Carga requisitos(documentos)

Mantenimiento Aspirante

Califica Aspirante

Recuperar contraseña

Buscar Aspirante

<<incluir>>

<<incluir>>

<<incluir>><<incluir>>

PROFESOR/INSTRUCTOR

Fuente: Investigación

Autor: Investigadores

129

Tabla 45 - Registro web de aspirante

CU042 REGISTRO WEB DE ASPIRANTE

CASO DE USO REGISTRO WEB DE ASPIRANTE

ACTORES Aspirante

OBJETIVO Registrar datos del Aspirante.

DESCRIPCION Registrar datos del usuario Aspirante en el sistema web.

PRECONDICIONES Seleccionar una convocatoria para proceso de formación.

POSTCONDICIONES Registro de datos personales del aspirante.

FLUJO NORMAL

1. El aspirante selecciona una convocatoria. 2. El sistema muestra el formulario con los

datos que el usuario debe ingresar para inicia con el proceso.

Nombres

Apellidos

Cedula

Edad

Promedio

Tipo de sangre, etc. 3. El sistema valida los dato ingresados. 4. El sistema emite un mensaje de

confirmación. 5. El aspirante confirma su acción. 6. Si no existe error en los datos ingresados,

se habilita la opción “Cargar Requisitos”.

FLUJO ALTERNATIVO

(2.1). En caso de ya existir el aspirante, el sistema muestra una alerta. (3.1). En caso de existir errores en las validaciones de los datos, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

130

Tabla 46 - Carga de requisitos

CU043 CARGA DE REQUISISTOS

CASO DE USO CARGA DE REQUISISTOS

ACTORES Aspirante

OBJETIVO Cargar los documentos del aspirante

DESCRIPCION Cargar los documentos virtuales del aspirante en el sistema.

PRECONDICIONES Ingresar datos del aspirante, habilitar la opción “Cargar Requisitos”

POSTCONDICIONES Documentos virtuales del aspirante cargados en el sistema.

FLUJO NORMAL

1. El aspirante selecciona la opción “Cargar Documentos”.

2. El sistema muestra el formulario para que el Aspirante pueda cargar sus documento virtuales:

Cedula de identidad

Título de bachiller

Papel de votación. 3. El sistema verifica los formatos de los

archivos cargados. 4. El sistema emite un mensaje de

confirmación. 5. El aspirante confirma su acción. 6. Si no existe error con los archivos se

continúa con el proceso.

FLUJO ALTERNATIVO

(2.1). En caso de ya existir el archivo para el aspirante, el sistema muestra una alerta. (3.1). En caso de existir errores en los formatos de archivos, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

131

Tabla 47 - Buscar aspirante

CU044 BUSCAR ASPIRANTE

CASO DE USO BUSCAR ASPIRANTE

ACTORES Operador EFOT, profesor /instructor

OBJETIVO Buscar un aspirante para visualizar o dar mantenimiento, o registrar resultados de evaluaciones

DESCRIPCION Mostrar los datos del aspirante, dar mantenimiento a los datos del aspirante,

PRECONDICIONES Seleccionar un aspirante.

POSTCONDICIONES Mostrar los datos del aspirante.

FLUJO NORMAL

1. El operador selecciona un aspirante del sistema y selecciona la opción consultar.

2. El sistema muestra los datos completos del aspirante.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del aspirante Eliminar datos. Resetear contraseña Ingresar calificaciones de pruebas. Editar o corregir calificaciones. Eliminar aspirante (solo

administrador). 4. El sistema e mite un mensaje de

confirmación. 5. El operador confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el aspirante consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación

Autor: Investigadores

132

Tabla 48 – Mantenimiento aspirante

CU045 MANTENIMIENTO ASPIRANTE

CASO DE USO MANTENIMIENTO DE ASPIRANTE

ACTORES Operador EFOT, aspirante

OBJETIVO Mantenimiento de aspirante registrado en el sistema.

DESCRIPCION Actualizar datos de un aspirante registrado en el sistema para dar inicio al proceso de formación seleccionado.

PRECONDICIONES Seleccionar un aspirante del sistema

POSTCONDICIONES Datos de un aspirante actualizado

FLUJO NORMAL

1. El operador de selecciona un aspirante del sistema, selecciona la opción “consultar”. o

2. El aspirante accede con su usuario u contraseña, y se habilita la opción “Modificar”.

3. El sistema muestra los datos completos del aspirante.

4. El sistema permite al operador realizar las siguientes opciones: Editar datos del aspirante Eliminar datos. Resetear contraseña

5. El sistema permite al usuario aspirante realizar las siguientes opciones: Editar datos del aspirante Recuperar contraseña

6. Solo el administrador tiene acceso a eliminar un aspirante.

7. El sistema emite un mensaje de confirmación.

8. El usuario acepta la acción. 9. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el aspirante consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

133

Tabla 49 – Califica aspirante

CU046 CALIFICA ASPIRANTE

CASO DE USO CALIFICA ASPIRANTE

ACTORES Operador EFOT, profesor / instructor

OBJETIVO Registrar calificaciones de aspirantes.

DESCRIPCION Registrar el resultado de las pruebas realizadas a los aspirantes antes de iniciar el proceso de formación.

PRECONDICIONES Seleccionar una prueba y seleccionar un aspirante.

POSTCONDICIONES Resultados de pruebas registrados en el sistema

FLUJO NORMAL

1. El profesor /instructor selecciona una un aspirante del sistema.

2. El sistema muestra el formulario para registrar las calificaciones del aspirante.

3. Las calificaciones deben ser ingresados por el instructor o profesor.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción. 6. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de ya calificación para el aspirante, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

134

Tabla 50 – Recuperar contraseña

CU047 RECUPERAR CONTRASEÑA

CASO DE USO RECUPERAR CONTRASEÑA

ACTORES Aspirante.

OBJETIVO Recuperar contraseña del aspirante

DESCRIPCION Procesos para que el aspirante recupere su contraseña vía web.

PRECONDICIONES Seleccionar una prueba y seleccionar un aspirante.

POSTCONDICIONES Resultados de pruebas registrados en el sistema

FLUJO NORMAL

1. El aspirante selecciona la opción “Recuperar Contraseña”.

2. El sistema muestra el formulario para recuperar la contraseña, ingresando el correo electrónico.

3. El sistema genera una clave temporal, y la envía por correo electrónico.

4. El aspirante accede al sistema con la clave temporal.

5. El sistema muestra un formulario para cambio de contraseña.

6. El usuario guarda lo cambios. 7. El sistema emite un mensaje de

confirmación. 8. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de ingresar erróneo el correo electrónico, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

135

1.3 Académico

1.3.1 Paralelo

Imagen 32- (Caso de uso – Paralelo)

ADMINISTRADOR

Crear Paralelo

Buscar Paralelo

MantenimientoParalelo

<<incluir>>OPERADOR

EFOT

Fuente: Investigación Autor: Investigadores

136

Tabla 51 – Crear Paralelo

CU048 CREAR PARALELO

CASO DE USO CREAR PARALELO

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear paralelo.

DESCRIPCION Crear nuevos paralelos para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES Paralelos creados.

FLUJO NORMAL

1. El administrador selecciona la opción Nuevo paralelo.

2. El sistema muestra el formulario con los datos que necesita para crear el paralelo.

3. El sistema valida los datos ingresados por el administrador.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la el paralelo ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

137

Tabla 52 – Buscar paralelo

CU049 BUSCAR PARALELO

CASO DE USO BUSCAR PARALELO

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una paralelo para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la etapa, dar mantenimiento de paralelo,

PRECONDICIONES Seleccionar un paralelo.

POSTCONDICIONES Mostrar los datos de la paralelo.

FLUJO NORMAL

1. El usuario selecciona un paralelo del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del paralelo.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de paralelo. Eliminar paralelo (solo administrador).

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el paralelo consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

138

Tabla 53 – Mantenimiento paralelo

CU050 MANTENIMIENTO PARALELO

CASO DE USO MANTENIMIENTO DE CONVOCATORIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de paralelos del sistema.

DESCRIPCION Actualizar datos de las convocatorias configuradas en el sistema.

PRECONDICIONES Seleccionar una convocatoria del sistema

POSTCONDICIONES Datos de una convocatoria actualizado

FLUJO NORMAL

1. El administrador selecciona un paralelo del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del paralelo.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del paralelo. Eliminar paralelo (solo administrador).

4. Solo el administrador tiene acceso a eliminar un paralelo.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el paralelo consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

139

1.3.2 Docente

Imagen 33- (Caso de uso – Docente)

ADMINISTRADOR

Crear Docente

Buscar docente

Mantenimientodocente

<<incluir>>OPERADOR

EFOT

Fuente: Investigación Autor: Investigadores

140

Tabla 54 – Crear docente

CU051 CREAR DOCENTE

CASO DE USO CREAR DOCENTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear docente.

DESCRIPCION Crear nuevos docentes para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES Paralelos creados.

FLUJO NORMAL

1. El administrador selecciona la opción Nuevo docente.

2. El sistema muestra el formulario con los datos que necesita para crear el docente.

3. El sistema valida los datos ingresados por el administrador.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la el docente ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

141

Tabla 55 – Buscar docente

CU052 BUSCAR DOCENTE

CASO DE USO BUSCAR DOCENTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una paralelo para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del docente, dar mantenimiento de docente,

PRECONDICIONES Seleccionar un docente.

POSTCONDICIONES Mostrar los datos de la docente.

FLUJO NORMAL

1. El usuario selecciona un docente del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del docente.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de docente. Eliminar docente (solo administrador).

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el docente consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

142

Tabla 56 – Mantenimiento docente

CU053 MANTENIMIENTO DOCENTE

CASO DE USO MANTENIMIENTO DE DOCENTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de docentes del sistema.

DESCRIPCION Actualizar datos de los docentes configurados en el sistema.

PRECONDICIONES Seleccionar un docente del sistema

POSTCONDICIONES Datos de un docente actualizado

FLUJO NORMAL

1. El administrador selecciona un docente del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del docente.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del docente. Eliminar docente (solo administrador).

4. Solo el administrador tiene acceso a eliminar un docente.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el docente consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

143

1.3.3 Estudiante

Imagen 34- (Caso de uso – Estudiante)

ADMINISTRADOR

Registra Estudiante

Buscar estudiante

Mantenimientoestudiante

<<incluir>>

OPERADOR EFOT

Lista de Aspirantes Idoneos

<<incluir>>

Fuente: Investigación Autor: Investigadores

144

Tabla 57 – Registra estudiante

CU054 REGISTRA ESTUDIANTE

CASO DE USO REGISTRA ESTUDIANTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear estudiante.

DESCRIPCION Crear nuevos estudiantes para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES Estudiantes registrados.

FLUJO NORMAL

1. El administrador selecciona la opción registro estudiante.

2. El sistema muestra el formulario con los datos que necesita para registrar el estudiante.

3. El sistema valida los datos ingresados por el administrador.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la el estudiante ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

145

Tabla 58 – Buscar Estudiante

CU055 BUSCAR ESTUDIANTE

CASO DE USO BUSCAR ESTUDIANTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una estudiante para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos del estudiante, dar mantenimiento de estudiante,

PRECONDICIONES Seleccionar un estudiante.

POSTCONDICIONES Mostrar los datos de la estudiante.

FLUJO NORMAL

1. El usuario selecciona un docente del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del estudiante.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de estudiante. Eliminar estudiante (solo

administrador). 4. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el estudiante consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

146

Tabla 59 – Mantenimiento estudiante

CU056 MANTENIMIENTO ESTUDIANTE

CASO DE USO MANTENIMIENTO DE ESTUDIANTE

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de estudiantes del sistema.

DESCRIPCION Actualizar datos de los estudiantes configurados en el sistema.

PRECONDICIONES Seleccionar un estudiante del sistema

POSTCONDICIONES Datos de un estudiante actualizado

FLUJO NORMAL

1. El administrador selecciona un estudiante del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos del estudiante.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos del estudiante. Eliminar estudiante (solo

administrador). 4. Solo el administrador tiene acceso a

eliminar un estudiante. 5. El sistema guarda los cambios realizados en

la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el estudiante consultado, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

147

1.3.4 Materia

Imagen 35- (Caso de uso – Materia)

ADMINISTRADOR

Crear Materia

Buscar Materia

MantenimientoMateria

<<incluir>>OPERADOR

EFOT

Fuente: Investigación Autor: Investigadores

148

Tabla 60 - Crear materia

CU057 CREAR MATERIA

CASO DE USO CREAR MATERIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear materia.

DESCRIPCION Crear nuevas materia para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES convocatoria materia

FLUJO NORMAL

1. El usuario selecciona la opción Nueva materia.

2. El sistema muestra el formulario con los datos que necesita para crear la materia.

3. El sistema valida los datos ingresados por el usuario.

4. El sistema emite un mensaje de confirmación.

5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la materia ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

149

Tabla 61 – Buscar Materia

CU058 BUSCAR MATERIA

CASO DE USO BUSCAR MATERIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una materia para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la materia, dar mantenimiento de materia,

PRECONDICIONES Seleccionar una materia.

POSTCONDICIONES Mostrar los datos de la materia.

FLUJO NORMAL

1. El usuario selecciona una materia del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la materia.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de la materia. Eliminar materia (solo administrador).

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la materia consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

150

Tabla 62 – Mantenimiento de materia

CU059 MANTENIMIENTO MATERIA

CASO DE USO MANTENIMIENTO DE MATERIA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de materia del sistema.

DESCRIPCION Actualizar datos de las materias configuradas en el sistema.

PRECONDICIONES Seleccionar una materia del sistema

POSTCONDICIONES Datos de una materia actualizados

FLUJO NORMAL

1. El administrador selecciona una materia del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la materia.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos de la materia. Eliminar materia (solo administrador).

4. Solo el administrador tiene acceso a eliminar una materia.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la materia consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

151

1.3.5 Malla

Imagen 36- (Caso de uso – Malla)

ADMINISTRADOR

Crear Malla

Buscar Malla

MantenimientoMalla

<<incluir>>OPERADOR

EFOT

Fuente: Investigación Autor: Investigadores

152

Tabla 63 – Crear malla

CU060 CREAR MALLA

CASO DE USO CREAR MALLA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Crear malla.

DESCRIPCION Crear nueva malla para uso de los procesos de formación del sistema.

PRECONDICIONES

POSTCONDICIONES convocatoria malla

FLUJO NORMAL

1. El usuario selecciona la opción Nueva malla. 2. El sistema muestra el formulario con los datos

que necesita para crear la malla. 3. El sistema valida los datos ingresados por el

usuario. 4. El sistema emite un mensaje de

confirmación. 5. El usuario confirma la acción.

FLUJO ALTERNATIVO

(2.1). En caso de existir datos inválidos, el sistema muestra una alerta. (2.2). En caso que la malla ya exista, el sistema muestra una alerta. (5.1). En caso de (error de almacenamiento) el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

153

Tabla 64 – Buscar malla

CU061 BUSCAR MALLA

CASO DE USO BUSCAR MALLA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Buscar una malla para visualizar o dar mantenimiento.

DESCRIPCION Mostrar los datos de la malla, dar mantenimiento de malla,

PRECONDICIONES Seleccionar una malla.

POSTCONDICIONES Mostrar los datos de la malla.

FLUJO NORMAL

1. El usuario selecciona una malla del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la malla.

3. El sistema permite al administrador realizar las siguientes opciones: Editar datos de la malla. Eliminar malla (solo administrador).

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la malla consultada, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

154

Tabla 65 – Mantenimiento malla

CU062 MANTENIMIENTO MALLA

CASO DE USO MANTENIMIENTO DE MALLA

ACTORES Usuario Administrador, operador EFOT

OBJETIVO Mantenimiento de materia del sistema.

DESCRIPCION Actualizar datos de las mallas configuradas en el sistema.

PRECONDICIONES Seleccionar una malla del sistema

POSTCONDICIONES Datos de una malla actualizados

FLUJO NORMAL

1. El administrador selecciona una malla del sistema, selecciona la opción consultar.

2. El sistema muestra los datos completos de la malla.

3. El sistema permite al operador realizar las siguientes opciones: Editar datos de la malla. Eliminar malla (solo administrador).

4. Solo el administrador tiene acceso a eliminar una malla.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir la malla consultada, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

155

1.3.6 Notas

Imagen 37- (Caso de uso – Notas)

Registrar notas paralelo

consulta notas

Mantenimientonotas

<<incluir>>OPERADOR EFOT

Genera Actas de Calificaciones

PROFESOR/INSTRUCTOR

ASPIRANTE

<<incluir>>

Fuente: Investigación Autor: Investigadores

156

Tabla 66 – Registro de notas

CU063 REGISTRO DE NOTAS

CASO DE USO REGISTRO DE NOTAS

ACTORES Operador EFOT, profesor / instructor

OBJETIVO Registrar notas.

DESCRIPCION Registrar notas de las evaluaciones realizadas durante el proceso de formación, de acuerdo a las materias de los estudiantes.

PRECONDICIONES Seleccionar un paralelo.

POSTCONDICIONES Notas registrados en el sistema

FLUJO NORMAL

1. El profesor /instructor escoge un paralelo, selecciona la opción consultar.

2. El sistema muestra el formulario para registrar las notas.

3. Las notas deben ser ingresadas por el instructor o profesor.

4. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de ya existir registro de notas para ese paralelo, el sistema muestra una alerta. (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

157

Tabla 67 - Consulta de notas

CU064 CONSULTA DE NOTAS

CASO DE USO CONSULTA DE NOTAS

ACTORES Usuario Administrador, operador EFOT, aspirante

OBJETIVO Buscar notas de un paralelo para visualizar o dar mantenimiento.

DESCRIPCION Mostrar las notas del paralelo para que el aspirante pueda visualizarlas, el operador o instructor pueden modificar notas en caso de error

PRECONDICIONES Seleccionar un paralelo.

POSTCONDICIONES Mostrar las notas del paralelo.

FLUJO NORMAL

1. El usuario selecciona un paralelo, selecciona la opción consultar.

2. El sistema muestra las notas del paralelo según la materia.

3. El sistema permite al operador realizar las siguientes opciones: Editar notas. Eliminar notas (solo administrador).

4. Se pueden modificar notas solo bajo autorización de un superior.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el paralelo consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

158

Tabla 68 - Mantenimiento de notas

CU065 MANTENIMIENTO DE NOTAS

CASO DE USO MANTENIMIENTO DE NOTAS

ACTORES Operador EFOT

OBJETIVO Modificar notas.

DESCRIPCION Modificar notas en caso de ocurrir algún error.

PRECONDICIONES Seleccionar un paralelo.

POSTCONDICIONES Resultados de pruebas registrados en el sistema

FLUJO NORMAL

1. El operador selecciona un paralelo. 2. El sistema muestra el formulario habilitado

para cambiar la nota. 3. Las notas solo pueden ser ingresadas por el

operador, 4. Las notas solo pueden ser modificadas por

el operador, solo si ha sido autorizado para hacerlo.

5. El sistema guarda los cambios realizados en la pantalla.

FLUJO ALTERNATIVO (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

159

Tabla 69 – Genera actas

CU066 GENERAR ACTAS DE CALIFICACIONES

CASO DE USO GENERAR ACTAS DE CALIFICACIONES

ACTORES Operador EFOT, profesor/ instructor

OBJETIVO Generar actas de calificaciones.

DESCRIPCION El sistema permite generar las actas de calificaciones para imprimir, y mantener el físico de las mismas.

PRECONDICIONES Seleccionar un paralelo.

POSTCONDICIONES Generar acta de calificaciones virtual.

FLUJO NORMAL

1. El operador selecciona un paralelo. 2. El sistema habilita la opción “Genera Acta”. 3. Las actas de calificaciones solo pueden ser

generadas por el operador o profesor. 4. El sistema realiza la acción, y registra el

usuario que generó el acta.

FLUJO ALTERNATIVO (4.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

160

1.4 Reportes

1.4.1 Consulta Reportes

Imagen 38- (Caso de uso – Reportes)

Consulta tipo reporte

Genera Reportes

OPERADOR EFOT

PROFESOR/INSTRUCTOR

ADMINISTRADOR

<<incluir>>

Fuente: Investigación Autor: Investigadores

161

Tabla 70 – Consulta de reportes

CU067 CONSULTA DE REPORTES

CASO DE USO CONSULTA DE REPORTES

ACTORES Usuario Administrador, operador EFOT, profesor/instructor.

OBJETIVO Consultar un tipo de reporte.

DESCRIPCION Consultar diferentes tipos de reportes según los permisos de cada usuario

PRECONDICIONES Seleccionar un reporte.

POSTCONDICIONES Mostrar reporte.

FLUJO NORMAL

1. El usuario selecciona un reporte, selecciona la opción consultar.

2. El sistema muestra el reporte. 3. El sistema permite a los usuarios consultar

reportes como: Reporte de inscritos a un curso de

formación. Reporte aprobados Reportes de etapas Reportes de rendimiento académico,

etc.

4. Solo el administrador puede consultar todos los tipos de reportes.

5. El sistema muestra en pantalla los reportes.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el reporte consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

162

Tabla 71 – Generar reportes

CU068 GENERAR REPORTES

CASO DE USO GENERAR REPORTES

ACTORES Usuario Administrador, operador EFOT, profesor/instructor.

OBJETIVO Consultar un tipo de reporte.

DESCRIPCION Consultar diferentes tipos de reportes según los permisos de cada usuario

PRECONDICIONES Seleccionar un reporte.

POSTCONDICIONES Mostrar reporte.

FLUJO NORMAL

1. El usuario selecciona un reporte, selecciona la opción consultar.

2. El sistema muestra el reporte. 3. El sistema habilita la opción Generar

Reporte, eso generara un archivo Excel, listo para imprimir.

4. De acuerdo los permisos del usuario, se generan los reportes.

5. Solo el administrador puede consultar todos los tipos de reportes.

6. El sistema muestra en pantalla los reportes.

FLUJO ALTERNATIVO

(2.1). En caso de no existir el reporte consultado, el sistema muestra una alerta. (3.1). En caso de no existir el permiso para una de las opciones, el sistema muestra una alerta.

Fuente: Investigación Autor: Investigadores

163

2. Diagrama de Clases Imagen 39 - Diagrama de Clases: Académico

Fuente: Investigación Autor: Investigadores

164

Imagen 40 - Diagrama de Clases: Convocatorias

Fuente: Investigación Autor: Investigadores

165

Imagen 41 - Diagrama de Clases: Seguridad

Fuente: Investigación Autor: Investigadores

166

3. Diseño de interfaz Imagen 42 - Pantalla Principal

Fuente: Investigación Autor: Investigadores

167

Imagen 43 - Menú principal

Fuente: Investigación Autor: Investigadores

168

Imagen 44 – Inicio de sesión

Fuente: Investigación Autor: Investigadores

169

Imagen 45 – Convocatorias

Fuente: Investigación Autor: Investigadores

170

Imagen 46 - Registro de aspirantes

Fuente: Investigación Autor: Investigadores

171

Imagen 47 – Nuevo Usuario

Fuente: Investigación Autor: Investigadores

172

4. Diseño de datos Imagen 48 - Modelo Entidad Relación (Global)

Fuente: Investigación Autor: Investigadores

173

Imagen 49 - Modelo Entidad Relación (Seguridad)

Fuente: Investigación Autor: Investigadores

174

Imagen 50 - Modelo Entidad Relación: Convocatorias

Fuente: Investigación Autor: Investigadores

175

Imagen 51 - Modelo Entidad Relación: Académico

Fuente: Investigación Autor: Investigadores

176

5. Diseño modular

Imagen 52 - Módulos – Visión General

Fuente: Investigación Autor: Investigadores

177

Imagen 53 - Módulo Administración

Fuente: Investigación Autor: Investigadores

178

Imagen 54 - Módulo convocatorias

Fuente: Investigación Autor: Investigadores

179

Imagen 55 - Módulo académico

Fuente: Investigación Autor: Investigadores

180

Imagen 56 - Módulo Reportes

Fuente: Investigación Autor: Investigadores

181

6. Arquitectura del sistema

Imagen 57 - Arquitectura del sistema

USUARIO

USUARIO

Nube FIREWALL

ACCESO A LA RED SERVIDOR DE

APLICACIONES

SERVIDOR DE ARCHIVOS

SERVIDOR BASE DE DATOS

SERVIDOR DE CORREOS

Fuente: Investigación Autor: Investigadores

182

7. Control de Acceso

Para proteger la información y evitar acceso indebido a las diferentes opciones del

sistema, se ha desarrollado la matriz de control de acceso en la cual se especifican

los roles definidos en la etapa de diseño y las opciones a las cuales podrá

acceder. Estos privilegios de acceso podrán ser modificados previa autorización

del Director de la Escuela de Formación de Oficiales y Tropa o su delegado.

Tabla 72 - Control de acceso: Académico

Fuente: Investigación

Autor: Investigadores

ROLES

ACADEMICO

NOTAS DOCENTE

REGISTRA NOTA

PARALELO

EDITAR NOTA

PARALELO

ELIMINAR NOTA

PARALELO

EMITE ACTAS

REGISTRAR EDITAR ELIMINAR REGISTRA

TITULO

EDITAR TITULO

ASPIRANTE

DOCENTE X X X

OPERADOR EFOT X X X

JEFE DEPARTAMENTAL

X X X

DIRECTOR ESCUELA

ADMINISTRADOR_SIS X X X X X X X X X

183

Tabla 73 - Control de Acceso: Académico (2)

ROLES

ACADÉMICO

CURSO PARALELO ESTUDIANTE MALLA MATERIA

CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR

ASPIRANTE

DOCENTE

OPERADOR EFOT X X X X X X X X X X

JEFE DEPARTAMENTAL

X X X X X X X X X X

DIRECTOR ESCUELA

ADMINISTRADOR_SIS X X X X X X X X X X X X X X X

Fuente: Investigación Autor: Investigadores

184

Tabla 74 - Control de Acceso: Reportes

ROLES

REPORTE

PROCESOS CURSOS

REGISTRADOS POR

PROCESO

APROBADOS POR

PROCESO

APROBADOS POR ETAPA

RESULTADOS POR ETAPA

REPORTE CALIFICADOS

PROCESO

REGISTRADOS POR CURSO

REGISTRADOS POR

PARALELO

NOTAS MATERIA

PARALELO

RENDIMIENTO DEL CURSO

ASPIRANTE X

DOCENTE X X

OPERADOR EFOT X X X X X X X

JEFE DEPARTAMENTAL

X X X X X X X X X

DIRECTOR ESCUELA X X X X X X X X X

ADMINISTRADOR_SIS X X X X X X X X X

Fuente: Investigación Autor: Investigadores

185

Tabla 75 - Control de Acceso: Convocatoria (1)

ROLES CONVOCATORIA

PROCESO PRUEBAS ETAPAS ASPIRANTE

CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR CREAR TIPO

PRUEBA

EDITAR TIPO

PRUEBA

ELIMINAR TIPO

PRUEBA

CREAR EDITAR ELIMINAR CALIFICAR REGISTRAR

ASPIRANTE

DOCENTE X

OPERADOR EFOT X X X X X

JEFE DEPARTAMENTAL

X X X X X X X X X X

DIRECTOR ESCUELA X X X X X X X X

ADMINISTRADOR_SIS X X X X X X X X X X X X X X

Fuente: Investigación Autor: Investigadores

186

Tabla 76 - Control de Acceso: Convocatoria (2)

ROLES CONVOCATORIA

REQUISITO PROCESO EVALUACION

CREAR TIPO

REQUISITO

EDITAR TIPO

REQUISITO

ELIMINAR TIPO

REQUISITO

CREAR REQUISITO

EDITAR REQUISITO

ELIMINAR REQUISITO

CREAR CONVOCATORIA

EDITAR CONVOCATORIA

ELIMINAR CONVOCATORIA

REGISTRAR RESUL

PRUEBA

EDITTAR RESUL

PRUEBA

ASPIRANTE

DOCENTE X X

OPERADOR EFOT X X

JEFE DEPARTAMENTAL

X X X X X X X X

DIRECTOR ESCUELA X X X X X X

ADMINISTRADOR_SIS X X X X X X X X X X X

Fuente: Investigación Autor: Investigadores

187

Tabla 77 - Control de Acceso: Administración (1)

ROLES ADMINISTRACION

USUARIOS MODULOS ROLES

CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR CREAR EDITAR ELIMINAR

ASPIRANTE

DOCENTE

OPERADOR EFOT X

JEFE DEPARTAMENTAL X

DIRECTOR ESCUELA

ADMINISTRADOR_SIS X X X X X X X X X

Fuente: Investigación Autor: Investigadores

188

Tabla 78 - Control de Acceso: Administración (2)

ROLES ADMINISTRACION

PRIVILEGIOS PARAMETROS

ASIGNAR PRIVILEGIO -USUARIIO

ASIGNAR PRIVILEGIO

-ROL

ELIMINAR PRIVILEGIO - USUARIO

ELIMINAR PRIVILEGIO

-ROL

CREAR TIPO PARAMETRO

CREAR PARAMETRO

ELIMINAR TIPO

PARAMETRO

ELIMINAR PARAMETRO

ASPIRANTE

DOCENTE

OPERADOR EFOT X X

JEFE DEPARTAMENTAL X X

DIRECTOR ESCUELA X X

ADMINISTRADOR_SIS X X X X X X X X

Fuente: Investigación Autor: Investigadores

189

Entregables del proyecto

Modelado de procesos

Diagrama de Casos de Usos

Diagrama de Clases Diseño del sistema

CRITERIOS DE VALIDACIÓN DE LA PROPUESTA

JUICIO DE EXPERTOS

La propuesta fue presentada al Director de la Escuela de Formación de Oficiales

y Tropa el cual dio su visto bueno al inicio del presente estudio y autorizando la

recopilación de la información necesaria en todas las unidades técnicas y

administrativas de la institución. En dicha aprobación se planteó los alcances del

estudio y las ventajas que tendría implementar el sistema en el desempeño

institucional.

Los jefes departamentales entrevistados durante la investigación mostraron su

apoyo a este tipo de estudios que permitirán la implementación posterior de un

sistema que apoyará las actividades académicas diarias que realizan en la

Escuela de Formación. Los operadores o personal administrativo expusieron las

opiniones en cuanto a la mejora de los procesos que acarrea este tipo de

implementaciones.

190

CAPÍTULO IV

CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO

Para que el producto de la presente investigación sea aceptado por el

personal de la Escuela de Formación de Oficiales y Tropa, deben cumplir

las siguientes características:

Los modelos deben ser claros y deberán abarcar todos los

escenarios planteados en las necesidades de la institución y los

alcances propuestos en el primer capítulo del presente documento.

Los modelos deberán garantizar la seguridad de la información que

se almacene y /o transmita a través del sistema.

Los modelos planteados deberán acoplarse de manera adecuada a

los sistemas que ya posee la Comisión de Tránsito del Ecuador.

El nuevo sistema debe mantener el diseño de su interfaz acorde a

los demás sistemas y páginas web que maneja la institución.

Que el nuevo sistema almacene los rastros de auditoria

correspondiente en cuanto a registro, modificación de la información

almacenada.

191

CONCLUSIONES Y RECOMENDACIONES

CONCLUSIONES

Una vez desarrollado el presente trabajo de titulación, se puede concluir que:

Se realizó el levantamiento de información que sirvió de insumo para

modelar los procesos de convocatoria, reclutamiento, formación,

especialización y ascenso en la Escuela de Formación de Oficiales y Tropa

de la Comisión de Tránsito del Ecuador, determinando los requerimientos

del sistema propuesto para lo cual también se presentan los procesos

ajustados en caso de implementar el sistema.

Se desarrolló un diseño adecuado para el sistema propuesto que busca

satisfacer las necesidades encontradas en los procesos estudiados. El

diseño de la aplicación está representada por los modelos diseñados

utilizando el lenguaje UML y define de manera clara todos los aspectos del

sistema. Los modelos representan al sistema en los aspectos de estructura

y funcionamiento.

El diseño propuesto se desarrolló en conjunto con los funcionarios que

realizan los procesos regularmente y manifestaron su beneplácito en

cuanto a la existencia de un sistema con las características explicadas.

Se desarrolló un plan de desarrollo del proyecto donde se dimensiona los

recursos y actividades necesarias para desarrollar el sistema en base al

documento presentado. Este plan de proyecto presenta los valores que se

deberá invertir en el caso de que la institución crea pertinente la

implementación de esta herramienta informática.

192

RECOMENDACIONES

Una vez culminado el presente trabajo de titulación se puede recomendar

lo siguiente:

Cuando se implemente el sistema informático propuesto que éste sea

desarrollado un lenguaje orientado a objetos ya que los modelos

presentados siguen del paradigma de orientación de objetos.

Que el equipo de desarrollo del sistema que se forme para la construcción

del sistema web, tome como fundamento para la implementación los

modelos desarrollados en el presente documento.

Que, una vez desarrollada la aplicación web, se agregue/configure

certificados SSL con la finalidad de proveer a los usuarios la seguridad

necesaria de que sus datos no serán interceptados.

Que los datos sensibles almacenados en la base de datos, sean

encriptados para proveer un nivel de seguridad adecuado de los datos.

Que se implemente un manual de políticas de seguridad que deberán ser

aprobadas por el Director de la Escuela de Formación de Oficiales y Tropa

en cuanto al uso del sistema y la protección de los datos.

Que se implemente un modelo/política de réplica y/o respaldo de la

información almacenada en el sistema informático.

Que se elabore un proceso / equipo de detección y recuperación de

incidentes de seguridad informática con la finalidad de mantener la

integridad y disponibilidad del sistema.

Que, en el caso de que la arquitectura presentada pueda llegar a no ser

suficiente para la atención de los usuarios, se diseñe una alternativa a

través de arquitectura distribuida y equipos balanceadores de carga y

espejos

193

Anexos

194

PLAN DE DESARROLLO

1. Introducción

Este Plan de Desarrollo del Software es una versión preliminar preparada

para ser incluida en la propuesta elaborada como respuesta al proyecto

implementación de “Diseño del sistema web para la gestión de aspirantes

para la “Escuela De Formación De Oficiales y Tropa” de la Comisión de

Transito del Ecuador, en las etapas de Reclutamiento, Formación,

Especialización y Ascenso”. Este documento provee una visión global del

enfoque de desarrollo propuesto.

El proyecto está basado en una metodología de Rational Unified Process

en la que únicamente se procederá a cumplir con las tres primeras fases

que marca la metodología, constando únicamente en la tercera fase de dos

iteraciones. Es importante destacar esto puesto que utilizaremos la

terminología RUP en este documento. Se incluirá el detalle para las fases

de Inicio y Elaboración y adicionalmente se esbozarán las fases

posteriores de Construcción y Transición para dar una visión global de todo

proceso.

El enfoque desarrollo propuesto constituye una configuración del proceso

RUP de acuerdo a las características del proyecto, seleccionando los roles

de los participantes, las actividades a realizar y los artefactos (entregables)

que serán generados. Este documento es a su vez uno de los artefactos

de RUP.

a. Propósito

El propósito del Plan de Desarrollo de Software es proporcionar la

información necesaria para controlar el proyecto. En él se describe

el enfoque de desarrollo del software.

Los usuarios del Plan de Desarrollo del Software son:

195

El líder del proyecto lo utiliza para organizar la agenda y

necesidades de recursos, y para realizar su

seguimiento.

Los miembros del equipo de desarrollo lo usan para

entender lo qué deben hacer, cuándo deben hacerlo y

qué otras actividades dependen de ello.

b. Alcance

Este documento es un enfoque preliminar del plan para el

desarrollo del proyecto implementación de “Diseño del sistema

web para la gestión de aspirantes para la “Escuela De Formación

De Oficiales y Tropa” de la Comisión de Transito del Ecuador, en

las etapas de Reclutamiento, Formación, Especialización y

Ascenso”. Se pretende establecer un calendario base para llevar el

control de las fases del proyecto por lo tanto las fechas de inicio y

fin del proyecto varían de acuerdo a las necesidades y condiciones

de la institución.

Es decir este documento deba adaptarse de acuerdo al desarrollo

del software.

c. Resumen

Luego de esta introducción, el documento está organizado en las

siguientes secciones:

Visión General del Proyecto — proporciona una descripción

del propósito, alcance y objetivos del proyecto,

estableciendo los artefactos que serán producidos y

utilizados durante el proyecto.

196

Organización del Proyecto — describe la estructura

organizacional del equipo de desarrollo.

Gestión del Proceso — explica los costos y planificación

estimada, define las fases e hitos del proyecto y describe

cómo se realizará su seguimiento.

2. Visión general del proyecto

a. Propósito, Alcance y Objetivos

Esta información debe ser un resumen del proyecto

implementación de “Diseño del sistema web para la gestión de

aspirantes para la “Escuela De Formación De Oficiales y Tropa”

de la Comisión de Transito del Ecuador, en las etapas de

Reclutamiento, Formación, Especialización y Ascenso”.

La Escuela De Formación De Oficiales y Tropa se encarga de

“Formar y capacitar agentes de tránsito con las habilidades

científicas, técnicas y humanísticas, con personal profesional en

materias en tránsito y transporte terrestre, para garantizar la

seguridad vial y movilidad sostenible”. Lo que permite contar con

el personal altamente capacitado para cumplir las tareas

encomendadas por las leyes de la república.

El proyecto debe proporcionar una propuesta para el desarrollo de

todos los subsistemas implicados.

197

b. Suposiciones y restricciones

Las suposiciones y restricciones respecto del sistema, y que se

derivan directamente del levantamiento de información, análisis y

diseño previamente realizado.

La lista de suposiciones y restricciones se incrementarán durante

el desarrollo del proyecto,

c. Entregables del proyecto

A continuación se indican y describen cada uno de los entregables

que serán generados y utilizados por el proyecto.

Plan de desarrollo de software

Modelos de casos de uso

Descripciones de casos de uso

Prototipos de interfaz de usuario

Definición de arquitectura

Producto final

198

3. Organización del Proyecto.

Se determinan los recursos humanos que se necesitan para el desarrollo

del mismo y sus responsabilidades.

Tabla 79 – Organización del proyecto

PERSONA

CARGO

RESPONSABILIDADES

Recurso_01 Líder de Proyecto Establecer condiciones de trabajo.

Dirigir recursos.

Asignar recursos.

Asignar tareas.

Coordinar reuniones con usuarios.

Planificar tareas.

Definir prioridades de las tareas del proyecto.

Define organización y estructura del proyecto.

Planifica reuniones con desarrolladores.

Recurso_02 desarrollador

Documentar el código.

Realiza la codificación de los componentes en el lenguaje de programación establecido.

Diseñar el programa.

Elaborar el programa con los diseños de software.

Dar soporte del programa.

Establece la pruebas del programa

Ejecuta pruebas del programa.

Realizar cambios y mejoras de acuerdo a los resultados del software.

Documentar las pruebas realizadas.

Cumplir con las normas de seguridad de software

Elaborar informes de las actividades

Recurso_03

199

Recurso_04 DBA Instalar los componentes del software de base de datos.

Instalar la aplicación de desarrollo de la base de datos

Implementar el diseño de la base de datos

Definir diccionario de datos.

Administrar la estructura de la base de datos.

Verificar controles de seguridad de la base de datos.

Realizar respaldos.

Prevenir riesgos.

Documentar todo lo efectuado en la base de datos, diseño, modificaciones, etc.

Fuente: Investigación Autor: Investigadores

200

4. Gestión del proyecto

a. Estimaciones del proyecto

Se realizó la estimación económica y de recursos humanos para el

desarrollo e implementación del proyecto basados en el análisis

realizado por los investigadores. Para realizar la estimación se

determinó el número de recursos humanos que se necesitaran para

el desarrollo e implementación del mismo.

Las estimaciones se muestran en la siguiente tabla:

Tabla 80 – Gestión del proyecto

RECURSO VALOR MENSUAL VALOR TOTAL

Líder De Proyecto $ 1.500,00 $ 12.000,00

DBA $ 1.500,00 $ 12.000,00

Desarrollador(2) $ 900,00 $ 7.200,00

Otros Gastos

(contratar personal)

$ 400,00 $ 3.200,00

Recursos de Oficina $ 300,00 $ 2.400,00

Costo total $ 36.800,00

Tiempo Total para desarrollo del proyecto 8 meses (32 semanas)

Fuente: Investigación Autor: Investigadores

201

5. Plan del proyecto

Se detallan las fases del proyecto y el calendario del proyecto.

a. Fases del proyecto

Tabla 81 – Fases

Fase Nro.

iteraciones Duración

Fase inicio 1 4

Fase de elaboración 2 16

Fase construcción 1 8

Fase de transición 2 4

Fuente: Investigación Autor: Investigadores

b. Descripción de las fases

Tabla 82 - Descripción de fases

DESCRIPCIÓN

HITO

Fase inicio En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta fase.

Fase de elaboración

En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase.

Fase construcción

Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la release 3.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta.

Fase de transición

En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto.

Fuente: Investigación Autor: Investigadores

202

c. Calendario del proyecto

A continuación se presenta un calendario de las principales tareas

del proyecto.

Imagen 58 - Calendario

Fuente: Investigación Autor: Investigadores

6. Infraestructura necesaria

De acuerdo con los requerimientos y tomando en cuenta que el ERP debe

ser desarrollado utilizando tecnología de la empresa Microsoft, y para el

correcto funcionamiento del sistema ERP para constructores de vivienda

asociados, se recomienda adquirir los siguientes equipos y licencias con

las características mínimas mostradas:

203

Tabla 83 – Infraestructura

CANTIDAD

EQUIPO

CARACTERÍSTICA

3 Esquipo de computo servidor Servidor HP ProLiant ML310e Gen8 v2 - Servidor (3.1 GHz, Intel Xeon, E3-1220, 2000 GB, 1000 GB, SATA)

4 Equipos de cómputo para desarrollo

Procesador Intel® Core™ i5-6200U (3M Cache, up to 2.80 GHz) memoria RAM 8gb Adv ECC, Disco Duro 500GB 7.2K RPM SATA 3.5" Hot Plug Hard Drive, DVD-ROM, SATA, Internal, tarjeta de red Embedded Broadcom® NetXtreme II 5709 Gigabit Ethernet NIC

1 No break Capacidad: 420 VA

Tecnología: interactiva

Regulación: SI

Tiempo de respaldo: 13 min.

Voltaje de entrada: 120 VOLTS

Voltaje de salida: 120 VOLTS

Conexión de entrada: NEMA 5-15 P

Conexión de salida: (4) NEMA 5-15 R

Rango de entrada: 82 - 144 VOLTS

Licencia Oracle

Desarrollo de la base de datos

Licencia java Desarrollo de la aplicación web

Licencia antivirus Antivirus

Fuente: Investigación Autor: Investigadores

Cabe señalar también, que la naturaleza y ejecución del sistema será en un ambiente web que deberá tener presencia pública sobre Internet. De esta forma, se sugieren una de dos cosas:

1. Permisos para usar el dominio de la Comisión de tránsito del Ecuador.

2. Reutilizar equipos para ahorrar costos de adquisición.

204

CRONOGRAMA DE ACTIVIDADES

Imagen 59 – Cronograma 1

Fuente: Investigación

Autor: Investigadores

205

Imagen 60 – Cronograma 2

Fuente: Investigación

Autor: Investigadores

206

Imagen 61 – Cronograma 3

Fuente: Investigación

Autor: Investigadores

207

Imagen 62 – Cronograma 4

Fuente: Investigación

Autor: Investigadores

208

Imagen 63 – Cronograma 5

Fuente: Investigación

Autor: Investigadores

209

Imagen 64 – Cronograma 6

Fuente: Investigación

Autor: Investigadores

210

BIBLIOGRAFÍA

Bibliografía

Bertoa, M., Troya, J., & Vallecillo, A. (2010). Aspectos de Calidad en el Desarrollo de Software Basado en Componentes. Depto. Lenguajes y Ciencias de la Computación. Universidad de Málaga.

Breugge, B., & Allen, D. (2002). Ingeniería de Software Orientado a Objetos. México: pearson Education.

Fernández, J. M. (01 de 01 de 2011). Universidad Veracruzana. Obtenido de Universidad Veracruzana: http://www.uv.mx/personal/jfernandez/files/2010/07/8_Calidad.pdf

ISO. (s.f.). ISO-8402. ISO-8402. López, A., Cabrera, C., & Valencia, L. (2008). INTRODUCCIÓN A LA

CALIDAD DE SOFTWARE. Scientia et Technica - Universidad Tecnológica de Pereira. ISSN 0122-1701 , 326-331.

Mateu, C. (2009). Software libre - Desarrollo de aplicaciones web. Barcelona: Fundació per a la Universitat Oberta de Catalunya.

Palacios, R., & Puente, C. (2014). Introducción a programas en el lado del cliente. En R. Palacios, & C. Puente, DESARROLLO DE APLICACIONES WEB (pág. 3). Madrid: Escuela Técnica Superior de Ingeniería.

Sommerville, I. (2005). Ingeniería del Software. Madrid: PEARSON EDUCACIÓN. S.A.