Modèle de gouvernance sur le développement des logiciels

interne, souvent par d’anciens informaticiens ayant une bonne pratique de la conduite des projets : on parle de MOAD, pour maîtrise d’ouvrage déléguée.

Table des matières
Modèle de gouvernance sur le développement des logiciels 1
Introduction 1
I) Le développement des modèles linéaires 3
A) le modèle en cascade 3
B) Modèles en V 4
C) Le modèle en Y 4
II) LES MODELES ITÉRATIFS ET INCREMENTAUX 5
A) Définition 5
B) Le modèle en spirale 6
III) Les modèles agiles 6
A) Le manifeste agile : texte rédigé en 2000 par 17 experts du développement d’application informatiques 6
B) Les tendances software craftsmanship et clean code 7
C) Développement Lean et kanban 7
IV) Les autres modèles de développement : 7
V ) La qualité du logiciel et sa gestion 8
A) la qualité du logiciel 8
B) La gestion de la qualité 9
Le contrôle qualité 9
L’assurance qualité 9

Comme pour toutes les fabrications, il est important d\’avoir un processus bien défini et documenté. Dans le cas du logiciel, il s’agit d’un type de fabrication un peu particulier, en un seul exemplaire, puisque la production en série est triviale par simple recopie.

I) Le développement des modèles linéaires

Les modèles linéaires sont apparus pour compléter des modèles trop simples (développement sauvage) qui nécessitait peu de travail d’analyse et de conception en amont. Cela concernait les petits programmes et donc obsolète pour des développements sérieux.
A) Le modèle en cascade
Le modèle en cascade a été proposé par Winston Royce dans les années 1970. Dans ce cas de figure, chaque étape doit être terminée avant que ne commence la suivante. A chaque étape, il y a production d\’un livrable qui sert de base pour l’étape suivante. Si une erreur est constatée cela nécessite un retour à la phase ou l’erreur a été commise, c’est pour cela qu’il faut agir dans une démarche de qualité afin de «tout bien faire » dès le début.

Cette approche est simple à comprendre et a utilisé. Elle facilite l’organisation du travail et des équipes dans les grands projets. En revanche la méthode dite « cascade » est peu adaptée si les besoins du client sont changeant ou difficiles à déterminer. Il est donc plus pertinent d’y avoir recours sur des projets importants dans des domaines et avec des technologies bien connus et maîtrisés par les équipes de développement

Schéma représentant les étapes du modèles en cascade

Cette méthode constitue six ou sept étapes.
• L’analyse des besoins : on étudie la faisabilité du projet pour définir les besoins et les exigences. Seuls les processus majeurs sont concernés. Il faut chiffrer les charges et envisager des délais.
• L’analyse du système : cette étape permet de peaufiner les points vus dans l\’étape précédente. On peut commencer à traiter les points mineurs.
• Conception : ici on effectue les différents choix techniques.
• Implémentation et tests unitaires : dans cette étape on programme. En fonction du langage choisi, les développeurs vont programmer. Une fois terminé, on effectue des tests unitaires. Ces tests vont permettre de vérifier si tous fonctionnent correctement.
• Validation et tests d’intégration : le client à son tour effectue des tests pour valider le système. Les tests d\’intégration se font souvent avec les utilisateurs.
• Exploitation et maintenance : dans cette dernière étape, il ne reste plus qu’à déployer le système. Et la maintenance permet de corriger les problèmes et les anomalies.
Il n’est possible que de revenir une étape en arrière s’il y a un problème.

B) Le modèle en V
Variante du modèle de cascade, il met en évidence la complémentarité des phases menant à la réalisation et des phases de test permettant de la valider. Il est calquer sur la production industrielle classique et met en évidence les différents niveaux de test suivant :
– Test unitaire : test de chaque composant de l’application pris isolément
– Test d’intégration : test des interactions entre les composants de l’application
– Test de validation (test système) : validation par les développeurs du système complet par rapport à son cahier des charges
– Test d’acceptation (recette) : validation par le client du système complet par rapport aux besoins des utilisations
Les inconvénients sont similaires à ceux évoqués pour la cascade. Les avantages reconnus sont de placer la vérification et la validation au centre des préoccupations dès les premiers stades du développement et d’imposer l’idée de livrable évaluable. Ce modèle convient aux projets classique, mettant la fiabilité au cœur de leurs préoccupation.

C) Le modèle en Y
Autre variante du modèle de la cascade, il distingue une branche fonctionnelle et une branche technique. Il est adapté aux projets technologiquement innovants car il permet de lever au plus tôt les incertitudes liées aux technologies à mettre en œuvre.

L’approche habituelle, qualifiée de «prototypage rapide », s’appuie sur le développement rapide d’un prototype avec le client pour analyser ses besoins. Le client donne son feedback qui conduit à des adaptations successives du prototype. Le développement du logiciel final se fait ensuite de manière classique, à partir du cahier des charges qui reprend les besoins mis en évidence via le prototype , L’idée est de permettre la validation des spécifications par expérimentation: « Je saurai ce que je veux lorsque je le verrai !», Cette approche permet une validation beaucoup plus concrète besoins, ce qui minimise les risques d’erreurs à ce niveau. Par contre, la planification initiale du projet est délicate à faire.

II) Les modèles itératifs et incrémentaux

A) Définition
Dans ces approches le logiciel est développé en plusieurs itérations. Cela revient à répéter des mini-processus de développement, plus ou moins complets. Chaque itération correspond au raffinement d\’un développement précédent ou à l’ajout d’un incrément supplémentaire (d’où l’expression “itératif et incrémental”). C’est intéressant pour les projets de grande taille, car on peut obtenir rapidement un logiciel fonctionnel offrant les fonctionnalités de base.
Dans l\’approche la plus classique, le logiciel est spécifié et conçu dans son ensemble. C’est la conception détaillée et la réalisation (codage, tests unitaires, intégration à ce qui a déjà été développé, livraison) qui se font par itérations successives .
Les avantages sont de permettre de développer en premier les fonctions primordiales ou les plus risquées. Les clients peuvent réagir après chaque itération. On peut aussi obtenir un meilleure motivation de l\’équipe de développement qui voit se concrétiser plus rapidement ses efforts. Les autres difficultés, comme la nécessité de recueillir dès le départ ou de figer les besoins, demeurent. Dans d’autres approches, les itérations incluent l\’analyse et la spécification des besoins, ce qui exclut la possibilité d’une conception globale

Les avantages principaux sont d’avoir un recueil des besoins continu et évolutif, une détection précoce des erreurs, une implication continue des clients/utilisateurs. Les inconvénients majeurs sont liés à la difficulté de gérer les besoins ( “explosion des besoins ») et à la difficulté de définir les incréments. Une direction rigoureuse est nécessaire pour ne retomber dans les errements du code and fix

B) Le modèle en spirale

Le modèle en spirale de Barry Boehm (1988) et le processus unifié de James Rumbaugh.
Jacobson et Grady Booch (1999) sont des cas particuliers d\’approches itératives. Le modèle en spirale est parfois qualifié de « méta procédé » car il peut inclure une activité de choix du procédé de développement. Il met l\’accent sur l\’identification et la résolution des risques :
• humains, comme le manque de compétences, d\’expérience, de communication, de motivation,
• organisationnels, comme le manque de temps, de budget, la non-disponibilité de composants externes,
• technologiques, comme des exigences démesurées par rapport à la technologie, une technologie non maîtrisée, des problèmes de performance.

Chaque itération (ou cycle de la spirale) correspond à une séquence de quatre phases:
(1) La détermination des objectifs et des alternatives possibles pour les atteindre (comme développer, réutiliser, acheter, sous-traiter, etc.) et des contraintes (temps, coûts). Ces analyses se fondent sur les résultats des itérations précédentes ou initialement sur l\’analyse préliminaire des besoins.
(2) identification des risques et l\’évaluation des alternatives pour les résoudre, par exemple par du prototypage.
(3) Le développement et la vérification de la solution retenue, par un modèle de procédé à définir ( cascade, modèle en V)
(4) La revue des résultats et la planification des cycles suivants.
Ce type d\’approche convient pour de grands projets complexes, plutôt innovants et risqués.

Les approches qui précèdent sont fréquemment qualifiées de « prescriptive » ou « normatives » car elles imposent, avec des jonctions très précises, une manière de développer le logiciel : quelles activités, dans quels moyens, avec quelle organisation, selon quelle planification, avec quels confrères etc

III) Les modèles agiles

Ces approches cherchent à alléger le cadre et à rester focalisées sur le code. Plus concrètement, les approches agiles sont des approches itératives à planification simple et itératives très courte. Contrairement aux approches prescriptives qui définissent des ensembles de règles, les approches agiles sont plutôt à base de principes.

A) Le manifeste agile : texte rédigé en 2000 par 17 experts du développement d’application informatiques
– Propose de valoriser par exemple plus les individus et leur interaction plutôt que les processus et les outils
– privilégier le dialogue en face à face
– ou encore propose de valoriser des logiciels opérationnels plus qu’une documentation exhaustive

B) Les tendances software craftsmanship et clean code
Un autre manifeste, celui des « artisans du logiciel » (= software craftsmanship ») rédigé en 2009. Il prolonge le manifeste agile en soulignant qu’au-delà des aspects d’ingénierie, la compétence et le savoir-faire des développeurs sont primordiaux.
Exemples :
– Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus (« clean code »)
– Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels
C) Développement Lean et kanban

Le développement Lean

IL signifie « au plus juste ». C’est une méthode de gestion de la production développée chez Toyota dans les années 1980 qui est centrée sur la lutte contre le gaspillage.
Exemples :
– Éliminer ce qui n’apporte pas de valeur, les processus inutiles, les défauts, l’excès de fonctionnalité…
– Améliorer l’apprentissage
– Décidé aussi tard que jamais
– Donner le pouvoir à l’équipe

Le concept de Kanban

Le processus de production amont est piloté par le processus de production aval via les fiches Kanban : il n’y a production en amont que s’il y a consommation en aval avec échange de la fiche kanban quand le produit est consommé. L’ensemble découle de la demande des clients, on obtient ainsi des flux tendus avec un minimum de stocks intermédiaires. En développement, les « fiches kanban » sont affichés sur les murs de la salle de projet « war room » avec 3 statuts de tâches :
– « à faire »
– « en cours »
– « terminé »

IV) Les autres modèles de développement :
Le développement par assemblage de composants génériques suit des étapes dans l’ordre chronologique suivant :
– Recherche et évaluation des composants disponibles
– Résolutions des questions d’intégration des composants
– Mise en place d’une architecture d’accueil
– Intégration des composants dans cette architecture
– Test pour valider

Quant à l’approche formelle on distingue celle dotée d’une sémantique opérationnelle et celle dotée d’une sémantique axiomatique. Elles présentent quatre intérêts : apporter une sémantique claire, produire des descriptions précises, proposer des abstractions de haut niveau, permettre les manipulations automatiques. Cependant leur impact reste très limité.

Le développement de logiciels libres qui assure quatre libertés primordiales :
• La liberté d’exécuter le programme pour tous les usages
• La liberté d’étudier le fonctionnement du programme et l’adapter à ses besoins
• La liberté de redistribuer des copies
• La liberté d’améliorer le programme avec la possibilité d’en faire bénéficier toute la communauté.

V ) La qualité du logiciel et sa gestion
A) la qualité du logiciel
La notion de « qualité du logiciel » n’est pas simple à définir car elle est multiforme et dépend du point de vue adopté, client ou fournisseur.
Pour le client, le logiciel doit répondre à ses besoins (adéquation), être efficace, facile d’apprentissage et d’utilisation (ergonomie), être fiable, robuste et sûr, être peu coûteux et livré dans les délais.
Pour le fournisseur, le coût et la durée de développement sont généralement primordiaux, de même que la facilité d’extension, de maintenance, d’adaptation et d’évolution, ainsi que la portabilité et l’interopérabilité (capacité de systèmes, unités, matériels à opérer ensemble).

Il est important de ne pas confondre les termes qui caractérisent les différentes formes de qualité. La signification des plus courants d’entre eux est rappelée dans le tableau suivant.

On résume parfois la variété de ce qui est attendu d’un logiciel par le sigle CQFD, pour Coûts, Qualité, Fonctionnalités, Délais. Cette vision simplifiée est suffisante pour montrer les tensions qui peuvent exister entre les principaux critères. Idéalement, il faudrait pouvoir faire du logiciel « chic et pas cher » (F élevé et C faible), ce qui n’est pas simple, et de le faire « vite et bien » (D faible et Q élevé), ce qui n’est également pas évident !
Tous ces critères sont bien entendu à pondérer en fonction du type de logiciel à développer : du logiciel critique pour la sécurité (safety critical), dont les défaillances peuvent avoir des conséquences désastreuses en termes humains, économiques ou environnementaux, jusqu’au logiciel « jetable » moins exigeant.

B) La gestion de la qualité
Le contrôle qualité et l’assurance qualité sont deux aspects souvent distingués au sein de la gestion de la qualité.

Le contrôle qualité

Le contrôle qualité est l’ensemble de toutes les actions qui permettent d’assurer que les artefacts du développement satisfont leurs critères de qualité.
Ces actions se pratiquent tout au long du développement. Pour les codes, on peut pratiquer des contrôles statiques, c’est-à-dire sans exécution, comme les relectures (revues et inspections), les analyses de code, les preuves formelles, etc…, ainsi que des contrôles dynamiques, c’est-à-dire en exécutant les codes, comme les tests ou les prototypages. Pour les autres artefacts, on peut pratiquer des relectures, des vérifications de modèle (modèle checking), etc.
Exemple de techniques de relectures : autocorrection, relecture croisée avec un collège, la revue informelle (walkthtrough) ou le lecteur résume paragraphe par paragraphe le document qui est discuté informellement par le groupe de revue, la revue structurée autour d’une check-list, l’inspection plus lourde mais la plus efficace.

L’assurance qualité

L’assurance qualité recouvre la mise en place et la gestion de l’infrastructure qui englobe tous les moyens permettant de produire du logiciel de qualité : méthodes, outils, gestion de projet, contrôle qualité, etc.
Les gestionnaires et les techniciens doivent recevoir toutes les informations nécessaires pour établir leur confiance dans la qualité du logiciel produit.

Phénomène artificiel ou accidentel lors d’une expérience scientifique ou une observation.