Qualités d’un bon logiciel

1. Validité : Remplit toutes les fonctions (Conforme au CDC)

2. Fiabilité : Gestion des conditions anormales (Exceptions)
3. Facilité d’utilisation : Utilisable par des non-informaticiens
4. Efficacité : Utilisation d’un minimum de ressource et un minimum de temps
5. Maintenabilité : Facilité de maintenance
6. Portabilité : Transférable d’un environnement à un autre facilement.
a. Portabilité logicielle : Windows/Linux
b. Portabilité matérielle : Intel / Mac OS
7. Réutilisabilité : Capacité à être utiles dans diverses applications

Cycle de vie

Le développement d’un logiciel est un processus.

 Processus : Ens. D’activités coordonnées, réglées, ordonnées, dont le but est de créer
un produit.
 Processus de développement : L’ordre et la manière d’enchaîner les étapes d’un
développement.

Activité

Les activités d’un processus sont décrites en terme de :

1. Entrées d’activité (Matière première)

2. Sorties de l’activité (Résultats)
3. Intervenants et rôles (Qui ?)
4. Description de l’activité (Quoi - quel est le problème à traiter ?)
5. Standards à appliquer (Comment ?)

Activités courantes

1. Spécifier :
a. Définir ce que doit faire le logiciel
b. S’assurer qu’il le fait
c. S’assurer qu’on développe le bon logiciel
i. Valider : Fait-on le bon logiciel ? Fait-il ce qu’il faut ?
2. Concevoir :
a. Organiser le logiciel
b. Les choix techniques
c. S’assurer de l’architecture du logiciel
i. Intégrer : Le logiciel est-il construit de sorte à faire ce qu’il doit faire ?
3. Coder :
a. Traduire cette organisation en code source
i. Tester unitairement : Le code source est-il bien écrit ?

1
 Faisabilité (Pourquoi ?)

1. Etudier la faisabilité du projet, ses contraintes techniques et les alternatives

2. Entrées : Problèmes à résoudre, objectifs à atteindre
3. Sorties : Oui/Non (Réaliser ou pas le projet)

Spécification (Quoi ?)

1. Décrire ce que doit faire le logiciel et comment vérifier qu’il fait bien ce qui est exigé
2. Entrées : Idées,exigences et besoins du client
3. Sorties : CDC
4. Bonnes pratiques : Communication, clarté, accords explicites, estimations exactes
5. Difficultés : Besoins du client changeants, les erreurs sont plus fréquentes à ce stade et
plus difficiles et coûteuses à corriger.

CDC

1. Bon niveau de généralité

2. Clair et adéquatement formulé
3. Complet
4. Cohérent
5. Vérifiable
6. Modifiable

Conception (Comment ?)

1. Organiser le logiciel afin qu’il satisfasse les exigences de la spécification, faire des
choix techniques
2. Entrées : Une spécification
3. Sorties : Une description des décisions de conception, des procédures de tests pour
vérifier

Conception architecturale

1. Décomposer le système en modules

2. Définir les interfaces et les liens entre les modules

Conception détaillée

1. Détailler le fonctionnement des composants

2. Définir des algos et la représentation de données
3. Des tests unitaires pour vérifier la conformité des composants

2
 Qualité d’une conception

La maintenabilité : Maximiser la cohésion, minimiser le couplage

Les dégradation de la conception

3
 Cycle de vie en cascade

Faisabilité et CDC
Spécification
Conception architecturale
Conception détaillée
Programmation
Intégration
Installation
Exploitation et maintenance

Propriétés

1. Il est linéaire sans aucune évaluation entre le début du projet et la validation

2. Le projet y est découpé en phases successives dans le temps
3. Chaque phase est une activité produisant des livrables
4. Chaque phase ne peut remettre en cause que sa précédente

Inconvénients

1. Les vrais projets suivent rarement un développement séquentiel

2. Etablir tous les besoins au début d’un projet est difficile
3. Aucune validation intermédiaire : Obligation de remettre en question les phases
précédentes, ce qui s’avère coûteux
4. Sensibilité à l’arrivée de nouveaux besoins : Refaire toutes les étapes

4
 Cycle en V

Faisabilité et CDC Installation & test

système

Spécification Test d’acceptation

Conception Intégration & test

architecturale d’intégration

Conception Test unitaire

détaillée

Programmation

Propriétés

1. C’est le cycle le plus utilisé jusqu’à présent, il est orienté test

2. A chaque activité créative correspond une activité de vérification
3. Chaque phase prépare la phase correspondante de vérification

Avantages

1. La préparation des dernières phases par les premières

2. Permet d’éviter d’énoncer une propriété qu’il est impossible de vérifier objectivement
après la réalisation

Inconvénients

Le logiciel est-il le bon ? Puisqu’il n’est utilisé que plus tard, donc il n’y a pas de moyen
d’impliquer le client et/ou les utilisateurs avant la dernière phase

5
 Prototypage

1. Construit et utilisé en phase d’analyse (spécification)

a. Interagir avec les utilisateurs, montrer aux clients les fonctions
b. Identifier les besoins
c. Vérifier les choix spécifiques d’IHM( ?)
2. Construit et utilisé en phase de conception
a. S’assurer de la faisabilité des parties critiques
b. Valider des options de conception
c. Vérifier l’efficacité réelle d’un algorithme

Prototypage jetable

Le squelette du logiciel n’est créé que dans un but et dans une phase particulière du
développement

Prototypage évolutif

1. Première version du prototype = Embryon du produit final

2. On itère jusqu’au produit final

Avantage

Les efforts consacrés au développement d’un prototype sont le plus souvent compensés par
ceux gagnés à ne pas développer des fonctions inutiles. ie : Quand on développe un prototype,
on ne perd pas son temps à développer n’importe quoi.

Inconvénients

1. Les décisions rapides sont rarement de bonnes décisions

2. Le prototype évolutif ne donne pas parfois le produit demandé

6
 Cycle de vie en spirale

Déroulement

1. Chaque cycle se déroule en quatre phases

2. Détermination : A partir des résultats des cycles précédents, ou de l’analyse des
besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes
3. Analyse des risques, évaluation des alternatives, éventuellement maquettage
4. Développement et vérification de la solution retenue. On peut utiliser ici un modèle
classique
5. Revenue des résultats et vérification du cycle suivant

Analyse des risques

1. Risques technologies :
a. Exigences démesurées par rapport à la technologie
b. Incompréhension des fondements de la technologie
c. Changement de technologie en cours de route
2. Risques liés au processus :
a. Gestion du projet mauvaise/absente
b. Calendrier et budget irréalistes
c. Calendrier abandonné sous la pression des clients
d. Développement de fonctions inappropriées
e. Risques humains
f. Défaillance du personnel
g. Surestimation des compétences
h. Travailleur solitaire

7
 i. Manque de motivation

Cycle itératif et incrémental

1. Segmentation du travail
2. Concentration sur les besoins et les risques
3. Les itérations sont des prototypes :
a. Expérimentation et validation des technologies
b. Planification et évaluation
4. Les prototypes « s’enroulent » autour du noyau de l’architecture

Principes

1. Développer de petits incréments fonctionnels livrés en courtes itérations

2. Un incrément fonctionnel est un besoin du client
3. Pour chaque version à développer après la première version livrée, il faut arbitrer
entre :
a. Les demandes de correction
b. Les demandes de modifications
c. Les nouvelles fonctionnalités à développer

8
 Quand est-ce qu’on réalise les itérations ?

1. Piloter le développement par les priorités :

a. Commencer par développer les fonctionnalités les plus importantes pour le
client et les plus risquées
2. Piloter le développement par les tests d’acceptation :
a. Ecrire des tests automatisés d’acceptation
b. Utiliser ces tests pour mesurer l’avancement du développement
c. L’avancement se mesure par les fonctionnalités s’exécutant conformément aux
besoins du client
d. Une fonctionnalité s’exécute conformément au besoin si elle réussit le test
d’acceptation
3. Pilotage par risques :

Avantages

1. Le cycle itératif est en phase avec la réalité

2. Permet la prise en compte de l’évolution
3. Demande un pilotage continu
4. Bien adapté à l’approche objet (et inversement)
5. Les choix techniques (spécification, conception, codage) sont validés très tôt par test
a. L’enchaînement des itérations permet de régulièrement vérifier que l’on
construit bien le logiciel
6. Le logiciel est utilisé très tôt
a. L’enchaînement des itérations permet aux utilisateurs de vérifier régulièrement
que l’on construit le bon logiciel (contrairement au cycle en V)

9
 Principaux risques récurrents

1. Intégration trop complexe

2. Environnement non adapté
3. Utilisateurs défavorables
4. Technologie complexe
5. Lourdeur des activités manuelles
6. Composants réutilisables inadaptés

Comparaison du cycle en cascade et l’itératif

10