La mise en production peut (devrait) s’effectuer sur des sites pilotes avant généralisation. v- Évaluation de la qualité de la solution. L’utilisation d’un système de gestion de tickets est recommandée pour le suivi des demandes. 3. Livraisons incrémentales – S’assurer que chaque incrément apporte une valeur mesurable. - Qualité totale : Intégrer la démarche qualité à chaque étape (plan qualité, revues, audits).
9.1 Activités classiques
- Analyse des besoins → spécifications fonctionnelles (cahier des charges).
- Conception générale → architecture (modules, interfaces).
- Conception détaillée → spécifications des fonctions (contrats d’interface).
- Codage (programmation).
- Tests unitaires (validation de chaque composant).
- Intégration & tests d’intégration (assemblage des modules).
- Tests de validation (conformité aux spécifications, scénarios métier).
9.2 Modèles de cycle de vie
| Modèle | Points forts | Points faibles |
|---|---|---|
| Cascade | Simplicité, documentation complète dès le départ. | Rigidité, coûts élevés de retours en arrière. |
| V‑Model | Alignement tests ↔️ conception, détecte tôt les défauts. | Même rigidité que la cascade, difficile à adapter aux changements fréquents. |
| Agile (Scrum, XP) | Rapide, itératif, forte participation du client. | Nécessite une culture “agile”, gestion du scope plus dynamique. |
| Environnement | Rôle | Technologies typiques |
|---|---|---|
| Développement (dev) | Codage, tests unitaires. | Docker, Podman, VS Code, Git. |
| Intégration / Test (int) | Tests d’intégration, validation QA. | Docker‑Compose, Kubernetes (minikube), Selenium. |
| Pré‑production (pre‑prod) | Reproduction de la prod, recette client. | VM snapshot, Helm charts. |
| Production (prod) | Service en ligne, support. | Kubernetes, Helm, monitoring, alerting (Prometheus + Alertmanager). |
CI/CD : pipeline automatisé (ex : GitLab CI → build → test → scan security → push image → deploy). Containers : lxc, Docker, Podman simplifient la reproduction d’environnements et accélèrent le déploiement.
9.3.2 Extreme Programming (XP)
| Pratique XP | Description | Valeur ajoutée |
|---|---|---|
| Client sur site | Représentant client présent en permanence. | Décisions rapides, clarification constante. |
| Planning poker | Estimation collective des scénarios. | Consensus, visibilité sur le coût. |
| Intégration continue | Chaque modification intégrée immédiatement. | Réduction du risque d’intégration massive. |
| Petites livraisons | Release fréquentes (hebdomadaires ou bi‑hebdomadaires). | Retour rapide du client, adaptation continue. |
| Rythme soutenable | Pas d’heures supplémentaires systématiques. | Qualité du code, bien‑être de l’équipe. |
| Tests fonctionnels (recette) | Scénarios définis par le client, automatisés le plus possible. | Validation continue, non‑régression. |
| Tests unitaires | Écrits avant le code (TDD). | Code fiable dès le départ. |
| Conception simple | Implémenter uniquement ce qui est demandé. | Moins de dette technique. |
| Métaphores | Utilisation d’analogies pour décrire le système. | Alignement vocabulaire technique / métier. |
| Refactoring | Amélioration continue du code sans changer le comportement. | Maintenabilité, évolutivité. |
| Appropriation collective | Tous peuvent toucher à tout le code. | Partage de connaissances, réduction du silo. |
| Convention de nommage | Standards communs (naming, formatage). | Cohérence du code base. |
| Programmation en binôme | Deux personnes travaillent ensemble sur le même poste. | Qualité, partage de compétences. |
Une tâche : activité simple, avec :
- Entrées (préalables, livrables requis).
- Ressources (personnes, environnements, outils).
- Sorties (livrable, livrable pouvant servir d’entrée à d’autres tâches).
Utilisez PERT / MPM pour visualiser les dépendances, Gantt pour planifier, et Kanban (tableau : À faire – En cours – À valider – Terminé) pour le suivi quotidien.