¿Qué elementos intervienen en una auditoría de software efectiva?

Hola,

Una de las preguntas que no se ha formulado es: ¿cuál es la naturaleza de la auditoría ? Podría estar relacionado con la seguridad en caso de un problema de seguridad crítico, modelado de amenazas, gestión de riesgos, etc.

Si ha definido la pregunta anterior, entonces está listo para seguir adelante. Los siguientes componentes serían hablar con los involucrados (a menos que sea compartimentado y un disco de un tercero) porque es probable que sepan dónde están enterrados muchos de los “cadáveres”. Puede que no sea culpa suya directamente, sino código escrito bajo plazos estrictos o código de estudiante. Esperemos que en este punto pueda consultar la documentación de requisitos y los resultados de las pruebas.

Desde allí puede comenzar una investigación exhaustiva del sistema. Cualquier cosa, desde los límites de la API del sistema, la versión del software y los inventarios de opciones, etc. Entonces, en última instancia, puede que tenga que presentar un informe de vulnerabilidad que puede hacerse público …

Como menciona Ron Brash, las auditorías generalmente están orientadas a un cierto aspecto: código, seguridad, accesibilidad, diferentes estándares adoptados. Ciertas industrias, como la farmacéutica, auditan productos de software de sus proveedores.
Para cada tipo de auditoría, encontrará mucho material escrito. El tema crítico es decidir qué tipo de auditoría tiene que enfrentar.

Descargo de responsabilidad rápido de que nunca he trabajado a través de una auditoría formal en ninguna capacidad profesional. Vi un día más o menos uno cuando estaba en la universidad, pero mi título es lo suficientemente mayor como para ir a la universidad …

Por lo tanto, esto puede sonar trivial, pero los requisitos del proyecto son probablemente críticos en muchos aspectos.

Me parece recordar que el enfoque en ese momento estaba en los puntos del software donde la información se movía de una ubicación a otra en el programa. Estos se desglosaron en algo como directo (asignaciones y parámetros), indirecto (almacenamiento común) y encubierto (comportamiento observable del programa afectado por los datos, como la longitud de una tabla que determina cuánto tiempo se tarda en ordenar). Por supuesto, también intentaron construir modelos matemáticos del programa, por lo que podrían no ser las mejores guías …

Pensando en cosas que me gustaría saber como programador uniéndome a un equipo, también incluiría planes de prueba, problemas conocidos, y esto puede sonar loco, pero me siento tentado a decir horarios antiguos e informes de tiempo, si son disponible. ¿Por qué? Si hay características de sonido simple que tomaron mucho tiempo en implementarse, hay algo mal con ese código que no aparecerá en ningún otro lugar.

Como dije, tome eso con un grano de sal y piense en ello como un punto para comenzar la discusión. Es un área donde no tengo más que una experiencia superficial.