Contrôle des modifications et des évolutions
Objectif(s)
Une fois le logiciel développé, il faut mettre en œuvre des dispositifs de gestion des modifications et des évolutions pour garantir que la qualité du développement en terme de sécurité et de sûreté ne soit pas remise en cause.
Documents en entrée
Tous les documents se référant à la modification devant être menée (c'est à dire si il s'agit d'une modification d'une exigence du logicielle, il est vraisemblable que toute la documentation soit en entrée, mais pas forcément dans le cas d'une intervention située plus tardivement dans le cycle en V, pour une modification d'un algorithme de décision par exemple). En plus de cette documentation spécifique à la modification/l'évolution, il est nécessaire d'avoir en plus le plan d'assurance qualité du logiciel, le plan de gestion de la configuration du logiciel, la demande de modification (afin de formaliser celle ci) et une analyse d'impact des modifications demandées. En effet, toutes les modifications ne sont pas forcément acceptables.
Documents en sortie
En sortie de l'activité de modification, tous les documents qui auront été modifiés se retrouve ainsi que l'enregistrement de la nouvelle configuration qui aura évidemment évolué.
Contraintes
Les contraintes exprimées pour la modification d'un logiciel sont de deux ordres : d'abord définir et formaliser tout ce qui sera nécessaire à la compréhension de la nécessité de modification. Les documents de report de dysfonctionnement doivent par exemple être utilisés. Il faut également spécifier les procédures à suivre pour s'assurer de la bonne prise en compte de demande de modification.
L'analyse d'impact doit quant à elle définir ce qu'il est nécessaire de reprendre dans le cycle de développement appliqué pour le développement initial. Par exemple, supposons qu'il soit nécessaire de faire une modification sur une valeur limite d'une constante dans un module X. L'analyse d'impact, va devoir indiquer quelles sont les exigences à modifier et quelles seront les activités à remmener suite aux modifications. Si plusieurs modules sont développés, il ne sera peut être pas nécessaire de revalider l'intégralité des modules en rejouant tous les jeux de tests (si l'on ne se préoccupe que de cette phase pour l'exemple), mais l'analyse d'impact devra identifier les tests à rejouer lors du processus de test.
