Génie logiciel (Un aperçu)

Transcription

1 (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH St Genès Champanelle

2 Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de projets 16% sont un succès 31% sont arrêtés en cours de réalisation 53% aboutissent mais au prix d'un accroissement du délai et du coût tout en offrant moins de fonctionnalités que prévu. Succès: implication des utilisateurs et exigences claires implication des dirigeants Echec: manque de clarté des besoins évolution des spécifications en cours de réalisation Exigence Dirigeant Evolution Utilisateur (standishgroup, 1995) Liste :

3 De nombreux processus de développement existent Modèle en cascade DSDM Pas de choix universel Modèle en V UP - Unified Process XP - extreme Programming RAD - Développement rapide d'applications Le choix dépend de : L organisation qui développe Le type de logiciel Les personnes impliquées

4 Ensemble d activités conduisant à la production d un logiciel 4 activités communes aux processus de développement : - définir les spécifications - conception et implémentation - validation -évolution Définir les spécifications : définir les services et les contraintes Conception et implémentation : convertir des spécification en un système exécutable Validation : conforme aux spécification et aux attentes de l utilisateur Evolution : changements durant ou après le développement du système

5 Perspectives Développement incrémental Modèle en cascade Evolution Réutilisation de composants logiciels

6 Cycle de vie/modèle en cascade Spécifications Conception Codage et tests unitaires beaucoup de documentations réponse difficile aux changements des spécifications utilisation uniquement à partir de la phase de maintenance Intégration et test global maintenance

7 Développement incrémental Incrément Version1 Version2 Version3 Version4 Version5 Version6 Plusieurs versions avant d obtenir toutes les spécifications Chaque version est testée, reçue par un utilisateur

8 Développement incrémental Activités spécification Version initiale Description générale Développement Versions intermédiaires Validation Version finale Plus d interactions avec les utilisateurs: plus d adaptations aux changement des besoins Au lieu de juger sur des documents, les utilisateurs jugent sur une version qu ils peuvent tester Même si toutes les fonctionnalités ne sont pas réalisées, on peut déployer une version intermédiaire

9 Spécification Réutilisation de composants logiciels Recherche de composants Modification des spécifications Conception avec composants réutilisables Développement et intégration de nouveaux composants Validation

10 Evolution Le logiciel sera en constante évolution. Le coût de la maintenance est beaucoup plus élevé que celui de la conception initiale Anticiper les changements Tolérance aux changements Prototypage Développement incrémental Un prototype teste un aspect particulier Interface utilisateur Valider les besoins fonctionnels Démontrer la faisabilité du développement aux décideurs

11 Cycle de vie en cascade Développement incrémental Réutilisation de composants logiciels Evolution Méthodes de développement Modèle en cascade UP - Unified Process RAD - Développement rapide d'applications DSDM XP - extreme Programming

12 Processus unifié (UP) Cas d utilisation Architecture Itératif et Incrémental

13 Processus Unifié (UP) Version 1 Version 2 Version n Chaque version est utilisable! Incrément Prototype Mini-projet 1 Mini-projet 2 Mini-projet m Inception Elaboration Construction Transition V E R S I O N 1

14 Processus unifié (UP) Les phases : obtenir une version Inception Que va faire essentiellement le logiciel pour les principaux utilisateurs, quelle pourrait être l architecture, quelle est la planification et le coût? Elaboration La majorité des spécifications et l architecture sont définies Construction Produit prêt à être transmis au utilisateurs Transition Version bêta aux utilisateurs expérimentés, performances, formations...

15 Processus unifié (UP) Comment mener un mini-projet (prototype)? Mini-projet 1 Mini-projet 2 Mini-projet m Définition des besoins Analyse Conception Implémentation Tests Ce qui est masqué : besoin en documentation, formalisation UML V E R S I O N 1 Mini-projet 1

16 Processus unifié (UP) Variantes à Unified Process Agile Unified Process (AUP), a lightweight variation Enterprise Unified Process (EUP), an extension of the Rational Unified Process Essential Unified Process (EssUP), a lightweight variation Open Unified Process (OpenUP), the Eclipse Process Framework software development process Rational Unified Process (RUP), the IBM / Rational Software development process Oracle Unified Method (OUM), the Oracle development and implementation process Rational Unified Process-System Engineering (RUP-SE), a version of RUP tailored by Rational Software for System Engineering

17 Méthodes de développement agiles Le Manifeste Agile Les quatre valeurs fondamentales Agiles sont: Davantage l interaction avec les personnes que les processus et les outils. Davantage un produit opérationnel qu une documentation pléthorique. Davantage la collaboration avec le client que la négociation de contrat. Davantage la réactivité face au changement que le suivi d'un plan.

18 Plannifiée/ Agile Approche plannifiée Analyse des besoins Spécification des besoins Conception et implémentation Approche agile Analyse des besoins Conception et implémentation

19 Extreme Programming(XP) Sélectionner un scénario d un utilisateur Evaluer le système Eclater le scénario en tâches 2 semaines Paire de programmeurs Interaction et choix avec l utilisateur Logiciel déployé Planifier la version Développement Intégration test

20 Comparaison de quelques méthodes Méthode Points clés Désavantages XP RUP Scrum FDD Guidé par les besoins du client. Binômes. Amélioration constante Adaptativité aux modifications. Processus complet assisté par des outils. Exhaustif. Rôles bien définis, modélisation. Petites équipes, itérations de 30 jours, réunions journalières. Procédé bien défini et simple, orienté objet et basé sur le développement. Itérations très courtes. au détriment d'une vue globale et des pratiques de management ou de formalisation. Lourd, largement étendu, il peut être difficile à mettre en oeuvre de façon spécifique. Convient pour les gros projets qui génèrent beaucoup de documentation. La mise en oeuvre du développement n'est pas précisée, seule compte la gestion des ressources humaines. Uniquement centré sur le développement.

21 Model Driven Architecture (MDA) (Object Management Group) Séparation infos métiers du technique : pérennité des savoir-faire Automatisation de modèles, productivité meilleur Platform Independant Model Platform Specific Model CODE Transformations automatiques On complète manuellement On complète manuellement Formalisme UML

22 Modelisation conceptuelle Séparer le modèle de connaissance de la technique logicielle Modèles à Compartiments Unified Modeling Langage (UML) (J. Learmount et al. 2006)

23 Références Kruchten P. Introduction au Rational Unified Process. Eyrolles, p. LearmountJ., M.A. Taylor, G. Smith, C. Morgan. A computer model to simulatecontrol of parasiticgastroenteritisin sheepon UK farms. VeterinaryParasitology. V. 142, pp Rota V.M. Gestion de projet : Vers les méthodes agiles. Eyrolles, p. SommervilleI. Software Engineering: International Version.Pearson Education (US); Édition: 9th Revised edition, pages