Add PdP introduction

content/projet_programmation/3_indroduction/index.md

@@ -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.