GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

Transcription

1 GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 2ÈME PARTIE PROCESSUS DE DEVELOPPEMENT DU LOGICIEL (SOFTWARE PROCESS) Faculté des Sciences et Techniques

2 Plan de cette partie de cours 2 Modèles de processus de développement du logiciel Les activités de ces processus Prise en compte des changements

3 3 Le processus de développement de logiciel Un ensemble structuré d activités nécessaires pour développer un logiciel Un modèle de développement de logiciel est une représentation abstraite d un processus De nombreux modèles différents mais pour tous : Spécification : on définit ce que le système devra faire Conception et implémentation : on définit l organisation du système et on l implémente Validation : on vérifie que le système fait bien ce que veut le client Evolution : on modifie le système en réponse aux changements des besoins du client

4 4 Description du processus de développement de logiciel Quand on décrit des processus, on parle des activités au sein de ceux-ci telles que : spécifier un modèle de données, concevoir une interface, etc et l ordonnancement de ces activités La description du processus peut aussi inclure Les produits, qui sont les résultats des sorties d une activité d un processus Les rôles, qui reflètent les responsabilités des personnes impliquées dans le processus Les pré- et post-conditions, qui sont des conditions vraies avant et après l activité d un processus

5 Processus agile vs dirigé par 5 planification Dans un processus dirigé par la planification, toutes les activités sont planifiées à l avance et les progrès sont mesurés vis-à-vis de ce plan Dans les processus agiles, la planification est incrémentale. Il est alors plus facile de changer le processus pour refléter les changements de besoins utilisateurs En pratique : un peu des deux Il n y a pas de bon ou mauvais choix

6 Les modèles de développement de 6 logiciel Le modèle en cascade Modèle en V Développement incremental (prototypage) Modèle orienté réutilisation Le modèle en spirale En pratique : mélange de divers modèles

7 Le modèle en cascade 7 Etude préalable Spécification Conception générale Conception détaillée codage intégration Validation recette diffusion exploitation

8 Les étapes du modèle en cascade 8 Etude préalable (feasibility) Phase exploratoire Y-a-t-il lieu de réaliser le logiciel? Fixer les conditions générales Débouche sur une phase conceptuelle Cahier des charges et plan de projet Spécification (requirements) Description informelle définition précise Des objets manipulés Des tâches à effectuer sur ces objets Des contraintes de performance Planification détaillée des étapes suivantes

9 Le modèle en cascade 9 Etude préalable Spécification Conception générale Conception détaillée codage intégration Validation recette diffusion exploitation

10 Les étapes du modèle en cascade 10 Conception générale (product design) Définition réalisation Architecture du système Principales structures de données Décomposition du système en modules Conception détaillée (detailed design) Raffinement des éléments précédents jusqu à l obtention d une forme permettant d écrire immédiatement les programmes

11 Le modèle en cascade 11 Etude préalable Spécification Conception générale Conception détaillée codage intégration Validation recette diffusion exploitation

12 Les étapes du modèle en cascade 12 Codage (coding) Écriture des textes des programmes Intégration Regroupement des divers modules Construction de l architecture générale Validation globale/recette Diffusion Préparation et distribution des différentes versions Exploitation Mise en place du système dans son environnement opérationnel

13 Le modèle en cascade 13 Deux interprétations Neutre : c est une description Volontariste : on doit suivre ces étapes On doit suivre TOUTES les étapes L ordre doit être respecté On passe à l étape n que lorsque l étape n-1 est terminée Les remises en cause font remonter d un seul niveau Principale faiblesse : difficulté à s adapter aux changements une fois le processus lancé

14 14 Documents produits par les étapes du modèle en cascade Étude préalable Phase exploratoire Dossier d entretiens Décisions (faire, ne pas faire, faire faire, acheter) Budget approximatif Phase conceptuelle Cahier des charges Plan général du projet Budget précis Définition des contraintes Spécification Document de spécification (fonctions et performances) Première version du manuel utilisateur Plan détaillé du reste du projet Plan de validation

15 15 Documents produits par les étapes du modèle en cascade Conception générale Définition des principales structures de données Décomposition du système en modules (architecture) Description du rôle de chaque module Conception détaillée Description détaillée des structures de données et des modules Codage Texte des programmes Chaque module est vérifié séparémment Validation globale, recette Compte rendu de recette Rapports d inspection et de validation Diffusion Versions des programmes et de leur documentation adaptées Exploitation Programme en fonctionnement Rapports d incidents et de correction

16 Le modèle en cascade 16 Etude préalable Spécification Conception générale Conception détaillée codage intégration Validation recette diffusion exploitation

17 Spécification 17 Processus qui dresse la liste de ce qui est attendu du système, ainsi que les contraintes sur l exécution du système et son développement Requirement = besoin/exigence/spécification Requirement engineering process Etude de faisabilité Est-il techniquement et financièrement faisable de construire le système? Elicitation et analyse des exigences Qu est-ce que les parties prenantes du système attendent de ce système? Spécification des exigences On définit les exigences en détail Validation des exigences On vérifie la validité des exigences

18 18 Le processus de spécification

19 Le modèle en cascade 19 Etude préalable Spécification Conception générale Conception détaillée codage intégration Validation recette diffusion exploitation

20 Conception et implémentation 20 Processus consistant à convertir la spécification en un système exécutable Conception Conception de la structure du logiciel permettant de réaliser la spécification Implémentation Traduction de cette structure en un code compilable Activités très liées

21 21 Modèle général du processus de conception

22 Les activités de la conception 22 Conception de l architecture Identification de la structure globale du système Les principaux composants Leurs relations Conception des interfaces On définit les interfaces du système Conception des composants Conception de chaque composant de façon indépendante Conception de la base de données Conception de la structure de la base de données

23 Vérification et Validation 23 Vérification Le système est conforme à la spécification (are we doing the product right?) Validation Le système répond aux exigences du client (are we doing the right product?) Inspections et tests Tests On exécute le système avec des cas de tests issus de la spécification de données réelles du système futur

24 Les phases de test 24 Tests unitaires Les composants sont testés individuellement Tests d intégration Test du système global Tests de recette Test avec des données clients pour vérifier que le système répond aux exigences du client

25 25 Les phases de test

26 Problèmes du modèle en cascade 26 Découpage rigide du projet en étapes distinctes difficile de s adapter aux changements des besoins utilisateurs Modèle bien adapté si les spécifications peuvent être précises dès le début et changeront peu Toutefois, il est rare d avoir des spécifications stables Les tests sont prévus tardivement Le modèle en cascade est principalement utilisé dans les grands projets où les systèmes sont développés sur plusieurs sites Dans ce cas, le modèle en cascade facilite la planification du projet

27 Le modèle en V 27 Etude préalable exploitation Spécification Validation recette Conception générale Tests d intégration Conception détaillée Tests unitaires codage

28 28 Modèle en V

29 Evolution du logiciel 29 Les logiciels sont flexibles et peuvent évoluer Les exigences peuvent changer avec les évolutions de l environnement (législatifs, financiers, techniques, etc) le logiciel basé sur cet environnement doit évoluer De plus en plus de nouvelles versions par évolution de nos jours

30 30 Evolution du logiciel

31 31 Développement incrémental

32 32 Bénéfices du développement incrémental Les coûts de l adaptation aux évolutions des exigences clients sont réduits Le volume d analyse et documentation qui doivent être conçu à nouveau est moindre que dans le modèle en cascade Il est plus facile d avoir des feedbacks réguliers du client Les clients peuvent faire des commentaires lors de démonstrations et constater l avancée du travail Possibilité de livrer plus rapidement des morceaux de logiciels utiles au client Le client peut utiliser des morceaux de logiciels plus tôt que dans le modèle en cascade

33 33 Problèmes du développement incremental Le processus n est pas visible (moins que dans le modèle en cascade) Les managers ont besoin de documents pour mesurer les progrès. Si le système évolue rapidement il n est pas productif de produire des documents reflétant chaque version du système La structure du système a tendance à se dégrader à chaque nouvel incrément à moins que du temps et de l argent soient dépensés pour reconstruire le logiciel pour l améliorer, les changements réguliers conduisent à une déterioration de la structure du logiciel. Plus on incorpore de changements plus cela devient difficile et couteux

34 34 Problèmes du développement incremental

35 Approche orientée réutilisation 35 Basée sur une réutilisation systématique de composants existants (commercial-off-the-shelf COTS) pour concevoir un nouveau système Les étapes du processus Analyse des composants Spécification des modifications Conception avec réutilisation Développement et intégration De plus en plus utilisé de nos jours

36 36 Reuse-oriented software engineering

37 Les types de composants logiciels 37 Les Web services Développés selon des standards Disponibles par appel sur un serveur Collections d objets intégrés dans un framework (tel que.net ou J2EE) Logiciels autonomes (COTS) configurés pour une utilisation dans un environnement particulier

38 S adapter aux changements 38 Les changements sont inévitables dans les grands projets L environnement change changement des exigences Nouvelles technologies possibilité d amélioration des implémentations Evolution des plateformes changement des applications Changements Nouvelles charges Re-analyse des exigences Coût d implémentation de nouvelles fonctionnalités

39 Réduire les coûts du re-développement 39 Eviter les changements Le processus de développement prévoira des activités permettant d anticiper des changements Exemple : développement d un prototype pour montrer des fonctionnalités clés au client Tolérance au changement On s accomode de changements à faible coût Développement incrémental Les changements sont implémentés dans des incréments non encore développés Si cela est impossible alors un incrément peut incorporer les changements

40 Prototypage 40 Un prototype est une version initiale/intermédiaire d un système, utilisée pour démontrer des concepts et faire des essais de choix de conception Un prototype peut être utilisé pour Le processus de spécification pour aider à l élicitation des exigences et leur validation L étape de conception, pour explorer des choix et proposer diverses versions d interfaces Comparer des versions lors de la phase de tests

41 Divers types de prototypes 41 Prototype exploratoire (maquette) Pour expliciter plus clairement l expression des besoins (exigences) Horizontal : permet de tester toutes les fonctionnalités à un niveau abstrait Vertical : quelques fonctions sont testées complètement Prototype expérimental étude de choix de conception Prototype évolutif Réalisé par raffinements successifs

42 Bénéfices du prototypage 42 Améliore la facilité d utilisation du système Meilleur adéquation avec les besoins réels Améliore la qualité de la conception Améliore la maintenabilité Réduit les efforts de développement

43 43 Processus de développement de prototype

44 Développement de prototype 44 Peut être basé sur des langages ou outils de prototypage Peut laisser de côté la fonctionnalité du produit Le prototype se focalise plutôt sur des côtés du produits qui ne sont pas bien compris Le traitement des erreurs peut ne pas être spécialement étudié dans le prototype Se focalise sur les exigences fonctionnelles plutôt que les non fonctionnelles

45 Prototypes jetables 45 Un prototype n est pas une bonne base pour un système commercial Il peut être impossible de répondre à des exigences non fonctionnelles Les prototypes sont souvent non documentés La structure d un prototype se dégrade généralement rapidement avec les évolutions Le prototype ne répond souvent pas aux standards de qualité de l environnement client

46 Livraison incrémentale 46 Plutôt que de livrer un système en une fois, le développement et la livraison sont découpés en incréments, chaque incrément permettant de livrer une partie de la fonctionnalité Les exigences sont ordonnées suivant leur priorité. Les exigences les plus prioritaires sont inclues dans les premiers incréments Lorsque le développement d un incrément a commencé, les exigences sont figées. Les exigences pour les autres incréments peuvent continuer à évoluer

47 47 Développement et livraison incrémental Développement incremental On développe le système par incrément. Chaque incrément est évalué avant de commencer le développement de l incrément suivant C est la démarche usuelle dans les méthodes agiles Evaluation réalisée par utilisateur/client Livraison incrémentale On déploit un incrément pour un utilisateur final Approche délicate pour les systèmes de remplacement car alors les incréments possèdent moins de fonctionnalités que le système à remplacer

48 48 Livraison incrémentale

49 Avantage de la livraison incrémentale 49 Chaque incrément apporte de la valeur pour le client les fonctionnalités du système sont disponibles plus tôt Des incréments précoces peuvent servir de prototypes et aider à l élicitation d exigences Moins de risque d échec global du projet Les services prioritaires du système ont tendance à subir le plus de tests

50 50 Problèmes de la livraison incrémentale La plupart des systèmes requièrent un ensemble de fonctionnalités de base utilisées par les diverses parties du système Comme les exigences ne sont pas définies en détail tant qu un incrément n est pas implémenté, il peut être difficile d identifier les fonctionnalités communes à tous les incréments L essence même du processus itératif est que la spécification est développée simultanément au logiciel Cela peut être en conflit avec le fait que les spécifs font partie du contrat

51 Modèle en spirale 51 Le processus de développement est représenté par une spirale plutôt qu une séquence d activités avec retour arrière éventuels Chaque boucle dans la spirale représente une étape du processus de développement Les risques sont explicitement adressés et résolus tout au long du processus

52 52 Modèle en spirale

53 Les divers secteurs du modèle en spirale 53 Définition des objectifs Les objectifs spécifiques de l étape sont identifiés Estimation et réduction des risques Les risques sont évalués et des activités sont mises en place pour réduire les risques clés Développement et validation Un modèle de développement est choisi pour le système Planification Le projet est inspecté et l étape suivante de la spirale est planifiée

54 54 FIN DE LA 2 ème PARTIE