UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL CONTROL DE CALIDAD. PROYECTO DE TITULACIÓN Previa a la obtención del Título de: INGENIERO EN SISTEMAS COMPUTACIONALES AUTOR: MARÍA ANABELL TINGO BELTRÁN TUTOR: MSc. VIVIANA PINOS MEDRANO GUAYAQUIL – ECUADOR
137
Embed
UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec/bitstream/redug/11622/1/PTG-B-CISC 903 TINGO... · 1. Identificación del Proyecto de Titulación Nombre Alumno: María Anabell Tingo
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA
“FRAMEWORK DE TRABAJO PARA PROYECTOS
DE TITULACIÓN APLICANDO LA METODOLOGÍA
SCRUM EN LA INGENIERÍA DE SOFTWARE”
ENFOCADO EN EL CONTROL DE CALIDAD.
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR: MARÍA ANABELL TINGO BELTRÁN
TUTOR: MSc. VIVIANA PINOS MEDRANO
GUAYAQUIL – ECUADOR
II
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL CONTROL DE CALIDAD.
REVISORES: Ing. Gary Reyes Zambrano e Ing. Janet
Elizabeth Pazmiño Ramírez
INSTITUCIÓN: Universidad de Guayaquil FACULTAD: Ciencias Matemáticas y Físicas
CARRERA: Ingeniería en Sistemas Computacionales
FECHA DE PUBLICACIÓN: Abril del 2016 N° DE PÁGS.: 80
ÁREA TEMÁTICA: Tecnología de Información
PALABRAS CLAVES: Estudio de Factibilidad, Metodología Ágil Scrum, Control de Calidad.
RESUMEN: El objetivo de este proyecto de titulación es realizar un estudio de factibilidad para la propuesta “Framework de trabajo para proyectos de titulación aplicando la metodología ágil Scrum en la ingeniería de software” enfocado en el control de calidad, donde se demuestre la relevancia de contar dentro de un equipo de trabajo con una persona encargada del control de calidad en el desarrollo de un software. Así mismo, a través de la creación del producto ARES del proyecto estudio de factibilidad para la propuesta framework de trabajo para proyectos de titulación aplicando la metodología Scrum, se intenta demostrar la eficacia y validez de la misma frente a otras metodologías de desarrollo de software que ya han sido aplicadas antes en el mismo producto sin haber dado los resultados esperados el cual consiste en la entrega a tiempo y funcional de un sistema web que cumpla a cabalidad todos los requerimientos definidos por los usuarios. Resulta de vital importancia ésta propuesta de tesis puesto que, de obtener los resultados esperados, ésta técnica o metodología de desarrollo de un producto, se impondrá ante las demás en la creación de futuras implementaciones de tesis orientadas al aseguramiento y control de la calidad de un software, además al obtener un producto de calidad se garantizará la satisfacción de todos los beneficiarios que utilizarán dicho producto. Esto será demostrado al aplicar una encuesta dirigida al usuario final donde se determinará el grado de satisfacción e importancia de la calidad de un producto en la comunidad.
N° DE REGISTRO: N° DE CLASIFICACIÓN: Nº
DIRECCIÓN URL:
ADJUNTO PDF SI NO
CONTACTO CON AUTOR: María Anabell Tingo Beltrán TELÉFONO:
En mi calidad de Tutor del trabajo de investigación, ESTUDIO DE
FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO
PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA
SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL
CONTROL DE CALIDAD elaborado por la Sra. MARÍA ANABELL TINGO
BELTRÁN Alumno no titulado de la Carrera de Ingeniería en Sistemas
Computacionales, Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil, previo a la obtención del Título de Ingeniero
en Sistemas Computacionales, me permito declarar que luego de haber
orientado, estudiado y revisado, la Apruebo en todas sus partes.
Atentamente
MSc. VIVIANA PINOS MEDRANO
TUTOR
IV
DEDICATORIA
Quiero dedicar mi trabajo primero a Dios por sus
infinitas bendiciones, por estar siempre a mi lado
y por brindarme la salud necesaria para poder
culminar este proyecto.
A mis padres, hermanos y esposo, pues ellos
forman el pilar fundamental sobre el cual he
podido encontrar refugio en los momentos no tan
buenos de vida y han sido testigos de mis más
grandes alegrías a lo largo de todo este ciclo
universitario convirtiéndose así en mi razón de
perseverancia y esfuerzo para poder alcanzar
todas mis metas en la vida.
V
AGRADECIMIENTO
Quiero agradecer en especial a mis padres
pues sin duda alguna son los responsables de
haber inculcado en mí el deseo de superación en
la vida y sus enseñanzas y ejemplos han logrado
que hoy dé un paso más en mi largo sendero
profesional.
A mi esposo por haber compartido juntos los
buenos y no tan buenos momentos en ésta
etapa de nuestra vida profesional. A Él hoy le
digo…Lo logramos.
VI
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, MSc.
DECANO DE LA FACULTAD CIENCIAS MATEMÁTICAS Y
FÍSICAS
Ing. Inelda Martillo Alcívar, Mgs.
DIRECTORA CARRERA INGENIERÍA EN
SISTEMAS COMPUTACIONALES
Ing. Viviana Pinos Medrano, MSc. TUTORA DEL PROYECTO DE
TITULACIÓN
Ing. Janet Pazmiño Ramírez, MSc. PROFESOR DEL ÁREA MIEMBRO TRIBUNAL
Lcdo. Pablo Alarcón S., MSc. PROFESOR DEL ÁREA
MIEMBRO DEL TRIBUNAL
Ab. Juan Chávez A. SECRETARIO
VII
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”
MARÍA ANABELL TINGO BELTRÁN
VIII
.
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE
TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA
METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE”
ENFOCADO EN EL CONTROL DE CALIDAD
Proyecto de Titulación que se presenta como requisito para optar por el
título de INGENIERO en SISTEMAS COMPUTACIONALES
Autor/a: MARÍA ANABELL TINGO BELTRÁN C.I.0929502029
Tutor: MSc. VIVIANA PINOS MEDRANO
Guayaquil, Diciembre del 2015
IX
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por el/la estudiante MARÍA ANABELL TINGO BELTRÁN, como requisito previo para optar por el título de Ingeniero en Sistemas Computacionales cuyo problema es: ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL CONTROL DE CALIDAD
Considero aprobado el trabajo en su totalidad.
Presentado por:
MARÍA ANABELL TINGO BELTRÁN C.I: 0929502029
Tutor: MSc. VIVIANA PINOS MEDRANO
Guayaquil, Diciembre del 2015
X
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Autorización para Publicación de Proyecto de Titulación en Formato
Digital 1. Identificación del Proyecto de Titulación Nombre Alumno: María Anabell Tingo Beltrán
Dirección: Fertisa Coop. Santiago Roldos Mz. 1375 Sl. 22
Tema del Proyecto de Titulación: Estudio de Factibilidad para la propuesta Framework de Trabajo
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación. Publicación electrónica:
Firma Alumno: María Anabell Tingo Beltrán
3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF.
DVD ROM CD-ROM
Facultad: Ciencias Matemáticas y Físicas
Carrera: Ingeniería en Sistemas Computacionales
Proyecto de titulación al que opta: Ingeniero en Sistemas Computacionales
Profesor guía: MSc. VIVIANA PINOS MEDRANO
Título del Proyecto de titulación: “ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL CONTROL DE CALIDAD
Inmediata X Después de 1 año
XI
ÍNDICE GENERAL
CARTA DE ACEPTACIÓN DEL TUTOR III
DEDICATORIA IV
AGRADECIMIENTO V
TRIBUNAL PROYECTO DE TITULACIÓN VI
DECLARACIÓN EXPRESA VII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR IX
ÍNDICE GENERAL XI
ABREVIATURA XII
SIMBOLOGÍA XIII
ÍNDICE DE GRÁFICOS XIV
ÍNDICE DE CUADROS XVI
RESUMEN XVII
(ABSTRACT) XVIII
INTRODUCCIÓN 1 – 2
CAPÍTULO I – EL PROBLEMA 3 – 11
Ubicación del problema en un contexto 3
Situación conflicto 4
Causa del problema, consecuencia 4
Delimitación del problema 5
Formulación del problema 6
Evaluación del problema 6
Objetivo General 7
Objetivo Específico 7
Alcance del problema 8
Justificación e Importancia 9
Utilidad práctica de la investigación 10
Beneficiarios 10
Metodología del Proyecto 10
CAPÍTULO II- MARCO TEÓRICO 12 – 27
Antecedentes del estudio 12
Fundamentación teórica 13 – 24
Fundamentación legal 24
Pregunta científica a contestarse 26
Definiciones conceptuales 27
CAPÍTULO III – PROPUESTA TECNOLÓGICA 28 – 53
Análisis de factibilidad 28
Etapas de la metodología del proyecto 30
Entregables del proyecto 37
Criterios de validación de la propuesta 37 CAPÍTULO IV – CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO 54
Bibliografías 58
Anexos 60
XII
ABREVIATURAS
UG Universidad de Guayaquil
CISC&N Carrera de Ingeniería en Sistemas Computacionales y
Networking.
FCMF Facultad de Ciencias Matemáticas y Físicas.
MSc. Máster
Ing. Ingeniero
RUP Rational Unified Process
MSF Microsoft Solution Framework
ARES Academic Relation Student
XIII
SIMBOLOGÍA
S Desviación estándar
e Error
E Espacio muestral
E(Y) Esperanza matemática de la v.a. y
s Estimador de la desviación estándar
e Exponencial
XIV
ÍNDICE DE GRÁFICOS
Pág.
GRÁFICO 1 Procesos de Scrum……………………...…………………….…..…………………..11 GRÁFICO 2 Control de Calidad del Software…………………..………….…..………………….13 GRÁFICO 3 Relación entre los modelos de calidad……………………….…..…………………15 GRÁFICO 4 Roles, artefactos y eventos principales de Scrum………….…..………………….19 GRÁFICO 5 Fases o etapas de Scrum………………………………………….......……………..20 GRÁFICO 6 Roles de Scrum……………………………………………………..………………….22 GRÁFICO 7 Proceso de calidad…………………………………………………………………….23
GRÁFICO 8 Resultados de la pregunta 1 de la encuesta (Barra horizontal)………………..…38
GRÁFICO 9 Resultados de la pregunta 1 de la encuesta (Gráficos de anillos)....…………….39
GRÁFICO 10 Resultados de la pregunta 2 de la encuesta (Barra horizontal)……………….…40
GRÁFICO 11 Resultados de la pregunta 2 de la encuesta (Gráficos de anillos)....…………….41
GRÁFICO 12 Resultados de la pregunta 3 de la encuesta (Barra horizontal)...………………..42
GRÁFICO 13 Resultados de la pregunta 3 de la encuesta (Gráficos de anillos)....…………….43
GRÁFICO 14 Resultados de la pregunta 4 de la encuesta (Barra horizontal)………………….44
GRÁFICO 15 Resultados de la pregunta 4 de la encuesta (Gráficos de anillos)....…………….45
XV
GRÁFICO 16 Resultados de la pregunta 5 de la encuesta (Barra horizontal)……………….…46
GRÁFICO 17 Resultados de la pregunta 5 de la encuesta (Gráficos de anillos)....…………….47
GRÁFICO 18 Resultados de la pregunta 6 de la encuesta (Barra horizontal)……………….…48
GRÁFICO 19 Resultados de la pregunta 6 de la encuesta (Gráficos de anillos)....…………….49
GRÁFICO 20 Resultados de la pregunta 7 de la encuesta (Barra horizontal)………………….50
GRÁFICO 21 Resultados de la pregunta 7 de la encuesta (Gráficos de anillos)....…………….51
GRÁFICO 22 Resultados de la pregunta 8 de la encuesta (Barra horizontal)……………….…52
GRÁFICO 23 Resultados de la pregunta 8 de la encuesta (Gráficos de anillos)....…………….53
XVI
ÍNDICE DE CUADROS
Pág.
CUADRO 1 Ranking de “agilidad” (los valores más altos representan una mayor agilidad)...17 CUADRO 2 Diferencias entre metodologías ágiles y no ágiles………...……………………….17 CUADRO 3 Resultados de la pegunta 1 de la encuesta.....……………………………………..38 CUADRO 4 Resultados de la pegunta 2 de la encuesta…..…………………………………….40 CUADRO 5 Resultados de la pegunta 3 de la encuesta…..…………………………………….42 CUADRO 6 Resultados de la pegunta 4 de la encuesta…..…………………………………….44 CUADRO 7 Resultados de la pegunta 5 de la encuesta…..…………………………………….46 CUADRO 8 Resultados de la pegunta 6 de la encuesta…..…………………………………….48
CUADRO 9 Resultados de la pegunta 7 de la encuesta…..…………………………………….50 CUADRO 10 Resultados de la pegunta 8 de la encuesta…………………………………………52 CUADRO 11 Nivel de cumplimiento del proyecto………..…..…………………………………….54
XVII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE
TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA
METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE”
ENFOCADO EN EL CONTROL DE CALIDAD
Resumen El objetivo de este proyecto de titulación es realizar un estudio de factibilidad para la propuesta “Framework de trabajo para proyectos de titulación aplicando la metodología ágil Scrum en la ingeniería de software” enfocado en el control de calidad, donde se demuestre la relevancia de contar dentro de un equipo de trabajo con una persona encargada del control de calidad en el desarrollo de un software. Así mismo, a través de la creación del producto ARES del proyecto estudio de factibilidad para la propuesta framework de trabajo para proyectos de titulación aplicando la metodología Scrum, se intenta demostrar la eficacia y validez de la misma frente a otras metodologías de desarrollo de software que ya han sido aplicadas antes en el mismo producto sin haber dado los resultados esperados el cual consiste en la entrega a tiempo y funcional de un sistema web que cumpla a cabalidad todos los requerimientos definidos por los usuarios. Resulta de vital importancia ésta propuesta de tesis puesto que, de obtener los resultados esperados, ésta técnica o metodología de desarrollo de un producto, se impondrá ante las demás en la creación de futuras implementaciones de tesis orientadas al aseguramiento y control de la calidad de un software, además al obtener un producto de calidad se garantizará la satisfacción de todos los beneficiarios que utilizarán dicho producto. Esto será demostrado al aplicar una encuesta dirigida al usuario final donde se determinará el grado de satisfacción e importancia de la calidad de un producto en la comunidad.
Autor: María Anabell Tingo Beltrán Tutor: MSc. Viviana Pinos Medrano
XVIII
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE
TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA
METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE”
ENFOCADO EN EL CONTROL DE CALIDAD
Abstract The objective of this project is to perform a titration feasibility study for the proposed " Framework of work for titling projects using Scrum agile methodology in software engineering " focused on quality control, where the importance of having within a proven team with a person in charge of quality control in the development of software. Likewise, through product creation ARES project feasibility study for the proposed working framework for projects using the Scrum methodology certification, It is attempting to demonstrate the effectiveness and validity of the same against other methodologies of software development that have already been applied earlier in the same product until the desired results which consists of on-time delivery and functional of a web system that meets fully all the requirements defined by users. It is vital this thesis proposal because, to obtain the expected results, this technique or methodology of product development , will prevail against the other in the creation of future -oriented implementations thesis assurance and quality control of a software , in addition to obtaining a quality product satisfying all beneficiaries who used the product is guaranteed. This will be demonstrated by applying a survey where the end user satisfaction and importance of the quality of a product is determined in the community.
Autor: María Anabell Tingo Beltrán Tutor: MSc. Viviana Pinos Medrano
1
INTRODUCCIÓN
Sin duda alguna, a pesar de que el internet tenga sus inicios en los años
sesenta, fue la aparición de las aplicaciones web a principios de los noventa, lo
que ha logrado que su uso se extienda por todo el mundo. Siendo ese el
principal objetivo de un software resulta imprescindible asegurar la ejecución
exitosa de un determinado proceso dentro de una aplicación web puesto que de
lograrlo, el mismo será catalogado por el usuario como un producto de confiable,
constituyendo así a la calidad en un aspecto importante a controlar durante el
desarrollo de un software.
Sin embargo, la calidad del software se ha convertido hoy en día en una
preocupación a la que se le dedica mucho esfuerzo y dedicación en su estudio e
investigación, principalmente por parte de los fabricantes de servicios
informáticos al tener éstas fábricas de software como propósito principal originar
y entregar un producto de la mejor calidad posible que cumpla las expectativas
de todos los usuarios. Las conclusiones derivadas de dichos estudios nos llevan
a determinar de que la obtención de un software de calidad implica el uso de
adecuadas metodologías en su desarrollo que incluyan dentro de su proceso el
rol de un tester el cual se encargue del control y aseguramiento de su calidad.
Todas estas razones nos conducen a afirmar que las constantes críticas y
descontentos de anteriores proyectos, son producidas por la falta de control de
calidad durante el desarrollo del mismo a consecuencia del desuso de una
metodología la cual tenga como parte de sus objetivos principales el
aseguramiento de la calidad del producto no solo al finalizarlo sino durante todo
el ciclo de vida de su desarrollo. Por tal motivo es que surge la necesidad de
desarrollar el producto ARES el cual abarque todos los índices de calidad que el
mismo debería tener para que permita a los estudiantes gozar de procesos
automatizados que le otorguen al usuario una experiencia mejorada y sobre todo
de calidad.
2
El actual proyecto de titulación se enfoca en el estudio de factibilidad para la
propuesta “Framework de trabajo para proyectos de titulación aplicando la
metodología Scrum” orientado al control de calidad en la creación del producto
ARES al cual podrán acceder estudiantes, docentes, y personal administrativo
pertenecientes a una institución de educación superior. Como premisa para esta
propuesta de titulación se tiene el conocimiento de que ya se han creado antes
un similar el cual proveía de diversos servicios de índole académico, el mismo
que se desea reemplazar con el producto que esta propuesta de tesis generará.
La realización de este proyecto de titulación, se basará en el uso de técnicas y
herramientas necesarias que permitan obtener el software de calidad que se
espera tener.
El presente proyecto de titulación se encuentra dividido en cuatro capítulos, los
mismos que se resumen en los posteriores cuatro párrafos y que fueron
estructurados utilizando el método científico:
El capítulo I, en este capítulo se describe el problema existente dentro de un
contexto, cuál es la situación conflicto, cuáles son las causas del problema y las
consecuencias de seguir manteniéndose, se describe la delimitación del
problema y su planteamiento, cuáles son los objetivos de la investigación, su
alcance y la justificación del problema.
El capítulo II, en este capítulo se elabora el marco referencial, el marco
conceptual; el mismo que hace referencia a fuentes bibliográficas sobre los
temas tratados en el estudio. Lo que permitirá establecer las palabras claves
involucradas en el mismo, la fundamentación legal en la que se apoya la
propuesta y constan las preguntas científicas y las variables con respecto al
estudio.
El capítulo III, en este capítulo se describe la metodología a utilizar y se realiza
un análisis de factibilidad de la propuesta que se plantea en el presente proyecto
de titulación.
El capítulo IV, en este capítulo constan los resultados, establecidos una vez que
se haya analizado y concluido el estudio del problema existente, además sirven
como respaldo para este estudio las referencias bibliográficas utilizadas con los
anexos correspondientes.
3
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del Problema en un Contexto
A la fecha, se conoce que se han desarrollado varios productos similares al que
el estudio de factibilidad para la propuesta “Framework de trabajo para proyectos
de titulación aplicando la metodología Scrum”, generará. Estos productos han
sido puestos en marcha en distintas instituciones educativas de nivel superior y
al consumo de sus usuarios con muchas de sus opciones o módulos que lo
conforman no funcionales y con graves problemas de estabilidad en producción.
La ausencia de un adecuado control de calidad en el desarrollo de un software
desencadena la puesta en producción de un producto sin las mínimas
precauciones de aseguramiento de garantía, generando así entre los
estudiantes, principales usuarios de estos sistemas, molestias por el retraso y en
muchas ocasiones fallas que se generan en las distintas transacciones, puesto
que, el tener aplicaciones web funcionalmente inestable originará procesos
fallidos los cuales pueden ir, para el caso de productos académicos, desde
pequeñas transacciones como la consulta de notas de un estudiante hasta
grandes fallas como el no permitirle al alumno matricularse a tiempo porque el
sistema no se encontraba en línea.
En consecuencia el estudio de factibilidad para la propuesta “Framework de
trabajo para proyectos de titulación aplicando la metodología Scrum”, se
encargará de demostrar la importancia de aplicar un adecuado control de calidad
en el desarrollo del producto ARES.
4
Situación Conflicto Nudos Críticos
El uso de metodologías de desarrollo de software que se han aplicado en la
implementación de anteriores productos como el que se creará para ésta
propuesta de tesis, donde no se la da suficiente importancia al rol de tester
dentro del equipo de trabajo del proyecto, persona encargada netamente de
controlar la calidad del software que se está desarrollando, genera grandes
problemas al momento de contar con el producto en producción, puesto que, al
no haberse asegurado antes la calidad del software se incurre en procesos
incorrectos cuando el usuario lo está usando.
En relación con las implicaciones descritas anteriormente, es importante acotar
que las metodologías tradicionales de desarrollo de software que se han usado,
sostienen que la calidad se asegura una vez terminado el software, pues lo único
que han originado es fracasar en la detección a tiempo de errores que impidan
incurrir o faltar a otro aspecto importante de la calidad del software que es la
entrega a tiempo del producto. También es significativo mencionar, que muchas
veces la calidad del mismo no puede ser la mejor, debido al mal estado de los
equipos donde se publica el software y lo que impide que pueda ser usado por
los estudiantes universitarios.
Causas y Consecuencias del Problema
Causas
No contar con un plan de pruebas antes del desarrollo de una funcionalidad
específica.
La poca importancia que se le otorga al rol de tester dentro del equipo de
trabajo.
No contemplar las tareas que realizará el tester dentro de la planificación del
proyecto en cuanto a tiempos y fechas de entrega.
5
No realizar el control de calidad durante el desarrollo del producto.
Consecuencias
Empezar un desarrollo sin conocer los criterios de aceptación de una tarea
incurre en la entrega de un producto que no se apega a las necesidades del
usuario final.
Considerar no necesario o poco relevante el trabajo de control de calidad que
pueda realizar una persona o un grupo de personas traerá como
consecuencia la entrega al público de un producto sin las mínimas garantías
de que el mismo cubrirá todas las expectativas del usuario final.
Si no se destina un tiempo prudente para la realización de pruebas el
producto caerá en la entrega tardía, puesto que la calidad es algo que no se
puede pasar por alto al momento de su entrega.
Sin duda alguna el aseguramiento tardío de la calidad del software nos dará
más trabajo al final del mismo, puesto que no se está detectando fallas a
corto tiempo sino una vez que se ha culminado el proyecto: Un error que de
ninguna manera se debe dejar de tomar en consideración.
Delimitación del Problema
Campo: Educación e Investigación
Área: Tecnologías de la Información
Aspecto: Estudio de Factibilidad
Tema: Estudio de Factibilidad para la Propuesta “Framework de Trabajo para
Proyectos de Titulación, aplicando la Metodología SCRUM en la Ingeniería de
Software” Enfocado en el Control de Calidad.
6
Formulación del Problema
¿Para garantizar la entrega de un producto, el cual para ésta propuesta de tesis
es la creación del producto ARES, que cumpla o supere las expectativas de los
usuarios, es necesario hacer uso de una metodología de desarrollo de software
que incluya dentro de su proceso a una persona encargada del control y
aseguramiento de la calidad del mismo?
Evaluación del Problema
Con el objetivo de evaluar la problemática planteada en este proyecto de
titulación, a continuación se detallan seis aspectos que están inmersos en el
presente estudio y que permiten evaluar el problema:
Delimitado: El estudio de factibilidad para la propuesta “Framework de trabajo
para proyectos de titulación aplicando la metodología Scrum” creará el producto
ARES para lo cual se necesita que se controle su calidad durante todo el ciclo
de vida de su desarrollo con el fin de garantizarle al usuario un producto que
cumpla y llene todas sus necesidades.
Claro: Se ha planteado directamente las causas y consecuencias de la
problemática dando a conocer la importancia de efectuar un adecuado control de
calidad del software.
Concreto: El problema que se plantea en este proyecto de titulación y posterior
detalle de la solución ideada para el mismo el cual también se encuentra en este
mismo proyecto de titulación, son redactados de manera que su lectura y
comprensión resulte ser corta, precisa, directa y adecuada para el lector
otorgándole así una experiencia satisfactoria al ser todo su contenido concreto y
preciso.
7
Relevante: Resulta prioritario para la comunidad universitaria contar con un
sistema académico que les brinde las garantías de calidad necesarias que el
producto debe tener, ésta satisfacción será confirmada luego de efectuarse
diversas encuestas entre los usuarios.
Original: El control de calidad en el desarrollo del producto ARES será
elaborado y ejecutado aplicando la metodología ágil SCRUM, la misma que no
ha sido probada ni estudiada antes en el desarrollo de ningún proyecto de
titulación demostrando así su originalidad y factibilidad.
Factible: La posibilidad de resolver la problemática resulta ser factible en
cuanto a tiempo de resolución y recursos que se usarán.
OBJETIVOS
Objetivo General
Verificar la calidad en el desarrollo del producto ARES que se usará como objeto
de estudio de factibilidad de la metodología ágil SCRUM en la ingeniería de
software para garantizar la entrega de un producto de calidad.
Objetivos Específicos
Elaborar instrumentos donde se reconozcan las distintas pruebas que se le
aplicará al producto ARES, el mismo que está conformado por seis sprints.
Recopilar documentación para elaborar pruebas unitarias, las cuales
consisten en la realización de QUERIES y store PROCEDURE, usando el
sistema de gestión de base de datos SQL Server 2014, y servicios web a
través de la aplicación SOAP UI. Estas pruebas se aplicarán a cada uno de
los seis sprints.
8
Elegir documentación para elaborar pruebas funcionales o integrales, las
cuales consisten en la preparación y posterior ejecución de casos de prueba,
las mismas que determinarán si una característica de la aplicación es
completamente satisfactoria. Estas pruebas se aplicarán a cada uno de los
seis sprints.
Seleccionar documentación para preparar pruebas de estrés, la cuales
consisten en la elaboración de pruebas de rendimiento sobre la aplicación
web usando la herramienta Jmeter.
Generar informes del control de calidad aplicado al producto ARES.
ALCANCES DEL PROBLEMA
Para la aplicación de pruebas unitarias se hará uso de la ejecución de
queries y store Procedure utilizando la herramienta de desarrollo de software
SQL Server 2014 conforme los seis sprints aprobados para este proyecto de
titulación.
Se aplicarán pruebas unitarias a los distintos servicios web que se
desarrollen haciendo uso de la herramienta de software Soap UI.
Para la aplicación de pruebas funcionales se elaborarán y ejecutarán los
casos de pruebas necesarias conforme los seis sprints aprobados para este
proyecto de titulación.
Para la aplicación de pruebas de estrés se someterá el producto ARES al
uso de la herramienta de software Jmeter.
9
JUSTIFICACIÓN E IMPORTANCIA
El presente proyecto de titulación el cual tiene como objetivo realizar un estudio
de factibilidad para la propuesta “Framework de trabajo para proyectos de
titulación aplicando la metodología Scrum en la ingeniería de software”
enfocado en el control de calidad, justifica su elaboración al demostrar la
relevancia de asegurar y controlar la calidad del software durante su
elaboración a través de la entrega del producto ARES.
Con referencia a lo anterior, se puede deducir que el propósito de esta
propuesta de tesis se basa en asegurar y controlar la calidad de un producto,
para lo cual se utilizará la metodología ágil Scrum como técnica que ayudará a
cumplir dicho propósito. Lograr que el producto ARES llene todas las
expectativas funcionales que los usuarios esperan obtener, justificará el
desarrollo de ésta tesis.
Con base a lo anterior, podemos citar que resulta importante garantizar la
calidad y buen desempeño del producto ARES el mismo que se obtendrá del
estudio de factibilidad “Framework de trabajo para proyectos de titulación
aplicando la metodología Scrum”, ya que será usado para dar servicio de índole
académico a miles de estudiantes y personal administrativo, por ende sus
procesos deberán ser completamente satisfactorios para sus usuarios.
En consecuencia, sin un tester dentro del equipo de trabajo de desarrollo de
software, encargándose del monitoreo continuo de la calidad del producto, el
cual para este estudio nos referimos al producto ARES, y asegurando que los
requerimientos del usuario se plasman en el mismo, el proyecto simplemente
fracasaría, pues se estaría entregando a la población estudiantil y
administrativa un producto que no cumple siquiera con los procesos básicos a
realizar en una institución de educación superior.
10
UTILIDAD PRÁCTICA DE LA INVESTIGACIÓN
La utilidad práctica que contribuye este proyecto de investigación, es el estudio
de factibilidad donde se pueda demostrar la importancia de un adecuado control
de calidad, exaltando el rol fundamental que tiene el tester y lo necesario de
contar con un plan de pruebas previo al desarrollo del producto ARES el cual lo
generará el estudio de factibilidad “Framework de trabajo para proyectos de
titulación aplicando la metodología Scrum”, y de esa manera poder convertir
dicha metodología en la favorita por los directores de futuras implementaciones
de software planteados en los proyectos de titulación.
Beneficiarios
Para el producto ARES se tiene inicialmente como principales beneficiarios a
toda la comunidad estudiantil pertenecientes a instituciones de educación
superior, como base de desarrollo del proyecto está la comunidad universitaria
de la Universidad de Guayaquil.
Metodología del Proyecto
Metodología de desarrollo:
Para la elaboración de este proyecto de titulación se aplicará la metodología
ágil SCRUM. Esta propuesta consiste en el aseguramiento de la calidad del
producto ARES mediante la elaboración y ejecución de pruebas unitarias,
funcionales y de estrés conforme los seis sprints aprobados para esta
propuesta de titulación.
Supuestos:
Se ejecutarán distintos tipos de pruebas al producto ARES los mismos
que se detallan en los objetivos específicos descritos en el presente
capítulo.
Una vez que todas las pruebas de un determinado sprint hayan sido
11
finalizadas con éxito se procederá a realizar las pruebas del siguiente
sprint.
Se redactará un informe el cual será entregado al Project Manager
donde se detallarán todas las fallas y mejores, en caso de haberlas,
para su respectivo análisis y conclusión.
Restricciones:
El tester no ejecutará ningún tipo de pruebas en ambiente de producción. Estas
pruebas son realizadas por el Project Manager junto con el director de tesis y
solo en caso de requerir la ayuda del tester, éste último, colaborará con
revisiones en dicho ambiente.
GRÁFICO N° 1 PROCESOS SCRUM
Fuente: Presentación del proyecto de titulación
Elaboración: Anabell Tingo Beltrán
La imagen anterior nos describe a rasgos generales los procesos que se llevan a
cabo al aplicar en un proyecto de desarrollo de software la metodología ágil
Scrum para lograr obtener módulos completamente funcionales al servicio del
usuario final.
12
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
Durante mucho tiempo las metodologías tradicionales de software caracterizadas
por ser muy rígidas y cerradas en sus conceptos, resultaron ser la única técnica
a utilizarse en el desarrollo de un software. El uso de este tipo de metodología
donde se prima la extensa documentación y complejos procesos, tal es el caso
de las muy conocidas RUP y MSF, resultaban en el incumplimiento de la fecha
de entrega del producto principalmente por la detección tardía de errores durante
su desarrollo y a esto es preciso añadir los elevados costos de necesitar realizar
un cambio de funcionalidad en el mismo.
Con base a lo descrito anteriormente y tras tener el conocimiento de la creación
de productos similares previo al que se desarrollará en este proyecto de
titulación, se puede evidenciar claramente que esto ha provocado preocupación
entre los responsables a cargo de dichos proyectos, debido a los retrasos en el
cumplimiento de entrega de aquellos productos y posterior a eso el descontento
de los usuarios al comenzar a utilizarlo, ya que son catalogados como sistemas
que no satisfacen completamente las necesidades de los usuarios y más bien los
retrasan en sus actividades al fallar constantemente los procesos implementados
en el mismo.
Con esta premisa, se analiza y se concluye que el fracaso en el desarrollo de
productos de software tiene sus problemas y se fundamenta en la falta o poca
importancia de aplicar o considerar un adecuado control y aseguramiento de la
calidad del mismo antes de ponerlo al servicio de la comunidad de todos sus
usuarios sin siquiera garantizar que el producto cumple con los índices mínimos
de calidad.
13
FUNDAMENTACIÓN TEÓRICA
Uno de los principales problemas con los que hoy en día todos los involucrados
en el mundo del desarrollo de software deben lidiar, sin duda alguna es la
calidad del producto final. Este tema se ha convertido en motivo de preocupación
no solo para los usuarios sino también para especialistas, ingenieros,
investigadores, comercializadores y fábricas de software que se han visto en la
necesidad de realizar análisis e investigaciones exhaustivas con el principal
objetivo de encontrar respuesta a las siguientes interrogantes: cómo obtener un
software de calidad y cómo evaluar la calidad del mismo.
La calidad del software se refiere al conjunto de características y funciones que
posee dicho software, el cual debe cumplir y satisfacer al cien por ciento las
necesidades y requerimientos definidos al inicio del proyecto por el usuario final.
En este aspecto (Calero, Moraga y Piattini, 2010:49) nos dice:
14
La calidad de software es de risa. Por supuesto no suscribimos esta sentencia, pero también está claro que hay mucho camino que recorrer hasta lograr la satisfacción del cliente o el usuario final. La calidad, sea de software o de cualquier otra cosa, requiere una visión integral. Algo bueno sólo en parte, no es muy satisfactorio. La percepción de calidad en la experiencia de uso del software no depende sólo del producto. El entorno (sistema) en que se ejecuta es igual de determinante. A su vez, la calidad del producto software es en función de los procesos que lo han generado y la calidad del sistema es en función de su buen algoritmo.
En cuanto a la cita anterior, el autor hace énfasis en lograr la calidad total y no
solo parcial del producto que se está desarrollando ya que asegura que es
determinante para lograr la satisfacción del cliente. Es importante mencionar que
la calidad es sinónimo de usabilidad, eficiencia, flexibilidad, seguridad e
integridad por ende, no está de más mencionar que dichas características
deberían estar inmersas en el producto final puesto que se encuentra
implícitamente involucrada dentro de la calidad del software.
Cabe destacar, en cuanto a este tema, lo que (Calero, Moraga y Piattini,
2010:55) cita en su libro acerca de la serie ISO/IEC 25000 (SQuaRe: Software
Quality Requirements, Requisitos y Evaluación de la calidad de productos
Software) ISO/IEC 25000 (2009), lo cual debe ser citado por su grado de
relevancia dentro de este capítulo:
Esta serie de estándares interpretan la calidad de un sistema software como el grado en el que el sistema satisface las necesidades implícitas y explícitas de sus diferentes usuarios (stakeholders). Estas necesidades se representan dentro de SQuaRe en diferentes modelos: el modelo de calidad del producto software, el modelo de calidad de datos y el modelo de calidad en uso del sistema.
Dicho de otra manera, el autor claramente establece o define tres modelos de
calidad, todos enfocados a llenar las expectativas y necesidades de los usuarios.
15
GRÁFICO N° 3 RELACIÓN ENTRE LOS MODELOS DE CALIDAD
Fuente: Calidad del producto y proceso software (Coral Calero, Ma. Ángeles Moraga y Mario Piattini)
Elaboración: Anabell Tingo Beltrán
La imagen anterior demuestra la relación entre los modelos de calidad de
producto software, el modelo de calidad de datos y el modelo de calidad en uso,
definidos en la serie ISO/IEC 25000 (2009). Por último, (Pressman, 2002) señala
lo siguiente en cuanto a la calidad del software:
Es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente.
Cabe señalar que en la cita descrita anteriormente, el autor claramente relaciona
los requerimientos funcionales alineados a las necesidades de sus usuarios, los
estándares de desarrollo que un software de nivel profesional debe tener y las
características del producto considerando aquí ese valor agregado que
sorprenda al usuario, con la calidad que el mismo debería poseer, lo que lo
convertirá sin duda alguna en un producto diferenciado entre los demás por su
alto nivel de calidad.
16
LAS METODOLOGÍAS ÁGILES COMO GARANTÍA DE
CALIDAD DEL SOFTWARE
Sin duda, las metodologías ágiles usadas en el desarrollo de software, tienen
como enfoque primordial entregar mayor valor al cliente, es decir, satisfacer sus
necesidades ofreciéndole un software funcional que cumple todas sus
expectativas. Adicional, se desarrolla software con rapidez y logran responder a
los cambios que puedan aparecer durante todo el ciclo de vida del proyecto.
Mientras que, las metodologías tradicionales fijan un alcance a desarrollar, en un
determinado tiempo de duración y con un costo ya definido lo que produce que
ante cualquier problema que se suscite durante el desarrollo del producto se
obtenga como resultado la disminución de la calidad en el producto final. Esto a
causa de las prisas por terminar en el plazo establecido o por no superar el
presupuesto estimado al inicio del proyecto.
Definición de metodología ágil:
La metodología ágil, usada en el desarrollo de un producto o servicio cuyo
propósito primordial es la entrega temprano de pequeñas partes del producto
final pero completamente funcional, nace como oposición a las metodologías
tradicionales, las cuales se caracterizan por su rigidez, complejos procesos a
seguir en su metodología y por la extensa documentación que se genera a partir
de cada una de las actividades que se desarrolla.
Por su parte, las metodologías ágiles, buscan integrar la calidad al proceso de
desarrollo con el único objetivo de generar satisfacción en el cliente al cumplir
sus expectativas y en muchos de los casos sobrepasando las mismas al
entregarle esa característica extra lo que le permitirá diferenciarse de sus
similares.
17
CUADRO N° 1 RANKING DE “AGILIDAD” (LOS VALORES MÁS ALTOS
En la metodología ágil Scrum se hacen presentes los siguientes roles:
Product Owner.- Dentro del equipo de trabajo, el product owner es la
persona que realmente conoce el negocio la cual aportará resolviendo las
dudas en cuanto a los requerimientos funcionales del producto.
21
Scrum Master.- Dentro del equipo de trabajo Scrum, el Scrum master es la
persona encargada de comprobar que la metodología que se está aplicando
para la elaboración del producto realmente funciona.
Equipo de Desarrollo.- Es un grupo de personas que tienen autoridad para
organizar y tomar decisiones con el único fin de conseguir su objetivo.
También se encuentran involucrados en la estimación del esfuerzo de cada
de las tareas que integran el backlog las mismas que conformarán al final del
proyecto el producto deseado por los usuarios.
Tester.- Es la persona o grupo de personas que se encargan del control y
aseguramiento de la calidad del producto durante su desarrollo detectando
así errores de funcionalidad tempranamente.
SVN.- Es la persona o grupo de personas que se encargan del control de
versiones del producto se está desarrollando. Su misión principal es
mantener en línea siempre el sistema.
Infraestructura.- Es la persona o grupo de personas encargadas de proveer
a todo el equipo de trabajo Scrum de las herramientas necesarias para el
desarrollo del software.
Usuarios.- Es el destinatario del producto. Él es el cliente, las personas
quienes usarán el producto por ende el mismo debe cubrir sus necesidades
el cual se constituye en motivo de su elaboración.
Stakeholders.- Son las personas encargadas de participar durante las
revisiones de cada sprint, puesto que son las personas a las que el producto
les generará beneficios.
Project Manager.- Es la persona dentro del esquipo de trabajo a cargo de
tomar decisiones finales en cuanto a definiciones de usuario y siempre es
participe en la selección de los objetivos y requisitos teniendo en cuenta
como prioridad beneficiar a los usuarios.
22
GRÁFICO N° 6 ROLES DE SCRUM
Fuente: Grupo del presente Proyecto de Titulación Elaboración: Anabell Tingo Beltrán
Eventos definidos en Scrum:
Las acciones por las que atraviesa un proceso Scrum son:
Sprint.- Un sprint es utilizado para cumplir los objetivos definidos en él, para
generar productos y también para analizar entre el proceso.
Sprint Planning.- Es una reunión donde se define como objetivo extraer los
requerimientos del cliente y planificar que artefactos serán entregados y
como se construirán.
Daily Scrum.- Es una reunión corta donde el equipo de desarrollo coordina y
planea su siguiente día de trabajo, también se comunicarán los avances y
dificultades.
Sprint Review.- Es una reunión en la que se analiza el avance del producto
creado y se adecúa el product backlog para el siguiente Sprint.
23
Proceso de calidad aplicado en el producto ARES
GRÁFICO N° 7 PROCESO DE CALIDAD
Fuente: Proyecto de Titulación Elaboración: Anabell Tingo Beltrán
De acuerdo al gráfico anterior, el flujo inicia con la aprobación por parte del
Project Manager del equipo Scrum para iniciar con el proceso de pruebas.
A continuación, se elaboran y aplican al software pruebas unitarias (SQL server
2015, Soap UI), pruebas funcionales (casos de pruebas) y pruebas de estrés
(Jmeter), conforme los criterios de aceptación detallados en cada una de las
historias de usuarios que conforman un sprint. Luego de ejecutadas las pruebas,
se elabora un documento con los resultados obtenidos el cual es enviado al
Project Manager. Si en el documento existen observaciones de fondo, es decir,
módulos no funcionales, el Project Manager convertirá dichas observaciones en
historias de usuario las mismas que deberán ser atendidas inmediatamente por
el equipo de desarrollo y una vez solucionadas darán aviso al Project Manager el
24
cual a su vez dará la aprobación al tester para ejecutar nuevamente las pruebas,
es decir, inicia nuevamente el flujo de control de calidad.
En caso de encontrarse con observaciones de forma, es decir, temas de diseño
u optimización de procesos que no afectan la funcionalidad esperada del
software, el Project Manager convertirá dichas observaciones en historias de
usuarios para sprints posteriores y con esto finalizará el proceso de control de
calidad. Lo que acontecerá posterior al control de calidad, es la versión del
software por parte del SVN, el cual inicia al igual que el proceso de calidad con la
aprobación por parte del Project Manager.
Para finalizar, es preciso citar lo que mencionan los autores (García León y
Beltrán Benavides, 1995) en cuanto al control de calidad:
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Lo anteriormente expuesto por los autores nos da la seguridad de que efectuar
un control de calidad sí es factible y realizable, y lo fundamentan citando que es
la conclusión de varios autores. Entonces nos mencionan que tras un adecuado
aseguramiento de la calidad del producto, es posible obtener que dicho producto
abarque todas las necesidades funcionales de sus usuarios.
FUNDAMENTACIÓN LEGAL
Constitución de la República del Ecuador
Art. 350.- “El sistema de educación superior tiene como finalidad la formación
académica y profesional con visión científica y humanista; la investigación
científica y tecnológica; la innovación, promoción, desarrollo y difusión de los
25
saberes y las culturas; la construcción de soluciones para los problemas del
país, en relación con los objetivos del régimen de desarrollo.”
Ley de Propiedad Intelectual
Art. 29.- “Es titular de un programa de ordenador, el productor, esto es la
persona natural o jurídica que tome la iniciativa y responsabilidad de la
realización de la obra. Se considera titular, salvo prueba en contrario, a la
persona cuyo nombre conste en la obra o sus copias de la forma usual. Dicho
titular está además legitimado para ejercer en nombre propio los derechos
morales sobre la obra, incluyendo la facultad para decidir sobre su divulgación.
El productor tendrá el derecho exclusivo de realizar, autorizar o prohibir la
realización de modificaciones o versiones sucesivas del programa, y de
programas derivados del mismo. Las disposiciones del presente artículo podrán
ser modificadas mediante acuerdo entre los autores y el productor.”
Reglamento a la ley de comercio electrónico, firmas electrónicas y
mensajes de datos
Art. 1.- “Objeto de la Ley.- Esta Ley regula los mensajes de datos, la firma
electrónica, Los servicios de certificación, la contratación electrónica y
telemática, la prestación de Servicios electrónicos, a través de redes de
información, incluido el comercio Electrónico y la protección a los usuarios de
estos sistemas.”
Art. 4.- “Propiedad Intelectual.- Los mensajes de datos estarán sometidos a las
leyes, Reglamentos y acuerdos internacionales relativos a la propiedad
intelectual.”
Art. 5.- “Confidencialidad y reserva.- Se establecen los principios de
confidencialidad y reserva para los mensajes de datos, cualquiera sea su forma,
26
medio o intención. Toda violación a estos principios, principalmente aquellas
referidas a la intrusión electrónica, transferencia ilegal de mensajes de o
violación del secreto profesional, será sancionada conforme a lo dispuesto en
esta Ley y demás normas que rigen la materia.”
Art. 9.- “Protección de datos.- Para la elaboración, transferencia o utilización de
bases de datos, obtenidas directa o indirectamente del uso o transmisión de
mensajes de datos, se requerirá el consentimiento expreso del titular de éstos,
quien podrá seleccionar la información a compartirse con terceros. La
recopilación y uso de datos personales responderá a los derechos de privacidad,
intimidad y confidencialidad garantizados por la Constitución Política de la
República y esta Ley, los cuales podrán ser utilizados o transferidos únicamente
con autorización del titular u orden de autoridad competente.
No será preciso el consentimiento para recopilar datos personales de
fuentes accesibles al público, cuando se recojan para el ejercicio de las
funciones propias de la administración pública, en el ámbito de su competencia,
y cuando se refieran a personas vinculadas por una relación de negocios,
laboral, administrativa o contractual y sean necesarios para el mantenimiento
de las relaciones o para el cumplimiento del contrato. El consentimiento a que
se refiere este artículo podrá ser revocado a criterio del titular de los datos; la
revocatoria no tendrá en ningún caso efecto retroactivo.”
PREGUNTA CIENTÍFICA A CONTESTARSE
Para la elaboración del presente proyecto de titulación se planteó la siguiente
interrogante:
¿El verificar la calidad del producto, ayudará al grupo de estudiantes que
integran el presente proyecto de titulación, a desarrollar el producto ARES dentro
de los parámetros de calidad que debería tener para beneficio de los estudiantes
y personal administrativo de instituciones educativas de educación superior?
27
DEFINICIONES CONCEPTUALES
Tester: Persona o grupo de personas dentro del equipo de trabajo de Scrum
encargadas del control de calidad del software (Testing). Será el responsable de
garantizar y asegurar que el producto final se alinea a los requerimientos del
usuario final.
Control de calidad: Se refiere a los diferentes tipos de pruebas al que es
sometido el software o cualquier otro tipo de producto por parte del tester con el
fin de asegurar su correcto funcionamiento.
Entrega de valor: Se entrega valor cuando se le da al cliente una versión del
producto completamente funcional. La usabilidad le proporcione al cliente deberá
ser del 100%.
Entregable: Un entregable es una parte funcional del software o versión, la
cual dentro de la metodología Scrum es conocida como sprint.
Garantía de calidad: Es cuando el tester asegura el correcto funcionamiento
del software que se está creando.
Scrum: Es una metodología ágil de desarrollo de software la cual tiene como
objetivo principal la entrega de valor al cliente al proporcionarle versiones del
producto final netamente funcionales y usables.
Sprint: Un sprint es el conjunto de historias de usuarios la cuales constituirán
un entregable funcional para el cliente.
Historia de usuario: Una historia de usuario comprende todos los
requerimientos del usuario final. Aquí se detallan también los criterios de
aceptación para cada tarea los mismos que permitirán medir el cumplimiento de
la misma.
28
CAPÍTULO III
PROPUESTA TECNOLÓGICA
El objetivo principal de esta propuesta de titulación es garantizar la calidad del
producto que el grupo de desarrollo creará con el único fin de poner en marcha
el proyecto en el ambiente de producción para que pueda ser usado por el
usuario final.
Análisis de factibilidad
Este proyecto se considera factible debido a que es necesario para que el grupo
de desarrollo pueda ponerlo en ejecución en un ambiente de producción y así
poder determinar si el producto ARES desarrollado usando Scrum como
metodología se considera un éxito o fracaso versus a las metodologías
tradicionales de desarrollo de software.
Factibilidad Operacional
El resultado del control de calidad que se le aplique al software que se está
desarrollando será cien por ciento utilizado tanto por el equipo de desarrollo para
corregir fallas en caso de haberlas como para el líder del proyecto, puesto que,
éste último podrá garantizarle a los directores del proyecto que el sistema se
encuentra totalmente funcional en producción.
Existe el compromiso por parte del equipo de desarrollo en el proceso de Testing
para proveer de la data suficiente al momento de ejecución de las pruebas. Así
mismo del líder del proyecto prestará su ayuda para aclarar dudas en cuanto a
29
los criterios de aceptación de cada uno de los sprints que conforman esta
propuesta.
Factibilidad Técnica
Este proyecto de titulación es técnicamente factible puesto que en cuanto a
software se cuentan con las herramientas necesarias para poder elaborar y
ejecutar los distintos controles al sistema web, lo que nos permitirá asegurar la
calidad del mismo.
En cuanto a hardware, se cuenta dentro del equipo de trabajo de este proyecto
de titulación, con un grupo de personas altamente capacitadas en el tema de
infraestructura. El equipo de infraestructura nos proveerá de ambientes de
desarrollo y producción altamente estables y operacionales donde se podrán
ejecutar las pruebas sin inconvenientes técnicos.
Factibilidad Legal
El presente proyecto de titulación se encuentra al cien por ciento dentro del
marco legal. Sin embargo, para evitar inconvenientes a futuro es recomendable
adquirir licencias de las herramientas de software que se usarán en caso de
necesitarlo.
Factibilidad Económica
Para este proyecto de titulación se utilizarán herramientas de software de ayuda
en el proceso del control de calidad, las mismas que son descargadas de
internet sin costo alguno y dentro del marco legal.
Por tal motivo esta propuesta de titulación es también considerada
económicamente factible para su elaboración.
30
Etapas de la metodología del proyecto
El presente proyecto de titulación se desarrolla en seis sprints dentro de la
metodología ágil Scrum, los mismos que van desde el sprint cero hasta el sprint
cinco, los cuales son detallados a continuación:
Tareas del Sprint 0
Elaboración de formatos para registrar las distintas pruebas que se
realizarán en el software.
Revisión de herramientas y técnicas que se usarán en la elaboración y
ejecución de pruebas.
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 1.
Tareas del Sprint 1
Elaboración de formatos para registrar las distintas pruebas que se
realizarán en el software.
Revisión de herramientas y técnicas que se usarán en la elaboración y
ejecución de pruebas.
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 1.
Elaboración del plan de pruebas unitarias que se aplicarán al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 1.
31
Elaboración del plan de pruebas funcionales que se aplicarán al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 1.
Elaboración del plan de pruebas de estrés que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 1.
Documentación de resultados obtenidos en la ejecución de las pruebas
unitarias del sprint 1 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
funcionales del sprint 1 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
de estrés del sprint 1 conforme al plan de pruebas elaborado.
Completar documentación de pruebas del sprint 1 para ser enviado al
Project Manager. El mismo que se encargará de trasmitirlo al equipo de
desarrollo para que corrijan las fallas en caso de haber existido alguna
durante la ejecución de las pruebas.
Repetir plan de pruebas unitarias del sprint 1 en caso de haberse
encontrado algún error.
Repetir casos fallidos del plan de pruebas funcionales del sprint 1 en caso
de haber fallado alguno.
Repetir plan de pruebas de estrés del sprint 1 en caso de haberse
encontrado algún error.
Actualizar documentos de pruebas del sprint 0-1 para enviarlo
nuevamente al Project Manager.
32
Tareas del Sprint 2
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 2.
Elaboración del plan de pruebas unitarias que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 2.
Elaboración del plan de pruebas funcionales que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 2.
Elaboración del plan de pruebas de estrés que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 2.
Documentación de resultados obtenidos en la ejecución de las pruebas
unitarias del sprint 2 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
funcionales del sprint 2 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
de estrés del sprint 2 conforme al plan de pruebas elaborado.
Completar documentación de pruebas del sprint 2 para ser enviado al
Project Manager, el mismo que se encargará de trasmitirlo al equipo de
desarrollo para que corrijan las fallas en caso de haber existido alguna
durante la ejecución de las pruebas.
Repetir plan de pruebas unitarias del sprint 2 en caso de haberse
encontrado algún error.
33
Repetir casos fallidos del plan de pruebas funcionales del sprint 2 en caso
de haber fallado alguno.
Repetir plan de pruebas de estrés del sprint 2 en caso de haberse
encontrado algún error.
Actualizar documentos de pruebas del sprint 2 para enviarlo nuevamente
al Project Manager.
Tareas del Sprint 3
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 3.
Elaboración del plan de pruebas unitarias que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 3.
Elaboración del plan de pruebas funcionales que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 3.
Elaboración del plan de pruebas de estrés que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 3.
Documentación de resultados obtenidos en la ejecución de las pruebas
unitarias del sprint 3 conforme al plan de pruebas elaborado.
Realizar la documentación de todos los resultados obtenidos en la
ejecución de las pruebas funcionales del sprint 3 conforme al plan de
pruebas elaborado.
34
Documentación de resultados obtenidos en la ejecución de las pruebas
de estrés del sprint 3 conforme al plan de pruebas elaborado.
Completar documentación de pruebas del sprint 3 para ser enviado al
Project Manager, el mismo que se encargará de trasmitirlo al equipo de
desarrollo para que corrijan las fallas en caso de haber existido alguna
durante la ejecución de las pruebas.
Repetir plan de pruebas unitarias del sprint 3 en caso de haberse
encontrado algún error.
Repetir casos fallidos del plan de pruebas funcionales del sprint 3 en caso
de haber fallado alguno.
Repetir plan de pruebas de estrés del sprint 3 en caso de haberse
encontrado algún error.
Actualizar documentos de pruebas del sprint 3 para enviarlo nuevamente
al Project Manager.
Tareas del Sprint 4
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 4.
Elaboración del plan de pruebas unitarias que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 4.
Elaboración del plan de pruebas funcional el mismo que se aplicará al
producto ARES conforme a todos los criterios de aceptación establecidos
en cada una de las historias de usuario que constituyen o conforman el
sprint 4.
35
Elaboración del plan de pruebas de estrés que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 4.
Documentación de resultados obtenidos en la ejecución de las pruebas
unitarias del sprint 4 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
funcionales del sprint 4 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
de estrés del sprint 4 conforme al plan de pruebas elaborado.
Completar documentación de pruebas del sprint 4 para ser enviado al
Project Manager, el mismo que se encargará de trasmitirlo al equipo de
desarrollo para que corrijan las fallas en caso de haber existido alguna
durante la ejecución de las distintas pruebas aplicadas al producto las
cuales son unitarias, funcionales y de estrés.
Repetir plan de pruebas unitarias del sprint 4 en caso de haberse
encontrado algún error, los mismos que son atendidos y solucionados por
el equipo de desarrollo.
Repetir casos fallidos del plan de pruebas funcionales del sprint 4 en caso
de haber fallado alguno, los mismos que son atendidos y solucionados
por el equipo de desarrollo.
Repetir plan de pruebas de estrés del sprint 4 en caso de haberse
encontrado algún error, los mismos que son atendidos y solucionados por
el equipo de desarrollo.
Actualizar el documento de pruebas del sprint 4 para enviarlo
nuevamente al Project Manager, esto en caso de haber encontrado
errores que el equipo de desarrollo debió resolver.
36
Tareas del Sprint 5
Reunión con el Project Manager y el equipo de trabajo para definir las
historias de usuario que conformarán el sprint 5.
Elaboración del plan de pruebas unitarias que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 5.
Elaboración del plan de pruebas funcionales que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 5.
Elaboración del plan de pruebas de estrés que se aplicará al sistema
conforme a los criterios de aceptación establecidos en cada una de las
historias de usuario que conforman el sprint 5.
Documentación de resultados obtenidos en la ejecución de las pruebas
unitarias del sprint 5 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
funcionales del sprint 5 conforme al plan de pruebas elaborado.
Documentación de resultados obtenidos en la ejecución de las pruebas
de estrés del sprint 5 conforme al plan de pruebas elaborado.
Completar documentación de pruebas del sprint 5 para ser enviado al
Project Manager, el mismo que se encargará de trasmitirlo al equipo de
desarrollo para que corrijan las fallas en caso de haber existido alguna
durante la ejecución de las pruebas.
Repetir plan de pruebas unitarias del sprint 5 en caso de haberse
encontrado algún error.
37
Repetir casos fallidos del plan de pruebas funcionales del sprint 5 en caso
de haber fallado alguno.
Repetir plan de pruebas de estrés del sprint 5 en caso de haberse
encontrado algún error.
Actualizar documentos de pruebas del sprint 5 para enviarlo nuevamente
al Project Manager.
Entregables del Proyecto
Acorde a la metodología de desarrollo de software aplicada en la elaboración del
presente proyecto de titulación, la cual es Scrum, se tiene como entregables del
proyecto cinco documentos correspondientes a los sprints uno, dos, tres, cuatro
y cinco en los cuales se registra el control de calidad que se ha aplicado al
software, que para esta propuesta de titulación ha sido el desarrollo del producto
ARES.
Es importante mencionar que para el sprint cero no se han considerado la
elaboración de un documento por no constar entre sus tareas la ejecución de un
control de calidad al producto.
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Encuesta de satisfacción del proyecto
Con el firme propósito de demostrar la importancia de contar con una persona
dentro de un equipo de trabajo de desarrollo de software, encargada de controlar
y asegurar la calidad del producto, se ha realizado una encuesta con el objetivo
de medir la satisfacción de las personas en cuanto a este tema. Los resultados
de la encuesta se detallan a continuación:
38
Resultados de la encuesta realizada a los estudiantes de la CISC&N
Pregunta 1:
¿Cuán importante debería ser la satisfacción del usuario en cuanto al uso
de un software?
CUADRO N° 3
RESULTADOS DE LA PREGUNTA 1 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 8 RESULTADOS DE LA PREGUNTA 1 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
39
GRÁFICO N° 9 RESULTADOS DE LA PREGUNTA 1 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 88,24% es decir, 45
personas, consideran como muy importante la satisfacción del usuario en cuanto
al uso del software mientras que solo el 11,76% es decir, 6 personas, lo
consideran como medianamente importante.
Es importante citar que ninguno de los encuestados lo consideró como poco o
nada importante, lo que demuestra el grado de importancia que tomará la
satisfacción del usuario cuando se encuentre en uso el sistema académico.
40
Pregunta 2:
¿Conoce usted el concepto de calidad del software?
CUADRO N° 4 RESULTADOS DE LA PREGUNTA 2 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 10 RESULTADOS DE LA PREGUNTA 2 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
41
GRÁFICO N° 11 RESULTADOS DE LA PREGUNTA 2 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 98,04% es decir, 50
personas, conocen el concepto de calidad del software mientras que solo el
1,96% es decir, 1 persona, desconoce su concepto.
Es importante citar que estas estadísticas demuestran que nos encontramos
ante usuarios que reconocerán y sabrán evaluar el grado de calidad que llegue a
tener el sistema ARES en cuanto se comience a usarlo.
42
Pregunta 3:
¿Está usted de acuerdo en que los estudiantes de la CISC&N merecen
contar con un sistema académico de calidad?
CUADRO N° 5 RESULTADOS DE LA PREGUNTA 3 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 12 RESULTADOS DE LA PREGUNTA 3 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
43
GRÁFICO N° 13 RESULTADOS DE LA PREGUNTA 3 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 92,16% es decir, 47
personas, se encuentran totalmente de acuerdo en que los estudiantes de la
CISC&N cuenten con un sistema académico de calidad, otro 5,88% es decir, 3
personas, se encuentran medianamente de acuerdo mientras que solo el 1,96%
es decir, 1 persona, está medianamente en desacuerdo.
Es importante citar que estas estadísticas demuestran que el equipo de trabajo a
cargo de lanzar el nuevo sistema académico deberá controlar y garantizar la
calidad del mismo.
44
Pregunta 4:
¿Considera usted que el actual sistema académico cumple con todos los
parámetros de calidad que un software de índole universitario debería
tener?
CUADRO N° 6 RESULTADOS DE LA PREGUNTA 4 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 14 RESULTADOS DE LA PREGUNTA 4 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
45
GRÁFICO N° 15 RESULTADOS DE LA PREGUNTA 4 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, solo el 11,76% es decir, 6
personas, consideran que el actual sistema académico cumple en su totalidad
con los parámetros de calidad que un software de índole universitaria debería
tener, otro 50,98% es decir, 26 personas, consideran que lo cumple parcialmente
mientras que el 37,25% restante es decir, 19 personas, consideran que no lo
cumple en absoluto.
Es importante citar que estas estadísticas nos demuestran claramente la
inconformidad del poblado estudiantil y administrativo de la CISC&N en cuanto a
la calidad del actual sistema académico ya que un software no puede ser sólo
medianamente de calidad sino que debe serlo en su totalidad para satisfacción
de sus usuarios.
46
Pregunta 5:
¿Está usted de acuerdo en que se desarrolle un nuevo sistema académico
donde se asegure y garantiza la calidad del mismo en beneficio de los
estudiantes y personal administrativo de la CISC&N?
CUADRO N° 7 RESULTADOS DE LA PREGUNTA 5 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 16 RESULTADOS DE LA PREGUNTA 5 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
47
GRÁFICO N° 17 RESULTADOS DE LA PREGUNTA 5 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 72,55% es decir, 37
personas, se encuentran totalmente de acuerdo en el desarrollo de un sistema
académico donde se asegure y garantiza la calidad del mismo en beneficio de
los estudiantes y personal administrativo de la CISC&N, otro 25,49% es decir, 13
personas, se encuentran medianamente de acuerdo en el desarrollo del mismo,
un 1,96% es decir, 1 persona, se encuentra medianamente en desacuerdo y
ningún encuestado se encuentra totalmente en desacuerdo en su desarrollo.
Es importante citar que estas estadísticas demuestran la aceptación y
aprobación por parte de la población estudiantil y administrativa de la CISC&N
en relación a la creación de un nuevo sistema académico cumpla con todos los
parámetros de calidad.
48
Pregunta 6:
¿Cree usted que se debería cambiar la metodología de desarrollo de
software en la creación del nuevo sistema académico?
CUADRO N° 8 RESULTADOS DE LA PREGUNTA 6 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 18 RESULTADOS DE LA PREGUNTA 6 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
49
GRÁFICO N° 19 RESULTADOS DE LA PREGUNTA 6 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 92,16% es decir, 47
personas, creen que se debería cambiar la metodología de desarrollo de
software en la creación del nuevo sistema académico y solo el 7,84% es decir, 4
personas, no lo creen necesario.
Es importante citar que estas estadísticas demuestran la aceptación y
aprobación de la población de la CISC&N respecto al cambio de metodología en
el desarrollo del nuevo sistema académico.
50
Pregunta 7:
¿Conoce o ha escuchado acerca de la metodología ágil SCRUM?
CUADRO N° 9 RESULTADOS DE LA PREGUNTA 7 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 20 RESULTADOS DE LA PREGUNTA 7 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
51
GRÁFICO N° 21 RESULTADOS DE LA PREGUNTA 7 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, el 78,43% es decir, 40
personas, conocen o han escuchado mucho acerca de la metodología SCRUM,
otro 13,73% es decir, 7 personas, poco y solo el 7,84% es decir, 4 personas, no
tienen conocimiento de la metodología Scrum.
Es importante citar que estas estadísticas demuestran el alto grado de
conocimiento de los estudiantes de la CISC&N acerca de la metodología que se
plantea aplicar en esta propuesta de titulación.
52
Pregunta 8:
¿Cree usted que se debería aplicar la metodología SCRUM en el desarrollo
de futuros proyectos de titulación por considerarla la más apta e idónea en
el desarrollo de software?
CUADRO N° 10 RESULTADOS DE LA PREGUNTA 8 DE LA ENCUESTA
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
GRÁFICO N° 22 RESULTADOS DE LA PREGUNTA 8 DE LA ENCUESTA
(BARRA HORIZONTAL)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
53
GRÁFICO N° 23 RESULTADOS DE LA PREGUNTA 8 DE LA ENCUESTA
(GRÁFICO DE ANILLOS)
Elaboración: Anabell Tingo Beltrán Fuente: Datos de la investigación
Del total de la población estudiantil y administrativa de la CISC&N de la cual se
tomó como muestra para la encuesta a 51 personas, pero 5 se omitieron en
contestar, el 100% es decir, 47 personas, creen en que se debería aplicar la
metodología ágil Scrum en el desarrollo de futuros proyectos de titulación por
considerarla la más apta e idónea en el desarrollo de software.
Es importante citar que las estadísticas descritas anteriormente solo demuestran
la efectividad de poner en funcionamiento y realizar este proyecto de titulación.
54
CAPÍTULO IV
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O
SERVICIO
Como política de aceptación del proyecto se deberán cumplir los seis sprints
detallados en la propuesta de este proyecto de titulación.
CUADRO N° 11 NIVEL DE CUMPLIMIENTO DEL PROYECTO
SPRINT NIVEL DE
CUMPLIMENTO
Sprint 0
100%
Elaboración de las tareas que comprenden este sprint, las mismas que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Sprint 1
100%
Elaboración de las tareas que comprenden este sprint, las mismas que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Sprint 2
100%
Elaboración de las tareas que comprenden este sprint, las mismas que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Sprint 3
100%
Elaboración de las tareas que comprenden este sprint, las mismas que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Sprint 4 100% Elaboración de las tareas que
comprenden este sprint, las mismas
55
que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Sprint 5
100%
Elaboración de las tareas que comprenden este sprint, las mismas que se detallaron en las etapas de la metodología del proyecto correspondientes al Capítulo III.
Elaboración: Anabell Tingo Beltrán
Fuente: Datos del proyecto de titulación
56
Conclusiones
A partir del análisis de las encuestas realizadas, se revela que la mayoría de los
encuestados consideran que la satisfacción del usuario se encuentra
directamente relacionada con la calidad del software. Un software es de calidad
porque además de no presentar errores, las funcionalidades que posee cubren
las necesidades de los usuarios.
El resultado de la pregunta 1, presenta que el 88.24% de los encuestados,
consideran muy importante la satisfacción del usuario en cuanto al uso de
software. EL resultado de la pregunta 3, indican que el 92.16% de los
encuestados están de acuerdo con que los estudiantes de la CISC&N merecen
un sistema académico de calidad, esto coincide con los resultados de la
pregunta 4, que enseña que el 50.98% de los encuestados considera que el
actual sistema académico cumple parcialmente los parámetros de calidad que un
software universitario debe tener.
Para conseguir que las funcionalidades de un sistema académico cubran las
necesidades de los usuarios, se plantea el uso de la metodología ágil Scrum,
tomando en consideración los resultados de la pregunta 6, que demuestra que
los 92.16% de los encuestados creen que se debe cambiar la metodología de
desarrollo para crear dicho sistema. Además de acuerdo a los resultados de la
pregunta 8 el 100% de los encuestados, creen que se deben aplicar la
metodología Scrum en el desarrollo de los futuros proyectos de titulación por ser
considerada la más apta e idónea.
57
Recomendaciones
Para obtener un producto donde sea posible asegurarle a sus interesados, que
el mismo posee todos los índices de calidad que un determinado producto de
software debe tener, se recomienda que el aseguramiento y control de su calidad
se lo realice no solo una vez concluido el producto sino también durante su
proceso de elaboración o desarrollo, puesto que, esto nos ayudará a detectar
errores a tiempo y con el uso de una adecuada metodología de desarrollo es
posible lograr que la resolución de dichos inconvenientes no afecte
principalmente el compromiso de fecha de entrega del mismo.
La calidad del software es importante para obtener la satisfacción del usuario,
por lo tanto se considera necesario contar con un tester en los futuros
desarrollos para medir que las funcionalidades del sistema cubran las
necesidades de los usuarios.
Dado los beneficios que se obtienen al usar la metodología Scrum en el
desarrollo del sistema académico se debe considerar la implementación de esta
metodología en los futuros proyectos de titulación.
García León Delba, Beltrán Benavides Alfa. Un enfoque actual sobre la calidad del software. ACIMED [revista en la Internet]. 1995 Dic [citado 2015 Dic 08]; 3(3): 40-42. Disponible en: http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1024-94351995000300005&lng=es. Patricio Lete y Mª Carmen Penadés. Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP). Ph.D., Departamento de Sistemas Informáticos y Computación (DSIC), Universidad Politécnica de Valencia (UPV). Recibido el: 15/12/2005; Aprobado el: 15/01/2006. Disponible en: http://www.cyta.com.ar/ta0502/v5n2a1.htm. Juan Manuel Cueva Lovelle. Calidad del Software. 1999. Disponible en: https://uvirtual.unet.edu.ve/pluginfile.php/7610/mod_resource/content/0/Calidad_software.pdf Díaz, José Ramón. Las metodologías ágiles como garantía de calidad del software. REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, vol. 5, núm. 3, octubre, 2009. Disponible en: http://www.redalyc.org/articulo.oa?id=92217181006 Miguel Ángel León Jiménez. Certificación en pruebas de software. Centro Universitario de Ciencias Económico Administrativas. Disponible en: http://defis.cucea.udg.mx/sites/default/files/Documento%20de%20titulacion%20Miguel%20Angel%20Leon.pdf Aguilera, Sergio. Los Estándares de Calidad ISO para Desarrollo de Software, junio del 2015. Disponible en: http://184.168.109.199:8080/jspui/bitstream/123456789/5208/1/FInform-502-U4-3-EstandaresdeCalidad%20ISOSwDev-2015.pdf
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Nombre: Cargo: Fecha: Universidad: Facultad: Encuesta realizada para la obtención de información del proyecto de titulación ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA “FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO LA METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE” ENFOCADO EN EL CONTROL DE CALIDAD Objetivo general: Controlar y asegurar la calidad en el desarrollo del sistema académico que se usará como objeto de estudio de factibilidad de la metodología ágil SCRUM en la ingeniería de software.
1. ¿Cuán importante debería ser la satisfacción del usuario en cuanto al
uso de un software?
Muy importante
Medianamente importante
Poco importante
Nada importante
2. ¿Conoce usted el concepto de calidad del software?
Sí lo conozco
61
No lo conozco
3. ¿Está usted de acuerdo en que los estudiantes de la CISC&N merecen
contar con un sistema académico de calidad?
Totalmente de acuerdo
Medianamente de acuerdo
Medianamente en desacuerdo
Totalmente en desacuerdo
4. ¿Considera usted que el actual sistema académico cumple con todos los
parámetros de calidad que un software de índole universitario debería
tener?
Lo cumple en su totalidad
Lo cumple parcialmente
No lo cumple en absoluto
5. ¿Está usted de acuerdo en que se desarrolle un nuevo sistema
académico donde se asegure y garantiza la calidad del mismo en beneficio
de los estudiantes y personal administrativo de la CISC&N?
Totalmente de acuerdo
Medianamente de acuerdo
Medianamente en desacuerdo
Totalmente en desacuerdo
6. ¿Cree usted que se debería cambiar la metodología de desarrollo de
software en la creación del nuevo sistema académico?
Sí lo creo
No lo creo
7. ¿Conoce o ha escuchado acerca de la metodología ágil SCRUM?
62
Mucho
Poco
Nada
8. ¿Cree usted que se debería aplicar la metodología SCRUM en el
desarrollo de futuros proyectos de titulación por considerarla la más apta e
idónea en el desarrollo de software?
Sí lo creo
No lo creo
1
MANUAL DE USUARIO
PRODUCTO ARES
2
ÍNDICE GENERAL
MANUAL DE USUARIO 6
INTRODUCCIÓN AL USUARIO 7
DESCRIPCIÓN DE EVENTOS 7
Inicio de Sesión 7
Recuperación de Password 8
Tipo de Usuario 11 Docente 11
Menú de Opciones 11 Pantalla Principal - Datos Generales 11
Asistencias de Alumnos 12 Notas de Alumnos 15 Vista General de la Asignatura 18
Horario de examen 20 Horario de Clases 20
Estudiante 21 Menú de Opciones 21 Matriculación 22 Anulación de Materias 25 Consulta de Notas 26
Notas actuales 26 Histórico de notas 27 Consulta de Asistencias 27
Listado de formatos de Solicitudes 28 Horarios 28
Horario de Examen 28 Horario General 29
Coordinador 29 Menú de Opciones 29 Generación calendario Académico 30 Generación de Horarios de clases 31 Generación de Horarios de examen 32 Subir solicitudes 33 Consulta de Horarios de Clases 34 Consulta de Horarios de Examen 35
Secretario o Administrativo 36 Menú de Opciones 36 Inscritos & Matriculados 36 Materias Aprobadas 37 Estudiante por Docente 38 Registro de Inscripción 39 Legalización de Ordenes 40 Registro de Anulación 41
Gráfico N° 1: Inicio de Sesión 8 Gráfico N° 2: Recuperación de Password 9 Gráfico N° 3: Mensaje de cambio de clave 9 Gráfico N° 4: Reestablecer contraseña 10
Gráfico N° 5: Menú de Opciones Docentes 11 Gráfico N° 6: Datos Generales 11 Gráfico N° 7: Opciones por Materia 12 Gráfico N° 8: Consulta de Asistencia 13
Gráfico N° 9: Consulta de Asistencia - Buscar 14 Gráfico N° 10: Mantenimiento de Asistencia 15 Gráfico N° 11: Notas de Alumnos – Consulta de Notas 16 Gráfico N° 12: Consulta de Notas - Buscar 16
Gráfico N° 13: Ingreso de Notas 17 Gráfico N° 14: Ingreso de Notas - Parcial 18 Gráfico N° 15: Vista General de la Asignatura - Primer Parcial 18 Gráfico N° 16: Vista General de la Asignatura - Segundo Parcial 19
Gráfico N° 17: Vista General de la Asignatura - Formatos de Descarga 19 Gráfico N° 18: Docente – Horario de Examen 20 Gráfico N° 19: Docente – Horario de Examen 21 Gráfico N° 20: Estudiantes - Detalle de Opciones 21
Gráfico N° 21: Matriculación 22 Gráfico N° 22: Matriculación – Proceso de Registro 22 Gráfico N° 23: Matriculación - Escoger materias 23 Gráfico N° 24: Matriculación - Validaciones 23
Gráfico N° 25: Matriculación - Finalización del Proceso 24 Gráfico N° 26: Matriculación – Datos Generales - Hoja de Registro 24 Gráfico N° 27: Anulación de Materia – Generar Solicitud 25 Gráfico N° 28: Anulación de Materias - Notificación 26
Gráfico N° 29: Consulta de Notas – Notas Actuales 26 Gráfico N° 30: Consulta de Notas – Históricos de Notas 27 Gráfico N° 31: Estudiantes - Consulta de Asistencias 27 Gráfico N° 32: Listado de formatos de Solicitudes 28
Gráfico N° 33: Estudiantes - Horario de Examen 28 Gráfico N° 34: Estudiantes - Horario de Examen 29 Gráfico N° 35: Coordinador - Menú de Opciones 29 Gráfico N° 36: Generación calendario Académico 30
Gráfico N° 37: Creación de Evento 31 Gráfico N° 38: Generación de Horarios de clases 32 Gráfico N° 39: Generación de Horarios de examen 33 Gráfico N° 40: Subir solicitudes 33
Gráfico N° 43: Consulta de Horarios de Examen 35 Gráfico N° 44: Consulta de Horario Examen - Buscar 36
Gráfico N° 45: Secretario o Administrativo Menú de Opciones 36 Gráfico N° 46: Reportes de Estudiantes Inscritos 37 Gráfico N° 47: Reporte de Materias Aprobadas 38 Gráfico N° 48: Reporte de Estudiante por Docente 39
Gráfico N° 49: Registro de Inscripción 40 Gráfico N° 50: Legalización Orden de Pago 40 Gráfico N° 51: Anulación de Materia 41 Gráfico N° 52: Aprobación Anulación de Materia 41
Gráfico N° 53: Actualización de Datos 42 Gráfico N° 54: Imagen de Perfil 43 Gráfico N° 55: Cambio de Contraseña 44 Gráfico N° 56: Mensajes 44