Professional Documents
Culture Documents
420-434
RESUMEN
El mantenimiento de software es una actividad muy importante y crtica para las empresas que conforman
la industria del software. Se puede considerar que el problema de costos durante la etapa de mantenimiento
reside en que no se tienen en cuenta aspectos de mantenibilidad durante el desarrollo del producto software.
Es por esto que este artculo propone el modelo de referencia MANTuS el cual ofrece buenas prcticas
para el proceso de desarrollo de software, las que pretenden que los artefactos software generados, durante
las diferentes etapas del ciclo de vida de desarrollo, incluyan las subcaractersticas de mantenibilidad
establecidas por la norma ISO/IEC 25010. Este modelo de referencia contiene una serie de prcticas
base, definidas para los procesos de anlisis de requisitos de software, diseo arquitectural de software,
diseo detallado de software, construccin de software, pruebas de evaluacin de software y gestin de
la documentacin del software. Incluir las prcticas en el proceso de desarrollo podra ayudar a potenciar
cada una de las subcaractersticas de mantenibilidad del producto software descritas en ISO/IEC 25010.
El modelo de referencia MANTuS ha sido evaluado por medio de un estudio de caso donde se evidenci
que llevar a cabo las prcticas propuestas por el modelo de referencia para el proceso de construccin
de software permiti potenciar la mantenibilidad del producto obtenido.
ABSTRACT
Software maintenance is a very important and critical activity for software companies. Problem of costs
during the maintenance stage lies on the fact that maintainability aspects are not taken into account during
the development of the software product. For this reason, this paper proposes the MANTuS reference
model, which provides a set of practices for software development process in hopes that the software
artifacts generated during the different development life cycle stages include the maintainability sub-
characteristics (established by the standard ISO/IEC 25010). This reference model contains a number of
base practices defined for the processes: software requirements analysis, software architectural design,
software detailed design, software construction, software qualification testing, and software documentation
management. To include practices in the development process could help to maximize each software
product maintainability sub-characteristic described in ISO/IEC 25010. Outcomes of apply the MANTuS
reference model through a case study shown that using practices for software construction process has
allowed to improve the maintainability of the obtained product.
1 Universidad del Cauca. Grupo IDIS. Facultad de Ingeniera de Electrnica y Telecomunicaciones. Calle 5 N 4-70. Popayn,
Cauca, Colombia.
E-mail: jderazo@unicauca.edu.co; asflorez@unicauca.edu.co; fjpino@unicauca.edu.co
* Autor de correspondencia.
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
421
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
ciclo de vida del mantenimiento, que es una contiene un conjunto de procesos definidos que
adaptacin del estndar ISO/IEC 12207[10]. colaboran entre ellos con el fin de mejorar este
ISO 12207 es un framework de referencia tipo de mantenimiento.
que cubre todos los aspectos del ciclo de
vida del software; sin embargo, no detalla Los estudios [4, 8-9, 11-12] tienen como tema
cmo implementar las tareas y actividades principal la etapa de mantenimiento de software,
incluidas en el proceso. MANTEMA incorpora proponen modelos y metodologas de mantenimiento
una serie de actividades bien organizadas de de software, con el fin de controlar y mejorar
acuerdo al tipo de mantenimiento, apoyando este proceso, ya que esta etapa es la ms costosa
el control de documentacin, se definen cinco y conflictiva del ciclo de vida del software. Los
tipos de mantenimiento: correctivo urgente, estudios anteriores se centran nicamente en la etapa
correctivo no urgente, perfectivo, preventivo de mantenimiento del software al final del ciclo de
y adaptativo. Adems de esto, se considera la vida del mismo, planteando una serie de actividades
participacin de tres tipos de organizaciones organizadas que permiten mejorar esta etapa con
en el proceso de mantenimiento: el cliente que el fin de reducir el problema de altos costos que
es el propietario del software y requiere del se presenta durante la misma. Sin embargo, estas
servicio de mantenimiento; el mantenedor es propuestas no tienen en cuenta la caracterstica de
la organizacin que cumple con el servicio de mantenibilidad de software ni plantean soluciones
mantenimiento; el usuario que utiliza el software para incorporarla al producto durante el proceso
mantenido. De igual forma MANTEMA tambin de desarrollo, siendo este el principal objetivo del
proporciona plantillas estndar para cada uno modelo de referencia MANTuS presentado en este
de los documentos generados. trabajo. Este modelo de referencia de procesos ha
Pino, Ruiz, Garca y Piattini [4] presentan Agile sido definido teniendo en cuenta los requerimientos
MANTEMA como una propuesta metodolgica para modelos de referencia de procesos indicados en
para el mantenimiento de software que se centra la norma ISO/IEC 33004, los procesos definidos en
en las pequeas organizaciones. Especifica una este siguen la misma estructura de los presentados
estrategia de mantenimiento que define qu en la norma ISO/IEC 15504-5 [13].
se necesita hacer, cundo, cmo y por quin.
Tambin establece una serie de elementos Estrategia de investigacin
como los tipos de mantenimiento, niveles de Para la construccin del modelo de referencia
servicio y niveles de capacidad, con el fin de MANTuS se utiliz una estrategia de investigacin
manejar la complejidad que es inherente al que se apoya en el mtodo Investigacin-Accin
proceso de mantenimiento. Esta metodologa multiciclo con bifurcacin [14-15]. La estrategia
permite a las pequeas compaas definir su de investigacin consta de tres ciclos:
propio proceso de mantenimiento, tomando
en cuenta sus caractersticas y necesidades el ciclo de investigacin conceptual donde se
particulares. El objetivo de Agile MANTEMA analizaron los trabajos relacionados con inclusin
es hacer los elementos de proceso descritos en de caractersticas de mantenibilidad al producto
MANTEMA ms livianos e incorporarlos en la software durante el proceso de desarrollo;
gestin de proyectos giles usando el mtodo el ciclo de investigacin metodolgico ejecutado
Scrum. Esta metodologa describe un proceso, para la definicin del modelo de referencia, este
niveles de servicio, niveles de desempeo de ciclo est dividido en tres fases: identificacin
proceso y niveles de capacidad de proceso. de los atributos software, clasificacin de los
Una propuesta que trata el mantenimiento de atributos software y realizacin del modelo de
software en detalle es el modelo de madurez referencia. Los resultados obtenidos en las dos
para el mantenimiento correctivo CM3, el que es primeras fases se encuentran documentados
tratado en [11], donde se sugiere que se deben en [16]. En la fase de realizacin del modelo
crear modelos de procesos especializados para de referencia se definen las prcticas base
cada uno de los tipos de mantenimiento. CM3 (actividades) necesarias para incorporar al
es un modelo de procesos especificamente para producto software cada uno de los elementos
la categora de mantenimiento correctivo, que identificados con el fin de potenciar las sub-
422
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
423
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
software durante el proceso de desarrollo con el fin de requisitos de software desde la perspectiva de
de potenciar esta caracterstica y que sean aplicables mantenibilidad, Diseo arquitectural de software
en el contexto de empresas desarrolladoras de desde la perspectiva de mantenibilidad, Diseo
software. Al igual que otros modelos de referencia detallado de software desde la perspectiva de
el alcance de este es la descripcin concreta de los mantenibilidad, Construccin de software desde la
procesos y no la especificacin detallada de los perspectiva de mantenibilidad, Pruebas de evaluacin
elementos particulares de la implementacin, es de software desde la perspectiva de mantenibilidad,
decir, la descripcin de los procesos establece lo Gestin de la documentacin desde la perspectiva
que se debe lograr mas no determina cmo debe de mantenibilidad. En la Tabla2 se presenta para
lograrse. Es por esto que los procesos pueden ser cada proceso del modelo de referencia su nombre,
implementados de diferentes formas obteniendo el identificador y propsito. Adems, las descripciones
mismo resultado. de los procesos del modelo de referencia MANTuS
se hacen en trminos de sus propsitos y resultados.
Procesos del modelo Los enunciados de los propsitos y resultados de los
El modelo de referencia MANTuS asume que la procesos son elementos obligatorios segn el estandar
mantenibilidad de software es un aspecto fundamental ISO/IEC 33004. La descripcin de los procesos
del producto que debe ser considerado desde el del modelo de referencia sigue la estructura de los
incio del ciclo de vida del mismo. Es por esto que procesos del estndar internacional ISO/IEC 15504-
se establecen los siguentes seis procesos: Anlisis 5. Estas descripciones incorporan el enunciado del
424
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
propsito del proceso y el conjunto de resultados procesos son independientes y que el proceso de
del proceso. El enunciado del propsito describe Gestin de la documentacin, desde la perspectiva
a un alto nivel el objetivo general de llevar a cabo de mantenibilidad es transversal a los otros, ya que
el proceso. El conjunto de resultados del proceso este es un proceso de soporte que puede ser ejecutado
describe los elementos con los que se demuestra el durante los otros cinco procesos. La vista general
logro exitoso de su propsito, como la produccin del modelo de referencia combina y sintetiza las
de un artefacto, un cambio significativo de estado prcticas base definidas en los procesos de todas
o el cumplimiento de restricciones especificadas. las subcaractersticas de mantenibilidad.
Relaciones entre los procesos del modelo Comunidad de inters y Contexto previsto de uso
El modelo de referencia que apoya la inclusin de El modelo de referencia MANTuS fue construido
subcaractersticas de mantenibilidad al producto para ser aplicado en empresas desarrolladoras de
software durante el proceso de desarrollo est software que deseen garantizar la mantenibilidad
compuesto por dos vistas: la vista especfica para de sus productos durante el proceso de desarrollo.
cada una de las cinco subcaractersticas y la vista Adems, empresas que estn interesadas en obtener
general para la caracterstica de mantenibilidad, la la certificacin de mantenibilidad del Sistema de
cual agrupa las vistas especficas. En la Figura1 se Gestin de la Calidad del Producto Software ISO
observa la vista general del modelo de referencia 25000 de AENOR [21-22].
con el nmero de prcticas base definidas para cada
proceso de las subcaractersticas de mantenibilidad. Los atributos identificados, sobre los cuales se ha
El modelo de referencia obtenido se basa en la basado el modelo de referencia, estn relacionados
informacin y anlisis realizado en cada una de directamente con las propiedades a evaluar en un
las actividades anteriores. producto software por el esquema de evaluacin
de mantenibilidad ISO 25000 realizada por AQC
Los seis procesos que conforman el modelo de Lab [23]. Dichas propiedades estn relacionadas
referencia MANTuS deben ser entendidos desde con el incumplimiento de reglas, la documentacin
una vista general. Estos procesos no presentan del cdigo, la complejidad, la estructuracin, el
relacin entre s, son independientes, es decir, tamao de los mtodos, el cdigo duplicado, el
para alcanzar los resultados de un proceso no es nivel de acoplamiento, el balance inestabilidad-
necesario haber logrado los resultados de otro u abstraccin, los ciclos y la cohesin. En el trabajo
otros procesos, lo que da flexibilidad al modelo de clasificacin de atributos, ejecutado realizado
de referencia. En la Figura1 se observa que estos en esta investigacin, se realiz una comparacin
425
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
Figura1. Vista general del modelo de referencia (ARS= Anlisis de requisitos de software, DAS=
Diseo arquitectural de software, DDS= Diseo detallado de software, CS= Construccin de
software, PES= Pruebas de evaluacin de software).
de los atributos de mantenibilidad identificados resultados del proceso cada resultado est asociado
versus las propiedades de mantenibilidad descritas a las subcaractersticas de mantenibilidad en las que
por el esquema de evaluacin. Del anlisis de influye, siendo CA= capacidad para ser analizado;
esta comparacin se puede establecer de manera M=modularidad; CM=capacidad para ser modificado;
general que los atributos facilidad de entendimiento, CP=capacidad para ser probado; R=reusabilidad.
complejidad y simplicidad guardan relacin con En la seccin prcticas base se proporciona la
todas las propiedades de mantenibilidad, mientras definicin de las actividades y las tareas necesarias
que los atributos comentarios, encapsulamiento, para alcanzar el propsito del proceso y cumplir con
estandarizacin, herencia y polimorfismo tienen los resultados del mismo; cada prctica base est
relacin con un menor nmero de propiedades. asociada a uno o ms resultados. Por ltimo, cada
Tambin se observ que la propiedad complejidad proceso describe los productos de trabajo de salida
tiene relacin con todos los atributos identificados; (PTS) correspondientes, los que estn relacionados
sin embargo, la propiedad balance inestabilidad- con los diferentes resultados de proceso.
abstraccin presenta menor relacin con estos.
Por otra parte, la comparacin realizada permiti EVALUACIN DEL MODELO
comprobar que todos los atributos identificado; estn DE REFERENCIA MANTuS
relacionados con a lo menos dos de las propiedades
de mantenibilidad, y adems que cada una de estas La evaluacin del modelo de referencia MANTuS
propiedades se ve influenciada por al menos seis de se realiz mediante un estudio de caso que permiti
los atributos definidos. la aplicacin del proceso de Construccin de
software desde la perspectiva de mantenibilidad.
El modelo de referencia MANTuS fue construido para Este estudio de caso fue realizado con ocho
ser usado en contextos de desarrollo de software donde desarrolladores de software que ejecutaron cambios
sea importante incluir al producto software atributos a dos versiones del mismo programa: una versin
de mantenibilidad para potenciar esta caracterstica. que evidencia la utilizacin de algunas prcticas
Asimismo, la especificacin de los resultados base del proceso de construccin del modelo
permite determinar aspectos a incluir o mejorar en la de referencia MANTuS (cdigo B) y otra que
implementacin de los procesos existentes. no las utiliza (cdigo A). Para la ejecucin de
este estudio de caso se tom como referencia la
Descripcin detallada de los procesos plantilla protocolo para planeacin de estudios
Debido a restricciones de espacio, en esta seccinsolo de caso planteado en [18]. A continuacin, se
se presenta el detalle del proceso construccin de describe cada uno de los pasos realizados en el
software desde la perspectiva de mantenibilidad estudio de caso, antecedentes, diseo, sujetos de
(ver Tabla3), los dems procesos y el modelo de investigacin y unidad de anlisis, procedimiento
referencia MANTuS completo se puede encontrar de campo, preparacin de recoleccin de datos,
en [20]. Es importante resaltar que en la seccin ejecucin de caso y anlisis.
426
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
Prcticas base
DEV-MANT.4.PB1: Utilizar comentarios. Hacer uso de comentarios adecuados en el cdigo fuente. [Resultados: a, c, d]
DEV-MANT.4.PB2: Describir propsitos. Explicar el propsito de las funciones, subrutinas, variables y constantes.
[Resultados: a, c, d]
DEV-MANT.4.PB3: Verificar los flujos de control. Incluir solamente los flujos de control necesarios. [Resultados: b, c, e, f]
DEV-MANT 4.PB4: Organizar cdigo. El cdigo fuente debe ser indentado. [Resultado: c, d]
DEV-MANT.4.PB5: Asignar nombres claros. Dar nombres descriptivos a las variables. [Resultado: c, d]
DEV-MANT.4.PB6: Controlar abreviaciones. Hacer poco uso de abreviaciones. [Resultado: c, d]
DEV-MANT.4.PB7: Controlar sentencias. Evitar sentencias largas en el cdigo fuente, es mejor mantener las lneas de
cdigo cortas, aunque esto implica separar las sentencias en mltiples lneas. [Resultado: c, d]
DEV-MANT.4.PB8: Controlar parntesis. Hacer correcto uso de los parntesis para mejorar la facilidad de lectura de las
expresiones aritmticas y lgicas. [Resultado: c, d]
DEV-MANT.4.PB9: Determinar funcionalidades. Implementar solamente las funcionalidades necesarias. [Resultados: b, c, e, f]
DEV-MANT.4.PB10: Dividir mtodos. Mantener mtodos simples, es decir, dividir los mtodos que tengan muchas
condiciones. [Resultados: b, c, e, f]
DEV-MANT.4.PB11: Controlar tamao. Evitar que el tamao del cdigo crezca innecesariamente. [Resultados: c, f]
DEV-MANT.4.PB12: Controlar nivel de anidacin. Evitar las estructuras de control anidadas innecesarias, ya que estas
son ms complejas que las estructuras de control secuenciales. [Resultados: b, c, e, f, g]
DEV-MANT.4.PB13: Evitar duplicacin. Detectar cdigo duplicado, extrayndolo en un nuevo procedimiento y reemplazando
todas las instancias del cdigo duplicado por llamadas al nuevo procedimiento. [Resultados: b, e, f, i]
DEV-MANT.4.PB14: Definir estndares. Tener un conjunto de estndares de programacin en la escritura de cdigo para
evitar la individualidad entre los programadores. [Resultados: d, h]
DEV-MANT.4.PB15: Utilizar convenciones. Hacer uso de convenciones estndar para el nombrado de paquetes, clases,
mtodos y variables. [Resultados: d, h]
DEV-MANT.4.PB16: Controlar tamao de unidad. Las piezas de funcionalidad de ms bajo nivel deben mantenerse
pequeas para que sean centradas y fciles de entender. [Resultados: b, c, e, f]
DEV-MANT.4.PB17: Verificar trazabilidad. Verificar peridicamente que los artefactos de una etapa sean consistentes con
artefactos de la etapa anterior. [Resultados: c, j, k]
DEV-MANT.4.PB18: Actualizar artefactos. Actualizar los artefactos cuando se presenten cambios. [Resultados: c, j, k]
Producto de trabajo de salida
PTS-06 Unidad de software que considera la mantenibilidad [Resultados: a, b, c, d, e, f, g, h, i, j, k]
PTS-04 Registro de trazabilidad [Resultados: j, k]
427
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
428
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
Las respuestas de los participantes a esta encuesta Con los tiempos registrados por los participantes al
soportaron los resultados cuantitativos obtenidos realizar las modificaciones solicitadas, se elaboraron
a partir de los tiempos registrados en las guas. De dos tablas resmenes con los tiempos invertidos
manera similar se realizaron preguntas para evaluar (Duracin) por cada uno de ellos y Correcto? que
la subcaracterstica capacidad para ser modificado. comprende los valores s o no, los cuales indican
que la modificacin fue realizada con xito o no,
Ejecucin del caso respectivamente. En la Tabla 4 se muestran los
La aplicacin del estudio de caso sigui el tiempos invertidos por los participantes al realizar
procedimiento de campo mencionado anteriormente: las modificaciones de los temes 1, 2, 3, 4, 6, 7,
429
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
8, y el tiempo total al realizar todos los cambios. con xito y sin xito. Partiendo de este anlisis se
Adems la tabla incluye el clculo del tiempo total obtuvo como resultado general que la tasa de xito
y promedio invertido por todos los participantes de modificacin es mucho mayor para el cdigo
para cada uno de los temes. B (100%) que para el A (42,9%), lo que evidencia
que el incluir las prcticas del modelo de referencia
En la Tabla5 se presenta para cada participante los definidas para el proceso de construccin aumenta la
tiempos invertidos al realizar el anlisis del cdigo tasa de xito de realizar los cambios correctamente.
para los tems 4, 5, 7, 8 y el tiempo total.
PA2: La utilizacin de prcticas base del proceso
Anlisis de resultados de construccin del modelo de referencia MANTuS
Para dar respuesta a las preguntas planteadas en este permite que el tiempo invertido al realizar cambios al
estudio de caso se realiz el anlisis presentado a producto software genere los resultados esperados?
continuacin.
El tiempo total invertido para realizar todos
PA1: Aumenta la tasa de xito para realizar cambios los cambios al producto fue hallado para cada
correctamente con la utilizacin de prcticas participante sumando los tiempos finales empleados
base del proceso de construccin del modelo de en el desarrollo de cada tem de la gua tanto en
referencia MANTuS? modificacin como en anlisis. Los datos hallados
indican que el participante del grupo A que realiz los
Para cada grupo se hall la tasa de xito de cambios en menor tiempo lo hizo en 02:05:53 (hh/
modificacin total teniendo en cuenta los siete mm/ss) mientras que para el grupo B el participante
tems de la gua relacionados con la realizacin con menor tiempo utiliz 02:06:05 (hh/mm/ss). A
de cambios. Este clculo fue encontrado teniendo pesar de que estos dos tiempos difieren por poco
en cuenta el total de cambios a realizar por todos (00:00:12), la tasa de xito del participante del grupo
los participantes, el total de cambios realizados A (57,1%) es considerablemente menor que la del
430
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
participante del grupo B (100%), lo que indica que el encuentro de fallos planteada en la norma ISO/
el tiempo invertido por el participante del grupo A IEC 9126 con la frmula (1):
no se ve reflejado en los resultados obtenidos al
realizar las modificaciones. Al realizar este mismo TEF = 1 (A/B) (1)
anlisis con el participante que obtuvo el segundo
menor tiempo en cada uno de los grupos, se puede 0 TEF 1, entre ms cercano a 1 mejor.
notar que el participante del grupo B invirti mayor
tiempo (02:23:03) con respecto al participante del Donde:
grupo A (02:15:17), sin embargo, logr realizar
correctamente todos los cambios solicitados, lo A = nmero de fallos cuyas causas no se han
que se ve reflejado en su tasa de xito (100%) que encontrado
es mucho mayor a la del participante PA2 (14,3%). B = nmero de fallos registrados.
Haciendo el mismo anlisis para los participantes Los valores obtenidos para TEF indican que la tasa
restantes de los dos grupos, se observa el mismo de xito en el encuentro de causa de fallos para el
comportamiento, lo cual indica que la inclusin grupo A es del 25% y para el grupo B es 100%, lo
de las prcticas base del modelo de referencia al que permite verificar que incluir las prcticas base
proceso de construccin permite que el tiempo del modelo de referencia al proceso de construccin
invertido al realizar cambios al producto software permite aumentar la tasa de xito en el encuentro
genere los resultados esperados. de la causa de fallos.
PA3: Utilizar las prcticas base del proceso de PA4: Disminuye el tiempo de anlisis de fallos
construccin del modelo de referencia MANTuS con la utilizacin de prcticas base del proceso de
permite aumentar la tasa de xito en el encuentro construccin del modelo de referencia MANTuS?
de la causa de fallos?
El tiempo de anlisis de fallos se hall haciendo uso
La tasa de xito en el encuentro de causa de fallos de la mtrica tiempo de anlisis de fallo establecida
(TEF) fue hallada para cada uno de los participantes en la norma ISO/IEC 9126 que se calcula mediante
teniendo en cuenta los resultados del tem relacionado la frmula (2):
con el anlisis de fallos planteado en la gua. Para
esto se tuvo en cuenta la mtrica tasa de xito en TAF Sum(T)/N (2)
431
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
0 TAF, entre ms pequeo sea TAF mejor. Validez de conclusin: para evitar el riesgo de
variacin en los resultados debido a diferencias
Para hallar el tiempo (T) se hace uso de la frmula (3): individuales de los sujetos de investigacin los
participantes elegidos fueron desarrolladores
T = Tout Tin (3) de software (estudiantes de ltimos semestres
de Ingeniera de Sistemas de la Universidad del
Donde: Cauca) los que tenan conocimientos adecuados
de programacin orientada a objetos y manejo
Tout = tiempo en el que las causas del fallo son del lenguaje C++. Lo anterior permiti reducir la
encontradas heterogeneidad en el grupo de estudio ya que ellos
Tin = tiempo en el que el reporte del fallo es recibido tenan conocimientos y antecedentes similares.
N: nmero de fallos registrados.
Validez de constructo: en la recoleccin de datos se
Debido a que el nmero de fallos cuyas causas se tuvieron en cuenta tanto medidas de tiempo como
deben hallar para cada tem planteado en la gua las observaciones individuales de los participantes
es uno, al reemplazar N la mtrica queda como se para cada modificacin, lo que permiti hacer un
muestra en la frmula (4): anlisis ms completo comparando estos dos aspectos.
432
Erazo Martnez, Florez Gmez y Pino: Generando productos software mantenibles desde el proceso de desarrollo:
comentaron que el cdigo puede ser simplificado demuestran que la utilizacin de prcticas base del
para evitar la redundancia y los mens pueden ser proceso de construccin del modelo de referencia
incluidos en funciones para facilitar su modificacin. MANTuS permite potenciar la mantenibilidad del
producto software.
Por el contrario, todos los participantes que
trabajaron con el cdigo B concluyeron que este Como trabajo futuro se ha iniciado un estudio de caso
s tiene alta mantenibilidad debido, a que las con el fin de evaluar todo el modelo de referencia
funcionalidades estaban separadas correctamente propuesto. Este se est llevando a cabo en la
y el cdigo estaba documentado e indentado. asignatura Proyecto II del Programa de Ingeniera de
Uno de los participantes afirm que las clases Sistemas de la Universidad del Cauca, incorporando
tenan un bajo acoplamiento y una alta cohesin, las prcticas del modelo de referencia a tres procesos
lo cual permita que un cambio, solo afectara a de desarrollo diferentes (Scrum-XP, Tutelcan,
la parte directamente relacionada con l y no a UP-VSE). De igual forma se propene, realizar la
todo el programa. Otro participante concluy validacin del modelo de referencia proyectado en
que la estructura del cdigo puede ser extendida un entorno empresarial mediante un estudio de caso
fcilmente para agregar nuevas funcionalidades. y aplicar el modelo de referencia estimado en una
organizacin desarrolladora de software que desee
CONCLUSIONES Y TRABAJO FUTURO obtener la certificacin de mantenibilidad realizada
por AQC, paravalidar si inclusin de las prcticas
En este trabajo se ha propuesto un modelo de definidas permiten alcanzar este fin.
referencia para la inclusin de subcaractersticas
de mantenibilidad al producto software durante el Con la aplicacin del modelo de referencia en un
proceso de desarrollo, este fue elaborado a partir entorno empresarial se puede obtener informacin que
de: (i)la identificacin de los atributos de software permita definir cul es el costo de incluir MANTuS en
que influyen en la mantenibilidad del producto, el proceso de desarrollo de la organizacin objetivo,
(ii)la clasificasin de los atributos identificados de esto con el fin de analizar el costo-beneficio e impacto
acuerdo a las subcaractersticas de mantenibilidad que tiene la aplicacin de las prcticas base sobre las
y a los procesos en los que se presentan, (iii) el actividades de desarrollo. Sin embargo, a partir de
analisis de como potenciar cada subcaracterstica, los resultados iniciales obtenidos del caso de estudio
(iv)la estructuracin del modelo de referencia y realizado en esta investigacin, se puede observar
(v)la evaluacin del modelo de referencia realizada que utilizar MANTuS puede traer beneficios a una
por medio de un caso de estudio. Se observa que organizacin ya que las actividades de mantenimiento
la mantenibilidad de software es una caracterstica se pueden realizar de manera ms efectiva, lo que
de calidad que se debe considerar desde etapas conlleva a reducir costos operacionales.
tempranas del ciclo de vida del producto y durante
todo el proceso de desarrollo de software con el Aunque la validacin de la propuesta aun es
fin de disminuir los costos de desarrollo y obtener limitada, como se ha mencionado anteriormente, se
un producto altamente mantenible, es por esto que est trabajando en aplicar el modelo de referencia
las prcticas base definidas para los procesos del MANTuS en la industria con el fin de obtener
modelo de referencia son sencillas, esto con el fin realimentacin y validacin de su aplicacin en
de no aumentar el esfuerzo durante el desarrollo; contextos industriales.
sin embargo, es importante resaltar que estas deben
considerarse durante el proceso de desarrollo y no en AGRADECIMIENTOS
etapas posteriores del ciclo de vida del producto. De
la aplicacin del estudio de caso se puede concluir Este trabajo ha sido apoyado por el proyecto Marco
que la inclusin de las prcticas base del modelo de trabajo para la elicitacin de requisitos no
de referencia al proceso de construccin permite funcionales basado en la gestin del conocimiento
potenciar la mantenibilidad del producto software, (Vicerrectora de Investigaciones de Unicauca -
ya que la capacidad para ser analizado y modificado VRI ID 4354). Adems Francisco J. Pino agradece
del producto aumentan considerablemente. Los a la Universidad del Cauca donde trabaja como
resultados obtenidos en el estudio de caso aplicado profesor titular.
433
Ingeniare. Revista chilena de ingeniera, vol.24 N3, 2016
434