5 Causas que afectan la calidad de software
A pesar de que las causas que afectan la calidad de software siempre están presentes, la mala calidad no es un atributo inevitable de todo software.
El software de mala calidad siempre representa riesgos.
Las causas que afectan la calidad de software son resultado de malas prácticas que aparecen desde la concepción del sistema.
En tal situación te hacemos una amplia recomendación para que conozcas más acerca del tema y revises nuestro Curso de gestión de proyectos en TICS. El capacitarte en gestión de proyectos te servirá después para comenzar la preparación para la Certificación PMP del PMI, que es la certificación en gestión de proyectos más valiosa a nivel internacional.
Sin embargo estas pueden ser predichas y controladas.
El no contar con sistemas de software con factores de calidad como alta disponibilidad, desempeño y la facilidad de adaptarse a cambios deriva en un sin número de problemas.
Si sospechas que tu sistema de software puede estar en riesgo por una mala calidad. Te invitamos a que bajes el siguiente test de evaluación.
Un problema principal del software de mala calidad son los costos que se derivan después de su implementación.
Muchas veces estos costos son subestimados y se desconoce el impacto que pueden llegar a generar.
La analogÃa es un iceberg en donde en la superficie aparecen los costos visibles a corto plazo, sin embargo los que terminar causando más daño son los ocultos.
Decimos que las actividades, recursos y personas requeridas para mantener la operación del software una vez implementado, son designadas al proceso conocido como mantenimiento de Software.
Las 5 principales causas que conllevan a una mala calidad de software y que serán recurrentes año tras año, son:
1. Falta de dominio del negocio
En la mayorÃa de los proyectos los desarrolladores en un principio no son expertos en los conceptos y temas propios del negocio, para el cual se está desarrollando el software.
Con el tiempo ellos logran conocer mucho sobre el negocio y se llegan a convertir en unos verdaderos expertos.
Sin embargo, mucho de este desconocimiento al inicio se traduce en un buen número de defectos introducidos al sistema por reglas y requerimientos funcionales malentendidos.
Una solución es introducir a expertos del negocio al inicio del proyecto, que den orientación a analistas y desarrolladores.
Los analistas deberán trabajar en documentar el entendimiento a través de metodologÃas, diagramas y notaciones estándares que faliciten su validación con los usuarios de negocio.
Ejemplos de estos diagramas y notación son UML y BPMN.
Posteriormente se recomienda conducir revisiones con los expertos de negocio para verificar que la documentación generada es correcta.
2. Desconocimiento de la tecnologÃa
La mayorÃa de los desarrolladores son conocedores de varios lenguajes y tecnologÃas informáticas.
Sin embargo, las aplicaciones empresariales actuales de múltiples capas son un enredo complejo de muchos lenguajes y plataformas de software.
Estos niveles incluyen la interfaz de usuario, la lógica empresarial y la gestión de datos, y pueden interactuar a través de middleware con sistemas de recursos empresariales y aplicaciones heredadas escritas en lenguajes arcaicos.
Pocos desarrolladores conocen todos estos lenguajes y tecnologÃas, y tienen suposiciones incorrectas sobre cómo funcionan otras tecnologÃas.
Esto llega a ser la fuente principal de los defectos no funcionales que causan interrupciones dañinas, corrupción de datos y fallas de seguridad durante la operación.
La mejor manera de mitigar esta causa es entrenar a los desarrolladores en diferentes tecnologÃas, realizando revisiones entre pares con otros desarrolladores que trabajen en diferentes aspectos de la aplicación.
3. Calendarios pocos realistas
Cuando los desarrolladores se ven obligados a sacrificar buenas prácticas de desarrollo de software por planes y calendarios mal elaborados y extremadamente cortos, los resultados no son buenos.
Los pocos resultados exitosos se basan en actos heroicos que rara vez se repiten.
Al trabajar a un ritmo vertiginoso, los desarrolladores más estresados cometen más errores y tienen menos tiempo para encontrarlos.
La única manera de mitigar esto es a través de la aplicación de fuertes prácticas de gestión de proyectos.
Controlar los compromisos a través de la planificación y el seguimiento para identificar problemas, asà como el control de lo cambios en los requerimientos son prácticas crÃticas para proporcionar un entorno profesional para el desarrollo de software.
4. No implementar ingenierÃa de Software
La mayorÃa de las actividades de desarrollo de software implican el cambio o la mejora de código.
Estudios demuestran que la mitad del tiempo dedicado a modificar software se gasta comprendiendo la lógica del código fuente.
El código complejo frecuentemente es difÃcil de entender y la modificación conduce a numerosos errores y efectos secundarios negativos imprevistos.
Estos defectos recién inyectados causan retrabajos costosos y liberaciones retardadas.
La manera de mitigar esta causa es volver a partes crÃticas del código guiado por información de análisis de código arquitectónico y estático.
5. Utilizar malas o nulas prácticas de desarrollo de Software
La mayorÃa de las aplicaciones multi-nivel grandes son construidas y mantenidas por equipos distribuidos, algunos o todos los cuales pueden ser subcontratados de otras compañÃas.
En consecuencia, la organización adquirente a menudo tiene poca visibilidad o control sobre la calidad del software que está recibiendo.
Por varias razones, los niveles del modelo CMMI no siempre han garantizado entregas de software de alta calidad.
Para mitigar los riesgos de problemas de calidad en el software suministrado externamente, los administradores deben implementar objetivos de calidad en sus contratos y una sólida garantÃa de calidad para el software entregado.
Las empresas sufren con los sistemas por la mala definición del requerimiento michas veces no saben que es lo que quieren y no conocen cual es el problema a solucionar.
Sin lugar a dudas la causa numero 1, el desconocimiento del negocio, no solo provoca mala calidad de sofware, esto puede llevar al fracaso total del proyecto. Si no se cuenta con expertos del negocio en el diseño de la solucion es muy probable que el proyecto fracase. El contar con expertos levantando requerimientos y no diseñando la solucion, no soluciona el problema.
Sin duda alguna, el no tener un buen conocimiento sobre el modelo a desarrollar, conlleva a retrabajos y un seguro fracaso del proyecto.
Buen documental, gracias!
Puedes tener todo el conocimiento del modelo, pero si carece de un empuje por parte de la dirección en la implementación ten por seguro que está destinado al fracaso o a la subutilización.
Buen artÃculo. Yo agregarÃa un punto. El interés por parte del negocio/gobierno por seguir nutriendo al software. Muchos sistemas implementados no se les implementa más fases de desarrollo o mejora continua. Eso a futuro causa que el software encarezca junto con los tiempos y mano de obra para el soporte. Ejemplo, los cajeros automáticos.
Estoy de acuerdo. La parte de requerimientos del cliente es una fase vital para el desarrollo de software. Es muy importante entender lo que realmente el cliente busca y necesita. Ademas, contar con el apoyo de personas expertas en el area es muy importante pues son quienes pueden ayudar a evaluar el progreso y definir si es necesario hacer cambios a tiempo en la direccion del desarrollo.
Creo que la calidad del software como tema es algo subjetivo o quizá un tema muy extenso, en el que serÃa difÃcil enumerar TODAS las causas que nos conlleva a la falta de esta. Principalmente porque existen muchos tipos de proyecto y lo que afecte a uno, para otro pudiera no ser un factor de alta importancia. Ademas también depende del tamaño de la solución a la que se enfrente, creo que entre más grande sea el proyecto más probabilidades tendrá de no llegar a la calidad deseada.
Es importante tener un equipo multidisciplinario que entienda los diferentes aspectos que están involucrados en un proyecto, ya que un buen software no depende solamente de la capacidad técnica de las personas involucradas, sino que es importante tomar en cuenta los tiempos disponibles para hacer realidad dicho software, el presupuesto necesario versus el presupuesto disponible, es decir que cada etapa desde la concepción del proyecto hasta su liberación estén debidamente cubierta por las personas mas capaces disponibles.
El equipo de análisis y diseño deberá tener la experiencia y expertise para obtener todas las reglas de negocio de cada usuario clave, de esta forma se obtendrán los indicadores claros de cumplimiento del proyecto.
En la parte de arquitectura de hardware y software deberá considerarse en ambos casos una arquitectura que permite el crecimiento, el alto performance y al mismo tiempo la simplicidad, siempre es buena idea mantener el principio KIS (Keep it simple).
Durante el proceso de desarrollo el o los administradores de proyectos deberán cuidar mucho que la ruta crÃtica se cumpla en tiempo y forma e identificar a tiempo los posibles riesgo e ir subsanandolos de manera oportuna, por supuesto será necesario que el equipo de análisis y diseño sepa transferir el conocimiento al equipo que desarrollara el proyecto, para que todas las reglas de negocio sean aplicadas de manera correcta y por ende cubrir los indicadores de cumpliemiento del proyecto. Durante este proceso es importante que se apliquen los patrones de diseño adecuados que permitan los siempre inevitables cambios de último moment.
Cuando se pase a la fase de liberación es importante contar con los usuarios adecuados que daran el visto bueno a la funcionalidad del producto, asà como el cumplimiento de las reglas de negocio, de esta forma se garantiza un alto porcentaje de éxito al momento de la liberación del proyecto, no tanto en el aspecto funcional, más bien en el cumplimiento de las expectativas del cliente, y es importante dejar un equipo atrás (no del mismo tamaño que el que participó en el desarrollo) para ultimar detalles y alcanzar ese 100% deseado y dejar a un cliente satisfecho. Porque al final esto es un negocio y un cliente satisfecho es una alta posibilidad de un nuevo negocio.