Processus de développement de logiciel

Le cycle de vie d’un produit - depuis la création d'une idée pour un produit à travers ...

• analyse du domaine
• collecte des exigences
• conception de l'architecture et spécification
• programmation et vérification
• livraison et le déploiement
• maintenance and évolution
• retraite

Problèmes de qualité et de coût du logiciel:

• Livraison en retard
• Coût plus grand que prévu
• Sans donner la satisfaction anticipée aux usagers

Les raisons:

• Il est difficile de comprendre le but du système assez bien pour planifier sa fonctionnalité au début et donner complète satisfaction aux usagers.
• La complexité du système et de son comportement dynamique est trop grande.
• La nature de visibilité du produit rend l’effort de développement et de maintenance difficile à comprendre et à contrôler.
• Il y a un manque de composantes éprouvées qui peuvent servir comme modules réutilisables. Il y a trop de re-développement.

Problèmes avec l'approche boite noire:

• L'hypothèse est que les exigences peuvent être pleinement compris avant le développement. (Malheureusement l'hypothèse presque jamais valide)
• Interaction avec le client ne se produit qu'au début (exigences) et la fin (après la livraison)
• Il y a normalement un problème de communication

Avantages de l'approche boite blanche:

• Réduire les risques en améliorant la visibilité
• Autoriser les changements de projet pendant que le projet avance, basés sur la réaction du client
• Il a différents processus de développement basés sur l'approche boite blanche: cascade, itératif, agile, etc.

Processus en cascade

• Inventé dans les années 1950 pour les grands systèmes de défense aérienne, popularisé dans les années 1970
• Organise les activités dans un flux séquentiel
• On standardise les sorties des différentes activités (livrables)
• Existe en de nombreuses variantes, tous partageant le style de flux séquentiel

Exemple d'activités:

Points forts du processus en cascades:

• Facile à comprendre, facile à utiliser
• Fournit la structure pour les personnels inexpérimentés
• Les étapes sont bien comprises
• Crée des exigences stables
• Facilite la gestion du projet
  

Points faibles du processus en cascades:

• Toutes les exigences doivent être connus d'avance
• Livrables de chaque phase sont considérés statiques- cela affecte négativement la flexibilité
• Peut donner une fausse impression de progrès
• Ne reflète pas la vrais nature de développent de logiciel: résolution des problèmes d’une façon itératif
• L'intégration est un big bang à la fin
• Peu de chances pour que le client voie et vérifie le système (avant qu'il soit trop tard)

Quand utiliser le processus en cascades . . .

• Quand . . . (mais cela arrive rarement)
  • Les exigences sont très bien connues
  • Définition du produit est stable
  • La technologie est très bien comprise
  • Nouvelle version d'un produit existant (peut-être!)
  • Portage d'un produit existant à une nouvelle plate-forme
• En général
• Risque élévé pour un nouveau système à cause de problèmes de spécification et conception
• Risque bas pour des développements bien compris utilisant des technologies familières

Processus itératif

Aussi appelé processus de développement incrémental. Il s'agit de développer le système par cycles répétés (itérations)

• Chaque cycle est responsable du développement d'une petite portion de la solution (tranche de fonctionnalité)
• Comparaison avec le processus en cascade: ce dernier est un processus en cascade spéciale avec un seul cycle

Processus agile

Insatisfaction avec les processus de développement des années 1980 et 1990 (après des faillites successives) a résulté dans la création de méthodes agiles. Ces méthodes:

• Donnent l'importance au code plutôt qu'à la conception
• Sont basés sur une approche itérative pour le développement de logiciels
• Sont supposés aider à produire des logiciels rapidement
• Les logiciels doivent être capables d’évoluer rapidement avec les changements dans les exigences

L'objectif de ces méthodes est de réduire les frais généraux (overhead) dans le processus de développement (par exemple limiter la documentation) et à être en mesure de répondre rapidement à l'évolution des exigences

MANIFESTO: Nous découvrons des meilleures façons pour développement de logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous nous sommes rendu-compte que (c'est à dire, les items sur la droite sont utiles, main nous accordant plus d’importance sur les items à gauche):

• Interaction entre les individus - Processus et outils
• Logiciel qui fonctionne - Documentation compréhensive
• Collaboration avec le client - Négociations prolongées sur les contrats
• Réagir au changement - Suivre un plan

Problèmes avec les méthodes agiles:

• Il peut être difficile de maintenir l'intérêt des clients qui sont impliqués dans le processus
• Membres de l'équipe peuvent être inadaptées à l’intensité qui caractérise les méthodes agiles
• La minimisation de documentation: presque rien n'est capturé, le code est la seule autorité

Vue vers le futur

De plus en plus, les activités du développement de logiciel peuvent être automatisées en utilisant des outils CASE appropriés. Ce cours donne une introduction à certains de ces outils:

• Des machines à états ou des diagrammes d'activités peuvent être utilisés comme prototypes qui modélisent les exigences fonctionnelles du système à construire - ou qui représentent la conception du système.
• Beaucoup d'outils fournissent des modèles exécutables qui peuvent être utilisés pour la simulation interactive et autres activités de validation-vérification (V&V).
• Des outils de "Model Checking" peuvent être utilisés pour prouver que de tels modèles ont certaines propriétés désirables (dans toutes les circumstances). Un exemple d'une telle propriété est l'absense de bloquage, ce qui est particulièrement difficile à déterminer dans le cas où plusieurs composantes du système interagissent. Dans ce cours, vous allez voir l'outil simple LTSA.
• Après la validation du modèle, le code d'implantation correct peut être généré automatiquement. La plupart des outils UML fournissent de telles facilités. Nous allons utiliser l'outil Umple dans ce cours.
• Dans le contexte de la construction de compilateurs et de l'analyse de langues, des outils existent pour s'occuper de l'analyse lexicale et syntaxique des langages. Nous allons utiliser des outils supportant des expressions régulières pour l'analyse lexicale, et allons comprendre comment des analyseurs syntaxiques peuvent être créés d'une façon systématique.

Les diagrammes suivants, proposés par David Harel (l'auteur de Hierachical State Charts), indiquent comment il voit le développement de logiciels dans les décennies qui viennent:

Notes de cours - Gregor v. Bochmann - University of Ottawa. Créées: January 9, 2015 - Note: cette page contient beaucoup de matériel copié des diagrammes Powerpoiont utilisés par Hussein Al Osman pour ce cours en 2014