Desarrollo del sistema de seguimiento de procesos de la SERCOP

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica- Escuela de Sistemas

DESARROLLO DEL SISTEMA DE SEGUIMIENTO DE PROCESOS DE LA SERCOP PARA LA AUTOMATIZACIÓN DEL CONTROL DE PROCESOS DE PROYECTOS EN EL DEPARTAMENTO DE CONTROL DE ENERGÍA DE LA CNEL EP CANTÓN SANTO DOMINGO EN EL AÑO 2013

Disertación de Grado previa a la obtención del título de Ingeniero de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software

Autor: EDWIN DAVID VILLAMARÍN ROJAS Asesor: MG. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo- Ecuador Octubre, 2014

ii

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica- Escuela de Sistemas HOJA DE APROBACIÓN DESARROLLO DEL SISTEMA DE SEGUIMIENTO DE PROCESOS DE LA SERCOP PARA LA AUTOMATIZACIÓN DEL CONTROL DE PROCESOS DE PROYECTOS EN EL DEPARTAMENTO DE CONTROL DE ENERGÍA DE LA CNEL EP CANTÓN SANTO DOMINGO EN EL AÑO 2013 Línea de Investigación: Estudio, Diseño e Implementación de Software

Autor:

EDWIN DAVID VILLAMARÍN ROJAS Rodolfo Sirilo Córdova Gálvez, Mg. DIRECTOR DE LA DISERTACIÓN DE GRADO

f.

Fausto Ernesto Orozco Iguasnia, Ing. CALIFICADOR

f.

César Rodrigo Mejía Ramos, Mg. CALIFICADOR

f.

Rodolfo Sirilo Córdova Gálvez, Mg. DIRECTOR DE LA ESCUELA DE SISTEMAS

f.

Santo Domingo- Ecuador Octubre, 2014

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Edwin David Villamarín Rojas portador de la cédula de ciudadanía No. 0802172205, declaro que los resultados obtenidos en la investigación que presento como informe final, previo la obtención del Grado de Ing. de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Edwin David Villamarín Rojas CI. 080217220-5

iv

AGRADECIMIENTOS

Agradezco a Dios, por haberme dado la vida, la salud y la capacidad para desarrollar con éxito la presente disertación. A mi padre Edwin Villamarín Córdova, por ser mi guía espiritual y por brindarme su apoyo incondicional en todo momento. Al Ing. Romel Analuisa, jefe del área de Control de Energía de la CNEL EP Santo Domingo, por permitirme hacer uso de sus instalaciones. A la PUCESD en conjunto con el Estado Ecuatoriano por las becas que me otorgaron para continuar mi carrera. Al director de disertación Mg. Rodolfo Córdova por su tiempo y disposición.

v

DEDICATORIA

La presente disertaci贸n de grado se la dedico a la memoria de mi madre, Patricia Rojas Delgado, mujer memorable, a ella le debo todo lo que soy y ser茅, sus consejos quedaron grabados en mi mente y me motivaron a cumplir esta meta. A mi padre Edwin Villamar铆n C贸rdova y su esposa Ximena Andrade. A mis hermanos Sara Patricia, Querles Steeven, Joseph Gustavo y Edwina Juseth, los quiero mucho.

vi

RESUMEN

La presente disertación de grado consiste en el diseño, desarrollo e implementación del Sistema de Seguimiento de los Procesos del SERCOP (Servicio Nacional de Contratación Pública), denominado SSPS, el cual fue desarrollado para la Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad Santo Domingo, con la finalidad de alertar la hora de ejecución de tareas de los procesos del SERCOP por realizarse en el día y anticipar las que deberán realizase el día siguiente en el área de control de Energía. SSPS se desarrolló aplicando la metodología de desarrollo ágil Programación Extrema (XP). Se utilizó el lenguaje Visual Basic.NET, se utilizó el IDE Microsoft Visual Studio 2008 para su codificación, aprovechando que la empresa cuenta con la licencia para el desarrollo de aplicaciones. Como Sistema Gestor de Bases de Datos se utilizó MySQL de licencia libre. SSPS utiliza una conexión a un servidor SMTP para el envío de emails desde el sistema. SSPS se divide en 2 aplicaciones: SSP_Desktop y SSP_Secretaria. SSP_Desktop es la aplicación principal, la cual contiene todos los módulos y operaciones de ingreso de información, dispone además de auditorías de procesos y de usuarios, en esta aplicación los recordatorios de tareas son mostrados al usuario dentro del mismo sistema, mientras que SSP_Secretaria trabaja conjuntamente con la aplicación SSP_Desktop y permite envíos automáticos de correos electrónicos con recordatorios y reportes de las actividades por realizarse a las cuentas de correo interinstitucionales de cada usuario implicado.

vii

ABSTRACT

This grade dissertation consists of the design, development and implementation of the Monitoring of SERCOP Processes’s System (National Service of Public Hiring), called SSPS, which was developed for the Strategic Public Utility National Electricity Corporation Santo Domingo, in order to alert when be held the task execution of processes SERCOP at the day and anticipate the tasks to be executed the next day in the Energy control area. SSPS was developed using the agile development methodology Extreme Programming (XP). Visual Basic.NET language was used, for coding we used the Microsoft Visual Studio 2008 IDE, taking advantage that the company is licensed for application development. As Database Management System we used MySQL Open Source. SSPS uses a connection to an SMTP server for sending emails from the system.

SSPS is divided into 2 applications: SSP_Desktop and SSP_Secretariat. SSP_Desktop is the main application, which contains all modules and data entry operations, also provides an auditing of processes and users, the execution task reminders are displayed to the user within the same system, while SSP_Secretariat works together with SSP_Desktop application and allows automatic emailing with reminders and reporting activities’s to be conducted to interagency email accounts of each user involved.

viii

ÍNDICE DE CONTENIDOS HOJA DE APROBACIÓN ............................................................................................... ii DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD ............................. iii AGRADECIMIENTOS ................................................................................................... iv DEDICATORIA ............................................................................................................... v RESUMEN…................................................................................................................... vi ABSTRACT… ................................................................................................................ vii I. INTRODUCCIÓN A LA DISERTACIÓN DE GRADO ......................................... 18 II. PLANTEAMIENTO DEL PROBLEMA .................................................................. 20 2.1. Antecedentes ........................................................................................................... 20 2.2. Problema de investigación ...................................................................................... 21 2.3. Justificación de la investigación.............................................................................. 22 2.4 Objetivos de la investigación ................................................................................... 24 2.4.1 Objetivo General ................................................................................................... 24 2.4.2 Objetivos Específicos ............................................................................................. 24 III. MARCO REFERENCIAL ....................................................................................... 25 3.1 Revisión de la literatura o fundamentos teóricos ...................................................... 25 3.1.1 Ingeniería de Software .......................................................................................... 25 3.1.1.1 Ciclo de vida del software .................................................................................. 27 3.1.1.2 Metodologías de Desarrollo de Software ........................................................... 33 3.1.1.2.1 Metodologías Clásicas ..................................................................................... 34 3.1.1.2.1.1 Modelo Basado en Prototipos ...................................................................... 34

ix

3.1.1.2.1.2 Modelo en Espiral ........................................................................................ 36 3.1.1.2.1.3 Proceso Unificado de Rational ..................................................................... 37 3.1.1.2.2 Metodologías Ágiles ........................................................................................ 38 3.1.1.2.2.1 Manifiesto Ágil ............................................................................................ 40 3.1.1.2.2.2 Programación Extrema (XP) ......................................................................... 42 3.1.1.2.2.2.1 Variables de Control XP ........................................................................... 43 3.1.1.2.2.2.2 Valores en XP ........................................................................................... 43 3.1.1.2.2.2.3 Roles en XP ............................................................................................... 45 3.1.1.2.2.2.4 Proceso de desarrollo de software XP ....................................................... 46 3.1.1.2.2.2.5 Principios y Prácticas ................................................................................. 50 3.1.1.2.2.2.6 XP Comparado con otras Metodologías ................................................... 51 3.1.1.3 Paradigmas de Programación ............................................................................. 56 3.1.1.3.1 Programación Orientada a Objetos (POO) ...................................................... 56 3.1.1.4 Arquitectura Cliente Servidor ............................................................................ 57 3.1.2 Bases de Datos ....................................................................................................... 58 3.1.2.1 Sistemas Gestores de Base de Datos ................................................................... 59 3.1.2.1.1 Oracle ............................................................................................................... 60 3.1.2.1.2 PostgreSQL ...................................................................................................... 60 3.1.2.1.3 MySQL............................................................................................................. 61 3.1.2.2 Lenguaje SQL ..................................................................................................... 61 3.1.2.2.1 DDL (Data Description Languaje) ................................................................... 62 3.1.2.2.2 DML (Data Manipulation Languaje) ............................................................... 62 3.1.2.3 Modelo de Datos ................................................................................................. 62

x

3.1.2.3.1 Modelo Relacional ........................................................................................... 63 3.1.3 Lenguajes de Programación ................................................................................... 64 3.1.3.1 Microsoft Visual Studio.NET ............................................................................. 64 3.1.3.1.1 Visual Basic.NET............................................................................................. 65 3.1.4 Servicio Nacional de Contratación Pública (SERCOP) ......................................... 65 3.1.4.1 Proceso interno para Adquisiciones del SERCOP .............................................. 67 3.1.5.2 Procesos del Servicio Nacional de Contratación Pública ................................... 68 3.1.5.2.1 Subasta Inversa Electrónica ............................................................................. 68 3.1.5.2.2 Cotización ........................................................................................................ 69 3.1.5.2.3 Licitación.......................................................................................................... 70 3.1.5.2.4 Mínima Cuantía ................................................................................................ 70 3.1.5.2.5 Tiempos establecidos para la ejecución de procesos ....................................... 71 3.2. Investigaciones o experiencias empíricas vinculadas con el problema de investigación. .................................................................................................................. 72 3.3. Hipótesis de trabajo .................................................................................................. 73 IV. METODOLOGÍA DE LA INVESTIGACIÓN ........................................................ 74 4.1 Diseño y tipo de Investigación .................................................................................. 74 4.1.1 Diseño de la investigación ..................................................................................... 74 4.1.1.1 Diseño no experimental....................................................................................... 74 4.1.1.1.2 Estudio Descriptivo ......................................................................................... 74 4.1.2 Tipo de investigación ............................................................................................. 75 4.1.2.1 Investigación Documental – Bibliográfica.......................................................... 75 4.1.2.2 Investigación de Campo ...................................................................................... 75

xi

4.1.2.3 Investigación Proyectiva Aplicable..................................................................... 76 4.2 Población/Universo .................................................................................................. 76 4.3. Muestra.. ................................................................................................................... 76 4.3.1 Muestra de una población pequeña ........................................................................ 76 4.3.2 Muestra de una población extensa ......................................................................... 77 4.4 Instrumentos de Recogida de Datos .......................................................................... 77 4.4.1 Entrevista................................................................................................................ 77 4.4.2 Encuesta ................................................................................................................. 78 4.5 Técnicas de Análisis de Datos ................................................................................. 80 4.5.1 Cuadros Estadísticos .............................................................................................. 80 4.6 Programación Extrema (XP) .................................................................................... 80 4.6.1 Planeación .............................................................................................................. 80 4.6.1.1 Roles en XP ......................................................................................................... 80 4.6.1.2 Historias de Usuario ............................................................................................ 81 4.6.1.3 División en iteraciones ........................................................................................ 81 4.6.1.4 Velocidad del proyecto ....................................................................................... 82 4.6.1.5 Entregas pequeñas ............................................................................................... 82 4.6.1.6 Plan de Entregas .................................................................................................. 82 4.6.1.7 Mover Personal ................................................................................................... 83 4.6.2 Diseño… ................................................................................................................ 83 4.6.2.1 Simplicidad ......................................................................................................... 83 4.6.2.2 Tarjetas CRC ....................................................................................................... 84 4.6.2.3 Refactorización .................................................................................................. 84

xii

4.6.3 Codificación .......................................................................................................... 85 4.6.3.1 Cliente siempre presente .................................................................................... 85 4.6.3.2 Utilización de Estándares en el código .............................................................. 85 4.6.3.3 Codificar primero la prueba ............................................................................... 85 4.6.3.4 Programación en Parejas .................................................................................... 86 4.6.3.5 Integración Secuencial ....................................................................................... 86 4.6.3.6 Integraciones Frecuentes .................................................................................... 87 4.6.3.7 Propiedad colectiva del código .......................................................................... 87 4.6.3.8 Evitar Horas Extras de trabajo ........................................................................... 87 4.6.4 Pruebas .................................................................................................................. 88 4.6.4.1 Pruebas Unitarias ............................................................................................... 88 4.6.4.2 Pruebas de Aceptación ....................................................................................... 89 V. RESULTADOS ......................................................................................................... 90 5.1 Discusión y análisis de los resultados ....................................................................... 90 5.1.1 Encuesta aplicada a los empleados de la CNEL EP SD. ....................................... 90 5.1.1.1 Introducción ........................................................................................................ 90 5.1.1.2 Metodología ........................................................................................................ 90 5.1.1.3 Tabulación y análisis de la información.............................................................. 91 5.1.2 Metodología de desarrollo Programación Extrema en la elaboración del Sistema SSPS………… .............................................................................................................. 101 5.1.2.1 Proceso de desarrollo de la Metodología XP .................................................... 101 5.1.2.2 Planificación ...................................................................................................... 101 5.1.2.2.1 Especificación de Requerimientos de Software (SRS) .................................. 101

xiii

5.1.2.2.2 Análisis y Gestión de Riesgos ........................................................................ 103 5.1.2.2.3 Historias de Usuario SSPS ............................................................................. 113 5.1.2.2.4 Velocidad del Proyecto SSPS ........................................................................ 114 5.1.2.2.5 Plan de Entregas ............................................................................................. 115 5.1.2.2.6 Reunión inicial del Proyecto XP ................................................................... 115 5.1.2.3 Diseño ............................................................................................................... 116 5.1.2.3.1 Metáfora del Sistema SSPS............................................................................ 116 5.1.2.3.2 Tarjetas CRC .................................................................................................. 117 5.1.2.3.3 Modelado Base de Datos SSPS ...................................................................... 117 5.1.2.4 Codificación y pruebas ...................................................................................... 121 5.2 Conclusiones ........................................................................................................... 123 5.3 Límites y Recomendaciones ................................................................................... 123 FUENTES DE INFORMACIÓN .................................................................................. 125 Bibliográficas ................................................................................................................ 125 Lincográficas…………………………………………………………………………..126 Hemerográficas ............................................................................................................. 126

xiv

ÍNDICE DE ILUSTRACIONES Ilustración 3. 1: Capas de la Ingeniería de Software ........................................................ 26 Ilustración 3. 2: Ciclo de Vida del Software - Modelo Cascada ..................................... 28 Ilustración 3. 3: Ciclo de vida - Modelo en V .................................................................. 31 Ilustración 3. 4: Ciclo de Vida Incremental ..................................................................... 32 Ilustración 3. 5: Modelo de Prototipos ............................................................................. 35 Ilustración 3. 6: Modelo en Espiral .................................................................................. 36 Ilustración 3. 7: Proceso Unificado de Rational............................................................... 38 Ilustración 3. 8: Proceso de la metodología Programación Extrema (XP) ...................... 46 Ilustración 3. 9: Fase de Diseño XP ................................................................................. 48 Ilustración 3. 10: Entorno de Trabajo XP ........................................................................ 49 Ilustración 3. 11: Representación Arquitectura Cliente - Servidor .................................. 58 Ilustración 3. 12: Logo de Oracle ..................................................................................... 60 Ilustración 3. 13: Logo de PostgreSQL ............................................................................ 60 Ilustración 3. 14: Logo de MySQL .................................................................................. 61 Ilustración 3. 15: Ciclo de vida clásico de modelado de datos ........................................ 62 Ilustración 3. 16: Estructura de una tabla en el Modelo Relacional................................. 63 Ilustración 3. 17: Logo del SERCOP ............................................................................... 65 Ilustración 3. 18: Filosofía del Servicio Nacional de Contratación Pública .................... 66 Ilustración 3. 19: Flujograma de inicio de un proceso SERCOP ..................................... 67 Ilustración 3. 20: Etapas de Subasta Inversa Electrónica ................................................. 69 Ilustración 3. 21: Etapas de Cotización ............................................................................ 69

xv

Ilustración 3. 22: Etapas de Licitación ............................................................................. 70 Ilustración 3. 23: Etapas de Menor Cuantía ..................................................................... 71 Ilustración 3. 24: Tiempos establecidos para la ejecución de procesos ........................... 71 Ilustración 3. 25: División por Zonas de Ecuador........................................................... 72

Ilustración 4. 2: Formula para el cálculo de la muestra en población extensa ................. 77

Ilustración 5. 1: Problemas recordar fechas del SERCOP ............................................... 91 Ilustración 5. 2: Casos de procesos caídos ....................................................................... 92 Ilustración 5. 3: Factores frecuentes caída de procesos SERCOP ................................... 94 Ilustración 5. 4: Olvido fechas del SERCOP ................................................................... 95 Ilustración 5. 5: Métodos para recordar fechas de procesos ............................................ 96 Ilustración 5. 6: Problema al editar un documento en la red ............................................ 97 Ilustración 5. 7: Tiempo promedio consultar fechas ........................................................ 99 Ilustración 5. 8: Implementar Sistema de Seguimiento ................................................. 100 Ilustración 5. 9: Modelo Relacional SSPS ..................................................................... 118 Ilustración 5. 10: CD de Instalación SSPS ..................................................................... 121 Ilustración 5. 11: Portada del CD de Instalación............................................................ 121 Ilustración 5. 12: Entrega del Software SSPS al Jefe del Área de Control de Energía .. 122

xvi

ÍNDICE DE TABLAS Tabla 3. 1: Empresas Multinacionales que usan metodologías ágiles. ............................ 40 Tabla 3. 2: Roles en XP.................................................................................................... 45 Tabla 3. 3: Principios y Prácticas en XP .......................................................................... 50 Tabla 3. 4: Comparativa de Metodologías con XP .......................................................... 51 Tabla 3. 5: Conceptos Fundamentales POO. ................................................................... 56 Tabla 3. 6: Funciones de un Sistema Gestor de Base de Datos ....................................... 59 Tabla 3. 7: Componentes del Modelo Relacional ............................................................ 63 Tabla 3. 8: Principios del Servicio Nacional de Contratación Pública ............................ 66

Tabla 5. 1: Datos previos de la encuesta realizada........................................................... 90 Tabla 5. 2: Problemas recordar fechas del SERCOP ....................................................... 91 Tabla 5. 3: Casos de procesos caídos ............................................................................... 92 Tabla 5. 4: Factores frecuentes caída de procesos SERCOP ........................................... 93 Tabla 5. 5: Olvido fechas del SERCOP ........................................................................... 94 Tabla 5. 6: Métodos para recordar fechas de procesos .................................................... 95 Tabla 5. 7: Problema al editar un documento en la red .................................................... 97 Tabla 5. 8: Tiempo empleado consultar fechas ................................................................ 98 Tabla 5. 9: Implementar Sistema de Seguimiento ......................................................... 100 Tabla 5. 10: Especificación de Requerimientos de Software SSPS: .............................. 101 Tabla 5. 11: Clasificación de los Riesgos ...................................................................... 103 Tabla 5. 12: Identificación de los Riesgos del Proyecto ................................................ 104 Tabla 5. 13: Definición de la valoración de Riesgos ..................................................... 105

xvii

Tabla 5. 14: Análisis y Valoración de Riesgos .............................................................. 106 Tabla 5. 15: Hoja Gestión de Riegos 1 .......................................................................... 107 Tabla 5. 16: Hoja Gestión de Riegos 2 .......................................................................... 107 Tabla 5. 17: Hoja Gestión de Riegos 3 .......................................................................... 108 Tabla 5. 18: Hoja Gestión de Riegos 4 .......................................................................... 109 Tabla 5. 19: Hoja Gestión de Riegos 5 .......................................................................... 110 Tabla 5. 20: Hoja Gestión de Riegos 6 .......................................................................... 110 Tabla 5. 21: Hoja Gestión de Riegos 7 .......................................................................... 111 Tabla 5. 22: Hoja Gestión de Riegos 8 .......................................................................... 112 Tabla 5. 23: Historias de Usuario SSPS ......................................................................... 113 Tabla 5. 24: Velocidad y Duración del Proyecto SSPS ................................................. 114 Tabla 5. 25: Plan de Entregas SSPS ............................................................................... 115 Tabla 5. 26: Estándares Aplicados en SSPS .................................................................. 116 Tabla 5. 27: Procedimientos Almacenados SSPS .......................................................... 118

I.

INTRODUCCIÓN A LA DISERTACIÓN DE GRADO

La siguiente disertación se enfocó en el análisis, diseño, codificación, pruebas e implantación

del Sistema de Seguimiento de los Procesos del SERCOP (Servicio

Nacional de Contratación Pública), denominado SSPS, para la Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad Agencia Santo Domingo (CNEL EP SD) aplicando la metodología de desarrollo ágil Programación Extrema (XP).

En la sección II el planteamiento del programa trata del origen de la CNEL EP en Santo Domingo y los inconvenientes del problema que conllevo a la investigación. En la subsección 2.1 se presenta en la práctica investigativa los antecedentes que constituyen el trasfondo del problema de investigación, es decir, la presentación de la temática a ser investigada con miras a ubicar el problema en un contexto específico de la investigación.

En la subsección 2.2 consta de la delimitación del problema de investigación, es la idea que se convierte en objeto de reflexión y de estudio del proyecto de investigación, se respondió a la pregunta ¿Qué estudiar o qué investigar? , se encapsuló el problema y se especificó lo que se va a solucionar por medio de la investigación, para ello se utilizó una especificación de requerimientos de software. En la subsección 2.3 se detalló la justificación de la investigación la cual contiene argumentos por la cual el software se desarrolló. En la sección 2.4, se planteó los objetivos de la investigación como son el objetivo general que contiene de manera general la función del sistema, y los objetivos específicos los cuales detallaron los procedimientos para desarrollar el sistema de acuerdo a la metodología utilizada.

18

19

La sección III contiene el marco referencial, en la subsección 3.1 se detalló la revisión de la literatura o fundamentos teóricos utilizados en el software que fueron el fundamento teórico en el que se respaldó el desarrollo de la disertación, en la subsección 3.2 se detalló las investigaciones o experiencias empíricas vinculadas con el problema de investigación, la subsección 3.3 se detalló la hipótesis en la que se formuló una suposición de lo que solucionaría el sistema.

La sección IV contiene la metodología de investigación que se utilizó en la disertación, en la subsección 4.1 se detalló el diseño y tipo de investigación, la subsección 4.3 define la población o universo al que fue dirigida la investigación, la subsección 4.4 se especificó la muestra que se utilizó para la encuesta, la subsección 4.5 contiene los instrumentos de recogida de datos que se utilizaron para el desarrollo de la investigación, la subsección 4.6 contiene las técnicas de análisis de los datos recogidos y la subsección 4.7 detalla el desarrollo paso a paso aplicando la XP. En la sección V contiene él análisis de resultados y discusión, en donde se materializó la investigación realizada y el resultado de la metodología de software, la subsección 5.1 detalla la discusión y análisis de los resultados obtenidos, en la subsección 5.2 detalla las conclusiones pertinentes a los resultados de la investigación y desarrollo de la metodología de software, y finalmente en la subsección 5.3 detalla los límites y las recomendaciones en torno a la desarrollo de la disertación.

II.

PLANTEAMIENTO DEL PROBLEMA

El personal del área de Control de Energía, entre otras funciones de la Corporación Nacional de Electricidad del Ecuador Agencia Santo Domingo (CNEL EP SD) como empresa pública, por mandato constitucional se rige al Servicio Nacional de Contratación Pública (SERCOP) para toda contratación pública ya sea de bienes o servicios.

2.1. Antecedentes La Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad (CNEL EP) está conformada por 10 Unidades de Negocio: Esmeraldas, Manabí, Santa Elena, Milagro, Guayas-Los Ríos, Los Ríos, EL Oro, Bolívar, Santo Domingo y Sucumbíos.

CNEL EP ofrece el servicio de distribución eléctrica a un total de 1,25 millones de abonados, abarcando el 30% del mercado de clientes del país. La unidad de Negocio objeto de estudio es la de Santo Domingo (CNEL EP SD), la matriz se encuentra ubicada la Av. Tsáchila 826 y Clemencia de Mora 825, CNEL EP SD fue creada el 21 de noviembre de 1988 en su origen su nombre fue Empresa Eléctrica Santo Domingo S.A. (EMELSAD), la empresa nace de la Cooperativa de Electrificación Rural que se formó el 22 de noviembre de 1963. El 13 de marzo de 2013 CNEL Corporación Nacional de Electricidad se constituyó oficialmente en empresa pública estratégica, por medio de Decreto Ejecutivo No 1459, bajo la denominación de Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad (CNEL EP).

El Servicio Nacional de Contratación Pública (SERCOP) es el órgano rector que lidera la gestión transparente y efectiva de la contratación pública, optimiza los recursos del

20

21

Estado y dinamiza el desarrollo productivo del país; La contratación pública se entiende por las adquisiciones de bienes, obras o servicios que una entidad pública realiza, por ejemplo: compras de vehículos, suministros de oficinas, construcción de parques, servicios de asesoría jurídica, entre otros, todo ello se adquiere por medio del SERCOP. Creado el 4 de Agosto del 2008 bajo el nombre de Instituto Nacional de Contratación Pública (INCOP) en el gobierno del presidente constitucional Eco. Rafael Correa, publicada en el

R O 395

de la Ley Orgánica del Sistema Nacional de

Contratación Pública (LOSNCP) en la cual se exige a todas las entidades públicas regirse al entonces INCOP. El 4 de octubre de 2013 se publicó la reforma a la LOSNCP, la misma que fue aprobada el 6 de septiembre de 2013 en la que se cambia la denominación de Instituto Nacional de Contratación Pública (INCOP) a Servicio Nacional de Contratación Pública (SERCOP).

Desde que la CNEL EP SD adoptó el SERCOP para sus contrataciones públicas por mandato constitucional en el año 2008, se ha visto en

inconvenientes porque el

SERCOP es muy estricto al supervisar la ejecución de tareas en las fechas y horas establecidas.

2.2. Problema de investigación El problema de investigación surge debido a la dificultad de recordar los códigos, fechas y horas para la ejecución de las tareas de los procesos por parte del personal encargado, para solucionar este problema, se ha llevado a cabo un seguimiento manual a los procesos del SERCOP, que consiste en realizar recordatorios de las fechas, mediante un informe generado en hojas de Excel compartidas en una red local, las cuales listan los

22

procesos y atributos como su código, nombre y responsable de cada proceso, este método no ha resultado eficiente, porque estos informes son estáticos y requieren una constante actualización de información, lo que conlleva el empleo de mucho tiempo.

Como estos documentos están compartidos en red, no permiten el acceso concurrente por parte de múltiples usuarios, es decir, no pueden ser editados por dos o más personas a la vez. Intentar acceder a la información mientras el documento está siendo utilizado por otra persona en red originará que accidentalmente se creen nuevas versiones del mismo documento, generando redundancia innecesaria de información y provocando confusión. Resulta un problema saber cuáles procesos están activos y cuáles han sido completados. Algunos miembros del personal encargado de los procesos de compras públicas, para evitar los inconvenientes generados por problemas mencionados anteriormente, prefieren anotar las fechas en papeles recordatorios.

2.3. Justificación de la investigación Debido a la necesidad de los encargados de los procesos de compras públicas de CNEL EP SD en velar por el correcto cumplimiento de las tareas de los procesos en las fechas establecidas, los ha llevado a confiar en herramientas como compartir en una red local informes estáticos en hojas de Excel, pero lamentablemente este método ha resultado caótico y ha generado muchos casos de confusión, esto se debe a que aquel método es obsoleto y rudimentario, hoy en día existen herramientas altamente eficientes que darían solución al problema sin generar inconvenientes, CNEL EP SD consciente de esto, ha motivado la modernización del seguimiento de los procesos del SERCOP, mediante la realización de un sistema de software que almacene los procesos y sus atributos y

23

permita la concurrencia a esta información por parte de múltiples usuarios en la red, permitiéndoles acceder a los datos e incluso actualizarlos cuando estén siendo utilizados por terceros, todo eso mientras brinda seguridad a cada uno de los procesos mediante auditorías internas autogeneradas, Además es necesario que el sistema recuerde las tareas de los procesos a realizar, tanto internamente en su interfaz como externamente mediante el envío automático de correos electrónicos a las cuentas personales interinstitucionales. Estos y otros requerimientos que se solicitaron para el desarrollo de la disertación fueron listados en el documento de especificación de requisitos de software (SRS) (Ver Anexo 1).

El desarrollo del sistema fue factible a nivel interinstitucional ya que la empresa CNEL EP Santo Domingo posee un convenio marco de cooperación interinstitucional con al Pontifica Universidad católica del Ecuador sede Santo Domingo firmado en la ciudad de Santo domingo el 9 de febrero del 2011 (Ver Anexo 2).

El desarrollo del sistema es tecnológicamente factible ya que la empresa cuenta con las herramientas necesarias para el desarrollo de software en cuanto a licencias y equipamiento, para el Sistema Gestor de Base de Datos SGBD se trabajó con Software Libre debido al Decreto Presidencial No. 1014 emitido por el presidente Constitucional Eco. Rafael Correa el 10 de Abril del 2008, quién estableció el uso del Software Libre en la Administración Pública Central.

El desarrollo de la disertación para solucionar la problemática planteada, es una alternativa viable, debido a que se cuenta con la aprobación por parte de las autoridades del área de Control de Energía (Ver Anexo 3), además se contó con el conocimiento

24

requerido y con el tiempo necesario para su desarrollo. El proyecto también fue viable en cuanto a la infraestructura de la institución, y dependencias de otros sistemas, ya que el área donde se realizó la implantación del sistema facilitó que el sistema se desarrolle en red local.

2.4 Objetivos de la investigación 2.4.1 Objetivo General Diseñar el sistema de seguimiento de procesos del Servicio Nacional de Contratación Pública (SERCOP), para la automatización del control de procesos de proyectos en el departamento de Control de Energía de la Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad Santo Domingo.

2.4.2 Objetivos Específicos  Analizar los requerimientos funcionales del proyecto  Diseñar el modelo lógico del sistema.  Codificar el núcleo y los módulos del sistema.  Realizar pruebas de funcionalidad al sistema.  Instalar el Sistema, entregar manual técnico y manual de usuario.

III.

MARCO REFERENCIAL

3.1 Revisión de la literatura o fundamentos teóricos 3.1.1 Ingeniería de Software La IEE93a define a la ingeniería de software como “el establecimiento y uso de principios fundamentales de la ingeniería con el objeto de desarrollar en forma económica, software que sea confiable y que trabaje con eficiencia en máquinas reales” (Sommerville, 2009).

A inicios de 1960, se introducen al mercado nuevos computadores lo cuales utilizaban circuitos integrados, esta tecnología prometía que las aplicaciones que no eran posibles realizarlas hasta esa fecha ahora sean factibles, con esta tecnología, se preveía que las aplicaciones resultantes fueran más complejas y de mayor magnitud. En sus inicios el software era elaborado en base a la experiencia previa del programador, pero esto ya no fue idóneo con las nuevas exigencias del auge de la tecnología de ese entonces, lo cual hizo que el desempeño del enfoque informal que hasta ese entonces había sido eficiente, ahora ya no sea suficiente, los proyectos tenían demasiado retraso, algunos costaban mucho más de lo presupuestado e incluso otros eran irrealizables o difíciles de mantener, esto provocó la "crisis del software", por el simple hecho que no cumplía las expectativas de los clientes y no resultaba rentable para los desarrolladores de software, todo esto motivó que en 1968 se desarrolle una conferencia en la que se desarrolló la idea de la Ingeniería del software que se sustentaría en la aplicación de las técnicas de la ingeniería en el desarrollo de software, reduciendo así el esfuerzo necesario y produciendo sistemas grandes y complejos en menor tiempo. Desde 1968 el desarrollo

25

26

de la ingeniería de software ha crecido y progresado enormemente y este progreso ha mejorado considerablemente el software que usamos hoy en día, gracias a ello también se han desarrollado métodos muy efectivos de especificación, diseño e implementación de software.

Sommerville (2009: 20) expresa que la ingeniería de software es la especialización de la ingeniería que se enfoca en la elaboración rentable de sistemas de software. Ratifica que las técnicas desarrolladas han llegado a ser parte de la ingeniería de software y actualmente son ampliamente utilizadas, expresa que entre más crezca la capacidad de producir software, de igual forma aumentará la complejidad de los nuevos sistemas solicitados, creando así nuevas demandas a los ingenieros de software.

Pressman (2010: 12) clasifica a la ingeniería de software como un conjunto de capas.

Como se aprecia en la Ilustración 3.1. En la cual ratifica que como cualquier enfoque de ingeniería incluyendo la del software debe sustentarse en el compromiso organizacional con la calidad, alimentando la cultura de la mejora continua.

Ilustración 3. 1: Capas de la Ingeniería de Software Fuente: (Pressman, 2010, pág. 12)

27

La capa de proceso: Es el fundamento para la ingeniería de software, une las capas de la tecnología y permite el desarrollo oportuno y racional del software, por lo cual se lo considera como la base para el control de la administración de los proyectos, a su vez se asegura la calidad y se administra el cambio de manera apropiada, estableciendo el contexto en el que los métodos técnicos se aplicarán.

Los capa de métodos: Proporcionan experiencia técnica a la ingeniería de software, en las que se incluyen un conjunto de tareas como comunicación, análisis de requerimientos, modelación, elaboración, pruebas y apoyo del software, los cuales se basan en principios fundamentales que incluyen actividades de modelación y otras técnicas descriptivas.

La capa de herramientas: Proporcionan un apoyo semiautomatizado para el proceso y los métodos. Cuando se integran todas las herramientas de tal forma que la información elaborada por una pueda ser reutilizada por otra, queda establecido un sistema denominado ingeniería de software asistido por un ordenador que apoya la elaboración del software.

3.1.1.1 Ciclo de vida del software Nace a raíz del modelo en cascada, en el que se sugería un enfoque sistemático y secuencial a la elaboración de software, surgió en 1970 convirtiéndose en el primer modelo para desarrollar software, de este modelo se derivaron los procesos esenciales de ingeniería de software.

Pressman (2010: 34) especifica que “el desarrollo de software está constituido por cinco etapas, empezando con la especificación de los requerimientos por parte del cliente y

28

continúa a través de la planeación, modelado, construcción y despliegue en la cual concluye con el apoyo o mantenimiento del software terminado”.

Ilustración 3. 2: Ciclo de Vida del Software - Modelo Cascada Fuente: (Pressman, 2010, pág. 34)

Es muy posible que antes de iniciar el desarrollo de software se realice un estudio de factibilidad en la que permitirá asegurar si el desarrollo del software es realizable o no.

A continuación se definirá cada una de las etapas del desarrollo del software que se muestran en la Ilustración 3.2.

3.1.1.1.1 Comunicación Es la etapa inicial del desarrollo, también llamada fase de definición o especificación de requisitos, en ella se obtiene una clara comprensión de los problemas a resolver (Serrano, 2008), para ello debe existir una comunicación entre el equipo de desarrollo y el cliente en la cual se extraerán las necesidades y de ella se derivarán aquellas funciones que debe realizar el sistema, en esta etapa se desarrolla el documento de Especificación de Requerimientos de Software (SRS).

3.1.1.1.2 Planeación Esta etapa tiene como objetivo estimar los costos y recursos que se necesitarán para desarrollar el software, para la estimación se usan técnicas basadas en el juicio experto, uno de los estándares es COCOMO, Sommerville expresa “COCOMO es un modelo

29

empírico que se obtuvo recopilando datos de varios proyectos grandes” (Sommerville, 2009). Este modelo utiliza formulas basadas en el esfuerzo utilizado para el desarrollo del software. Al final de esta etapa se obtendrá el plan de desarrollo con la estimación de costes y recursos.

3.1.1.1.3 Modelado Consta del análisis funcional y diseño del software, en esta fase se determinará una solución arquitectónica y detallada a los requerimientos del sistema definidos en la fase de especificación de requisitos (Serrano, 2008), el análisis funcional, describe el problema a solucionar y descompone los requisitos del sistema, a los subsistemas, se identifican los requisitos específicos y los distintos componentes del sistema (módulos), luego en el diseño, existen 2 fases: diseño arquitectónico y diseño detallado , en la primera fase se define la estructura de la solución, se modelan los módulos y sus relaciones, se identifican los arquetipos, que son abstracciones similares a la de una clase en las que se representa un elemento de comportamiento del sistema (Pressman, 2010), al final se obtiene la estructura del sistema tomada de la definición y refinación de los componentes del software que implementan cada arquetipo, en la segunda, se define los algoritmos que se emplearán y la organización del código que se usará para empezar la implementación.

3.1.1.1.4 Construcción También llamada implementación, en ella se producirá una solución eficiente en un lenguaje de programación que implemente las decisiones que adoptaron en la fase de modelado, consta de la generación de código (ya sea manual o automatizada) y pruebas

30

del sistema, al final se obtendrá un paquete ejecutable (software) sobre una plataforma (hardware y S.O) requerida por el usuario. (Serrano, 2008), cabe mencionar que las fases anteriores son conceptualmente independientes a un lenguaje de programación, es en esta fase cuando se selecciona y se utiliza un lenguaje de programación específico para codificar e integrar los diversos módulos en un proceso llamado integración, una vez obtenido la codificación del sistema es necesario realizar las pruebas respectivas y es aquí donde se comprueba que el sistema satisface los requerimientos definidos inicialmente.

3.1.1.1.5 Despliegue En esta fase se genera el manual de usuario junto con la el manual de instalación, previa a la entrega del sistema (Serrano, 2008), pero una vez entregado el sistema al cliente se debe tener en cuenta que no termina allí, el software necesitará mantenimiento y asistencia técnica durante su vida útil para ello se aconseja realizar una retroalimentación del mismo, que consistirá en redefinir nuevamente los requerimientos que se pretenda mejorar y realizar la adaptación de módulos para que el software se cumpla nuevamente a las expectativas del cliente.

No obstante, seguir secuencialmente las etapas de desarrollo de software clásico puede crear inconvenientes, debido a que el modelo exige que se determinen todos los requerimientos de forma explícita en la etapa inicial, lo que resulta difícil para el cliente, se debe tener paciencia. En este modelo no se dispondrá de una versión funcional del software a primeras instancias, sino hasta que esté completado el sistema, por lo cual un error a finales del ciclo de desarrollo podría ser desastroso. Debido a la falta de

31

flexibilidad del modelo cascada, se planteó una variante en cual se puede apreciar en la Ilustración 3.3.

Ilustración 3. 3: Ciclo de vida - Modelo en V Fuente: (Pressman, 2010, pág. 35)

En esta variación del modelo cascada se soluciona los problemas comúnmente conocidos por la falta de flexibilidad, en la cual a simple vista se observa que los aspectos de prueba están claramente ligados a cada una de las fases, es decir se asocia una fase de prueba a cada fase del ciclo de vida, estableciendo formas de gestión para validación de cada una de ellas. Globalmente, en el modelo en “V” las pruebas no se consideran parte de la implementación sino que se las separa y se las asocia mediante la relación de cada una de las fases de desarrollo (Serrano, 2008).

32

Con el paso del tiempo, no basto solo la flexibilidad para el desarrollo del software, los sistemas necesitaban agilidad, demoraban en desarrollarse y costaban mucho, debido al incremento de complejidad, el software resultante no complacía completamente a los clientes, se pensó entonces combinar el proceso lineal y paralelo para dar solución a los problemas, en Ilustración 3.4 se puede observar el proceso lineal de la metodología clásica con la variación que ahora se realiza en forma cíclica, secuencial y paralela, cada ciclo se llama secuencia y produce “incrementos” de software que son productos funcionales y operacionales entregables.

Ilustración 3. 4: Ciclo de Vida Incremental Fuente: (Pressman, 2010, pág. 36)

Los primeros incrementos van a contener requerimientos con más prioridad, los cuales se convertirán en los productos fundamentales, y serán en muchos casos versiones desnudas del producto final. (Pressman, 2010), lo que permitirá al cliente formar parte del equipo de desarrollo en las pruebas del software, las primeras iteraciones se desarrollarán con pocos trabajadores y en caso de ser bien recibido el personal se podrá

33

incrementar si es necesario, para desarrollar el siguiente incremento, todo esto permitió reducir precios y aumentar la satisfacción del cliente hacia el software.

3.1.1.2 Metodologías de Desarrollo de Software Una metodología de desarrollo de sistemas de software es una representación abstracta del desarrollo del software (Sommerville, 2009), una metodología o modelo de desarrollo de software está compuesta de principios y prácticas para el desarrollo del software y cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable, aparecen a principios de los años 70 con la aparición de la programación estructurada, fueron propuestos originalmente para poner orden en el caos del desarrollo del software, en la que se plantea el modelo en cascada, que es la primera metodología para sistemas estructurados.

Entre los principios que ofrece una metodología de desarrollo están:  Reducen el tiempo de elaboración del software.  Reducen el costo del software.  Organiza el desarrollo de software mediante fases o incrementos.  Incrementar la productividad y satisfacción del cliente.  Estandarizar los procesos y técnicas de elaboración.  Aumentar la calidad del software.

Las metodologías se pueden dividir en dos grandes grupos: Las metodologías clásicas y las metodologías ágiles.

34

3.1.1.2.1 Metodologías Clásicas Estas metodologías poseen un análisis estructurado, rígido y exigente, basado en normas de estándares seguidos por el equipo de desarrollo, donde la documentación y la planificación de actividades es la base para la elaboración de software de calidad.

Algunos autores las denominan metodologías pesadas, debido a que todo el proceso de desarrollo es documentado para estandarizar el desarrollo, cada una de ellas se descompone en procesos que se dividen en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. (Sommerville, 2009). La primera metodología clásica fue el modelo en cascada, apareció en la década de los 70 y marcó el proceso básico de la vida del software.

Aplicar metodologías tradicionales a un proyecto de software requiere mucha inversión, experiencia y esfuerzo, por lo cual no es idóneo aplicarlo a proyectos pequeños o medianos. Entre las metodologías clásicas que más han trascendido están el modelo basado en prototipos, modelo en espiral y el Proceso Unificado de Rational (RUP) que actualmente

junto al Lenguaje Unificado de Modelado (UML) constituyen la

metodología estándar más utilizada para la elaboración y documentación de software, debido a que combinan los procesos de diferentes metodologías clásicas.

3.1.1.2.1.1 Modelo Basado en Prototipos El modelo basado en prototipos se creó para resolver los problemas ocasionados por la falta de requerimientos detallados o al no tener una idea clara de lo que se desea hacer y lo que se quiere resolver (Pressman, 2010).

35

El paradigma de hacer prototipos (véase ilustración 3.5) empieza con la comunicación en la que se especifica los requerimientos mediante una reunión con el cliente y posteriormente analizándolos con el equipo de trabajo, identificando los requerimientos de prioridad, luego se planea rápidamente una iteración para hacer el prototipo, seguido de un diseño rápido en la que se enfoca en los aspectos visibles de software como la interfaz gráfica que da como origen un prototipo el cual es entregado y procede a ser evaluado por los participantes que darán retroalimentación para mejorar los requerimientos, a medida que avanzan las iteraciones el prototipo es refinado, hasta que satisfaga completamente las necesidades del cliente. El inconveniente de este paradigma al igual que las metodologías pesadas es la complejidad en la excesiva documentación, en la Ilustración 3.5 se puede apreciar el ciclo de vida de este paradigma.

Ilustración 3. 5: Modelo de Prototipos Fuente: (Pressman, 2010, pág. 37)

36

3.1.1.2.1.2 Modelo en Espiral Propuesto por Barry Boehn el cual expresa que “El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en software.

Tiene dos características principales. La primera es el enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias”. (Pressman, 2010).

Ilustración 3. 6: Modelo en Espiral Fuente: (Pressman, 2010, pág. 39)

El modelo espiral es un enfoque realista y se adapta a la evolución del software ya que a medida que aumentan las iteraciones el desarrollador y el cliente tienen una mejor comprensión y reacción a los riesgos en cada nivel de evolución, ya que usa prototipos para reducir riesgos, pero lo más destacado es que permite usar el enfoque de realizar

37

atributos en cualquier etapa de evolución y desarrollo del proyecto. Este modelo se ha usado por mucho tiempo para la elaboración de proyectos grandes de desarrollo de software como sistemas operativos o sistemas de n módulos. Los primeros ciclos de este modelo se pensaron para garantizar una acertada comprensión del sistema y de sus requerimientos, postergando cualquier implementación del software, hasta que todos los factores de riego se hayan eliminado.

El inconveniente de este modelo es que demanda demasiada experiencia en la evaluación del riesgo y ya que se basa en ella para lograr el éxito, el no resolverlos de forma correcta y a tiempo, hará que el proyecto sin duda fracase.

3.1.1.2.1.3 Proceso Unificado de Rational Pressman (2010: 91) define al Proceso Unificado de Rational (RUP) como “un ejemplo de modelo de proceso moderno que proviene del trabajo en el UML y el asociado Proceso Unificado de Desarrollo de software”. Aparece a inicios del 2000 desarrollado por la empresa Rational, actualmente pertenece a IBM. Sus creadores Ivar Jacobobson, Grady Booch y James Rumbaugh en su libro fundamental, Unified Porcess, expresan que RUP nació de la iniciativa de crear un “método unificado”, iterativo e incremental que dé la sensación evolutiva que resulta esencial en el desarrollo moderno del software y que haga énfasis en la importancia de su arquitectura. El proceso unificado es un intento de aprovechar y mejorar los rasgos y características de las metodologías clásicas del proceso del software, pero implementando a su vez muchos de los principios de las metodologías ágiles como por ejemplo la importancia de la comunicación con el cliente, además usa los casos de uso

38

como métodos para describir el punto de vista respecto de un sistema. El proceso unificado ayuda a que el arquitecto se centre en las metas correctas, tales como que sea comprensible, permita cambios futuros y la reutilización. En la Ilustración 3.7 se puede apreciar las fases del Proceso Unificado de Rational (RUP).

Ilustración 3. 7: Proceso Unificado de Rational Fuente: (Pressman, 2010, pág. 47)

3.1.1.2.2 Metodologías Ágiles Aparecen a mediados de los años 80 y a principios de los 90 a partir del descontento con los enfoques de desarrollo pesados (clásicos) en la que estos enfoques estaban más centrados en el diseño de la arquitectura y documentación que en el software, fueron pensadas para el entorno global actual que tiende a cambiar rápidamente y donde a menudo es prácticamente imposible obtener un completo conjunto de requerimientos, debido a que estos cambian inevitablemente, a los clientes les resulta imposible saber a ciencia cierta qué operaciones deben automatizar y es muy probable que los requerimientos reales solo queden claros cuando se haya entregado el sistema y los usuarios hayan adquirido experiencia (Sommerville, 2009). Teniendo en cuenta el

39

cambiante entorno, los sistemas de negocio buscan el desarrollo y entrega rápida de software como prioridad, para aprovechar nuevas oportunidades y responder a la presión de la competencia.

Joskowicz (2009: 4) expresa que “Las metodologías ágiles son adaptables en lugar de predictivos y son orientados a la gente y no orientados al proceso”. La base de los métodos ágiles es enfatizar las comunicaciones cara a cara en vez de la documentación.

El desarrollo ágil de software está basado en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos autoorganizados y multidisciplinarios, pensados para entregar software funcional de forma rápida a los clientes. Los lapsos cortos de tiempo en que el software es desarrollado se llaman “iteraciones”, la cuales deben durar de una a cuatro semanas para minimizar riesgos. Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación. Una iteración no debe agregar mucha funcionalidad a inicio del desarrollo, sino que la meta es tener un producto de prueba sin errores al final de cada iteración, una vez finalizada esta, el equipo vuelve a evaluar las prioridades del proyecto.

El uso de las metodologías ágiles se ha incrementado considerablemente según lo indica el quinto informe del World Quality Report presentado por las empresas Sogeti, Capgemini y HP, en la que expresa “Los datos de este año muestran que el número de organizaciones que trabajan con metodologías ágiles se ha incrementado un 83%. Estas tasas de adopción crecientes no son sorpresa, ya que muchos proyectos cascada tradicionales han fallado en entregar resultados y mantenerse dentro de objetivos de tiempo y presupuesto razonables. A medida que la proporción de los nuevos proyectos

40

aumenten en los próximos años, se espera que las organizaciones continúen el empleo de metodologías y prácticas ágiles”. (Capgemini, Sogeti, HP, 2013- 2014).

A continuación, en la tabla 3.1 se muestra una lista de las empresas que usan metodologías ágiles para el desarrollo de sus aplicaciones.

Tabla 3. 1: Empresas Multinacionales que usan metodologías ágiles.

Sectores

Ejemplos de empresas que utilizan metodologías ágiles

Teléfonos móviles

Motorola, Nokia, Palm, Sony/Ericsson

Hardware y Software

Adobe, IBM, Intel, Microsoft, Novell, OpenView Labs, Softhouse, Valtech.

Internet

Amazon, Google, Yahoo

ERP

SAP

Juegos

Blizzard, High Moon Studios, Crytek, Ubisoft, Electronc Arts.

Fuente: (www.proyectosagiles.org)

3.1.1.2.2.1 Manifiesto Ágil En el 2001, Kent Beck y otros 16 notables desarrolladores de software, escritores y consultores se reunieron para formalizar los principios para el desarrollo ágil de software, donde firmaron el “Manifiesto por el desarrollo ágil del software” (http://agilemanifesto.org/principles.html). En el que se ha llevado a valorar: Individuos e interacciones más que procesos y herramientas.

Software que funciona más que documentación exhaustiva.

Colaboración con el cliente más que negociación de contratos.

41

Responder ante el cambio más que seguimiento de un plan.

El Manifiesto Ágil contempla los siguientes doce principios: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

42

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Existen muchos métodos de desarrollo ágil, En la presente disertación se profundizará en la metodología de desarrollo ágil Programación Extrema (XP).

3.1.1.2.2.2 Programación Extrema (XP) Es el enfoque ágil más utilizado en el desarrollo del software, aparece a principios del año 2000 acuñado a Beck, surge como una nueva filosofía de desarrollar software en la que se propone esencialmente simplicidad y agilidad y como una alternativa para eliminar la burocracia de las metodologías pesadas (Joskowicz, 2009), consta de principios y prácticas como desarrollo iterativo y participación del cliente, y las lleva a niveles extremos, el primordial objetivo de XP es reducir el riesgo en ciclo de desarrollo del software, por ello XP se enfoca en las pruebas del sistema más que cualquier otra metodología, mediante pruebas incrementales y continuas se busca reducir a temprana etapa la posibilidad de errores en el software y eludir inconvenientes en las pruebas y validaciones del sistema, aumentando así la productividad.

“XP está diseñada para entregar el software que necesitan, en el tiempo que lo necesitan, para ello alienta a los desarrolladores a responder a los requerimientos cambiantes de los clientes, aun en fases tardías de desarrollo” (Joskowicz, 2009). XP promueve el trabajo

43

conjunto, los clientes forman parte del equipo de desarrollo y se los considera primordiales e indispensables en la especificación y establecimiento de prioridades de los requerimientos del sistema. En XP los requerimientos son expresados como escenarios y se llaman historias de usuario, las cuales se desarrollan como tareas, en esta metodología los programadores trabajan en parejas, los cuales ejecutan pruebas para cada tarea previa a la implementación de código nuevo.

3.1.1.2.2.2.1 Variables de Control XP La metodología XP define cuatro variables de control para cualquier proyecto de software.

Costo: Dinero suficiente para resolver el problema.

Tiempo: Más tiempo permite que la calidad o el alcance se incrementen.

Calidad: Sacrificar calidad, puede costar la productividad.

Alcance: Si el alcance es reducido, se obtiene más calidad y en menos tiempo.

Joskwicz (2009: 7) ratifica “de estas cuatro variables, solo tres de ellas podrán ser fijadas arbitrariamente por los clientes y jefes de proyecto y el valor de la variable restante se establecerá por el equipo de desarrollo en función de las otras tres”. Por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo tendrá libertad de determinar el tiempo de duración del proyecto (Joskowicz, 2009).

3.1.1.2.2.2.2 Valores en XP Un valor es una descripción de la manera en que debe enfocarse el desarrollo de software, estos valores deben estar inculcados en el equipo de desarrollo para que el

44

proyecto tenga éxito, XP se compone de 4 valores fundamentales: Comunicación: Muchos de los problemas que existen en proyectos de software se deben a problemas de comunicación durante el desarrollo del proyecto (Joskowicz, 2009). XP alienta a que exista una comunicación extrema durante todo el proyecto, dado que la documentación es escasa. El medio básico de comunicación es el dialogo frontal, cara a cara, entre desarrolladores, gerentes y el cliente.

Simplicidad: Como una metodología ágil, XP apuesta a la sencillez, en su máxima expresión (Joskowicz, 2009). La sencillez es esencial por ello se la aplica en el diseño, en los procesos, e incluso en el código, el cual debe ser refactorizado tan a menudo como sea posible, para manera mejorar su estructura sin cambiar su funcionalidad, logrando así mejor comprensión del código.

Retroalimentación: Algunos autores lo llaman Feedback. Cortizo, Gil, & Ruiz expresan “XP se esfuerza en realizar Feedback tan rápido como sea posible en todos los aspectos del proyecto” (Cortizo, Gil, & Ruiz, 2008). El equipo de trabajo en las retroalimentaciones que se efectúen aumentaran la calidad del código revisado, los resultados de las pruebas unitarias son también una retroalimentación permanente que tienen los desarrolladores sobre la calidad de su trabajo.

Coraje: Cuando se encuentran problemas serios en el diseño, o en cualquier otro aspecto, se debe tener el coraje suficiente como para encarar su solución, sin importar su dificultad (Joskowicz, 2009). No hay

que escatimar esfuerzos, si es necesario

reestructurar completamente parte del código, se lo hace, sin importar el tiempo

45

previamente invertido en el mismo.

3.1.1.2.2.2.3 Roles en XP En XP se utiliza el concepto de roles para delegar el desarrollo de cada una de las actividades que se realizarán durante el transcurso del desarrollo del software. A diferencia de metodologías clásicas XP posee pocos roles donde cada papel es desempeñado por uno o varios integrantes del equipo de desarrollo, sin descartar la posibilidad de rotar los roles entre el equipo durante el transcurso del desarrollo. Los roles serán especificados a continuación en la Tabla 3.2: Tabla 3. 2: Roles en XP

Rol

Desempeño

Manager del Proyecto

Tiene la responsabilidad la dirección y organización de las reuniones que se realizarán durante el proyecto.

Cliente

Determinará qué se construirá en el sistema, decide el orden en que se entregarán cada segmento del proyecto, además establece pruebas de aceptación, las que determinarán si el sistema es apto.

Programadores

En ese grupo se encuentran también los diseñadores y analistas. Los programadores construyen el sistema y realizan pruebas correspondientes a cada incremento

Entrenador (Coach)

Es el responsable de dar ayuda continua a los integrantes del grupo y velar que el proceso sea realizado en forma correcta.

Se asegura de que los conceptos de la metodología se apliquen en el proyecto.

Tester

Colabora en la realización de las pruebas de aceptación y es quien se encarga de mostrar los resultados.

Rastreador (Tracker)

Su tarea es observar la realización del sistema. Mantiene datos históricos del proyecto.

Fuente: (Cortizo, Gil, & Ruiz, 2008, pág. 220).

46

3.1.1.2.2.2.4 Proceso de desarrollo de software XP La programación extrema usa un enfoque orientado a objetos como paradigma preferido de desarrollo y engloba un compendio de reglas y prácticas que ocurren dentro del contexto de cuatro fases estructurales: planeación, diseño, codificación y pruebas (Pressman, 2010). En la Ilustración 3.8 se plasma gráficamente el proceso de desarrollo de software XP y resalta alguna de las tareas y tareas claves:

Ilustración 3. 8: Proceso de la metodología Programación Extrema (XP) Fuente: (Pressman, 2010, pág. 62)

Planeación: La metodología XP plantea la planificación como un dialogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores o gerentes. La planeación comienza escuchando para recabar requerimientos que permitirán al equipo de desarrollo entender el contexto del negocio para el software y adquirir la sensibilidad de la salida y características principales y funcionalidad que se requieren (Pressman, 2010).

Escuchar lleva a la creación de

47

“Historias de usuarios” que sustituyen a los tradicionales “casos de uso”. Las historias de usuario describen la salida necesaria, funcionalidad del software y características del software que se va a elaborar, a ellas el cliente les asigna una prioridad, el equipo de desarrollo evalúa cada historia y le asigna un costo, medido en semanas de desarrollo, el cual no puede ser mayor a tres semanas ni menor a una semana, es importante aclarar que en cualquier momento es posible escribir nuevas historias, modificarlas

o

eliminarlas, el equipo de trabajo acordará el orden en que se implementará las historias de usuario y de igual forma las entregas, mediante reuniones, que darán como resultado un “Plan de entregas”.

Diseño: La metodología XP hace especial énfasis en los diseños simples y claros, Un diseño simple se implementa más rápidamente que uno complejo, por ello se prefiere siempre un diseño sencillo y simple por encima de una representación compleja. El diseño guía la implementación de una historia conforme se escribe, se descalifica la funcionalidad adicional, dado que el desarrollador asume que se requerirá después en una nueva iteración (Pressman, 2010). En XP se estimula el uso de tarjetas CRC (claseresponsabilidad- colaborador) como un eficaz mecanismo para enfocarse en el software en un contexto orientado a objetos, estas tarjetas serán el único producto del trabajo de diseño que se generará como parte del proceso XP. Si el diseño de de una historia es difícil, se recomienda una “solución en punta” que consiste en la creación inmediata y evaluación de un prototipo operativo de esa parte del diseño. XP también estimula el “rediseño” como técnica de construcción y optimización del diseño.

48

Ilustración 3. 9: Fase de Diseño XP Fuente: (Cortizo, Gil, & Ruiz, 2008, pág. 35)

Codificación: Luego del desarrollo de las historias durante del trabajo de diseño preliminar, aún no se puede proceder a la codificación sin antes haber desarrollado una serie de pruebas unitarias a cada una de las historias que se incluirán en el próximo incremento (Pressman, 2010). Una vez culminada la prueba unitaria el desarrollador está mejor capacitado para centrarse en lo que debe implementarse, durante todo el desarrollo se aplica el principio de “programación en parejas” como un mecanismo de solución de problemas y aseguramiento de calidad en tiempo real, en la pareja cada persona adopta un papel diferente, por ejemplo, una de ellas puede codificar los detalles una porción particular de diseño y la otra revisar el código para optimizarlo y verificar que se apliquen los estándares (Parte necesaria de XP), a medida que las parejas de programadores implementan, revisan y prueban las porciones del diseño, se aplica el principio de “integración continua” que consiste en ir integrando el código revisado con el trabajo del resto del equipo de desarrollo. XP busca siempre aprovechar al máximo la productividad de los programadores, para ello sugiere no trabajar excesivas horas extras ya que esto reduce la productividad media del equipo, además XP propone brindar al programador un entorno agradable para trabajar (revisar Ilustración 3.10).

49

Ilustración 3. 10: Entorno de Trabajo XP Fuente: (Cortizo, Gil, & Ruiz, 2008, pág. 45)

Pruebas: En XP las pruebas son fundamentales, por tanto XP pone más énfasis en el proceso de pruebas que cualquier otro método ágil, en ella se ha desarrollado un enfoque que reduce la probabilidad de producir que se introduzcan error en los nuevos incrementos del sistema (Sommerville, 2009). Entre las pruebas que se realizan en XP están las pruebas unitarias individuales que se realizan previa y posteriormente a la codificación de cada historia, a medida que las pruebas unitarias individuales se realizan y se va integrando el código se procede a realizar diariamente pruebas de integración y validación, esto da al equipo XP una indicación continua de avance o una señal de alerta si las cosas no marchan como se esperaba, Don Wells uno de los precursores de XP menciona “Corregir pequeños problemas cada cierto número de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final” (Pressman, 2010).

Una vez terminado el incremento se procede a realizar “las pruebas de aceptación XP” que se derivan de las historias de usuario, son especificadas por el cliente y se centran en

50

la funcionalidad y características generales del sistema, que son visibles y revisables por parte del cliente.

3.1.1.2.2.2.5 Principios y Prácticas La metodología XP tiene un conjunto importante de principios y prácticas. A continuación en la Tabla 3.3 se explicarán de forma general.

Tabla 3. 3: Principios y Prácticas en XP

Principio y/o Práctica

Descripción

Planificación incremental

Los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinarán según el tiempo disponible y su prioridad relativa. Los desarrolladores dividen estas historias en tareas de desarrollo.

Entregas Pequeñas

El mínimo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.

Diseño sencillo

Sólo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.

Desarrollo previamente probado

Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que éstas se implementen.

Refactorización

Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentre posibles mejoras en el código. Esto conserva el código sencillo y mantenible.

Programación en parejas

Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y proporcionando la ayuda necesaria para hacer siempre un buen trabajo.

Propiedad colectiva

Las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen islas de conocimientos y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.

51

Integración continua

En cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Después de la integración, se deben pasar al sistema todas las pruebas unitarias.

Ritmo sostenible

No se consideran aceptables grandes cantidades de horas extras, ya que a menudo el efecto que tienen es que se reduce la calidad del código y la productividad a medio plazo.

Cliente presente

Debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (cliente) a tiempo completo. En un proceso de la programación extrema, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementación.

Fuente: (Sommerville, 2009, p. 374)

3.1.1.2.2.2.6 XP Comparado con otras Metodologías Previamente a la elección de la metodología de desarrollo a aplicar durante el proyecto SSP, se comparó XP con la metodología Espiral, por Prototipos metodologías según parámetros técnicos, de la comparativa se identificó a XP como idóneo para ser usado durante el desarrollo del proyecto, requerimientos contractuales del

por lo que se adaptaba a la mayoría de los

proyecto. En la tabla 3.4 se puede observar la

comparativa efectuada.

Tabla 3. 4: Comparativa de Metodologías con XP

Parámetros

Extreme Programming (XP)

Metodología Espiral

Metodología por Prototipos

Proceso Unificado de Rational (RUP)

Tipo

Metodología Ágil

Metodología Clásica

Metodología Clásica

Unión de Metodologías Clásicas.

Orientada a Objetos

Orientada a Objetos

Orientada a Objetos

Orientada a Objetos

Paradigma

52

Basada en

Heurísticas provenientes de prácticas

Normas provenientes de estándares

Normas provenientes de estándares

Normas provenientes de estándares

Orientación

Proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Proyectos de cualquier tamaño, pero suelen ser especialmente efectivo en proyectos grandes y con equipos posiblemente dispersos

Proyectos de cualquier tamaño, efectivo en proyectos medianos y grandes, entregas frecuentes.

Proyectos de cualquier tamaño, pero suelen ser especialmente usado en proyectos grandes y con equipos posiblemente dispersos

Contrato Inicial

Bastante flexible.

Prefijado

Prefijado

Prefijado

Roles

Genéricos y flexibles (Pocos).

Específicos (Muchos).

Específicos (Muchos).

Específicos (Muchos).

Modelado

Prescindible

Esencial, mantenimiento de modelos

Esencial, modelos desechables.

Esencial, mantenimiento de modelos.

Participació n del Cliente

Como parte del equipo de desarrollo (insitu)

interactuando con el equipo de desarrollo mediante reuniones

interactuando con el equipo de desarrollo mediante reuniones

interactuando con el equipo de desarrollo mediante reuniones

Arquitectur a

Se va definiendo y mejorando a lo largo del proyecto

Se promueve que se la defina tempranamente en el proyecto

Se la define tempranamente y se la va mejorando a lo largo del proyecto

Se la define tempranamente y se la va mejorando a lo largo del proyecto

Énfasis

En los aspectos humanos: el individuo y el trabajo en equipo

En la definición del proceso: roles, actividades y artefactos

En la definición del proceso: roles, actividades y artefactos

En la definición del proceso: roles, actividades y artefactos

53

Cambios en los requerimien tos

Se esperan durante el proyecto

Se espera que no ocurran o no den gran impacto durante el proyecto

Se espera que no ocurran o no den gran impacto durante el proyecto

Se espera que no ocurran o no den gran impacto durante el proyecto

Definición de comportami entos

Mediante historias de usuario

Mediante casos de uso y diagramas de caso de uso

Mediante casos de uso y diagramas de caso de uso

Mediante casos de uso y diagramas de caso de uso

Posibilidad de cambiar comportami entos

En cualquier momento es posible escribir nuevas historias, modificarlas o eliminarlas

No es posible la eliminación o modificación de un caso de uso en etapas finales del proceso.

Es posible la eliminación o modificación de un caso de uso en etapas finales del proceso.

No es posible la eliminación o modificación de un caso de uso en etapas finales del proceso.

Inversión talento humano

Poca (2 ó más integrantes)

Mucha (10 ó integrantes)

Mucha (10 ó integrantes)

Mucha (10 ó integrantes)

Dependenci a de integrantes del equipo de desarrollo

Los cargos rotan mutuamente, se usan estándares de programación, todos conocen bien el proyecto, solo el cliente es indispensable.

Los cargos son permanentes, en caso de cambio de programadores, el proyecto tomará más tiempo de lo acordado y costará más.

Los cargos son permanentes, en caso de cambio de programadores , el proyecto tomará más tiempo de lo acordado y costará más.

Los cargos son permanentes, en caso de cambio de programadores , el proyecto tomará más tiempo de lo acordado y costará más.

Análisis de requerimien tos y modelado de negocio

Mediante Historias de Usuario, valores de comunicación, retroalimentació n y cliente como parte del equipo de desarrollo.

Mediante análisis de casos de Uso.

Mediante análisis de casos de Uso.

Mediante análisis de casos de Uso.

54

Análisis en el diseño

Diseño simple, El sistema se diseña por bocetos de tarjetas CRC (ClaseResponsabilidad -Colaboración)

Mediante modelado de diagramas de clases, secuencia, colaboración y actividades.

Mediante modelado de diagramas de clases, secuencia, colaboración y actividades.

Mediante modelado de diagramas de clases, secuencia, colaboración y actividades.

Implementa ción

Mediante Mediante entregas arquitectura de frecuentes prototipos. continuas, integración continua, trabajo colectivo, programación en parejas y refactorización de código.

Mediante arquitectura de prototipos.

Mediante arquitectura de prototipos.

Testeo de software

Probar antes de codificar.

Mediante la planeación del diseño e implementación de pruebas.

Mediante la planeación del diseño e implementació n de pruebas.

Mediante la planeación del diseño e implementació n de pruebas.

Configuraci ón y cambios de manejo de gestión

Cambian o se desechan historias de Usuario

Cambia el documento de especificación de software

Cambia el documento de especificación de software

Cambia el documento de especificación de software

Manejo de Gestión de proyectos.

Plan de iteraciones

Definición de un documento de evaluación de estados del plan.

Definición de un documento de evaluación de estados del plan.

Definición de un documento de evaluación de estado del plan.

Modus operandi de trabajo

Trabajo sin excesiva presión, 40 horas semanales, No horas extras.

Trabajo con excesiva presión, es necesario cumplir con la

Trabajo con excesiva presión, es necesario cumplir con la

Trabajo con excesiva presión, es necesario cumplir con la

55

planificación, en muchos casos horas extras son necesarias.

planificación, en muchos casos horas extras son necesarias.

planificación, en muchos casos horas extras son necesarias.

Requiere mucha experiencia, especialmente en el manejo de riesgos.

Por parte de todos los integrantes del equipo de trabajo.

Por parte de todos los integrantes del equipo de trabajo.

Necesidad de experiencia

No es necesario para todos, basta solo una persona conozca de la metodología.

Proceso

Poco controlado, Muy controlado, pocos numerosa principios. normas.

Muy controlado, numerosa normas.

Muy controlado, numerosa normas.

Tiempo de desarrollo

Rápido.

Lento.

Lento.

Lento.

Costo de producción

Bajo.

Alto.

Alto.

Alto.

Documenta ción

Poca

Mucha

Mucha

Mucha

Pruebas

Durante todo el proceso de desarrollo.

Como etapa de desarrollo.

Como etapa de desarrollo.

Como etapa de desarrollo.

Gestión de Riesgos

Optimizada

Detallada.

No posee.

Detallada.

Alternativa para mitigar tasa de errores

Pruebas constantes, disminuyen la tasa de errores.

Guiado por Riegos, para disminuir tasa de errores.

Guiado por Riegos, para disminuir tasa de errores.

Guiado por Riegos, para disminuir tasa de errores.

Uso en las empresas transnacion ales de desarrollo.

Metodologías ágiles son las más usadas actualmente.

Metodologías clásicas están en desuso.

Metodologías clásicas están en desuso.

Metodologías clásicas están en desuso.

Fuente: (Cortizo, Gil, & Ruiz, 2008)

56

3.1.1.3 Paradigmas de Programación El mundo del desarrollo de software está sometido a un proceso de evolución constante, desde el código máquina y ensamblador a través de paradigmas como la programación procedural, la programación estructurada, la programación lógica, entre otras, hasta llegar a la programación orientada a objetos que hoy en día es el paradigma más extendido (Rodrigez, Encarna, & Prieto, 2011).

3.1.1.3.1 Programación Orientada a Objetos (POO) La programación orientada a objetos supone un cambio de concepción para el mundo del desarrollo de software (Rodrigez, Encarna, & Prieto, 2011). POO plantea una situación para desarrollar sistemas muy parecida al mundo real y su principal objetivo es descomponer los sistemas grandes y complejos en sistemas pequeños y fáciles de desarrollar, de esta forma está dedicado para su utilización en sistemas de software complejos a partir de módulos reutilizables. En POO se define a un objeto como un elemento real o abstracto que tiene un estado, un comportamiento y una identidad y a una clase como una representación abstracta de un grupo de objetos, actualmente la Programación orientadas a objetos es el paradigma de programación más usado en todo el mundo.

Los conceptos fundamentales de este paradigma se aprecian en la tabla 3.4: Tabla 3. 5: Conceptos Fundamentales POO.

Concepto

Descripción

Abstracción

Propiedad que selecciona lo más importante y desecha las demás características menos importantes.

57

Encapsulamiento Propiedad que permite ocultar detalles del objeto que no son tan importantes, ni necesarios para su uso.

Modularidad

Propiedad que permite subdividir el sistema en subsistemas.

Jerarquía

Propiedad que permite ordenar las abstracciones, se subdivide en herencia y agregación.

Polimorfismo:

Ofrece a los objetos de clases diferentes la posibilidad de efectuar la misma operación de diferentes formas.

Fuente: (Weitenfeld, 2005)

3.1.1.4 Arquitectura Cliente Servidor La arquitectura Cliente-Servidor es un entorno distribuido en la cual la idea básica es que el servidor brinde información a los clientes siempre y cuando ellos se lo pidan, se divide en 2 actores: 3.1.1.4.1 Servidor Llamados también parte dorsal o back-end. Es un nodo que, formando parte de una arquitectura, provee servicios a otros nodos denominados clientes. (Carlos Coronel, Steven Morris, Peter Rob, 2011).Los servidores de bases de datos surgen de la necesidad de las empresas de manejar grandes y complejos volúmenes de datos, a su vez al tiempo que requieren compartir la información con un conjunto de clientes de una manera segura, todo ello se podrá realizar a través del lenguaje SQL 3.1.1.4.2 Cliente Llamados también partes frontales o interfaces, en sí son las aplicaciones en las cuales el cliente hace el requerimiento al servidor y mediante interfaces gráficas muestra al usuario de forma gráfica la información que solicito al servidor.

58

Ilustración 3. 11: Representación Arquitectura Cliente - Servidor Fuente: (Carlos Coronel, Steven Morris, Peter Rob, 2011, pág. 8).

En la Ilustración 3.11, se detalla un ejemplo sencillo de entorno cliente/servidor, la cual muestra un sistema gestor de bases de datos adaptado en un servidor, los programas que se ejecutan en los ordenadores (clientes) se comunican con el servidor a través de la red de comunicaciones, para ello un usuario realiza una consulta mediante lenguaje SQL al servidor, este que está escuchando recibe la petición, la procesa y reenvía los datos solicitados al cliente, y este a su vez lo mostrará en su interfaz al usuario.

3.1.2 Bases de Datos Una Base de Datos (BD) es una colección de datos relacionados y lógicamente coherentes con algún tipo de significado inherente (Shamkant B. & Ramez, 2007). Una base de datos representa un aspecto del mundo real y se diseña, construye y se la surte de datos siempre con un propósito en específico, una BD también dispone de un grupo

59

de usuarios y algunas aplicaciones preconcebidas en las que esos usuarios están interesados. Entre los muchos beneficios que nos ofrece una BD están, la capacidad de almacenamiento, capacidad de acceso, y la capacidad de manipular la información en computadoras de bajo costo.

3.1.2.1 Sistemas Gestores de Base de Datos Un Sistema Gestor de Base de Datos (SGBD) es una herramienta cliente/servidor, conformado por un sistema de software de propósito general que facilita los procesos de definición, construcción, manipulación, protección, mantenimiento y compartición de bases de datos entre varios usuarios y aplicaciones (Shamkant B. & Ramez, 2007). En la tabla 3.4 se definen cada una de las funciones de un SGBD. Tabla 3. 6: Funciones de un Sistema Gestor de Base de Datos

Funciones

Descripción

Definición

Definir una base de datos implica especificar los tipos de datos, estructuras y restricciones de los datos que se almacenarán en la base de datos.

Construcción

La construcción de la base de datos es el proceso consistente en almacenar los datos en algún medio de almacenamiento controlado por el SGBD.

Manipulación

La manipulación de una base de datos incluye funciones como la consulta de la base de datos para recuperar datos específicos, actualizar la base de datos para reflejar los cambios introducidos y generar informes a partir de los datos.

Compartir

Compartir una base de datos permite que varios usuarios y programas accedan a la base de datos de forma simultánea.

Protección

La protección incluye la protección del sistema contra el funcionamiento defectuoso del hardware o el software (caídas) y la protección de la seguridad contra el acceso no autorizado o malintencionado.

60

Mantenimiento Una gran base de datos típica puede tener un ciclo de vida de muchos años, por lo que el SGBD debe ser capaz de mantener el sistema de bases de datos permitiendo que el sistema evolucione según cambian los requerimientos con el tiempo.

Fuente: (Shamkant B. & Ramez, 2007, pág. 26)

3.1.2.1.1 Oracle Oracle sin duda alguna es el SGBD más avanzado, es vendido a nivel mundial, aunque por norma general la gran potencia que tiene y su elevado precio hace que sólo se vea en empresas muy grandes y multinacionales.

Ilustración 3. 12: Logo de Oracle Fuente: (www.oracle.com)

3.1.2.1.2 PostgreSQL PostgreSQL se autodenomina el SGBD de código abierto más avanzado del mundo, ya que posee herramientas que incrementan el rendimiento, escalabilidad, disponibilidad y gestión de bases de datos que lo hacen más seguro que otros SGBD, su naturaleza opensource hace que sea accesible para todas las empresas, PostgreSQL se considera la alternativa opensource de Oracle.

Ilustración 3. 13: Logo de PostgreSQL Fuente: (www.postgresql.org)

61

3.1.2.1.3 MySQL MySQL es un SGBD de código abierto, veloz y robusto. Actualmente pertenece a Oracle, MySQL Se autodenomina el SGBD más popular del mundo, ha sido mundialmente conocido por su alta velocidad al desarrollar búsquedas de datos e información, debido a esta popularidad, MySQL se ha convertido en el SGBD más usado en aplicaciones web y muy comúnmente se lo suele combinar con el lenguaje PHP, lo que ha generado excelentes resultados e incluso ha logrado convertirlo en un componente de plataformas como WAMP, LAMP, MAMP y XAMPP. MySQL Está proyectado para sistemas críticos en producción, soporta intensas cargas de trabajo y puede adaptarse en sistemas de desarrollo masivo de software.

Ilustración 3. 14: Logo de MySQL Fuente: (www.mysql.com)

3.1.2.2 Lenguaje SQL El lenguaje de consulta estructurado (SQL) es un lenguaje declarativo de muy alto nivel.

Elmasri & Navathe definen “SQL es un lenguaje de base de datos global; cuenta con sentencias para definir datos, consultas y actualizaciones. Además dispone de características para definir vistas en la base de datos, especificar temas de seguridad y autorización,

definir

restricciones

de

integridad,

y especificar

controles

de

transacciones” (Shamkant B. & Ramez, 2007). Su versatilidad lo ha convertido en el estándar de los SGBD, y ha tenido mucha influencia para el éxito comercial de los mismos.

62

3.1.2.2.1 DDL (Data Description Languaje) El lenguaje de definición de datos (DDL) se encarga de definir las bases de datos entre ellas, tablas, vistas, procedimientos, funciones, entre otros. Los comandos propios de este lenguaje son: CREATE, ALTER, DROP, TRUNCATE, RENAME. 3.1.2.2.2 DML (Data Manipulation Languaje) El lenguaje de manipulación de datos (DML) se encarga de administrar los datos existentes en la base de datos, mediante este lenguaje podemos ingresar, eliminar, actualizar y acceder a los registros de la base de datos, los comandos propios de este lenguaje son: SELECT, INSERT, UPDATE, DELETE. 3.1.2.3 Modelo de Datos Un modelo de datos es un mecanismo formal de representación y manipulación de información de manera general y sistemática, en la cual se especifican la descripción de datos, operaciones y reglas de integridad.

Ilustración 3. 15: Ciclo de vida clásico de modelado de datos Fuente: (Universidad de Granada, 2010, pág. 11)

63

3.1.2.3.1 Modelo Relacional El modelo relacional representa la base de datos como una colección de relaciones similar a una tabla de valores, cuando una relación está pensada como una tabla de valores, cada fila representa una colección de valores relacionados. Cada fila recibe el nombre de tupla y representa una colección de valores seleccionados, la cabecera de columna es un atributo y el nombre de la tabla es una relación (más detalle en la Ilustración 3.16).

Ilustración 3. 16: Estructura de una tabla en el Modelo Relacional Fuente: (Shamkant B. & Ramez, 2007, pág. 143)

E la tabla 3.6 se definen los componentes implícitos del modelo relacional.

Tabla 3. 7: Componentes del Modelo Relacional

Descripción de Datos

Entidades y relaciones se representan en forma de tablas, las mismas que reciben el nombre de la relación, las filas (tuplas) contienen datos sobre cada entidad, las columnas corresponden a los atributos de las entidades.

Operaciones

Unión, intersección, diferencia, producto cartesiano, selección, proyección y reunión.

Restricciones de Integridad

Integridad de entidad (llaves primarias) e integridad referencial (llaves foráneas).

Fuente: (Universidad de Granada, 2010, pág. 4)

64

3.1.3 Lenguajes de Programación Un lenguaje de programación es el lenguaje que se utiliza para escribir programas de computadoras y programadores son los escritores y diseñadores de programas El procedimiento de escritura del código fuente de un software. El proceso de traducir un pseudocódigo a un lenguaje de programación se denomina codificación y el algoritmo escrito en un lenguaje de programación se denomina código fuente (Joyanes, 2008).

Formalmente un lenguaje de programación es aquella estructura que, con una cierta base sintáctica y semántica, le indica al programa informático qué acción tiene que llevar a cabo y cuál es el modo de concretarla. Un lenguaje de programación contiene variables, vectores, bucles, condicionantes. Actualmente existen muchos lenguajes en el mercado, en su mayoría se adapta a la programación orientada a objetos. Entre los lenguajes de programación más conocidos podemos citar a C++, Visual Basic.NET, PHP y Java.

3.1.3.1 Microsoft Visual Studio.NET Visual Studio es una colección completa de herramientas y servicios para desarrollar aplicaciones para equipos de escritorio, la Web, dispositivos y la nube. Visual Studio proporciona un entorno de colaboración flexible que permite conectar con otras herramientas de desarrollo, como Eclipse y Xcode (Microsoft, 2014). Cuando creamos una aplicación usando Visual Studio.NET, el propio IDE facilita la labor del programador, mediante la creación automática de la estructura básica del programa, específicamente crea un fichero de código obteniendo un módulo que tiene el procedimiento de entrada, a espera de que el programador escriba las sentencias de código que desee ejecutar. Un proyecto aglutina los ficheros de código de la aplicación, recursos, referencias a clases globales de la plataforma .NET, entre otros (Blanco, 2005).

65

En sí todos los elementos que componen una aplicación en Visual Studio.NET se las denomina con el concepto de proyecto.

3.1.3.1.1 Visual Basic.NET Visual Basic.NET (VB.NET) es un lenguaje de programación orientado a objetos, es una evolución del lenguaje BASIC que se implementa sobre el Framework.NET. Nace de la necesidad de integrar Visual Basic como lenguaje del entorno .NET para incluir la programación en Internet y todo el nuevo espectro de servicios que ofrece el desarrollo integrado Microsoft Visual Studio.NET (Blanco, 2005). VB.NET facilita el desarrollo de aplicaciones avanzadas con herramientas de programación para internet mediante Web Forms y para Windows mediante Win Forms.

3.1.4 Servicio Nacional de Contratación Pública (SERCOP) El Servicio Nacional de Contratación Pública, es un organismo de derecho público, técnico y autónomo, cuya función es ejercer rectoría del Sistema Nacional de Contratación Pública. En la Ilustración 3.18 se puede observar el cambio que ha sufrido el SERCOP, en un inicio su nombre fue INCOP (Instituto Nacional de Contratación Pública), luego el 6 de septiembre del 2013 se cambió el nombre al SERCOP.

Ilustración 3. 17: Logo del SERCOP Fuente: (www.portal.compraspublicas.gob.ec)

66

Ilustración 3. 18: Filosofía del Servicio Nacional de Contratación Pública Fuente: (Escuela Politécnica Nacional, 2013).

La ley Orgánica del Sistema Nacional de Contratación Pública lo define al SERCOP como “El conjunto de procesos, procedimientos y mecanismos de evaluación de las compras realizadas por las instituciones del Estado y está orientado a la consecución de principios”. Los principios están especificados en la Tabla 3.7: Tabla 3. 8: Principios del Servicio Nacional de Contratación Pública

Principios

Descripción

Legalidad

Debe realizarse de acuerdo con lo que establece la Ley, la normativa aplicable estará jerarquizada jurídicamente.

Trato justo

Igual trato entre iguales, tal caso de los proveedores en los diferentes procedimientos de contratación.

Igualdad

Garantizar la igualdad de todos los oferentes dentro del proceso de contratación, evitando la discrecionalidad.

Calidad

Garantizar calidad tanto en el gasto público como en el objeto de la contratación.

Vigencia

Promover el uso intensivo de tecnología para simplificar los procedimientos de contratación legalmente establecidos, democratizar la información y transparentarla gratuitamente.

Tecnológica Oportunidad

Los procedimientos deben adecuarse de manera oportuna y eficiente

67

a las necesidades de las entidades contratantes, guardando relación con la programación realizada.

Concurrencia

Garantizar la participación competitiva de los proveedores sin discriminación alguna.

Transparencia La gestión de la Administración Pública se realiza bajo la ética y la moral, de carácter imparcial, de acuerdo con prácticas de honestidad y justicia.

Publicidad

Garantizar que los procesos de contratación sean de conocimiento del mayor número posible de interesados y de la sociedad en general.

Fuente: (Ley Orgánica del SNCP, 2008).

La constitución del Ecuador en el Artículo 288 especifica que “Las compras públicas cumplirán con criterios de eficiencia, transparencia, calidad, responsabilidad ambiental y social. Se priorizarán los productos y servicios nacionales, en particular los provenientes de la economía popular y solidaria de las micro, pequeñas y medianas unidades productivas”.

3.1.4.1 Proceso interno para Adquisiciones del SERCOP

Ilustración 3. 19: Flujograma de inicio de un proceso SERCOP Fuente: (Escuela Superior Politécnica de Chimborazo, 2014, pág. 5)

Todo proceso de adquisición, inicia con la elaboración del Justificativo de Requerimiento y Solicitud de Compra por parte de la unidad requirente, quien deberá

68

constatar previamente que lo solicitado se encuentre en el PAC y POA aprobado por la Máxima Autoridad o su delegado y publicado en la página web institucional. La Unidad de Adquisiciones recibirá la documentación completa y dará trámite siempre y cuando se constate la existencia de lo solicitado en el Plan Anual de Contratación vigente, caso contrario se devolverá a la unidad requirente. Posteriormente, se remite la documentación a la Unidad Técnica de Planificación para que se proceda con la certificación del Plan Operativo Anual, luego de lo cual, se devuelve a la Unidad de Adquisiciones. Una vez certificado el PAC y POA, se solicita al Departamento Financiero emita el documento que acredite la correspondiente disponibilidad de fondos, necesariamente se necesita una certificación presupuestaria. Seguidamente se solicita en el Rectorado la autorización requerida para iniciar el proceso de contratación.

Dependiendo del tipo de contratación, se ejecuta un proceso diferente lo cual implica diversas etapas con tiempos heterogéneos.

3.1.5.2 Procesos del Servicio Nacional de Contratación Pública En la presente disertación estudiaremos a fondo cuatro procesos del SERCOP, a los cuales se automatizará su seguimiento, los procesos que se estudiarán son: Subasta Inversa Electrónica, Cotización, Licitación y Mínima Cuantía.

3.1.5.2.1 Subasta Inversa Electrónica Un proceso de Subasta inversa electrónica se realiza cuando existe una sola oferta técnica calificada, o si a pesar de haber más de una oferta técnica calificada, solo un proveedor habilitado presenta la oferta económica inicial en el portal. No existe límite de monto de contratación.

69

Ilustración 3. 20: Etapas de Subasta Inversa Electrónica Fuente: (Escuela Politécnica Nacional, 2013, pág. 75).

3.1.5.2.2 Cotización Permite la contratación de bienes y servicios normalizados, se puede acceder a este proceso solo cuando el proceso de Subasta Inversa Electrónica se haya declarado desierto. Se puede aplicar Cotización cuando el monto destinado de contratación esté entre $68.601,27 y $514.514,56.

Ilustración 3. 21: Etapas de Cotización Fuente: (Escuela Politécnica Nacional, 2013, pág. 125).

70

3.1.5.2.3 Licitación Permite la contratación de bienes y servicios normalizados, se puede acceder a este proceso solo cuando el proceso de Subasta Inversa Electrónica se haya declarado desierto. Se puede aplicar Licitación cuando el monto de contratación sea mayor o igual a $514.509,56.

Ilustración 3. 22: Etapas de Licitación Fuente: (Escuela Politécnica Nacional, 2013, pág. 102).

3.1.5.2.4 Mínima Cuantía Menor Cuantía es el proceso administrativo que consiste en una invitación a contratar de acuerdo a bases previamente determinadas con la finalidad de obtener la oferta más beneficiosa para la administración. Se puede aplicar Mínima Cuantía cuando el monto de contratación sea menor o igual a $68.601,27.

71

Ilustración 3. 23: Etapas de Menor Cuantía Fuente: (Escuela Politécnica Nacional, 2013, pág. 87).

3.1.5.2.5 Tiempos establecidos para la ejecución de procesos

Ilustración 3. 24: Tiempos establecidos para la ejecución de procesos Fuente: (Escuela Superior Politécnica de Chimborazo, 2014, pág. 12)

72

3.2. Investigaciones o experiencias empíricas vinculadas con el problema de investigación

Ilustración 3. 25: División por Zonas de Ecuador Fuente: http://www.planificacion.gob.ec/

Para la presente investigación se tomó en cuenta las universidades de categoría A y B que cuenten con carreras de Ingeniería de Sistemas, de cada una de las 7 zonas del Ecuador (véase Ilustración 9).

A nivel local (Santo Domingo de los Tsáchilas) se investigó en el repositorio virtual de la Pontificia Universidad Católica del Ecuador sede Santo Domingo (PUCESD) y en la Universidad Autónoma de los Andes (UNIANDES) en la cual no se encontró ninguna disertación que se vincule directamente con la presente disertación.

A nivel nacional en la zona 1, en el repositorio virtual de la Pontificia Universidad

73

Católica del Ecuador sede Esmeraldas, en la que no se halló disertaciones vinculadas a la presente disertación, de la misma manera en la zona 2 se investigó en la Escuela Politécnica Nacional en sus respectivos repositorios virtuales, en la investigación no se halló disertaciones que se vinculen con la presente disertación, en la zona 5, se investigó en el repositorio virtual de la Escuela Superior Politécnica del Litoral, en la que no se halló ninguna disertación vinculada con la presente, en la zona 6 se investigó en la Universidad de Cuenca en su respectivo repositorio virtual donde no se halló disertaciones vinculadas con la presente, por último se investigó en la zona 7 en el repositorio virtual de la Universidad Técnica Particular de Loja, en la que no se encontró disertación que se vincule directamente a la presente.

Por lo cual se concluye que ni a nivel local, ni a nivel nacional existe una disertación que se vincule con la presente.

3.3. Hipótesis de trabajo El Sistema SSPS mejorará el seguimiento de los procesos de la SERCOP en CNEL EP cantón Santo Domingo.

IV. METODOLOGÍA DE LA INVESTIGACIÓN 4.1 Diseño y tipo de Investigación 4.1.1 Diseño de la investigación Señala el camino a seguir para alcanzar los objetivos de estudio y llegar a demostrar o rechazar la hipótesis.

4.1.1.1 Diseño no experimental Según Triola (2005,) el diseño no experimental es aquel que se realiza sin manipular deliberadamente variables, es decir, se trata de investigación donde no se hace variar intencionalmente las variables independientes (Mario F. Triola, 2005). Lo que se hace en la investigación no experimental es observar fenómenos tal y como se dan en su contexto natural, para después analizarlos.

Aplicación: Se aplica este método al análisis de la primera entrevista, donde se pudo tener una impresión de la problemática y del entorno de trabajo del área de control de energía.

4.1.1.1.2 Estudio Descriptivo Los estudios descriptivos “busca especificar

propiedades, características y rasgos

importantes de cualquier fenómeno que se analice. Describe tendencias de un grupo o población, pretenden medir o recoger información de manera independiente o conjunta sobre los conceptos o las variables a las que se refieren” (Hernández, 2010, pág. 80).

Aplicación: Se aplica este método en el primer resultado que corresponde análisis de la encuesta, donde se determinó los problemas que aquejan, determinando las causas y factores que determinan el ineficiente seguimiento brindado a los procesos del SERCOP, 74

75

para de esta manera implementar la solución, como es la implantación del Sistema de Seguimiento de Procesos del SERCOP. 4.1.2 Tipo de investigación Se puede definir al tipo de investigación como la clasificación genérica de la investigación 4.1.2.1 Investigación Documental – Bibliográfica “Es aquella que se realiza a través de la consulta y análisis de documentos.

Adopta

diferentes formas, siendo las más usuales: monografía, ensayos, informes, estadísticas, investigaciones, memorias, trabajos didácticos, anales, historia, historiografía, técnica y ciencia”. (Cauca, 2013) .

Aplicación: Este tipo de investigación contribuye para el sustento del marco referencial, para la conceptualización de temas relevantes y permite profundizar, basándose en documento con base teórica científica, que fundamenten el proyecto de investigación, tomando en cuenta los criterios de varios autores sobre una definición determinada.

4.1.2.2 Investigación de Campo Se basa en informaciones obtenidas directamente de la realidad, permitiéndole al investigador cerciorarse de las condiciones reales en que se han conseguido los datos.

Aplicación: Mediante este tipo de investigación se podrá observar la problemática directamente en el Área de Control de Energía en CNEL cantón Santo Domingo, así obtener toda la información requerida para el desarrollo del proyecto mediante la aplicación de encuestas y entrevista.

76

4.1.2.3 Investigación Proyectiva Aplicable La investigación es de tipo proyectiva ya que aporta a la solución del problema y tiene como objetivo diseñar o crear propuestas, a través de una planificación dirigida a resolver determinadas situaciones y algún tipo de necesidad que sea práctico.

Aplicación: Consientes de los problemas ocasionados por el ineficiente seguimiento de procesos del SERCOP, se planteó el desarrollo de un sistema de seguimiento de procesos y la implantación en el área de Control de Energía.

4.2 Población/Universo “La población es el conjunto de elementos que representan una característica o condición común que es objeto de estudio”. (Pineda & Alvarado, 2009, pág. 123) Aplicación: La población para este proyecto será el personal del Área de Control de Energía de la CNEL cantón Santo Domingo.

4.3. Muestra “La muestra es la parte de los elementos o subconjuntos de una población que se seleccionan para el estudio de esa característica o condición” ( Pineda& Alvarado , 2008, pág. 123).

4.3.1 Muestra de una población pequeña Cuando la población posee un número menor o igual a 200 integrantes, el tamaño de la muestra será el mismo de la población. (Mario F. Triola, 2005).

77

4.3.2 Muestra de una población extensa Cuando la población excede de 200 integrantes. La muestra se obtendrá por medio el uso de la siguiente fórmula:

Ilustración 4. 1: Formula para el cálculo de la muestra en población extensa Fuente: (Mario F. Triola, 2005, pág. 330)

Dónde: n = tamaño de la muestra.

N = tamaño de la población. σ = desviación estándar de la población que, generalmente cuando no se tiene su valor, Z = valor obtenido mediante niveles de confianza. e = Límite aceptable de error muestral.

Aplicación: Dado el caso de la presente disertación, donde la población es de 15 integrantes, se considera como población finita, se tomaran los mismos individuos de la población como muestra para el análisis. .

4.4 Instrumentos de Recogida de Datos Para la recolección de datos se usaran las siguientes técnicas: 4.4.1 Entrevista Consiste en una conversación planificada entre el entrevistador y entrevistado, en la cual se pueden hacer preguntas abiertas sobre temas específicos relacionados con la problemática a estudiar, esta técnica es útil y permite conocer los diferentes tipos de

78

vista de las partes involucradas en la investigación. Se emplea para investigar hechos o fenómenos de forma particular.

Aplicación: Se aplicó una entrevista al Jefe del Área de Control de Energía para determinar los requerimientos del sistema en las cuales se generaron las historias de usuarios propias de la metodología de desarrollo de software.

4.4.2 Encuesta Se trata de un estudio en el cual el investigador busca recaudar datos por medio de un cuestionario pre diseñado referente a la temática particular, una encuesta permite conocer el tipo de vista de las personas sobre el problema tratado. Se emplea para investigar hechos o fenómenos de forma general.

Las preguntas de la encuesta pueden ser de diferentes tipos los cuales están especificados en la Tabla 4.1.

Tabla 4. 1: Tipos de preguntas posibles en una encuesta.

Tipos de Preguntas

Descripción

Preguntas abiertas

Permiten que el encuestado tenga la libertad de exponer su respuesta como crea conveniente.

Preguntas cerradas

Permiten al encuestado elegir entre respuestas ya establecidas por el encuestador.

Preguntas Mixtas

Son preguntas cerradas que dan opción al encuestado la posibilidad de ampliar su respuesta, mediante la opción “otros” o “por qué”.

Preguntas dicotómicas

Permiten solo dos alternativas “Si” o “No”.

Preguntas de batería

Conjunto de preguntas dependientes una de otra.

Preguntas con múltiple respuestas

Permiten al encuestado escoger entre un grupo de opciones.

79

Preguntas con unipolares respuestas

Permiten al encuestado escoger su respuesta dentro de una escala de calificación Fuente: (Pineda & Alvarado, 2009)

Previa a la realización de la encuesta se deben tomar en cuenta los siguientes datos: Tabla 4. 2: Datos a tomar en cuenta previo a la realización de la encuesta

Datos a tomar en cuenta

Descripción

Entidad

Objeto a participar en la encuesta.

Actividad

Acción realizada por la entidad participante en la encuesta

Ubicación

Localización geográfica de la entidad.

Área

Lugar específico que es parte de la entidad.

Tipo de preguntas

Se refiere a la categorización por tipo de las preguntas incluidas en la encuesta.

Tipo de encuesta

Se refiere al medio por el que es realizada la encuesta.

Trabajo de Campo

Los días en que se realizó la encuesta.

Población

Conjunto de individuos pertenecientes a la entidad y cuyas opiniones son objeto de análisis para la encuesta.

Muestra

Subconjunto representativo de la población

Realizada Por

Actor responsable de la encuesta.

Fuente: (Pineda & Alvarado, 2009)

Aplicación: Se aplicó una encuesta al personal en general del área de control de energía, en donde se hizo una observación y medición de las necesidades de los empleados del área referente al seguimiento de procesos. Para ver el modelo impreso de la encuesta (Ver Anexo 4).

80

4.5 Técnicas de Análisis de Datos 4.5.1 Cuadros Estadísticos Son Ilustraciones gráficas que ayudan a apreciar mejor y tener una idea más clara y organizada de los datos obtenidos.

Aplicación: La información recolectada en las encuestas al personal fue tabulada y analizada mediante cuadros estadísticos en la herramienta Excel.

4.6 Programación Extrema (XP) XP Es la metodología de desarrollo de software escogida para el desarrollo del sistema de seguimiento de procesos del SERCOP (SSPS), debido a la necesidad de agilidad por el poco tiempo disponible para el desarrollo del sistema, XP es atractivo porque posee prácticas como desarrollo iterativo y participación del cliente, y las lleva a niveles extremos. A continuación se describirá la experiencia obtenida en la realización del Sistema SSPS durante las etapas de planeación, diseño, codificación y pruebas, aplicando XP. 4.6.1 Planeación La planeación es indispensable en toda metodología de desarrollo de software en, en XP de igual forma, en esta etapa se realizan las primeras reuniones, en donde se definen roles y se planifican tiempos de entrega e iteraciones.

4.6.1.1 Roles en XP XP define roles para compartir tareas durante todo el proceso de desarrollo, a diferencia de las metodologías clásicas, XP solo necesita de cinco roles los cuales son

81

programador, cliente, encargado de pruebas, encargado de seguimiento, entrenador y Manager de proyectos.

Aplicación en SSPS: Teniendo en cuenta que solo había un desarrollador para este proyecto, los roles de programador, Manager y encargado de pruebas fueron ocupados por Edwin Villamarín, el rol de cliente fue ocupado por el jefe de control de energía de la CNEL EP SD. El rol de traker o encargado se seguimiento no fue tomado en cuenta debido a que no fue necesario.

4.6.1.2 Historias de Usuario XP define que las historias de usuarios deben ser escritas por el cliente, usando su terminología, a bajo nivel de detalle, y a su vez estas sirven para estimar los tiempos de implementación.

Aplicación en SSPS: Debido a que el cliente no tenía los conocimientos necesarios sobre el formato de las historias de usuario, este no escribió personalmente las historias de usuario, pero diseñó el contenido y dirigió la redacción de cada una, se trató en lo posible en no profundizar en procesos y mantener la terminología del cliente. Al final de este proceso se obtuvo un total de veintiséis historias de usuario.

4.6.1.3 División en iteraciones XP especifica que los proyectos se deben dividir en iteraciones y una iteración tendrá una duración entre una y tres semanas.

82

Aplicación en SSPS: El proyecto fue dividido en 4 iteraciones, por consiguiente se definió un total de cuatro entregas, cuyas entregas fueron planeadas posteriormente, debido a la escasa disponibilidad del cliente.

4.6.1.4 Velocidad del proyecto Xp dice que basándose en las historias de usuario o tareas de programación se puede estimar la cantidad de historias de usuario a implementar en una determinada iteración.

Aplicación en SSPS: Para las veintiséis historias de se definieron de 12 semanas.

4.6.1.5 Entregas pequeñas XP expresa que se deben realizar entregas pequeñas al final de cada iteración.

Aplicación en SSPS: Debido a que el proyecto fue divido en 4 iteraciones, se realizaron cuatro entregas, las cuales se planificaron posteriormente con el cliente.

4.6.1.6 Plan de Entregas XP especifica que se debe realizar una reunión al inicio del proyecto, en el cual se definirán cuales historias de usuario serán implementadas en cada entrega, debido al grado de relevancia que proporcione el usuario, en esta reunión se aproxima el tiempo que conlleva la realización de cada iteración y el diario que llevará a cabo cada miembro del equipo.

Aplicación en SSPS: Se realizó una modificación a la metodología, debido a que la clasificación de las historia de usuario no se realizó por el grado de importancia, el módulo de usuarios se realizó en la primera iteración, de igual forma no se siguió

83

estrictamente el diario de cada integrante por lo que sufrió muchas modificaciones debido a obligaciones externas del proyecto.

4.6.1.7 Mover Personal XP sugiere que cada persona del equipo debe conocer el código de cada sección del proyecto, por lo que se sugiere rotar los programadores.

Aplicación en SSPS: Debido a que solo se contaba con un programador esta tarea fue fácil de implementar.

4.6.2 Diseño A diferencia de las metodologías pesadas, en XP el diseño se realiza durante todo el proceso de desarrollo, siendo continuamente revisado y a veces modificado, debido a cambios de requerimientos durante el desarrollo.

4.6.2.1 Simplicidad XP especifica que el diseño debe de ser sencillo.

Aplicación en SSPS: Debido a que uno de los requerimientos era que el sistema SSPS debía contar con una interfaz amigable, no se cumplió específicamente, por lo que se tuvieron que no se cumplió estrictamente la planificación y se tuvo que modificar en muchos casos el diario del programador, pero valió la pena el sacrificio debido a que el resultado fue un diseño de vanguardia, agradable al usuario.

84

4.6.2.2 Tarjetas CRC XP dice que la principal utilidad de las tarjetas CRC (Clase-ResponsabilidadColaboración) es dejar el enfoque procedimental y permite entrar al modelo orientado a objetos.

Aplicación en SSPS: Las tarjetas CRC fueron de gran ayuda en el diseño, debido a que sirvieron como columna vertebral para la elaboración y sirvieron de base para la elaboración del modelo relacional y la posterior creación de la base de datos. Las tarjetas CRC se definieron a inicios del proyecto y se fueron modificando según las pruebas unitarias. Se realizó una tarjeta CRC por cada entidad.

4.6.2.3 Refactorización XP aconseja refactorizar el diseño como tarea permanente, de esta manera se conserva el código sencillo, e incluso se podrán rehacer secciones de código de ser necesario.

Aplicación en SSPS: Durante el diseño de la aplicación se revisó constantemente sugiriendo situaciones nuevas que no fueron tomadas en cuanta al inicio del desarrollo, así se aumentaba la productividad del sistema, por ejemplo se planteó diseñar una tabla llamada procesos, el cual contendría los procesos de las 4 tablas de procesos: Subasta inversa, Mínima cuantía, Cotización y Licitación, se tomó en cuenta los atributos en común como nombre del proceso, fecha de inicio, fecha de finalización, así de esta manera en una sola consulta se obtendría los procesos activos y los completados, otro tipo de refactorización fue cambiar el tipo de datos de las fechas de date a varchar(10), de esta manera se mantendría el formato DD/MM/AA sugerido en la historia de usuario.

85

4.6.3 Codificación En las metodologías clásicas la codificación se realiza luego de las etapas de análisis y diseño, en XP no, la codificación empieza desde que inicia el proyecto.

4.6.3.1 Cliente siempre presente XP plantea que el cliente debe estar disponible en el sitio de trabajo y que el cliente es fundamental para solucionar dudad cara a cara.

Aplicación en SSPS: Este principio no fue fácil de cumplir, así que se ideo un plan para comunicación con el cliente debido a que el cliente por motivos de trabajo no podía desplazarse al lugar de trabajo, el plan de comunicación fue mediante correo electrónico y vía telefónica, de esta manera el cliente solucionaba las dudas que se presentaban en el proyecto.

4.6.3.2 Utilización de Estándares en el código XP exige que al escribir código del programa se deben seguir estándares del lenguaje de programación.

Aplicación en SSPS: Para evitar inconvenientes, desde un inicio de la codificación se emplearon los estándares de Visual Basic. NET y de igual forma para la conexión de la base de datos se aplicó el Estándar OBDC. 4.6.3.3 Codificar primero la prueba XP aconseja que antes de escribir el código este debe ser probado.

86

Aplicación en SSPS: Se planteó una modificación a este principio en el que se optó por desarrollar mentalmente el algoritmo, mediante las tarjetas CRC se pensaba el algoritmo a desarrollar para la ejecución del código, basada en la experiencia.

4.6.3.4 Programación en Parejas XP plantea que toda la programación realizada en el proyecto debe ser en parejas, de esta manera se mejora la calidad y se obtiene un código más organizado y los problemas se pueden solucionar más fácilmente, basado en el dicho “dos cabezas piensan mejor que una”.

Aplicación en SSPS: Debido a que se contaba con un solo programador este principio no se pudo aplicar, pero eso no quiere decir que el código generado sea de calidad, a lo contrario luego de escribir el código el programador revisaba nuevamente el código verificando los estándares y en lo posible se trataba de optimizarlo, logrando de esta manera hacer la labor de los dos programadores por una sola persona.

4.6.3.5 Integración Secuencial XP exige que antes de integrar un nuevo código al proyecto se debe garantizar que la última versión halla pasado todas las pruebas.

Aplicación en SSPS: Para la aplicación de este principio se tuvo siempre a una copia de la última versión funcional, para ello una vez esta pasaba las pruebas se generaba una copia y para la nueva integración se trabajaba sobre la copia, en caso de no lograr la integración deseada se volvía a la última versión funcional, evitando así dañar la última versión funcional, en caso de que la copia se adaptaba al proyecto y pasaba las pruebas se la guardaba como última versión.

87

4.6.3.6 Integraciones Frecuentes XP sugiere que se deben hacer integraciones cada corto tiempo, debido a que entre más se tarde en encontrar un problema, resultará más costoso resolverlo.

Aplicación en SSPS: Por lo general se realizaban 1 integración diaria y en los momentos con más ocupaciones externas al proyecto, se realizaba 2 integraciones a la semana, garantizando de esta manera una constante ejecución del código, para garantizar que se trabajaba siempre sobre la más reciente versión probada, se realizaba el siguiente procedimiento: A la última versión probada se la ubicaba en una carpeta con el nombre de “SSPS <Día> <Mes> <Hora>”.

4.6.3.7 Propiedad colectiva del código XP dice que se debe procurar rotar a los programadores, debido a que cualquier programador debería poder continuar la codificación que alguien empezó sin muchas dificultades, por ello el uso de estándares de programación.

Aplicación en SSPS: No se aplicó del todo este principio debido a que solo existía un programador, el cual llevo toda la parte de la codificación, pero si se aplicó los estándares de modo que cualquier programador pueda continuar.

4.6.3.8 Evitar Horas Extras de trabajo XP sugiere no trabajar horas extras, debido a que se busca aprovechar al máximo las cualidades del programador, y está comprobado que un programador cansado genera código de mala calidad, y eso es inaceptable. Es preferible replantear los plazos a trabajar horas extras.

88

Aplicación en SSPS: Este principio fue aplicado durante todo el desarrollo, es uno de los principios más interesantes y uno de los que más me gustó, debido a que se aprovechó al máximo la productividad marginal del programador, durante el proyecto existieron retrasos, pero se decidió replantear los plazos a trabajar horas extras. Lo que dio excelentes resultados.

4.6.4 Pruebas XP se enfatiza en las pruebas más que ninguna otra metodología, debido al principio, probar antes y después de la codificación genera software de calidad y evita pérdida de tiempo en el futuro. De esta manera se evita la posibilidad de que un error avance en una siguiente iteración.

4.6.4.1 Pruebas Unitarias XP indica que las pruebas deben ser escritas antes que los métodos y su implantación y ejecución deben consumir el menor tiempo posible.

Aplicación en SSPS: Al principio fue caótico acostumbrarse a la realización de pruebas pero con el tiempo de desarrollo esto paso a ser muy novedoso y evitó muchos problemas, por ejemplo, se planteaba realizar un timer para recordar las fechas de ejecución de los procesos, la idea era esa, pero en la prueba unitaria se comprendió que no era necesario en timer ya que consumiría más recursos y envés de ello se empleó un generar un botón que al presionarlo llame al evento Load Form(), lo que resultó más útil, otra experiencia en las pruebas unitarias era el envío de email con las tareas a ejecutar en el día y el día siguiente, se pensaba en un timer que genere un hilo de envío, se realizó el algoritmo, el cual parecía funcionar, pero al codificarlo se presentaron problemas,

89

porque no se ejecutaba todo el hilo, es decir, no enviaba todos los emails de tenía que enviar, así que no pasó la prueba luego de la codificación y se resolvió rápidamente colocar el hilo de ejecución en una nueva aplicación llamada SSP_Secretaria, aquella aplicación solo se ejecutaría en la máquina de la secretaria, así de esta forma se implementó que al prender la comparadora, SSP_ Secretaria se autoejecute y en el evento Form Load(), se colocó el hilo, pero aún así no enviaba todos los emails, así que se probó con la función Sleep(200) luego de cada envío, lo que resultó en éxito.

4.6.4.2 Pruebas de Aceptación XP sugiere diseñar las pruebas de aceptación con base en las historias de usuario.

Aplicación en SSPS: Se realizaron cuatro pruebas de aceptación, una por cada iteración, las pruebas de aceptación se realizaron correctamente, en las dos primeras iteraciones, ya que las pruebas fueron realizadas por el programador, debido a la poca disponibilidad del cliente en esos días, en las dos últimas iteraciones, el cliente participó en las pruebas de aceptación. La tercera prueba de aceptación fue complicada, porque era la primera prueba de aceptación que realizaba el cliente en su computador, no se pudo realizar la conexión en la red local, debido a la incompatibilidad con del Sistema Operativo. Por lo que para la última prueba de aceptación funcionó la conexión con una versión más antigua del SGBD MySQL. La última prueba de aceptación fue exitosa, porque no se encontró un solo error.

V. RESULTADOS 5.1 Discusión y análisis de los resultados 5.1.1 Encuesta aplicada a los empleados de la CNEL EP SD. 5.1.1.1 Introducción Se realizó una encuesta a los empleados de la CNEL EP Santo Domingo (Ver Anexo 4), para determinar los problemas y necesidades más comunes que presentan con relación al seguimiento y control de los procesos del SERCOP. 5.1.1.2 Metodología Previo a la realización de la encuesta se tomaron en cuenta los siguientes datos.

Tabla 5. 1: Datos previos de la encuesta realizada

Datos de la encuesta

Descripción

Entidad

Empresa Pública Estratégica Corporación Nacional de Electricidad Santo Domingo CNEL EP SD.

Actividad

Distribución y comercialización de energía eléctrica.

Ubicación

Ecuador, Santo Domingo de los Tsáchilas, Av. Tsáchila 826 y Clemencia de Mora.

Área

Área de Control de Energía.

Tipo de preguntas

Constó de 8 preguntas de selección múltiple.

Tipo de encuesta

Medio Impreso, 1 hoja.

Trabajo de Campo

18, 19 y 20 de Septiembre del 2013

Población

Personal del área de Control de Energía, contabilizados suman 15 miembros.

Muestra

Debido a que el tamaño de la población es pequeño, no fue necesario calcular la muestra representativa, y se aplicó la encuesta a toda la población (15 personas).

90

91

Realizada Por

Edwin Villamarín Rojas.

Fuente: El disertante.

5.1.1.3 Tabulación y análisis de la información A continuación se presenta la tabulación y análisis de cada una de las preguntas aplicadas en la encuesta.

Pregunta 1.- ¿Ha tenido usted problemas en recordar fechas de tareas de algún proceso del SERCOP? Tabla 5. 2: Problemas recordar fechas del SERCOP Opción

f

%

Si

11

73,33%

No

4

26,67%

Total

15

100% Fuente: El disertante.

26,67%

73,33% No

Si

Ilustración 5. 1: Problemas recordar fechas del SERCOP Fuente: El disertante

Interpretación y análisis: El resultado se inclina al 73,33% los empleados del área de Control de energía tienen problemas al momento de recordar fechas de un proceso del

92

SERCOP. Los 26,67 restantes no tienen problemas al recordar la fecha de una tarea de un proceso.

La mayoría de empleados del área de control de energía tienen o han tenido problemas para recordar fechas de tareas de procesos. Por lo que esto obliga a los empleados a usar diferentes herramientas que ayuden a recordar las tareas necesarias a realizar en un día determinado.

Pregunta 2.- ¿En su área, conoce Usted casos de que se haya caído algún proceso del SERCOP? Tabla 5. 3: Casos de procesos caídos Opción

f

%

Si

15

100%

No

0

0%

Total

15

100% Fuente: El disertante

100%

si Ilustración 5. 2: Casos de procesos caídos Fuente: El disertante

93

Interpretación y análisis: Los resultados de la encuesta realizada indican que el 100% de los empleados encuestados conocen casos de caídas de procesos en la empresa.

En la empresa CNEL EP han existido casos de caídas de procesos, todos los empleados encuestados lo afirmaron, claro que no ocurren con frecuencia, pero ocurren, las causas son muchas, una de ellas es el olvido involuntario de fechas.

Pregunta 3.- ¿Cuáles son los factores más frecuentes por lo que se cae un proceso del SERCOP?

Tabla 5. 4: Factores frecuentes caída de procesos SERCOP Opción

f

%

El proveedor queda mal

3

20,00%

Se olvidan las fechas de

7

46,67%

Ambas

5

33,33%

Total

15

100%

ejecución

Fuente: El disertante.

94

20,00% 46,67%

33,33%

El proveedor queda mal

Ambas

Se olvidan las fechas de ejecución

Ilustración 5. 3: Factores frecuentes caída de procesos SERCOP Fuente: El disertante

Interpretación y análisis: El resultado de la encuesta refleja que el 46,67% de los casos de caídas de procesos se deben a que se olvidan las fechas de ejecución, el 20,00% de los encuestados en cambio dicen que se debe a que el proveedor queda mal y el 33,33% de los encuestados expresan que se debe a ambas.

En la empresa CNEL EP la mayoría de casos que originan la caída de procesos es el olvido involuntario de fechas.

Pregunta 4.- ¿Alguna vez usted Se ha olvidado la fecha de ejecutar alguna tarea de algún proceso?

Tabla 5. 5: Olvido fechas del SERCOP Opción

f

%

Si

11

73,33%

No

4

26,67%

95

Total

15

100% Fuente: El disertante.

26,67% 73,33%

No

Si

Ilustración 5. 4: Olvido fechas del SERCOP Fuente: El disertante

Interpretación y análisis: El resultado de la encuesta se inclina con un 73,33% de los encuestados que afirman que se han olvidado involuntariamente una tarea de un proceso del SERCOP, en cambio un 26,67 expresa no haber olvidado nunca la fecha de ejecución de una tarea del SERCOP. Debido a la complejidad de recordar fechas, un contundente 73,33% acepta haber olvidado las fechas de las tareas de los procesos, a un 26,67% que asegura no haberlas olvidado, debido al uso de alguna herramienta que ayude a recordar la respectiva fecha.

Pregunta 5.- ¿Para recordar códigos o fechas de algún proceso, que método utiliza usted?

Tabla 5. 6: Métodos para recordar fechas de procesos Opción

f

%

Agendas Electrónicas

1

6,67%

96

Notas en el Escritorio

1

6,67%

Hojas de Cálculo

2

13,33%

Papeles Recordatorios

11

73,33%

Total

15

100%

(Excel)

Fuente: El disertante.

6,67% 6,67%

13,33% 73,33%

Agendas Electrónicas Notas en el escritorio Hojas de Cálculo (Excel) Papeles recordatorios

Ilustración 5. 5: Métodos para recordar fechas de procesos Fuente: El disertante

Interpretación y análisis: Se concluye que el 73,33% los empleados del área de Control de energía usan papeles recordatorios para recordar la fecha de ejecución de una tarea de un proceso del SERCOP, un 13,13 usa hojas de cálculo (Excel) para recordar códigos o fechas, un 6,67 confía en las notas en el escritorio y un 6,67 usa agendas electrónicas.

Buscar el método más fácil para recordar es importante, para la empresa CNEL EP SD los papeles recordatorios son la mejor opción para recordar las tareas, pero lamentablemente esto ocasiona que se efectúe gastos extras de equipos de oficinas y

97

puede genera un impacto negativo al medio ambiente.

Pregunta 6.- ¿Ha tenido problemas al momento de editar un documento de procesos (en Excel) cuando otra persona lo tiene abierto en la red local?

Tabla 5. 7: Problema al editar un documento en la red Opción

f

%

Si

12

20%

No

3

80%

Total

15

100% Fuente: El disertante.

20,00%

80,00%

No

Si

Ilustración 5. 6: Problema al editar un documento en la red Fuente: El disertante

Interpretación y análisis: Se concluye que el 80 % los empleados del área de Control de energía tienen problemas al editar un documento de Excel (documento en el que constan las los códigos y fechas de ejecución de procesos del SERCOP). , en cambio otro 20% puede editar sin inconvenientes el archivo de Excel generando una nueva copia del documento.

98

En vista que existía un documento de Excel para guardar información sobre los procesos del SERCOP, la mayoría tiene problemas al editarlo, ya que incurre en la creación de una nueva copia del mismo, lo que genera confusión y consumo innecesario de memoria en el servidor.

Pregunta 7.- ¿Qué tiempo promedio Ud. se demora al buscar un código de un proceso activo en una hoja de cálculo y luego buscar ese código en la página del SERCOP para divisar las fechas de las tareas de ese proceso? (Tenga en cuenta que el documento de Excel está siendo utilizado por otra persona en la red) Tabla 5. 8: Tiempo empleado consultar fechas Opción

f

%

Menos de 5 minutos

3

20%

5 minutos

2

13,33%

7 minutos

2

13,33%

10 minutos

7

46,67%

Más de 10 minutos

1

6,67%

Total

15

100% Fuente: El disertante.

99

6,67% 13,33%

46,67%

13,33%

20,00%

Más de 10 minutos 5 minutos 7 minutos Menos de 5 minutos Ilustración 5. 7: Tiempo promedio consultar fechas Fuente: El disertante

Interpretación y análisis: Se concluye que el 46,67 % los empleados del área de Control de energía se demoran 10 minutos para buscar el código de un proceso activo en una hoja de cálculo e ingresarlo a la página web del SERCOP para divisar las fechas, otros más ágiles lo hacen en menos tiempo, como el 13,33 que lo hace en 7 minutos, otro 13,13% lo hace en 5 minutos, y un 20% lo hace en menos de 5 minutos, pero existe un 6,67% que lo hace en más de 10 minutos.

Recordar la fecha de una tarea de un proceso del SERCOP conlleva para la mayoría 10 minutos, debido a que la herramienta utilizada es obsoleta e ineficiente para llevar a cabo la función destinada por los empleados de CNEL EP.

100

Pregunta 8.- ¿Ud. Estaría de acuerdo que se debería implementar un Sistema para dar seguimiento a los procesos del SERCOP, para así automatizar el control y seguimiento de los procesos del SERCOP? Tabla 5. 9: Implementar Sistema de Seguimiento Opción

f

%

Si

15

100%

No

0

0%

Total

15

100% Fuente: El disertante.

100,00%

Si Ilustración 5. 8: Implementar Sistema de Seguimiento Fuente: El disertante

Interpretación y análisis: Se concluye que el 100 % los empleados del área de Control de energía están de acuerdo en la implementación de un sistema para dar seguimiento a los procesos del SERCOP. La implementación del sistema cambiará el enfoque del seguimiento obsoleto que utilizaban, por un enfoque más ágil y preciso, el personal de CNEL expresa en mayoría absoluta que es necesario que se implante el sistema.

101

5.1.2 Metodología de desarrollo Programación Extrema en la elaboración del Sistema SSPS. 5.1.2.1 Proceso de desarrollo de la Metodología XP El Sistema de Seguimiento de Procesos del SERCOP (SSPS) se desarrolló paso a paso, usando la metodología de desarrollo Programación Extrema (XP). A continuación se explica su desarrollo.

5.1.2.2 Planificación Como parte inicial de la metodología aquí se realizaron reuniones para definir los roles, establecer los requerimientos y las historias de usuarios, además de establecer el número de iteraciones y el tiempo aproximado que tomara el desarrollo del sistema, además en esta fase se planificaron entregas y se definieron los diarios (tareas) para cada integrante del equipo de desarrollo.

5.1.2.2.1 Especificación de Requerimientos de Software (SRS) En esta parte se definieron todos los requerimientos iniciales y se elaboró el SRS, a medida que cambiaron los requerimientos a lo largo del desarrollo del sistema se generaron nuevos SRS. La versión final del SRS, continente los siguientes requerimientos.

Tabla 5. 10: Especificación de Requerimientos de Software SSPS:

N.

REQUERIMIENTO

1

Ingreso al sistema

PRIORIDAD Alta

102

2

Registro de Usuarios

Alta

3

Modificar datos de usuarios

Alta

4

Aceptar/Rechazar solicitud de usuarios

Alta

5

Eliminar Usuarios

Alta

6

Reporte de usuarios

Alta

7

Reporte de auditoría de usuarios

Alta

8

Reporte de auditoría de procesos

Alta

9

Envío de Emails a usuarios

Media

10

Recordar tareas de procesos vía Email

Media

11

Recuperar cuenta vía Email

Media

12

Ingreso de procesos licitación

Media

13

Ingreso de procesos de subasta inversa

Media

14

Ingreso de procesos de menor cuantía

Alta

15

Ingreso de procesos de cotización

Alta

16

Modificación de procesos de subasta inversa

Alta

17

Modificación de procesos de menor cuantía

Alta

18

Modificación de procesos de cotización

Alta

19

Eliminación de procesos de licitación

Alta

20

Eliminación de subasta inversa

Alta

21

Eliminación de menor cuantía

Alta

22

Eliminación de cotización

Alta

23

Consulta de procesos activos

Alta

24

Consulta general de procesos

Alta

25

Reporte de procesos activos

Alta

103

26

Reporte personalizado de procesos

Media

27

Reporte de procesos personalizada

Media

28

Mensajes en el Panel

Media Fuente: El disertante.

Para mayor información y detalle, revise la última modificación del SRS (Revise el Anexo 1).

5.1.2.2.2 Análisis y Gestión de Riesgos Se Realizó un análisis y gestión de los posibles riesgos que se presentarán durante la ejecución del proyecto de disertación, para lo cual se tomó en cuenta tres tipos de riesgos, los cuales están especificados en la Tabla 5.11.

Tabla 5. 11: Clasificación de los Riesgos

TIPO DE RIEGO

DETALLE

Riesgo de Negocio

Amenazan la viabilidad del software que se construirá.

Riesgo del Proyecto

Amenazan la planificación temporal (plan del proyecto), coste y calidad del proyecto.

Riesgo Técnico

Amenazan la calidad y actualidad del software que se producirá.

Fuente: El disertante.

Se identificaron los posibles riesgos, y se los organizó por tipo de riesgo y consecuencia que originará durante la ejecución del proyecto de disertación, todos los posibles riesgos se listan en la tabla 5.12.

104

Tabla 5. 12: Identificación de los Riesgos del Proyecto

I ID

RIESGO

TIPO

CONSCUENCIA

1

R Cambio de directivos de la institución

Riesgo de Negocio

2

R Oposición de Empleados a los cambios

Falta de colaboración al Riesgo del efectuar el levantamiento de Negocio requerimientos

3

R Incumplimiento de Requerimientos establecidos

Riesgo de Negocio

Pérdida de recursos y tiempo.

Retraso en la entrega del software

4

Poco tiempo y recursos R disponibles para el desarrollo del proyecto.

Riesgo de Negocio

Proyecto no terminado a tiempo.

Cambio de Políticas o Leyes R (Aumento, disminución o modificación de factores)

Cambio de requerimientos, Riesgo del Producto terminado no Proyecto utilizado.

R Ocupaciones Extra-laborales

Riesgo del Retraso en el proyecto. proyecto

Falta de experiencias en R herramientas de planificación y/o programación

Riesgo de proyecto

Falta de información de R requerimientos, alcance y metas del proyecto.

Riesgo del Retraso en el análisis del proyecto software.

5

6

7

8

9

Cambio de requerimientos o suspensión del proyecto

Pérdida de tiempo en el aprendizaje generando retrasos en el proyecto.

Falta de información de R requerimientos, alcance y metas del proyecto.

Riesgo del Retraso en el análisis del proyecto software.

R Fallo de equipo que posea la

Riesgo

Retraso la implementación por

105

10

Técnico

falencias en el recurso físico.

10

R Violación de seguridad e Integridad de los datos

Riesgo Técnico

Retraso del proyecto al plantear un método que permita contener la seguridad del software.

11

R Interactuar con software que no ha sido probado

Riesgo Técnico

Retraso del proyecto, hasta probar el software nuevo, antes de interactuar.

Riesgo Técnico

Retraso del proyecto, hasta tener experiencia en la utilización de los nuevos métodos propios de la metodología empleada.

12

institución

R Utilización de métodos nuevos de análisis, diseño o pruebas

Fuente: El disertante.

Una vez identificados los riesgos se realizó un análisis y valoración de riesgos, para ello en la tabla 5.13 se muestra la definición que se utilizó para realizar cuyo análisis.

Tabla 5. 13: Definición de la valoración de Riesgos

Probabilidad de Riesgos

Impacto de Riesgos

Exposición al Riesgo

(%)

Valor

Resultado

Valor

Resultado

Valor

Resultado

0 – 25

1

Baja

1

Bajo

2

Baja

26 – 50

2

Media

2

Moderado

3-5

Media

51-100

3

Alta

3

Alto

6-12

Alta

4

Crítico Fuente: El disertante.

En el análisis y valoración de riesgos se tomó en cuenta la probabilidad que ocurra el riesgo, el impacto que este originará y la exposición que tiene el proyecto ante el riesgo planteado, se puede observar el análisis en la Tabla 5.14.

106

Tabla 5. 14: Análisis y Valoración de Riesgos PROBABILIDAD

IMPACTO

EXPOSICIÓN AL RIESGO

ID

%

Valor

Prioridad

Valor

Impacto

Valor

Exposición

1

5

1

Baja

2

Moderado

2

Baja

2

5

1

Baja

2

Moderado

2

Baja

3

5

2

Media

3

Alto

6

Alta

4

5

2

Media

2

Moderado

4

Media

5

5

1

Baja

4

Critico

4

Media

6

0

2

Media

2

Moderado

4

Media

7

0

2

Media

2

Moderado

4

Media

8

5

1

Baja

2

Moderado

2

Baja

9

5

1

Baja

2

Moderado

2

Baja

10

5

1

Baja

3

Alto

3

Media

11

5

1

Baja

3

Alto

3

Media

12

5

1

Baja

3

Alto

3

Media Fuente: El disertante.

Para la gestión de riesgos, se tomó en cuenta solo los riesgos que daban una exposición alta o media; Para cada ellos se realizó una hoja de gestión de Riesgos, mostradas a continuación.

107

Tabla 5. 15: Hoja Gestión de Riegos 1

Hoja de Gestión de Riesgos: N.1 Riesgo: R3

Probabilidad: 35% - Media

Exposición: Alta

Fecha: 20/2/2014

Impacto: Alto

Responsable: Edwin Villamarín

Tipo: R. Negocios

Descripción del Riesgo: Incumplimiento de Requerimientos establecidos Causa – Efecto: El incumplimiento de los requerimientos establecidos para el software, ocasionará una pérdida de recursos y tiempo, originando por consiguiente un retraso en la entrega final del software.

Plan de contingencia (Solución): Para solucionarlo se aplicarán algunos principios de la metodología XP, como el cliente como parte del equipo de desarrollo, entregas pequeñas, diseño sencillo y ritmo sostenible, para así cumplir las expectativas de los requerimientos establecidos del usuario.

Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 16: Hoja Gestión de Riegos 2

Hoja de Gestión de Riesgos: N.2 Riesgo: R4

Probabilidad: 35% - Media

Exposición: Media

Fecha: 20/2/2014

Impacto: Moderado

Responsable: Edwin Villamarín

Tipo: R Negocios

Descripción del Riesgo: Poco tiempo y recursos disponibles para el desarrollo del

108

proyecto.

Causa – Efecto: El escaso tiempo y recursos limitados disponibles para el desarrollo del proyecto, ocasionará retrasos en la entrega final del software y en el peor de los casos que es proyecto no se complete.

Plan de contingencia (Solución): Para solucionarlo se aplicará la metodología XP, debido a que permite desarrollar software de calidad a bajo costo y lograrlo en menor tiempo que otras metodologías.

Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 17: Hoja Gestión de Riegos 3

Hoja de Gestión de Riesgos: N.3 Riesgo: R5

Probabilidad: 25% - Baja

Exposición: Media

Fecha: 20/2/2014

Impacto: Crítico

Responsable: Edwin Villamarín

Tipo: R. Proyecto

Descripción del Riesgo: Cambio de Políticas o Leyes (Aumento, disminución o modificación de factores) Causa – Efecto: El cambio de políticas o leyes institucionales, ocasionará un cambio de requerimientos, que afectaría al contrato, originando una restructuración al documento de especificación de requerimientos de software, y en instancias finales, provocaría que producto terminado no sea utilizado.

Plan de contingencia (Solución): Para su solución se aplicará la metodología XP, debido a que una de sus propiedad es que se puede generar o eliminar un requerimiento en cualquier etapa del proceso de desarrollo, debido a la utilización de

109

historias de usuarios y la flexibilidad del contrato.

Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 18: Hoja Gestión de Riegos 4

Hoja de Gestión de Riesgos: N.4 Riesgo: R6

Probabilidad: 50% - Media

Exposición: Media

Fecha: 20/2/2014

Impacto: Moderado

Responsable: Edwin Villamarín

Tipo: R. Proyecto

Descripción del Riesgo: Ocupaciones Extra-laborales Causa – Efecto: Las ocupaciones Extra-laborares, originarán un retraso en el desarrollo del proyecto.

Plan de contingencia (Solución): Durante la etapa de ocupaciones extra-laborales en la universidad, se practicaba las nuevas herramientas y software no conocido, además se aplicó el principio de 40 horas semanales y no horas extras, para rendir mejor y obtener mejores resultados.

Estado Actual: 18/06/2014

En Supervisión En Ejecución Finalizado Fuente: El disertante.

110

Tabla 5. 19: Hoja Gestión de Riegos 5

Hoja de Gestión de Riesgos: N.5 Riesgo: R7

Probabilidad: 40% - Media

Exposición: Media

Fecha:

Impacto: Moderado

Responsable: Edwin Villamarín

Tipo: R. Proyecto

20/2/2014 Descripción del Riesgo: Falta de experiencias en herramientas de planificación y/o programación Causa – Efecto: La Falta de experiencias en herramientas de planificación y/o programación, ocasionará una pérdida de tiempo durante el periodo de aprendizaje de las nuevas herramientas, generando retrasos en el desarrollo del proyecto.

Plan de contingencia (Solución): Para solucionar este inconveniente se planteó destinar un tiempo de 3 semanas para especializarse en la utilización de herramientas de planificación y programación, a la vez de adoptar las prácticas de diseño sencillo y aplicación de estándares de lenguajes de programación, propias de XP. Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 20: Hoja Gestión de Riegos 6

Hoja de Gestión de Riesgos: N.6 Riesgo: R10

Probabilidad: 25% - Baja

Exposición: Media

Fecha: 20/2/2014

Impacto: Alto

Responsable: Edwin Villamarín

Tipo: R. Técnico

111

Descripción del Riesgo: Violación de seguridad e Integridad de los datos Causa – Efecto: Por motivo de prevenir la violación de seguridad e Integridad de los datos, se producirá un retraso en el proyecto al plantear un método que permita contener la seguridad del software.

Plan de contingencia (Solución): Para solucionar la violación de seguridad e integridad de los datos, se planeó crear auditorías, tanto de usuarios como de procesos, para proteger la integridad de los datos.

Para proteger la suplantación de usuarios, se crearon los siguientes métodos: 1) Un método de autentifique al usuario que se registra al sistema, mediante roles inspectores, y aplicando una seguridad de auditoría de usuarios, la cual es inalterable.

2) Un método que permita detectar la hora, desde que IP se está conectando y la última conexión de un usuario al sistema.

Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 21: Hoja Gestión de Riegos 7

Hoja de Gestión de Riesgos: N.7 Riesgo: R11

Probabilidad: 25% - Media

Fecha: 20/2/2014

Impacto: Baja

Tipo: R. Técnico

Exposición: Media Responsable: Edwin Villamarín

Descripción del Riesgo: Interactuar con software que no ha sido probado Causa – Efecto: Al interactuar con un software nuevo o que no ha sido probado,

112

generará un retraso al proyecto, ya que se necesitará probarlo antes de ponerlo en ejecución en el proyecto, así para prevenir fallos.

Plan de contingencia (Solución): Para solucionar este inconveniente se planteó destinar un tiempo de 3 semanas para especializarse en la utilización de herramientas y adoptar las prácticas de diseño sencillo y aplicación de estándares, propias de XP. Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

Tabla 5. 22: Hoja Gestión de Riegos 8

Hoja de Gestión de Riesgos: N.8 Riesgo: R12

Probabilidad: 25% - Baja

Exposición: Media

Fecha: 20/2/2014

Impacto: Alto

Responsable: Edwin Villamarín

Tipo: R. Técnico

Descripción del Riesgo: Utilización de métodos nuevos de análisis, diseño o pruebas Causa – Efecto: La utilización de métodos nuevos de análisis, diseño y pruebas, demandará de experiencia, lo que generará un retraso al proyecto.

Plan de contingencia (Solución): Para solucionar este inconveniente se planteó usar la metodología XP, debido a que existe varios sitios web oficiales en donde la enseñan a detalle, lo que facilitará la comprensión.

Estado Actual: 18/06/2014 En Supervisión En Ejecución Finalizado Fuente: El disertante.

113

5.1.2.2.3 Historias de Usuario SSPS Las historias de Usuario en las metodologías ágiles tienen la misma función de los casos de Uso en las metodologías pesadas, fueron descritas por el Cliente, y servirán para estimar los tiempos de implementación.

Tabla 5. 23: Historias de Usuario SSPS

N.

Historia de Usuario

Iteración

Tiempo de desarrollo

1

Ingreso del Sistema

1

15 horas

2

Registro de Usuarios

1

15 horas

3

Eliminar Usuario

1

5 horas

4

Despliegue y reporte de usuarios

3

7 horas

5

Despliegue y reportes de auditoría de usuarios

3

7 horas

6

Despliegue y reporte de auditoría de procesos

3

5 horas

7

Envío de Emails a usuarios

4

6 horas

8

Recordar tareas de procesos gráficamente y vía Email.

4

12 horas

9

Recuperación de Cuenta vía Email

4

5 horas

10

Ingreso de procesos de licitación

2

5 horas

11

Ingreso de procesos de Cotización

2

5 horas

12

Ingreso de procesos de Menor cuantía

2

5 horas

13

Ingreso de procesos de Subasta Inversa Electrónica

2

5 horas

14

Modificación de procesos de menor cuantía

2

5 horas

15

Modificación de procesos de Licitación

2

5 horas

16

Modificación de procesos de Cotización

2

5 horas

114

17

Modificación de procesos de Subasta Inversa

2

5 horas

18

Eliminación de procesos de menor cuantía

3

2 horas

19

Eliminación de procesos de Licitación

3

2 horas

20

Eliminación de procesos de Cotización

3

2 horas

21

Eliminación de procesos de Subasta Inversa

3

2 horas

22

Consulta y Reportes de procesos Activos

3

5 horas

23

Consulta y Reportes personalizados de procesos.

3

5 horas

24

Notas en el Panel Administrador

3

6 horas

25

Aceptar/ Rechazar Usuario

4

6 horas

26

Auditoría de Usuarios

4

8 horas

27

Auditoría de Procesos

4

8 horas

Fuente: El disertante.

Para mayor información y detalle, revise la última modificación de las historias de Usuario (Ver Anexo 5).

5.1.2.2.4 Velocidad del Proyecto SSPS La velocidad del proyecto se calculó por el número de historias o tareas de programación realizadas por iteración. Para las horas semanales dividimos las semanas de duración del proyecto (valor arbitrario, entre una y cuatro semanas) para las horas (suma de las horas de las historias de usuario por iteración).

Tabla 5. 24: Velocidad y Duración del Proyecto SSPS

Horas

Iteración 1

Iteración 2

Iteración 3

Iteración 4

30,00

40,00

37,00

45,00

115

Semanas

3

4

4

4

Horas Semanales

10

10

9,25

11,25

Historias de Usuario ( Velocidad del Proyecto)

3

8

9

6 Fuente: El Autor.

5.1.2.2.5 Plan de Entregas Se planificó realizar entregas al finalizar cada iteración, las fechas en que se realizaron las entregas, se expresan a continuación en la Tabla 5.13.

Tabla 5. 25: Plan de Entregas SSPS

Iteración

Fecha

Duración (horas)

1era

21 de Abril del 2014

1:02:00

2da

12 de mayo del 2014

1:30:00

3era

9 de Junio del 2014

1:45:00

4ta

7 de Julio del 2014

2:10:00 Fuente: El Autor.

5.1.2.2.6 Reunión inicial del Proyecto XP Se determinaron los roles, en vista de que solo se disponía de un desarrollador, el desarrollador ejerce los roles de Programador, tester y Manager y se definió la planificación para cada rol del equipo de trabajo mediante los diarios, tanto como para el programador, el tester y el manager, los cuales fueron modificados y llevados en forma de bitácora. ( Ver Anexo 6).

116

5.1.2.3 Diseño En XP el diseño se realiza durante todo el proceso de desarrollo, siendo continuamente revisado y a veces modificado, debido a cambios de requerimientos durante el desarrollo.

5.1.2.3.1 Metáfora del Sistema SSPS Como metáforas se emplearon una serie de estándares o buenas prácticas para mejorar la compresión del código.

Tabla 5. 26: Estándares Aplicados en SSPS

Estándar

Descripción

Inicia con Mayúscula

 

Toda Clase Todo Paquete

Inicia con Minúscula

 

Todo Método Toda Variable

Crear comentarios en el código

Genera mejor comprensión del código en VB.NET se define un comentario con “ ’ ”.

Todo código debe estar correctamente identado

   

Se abre una llave en la siguiente línea vacía.

No se escribe nada más en esa línea Se cierra en la misma columna que fue abierto Tampoco se escribe nada en la línea de cierre.

Hora y Fecha



La hora se definirá en formato 24 horas. Ej. 23:00 La fecha se definirá en el formato DD/MM/AAAA



Nombre de Variables

    

Label: lblnombre Textbox: txtnombre Combobox: cbxnombre Picture box: Pcbnombre Botón: btnnombre

117

Base de Datos

  

Tablas: tblnombre Vistas: vwnombre Procedures: SPnombre Fuente: El disertante.

5.1.2.3.2 Tarjetas CRC Las tarjetas CRC fueron de gran ayuda en el diseño, debido a que sirvieron como columna vertebral para la elaboración y sirvieron de base para la elaboración del modelo relacional y la posterior creación de la base de datos. Las tarjetas CRC se definieron a inicios del proyecto y se fueron modificando según las pruebas unitarias. Se realizó una tarjeta CRC por cada entidad.

5.1.2.3.3 Modelado Base de Datos SSPS La base de datos fue modelado en la herramienta MySQL Workbech 6.0, del cual basados en las tarjetas CRS se obtuvo el modelo relacional.

118

Ilustración 5. 9: Modelo Relacional SSPS Fuente: El disertante

Se generaron también procedimientos almacenados en la base de datos (Tabla 5.15).

Tabla 5. 27: Procedimientos Almacenados SSPS

Nombre del Procedimiento

Descripción

SP_ACEPTAR_USUARIO

Procedimiento almacenado que permite aceptar la solicitud de un usuario para pertenecer al sistema.

SP_AUDITAR_USUARIO

Procedimiento almacenado que permite auditar toda operación realizada sobre un usuario.

SP_BUSQ_AUDITORIA

Procedimiento almacenado que permite realizar una búsqueda en la tabla de auditoría de usuarios.

119

SP_BUSQ_AUDITORIAPROC

Procedimiento almacenado que permite realizar una búsqueda en la tabla de auditoría de procesos.

SP_BUSQ_USUARIO

Procedimiento almacenado que permite realizar una búsqueda en la tabla de usuarios.

SP_CREAR_USUARIO

Procedimiento almacenado que permite agregar un registro a la tabla de usuarios.

SP_CUMPLEANIOS

Procedimiento almacenado que permite identificar que usuarios cumplen años en el día.

SP_ELIMINAR_COT

Procedimiento que permite eliminar un proceso de cotización.

SP_ELIMINAR_SIE

Procedimiento almacenado que permite eliminar un proceso de Subasta Inversa Electrónica, este procedimiento se guarda en la auditoría de procesos.

SP_ELIMINAR_USUARIO

Procedimiento almacenado que permite eliminar un Usuario.

SP_ELIMINAR_PROCESO

Procedimiento almacenado que permite eliminar un proceso de la tabla tbl_procesos.

SP_EXTRAER_PROCESOS

Procedimiento almacenado que permite extraer todo los procesos de cada tipo.

SP_INSERTAR_COT

Procedimiento almacenado que permite insertar un proceso de Cotización a su vez lo registra en la tabla auditoria de procesos.

SP_INSERTAR_LIC

Procedimiento almacenado que permite insertar un proceso de Licitación a su vez lo registra en la tabla auditoria de procesos.

SP_INSERTAR_MCUANTIA

Procedimiento almacenado que permite insertar un proceso de Mínima Cuantía a su vez lo registra en la tabla auditoria de procesos.

SP_INSERTAR_SIE

Procedimiento almacenado que permite insertar un proceso de Subasta Inversa Electrónica y a su vez lo registra en la tabla auditoria de procesos.

SP_LISTA_AUDITORIA

Procedimiento almacenado que permite seleccionar todos los registros de la tabla auditoria de usuarios.

SP_LISTA_AUDITORIAPROC

Permite seleccionar todos los registros de la

120

tabla auditoria de procesos.

SP_MOD_COTIZACION

Procedimiento almacenado que permite modificar un proceso de cotización

SP_MOD_ESTILO_USUARIO

Procedimiento almacenado que permite modificar el fondo o diseño del panel de un usuario.

SP_MOD_INGRESO

Procedimiento almacenado que permite modificar la última fecha de ingreso de un usuario al sistema y modifica el estado de la cuenta a activo.

SP_MOD_LICITACION

Procedimiento almacenado que permite modificar un proceso de Licitación

SP_MOD_MENORCUANTIA

Procedimiento almacenado que permite modificar un proceso de Mínima Cuantía.

SP_MOD_PASSWORD_USUARI O

Procedimiento almacenado que permite modificar la actual contraseña de un usuario.

SP_MOD_SALIDA

Procedimiento almacenado que permite modificar el estado de la cuenta de un usuario de activo a desconectado.

SP_MODIFICAR_SIE

Procedimiento almacenado que permite modificar un proceso de Subasta Inversa Electrónica.

SP_SHOWADMINPROCESS

Permite desplegar todos los procesos de Licitación y Cotización.

SP_SHOWADMINPROCESSMC

Permite desplegar todos los procesos de Mínima Cuantía.

SP_SOLICITUDES_USUARIOS

Procedimiento almacenado que permite desplegar las solicitudes de los usuarios para pertenecer al sistema.

SP_USUARIOS_CONECTADOS

Procedimiento almacenado que despliega todos los usuarios que se encuentran conectados al sistema.

SP_USUARIOS_LISTA

Procedimiento almacenado que permite desplegar todos los Usuarios que pertenecen al sistema.

Fuente: El disertante

Para mayor detalle puede revisar el diccionario de datos en el Anexo 7.

121

5.1.2.4 Codificación y pruebas Para la codificación se empleó el lenguaje Visual Basic.NET en el IDE Microsoft Visual Studio.NET, se lo realizó en base a las iteraciones.

Para las pruebas se emplearon las pruebas unitarias constantemente y las pruebas de aceptación al final la iteración. En el anexo 8 puede ver la última prueba realizada.

Se realizó los Manuales de Usuario (Ver Anexo 9) y el Manual Técnico (Ver Anexo 10).

Posterior a ello se entregó el sistema, se firmó un acta de entrega recepción. (Ver Anexo 11).

Ilustración 5. 10: CD de Instalación SSPS Fuente: El disertante

Ilustración 5. 11: Portada del CD de Instalación Fuente: El disertante

122

Ilustración 5. 12: Entrega del Software SSPS al Jefe del Área de Control de Energía Fuente: El disertante

El 28 de Julio del 2014, se realizó una capacitación al personal de compras públicas, a dicha capacitación asistieron 6 personas, las cuales constan registradas en el documento de capacitación de personal (Ver Anexo 12).

123

5.2 Conclusiones De acuerdo a los resultados obtenidos al usar la metodología XP, se concluye que: 

El análisis de los requerimientos funcionales del proyecto permitió obtener información otorgada por el cliente, la cual ayudó a elaborar las historias de usuario, posteriormente mediante el análisis de riesgos y la asignación de prioridades a cada historia, se pudo dividir el desarrollo en iteraciones y calcular la velocidad del proyecto.



El Diseño lógico del sistema ayudó en la descripción de los requerimientos funcionales para resolver los problemas identificados en el previo análisis, obteniendo las tarjetas CRC para sustentar el modelado de la base de datos.



Desde un inicio del proyecto, se efectuó la codificación, empezando por el núcleo y posteriormente los módulos, basándose en el orden de las iteraciones y el uso de estándares para optimizar el código y lograr mejores resultados.



Las pruebas unitarias constantes se utilizaron para verificar que el funcionamiento del sistema sea el esperado.



Instalar el sistema en el espacio de trabajo del cliente facilitó que el cliente pueda probar su funcionalidad,

una vez superada la última iteración, el sistema se

considera terminado y se procede a la elaboración de los manuales de usuario y manual técnico para facilitar la guía del funcionamiento del sistema.

5.3 Límites y Recomendaciones Límites:  El sistema únicamente se podrá instalar y distribuir dentro de CNEL EP SD.  El sistema le pertenece a CNEL EP SD por tanto solo podrá ser utilizado en los bienes de la corporación.

124

Recomendaciones:

 Para confidencialidad de la información, instalar SSPS solo en los computadores de las personas encargadas de dar seguimiento a los procesos del SERCOP.

 El personal encargado de los procesos del SERCOP debe estar pendiente a las notificaciones que llegarán al correo interinstitucional de los responsables a ejecutar tareas, por disposición se enviarán con un día de anticipación.

 Ingresar correctamente la información de los procesos a ejecutar.

 Se recomienda instalar la aplicación SSP_Secretaria en un computador que posea conexión a internet, para que la aplicación pueda enviar los correos electrónicos con la información de los procesos a las personas encargadas.

125

FUENTES DE INFORMACIÓN Bibliográficas o Pineda& Alvarado . (2008). Metodología de la invetigación. Washigton : 3ra edición o Blanco, L. M. (2005). Programación en Visual Basic .NET. Madrid: Eidos. o Carlos Coronel, Steven Morris, Peter Rob. (2011). Bases de Datos, Diseño, Implementación y Administración. Cengage Learning Editores. o Cauca, U. D. (2013). o Cortizo, J., Gil, D., & Ruiz, M. (2008). eXtreme Programming. o Gómez de Silva, A., & Ania Briseño, I. d. (2008). Introducción a la Computación.

Cengage Learning. o Joskowicz, I. J. (2009). Reglas y Prácticas en eXtreme Programming. Madrid. o Joyanes, L. (2008). Fundamentos de Programación. Salamanca, España: Mc Graw. o Kniberg, H. (2008). Scrum and XP from the Trenches. Miami: C4Media Inc. o Mario F. Triola. (2005). Estadística. Pearson Educación. o Pineda & Alvarado. (2009). Metodología de la invetigación. Washigton. o Pressman, R. S. (2010). Software Engineering A Practitioner's Approach. New York: McGraw-Hill. o Rodrigez, R., Encarna, S., & Prieto, Á. (2011). Programación Orientada a Objetos.

México D.F. o Serrano, G. L. (2008). Ingeniería de Sistemas de Software. Publicaciones de ingeniería de Sistemas . o Shamkant B., N., & Ramez, E. (2007). Fundamentos de Sistemas de Bases de Datos.

Madrid: Pearson Educacion.

126

o Sommerville. (2009). Software Engineering. Madrid: PEARSON EDUCACIÓN. o Universidad de Granada. (17 de febrero de 2010). Fundamentos del diseño de base de datos. Granada, Andalucía, España. o Weitenfeld. (2005). Programación orientada a objetos con UML Java e Internet.

Thomson Editorial.

Lincográficas o Microsoft. (2014). Visual Studio. Recuperado el 20 de Julio de 2014, de http://www.visualstudio.com/ o Principios del Manifiesto Ágil. (s.f.). Recuperado el 10 de Julio de 2014, de http://agilemanifesto.org/iso/es/principles.html o www.proyectosagiles.org. (s.f.). Recuperado el 10 de julio de 2014, de http://www.proyectosagiles.org/historia-de-scrum

Hemerográficas o Capgemini, Sogeti, HP. (2013- 2014). Testing in the Agile Development Environment. World Quality Report , 36. o Escuela Politécnica Nacional. (14 de Septiembre de 2013). Servicio Nacional de Contratación Pública. Quito, Pichincha, Ecuador. o Escuela Superior Politécnica de Chimborazo. (4 de Febrero de 2014). Módulo de Contratación Pública. Riobamba, Chimborazo, Ecuador. o Ley Orgánica del SNCP, Nº 395 (Suplemento del Registro Oficial 22 de Julio de 2008).