Plan

Chapitre1: Introduction au Génie Logiciel (AGL)

Chapitre2: Fonctionnalités de base pour le management
d’un projet
Chapitre3: Processus de développement – Exemple
d’une démarche de développement objet basée UML
Chapitre4: Les découpages et les modèles de
développement
Chapitre5: Facteurs et Critères de Qualité du logiciel

14/10/2018 Dr. Aymen LOUATI 46

Étapes du processus de développement

Analyse des
Spécifications
besoins

Analyse du
Maintenance système

Validation Conception

Implémentation

14/10/2018 Dr. Aymen LOUATI 47

Analyse des besoins

Étape préalable si le client n’a pas une idée précise

du système à réaliser

o Étude informelle des fonctionnalités (externes) du

système sans considération technique: Point de vue
métier / utilisateur

o Aide au formalisme du problème à résoudre

o Production de documents textuels avec schémas,

graphes, etc.

14/10/2018 Dr. Aymen LOUATI 48

Spécifications

Ce que doit faire le système côté client

o Document précis spécifiant les fonctionnalités
attendues (contour fonctionnel)
o Base du contrat commercial avec le client
o Document facile à comprendre par le client / utilisateur
o (scénarios, interactions, enchaînement d’écrans)

Les spécifications ne sont jamais complètes et définitives

(évolution du domaine, besoins supplémentaires, …)

14/10/2018 Dr. Aymen LOUATI 49

Analyse du système

Quoi faire ? : comprendre et modéliser le métier

o Réflexion métier hors de toute considération technique
o Reste un support de discussion avec le client/utilisateur
(questions/réponses)
o Premier modèle du système (niveau métier)
o Identifier les éléments intervenant (acteurs) hors et
dans le système: fonctionnalités, structure et
relations, états par lesquels ils passent suivant
certains événements
L’analyse n’est jamais complète, mais elle doit être juste
Établissement du cahier des charges
et des contraintes du système
14/10/2018 Dr. Aymen LOUATI 50
Conception

Comment faire le système: choix techniques

 Choix d’une architecture technique (matérielle,
logicielle) suivant certaines contraintes (robustesse,
efficacité, performances, portabilité …)
 Expertise informatique: hors compréhension du client
 Modèle de l’architecture logicielle du système
• Décomposition en sous systèmes: application
(interfaces), domaine (métier) et infrastructure
(implémentation)
• Permet la définition des phases d’implémentions,
de validation et de maintenances
Production d’un modèle du système final
en cohérence avec les choix d’architecture
14/10/2018 Dr. Aymen LOUATI 51
Implémentation

 Trop de temps consacré à cette phase au détriment

d’analyse et de conception: mauvaise pratique, parfois
très coûteuse …

 Nécessite un savoir de la réutilisabilité des

composants, voir d’outils de génération de code (voir
MDA)

 L’activité sera de plus en plus tournée vers la

réutilisation des composants existants

14/10/2018 Dr. Aymen LOUATI 52

Validation

 Tests de vérification
o Vérification de la robustesse et cohérence du système,
en particulier dans les cas d’exceptions
o Testeur est différent du concepteur ou du développeur
o Logiciels de tests: toute ligne de code doit être testée
o Différentes méthodes de validation (voir cours
méthodes formelles)

 Recette
o Validation client: accord avec les besoins
o Planification dès spécifications: cahier de recettes

 Activité souvent sous estimée

14/10/2018 Dr. Aymen LOUATI 53
Maintenance

 Deux types de maintenance

o Correction des erreurs du système
o Demande d’évolution (modification de l’environnement
technique, nouvelle fonctionnalités …)
 Facteurs da qualité essentiels
o Corrections: robustesse
o Évolution: modificabilité, portabilité

 Étape longue, critique et coûteuse

o Une enquête effectuée aux USA en 1986 auprès de 55
entreprises a révélé que 53% du budget total d'un
logiciel est affecté à la maintenance

14/10/2018 Dr. Aymen LOUATI 54

 Exemple d’une
démarche Orientée
objets Basée sur le
langage UML

14/10/2018 Dr. Aymen LOUATI 55

1. Avoir la discipline d’appliquer une bonne
démarche de développement de logiciel.

2. Réaliser son application utilisant le formalisme

UML et le bon outil CASE (Computer-Aided
Software Engineering).

3. Arriver à visualiser les problèmes, préciser les

comportements et les structures, fournir un
guide pour la réalisation, documenter les
décisions.

14/10/2018 Dr. Aymen LOUATI 56

Modélisation: Contexte et Objectifs
 Complexité croissante des systèmes de plus en plus.
 Coût élevé de l’échec dans les systèmes critiques.
 Besoins de:
o Réutilisation
o Modélisation
o Abstraction

 Une production fiable et une conformité des

besoins.
 Une bonne démarche de modélisation.
 Une Sécurité de communication et une
rapidité d’exécution.

14/10/2018 ISI Kef Workshop 57

Modélisation

 Satisfaction du client.
 Production d’applications de qualité.
 Simplification de la réalité.
 Mieux appréhender le système.
Utiliser les bon outils de communication
 Le choix des modèles simplifie la manière d’aborder le
problème et sa solution.
 Décomposer le système en un ensemble de modèles pour en
améliorer la compréhension.

La modélisation est une des caractéristiques d’un

projet qui réussi
14/10/2018 ISI Kef Workshop 58
Pourquoi modéliser
 Fournir des spécifications claires : produire, exploiter, etc.
 Clarifier les objets, les concepts, les référentiels, les
processus.

Réponses possibles aux questions suivantes

o Pour quel processus je travaille?
o Quel rôle j’ai dans ce processus?
o Quel est l’ensemble des processus de mon entreprise?

Modéliser  Générer des modèles

 Abstraction de la réalité.
 Vue subjective mais pertinente de la réalité.

14/10/2018 ISI Kef Workshop 59

Modèle: Exemple
1er modèle
proposé

Système
= Réalité

3ème modèle
2ème modèle proposé
proposé

14/10/2018 ISI Kef Workshop 60

  Unified Modeling Language (uniquement un
langage et pas une méthode).
 Un fruit d’une évolution des méthodes orientées
objet.
 Une notation de plus en plus répandue (connue,
enseignée, supportée par les outils…).
 Pas de nécessité d’avoir des compétences métier:
fonctionnels et développeurs ont un langage commun.

14/10/2018 ISI Kef Workshop 61

14/10/2018 ISI Kef Workshop 62
 Les diagrammes UML2.5

Vue statique Vue dynamique

Diagramme Diagramme
Diagramme Machine Diagramme de
de classe d’objets
d’activité d’états UML cas d’utilisation

Diagramme de Diagramme de Diagrammes

composants déploiement d’interaction

Diagramme de Diagramme de
séquence communication

Diagramme de Diagramme de Diagramme de Diagramme global Diagramme

profile structure composite paquetages d’interaction de timing

Nouveaux sous UML2

 Représentation
Possibilité
Diversité dede diagrammes
visualiser
graphiqueet pour
d’une
manipuler
séquence
une des éléments
d’opérations
modélisation de
sous
modélisation
ou de la structure
plusieurs angles d’un système
14/10/2018 ISI Kef Workshop 63
 Domaine d’application

– Les systèmes informatiques d’entreprise,

– Les banques,
– Les télécoms,
– Les transports,
– La défense,
– Le web et etc.
– Même les plus gros projets peuvent être spécifiés et
maintenus en UML.

Quelques problèmes de communication

 Diagrammes complexes: difficiles à comprendre.
 Panoplie de diagrammes: perdre la direction.
14/10/2018 ISI Kef Workshop 64
Modélisation et Démarche

Un
 UMLbon
est-il Informaticien
la bonne solution? est un bon
 Comment appliquer la bonne démarche?
développeur,
 UML est unOUI c’est vrai
avantage pourmais ?????
la modélisation
ouTrès
une bon
 Comment ANALYSTE
générer
perte delestemps –pour
Trèslivrer
bon modèles? bon un
produit? CONCEPTEUR
14/10/2018 ISI Kef Workshop 65
1. Echanger avec son client
– Définir ensemble un diagramme de cas d’utilisation.
– Valider ensemble les scénarios.

2. Analyser et concevoir le système

– A partir des Uses Cases et des scénarios, définir le
diagramme de classe.
– A partir des scénarios, définir les diagrammes de
séquence et de collaboration (et enrichir les classes).
– Définir si besoins les diagrammes d’états…..
14/10/2018 ISI Kef Workshop 66
 Démarche linéaire (Modèle de la cascade),
 Processus Unifié (UP) (Modèle itératif),
 2Truck UP (Modèle en Y),
 Etc.… (panoplie de démarches et de modèles),

Simplifier une démarche

Proposition d’une démarche de
développement itérative et incrémentale par
activités s’inspirant du UP.

14/10/2018 ISI Kef Workshop 67

Démarche de développement Objet
Nécessité d’un outil de modélisation (CASE) + Sélection
de l’environnement de développement du projet
pivot à toute la conception.

14/10/2018 ISI Kef Workshop 68

Suite
Diagrammes de séquences
Diagrammes de classes (Modélisation de scénarios par
(Modélisation du domaine) échanges de messages)

Diagrammes d’activités Diagrammes de classe de

(Modélisation de processus conception
d’affaires ou autres) (objets, encapsulation, etc.)
14/10/2018 ISI Kef Workshop 69
 Un même type de diagramme peut :
 Modéliser des concepts différents,
 Être utilisé à des moments différents du processus
de développement,
 Être à différents niveaux d’abstraction,
 Ne pas être utilisé,

14/10/2018 ISI Kef Workshop 70