Cycle De Vie D'un Logiciel

CYCLE DE VIE D’UN LOGICIEL Définition d'un système – Un système est un ensemble d'éléments matériels et logiciels qui permettent • D'assurer un ensemble de fonctions d'échanges d'informations avec son environnement extérieur • Le traitement de ces informations

– La décomposition en éléments est définie en concertation avec le client – Souvent volumineux, un sous-ensemble logiciel est alors décomposé en composants logiciels

1/36

Les fonctions du développement logiciel – Fonctions de production • • • • • • • •

Expression des besoins Spécification Conception Programmation et tests unitaires Intégration et tests de qualification Installation Exploitation et maintenance Rétro-ingénierie

– Fonctions de gestion et de contrôle • Gestion de projet • Évaluation du produit tout au long de développement • Gestion de configuration

2/36

Les fonctions de production – Expression des besoins • Le but de cette activité est de définir les besoins exacts attendus pour un domaine d'application donné en terme de – Frontières – Rôles – Ressources disponibles et requises – Contraintes d'utilisation et de performance • Définition des limites en terme – Économiques et de stratégie technique » Analyse de la valeur, ressources, délais, retour sur investissement » Faisabilité, choix matériel et technologie – De risques » Grands projets, sûreté de fonctionnement – De compétitivité et d'avantage concurrentiel – D'organisation globale » Relations MOA/MOE, projets étatiques, consortium 3/36

Les fonctions de production – Expression des besoins • Nécessité d'un dialogue entre les experts du domaine d'application et les futurs utilisateurs • Les méthodes utilisées ne relèvent pas directement des techniques informatiques • Le résultat de cette phase est un ensemble de documents qui décrivent – Les aspects pertinents de l'environnement du futur système, son rôle et sa future utilisation – Un manuel d'utilisation préliminaire – Le partage entre logiciel et matériel • L'analyse des besoins est l'activité essentielle du début du processus de développement… – Apparition des nouvelles questions sur les besoins et l'environnement • …et se poursuit durant tout le processus et tout le cycle de vie du logiciel – Maintenance évolutive

4/36

Les fonctions de production – Spécification • Le but de cette phase est d’établir une première description du futur système • Les données en entrée sont – Les résultats de l’expression des besoins – Les considérations de techniques et faisabilité informatique • Le résultat est une description de ce que doit faire le logiciel – On dit quoi, on ne dit pas comment • Cette description est le point de départ du développement • Cette phase est – Fortement corrélée avec la phase d’expression des besoins – Corrélée avec la phase de validation • Eviter de faire des choix d’implémentation prématurés • Chaque besoin sera traduit en terme d’exigence

5/36

Les fonctions de production – Spécification • Cette phase nécessite parfois un maquettage ou un prototypage de certaines fonctions – Pour être en mesure de les spécifier correctement – Particulièrement vrai pour les E-programmes • Le maquettage est caractérisé par – Un développement rapide » Sans contrainte de performance » Ni toutes les fonctionnalités » Et ne répond pas aux exigences finales de qualité – Il facilite l’expression des besoins et la spécification des éléments logiciel en contact direct avec les utilisateurs • Le prototypage est caractérisé par – Le développement d’un système » Éventuellement incomplet » Dans son dimensionnement réel – Il permet de faire des essais en vrai grandeur – Il est composé de code instrumenté et constitue un premier incrément du logiciel – Il est codé dans un autre langage ou “bouchonné" 6/36

Les fonctions de production – Conception • Cette phase consiste à définir de façon très précise les fonctions et architecture du logiciel – On passe à la description du comment • Elle se décompose en deux étapes – Conception préliminaire » Définition de l’architecture en composants simples » Définition des interfaces et des fonctions de chaque composant – Conception détaillée » Fournit le détail de chaque composant : algorithmes, représentation des données » Définit la structure de contrôle, l’enchaînement des fonctions et le séquencement des opérations • Cette phase est corrélée avec l’activité d’intégration • Tous les composants sont répertoriés dans la nomenclature du logiciel (gestion de configuration) 7/36

Les fonctions de production – Programmation et tests unitaires • Cette phase correspond à la programmation des fonctions issues de la conception • Traduction en langage de programmation Applications de normes de programmation • Cette phase est la plus outillée • A ce stade on passe de la pensée à l’exécutable • Les premières faiblesses vont se révéler • Nécessité de rétro-conception • Chaque fonction programmée doit compiler sans erreur • Chaque fonction programmée doit faire l’objet de tests unitaires • L’activité de tests unitaires est un compromis complétude/coût • Cette phase représente – 15 à 20% voire 10% du temps de développement – Contre 40% pour la spécification/conception – Et 40% pour la validation/vérification 8/36

Les fonctions de production – Intégration et tests de qualification • Cette phase consiste à assembler tout ou partie des composants d’un logiciel en vue d’obtenir un système exécutable • Cette phase permet de garantir la vérification et la validation progressive du logiciel • La vérification consiste à s’assurer que les descriptions successives du logiciel satisfont la spécification globale • La validation consiste à s’assurer que le système répond bien aux attentes des utilisateurs • A l’issue de cette phase, il est possible de s’assurer que chacune des exigences qui ont été analysées lors de l’expression des besoins puis spécifiées sont vérifiées • Cette phase utilise la gestion de configuration pour assembler des version cohérentes de chaque composant

9/36

Les fonctions de production – Installation • Cette phase correspond à la mise en œuvre opérationnelle du logiciel dans le contexte client • Il s'agit de vérifier que la procédure d'installation est conforme aux exigences formulées par l'équipe d'exploitation du client • Des formations sont prévues • Le support technique est opérationnel

10/36

Les fonctions de production – Exploitation et maintenance • Cette phase correspond au déploiement du logiciel tel qu'il a été initialement envisagé • Durant cette phase pouvant être longue, assurance du bon fonctionnement du logiciel • Ce qui implique la correction des fautes dans des délais correspondant au contrat de maintenance • Cette activité diffère selon que le logiciel est clef en main ou un progiciel – Correction d'erreurs – Modifications + ou – importantes demandées par les usagers

11/36

Les fonctions de production – Exploitation et maintenance • Maintenance corrective des clefs en main – Corrections des erreurs durant la phase d'exploitation du système » 10 à 20 ans pour les grands systèmes – Pas d'innovation techniques » L'architecture est connue » Les méthodes et outils connus – Pas de création mais nécessite une grande organisation et beaucoup de rigueur parce que grand volume d'information à manipuler » Le mainteneur n'est pas l'auteur » Cohérence documentation, historique, tests et logiciel » Les normes donnent de la rigueur et de l'homogénéité » Si laisser-aller en conception et programmation alors coût de maintenance 12/36

Les fonctions de production – Exploitation et maintenance • Maintenance corrective des progiciels – La problématique est identique aux clefs en main – La complexité supplémentaire vient de l'effet de parc – Les fautes et défaillances ont des manifestations différentes selon les contextes d'emploi – La complexité de correction vient de la combinatoire entre les différents états des systèmes installés » Le nombre d'états technique croît avec l'âge du parc » Le coût de gestion du parc a tendance à croître (objets à gérer + états techniques ) » La solution pour réduire le nombre d'états technique vient de la distribution systématique des corrections sur tout le parc » Solution coûteuse, risquée, voire inutile

13/36

Les fonctions de production – Exploitation et maintenance • Maintenance évolutive – Signe positif de réactivité du parc – Deux catégories d'évolutions » Maintenance adaptative (modification de l'ergonomie, des performances, …) » Ajout d'extensions répondant à des nouveaux besoins – La maintenance évolutive s'apparente à un développement – Il faut pondérer les phases

14/36

Les fonctions de production – Rétro-ingénierie • Le coût moyen des modifications apportées en maintenance – L'architecture et les interfaces se saturent – Risque de régression – La documentation technique se délite – Les tests ne sont plus pertinents – Les équipes de développement et de maintenance ont été renouvelées plusieurs fois – Le flux d'erreurs se remet à croître après une période d'amélioration • Deux attitudes sont possibles – On refait tout (années 80) – On essaie de récupérer (années 90) • Cette dernière opération est appelée rétro-ingénierie

15/36

Les fonctions de production – Rétro-ingénierie • Un grand logiciel qui est composé de S, P et E programmes – Beaucoup de fonctions sont recyclables – Des fonctions P et E deviennent S • Les éléments les plus facilement récupérables – Les documents d'architecture – Le code source – Les données pour les logiciels utilisant des fichiers ou bases de données – Les tests – Certains outils développés spécifiquement • Tous ces éléments doivent être archivés soigneusement • Tout s'articule autour du processus d'intégration

16/36

Les fonctions de gestion et de contrôle – Gestion de projet • Ressources humaines • Organisation • Temps/coûts

– Évaluation du produit tout au long de développement • Contrôles en fonction des prévisions • Revues

– Gestion de configuration • Évolutions, versions, documentation

17/36

Le cycle de vie – Il s'agit de l'ensemble du processus de développement, d'installation et de maintenance – Il est constitué de différentes phases – Chaque phase regroupe un ensemble d'activités cohérent – Point commun à toutes les phases : la documentation • Elle varie d'une norme à l'autre mais d'une façon générale à chaque phase correspond au minimum un document

– Les cycles comportent généralement des revues de fin de phase • Elles vérifient que toutes les exigences de la phase ont été réalisées • Elles valident la phase par passage à la suivante

– Il y a parfois des audits externes, des inspections des services qualité internes

18/36

Le cycle de vie – Il existe différents modèles de cycle de vie • • • • •

IEEE En V En cascade Par incréments En spirale

– Le "temps" de réalisation d'un logiciel est découpé en périodes se superposant en partie ou non durant lesquelles des ensembles d'activités sont définis : les phases

19/36

Le cycle de vie – Exemple : IEEE

20/36

21/36

Le cycle de vie – Le plus courant : en V

• Premières étapes = construction • Dernières étapes = vérification et validation • Deux sortes de dépendances – Enchaînement et itération éventuelle des phases – Dépendance entre les phases amonts et avals

22/36

Spécification des logiciels

23/36

La spécification – Pour qui ? • Le client – vérifier que le système remplit ses objectifs – Il ne faut pas proposer plus que ce que le client exige • Le concepteur – Que faut-il résoudre ? – Que faut-il faire ? – Il faut être le plus précis possible pour faciliter sa tâche

– Antagonisme entre les deux points de vues – Une seule spécification – Solution : exprimer toutes les exigences et que les exigences

24/36

La spécification – Pourquoi ? • S'assurer que l'on a compris le client • S'assurer que le client nous a compris communiquer par écrit • La spécification doit donc être écrite – Document lisible et compréhensible » tous les termes sont définis – Problème de maintenance des documents qui seront évolutifs • Analyser le problème pour : – mieux comprendre – poser toutes les questions nécessaires à la réalisation

25/36

La spécification – Quoi ? • Une spécification est un ensemble d'exigences – Interfaces externes – Fonctionnalités – Données – Qualité (facteurs) – Qualification • Qualité et qualification doivent être prises en compte très tôt • Il faut pouvoir valider toutes les exigences • Les exigences sont inscrites dans un document – Plan type – Si possible une exigence par phrase

26/36

La spécification – Comment ? • On utilise une méthode d'analyse • But : construire un modèle – C'est-à-dire un moyen d'obtenir les réponses aux questions posées par la réalité – On capture un aspect de cette dernière • Il faut connaître : – Les questions auxquelles on veut répondre – Le point de vue de la personne concernée – Utilisateur ≠ concepteur informatique • Le point de vue permet la modélisation

27/36

La spécification – Comment ? • La méthode c'est – Un langage – Des règles – Une démarche • Langage = éléments lexicaux + syntaxe – Sémantique + règles de bon usage – Langages textuels : français, anglais, maths, … » + précis, + pratique – Langages graphiques : SART, SADT, UML, … » + synthétique • La démarche et la méthode seront supportées par des outils

28/36

La spécification – Comment ? • Il existe des langages – Informels » syntaxe et sémantique peu définies (textuel) – Semi-formels » Syntaxe bien définie, sémantique peu définie – Formels » Syntaxe et sémantique fixées (langage machine) • La spécification utilise un langage semi-formel • Le modèle capture les 3 aspects du réel

29/36

Les sept qualités d'une bonne spécification – Conforme aux besoins réels de l'utilisateur : éviter d’interpréter les besoins du client. – Communicable : soigner le fond et la forme ; employer une méthode de description bien documentée qui sera comprise par le client. – Faisable : tout en restant dans la description du quoi, il faut penser aux concepteurs. – Modifiable : la modularité sera un gage d’évolutivité. – Validable : chaque exigence devra pouvoir être vérifiée simplement par le client. • en tant que document • par la qualification

– Cohérente : éviter les contradictions. – Complète : ne rien omettre. 30/36

Les sept péchés capitaux des spécifications – Bruit : élément du texte n'apportant d'information sur aucune des caractéristiques du problème. – Silence : caractéristique du problème à laquelle ne correspond aucun élément du texte. – Sur spécification : élément du texte correspondant à une caractéristique non pas du problème mais d'une solution possible. – Contradiction : éléments du texte définissant de façons incompatibles une même caractéristique du problème. – Ambiguïté : élément du texte permettant de comprendre une caractéristique du problème de deux façonss ou plus. – Référence en avant : élément du texte utilisant une caractéristique du problème définie plus loin dans le texte. – Vœu pieux : élément du texte décrivant une caractéristique du problème de telle façon qu'il sera impossible de valider une solution éventuelle relativement à cette caractéristique. 31/36

Conception du logiciel dans un contexte système – Tout système informatique est un assemblage d’équipements informatiques et de logiciels d’origine diverse : notion de plateforme / infrastructure • Niveau de dépendance du logiciel par rapport au matériel • Perception du niveau de risque logiciel (caractéristiques non fonctionnelles, cf. Norme ISO 9126) – Système à logiciel prépondérant

– Idéalement, il faut rendre la conception du logiciel la plus indépendante possible du matériel et des plate-formes – Très important pour le client-serveur, les IHM, les SGBD, etc.

– La caractéristique « soft » du logiciel est de pouvoir être facilement modifiée doit être préservée – C'est un vecteur de souplesse et d'adaptabilité du système

32/36

Les étapes de la conception – Notion de système englobant • Le logiciel fait nécessairement partie d'un ensemble plus vaste qui détermine tout ou partie des comportements attendus (contraintes)

– Notion de modèle • C'est une représentation abstraite rigoureuse de tout ou partie d'un système en vue d'en étudier le comportement. L'étude peut être : – Qualitative : existence de telle ou telle propriété » Le système est-il stable ? – Quantitative : on sait associer une mesure à la propriété » Quel et le temps de réponse moyen? • Quelques mots clés – Représentation abstraite : syntaxe, sémantique, pragmatique – Isomorphisme / homomorphisme : règles de correspondance qui relient le modèle à la réalité, d’où : fidélité→vérification, validation, test – Observable : ce qui relie le modèle à la réalité (observateur)

33/36

Les étapes de la conception – Intérêts des modèles • Pouvoir d’anticipation : c'est la capacité à prédire – Détection et contrôle » Contrôle aérien et spatial, météo… • Pouvoir d’accélération : le modèle va plus vite que la réalité – Calcul numérique, simulation, recherches sur critères… – Aides à la décision • Pouvoir de substitution : on remplace la réalité par un modèle – Un conducteur de train » Le modèle prend toutes les décisions à la place du conducteur – Les comptables et employés aux écritures dans les banques » Système d'information

– Tout système informatique est, par définition, un modèle

34/36

Les étapes de la conception – Ces étapes indiquent un cheminement, une progression, et non pas une séquence d’activités nettement séparées

35/36

Les étapes de la conception

36/36