GL&AGL : Résumé

1/ Les Enjeux & l’Importance du Génie Logiciel :

Définition GL :
Discipline basée sur le savoir, le savoir-faire et le faire savoir pour produire de
façon industrielle des logiciels de qualité au meilleurs prix.

Facteurs de qualité du logiciel :

*les critères externes = de pt de vue utilisateur

Fiabilité - La conformité du logiciel vis-à-vis de ses spécifications.

- Les résultats sont vérifiables et sont ceux attendus.
Robustesse & - Le logiciel reste stable, disponible et capable de fournir des
Sureté résultats toujours fiables
dans les conditions de fonctionnement extrême dans le temps.
Efficacité Le logiciel fait bon usage de ses ressources, en terme d’espace
mémoire, et temps d ’exécution
Convivialité et Facile à utiliser
Utilisabilité
Documentable Accompagné d’un manuel utilisateur, ou d’un tutoriel
Ergonomique - L’architecture doit être adaptée aux conditions de travail
Sécurité C’est la sûreté (assurance) et la garantie , ou l’absence du
danger lors de son exploitation .
Adéquation et validité conformité au maquettage
Intégrité =l’aptitude d’un logiciel à protéger son code et ses données
contre des accès non autorisé.

*les critères internes= de pt de vue développeur = liés à la maintenance d’un logiciel

Documentable précédé par un document de conception ou architecture

Lisibilité et Clarté écrit proprement, et en respectant les conventions de
programmation
Portabilité pouvoir fonctionner sur plusieurs machines => le rendre
indépendant de son environnement d'exécution.
Extensibilité souple ou flexible / ou permet l’ajout possible de nouvelles
fonctionnalités.
Réutilisabilité Des parties peuvent être réutilisées pour développer d’autres
logiciels similaires.
Interopérabilité et pouvoir interagir en synergie avec d'autres logiciels.
coulabilité
Traçabilité = la possibilité de suivre un produit aux différents stades de sa
production, de sa transformation et de sa commercialisation.
Testabilité et = la possibilité de soumettre un logiciel à une épreuve de
vérifiabilité confirmation de la tâche à exécuter.

*méthode VS méthodologie :

la méthode est plus spécifique et se concentre sur les étapes pratiques à suivre
pour accomplir une tâche particulière.
la méthodologie est plus générale et fournit un cadre global pour l'approche du
développement, incluant souvent des considérations plus larges sur la gestion
et la qualité.

//////////////////////////////////////////////////////////////
Chap 2 : Gestion des exigences :
*Spécification logicielle :
Assure la clarté, la compréhension commune, la gestion efficace et la réduction
des risques tout au long du cycle de vie du développement logiciel.
*Processus d’ingénierie des exigences : = phase importante qui vise à
comprendre, documenter et gérer les besoins des utilisateurs et du système.
1.Recueil des besoins : à travers des questionnaires, interviews, réunions,
brainstorming, etc.
2.Analyse des besoins : éliminant les ambiguïtés, incohérences,
Redondances, incomplétudes et en filtrant les besoins (par
objectif, par contexte, etc.)
3.Spécification des exigences : (Cahier de spécification) (mch de charge)
4. Validation des exigences : par tt les PP (revues de documents, maquettes,
prototypes, etc.)
5. Gestion des évolutions : considérer les changements apportés aux exigences
tout au long du cycle de vie du projet.
*Types de documents de spécification
 • Pour le point de vue interne : (concepteurs, des personnels techniques ...) :
Document de spécification technique
une description la plus précise possible du système.
=> Spécification du système /Spécification technique.
• Pour le point de vue externe : (utilisateur …) :
Document de spécification des besoins
une description abstraite de services et les contraintes
=> Spécification du système /Spécification technique.
=> Spécification des besoins /Spécification générale
*Catégories de spécification :
Fonctionnelles :
Non fonctionnelles :
Liées au processus : (coût, délai, assurance qualité, prix de vente, marché de
distribution, etc )…
////////////////////////////////////////////////////////////
Chapitre 3
Modèles de Cycle de vie logiciel et méthodes de développement
Définition du cycle de vie
Ensemble d’étapes qui composent le processus de développement et
d’utilisation du logiciel.

Modèle Principe Avantages Inconvénients

En cascade -dev divisé en étapes(date précise) +Simple à mettre en Détection tardive des
-à la fin de chaque étape il y a des place. erreurs => Augmentation
doc/prog produits +garantir l'existence du coût de la correction
-Validation à la fin de chaque étape d'une documentation -N’est pas efficace pour
On passe à l’étape suivante si bien structurée les projets qui exigent la
l’examen (la validation) est prise en considération de
satisfaisant sinon la phase sera risques.
renvoyer à la phase précédente pour
modifier.
En V Les premières étapes préparent les +Vérification objective N’est pas efficace pour :
dernières. des spécifications. -besoin de clients pas
*dépendances entre les étapes +Modèle plus réaliste stable
*Enchaînement séquentiel(cascade) que celui en cascade. -projet exige …des
de gauche à droite. +Eprouvé pour des risques
grands projets.

Par Raffinement des spécifications, des ✓Le client participe -Le coût du projet peut
fonctionnalités et performances par activement dans le rapidement s’éclater.
prototypag des prototypes successifs. dév du produit -Il est impossible
e +Les prototypes : cerner les ✓ client reçoit des d’estimer les délais au
estimations et les coûts de résultats tangibles démarrage du projet.
développement rapidement
+ Implication du client à intervenir ✓Introduction d’un
dans l’expression de son besoin feedback immédiat de
+L’analyse de chaque prototype la part des user
conduit à un développement ✓Amélioration de la
rapide -> converger rapidement. communication entre
+Expérimenter plusieurs techniques l’équipe de dév client.
de réalisation.
incrémental ✓Développer des app en étendant ✓Le dév d’incréments ✓Les incréments doivent
PROGRESSIVEMENT ses est plus simple. être indépendants aussi
fonctionnalités. ✓Les intégrations sont bien
✓ développer le logiciel par progressives. fonctionnellement qu’au
extension successive à partir d’un ✓livraisons et des niveau des calendriers de
produit « Noyau » du logiciel. mises en service après développement.
✓Permet d’éviter de TOUT chaque intégration ✓ difficulté de fixation
CONCEVOIR, de TOUT TESTER d’incrément. des incréments dès le
(cascade) ✓optimiser le temps début du projet.
✓a des répercussions sur la et le partage des
répartition des efforts en fct du tâches.
temps. ✓Diminution d’effort
pendant la phase de
test d’intégration.
En ✓développement itératif ✓Nouveau : analyse ✓ Difficile à appliquer.
(prototypes). des risques, ✓Beaucoup de temps.
Spirale Il y a 4 phases : maquettes, ✓Coût élevé.
1. Analyse des besoins, prototypages
Spécification. ✓Modèle complet,
2. Analyse des risques, Alternatives, complexe et général.
Maquettage. ✓Effort important
3. Conception et Implémentation de pour la mise en
la solution retenue. œuvre.
4. Vérification, Validation, ✓Utilisé pour des
Planification du cycle suivant. projets innovants ou à
risques.
Méthodes lourdes VS Méthodes agile :
*Le processus unifié (UP) est une méthode générique de dév de
logiciels.
*Caractéristiques de UP :
• Piloté par les cas d’utilisation
• Itératif et incrémental
• Centré sur l’architecture
• Orienté risques
*Composantes de UP :
• Ensemble d’itérations : circuit de développement aboutissant à
un livrable.

• Les principales activités dans UP :

• Expression des besoins :
Identification des besoins fonctionnels + non fonctionnels.
• Analyse :
Formalisation du système à partir des besoins.
Modélisations de diagrammes statiques et dynamiques.
Vue logique du système.
• Conception :
Définition de l’architecture du système.
Etendre les diagrammes d’analyse.
Prise en compte des contraintes de l’architecture technique.
• Implémentation :
Production du logiciel :
Composants.
Bibliothèques.
Fichiers….
• Test :
Vérifier l’implémentation de tous les besoins
Vérifier l’interaction entre les objets.
Vérifier l’intégration de tous les composants.
Différents niveaux de tests (unitaires, d’intégration, deperformance..).
Déploiement
•Les phases de UP :
1. Etude d’opportunité/ Inception/ Pré-Etude :
• faisabilité du projet, des frontières du système, des risques ..
• A la fin de cette phase, est établi un document donnant une vision globale des
principales exigences, des fonctionnalités clés et des contraintes majeures.
• établir une estimation initiale des risques "Business Model".

2. Elaboration :
• Reprise des résultats de la phase d’incubation.
• Spécification détaillée des cas d’utilisation.
• Détermination de l’architecture de référence.

3. Construction :
• Construction d’une première version du produit
• Construction de tous les cas d’utilisation.

4. Transition :
• Test et correction des anomalies.
• Préparer la version finale du produit.
• Déploiement du produit.

RUP (Rational Unified Process) : est une instance /

implémentation de UP.
• Artéfact : Élément d’information, produit ou utilisé lors d’une activité de dév
logiciel (modèle, source, etc.)
• Activité : Opération exécutée au sein d’un état + elle peut être interrompue.
• Rôle : Comportement et responsabilités d’un ensemble de personnes.

2TUP (2 Track Unified Process) : =une démarche de dév

= instance/implémentation de UP.
Le développement d’un système peut se décomposer suivant :

• Une branche fonctionnelle :

Capitalise la connaissance du métier de l’entreprise.
Capture les besoins fonctionnels.

• Une branche technique :

Capitalise un savoir-faire technique et/ou des contraintes techniques.
Les techniques développées pour le système sont indépendantes des fonctions
à réaliser.

• La phase de réalisation :
Réunir les deux branches, permettant de mener une conception applicative .
Livrer une solution adaptée aux besoins.
- Inconvénients de UP :
Fait tout, mais lourd.
Parfois difficile à mettre en œuvre de façon spécifique.
/////////////
UP pour les gros projets qui génèrent beaucoup de documentation.
RUP 4 fois plus lent que Scrum

Méthodes agiles :
-> 4 valeurs
-> 12 principes
Les 4 valeurs des méthodes agiles :
• Priorité aux personnes et aux interactions sur les procédures et les outils ;
• Priorité aux applications fonctionnelles sur une documentation
pléthorique (beaucoup)
• Priorité à la collaboration avec le client sur la négociation de contrat ;
• Priorité à l'acceptation du changement sur la planification.

Les 12 principes des méthodes agiles :

1. Satisfaction du client par la livraison continue.
2. Acceptation des changements même tardifs
3. Livraison fréquente avec une préférence pour les périodes courtes
4. PP et développeurs doivent travailler ensemble
5. Construction de projets autour de personnes motivées.
6. Communication face à face comme moyen efficace de transmission
d'information.
7. Mesure de la progression par le logiciel fonctionnel.
8. Encouragement au développement durable et maintien d'un rythme
constant
9. Attention continue à l'excellence technique et au bon design.
……
https://www.youtube.com/watch?v=tYV6GtOzeFg
Exemple de méthode agile : Scrum
3 rôles : Product owner (chef projet), Scrum master, équipe

Chap4 : Architecture & Conception de logiciels

 1) Niveaux conceptuels :
Conception architecturale globale Conception architecturale détaillée
 architecture de haut niveau Fournir une description, de la manière
+ minimiser la complexité dont les fonctions ou les services
+ favoriser des interfaces claires entre les sont réalisés : structures de
composants données, algorithmes, etc.
+assurer un déploiement efficace sur les
nœuds physiques.

2) Types d’architecture :
Architecture logique Architecture physique
• Structure logique de l’application. • Ensemble de ressources physiques
• Décomposition en éléments logiques. (serveurs, ordinateurs, etc.) nécessaires à
• Exple : découpage en composants. l’exécution de l’application.
• Exemple : Découpage en
nœuds physiques.

*Architecture logique – Approche de résolution :

• Approches de haut en bas (Top – Down) :
1. Concevoir la structure générale.
2. Etudier les éléments du plus bas niveau.
3. Détailler tous les éléments de la structure : format des données,
algorithmes …
• Approche de bas vers le haut (Bottom – Up) :
1. Identifier les éléments de bas niveau.
2. Prendre des décisions concernant la réutilisation.
3. Décider de l’assemblage des éléments pour créer des structures de plus
haut niveau.
• Combinaison des 2 approches
*Patrons d’architecture :

1-Modèle en 3 couches :
Principe :

faire évoluer distinctement l'IHM (couche présentation) et/ou le métier (couche

applicative) et/ou l’image base de donnée(les entités) (couche infrastructure) .
• une dépendance bidirectionnelle entre « IHM » et « Métier »
• La couche infrastructure n'a aucune dépendance sur la couche « Métier »
• mais le package « infrastructure » devra répondre aux besoins de « Métier ».
Couche présentation :IHM
Interactions Utilisateur-Logiciel
Visualisation des Informations
Traduction des Commandes Utilisateur pour devenir compréhensibles pour les
autres couches.
Couche applicative : métier
• Décrit les opérations que l'app opère sur les données en fct des requêtes des
utilisateurs( eli fl couche présentation)
• Offre des services applicatifs et métiers à la couche présentation
• S'appuie sur les données de la couche inférieure.
• Renvoie à la couche présentation les résultats qu'elle a calculés.
Couche infrastructure : (accès au données)
Abstraction de la Base de Données
Simplification de la Couche Métier
Masquage des Traitements de Mapping
Facilité de Remplacement de la Base de Données
 Indépendance de la Couche Métier du code de BD elle manipule
seulement les objets pour accèder à BD.

+ -
• Renforcement de la sécurité •Complexe.
• Facilite la réutilisation et la • Plus d’exigence.
substitution • Problèmes au niveau des
 (couplage plus faible et mieux performances.
contrôlé).
•Minimise les dépendances entre
couches.

2-Modèle en 5 couches : =Modèle en 3 couches + logique applicative + accès

données.

• La couche IHM (Présentation) : Gérer le dialogue Humain-machine

• La couche Applicative : Implémenter les services (cas d’utilisation)
demandés par l’utilisateur
• La couche Métier : Implémenter les services atomiques
métiers propres au domaine et réutilisables par les
applications
• La couche d’accès aux données (CRUD)
• La couche de gestion des données (communicateur avec la base
de données)
3-MVC :
• Modèle: contient les données à afficher(BD)
Ne connait ni la vue ni l’API du contrôleur :
Le contrôleur et la vue sont des observateurs, Le modèle est
l’observé.
• Vue: fait l’affichage
Ne connait ni l’API du contrôleur, ni le modèle.
• Contrôleur : Assure l’interaction entre données et vue.
Connait la vue et le modèle.
Observe le modèle, modifie la vue
Observe la vue, modifie le modèle
Avantages du MVC :
• plusieurs vues pour le même modèle.
• Plusieurs contrôleurs peuvent modifier le même modèle.
• Tt les vues seront notifiées des modifications.
(voir p 32+33)

4-L’architecture physique :
Les architecture physique 1-niveau (1-tiers) : toutes les couches logiques
(présentation, logique métier et données) sont situées sur la même machine
Les architecture 2-niveaux (2-tiers) : les couches logiques sont réparties entre
deux sites ou deux machines distinctes.
Les dispositifs du serveur(BD, services) situés sur un site
Le reste de l'architecture (ex : l'interface utilisateur) sur les postes clients
Permet le partage d’information entre utilisateurs : Accès simultanés,
Synchronisation des données.
**Des variantes existent pour alléger le poste client (Plus d’applicatifs sur le
site serveur réduisant la charge de traitement côté client)

données : serveur
présentation + traitement :client

*Qualité de la conception architecturale :

critères de qualité :
• Faible couplage
• Forte cohésion.

patrons de conception : Gang of four

-De création.
-De structure.
-De comportement.
Fort couplage :
= dépendance étroite entre deux composants d'un système informatique.
Un changement dans l'un des composants peut avoir un impact direct sur
l'autre.
Un système a une cohésion si:
✓Les éléments inter reliés sont groupés ensemble.

✓Les éléments indépendants sont dans des groupes distincts.

Patrons : types :
• Les patrons d’analyse.
Fournissent des solutions réutilisables pour les étapes d’analyse.
• Les patrons architecturaux.
• Exp. : MVC (Model View Controller).
• Les patrons de conception (Design Pattern)
• Exp. : Singleton, Observer, Factory, etc.

Cycle de vie prototype