110 lines
4.4 KiB
Markdown
110 lines
4.4 KiB
Markdown
---
|
|
title: "PdP: Introduction aux processus de développement logiciel"
|
|
date: 2024-01-24
|
|
tags: ["besoins", "analyse", "developpement logiciel"]
|
|
categories: ["Projet de programmation", "Cours"]
|
|
---
|
|
|
|
Le génie logiciel a pour finalité de permettre au logiciel développé:
|
|
|
|
* d'avoir plus de chance d'être **adéquat à la demande**: analyse des besoins,
|
|
fonctionnalités, services, performances, documentation;
|
|
* d'avoir plus de chance de **fonctionner**: spécifications, tests, outils
|
|
d'analyse, technique de programmation;
|
|
* d'avoir plus de chance de **durer**: code lisible, analysable, déboggable,
|
|
extensible, documenté etc.;
|
|
* soit développé dans de **bonnes conditions** et de **manière efficiente**:
|
|
processus de développement, outils adaptés et encore une fois
|
|
*documentation*.
|
|
|
|
Le génie logiciel permet donc le passage à l'échelle là où le bricolage ne
|
|
suffit plus.
|
|
|
|
D'après le théorème de Rice:
|
|
|
|
> Toute propriété non triviale d'un programme est indécidable.
|
|
|
|
En conséquence, la plupart des propriétés de fonctionnement des logiciels sont
|
|
indécidable.
|
|
|
|
Si le matériel informatique évolue vite (loi de Moore), les technique de
|
|
développement logicielle le font lentement! Pour information, les technique de
|
|
programmation orientée objet **ont été conçue dans les années 60**.
|
|
|
|
Il est aussi difficile d'automatiser lorsqu'il s'agit de génie logiciel. Ce qui
|
|
explique les efforts pour inclure des techniques d'apprentissage automatique
|
|
(*machine learning*) et l'IA générative dans le génie logiciel.
|
|
|
|
## Les processus de développement
|
|
|
|
Ce processus inclut en général :
|
|
|
|
* une phase de spécification comprenant:
|
|
* une analyse des besoins
|
|
* son énonciation
|
|
* une modélisation et conception
|
|
* une mise en œuvre/implémentation
|
|
* une validation/vérification et des tests
|
|
|
|
Il existe plusieurs modèles de développement logiciels classique. Il doit être
|
|
choisis en fonction des propriétés du logiciels (type, taille de l'équipe ...).
|
|
Ces modèles se divises en deux parties:
|
|
|
|
* les processus séquentiels;
|
|
* les processus incrémentaux et itératifs (agiles).
|
|
|
|
|
|
### Processus séquentiels
|
|
|
|
#### Le processus en cascade
|
|
|
|
Les phases de développement sont effectuées de manière séquentielle. Il est
|
|
inspiré des industries manufacturières et de la construction. Il en existe
|
|
plusieurs variantes.
|
|
|
|
Il est cependant impossible de revenir en arrière dans ce modèle de base. Si les
|
|
exigence du départ son mal exprimées ou erronés alors il est possible que le
|
|
projet soit intégralement à re-développer.
|
|
|
|
Cette méthode manque aussi de retours (*feedback*) entre les étapes.
|
|
|
|
C'est aussi un modèle rigide.
|
|
|
|
#### Le cycle en V
|
|
|
|
C'est une évolution du modèle en cascade pour intégrer des tests de
|
|
vérifications et de validation pour chacune des phases. Là aussi des variantes
|
|
existent, surtout au niveau des *feedback* (destination, qualification).
|
|
|
|
#### Conclusion sur les modèles séquentiels
|
|
|
|
Chacune des phase de développement sont clairement distinctes les unes des
|
|
autres avec les différentes responsabilités des acteurs. Chacune des phases
|
|
incluent une vision et des spécifications globale du logiciel. Ces modèles sont
|
|
adaptés aux gros projets ou chacune des étapes peut être assignée à une équipe
|
|
différente.
|
|
|
|
Cependant le commencement d'une étape nécessite que les précédentes soient
|
|
terminées. Il est aussi difficile de revenir en arrière (vers des phases
|
|
précédentes), les modifications / améliorations sont difficilement réalisable
|
|
qui plus est quand les problèmes surviennent. Les vérifications globales ne se
|
|
font que sur les phases finales.
|
|
|
|
Il existe **des adaptations moins séquentielles** de ces méthodes avec l'accent
|
|
sur les tests et les retours facilité.
|
|
|
|
### Processus de développement agiles
|
|
|
|
C'est l'autre grande famille de processus de développement. Ici les phases sont
|
|
cycliques avec des retours en arrières possibles (processus itératif). C'est lié
|
|
à la notion d'*Xtreme Programing*.
|
|
|
|
Le processus est plus réactif / flexibles. Le client / demandeur est partie
|
|
intégrante du processus ( et / ou les futurs utilisateurs).
|
|
|
|
Cependant les phases manque de profondeur dans les phases de conceptions et de
|
|
spécification.L
|
|
|
|
es méthodes agiles ne sont pas adaptées à de gros projet. Mais des alternatives,
|
|
ou plutôt des dérivés comme le *Scrum of Scrum* et d'autres processus *Meta
|
|
Agile* et une organisation hiérarchique de plusieurs équipes.
|