La capacidad de la gestión de la configuración en =
las
pequeńas organizaciones de desarrollo de software
The capacity of
configuration management in small software development organizations
Max Renato Zúńiga.[1], =
Galo
Patricio Hurtado.[2] & Juan Marcelo Pérez.[3]
This article is the result of the research project
entitled "The Reality of the Software Industry", was conducted by=
the
teachers of the career of Software Development Instituto Superior Tecnológico Particular Sudameric=
ano
in the city of Cuenca - Ecuador during the year 2019. Through the applicati=
on
of questionnaires, it was observed that small organizations were complement=
ing
the software development process with configuration management. Due to the =
need
to maintain control of changes in the configuration of software products.
Digital transformation has influenced small organizations, automating part =
of
their processes, including supporting configuration management with a level=
1
capability. To understand the reality of organizations from this point of v=
iew,
the CMMI 2.0 capability model was used to assess the capability of the
configuration management process area. The techniques used for data collect=
ion
are: The interview and the survey. The
method used was deductive, due to the diversity of contexts in which the
organizations studied are developed.
Finally, 2 organisations known in the ci=
ty (MyCodedMain and PlanERP) =
with
more than 5 years of experience were selected. On the other hand, 3
organizations were selected, made up of development teams between 3 and 5
members (ReflaAustro, La Merced, Engicoders).
In addition, the evaluation process used the phases recommended by the meth=
od
defined by the CMMI.
Resumen.
El presente artículo es el resultado del proyecto =
de
investigación titulado La Realidad de la Industria del Software, fue
realizado por los docentes de la carrera de Desarrollo de Software Instituto
Superior Tecnológico Particular Sudamericano en la ciudad de Cuenca - Ecuad=
or
durante el ańo 2019. Mediante la aplicación de cuestionarios se observó que=
las
pequeńas organizaciones complementaban el proceso de desarrollo de software=
con
la gestión de la configuración. Debido a la necesidad de mantener un contro=
l de
los cambios en la configuración de los productos de software. La transforma=
ción
digital ha influido en las pequeńas organizaciones, automatizando parte de =
sus
procesos, entre ellos el soporte de la gestión de la configuración con una
capacidad de nivel 1. Para comprender la realidad de las organizaciones des=
de
este punto de vista, se utilizó el modelo de capacidad del CMMI 2.0 para
evaluar la capacidad del área de procesos de la gestión de la configuración.
Las técnicas utilizadas para la recolección de datos son: La entrevista y la
encuesta. El método utilizado fue
deductivo, debido a la diversidad de contextos en los que se desarrollan las
organizaciones estudiadas. Por últ=
imo,
se seleccionaron 2 organizaciones conocidas en la ciudad (MyCodedMain
y PlanERP) con más de 5 ańos de experiencia. Po=
r otra
parte, se seleccionó a 3 organizaciones conformadas por equipos de desarrol=
lo
entre 3 a 5 miembros (ReflaAustro, La Merced, <=
span
class=3DSpellE>Engicoders). Además, para el proceso de evaluación se
utilizó las fases recomendadas por el método definido por el CMMI.
Palabras claves: Gestión de la configuración, pequeńas organizacio=
nes,
CMMI 2.0, Desarrollo de software.
Introducción.
La gestión de la configuración es una disciplina especializada, brinda
soporte a los procesos de ingeniería de sistemas y de software. Su propósit=
o es
identificar y documentar cada elemento de la configuración (CI), mantener un
control de los cambios en tales características, registrar y reportar cada
cambio y estado de la configuración, hasta el soporte de auditoría (IEEE 82=
8, 2012).
Según el CMMI Institute (2018), la gestió=
n de
la configuración es un proceso de soporte de la ingeniería del software. Sus
principales objetivos son: gestionar la integridad de los productos de trab=
ajo,
controlar versiones y cambios, y realización de auditorías. La implementaci=
ón
de dicho proceso de soporte, permite a las
organizaciones: ofrecer la versión correcta de la solución al cliente y red=
ucir
la pérdida de trabajo.
En el contexto de las pequeńas organizaciones que desarrollan softwar=
e y
sus limitados recursos, es importante, analizar la realidad de estas
organizaciones respecto a la gestión de la configuración. Debido al impacto=
que
tienen sobre la calidad de los productos de software, la productividad y
competitividad de las organizaciones.
Las pequeńas organizaciones participantes de este estudio,
utilizaban metodologías ágiles para la gestión y desarrollo de proyecto de
software, entre ellas: Programación extrema y SCRUM. Según los principios d=
el
manifiesto de la agilidad los individuos y las iteraciones son más importan=
tes
que los procesos y herramientas. De tal manera que, la realización de una
gestión de la configuración como práctica recomendada por el CMMI son
necesarios si las pequeńas organizaciones desean mejorar la calidad de sus =
productos
de software.
A finales del ańo 2019. Se realizó una encuesta, a cinco Pequeńas
Organizaciones (PO) en la ciudad de Cuenca, reveló problemas en la Gestión =
de
la Configuración (GC) específicamente en el proceso de auditoría. Por lo qu=
e,
el estado de la configuración de un producto de software se conoce hasta que
los involucrados en el proyecto recolectan la información del Ciclo de Vida=
de
Desarrollo del Software (CVDS) y reportan la situación al jefe de proyecto.=
De lo anterior, los siguientes objetivos de investigación son plantea=
dos:
1.&n=
bsp;
Medir el nivel de la capacidad =
de
la gestión de la configuración de las pequeńas organizaciones
2.&n=
bsp;
Determinar qué factores afectan=
a
la capacidad de la gestión de la configuración.
3.&n=
bsp;
Mostrar el estado actual de la =
gestión
de la configuración de las pequeńas organizaciones.
Desarrollo.
Las prácticas recomendadas por el CMMI 2.0
El CMMI 2.0 por medio de la integración de buenas práctic=
as,
recomienda la implementación del proceso de soporte fundamental a la gestió=
n de
la configuración, mejorar y mantener la capacidad de este proceso requiere =
las
siguientes prácticas recomendadas, resumidas a continuación:
|
Tabla 1. CMMI 2.0 Prácticas Recomendad=
as
Sobre la Gestión de la Configuración (CM) |
|
|
Práctica Recomendada por el C=
MMI
2.0 |
Nivel=
de
Capacidad |
|
|
1 |
|
|
2 |
|
|
2 |
|
|
2 |
|
|
2 |
|
|
2 |
|
|
2 |
Fuente: Elaboración propia.=
CM 1.1. Realizar el control de
versiones.
Los cambios a la configuración en los productos de softwa=
re
son comunes en la industria del software.
Principalmente, porque, las empresas con el paso del tiempo comprend=
en
de mejor manera su modelo de negocio. Por lo que, cambian sus requerimientos
para adaptarse al contexto en que se desempeńan. Este hecho afecta de manera
directa a la configuración.
Los miembros de un equipo de desarrollo de software reali=
zan
diferentes cambios al software respectivamente en sus espacios de trabajo, =
los
conflictos aparecen cuando se intenta fusionar las diferentes instancias en=
una
misma versión de software, debido a la falta de coordinación en las tareas a
realizar durante el desarrollo de una solución (Kaur
y Singh, 2017).
De modo que, las pequeńas organizaciones para mantener su
competitividad, debido a la alta demanda de software, mantener la calidad d=
el
software y que aporte valor al cliente al mismo tiempo, opta por, automatiz=
ar
sus procesos de desarrollo de software, utilizando sistema de gestión de
versiones como: GitLab, GitHub, Bitbucket.
Figura 1. Uso
de sistemas de control de versiones.
Fuente: Elaboración propia.
La figura 1 muestra que las pequeńas organizaciones prefi=
eren
implementar repositorios basados en GIT para el control de las versiones.
La implementación de estos sistemas trae consigo las
siguientes ventajas:
ˇ =
Automatización de los
procesos de desarrollo
ˇ =
Automatización de los
procesos de operaciones
ˇ =
Control de los cambio=
s
ˇ =
Comunicación entre los
miembros del equipo de desarrollo
ˇ =
Trazabilidad de los e=
lementos
de configuración
ˇ =
Incorporación de datos
estadísticos de los proyectos
ˇ =
Distribución de la ge=
stión de
la configuración
La innovación en las tecnologías para el desarrollo de
software es crucial en una economía creciente, que demandan una mayor tasa =
de
entregas de software. La continua integración (CI) afecta directamente en la
calidad del software y la productividad de las organizaciones (Kaur y Singh, 2017). Basándonos en esto, es posible
observar el incremento de confirmaciones (commits) y
clonaciones de repositorios (pull request)
en el ańo 2019. Así pues, los sistemas de versiones son un factor clave par=
a el
crecimiento de las pequeńas organizaciones.
Ahora
bien, podemos mencionar la tendencia desde el ańo 2018 hasta inicios del 20=
20,
registrada por GITHUB sobre las cuentas localizadas en Cuenca Ecuador, el
contador de confirmaciones (commits) realizadas=
en lo
repositorios que colaboran en este sistema.
Figura
2. Commits en cuentas de GitHUB 2018-20=
20
Fuente: Elaboración propia.
Las pequeńas organizaciones, prestan poca o ninguna atenc=
ión
a la documentación técnica y el desarrollo de sistema de versiones. Esto pu=
ede
ser evidenciado por la falta de archivos Hooks y de archivos de
configuración =
Yamel en la estructura de los repositor=
ios.
Es decir, pierden la oportunidad de mejorar la competitividad de sus empres=
as
al no integrar herramientas especializadas para la gestión de proyectos, por
ejemplo, JIRA y para la elaboración de documentación por medio de Cicle CI o
Travis CI. Las herramientas impactan directamente en el tiempo y esfuerzo
dedicados por los miembros del equipo de desarrollo.
En
definitiva, todo esto, deja en claro, que las pequeńas organizaciones son
capaces de alcanzar el nivel 1 de capacidad de la gestión de la configuraci=
ón,
simplemente por implementar un sistema de versiones basado en Git. Expandir=
su
capacidad mediante el uso de Herramientas adicionales como JIRA y Travis.
También se debe aclarar que la implementación de un sistema de versiones
implica tiempo de capacitación al personal, coordinar actividades. En medio=
de
un ambiente ágil de desarrollo de software.
CM 2.1 Identificar los artículos a ser incluidos en la
Gestión de la configuración.
Antes que determinemos los elementos de la configuración =
(CI)
que serán incluirse a la gestión de la configuración. Es importante, el con=
texto
y la cultura organizacional en la cual se desarrollan las pequeńas
organizaciones.
El contexto organizacional de una organización comprende,
como intenta lograr sus objetivos respecto a la gestión de la configuración
(Abran et al., 2004). Para que, las versiones correctas sean entregas a los
clientes (IEEE 828, 2012). Hoy en =
día
muchas empresas están utilizando contextos ágiles para el desarrollo de
software versus los tradicionales.
Figura 3. Contextos Organizacionales en l=
as
Pequeńas Organizaciones (PO)
Fuente: Elaboración propia.
En efecto, las pequeńas organizaciones tienden a implemen=
tar
contextos organizacionales ágiles, como se puede apreciar en la figura 3.
Específicamente utilizando metodología SCRUM para la gestión de proyectos de
desarrollo de software.
Una
vez determinado el contexto organizacional; los elementos de la configuraci=
ón
(CI) pueden ser identificados utilizando el siguiente criterio:
Criterio.
Si
los requerimientos son aprobados y los cambios sobre ellos deban seguir un
proceso definido de control de cambios, entonces, estos requerimientos se
convierten en un elemento de la configuración; y pasan a ser parte de la lí=
nea
base.
Los
elementos de la configuración identificados en la metodología SCRUM son:
ˇ =
Las historias de usua=
rio
ˇ =
Los sprints
(iteraciones de desarrollo)
ˇ =
Las tareas
ˇ =
Las incidencias
ˇ =
Los códigos fuente
ˇ =
Pruebas
ˇ =
Retrospectivas
ˇ =
Modelos
Luego los elementos de la configuración son organizados y
planificados; la trazabilidad de los elementos de la configuración será
mantenida por la estructura y jerarquía establecida por la empresa. La
siguiente figura 4 ilustra la estrategia:
Figura 4. Organ=
ización,
Jerarquización de los elementos de la configuración
Fuente:
Elaboración propia.
Según Uribe, Ayala (2007), los
valores establecidos por el manifiesto de las metodologías ágiles son:
ˇ =
El recurso humano por=
encima
de las herramientas
ˇ =
Software antes que la
documentación
ˇ =
Colaboración con el c=
liente
antes que los contratos
Por lo tanto, para no= entrar en conflicto con los valores establecidos en el manifiesto, los sistemas de control de versiones disponibles, han desarrolla= dos funcionalidades como: hitos, etiquetas, incidencias. Así como, mecanismos p= ara soportar líneas base del proyecto, entre ellos tenemos las ramificaciones.<= o:p>
Al respecto a la estr=
ategia
de ramas utilizadas por las pequeńas organizaciones son implementadas de acuerdo a las necesidades de la institución. Sin em=
bargo,
la documentación de GIT, recomienda las siguient=
es
estrategias para el flujo de trabajo (Git, 2019):
ˇ =
Administrador-Integra=
ción
(Ad-In): Utilizar en proyectos de pequeńos a grandes.
ˇ =
Dictador-Teniente
(Di-Te): Utilizar en proyectos muy grandes.
Figura 5. Tipos de flujo de trabajo
utilizados en las pequeńas organizaciones
Fuente: Elaboración propia.
La mayoría de las pequeńas organizaciones, mantienen los
elementos de la configuración definidos por la metodología SCRUM. Hay que t=
omar
en cuenta la importancia de la automatización del proceso de gestión de la
configuración, proporcionado por las herramientas basadas en GIT, caso
contrario entraría en conflicto con los valores propuestos por la metodolog=
ía
ágil.
Y, por último, la trazabilidad es asegurada por mecanismo=
de
seguimiento (etiquetas) y agrupación (hitos), por ejemplo: las organizacion=
es
que utilizan GITLAB.
CM 2.2 Desarrollar, actualizar y usar un sistema de
configuración y de Gestión del cambio.
Hoy en día los sistemas de gestión de cambios están inclu=
idos
en los sistemas de gestión de versiones.
Por tal motivo, en esta práctica, si cumple con la prácti=
ca
CM 1.1 solo sería necesario revisar el cumplimiento de esta funcionalidad a
nivel del sistema.
En este punto la posibilidad de integración del sistema c=
on
otros sistemas externos también es importante. Entre algunos sistemas
encontrados de uso frecuentes en las pequeńas organizaciones son: Jira y
Travis.
CM 2.3 Desarrollar o liberar líneas base para uso interno=
o
para su entrega al cliente.
En el desarrollo software, la comprensión de los concepto=
s de
alcance, costo y tiempo es muy importante para la gestión de un proyecto. El
Project Management Institute (2017) seńala que =
las
líneas base mantienen una relación directa a la planificación u hojas de ru=
ta
del proyecto.
Por lo que, la falta de esta práctica compromete el
desarrollo de un proyecto de software exitoso.
En
consecuencia, tres factores evidencian el desarrollo de líneas base son sus
productos de trabajo como son:
ˇ =
Su uso interno o exte=
rno.
ˇ =
Realización de hojas =
de ruta.
ˇ =
La estructura de desg=
lose de
trabajo (EDT).
Figura 6. =
Uso
de las Líneas Base
Fuente: Elaboración propia.
Las líneas base desarrolladas en las pequeńas organizacio=
nes
son utilizadas de manera interna principalmente, esto para el control y
seguimiento de los proyectos de software.
Figura 7. Planificación y Realización de
Horas de Ruta (RoadMaps)
Fuente:
Elaboración propia.
La realización de las hojas de ruta, no son realizadas por
las empresas en su mayoría.
La mayoría de las herramientas que utilizan las pequeńas
organizaciones son libres. Esto incluye que vean limitadas sus funciones. El
costo de adquirir licencias para el uso de funcionalidades más avanzadas
influye en el costo final de los proyectos.
Figura 8. Realización de Estructuras del
Desglose de Trabajo.
Fuente: Elaboración propia.
En cuanto al control de los cambios, los gerentes o dueńo=
s de
la empresa tiene la autoridad para realizar los cambios a los elementos de =
la
configuración.
CM 2.4 Gestionar los cambios en los elementos de la gesti=
ón
de la configuración.
Los cambios en el software son frecuentes. Normalmente
impactan en el desarrollo y operaciones de la organización. Esto implica que
una coordinación y coreográfica de un proceso de cambio son necesarios para
gestionar los cambios a los elementos de la configuración y solo los cambios
establecidos sean cumplidos (Hüttermann, 2012).=
Como está práctica es muy importante en cualquier
organización, por esta razón, muchas de ellas, establecen algún tipo de pro=
ceso
o mecanismo para atender los cambios los requerimientos del software. Estos
mecanismos incluyen: Uso de Correos electrónicos hasta sistemas de tiquetes=
.
Según Akbar, Sang,
Khan, Mahmood, Qadri y Xia=
ng
(2019) asegura que, en las organizaciones dedicadas al negocio del desarrol=
lo
de software, el cambio dinámico de los requerimientos es esencial. Por otra
parte, las empresas manifiestan dificultad en atender los cambios. Tienden a
introducir los cambios al finalizar una iteración del desarrollo, en algunos
casos delimitando del número de cambios que el interesado o dueńo del produ=
cto
puede realizar.
En cuanto a esta práctica se encontró que las pequeńas
organizaciones:
ˇ =
No todas tienen un pr=
oceso
establecido para atender los cambios
ˇ =
Si registran peticion=
es de
cambios solicitadas por los clientes, así como su priorización, pero no exi=
sten
documentación con formato establecido.
ˇ =
Realizan inspecciones=
para
medir el estado de las solicitudes de cambio.
ˇ =
Casi todas realizan p=
ruebas
unitarias o revisiones que garanticen consecuencias no deseadas.
CM 2.5 Desarrollar, mantener actualizados y utilizar
registros que describen los elementos de la gestión de la configuración.
El estado de la configuración requiere la actualización y
mantenimiento de registro que describan los elementos de la configuración p=
ara
revisar y reportar los activos bajo la gestión de la configuración del proy=
ecto
(IEEE 828, 2012).
En la misma norma se recomienda que los elementos de la
configuración deben contener la siguiente información (CMMI 2.0, 2018):
ˇ =
Fecha de origen
ˇ =
Localización
ˇ =
Versión aprobada
ˇ =
Estado
ˇ =
Trazabilidad
De tal modo que, cuando las organizaciones logran el
complimiento de esta práctica son capaces de realizar reportes en base a la
planificación y la información de los elementos de la configuración. Por lo
que, mantienen mecanismos y medios para la extracción de información, entre
ellos:
ˇ =
Revisiones y registro=
de los
elementos
ˇ =
Registro de solicitud=
de
cambio
ˇ =
Estado de elementos d=
e la
configuración
ˇ =
Revisión de las línea=
s base
El siguiente
gráfico ilustra, la relación de actividades encontradas respecto a esta
práctica:
Figura 9. Mecanismos y Medios para Manten=
er
el Registro de los Elementos de la configuración
Fuente: Elaboración propia.
CM 2.6 Realizar auditorías de configuración para mantener=
la
integridad de las líneas base de configuración, cambios y contenido del sis=
tema
de gestión de la configuración.
Los contextos ágiles de gestión de proyectos de software,=
ha
causado un gran impacto en el desarrollo de software.
Según Bryan, Siegel y Whiteleather
(1982) dice, las metodologías ágiles es una combinación de varios métodos de
desarrollo entre incrementales e iterativas. Destacan seis factores que deb=
en
revisarse periódicamente: el cumplimiento, el flujo de trabajo, la segurida=
d,
el proceso gestión, revisión de códigos, gestión de la construcción y el
trabajo en equipo.
Dai y Vasarhe=
lyi
(2016), en cambio, proponen una auditoria acorde a la industria 4.0 basados=
en
seis principios de diseńo e implementación: Interoperabilidad, virtualizaci=
ón,
descentralización, capacidad en tiempo real, orientación a los servicios y
modularidad. Debido a la presión que reciben las organizaciones para entreg=
ar
con mayor frecuencia productos de software.
El
incremento de la frecuencia de liberaciones de software incluye mayor
incremento de auditorías, revisiones o inspecciones por el equipo de
desarrollo, que garanticen la calidad del software. Sin embargo, el 80% de =
las
pequeńas organizaciones analizadas no realiza está práctica.
Por lo tanto, se procedió a revisar los sistemas de gesti=
ón
de la configuración y tipos de cuentas a las cuales las organizaciones están
suscritas tales como: Platium, Silver o libre.
Normalmente la cuentas tipo Silver habilitan al usuario funcionalidades de
auditoria, la mayoría de las organizaciones utilizan cuentas Free.
Figura 10. Cuentas y Funcionalidades de
Auditoría
Fuente: Elaboración propia.
Evaluación de la capacidad de la gestión de la configurac=
ión
La fase 1 Planificación y Preparación consistió en las
siguientes actividades listadas en orden:
ˇ =
Selección de las pequ=
eńas
organizaciones
ˇ =
Entrevistas realizada=
s a los
gerentes
ˇ =
Delimitación de la ev=
aluación
ˇ =
Preparación de inform=
ación
requerida
ˇ =
Coordinación de las
actividades
Las empresas
seleccionadas fueron seleccionadas, de acuerdo con los ańos de experiencias,
número de proyectos y disponibilidad de los gerentes o equipo de desarrollo=
. El
alcance de la evaluación está limitada a la gestión de la configuración gen=
eral
o específica en los proyectos de desarrollo de software. Por lo tanto, las
empresas seleccionadas son:
|
Empresa |
Experiencia |
N° Proyectos |
Disponibilidad |
|
PlanERP |
+ 5ań=
os |
+ 5
proyectos |
Si |
|
MyCodedMain |
+ 5ań=
os |
+ 20
proyectos |
Si |
|
ReflaAustro |
+ 5ań=
os |
+ 3
proyectos |
Si |
|
La Merced |
+ 5ań=
os |
+ 2
proyectos |
Si |
|
Engicoders |
+ 5ań=
os |
+ 3
proyectos |
Si |
|
Multics |
+ 5ań=
os |
-- |
No |
|
Cobus |
+ 5ań=
os |
-- |
No |
|
Sodel |
+ 5ań=
os |
+ 3
proyectos |
No |
|
Estratego |
-- |
-- |
-- |
|
Interpro |
-- |
-- |
-- |
|
Alliance |
-- |
-- |
-- |
|
Sonex |
-- |
-- |
-- |
Fuente: Elaboración propia.
La
fase 2: Realización de la evaluación
ˇ =
Coordinación de visit=
as
ˇ =
Preparación de Cuesti=
onario
Por lo
expuesto anteriormente, el cuestionario fue estructurado como indica el for=
mato
mostrado a continuación:
Tabl=
a 3. Formato Cuestionario de Evaluación
|
|
|||
|
Práct=
ica |
Nivel=
|
Evide=
ncia |
Calif=
icación |
|
CM 1.1 Realizar el control de versiones. |
1 |
Versiones de software Uso de repositorios Sistema de versiones (De preferencia vasados en Git) Commits y Push Request Estrategias de ramificación (Ad-In) No existe conflicto con el manifiesto de agilidad. |
En
gran medida cumple (LM) |
|
CM 2.1 Identificar los artículos a ser incluidos en la Gestió=
n de
la configuración. |
2 |
Combinación de una o varios de los elementos listados a continuació=
n: ˇ&=
nbsp;
Las historias de usuario ˇ&=
nbsp;
Los sprints ˇ&=
nbsp;
Las tareas ˇ&=
nbsp;
Las incidencias ˇ&=
nbsp;
Los códigos fuente ˇ&=
nbsp;
Pruebas ˇ&=
nbsp;
Retrospectivas ˇ&=
nbsp;
Modelos |
Cumple
parcialmente (PM) |
|
CM 2.2 Desarrollar, actualizar y usar un sistema de configura=
ción
y de Gestión del cambio. |
2 |
Sistema integrado de gestión de la configuración Sistema integrado de gestión de cambios (Ejemplo:
Jira o Travis) |
|
|
CM 2.3 Desarrollar o liberar líneas base para uso interno o p=
ara
su entrega al cliente. |
2 |
Desglose de trabajo (EDT) Autoridad designada para cambios. Realización de hojas de ruta (opcional). Realización de un plan. Trazabilidad de los elementos de la configuración. |
Cumple
parcialmente (PM) |
|
CM 2.4 Gestionar los cambios en los elementos de la gestión d=
e la
configuración. |
2 |
Solicitudes de cambio Flexibilidad de cambios Proceso establecido |
En gran medida cumple (LM) |
|
CM 2.5 Desarrollar, mantener actualizados y utilizar registro=
s que
describen los elementos de la gestión de la configuración. |
2 |
Los documentos que soportan la gestión de la configuración deben te=
ner
al menos las siguientes características: ˇ &nbs=
p; Fecha de origen ˇ &nbs=
p; Localización ˇ &nbs=
p; Versión aprobada ˇ &nbs=
p; Estado ˇ &nbs=
p; Trazabilidad |
No
cumple (DM) |
|
CM 2.6 Realizar auditorías de configuración para mantener la =
integridad
de las líneas base de configuración, cambios y contenido del sistema de
gestión de la configuración. |
2 |
Registro de auditorias Automatización del proceso Apertura de cuentas en sistemas de gestión de la configuración no F=
ree. |
No
cumple (DM) |
Fuente: Elaboración propia.=
|
Tabla 4<=
span
class=3Dtlid-translation> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Parti=
ally Meets (PM) |
|
|
|
|
Fuente: CMMI 2.0 Calificación a nivel de
prácticas.
Conclusiones:
ˇ&nb=
sp;
La capacidad de gestión según el CMMI es de nivel 1, es
decir, las pequeńas organizaciones tienen la capacidad inicial del proceso =
de
soporte de la gestión de la configuración. Para llegar al nivel 2 de madure=
z de
la capacidad es necesario una revisión a la planificación del proceso de
gestión.
ˇ =
En las pequeńas
organizaciones, la automatización de la gestión de la configuración es clave
para mejorar su eficiencia, calidad, productividad y competitividad. Una me=
jora
en la eficiencia es posible, mediante la implementación de herramientas
gratuitas entre ellas GitLab o Jira.
ˇ =
SCRUM, gestiona de un=
a manera
visual la gestión de la configuración con el uso de tableros, no está limit=
ado
en su capacidad como lo recomienda la IEEE 828 y el CMMI 2.0 que están basa=
dos en
documentación como evidencia real del trabajo realizado durante el proceso =
de
desarrollo.
Referenci=
as
bibliográficas.
Abran, A., Moore, J. W., Bourque,=
P.,
Dupuis, R., & Tripp, L. (2004). Software engineering body of knowledge. IEEE Computer
Society, Angela Burgess.
Akbar, M. A., Sang, J., Khan, A. =
A.,
Mahmood, S., Qadri, S. F., Hu, H. y Xiang, H. (2019). Success factors influencing
requirements change management process in global software development. Jour=
nal
of Computer Languages, 51, 112-130.
Bryan, W. L., Siegel, S. G. y Whi=
teleather,
G. L. (1982). Auditing throughout the software life cycle: A primer. Computer, (3), 57-67.
CMMI Institute, (2018). Modelo CM=
MI
2.0.
http://pdfmicroservice.eastus.-azurecontainer.io/protected?token=3DeyJhbGci=
OiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJGa-XJzdE5hbWUiOiJNYXggUmVuYXRvIiwiTWlkZGxlT=
mFtZSI6IiIsIkxhc3ROYW1lIj-oiWsO6w7FpZ2EgTMOzcGV6IiwiUGRmIjoiVjIwRnVsbE1vZGV=
sLnBkZiIsImlhdC-I6MTU5NTk3Njk2MCwiZXhwIjoxNTk1OTc4NzYwfQ.i1rL5ka1j2vUc9HIt-=
cxuNL2nimXNVMF0x9IfE2jEQZ
Dai, J. y Vasarhelyi, M. A. (2016=
). Imagineering Audit 4.0. Journal of
Emerging Technologies in Accounting, 13(1), 1-15.
Git. (2019). 5.1 Git en entornos
distribuidos - Flujos de trabajo distribuidos.
https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-traba=
jo-distribuidos#ch05-distributed-git
Hüttermann, M. (2012). DevOps for
Developers: Experts Voice in Web Development 1st ed. Apress.
https://doi.org/10.1007/978-1-4302-4570-4
IEEE 828. (2012). IEEE Standard f=
or
Configuration: Management in Syste=
ms and
Software Engineering. New York: IEEE.
Kaur, I. y Singh, H. (2017). Adva= nced version control (AVC): A paradigm shift from version control to conflict management. International Journal of Computer Applications, 167(10), 7-15.<= o:p>
Project Management Institute (201=
7).
Guía de los fundamentos para la dirección de proyectos (PMBOKŽ Guide). 6th =
ed. Newtown Square, Pa.: Project
Management Institute, Inc.
Uribe, E. H. y Ayala, L. E. V.
(2007). Del manifiesto ágil sus valores y principios. Scientia et technica,
13(34), 381-386.
PARA CITAR EL ARTÍCULO INDEXADO.
Renato Zúńiga,=
M.
R., Patricio Hurtado, G. P., & Pérez, J. M. (2020). La capacidad de la
gestión de la configuración en las pequeńas organizaciones de desarrollo de
software. ConcienciaDigital, 3(3), 466-4=
85. https://doi.o=
rg/10.33262/concienciadigital.v3i3.1339
El artículo que se publica es de
exclusiva responsabilidad de los autores y no necesariamente reflejan el
pensamiento de la Revista Concienc=
ia
Digital.
El
artículo queda en propiedad de la revista y, por tanto, su publicación parc=
ial
y/o total en otro medio tiene que ser autorizado por el director de la Revista Conciencia Digital.
[1] Insti=
tuto
de Tecnologías Sudamericano, Cuenca, Ecuador, mzuniga@sudamericano.edu.ec
[2] Instituto=
de
Tecnologías Sudamericano, Cuenca, Ecuador, gphurtado@sudamericano.edu.ec
[3] Instituto de Tecnologías Sudamericano, Cuenca, Ecuador, jperez@sudamericano.edu.ec