Les ingénieurs systèmes ont longtemps considéré le V comme un élément fondamental d’une bonne ingénierie. Récemment, cependant, le V de l’ingénierie des systèmes a eu mauvaise réputation. La nouvelle génération d’ingénieurs le considère comme un symbole des pratiques d’ingénierie lentes et en cascade. Ils considèrent que ces pratiques ne sont pas pertinentes pour la vitesse requise pour le développement de logiciels.
Les partisans de l’ingénierie traditionnelle préfèrent le V aux méthodes « agiles ». Cela est particulièrement vrai lorsqu’il s’agit de systèmes critiques.
Qui devons-nous croire ?
Bien, si nous sommes honnêtes, lorsque le V existe comme une passe glorieuse pour un système entier, la nouvelle génération marque un grand point. Le V peut vraiment ralentir le développement d’un bon logiciel.
À la base, le V de l’ingénierie des systèmes est une construction logique. Il décrit la découverte des exigences du système en décomposant un système en parties plus petites, puis en assemblant et en validant ces parties.
Les ingénieurs système appliquent le V dans divers contextes. Le plus souvent, le V apparaît dans les grandes organisations, comme le ministère américain de la Défense. Il est également proéminent dans les institutions académiques.
Ces grands programmes ou organisations utilisent le V dans le cadre de leur processus d’exécution de haut niveau. Le flux de travail général comporte sept phases :
Le processus commence sur le côté gauche du V où (1) les concepts sont générés. Ensuite, (2) les exigences pour l’ensemble du système sont définies, décomposées et attribuées. Puis, (3) les composants du système sont conçus en détail.
L’implémentation se produit au bas du V (4). C’est là que les composants conçus sont créés selon les exigences de plus tôt dans le processus.
En remontant le côté droit du V, ces composants sont (5) intégrés ensemble dans le système final. Le système intégré est ensuite vérifié pour s’assurer qu’il répond aux exigences initiales et validé pour s’assurer qu’il répond aux besoins des utilisateurs (6). Enfin, (7) le système est livré et entretenu.
Défis de la V
L’exécution du processus de la V s’avère problématique pour de nombreux grands projets – en particulier ceux qui comprennent des logiciels.
Intégration
Un problème majeur est que l’intégration se produit trop tard dans le processus de développement. Les programmes s’appuyant sur le V attendent que les composants logiciels soient complets pour réduire les reprises d’intégration coûteuses.
L’intégration manuelle des composants logiciels prend énormément de temps. La réalité que nous savons tous être vraie est que le logiciel n’est jamais terminé. Les activités d’intégration laissées à la fin sont précipitées pour respecter le calendrier du programme.
Dans le V, les composants intégrés répondent généralement aux exigences fonctionnelles, mais ne sont souvent pas sûrs, sécurisés ou corrects.
Vérification &Validation
Attendre que le système ait été complètement intégré pour effectuer la vérification et la validation (V&V) aggrave ce problème. La mise en œuvre de correctifs entraîne des répercussions sur l’ensemble du système, ce qui rend difficile et coûteux le traitement des problèmes qui surviennent pendant la V&V.
Les programmes mettent souvent en place des correctifs » au niveau du système » au lieu de résoudre la racine du problème – une approche de fortune. Le risque logiciel est souvent atténué par des pratiques telles que les pare-feu au niveau du système et les logiciels antivirus plutôt que de l’aborder dans le code.
Les pansements diminuent les chances que les utilisateurs rencontrent la faille, mais la faille elle-même n’est pas corrigée et continue à se tapir dans le système.
Répondre au défi
Les concepts du V de l’ingénierie des systèmes ne sont pas le problème – c’est la structure du V qui ne s’applique pas aux logiciels
Les techniques modernes peuvent permettre l’intégration continue des logiciels, même sur de grands programmes. L’utilisation d’outils et de processus qui englobent l’intégration précoce et la vérification ne nie pas les concepts fondamentaux du V – ils améliorent le V afin qu’il fonctionne pour le développement de logiciels.
Le résultat final est un logiciel correct à la création, et un système moins cher, plus sûr et plus rapide à livrer.
.