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 plate-
forme / 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