Analyse comparative du guide swebok et des principes fondamentaux du génie logiciel

Le standard IEEE 610.12 [1] de l’Institute of Electrical and Electronics Engineers (IEEE) définit le génie logiciel comme étant l’application d’une approche systématique, disciplinée et quantifiable pour le développement, l’opération et la maintenance du logiciel; c’est-à-dire l’application du génie au logiciel. Mais, le génie logiciel est une discipline encore jeune et il existe encore des zones grises dans sa reconnaissance comme discipline du génie. Comme le souligne Gabrini [2], lorsqu’il est question de développement de logiciel, il y a manipulation d’idées abstraites et le logiciel n’est pas aussi contraint que les ponts par les lois de la physique et du monde qui l’entoure. Il y a aussi Kruth [3] qui suggère que le développement de logiciel est plus un art qu’une science.

En fait, la reconnaissance du génie logiciel comme discipline du génie n’est que toute récente [4] et exige que des efforts significatifs soient investis pour en améliorer les bases. En particulier, un besoin a été identifié pour découvrir, et graduellement reconnaître, des principes spécifiques au domaine qui doivent devenir l ‘un des fondements du génie logiciel [5]. L’identification des connaissances généralement reconnues en génie logiciel a déjà produit un ouvrage présentant les différents domaines de connaissances de la discipline [ 6]. Par contre, en raison de la dynamique des changements techniques et technologiques, et de la jeunesse de la discipline, les résultats obtenus de cette identification doivent continuellement être révisés pour refléter la réalité du temps. Cette base en mouvement de la discipline confirme ce besoin d’effectuer des travaux de recherche pour définir ce qui doit constituer la base de la discipline, pour en faciliter l’évolution et la maturation.

Les principes fondamentaux sont l’une des pièces maîtresses qui doivent composer cette base de la discipline. Comme le présente Bourque et al. [5], l’identification des principes fondamentaux du génie logiciel est influencée par les principes fondamentaux plus généraux s’appliquant à l’ensemble des disciplines du génie. Les principes fondamentaux du génie logiciel soutiennent à leur tour les pratiques et les normes de la discipline.

Mais, il faut comprendre que le génie logiciel ne possède pas actuellement une liste de principes fondamentaux reconnue par l’ensemble des intervenants de la discipline. Celle-ci (la liste) n’étant pas reconnue, la discipline repose sur une base en mouvement. Certains ouvrages ont été écrits dans le but d’identifier des principes devant faire partie de cette liste. Ainsi, des principes fondamentaux candidats ont été suggérés par Bourque et al. [5] pour répondre à cette préoccupation. Ceci et d’autres ouvrages identifiés dans Séguin [7], représentent une avancée importante et suggèrent davantage d’investigation et de validation dans la discipline du génie logiciel pour définir une liste de principes fondamentaux reconnus.

Tel que le décrit Séguin [7], en référence aux bases du génie logiciel, l’établissement d’une liste de principes fondamentaux du génie logiciel permettrait d’obtenir un cadre d’analyse pour les normes et les pratiques, et faciliterait leur reconnaissance par la discipline. Il existe déjà des normes qui ont été définies par différents organismes et le corpus de connaissances du génie logiciel fait l’objet d’un consensus d’envergure international. Le «Guide to the Software Engineering Body of Knowledge » (Guide SWEBOK) [6] constitue ce consensus et peut servir de base de comparaison pour réaliser une validation préliminaire des principes fondamentaux identifiés en [ 5] et pour effectuer certains ajustements à cette liste. Lorsqu’une liste de principes fondamentaux aura été reconnue par la discipline, il sera possible d’en vérifier l’application dans les pratiques et les normes existantes pour identifier des améliorations possibles à celles-ci. C’est au niveau de la validation préliminaire des principes fondamentaux que se situe l’analyse présentée dans ce document.

Pour réaliser notre étude, nous utiliserons le cadre de Basili [8] adapté pour la recherche exploratoire en génie logiciel. Le premier chapitre du document présente cette adaptation. Chacun des chapitres suivants est structuré pour refléter les différentes phases du cadre de Basili alignées sur les objectifs de l’étude. nous comparons les quinze (15) principes fondamentaux identifiés par Bourque et al. [5], par rapport aux connaissances généralement reconnues de la discipline du Guide SWEBOK [6], pour:
a. évaluer le niveau et l’étendue de la correspondance de ces principes par rapport aux connaissances généralement reconnues;
b. identifier les notions dans les connaissances généralement reconnues pouvant servir de base à la production d’une description d’accompagnement pour chacun des principes fondamentaux;
c. produire les descriptions d’accompagnement pour les principes fondamentaux de Bourque et al. [5];
d. identifier des pistes d’améliorations au Guide SWEBOK ou à la discipline.

Connaissances généralement reconnues 

Le corpus de connaissances existe dans la littérature du génie logiciel. Le but du Guide SWEBOK [6] est de décrire quelle portion de cette littérature est «généralement reconnue», d’organiser cette portion et de fournir un accès par sujet à celle-ci. Cinq objectifs ont permis de définir le contenu du Guide SWEBOK (voir [CH1P2]):
a. Promote a consistent view of software engineering worldwide.
b. Clarify the place – and set the boundary – of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics.
c. Characterize the contents ofthe software engineering discipline.
d. Provide a topical access to the Software Engineering Body ofKnowledge.
e. Provide a foundation for curriculum development and individual certification and licensing material.

L’organisation hiérarchique du Guide SWEBOK a été définie pour répondre à ces objectifs et pour être compatible avec les principales écoles de pensée de l’industrie, la littérature et les standards de l’ingénierie du logiciel. La taxonomie présentée est celle nécessaire pour permettre une compréhension de la nature de la connaissance «généralement reconnue» des sujets et pour faciliter la recherche d’informations lorsque le guide est utilisé comme ouvrage de référence.

LIRE AUSSI :  Mémoire Online: Etudes expérimentales des couches minces Ni 100-x-Px électrochimiques

Quant à la profondeur du traitement des sujets, il a fallu faire la distinction entre la connaissance « généralement reconnue », la connaissance « avancée » et provenant de la recherche (associée à la maturité du sujet), et la connaissance« spécialisée» (associée à la généralisation de l’application). Une définition produite par le Project Management Institute (PMI), a été choisie à ce niveau pour définir la connaissance « généralement reconnue» (voir la référence dans le Guide SWEBOK [CH1P3]) : «The general/y accepted knowledge applies to most projects most of the ti me, and widespread consensus validates its value and effectiveness ».

Principe fondamental vs Connaissance généralement reconnue 

Il faut comprendre que c’est par les ressemblances entre les concepts de «principes fondmnentaux » et de « connaissances généralement reconnues » que l ‘étude est rendue possible. Les définitions de «principe fondamental » et de « connaissance généralement reconnue » sont assez similaires même si des méthodes différentes de recherche les ont produites. Les principes fondmnentaux de l’étude et le Guide SWEBOK ont été produits grâce à l’implication d’un grand nombre d’intervenants de la discipline. Les processus utilisés dans les deux cas facilitent l’atteinte d’un consensus permettant le regroupement de spécialistes de la discipline dans la réalisation du projet.

Pour produire la liste des principes fondamentaux de l’étude, Bourque et al. [5] ont suivi le processus suivant:
a. recommandations pour l’identification de principes fondamentaux du génie logiciel lors d’un premier atelier de travail tenue dans une conférence internationale lors d’un premier atelier de travail tenue dans une conférence internationale;
b. définition des critères pour l’identification et l’évaluation des principes proposés;
c. soumission de 65 principes candidats dans une première ronde d’étude « Delphi » (cotation sur l’importance à accorder à chacun des principes et vote sur l’acceptation de la moyenne de cotation obtenue par 14 participants);
d. évaluation des principes fondamentaux candidats par des experts internationaux de la discipline, lors d’un deuxième atelier de travail également tenu dans une conférence internationale [35];
e. soumtsston de la liste améliorée de pnnctpes fondamentaux avec les recommandations des experts, pour une deuxième ronde d’étude « Delphi » (72 participants);
f. évaluation des pnnctpes fondamentaux candidats par les membres du Technical Council on Software Engineering du IEEE Computer Society à l’aide d’un sondage par Internet (574 participants).

Table des matières

INTRODUCTION
CHAPITRE 1 MÉTHODE DE RECHERCHE
1.1 Définition du projet
1.2 Planification du projet
1.3 Exécution du projet
1.4 Interprétation
CHAPITRE 2 DÉFINITION DU PROJET
2.1 Motivation
2.1.1 Principes fondamentaux
2.1.2 Connaissances généralement reconnues
2.1.3 Principe fondamental vs Connaissance généralement reconnue
2.1.4 Apport de l’étude
2.2 Objet de l’étude
2.2.1 Guide SWEBOK
2.2.2 Fundamental Principles of Software Engineering- A Journey
2.3 Objectifs de l’étude
2.4 Utilisateurs
CHAPITRE 3 PLANIFICATION DU PROJET
3.1 Étapes du projet
3 .1.1 Analyse de la correspondance
3.1.2 Production des descriptions d’accompagnement
3.2 Les intrants
3.3 Les livrables
CHAPITRE 4 EXÉCUTION DU PROJET
Analyse de la correspondance
Apply and use quantitative measurements in decision-mak:ing
Build with and for re use
Control complexity with multiple perspectives and multiple levels of
abstraction
De fine software artifacts rigorously
Establish a software process that pro vides flexibility
Implement a disciplined approach and improve it continuously
Invest in the understanding ofthe problem
Manage quality throughout the life cycle as formally as possible
Minimize software component interaction
Produce software in a stepwise fashion
Set quality objectives for each deliverable product
Since change is inherent to software, plan for it and manage it
Since tradeoffs are inherent to software engineering, mak:e them explicit and document them
4.1.14 To improve design, study previous solution to similar problems
4.1.15 Uncertainty is unavoidable in software engineering, identify and manage it
4.1.16 Présentation de la correspondance dans les domaines connaissances
4.2 Production d’une description d’accompagnement par principe fondamental
4.2.1 Apply and use quantitative measurements in decision-making
4.2.2 Build with and for reuse
4.2.3 Control complexity with multiple perspectives and multiple levels of abstraction
4.2.4 Define software artifacts rigorously
4.2.5 Establish a software process that pro vides flexibility
4.2.6 Imp1ement a discip1ined approach and improve it continuous1y
4.2.7 Invest in the understanding ofthe problem
4.2.8 Manage quality throughout the life cycle as formally as possible
4.2.9 Minimize software component interaction
Produce software in a stepwise fashion
Set quality objectives for each deliverable
Since change is inherent to software, plan for it and manage it
Since tradeoffs are inherent to software engineering, make them
explicit and document them To improve design, study previous solutions to similar problems
Uncertainty is unavoidable in software engineering, identify and manage it
Présentation de pistes d’amélioration
Apply and use quantitative measurements in decision-making
Build with and for reuse
Control complexity with multiple perspectives and multiple levels of
abstraction
De fine software artifacts rigorously
Establish a software process that pro vides flexibility
Implement a disciplined approach and improve it continuously
ln v est in the understanding of the problem
Manage quality throughout the li fe cycle as formally as possible
Minimize software component interaction
Produce software in a stepwise fashion
Set quality objectives for each deliverable product
Since change is inherent to software, plan for it and manage it
Since tradeoffs are inherent to software engineering make them explicit
and document them To improve design, study previous solution to similar problems
Uncertainty is unavoidable in software engineering, identify and manage it
Évaluation globale de la correspondance
Sommaire
CHAPITRE 5 INTERPRÉTATION
5.1 Contexte d’interprétation
5.2 Extrapolation
5.3 Travaux subséquents
5.4 Récapitulation
CONCLUSION

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *