Exigences, Design et Organisation dans le processus de conception des logiciels Open Source

1
Exigences, Design et Organisation dans le
processus de conception des logiciels Open Source

• Quentin Dallons Laurent Stalens
• Institut dinformatique FUNDP Namur
• Génie Logiciel matières approfondies
• Mars 2003

2
Plan

• Introduction
• Définitions
• Organisation Management Outils
• Exigences
• Design
• Conclusions

3
Introduction - 1

• Les Logiciels Open Source (LOS) sont
• Plus fiables
• Moins chers
• Plus performants
• Mieux adaptés à lutilisateur

4
Introduction - 2

• Pourquoi ?
• La méthodologie utilisée en Open Source est-elle
  la nouvelle Silver Bullet du Software
  Engineering ?
• Est-ce vraiment le cas ?

5
Introduction - 3

• Divers aspects à aborder
• Processus de spécifications (organisation,
  exigences, design)
• Aspects économiques de lOpen Source
• Cycle de vie dun logiciel Open Source

6
Définitions

• Les différents types de logiciels

Ref. C. Gacek, T. Lawrie, and B. Arief. The many
meanings of open source.
7
Organisation - 1

• Les participants à un projet Open Source

Ref. C. Gacek, T. Lawrie, and B. Arief. The many
meanings of open source.
8
Organisation - 2

• Outils utilisés dans les projets Open Source
• Outils de contrôle de version ( CVS et
  SubVersion)
• Outils de suivi de problèmes et de support
  technique (Bugzilla et Scarab).
• Outils de discussion technique et de raisonnement
  ( mailing listes, newsgroups, WikiWikiWeb, FAQ,
  ...
• Outils dautomatisation de la compilation (Make
  et Ant )
• Outils de design et de génération de code
  (ArgoUML et Torque)
• Des environnements de développement intégrés
  (Emacs, NetBeans et Eclipse)
• Des outils de test du code (Junit et Cactus)
• Des outils de packaging et de déploiement (Redhat
  Package Manager)

9
Exigences - 1

• Sources des exigences en Open Source

Mettre ref
10
Exigences - 2

• Les exigences sont informelles en Open Source

11
Exigences - 3

• Principaux domaines couverts en Open Source

12
Design 1

• Manque de design formel

13
Design 2

• Divergence entre architecture concrète et
  conceptuelle

Ref. J. B. Tran, M. W. Godfrey, E. H. S. Lee,
and R. C. Holt. Architecture analysis and repair
of open source software.
14
Design 3

• Problème de maintenance
• Dépendances et évolution du logiciel
• Relation entre ajout de modules et dépendances
• Méthode de réparation darchitecture

15
Conclusion - 1

• Pas de méthodologie propre
• Pas de formalisme des spécifications (exigences
  et design)
• Cest essentiellement le reviewing du code qui
  fait la qualité

16
Conclusion - 2

• Quelques propositions pour une méthodologie de
  développement plus formelle en Open Source.
• Exigences
• utiliser les procédures et outils actuels.
• bloquer la liste dexigences à la version
  courrante
• formalisation (UML, Meurise,...).
• raffinements successifs.
• développer un jeu de tests.
• Design
• spécifications des composants, les analyses des
  tâches pour la conception des IHM, les divers
  schémas de persistance, ...
• formalisation par méthodologies avérées (UML
  EA, ...)
• raffinements successifs.

17
Conclusion 3

• Choix dimplémentation
• Implémentation
• le fondateur du projet et son équipe principale
  veilleront à garder la cohésion entre le code et
  les spécifications. Les principes dorganisation
  et les outils habituels en développement Open
  Source seront utilisés.
• Remarque
• effectuer les différents correctifs de bugs tout
  en travaillant sur les nouvelles spécifications
  des exigences et de larchitecture de la version
  suivante du logiciel.