X
BLOG

Evite estas 5 cosas cuando publique software

Evite estas 5 cosas cuando publique software Tiempo de leer: 4 minutos
El costo de una falla de software se puede sentir de diferentes maneras: en el precio de las acciones de una empresa pública, por ejemplo, o en una pequeña empresa, puede significar la quiebra.

Con demasiada frecuencia, veo organizaciones que lanzan software de una manera tan segura como jugar a la ruleta rusa: apostar con la seguridad, los datos privados y la seguridad de sus clientes, sin mencionar la confiabilidad. También están jugando con la reputación y los resultados de su empresa. IEEE publicó un excelente lista de fallas públicas hace un par de años y puede estar seguro de que el software sigue fallando. 

La razón por la que me gusta esta analogía algo aterradora es que, con demasiada frecuencia, escucho a la gente decir cosas como "Ese software ha estado fuera durante mucho tiempo y no ha tenido problemas" o "Siempre lo hemos hecho de esta manera y funciona ”, pero, por supuesto, esta es una mala forma de planificar. Una empresa centrada en la ingeniería de software está buscando formas de crear y lanzar un mejor software que falle menos. Esto significa planificar proactivamente para el éxito haciendo lo correcto, incluso si hasta ahora ha funcionado hacer lo incorrecto.

Investigadores en Harvard han descubierto que algo así como la mitad de los proyectos de software de TI fracasan. Hay muchos números de otros y esa estimación no es la más alta, así que tomémosla por un minuto. Esto es como jugar a la ruleta rusa con 3 balas en la recámara: una probabilidad de 50-50 de fallar. No me gustan esas probabilidades y ciertamente no apostaría el futuro de mi empresa a eso.

Veamos algunas de las malas apuestas que la gente hace todos los días cuando lanza su software. Balas en su pistola de ruleta, por así decirlo:

1. Errores antiguos conocidos

Todos sabemos que publicamos software con errores porque la creación de un software impecable tardaría una eternidad. Pero esa no es una excusa para no corregir los errores que conocemos. Se ha hablado mucho sobre la deuda técnica en términos muy abstractos, pero esta es una medida práctica real de la deuda en su software. Si hay un error y no lo está solucionando, será mejor que tenga una buena razón por la que cree que no importa. Planifique algo de tiempo en cada lanzamiento no solo para agregar nuevas funciones, sino también para mejorar las cosas en general. Tómese su tiempo para pulir su software.

2. Nuevos errores en el código antiguo

El código antiguo es complicado. He visto compañías que tienen una política de "limpiarlo si lo está arreglando de todos modos" y otras donde la regla es "solo toque lo que debe, y solo cuando haya un error informado en el campo". Ambas son políticas interesantes, pero lo más importante es comprender el riesgo que implica cuando encuentra un nuevo error en el código antiguo. Estaba trabajando con un proveedor de hardware y estaban luchando con cómo manejar la salida de una nueva herramienta en algún código heredado. En su caso, fue un problema de alcance ambiguo que todavía me deja preguntándome cómo su compilador pudo permitir tal locura. Se estaban encontrando con un conflicto: por un lado, tenían esta nueva herramienta y, por otro lado, se suponía que no debían tocar el código antiguo a menos que hubiera un informe de error del campo.

Es importante comprender lo que planea hacer con su código heredado, así como comprender completamente el riesgo para su organización. Si el código es crítico, es posible que la edad no importe tanto como cree. Si el código está en desuso, quizás esté perdiendo el tiempo probando cosas que no tiene la intención de corregir.

3. La seguridad como parte de las pruebas en lugar del desarrollo

Es deprimentemente común que las organizaciones pasen por alto la seguridad. En algunos casos, piensan que pueden probar la seguridad en su aplicación (no pueden), mientras que en otros casos piensan que los problemas de seguridad no se aplicarán a su código (lo harán). Para salir de este lío de constantes fallas de seguridad, las organizaciones deben fortalecer el código con las mejores prácticas sólidas de AppSec, codificadas en una herramienta de análisis estático que hace más que solo análisis de flujo. Si no sabe por dónde empezar, honestamente, no estaría de más tomar las reglas de MISRA y comenzar a seguirlas para cualquier código que escriba a partir de hoy.

4. El conjunto de pruebas que siempre falla y que pasa siempre

Una práctica extremadamente común y peligrosa que veo es tener un gran conjunto de pruebas y confiar en una métrica simple de la cantidad de pruebas que pasaron. Por ejemplo, normalmente tiene una tasa de aprobación del 80%, por lo que asume que esto estará bien. El problema es que no hay forma de saber si el 80% que pasó hoy es igual al 80% que pasó ayer. Fácilmente podría haber una nueva falla real escondida en ese 80% (hay) porque algo más se solucionó, dejando el número equilibrado. Mantenga limpia su suite de pruebas o no le dirá mucho. Cuestionaría seriamente el valor de una prueba fallida que te sientes cómodo ignorando. ¿Por qué no simplemente saltarse esa prueba? Es un enfoque más honesto y útil.

5. Publicación en el calendario

Probablemente, el criterio de publicación crucial más común sigue siendo el calendario. La gente eligió una fecha y ahora la van a soltar porque llegó esa fecha. Por supuesto, hay problemas externos que influyen en su cronograma de lanzamiento, pero el hecho de que haya llegado una fecha no significa que esté bien enviar un software de mala muerte a sus desprevenidos clientes que pronto serán antiguos clientes. Suelte cuando esté listo / seguro / estable / bueno. Si el calendario es una restricción fija, asegúrese de que su proceso lo lleve a tiempo.

En conclusión…

¿Cuántas veces puedes lanzar así antes de pagar el precio? En nuestra analogía con la ruleta rusa, como máximo seis, tal vez tan solo uno. Hagamos nuestro mejor esfuerzo para asegurarnos de que entregaremos el mejor software con las mayores posibilidades de éxito.

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft