Serviços customizados
Espanhol (pdf)
Artigo em XML
Referências do artigo
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
INTRODUCCIÓN
En la actualidad como un área de investigación desafiante por parte de la comunidad de ingenieros de software se ha considerado a los requisitos cambiantes (Jayatilleke & Lai, 2018). Se ha arribado a que éstos cambian durante las diferentes fases del ciclo de vida del desarrollo del software y este cambio desempeña un papel vital en el éxito o fracaso de cualquier proyecto (Williams, Carver, & Vaughn, 2006). Lo cierto es que más de la mitad de los requisitos de un software cambian antes de la implementación real de este. La mayoría de las fallas de software se atribuyen a una ingeniería de requisitos deficiente en la que los requisitos ambiguos e incompletos conducen a cambios en todo el proceso de desarrollo de software (Kotonya & Sommerville, 1998), (Bano, Imtiaz, Ikram, Niazi, & Usman, 2012), (Jayatilleke & Lai, 2018). En los últimos años, la tendencia ha cambiado de culpar al problema a identificar la causa de ese problema. Para gestionar los cambios en los requisitos se necesita identificar la causa de esos cambios para poder monitorearlos y gestionarlos de manera eficaz y también para encontrar mejores soluciones. Existen numerosas causas de cambio de requisitos resaltadas en la literatura, como el cambio en la tecnología, las preferencias del usuario y el entorno siempre cambiante (AlSanad & Chikh, 2015). Estas causas pueden ocurrir durante cualquier fase del desarrollo de software y, a su vez, provocar cambios en los requisitos generales del sistema.
La literatura (AlSanad & Chikh, 2015), (Bano et al., 2012), (Ali & Lai, 2016), (Jayatilleke & Lai, 2018) destaca el hecho de que la anticipación del cambio temprano en el diseño, el conocimiento de dónde buscarlo y los requisitos que cambian con más frecuencia que los otros, ayudaría a ahorrar costos, reducir el tiempo de desarrollo general y aumentar la tasa de éxito de los proyectos. Si no se responde a los cambios requeridos, se producen retrasos, problemas de configuración, defectos e insatisfacción general del cliente por no obtener el producto de calidad (Ebert & De Man, 2005). Los desarrolladores de software consideran que responder al cambio de requisitos es más importante que centrarse en los requisitos estables de beneficios en términos de costo y tiempo de desarrollo. Aceptar el hecho de que el cambio es inevitable puede acomodar y gestionar un proyecto exitoso.
Los cambios en los requisitos también tienen diferentes riesgos asociados con ellos en términos de costo y tiempo, y el impacto aumenta con la propagación de esos cambios de una fase a la siguiente. Por lo tanto, es necesario recopilar y clasificar las causas y mapear su impacto en los artefactos generados durante el desarrollo de software.
El objetivo de este estudio es recopilar evidencia de las diferentes causas del cambio de requisitos mediante la realización de una revisión bibliográfica y la clasificación de los cambios de requisitos en diferentes grupos lógicos.
MÉTODOS O METODOLOGÍA COMPUTACIONAL
Se realizó una revisión bibliográfica utilizando la metodología propuesta por (Gómez-Luna, Fernando-Navas, Aponte-Mayor, & Betancourt-Buitrago, 2014) la cual facilita la adquisición de la información disponible, la identificación de los principales autores, el número de publicaciones por año, las principales áreas de trabajo y las tendencias en el área objeto de investigación. Las bases de datos consultadas fueron: SpringerLink , IEEE Xplore , ACM Digital Library , ScienceDirect , Cite Seer5.
Definición del problema
Como tema se definió las causas de los cambios en los requisitos de software.
Búsqueda de Información
Una vez definido el problema a investigar, se consultaron diferentes fuentes de información como artículos, libros, disertaciones doctorales, presentaciones y revisiones sistemáticas de la literatura publicadas entre el 2005 y el 2019; empleando las ecuaciones de búsqueda mostrada en la siguiente Tabla 1.
Del total de documentos encontrados, luego de analizar la información, y filtrarlos por fecha, se seleccionaron 6 documentos, siendo los principales autores: Munera Bano de Pakistán, Shalinka Jayatilleke y Naved Ali de autralia y Muhammad Azeem Akbar de China. (Bano et al., 2012), (Ali & Lai, 2016), (Jayatilleke & Lai, 2018), (Akbar, Sang, Nasrullah, Khan, Mahmood, et al., 2019), (Akbar, Sang, Khan, & Hussain, 2019), (Akbar, Sang, Nasrullah, Khan, Shafiq, et al., 2019).
Una solicitud de cambio de software puede tener muchas razones; por ejemplo, los ingenieros de requisitos pueden olvidar mencionar un requisito y es una característica que falta en un sistema resultante, o se ha identificado un error, cuya rectificación es un requisito, o malentendido de los requisitos debido a la falta de participación activa de los involucrados o stakeholders (Bano et al., 2012). Otros ejemplos pueden ser: los cambios en las prioridades de las organizaciones, las tendencias del mercado y la competencia introducen continuamente nuevos requisitos, la nueva legislación o las normas de la organización pueden obligar a cambiar, las personas pasan a la solución antes de comprender cuál es realmente el problema (Harker, Eason, & Dobson, 2002).
Para establecer y comprender plenamente las causas implícitas del cambio de requisitos, es imperativo tener una respuesta convincente al cambio de requisitos. Los problemas de requisitos puede propagarse a otras fases del desarrollo del software si estos problemas no se abordan en las etapas iniciales, es decir, el cambio de requisitos puede afectar el diseño y, en última instancia, codificar y dar como resultado un sistema que no es deseable debido a estos cambios (Jayatilleke, Lai, & Reed, 2018). El cambio es un problema que puede tener varios efectos en el proyecto de software, por lo tanto, es fundamental para comprender la relación de causa y efecto para un proceso de toma de decisiones en la gestión de cambios de requisitos.
El análisis de la causa del cambio de requisitos puede ayudar a prevenir los problemas en la fase de requisitos. Se ha observado que si los profesionales tienen conocimiento de por qué se presenta la solicitud de cambio y cuál fue la causa subyacente que generó esta solicitud, les ayudaría a decidir cómo abordar el mismo. El objetivo de la revisión bibliográfica es recopilar evidencias empíricas sobre las causas de la necesidad de cambio. El conocimiento generado por esta revisión ayudará a los gerentes de proyectos y desarrolladores en el proceso de gestión de cambios de requisitos para analizar la relación de causa y efecto y a tomar la decisión adecuada con respecto a cualquier solicitud de cambio de requisitos. La clasificación y la agrupación de los cambios en los requisitos es uno de los factores importantes que deben examinarse y analizarse en la gestión de cambios requerida (McGee & Greer, 2009), ya que ayuda a los profesionales a comprender la categoría de cambio de requisitos y evaluar su impacto en el Proceso de desarrollo de software y producto. Uno de los objetivos del estudio es analizar las causas de los cambios en los requisitos y clasificarlos en grupos lógicos.
Estas categorías se pueden evaluar para determinar la frecuencia de aparición durante las diferentes fases de desarrollo del software. A pesar de toda la importancia del cambio de requisitos reivindicado en la literatura publicada, también se ha señalado que hay poco trabajo empírico realizado para la investigación y exploración en esta área (Jayatilleke & Lai, 2018).
Existen diferentes herramientas, técnicas y métodos propuestos por la comunidad de investigación para gestionar los requisitos cambiantes. Sin embargo, existe una necesidad de comprender las causas subyacentes de los cambios en los requisitos para poder gestionar mejor sus impactos en el desarrollo de software.
RESULTADOS Y DISCUSIÓN
La siguiente Tabla 2 muestra la información general sobre los estudios incluidos;
De acuerdo con los documentos consultados los factores que causan los cambios de los requisitos se dividen en dos categorías: activados por eventos o por incertidumbre. En realidad, es difícil determinar si el cambio ocurre como resultado de uno o ambos. En un sentido práctico, no es importante que las causas de los cambios se dividan en estas dos categorías, siempre que estén identificadas. En realidad, es difícil determinar si el cambio ocurre como resultado de uno o ambos. En un sentido práctico, no es importante que las causas de los cambios se dividan en estas dos categorías, siempre que estén identificadas. Estos cambios identificados se pueden clasificar en cinco áreas: mercado externo; organización del cliente; visión del proyecto; especificación de requerimiento; y solución. Estas cinco áreas se identificaron observando las características de los eventos de cambio y las incertidumbres discutidas en la literatura (Bano et al., 2012), (Akbar, Sang, Nasrullah, Khan, Shafiq, et al., 2019). Por ejemplo, cualquier factor de cambio que fuera parte del entorno externo de la organización, como competidores, regulaciones gubernamentales, etcétera se categorizó como mercado externo. Según la ubicación en el ciclo de vida del proyecto de software, la información anterior puede ser significativa para anticipar qué factores pueden causar cambios y, como resultado, conducirá a una mejor planificación que garantizará una mejor tasa de éxito del proyecto. A continuación, se muestra una Tabla 3 con las causas más comunes de cambios de requisitos documentadas en la bibliografía consultada. Estas causas están recogidas dentro de las áreas que fueron mencionadas con anterioridad.
La siguiente Tabla 4 muestra la tasa de ocurrencia de cambios con respecto a la fase de desarrollo de software de los estudios seleccionados.
Se encontraron pocas investigaciones que muestren resultados sobre las causas de cambio de los requisitos de software. Pero si ha quedado claro en la literatura revisada que los requisitos cambiantes han sido el principal desafío que enfrentan los ingenieros de software y gestores de proyectos durante todo el ciclo de vida de un proyecto de software.
También se ha podido observar en este estudio que, para causas accidentales, el foco debe estar en el diseño, por lo que se deben emplear técnicas y procedimientos de calidad para evitar su ocurrencia. Las causas del cambio de requisitos pueden clasificarse además en función de su origen. Las causas pueden originarse desde dentro del proyecto (por ejemplo, “especificación de requisitos incompletos”) o causas pueden originarse desde fuera del proyecto también (por ejemplo, “cambio en política de organización”) o del entorno empresarial en que opera la organización cliente (por ejemplo, demandas de mercado). Se requieren diferentes técnicas para hacer frente a diferentes tipos de causas y su impacto (Ali & Lai, 2016), (Jayatilleke & Lai, 2018). Estas técnicas están recogidas dentro de las 3 áreas de la Gestión de Cambio de Requisitos (GCR), Identificación, Análisis y Estimación del Costo del Cambio.
Luego del análisis realizado se puede decir que:
Los métodos de identificación de cambios no parecen tener mucho consenso sobre cómo se debe realizar la identificación, ni muchos de los métodos son formales.
La mayoría de los métodos de identificación de cambios encontrados se basan en dos técnicas: mediante taxonomías y mediante clasificaciones.
Las taxonomías de cambio tienden a basarse en conceptos más amplios, como casos de uso y modelos UML, mientras que las clasificaciones de cambio utilizan mecanismos más simplificados, como direcciones de cambio y parámetros.
La identificación del cambio generalmente conduce a la comprensión de la necesidad del cambio, que también se relaciona con un análisis más detallado del cambio.
Las técnicas de trazabilidad han sido la opción más popular al analizar el cambio, ya que la trazabilidad de los requisitos facilita la identificación del impacto del cambio de manera más eficiente.
Sin embargo, este parece ser un concepto teórico ya que la trazabilidad de los requisitos tiene muchas limitaciones.
La idea principal del análisis de cambios es identificar cómo el cambio solicitado impacta el diseño o sistema existente. A tal efecto, los métodos de análisis del impacto del cambio que se encuentran en la literatura pueden agruparse en función de los objetos que se ven afectados: conjunto de impacto inicial, conjunto de impacto estimado y conjunto de impacto real.
Dentro de las técnicas de cálculo de costos dedicadas a estimar el costo de los cambios en los requisitos destacan las técnicas de costo existentes, como COCOMO, juicio de expertos, etc.
Es posible dividir las técnicas de costo existentes en dos categorías: algorítmicas y no algorítmicas.
Dependiendo de en qué punto del ciclo de vida se encuentre el proyecto de software y qué artefactos se utilicen para la estimación de costos, se puede juzgar la idoneidad de cada estimación para la estimación de costos de los cambios.
CONCLUSIONES
Los cambios en los requisitos ocurren por diferentes razones y pueden ser causados por múltiples partes interesadas. Independientemente de quién o qué causa estos cambios, la necesidad de una gestión adecuada es grande debido a las consecuencias indeseables si no se atienden a tiempo. El objetivo principal de esta investigación fue determinar las causas de los cambios en los requisitos y establecer algunas clasificaciones y técnicas que ayuden a los equipos de desarrollo a identificar y conducir de forma exitosa esta área dentro de la gestión de proyectos.
En el documento, la sección sobre factores que causan cambios en los requisitos proporciona una comprensión de cuán amplios y constantes pueden ser estos cambios. No existe una causa fundamental para los cambios, lo que hace que la gestión de cambios sea una tarea desafiante. Por lo tanto, incluso con una gran cantidad de investigación sobre la gestión del cambio, todavía hay margen de mejora. Dada la complejidad de los cambios, es importante identificar los procesos existentes para gestionarlos. De la literatura disponible se desprende claramente que no existe consenso sobre cómo gestionar el cambio. En algunos casos, se basa en el tipo de organización y el entorno y, en muchos casos, se basa en el tipo de cambios. A través de los pasos del proceso disponibles, se identificaron tres procesos comunes; identificación, análisis y estimación de costos del cambio. Este trabajo también es una guía para los futuros investigadores sobre las causas del cambio en términos del trabajo importante que se ha realizado hasta ahora.
