Add PdP introduction
This commit is contained in:
parent
460e9485c8
commit
924ab58f63
1 changed files with 110 additions and 0 deletions
110
content/projet_programmation/3_indroduction/index.md
Normal file
110
content/projet_programmation/3_indroduction/index.md
Normal file
|
@ -0,0 +1,110 @@
|
||||||
|
---
|
||||||
|
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.
|
Loading…
Add table
Add a link
Reference in a new issue