Génie Logiciel : Fondamentaux et Pratiques Modernes

Université de Toulon

LIS UMR CNRS 7020

2026-10-03

Points clés du cours

Principes fondamentaux
Méthodologies de développement
Outils et pratiques modernes
Gestion de la qualité

mindmap
  root((SE))
    Fondamentaux
      Principes
      Qualité
    Méthodes
      Agile
      DevOps
    Pratiques
      CI/CD
      TDD

Figure 1: Mindmap des points clés du cours

Plan du cours

Introduction

Définition et importance
État de l’art et défis actuels

Fondamentaux

Principes d’ingénierie logicielle
Qualités logicielles
Cycle de vie

Processus et Méthodes

Approches classiques
Méthodes agiles
Gestion de projet

Ingénierie des Exigences

Analyse des besoins
Spécification
Validation

Conception et Architecture

Patterns et principes
Modélisation UML
Architecture logicielle

Développement et Tests

Pratiques de codage
Types de tests
Assurance qualité

Livraison et Maintenance

Intégration continue
Déploiement
Gestion des versions

Pratiques DevOps

CI/CD
Monitoring
Infrastructure as Code

Introduction au génie logiciel

Le génie logiciel aujourd’hui

Défis modernes
- Complexité croissante des systèmes
- Time-to-market raccourci
- Qualité et fiabilité critiques
- Agilité indispensable

mindmap
  root((Génie<br>Logiciel))
    Processus
      Agile
      DevOps
    Qualité
      Tests
      Standards
    Architecture
      Cloud
      Microservices
    Pratiques
      Clean Code
      CI/CD

Figure 2: Mindmap des défis modernes du génie logiciel

2. Principes fondamentaux

Définition et objectifs du génie logiciel

Le génie logiciel est une discipline qui intègre les principes d’ingénierie et de gestion pour créer des logiciels fiables et efficaces.

flowchart LR
  A[Problème] --> B[Analyse]
  B --> C[Conception]
  C --> D[Implémentation]
  D --> E[Test]
  E --> F[Déploiement]
  F --> G[Maintenance]

Figure 3: Processus de développement logiciel

3. Cycle de vie et processus

3.1 Cycle de vie du logiciel

Le cycle de vie comprend toutes les phases depuis la conception jusqu’à la fin de vie du logiciel.

stateDiagram-v2
    direction LR
    
    classDef analysisPhase fill:#d4f1f9,stroke:#05668d,stroke-width:2px
    classDef designPhase fill:#ffdac1,stroke:#d95204,stroke-width:2px
    classDef devPhase fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    classDef testPhase fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    classDef deployPhase fill:#ffecb3,stroke:#ff8f00,stroke-width:2px
    classDef maintainPhase fill:#f5b7b1,stroke:#922b21,stroke-width:2px
    
    Analyse --> Conception
    Conception --> Implémentation
    Implémentation --> Test
    Test --> Déploiement
    Déploiement --> Maintenance
    Maintenance --> Analyse: Évolution
    
    note right of Analyse: <b>Définition des besoins</b><br/>Compréhension du problème<br/>Spécification des exigences
    note right of Conception: <b>Architecture et design</b><br/>Structure du système<br/>Interfaces et composants
    note right of Implémentation: <b>Développement</b><br/>Écriture du code<br/>Unités fonctionnelles
    note right of Test: <b>Validation</b><br/>Vérification fonctionnelle<br/>Assurance qualité
    note right of Déploiement: <b>Mise en production</b><br/>Installation<br/>Configuration
    note right of Maintenance: <b>Évolution</b><br/>Corrections<br/>Améliorations<br/>Adaptation
    
    state "Analyse" as Analyse
    state "Conception" as Conception
    state "Implémentation" as Implémentation
    state "Test" as Test
    state "Déploiement" as Déploiement
    state "Maintenance" as Maintenance
    
    class Analyse analysisPhase
    class Conception designPhase
    class Implémentation devPhase
    class Test testPhase
    class Déploiement deployPhase
    class Maintenance maintainPhase

Figure 4: Cycle de vie du logiciel

Le modèle en cascade suit une approche linéaire et séquentielle:

Analyse des besoins
Conception
Implémentation
Test
Déploiement
Maintenance

Avantages: Structure claire, documentation complète
Inconvénients: Peu flexible, retour client tardif

Le modèle en V associe chaque phase de développement à une phase de test:

Voici un diagramme Mermaid pour le modèle en V qui illustre clairement la correspondance entre les phases de développement et de test:

graph TD
    %% Définition des nœuds principaux
    A[Analyse des besoins] -->|développement| B[Conception système]
    B -->|développement| C[Conception détaillée]
    C -->|développement| D[Codage]
    D -->|validation| E[Tests unitaires]
    E -->|validation| F[Tests d'intégration]
    F -->|validation| G[Tests système]
    G -->|validation| H[Tests d'acceptation]
    
    %% Liens de validation croisés
    A -.->|validation| H
    B -.->|validation| G
    C -.->|validation| F
    
    %% Annotations des nœuds
    A1[Définition des exigences<br>Expression des besoins]
    B1[Architecture globale<br>Interfaces principales]
    C1[Design des composants<br>Algorithmes]
    D1[Programmation<br>Implémentation]
    E1[Validation des modules<br>individuels]
    F1[Validation des<br>interactions]
    G1[Validation de<br>l'architecture]
    H1[Validation des<br>besoins initiaux]
    
    %% Connexion des annotations
    A --- A1
    B --- B1
    C --- C1
    D --- D1
    E --- E1
    F --- F1
    G --- G1
    H --- H1
    
    %% Style des nœuds par type
    style A fill:#ffdac1,stroke:#d95204,stroke-width:2px
    style B fill:#ffdac1,stroke:#d95204,stroke-width:2px
    style C fill:#ffdac1,stroke:#d95204,stroke-width:2px
    style D fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    style E fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    style F fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    style G fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    style H fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    
    %% Style des annotations
    style A1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style B1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style C1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style D1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style E1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style F1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style G1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    style H1 fill:#f9f9f9,stroke:#aaa,stroke-width:1px
    
    %% Groupes des phases (simplifié pour compatibilité)
    subgraph Développement
        A
        B
        C
    end
    
    subgraph Implémentation
        D
    end
    
    subgraph Validation
        E
        F
        G
        H
    end

Figure 5: Modèle en V: correspondance entre développement et validation

Avantages: Emphase sur les tests, traçabilité
Inconvénients: Rigidité, adaptation difficile au changement

Approches agiles

Les méthodes agiles favorisent:

Livraison incrémentale et itérative
Adaptation aux changements
Collaboration étroite avec le client
Amélioration continue

Manifeste Agile

Individus et interactions plutôt que processus et outils
Logiciel fonctionnel plutôt que documentation exhaustive
Collaboration avec le client plutôt que négociation de contrat
Adaptation au changement plutôt que suivi d’un plan

Scrum

Sprints: Cycles de travail de 2-4 semaines
Rôles clés:
- Product Owner (responsable du produit)
- Scrum Master (facilitateur)
- Équipe de développement (auto-organisée)
Rituels:
- Daily Stand-up (synchronisation quotidienne)
- Sprint Planning (planification)
- Sprint Review (démonstration)
- Sprint Retrospective (amélioration)
Forces: Cadre structuré, livraison rapide, collaboration

Kanban

graph LR
    %% Colonnes du tableau Kanban n . 
    subgraph Backlog
        B1[User story #1]
        B2[User story #2]
        B3[User story #3]
        B4[...]
    end
    
    subgraph AFaire[À faire - WIP: 3/3]
        T1[Tâche #4]
        T2[Tâche #5]
        T3[Tâche #6]
    end
    
    subgraph EnCours[En cours - WIP: 2/2]
        P1[Tâche #7]
        P2[Tâche #8]
    end
    
    subgraph Test[Test - WIP: 1/2]
        R1[Tâche #9]
    end
    
    subgraph Termine[Terminé]
        D1[Tâche #1]
        D2[Tâche #2]
        D3[Tâche #3]
    end
    
    %% Flux entre colonnes
    Backlog --> AFaire
    AFaire --> EnCours
    EnCours --> Test
    Test --> Termine
    
    %% Métriques (simplifiés pour compatibilité)
    M1[Cycle Time: 2.3 jours]
    M2[Lead Time: 6.5 jours]
    M3[Débit: 8 tâches/semaine]
    
    %% Styles compatibles avec anciennes versions
    style AFaire fill:#ffcccb,stroke:#333
    style EnCours fill:#ffffcc,stroke:#333
    style Test fill:#ccffcc,stroke:#333
    style Termine fill:#ccccff,stroke:#333

Figure 6: Tableau Kanban avec limites WIP

Kanban : Principes fondamentaux

Visualisation du flux de travail : Représentation claire de chaque étape du processus
Limitation du travail en cours (WIP) : Prévention de la surcharge et identification des goulots d’étranglement
Gestion du flux : Optimisation pour un mouvement fluide et prévisible des tâches
Politiques explicites : Règles claires pour chaque étape du processus
Boucles de feedback : Réunions, métriques et révisions régulières
Amélioration collaborative : Évolution progressive basée sur des données empiriques

Métriques clés:

Lead time : Temps total depuis la demande jusqu’à la livraison
Cycle time : Temps de traitement effectif d’une tâche
Throughput : Nombre de tâches complétées par unité de temps
Taux de blocage : Pourcentage de tâches bloquées

Forces: Flexibilité, visualisation immédiate des problèmes, adaptation continue, réduction du gaspillage, prévisibilité accrue

Idéal pour: Environnements avec flux de travail continu, équipes de maintenance, projets à priorités changeantes

XP (Extreme Programming)

Pratiques techniques rigoureuses:
- Programmation en binôme
- Développement piloté par les tests (TDD)
- Intégration continue
- Refactoring fréquent
Cycles courts et feedback constant
Client sur site pour consultation immédiate
Design simple et évolutif
Forces: Qualité technique élevée, adaptabilité, réduction des défauts

flowchart TD
    A[Exigences] --> B[Planning]
    B --> C[Conception simple]
    C --> D[Tests]
    D --> E[Programmation en binôme]
    E --> F[Intégration continue]
    F --> G[Livraison fréquente]
    G --> A

Figure 7: Processus XP

Scrumban

Hybride entre Scrum et Kanban
Combine itérations de Scrum et flux continu de Kanban
Planification à la demande (quand le backlog s’épuise)
Métriques de flux pour optimiser le processus
Forces: Flexibilité accrue de Scrum, visualisation améliorée

flowchart LR
    A[Backlog] --> B[Planifié]
    B --> C[En cours]
    C --> D[Test]
    D --> E[Terminé]
    
    subgraph "Priorités dynamiques"
        A
    end
    subgraph "Sprint flexible"
        B
        C
        D
    end
    subgraph "Mesure continue"
        E
    end

Figure 8: Processus Scrumban

Processus unifié

Le Processus Unifié (RUP: Rational Unified Process) est un cadre de développement logiciel itératif et incrémental basé sur UML et les meilleures pratiques de l’industrie. Référence: UPEDU

Phases: Inception, Élaboration, Construction, Transition
Aspects: Risques, Architecture, Valeur métier, Compétences
Disciples: Modélisation, Implémentation, Test, Déploiement, etc.

RAD (Rapid Application Development)

Définition: Méthodologie créée par James Martin (1991) pour accélérer le développement
Objectif: Livrer rapidement des applications fonctionnelles (60-90 jours)
Principes: Prototypage rapide, implication continue des utilisateurs, équipes pluridisciplinaires
Phases: 1) Planification des besoins → 2) Conception utilisateur (prototypes) → 3) Construction rapide → 4) Transition
Forces: Développement rapide, forte adhésion utilisateur, visibilité précoce des résultats
Limites: Évolutivité limitée, nécessite utilisateurs disponibles et développeurs expérimentés
Cas d’usage: Projets de taille moyenne, besoins utilisateurs évolutifs, applications avec forte composante UI
Évolution: A inspiré DSDM, certains aspects d’XP, et les plateformes low-code/no-code modernes
Différenciation: Plus structuré que les méthodes purement agiles, mais plus flexible que le cycle en cascade

flowchart LR
    A[1. Planification<br>• Définition périmètre<br>• Ateliers JAD] --> B[2. Conception utilisateur<br>• Prototypage<br>• Validation immédiate]
    B --> C[3. Construction<br>• Développement rapide<br>• Tests continus]
    C --> D[4. Transition<br>• Finalisation<br>• Formation]
    D -.-> B
    style A fill:#f9d5e5,stroke:#333
    style B fill:#eeeeee,stroke:#333
    style C fill:#e3eaa7,stroke:#333
    style D fill:#b5ead7,stroke:#333

Figure 9: Processus RAD

4. Gestion de projet

Définition: Ensemble des activités de planification, d’organisation, de suivi et de contrôle d’un projet de développement logiciel.
Objectif: Livrer un produit conforme aux exigences, dans les délais et le budget alloués.

Approches de gestion de projet

Prédictives (plan-driven)
- Approche traditionnelle (cascade, cycle en V)
- Planification détaillée en amont
- Contrôle du respect du plan
- Adapté aux projets à exigences stables
Adaptatives (change-driven)
- Approches agiles (Scrum, Kanban, XP)
- Planification progressive
- Inspection et adaptation continues
- Adapté aux projets à forte incertitude

5. Analyse et conception

5.1 Ingénierie des exigences

L’ingénierie des exigences comprend:
1. Élicitation: Découvrir les besoins des parties prenantes
2. Analyse: Clarifier et prioriser les exigences
3. Spécification: Documenter les exigences
4. Validation: Vérifier la cohérence et la pertinence
5. Gestion: Suivre l’évolution des exigences

Techniques de collecte des besoins

Interviews et questionnaires
Ateliers et brainstorming
Observation et ethnographie
Prototypage et scénarios d’utilisation
Analyse de documents existants

Règles SMART pour les exigences

Spécifique
Mesurable
Atteignable
Réaliste
Temporellement défini

5.2 Conception logicielle et UML

Modélisation avec UML

Le langage UML (Unified Modeling Language) est une notation standardisée pour visualiser, spécifier, construire et documenter les artefacts d’un système logiciel. Développé dans les années 1990 et maintenu par l’OMG (Object Management Group), il constitue aujourd’hui le standard de facto pour la modélisation orientée objet.

Diagrammes structurels

Les diagrammes structurels représentent l’architecture statique du système
Ils montrent les classes, interfaces, composants, packages, etc.
Ils incluent les relations, attributs, méthodes, etc.
Ils sont utiles pour la conception et la documentation
Principaux types: diagramme de classes, diagramme d’objets, diagramme de composants, diagramme de déploiement, diagramme de paquetages

Diagramme de classes

Objectif : Représenter les classes, leurs attributs, méthodes et relations.

Éléments clés :

Classes et interfaces
Attributs et méthodes avec visibilité
Relations : association, agrégation, composition, héritage, etc.
Cardinalités et rôles

java.io.IOException: Cannot run program "/opt/local/bin/dot": Exec failed, error: 2 (No such file or directory) 
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1112)
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1046)
    at net.sourceforge.plantuml.dot.ProcessRunner.run(ProcessRunner.java:71)
    at net.sourceforge.plantuml.dot.ProcessRunner.run(ProcessRunner.java:60)
    at net.sourceforge.plantuml.dot.GraphvizVersionFinder.dotVersion(GraphvizVersionFinder.java:120)
    at net.sourceforge.plantuml.dot.GraphvizVersionFinder.getVersion(GraphvizVersionFinder.java:75)
    at net.sourceforge.plantuml.dot.GraphvizRuntimeEnvironment.getVersion(GraphvizRuntimeEnvironment.java:86)
    at net.sourceforge.plantuml.svek.DotStringFactory.getGraphvizVersionInternal(DotStringFactory.java:278)
    at net.sourceforge.plantuml.svek.DotStringFactory.getGraphvizVersion(DotStringFactory.java:267)
    at net.sourceforge.plantuml.svek.GraphvizImageBuilder.printEntityInternal(GraphvizImageBuilder.java:381)
    at net.sourceforge.plantuml.svek.GraphvizImageBuilder.printEntity(GraphvizImageBuilder.java:363)
    at net.sourceforge.plantuml.svek.GraphvizImageBuilder.printEntities(GraphvizImageBuilder.java:355)
    at net.sourceforge.plantuml.svek.GraphvizImageBuilder.buildImage(GraphvizImageBuilder.java:225)
    at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFileInternal(CucaDiagramFileMakerSvek.java:104)
    at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFile(CucaDiagramFileMakerSvek.java:70)
    at net.atmp.CucaDiagram.exportDiagramInternal(CucaDiagram.java:489)
    at net.sourceforge.plantuml.classdiagram.ClassDiagram.exportDiagramInternal(ClassDiagram.java:85)
    at net.sourceforge.plantuml.UmlDiagram.exportDiagramNow(UmlDiagram.java:119)
    at net.sourceforge.plantuml.AbstractPSystem.exportDiagram(AbstractPSystem.java:216)
    at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:189)
    at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:147)
    at io.github.spencerpark.ijava.magics.JavaPlantUMLMagics.plantUML(JavaPlantUMLMagics.java:53)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:565)
    at io.github.spencerpark.jupyter.kernel.magic.registry.Magics.invoke(Magics.java:89)
    at io.github.spencerpark.jupyter.kernel.magic.registry.Magics$CellReflectionMagicFunction.execute(Magics.java:164)
    at io.github.spencerpark.jupyter.kernel.magic.registry.Magics.applyCellMagic(Magics.java:36)
    at io.github.spencerpark.ijava.runtime.Magics.cellMagic(Magics.java:54)
    at REPL.$JShell$26.do_it$($JShell$26.java:53)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:565)
    at io.github.spencerpark.ijava.execution.IJavaExecutionControl.lambda$execute$0(IJavaExecutionControl.java:95)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
    at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.io.IOException: Exec failed, error: 2 (No such file or directory) 
    at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
    at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:300)
    at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:231)
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1078)
    ... 35 more

Diagramme d’objets

Objectif : Montrer une “photo instantanée” d’instances de classes et leurs relations à un moment donné.

Éléments clés :

Instances d’objets nommées
Valeurs d’attributs concrètes
Liens entre objets (instances d’associations)

Diagramme de composants

Objectif : Représenter l’organisation physique des composants d’un système et leurs dépendances.

Éléments clés :

Composants logiciels
Interfaces fournies et requises
Relations de dépendance

Diagramme de déploiement

Objectif : Montrer la configuration physique du matériel et la distribution des composants logiciels.

Éléments clés :

Nœuds (hardware)
Artefacts (composants déployés)
Connexions réseau

Diagramme de paquetages

Objectif : Organiser les éléments du modèle en groupes pour simplifier les diagrammes complexes.

Éléments clés :

Paquetages (namespaces/modules)
Dépendances entre paquetages
Visibilité des éléments

Diagrammes comportementaux

Les diagrammes comportementaux illustrent le fonctionnement dynamique du système
Ils montrent les interactions entre objets, les flux de contrôle, les états, etc.
Ils sont utiles pour comprendre le comportement du système et valider les exigences
Principaux types: diagramme de cas d’utilisation, diagramme de séquence, diagramme d’activité, diagramme d’état, diagramme de communication

Diagramme de cas d’utilisation

Objectif : Décrire les fonctionnalités du système du point de vue utilisateur.

Éléments clés :

Acteurs (utilisateurs ou systèmes externes)
Cas d’utilisation (fonctionnalités)
Relations entre cas d’utilisation (inclusion, extension)

Diagramme de séquence

Objectif : Modéliser les interactions entre objets dans le temps, montrant l’ordre des messages échangés.

Éléments clés :

Objets (instances de classes)
Lignes de vie et messages
Activations (périodes d’exécution)
Fragments d’interaction (alternatives, boucles)

Diagramme d’activité

Objectif : Décrire les flux de travail, processus métier ou algorithmes avec leurs points de décision.

Éléments clés :

Actions et activités
Transitions et conditions
Bifurcations et jointures (parallélisme)
Partitions (swimlanes)

Diagramme d’état

Objectif : Illustrer les différents états d’un objet au cours de son cycle de vie et les transitions entre ces états.

Éléments clés :

États (représentant une condition ou situation)
Transitions (changements d’état)
Événements déclencheurs
Actions et activités dans les états

Diagramme de communication

Objectif : Montrer les interactions entre objets en se concentrant sur la structure des échanges plutôt que sur leur chronologie.

Éléments clés :

Objets et leurs liens
Messages numérotés
Conditions et itérations

Bonnes pratiques UML

Niveau de détail adapté : Inclure uniquement les informations pertinentes pour l’audience cible
Cohérence : Maintenir une terminologie et des conventions cohérentes entre diagrammes
Modularité : Diviser les modèles complexes en sous-modèles plus simples
Annotation : Ajouter des notes pour clarifier les aspects ambigus
Évolution progressive : Commencer par des modèles simples et les affiner itérativement

Outils de modélisation UML

Outils dédiés : Enterprise Architect, Visual Paradigm, Modelio
IDE avec support UML : IntelliJ IDEA, Eclipse avec plugins
Outils collaboratifs : Lucidchart, draw.io
Langages textuels : PlantUML, Mermaid

6. Implémentation et tests

Implémentation

Définition: Phase de transformation des spécifications en code exécutable
Objectif: Produire un logiciel fonctionnel selon les spécifications établies
Résultats: Code source, documentation technique, tests automatisés

Bonnes pratiques de programmation

DRY (Don’t Repeat Yourself): Éviter la duplication de code
KISS (Keep It Simple, Stupid): Privilégier la simplicité
YAGNI (You Aren’t Gonna Need It): Ne pas anticiper des besoins hypothétiques
Separation of Concerns: Diviser le code en responsabilités distinctes
Fail Fast: Détecter et signaler les erreurs au plus tôt

Tests et Qualité

Points essentiels

Tests unitaires
Tests d’intégration
Tests système
Métriques clés

7. Déploiement et maintenance

Gestion de versions

La gestion des versions est un aspect crucial du développement logiciel moderne, permettant de:

Suivre l’évolution du code source et des composants
Coordonner le travail des équipes
Faciliter la livraison de nouvelles fonctionnalités
Assurer la traçabilité des changements
Maintenir plusieurs versions du produit

Versionnement sémantique (SemVer)

Principe: MAJOR.MINOR.PATCH
- MAJOR: Changements incompatibles avec l’API précédente
- MINOR: Ajouts de fonctionnalités compatibles
- PATCH: Corrections de bugs compatibles
Exemples:
- 0.0.1: Version initiale
- 1.0.0: Version initiale stable
- 1.1.0: Ajout de nouvelles fonctionnalités
- 1.1.1: Correction de bugs
- 2.0.0: Changements cassant la compatibilité
Suffixes additionnels:
- -alpha: Version instable en développement interne
- -beta: Version en test externe
- -rc.1: Release candidate (quasi-finale)

Systèmes de gestion de versions (VCS)

Centralisés: SVN, CVS
- Serveur central unique
- Check-out, check-in
- Risque de conflits
Décentralisés: Git, Mercurial
- Copie locale complète
- Branches, merges, commits locaux
- Facilité de collaboration

Workflows de développement

Définition: organisation des branches et des cycles de vie du code source
Objectifs: Isoler les développements, faciliter les tests, garantir la stabilité
Exemples:
- GitFlow: Branches principales (main, develop) et branches de support (feature, release, hotfix)
- Feature Flow: Branches principales (main) et branches de fonctionnalités temporaires
- Forking Workflow: Forks et pull requests pour contribuer à un projet

Intégration continue (CI) et livraison continue (CD)

Intégration continue (CI)
- Build et tests automatiques à chaque commit
- Détection rapide des problèmes d’intégration
- Validation de la qualité du code (linting, tests unitaires)
Livraison continue
- Package automatique en artefacts déployables
- Tests d’intégration et système automatisés
- Validation par les équipes QA

Déploiement continu (CD)

Mise en production automatique après validation CI
Déploiement progressif (canary, blue-green)
Surveillance et rollback automatique si problème

8. Pratiques modernes

8.1 Gestion de versions

8.2 Intégration et déploiement continus

Gestion de projet

Définition: Ensemble des activités de planification, d’organisation, de suivi et de contrôle d’un projet de développement logiciel.
Objectif: Livrer un produit conforme aux exigences, dans les délais et le budget alloués.

Approches de gestion de projet

Prédictives (plan-driven)
- Approche traditionnelle (cascade, cycle en V)
- Planification détaillée en amont
- Contrôle du respect du plan
- Adapté aux projets à exigences stables
Adaptatives (change-driven)
- Approches agiles (Scrum, Kanban, XP)
- Planification progressive
- Inspection et adaptation continues
- Adapté aux projets à forte incertitude

Analyse et spécification des besoins

L’ingénierie des exigences comprend:
1. Élicitation: Découvrir les besoins des parties prenantes
2. Analyse: Clarifier et prioriser les exigences
3. Spécification: Documenter les exigences
4. Validation: Vérifier la cohérence et la pertinence
5. Gestion: Suivre l’évolution des exigences

Techniques de collecte des besoins

Interviews et questionnaires
Ateliers et brainstorming
Observation et ethnographie
Prototypage et scénarios d’utilisation
Analyse de documents existants

Règles SMART pour les exigences

Spécifique
Mesurable
Atteignable
Réaliste
Temporellement défini

Conception logicielle

Définition: Processus de transformation des exigences en représentation implémentable
Objectif: Créer un plan détaillé pour guider l’implémentation
Position: Phase intermédiaire entre analyse des besoins et codage
Résultat: Ensemble de modèles, schémas et spécifications techniques

Approches fondamentales

Conception descendante (Top-Down)
- Commence par la vision globale, Décompose progressivement en sous-systèmes, Favorise la compréhension des objectifs généraux
Conception ascendante (Bottom-Up)
- Commence par les composants de bas niveau, Les assemble progressivement en systèmes plus grands, Favorise la réutilisation et le pragmatisme
Conception orientée objet (OOD)
- Organisation autour d’objets plutôt que d’actions, Encapsulation des données avec comportements associés, Relations basées sur héritage, composition, agrégation

Niveaux de conception

Architecture logicielle
- Structure globale du système
- Décomposition en sous-systèmes/modules
- Définition des interfaces principales
- Choix des styles architecturaux (couches, microservices, etc.)
Conception détaillée
- Spécification précise des classes/modules
- Algorithmes et structures de données
- Protocoles de communication
- Relations entre composants

Méthodologies de conception logicielle

graph TD
    %% Décennies comme points d'ancrage
    A[1970s] --> B[1980s]
    B --> C[1990s]
    C --> D[2000s]
    D --> E[2010s]
    E --> F[2020s]
    
    %% Méthodologies par décennie avec sous-nœuds
    A1[Structured Design<br>Analyse structurée]
    B1[Object-Oriented Design<br>Design par abstraction]
    C1[Design Patterns<br>UML<br>GRASP]
    D1[Agile Methods<br>TDD<br>Refactoring]
    E1[DDD<br>BDD<br>Microservices]
    F1[API-first<br>Event-driven<br>Continuous Design]
    
    %% Connexions
    A --- A1
    B --- B1
    C --- C1
    D --- D1
    E --- E1
    F --- F1
    
    %% Styles pour meilleure lisibilité
    style A fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    style B fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    style C fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    style D fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    style E fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    style F fill:#f9eacf,stroke:#d9a252,stroke-width:2px
    
    %% Style des méthodologies
    style A1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    style B1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    style C1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    style D1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    style E1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    style F1 fill:#e8f4f8,stroke:#5aa9d6,stroke-width:1px
    
    %% Annotations complémentaires
    AN[Légende:<br>Les méthodologies sont cumulatives,<br>avec une évolution vers plus d'agilité<br>et de design centré utilisateur]
    style AN fill:#f9f9f9,stroke:#aaa,stroke-width:1px,stroke-dasharray: 5 5

Figure 10: Évolution des méthodologies de conception logicielle (1970-2020s)

Domain-Driven Design (DDD)

Philosophie: Alignement du code sur le modèle mental du métier

Étapes clés:

Établir un langage omniprésent
Identifier les bounded contexts
Modéliser le domaine (entités, agrégats, services)
Implémenter en préservant l’intégrité du modèle

Test-Driven Development (TDD)

Philosophie: Les tests guident la conception

Étapes clés:

Écrire un test qui échoue (RED)
Écrire le code minimal pour passer le test (GREEN)
Améliorer le code sans changer son comportement (REFACTOR)
Répéter

Behavior-Driven Development (BDD)

Philosophie: Les comportements attendus définissent le logiciel

Étapes clés:

Spécifier le comportement en langage naturel structuré (Given-When-Then)
Automatiser les spécifications en tests exécutables
Développer pour satisfaire les comportements
Utiliser les scénarios comme documentation vivante

Model-Driven Architecture (MDA)

Philosophie: Les modèles abstraits sont la source de vérité

Étapes clés:

Créer un modèle indépendant de la plateforme (PIM)
Transformer en modèle spécifique à la plateforme (PSM)
Générer le code à partir du PSM
Affiner et compléter l’implémentation

Feature-Driven Development (FDD)

Philosophie: Organiser le développement autour des fonctionnalités utilisateur

Étapes clés:

Développer un modèle global
Construire une liste de fonctionnalités
Planifier par fonctionnalité
Concevoir par fonctionnalité
Implémenter par fonctionnalité

Continuous Design

Philosophie: La conception évolue progressivement avec le code

Étapes clés:

Commencer avec un design minimal viable
Intégrer continuellement les changements
Refactoriser régulièrement
Utiliser les métriques pour guider l’évolution
Adapter la conception aux nouveaux besoins

Event Storming

Philosophie: Exploration collaborative du domaine par les événements

Étapes clés:

Identifier les événements du domaine (post-its)
Ajouter les commandes qui déclenchent ces événements
Identifier les agrégats et règles métier
Organiser en bounded contexts
Dériver le modèle de domaine

Planification et estimation

Techniques d’estimation
- Analogique: Comparaison avec projets similaires
- Paramétrique: Utilisation de métriques (points de fonction, lignes de code)
- Bottom-up: Décomposition et estimation des éléments individuels
- Expert: Jugement basé sur l’expérience
- Planning poker: Estimation collaborative et consensuelle
Outils de planification
- WBS (Work Breakdown Structure) : Décomposition hiérarchique des tâches
- Diagrammes de Gantt (PERT, CPM) : Visualisation des dépendances et durées
- Backlog produit et planification de sprint : Liste des fonctionnalités et ordonnancement par priorité
- Story mapping : Visualisation des fonctionnalités par scénarios utilisateur
- Méthode du chemin critique (CPM) : Identification des tâches critiques
- Story mapping : Visualisation des fonctionnalités par scénarios utilisateur

Maintenance et évolution

Types de maintenance
- Corrective: Correction des défauts
- Adaptative: Adaptation aux changements d’environnement
- Perfective: Amélioration des fonctionnalités
- Préventive: Prévention des problèmes futurs