Le génie logiciel

Introduction

Ensembles des activités nécessaires à la production de systèmes logiciels

Un système logiciel n'est pas que du code (ou qu'une application) réalisant certaines fonctionnalités poru l'utilisateur:  

  • doit interagir avec d'autres systèmes non prévus au départ
  • doit supporter des évolutions
  • doit pouvoir être maintenu

D'après, Mythical Man-Month, la réalisation d'un système logiciel packagé (software system product) demande 9 mois plus de temps que la réalisation du seul logiciel dans des conditions idéales:

Nécessité d'une méthode de développement (Méthodologie = étude des méthodes), définition d'un processus industriel de développement (industrialisation des développements):  

Difficile à mettre en oeuvre dans un cadre pédagogique.

Méthodes de développement

Existe de très nombreuses méthodes et normes de développement. Les plus connus (en FRance):  

Méthodes définissent tout ou partie des éléments suivantsn :

Normes (CMMi, SquareD) définissents des critères "objectifs" permettant d'industrialiser les processus de développements. L'hypothèse est que la normalisation d'un processus induit la normalisation du résultat de ce processus, donc une qualité optimale.  

Pb: il ne s'agit pas de processus mécaniques mais de processus Humains donc sujets à erreurs, omissions mais aussi à l'imprévu et le génial.  

Tendances actuelles (pays anglophones): méthodes agiles sur le modèle japonais tendant à accroitre la productivité et la réactivité des développements (Lean software development, extreme programming, Scrum, Crystal Clear ...). Méthodes centrées sur:

Amélioration globale de la productivité des équipes et de la satisfaction du client, tout en collant le plus possible à l'évolution des besoins.  

Transposition dans le domaine du génie logiciel des méthodes de production japonaises: Toyota Production System, Scrum. Production extrêmement réactive, systèmes de files d'attente (pipelines) et de production à la demande (pull vs. push).

Activités du GL

Principales phases traditionnellement identifiées

Cycle de développement :: Enchaînement de plusieurs phases les unes aux autres:

  1. besoins
  2. analyse
  3. conception
  4. développement
  5. recette
  6. maintenance

Notion de rétroaction (feedback): flux d'information normal (modèle cascade de 1 vers 5, puis retour vers 1.  

Objectif: raccourcir le cycles de développement:  

Autres activités

La qualité des logiciels

Think

"...well over half of the time you spend working on a project (on the orderof 70 percent) is spent thinking, and no tool, no matter how advanced, canthink for you. Consequently, even if a tool did everything except thethinking for you -- if it wrote 100 percent of the code, wrote 100 percentof the documentation, did 100 percent of the testing, burned the CD-ROMs,put them in boxes, and mailed them to your customers -- the best you couldhope for would be a 30 percent improvement in productivity. In order to dobetter than that, you have to change the way you think." -Frederick P. Brooks, [paraphrased]

Le développement logiciel est une activité intellectuelle: près de 70% du temps passé dans un projet l'est à réfléchir et concevoir quel que soit le type de projet. Donc:

  1. la marge de manoeuvre pour automatiser et outiller est faible: 30%du coût total
  2. il vaut mieux apprendre à mieux réfléchir (ie. former mieux lesingénieurs, améliorer la qualité des développeurs)

Le coût de la qualité

(d'après Understanding Software CostsB.Boehm et al., TSE 1988

Faster, better, cheaper: choose two as you cannot get all three

Analyse des coûts du développement des logiciels. On constate un ratio de productivité pouvant aller de 1 à au moins 10 entre les développeurs et les équipes.  

Deux approches sont possibles:

  • faible coût + faible qualité: augmentation du TCO. On constate quele coût de développement des projets HQ est le double des projetsLQ, mais que le coût de maintenance est de la moitié: tout dépendde l'horizon de vie du système développé
  • faible coût + faible qualité: nécessite de revoir les pratiques etd'analyser la structure de coûts des logiciels

Analyse des facteurs influencant les coûts

Analyse expérimentale:

  1. le langage utilisé (4GL vs. 3GL) est un facteur importantd'accroissement  de la productivité (cependant, sa mesure restesujet à caution)

Observations:

  1. le nombre d'instructions à écrire augmente les coûts: réutiliserdes composants, utiliser des langages plus évolués et expressifs
  2. qualité des développeurs: l'accroissement du coût salarial sembleêtre inférieur aux bénéfices tirés de l'accroissement de la productivité
  3. volatilité des exigences: peut être gérée par un développementincrémental

P.ex: l'utilisation d'Ada semble augmenter le coût de 30% à court terme (formation, niveau de compétence plus élevé) mais le baisser de 40% sur le long terme.

Analyse de la distribution des coûts

Remaniement vs. développement

Le coût du remaniement du système (réécriture) est supérieur à 50% du coût des développements.  

  1. il est plus faible dans les phases initiales d'un projet
  2. il suit une distribution de Pareto (loi des 80/20)

L'identification et la gestion des risques permettent d'en limiter l'impact: modèle en spirale

  1. définition des objectifs/alternatives et contraintes
  2. analyse des risques, évaluations des alternatives, levée desrisques par prototypage, simulation, bouchonnage
  3. production, réduction des risques
  4. analyse des résultats obtenus, ajustement des plans

Autres coûts

  • documentation représente plus de la moitié du coût total
  • intensité capitalistique faible: la mise en place d'infrastructuresde développement, l'automatisation des processus (ie. usines àlogiciels) améliorent la productivité du travail

Chaîne  de valeur

Construction de la chaîne de valeur du développement logiciel: représentation de la contribution au coût total des différentes activités sur un projet:

  • activité opérationnelles (ie. dév) = 68% des coûts totaux
  • réécriture, ie. correction d'erreurs = 30% du coût total

La réduction du coût opérationnelle peut se faire de deux manières:

  1. réduire le coût de chaque opération: accroître l'efficacité  dechaque étape, supprimer des étapes en automatisant, supprimer dela réécriture (prototypage, détection précoce des erreurs)
  2. réduire le nombre d'opérations: réutiliser, simplifier

Opportunités de réduction des coûts

  • Efficacité de chaque étape de production Integrated Project SupportEnvironment
    • procees model
    • référentiel projet
    • support de toutes les activités (QA, Dev, RE, PM...)
    • IHM uniforme
    • outils de communication
  • automatisation:
    • documentation (ie. javadoc)
    • génération de code (ie. DSLs)
  • knowledge based software assistant: aides aux programmeurs,augmenter la pertinence de leurs décisions
    • outil cASE
    • RAD
    • rapid prototyping: langages dédiés à la conception et à laspécification
  • élimination d'informations: encapsulation, interfaces, isoler etneutraliser les sources de changement
  • simplification
    • supprimé le plaqué or (words are cheap: l'utilisateur/l'analystequi ne doit pas écrire le programme demandera desfonctionnalités inutiles, optionnelles, coûteuses et au finaluniquement décoratives)
    • second system syndrom: corriger d'un coup toutes les erreurs dupremier système
    • se concentrer sur les besoins réels (les spécifications écritesentraînent le plaqué or)
  • réutilisation de composants:
    • génération d'applications (ie. tableurs, SGBD intégrés typeDBase III ou Access)
    • pb de l'interfaçage des 4GL avec les systèmes classiques

Conclusion

  1. writing less code
  2. getting the best from people
  3. avoiding rework
  4. develop and use integrated project support env.