¿Cómo identificar riesgos potenciales en software?

Identificar riesgos potenciales en software y prevenirlos debe ser un asunto de prioridad en nuestra organización.

Los impactos de estos riesgos convertidos en fallas en el software dan como resultado altos costos, pero sobre todo la pérdida de credibilidad con nuestros clientes, proveedores y colaboradores.

Para una situación de esta categoría te sugerimos revisar la siguiente información sobre 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 de la Certificación PMP del PMI, que es la certificación en gestión de proyectos más valiosa a nivel internacional.

Simplemente en México los costos por las fallas de software cuestan 23.1 mdd anuales a empresas.

Siendo la media internacional 21.8 mdd este impacto significativo en costos da como consecuencia que las organizaciones, busquen identificar riesgos potenciales y eliminarlos.

¿Cómo identificar riesgos potenciales en software?

La forma es conduciendo una revisión o assessment de la calidad del sistema de software en cuestión.

Esta evaluación puede ser desempeñada por nosotros mismos o alguien más, sin embargo hay que evitar caer en ser juez y parte, por lo que es siempre recomendable que no sea el mismo equipo que participó en el desarrollo quien evalúe.

Existen diferentes métodos para realizar la evaluación, uno de los más frecuentemente utilizados es el de “Evaluación de software con base en criterios”.

¿Cómo conducir una evaluación de software?

La evaluación de software es realizada por una o más personas con los conocimientos necesarios y un método que les permita conducir de forma objetiva la evaluación.

La forma en como podemos conducir la evaluación es a través de determinar el alcance y establecer y acordar criterios para la revisión

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.

Determinar el alcance

Hay muchos aspectos que se pueden evaluar en un sistema de software, por lo que será muy importante entender qué queremos evaluar.

Para ello podemos hacer uso del modelo de McCall, uno de los modelos de calidad más difundidos y que ha servido de base para otros modelos como el de Boehm y el Software Quality Management (SQM) de Murine.

El modelo de McCall organiza factores de calidad en tres ejes o puntos de vista, desde los cuales el usuario puede contemplar la calidad de un sistema de software.

Cada factor será una perspectiva en la cual podemos revisar el sistema, empecemos por revisar qué significa cada una de ellas.

Revisión del producto

Facilidad de mantenimiento. Esfuerzo que existe para poder corregir el sistema.

Facilidad de pruebas. Esfuerzo requerido para poder probar el sistema.

Flexibilidad. Esfuerzo que se necesita para modificar el sistema.

Operación del producto

Corrección. Nivel en el que el sistema cumple con sus especificaciones y objetivos.

Fiabilidad. Nivel en el que un sistema lleve a cabo sus funciones esperadas con la precisión requerida.

Eficiencia. Cantidad de recursos de cómputo requeridos para que un sistema realice sus funciones.

Integridad. Nivel en el que puede controlarse el acceso al sistema o a sus datos por usuarios no autorizados.

Facilidad de uso. Esfuerzo requerido para aprender a utilizar o interpretar la información del sistema.

Transición del producto

Portabilidad. Esfuerzo requerido para implementar un sistema de una plataforma a otra.

Reusabilidad. Nivel en el que un sistema o partes de él se pueden usar en otro.

Interoperatividad. Esfuerzo para asociar o comunicar un programa con otro.

Con base en los requisitos de calidad que hayan sido especificados para el sistema, podremos seleccionar los factores que queremos evaluar.

Es importante mencionar que es imposible que un sistema cumpla con altos niveles de calidad en todos los factores, ya que cuando hay un grado de calidad alto para uno puede haber bajo para otros.

La relación la vemos definida en la siguiente tabla.

Las verificaciones de estos factores se realiza convencionalmente, sobre una versión del sistema operando, así como en el código fuente.

Sin embargo otros elementos que deben considerarse para evaluar la calidad de cada factor son:

La documentación técnica del sistema. Aquella que se utilizó para el análisis y diseño
La documentación de usuario. Guías y manuales
Bases de datos
Herramientas y componentes utilizados en el desarrollo
Plataforma tecnológica para operar el sistema
Documentación de implementación
Bitácoras de registro y atención a incidencias o peticiones de usuarios
Entre otras

Establecer y acordar criterios para la revisión

Desde un principio en la evaluación hay que definir qué criterios se tomarán en cuenta, para llevar a cabo la verificación de los diferentes artefactos o elementos que serán sometidos a revisión.

Las evaluaciones deben conducirse de forma objetiva y esto implica que no será posible evaluar artefactos que no se contemplaron realizarse en el desarrollo como aspectos de calidad que debían cuidarse en su elaboración.

De esta manera debemos establecer criterios que nos permita de forma homogénea y consistente, saber cómo se evaluarán los artefactos contemplados en el alcance.

Ejemplos de criterios que podemos utilizar para un factor de calidad son:

Conclusiones

Dado que cualquier desarrollo de software implicará riesgos, el mejor mecanismo para prevenirlo es evaluando el sistema.

Si ésta se puede realizar lo antes posible y durante todo el desarrollo y mantenimiento del software, esto asegurará reducir considerablemente los riesgos.

Sin embargo muchos sistemas de software ya están construidos y se siguen manteniendo, es aquí o para desarrollo donde no se tenga un equipo dedicado a la calidad donde podemos introducir los assessments o evaluaciones de calidad.

Esto ayudará a que los riesgos estén ocultos y se lleguen a convertir en problema al no visualizarlos y atenderlos.

Un aspecto importante para conducir estas evaluaciones, es el conocimiento, método y herramientas del equipo evaluador.