AlcionTech

Une exigence en ingéniérie informatique est un besoin fonctionnel ou technique que le produit du projet doit satisfaire. Il doit être idéalement sans ambiguité et purement quantitatif.
Example:

Le système doit afficher l'écran mis à jour en moins de 2s une fois le bouton de validation cliqué.

On ne le dira jamais assez: la gestion des exigences est une cause fondamentale de la réussite ou de l'échec d'un projet.
Dans un processus de développement, il est illusoire de croire que l'on n'aura jamais besoin de "revenir en arrière", c'est à dire de retoucher au jeu initial d'exigences. Le versionning d'exigences est une réalité au même titre que le versionning de code.
Dans encore trop de projets, les exigences sont gérées dans des documents Office qu'il est bien difficile de tenir à jour. Heureusement il existe des outils dédiés à la gestion des exigences facilitant la collecte, la collaboration et l'analyse d'impact tout au long du cycle de développement logiciel. On citera Telelogic doors et Borland Caliber mais il en existe d'autres sur le marché.
Ces outils sont en général des modules d'une suite de logiciels couvrant tout les aspects de l'Application Lifecycle Management (planifier, définir, concevoir, tester) à partir d'un repository unique de données.

Paris, les 2 et 3 mai 2007
La conférence agile sur les méthodes agiles !

Même si les attaques arrivent en général par le réseau, ce sont les outils que nous choisissons et nos pratiques de développement logiciel qui déterminent la résistance des systèmes aux attaques, et non pas l'intervention a priori ou a posteriori d'un ingénieur sécurité. Que de responsabilités !
Voici le résumé d'un guide de survie, "les 6 idées stupides en sécurité informatique", l'expérience montrant que ce sont les idées les plus séduisantes et/ou sensées qui conduisent aux pire catastrophes :

• Permissions par défaut : une expression à bannir. Le défaut doit être l'interdiction. Le firewall d'un site web qui rejette les URLs malicieuses ? Non, il ne laisse passer que les URLs autorisées.
• Liste des attaques : mauvaise approche, puisqu'il en arrive de nouvelles tous les jours (80000 virus identifiés). Il est plus facile de lister les utilisations légitimes d'un réseau ou d'une application, et de bannir tout le reste.
• Pénétration/correction : refuser la logique qui voudrait qu'un logiciel / un système puisse être amélioré au fur et à mesure que ses vulnérabilités sont découvertes. Si c'était le cas, IE serait devenu sûr et le nombre de vulnérabilités découvertes diminuerait. L'alternative ? Concevoir le logiciel avec la sécurité en tête. Des exemples : QMail, Postfix...
• Les hackers sont cool, il faut les excuser : non, ce sont des sociopathes qui détruisent volontairement.
• Former les utilisateurs : nécessaire mais insuffisant. Si ça marchait, personne n'ouvrirait plus de pièce jointe exécutable.
• Agir plutôt qu'attendre : non, car agir vite fait prendre les mauvaises décisions. Mieux vaut attendre d'avoir des retours d'expérience que d'installer la nouvelle passoire juste parce qu'elle est à la mode.
• un septième point ? A lire directement dans l'article, avec les exemples, assez savoureux.

Autre sujet, même question, celle de la confiance que l'ingénieur peut avoir dans le résultat de ce qu'il produit : les "Observations personnelles sur la sûreté de la navette spatiale" du (grand) physicien Richard Feymann.

Voici mes liens préférés pour trouver des informations utiles sur les tests, les outils, la démarche qualité, l'automatisation des tests, etc .... Une mine d'informations à découvrir sur :

• Qalinks : liens vers sites assurance qualité, tests, automatisation…
• Testissimo : sur les tests logiciels, actualités...
• Qualiteonline : management de la Qualité
• Allquality : qualité et systèmes de management
• SEI/CMMI : site de référence du CMMI