PLAN DE GESTIN DE MANTENIMIENTO

BASADO EN ISO 14764

Equipo de Desarrollo de ProActSoft

Sandra Camuas
Sergio Martnez
David Valero

ndice
INTRODUCCIN

ERRORES ENCONTRADOS
RESPONSABLES
ESTUDIO DE VIABILIDAD

2
2
2

PLAN DE MANTENIMIENTO

PROCESO DE MANTENIMIENTO SEGN ISO 14764

DECISIONES ACERCA DE LOS TIPOS DE MANTENIMIENTO

4
8

ProActSoft S.L

Pgina 1

Introduccin

Errores encontrados

Gracias al sistema de tickets integrado en nuestra web del proyecto, hemos podido
recibir feedback de nuestros usuarios (empresa SanaCare) para poder hacer un
mantenimiento adecuado a la aplicacin AncientDroid. Los fallos reportados han sido
los siguientes:
-

Notificacin errnea Ha superado los ingresos mientras se realizaba ciertas

operaciones que no implicaban dicha notificacin.
Error en el sistema de notificaciones al superar el lmite de gastos, puesto que
no realiza ninguna.
Aadir un nuevo tipo de gasto (dinero recibido o prstamos) que se muestre en
la vista grfica con forma de queso.

Responsables

Dado que somos una pequea empresa con muy poco personal y que el nico proyecto
que tenemos en la actualidad en desarrollo, a la espera de que en las prximas
semanas se cierren nuevos acuerdos, es la aplicacin AncientDroid, todo el equipo de
desarrollo ser el encargado llevar a cabo el mantenimiento de la misma.
Sin embargo, atendiendo a los roles inicialmente acordados entre el grupo de trabajo,
David Valero, encargado de los departamentos de testing y mantenimiento, ser el
responsable de liderar y tomar las decisiones concernientes a la correccin de los fallos
remitidos por nuestros usuarios.
Estudio de viabilidad

Atendiendo a los issues recibidos, se ha procedido a realizar un estudio de viabilidad

simplificado de cada uno de los mismos:
#

Issue

Duracin
(h)

Not. Errnea

2 Impl.
3
Pruebas.

Error notific.

1,5
Impl.

ProActSoft S.L

Coste/h
()

8,52
Impl.
4,55
Pruebas.

Total (h
- )

5
horas.
30,69.

4,5
horas.

Observaciones
Su localizacin es muy concreta y
su reparacin no implica ms all
de modificar un par de lneas de
cdigo.
As mismo, este mantenimiento
es del tipo correctivo, al cual
tiene derecho el cliente sin coste
alguno*.
Al igual que el caso anterior, su
arreglo pasa por modificar un par
Pgina 2

3
Pruebas.

Nueva
funcionalidad

2
Anlisis.
1
Diseo.
2 Impl.
4
Pruebas.

26,43.

10,23
Anlisis.
10,23
Diseo.
8,52
Impl.
4,55
Pruebas.

9
horas.
65,93.

de lneas de cdigo.
El tipo de mantenimiento es
nuevamente correctivo, al cual
tiene derecho el cliente sin
ningn tipo de sobrecoste*.
En este caso es necesario
someter este desarrollo a las
disciplinas de ingeniera vistas en
el PUD para adecuarlo a la
metodologa
de
desarrollo
utilizada en el proceso de
construccin de la aplicacin.
El tipo de mantenimiento en este
caso es perfectivo, al cual tiene el
derecho el cliente abonando el
sobrecoste que ello suponga.

*El coste total que supondra al cliente el mantenimiento es de 0, por lo que el nico
gasto aqu presente sera el temporal.

Issue #X.
1
2
3

Resumen de Costes
Coste ()
0
0
65,93
65,93

Coste (horas)
5
4,5
9
18,5 horas

La temporalidad estimada (sin realizar ninguna planificacin con el detalle de la

realizada en el PUD) teniendo en cuenta que el equipo de desarrollo consta de 3
personas ser de 4 das.
Con todo lo aqu expuesto, el proyecto resulta viable para la empresa y se proceder a
resolver las peticiones demandas mediante un adecuado plan de mantenimiento.
Plan de mantenimiento

Nuestra empresa toma como referencia la norma internacional ISO 14764 para llevar a
cabo un plan de mantenimiento sobre todos nuestros productos software, siempre en
aras de proveer al cliente y a los usuarios finales la mxima calidad posible.

ProActSoft S.L

Pgina 3

Proceso de mantenimiento segn ISO 14764

Proceso de implementacin.
Gracias al uso de tickets, hemos detectado que la empresa SanaCare (por medio
de los usuarios de la aplicacin) nos han informado de lo siguiente:
-

Informe de Problemas:
o Notificacin errnea Ha superado los ingresos mientras se realizaba
ciertas operaciones que no implicaban dicha notificacin.
o Error en el sistema de notificaciones al superar el lmite de gastos,
puesto que no realiza ninguna.
Peticin de Modificacin:
o Aadir un nuevo tipo de gasto (dinero recibido o prstamos) que se
muestre en la vista grfica con forma de queso.

As mismo, como desarrolladores de AncientDroid, disponemos de toda la

documentacin concerniente a la aplicacin para facilitar la localizacin y posible
solucin de los problemas encontrados.
El plan de mantenimiento consistir en atender todas las peticiones realizadas
por SanaCare en la mayor brevedad de tiempo posible, teniendo en cuenta que la
implementacin y desarrollo de la gestin de la configuracin ya fue realizada al
momento de la entrega de la aplicacin, all por el mes de Diciembre. Evidentemente,
se har uso de la infraestructura empleada (maven junto con svn) para poder llevar un
control de los cambios efectuados, as como hacer uso de toda la documentacin
producida.
Como se observa en el estudio de viabilidad previo, son supuestos que no
implican un gasto excesivo (ni temporal ni econmico) y resultan sencillos de resolver,
por lo que se aceptan las modificaciones y correcciones sugeridas por SanaCare.
Anlisis del problema y modificacin.
-

En el issue #1:
o El fallo se produca en una funcin denominada enviarNotificacion()
establecida en la clase Notificacion.java residente en el mdulo 3.
o El fallo consista en un error a la hora de realizar el clculo del lmite de
gastos y el error que se dejaba como margen para hacer saltar la
notificacin.
o Adems, exista otro error producido al no superarse el lmite de gastos
o cuando no haban ni ingresos ni gastos puesto que este ltimo caso no
estaba siquiera contemplado en la implementacin.

ProActSoft S.L

Pgina 4

o La solucin ha consistido en recalcular las condiciones para mostrar

segn qu tipo de notificacin as como aadir una serie de if else para
contemplar los supuestos comentados en el punto anterior.
Todo esto se puede apreciar de manera simplificada a continuacin y en nuestro
repositorio de svn, en la carpeta mantenimiento/src/modulo3.
public static String enviarNotificacion() {
[ ]
if(gastos>=tope&&gastos<=(tope+(tope*error))) notificacion="Ha superado el
limite";
else{
if(gastos>=(tope+(tope*error))&&gastos<=ingresos)
notificacion="Ha superado mas del limite";
else {
if(gastos>=ingresos)
notificacion="Ha superado sus ingresos";
else{
/*Casos nuevos ha tener en cuenta*/
if(ingresos==0)
notificacion="No tiene ingresos";
else{
if(tope==0) notificacion="No tiene tope";
else notificacion="No tiene error";
}
}
}
}
return notificacion;
}

En el issue #2:
o El fallo se produca en una funcin denominada tipoGasto() establecida
en la clase GraficoQueso.java residente en el mdulo 2.
o El fallo radicaba en el lmite, que estaba mal fijado. As, al introducir un
ingreso cuya cantidad estuviese acotada en el siguiente intervalo
[0,3000], la aplicacin la dara por vlida; sin embargo, la forma
correcta de proceder sera un ingreso acotado entre [600,3000].
o La solucin ha consistido en recalcular el lmite del switch case
oportuno.
Todo esto se puede apreciar de manera simplificada a continuacin y en
nuestro repositorio de svn, en la carpeta mantenimiento/src/modulo2.

ProActSoft S.L

Pgina 5

private static String tipoGasto(char c, int n){

String ret=" ";
switch (c){
[]
case 'I': //Corregido el fallo
if(600<=n&&n<=3000) ret="Ingresos "+n;
break;
}
return ret;
}

En el issue #3:
o Gracias al diseo modular y orientado a objetos empleado en el
desarrollo de AncientDroid, la modificacin de cdigo es realmente
mnima.
o El grfico en forma de queso se actualiza automticamente conforme
a los datos de entrada que posea, es decir, se pueden aadir nuevas
casusticas a la funcin de la cual se nutre, que ste generar una nueva
porcin en el grfico consistente al nuevo valor introducido, que en el
caso que nos ocupa, se corresponde con prstamos / dinero prestado.
o Por todo ello, la solucin radica en aadir un nuevo case al switch de la
funcin corregida en el punto anterior que contemple este nuevo caso.
Lo concerniente a la vista (GUI) y al resto de funcionalidad
interaccionable con el usuario no se ve afectada por este aadido.
Todo esto se puede apreciar de manera simplificada a continuacin y en
nuestro repositorio de svn, en la carpeta mantenimiento/src/modulo2.
private static String tipoGasto(char c, int n){
String ret=" ";
switch (c){
[]
case 'P': //Nuevo tipo de gasto
if(10<=n&&n<=100) ret="Prestamo "+n;
break;
}
return ret;
}

ProActSoft S.L

Pgina 6

Implementacin de la modificacin.
Para llevar a cabo la implementacin ser necesario lo siguiente:
o La arquitectura del sistema. Como se puede apreciar a lo largo de todo
el proceso de desarrollo, la arquitectura escogida result ser la
archiconocida MVC utilizando un patrn singleton para manipular datos
de la capa de persistencia.
o As mismo, se dispone del cdigo fuente as como de los MR/PR
aprobados en el primer punto del ciclo de vida establecido por esta
norma.
Una vez tenido lo expuesto anteriormente, se har uso de la norma ISO 12207,
tomando los procesos definidos y especificados en la misma de los cuales hace
uso ProActSoft S.L en todos sus desarrollos de software. En el site de la empresa
se puede apreciar qu procesos implementamos as como cuando los llevamos a
cabo, por lo que al tratarse el mantenimiento realizado como si de otro
proyecto (a menor escala y ms sencillo) se tratase, son igualmente aplicables.
Aceptacin / Revisin del mantenimiento.
Se han llevado a cabo nuevos test-case sobre el software modificado para
corroborar que la funcionalidad es la esperada. As mismo, se han vuelto a ejecutar los
mismos casos de prueba efectuados en la primera versin entregada en esta nueva
revisin de la aplicacin.
Una vez realizados y superados los casos de prueba, se ha procedido al envo de
la aplicacin a la empresa SanaCare para dar el visto bueno a los cambios introducidos
obteniendo una respuesta afirmativa.
Migracin.
La aplicacin desde sus inicios siempre ha estado pensada para ser ejecutada en
un entorno Android, por lo que en un futuro cercano no se migrar a ninguna otra
plataforma; sin embargo, por las conversaciones mantenidas a lo largo de estos meses
con SanaCare, s cabe la posibilidad de migrar a sistemas iOS (Apple) cuando la
aplicacin est ampliamente extendida y asentada entre los usuarios.
Retirada del software.
Debido a la juventud de la aplicacin y que todava no ha alcanzado ni el primer
ao de vida, no se ha diseado ni tan siquiera pensado en una hipottica retirada del
software; del mismo modo, se ha realizado un breve anlisis que justifica la presencia
de la aplicacin en el mercado actual:
ProActSoft S.L

Pgina 7

La tecnologa sobre la que se asienta est en auge.

Ha sido desarrollada siguiendo un esquema modular, es decir, separando la
funcionalidad en mdulos independientes.
Gracias a la modularidad as como a la documentacin obtenida de cada una de
las fases de desarrollo, el mantenimiento puede ser llevado a cabo con
facilidad.
El software ha sido realizado mediante la gua de distintos estndares
internacionales en sus ltimas revisiones: ISO 12207, ISO 25010, etc.

Decisiones acerca de los tipos de mantenimiento

Como se puede observar a lo largo del presente documento, los tipos de

mantenimiento llevados a cabo en AncientDroid son el correctivo y el perfectivo.
Respecto al porqu no hay presencia de los otros dos tipos se resume en las siguientes
lneas:
-

Mantenimiento Adaptativo:
o En lo que a nivel software respecta:
Como se ha especificado en migracin, la aplicacin no va a ser
portada en futuro cercano a ninguna otra plataforma.
El entorno de datos empleado est actualizado a los tiempos que
corren, utilizando SGBD propios de la infraestructura.
o En lo que a nivel hardware respecta:
La aplicacin ha sido desarrollada bajo la ltima versin estable
del sistema operativo, garantizando tambin su uso en
dispositivos con una versin ms antigua del mismo.
En lo que respecta a arquitecturas distintas entre distintos tipos
de mviles (diferentes procesadores, memorias, etc), Android nos
abstrae de ellas, y el nico requisito necesario es la instalacin de
la ltima versin disponible a fecha de Diciembre-2013, o en su
defecto, en alguna de las anteriores.
Por todo esto, la aplicacin va a seguir mantenindose usable en la actualidad
ya que no est previsto un cambio inmediato de versin del sistema operativo.

Mantenimiento preventivo:
o El software ha sido desarrollado utilizando distintos patrones de diseo:
Singleton para la manipulacin de los datos de la capa de
persistencia.
Modelo-Vista-Controlador para independizar cada una de las
capas que conforman la arquitectura de la aplicacin.

ProActSoft S.L

Pgina 8

o Al realizar un desarrollo iterativo e incremental, la funcionalidad ha ido

implementndose de manera modular, facilitando la legibilidad del
cdigo as como eventuales modificaciones sobre el mismo, ya que no
ser necesario modificar ms all de la funcionalidad implcita de la
funcin en cuestin.

ProActSoft S.L

Pgina 9