GUIA PARA LA MEJORA EN EL LEVANTAMIENTO DE REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGISTICA DE TRANSPORTE

GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE
REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGÍSTICA DE
TRANSPORTE
CARLOS ANDRÉS RODRÍGUEZ SILVA
UNIVERSIDAD CATÓLICA DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C
2021
1
GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE REQUERIMIENTOS DE
SOFTWARE EN UNA PYME DE LOGÍSTICA DE TRANSPORTE
CARLOS ANDRÉS RODRÍGUEZ SILVA
Trabajo de grado para optar al título de Ingeniero de Sistemas y
Computación
Asesor: Profesor Jaime Fernando Pérez González
UNIVERSIDAD CATÓLICA DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C
2021
2
3
Nota de aceptación
______________________________________
______________________________________
______________________________________
______________________________________
Presidente del Jurado
_______________________________
Jurado
_______________________________
Jurado
Bogotá D.C. Noviembre del 2021
4
AGRADECIMIENTOS
Agradezco a Dios por darme la fortaleza mental para superar las dificultades y
continuar con mi trabajo y estudio.
Agradezco a mis padres por toda la ayuda recibida a lo largo de la carrera, que me
facilitaron enormemente concentrarme en mis estudios y actividades.
Agradezco a mi tutor, el ingeniero Jaime Fernando Pérez, por sus consejos y su
ayuda a pesar de las dificultades, para mejorar mi proceso como estudiante y poder
realizar este trabajo de la mejor manera.
5
CONTENIDO
INTRODUCCIÓN ............................................................................................................. 12
1. PLANTEAMIENTO DEL PROBLEMA .......................................................................... 14
2.OBJETIVOS ................................................................................................................. 18
2.1. OBJETIVO GENERAL ....................................................................................................... 18
2.2. OBJETIVOS ESPECÍFICOS............................................................................................. 18
3. MARCO DE REFERENCIA.......................................................................................... 19
3.1. MARCO TEÓRICO ............................................................................................................. 19
3.1.1. INGENIERÍA DE REQUERIMIENTOS..................................................................... 19
3.1.1.1. DEFINICIÓN ............................................................................................................. 19
3.1.1.2. FASES ....................................................................................................................... 19
3.1.2. CALIDAD DE SOFTWARE ........................................................................................ 21
3.1.2.1. HISTORIA DE LA CALIDAD DE SOFTWARE .................................................... 21
3.1.2.2. CONCEPTO E IMPORTANCIA DE LA CALIDAD DE SOFTWARE ................ 22
3.1.2.3. ¿CÓMO LOGRAR LA CALIDAD DE SOFTWARE? ........................................... 22
3.1.2.4. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE .................................. 22
3.1.3. METODO PARA INTERACTUAR CON STAKEHOLDERS EN EL
LEVANTAMIENTO DE REQUERIMIENTOS ..................................................................... 25
3.1.4. IMPACTO DE LOS REQUERIMIENTOS EN LA CALIDAD DEL SOFTWARE . 27
3.2. MARCO CONCEPTUAL .................................................................................................... 29
3.3. ESTADO DEL ARTE .......................................................................................................... 31
4.ALCANCES Y LIMITACIONES ..................................................................................... 38
5.METODOLOGÍA ........................................................................................................... 39
5.1 ENFOQUE METODOLÓGICO .......................................................................................... 39
5.2 FASES DEL PROYECTO................................................................................................... 39
6. CRONOGRAMA .......................................................................................................... 41
7. PRODUCTOS A ENTREGAR ...................................................................................... 42
8. INSTALACIONES Y EQUIPO REQUERIDO ................................................................ 43
9. PRESUPUESTO DEL TRABAJO................................................................................. 44
10. ESTRATEGIAS DE COMUNICACIÓN Y DIVULGACIÓN .......................................... 46
6
11. DESARROLLO DE LA PROPUESTA ........................................................................ 47
11.1 DIAGNÓSTICO PROPIO SOBRE EL LEVANTAMIENTO DE REQUERIMIENTOS.
....................................................................................................................................................... 47
11.2 EVALUACIÓN DEL PROCESO ACTUAL DE LEVANTAMIENTO DE
REQUERIMIENTOS. ................................................................................................................. 48
11.3 ESTUDIO ANALITICO SOBRE NORMAS Y METODOLOGIAS ENFOCADAS EN
EL LEVANTAMIENTO DE REQUERIMIENTOS DE SOFTWARE. ................................... 52
11.4 DISEÑO DE LA GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE
REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGÍSTICA DE
TRANSPORTE. .......................................................................................................................... 53
11.5 EVALUACIÓN DE RETROALIMENTACIÓN DE LA GUÍA PARA LA MEJORA EN
EL LEVANTAMIENTO DE REQUERIEMIENTOS DE SOFTWARE. ................................. 66
12. CONCLUSIONES ...................................................................................................... 70
BIBLIOGRAFÍA ................................................................................................................ 71
ANEXOS ......................................................................................................................... 74
7
LISTA DE FIGURAS
Figura 1. Cronograma del proyecto ............................................................ 41
Figura 2. Presupuesto preliminar. ............................................................... 44
Figura 3. Presupuesto del personal ............................................................. 44
Figura 4. Presupuesto de gastos generales ................................................ 45
Figura 5. Presupuesto general del proyecto ................................................ 45
Figura 6. Pregunta 4 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 48
Figura 7. Pregunta 6 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 49
Figura 8. Pregunta 7 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 49
Figura 9. Pregunta 8 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 50
Figura 10. Pregunta 9 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 50
Figura 11. Pregunta 10 evaluación del proceso actual de levantamiento de
requerimientos ............................................................................................. 51
Figura 12. R01 diligenciado en el formato según la guía diseñada ............. 66
Figura 13. R02 diligenciado en el formato según la guía diseñada ............. 66
Figura 14. R03 diligenciado en el formato según la guía diseñada ............. 67
Figura 15. R04 diligenciado en el formato según la guía diseñada ............. 67
Figura 16. R05 diligenciado en el formato según la guía diseñada ............. 67
Figura 17. Pregunta 8 formulario retroalimentación de la guía diseñada .... 68
Figura 18. Pregunta 9 formulario retroalimentación de la guía diseñada .... 68
Figura 19. Pregunta 10 formulario retroalimentación de la guía diseñada .. 69
8
LISTA DE ANEXOS
Anexo A. Formato de diligenciamiento de requerimientos en una pyme de logística
de transporte.................................................................................................................. 74
Anexo B. Cuadro analítico sobre metodologías y normas enfocadas en el
levantamiento de requerimientos de software ........................................................... 75
9
RESUMEN
El presente trabajo de grado comprende el desarrollo del diseño de una guía de
calidad para el proceso de levantamiento de requerimientos en una PyME de
logística de transporte en Colombia, para verificar porque este proceso es uno de
los más importantes y claves en cualquier proyecto de desarrollo de software. Lo
descrito anteriormente se basa en un conjunto de normas y metodologías de calidad
actuales enfocadas al entorno y la situación actual de la empresa. Para el marco de
referencia y estado del arte se investigaron diferentes estudios sobre los diferentes
procesos en el levantamiento de requerimientos a nivel, internacional, continental y
local para tener una visión sobre la forma de implementar la guía según el contexto
de la empresa y su modo de operar.
Se hizo un diagnóstico propio al comienzo, sobre el proceso de software enfocado
en la etapa de requerimientos, para verificar las inconsistencias y malas prácticas
en algunos procesos de esta misma.
Se consultaron a nivel nacional e internacional las normas y metodologías utilizadas
filtradas según el marco colombiano de Min Tic para asegurar la calidad, en el
proceso de levantamiento de requerimientos, eligiendo las que se adaptarían al
modo de operar de las Pymes colombianas enfocadas en el desarrollo de software.
Para el desarrollo de la guía fue evidentemente seleccionar las buenas prácticas y
metodologías consultadas para utilizar las más útiles y que aportaran de la mejor
forma la estrategia de trabajo de la empresa sin generar un cambio drástico en la
organización de la misma. Las elegidas fueron la norma ISO 25010 y las
metodologías SCRUM y TSP para utilizar las características seleccionadas de cada
una de ellas y no en su totalidad.
Como parte final se pudo poner en práctica, aunque no en su totalidad lo
desarrollado en la guía y ver una retroalimentación por parte de los empleados en
la PyME, llevando a la conclusión del trabajo y de la importancia de los
requerimientos desde el inicio de la historia donde se introdujeron por primera vez
hasta el día de hoy.
Palabras Clave: Guía, Calidad, Ingeniería de requerimientos, Ingeniería de
software, Empresa, PyME.
10
ABSTRACT
This degree work includes the development of the design of a quality guide for the
requirements gathering process in a transport logistics SME in Colombia, to verify
why this process is one of the most important and key in any software development
project. The above described is based on a set of current quality standards and
methodologies focused on the environment and the current situation of the company.
For the frame of reference and state of the art, different studies on the different
processes in the requirements gathering at international, continental and local level
were investigated to have a vision on how to implement the guide according to the
context of the company and its way of operating.
A diagnosis was made at the beginning of the software process focused on the
requirements stage, to verify the inconsistencies and bad practices in some of its
processes.
National and international standards and methodologies used to ensure quality in
the requirements gathering process were consulted, choosing those that would
adapt to the way Colombian SMEs focused on software development operate.
For the development of the guide it was evidently necessary to filter the good
practices and methodologies consulted in order to use the most useful and that
would contribute in the best way to the work strategy of the company without
generating a drastic change in its organization. The chosen ones were the ISO
25010 standard and the SCRUM and TSP methodologies in order to use the
selected characteristics of each one of them and not all of them.
As a final part, it was possible to put into practice, although not in its entirety, what
was developed in the guide and to see feedback from employees in the SME, leading
to the conclusion of the work and the importance of the requirements from the
beginning of the story where they were first introduced until today.
Keywords: Guidance, Quality, Requirements engineering, Software engineering,
Enterprise, SME.
11
INTRODUCCIÓN
La evolución de la tecnología es un claro ejemplo que nada es estático y, cada día
se observa un constante cambio del mundo. Un claro ejemplo de esto es el
desarrollo de software el cual se ha convertido en aliado de las empresas buscando
mejorar los procesos y así impulsarlos a tener ventajas competitivas.
Hoy en día son muchas las empresas proveedoras de software que han identificado
en la crisis de la pandemia una oportunidad de interconectar a las compañías,
permitiendo que personas empezaran a crear una relación seriamente no solo con
la tecnología sino con las aplicaciones web, aprovechar los espacios en la nube, el
acercamiento a las aplicaciones (Apps), entre otras; buscando estas últimas proveer
los mejores servicios y las mejores funcionalidades para sobresalir en un mercado
altamente competitivo.
Es por esto, que la calidad del software es una competencia, y debe ser excelente,
no solo por brindarle un mejor servicio al cliente, sino porque internamente en
cualquier proyecto de software que se desarrolle éste deberá contar con los
procesos correctos y adaptándose a las normas para tener un buen control de
recursos, tiempo y alcance al implementarlo.
Para cada cliente o usuario final de una aplicación, al tener tantas opciones en el
mercado; siempre se guiará por la cantidad de procesos que pueda hacer y servicios
que pueda recibir, en cualquier lugar y en cualquier momento, esperando que se
comporte de manera óptima y acorde las 24 horas del día.
Para tener claro que el software puede cumplir con estos requerimientos, debe
cumplir con unas etapas donde se valida su pertinencia, confiabilidad y desempeño.
siendo estas características validadas desde una concepción como idea o respuesta
a un problema específico.
Cuando se habla de esa idea o problema a resolver, se denomina como
requerimiento inicial, y debe ser lo suficientemente claro y específico posible, de tal
manera que durante el desarrollo del proyecto de software no presente
ambigüedades.
Por lo anterior descrito, el presente trabajo tiene como finalidad, la creación de una
guía que apoye el proceso de levantamiento de requerimientos, ya que muchas
empresas omiten este factor al iniciar proyectos de software; para cumplir con este
objetivo se analizará una PyME de logística de transporte que provee software para
la mayoría de las operaciones que involucran esta industria, los procesos que llevan
a cabo, de qué forma los manejan y cómo es posible mejorar en algunas tareas que
no se estén realizando basadas en los mejores estándares.
12
De igual manera, se resaltará la importancia sobre la responsabilidad que se tiene
a la hora de levantar requerimientos de software para demostrar que las excusas
de pérdida de tiempo y documentación excesiva no se conviertan en algo difícil de
manejar, sino al contrario, demostrar que más se pierde en recursos y se generan
más problemas en el ciclo de vida del software si esta etapa no se le da la misma o
mayor prioridad que las demás.
13
1. PLANTEAMIENTO DEL PROBLEMA
La búsqueda de software de calidad hoy en día está siendo ampliamente necesitado
ya que el mercado se ha vuelto más competitivo, las nuevas tecnologías han
impulsado a transformar las empresas y su modo de operar. Así lo expone un
artículo sobre el aseguramiento de la calidad en Pymes en Colombia:
La calidad del software es un tema cada vez más importante y al que
se presta mayor atención, no solo desde el punto de vista investigativo,
sino también desde el punto de vista empresarial, puesto que cada vez
más las empresas buscan ofrecer a sus clientes productos y servicios
que les permitan diferenciarse de sus competidores por la calidad de
los mismos [1].
Basta con mencionar diferentes autores que han estudiado la fase de levantamiento
de requerimientos de software y su vital importancia como se menciona en este
artículo sobre algunas de las principales causas de fracaso de un proyecto de
software:
Factores de daño o cancelación
•
•
•
•
•
•
•
•
Requerimientos incompletos
Deficiencia en el involucramiento del usuario
Deficiencia de recursos
Cambios en los requerimientos y especificaciones
Deficiencia en la planeación
Fin de la necesidad del requerimiento.
Desconocimiento de tecnología
Expectativas no realistas [2]
Se puede observar que en el anterior listado cuatro de estos factores
(Requerimientos incompletos, cambios en los requerimientos, fin de la necesidad
del requerimiento y expectativas no realistas) están directamente relacionados con
la fase de levantamiento de requerimientos, haciendo que cada vez más las
empresas se cuestionen sobre esta primera fase del desarrollo de software, la
magnitud de afectación de este después de terminado el producto que es lo que
genera mayores pérdidas en recursos y tiempo.
The Standish Group, es una firma internacional independiente de asesoría en
investigación de TI fundada hace más de 30 años que realiza varios informes
14
anuales, donde hace unos años atrás como se planteó en este articulo [3] varias de
las dificultades de gestionar el proceso de desarrollo de software son:
•
•
•
•
•
El 15% de todo el esfuerzo de desarrollo de software se desperdicia
debido a la cancelación de proyectos (a nivel mundial).
El 50% de los proyectos de gran dimensión sobrepasa el presupuesto
o se retrasa en su plazo de entrega.
La mayoría de los proyectos de pequeña dimensión sobrepasan su
presupuesto y sufren el retraso de un 20% en los plazos de entrega.
La cantidad de trabajo en productos de software se duplica cada dos
años.
El 75% de los sistemas de gran dimensión tienen problemas de
funcionamiento.
Que son causadas por las siguientes debilidades enumeradas, dentro de este
mismo proceso como:
1.
2.
3.
4.
5.
6.
Alta dependencia de la mano de obra.
Altos costos, debido a los largos plazos de entrega.
Calidad insuficiente.
Procesos escasamente repetibles.
Modelos de gestión organizacional apenas desarrollados.
Estructura reducida y carencias de personal cualificado en gestión
empresarial.[3]
Solo con seleccionar la insuficiente calidad, acompañado de un desborde del
alcance proyecto haciendo que este sobrepase presupuestos definidos y retrasos
en los plazos de entrega se justifica mucho más el presente trabajo argumentado
por todo el historial referente a el levantamiento de requerimientos y la calidad del
mismo.
Ahora centrándonos en Colombia, se presenta a continuación algunos casos donde
pasa aquí como ya lo hemos mencionado, ayudado del Standish Group a nivel
mundial, situaciones similares con el proceso de desarrollo de software.
Desde inicios de este siglo se han visto clientes peleando por quien responde por
las pérdidas que generan los errores de software como lo expresa Alan Levine,
director de seguridad global de Alcoa, “'Cada vez que un fabricante de software saca
un nuevo parche o arreglo para reparar una falla es en cierto modo una retirada del
producto” [4].
También lo vemos recientemente con el caso de Avianca ocurrido en el 2018: “Falla
en software entre las causas de los retrasos de Avianca” que afectó el 8% de vuelos
15
en un día, afectando a más de 4000 pasajeros, los cuales representan cifras no
grandes, pero a considerar para la compañía. Así bien, grandes empresas no se
preocupan mucho por entregar software de calidad ya que siempre tienen las
excusas de que se requiere mucho tiempo, para revisar detenidamente y la presión
de los clientes por la entrega de productos los hace enfocarse en un solo objetivo
[5].
Por todo lo mencionado anteriormente se presenta el caso de este trabajo de grado
para verificar como se están realizando los procesos en PyMES y empresas recién
empezadas, específicamente en el levantamiento de requerimientos, primera fase
en el ciclo de vida del desarrollo de software:
La PyME de logística de transporte a trabajar durante este proyecto, es una
empresa conformada por un grupo de personas que desde hace más de 10 años
vienen dando soporte y desarrollo a una aplicación creada para todo el proceso del
área de transporte, desde la creación de una orden de servicio, todo el proceso de
tráfico, hasta cuando se liquida y se termina la misma.
Hoy en día esta empresa provee los servicios a más de cincuenta microempresas y
medianas empresas, de las cuales cada una tienen procesos diferentes y así mismo
no todos los servicios se proveen de igual forma a las mismas empresas, esto quiere
decir que algunos procesos como facturación electrónica, o módulos de contabilidad
algunas empresas los tienen y otros prefieren utilizarlos con terceros.
La PyME al no contar con muchos empleados y al no ser enfocada hacia el
desarrollo sino al proveer un servicio por medio de una aplicación, pero siendo el
software un componente esencial, se hace inviable aplicar una metodología de
desarrollo de software.
Lo anterior se justifica por medio de lo que se expresa en los siguientes trabajos de
investigación donde se afirma que:
Los modelos y metodologías actuales son extranjeros y ajenos a las
condiciones y/o características propias, con servicios de capacitación
muy formales y servicios de consultoría excesivamente costosos y no
son fáciles de aplicar en organizaciones pequeñas [6].
La carencia de una buena gestión de requerimientos en los proyectos
software ha demandado la necesidad de un instrumento para la
generación del proceso de desarrollo de requerimientos de software
para micro y pequeñas empresas, pues según varios autores no existe
un instrumento que sugiera un proceso de desarrollo de software con
base en características de la organización y en buenas prácticas [7].
16
Como el modo de operar de la empresa es por medio de aplicar algunas buenas
prácticas, el proceso o, dicho de otra manera, el ciclo de vida del desarrollo de este
software, muchas de sus fases se realizan de manera irregular, encontrándose
casos donde se pierde información de algunos usuarios, se realizan soluciones de
funcionalidades más de una vez, confusión sobre lo que requiere el cliente y
contradicciones en algunos procesos, entre otros. Lo anterior hace que se pierda
demasiado tiempo en soporte, realizando un efecto dominó ya que se pierde tiempo
además en el desarrollo de nuevas funcionalidades, se pierde confianza en el
sistema o retrasos en procesos de vital importancia para estas empresas pequeñas.
-----------[1]
Toro, A. y Peláez, L. E. «Validación de un modelo para el aseguramiento de la
calidad del software en MIPYMES que desarrollan software en el Eje Cafetero.»
2018.
[2]
Cristiá, Maximiliano. «Introducción a la ingeniería de requerimientos.» Trabajo
de Investigación, Rosario, 2014.
[3] Toro,
A. y Peláez, L. E. Op. Cit., p.109
[4]
Journal, David Bank The Wall Street. «El Tiempo.» Hartas de fallas informaticas,
las empresas quieren exigir responsabilidad. 25 de Febrero de 2005.
<https://www.eltiempo.com/amp/archivo/documento/MAM-1682351>.
[5]
Benavides, Lina María Guevara. La República. 2 de Agosto de 2018.
<https://amp.larepublica.co/empresas/el-problema-de-avianca-de-ayer-tuvoque-ver-con-una-falla-en-el-software-aerocivil-2755884>.
[6]
Luis Merchán, Alba Urrea y Rubén Rebollar. «Definición de una metodología ágil
de ingeniería de requerimientos para empresas emergentes de desarrollo de
software del sur-occidente colombiano.» Trabajo de Investigación, Cali,
2008.
[7]
Gálvez, A. Toro y J. G. «Especificación de requisitos de software: una mirada
desde la revisión teórica de antecedentes.» Pereira, 2016.
17
2.OBJETIVOS
2.1. OBJETIVO GENERAL
•
Diseñar una guía de calidad para el levantamiento de requerimientos de
desarrollo de software en una PyME de logística de transporte.
2.2. OBJETIVOS ESPECÍFICOS
•
•
•
•
Realizar un diagnóstico en la fase de levantamiento de requerimientos en el
ciclo de software actual en la PyME de logística de transporte.
Analizar las normas y metodologías de calidad de software actuales.
Proponer el diseño de la guía y sus fases de acuerdo a la norma o
metodología seleccionada para mejorar el levantamiento de requerimientos.
Evaluar la guía propuesta, para medir su grado de eficiencia.
18
3. MARCO DE REFERENCIA
3.1. MARCO TEÓRICO
3.1.1. INGENIERÍA DE REQUERIMIENTOS
Desde inicios del siglo ha empezado a estudiarse la importancia de las fases previas
en el ciclo de vida del desarrollo del software y como, con ayuda de compañías que
se encargan de medir los errores más comunes en estos proyectos de tecnología y
desarrollo se puede apreciar que la obtención de requerimientos inexactos hace que
los procesos y en general el proyecto se atrase y pierda en recursos, así como
también desborda su alcance.
Por supuesto se ha creado lo que conocemos como ingeniería de requerimientos
que, partiendo de una definición, desglosa todo lo que se puede hacer en esta etapa
de levantamiento de informacion o de requerimientos además de cómo podemos
asegurar la calidad de ellos.
3.1.1.1. DEFINICIÓN
Según Pressman ingeniero de software, consultor y autor estadounidense, la
ingeniería de requerimientos puede definirse como:
Aquella que proporciona el mecanismo apropiado para entender lo que
desea el cliente, analizar las necesidades, evaluar la factibilidad,
negociar una solución razonable, especificar la solución sin
ambigüedades, validar la especificación y administrar los
requerimientos a medida que se transforman en un sistema funcional
[8].
Según lo anterior, el presente proyecto se enfocará en el análisis de requerimientos
de software y su levantamiento ya que la PyME actual ya cuenta con un software
definido y estructurado, por lo cual se continua en el siguiente apartado identificando
las fases de este proceso.
3.1.1.2. FASES
Según Pressman, en su libro de ‘Ingeniería de software, un enfoque práctico’,
también define las cinco fases del proceso de análisis de requerimientos:
1. Reconocimiento del problema: se deben de estudiar inicialmente las
especificaciones del sistema. El analista debe establecer un canal adecuado de
comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la
19
función primordial del analista en todo momento es reconocer los elementos del
problema tal y como los percibe el usuario.
2. Evaluación y síntesis En esta etapa el analista debe centrarse en el flujo y
estructura de la información, definir las funciones del software, determinar los
factores que afectan el desarrollo de nuestro sistema, establecer las características
de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas
anteriores conducen fácilmente a la determinación del problema de forma
sintetizada.
3. Modelización: durante la evaluación y síntesis de la solución, se crean modelos
del sistema que servirán al analista para comprender mejor el proceso funcional,
operativo y de contenido de la información.
4. Especificación: las tareas asociadas con la especificación intentan proporcionar
una representación del software. Esto más adelante permitirá llegar a determinar si
se ha llegado a comprender el software, en los casos que se lleguen a modelar se
pueden dejar plasmados manuales.
5. Revisión: una vez que se ha descrito la información básica, se especifican los
criterios de validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La documentación
del análisis de requerimientos y manuales, permitirán una revisión por parte del
cliente, la cual posiblemente traerá consigo modificaciones en las funciones del
sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones
previstas inicialmente [9].
Lo anterior es una base y está implícito en cualquier proceso de software
actualmente, pero a partir de este estudio y estandarización enfocado a los
requerimientos es que se podrá estructurar de mejor manera como analizar el
levantamiento de requerimientos, pero al mismo tiempo verificar la calidad de los
mismos.
20
3.1.2. CALIDAD DE SOFTWARE
A continuación, en este apartado se busca identificar como empezó a crearse el
concepto de calidad del software y por qué es tan importante y tan beneficioso
tenerlo en cuenta en cada desarrollo que se realice para satisfacer aún más las
necesidades de los usuarios y verificar lo desarrollado teniendo en todo momento
el control y aseguramiento de ella:
3.1.2.1. HISTORIA DE LA CALIDAD DE SOFTWARE
En 1985, la ISO, que fue creada en 1947 a pocos años de terminada la segunda
guerra mundial, determinó que ciertos de sus países miembros harían un
reglamento. Cinco años más tarde compañías gigantes en todo el mundo,
reconocían que se desperdiciaban millones de dólares en software que no tenía ni
las características ni la funcionalidad que se prometía al inicio.
Esta designación del reglamento se dio a través de un comité técnico, este
reglamento que elaborarán debía ser sobre la garantía de la calidad a nivel
internacional. Uno de los modelos utilizados en la elaboración fueron las normas
británicas BS 5750 de 1977). Diez años después aparece la primera edición de la
serie de normas ISO 9000. Las revisiones a esta versión se realizaron en 1994,
2008 y la última data del 2015.
Lo que se busca con las normas ISO es asegurar que los productos que llegan al
cliente tengan un mínimo de calidad asegurada. El objetivo perseguido por las
normas ISO es asegurar que los productos y/o servicios alcanzan la calidad
deseada. Del lado de las compañías, son vistas como una forma de abaratar costos
mediante la prevención de errores y mayor productividad [10].
Cuando se implementa un sistema de gestión de calidad o visto de manera más
simple, cuando se asegura la calidad y se la aplica al proceso de desarrollo de
software se beneficia tanto el cliente como la empresa ya que:
● Mejora la satisfacción del cliente, ya que las funcionalidades están alineadas
con las necesidades de él.
● Se consigue uniformidad y estabilidad en la producción, aportando un mínimo
de calidad en los mismos procesos en diferentes clientes.
● Se aumenta la eficiencia y se reducen costos, ya que se enfoca en los
procesos realmente productivos.
● Genera una buena reputación en la empresa que provee el software con
evidencia por parte de sus clientes.
21
3.1.2.2. CONCEPTO E IMPORTANCIA DE LA CALIDAD DE SOFTWARE
En pocas palabras y en sentidos generales para no generar un debate, ya que la
palabra calidad de por si es ambigua la calidad de software lo define Pressman en
su libro como “un proceso eficaz de software que se aplica de manera que crea un
producto útil que proporciona valor medible a quienes lo producen y a quienes lo
utilizan “[11].
Un proceso eficaz, ya que se necesita un estándar permitiéndole al software no
llegar a una situación caótica y haciendo que cualquier elaboración tenga su
recompensa; un producto útil, cuando se entrega en completitud las funciones y
características que debe tener este software, claro está sin errores. Finalmente
obtener valor agregado dentro del software es de vital importancia en un futuro o
después de implementado ya que, para la parte desarrolladora, genera menos
tiempo y esfuerzo para mantenimiento; del otro lado para los usuarios sea de
cualquier tipo da una mejora y facilita cualquier proceso de negocio.
Para llegar al producto anterior o que posea calidad, se hace evidente como llegar
o alcanzar la calidad del software tanto en el producto que es nada menos que la
suma de lo realizado en el proceso.
3.1.2.3. ¿CÓMO LOGRAR LA CALIDAD DE SOFTWARE?
Para lograr la calidad de software Pressman dice que existen cuatro actividades
principales en el desarrollo del software para alcanzar una alta valoración de esta:
métodos de la ingeniería de software, técnicas de administración de proyectos,
acciones de control de calidad y aseguramiento de la calidad del software.
Para efectos del presente proyecto nos enfocaremos en la última actividad que es
el aseguramiento de la calidad de software rigiéndose por las normas que existen
actualmente y que harán parte del desarrollo de este.
3.1.2.4. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Para asegurar la calidad en el desarrollo y producto del software, Pressman
involucra actividades esenciales para su correcta administración:
22
• Estándares: el IEEE, ISO y otras organizaciones que establecen estándares
han producido una amplia variedad de ellos para ingeniería de software y
documentos relacionados. Los estándares los adopta de manera voluntaria
una organización de software o los impone el cliente u otros participantes.
• Revisiones y auditorias: Las revisiones técnicas son una actividad del control
de calidad que realizan ingenieros de software para detectar errores o
inconsistencias sobre algún proceso; en este caso, el proceso de desarrollo
de software.
• Colección y análisis de los errores. La única manera de mejorar es medir
cómo se está haciendo algo. El ACS reúne y analiza errores y datos acerca
de los defectos para entender mejor cómo se cometen los errores y qué
actividades de la ingeniería de software son más apropiadas para eliminarlos.
• Educación. Toda organización de software quiere mejorar sus prácticas de
ingeniería de software. Un contribuyente clave de la mejora es la educación
de los ingenieros de software, de sus gerentes y de otros participantes [12].
Estas son algunas de las actividades para asegurar la calidad en el software, y por
tanto son las bases a utilizar para el desarrollo del presente proyecto, justificándose
de la siguiente manera:
Parte del proceso de investigación del proyecto y en cumplimiento al objetivo
específico número dos, se hará evidente indagar y analizar las normas existentes
que se puedan adaptar y aplicar de la mejor manera en forma conjunta a la situación
actual de la empresa.
En cumplimiento al primer objetivo específico, se planea la actividad de revisión o
diagnóstico propio, junto con ella la reunión de errores que se evidencian en el
proceso de levantamiento de requerimientos actual en la PyME.
Por último, y apuntando hacia la parte final del proyecto, es importante que, aunque
el diseño de guía de calidad queda a discreción de la empresa seguirla utilizando o
no, como conclusiones sería de gran provecho que todos los integrantes de la
empresa en las diferentes áreas puedan mejorar de una forma u otra las practicas
sobre la ingeniería del software y sobre el proceso de levantamiento de
requerimientos en sí.
-----------[8]
Roger S. Pressman, Ph.D. Ingeniería del software. Un enfoque práctico.
Mansfield: McGRAW-HILL INTERAMERICANA, 2018. p. 102
23
[9]
[10]
Gil, Gustavo Daniel. «HERRAMIENTA PARA IMPLEMENTAR LEL Y
ESCENARIOS(TILS).» Tesis Magister, Buenos Aires, 2002.
Sulca,
Ana
María
Quispe.
2018.
<https://repositorio.une.edu.pe/bitstream/handle/UNE/3597/MONOGRAF%c
3%8dA%20-%20QUISPE%20SULCA.PDF?sequence=1&isAllowed=y>.
[11] Roger
[12] Ibid.,
S. Pressman, Op. Cit., p. 340
p. 370
24
3.1.3. METODO PARA INTERACTUAR CON STAKEHOLDERS EN EL
LEVANTAMIENTO DE REQUERIMIENTOS
Se ha identificado a lo largo de los proyectos de software que el éxito de estos radica
en gran parte en la comunicación que debe de tener las partes involucradas, la
ingeniería de requerimientos trabajada anteriormente reúne todas estas partes
como gerentes de proyecto, desarrolladores, clientes y diseñadores para realizar el
proceso de elicitación de requerimientos de la mejor manera.
En base a lo anterior el siguiente trabajo de investigación realizado por varios
Ingenieros de sistemas de la ciudad de Cúcuta propusieron un método para llevar
a cabo de forma efectiva el levantamiento de requerimientos formado por cuatro
fases [13]:
1. Enlace con la organización: En esta fase se propone, conocer la información
organizacional en institucional de la parte a trabajar; analizar los procesos y
donde se encuentra la mayor cantidad de requerimientos solicitados y
finalmente un equipo de apoyo generando entrevistas junto con los
stakeholders.
2. Conocimiento del proyecto: En esta fase se propone el tipo de proyecto de
software a desarrollar, si es totalmente nuevo, una replantación o una
extensión; si son pequeños, medianos o grandes basados en el equipo de
desarrollo requerido para cumplir con los objetivos.
3. Identificación de stakeholders: Se propone analizar y priorizar los
Stakeholders involucrados ya que a través de su efectiva comunicación hace
que el proyecto tenga éxito. Establecer compromisos con ellos, y finalmente
dar y mantener la interacción con ellos aun después de entregado el
proyecto.
4. Captura de requerimientos: Identificar la técnica adecuada dependiendo los
tres puntos anteriores, definir los métodos de relación y comunicación con
los stakeholders y finalmente identificar los requerimientos, priorizarlos y
entregar un documento formal.
Como puntos finales, concluyen que la interacción activa por medio de los
stakeholders resulta fundamental para controlar los tiempos de entrega del software,
así como también el presupuesto del mismo.
Además, terminan afirmando que “El método propuesto facilita el formalismo
desarrollando cada actividad propuesta en las fases del método, con el desarrollo
de las actividades se obtiene un documento formal de requisitos.” [14]
25
-----------[13]
Judith del Pilar Rodriguez, Claudia Yamile Gómez y Carlos René Angarita.
«Método para interacturar con los stakeholders en el proceso de
levantamiento de requerimientos de software.» Revista Gerencia
Tecnológica Informática, 2016: 14(40), 47-56.
[14] Ibid.,
p. 55
26
3.1.4. IMPACTO DE LOS REQUERIMIENTOS EN LA CALIDAD DEL
SOFTWARE
Para finalmente verificar la relación de la calidad de un proyecto de software con los
requerimientos del mismo, se presenta un artículo de investigación de la
Universidad Distrital Francisco José de Caldas en la ciudad de Bogotá en el año
2017 donde se enfoca la calidad del software en pruebas estadísticas permitiendo
como influyen en el tiempo y costo de un proyecto.
Los requerimientos son ejecutados por personas y dados por ellas mismas haciendo
que el proceso se vea influenciado como: “factores como las perspectivas y
prejuicios de los usuarios respecto al sistema o las políticas organizacionales, lo
cual puede llegar a incidir de forma negativa en las etapas posteriores del desarrollo
de software si no se realiza una adecuada definición de los mismos”. [15]
Según el estándar IEEE 830 [16] un requerimiento define “la necesidad sobre la
funcionalidad de un sistema”, debe ser clara y concisa y cumpliendo con las
características pactadas entre las partes involucradas.
De igual manera sugiere que dentro de las principales características que debe
tener un requerimiento están:
•
•
•
•
•
•
•
•
•
Correcticidad.
No ambigüedad.
Completitud.
Verificabilidad.
Consistencia.
Priorización.
Modificación.
Exploración.
Utilización.
Según el artículo basado en múltiples estudios realizados por muchos
profesionales del área como James Martin afirma que el “56% de los defectos
encontrados en el proceso de pruebas, se debe a errores introducidos en la
fase de requisitos como resultado de requerimientos mal escritos, ambiguos
o incompletos” [17].
Resaltando además nuevamente que “el esfuerzo que implica corregir este
tipo de defectos es mucho mayor que cualquier otro (82%)” [17].
27
-----------[15] Barajas,
Cindy Tatiana Rodríguez. «Impacto de los requerimientos en la calidad
del software.» TIA, 2017: 161-173.
[16] IEEE.
«Especificación de requisitos según estándar IEE 830.» 1998.
[17] Barajas,
Op. Cit., p. 167
28
3.2. MARCO CONCEPTUAL
El siguiente marco conceptual se compone de una redacción conjunta de
definiciones referentes a la situación y el proceso de este trabajo de investigación.
Para empezar con el marco hay que involucrarse un poco en lo que se conoce como
un sistema donde según [18] se traduce como “Un conjunto organizado de cosas o
partes interactuantes e interdependientes, que se relacionan formando un todo
unitario y complejo. Cabe aclarar que las cosas o partes que componen al sistema,
no se refieren al campo físico (objetos), sino más bien al funcional.
Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen
(salida) información, productos o servicios [19]. Así pues, en el software siendo un
conjunto de programas que realizan tareas dentro de una computadora y el
desarrollo identificado como el avance a lo largo del tiempo que va evolucionando
ya sea de manera ascendente o descendente, siempre en la práctica enfocado al
primero, es importante definir el proceso general del proyecto, el ciclo de vida del
desarrollo de software.
El ciclo de vida del desarrollo del software o también conocido como SDLC o
Software Development Life Cycle en inglés, contempla las fases necesarias para
validar el desarrollo del software y así garantizar que este cumpla los requisitos para
la aplicación y verificación de los procedimientos de desarrollo, asegurándose de
que los métodos usados son apropiados [20].
Dentro de las fases necesarias para su validación se encuentra la fase de
levantamiento de requerimientos que es una de las primeras fases y más
importantes para el desarrollo de un sistema de información. Un buen levantamiento
conlleva a desarrollar un sistema lo más apegado posible a los requerimientos del
usuario final. Agregando lo anterior existe la ingeniería de requerimientos que es el
proceso de recopilar y analizar las necesidades del cliente para un sistema de
software a desarrollar para hacer su posterior entrega.
El propósito de este proceso es lograr, una especificación de requerimientos de
software lo más concreta y correctamente posible. Ahora bien, el requerimiento
define las funciones, capacidades o atributos de cualquier sistema de software.
Junto al requerimiento, el usuario final es la persona que usa el software o hardware
después de que se haya desarrollado, comercializado e instalado por completo es
por esto que es quien valida que las funcionalidades del sistema o aplicación sean
lo más precisas para su correcto funcionamiento.
29
Cabe resaltar que un sistema no trabaja completamente solo, sino que hace uso de
algunas aplicaciones ya sean de mayor o menor magnitud y funcionalidad, una
aplicación es un programa que, una vez ejecutado, permite trabajar con el
ordenador.
Para que todo lo anterior descrito funcione correctamente en su mayoría ya que un
sistema no es 100% perfecto, por el error humano, aparece la calidad del software,
que es según [21]: “el conjunto de cualidades que lo caracterizan y que determinan
su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.”
Agregando a este término, por supuesto que existen varias maneras de medir la
calidad dependiendo los objetivos que se quieren lograr con dicho software. Para
medirla y/o alcanzar esta calidad del software se debe tener:
La utilización de metodologías o procedimientos estándares para el
análisis, diseño, programación y prueba del software que permitan
uniformar la filosofía de trabajo, en aras de lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven
la productividad, tanto para la labor de desarrollo como para el control
de la calidad del software [22].
-----------[18] Bertalanffy,
Ludwig Von. Teoría General de Sistemas. Nueva York, 1968.
[19] Ibid.
[20] Pressman
Op. Cit., p. 27
[21] Oscar
M. Fernández Carrasco, Delba García León y Alfa Beltrán Benavides. Un
enfoque actual sobre la calidad del software. Técnico, La Habana: ACIMED,
1995.
[22] Ibid.
30
3.3. ESTADO DEL ARTE
Para el siguiente estado del arte presentado a continuación, se trató de hacer una
agrupación desde investigaciones a nivel internacional, pasando por el continente y
llevándolo a la parte nacional y por último local de la ciudad de Bogotá.
A nivel internacional, un buen artículo reciente es el de Ceballos, Darío Emmanuel
Vázquez.«Método de selección de técnicas de levantamiento de
requerimientos para el desarrollo de software con un enfoque de experiencia
de usuario.» Tesis, Ciudad de Mexico, 2021.
Donde se presenta una tesis donde se aborda una de las principales problemáticas
en la fase inicial del desarrollo de software conocida como ingeniería de
requerimientos. Se hace un análisis de las dificultades en las actividades que se
pueden realizar en esta etapa: como la selección inadecuadamente de técnicas de
levantamiento de requerimientos, no contar con una estrategia ni orden y
ambigüedades en el entendimiento de las necesidades de los clientes.
Para la muestra se realizó un estudio comparativo de 18 técnicas de levantamiento
de requerimientos donde, se analizaron en la literatura, en ella se presenta una
breve descripción sobre la mecánica y función de la técnica, las principales ventajas
y desventajas de su empleo, así como las referencias a las fuentes de la
información.
Se utilizaron como metodología de la tesis, un conjunto de técnicas de
levantamiento de requerimientos donde unida con la metodología de software
Scrum se pudo validar y retroalimentar sobre el trabajo por medio de encuestas a
un grupo de panelistas y asesores relacionados al tema.
Como resultados se puede obtener que el 80 % de los panelistas encuestados
coinciden con que dentro de la fase de levantamiento de requerimientos son
actividades de dificultad moderada y que se pueden realizar adecuadamente
empleando técnicas de apoyo. El anterior resultado se explica de la experiencia y
del conjunto de habilidades y estrategias que han desarrollado y perfeccionado a lo
largo de diferentes proyectos de software. Siguiendo sobre el impacto que tiene un
mal levantamiento de requerimientos sobre el proceso de ingeniería de software. El
70 % considera que es muy negativo, mientras un 30 % indica que es algo negativo
en el software resultante y sus funcionalidades.
A manera de conclusión El 100 % del panel de expertos coincide en que se puede
incluir con metodologías de desarrollo de software actuales considerando el ciclo de
vida del proceso. De igual manera el software resultante de una deficiente etapa de
levantamiento de requerimientos es reflejo de una serie de errores y fallas en la
31
implementación, que concluye en la mayoría de los casos en un software no
funcional, que no coincide con lo esperado por el cliente y los usuarios finales [23].
Otro artículo escogido a nivel internacional es el de Meinert E, Milne-Ives M,
Surodina S, Lam C Agile Requirements Engineering and Software Planning for
a Digital Health Platform to Engage the Effects of Isolation Caused by Social
Distancing: Case Study JMIR Public Health Surveill 2020;6(2): e19297 doi:
10.2196/19297 PMID: 32348293 PMCID: 7205031
Parte de sus objetivos en este caso de estudio fue:
“to provide a tool for older people and their families and peers to
improve their well-being and health during and after regulated social
distancing. First, we will evaluate the tool’s feasibility, acceptability, and
usability to encourage positive nutrition, enhance physical activity, and
enable virtual interaction while social distancing. Second, we will be
implementing the app to provide an online community to assist families
and peer groups in maintaining contact with older people using goal
setting” [24].
Para la metodología ya que el desarrollo fue en el mismo momento de publicación
del documento se seleccionó un diseño de estudio de caso para proporcionar un
medio sistemático de captura de la ingeniería de software en progreso. De igual
manera para el marco de desarrollo de aplicaciones para el diseño de software se
basó y utilizó en métodos ágiles.
Como algunos resultados se hace uso de un marco de software preexistente para
el cambio de comportamiento de salud, se desarrolló una prueba de concepto y se
creó un desarrollo e implementación de aplicaciones de varias etapas para la
solución.
Y finalmente, para concluir decidieron que este caso de estudio sienta las bases
para el desarrollo futuro de aplicaciones para combatir los problemas mentales y
sociales que surgen de las medidas de distanciamiento social. La aplicación será
probada y evaluada en futuros estudios para permitir la mejora continua de la
aplicación.
De todo este articulo rescato la manera como utilizaron el proceso de desarrollo ágil
para llevar a cabo el caso de estudio donde cito que:
La fase de descubrimiento tiene como objetivo definir de manera
eficiente los requisitos a través de un proceso estructurado, con la
posterior compilación iterativa y las pruebas durante las fases alfa,
beta y en vivo. Este enfoque también permite que los conocimientos y
32
la tecnología resultantes sean replicables, escalables y transferibles
para extender la solución a las áreas problemáticas adyacentes [25].
A nivel continental, se encontraron casos interesantes mayormente en Estados
Unidos donde comparto el siguiente:
Zowghi, D., & Coulin, C. (n.d.). Requirements Elicitation: A Survey of
Techniques, Approaches, and Tools. Engineering and Managing Software
Requirements, 19–46. doi:10.1007/3-540-28244-0_2
La temática en este capítulo del libro es la elicitación de requerimientos siendo
entendido como el descubrimiento y la evolución de elementos que la componen
uniendo muchas actividades aprovechando técnicas, acercamientos y herramientas
para trabajarla.
Son muchas las formas de elicitar y cada una de ellas tiene ventajas y desventajas
dependiendo el contexto y la situación. El objetivo, así pues, es resaltar y analizar
los aspectos importantes de estas técnicas y herramientas, examinando a su vez
los diferentes problemas, tendencias y retos que enfrentan investigadores y actores
en este campo.
Sobre este estudio extraigo a manera de conclusiones los siguientes puntos:
1. Es importante al inicio de este proceso, investigar y examinar detalladamente
la situación o como la llaman [26] “el mundo real”, donde el sistema residirá
finalmente. El entorno del sistema necesita ser explorado en cada aspecto
(político, organizacional, social, entre otros) así como adicionar las
limitaciones que tenga.
2. Los requerimientos son entregados de muchas maneras y presentados en
diferentes formatos. Y existen muchas fuentes de requerimientos entre los
que se encuentran los stakeholders, los usuarios y expertos para adicionar
información detallada de las necesidades de los primeros.
3. Analizar los stakeholders y filtrarlos de acuerdo a su participación e influencia
en el proceso hace que se identifiquen los factores claves del producto.
4. Although some may advocate that just one elicitation technique or a single
methodology is sufficient and may be applied to all cases, it is generally
accepted that an individual requirements elicitation technique or approach
cannot possibly be suitable for all projects [27].
Y finalmente agrego nuevamente que como lo dicen en este estudio: “Clearly
requirements elicitation is best performed using a variety of techniques. In the
33
majority of projects several methods are employed during and at different stages in
the software development life cycle, often in cooperation where complementary”
[28].
Donde se sustenta de manera clara y clave la razón de la fase de análisis de este
trabajo el cual permite decir por qué se plantea el uso de varias técnicas unido con
una metodología clave en el contexto y situación de la empresa, pero esto lo
veremos más adelante.
Y finalmente a nivel nacional y local aparecen los siguientes casos de relevancia en
el contexto de este trabajo:
Suárez, L. M. (2019). CALIDAD EN EL LEVANTAMIENTO
REQUERIMIENTOS EN PROYECTOS DE SOFTWARE. Articulo
Investigación, Bogotá D.C.
DE
de
Donde el objetivo de este trabajo fue la investigación de las diferentes técnicas para
el levantamiento de requerimientos y que fomentan el éxito en los proyectos de
software cumpliendo tanto en calidad como en el tiempo estimado.
Las investigaciones apuntaron a que la lluvia de ideas (Brainstorming) y mesas de
trabajos (Workshops) que junto con la estructura del HPVA (Hacer, Planificar,
Verificar y Actuar) eran las técnicas que más se ajustan a las necesidades del cliente
y donde el levantamiento de requerimientos tenga esa calidad construida desde el
inicio del proyecto.
Porque como lo mencionan en el artículo esta etapa en el ciclo del software se
realiza utilizando una metodología y varias técnicas, donde si bien existen, permiten
de manera clara y precisa determinar los requisitos esenciales para los diferentes
tipos de productos o servicios a diseñar y desarrollar.
Y a su vez reiteran en la calidad del diseño como medir: “el acierto del proyecto
desarrollado para traducir los requisitos de calidad escuchados por la dirección en
especificaciones técnicas o normas de calidad para la elaboración o prestación del
producto y de este modo lograr la calidad total del producto [29]”.
A manera de conclusión después de que se encuestara al personal de la empresa
sobre las técnicas a utilizar donde las mesas de trabajo y lluvia de ideas eran las
más conocidas para ellos y más fáciles de aplicar con un 80% y un 40%
respectivamente, definen que:
Es perceptible que la correcta elección de una técnica de
levantamiento de requerimientos es primordial en el transcurso del
desarrollo de proyectos de software, puesto que beneficia no
34
solamente al cliente que es lo más importante del proceso sino
también a las empresas que buscan posicionarse satisfactoriamente
en el mercado y brindar un buen servicio con excelente calidad. De
igual forma, siempre es necesario realizar un análisis de las
dificultades a las cuales se enfrenta el proceso para de esta forma
localizar los beneficios que ofrece cada técnica y ser selectivos con la
que se acerca a las necesidades que solicita el cliente [30].
De este trabajo doy la importancia a como se asegura que es necesario para realizar
una buena etapa de levantamiento de requerimientos el tener una metodología junto
con técnicas o herramientas que permitan adecuarse a las necesidades del cliente
y el contexto de la empresa.
Finalmente comparto este trabajo realizado hace varios años pero que no deja de
ser importante las cifras sobre la manera como se realiza el desarrollo de software
en Pymes en Bogotá D.C:
Alexandra Abuchar Porras, B. C. (2012). Observatorio de prácticas de
desarrollo de software en MinPyme y pymes de Bogotá. Trabajo de
Investigación, Bogotá D.C.
El objetivo principal del artículo fue detectar las prácticas de desarrollo de software
en las pequeñas y medianas empresas de Bogotá.
Para la fase uno de esta investigación quiso obtener información sobre el
movimiento de las pequeñas empresas en Bogotá y cuál era su producción, a que
se dedicaban y como proveían sus servicios.
Dentro de las cadenas productivas encontraron que, la de servicios es la de mayor
demanda y, debido a que es utilizada por las demás, en esta está el clúster de
software.
Y además tomando peso la siguiente justificación donde se asegura que:
En Colombia la industria de software tiene el potencial de convertirse
en un sector económico de gran impacto, que pueda incluso suplir la
demanda interna y llegar con éxito a los mercados del exterior.
También, por ser este un sector que involucra el manejo transversal a
nivel empresarial, puede apoyar y brindar soporte, agilizando los
procesos, facilitando la comunicación y reduciendo los cos-tes de
operación [32].
35
Además, se estimó en ese año que el 98 % de las empresas de software en
Cundinamarca se encontraban en Bogotá D.C, el otro 2% venia de ciudades
aledañas como Chía, Soacha, Fusagasugá, entre otras.
De esta primera fase del proyecto hago énfasis en esta frase que me llama
la atención y que es esencial aportando al trabajo: “La calidad de un sistema
software depende de la calidad del proceso usado para su desarrollo [33]”.
Para la segunda fase la investigación se enfocó en una muestra donde se obtuvo la
información de 100 empresas, cuyo único criterio de selección era pertenecer al
rubro del desarrollo de software. Luego de llevar a cabo la selección, se procedió a
la aplicación de un instrumento, conformado por 20 ítems, que permitió identificar
las determinadas prácticas de desarrollo del software.
Como conclusiones finales de las 20 preguntas o ítems realizados se obtienen de
[34] como relevantes que:
1. Los proyectos de software están dentro del rango de proyectos cortos con un
53% y con entregas exitosas, aunque se ha podido determinar una
generalizada demora en la entrega final.
2. Se detectó que hace falta conocimiento en la utilización de los estándares de
calidad de desarrollo de software, tanto por parte de las empresas como de
las personas. Así mismo, las empresas que cuentan con algún plan estándar
no lo dan a conocer a los empleados.
3. Las empresas del sector estudiado en esta investigación, no llevan una
metodología, la mayoría no lleva un modelo de desarrollo, no conoce los
estándares de calidad, no lleva una documentación adecuada de sus
productos y la planeación de las actividades presenta mu-chas falencias. De
allí que el 84% de las entregas anuales presente demoras.
-----------[23] Ceballos,
Darío Emmanuel Vázquez. «Método de selección de técnicas de
levantamiento de requerimientos para el desarrollo de software con un
enfoque de experiencia de usuario.» Tesis, Ciudad de Mexico, 2021.
[24] Edward Meinert, MA, MSc, MBA, MPA, PhD. «Agile Requirements Engineering
and Software Planning for a Digital Health Platform to Engage the Effects of
Isolation Caused by Social Distancing: Case Study.» JMIR Publications,
2020: 10.
[25] Ibid.
[26] Coulin, Didar Zowghi and Chad. «Requirements Elicitation: A Survey of
Techniques, Approaches and Tools.» En Engineering and Managing
36
Software Requirements, de A., & Wohlin, C. Aurum, 19-41. New York:
Springer, 2005.
[27] Ibid.
[28] Ibid.
[29]
Suárez, L. M. (2019). CALIDAD EN EL LEVANTAMIENTO DE
REQUERIMIENTOS EN PROYECTOS DE SOFTWARE. Articulo de
Investigación, Bogotá D.C.p. 9
[31] Ibid.
p.12
[32] Alexandra
Abuchar Porras, B. C. (2012). Observatorio de prácticas de
desarrollo de software en MinPyme y pymes de Bogotá. Trabajo de
Investigación, Bogotá D.C.
[33] Ibid.
[34] Ibid.
p.120
p.129
37
4.ALCANCES Y LIMITACIONES
Alcances:
● El proyecto se enfoca esencialmente en la creación de una guía de calidad
basándose en las referencias sobre calidad en levantamiento de
requerimientos que se ajusten a las características, la situación actual y la
operación en la PyME.
● El presente proyecto no representa un modelo de referencia para cualquier
empresa de logística de transporte ya sea en la ciudad o en todo el territorio
para verificar la calidad del proceso de levantamiento de requerimientos en
el ciclo de desarrollo del software, pero puede tomarse como guía para
trabajos similares y futuros.
Limitaciones:
● La PyME de logística de transporte queda a discreción de seguir utilizando o
no la guía de calidad propuesta, lo anterior limitando su implementación a
una segunda fase del proyecto.
● Sujeto a temas de confidencialidad por parte de la PyME, todas las
actividades realizadas no serán tenidas en cuenta dentro de la guía de
calidad, pero si se trataran las disponibles y esenciales para validar el
proceso de levantamiento de requerimientos de software.
● Al llevar a cabo el diseño de la guía de calidad, esta estará compuesta y
articulada por características útiles tomadas en consideración de la norma
ISO 25010 y las metodologías SCRUM y TSP, permitiendo adaptarlas mejor
a la PyME y su funcionamiento.
38
5.METODOLOGÍA
5.1 ENFOQUE METODOLÓGICO
El presente trabajo de grado estará desarrollado bajo el enfoque mixto, ya que, a
diferencia de otros, es el que mejor se adapta a las necesidades y a la situación
actual de la empresa.
El enfoque mixto es un proceso que reúne el enfoque cuantitativo y cualitativo para
su posterior inferencia. El enfoque cuantitativo utiliza el análisis y la recolección de
datos numéricos para responder preguntas de investigación y comprobar hipótesis
de manera exacta. Por otra parte, el enfoque cualitativo recolecta datos no
numéricos para descubrir otra interpretación sobre los resultados finales.
Para el enfoque mixto se tomará en el enfoque cualitativo la técnica de investigación
focus-group junto con el instrumento de cuestionario con preguntas abiertas, para
recolectar la opinión y/o percepción de cada persona frente al proceso que se va a
realizar.
Para el enfoque cuantitativo la técnica de investigación será encuestas con el
instrumento de preguntas cerradas para puntuar de forma clave las diferencias de
los procesos antes de aplicar la guía y después de aplicarla.
De igual manera se pretende como primer paso en el enfoque cuantitativo la técnica
de investigación ‘observación’ realizando una guía de la misma para tener la opinión
al respecto sobre la situación actual en la fase de requerimientos de la PyME.
5.2 FASES DEL PROYECTO
A continuación, se plantean las siguientes fases:
Fase 0 – Planeación
Durante esta etapa, se realiza la adquisición de formatos y el levantamiento de
información a partir de fuentes primarias, para lo cual se identifican los aspectos de
recurso humano, recurso financiero, cronograma y la misma metodología.
Fase 1 – Inicio o Diagnóstico
En esta etapa, se realiza el estudio y valoración del proceso de levantamiento de
requerimientos en la PyME de logística de transporte, verificando los pasos que lo
39
integran, revisando en profundidad si tienen algún procedimiento que realizan para
tal fin y sobre la opinión actual de los involucrados en el proceso.
Fase 2 – Análisis
En esta etapa, se estudia e investiga a fondo sobre las normas existentes para la
calidad del software enfocadas en la fase de levantamiento de requerimientos y se
hace una elección reuniendo todas las variables que permitirán alcanzar los
objetivos del proyecto y adecuarse a la situación actual de la empresa.
Fase 3 – Diseño
En esta etapa, se propone diseñar la guía con un conjunto de pasos en un formato
estructurado realizado por el encargado del proyecto basado en el conjunto de
normas y metodologías elegidas en la etapa de análisis donde se propone mejorar
las ineficiencias en el levantamiento de requerimientos que se hayan encontrado en
la fase 1.
Fase 4 – Resultados
Aplicar la guía diseñada, evaluando su grado de eficiencia y concluir respecto a ella.
Verificando que se globalice todos los subprocesos que conlleva el levantamiento
de requerimientos del software de la empresa. Concluyendo junto con el personal
de la empresa o de forma grupal, si resultó efectiva, qué cambios notaron, y que se
puede rescatar de lo realizado.
Fase 5 – Cierre
Retroalimentar sobre el antes y después de haber aplicado la guía de forma
personal, dando conclusiones y opiniones sobre lo realizado durante el trabajo de
grado y sobre futuros proyectos.
40
6. CRONOGRAMA
A continuación, se presenta el cronograma del proyecto, ajustándose a la
metodología y a las fases del mismo, dentro de cada fase se planean una serie de
actividades para la completitud de estas y posteriormente la del proyecto.
Figura 1. Cronograma del proyecto
41
7. PRODUCTOS A ENTREGAR
PRODUCTOS A ENTREGAR
TIPO
NOMBRE DEL PRODUCTO
FECHA DE ENTREGA
Diagnóstico
17 de agosto, 2021
Análisis investigativo
Documento
Evaluación
Diagnóstico
sobre
el
levantamiento
de
requerimientos
de
la
empresa actualmente.
Análisis de las normas
vigentes de calidad del
software.
Guía de calidad para el
correcto levantamiento de
requerimientos
Evaluación de la aplicación
de la guía de calidad.
02 de septiembre, 2021
4 de octubre, 2021
28 de octubre, 2021
Tabla 1. Productos a entregar
42
8. INSTALACIONES Y EQUIPO REQUERIDO
Para el diagnóstico de la situación actual sobre el levantamiento de requerimientos
de software en la empresa se utilizarán las siguientes herramientas:
● Recolección de Datos: proceso de recolectar (reunir, recoger o cosechar
algo). Un dato, por su parte, una información que permite generar un cierto
conocimiento.
Para la fase de análisis de las normas de calidad del software, se pretenden realizar
por medio de:
● Cuadro comparativo y a futuro otros diagramas que permitan ver de manera
clara y precisa las variables que ofrecen las diferentes normas o
metodologías para aplicar en la situación de la empresa y cumplir los
objetivos del proyecto.
Para la fase de evaluación de la guía y sobre el proceso actual de levantamiento de
requerimientos se pretenden realizar este tipo de encuestas:
● Encuesta de opción múltiple: Permiten de una manera simple y directa
cuantificar los resultados sobre preguntas específicas para las conclusiones
finales.
● Encuesta de Respuesta abierta: Estas permiten al encuestado tener la
libertad de responder libremente cada pregunta, esto permite obtener
respuestas más profundas y enfocadas a la percepción de la persona.
Aunque son difíciles de cuantificar, se utilizarán también las de opción
múltiple.
43
9. PRESUPUESTO DEL TRABAJO
A continuación, se presenta el presupuesto del trabajo de grado dividido en tres
presupuestos y consolidado en un último presupuesto llamado presupuesto general
del proyecto:
El presupuesto preliminar viene siendo los costos realizados en la fase 0 de
planificación y organización la cual plantea utilizar dos escritorios o mesas de
trabajo, una pequeña capacitación de organización y como se va trabajar para
realizar el proyecto de grado y finalmente una capacitación de empleados sobre lo
que se va realizar y en que se va a trabajar específicamente.
Figura 2. Presupuesto preliminar.
El presupuesto del personal es los costos de tener a las personas requeridas e
involucradas durante el proyecto:
El personal de la empresa está constituido por dos ejecutivas de cuenta y un programador
web.
Figura 3. Presupuesto del personal
El presupuesto de gastos generales tendrá todos los bienes y servicios a consumir, de
igual forma los implementos que se requieran y los imprevistos que ocurran, todo esto a lo
largo de la duración del proyecto
44
Figura 4. Presupuesto de gastos generales
Finalmente, en el presupuesto general es el total de los presupuestos anteriores, y que da
espacio al total del proyecto como tal.
Figura 5. Presupuesto general del proyecto
45
10. ESTRATEGIAS DE COMUNICACIÓN Y DIVULGACIÓN
• Socialización de los resultados del proyecto en la sustentación del
proyecto de grado.
• Publicación del trabajo de grado en el repositorio institucional de la
Universidad Católica de Colombia.
• Entrega del artículo sobre el proyecto de grado de una guía para la
mejora en el levantamiento de requerimientos de software en una
PyME de logística de transporte
.
46
11. DESARROLLO DE LA PROPUESTA
Según lo expuesto en la metodología del trabajo y continuando con la fase 1 donde
se realiza un estudio propio detallado del proceso de levantamiento de
requerimientos en la PyME de logística de transporte, se verificaron por medio de
dos formatos el proceso actual de la empresa: Un diagnóstico de fuente propia sobre
el diligenciamiento de los requerimientos dentro de una pyme de logística de
transporte y un formulario realizado con la herramienta Google Forms sobre la
opinión y evaluación del proceso de levantamiento de requerimientos actual en la
empresa por parte de los involucrados en el proceso de desarrollo.
11.1
DIAGNÓSTICO
REQUERIMIENTOS.
PROPIO
SOBRE
EL
LEVANTAMIENTO
DE
Para este diagnóstico se diseña y se crea un formato donde se hace énfasis en la
descripción del requerimiento, tal cual como se haya dictado o expuesto dentro del
personal de la empresa y/o equipo involucrado.
Se toman tiempos en la hora de inicio del requerimiento (desde que se solicita), y
hora fin (hasta que se entrega) y es aprobado por el cliente como verificación de la
satisfacción con el desarrollo realizado. Además, se especifica como ítem adicional
la diferencia en horas y/o minutos según sea el caso de lo que el requerimiento toma
en tiempo para contestarse.
De igual manera se pide elegir el medio de contacto para ver después en un análisis
los medios mas utilizados para la elicitación de requerimientos. Además, se realizan
preguntas sobre el entendimiento de requerimiento, si se solicita mas información o
aclaración del mismo, el porqué de esta solicitud y finalmente cuantos ajustes o
correcciones se realizan después del primer desarrollo terminado por parte de los
programadores.
Para este proyecto durante varias semanas y en cumplimiento con la aleatoriedad
se eligieron sin ninguna preferencia diecisiete (17) requerimientos para ser
registrados en el formato. Ver descripción ampliada en el anexo A – Formato de
diligenciamiento de requerimientos en una pyme de logística de transporte.
47
11.2 EVALUACIÓN DEL PROCESO ACTUAL DE LEVANTAMIENTO DE
REQUERIMIENTOS.
La siguiente evaluación que se realiza consta de 11 preguntas donde se pudo
obtener información acerca de los involucrados en el proceso de desarrollo y en
especial el proceso de levantamiento de requerimientos de software (roles). Se
realiza en el mes de agosto del presente año, cumpliendo con los tiempos del
cronograma del proyecto. Todos los miembros reconocen que existe un estándar
para el proceso de levantamiento de requerimientos antes y después de
implementado el software, por supuesto no existe solo un estándar y se deja la
pregunta de modo general para que sea mejor recibida y entendida por parte de los
encuestados.
Sobre los encuestados, el 75% afirma creer que existe una estandarización del
proceso de levantamiento de requerimientos de software mientras que el 25% dice
lo contrario. Mostrando ya una división de opiniones, como se aprecia en la fig.6
Figura 6. Pregunta 4 evaluación del proceso actual de levantamiento de requerimientos
Sobre los medios de comunicación para el levantamiento de requerimientos todos
estuvieron de acuerdo en que el correo electrónico y teléfono celular son los principales
métodos para dialogar con los clientes y atender las necesidades por medio de la
elicitación de requerimientos.
Por otro lado, aunque todos estuvieron entre un medio (3) y un alto (4) índice de
que estos medios de comunicación generan dudas, inconvenientes, preguntas,
48
problemas, quejas o reclamos fig.7, creen de igual forma que el proceso actual de
levantamiento de requerimientos en efectividad es aceptable (3) y bueno (4), fig.8.
Figura 7. Pregunta 6 evaluación del proceso actual de levantamiento de requerimientos
Figura 8. Pregunta 7 evaluación del proceso actual de levantamiento de requerimientos
A continuación, dando como sustento la presente investigación dentro del trabajo se
presentan las respuestas donde justifican porqué debería, aunque los resultados son
buenos, replantear o mejorar la metodología en el levantamiento de requerimientos de
software y la manera como se lleva a cabo fig. 8 y fig. 9.
49
Figura 9. Pregunta 8 evaluación del proceso actual de levantamiento de requerimientos
Figura 10. Pregunta 9 evaluación del proceso actual de levantamiento de requerimientos
Finalmente, para resaltar una ultima pregunta de la encuesta donde se justifica
según [35] donde afirma que, “La necesidad que tiene la industria de disponer de
nuevas propuestas que contribuyan al mejoramiento de la calidad a través del
proceso de requisitos…”.
Se podría suplir basado en procedimientos que nuevamente [36], “…no requieran
de personas expertas en el área de requisitos al momento de su aplicación ni
tampoco la necesidad de contar con conocimiento específico en lenguajes formales
para especificar requisitos…”
50
Donde complementando a lo expuesto anteriormente, las características de esta
nueva propuesta estarían basada según las opiniones dadas en la siguiente
pregunta realizada dentro de la evaluación.
Figura 11. Pregunta 10 evaluación del proceso actual de levantamiento de requerimientos
Con lo descrito anteriormente podremos pasar a la fase 2 del proyecto donde se
hace a modo de estado el arte, un estudio analítico sobre las diferentes normas y
metodologías existentes y que se adapten a las necesidades de la empresa
-----------[35] Peláez,
A. T. (2016). Ingeniería de Requisitos: de la especificación de requisitos
de software al aseguramiento de la calidad. Como lo hacen MiPymes
desarrolladoras de software de la ciudad de Pereira. Pereira.
[36] Ibid.
p.121.
51
11.3 ESTUDIO ANALITICO SOBRE NORMAS Y METODOLOGIAS ENFOCADAS
EN EL LEVANTAMIENTO DE REQUERIMIENTOS DE SOFTWARE.
Para esta fase 2 se realiza un cuadro comparativo analítico. Ver descripción
ampliada en el anexo B – Cuadro analítico sobre metodologías y normas enfocadas
en el levantamiento de requerimientos de software.
Cabe resaltar que en esta fase y en conjunto con el desarrollo del cuadro
comparativo analítico se estudió e investigó a nivel internacional las normas
utilizadas, pero también según lo expuesto por Min Tic para Colombia donde es el
área que se encuentra la PyME de logística de transporte a estudiar.
Este cuadro analítico se conforma separado por normas y metodologías ya que
técnicamente no se pueden elegir entre estas dos por tratarse de conceptos
diferentes, sino que a su vez se reunieron un conjunto de normas y un conjunto de
metodologías donde cada conjunto es comparado en cuanto a las ventajas ,
desventajas, el contexto organizacional donde se pueden trabajar y aplicar ya sea
un conjunto o el otro y finalmente los recursos útiles y no útiles de cada uno de estos
conjuntos que serán trabajados en la guía a diseñar.
Solo para ampliar, las normas estudiadas y analizadas fueron:
•
•
•
•
ISO 9001: Requisitos sistema de gestión de calidad
ISO 12207: Procesos ciclo de vida del software
ISO 25010: Parámetros para la calidad del producto software
IEEE 830: Especificación de requerimientos de software*
De igual manera las metodologías fueron:
•
•
•
•
SCRUM
TSP
PSP
CMMI
-----------*No es una norma, aunque representa un estándar sobre la especificación de
requerimientos de software.
52
Cabe resaltar que, según el alcance del presente proyecto, las normas y/o
metodologías que fueran seleccionadas en esta fase no se trabajarían
completamente sino por el contrario, se extraerían características principales y que
fueran útiles para la creación del diseño de la guía.
Finalmente en esta etapa se eligió la norma ISO 25010 junto con las metodologías
SCRUM y TSP ya que en resumidas palabras aunque se puede apreciar en el anexo
a profundidad los ítems a evaluar, eran las que presentaban mejores recursos útiles
a trabajar dentro del contexto organizacional de la PyME y que permitía de igual
manera y de acuerdo con la evaluación por parte de los empleados no reestructurar
y cambiar completamente la manera como se trabaja el proceso de levantamiento
de requerimientos.
11.4 DISEÑO DE LA GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE
REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGÍSTICA DE
TRANSPORTE.
53
UNIVERSIDAD CATÓLICA DE COLOMBIA - FACULTAD
DE INGENIERÍA
FORMATO GUÍA PARA LA MEJORA EN EL
LEVANTAMIENTO DE REQUERIMIENTOS DE SOFTWARE
EN UNA PYME DE LOGÍSTICA DE TRANSPORTE
CARLOS ANDRÉS RODRÍGUEZ SILVA - 67000100
PROGRAMA INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN
BOGOTÁ D.C
2021
54
HOJA DE INFORMACIÓN GENERAL
Control Documental:
Proyecto:
GUÍA PARA LA MEJORA EN EL LEVANTAMIENTO DE
REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGÍSTICA DE
TRANSPORTE
Entidad:
ESTUDIANTE CARLOS ANDRÉS RODRÍGUEZ SILVA
PERTENECIENTE AL PROGRAMA DE INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN DE LA UNIVERSIDAD CATÓLICA DE COLOMBIA,
Versión: 2.1
Fecha: 10-11-2021
Nombre: Formato_Guia_Calidad_v2.1_2021pyme
Resumen:
GUIA PARA LA MEJORA EN EL LEVANTAMIENTO DE
REQUERIMIENTOS DE SOFTWARE EN UNA PYME DE LOGISTICA DE
TRANSPORTE EN LA CIUDAD DE BOGOTÁ D.C COLOMBIA.
55
CONTROL DE VERSIONES
Fuente de cambio
Fecha
Versión Solicitante ¿Cambio
Descripción
Fecha
de
autorizado? breve
del del
solicitud
cambio
cambio
realizado
Formato_Guia_Calidad_v1.0_2021pyme.docx 1.0
Formato_Guia_Calidad_v1.0_2021pyme.docx 2/NOV
2.0
Ejecutiva
Si
Correcciones 3/NOV
de cuenta
de redacción
y sintaxis
Formato_Guia_Calidad_v2.0_2021pyme.docx 8/NOV
2.1
Si
Correcciones 9/NOV
de títulos y
párrafos
Formato_Guia_Calidad_v2.1_2021pyme.docx
56
ÍNDICE
INTRODUCCIÓN ............................................................................................................. 58
APLICACIÓN ................................................................................................................... 58
ESTRUCTURA ................................................................................................................ 58
1.MODELO DE LA CALIDAD EN EL PRODUCTO .......................................................... 59
2.MODELO DE LA CALIDAD EN EL PROCESO ............................................................. 60
3.MODELO DE LA CALIDAD EN LA ORGANIZACIÓN, ESTRUCTURA Y
COMUNICACIÓN ............................................................................................................ 63
GLOSARIO ...................................................................................................................... 64
BIBLIOGRAFÍA ................................................................................................................ 65
57
INTRODUCCIÓN
La presente guía está basada en la norma ISO 25010 aplicándose junto con algunas
de las características de las metodologías SCRUM y TSP en conjunto.
Es importante resaltar que esta normas y metodologías escogidas fueron
seleccionadas previamente según un análisis investigativo realizado en un trabajo
de grado donde se analizaron las variables del contexto organizacional, ventajas y
desventajas entre normas y metodologías y finalmente las características a utilizar
según el modo de operar de la empresa y el recurso humano con el que cuenta.
El proceso de levantamiento de requerimientos tiene como objetivo garantizar que
el producto desarrollado y entregado cumpla con las necesidades expuestas por el
cliente previamente. Para lograrlo y al mismo tiempo contar con un mínimo de
calidad, según lo anterior, es importante realizar un conjunto de actividades y
buenas prácticas para mejorar los procesos que se tengan, para maximizar los
recursos en tiempo y costos, y finalmente generar la relevancia y la diferencia que
genere la satisfacción de los que vayan a utilizar ese producto y los involucrados.
APLICACIÓN
•
•
•
La presente guía no pretende asegurar la calidad dentro del proceso de
levantamiento de requerimientos ya que esta palabra es subjetiva y no es
algo que tenga un valor global específico para saber si se cuenta con ella o
no.
Esta guía es aplicable solamente a la PyME de logística de transporte
estudiada y analizada previamente en el trabajo de grado realizado. No
pretende ser una guía para empresas con características similares, aunque
puede ser tomada en cuenta para estudios futuros.
Esta guía debe ser utilizada en su totalidad por la PyME a tratar y se evaluará
solo la fase de levantamiento de requerimientos según el ciclo de vida del
desarrollo de software empleado en ella.
ESTRUCTURA
La siguiente guía se compone de tres partes explicadas a continuación:
1. Modelo de la calidad en el producto:
2. Modelo de la calidad en el proceso.
3. Modelo de la calidad en la organización, estructura y comunicación.
58
1.MODELO DE LA CALIDAD EN EL PRODUCTO
Para la primera parte centrada en el producto a entregar, se establece según la
norma ISO 25010, que un producto se debe componer de 8 características básicas
las cuales deben ser:
•
•
•
•
•
•
•
•
Adecuación funcional: Proporcionar funciones que satisfacen las
necesidades del cliente, declaradas e implícitas según las condiciones
dadas.
Eficiencia del desempeño: Desempeño relativo según los recursos
utilizados.
Compatibilidad: Capacidad entre sistemas o componentes para
intercambiar información, compartiendo el entorno y realizando las debidas
funciones.
Usabilidad: Capacidad del producto software para ser entendido, aprendido,
usado y resultar atractivo para el usuario.
Fiabilidad: Poder desempeñar funciones especificadas dentro de unas
condiciones y tiempos determinados.
Seguridad: Protección de datos para que terceros no autorizados no puedan
leerlos o modificarlos.
Mantenibilidad: El producto puede ser modificado de manera efectiva según
las necesidades de evolución, corrección y perfeccionamiento.
Portabilidad: Puede ser transferido el producto o componente de forma
efectiva de un entorno hardware, software o de utilización a otro.
Lo anterior permite describir la manera como se debería evaluar un producto ya sea
un sistema, o como se trabaja actualmente múltiples y pequeños componentes
(módulos) que hacen que sean el foco principal de la evolución del sistema.
Desde el inicio de la creación del sistema de logística de transporte, alguna de estas
características ya ha sido definidas e identificadas en el contrato del proveedor y el
cliente, pero existen otras que se deberían continuar trabajando y mejorando para
generar más calidad el producto y/o servicio entregado.
59
2.MODELO DE LA CALIDAD EN EL PROCESO
Para la segunda parte centrada en el proceso propio de levantamiento de
requerimientos es importante tener en cuenta alguno de los aspectos que nos
sugiere la norma ISO 12207 donde tenemos:
1. Ciclo de vida del software o sistema:
Figura 01: Ciclo de vida del desarrollo de software estándar – Fuente: Elaboración propia
2. Tipo de software: En nuestro caso el tipo de software, es independiente.
3. Rol Ciclo de vida: Dentro de los roles en el ciclo de vida, nos determinamos
como proveedores, desarrolladores y mantenedores.
4. Modelo de desarrollo: El modelo de desarrollo en la PyME vendría siendo
cascada
Figura 02: Modelo de desarrollo de cascada – Fuente:
https://blog.comparasoftware.com/modelo-de-desarrollo-en-cascada/
60
5. Características del proyecto: Se identifica que el proyecto es un sistema
desarrollado y terminado hace varios años atrás, y que se ha venido
evolucionando, mejorando y haciendo el correcto mantenimiento para su
sostenimiento y adecuación a cada empresa cliente de transporte trabajada.
Para el proceso de levantamiento de requerimientos es importante definir las
prioridades de los requerimientos y los formatos o medios de comunicación según
cada caso:
Ya que el tema a tratar dentro de la PyME es el transporte, en la mayoría de casos
el tiempo de respuesta es indispensable y es una labor que requiere de mucha
concentración y rapidez para mantener los procesos al día, tanto en la empresa
proveedora como en los clientes. Se ha identificado que existen procesos divididos
por prioridad así:
Prioridad Baja: Tareas de desarrollo de medio o gran tamaño que son
comunicadas por correo y en espera de respuesta de 2 a 4 semanas. No interfieren
con la operación del transporte.
Prioridad Media: Tareas relevantes que de una manera u otra paran la operación
parcial de los clientes. El tiempo de solución varía según el caso que se presente
en el sistema.
Prioridad Alta: Tareas urgentes comunicadas por llamada telefónica que necesitan
ser resueltas de inmediato dando solución la mayoría de veces en un plazo no
mayor a 15 minutos.
En base al estándar IEEE 830 de levantamiento de requerimientos se debería tratar
de especificar un formato del proceso donde se indique principalmente, después de
haberse dialogado con el cliente lo siguiente:
•
Empresa solicitante, característica del requerimiento, descripción del
requerimiento, modulo o punto donde se pretende implementar y prioridad
del requerimiento.
61
Figura 03: Diseño formato de requerimiento en la PyME – Fuente: Elaboración propia
Lo anterior para despejar dudas sobre algún requerimiento que se tenga, así como
el alcance y la necesidad a resolver primordialmente. Eliminando pérdidas de tiempo
y/o soluciones no adecuadas
62
3.MODELO DE LA CALIDAD EN LA ORGANIZACIÓN,
ESTRUCTURA Y COMUNICACIÓN
Finalmente, en la tercera parte se pretende establecer la organización, estructura y
comunicación dentro de la PyME para brindar un servicio realizando buenas
prácticas de calidad en los procesos que se llevan a cabo.
Junto con la norma ISO 25010 se puede aplicar varias metodologías a nivel personal
y de equipo, entre ellas para los desarrolladores se cuenta con PSP (Personal
Software Process) – Proceso de desarrollo personal: Donde rescatamos de esta
metodología y que sea aplicable al proceso de la organización en el desarrollo de
software, el análisis sobre cómo se está llevando a cabo la forma de programar,
como he evolucionado, que tanto tiempo estoy invirtiendo en cada requerimiento,
que buenas prácticas de codificación estoy utilizando.
Necesitamos tener resueltas estas variables anteriores para realizar el TSP (Team
Software Process) para aquí poder realizar las 2 de 3 fases que lo componen:
•
•
Fase de lanzamiento: Los equipos de desarrollo ya están construidos, así
que lo siguiente es establecer las metas, establecer las tareas a realizar
(requerimientos a responder) y evaluar los riesgos que se tomen en caso de
que sea necesario.
Fase de ejecución: Nuevamente ya en conjunto con todo el equipo
(Desarrolladores, ejecutivas de cuenta y gerencia) realizar el seguimiento de
esfuerzo (en tiempo e implementaciones) y la calidad lograda con el esfuerzo
realizado.
Añadiendo a lo anterior, se identifica junto con las metodologías anteriores, se está
utilizando actualmente parte de la metodología ágil SCRUM donde se debe realizar
e identificar los roles:
•
•
•
Product Owner: Donde es el responsable de maximizar el trabajo del equipo
de desarrollo, además de conocer el sistema y el negocio en el que se
encuentra.
Scrum Master: Se encarga de que todas las técnicas descritas en esta guía
sean realizadas correctamente, además de aclarar dudas al equipo de
desarrollo.
Equipo de desarrollo: Realizar las tareas priorizadas, deben ser
multifuncionales y autoorganizados.
Finalmente se debe realizar en base a esta metodología ágil reuniones, según el
contexto de la empresa al menos semanales para resumir lo que se ha venido
trabajando, lo que se está realizando y cuáles serían las dudas que salieron de
requerimientos y/o casos nuevos.
63
GLOSARIO
•
•
•
•
•
•
•
Ciclo de vida del desarrollo de software: Comprende las fases necesarias
para validar el desarrollo del software y así garantizar que este cumpla los
requisitos para la aplicación
IEEE 830: Estándar creado por un conjunto de recomendaciones para la
especificación de los requerimiento o requisitos de software el cual tiene
como producto final la documentación de los acuerdos entre el cliente y el
grupo de desarrollo
ISO 25010: Parte de la familia de normas 25000, es una norma donde se
determinan las características de calidad que se deben tener en cuenta en el
momento de evaluar las propiedades de un producto software terminado.
Metodología Ágil: Métodos de ingeniería del software basados en el
desarrollo iterativo e incremental, donde los requisitos y soluciones
evolucionan con el tiempo.
PSP: Conjunto de prácticas disciplinadas para la gestión del tiempo y mejora
de la productividad personal de los programadores
SCRUM: Es una forma de trabajo de la metodología Ágil mediante la cual a
través de prácticas colaborativas se minimizan todo tipo de riesgos en la
elaboración de un proyecto.
TSP: En combinación con PSP, proporciona un marco de trabajo de procesos
definidos que está diseñado para ayudarle a equipos de gerentes e
ingenieros a organizar y producir proyectos de software.
64
BIBLIOGRAFÍA
Abellán, E. (05 de 03 de 2020). We Are Marketing. Obtenido
https://www.wearemarketing.com/es/blog/metodologia-scrum-que-es-ycomo-funciona.html
de
Andres Gallegos Velazquez, P. A. (2011). ELABORACIÓN DEL ESTANDAR DE
APLICACIÓN DE LA NORMA ISO 12207, AL DESARROLLO DE
APLICACIONES DE SOFTWARE PARA LA UTIC DE LA ESPE.
EcuRed.
(2011).
EcuRed.
https://www.ecured.cu/Team_Software_Process
Obtenido
de
Formato
IEEE
830
1998.
(s.f.).
Obtenido
https://www.ctr.unican.es/asignaturas/is1/ieee830_esp.pdf
de
ISO
de
25000
calidad
de
software
y
datos.
(s.f.). Obtenido
https://iso25000.com/index.php/normas-iso-25000/iso-25010
65
11.5 EVALUACIÓN DE RETROALIMENTACIÓN DE LA GUÍA PARA LA MEJORA
EN EL LEVANTAMIENTO DE REQUERIEMIENTOS DE SOFTWARE.
Finalmente, para la evaluación y/o retroalimentación después de haber leído,
entendido y aplicado, aunque no en su totalidad, por cuestiones de tiempo y trabajo
acumulado se realizó una ultima encuesta con preguntas mas abiertas para conocer
la opinión de algunos de los empleados involucrados dentro del desarrollo de
software en la PyME de logística de transporte.
Antes de mostrar los resultados de la retroalimentación, se muestra a continuación
algunos de los requerimientos trabajados en la guía en los días del 25 de octubre al
8 de noviembre que, aunque por cuestiones laborales no se pudieron realizar más
se aprecia el formato diligenciado, propuesto en el diseño de la guía
Figura 12. R01 diligenciado en el formato según la guía diseñada
Figura 13. R02 diligenciado en el formato según la guía diseñada
66
Figura 14. R03 diligenciado en el formato según la guía diseñada
Figura 15. R04 diligenciado en el formato según la guía diseñada
Figura 16. R05 diligenciado en el formato según la guía diseñada
Dentro de los resultados de la guía realizada, aunque no participaron todos los
empleados ya que no se encontraban en el momento de la evaluación, aunque los
resultados sean óptimos se requiere la participación de todo para concluir
claramente sobre las preguntas.
A continuación, se comparten las preguntas mas relevantes y mas pertinentes dado
el trabajo realizado.
67
Figura 17. Pregunta 8 formulario retroalimentación de la guía diseñada
Es importante resaltar el orden que se debe tratar los requerimientos y su
importancia en los proyectos de desarrollo de software, basado en las normas ISO
complementan los estudios realizados por múltiples entidades y personas que han
llevado a estandarizar practicas e ítems puntuales sobre la fase de levantamiento
de requerimientos de software.
Figura 18. Pregunta 9 formulario retroalimentación de la guía diseñada
68
Figura 19. Pregunta 10 formulario retroalimentación de la guía diseñada
Finalmente, la calidad de un producto o de un servicio desarrollado no termina aquí,
se debe seguir siendo muy minucioso con los procesos que se realizan a cabo,
continuar lo que se estar realizando bien y mejorar lo que nos puede traer problemas
en proyectos futuros. Lo anterior con el fin de cumplir con la efectividad de la
aplicación de una guía o de en otras ocasiones implementar estándares dentro de
cualquier empresa.
69
12. CONCLUSIONES
•
•
•
•
Como aprendizaje del trabajo realizado se entiende la importancia a través
de la historia de como la calidad de software hasta el día de hoy recae en las
primeras fases de desarrollo, en especial el levantamiento y/o elicitación de
requerimientos, atribuyendo la importancia de generar no solo un buen
proyecto de software sino a nivel general desde las primeras fechas según
un cronograma para evitar riesgos y perdidas en cuanto alcance, tiempo y
recursos.
Ya que el tiempo no alcanzó para implementar en su totalidad la guía
elaborada o diseñada como se planeó a inicios del trabajo se pretende, que
no solo en esta PyME estudiada sino en demás microempresas a nivel capital
y nacional analicen la importancia de las metodologías que están llevando
acabo para su vez atribuir la eficacia de los procesos que realizan.
La evaluación de la calidad, aunque sigue siendo tema subjetivo de como se
debe calificar o como se cuando la he alcanzado, es importante al menos
tratar de lograr llegar a ella por medio de procedimientos rigurosos donde
participen todos los involucrados dentro del desarrollo de software para
obtener mejores beneficios.
El levantamiento de requerimientos ya sea que se tengan recursos para
aplicar una norma internacional y se quiera certificar o se adopten
metodologías agiles aplicadas en micro y medianas empresas, es importante
que todos los stakeholders participen activamente para el mejoramiento del
servicio y de un producto, solo así se obtendrán los resultados de negocio
que mejoraran ambas partes e impulsaran a los negocios a cumplir objetivos
y metas enfocadas a las estrategias organizaciones con las que se cuenten.
70
BIBLIOGRAFÍA
Abellán, E. (05 de 03 de 2020). We Are Marketing. Obtenido
https://www.wearemarketing.com/es/blog/metodologia-scrum-que-es-ycomo-funciona.html
de
Alexandra Abuchar Porras, B. C. (2012). Observatorio de prácticas de desarrollo de
software en MinPyme y pymes de Bogotá. Trabajo de Investigación, Bogotá
D.C.
Andres Gallegos Velazquez, P. A. (2011). ELABORACIÓN DEL ESTANDAR DE
APLICACIÓN DE LA NORMA ISO 12207, AL DESARROLLO DE
APLICACIONES DE SOFTWARE PARA LA UTIC DE LA ESPE.
Barajas, C. T. (2017). Impacto de los requerimientos en la calidad del software. TIA,
161-173.
BAUTISTA, E. C. (2020). GUÍA DE PRINCIPIOS Y BUENAS PRÁCTICAS PARA
PRUEBAS DE SEGURIDAD DE SOFTWARE EN APLICACIONES WEB
PARA UNA EMPRESA DEL SECTOR PRIVADO. Bogotá.
Benavides, L. M. (2 de Agosto de 2018). La República. Obtenido de
https://amp.larepublica.co/empresas/el-problema-de-avianca-de-ayer-tuvoque-ver-con-una-falla-en-el-software-aerocivil-2755884
Bertalanffy, L. V. (1968). Teoría General de Sistemas. Nueva York.
Ceballos, D. E. (2021). Método de selección de técnicas de levantamiento de
requerimientos para el desarrollo de software con un enfoque de experiencia
de usuario. Tesis, Ciudad de Mexico.
Coulin, D. Z. (2005). Requirements Elicitation: A Survey of Techniques, Approaches
and Tools. En A. &. Aurum, Engineering and Managing Software
Requirements (págs. 19-41). New York: Springer.
Cristiá, M. (2014). Introducción a la ingeniería de requerimientos. Trabajo de
Investigación, Rosario.
Desastres
provocados
por
Software.
(s.f.).
Obtenido
https://lsi2.ugr.es/~mvega/docis/aluwork/costela/ficheros/parte3.html
de
EcuRed.
(2011).
EcuRed.
https://www.ecured.cu/Team_Software_Process
de
Obtenido
71
Edward Meinert, M. M. (2020). Agile Requirements Engineering and Software
Planning for a Digital Health Platform to Engage the Effects of Isolation
Caused by Social Distancing: Case Study. JMIR Publications, 10.
Formato
IEEE
830
1998.
(s.f.).
Obtenido
https://www.ctr.unican.es/asignaturas/is1/ieee830_esp.pdf
de
Gálvez, A. T. (2016). Especificación de requisitos de software: una mirada desde la
revisión teórica de antecedentes. Pereira.
Gil,
G. D. (2002). HERRAMIENTA PARA IMPLEMENTAR
ESCENARIOS(TILS). Tesis Magister, Buenos Aires.
LEL
Y
IEEE. (1998). Especificación de requisitos según estándar IEEE 830.
ISO
25000
calidad
de
software
y
datos.
(s.f.). Obtenido
https://iso25000.com/index.php/normas-iso-25000/iso-25010
de
Journal, D. B. (25 de Febrero de 2005). El Tiempo. Obtenido de Hartas de fallas
informaticas,
las
empresas
quieren
exigir
responsabilidad:
https://www.eltiempo.com/amp/archivo/documento/MAM-1682351
Judith del Pilar Rodriguez, C. Y. (2016). Método para interacturar con los
stakeholders en el proceso de levantamiento de requerimientos de software.
Revista Gerencia Tecnológica Informática, 14(40), 47-56.
Luis Merchán, A. U. (2008). Definición de una metodología ágil de ingeniería de
requerimientos para empresas emergentes de desarrollo de software del suroccidente colombiano. Trabajo de Investigación, Cali.
Oscar M. Fernández Carrasco, D. G. (1995). Un enfoque actual sobre la calidad del
software. La Habana: ACIMED.
Peláez, A. T. (2016). Ingeniería de Requisitos: de la especificación de requisitos de
software al aseguramiento de la calidad. Como lo hacen MiPymes
desarrolladoras de software de la ciudad de Pereira. Pereira.
Roger S. Pressman, P. (2018). Ingeniería del software. Un enfoque práctico.
Mansfield: McGRAW-HILL INTERAMERICANA.
Suárez, L. M. (2019). CALIDAD EN EL LEVANTAMIENTO DE REQUERIMIENTOS
EN PROYECTOS DE SOFTWARE. Articulo de Investigación, Bogotá D.C.
Sulca,
A.
M.
(2018).
Obtenido
de
https://repositorio.une.edu.pe/bitstream/handle/UNE/3597/MONOGRAF%c3
%8dA%20-%20QUISPE%20SULCA.PDF?sequence=1&isAllowed=y
72
Toro, A. y. (2018). Validación de un modelo para el aseguramiento de la calidad del
software en MIPYMES que desarrollan software en el Eje Cafetero.
VANESSA BAUTISTA GRISALES, E. C. (2019). MODELO ISO/IEC 25010 EN EL
PROCESO DE EVALUACIÓN DE LA CALIDAD DEL SOFTWARE EN LA
EMPRESA OBRAS CIVILES DE BOGOTÁ EN EL ÁREA DE TECNOLOGÍA
DE LA INFORMACIÓN Y COMUNICACIÓN. Bogota.
73
ANEXOS
Anexo A. Formato de diligenciamiento de requerimientos en una pyme de
logística de transporte
Diagnóstico hecho por: Carlos
Andrés Rodríguez Co. 67000100
Formato de diagnóstico
Versión: 1.0
Proceso de requerimientos
actual
Fecha: 28/07/2021
Descripción del requerimiento solicitado por parte de la empresa-cliente
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
________________________________________________________________________
Hora Inicio: _________
Medio de contacto
o Correo
o WhatsApp
o Página web de tickets
o Otro ¿Cuál?: _______________
¿Se entendió el requerimiento leyendo la primera vez la descripción del mismo?
o Si
o No
o Mas o menos ¿Se tienen dudas? ¿Cuáles?
________________________________________________________________________
________________________________________________________________________
__________________________________
¿Se requirió solicitar más información o aclaración sobre la primera descripción?
o Si
o No
74
Si la respuesta fue si elija por qué ocurrió esto:
o No fue entendido por parte del equipo de desarrollo
o No fue explicado de la mejor manera por parte del solicitante
o No hubo una buena comunicación entre las áreas en la pyme
o Otro ¿Cuál?
________________________________________________________________________
______
¿Después de solucionado el requerimiento, cuantos ajustes se realizaron para entregar en su
totalidad?
o Solo una (1)
o Dos (2)
o Más de dos (>2)
Duración del requerimiento
Hora fin: _________ Tiempo: _________
Anexo B. Cuadro analítico sobre metodologías y normas enfocadas en el
levantamiento de requerimientos de software
75
76