Cuantificación de la deuda técnica en...
129
0 INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN CUANTIFICACIÓN DE LA DEUDA TÉCNICA EN APLICACIONES BANCARIAS, MEDIANTE EL MÉTODO SQALE T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA P R E S E N T A: EMMANUEL FLORES RAMOS DIRECTOR DE TESIS: DR. ERIC MANUEL ROSALES PEÑA ALFARO
Transcript of Cuantificación de la deuda técnica en...
0
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE
INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
CUANTIFICACIÓN DE LA DEUDA TÉCNICA EN
APLICACIONES BANCARIAS, MEDIANTE EL MÉTODO SQALE
T E S I S
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN
INFORMÁTICA
P R E S E N T A:
EMMANUEL FLORES RAMOS
DIRECTOR DE TESIS:
DR. ERIC MANUEL ROSALES PEÑA ALFARO
1
2
3
4
A mi familia, que con su fulgida presencia apremia mi superación, los amo.
A mi bien idolatrado Instituto Politécnico
Nacional, por darme el pundonor de ser parte de él.
5
Resumen El presente trabajo inicia estudiando los distintos enfoques de la calidad de software, centrando el
estudio en la cuantificación de la calidad interna, mejor conocida como deuda técnica.
Describiendo en detalle el método SQALE y su relación con la deuda técnica. Mostrando los
resultados de la adaptación del método SQALE para la cuantificación de la deuda técnica
realizados a una aplicación web de una institución bancaria. Finaliza, proponiendo una serie de
medidas para el manejo de la deuda técnica que se ajusten con la agenda, metodología y planes
de la institución.
Abstract This work begins studying different approaches to software quality; it focuses on the study of quantifying the internal quality, better known as technical debt. Describes the SQALE method and its relation to the technical debt for measure and quantify it. Showing the results of the SQALE adaptation method for the quantification of technical debt performed to a Web application from a bank institution. It ends by proposing a series of measures for managing technical debt that better fits with the agenda, methodology and schedules that the institution owned.
6
Tabla de contenido Resumen ............................................................................................................................................5
Abstract ..............................................................................................................................................5
Introducción .......................................................................................................................................8
Capítulo 1 El ciclo de vida del software ..............................................................................................9
1.1 Procesos de Desarrollo de Software .............................................................................................9
1.2.1 Ciclo de Vida del Desarrollo de Software. ..............................................................................9
1.2.2 Metodologías de Desarrollo de Software ............................................................................14
1.3 Calidad del Software ..................................................................................................................19
1.3.1 Valor y Costo de la Calidad. .................................................................................................20
1.3.2 Múltiples Aspectos de la Calidad. ........................................................................................22
Capítulo 2 Modelos de Calidad de Software ....................................................................................24
2.1.1 Calidad en los Procesos de Software. ..................................................................................24
2.1.2 Team Software Process (TSP) ..............................................................................................26
2.1.3 CMMI ...................................................................................................................................30
2.1.4 ISO 9001 ..............................................................................................................................34
2.1.5 ISO 15504 (SPICE, Software Process Improvement and Capability determination) .............37
2.1.6 MOPROSOFT Norma Oficial Mexicana NMX-059/02-NYCE-2005 .......................................39
2.1.7 Modelos de evaluación de la calidad del software. .............................................................44
2.1.8 Norma Internacional ISO/IEC 9126 ...............................................................................44
2.1.9 Modelo SQALE (Software Quality Assessment based on Lifecycle Expectations).................54
Capítulo 3 Deuda Técnica .................................................................................................................60
3.1. Orígenes del Término. ...............................................................................................................60
3.1.1 Causas de la Deuda Técnica. ................................................................................................62
Métodos de Mitigación de la Deuda Técnica ...........................................................................64
3.1.2 Identificación, Cuantificación y Manejo de la deuda técnica. ..............................................67
3.1.2.1 Identificación de la deuda técnica. ...............................................................................67
3.1.2.2 Cuantificación de la deuda técnica ...............................................................................71
3.2 Calculo de costos de la mala calidad. ...........................................................................76
Capítulo 4 Herramientas para la medición de la deuda técnica .......................................................77
7
4.1.4 Herramienta SonarQube .....................................................................................................77
4.1.5 Herramienta SQuORE ..........................................................................................................80
4.1.6 Herramienta Mia-Quality ....................................................................................................83
4.2 Conclusiones sobre las herramientas. ........................................................................................86
Capítulo 5 El método SQALE adaptado y las herramientas de experimentación..............................87
5.1.1 Sistema bancario a evaluar. ..........................................................................................87
5.2 Adaptación de la Lista de Características SQALE ..........................................................87
5.2.1 Características SQALE a Evaluar ....................................................................................87
5.2.1.1 Cálculo de costos ..........................................................................................................89
5.2.1.2 Testability (Comprobabilidad) .....................................................................................91
5.2.1.3 Mantenibilidad (Maintainability ) .................................................................................91
5.2.1.4 Reliability (Confiabilidad) .............................................................................................93
5.3 Herramientas para Validar las Características ..................................................................98
5.4.1 Herramienta para determinar la comprobabilidad del código. ....................................98
5.4.2 Herramienta para determinar la mantenibilidad y la confiabilidad ..............................99
5.5 Herramienta para medir el tamaño del software (Locmetrics) ........................................99
Capítulo 6 Ejecución de Experimentos .................................................................................101
6.1 Breve introducción .....................................................................................................101
6.2 Desarrollo de Experimentos .......................................................................................101
6.3 Resultados ......................................................................................................................108
6.4 Interpretación de resultados. .........................................................................................111
Conclusiones ..................................................................................................................................112
Glosario ..........................................................................................................................................114
Referencias.....................................................................................................................................115
Anexos ............................................................................................................................................117
8
Introducción
En la actualidad las organizaciones demandan aplicaciones empresariales de fácil mantenimiento.
Que atiendan a los constantes cambios del entorno y que puedan adaptarse a este con la misma
rapidez, además el software empresarial cada vez se vuelve más indispensable a la operación
diaria de las mismas y con ello generando un creciente volumen de operaciones por minuto; la
falta de estas capacidades en el software ocasionaría cuantiosas pérdidas económicas.
Por ello para poder cumplir con estas exigencias, es necesario contar con software de calidad, que
cumpla con las mejores prácticas de desarrollo y estándares de codificación.
El software debido a lo ajustado de los tiempos de entrega o a recursos humanos inexpertos
contiene mala calidad y esta queda oculta para los usuarios finales; esta mala calidad invisible y
difícil de entender en términos de negocio se conoce como deuda técnica, cabe mencionar que el
término deuda técnica tiene menos de cinco años como tema de estudio en artículos científicos.
El objetivo de esta tesis es cuantificar la mala calidad del software que afecta en los procesos
cotidianos de una entidad bancaria y que de manera directa no es posible percibir o visualizar
(deuda técnica), para ello se ocuparán las metodologías que permitan su cuantificación y que se
basen en las expectativas de calidad durante el ciclo de vida del software. La justificación es que el
personal de una institución bancaria al momento de pretender entender los costos de la mala
calidad asociados a las malas prácticas y errores en el desarrollo del software minimizan o nulifican
el esfuerzo requerido para poder solucionar estos problemas y no ven la ventaja de que en un
futuro se redujera el tiempo y costo de los mantenimientos futuros en las aplicaciones bancarias.
La problemática existente es que la mala calidad del código es difícil de cuantificar y expresar en
términos de impacto al negocio, ya sea en forma de un error fatal en el sistema que detenga
parcial o totalmente la operación, el gasto en hardware por la mala optimización en los algoritmos
o cálculos , la tardía entrega de desarrollos que permiten posicionar mejor a la institución bancaria
o tomar ventaja estratégica con el desarrollo de un módulo de software derivado de código
fuente ilegible y que nos e apegue a los estándares y mejores prácticas de desarrollo.
En el presente trabajo se pretende adaptar un modelo para la medición y cuantificación de la
deuda técnica en las aplicaciones de una institución bancaria.
9
Capítulo 1 El ciclo de vida del software En este capítulo se abordará el ciclo de vida del software así como la definición de procesos para
aseguramiento de su calidad. Se presentará el estándar internacional para definir el ciclo de vida
de los sistemas, el estándar ISO/IEC 12207.Se mencionan los distintos tipos de metodologías de
desarrollo de software, realizando una comparativa entre los métodos tradicionales y ágiles. Se
abordarán los distintos enfoques de la calidad en el software.
1.1 Procesos de Desarrollo de Software
1.2.1 Ciclo de Vida del Desarrollo de Software.
Definición
El ciclo de vida de desarrollo de sistemas (CVDS), es un término usado en ingeniería de sistemas e
ingeniería de software que describe el proceso de planeación, creación, pruebas, desarrollo,
despliegue y mantenimiento de un sistema de información o programa informático.
El ciclo de vida del software está compuesto de diferentes fases de trabajo que son atendidas por
los ingenieros de software e ingenieros de sistemas para planear, diseñar, construir, probar y
mantener los sistemas de información. El ciclo de vida del desarrollo de software así como
cualquier otro producto, buscan generar sistemas que cumplan o excedan las expectativas de los
clientes a través de sus fases.
Etapas del ciclo de desarrollo de software.
El término ciclo de vida del software describe la evolución del software, desde la fase concepción
del software hasta su mantenimiento. Intermedio a estas faces de inicio y fin existen distintas
fases que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el
software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo
y verificación de que los métodos utilizados sean los apropiados.
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se
detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se
detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad
del software, en los plazos de implementación y en los costos asociados.1
El ciclo de vida básico de un software consta de los siguientes pasos:
1. Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
2. Análisis de requerimientos y su factibilidad: recopilar, examinar y formular los requisitos
del cliente.
1 Sommerville Ian (2011). Software Engineering 9/E. Escocia: Pearson
10
3. Diseño general: requisitos generales de la arquitectura de la aplicación.
4. Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
5. Programación: es la implementación de un lenguaje de programación para crear las
funciones definidas durante la etapa de diseño.
6. Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar
que se implementaron de acuerdo con las especificaciones.
7. Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste
es el propósito de la prueba de integración que está cuidadosamente documentada.
8. Prueba beta (o validación), para garantizar que el software cumple con las especificaciones
originales.
9. Documentación: sirve para documentar información necesaria para los usuarios del
software y para desarrollos futuros.
10. Instalación, Despliegue o puesta en marcha.
11. Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y
las actualizaciones secundarias del software (mantenimiento continuo).
Este ciclo de vida básico del desarrollo de software pudieren omitir algunas etapas, o incluso
cambiar de orden para cumplir con las necesidades del equipo de desarrollo o cumplir con los
estándares propios de cada compañía. 2
La siguiente figura Ciclo de Vida del Desarrollo de Software 1 nos muestra la interacción de los
pasos del ciclo de vida del software.
2Sánchez Salvador, Sicilia Miguel Ángel y Rodríguez Daniel (2012). Ingeniería del Software Un
enfoque desde la guía SWEBOK. España: Alfaomega.
11
1Figura 1 Ciclo de Vida del Desarrollo del Software (Elaboración Propia)
Estándar ISO/IEC 12207 para los procesos del ciclo de vida de software.
El ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software de la organización ISO.
Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.3
El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:
3 Pino, F.J.; Garcia, F.; Ruiz, F.; Piattini, M., "Adaptation of the standards ISO/IEC 12207:2002 and
ISO/IEC 15504:2003 for the assessment of the software processes in developing countries," Latin
America Transactions, IEEE (Revista IEEE America Latina) , vol.4, no.2, pp.85,92, April 2006
Requerimientos •Validación
Diseño •Pruebas
Codificación •Pruebas Unitarias
Integración •Pruebas Integrales
Implementación •Verificación
Mantenimiento •Validación
12
A. Procesos principales del ciclo de vida.
Son los procesos para iniciar o llevar a cabo el desarrollo, operación o mantenimiento del
software.
1. Proceso de Adquisición.
2. Procesos de Suministro.
3. Procesos de Desarrollo.
4. Procesos de Operación.
5. Procesos Mantenimiento.
B. Procesos de apoyo del ciclo de vida.
Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo. Un proceso
de apoyo se emplea y ejecuta por otro proceso, según sus necesidades.
1. Documentación
2. Gestión de la configuración.
3. Aseguramiento de calidad.
4. Verificación.
5. Validación.
6. Revisión conjunta.
7. Auditoría.
8. Resolución de problemas.
C. Procesos organizativos del ciclo de vida.
Se emplean por una organización para establecer e implementar una infraestructura constituida
por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta
infraestructura. Se usan habitualmente fuera del ámbito de proyectos y contratos, contribuye a la
mejora de la organización.
1. Gestión.
2. Infraestructura.
3. Mejora.
4. Recursos Humanos.
13
2 Figura Procesos, Actividades y Tareas Ciclo Vida
•Se Organizan Procesos
(17)
•Se Implementan
Actividades (74)
•Interactuan
•Politicas
•Planes
•Registros
•Documentos
•Auditorias
Tareas (224)
14
Figura3. Diagrama Estructural ISO12207 1
1.2.2 Metodologías de Desarrollo de Software
Definición.
Una metodología de desarrollo de software se refiere a un marco de trabajo que es usado para estructurar, planear y controlar el proceso de desarrollo de un sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.
Una metodología de desarrollo de software consiste en:
Una filosofía de desarrollo de programas de computación con el enfoque de procesos. Herramientas, modelos y métodos para asistir al proceso de desarrollo de software.
Estos marcos de trabajo son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología.
Metodología tradicional.
Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas. Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un
15
software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos o requerimientos no pueden predecirse o bien pueden variar. Entre las metodologías tradicionales o pesadas podemos citar.
RUP (Rational Unified Procces). MSF (Microsoft Solution Framework). Win-Win Spiral Model. Iconix.
En el caso particular de RUP, presenta un especial énfasis en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
Metodologías ágiles.
En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término "ágil" aplicado al
desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologías de desarrollo de
software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos
desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en
cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya
estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y
reconocimiento.
Estos son los principios de las metodologías ágiles.
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software
que le aporte un valor. Un proceso es ágil si a las pocas semanas de empezar ya entrega
software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho
software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa
de posibles cambios a realizar.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del
equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va
a permitir aprender más, a la vez que logran una mayor satisfacción del cliente. Este
principio implica además que la estructura del software debe ser flexible para poder
16
incorporar los cambios sin demasiado coste añadido. El paradigma orientado a objetos
puede ayudar a conseguir esta flexibilidad.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas. Las entregas al cliente se
insiste en que sean software, no planificaciones, ni documentación de análisis o de diseño.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El
proceso de desarrollo necesita ser guiado por el cliente, por lo que la interacción con el
equipo es muy frecuente.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal
factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano.
Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste
es el principal modo de comunicación. Se pueden crear documentos pero no todo estará
en ellos, no es lo que el equipo espera.
VII. El software que funciona es la medida principal de progreso. El estado de un proyecto no
viene dado por la documentación generada o la fase en la que se encuentre, sino por el
código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el
50% de los requisitos ya están en funcionamiento.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores
y usuarios deberían ser capaces de mantener una ritmo constante. No se trata de
desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la
duración del proyecto, asegurando en todo momento que la calidad de lo producido sea la
máxima.
Entre las metodologías ágiles más destacadas hasta el momento se pueden nombrar:
XP (Extreme Programming)
Scrum
Crystal Clear
DSDM (Dynamic Systems Developmemt Method)
FDD (Feature Driven Development)
ASD (Adaptive Software Development)
17
XBreed
Extreme Modeling
XP es uno de los métodos más representativos dentro de las metodologías llamadas ligeras que
lleva al extremo las prácticas para la consecución de sistemas funcionales y que cumplan las
características del usuario cliente, surge como respuesta a la sobre planificación a la hora de
generar software. Está basada en la simplicidad, la comunicación, la retroalimentación y la
refactorización de código.
Comparativa de Metodologías Tradicionales vs Ágil
A continuación un par de tablas comparativas entre metodologías ágiles y tradicionales resaltando
sus características en el proceso de desarrollo de software sus debilidades y fortalezas.
Métodos Ágiles Métodos Tradicionales
Enfoque Adaptación Predictivo
Asignación de Prioridades Generen Valor de Negocio Conforme a lo Planificado
Tamaño Proyecto Pequeño Grande
Estilo de Gestión Descentralizada Autocrático
Perspectiva de Cambio Adaptabilidad al Cambio Emplazamiento del Cambio
Documentación Bajo Pesado
Énfasis Orientado a las Personas Orientación a los Procesos
Ciclos Muchos Limitado
Dominio Impredecible exploratorio Previsible
Planificación Mínima Exhaustiva
Retorno de la Inversión Desde del Inicio de Proyecto Hasta el Fin del Proyecto
Tamaño de Equipos Pequeño Grande
Tabla1. Comparativa de características entre tipos de metodologías.
18
Tabla2. Comparativa de cualidades entre tipos de metodologías de desarrollo.
Metodologías Agiles Metodologías Tradicionales
Basada en mejores prácticas de producción de
código.
Basada en estándares de desarrollo.
Especialmente preparada para cambios en el
proyecto.
Cierta resistencia al cambio.
Reglas definidas por el equipo de trabajo. Reglas definidas por el administrador del
proyecto.
Proceso poco controlado con unos pocos
principios.
Proceso mucho más controlado con
numerosas políticas y normas.
No existe un contrato tradicional o al menos es
más flexible.
Existe un contrato previamente establecido.
El cliente es parte del equipo de desarrollo. El cliente interactúa con el equipo de trabajo
mediante reuniones.
Grupos pequeños menor a diez integrantes y
trabajando en el mismo sitio.
Grupos grandes y posiblemente distribuidos.
Pocos Artefactos Muchos Artefactos
Pocos Roles Muchos Roles
Menor énfasis en las arquitecturas de software La arquitectura de software es esencial y se
plasma en modelos.
19
1.3 Calidad del Software Según la guía SWEBOK se define la calidad como “la capacidad de un producto de software para
satisfacer la necesidades expresas e implícitas bajo condiciones específicas”4 y también como, “el
grado en que un producto de software cumple con los requisitos establecidos; Sin embargo, la
calidad depende del grado en que los requisitos establecidos representan con exactitud las
necesidades de las partes interesadas, deseos y expectativas”5
En la guía SWEBOK6 se indica que todos los ingenieros de software deben conocer el significado y
características de la calidad, así como su valor en el desarrollo y mantenimiento del software.
En el desarrollo de un sistema de software, la calidad inicia con los requerimientos de software,
momento donde se establecen los parámetros y criterios de calidad del software que se
construirá. Las características de calidad que se definan en ese momento serán la referencia de
calidad de ahí en adelante, por lo que todo aquello que se establezca como requisito de calidad
será un parámetro requerido para medir la calidad y evaluado como un criterio que debe cumplir
el producto final. Ver siguiente figura:
4 ISO/IEC, 25010:2011 Systems and SoftwareEngineering—Systems and Software Quality Requirements and Evaluation(SQuaRE)—Systems and Software Quality Models, ISO/IEC, 2011. 5 IEEE, P730™/D8 Draft Standard for Software Quality Assurance Processes, IEEE, 2012. 6 Software Engineering Body of Knowledge
20
1.3.1 Valor y Costo de la Calidad. La premisa que subyacente para definir el costo de calidad en un producto de software se puede
calcular de acuerdo a los costos de las actividades relacionadas con el manejo de las consecuencias
de la mala calidad.
La mala calidad significa que el producto software no "satisfacer necesidades expresadas o
implícitas"
Son cuatro los costos de las categorías de calidad de los requisitos establecidos. Preventivos,
estimación, error interno, o error externo (visible o no al usuario).
Calidad
Cultura de la
Calidad
Aseguramiento de la
Calidad
Modelos de
Calidad
Valor y costo de la
Calidad
Figura 4.Modelo de Calidad SWEBOK - IEEE 1 (Elaboración propia)
21
El hecho de buscar obtener un producto de software de calidad es ya una cualidad de nuestro
producto, pero hemos de saber bien que los beneficios de la calidad generan costos asociados con
la obtención de la misma.
Los componentes del costo de la calidad son los siguientes.
Costo de los Fallos Externos.
Se derivan de la rectificación de los fallos encontrados en el software después de la entrega final
con el cliente. Entre los más habituales podemos encontrar los relacionados con el análisis del
Costos de la
Calidad
Costo de los Fallos
Externos
Costo de los Fallos
Internos
Costo de
Evaluación de la
Calidad
Costo de
Prevención
Figura 5. Costos de la Calidad 1 (Elaboración propia)
22
software que derivan del cambio de requerimientos por parte del cliente, el costo de reemplazo
del producto. Así como el costo asociado a reparaciones y servicio de mantenimiento durante el
periodo de garantía.
Costo de los Fallos Internos.
Podemos definir a los defectos internos como aquellos que se hacen presentes en el software
durante su previa entrega al usuario final. A pesar de que a primera vista estos fallos son
imperceptibles para el usuario, su ponderación en cuanto a importancia no es menor, ya que de
no eliminarse la consecuencia podrían ser fallos externos. Entre los factores de costo podemos
mencionar la corrección de errores en el producto final, o el costo de la inspección de un producto
corregido para verificar que se encuentre libre de errores.
Costo de Evaluación de la Calidad.
Para poder estimar el costo de ob tener una buena calidad en un producto es necesario evaluarla y
estimarla para conocer si los requerimientos primordiales del software y la agenda nos permiten
llevarlos a cabo ya que toda tarea extra a los requerimientos explícitos dentro de un proyecto de
software en deben someterse a este proceso de evolución y ponderación. Es necesario tener
presente el no sobrevalorar u omitir alguna actividad necesaria para lograr la calidad, como por
ejemplo para poder reparar algún error es necesario documentarlo, replicarlo, corregirlo, probarlo
de manera tanto unitaria como integral y su posterior liberación.
Costo de prevención.
Podemos definir al costo de los fallos externos como el derivado de permitir que el proceso de
desarrollo de software se atenga a los parámetros previamente establecidos de calidad, así como a
la prevención de los mismos. El costo de los fallos externos se encuentra directamente relacionado
con la planificación de las actividades de calidad, la integración y el progreso de nuevos
integrantes del equipo de desarrolladores, o la generación de reportes de calidad del producto
final, entre otros aspectos.
1.3.2 Múltiples Aspectos de la Calidad. La calidad es un aspecto muy complejo y con múltiples facetas las cuales son:
La versión transcendental de la calidad, también denominada calidad relativa. Hace
referencia al hecho de que la calidad es fácil de percibir y reconocer, pero difícil de definir.
Según esta perspectiva, todos tenemos un concepto similar de lo que es la calidad de
software, algo así como un ideal que habría que alcanzar. No obstante que es difícil que el
software, una vez construido, tenga la perfección de un software ideal que sirviese al
mismo fin.
23
La perspectiva del usuario, según la cual la calidad se entiende como el grado de
conformidad con aquello que el cliente espera recibir y que fue establecido en las
especificaciones del software. A diferencia de la perspectiva anterior, esta perspectiva
permite medir la calidad en términos concretos: cuanto mayor sea el grado entre la
cercanía de las necesidades del usuario y las características del software mayor será la
calidad. Es importante notar que en este enfoque la visión de calidad varía en función del
contexto, ya que le mismo producto, dirigido a un diferente mercado o tipo de usuario,
tendrá diferentes percepciones de calidad global.
La perspectiva de la producción identifica la calidad del producto con la calidad de los
procesos de producción y postventa. Desde esta perspectiva, todo producto fabricado de
acuerdo a estándares regulados de calidad podrá ser considera un producto de calidad,
aquí podremos enumerar los proceso CMMI, SPICE e ISO 9001.
La perspectiva del producto relaciona la calidad con ciertas características de este, tales
como la facilidad de mantenimiento, la funcionalidad o confiabilidad, A diferencia de las
anteriores, que observan la calidad del software tal y como es percibida exteriormente,
esta perspectiva apunta a la calidad interna del software, por ejemplo el estándar ISO/IEC
9126.
La perspectiva del valor establece una relación entre la cantidad de dinero que el cliente
está dispuesto a pagar y la calidad del producto. Se trata de una forma pragmática de
entender la calidad, pues llegado un punto donde existe un conflicto entre lo que le
cliente está dispuesto a pagar y el costo de lo que necesita se pudiera bajar la calidad para
adecuarse al presupuesto del cliente.
Con base en lo anteriormente podemos concluir. Que la calidad es la capacidad del software para
cumplir con los requerimientos expresos e implícitos que satisfagan las demandas de los usuarios,
y que para ello existen diferentes enfoques para su logro. Uno es mediante la adopción de una
metodología, otro mediante la medición de la satisfacción del usuario final y uno último que es él
se abordara es tomar métricas acerca de la calidad interna del software.
24
Capítulo 2 Modelos de Calidad de Software Una vez conociendo los distintos enfoques de calidad y las metodologías de desarrollo de
software. Es necesario estudiar y comparar los métodos para lograr la calidad mediante la
adopción de una metodología en los procesos de software, así como analizar las normas y
procedimientos para la evaluación del producto de software.
2.1.1 Calidad en los Procesos de Software. Un enfoque de calidad consiste en que, si se desarrolla un producto mediante el seguimiento
estricto de los pasos de una metodología o proceso de software, el producto final alcanzara la
calidad esperada.
Para ello se han estudian los estándares de calidad y los procesos de software en el ámbito
nacional e internacional.
Personal Software Process (PSP).
El proceso personal de software ss un conjunto de prácticas disciplinadas para la gestión del
tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en
tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en
organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey
en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An
introduction to the Personal Software Process" se dirige ahora a ingenieros novatos.
Se puede considerar como la guía de trabajo personal para ingenieros de software en
organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos
que implica la medición cualitativa y mejora de procesos.7
Uno de los mayores problemas que tienen es la gran cantidad de datos que hay que tomar.
El PSP tiene obsesión por la toma de datos y elaboración de tablas.
El PSP se orienta el conjunto de áreas que un desarrollador lleva de manera individual al momento
de la construcción del software, estructurándose en niveles y etapas como se describe a
continuación.
o Nivel 1 - Inicial:
Seguimiento y control de proyectos.
Planeación de los proyectos.
o Nivel 2 - Repetible:
Revisión entre colegas.
7Humprey, Watts S. (1996) Introduction to the Personal Software Process
25
Ingeniería del producto de software.
Manejo integrado del software.
Definición del proceso de software.
Foco del proceso de software.
o Nivel 3 - Definido:
Control de calidad.
Administración cuantitativa del proyecto.
o Nivel 4 - Controlado/Administrado:
Administración de los cambios del proceso.
Administración del cambio tecnológico.
Prevención de defectos.
o Nivel 5 - Optimizado.
Mejora del proceso de software.
26
Figura 6. Diagrama Procesos PSP8
2.1.2 Team Software Process (TSP) El Team Software Process (TSP) se basa en el desarrollo de los equipos que desarrollan el
software. El TSP busca integrar un equipo que tenga como punto de partida la unificación del
mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los
procesos que desarrollan.
TSP es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar
equipos para el desarrollo de software de calidad. TSP proporciona directrices para ayudar a un
equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que
la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos
eficientes, fiables y de calidad.
TSP es una solución basada en procesos para resolver problemas de negocio, tales como:
predictibilidad de costo y tiempo, mejora de productividad y ciclos de desarrollo y mejora de
calidad de productos.
Por tal motivo, Watts Humphrey el creador de PSP desarrolló así mismo el TSP, el cual considera
como parte importante, además de lo previsto por el PSP. El adicionar las pruebas de integración,
la documentación y otras actividades típicas de todo proyecto de desarrollo, de igual manera
incluyó en el TSP las actividades de cada uno de los miembros del equipo y sus roles dentro de la
8 Humprey, Watts S (1996). Introduction to the Personal Software Process. USA: Addison-Wesley
27
organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos
existentes en la organización.
Los Roles (responsabilidades) en los equipos en TSP son:
Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos
y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del
equipo.
Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.
Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del
trabajo.
Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso
y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo
uniforme. Modera las inspecciones y revisa cada artefacto generado.
Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de
requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de
apoyo administrativo. Administra el plan de configuración del software.
Es necesario que los ingenieros que usan TSP estén formados en PSP.
TSP está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en
equipo:
Formación del equipo de trabajo.
Gestión del equipo de trabajo.
Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de
desarrollo, esto reduce de manera importante el tiempo de pruebas. Si se tiene una ejecución de
pruebas más corta, el ciclo completo se reduce.
A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es
disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de
procesos organizacionales.
En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:
1. Lanzamiento
2. Estrategia
3. Plan
28
4. Requisitos
5. Diseño
6. Implementación
7. Pruebas
8. Postmortem
A continuación la siguiente figura nos muestra los componentes de Team Software Process.
Componentes de la Metodología TSP 9
9 Humprey, Watts S (2000). Introduction to the Team Software Process. USA: Addison-Wesley
29
TSP
PSP
Disciplina
Medición de Calidad y
Desempeño
Evaluación de Equipo y
Roles
Guía para solución rápida de
problemas.
Medidas Precisas
Desarrollo Cíclico
Figura 7. Componentes de Team Software Process (Elaboración propia)
30
2.1.3 CMMI El modelo CMMI constituye un marco de referencia de la capacidad de las organizaciones de
desarrollo de software en el desempeño de sus diferentes procesos, proporcionando una base
para la evaluación de la madurez de las mismas y una guía para implementar una estrategia para
la mejora continua de los mismos. Ver figura 8
Evolución del estándar
La primera aproximación a la mejora de procesos aparece en el trabajo de Walter Shewhart, con
sus principios de control estadístico de la calidad. Estos principios fueron refinados por W. E.
Deming y J. Juran. W. Humphrey, R. Radice y otros, desarrollaron aún más estos principios y
empezaron a aplicarlos al software en su trabajo en IBM y el SEI. Humphrey proporciona una
descripción de los principios y conceptos básicos en que se basan la mayoría de los modelos de
madurez, Mark Paulk y otros en el SEI crearon el primer modelo de madurez de capacidad,
diseñado para organizaciones de desarrollo software
CMM dirige su enfoque a la mejora de procesos en una organización, estudia los procesos de
desarrollo y produce una evaluación de la madurez (indicador para medir la capacidad para
construir un software de calidad) de la organización según una escala de cinco niveles (inicial,
repetible, definido, dirigido y optimizado). Los modelos contienen los elementos esenciales de
procesos efectivos para una o más disciplinas y describen el camino para evolucionar y mejorar
desde procesos inmaduros a procesos disciplinados, maduros con calidad y eficiencia mejorada y
probada.
Propiciado por su rápido éxito y por demanda de modelos en otros ámbitos, se publica un
conjunto de modelos para otras disciplinas y funciones: People CMM (1995), Systems Engineering
CMM (1995), Integrated Product Development (1996), Software Acquisition CMM, FAA-CMM,
Trillium. Mientras algunas organizaciones encontraban estos modelos útiles, también encontraban
que se solapaban sobremanera, que a veces eran contradictorios, escasamente limpios con
interfaces ininteligibles, escasa estandarización y mezclando diferentes niveles de detalle.
El proyecto de integración de CMM o CMMI fue puesto en marcha para desarrollar un marco de
trabajo simple para la mejora de procesos, para organizaciones que persiguen la mejora en todos
los ámbitos y niveles de la empresa.
Estructura del estándar.
Basándose en SE-CMM y EIA 731 (que recogían la representación continua de los borradores del
modelo SPICE), CMMI presenta dos representaciones del modelo: continua (capacidad de cada
área de proceso) y/o por etapas (madurez organizacional).
En la representación por etapas, se da un mapa predefinido, dividido en etapas (los niveles de
madurez), para la mejora organizacional basada en procesos probados, agrupados y ordenados y
sus relaciones asociadas. Cada nivel de madurez tiene un conjunto de áreas de proceso que
indican donde una organización debería enfocar la mejora de su proceso. Cada área de proceso se
31
describe en términos de prácticas que contribuyen a satisfacer sus objetivos. Las prácticas
describen las actividades que más contribuyen a la implementación eficiente de un área de
proceso; se aumenta el ‘nivel de madurez’ cuando se satisfacen los objetivos de todas las áreas de
proceso de un determinado nivel de madurez.
En la representación continua, enfocamos la capacidad de cada área de proceso para establecer
una línea a partir de la que medir la mejora individual, en cada área. Al igual que el modelo por
etapas, el modelo continuo tiene áreas de proceso que contienen prácticas, pero éstas se
organizan de manera que soportan el crecimiento y la mejora de un área de proceso individual.
Ambas representaciones incluyen Metas (genéricas y específicas, definiciones de resultados a
obtener por la implementación efectiva de los grupos de prácticas) y Prácticas (Genéricas y
Específicas, acciones a realizar para cumplir objetivos de área de proceso). El modelo de programa
de mejora continua de procesos que propone SEI se llama IDEAL (Initiating, Diagnosing,
Establishing, Action, Learning).
Puntos fuertes y débiles
No cabe duda de que CMM, tanto por su difusión y resultados reportados, ha sido un modelo
exitoso. Por ello, a priori, dadas las similitudes, debemos esperar que CMMI ofrezca también
brillantes resultados en incremento de la productividad, más rápida respuesta al mercado,
reducción de defectos, disminución de costes, planificaciones fiables.
Son numerosos los casos de estudio que prueban la mejora sustancial que supone la participación
en una iniciativa de mejora de procesos basado en modelos de madurez y realizando interesantes
comparativas entre metodologías.
Sin embargo, por lo reciente de los nuevos estándares que estamos revisando, han quedado
anticuados y aún hay pocos resultados cuantitativos publicados sobre CMMI.
SEI publicó un informe especial y su actualización que, si bien no es estadísticamente significativa,
presenta evidencia cuantitativa creíble de las mejoras en rendimiento y calidad obtenidas en 12
casos de estudio, tanto en coste (ahorros y disminución en coste de encontrar y reparar errores),
planificación (disminución del tiempo necesario para terminar tareas y aumento de la
confiabilidad de las predicciones sobe estimaciones), calidad (reducción de tasa de defectos), y
satisfacción del cliente como retorno de la inversión.
Entre sus fortalezas podríamos destacar:
Inclusión de las prácticas de institucionalización, que permiten asegurar que los procesos
asociados con cada área de proceso serán efectivos, repetibles y duraderos.
Guía paso a paso para la mejora, a través de niveles de madurez y capacidad (frente a ISO).
32
Transición del ‘aprendizaje individual’ al ‘aprendizaje de la organización’ por mejora
continua, lecciones aprendidas y uso de bibliotecas y bases de datos de proyectos
mejorados.
Algunas de sus debilidades son:
o El CMMI puede llegar a ser excesivamente detallado para algunas organizaciones.
o Puede ser considerado prescriptivo.
o Requiere mayor inversión para ser completamente implementado.
o Puede ser difícil de entender.
o No existencia de una guía a medida de pequeñas organizaciones. Reconocen que
inicialmente se dirigía a grandes corporaciones, pero la representación continua permite
seleccionar sólo aquellas áreas de proceso de interés (asumible por pequeñas empresas).
o Simplemente demasiado grande para pequeñas organizaciones. Crecimiento cuasi-
exponencial del número de áreas y prácticas, tiempo, recursos y costes, pero si se alinean
los procesos a las necesidades de la organización, se beneficiarán de un proceso
estructurado.
o ROI (Retorno de la inversión) no ha sido validado aún en CMMI.
o CMMI resalta la ingeniería de sistemas frente a la ingeniería del software.
o CMMI es demasiado normativo, en especial con pequeñas organizaciones que, además,
funcionan y evolucionan de distinta manera que las grandes.
o CMMI parece escrito para organizaciones ya maduras y vagamente escrito para ser usado
en valoraciones.
33
.
Tiempos aproximados para la maduración de las etapas de CMMI
Figura 8. Proceso de Mejora Continua CMMI 1
Figura 9 Dinámica entre procesos de calidad.
34
2.1.4 ISO 9001 ISO 9001 es un conjunto de estándares internacionales para sistemas de calidad. Diseñado para la
gestión y aseguramiento de la calidad, especifica los requisitos básicos para el desarrollo,
producción, instalación y servicio a nivel de sistema y a nivel de producto.
Evolución del estándar
Fue primeramente publicado en 1987, revisado en 1994 y actualizado nuevamente en el año 2000
(con un compromiso de ser revisado cada 5 años). La versión del 94 establecía un conjunto básico
mínimo de requisitos para el establecimiento y mantenimiento del sistema de gestión y
aseguramiento de la calidad para la ingeniería del software. Identificaba 20 áreas principales
(MTA’s) y 177 resultados de gestión. Se concibe como una metodología de procesos basada en
una lista de comprobaciones o requisitos a cumplir, umbral de calidad, valorado apto o no apto. Y
esta simplicidad es la que la ha hecho mundialmente extendida.
La retroalimentación de los usuarios, el desarrollo de los modelos de evaluación y mejora continua
y las críticas especializadas hacen que se requiera un estándar que:
Se centra en una aproximación de gestión basada en el proceso.
Sea compatible con otros sistemas de gestión (p.ej. ISO 14000).
Incluya requisitos para la mejora continua del sistema de calidad.
Coincida con las necesidades de los participantes externos (p.ej. clientes, proveedores,
etc.)
Sea amigable al usuario y al cliente.
Estas mejoras son recogidas en la ISO 9001:2000, donde se produce un movimiento desde una
aproximación prescriptiva, basada en prácticas de gestión de la calidad modernas con un enfoque
orientado al proceso, orientado a la satisfacción del cliente y la mejora continua.
Estructura del estándar
La nueva familia de estándares es la siguiente:
ISO 9000, Fundamentos y vocabulario.
ISO 9001, Requisitos para aseguramiento de la calidad.
ISO 9004, Directrices para la mejora del rendimiento.
ISO 9011, Directrices para la auditoría de los sistemas de gestión de la calidad y/o
ambiental.
35
ISO 9001 e ISO 9004 se han desarrollado como un par coherente de normas,
complementándose. Mientras ISO 9001 se centra en la eficacia del sistema de gestión de
la calidad para dar cumplimiento a los requisitos del cliente, ISO 9004 se recomienda para
organizaciones que persiguen la mejora continua, sin afán certificador.
El estándar se basa en un conjunto de Principios de Gestión de la Calidad:
Enfoque al cliente, Liderazgo, Implicación de todo el personal, Enfoque a procesos, Enfoque del
sistema hacia la gestión, Mejora continua, Enfoque objetivo hacia la toma de decisiones y
Relaciones mutuamente beneficiosas con los proveedores. Las cinco secciones que comprender
ISO 9001:2000 son:
1. Sistema de gestión de la calidad (requisitos generales y requisitos de la documentación).
2. Responsabilidad de la gestión (compromiso de la dirección, enfoque al cliente, política de
la calidad, planificación,...).
3. Gestión de los recursos (provisión de recursos, recursos humanos, infraestructura,
ambiente de trabajo).
4. realización del producto (planificación de la realización del producto, procesos
relacionados con los clientes, diseño y desarrollo, compras, prestación del servicio).
5. Medición, análisis y mejora (generalidades, supervisión y medición, control de servicio no-
conforme, análisis de datos, mejora).
De ISO 9001:2000 podríamos destacar positivamente, los siguientes puntos:
Amplia aplicabilidad, en cualquier industria y entorno.
Afecta la mayoría de las áreas funcionales de una organización, esto es, gestión, recursos
humanos, producción, ingeniería y calidad.
Reconocimiento y apariencia internacional, marca de reconocido prestigio.
Libertad de implementación y de interpretación de los requisitos.
Incrementa las oportunidades de negocio en ciertos mercados y mejora la satisfacción del
cliente.
Incremento de la productividad.
Menos repeticiones de trabajo.
36
Incremento de la satisfacción del empleado.
Mejora continua.
Incremento en los márgenes.
A ISO 9001:2000 se le critica:
o Es muy general, no proporciona información de cómo aplicarlo a empresas de menor
tamaño, tampoco proporciona directrices para su implementación en varias industrias.
o A causa de la amplia aplicabilidad del estándar ISO, hay pocas directrices para su
implementación en algunas industrias o campos específicos. Tampoco existen directrices
para su aplicación en una división o en una sucursal de una gran empresa.
o Para ISO 9001:1994, otro estándar, ISO 9000-3, se publicó como una guía para interpretar
ISO 9001 para el software.
o A pesar de estar ISO 9004:2000 dedicado a la mejora del proceso, sigue la estructura de
ISO 9001 y apunta alguna explicación de lo que se espera, pero se queda corto en entregar
un mapa para implementar el proceso de mejora. Cuando se lee ISO 9004, uno no sabe
qué áreas dirigir primero y cuáles después.
o En cuanto a pruebas empíricas, sólo hemos podido encontrar encuestas de satisfacción
entre usuarios que revelan, por ejemplo, que los más importantes beneficios como
resultado de la aplicación de ISO 9000:2000 como herramienta de mejora:
Uso de los datos medidos como herramienta de gestión de negocio (45.6%).
Más efectivas revisiones al modo de gestionar (41.9%).
Incremento del compromiso de gestión (39.2%).
Mejora de la satisfacción del cliente (30.4%).
A continuación una figura los pasos necesarios para la implantación de un sistema de gestión de
calidad. Fig. Proceso de Implantación ISO 9001:2000
37
Figura 10. Ciclo de implantación de un sistema de calidad.
2.1.5 ISO 15504 (SPICE, Software Process Improvement and Capability
determination) ISO/IEC 15504 es un emergente estándar internacional de evaluación y determinación de la
capacidad y mejora continua de procesos de ingeniería del software, con la filosofía de desarrollar
un conjunto de medidas de capacidad estructuradas para todos los procesos del ciclo de vida y
para todos los participantes. Es el resultado de un esfuerzo internacional de trabajo y colaboración
y tiene la innovación, en comparación con otros modelos, del proceso paralelo de evaluación
empírica del resultado.
Estructura del estándar
ISO/IEC desarrolla un modelo 2-D de evaluación de la capacidad del proceso, donde se valora la
organización de desarrollo software en la dimensión del proceso contra los atributos del proceso
en la dimensión de capacidad. La primera versión estructuraba el modelo en nueve partes, pero en
el curso de los debates y votaciones, en aras de reducir el tamaño del estándar, se decide que se
divida en cinco partes:
Parte 1. Conceptos y Vocabulario.
Parte 2. Realizando una Evaluación (Requisitos, normativa).
Parte 3. Guía para Realización de Evaluaciones.
Parte 4. Guía para el Uso de Resultados de Evaluaciones.
38
Parte 5. Un Modelo de Evaluación de Procesos.
La versión 1.0 inicialmente recogía treinta y cinco procesos agrupados en cinco categorías (cliente
proveedor, ingeniería, proyecto, soporte y organización).
Sin embargo, la idea de expandir el ámbito de aplicación del estándar evitando restringirlo a un
determinado ciclo de vida, la compatibilidad con ISO/IEC 12207 e ISO/IEC 15288 y con cualquier
modelo posterior, permite la evolución del estándar para aceptar Modelos de Referencia de
Procesos eliminando la inicial dimensión de procesos.
Puntos fuertes y puntos débiles.
SPICE ha sido un proyecto de lenta maduración, que ha variado mucho desde su borrador inicial
en 1995, hasta los modelos que están acabando de ser publicados. Muchas de las críticas o
mejoras propuestas a lo largo de estos años por diversos autores, han sido recogidas así como
ciertos aspectos positivos (como la representación continua del modelo) han sido adoptadas por
otros.
Cabe destacar el considerable número de estudios de evaluación empírica realizados, pudiendo
revisar sus conclusiones más significativas, en cuanto a validez predictiva, veracidad de la
capacidad, demostración de su capacidad para identificación de fuerzas, debilidades y riesgos así
como dirigir y priorizar el proceso de mejora.
Puntos Fuertes:
Primer modelo de procesos de 2 dimensiones, dimensiones independientes para los
procesos y la capacidad.
El resultado de una evaluación de proceso puede ser representado por un perfil de
proceso, una gráfica de 2 dimensiones.
Inicialmente recogía una escala refinada de procesos de 9 atributos y 6 niveles, que
posteriormente fue mejorada con la desaparición de la escala de procesos y la adopción
de los PRMs.
Define un conjunto de criterios de conformidad para permitir la comparación de modelos
externos de procesos y encontrar requisitos comunes.
Debilidades:
o Pensaba que el dominio de procesos debería ser más amplio para abarcar todos los
posibles ciclos de vida y que era difícil que todos los atributos de proceso fueran
universales, aplicables a todos los procesos y prácticas base.
o La dimensión capacidad ha alcanzado un alto grado de dificultad y existen solapamientos
con la dimensión procesos.
39
o La complejidad de las evaluaciones (y por consiguiente el costo) es significativamente más
alta que en otros modelos.
o Por último, en sus conclusiones, al valorar el panorama de distintos estándares existentes,
afirma la necesidad de pruebas de la efectividad y el impacto de la adopción de estos
modelos de mejora tanto en la ingeniería del software como en otros campos y resalta la
necesidad de búsqueda de integración y facilidad para la evolución que deben adoptar los
estándares, aspectos que, aunque no lo recoja el autor, están resueltos por SPICE frente a
otros modelos.
Se afirma que el desarrollo de ISO 15504 ha acercado a lo mejor de los expertos internacionales en
evaluación de procesos, y a través de la sinergia de estas relaciones ha llevado a significativos
avances en el estado del arte y en la argumentación teórica del proceso. Así, encontramos un
reconocimiento a la influencia de SPICE en el desarrollo de CMMI. Merecen ser destacados los
estudios sobre implantación de SPICE en pequeñas empresas, y de lo inadecuado del uso de SPICE
para metodologías ágiles. La siguiente Figura detalla los niveles de madurez en SPICE, ver figura 11
Figura 11. Niveles de Madurez SPICE 1
2.1.6 MOPROSOFT Norma Oficial Mexicana NMX-059/02-NYCE-2005
Los modelos estudiados anteriormente, ayudan a medir la madurez en organizaciones muy grandes. Si bien estos modelos internacionales permiten determinar la capacidad de procesos de una organización que desarrolla software, no es fácil adaptarlos al contexto de las empresas
40
mexicanas, que en su mayoría son PyMEs. De acuerdo con un estudio hecho en 2004, 92% de las empresas que desarrollan software en México son PyMEs, con menos de 100 empleados.
MoProSoft es un modelo de procesos para la industria de software nacional, que fomenta la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la capacidad de las organizaciones que desarrollan o mantienen software para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. También es aplicable en áreas internas de desarrollo de software de las empresas de diversos giros.
Características de MoProSoft
Es específico para el desarrollo y mantenimiento de software. Es sencillo de entender y adoptar. Facilita el cumplimiento de los requisitos de otros modelos como ISO 9000:2000, CMM y
CMMI. Se enfoca a procesos. Se le considera práctico en su aplicación, principalmente en organizaciones pequeñas, con
bajos niveles de madurez. Comprende un documento de menos de 200 páginas que, al compararlo con otros
modelos y estándares, lo hace bastante práctico. Resulta acorde con la estructura de las organizaciones mexicanas de la industria de
software. Está orientado a mejorar los procesos, para contribuir a los objetivos de negocio, y no
simplemente ser un marco de referencia o certificación. Tiene un bajo costo, tanto para su adopción como para su evaluación.
Fortalezas de MoProSoft
Mejora la calidad del software producido por la empresa que adopta el modelo.
Eleva la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad.
Integra todos los procesos de la organización y mantiene la alineación con los objetivos estratégicos.
Inicia el camino a la adopción de los modelos ISO 9000 o CMMI.
Sirve para implantar un programa de mejora continua.
Permite reconocer a las organizaciones mexicanas por su nivel de madurez de procesos.
Facilita la selección de proveedores.
Permite obtener acceso a las prácticas de ingeniería de software de clase mundial.
Estructura de MoProSoft
El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua. Sintetiza las mejores
41
prácticas en un conjunto pequeño de procesos que abarcan las responsabilidades asociadas a la estructura de una organización que son: la alta dirección, gestión y operación.
MoProSoft es un modelo integrado donde las salidas de un proceso están claramente dirigidas como entradas a otros; las prácticas de planeación, seguimiento y evaluación se incluyeron en todos los procesos de gestión y administración; por su parte los objetivos, los indicadores, las mediciones y las metas cuantitativas fueron incorporados de manera congruente y práctica en todos los procesos; las verificaciones, validaciones y pruebas están incluidas de manera explícita dentro de las actividades de los procesos; y existe una base de conocimientos que resguarda todos los documentos y productos generados.
Figura 12. El propósito de los procesos de MoProSoft10
10 Oktaba, H., Esquivel, C. A., Ramos, A. S., Martínez, A. M., Osorio, G. Q., López, M. R., ... & Lemus, M. Á. F. (2003). Modelo de Procesos para la Industria de Software MoProSoft. Versión.
42
Tabla3. Mapa de Procesos MoProSoft 1
Categoría Proceso Propósito
Alta Dirección
Gestión de Negocio Establecer la razón de ser de la organización, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cambios que permitan la mejora continua. Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos.
Gestión Gestión de Procesos Establecer los procesos de la organización, en función de los procesos requeridos identificados en el Plan Estratégico. Así como definir, planificar e implantar las actividades de mejora en los mismos.
Gestión Gestión de Proyectos Asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.
Gestión Gestión de Recursos Conseguir y dotar a la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como crear y mantener la Base de Conocimiento de la organización. La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización. Las actividades de este proceso se apoyan en tres subprocesos: - Recursos humanos y ambiente de trabajo. - Bienes, servicios e infraestructura. - Conocimiento de la organización.
Operación Administración de Proyectos Específicos
Establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados.
Operación Desarrollo y Mantenimiento de Software
Realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. 11
El 15 de agosto de 2005 se publica en el Diario Oficial de la Federación la declaratoria de vigencia de la norma NMX-059-NYCE-2005, bajo el nombre de TECNOLOGÍA DE LA
11 Modelo de Procesos para la Industria de Software MoProSoft, versión 1.3 (agosto 2005).
43
INFORMACIÓN SOFTWARE MODELOS DE PROCESOS Y EVALUACIÓN PARA DESARROLLO Y MANTENIMIENTO DE SOFTWARE.
Los beneficios de MoProSoft, en palabras de la directora del equipo que lo elaboró, la Dra. Hanna Oktaba, son12:
Al tener prácticas integradas, que abarcan desde la gestión de negocio hasta el desarrollo y mantenimiento de software, las empresas logran un mayor control sobre su desempeño en el mercado.
El costo de incorporación del nuevo personal podría disminuir si se enfocan a la educación y a la capacitación sobre un modelo único.
Las empresas pequeñas, al seguir procesos similares, podrían asociarse con mayor facilidad para afrontar proyectos de mayor envergadura.
La exportación de servicios de software de las empresas mexicanas será más factible, incluso se podría disminuir la necesidad de la intermediación de las empresas trasnacionales, gracias a que MoProSoft considera las prácticas reconocidas en el ámbito internacional.
La implantación de MoProSoft no demanda la incorporación de personal especializado en las empresas, únicamente requiere de una adecuada capacitación del personal existente.
12 Oktaba, H., Esquivel, C. A., Ramos, A. S., Martínez, A. M., Osorio, G. Q., López, M. R., ... & Lemus, M. Á. F. (2003). Modelo de Procesos para la Industria de Software MoProSoft. Versión.
44
2.1.7 Modelos de evaluación de la calidad del software. En esta sección se aborda la norma internacional para la evaluación de la calidad del software. Y su
relación con el método SQALE para la medición de la deuda técnica ya que esta última es una
implementación de la norma, este norma y su implementación nos permite medir la calidad en
base a las expectativas de la calidad esperadas por el usuario.
2.1.8 Norma Internacional ISO/IEC 9126 Lo norma ISO/IEC 9126 fue publicada en 1992, la cual es usada para la evaluación de la calidad
de software, llamado “Information technology Software product evaluation Quality
characteristics and guidelines for their use”; o también conocido como ISO 9126 (o ISO/IEC
9126). Este estándar describe seis características generales funcionalidad, confiabilidad,
usabilidad, eficiencia, mantenibilidad, portabilidad. Más adelante se estudiaran cada una de
estas características.
La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes
criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte,
mantenimiento, aseguramiento de la calidad y auditoria de software. Los modelos de calidad
para el software se describen así:
Calidad interna y externa:
El aseguramiento de la calidad se da a través de las seis características antes mencionadas,
tanto como para calidad interna como para la externa, las cuales, están subdivididas. Estas
seis divisiones se manifiestan externamente cuando el software es usado como parte de un
sistema Informático, y son el resultado de atributos internos de software los atributos
internos son las características de la calidad intrínsecas en el software y con no son visibles
directamente por el usuario.
Calidad en uso:
Calidad en uso es la combinación del usuario final de las seis características de la calidad
interna y externa del software.
Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación
más completo, se puede pensar que la usabilidad del modelo de calidad externa e interna
pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es la forma como los
profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se
puede asumir como la forma que lo asimila o maneja el usuario final. Si se unen los dos
modelos, se puede definir que los seis indicadores del primer modelo tienen sus atributos y el
modelo de calidad en uso sus cuatro indicadores pasarían hacer sus atributos, mirándolo
gráficamente quedaría así ver figura 13
45
Figura 13. Componentes Norma ISO/IEC 9126 1(Elaboración propia)
Norma de Evaluación ISO/IEC 9126
La norma ISO/IEC9126 establece categorías para las cualidades de la calidad externa e interna
y calidad en uso del software, teniendo en cuenta estos siete indicadores (funcionalidad,
confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad en uso),
que se subdividen a su vez en varios indicadores; estas se pueden medir por métrica interna o
externa. Ver Fig. 13 ISO/IEC Componentes
FUNCIONALIDAD
Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer
las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas. A
continuación se muestra la característica de Funcionalidad y las subcaracterísticas que cubre.
ISO/IEC 9126
Eficiencia
Usabilidad
Confiabilidad
Funcionalida
Mantenibilidad
Portabilidad
Calidad de Uso
46
Figura 14. Características de la Funcionalidad (Elaboración propia)
Característica de funcionalidad
La funcionalidad se divide en 5 características:
1. Adecuación: La capacidad del software para proveer un adecuado conjunto de
funciones que cumplan las tareas y objetivos especificados por el usuario.
2. Exactitud: La capacidad del software para hacer procesos y entregar los resultados
solicitados con precisión o de forma esperada.
3. Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas
específicos.
4. Seguridad: La capacidad del software para proteger la información y los datos de
manera que los usuarios o los sistemas no autorizados, no puedan acceder a ellos para
realizar operaciones, así como la capacidad de aceptar el acceso a los datos de los
usuarios o sistema autorizado, también incluye el mantener la integridad y
salvaguarda de los datos.
5. Conformidad: La capacidad del software de cumplir con los estándares referentes a la
funcionalidad.
Funcionalidad
Seguridad
Interoperatividad
Conformidad
Exactitud
47
Confiabilidad
La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento adecuado
al ser utilizando en condiciones específicas. En este caso la confiabilidad se amplía al hecho de
mantener un nivel especificado de funcionamiento y no una función requerida.
Figura 16. Subcaracterísticas Confiabilidad 1 (Elaboración propia)
Característica de Confiabilidad
La confiabilidad se divide en 4 criterios:
1. Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra
errores. Ejemplo, la forma como el software advierte al usuario cuando realiza
operaciones en un disco sin formato, o cuando no encuentra espacio suficiente el
disco duro donde esta almacenando los datos.
2. Tolerancia a fallos: La capacidad que tiene el software para mantener un nivel de
funcionamiento en caso de un fallo o error de sistema.
3. Recuperabilidad: La capacidad que tiene el software para restablecer su
funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.
4. Conformidad de la confiabilidad: La capacidad del software de cumplir a los
estándares o normas relacionadas a la confiabilidad.
Confiabilidad
Aceptaciónn
Tolerancia a Errores
Recuperabilidad
Madurez
48
Usabilidad
La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en forma fácil
y atractiva. Algunos criterios de funcionalidad, confiabilidad y eficiencia afectan la usabilidad,
pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como usabilidad. La usabilidad
está determinada por los usuarios finales y los usuarios indirectos del software, dirigidos a
todos los ambientes, a la preparación del uso y el resultado obtenido.
Figura 17. Subcaracterísticas Usabilidad 1 (Elaboración propia)
Característica de Usabilidad
La usabilidad se divide en cinco criterios:
1. Entendimiento: La capacidad que tiene el software para permitir al usuario entender
si es adecuado, y de una manera fácil como ser utilizado para las tareas y las
condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la
documentación y de las ayudas que el software entrega.
2. Aprendizaje: La forma como el software permite al usuario aprender su uso. También
es importante considerar la documentación.
Usabilidad
Operabilidad
Atracción
Conformidad Entendimiento
Aprendizaje
49
3. Operatividad: La manera como el software permite al usuario operarlo y controlarlo.
4. Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a
las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño
gráfico.
5. Conformidad de uso: La capacidad del software de cumplir los estándares o normas
relacionadas a su usabilidad.
Eficiencia
La eficiencia del software es la forma del desempeño adecuado, de acuerdo al número de
recursos utilizados según las condiciones planteadas. Se debe tener en cuenta otros aspectos
como la configuración de hardware, el sistema operativo, entre otros.
Figura 18. Subcaracterísticas Eficiencia 1(Elaboración propia)
Eficiencia
Conformidad de eficiencia
Utilizacion de recursos
Comportamiento de
Tiempos
50
Característica de Eficiencia
La eficiencia se divide en 3 criterios:
1. Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento,
el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar
el procedimiento más complejo del software y esperar su tiempo de respuesta,
realizar la misma función pero con más cantidad de registros.
2. Utilización de recursos: La capacidad del software para utilizar cantidades y tipos
adecuados de recursos cuando este funciona bajo requerimientos o condiciones
establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.
3. Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los
estándares o convenciones relacionados a la eficiencia.
Capacidad de mantenibilidad.
La capacidad de mantenimiento es la cualidad que tiene el software para ser modificado.
Incluyendo correcciones o mejoras del software, a cambios en el entorno, y especificaciones
de requerimientos funcionales.
Figura 19. Subcaracterística Capacidad Mantenibilidad. 1 (Elaboración propia)
Mantenibilidad
Cambiabilidad
Facilidad de Prueba
Conformidade Mantenimiento
Capacidad de ser analizado
51
Característica de Mantenimiento
El mantenimiento se divide en 5 criterios:
1. Capacidad de ser analizado: La forma como el software permite diagnósticos de
deficiencias o causas de fallas, o la identificación de partes modificadas.
2. Cambiabilidad: La capacidad del software para que la implementación de una
modificación se pueda realizar, incluye también codificación, diseño y documentación
de cambios.
3. Estabilidad: La forma como el software evita efectos inesperados para modificaciones
del mismo.
4. Facilidad de prueba: La forma como el software permite realizar pruebas a las
modificaciones sin poner el riesgo los datos.
5. Conformidad de facilidad de mantenimiento: La capacidad que tiene el software para
cumplir con los estándares de facilidad de mantenimiento.
Portabilidad
Es la capacidad que tiene el software para ser instalado y desplegado en ambientes o
plataformas distintitas para el cual fue diseñado, utilizando el menor de los esfuerzos para su
adecuación.
Característica de portabilidad
La portabilidad se divide en cinco grandes criterios:
1. Adaptabilidad: Es como el software se adapta a diferentes entornos especificados
(hardware o sistemas operativos) sin que implique reacciones negativas ante el
cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla,
tablas, volúmenes de transacciones, formatos de reporte, etc.).
2. Facilidad de instalación: La facilidad del software para ser instalado en un entorno
específico o por el usuario final.
3. Coexistencia: La capacidad que tiene el software para coexistir con otro o varios
software, la forma de compartir recursos comunes con otro software o dispositivo.
52
4. Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro
software del mismo tipo, y para el mismo objetivo. Ejemplo, la reemplazabilidad de
una nueva versión es importante para el usuario, la propiedad de poder migrar los
datos a otro software de diferente proveedor.
5. Conformidad de portabilidad: La capacidad que tiene el software para cumplir con los
estándares relacionados a la portabilidad.
Figura 20. Características de la Portabilidad 1 (Elaboración propia)
Calidad en uso
Es la característica del software en la cual el usuario final logra realizar los procesos con
satisfacción, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisión de
todas las opciones que el usuario trabaja diariamente y los procesos que realiza
esporádicamente relacionados con el mismo software.
Portabilidad
Facilidad de Instalación
Reemplazabilidad
Conformidad Adaptabilidad
Coexistencia
53
Figura 21. Característica Calidad de Uso 1 (Elaboración propia)
Característica Calidad de uso
La calidad de uso se divide en 4 criterios:
1. Eficacia: La capacidad del software para permitir a los usuarios finales realizar los
procesos con exactitud e integridad.
2. Productividad: La forma como el software permite a los usuarios emplear cantidades
apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de
uso. Para una empresa es muy importante que el software no afecte al productividad
del empleado
3. Seguridad: Se refiere al que el Software no tenga niveles de riesgo para causar daño a
las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son
normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad),
confiabilidad, usabilidad o facilidad de mantenimiento.
4. Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el software
cuando el software alcanza sus expectativas de uso, rendimiento y disponibilidad.
Calidad en Uso
Productividad
Seguridad
Satisfaccion
Eficacia
54
2.1.9 Modelo SQALE (Software Quality Assessment based on Lifecycle
Expectations)
SQALE (Evaluación de la Calidad de Software basado en las expectativas de ciclo de vida) es un
método para apoyar la evaluación del código fuente de la aplicación de software. Se trata de un
método genérico, independiente del lenguaje de las herramientas de análisis de código fuente,
bajo la licencia Creative Commons Reconocimiento No comercial sin obra derivada 3.0. Editores de
software pueden utilizar e implementar libremente el método SQALE13
El método SQALE fue desarrollado por Inspearit en Francia (antes DNV ITGS - Francia). Y es
utilizado por muchas organizaciones para aplicaciones de cualquier tipo y cualquier tamaño. Este
método se implementa mediante varias herramientas estáticas de análisis de código que producen
los índices e indicadores de la calidad. Este método permite hacer la gestión precisa de la deuda
de diseño y de la deuda técnica de proyectos de desarrollo de software.
El método SQALE se basa en ocho principios fundamentales:
1. La calidad del código fuente es un requisito no funcional, es decir no forma parte directa
de los requerimientos de funcionalidad del sistema.
2. Los requisitos en relación con la calidad del código fuente tienen que ser formalizados
como cualquier otro requisito del mismo. Como consecuencia, un requisito de calidad
que afecte al código fuente tiene que ser al menos:
Atómico
No ambiguo
No redundante
Justificable
Aceptable
Implementable
No contradictorio con cualquier otro requisito
Verificable
3. Medir o calcular la calidad del código es contrastar el estado actula del código fuente
con el esperado.
13 Jean-Louis Letouzey (2012). SQALE Method Definition Document Version 1.0. Francia: Inspearit
55
4. El método SQALE mide la distancia a la conformidad de los requisitos considerando el
coste de remediar o corregir el código fuente hasta alcanzar la conformidad.
5. El método SQALE respeta la condición de representación, un componente importante
de la teoría de medidas. La condición de representación afirma que una medida “M”
tiene que mapear entidades en números y relaciones empíricas en relaciones numéricas
de tal manera que se siga preservando el significado.
6. El método SQALE utiliza la adición para agregar los costes de corrección y para calcular
los indicadores de calidad.
7. El modelo de calidad de SQALE es ortogonal. Esto significa que un requisito relacionado
con un atributo de calidad sólo aparecerá una vez en el modelo. Un requisito se enlazará
solamente con una subcaracterísticas de calidad. Y una subcaracterísticas se enlazará
solamente con una característica.
8. El modelo de calidad de SQALE tiene en cuenta el ciclo de vida del software. Las
características, subcaracterísticas y requisitos se organizan de manera que se pueda
reflejar correctamente la cronología de las necesidades tal y como aparecen en el ciclo
de vida del software.
Estructura del modelo
El modelo de calidad se organiza en tres niveles jerárquicos. Cada uno de ellos agrupa al siguiente
nivel hasta llegar a los requerimientos específicos de la calidad. El primer nivel describe las
características deseadas, y el segundo nivel de subcaracterísticas desglosa y detalla a cada
característica. El tercer nivel se compone de los requisitos que debe cumplir el código fuente. Ver
Figura 22
Figura 22. Diagrama Flujo Metodología SQALE (Elaboración Propia)
Nivel 1
Caracteristicas. Nivel 2
Subcaracteristicas. Nivel 3
Requisitos
56
Características
El método SQALE define ocho características de primer nivel que se deducen del ciclo teórico de
un archivo de código fuente (codificar, probar, cambiar, entregar, mantener, portar, reutilizar).
Estas características se establecen conforme a la norma ISO 9126 y han sido seleccionadas para el
modelo porque representan propiedades internas del código, y porque impactan directamente en
las actividades típicas del ciclo de vida del desarrollo software. Ver figura
Figura 23. Características Modelo SQALE 1
El método SQALE es una proyección de la norma ISO 9126 sobre la cronología del ciclo de
desarrollo del software.
Los índices característicos del método SQALE son los siguientes:
SQALE Testability Index: STI
SQALE Reliability Index: SRI
SQALE Changeability Index: SCI
SQALE Efficiency Index: SEI
SQALE Security Index: SSI
SQALE Maintainability Index: SMI
SQALE Portability Index: SPI
SQALE Reusability Index: SRuI
A continuación se definen cada uno de estos índices, todas las características anteriores pueden
ser adaptadas de acuerdo a las condiciones de cada empresa siempre y cuando se mantenga el
orden de las misma para su evaluación y las tres primeras características de la calidad que son
Testability, Reliability y Changebility sean las mínimas a evaluar.
Testability: Voas y Miller definen este concepto como la probabilidad de que el software se
“cansará” en su próxima ejecución. En el estándar de la IEEE la capacidad de prueba se define
57
como: (1) el grado en que un sistema o componente facilita el establecimiento de los criterios de
prueba y la realización de pruebas para determinar si esos criterios se cumplen
Reliability: El concepto de confiabilidad se aplica cuando esperamos que algo se comporte de
cierta manera. La confiabilidad es uno de los indicadores que se utilizan para medir la calidad. Este
factor está mayormente encaminado al usuario en relación con el funcionamiento del sistema,
intuitivamente, si los usuarios de un sistema rara vez experimentan fallo, el sistema se considera
que es más fiable que uno que falla con más frecuencia
Changeability: El cambio o mutabilidad puede ser definido como la transición en el tiempo de un
sistema a una estado alterado. Un evento de cambio se puede caracterizar con tres elementos: (1)
el agente de cambio, (2) el mecanismo de cambio, y (3) el efecto del cambio. Ver Fig.figura 24.
Efficiency: El conjunto de recursos informáticos y de código necesarios para que un programa
realice su función.
Security: Un sistema seguro debe de cumplir con los requerimientos de auditoria, autenticación y
acceso. En los cuales única y exclusivamente tendrán acceso los usuarios que se han verificados
mediante mecanismos de autenticación y solo a los módulos u operaciones que estén
autorizados para su perfil, y que además se registren los sucesos o transacciones a las cuales
accedió.
Por otra parte la característica de seguridad debe previene la posible explotación de
vulnerabilidades en el sistema originadas por malas prácticas en la codificación o la no aplicación
de parches de seguridad a la infraestructura del sistema.
Maintainability: El IEEE1 (19990) define mantenibilidad como: “La facilidad con la que un sistema o
componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u
otros atributos o adaptarse a cambios en el entorno”.
Esta definición está directamente conectada con la definición del IEEE para mantenimiento del
software: “es el proceso de modificar un componente o sistema software después de su entrega
para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarlo a cambios en el
entorno”.
En consecuencia, la mantenibilidad es una característica de calidad del software relacionada con la
facilidad de mantenimiento, que nosotros consideraremos como una actividad de mantenimiento.
A mayor mantenibilidad, menores costes de mantenimiento (y viceversa).
Portability: El esfuerzo necesario para transferir el programa de un entorno hardware/software a
otro entorno diferente.
Reusability: Hasta dónde se puede volver a emplear un programa en otras aplicaciones, en
relación al empaquetamiento y alcance de las funciones que realiza el programa.
58
Subcaracterísticas
Cada una de las características se descompone en un conjunto de subcaracterísticas. Estas
subcaracterísticas se utilizan para agrupar los requisitos y así permitir realizar análisis con varios
niveles de abstracción.
Existen dos tipos de subcaracterísticas:
1. Las que se corresponden con actividades del ciclo de vida como pruebas unitarias, pruebas
de integración, optimización del uso de procesador o del tamaño del código generado.
2. Las que resultan de aplicar reglas en términos de buenas o malas prácticas relacionadas
con la arquitectura del software y la codificación.
Requisitos
Este nivel del modelo contiene todos los requisitos de calidad del código, siempre respetando los
criterios presentados en los principios fundamentales. Estos requisitos se refieren a aspectos que
existan en el código fuente.
Por ejemplo, supongamos que se especifica un requisito relacionado con la complejidad
ciclomática. Este requisito tendrá impacto sobre las pruebas unitarias (por tanto, afectará a la
característica de la facilidad de prueba) y a la legibilidad (y por tanto, afectará a la característica de
mantenibilidad).
Cada uno de los requisitos se enlaza con el nivel más bajo posible, en relación con la primera
característica de calidad a la que contribuya cronológicamente.
Un ejemplo de requisito puede ser un umbral límite para una métrica estructural, o respetar una
regla sintáctica.
A continuación se estudiara el rango de calificación de la deuda técnica según el método SQALE.
Calificación SQALE
La calificación consiste en producir una métrica derivada en una escala ordinal.
59
Figura 25. Calificación Modelo SQALE 1
La calificación para una característica concreta y un artefacto concreto es el resultado de una
comparación del coste estimado de corregirla respecto a la estimación del coste de desarrollo de
ese artefacto, o lo que es lo mismo la deuda técnica de tu artefacto software.
Ejemplo del cálculo del rango SQALE mediante la herramienta SonarQube
60
Capítulo 3 Deuda Técnica Una vez estudiados los distintos procesos de desarrollo, los modelos de calidad en los procesos de
desarrollo y sus modos de evaluación de la calidad del producto de software, así como la
definición de mejores prácticas. Conoceremos la metáfora de la deuda técnica y su aportación en
el manejo de la calidad de software con respecto al tiempo.
3.1. Orígenes del Término. El término proviene de una metáfora que acuño Ward Cunningham, la cual se cita a continuación:
“Deuda técnica incluye aquellas cosas internas que usted elija no hacer
ahora, pero que le impedirá el desarrollo futuro si se dejan sin hacer. Esto incluye la
refactorización diferida. Deuda técnica no incluye la funcionalidad diferida salvo en
casos extremos donde la funcionalidad entregada es “suficientemente buena para el cliente,
pero no satisface algún estándar (por ejemplo, un elemento de interfaz de usuario que no es
totalmente compatible con algún estándar de interfaz de usuario)” 14
Es decir la deuda técnica es posponer todas aquellas actividades inherentes al desarrollo de
software que por diferentes situaciones, ocasionarán que en un futuro compliquen o impidan el
correcto mantenimiento del software, este concepto no incluye la funcionalidad no incluida o
faltante ya que solo contempla las actividades propias del desarrollo de software.
Deuda Técnica es una excelente metáfora acuñada con el fin de prevenirnos de una deuda. La
metáfora, nos previene que si continuamos haciendo las cosas de la manera rápida y sucia
obtendremos una deuda técnica, que es similar a una deuda financiera.
Y al igual que una deuda financiera, la deuda técnica incurre en el pago de intereses, que vienen
en la forma de un esfuerzo extra que tendremos que pagar a futuro dentro del desarrollo o
mantenimiento, debido a la mala decisión de un diseño rápido y sucio.
Como toda deuda, podemos optar por:
Seguir pagando los intereses moratorios mediante la corrección de errores.
Podemos liquidar el adeudo inicial, tomando medidas como el refactorizar por
completo el código que fue basado en un diseño rápido y sucio por uno mejor.
Aunque cuesta de momento pagar el monto total, ganamos con pagos de interés reducidos en el
futuro.
La metáfora también explica el porqué, de momento puede ser más coherente el enfoque
14 Chris Sterling (2011). Manning Software Debt, Building for the inevitable change. USA: Addison-
Wesley
61
apresurado y sucio del desarrollo de software. Esto se debe a que como en algunas ocasiones una
empresa incurre en una deuda para aprovechar una oportunidad de mercado.
También otra forma de incurrir en deuda técnica es cuando el equipo de desarrollo incurre en
deuda técnica para poder alcanzar una fecha límite importante.
Otro problema muy común es que las organizaciones de desarrollo permiten que su deuda se
salga de control y pasan la mayor parte de su esfuerzo de desarrollo o mantenimiento de software
en pagar los intereses agobiantes.15 Ver siguiente figura.
Figura 26. Gráfica de Deuda Técnica 1 (Elaboración Propia)
Nuevas definiciones:
La deuda Técnica es un concepto que equipara la evasión u omisión de la aplicación de mejores
prácticas en el desarrollo de software a la deuda financiera que se acumula con el tiempo.
Imagine que usted tiene un proyecto que tiene dos opciones posibles.
a) Una de ellas es la manera rápida y fácil, pero inherentemente será necesario modificar en
el futuro.
b) El otro tiene un mejor diseño, pero tomará más tiempo para poner en práctica.
En el desarrollo, la liberación de código como un enfoque rápido y sencillo es como incurrir en una
deuda y la obligación de hacerlo bien como un interés, que se presenta en forma de trabajo
adicional en el futuro.
15 Chris Sterling (2011). Manning Software Debt, Building for the inevitable change. USA: Addison-
Wesley
62
Tomarse el tiempo para refactorizar es equivalente a liquidar la deuda principal. Mientras que esto
lleva tiempo en el corto plazo, también disminuye los pagos de intereses futuros.
Ward Cunningham describe este concepto en el año 1992 de la siguiente manera:
“Liberar código por primera vez es como entrar en la deuda técnica. A poca deuda técnica el
desarrollo se acelera, siempre y cuando se pague de inmediato la deuda se vuelve tolerable. Pero
que empeorara con el pago de intereses moratorios cada que hacemos caso omiso a la misma”
El concepto no significa que nunca se debe incurrir en la deuda. Ya que del mismo modo que el
endeudamiento se usa como un apalancamiento que puede ayudar a una empresa cuando se usa
correctamente y responsablemente, una solución rápida puede significar una respuesta ágil a las
demandas del mercado.
Además, la deuda técnica no es sólo, código chatarra. El mal código siempre será mal código, y la
deuda técnica puede ser resultado del trabajo de buenos programadores bajo la premura de un
proyecto mal estimado.
A continuación la siguiente tabla nos muestra la Visibilidad de la Deuda Técnica con respecto a las
demás características de un sistema. Ver Fig. Visibilidad de la Deuda Técnica.
Visible Invisible
Valor Positivo (+) Mejora Arquitectura
Valor Negativo (-) Defecto Deuda Técnica
Figura 27. Visibilidad de la Deuda Técnica 1 (Elaboracion Propia)
De la tabla anterior se puede decir que un defecto tiene un impacto negativo y es fácil de detectar
al ser visible manifestándose como un defecto en el software, sin embargo la deuda técnica
permanece oculta para los usuarios finales o no técnicos y es igual de nociva a un proyecto de
software como un defecto.
3.1.1 Causas de la Deuda Técnica. Existen algunas causas muy identificadas acerca de la deuda técnica que directamente la
aumentan, si los equipos de desarrollo buscan eliminar o reducir la deuda técnica es necesario
mitigar estas casusas raíz, las cuales son:
a) Presión por la calendarización (schedule presure).
b) Duplicación (copy & paste)
c) Pretender hacerlo todo, de una vez (get It “right” the first time).16
16 Chris Sterling (2011). Manning Software Debt, Building for the inevitable change. USA: Addison-
Wesley
63
a) Presión por la calendarización.
Cuando los equipos están sujetos a un compromiso que no es razonable, están presionados por
tomar atajos para cumplir las expectativas de los administradores de proyectos.
Múltiples situaciones pueden causar que un compromiso sea inalcanzable. A continuación se
mencionaran algunas:
I. Arrastramiento del alcance (Scope Creep):
En administración de proyectos se refiere a aquellos cambios no controlados en el alcance de un
proyecto. Este fenómeno puede ocurrir cuando el alcance de un proyecto no se define,
documenta, o controla correctamente. Típicamente, el aumento del alcance consiste en productos
nuevos o nuevas características de productos ya aprobados que hacen que el equipo de proyecto
se desvíe de su propósito original. Debido a su tendencia a centrarse en solamente una dimensión
de un proyecto, el arrastramiento del alcance puede también dar lugar a que el equipo de
proyecto exceda su presupuesto y cronograma originales. Mientras el alcance de un proyecto
crece, más tareas se deben terminar con el mismo presupuesto y calendarización que la cantidad
original de tareas del proyecto.
El arrastramiento del alcance puede ser un resultado de:
Un pobre control de cambios.
Clientes maliciosos que fomentan la ambigüedad a fin de evitar compromisos.
Carencia de la identificación inicial apropiada de qué se requiere para lograr los objetivos
del proyecto.
Un gerente de proyecto o patrocinador débil.
El crecimiento del alcance es un riesgo en la mayoría de los proyectos, esto a menudo da lugar a
excesos en el presupuesto.
II. Estimaciones de terceros.
El líder técnico o arquitecto hace una estimación inicial de cuánto tiempo se podría tardar el
desarrollo o mantenimiento y cuánto esfuerzo le tomara entregar al desarrollador. A lo cual el
equipo de desarrollo que es el encargado de realizar las tareas de diseño y codificación lo acepta
sin cambios.
III. Cambios en el equipo de trabajo.
Se incorporan miembros del equipo, se separan del mismo o se sustituyen después del
lanzamiento del plan es decir no hay integración del equipo.
IV. Rígido proceso de estimación.
La estimación es una mera suposición, o a lo sumo es una muy bien informada suposición. Por
tanto generar compromisos sin ninguna duda razonable o variabilidad en el plan del proyecto.
Resulta problemático.
64
V. Integración de Módulos y/o Funcionalidad en etapas tardías.
Cuando la integración ocurre tarde en el ciclo de liberación, los problemas inesperados llegan Y
generalmente deben ser abordados y estabilizados dentro del tiempo estipulado por el plan de
liberación.
La planeación y calendarización se basa en numerosos supuestos. Es imposible
saber qué va a pasar en el futuro. También es imposible comprender plenamente
un sistema complejo como lo es el software antes de su construcción. Por lo tanto, los planes son
herramientas para ayudar a guiarnos hacia nuestras metas.
VI. Duplicidad.
Hay muchas razones por las que la duplicidad de código se produce en el desarrollo de software:
o La falta de experiencia por parte de los miembros del equipo.
o Programación de copiar y pegar o de “canibalización de código”17
o Conforme a un mal diseño del software existente.
o La presión para entregar.
La duplicación de código fuente es difícil de evitar por completo, pero existen herramientas que
pueden ayudan a su identificación.
Herramientas que implementan algoritmos para la búsqueda de código duplicado en
la mayoría de los lenguajes populares modernos han madurado en los últimos años.
El método de análisis de código estático nos ayuda a la detección temprana de esta causa de la
deuda técnica.
Métodos de Mitigación de la Deuda Técnica
Algunos métodos de mitigación para evitar la duplicidad de código son:
Programación por pares:
El simple hecho trabajar con otras personas propicia un ambiente colaborativo en el cual los
miembros del equipo pueden compartir su conocimiento y mejorar las competencias de cada uno
de los miembros del equipo. La programación por pares no es tan fácil como poner dos
miembros del equipo en la misma estación de trabajo y que se le piden que trabajar juntos.
La mayor interacción entre los miembros del equipo utilizando la programación en parejas
17 Omar Isidro Pineda Mancilla (2013). Generador de código fuente cobol. UPIICSA – IPN México, Ciudad de México
65
podría dar lugar a conflictos. Este conflicto puede ser positivo o negativo
al equipo, dependiendo de cómo sea manejado.
Es importante apoyar a los miembros del equipo en el uso de la programación en parejas
a través del entrenamiento y la reflexión periódica.
Evitar la mala práctica de Copiar y pegar:
Copiar y pegar es una mala práctica de desarrollo en la cual frecuentemente incurren
programadores sin experiencia o estudiantes, que encuentran al hecho de escribir código desde
cero algo difícil y prefieren buscar una solución pre-escrita o solución parcial que pueden utilizar
como base para su propia solución.
Este tipo de programadores copian código a menudo y no entienden completamente el código
que están tomando. El código a menudo proviene de diversas fuentes tales como colegas, foros de
internet, código proporcionado por profesores, o los libros de texto de informática.
Al copiar y pegar se corre el riesgo de:
o Copiar código ilegible y ofuscado.
o Copiar código superfluo e innecesario
o Tener código descontextualizado, el código al ser incrustado en un contexto o propósito
para el cual no fue creado pudiera ser difícil de leer y entender.
o El código copiado pudiera tener código malicioso. 18
Evitar el sobre evolucionar constantemente el diseño de software:
El software debe ser evolutivo de manera que constantemente se generen nuevos diseños que
robustezcan el mismo, atendiendo los requerimientos funcionales y no funcionales.
Después debe ser revisado, y final mente codificado. Evitando el constate cambio y la
postergación de la tarea de la codificación al querer perfeccionar el diseño.
a) Hacerlo todo de una sola vez.
Hacer todo de una vez es crear soluciones complejas a funcionalidades hipotéticas que jamás
serán usadas pero que se les deberá dar mantenimiento en un futuro. El diseño a una solución
perfecta es una tarea destructiva y es difícil de alcanzar aun para el desarrollador de software más
experimentado.
Debemos admitir que el software es complejo, incluso en sus formas más básicas. Ya que convertir
las necesidades de los usuarios en código es un esfuerzo complicado y más aún trabajar con otros
desarrolladores la complica aún más. Entonces ¿porque creemos que podemos crear software que
resuelva todo eso y de una sola vez?
18 Omar Isidro Pineda Mancilla (2013). Generador de código fuente cobol. UPIICSA – IPN México, Ciudad de México
66
Existe la falsa creencia de que las necesidad de negocio o reglas de negocio no cambiaran por un
periodo largo de tiempo, pensar de este manera es pensar que el software desarrollado esta
hecho de una vez por todas. Dicho de otra manera, si se sabe que el código fuente cambiaria a lo
largo del tiempo es preferible dejarlo abierto a modificaciones que suponer las mismas.
La figura 28 muestra el círculo permanente en el que se incurre con malas prácticas y negligencias
al momento del desarrollo de un producto.
Figura 28. Circulo Vicioso de la Deuda Técnica 1
Más Tiempo conlleva más
costos.
Negocio menos ágil, código
menos tolerante a cambios.
Generan menos retorno de inversión y menos dinero.
Menos dinero para futuros desarrollos.
Código pobremente
escrito.
67
3.1.2 Identificación, Cuantificación y Manejo de la deuda técnica.
3.1.2.1 Identificación de la deuda técnica.
La deuda técnica es similar a una deuda financiera, de momento ayuda a un rápido desarrollo
pero al costo de un interés que tendrá que ser pagado a futuro. Entre más alarguemos el pago de
la misma mayor será el costo de los intereses.
Las restricciones no técnicas para pagarla son.
o Un presupuesto apretado.
o Cumplir con fechas de entrega apretadas.
Aunque probablemente estas situaciones pueden ser excusas para un código sucio y un pobre
diseño esto es resultado de otros factores. La deuda técnica existe cuando es intencional, aunque
de momento no lo pareciere, es decir que se toma la decisión de incurrir en ella debido a obtener
un rápido beneficio estratégico ganando tiempo o mercado.
Por ejemplo algunos administradores de proyectos incurren en deuda técnica a cambio de cumplir
con las metas de mediano plazo y deciden pagarla con un esfuerzo adicional en la siguiente
iteración del programa o siguiente liberación.
Después de detectar si la deuda técnica fue accidental, intencional o por ignorancia. Tarde que
temprano tendremos que pagarla. Esto no pudiera ser necesariamente cierto. En decir algunas
situaciones incurrir en una deuda podría generar beneficios de muy corto plazo.
La prioridad para elegir si pagar o no la deuda técnica viene de las decisiones de negocio o
estrategias empresariales, especialmente cuando la deuda es intencional.
En algunas situaciones cuando la deuda es intencional, consiente y por razones de negocio. Puede
ayudar a financiar el desarrollo rápido de un producto y debemos en todo momento estar
conscientes de pagarla en futuros desarrollos o liberaciones.
Cuando esta deuda es inconsciente y derivada de errores o malas prácticas en el desarrollo debe
estimarse de inmediato para poder tomar una decisión consciente, que esté de acuerdo a las
estrategias de negocio.19
En la siguiente figura se muestra una clasificación de los tipos de justificaciones que se dan en un
proyecto al momento de incurrir en deuda técnica ver figura.
19 Buschmann, F., "To Pay or Not to Pay Technical Debt," Software, IEEE , vol.28, no.6, pp.29,31, Nov.-Dec. 2011
68
Figura 29. Ejemplos de Clasificación de Causas de la deuda Técnica.
Cruce te Tipos de Incidentes vs Hallazgo 1
Mitigación de la deuda técnica.
El primer paso para mitigar la deuda técnica es reconocer que existe y
es perjudicial para el mantenimiento del software que se está trabajando. Esto
parecería obvio, pero normalmente los equipos de desarrollo no ven las consecuencias de la
deuda y sólo se quejan de su existencia. Si los equipos no abordan la deuda técnica, ya que la
identificaron, se están estableciendo un precedente de hacer caso omiso de ella.
Cada vez que el equipo no reconoce y/o no toma acciones correctivas el costo de la deuda para el
mantenimiento del software se incrementa.
A continuación se presentan algunas de las formas en que la deuda técnica se ataca con eficacia.
a) Pagar la deuda técnica inmediatamente (también conocida como “Fix it now”).
b) Realizar abonos inmediatos sin entorpecer el plan del proyecto.
c) Transferir los intereses de la deuda técnica para la siguiente iteración.
a) Pagar de inmediato.
El método más efectivo de estos tres es probablemente el más controvertido. El pago de la deuda
técnica inmediatamente va en contra de las normas del proyecto. Ya que los equipos se utilizan
69
para codificar sólo las funcionalidades en las que está trabajando actualmente y dejar las mejoras
técnicas para después, incluso aunque para después nunca llegue.
¿Cómo puede un equipo justificar el arreglar inmediatamente la deuda técnica al momento que se
le encuentra en lugar de sólo agregar la funcionalidad por la cual fue contratado?
Se analizan dos premisas, para contestar la pregunta:
Un cliente no contrata a un desarrollador solo para tomar decisiones del cómo mejorar el
desarrollo de software o que solo tenga presente esto. Los clientes internos o externos emplean a
los equipos de desarrollo que cumple con las necesidades de negocio actual y que en ocasiones
soporten modificaciones a futuro. Esto significa que el software debe ser mantenible, es decir
susceptible a ser modificado (para corrección y mejora) de forma simple y rápida. Un miembro del
equipo es responsable acerca de las mejoras que ayuden a la mantenibilidad del software, esto es
considerado con que aporta valor para los clientes.
La segunda consideración es acerca de que el costo de oportunidad o costo asociado de arreglar la
deuda técnica. Es una constante que permanece en el tiempo, pero que se incrementa a cada
momento que la enfrentamos y no la arreglamos.
Por ejemplo tenemos una variable ambigua como la que se muestra en el siguiente fragmento de
código: Veamos el siguiente fragmento de pseudocodigo
DRC d;
El tiempo gastado en entender el origen de esta variable, su funcionamiento, su tipo de dato y sus
dependencias, se volverá a gastar cada que ocupemos un fragmento de código asociado con esta
variable y que se incrementara hasta no ser renombrada y documentada.
Los clientes esperan que los desarrolladores creen software mantenible y robusto, los
desarrolladores no deben engañarse en que el usuario busca sacrificar calidad y mantenibilidad
por tiempo de desarrollo.
La eliminación de la deuda técnica permite a un equipo aumentar su confianza en la medida en
que aumenta el rendimiento y mantenibilidad del software.
b) Realizar abonos a la deuda técnica que no afecten al plan del proyecto.
A veces al momento de codificar un requerimiento o durante la etapa de desarrollo de un
proyecto se encuentre deuda técnica. Si se toma el enfoque anterior de resolverlo de manera
inmediata, se perdería el foco de nuestra asignación actual y esto suena como demasiada
distracción que comprometerá los tiempos de entrega tan apretados.
Dado sea el caso ¿ qué acción se debe de tomar para disminuir la deuda técnica?
70
Podremos dejar comentarios con código de limpieza. Para que en futuras iteraciones sea corregido
ejemplos: ver fragmento de comentarios en Java o C++
//TO DO
// FIX ME
Pero eso sería como transferir la deuda técnica al final de cada iteración, y esto le veremos más
adelante.
En lugar de esto podemos lanzar excepciones en tiempo de ejecución localizadas
estratégicamente.
Veamos el siguiente fragmento de código java:
try { File toolTipConfigFile = new File(“C:/app/tooltip.config”); FileInputStream fis = new FileInputStream(toolTipConfigFile);
Properties toolTipProperties = new Properties(fis);
} catch (IOException ex) {
}
String debugVal = toolTipConfigFile.getProperty(“debug”);
Boolean debugTurnedOn = Boolean.parseBoolean(debugVal);
Como podemos ver el archivo de configuración se carga desde una ruta que está en código duro.
En lugar de esto podemos lanzar una excepción en tiempo de ejecución con una leyendo con la
posible solución.
String debugVal = toolTipConfigFile.getProperty(“debug”); Boolean debugTurnedOn = Boolean.parseBoolean(debugVal); throw new RuntimeException(“No cargar archivos desde rutas en código duro”); El usar esta técnica puede ser difícil ya que expone de inmediato la necesidad de resolver la deuda técnica. Puede ser que encuentre una alternativa a esto pero asegúrese de que se forcé el manejo de la deuda técnica y no se ignore. 20
c) Agregar el pago de la deuda técnica al final de la iteración del producto.
20 Managing Software Debt: Building for Inevitable Change, Chris Sterling, Addison Wesley
71
Desde el momento en que decidimos agregar la deuda técnica al final existe un riesgo de no ser tomada en cuenta. La siguiente es una lista de problemas que debemos de cuidar al momento de tomar la decisión.
Que todos los items de la deuda técnica sea priorizados como de severidad baja.
Demasiados items de deuda técnica son capturados como para ser manejados de manera efectiva.
La deuda técnica puede tomar más del tiempo de la iteración en ser solucionado.
Un gran número de items de deuda técnica pudieran ser excusa para que se hiciere un gran diseño a nivel macro y súper detallado.
Si la deuda técnica es sobreestimada es porque no se dio una suficiente explicación de la importancia de ser atacada, como para que fuera ignorada.
Es muy común que durante de principio veamos deuda técnica por todas partes. Cuando encontramos demasiada deuda técnica se vuelve inmanejable. Los miembros del equipo tienen que encontrar formas de filtrar y clasificar la deuda técnica.
La deuda técnica puede ser frustrante al momento de manejarla. Esta frustración nos puede llevar al hecho de generar un diseño que rehaga todo o la mayor parte del código. Es necesario no se incurra en esto y se tome con responsabilidad y realizar solo un diseño modular.
3.1.2.2 Cuantificación de la deuda técnica
Para la cuantificación de la deuda técnica existe un método basado en la norma ISO9126. Esta
metodología le da a la norma ISO un enfoque de calidad desde el punto de vista del impacto que
tiene la mala calidad en las operaciones del negocio.
Para ello tomaremos como método de cuantificación el método SQALE.
3.1.2.2.1 Antecedentes del método SQALE el Estándar ISO 9126
Se menciona a continuación el estándar ISO 9126 para dimensionar el origen del método SQALE. El
cual sigue los mismos principios.
El estándar está dividido en cuatro partes las cuales abordan respectivamente, el modelo de
calidad, las métricas externas, las métricas internas y la calidad en el uso de las métricas. El
modelo de calidad fue establecido en la primera parte del estándar, ISO 9126-1 y clasifica la
calidad del software en un conjunto estructurado de características y subcaracterísticas de la
siguiente manera:
Confiabilidad
Una vez que un sistema de software está funcionando, tal como se especifica. La
característica confiabilidad define la capacidad del sistema para mantener su prestación
de servicios en condiciones definidas por períodos de tiempo definidos. Un aspecto de
esta característica es que la tolerancia a fallos es la capacidad de un sistema para soportar
el fallo de uno o más componentes. Por ejemplo, si la red se cae durante 20 segundos y
luego regrese el sistema debe ser capaz de recuperarse y seguir funcionando.
72
Usabilidad
La Usabilidad sólo existe con respecto a la funcionalidad y se refiere a la facilidad de uso
para una función dada. Por ejemplo, una función de un cajero automático es para
dispensar efectivo a lo solicitado. La colocación de cantidades comunes en la pantalla de
selección, es decir, $ 20.00, $ 40.00, $ 100.00, etc, no afecta la función del cajero
automático, pero aborda la usabilidad de la función. La capacidad de aprender a utilizar un
sistema (capacidad de aprendizaje) es también un importante subcaracterística de
usabilidad.
Eficiencia
Esta característica se refiere a los recursos del sistema utilizados en la prestación de la
funcionalidad requerida. La cantidad de espacio en disco, memoria, red, etc. ofrece una
buena indicación de esta característica. Al igual que con un número de estas
características, hay solapamientos. Por ejemplo, la facilidad de uso de un sistema se ve
influida por el rendimiento del sistema, en la que si un sistema tarda 3 horas para
responder el sistema no sería fácil de usar aunque la cuestión esencial es una
característica de rendimiento o eficiencia.
Mantenibilidad
La capacidad de identificar y corregir un fallo en un componente de software es lo que las
direcciones característicos mantenibilidad. En otros modelos de calidad del software de
esta característica se hace referencia como compatibilidad. Mantenibilidad es impactado
por la legibilidad de código o complejidad, así como la modularización. Cualquier cosa que
ayude a identificar la causa de una avería y después de arreglar la falla es la preocupación
de mantenimiento. También la capacidad de verificar (o prueba) un sistema, es decir, la
capacidad de prueba, es una de las subcaracterísticas de mantenimiento.
Portabilidad
Esta característica se refiere a lo bien que el software puede adoptar a los cambios en su
entorno o con sus requisitos. Las subcaracterísticas de esta característica incluyen
adaptabilidad. Orientados a objetos de diseño e implementación prácticos pueden
contribuir a la medida en que esta característica está presente en un sistema dado.
73
Figura 30. Imagen de la Norma ISO/IEC 25000:2005 (Elaboración Propia)
3.1.2.2.2 Definición del Método SQALE
El método SQALE se usa para formular y organizar los requerimientos no funcionales relacionados
a la calidad del código. Esta organizado en tres niveles jerárquicos. El primer nivel está compuesto
de características el segundo de subcaracterísticas y el último de requerimientos.
3.1.2.2.2.1 Nivel de Características
SQALE cuenta con ocho niveles de calidad, estas características son habilidades resultado del
estándar ISO 9126. Estas fueron seleccionados por que depende de las propiedades internas del
código y por otra parte el impacto a las actividades típicas del ciclo de vida del software. Además
agrega la característica de reusabilidad que no aparece en el estándar.
3.1.2.2.22 Nivel Subcaracteristicas
Cada característica es descompuesta en subcaracterísticas. Las subcaracterísticas son usadas para
combinar los requerimientos en grupos de mediano tamaño, por lo tanto el análisis a profundidad
puede ser llevado a cabo. Un subcaracterísticas solo le corresponde a una y solo una
característica.
A continuación se muestra un ejemplo de la distribución de una característica en
subcaracterísticas.
Confiabilidad
Usabilidad
Eficiencia Mantenibilidad
Portabilidad
74
Tabla Ejemplo de niveles 1 y 2 de un Modelo de Calidad SQALE
Característica Subcaracterística
Reutilización Extractabilidad
Reutilización Concisión
Reutilización Estabilidad
Portabilidad Portabilidad relacionada Idioma
Portabilidad Portabilidad zona relacionada Tiempo
Portabilidad La portabilidad de hardware
Portabilidad Portabilidad relacionada aplicación externa
Portabilidad La portabilidad del compilador relacionados
Portabilidad Portabilidad relacionados OS
Mantenibilidad Comprensibilidad
Mantenibilidad Legibilidad
Seguridad Relacionados con la seguridad del sistema operativo
Seguridad Relacionados con la seguridad del usuario
Seguridad Declaración de la seguridad relacionada
Eficiencia Eficiencia relacionados ROM
Eficiencia Eficiencia relacionados RAM
Eficiencia Eficiencia relacionados CPU
Mutabilidad Arquitectura relacionados mutabilidad
Mutabilidad Lógica mutabilidad relacionados
Mutabilidad Los datos relacionados con la variabilidad
75
Característica Subcaracterística
Confiabilidad La tolerancia a fallos
Confiabilidad Arquitectura relacionados confiabilidad
Confiabilidad Confiabilidad Recursos relacionados
Confiabilidad Relacionada con la sincronización confiabilidad
Confiabilidad Confiabilidad relacionada Declaración
Confiabilidad Confiabilidad relacionados Lógica
Confiabilidad Los datos relacionados con la confiabilidad
Comprobabilidad Pruebas de Integración capacidad de prueba
Comprobabilidad Unidad de Pruebas capacidad de prueba
3.1.2.2.3 Nivel Requerimientos.
Este nivel del modelo contiene todos los requerimientos relacionados con el alcance de la calidad
dependiente del lenguaje de programación usado.
Cada uno de los requerimientos deberá ser usado al más bajo niveles posible en relación con la
característica en la que está relacionada.
Cabe destacar, que el método SQALE menciona que el nivel de requerimientos es descriptivo y
será definido en base a las necesidades y expectativas de cada proyecto y organización.
Tabla 5. Niveles SQALE para el lenguaje Java.
CARACTERÍSTICA SUBCARACTERÍSTICA REQUISITO DE DESCRIPCIÓN GENÉRICO
Mantenibilidad Comprensibilidad No hay declaraciones no estructuradas (goto, break outside a switch)
Mantenibilidad Comprensibilidad Ningún uso de "continuar" declaración dentro de un bucle
Mantenibilidad Comprensibilidad Archivo comentario relación (COMR)> 35%
Mantenibilidad Legibilidad Inicio Nombre de la variable con una letra minúscula
Mantenibilidad Legibilidad La llave de cierre "} 'está en una línea independiente
Mantenibilidad Legibilidad El código de seguir las reglas de sangría consistente
Mantenibilidad Legibilidad Tamaño del archivo (LOC) <1000
Mantenibilidad Legibilidad Sin código comentado de salida
Eficiencia RAM eficiencia relacionada Profundidad Clase de sucesiones (DIT) <8
Eficiencia RAM eficiencia relacionada Ninguna variable no utilizada, el parámetro o constante en el código
76
Mutabilidad Arquitectura relacionados mutabilidad Complejidad Clase ponderada (WMC) <100
Mutabilidad Arquitectura relacionados mutabilidad Especificación de clase no contiene datos públicos
Mutabilidad Lógica mutabilidad relacionados Si, de lo contrario, ya que, mientras que las estructuras están obligados por alcance
Mutabilidad Los datos relacionados con la variabilidad No hay constantes explícitos utilizados directamente en el código (excepto 0,1, Verdadero y Falso)
Confiabilidad Tolerancia a fallos Interruptor de la declaración tiene una "condición predeterminada '
CARACTERÍSTICA SUBCARACTERÍSTICA REQUISITO DE DESCRIPCIÓN GENÉRICO
Confiabilidad Lógica relacionada con la confiabilidad Sin asignacion '=' dentro 'if'
Confiabilidad Lógica relacionada con la confiabilidad Sin asignacion '=' dentro ', while' declaración
Confiabilidad Lógica relacionada con la confiabilidad Índice iteración Invariante
Confiabilidad Los datos relacionados con la confiabilidad Sin uso de variables no inicializado
Comprobabilidad La capacidad de prueba de nivel de
integración No "Swiss Army Knife" anti patrón de clase
Comprobabilidad La capacidad de prueba de nivel de
integración El acoplamiento entre objetos (CBO) <7
Comprobabilidad Unidad de pruebas capacidad de prueba Ninguna parte duplicado más de 100 contadores
Comprobabilidad Unidad de pruebas capacidad de prueba Número de ind. caminos de prueba dentro de un módulo (v (G)) <11
Comprobabilidad Unidad de pruebas capacidad de prueba Número de parámetros en una llamada de módulo (NOP) <6
3.2 Calculo de costos de la mala calidad.
El método SQALE exige que el cálculo de la deuda técnica sea el resultado de penalizar cada una
de las violaciones a los requerimientos de calidad por un factor de remediación y también por un
factor que penalice su costo de no remediación.
3.2.1 Costos de remediación
La cantidad de esfuerzo necesario para remediar las violaciones al código fuente expresado en
horas hombre es el factor de remediación. Ver Figura 6
3.2.2 Costos de No remediación
El costo de la no remediación es la cantidad de esfuerzo que una organización tendrá que pagar
por no solucionar una violación a un requerimiento de calidad. La unidad de medida es variable de
acuerdo a cada organización será en horas que detiene la operación.
El interés o costo total de la deuda técnica es el resultado de sumar todos los costos de
remediación entre los costos de la no remediación.
77
Capítulo 4 Herramientas para la medición de la deuda técnica
4.1 Breve introducción
Este capítulo muestra algunas herramientas que miden cada una de las características,
subcaracterísticas y requerimientos de los niveles de la metodología SQALE, al final del mismo se
presenta la evaluación de las mismas.
Para la implementación del método SQALE se requiere de herramientas que lo soporten, algunas
herramientas disponibles al momento la escritura del trabajo las siguientes herramientas son las
existentes en el mercado:
SonarQube (by SonarSource)
SQuORE (by SQuORING)
Mia-Quality (by Mia-Software )
4.1.4 Herramienta SonarQube21 Tiene una forma muy eficiente de navegar, un equilibrio entre la visión de alto nivel, tablero de
control, línea de tiempo y herramientas de análisis de código estático para la detección
automática de errores. Esto permite descubrir rápidamente los proyectos y / o componentes que
están en deuda técnica para establecer planes de acción.
La herramienta ofrece numerosas características para realizar un proceso de inspección continua.
SonarQube es una plataforma abierta en la web para gestionar la calidad del código.
SonarQube añade motores de reglas, métricas avanzadas que se puede hacer a través de un
mecanismo de extensión de gran alcance. Cuenta con más de 50 plugins.
Características.
Gestión del código
- Se gestiona la calidad del código se evalua a nivel de archivo, módulo, proyecto o paquete ,
numerosos cuadros de mando de SonarQube ofrecen una visión rápida.
Soporte de lenguajes
- Soporta los lenguajes de Java, C #, C / C ++, COBOL, PL / SQL, ABAP, Javascript, PHP, Web, XML,
CSS, Erlang, Flex / ActionScript. La plataforma también ofrece la posibilidad de añadir sus propias
reglas en esos idiomas.
Comprobación de código fuente
21 SonarSource S.A. (2008). Características. 06/06/2015, de SonarQube Sitio web: http://www.sonarqube.org/features/
78
- El código fuente se puede comprobar antes de realizar cambios al SCM, ya sea directamente en
Eclipse, IntelliJ IDEA o a través de un lote con la capacidad de obtener los temas en el modo de
vista previa.
Seguridad
- Cuenta con un mecanismo completo para la autenticación y autorización, pero también es
posible delegar la seguridad a un sistema externo tal como LDAP, Active Directory, etc.
Línea de tiempo
- Existen varios métodos para reproducir la evolución de las métricas: tablas, líneas de tiempo,
gráficos dinámicos, etc. Esto asegurará el progreso que se pretende conseguir y un seguimiento en
el tiempo.
Inspeccion detalla de la fuente
- Un proyecto, grupo de proyectos se pueden descomponer para acceder a cualquier métrica en
unos pocos clics, y profundizar con la fuente de la información: el código fuente.
Hay varios tipos diferentes de la página en la GUI SonarQube:
Cuadro de instrumentos:
o Cuadros de mando globales muestran datos de alto nivel (nivel de instancia)
o Cuadros de mando del proyecto se muestran los datos del proyecto
Visor de componentes muestra información detallada sobre los componentes
Navegación y gestión: cuestiones, medidas, reglas, perfiles de calidad, etc.
Configurable
o Configuración del sistema para los administradores de sistemas que permite
administrar la instancia SonarQube
o Configuración del proyecto para los administradores de proyectos para configurar
sus ajustes del proyecto (configuración de las propiedades de análisis, la creación
de planes de acción )
A continuación se describen los cinco niveles de cuantificación de errores en el código fuente.
NOMBRE DEL NIVEL
DESCRIPCIÓN
Blocker Erro con alta impacto en el comportamiento de la aplicación en la producción de: pérdida de memoria, conexión JDBC sin cerrar.
Critical Un error con una probabilidad baja para afectar el comportamiento de la
79
aplicación en la producción o un tema que representa una falla de seguridad: bloque catch vacío, inyección SQL.
Major Defecto de calidad que puede tener un impacto altamente la productividad de los desarrolladores: pieza descubierta de código, los bloques duplicados, los parámetros utilizados
Minor Defecto de calidad que puede afectar ligeramente la productividad de los desarrolladores: las líneas no deben ser demasiado largas, las declaraciones "switch" deben tener al menos 3 casos
Info Ni un error ni un defecto de calidad, sólo un hallazgo Tabla 7. Niveles de gravedad para la clasificación de errores.
Ejemplo de un tablero de control para la herramienta SonarQube, mostrando la cantidad de
errores su clasificación y el tiempo de remediación de los mismos.
Figura 32. Imagen que muestra los errores potenciales
Licencia:
Licencia Propietaria.
Costo:
2700 euros.
80
Figura 32.1 Costo de la Licencia
4.1.5 Herramienta SQuORE22 SQuORE es una herramienta de inteligencia de Negocios para el control de los proyectos y
sistemas de software que proporciona indicadores de gestión pertinente y utilizable evaluando el
nivel de calidad con un control adecuado, ya sea en el desarrollo de las fases, adquisición o
mantenimiento.
22 SQUORING Technologies. (2015). Squore. 06/06/2015, de SQUORING Technologies Sitio web: http://www.squoring.com/en/produits/tableau-de-bord-squore/
81
Figura 39. Squore implementa los conceptos de Inteligencia de Negocio para la gestión de proyectos.
Características
o Evaluación objetiva y adaptable
- Un conjunto predefinido de métricas e indicadores de apoyo a modelos de evaluación de
desempeño reconocidas, relacionadas con limitaciones industriales o normativas (por ejemplo, ISO
9126, SQALE)
- Ofrece la posibilidad de personalizar o integrar los indicadores para su organización, alineados
con sus objetivos estratégicos
o Tablero de colaboración
- SQuORE ofrece una tabla de funciones múltiples para la difusión selectiva de indicadores
- Un cuadro de mandos intuitivo: gráficos, drill down y capacidades de filtrado para acceder a la
información pertinente
- Generación de informes en un formato estandarizado de modelos configurables, para impartir
una selección de datos seleccionado a los socios, clientes, terceros y organismos de certificación
82
- Una interfaz web segura para una fácil implementación y difusión de información accesible a las
partes interesadas
- Una aplicación móvil para el acceso a la información clave
o Toma de decisión rápida y fiable
- Una toma de decisiones basada en datos fiables y actualizados en tiempo real a través de los
mecanismos de integración continua
- Generación automática de planes de acción basados en el motor de decisión de gran alcance, con
criterios configurables por el usuario: la selección de los defectos más críticos para construir el
"Todo-list" ideal y exportación de sistemas de gestión de cambios "atraso" de los desarrolladores,
etc.
- Análisis de tendencias y el control estadístico de procesos (SPC): la detección inmediata de
violaciones y regresiones de versiones anteriores
- Estadísticas y datos descriptivo de modelado: Capitalización de datos de proyectos anteriores
para establecer correlaciones entre los atributos del producto (por ejemplo, la complejidad) y las
características de calidad externos (por ejemplo, confiabilidad)
Subcaracterísticas de SQuORE
o Medios de acción por la producción de indicadores de desempeño
- Un estado integral, objetivo y en tiempo real de sus proyectos
- Control optimizado basado en un seguimiento de sus indicadores de desempeño
- Controla las prioridades
o La confiabilidad de la evolución y la reducción de costes de mantenimiento
- Vigilancia objetiva y en tiempo real del cumplimiento de las características, desarrollos previstos
y los requisitos de las normas de calidad
- La reducción del ciclo correcciones mediante la identificación de los primeros casos de
incumplimiento y regresiones
- La reducción de las revisiones finales y costosas
- El dominio de su deuda técnica
83
o La satisfacción del cliente final
- A contratación de sus requisitos técnicos
- Los criterios de aceptación claramente establecidas, las metas, y compartido con los equipos
encargados de desarrollar sus proyectos
- La reducción de sus tiempos y costos de recetas
- Entregables que cumplen con los requisitos de calidad del producto
o Mayor colaboración entre las partes interesadas
- La colaboración facilitada por una visión global y objetiva de los productos y procesos,
compartida por todos
- Un ahorro de las decisiones tomadas por el enfoque en los indicadores más significativos de
tiempo
- La adopción consensuada de los planes de remediación más adecuados
o Mejora de procesos continuos
- Mejor control a través de indicadores y las lecciones del pasado, los procesos ganan capacidad,
madurez y rendimiento.
- Se promueve la difusión y adopción de las mejores prácticas dentro de su organización a través
de un repositorio común y una herramienta compartida por todas las partes interesadas
Puede integrar todos los tipos de datos por su mecanismos de ETL (Extract / Transformar / Load).
Por lo tanto, cualquiera que sea la etapa del proyecto, SQuORE agrega sus propias mediciones con
datos de todas sus herramientas ya en su entorno, para proporcionar una visión completa y
sintética de sus productos y procesos de software y sistemas.
Licencia:
Licencia Propietaria.
Costo:
No Específica, es necesario pedir una demostración en sitio.
4.1.6 Herramienta Mia-Quality Mia-Quality es una solución de análisis de la calidad del software que se ocupa de los lenguajes
principales de desarrollo y se adapta al análisis de acuerdo con las necesidades específicas del
cliente.
84
Después de definir un modelo que se ajuste a sus problemas de calidad, el usuario puede ver los
resultados del análisis en una SonarQubeTM portal web intuitivo y ergonómico. Mia-Quality ofrece
indicadores macroscópicos para la dirección y luego desciende al código de la aplicación para
tener una presentación detallada y los indicadores aplicados.
Mia-Quality es totalmente compatible con los estándares de calidad ISO9126 y también
implementa el método SQALE.
El proceso de análisis de calidad se ejecuta en tres fases consecutivas:
o La definición de indicadores y estándares de calidad que deben cumplir
o Análisis automático de los activos de aplicaciones
o Resultados de visualización y archivo
Figura 40. Arquitectura de Mia Software Quality 1
Las medidas de calidad se aplican al código fuente, sino también para proyectar la información de
seguimiento, solicitudes de mantenimiento y los incidentes de producción. Para ello, muchos
conectores están disponibles.
El análisis está disponible para muchos idiomas y entornos. Esta cadena de análisis es
personalizable, escalable y basada en modelos estándar de calidad (ISO9126, SQALE).
85
Una vez que el modelo de calidad desarrollado, Mia-Quality genera automáticamente el plug-in
que muestra los resultados consolidados en un portal web Sonar.
Características
La medición de la calidad del código de la aplicación se basa en
o Métrica estándar
o Un control estándar específico a cada contexto
Modelo de calidad Mia-Quality es totalmente parametrizado
o El usuario puede crear y modificar sus normas de calidad
o La implementación de los modelos estándar ISO9126 y SQALE
Una complemento en el portal Sonar basado en la web o Cuadros de mando personalizados
o Navegación general para el individuo (profundizar)
o Resultados de registro
Licencia:
Licencia Propietaria.
Costo:
No Específica, es necesario pedir una demostración en sitio.
A continuación se muestra el resultado de la comparación de las herramientas con soporte SQALE.
País Soporte
SQALE
Licencia Costo
SonarQube Suiza 100% Propietaria € 2,700
Squore Francia 100% Propietaria No Específica
Mia-Quality Francia 100% Propietaria No Específica
Tabla Comparativa Herramientas SQALE
86
4.2 Conclusiones sobre las herramientas. Las tres herramientas antes mencionadas cumplen con el cálculo de la deuda técnica bajo el
método SQALE. Todas cuentan con documentación técnica y de usuario final. Todas las anteriores
cuentan con reportes detallados por portfolio de aplicaciones por aplicación, por paquetes o por
archivo de código fuente. Todas cuentan con una configuración amigable y fácil adaptación de los
analizadores de código fuente que recolectaran las métricas en el código.
Sin embargo ninguna permite su uso gratuito y las herramientas de evaluación tienen restricciones
de cantidad de KSLOC para analizar.
Por ello se propone el desarrollo de archivos batch que automaticen y lance las tareas de análisis
de código estático, que cuente la cantidad de líneas de código y deposite la salida de estos cálculos
en formato para su cómputo final
87
Capítulo 5 El método SQALE adaptado y las herramientas de
experimentación. En este capítulo se definirá el conjunto de característica, subcaracterísticas y requerimiento a
evaluar en el código fuente de un sistema bancario así como las herramientas que lo evaluaran.
5.1.1 Sistema bancario a evaluar. Para el desarrollo del experimento se eligió un sistema bancario que fue desarrollado bajo la
plataforma Java 6 y base de datos Oracle 10g.
Sistema Bancario “X”
Por razones de confidencialidad con la institución financiera se ha omitido el nombre del sistema
así como la referencia a la misma institución.
El sistema bancario avala total o parcialmente el pago de capital o intereses relativo a la emisión
de papel comercial, certificados bursátiles o cualquier otro instrumento utilizado en el mercado de
valores nacional o extranjero. Resguarda la garantía bursátil permitiendo mejorar la calificación
que asignan las calificadoras a las emisiones bursátiles, que buscan financiar operaciones de
equipamiento, proyectos de desarrollo tecnológico, creación y desarrollos de infraestructura,
mejoramiento ambiental, reestructuración de pasivos y bursatilización de activos (cuentas por
cobrar, pagarés, remesas, hipotecas, entre otros).
5.2 Adaptación de la Lista de Características SQALE
De acuerdo a lo que menciona la metodología SQALE es posible considerar ciertas características
como no aplicables siempre que el contexto lo justifique. En este caso, las subcaracterísticas y
requisitos asociados se eliminan del Modelo de Calidad. Por lo tanto, se tomarán en consideración
las siguientes características para el caso de estudio:
o Maintainability (Mantenibilidad)
o Reliability (Confiabilidad)
o Testability (Comprobabilidad)
Para cualquiera de los artefactos del código fuente el costo de remediación se puede estimar
mediante la suma de todos los costos de remediación relacionados con las no conformidades
detectadas que se observaron con respecto a los requisitos vinculados a la característica.
5.2.1 Características SQALE a Evaluar
Para este caso de estudio solo se tomaran las tres primeras características del método SQALE que
marca como obligatorias. Ya que para poder evaluar las ocho características del método es
88
necesario que la organización muestre un nivel de madurez en el desarrollo de software y que den
seguimiento a estándares y normas de calidad. Ver Figura 41
Las tres características que se utilizaran para los experimentos
Índice Comprobabilidad se define como: SCTI = STI
Índice Consolidado Confiabilidad: SCRI = STI + SRI
Índice Consolidad Mantenibilidad: SCMI = STI + SRI + SCI
El uso y la interpretación de estos índices consolidados se utilizan para alimentar el indicador
"SQALE Pirámide"
3 Figura de Características SQALE elegidas.
Para cada una de las características antes seleccionadas es necesario elegir las subcaracterísticas
que los definen en la siguiente tabla se esquematizan.
Mantenibilidad
Confiabilidad
Comprobabilida
89
Tabla 13. Muestra las subcaraterísticas que serán evaluadas en el código fuente
Comprobabilidad Confiabilidad Mantenibilidad
Exista Prueba Unitaria por cada clase de java tipo Data Acces
Object Básica Uso de Comentarios
Exista Prueba Unitaria por cada clase Java tipo Servicio
J2ee Nomenclatura estilo JavaBeans
Optimizaciones Código Innecesario
Manejo de cadenas Código Sin Uso
Resolución de Tipos de Datos Uso de Corchetes
Manejo de Cadenas Acoplamiento entre Clases
Tamaño del Código Código duplicado
Condigo Controvertido
5.2.1.1 Cálculo de costos
El método SQALE exige que el cálculo de la deuda técnica sea el resultado de penalizar las cad a
una de las omisiones a los requerimientos de calidad con un factor de remediación y también por
el consto de su no remediación.
3.2.2.1.1 Costos de remediación:
La cantidad de esfuerzo necesario para remediar las violaciones al código fuente expresado en
horas hombre es el factor de remediación. Ver Figura 6
3.2.2.1.2 Costos de No remediación
El costo de la no remediación es la cantidad de esfuerzo que una organización tendrá que pagar
por no solucionar una violación a un requerimiento de calidad. La unidad de medida es variable de
acuerdo a la que cada organización decida para este caso de estudio será en horas que detiene la
operación. Ver Figura 7
90
El interés o costo total de la deuda técnica es el resultado de sumar todos los costos de
remediación entre los costos de la no remediación.
COSTO DE REMEDIACIÓN
Tipo Descripción Ejemplo Factor de remediación
1 Corregible con una herramienta automática, no hay riesgo
Cambio de carácter. 0.05
2 Remediación Manual , pero no influye en la compilación
Agregue un poco de comentarios 0.5
3 Impacto local , sólo necesita las pruebas unitarias
Reemplazar una instrucción por otra
1
4 Impacto medio , necesitan pruebas de integración
Cortar una gran función en dos 8
5 Gran impacto , necesitan una validación completa
Cambie dentro de la arquitectura 40
Tabla Costos de remediación
COSTO DE NO REMEDIACIÓN
Tipo Descripción Ejemplo Factor de No remediación
Bloqueo
Será o puede dar lugar a un bug División por cero 40
Alto Tiene un impacto alto / directo en el costo
mantenimiento Copiar y pegar 8
Medio
Tendrá un impacto potencial / impacto medio sobre el costo de mantenimiento
Lógica compleja 1
Bajo Tendrá un bajo impacto en el costo mantenimiento Convenio de
denominación 0.5
Informe
Muy bajo impacto , es sólo un informe de costos de remediación
Tema de Presentación
0.05
Tabla Costos de No remediación
91
5.2.1.2 Testability (Comprobabilidad)
Antes de tomar en consideración la confiabilidad del código, su rendimiento, su seguridad, su
capacidad de mantenimiento por parte de terceros, etc. Se debe tener en cuenta su capacidad de
prueba y cumplir con los requisitos correspondientes.
Si el código no es comprobable (eso significa que es demasiado complejo, demasiado acoplado),
no se tendrá la capacidad de probar adecuadamente antes de la entrega. No se podrá ser capaz de
controlar y mejorar su confiabilidad y seguridad. Cuando se realicen cambios y mantenimiento
correctivo por medio de una su solicitud, no se podrá probar y comprobar correctamente el
trabajo.
Esto lleva a la conclusión de que la capacidad de prueba es la base sobre la cual todas las otras
características de calidad se sustentan.
Si se desea mejorar la calidad general de una aplicación, se debe empezar por la mejora de su
capacidad de prueba. Eso significa refactorización su arquitectura y su estructura interna con el fin
de que sean completamente comprobables.
A continuación las subcaracterísticas a evaluar para la comprobabilidad así como su costo de
remediación y no remediación. Ver Tabla 8
4 Costos de remediación y no remediación para Comprobabilidad
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Pruebas Unitarias Prueba Unitaria para Clase Java Obligatoria 5 50
5.2.1.3 Mantenibilidad (Maintainability )
El índice de mantenibilidad representa el costo de remediación para los requisitos directamente
vinculados a la mantenibilidad. Pero para que una aplicación de software sea capaz de ser
fácilmente mantenido en su fase de funcionamiento, tiene que ser verificable, confiable y
actualizable. Por lo tanto, es el Índice de mantenimiento consolidado que representa mejor el
estado del software en relación con ese objetivo.
A continuación se muestran la subcaracterísticas, el requerimiento o regla a cumplir junto con el
costo de corregirla y el costo de no corregirla y por ende perjudicar al negocio.
92
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Copiar Pegar Código duplicado 40 8
Comentarios Comentario Obligatorio 0.5 0.05
Comentarios Tamaño del Comentario 0.5 0.05
Comentarios Contenido del Comentario 0.5 0.05
JavaBeans Los miembros deben ser serailizados 0.5 0.05
JavaBeans Falta SerialVersionUID 0.05 0.05
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Innecesario UnnecessaryConversionTemporary 1 0.05
Innecesario UnnecessaryReturn 1 0.05
Innecesario UnnecessaryFinalModifier 1 0.05
Innecesario UselessOverridingMethod 1 0.5
Innecesario UselessOperationOnImmutable 1 1
Innecesario UnusedNullCheckInEquals 0.5 0.5
Innecesario UselessParentheses 0.05 0.05
Código sin Uso UnusedPrivateField 0.5 0.5
Código sin Uso UnusedLocalVariable 0.5 0.5
Código sin Uso UnusedPrivateMethod 0.5 0.5
Código sin Uso UnusedFormalParameter 0.5 0.05
Código sin Uso UnusedModifier 0.5 0.05
93
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Corchetes IfStmtsMustUseBraces 0.05 0.05
Corchetes WhileLoopsMustUseBraces 0.5 0.05
Corchetes IfElseStmtsMustUseBraces 0.5 0.05
Corchetes ForLoopsMustUseBraces 0.5 0.05
5.2.1.4 Reliability (Confiabilidad)
La confiabilidad se enfoca en el código, y consiste en determinar los objetivos de calidad para la
aplicación que va a ser desarrollada. Estos objetivos son, por ejemplo una gran confiabilidad y una
buena calidad para las características del código fuente.
Si la organización no tiene un Modelo de Calidad semejante a SQALE, se desarrolla una adaptación
del mismo que enumera todos los requisitos relativos a la calidad del código.
Los requisitos relativos a la calidad del código se deberán especificar en el contrato. Esto da lugar a
tener en consideración los siguientes elementos:
o Especificar de acuerdo al modelo de calidad SQALE lo que se utiliza como referencia ( es
decir, los requisitos precisos para el lenguaje utilizado )
o Las funciones de remediación se utilizan para calcular índices.
o Los umbrales de destino para diferentes densidades de índice en acuerdo con los objetivos
fijados
Por ejemplo, si el tamaño se expresa en KSLOC (miles de líneas de código fuente) y si la
confiabilidad es un requisito fuerte
STID < 0.1
SRID < 0.1
Otras características SQALE para índices de densidades
o Durante el transcurso del proyecto, se informa el valor de los distintos indicadores en el
momento de las reuniones del comité de dirección con el fin de asegurar al cliente que se
cumplirán los objetivos de calidad del código.
o En el momento de la entrega del proyecto, se deben proporcionar los resultados del
análisis para establecer que se han alcanzado los umbrales de acuerdo a lo que se
estableció en el contrato.
o Si es necesario, en el momento de la prueba de aceptación, la organización comprueba
con sus propias herramientas que se cumplen con los requisitos que se establecieron en el
contrato
94
Subcaracterísticas Requerimiento Costo de
remediación Costo de no remediación
Basic JumbledIncrementer 8 0.5
Basic ForLoopShouldBeWhileLoop 1 0.05
Basic OverrideBothEqualsAndHashcode 1 0.05
Basic DoubleCheckedLocking 1 0.05
Basic ReturnFromFinallyBlock 8 0.5
Basic UnconditionalIfStatement 1 0.05
Basic BooleanInstantiation 0.5 0.05
Basic CollapsibleIfStatements 0.5 0.5
Basic ClassCastExceptionWithToArray 8 40
Basic AvoidDecimalLiteralsInBigDecimalConstructor 1 0.5
Basic MisplacedNullCheck 1 0.5
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Basic AvoidThreadGroup 1 0.5
Basic BrokenNullCheck 8 40
Basic BigIntegerInstantiation 1 0.05
Basic AvoidUsingOctalValues 0.5 0.05
Basic AvoidUsingHardCodedIP 0.5 40
Basic CheckResultSet 1 0.5
Basic AvoidMultipleUnaryOperators 8 0.5
Basic ExtendsObject 1 0.05
Basic CheckSkipResult 8 0.05
95
Subcaracterísticas Requerimiento Costo de
remediación Costo de no remediación
Basic AvoidBranchingStatementAsLastInLoop 0.5 40
Basic DontCallThreadRun 8 1
Basic DontUseFloatTypeForLoopIndices 1 0.5
J2EE UseProperClassLoader 8 0.5
J2EE MDBAndSessionBeanNamingConvention 0.5 0.05
J2EE RemoteSessionInterfaceNamingConvention 0.5 0.05
J2EE LocalInterfaceSessionNamingConvention 0.5 0.05
J2EE LocalHomeNamingConvention 0.5 0.05
J2EE RemoteInterfaceNamingConvention 0.5 0.05
J2EE DoNotCallSystemExit 0.5 40
Subcaracterísticas Requerimiento Costo de
remediación Costo de no remediación
J2EE StaticEJBFieldShouldBeFinal 0.5 0.05
J2EE DoNotUseThreads 50 1
Optimización LocalVariableCouldBeFinal 0.5 0.05
Optimización MethodArgumentCouldBeFinal 0.5 1
Optimización AvoidInstantiatingObjectsInLoops 1 0.05
Optimización UseArrayListInsteadOfVector 1 0.5
Optimización SimplifyStartsWith 0.5 0.5
Optimización UseStringBufferForStringAppends 0.5 0.5
Optimización UseArraysAsList 0.5 0.5
Optimización AvoidArrayLoops 1 0.5
Optimización UnnecessaryWrapperObjectCreation 1 0.05
Optimización AddEmptyString 0.5 0.05
Optimización RedundantFieldInitializer 0.5 0.05
Optimización PrematureDeclaration 0.5 0.05
96
String and StringBuffer AvoidDuplicateLiterals 0.5 0.05
String and StringBuffer StringInstantiation
String and StringBuffer StringToString 0.05 0.05
String and StringBuffer InefficientStringBuffering 1 0.5
String and StringBuffer UnnecessaryCaseChange 0.5 0.05
String and StringBuffer UseStringBufferLength 0.5 0.05
String and StringBuffer AppendCharacterWithChar 0.5 0.05
String and StringBuffer ConsecutiveAppendsShouldReuse 0.5 0.05
String and StringBuffer ConsecutiveLiteralAppends 0.5 0.5
String and StringBuffer UseIndexOfChar 0.5 0.05
String and StringBuffer InefficientEmptyStringCheck 0.5 0.05
String and StringBuffer InsufficientStringBufferDeclaration: 0.5 0.05
String and StringBuffer UselessStringValueOf: 0.5 0.05
String and StringBuffer StringBufferInstantiationWithChar 0.5 0.05
String and StringBuffer UseEqualsToCompareStrings 0.5 0.05
Subcaracterísticas Requerimiento Costo de
remediación
Costo de no remediación
String and StringBuffer
AvoidStringBufferField 0.5 0.05
Type Resolution LooseCoupling: 0.5 0.05
Type Resolution CloneMethodMustImplementCloneable 1 0.05
Type Resolution UnusedImports: 0.5 0.05
Type Resolution SignatureDeclareThrowsException 1 0.5
Strict Exceptions AvoidCatchingThrowable 1 0.05
Strict Exceptions SignatureDeclareThrowsException 0.5 0.05
Strict Exceptions ExceptionAsFlowControl 1 0.5
Strict Exceptions AvoidCatchingNPE 1 0.5
Strict Exceptions AvoidThrowingRawExceptionTypes 1 0.5
Strict Exceptions AvoidThrowingNullPointerException 8 1
Strict Exceptions AvoidRethrowingException 1 0.5
97
Strict Exceptions DoNotExtendJavaLangError 1 0.05
Strict Exceptions DoNotThrowExceptionInFinally 0.5 0.05
Strict Exceptions AvoidThrowingNewInstanceOfSameExceptio
n 0.5 0.05
Strict Exceptions AvoidCatchingGenericException 0.5 0.05
Strict Exceptions AvoidLosingExceptionInformation: 1 0.5
Code Size NPathComplexity 0.5 0.5
Code Size ExcessiveMethodLength 0.5 0.05
Code Size ExcessiveParameterList 0.5 0.05
Code Size ExcessiveClassLength: 0.05 0.05
Code Size CyclomaticComplexity 8 0.5
Code Size StdCyclomaticComplexity 8 0.5
Code Size ModifiedCyclomaticComplexity 8 0.5
Code Size ExcessivePublicCount 8 0.5
Code Size TooManyFields 0.05 0.05
Code Size NcssMethodCount 0.05 0.05
Code Size NcssTypeCount 0.05 0.05
Code Size NcssConstructorCount 0.05 0.05
Subcaracterísticas Requerimiento Costo de remediación Costo de no remediación
Code Size TooManyMethods 8 1
Controversial UnnecessaryConstructor 1 0.05
Controversial NullAssignment 1 0.05
Controversial OnlyOneReturn 1 0.05
Controversial AssignmentInOperand 0.5 0.05
Controversial AtLeastOneConstructor 0.5 0.05
Controversial DontImportSun 0.05 0.05
Controversial SuspiciousOctalEscape 0.5 0.05
Controversial CallSuperInConstructor 1 0.05
Controversial UnnecessaryParentheses 0.05 0.05
Controversial DefaultPackage 0.05 0.05
98
Controversial DataflowAnomalyAnalysis 1 0.05
Controversial AvoidFinalLocalVariable 0.05 0.05
Controversial AvoidUsingShortType 0.5 0.05
Controversial AvoidUsingVolatile 0.5 0.05
Controversial AvoidUsingNativeCode 0.5 0.05
Controversial AvoidAccessibilityAlteration 0.5 0.05
Controversial DoNotCallGarbageCollectionExplicitly 1 0.05
Controversial OneDeclarationPerLine 0.5 0.05
Controversial AvoidPrefixingMethodParameters 0.5 0.05
Controversial AvoidLiteralsInIfCondition 0.5 0.05
Controversial UseObjectForClearerAPI 8 1
Controversial UseConcurrentHashMap 0.5 0.05
Todas la tablas anteriores son el
5.3 Herramientas para Validar las Características En esta sección se definirán las herramientas que buscaran las violaciones a los requerimientos de
calidad del código fuente por cada característica.
5.4.1 Herramienta para determinar la comprobabilidad del código. JUnit permite realizar las pruebas sobre las clases de manera controlada para saber si cada uno de
los métodos de una clase funciona como se espera.
Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase
cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó
exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método
durante la ejecución, JUnit devolverá un fallo en el método correspondiente.
JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del
código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos
anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.
Se muestra un pequeño ejemplo que muestra cómo escribir una prueba unitaria.
Clase a probar.
pública clase Calculadora { pública int evaluar ( Cadena expresión ) { int suma = 0 ;
99
para ( Cadena sumando : la expresión . split ( " \\ + " )) suma + = Entero . valueOf (sumando); retorno suma; } }
Prueba Unitaria de la clase a probar.
importación { Calculadora calculadora = nueva Calculadora (); int suma = calculadora . evaluar ( " 1 + 2 + 3 " ); assertEquals ( 6 , suma); } }
5.4.2 Herramienta para determinar la mantenibilidad y la confiabilidad o StaticAnalisysPMD: es un analizador de código fuente que identifica posibles problemas
potenciales de comunes de programación como las variables utilizadas, bloques catch
vacíos, la creación de objetos innecesarios, y así sucesivamente. StaticAnalisysPMD
incluye CPD, el copy-paste - detector. CPD encuentra duplicada código en Java, C, C ++, C
#, PHP, Ruby, Fortran, JavaScript, PLSQL, Apache Velocity, Ruby, Scala, Objective C,
Matlab, Python, Go.
o Correr PMD a través de línea de comandos en GNU/Linux: y otros sistemas operativos
basados en UNIX, StaticAnalisysPMD viene con varias utilidades de línea de
comandos. Anteriormente, cada uno de ellos tenía su propia puesta en marcha de la
escritura, pero esto se ha simplificado en gran medida desde el PMD 5.0. ... Al menos para
los sistemas Unix. Ahora hay sólo una secuencia de comandos, llamado "run.sh", dentro
del bin/ directorio de la distribución PMD.
o Correr PDM a través de líneas de comandos en Windows: Se tiene que encontrar el
arranque de archivo por lotes de PMD pmd.bat en el bin subdirectorio.
Además de las herramientas necesarias para el cálculo de la deuda técnica. Se necesitara un programa que permita conocer el tamaño del software a analizar, para ello se ocupara Locmetrics.
5.5 Herramienta para medir el tamaño del software (Locmetrics) LocMetrics cuenta total de líneas de código (LOC), líneas en blanco de código (BLOC), líneas de
comentario de código (CLOC), líneas que contienen código y comentarios (C & SLOC), líneas de
código fuente a nivel lógico (SLOC -L), la complejidad McCabe VG (MVG), y el número de palabras
de comentario (CWORDS). Las líneas de código ejecutables a nivel físico (SLOC -P) se calculan
100
como el total de líneas de código fuente, menos líneas en blanco y líneas de comentarios. Los
recuentos se calculan sobre una base por archivo y acumulados para todo el proyecto. 23
Locmetrics tiene una manera de ejecutarse desde la línea de comandos.
Parámetro Descripción Tipo
-i directorio del código
fuente de entrada
(requerido)
-e extensiones de tipos
de archivo
(opcional)
-o directorio de salida (opcional)
23 Locmetris. (Última modifficación Octubre 2007). Descripción. 21/06/2015, de Locmetrics.com Sitio web:
http://www.locmetrics.com/
101
Capítulo 6 Ejecución de Experimentos A continuación se detalla cada experimento realizado al sistema bancario bajo la metodología
SQALE.
6.1 Breve introducción
En este capítulo se va a realizar una descripción de los sistemas que tiene la entidad bancaria
seleccionada y que serán utilizados para el caso de estudio. Es de suma importancia señalar que
únicamente se van a aplicar evaluaciones a a las tres primeras características y mandatarias para el
método SQALE, ya que el nivel de inmadurez de la entidad y el bajo apego a estándares no lo
permiten, las tres características a evaluar son Confiabilidad, Comprobabilidad y Mantenibiliad
La plataforma de desarrollo es JDK 1.7 utilizando acceso a bases de datos con ORACLE 10g y como
servidor de aplicaciones Oracle Weblogic 10.3.
6.2 Desarrollo de Experimentos
El procedimiento para aplicar las pruebas de mantenibilidad y confiabilidad son las siguientes:
1. Se extrae la muestra del código de la aplicación.
2. Desde la línea de comando se escribe la siguiente instrucción: pmd -d "C:\pmd\codigo_fuente\src\main\java" -f summaryhtml -version 1.7 -language java -R rulesets/java/unusedcode.xml -r sigab_report.html -shortnames
o bien se puede crear un archivo con extensión .bat con la misma línea de comando.
3. Se ejecuta el archivo con extensión .bat o se ejecuta desde la línea de comando la
instrucción anteriormente indicada
4. Se obtiene el resultado de la prueba.
La herramienta que se utilizará para los fines de comprobabilidad es JUnit (conjunto de bibliotecas
que son utilizadas para realizar pruebas unitarias). Para el caso de estudio se prescindirá de esta
herramienta debido a que los sistemas que se utilizarán como muestra no cuentan con pruebas
unitarias o con documentación alguna de pruebas unitarias. Por ello por cada clase encontrada
en la capa de persistencia o de la capa de servicios que no cuente con su correspondiente prueba
unitaria tendrá un costo de penalización.
Característica Subcaracterísticas Num. Violaciones
Comprobabilidad Pruebas Unitarias 89
Las siguientes imágenes y tablas muestran los resultados correspondientes a la característica de
mantenibilidad.
Resultado obtenido de la subcaracterística: Comments.
102
Figura 41. Sumario correspondiente a la subcaracterística comments que muestra el nombre de la regla y el
número de violaciones a la misma
Resultado obtenido de la subcaracterística: JavaBeans.
Figura 42. Sumario correspondiente a la subcaracterística JavaBeans que muestra el nombre de la regla y el
número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Unnecessary
Figura 43. Resumen correspondiente a la subcaracterística Unnecessary que muestra el nombre de la regla y
el número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Unusuedcode.
103
Figura 44. Sumario correspondiente a la subcaracterística Unusuedcode que muestra el nombre de la regla y
el número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Braces.
Figura 45. Sumario correspondiente a la subcaracterística Braces que muestra el nombre de la regla y el
número de violaciones a la misma.
Las siguientes imágenes y tablas muestran los resultados correspondientes a la característica de
confiabilidad.
Resultado obtenido de la subcaracterística: Basic.
104
Figura 46. Sumario correspondiente a la subcaracterística Basic que muestra el nombre de la regla y el
número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Optimizations.
Figura 47. Sumario correspondiente a la subcaracterística Optimizations que muestra el nombre de la regla y
el número de violaciones a la misma.
Resultado obtenido de la subcaracterística: StringandStringBuffer.
105
Figura 48. Sumario correspondiente a la subcaracterística StringandStringBuffer que muestra el nombre de
la regla y el número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Strictexception.
Figura 49. Sumario correspondiente a la subcaracterística Strictexception que muestra el nombre de la regla
y el número de violaciones a la misma.
Resultado obtenido de la subcaracterística: Codesize.
106
Figura 49. Sumario correspondiente a la subcaracterística Codesize que muestra el nombre de la regla y el
número de violaciones a la misma
Resultado obtenido de la subcaracterística: Controversial.
Figura 50. Sumario correspondiente a la subcaracterística Controversial que muestra el nombre de la regla y
el número de violaciones a la misma
Evidencia de la medición del tamaño del código fuente
107
5 Métricas de Código fuente
108
6.3 Resultados A continuación se muestran las cifras obtenidas por las herramientas de análisis de código estático y conteo de líneas de código.
Se obtuvo el siguiente tamaño de código fuente por cada mil líneas, ya que SQALE recomienda esta unidad de medida, ya que si contamos la
cantidad de defectos en una clase de java o en cien líneas de código se corre el riesgo de tener una falsa densidad de errores por unidad y
defecto.
Tamaño del Código Fuente
152.981 KLOC
Suma de todas las violaciones al código fuente.
Total Violaciones
21282
Resultado de la división entre el tamaño del código fuente y la cantidad de errores encontrados en el mismo.
Densidad de Errores
139.115315
Se muestra la mediana de los costos de remediación por todas las características y por cada una de ellas.
TOTALES Confiabilidad Mantenibilidad Comprobabilidad
Costos remediación Costos de no remediación Costos remediación Costos remediación Costos remediación Costos de no remediación Costos remediación Costos de no remediación
0.5 0.05 0.5 0.5 0.5 0.05 8 1
109
Se muestran los promedios de los costos de remediación totales y por cada una de las características
TOTAL Confiabilidad Mantenibilidad Comprobabilidad
Costos remediación Costos de no remediación Costos remediación Costos remediación Costos remediación Costos de no remediación Costos remediación Costos de no remediación
235.97 69.93 81.87 48.72 1013.44 176.99
8 1
Totales de los índices de calidad e impacto al negocio por característica, así como su calificación en el rango SQALE
Característica SQI x Característica Violaciones SQI Consolidado SBI x Característica SQALE Rate Índice de Densidad x KLOC
Comprobabilidad 712 89 712 89 8.00 4.65
Mantenibilidad 21583.7 582.190 22295.7 3804.8 5.67 141.08
Confiabilidad 9089.1 135.164 31384.8 5407.65 1.68 59.41
6 Tabla de Índices de Calidad
110
Figura 51. Clasificación de SQLAE
En la siguiente tabla se muestra el rango de viabilidad (ver figura 52 ) del pago de la deuda técnica. De acuerdo con los parámetros SQALE ver
Figura 51.
SQALE Rate Costo de remediación horas/hombre
Comprobabilidad 8 D 712 HORAS
Confiabilidad 1.68 B 9089 HORAS
Mantenibilidad 5.67 D 21583 HORAS
Figura 52. Muestra de resumen de resultados obtenidos.
Clasificación Hasta Color
A 1%
B 2%
C 4%
D 8%
E ∞
CLASIFICACIÓN SQALE
111
6.4 Interpretación de resultados.
A continuación los resultados obtenidos de la evaluación de la comprobabilidad, mantenibilidad y
confiabilidad.
El tamaño total del sistema evaluado fue de 152.981 KLOC (miles de líneas de código), y la
cantidad de violaciones fue de 21282. Que al dividir estos dos indicadores la densidad de errores
en el código fuente es de 139.11. Esto significa que el 139% del código incumplió con los
requerimientos de la calidad mínima esperada. También se interpreta que al ser mayor del 100%
la densidad de errores, se ha cometido el mismo error más de una vez dentro de las mismas mil
líneas de código que se evaluaron.
También se observa que a pesar de tener una gran densidad de errores en el código fuente la
media de penalización de estos en 0.5 del tiempo en una jornada laboral de ocho horas y el
impacto al negocio es de 0.05 es decir que la media de errores es baja con respecto al impacto al
negocio. No siendo así para la característica de comprobabilidad que se mantiene alta ya que no
existen evidencias de documentación y pruebas unitarias del código.
Se observa que de las tres características calificadas, la de mayor promedio de deuda técnica es la
comprobabilidad esto es por la inexistencia de pruebas unitarias así como su respectiva
documentación.
Cabe mencionar que la falta de desarrollo de pruebas unitarias es una mala práctica que se
encontró en otros sistemas no evaluados, y con esto se demuestra que la organización tiene bajo
nivel de madurez de apego a estándares de desarrollo y mejores prácticas.
De las tres características la de mayor promedio al costo de remediación es la mantenibilidad y
también la de mayor impacto al negocio, es decir esta aplicación no podrá responder de manera
ágil a los mantenimientos necesarios por el cambio de estrategia de negocio.
También se observa que el mayor número de violaciones encontradas se encuentra de nuevo en la
mantenibilidad con 582 violaciones.
Por lo tanto se recomienda dar cumplimiento inmediato a estas violaciones al código fuente. Ya
que el costo de remediación es relativamente bajo si lo dividimos entre el índice de impacto al
negocio, es decir resulta muy benéfico a la organización resolver esta deuda técnica con el fin de
tener un sistema adecuado y listo al entorno cambiante de las reglas de negocio de un banco.
También se recomienda agregar el pago de la deuda técnica como parte de las tareas del plan para
ganar una ventaja estratégica al tener una aplicación lista y de fácil mantenimiento al cambiante
entorno de las empresas.
112
Conclusiones Derivado de los resultados antes obtenidos se concluye que.
El foque mas adaptado para el aseguramiento de calidad desde el punto de vista de la deuda
técnica es el método SQALE.
El método SQALE permite su adaptación al entorno empresarial donde se desea aplicar siempre y
cuando el nivel de madurez de las organizaciones permita ir aumentando el nivel de características
a evaluar, en este caso de estudio solo se permitió la evaluación de las tres primeras y obligatorias
características de calidad (Comprobabilidad, Confiabilidad y Mantenibilidad).
Las herramientas existentes en el mercado son de propietario con versiones limitadas de
evaluación y con elevados costos de adquisición para la pequeña y mediana empresa, por ello es
necesario la integración de distintas herramientas y realizar los cálculos de manera manual con
apoyo de una hoja de cálculo.
Que las funciones que generan los costos de remediación y no remediación para penalizar cada
una de las violaciones en el código fuente son dimensionados y valorados de acuerdo a las
expectativas de los usuarios finales y que los costos de remediación de las mismas son estimadas
por los desarrolladores que las llevaran acabo
En cuanto a los cálculos obtenidos se observa una densidad de violaciones elevada. Teniendo más
de 130% de violaciones por cada mil líneas de código.
En el caso de una institución financiera evaluada se dan prioridad a los relacionados con la
fiabilidad, es decir se tiene mayor cuidado en los posibles errores derivados de una mala calidad
en el código que pudieran detener o entorpecer la operación diaria de la misma.
Se muestra un número elevado de horas hombre para cumplir con todos los requerimientos de
calidad, esto concluye que al dejar pasar el tiempo la deuda técnica la igual que una deuda
financiera se va incrementando con el tiempo
De acurdo al índice desfavorable de deuda técnica se sugiere sea pagada a la brevedad y las tareas
de remediación se agregan al plan del trabajo.
Cuando el grueso de la deuda técnica está en la mantenibilidad como fue en el caso de estudio, se
obtienen como consecuencias, una sistema difícil de adaptar al entorno cambiante y que por ello
los costos de mantenimiento sean mayores ya que para poder lograr el apretado plan del proyecto
se recurre al sobreesfuerzo del equipo del proyecto.
113
La deuda técnica derivada de la mala mantenibilidad puede derivar en costos de desarrollo no
visibles y mala estimación en el plan de desarrollo del proyecto
Dado lo anterior y llevado acabo los experimentos en una aplicación bancaria con bajo apego a
metodologías de desarrollo y poco nivel de madurez por la adopción de estándares o
metodologías de desarrollo, se concluye que el concepto de deuda técnica y la metodología SQALE
son una imprescindible metodología para hacer poder demostrar la mala calidad intrínseca del
software para los usuarios finales y que dicha metodología es adaptable a cualquier contexto
empresarial.
114
Glosario
Despliegue: Es el proceso que comprende las actividades o tares necesarias para la puesta en
marcha de un sistemas, entre las que incluye la configuración de los componentes del sistema,
instalación de la base de datos y servidor de aplicaciones, así como las pruebas de aceptación, que
aseguran el correcto funcionamiento de la aplicación que deseamos instalar.
Integración Continua: es un modelo informático propuesto inicialmente por Martin Fowler que
consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así
poder detectar fallos cuanto antes. Entendemos por integración la compilación y ejecución de
pruebas de todo un proyecto.
Métrica de Software: Medida o conjunto de medidas que permite estimar el tamaño de una
característica del software
Complejidad Ciclomática: Métrica de software que proporciona una medida cuantitativa de la
complejidad de un programa, Este cálculo se realiza mediante el conteo del número de caminos o
flujos independientes del código fuente.
Mejor práctica: es una técnica o metodología que, a través de la experiencia y la investigación, ha
demostrado conducir confiablemente a un resultado deseado. Un compromiso con el uso de las
mejores prácticas en cualquier campo es un compromiso de utilizar todos los conocimientos y la
tecnología a disposición de uno para asegurar el éxito.
KSLOC: Miles de líneas de código (Thousands Lines of Code), métrica de software para medir el
tamaño de los componentes de software.
Penalización: Sanción por el incumplimiento de alguna mejor practica o estándar de codificación.
Código Duro (Hard Code): Mala práctica de desarrollo de software que consiste en dejar datos que
cambia constantemente en un archivo externo en lugar del código que será compilado.
115
Referencias.
Libros
1. Capers Jones (2010). Best Practices Lessons from Successful Projects in the Top of
Companies. New York, USA: Mcgraw-Hill
2. Chris Sterling (2011). Manning Software Debt, Building for the inevitable change. USA:
Addison-Wesley
3. Sánchez Salvador, Sicilia Miguel Ángel y Rodríguez Daniel (2012). Ingeniería del Software
Un enfoque desde la guía SWEBOK. España: Alfaomega.
4. Jean-Louis Letouzey (2012). SQALE Method Definition Document Version 1.0. Francia:
Inspearit
5. Spinellis Diomidis (2006). Code quality : The open source perspective. USA: Adisson-Wesley
6. Pressman Roger S. (2010). Ingeniería de Software un enfoque práctico. México: Mc Graw
Hill
7. Sommerville Ian (2011). Software Engineering 9/E. Escocia: Pearson
8. Humprey, Watts S (1996). Introduction to the Personal Software Process. USA: Addison-
Wesley
9. Humprey, Watts S (2005). PSP(sm): A Self-Improvement Process for Software Engineers.
USA: Addison-Wesley
10. Humprey, Watts S (2000). Introduction to the Team Software Process. USA: Addison-
Wesley
Artículos
1. Pino, F.J.; Garcia, F.; Ruiz, F.; Piattini, M., "Adaptation of the standards ISO/IEC 12207:2002
and ISO/IEC 15504:2003 for the assessment of the software processes in developing
countries," Latin America Transactions, IEEE (Revista IEEE América Latina) , vol.4, no.2,
pp.85,92, April 2006
2. Kruchten Philippe, Nord Robert L. y Ozkaya Ipek (2012). Managing Technical Debt with
the SQALE Method. USA: IEEE
3. Letouzey Jean-Louis y Ilkiewicz Michel (2012). Managing Technical Debt with the SQALE
Method. USA: IEEE
4. Buschmann Frank (2012). To Pay or Not to Pay Technical Debt. USA: IEEE
5. Kruchten, Philippe (2012) Strategic Management of Technical Debt. USA: IEEE
6. Curtis Bill, Sappisi Jay y Szynkarski Alexandra(2012). Estimating the Size, Cost, and Types of
Technical Debt. USA: IEEE
116
7. Kruchten Philippe (2012). Strategic Management of Technical Debt, USA: IEEE
8. Kruchten Philippe, Nord Robert L. y Ozkaya Ipek (2012). Technical Debt: From Metaphor
to Theory and Practice .USA: IEEE
9. Vetro Antonio (2012). Using Automatic Static Analysis to Identify Technical Debt. USA: IEEE
10. Alves, Nicolli S. R. & Others (2014). Towards an Ontology of Terms on Technical Debt. USA:
IEEE
117
Anexos Articulo emanado del trabajo presente y publicado en la revista de la ANIEI, Enero 2016
118
119
120
121
122
123
124
125
126
127
128
