-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
CH1 : GL
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
Définition du Génie Logiciel
Le Génie Logiciel est l'ensemble des méthodes, techniques et outils nécessaires à
la production de logiciels de qualité, en prenant en compte le savoir, le savoir-
faire et le savoir-faire savoir.
Le savoir-faire ➔ compétence, ressource humaine
Le faire savoir ➔communication
-----------Facteurs de Qualité du Logiciel
Critères externes :
Fiabilité-> La conformité du logiciel vis-à-vis de ses spécifications.
Robustesse
Efficacité
Convivialité -> Est-il facile et agréable à utiliser?
Documentation -> tutoriel
Ergonomique -> L’architecture du logiciel doit particulièrement être adaptée aux
conditions de travail de l’utilisateur
Sécurité
Intégrité -> t l’aptitude d’un logiciel à protéger son code et ses données contre
des accès non autorisé.
Critères internes :un bon logiciel du point de vue du développeur :
Documentabilité
Lisibilité
Portabilité
Extensibilité
Réutilisabilité
Traçabilité
------------Éléments Clés du Génie Logiciel
Processus de développement logiciel
Méthodologies de développement
Normes de qualité ->ISO, ITIL, COBIT, PMBOK, CMMI
Outils de développement
-----------------------------------------------------------------------------------
----------------------------------------------------------------------------
CH2 : spécification logicielle
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
Catégories des exigences
o Fonctionnelles FR: définit les services du système en termes de relation
entre les entrées et les sorties
o Non Fonctionnelles NFR : ce sont les contraintes et les propriétés remplies
par le système ( performance , sécurité )
o Liées au processus : ce sont des contraintes liées au développement du
produit (coût, délai, assurance qualité), ou liées à l’exploitation future
(prix de vente, marché de distribution, etc.)
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
CH3: model de cycle de vie
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
------Définition du cycle de vie
Ensemble d’étapes qui composent le processus de développement et d’utilisation du
logiciel
------Modèle de cycle de vie en cascade
( analyse et spécification=>conception globale=>conception détaillé =>
programmation => test => maintenance )
Principe :
• Le développement se divise en étapes.
• Chaque étape se termine à une date précise.
• Des documents/programmes sont produits à la fin de chaque étape.
• Le résultat de chaque étape est soumis à une Validation.
• On passe à l’étape suivante si l’examen est satisfaisant.
• Chaque phase doit pouvoir nécessairement renvoyer à la phase précédente en cas de
défauts constatés en aval (par exemple, en cas d'erreur découverte lors des tests,
il est nécessaire de retourner à la phase de programmation)
Avantages
+ Simple à mettre en place.
+ Permet de garantir l'existence d'une documentation bien structurée
Inconvénients
- Détection tardive des erreurs => Augmentation du coût de la correction.
- N’est pas efficace pour les projets qui exigent la prise en considération de
risques.
--------Modèle de cycle de vie en V + taswira
Parmi ses avantages, on trouve la clarté, la détection précoce des erreurs et une
documentation rigoureuse. Cependant, il présente des inconvénients, tels que sa
rigidité, le coût élevé des modifications tardives et une inadéquation avec les
méthodes agiles, rendant ce modèle plus adapté aux projets avec des exigences bien
définies.
-------Modèle de cycle de vie par prototypage + taswira
Avantages
+ Le client participe activement dans le développement du produit
+ Le client reçoit des résultats tangibles rapidement
+ Amélioration de la communication entre l’équipe de développement et le client.
+ Permet d’éviter l’effet Tunnel.
Inconvénients
- Le coût du projet peut rapidement s’éclater.
- Il est impossible d’estimer les délais au démarrage du projet.
--------Modèle de cycle de vie incrémental + taswira
Avantages
+ Le développement du projet sous forme d’incréments est plus simple.
+ Permet d’éviter de TOUT CONCEVOIR, de TOUT TESTER comme l’approche en cascade.
+ Les intégrations sont progressives.
+ Il peut y avoir des livraisons et des mises en service après chaque intégration
d’incrément.
+ Permet d’optimiser le temps et le partage des tâches.
+ Diminution d’effort pendant la phase de test d’intégration.
Inconvénients
- Les incréments doivent être indépendants aussi bien fonctionnellement qu’au
niveau des calendriers de développement.
- La difficulté de fixation des incréments dès le début du projet.
------spiral + taswira
Avantages
+ Nouveau : analyse des risques, maquettes, prototypages
+ Modèle complet, complexe et général.
+ Effort important pour la mise en œuvre.
+ Utilisé pour des projets innovants ou à risques.
Inconvénients
- Difficile à appliquer.
- Beaucoup de temps.
- Coût élevé.
------méthodologie lourde
Le processus unifié (UP)
Le processus unifié (UP) est une méthode générique de développement de logiciels .
-----Caractéristiques de UP :
1- Piloté par les cas d utilisation: Système analysé, conçu et développé pour des
utilisateurs.
2- Itératif et incrémental: + Le feedback de l'utilisateur
3- Centré sur l architecture: L'architecture du système est décrite à l'aide de
différentes vues.
4- Orienté risques: Identifier les risques. Maintenir une liste de risques tout au
long du projet.
------Composantes de UP :
4 phases :
1/Etude d opportunité/ Inception / Pré-etude: Cette phase pose la question de la
faisabilité du projet, des frontières du système, des risques majeurs A la fin de
cette phase, est établi un document donnant une vision globale des principales
exigences, des fonctionnalités clés .
2/Elaboration: 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 de tous les cas d
utilisation.
4/Transition: Test et correction des anomalies. + Préparer la version finale du
produit. + Déploiement du produit.
-------Ensemble d activités:
1/Expression des besoins: Identification des besoins fonctionnels et non
fonctionnels.
2/Analyse: Formalisation du système à partir des besoins. Modélisations de
diagrammes statiques et dynamiques.
3/Conception: Définition de l architecture du système. + Etendre les diagrammes d
analyse. + Prise en compte des contraintes de l architecture technique.
4/Implémentation: Production du logiciel
5/Test: Vérifier l implémentation de tous les besoins (fonctionnels et non
fonctionnels). + 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, de
performance, etc.).
6/Déploiement
-------------------------RUP
kol we7ed 3ndo role walla akther w activite
-------------------------2 TUP ( 2 Track Unified Process)
Le développement d un système peut se décomposer suivant :
Une branche fonctionnelle
Une branche technique
-----------------------------------------------------------------
------------Méthodes agiles
Les 4 valeurs des méthodes agiles :
• interactions
• applications fonctionnelles
• collaboration avec le client
• l'acceptation du changement sur la planification.
Les 12 principes des méthodes agiles :
1. satisfaction du client
2. Acceptation des changements
3. Livraison fréquente du logiciel
4. Le logiciel fonctionnel.
5. Les processus agiles encouragent le développement durable.
6. un bon design améliore l’agilité.
7. La simplicité
8. Les meilleures architectures
…..
-------------------SCRUM
Exemple de méthode agile : Scrum
Scrum est une méthode agile utilisée dans le développement de logiciels. Elle vise
à satisfaire au mieux les besoins du client tout en maximisant les probabilités de
réussite du projet.
• Un projet utilisant Scrum est composé d'une suite d'itérations courtes de l'ordre
de 2 à 4 semaines appelées sprints.
• A la fin d'un sprint, l'équipe livre au client un incrément de logiciel fini
potentiellement livrable.
• Le projet peut être réorienté par le client à la fin de chaque sprint.
• Le backlog du produit constitue l'ensemble du travail connu sur le projet à un
instant t.
• Le travail à faire durant un sprint est listé dans le backlog du sprint.
LES indicateurs SCRUM
-> tableau blanc
->graphique d'avancement ( burndown chart
Les artefacts SCRUM
-- product backlog : ys3no el product owner dima ytbadel fih priorité
-- sprint backlog : list user story jeya mel sprint planning ( meet) tsn3o équipe
fih les taches
-- incrément : fih les element mt3 el product backlog eli kemlo
LES ÉVÉNEMENTS SCRUM
-> sprint : iteration ( 2 à 4 sem)
-> sprint planning : lance le sprint ( meet yt3ml bech y7aded el 5edma mt3 el
sprint hedhy ) max 8h
-- what meeting : chnowa eli inijm youfaa fel sprint hedhy
-- how meeting : kifeh bech yt5dem el 5edma
-> sprint review : 4h max e5er el sprint | inspecter le resultat du sprint et
determine l'adaptation future | PO yvaled esq kolchyn cv walla le | ken thamma
tabdila fel product backlog tsir
-> retorspective de sprint : 3h e5er el sprint | ychouf el ajwe2 el 3amma fel
sprint t3det bel behy walla le ( 5 pourquoi )
->daily scrum meeting : kol nhar 15 min | kol we7ed y9oul chnowa 5dem fel 24h w
chnowa bech y3ml w chniya el machekel eli 3ordhoto (lkol we9fin , nafs el blassa
kol nhar , kol prob ywali to do )
-> affinage du backlog
Les roles SCRUM
-- developpeur : y7wlo el product backlog l sprint backlog
-- product owner : represente les besoin de client | pilote le projet de point de
vue metier | accepte ou rejet un sprint | ytlhe product backlog |
-- scrum master : il garentit le bon application de scrum dans l'equipe | Ameliore
les conditon de travail | guide les developpeur | facilite les meeting
****devops :
Le DevOps consiste à encourager la collaboration et la communication et
l’automatisation entre les ingénieurs logiciel (Dev) et les opérations IT (Ops).
Les valeurs de l’approche DevOps : CAMS (Culture, Automation, Measurement and
Sharing)
•Culture : se base sur les principes de l’agilité et consiste principalement à
éliminer les barrières entre les équipes.
•Automatisation : l'équipe obtient des résultats plus rapides, plus reproductibles
et plus cohérents grâce à l'automatisation
•Mesurément : l’approche DevOps permet de tout mesurer : les performances des
personnes, des processus et des outils
•Sharing: le partage des outils, des découvertes, des connaissances et des erreurs
entre les différentes équipes en permanence.
---Agilité Vs DevOps:
Planification des tâches : A (par sprint ) D (Souvent que possible)
Livraison : A ( periodique ) D ( Continue CD)
Intégration : A ( periodique ) D ( Continue CI )
Implémentation : A ( Planifié ) D ( immédiate)
Tests : A ( tôt ) D ( Tester en continue )
-----------------------------------------------------------------------------------
---------------------------------------------------------------------
CH4 : Architecture &
Conception de logiciels
-----------------------------------------------------------------------------------
--------------------------------------------------------------------
Conception logicielle c'est de faire des spécification et d'analyse pour concevoir
et proposer des solution
Objectifs de la conception : La réutilisabilité , La maintenabilité ( deviser
pour mieux regner)
Types d’architectures :
-->Architecture logique :découpage en composants
--Approches de haut en bas ( globale --> details) + maintenabilité
--Approche de bas vers le haut ( details -> globale ) + réutilisabilité -
maintenabilité
--Combinaison des 2 approches
-->Architecture physique : Découpage en nœuds physiques ( serveur )
Patrons d’architecture:
1/Modèle en couches (
3 ( présentation IHM , applicative , infrastructure ) (+ On peut
s’occuper d’une couche sans savoir à connaitre le détail des autres
+ Minimise les dépendances
entre couches
+ Facilite la réutilisation et
la substitution
+ La sécurité peut être
renforcée
- Complexe
- Plus d’exigence
ou
5 (Présentation IHM, logique applicative ,Métier , accès donne ,
infrastructure )
2/MVC : model view Controller
Qualité de la conception architecturale:
• Application de critères de qualité :
Faible couplage. ( a9al rabt momken binet b3dhom)
Forte cohésion. ( eli teb3in b3dhom b7dha b3dhhom)
• Utilisation de patrons de conception : Solution générique à un problème
De création : par prototypage => Solutions aux problèmes liés à
l'instanciation des classes
De structure : facade => Solutions aux problèmes de structuration des classes
De comportement : observer => Solutions aux problèmes de communication entre
objets et d'algorithmique
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------
CH5 : Gestion de configuration
logicielle
-----------------------------------------------------------------------------------
---------------------------------------------------------------------------
Gestion de configuration logicielle : Gestion de conflit
Collaboration
journalisation
Versionnage
L’intérêt d’un GCL :Travailler à plusieurs , Conserver l’ensemble des versions d’un
ensemble de fichiers , Conserver les actions des développeurs ,Gérer les conflits
Les architectures d’un GCL :
--> Architecture centralisée : ( SVN ( subversion) , CVS ) Basée sur le modèle
Client- Serveur | + journalise , historique, securite | - conflit , 5edma a
disctance le lezem dima connecte ll serveur , Il nécessite un serveur de back-up
pour assurer la fiabilité
-->Architecture décentralisée:( Git , GNU ) logiciel de gestion de versions , de
façon désynchronisée des autres | + travailler de manière indépendante ,
enregistrer ses modifications sur le dépôt sans être connecté à Internet | - Cloner
un dépôt est long car il faut récupérer tout son historique
La gestion des versions :tag => X1.X2.X3
X1 => changement majeur
X2 => ajout des nouvelle foncionnalite
X3 => correction des errurs
mel X1' ll X1'' fusion
mel X2' ll X2'' branche
X1.0.0 x1'.0.0 et X1''.0.0 version stable => tranche /main line
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------------
CH6 : test et validation
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Principes des tests:
Les tests montrent la présence de défauts
Les tests exhaustifs sont impossibles
Tester tôt
Les tests dépendent du contexte
erreur (erreur hummain) -> defaut ( presence ou absence d'un element ) ->
defaillance
Méthodes (familles) des tests
-->Méthode boîte noire:
--> Méthode boîte blanche (ou transparente)
--> Méthode boîte grise
Types des tests
*test unitaire : Tester les fonctions (ou les modules) de code par les programmeurs
*test d’intégration : Valider le bon fonctionnement d’une ou de plusieurs parties
*test de non régression: Reprendre un ensemble de cas de tests après avoir fixé
*test d’administration : tests des backups
*test de sécurité : Détecter les intrusions et les failles de sécurité
*test nominal = to pass : Entrer des données volontairement valides
*test de de défense = to fail : Entrer des données volontairement invalides
