Según la norma ISO 9000, la calidad de un servicio o producto es el “grado en el que un conjunto de características inherentes cumple con los requisitos”, y se aclara que debe entenderse por requisito “una necesidad o expectativa establecida, generalmente implícita u obligatoria”.
Por tanto la calidad de un servicio o producto es un concepto relativo a las especificaciones del mismo y al contexto en el que se diseña y desarrolla. Es difícil asegurar que un producto es mejor que otro salvo que estén concebidos para unas mismas especificaciones.
Este artículo se centra en problemas de calidad de las aplicaciones que pueden ser aceptadas con carácter general y se admite que, en situaciones concretas puede haber criterios adicionales de calidad o valoraciones diferentes de los aquí descritos.
Se asume que se conocen los principios de funcionamiento de icaria Lean Factory. Ver este enlace para acceder a una breve descripción de la tecnología icaria
En general es posible afirmar que las siguientes son causas comunes a los problemas de calidad de las aplicaciones y sistemas de información, que se manifiestan en un número elevado de incidencias, en un coste excesivo de mantenimiento y/o en un aprovechamiento ineficiente de la evolución del contexto tecnológico. Por centrarnos en tres causas significativas (la lista podría variar en opinión de otros) éstas podrían ser:
Tal y como se comentó anteriormente, el código fuente de una aplicación es heterogéneo en dos dimensiones: la consistencia intrínseca del código escrito (respeto a las normas y convenciones de programación, metodología, comentarios, etc.) y la consistencia de las soluciones ofrecidas a un mismo problema.
Este efecto se multiplica en aplicaciones desarrolladas por equipos que rotan a lo largo de un periodo amplio de tiempo, y está condicionado por la formación y experiencia de los desarrolladores.
Los responsables de la calidad de la aplicación –generalmente arquitectos de software – hacen un gran esfuerzo para limitar la capacidad de los programadores para producir código heterogéneo. Para ello desarrollan un conjunto de normas y metodologías de programación que tratan de regular desde la estructura y contenido de los ficheros, hasta la nomenclatura de variables y normas básicas de programación, por un lado, y por otro, dictaminan que soluciones son aceptables para una determinada especificación de entre las muchas posibles. Nótese que puede generarse código respetuoso con las normas básicas que implemente dos soluciones distintas para un mismo tipo de especificación que se repite a lo largo del sistema de información.
El desarrollo convencional – manual – ofrece soluciones poco eficientes, por la relación entre el coste y los resultados obtenidos, tales como los libros “blancos” de arquitectura, las revisiones entre iguales (peer-to-peer revision), auditorías de calidad, etc.
Con el avance del proyecto, la rotación del equipo de programadores, la evolución de las normas, etc. mantener la homogeneidad del código es una tarea de creciente dificultad. Es común medir la “deuda técnica”, el coste de resolver los problemas de calidad del código fuente, pero generalmente es un problema inabordable que se aplaza indefinidamente, y que tiende a crecer, por lo que tiende a perpetuarse.
Los arquitectos de software implementan las normas de escritura del código y las soluciones en el cartucho de generación, de forma que el configurador no puede saltarse las reglas impuestas. Todo el código generado es homogéneo en el fondo y en la forma. Dicho de otra forma. Todos los miembros del equipo de trabajo producen exactamente el código fuente especificado, independientemente de su formación, experiencia o estado de ánimo. El libro “blanco” del arquitecto se ha volcado en el cartucho tecnológico.
Pero además es consistente a lo largo del tiempo. Cuando el arquitecto de software encuentra un problema o una mejor solución, mejora el cartucho, y lo pone a disposición del equipo de trabajo. La aplicación se regenera con la nueva versión y el código se adapta automáticamente a los nuevos estándares. El coste de la deuda técnica es ahora asumible.
El proceso habitual del trabajo con icaria Lean Factory incluye la monitorización del código generado con herramientas de auditoría de la calidad como SONAR. El análisis de Sonar ofrece al arquitecto información muy valiosa de cómo mejorar el cartucho de generación.
El esfuerzo de control se reduce al mínimo y la calidad del software producido ha mejorado de forma muy importante.
En el inicio del proyecto de desarrollo de un sistema de información se deben elegir las herramientas, el entorno tecnológico y los componentes en los que basar el nuevo software. No es una decisión trivial. Hay muchas alternativas y una buena elección reduce mucho el esfuerzo necesario para culminar con éxito el proyecto. Lo que sí se sabe al tomar la decisión es que la tecnología elegida quedará obsoleta pronto. El ecosistema de herramientas alternativas evoluciona constantemente, pero sustituir una por otra en el código fuente ya escrito de una aplicación de complejidad media no es viable, en la mayoría de los casos. Por ello, antes o después, la tecnología base en la que se apoya un sistema queda obsoleta y el sistema no puede sacar partido de los avances del ecosistema tecnológico disponible.
Desde la perspectiva de calidad esto supone un coste enorme, ya que las necesidades del negocio y las exigencias del usuario se relacionan más con las opciones disponibles que con las limitaciones de la decisión tomada al inicio del proyecto.
Con icaria Lean Factory, las decisiones relativas al ecosistema de herramientas (frameworks) en los que basar el sistema se toman en el cartucho tecnológico, no en el código fuente. Cuando el ecosistema disponible evoluciona, el arquitecto de software puede reemplazar una herramienta por otra trabajando en la evolución del cartucho sin afectar a los sistemas que utilizan la versión aprobada del mismo. Cuando ha terminado de implementar y probar la nueva versión, liberará el cartucho y los sistemas que lo utilicen podrán se regenerados automáticamente. El código de todos los sistemas de información se adaptará a la nueva decisión técnica.
CASO REAL
La versión anterior del cartucho J2EE utilizaba JSF como plataforma (framework) de componentes gráficos e integración AJAX, y con él se generaron sistemas y aplicaciones durante dos años.
En 2012, RAP sustituyó a JSF en el cartucho porque éste último no había evolucionado según lo esperado y RAP ofrece la posibilidad de desplegar aplicaciones web y de escritorio.
Las aplicaciones basadas en JSF se regeneraron con el nuevo cartucho y abandonaron la tecnología obsoleta.
Más relevante que el debate sobre las ventajas o no de RAP sobre JSF es la posibilidad de elegir.
