Génie Logiciel Mejdi BLAGHGI - academiepro.com · Le génie logiciel (anglais software...

Génie LogicielGénie Logiciel

Direction Générale des Études Technologiques

Institut Supérieur des Etudes Technologiques de Djerba

Département Technologies de l’informatique

Mejdi BLAGHGI

��[email protected]

Chapitre 1 : Définitions et Chapitre 1 : Définitions et

principes de baseprincipes de baseprincipes de baseprincipes de base

�Le génie logiciel (anglais softwareengineering)

�C’une science de génie industriel qui étudieles méthodes de travail et les bonnespratiques des ingénieurs qui développent des

Définitions

Page

pratiques des ingénieurs qui développent deslogiciels. [Wikipedia]

�C’est l'ensemble des activités de conceptionet de mise en œuvre des produits et desprocédures tendant à rationaliser laproduction du logiciel et son suivi [JO Fr1984]

Génie Logiciel par M. BLAGHGI 3

�Les Coûts restent dans les limites prévuesau départ.

�La Qualité correspond au contrat de serviceinitial.

�Le système répond aux besoins des

Objectifs : Règle du CQFD

Page

�Le système répond aux besoins desutilisateurs et réalise les Fonctionnalitésdemandées.

�Les Délais restent dans les limites prévuesau départ.


Historique

PageGénie Logiciel par M. BLAGHGI 5

�TAURUS, un projet d'informatisation de labourse londonienne : abandonné après 4années de travail et 100 millions de £ depertes,

�Avion C17 livré avec un dépassement de 500

Célèbres exemples

Page

�Avion C17 livré avec un dépassement de 500millions de $ ... (19 calculateurs hétérogèneset 6 langages de programmation différents),

�Non différenciation entre avion civil et avionmilitaire : guerre du Golfe - Airbus iranienabattu : 280 morts


�Le logiciel est un objet immatériel, trèsmalléable au sens de facile à modifier�Ses caractéristiques attendues sont difficiles à

figer au départ et souvent remises en cause encours de développement

Raisons des problèmes

Page

cours de développement

�Les défaillances et erreurs ne proviennent nide défauts dans les matériaux ni dephénomènes d’usure dont on connaît les loismais d’erreurs humaines, inhérentes àl’activité de développement

�Le logiciel ne s’use pas, il devient obsolèteGénie Logiciel par M. BLAGHGI 7

�Carlo Ghezzi liste sept principesfondamentaux :�Rigueur�Séparation des problèmes�Modularité

Principes :

Page

�Modularité�Abstraction�Anticipation du changement�Généricité�Construction incrémentale


�La production de logiciel est une activitécréative, mais qui doit se conduire avec unecertaine rigueur.

�Le niveau maximum de rigueur est la

Principes : Rigueur

Page

�Le niveau maximum de rigueur est laformalité,�c’est à dire le cas où les descriptions et les

validations s’appuient sur des notations et loismathématiques.


�Stratégie générale du « diviser pour régner »

�Séparation dans le temps avec la notion decycle de vie du logicielSéparation des qualités que l’on cherche à

Principes : Séparation des problèmes

Page

�Séparation des qualités que l’on cherche àoptimiser à un stade donné

�Séparation des vues que l’on peut avoird’un système

�Séparation du système en parties


�Exemple 1 :Comment acheminer un email de façon sûr àtravers un réseau ?

�Solution :Décomposition en couches utilisée sur


Page

Décomposition en couches utilisée surInternet :�STMP : protocole de la couche application qui

suppose une couche de transport de paquet sûr.�TCP : protocole de la couche transport permettant

de s’assurer que tous les paquets arrivent, mêmesi le réseau peut perdre des paquets.


�Exemple 2 :Comment créer dynamiquement une pageinternet pour visualiser et modifier lecontenu d’une BD sans la corrompre ?

�Solution :


Page

�Solution :Décomposition en trois composants :�Modèle : son rôle est gérer le stockage des

données.�Vue : son rôle est formater les données.�Contrôleur : son rôle est de n’autoriser que les

modifications correctes.Génie Logiciel par M. BLAGHGI 12

�Un système est modulaire s’il est composéde sous-systèmes plus simples, ou modules.

�La modularité permet de considérerséparément le contenu du module et lesrelations entre modules.

Principes : Modularité

Page

relations entre modules.�Elle facilite la réutilisation de composants.�Un bon découpage modulaire se caractérise

par :�une forte cohésion interne des modules�un faible couplage entre les modules


�L’abstraction consiste à ne considérer que lesaspects jugés importants d’un système à unmoment donné, en faisant abstraction desautres aspects.

�L’abstraction permet une meilleure maîtrise

Principes : Abstraction

Page

�L’abstraction permet une meilleure maîtrisede la complexité.

�Exemple : circuit électronique


�La caractéristique essentielle du logiciel, parrapport à d’autres produits, est qu’il estpresque toujours soumis à des changementscontinuels :�corrections d'imperfections

Principes : Anticipation du changement

Page

�corrections d'imperfections�évolutions en fonctions des besoins

�Il faut par exemple :�faire en sorte que les changements soient les plus

localisés possibles (bonne modularité),�être capable de gérer les multiples versions des

modules et configurations des versions.


�Il est parfois avantageux de remplacer larésolution d’un problème spécifique par larésolution d’un problème plus général.

�Cette solution générique (paramétrable ouadaptable) pourra être réutilisée plus

Principes : Généricité

Page

adaptable) pourra être réutilisée plusfacilement.

�Exemple : cas d’une template web :�Plutôt que de définir un style spécifique pour un

moyen de visualisation particulier, écrire (ouréutiliser) une feuille de styles.


�Un procédé incrémental atteint son but parétapes en s’en approchant de plus en plus.

�Chaque résultat est construit en étendant leprécédent.

Principes : Construction incrémentale

Page

�Par exemple :�réaliser d’abord un noyau des fonctions

essentielles et ajouter progressivement lesaspects plus secondaires.

�construire une série de prototypes simulant plusou moins complètement le système envisagé


Chapitre 2 : Processus Chapitre 2 : Processus

et Cycles de vieet Cycles de vieet Cycles de vieet Cycles de vie

Les acteurs dans la vie du logiciel

Maître d’ouvrage (MO)

� Commande le logicielet assure la relationentre les usagers etles développeurs

Maître d’œuvre (ME)

� Responsable du suiviet développementlogiciel

Page

les développeurs

� Utilisateur(s) � Programmeur(s)


� Projet :� Ensemble d’activités organisées permettant de créer un

produit ou un service avec une qualité définie dans le cadred’un budget fixé.

� Processus :� Savoir-faire associé à une discipline

Terminologie

Page

� Savoir-faire associé à une discipline� Un processus est un ensemble structuré :

• d’acteurs

• d’activités pour chaque acteur (code, planification, …)

• d’artefacts pour chaque activité (exécutable, planning…)

• de workflows (un workflow = un ensemble d’activités)

� Un processus peut lui-même englober des sous-processus


�Un processus regroupe un ensemble d’étapes(dites activités, phases)�Séquentielles :

• Définition des besoins• Analyse / Conception

Processus de développement de

logiciels

Page

• Analyse / Conception• Implémentation• Validation et tests• Déploiement et maintenance

�Permanentes (horizontales) :• Produits intermédiaires• Plan d’assurance qualité et documentation• Gestion de projet, des ressources


�Permet d’assurer le cycle de vie du logiciel :�Depuis sa création … jusqu’à son retrait�En passant par sa distribution sur un marché�Ensemble séquentiel de phases : déterminées en

fonction des besoins du projet

Processus de développement de

logiciels (2)

Page

fonction des besoins du projet


Exemple de processus de

développement


=

enchaînement

des activités

RUP (Rational Unified Process)

Retrait et remplacement


MaintenanceMaintenance

Mise en exploitation


Définitions des besoinsDéfinitions

des besoins

ObjectifsObjectifs

Les étapes du cycle de vie

Page

QualificationQualification

Validation et intégration


Implémentation et tests unitairesImplémentation et tests unitairesConceptionConception

PlanificationPlanification

Analyse des besoins

Analyse des besoins


Vie du logiciel


(d’après J. Printz)

67% du coût total d’un logiciel � maintenance (dont 48% à réparer des défauts)

60% des défauts correspondent à des erreurs de spécification et de conception(d’après A.-M. Hugues)

Répartition des phases


�Ensemble séquentiel d’étapes

Cycle de vie et qualité

Activitéprincipale

Intrants (autres processus) Extrants (autres process us)

Validation / VérificationDocGestion des versions, tests

Page

�Cycle de vie et assurance qualité lié :�Assurance qualité : contrôles réguliers dont :

• Validation : le bon produit ?• Vérification : le produit correct ?

�Solutions pour réduire les erreurs : prototypes,maquettes, documents de spécif, conception,tests, …


ObjectifsObjectifs



MaintenanceMaintenanceAnalyse des besoins

Analyse des besoins


des besoins


Page






Implémentation et tests unitairesImplémentation et tests unitaires

ConceptionConception



�Objectifs :�Schéma directeur, étude d’opportunité

(avantages, risques)

�Besoins :�Définition du Cahier des Charges (CdC)

Objectifs et définition des besoins

Page

�Définition du Cahier des Charges (CdC)�Consultation des intervenants du projet�Description du produit à partir de scénarii

d'utilisation (use cases)

�Un appel d'offres est peut êtreéventuellement lancé


� Spécifications :� Fonctionnelles et non fonctionnelles� Base du contrat commercial avec le client

� Comprendre et modéliser le métier� Contraintes de réalisation, ébauche du manuel utilisateur,

glossaire

Analyse des besoins et du système

Page

glossaire�Maquettes, prototypes, spécification d’interfaces, simulation

�Maquette :� Système incomplet� Tester l’ergonomie� Dialogue entre développeur et utilisateur� Ne permet pas de tester : performance / temps de réponse


� Prototype (dans un langage quelconque)� Faisabilité du système, oublis de spécification, contradictions� Fonctionnalités finales : sans contraintes de fiabilité,

robustesse

� Spécification d’interfaces : Maquette pour validerl’IHM

Prototypes, spécification d’interfaces

et simulations

Page

l’IHM�Outils de simulation :

� Comparer plusieurs solutions envisageables, étude defaisabilité

�Méthodes utilisées :� Théorie des réseaux de files d'attente (le plus utilisé)� Réseaux de Pétri (petits systèmes)� Chaînes de Markov (petits systèmes)


ObjectifsObjectifs




Analyse des besoins


des besoins


Page










�Gestion de projet (matériel et logiciel) :�Découper en tâches puis les ordonnancer (MS

Project)�Système de contrôle pour les produits

intermédiaires du cycle de vie

Planification et gestion de projet

Page

intermédiaires du cycle de vie

�Gestion de projet (humain) :�Organiser la formation sur les méthodes, outils,

nouvelles technologies�Motiver les équipes, anticiper les problèmes


�Gestion de la configuration�Assurer la cohérence des composants et leur

évolution au cours du temps�Nombreux outils pour faciliter :

• la gestion des versions (CVS, SVN)

Planification et gestion de projet

(2)

Page

• la gestion des versions (CVS, SVN)• la reconstruction du système (Ant, Maven, Make)

�Plan qualité, suivi de projet, documentation


�Choix d’une architecture techniques :�Suivant certaines priorités�Expertise informatique

�Modèles conceptuels :�Méthodes graphiques : Merise (MCD, MCT) - UML

Conception d’une solution

(structurée ou OO)

Page

�Méthodes graphiques : Merise (MCD, MCT) - UML(diagrammes de classes, d’états, …) - Réseaux dePetri

�Méthodes formelles : automates (langage VDM, Z,Larch, Eiffel)

�Dossier de conception, plan d'intégration desmodules, plans de tests


Modèles conceptuels : UML


Tiré de : http://www-lipn.univ-paris13.fr/~gerard/index.php/uml

�Implémentation + documentation :�Environnements de développement (AGL :

Microsoft Visual C++, Dev C++, Windev, Eclipse,Borland Turbo Pascal, Oracle Designer, …)

�Outils de génération de code (Rational Rose,

Codage

Page

�Outils de génération de code (Rational Rose,Topcased, Omondo, …)

�Réutilisation de composants existants (DesignPatterns, Java Beans)


�Tests de vérification (le produit correct ?)�De la robustesse et cohérence du système (cas

d’exceptions)�Environnements de tests unitaires (JUnit, Boost,

JML)

Tests

Page

JML)

�Tests de validation (le bon produit ?)�En accord avec les besoins du client�Une fois les tests de vérification satisfaits


ObjectifsObjectifs




Analyse des besoins


des besoins


Page










�Intégration matérielle et logicielle :�Modules intégrés avec les autres (plan

d'intégration)�L'ensemble est testé conformément au plan de

tests

Intégration et qualification

Page

tests

�Qualification (une fois le logiciel terminé) :�Produit testé dans des conditions normales

d'utilisation�A l'issue de cette phase, le logiciel est prêt à la

mise en exploitation


�Correction des erreurs :�robustesse

�Demandes d’évolution :nouvelles fonctionnalités, portabilité, …

Maintenance et évolution

Page

�nouvelles fonctionnalités, portabilité, …

�Etape longue, critique et coûteuse :�80% de l’effort de certaines entreprises


�Méthodes prédictives (GL traditionnel) :�on planifie au début du projet

�Méthodes adaptatives (agiles) :Intègrent le changement

Deux grandes approches

Page

�Intègrent le changement�La planification est réévaluée au cours du

développement


Deux grandes approches


�Création : 1970�Séquentiel linéaire�L’un des premiers

modèles proposésEx : Merise

Modèle en cascade

Conceptiongénérale

Conceptiondétaillée

Validation

Vérification

Vérification

Spécifications

Page

�Ex : Merise


Codage

Intégration

Mise en production

Maintenance

Vérification

Tests unitaires

Tests d’intégration

Validation

Erreur de spécification trouvée en maintenance :

coûte + de 100 fois + cher que si trouvée lors des spécifications

� Les vrais projets suivent rarement undéveloppement séquentiel

� Établir tous les besoins au début d’un projet estdifficile

� Applicable pour les projets bien compris et maîtrisés

Problèmes du modèle en cascade

Page

� Applicable pour les projets bien compris et maîtrisés� Pas de frontière claire entre conception et

développement� Cadre de développement rigide et non transparent

au client� Le produit apparaît très tard� Risques élevés et non contrôlés


Modèle en V

Définition des testsSpécifications fonctionnelleset planification

Conception détaillée

Conception globale

Tests unitaires

Intégration

Qualification

Définition du plan d’intégration

Horizontal : préparation de la vérification

Ver

tical

: dé

velo

ppem

ent d

es m

odul

es


Programmation

Gestion des configurations

Gestion de projet

Plan assurance qualité

Ver

tical

: dé

velo

ppem

ent d

es m

odul

es

�Avantages :�Permet une meilleure anticipation, validation

intermédiaire�Evite les retours en arrière

Avantages et inconvénients du

cycle en V

Page

�Inconvénients :�Le cadre de développement reste rigide�La durée est souvent trop longue�Le produit apparaît toujours très tard


� Chaque nouvel incrément :� a pour objectif la maîtrise d'une partie des risques� apporte une preuve de faisabilité ou d'adéquation avec les

objectifs

� Développement logiciel :� processus graduel d’élimination des risques

Modèle itératif

Page

objectifs

48

A chaque itération :

1. Spécification2. Conception

3. Implémentation4. Tests

Génie Logiciel par M. BLAGHGI

�Basé sur les maquettes / prototypes�Vérifier l’efficacité réelle d’un algorithme�Identifier les besoins (prototype jetable)�Implémenté par des générateurs de code

(prototype évolutif)

RAD(Rapid Application Development)

Page

(prototype évolutif)


�Avantages :�Client : acteur dans le processus et reçoit des

résultats rapidement�Temps de développement très court

RAD(Rapid Application Development)

Page

�Inconvénients : prototyper n’est pas spécifier�Qualité du produit développé souvent faible�Pour des petits projets ou à courte durée de vie�Approprié pour les systèmes dont la modularité

est évidente


Modèle incrémental

Combine des éléments des modèles linéaires et du prototypage

utilisé quand il n’y a pas assez de ressources disponibles pour une livraison à temps


Produit opérationnel :incréments livrables

�Le premier incrément est souvent le noyau

� Les incréments aident à gérer les risques techniques (matériel non disponible)

Modèle en spirale

communiquer avec le clientrisques techniques et de gestion

Couplage de la nature itérative du prototypage avec les aspects contrôlés du modèle en cascade


construire, tester, installer

définir les ressources, la répartition dans le temps

Réduit les risques si bien

appliqué

eXtreme Programming (XP)

« Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaires et être aussi réactifs que possible ? »

Pour des petits projets (moins de 10 personnes)

Valeurs d’XP :

1. Communication


1. Communication

2. Feedback

3. Simplicité

4. Courage

Inconvénients :- Phase d’analyse pas assez couverte- Manque de contrôle et de structuration

A suivre …A suivre …

Génie Logiciel Mejdi BLAGHGI - academiepro.com · Le génie logiciel (anglais software...

Documents

Transcript of Génie Logiciel Mejdi BLAGHGI - academiepro.com · Le génie logiciel (anglais software...