CYCLE DU DÉVELOPPEMENT DU LOGICIEL
Le développement d'un programme se résume souvent pour beaucoup de personnes à une phase de codage. Cette étape
représente
pourtant qu'une petite partie du cycle de vie d'un logiciel. Un programme ne pourrait bien sûr pas exister sans
son écriture. Il est tout à fait possible de réaliser un logiciel sans utiliser d'autres étapes, mais des problèmes peuvent
rapidement survenir si nous devons y apporter des modifications, ajouter des fonctionnalités...
Dès les années 70, le développement de logiciels connaissait des
problèmes. Il n'y avait pas de méthodologie et de
norme ce qui donna bien souvent des systèmes de qualité douteuse.
Les
systèmes d'aujourd'hui sont encore plus complexes qu'à
cette époque, imaginer alors les problèmes pouvant être rencontrés de
nos jours. Le génie logiciel tente à l'aide de processus, analyse,
méthode et
norme de corriger ce problème. Les dépassements de budget et de temps
sont monnaie courante dans le développement
d'application. Nous allons voir les principes de base du génie logiciel
qui tente de corriger ces problèmes.
Le but du développement de logiciel est de produire un logiciel de qualité. De nombreux critères existent afin de
définir la qualité d'un logiciel.
Exactitude
C'est l'obtention des résultats escomptés. Si un logiciel doit effectuer des calculs sur des matrices,
on s'attend à ce qu'il le fasse. Obtenir tout autre résultat ne nous intéresse pas et ne répond pas à nos besoins.
Portabilité
C'est la facilité à porter un logiciel sur un autre système d'exploitation. Par exemple, on pourrait citer Mozilla
et Apache qui ont cette qualité, car ils existent pour divers systèmes.
Extensibilité
C'est la facilité qu'un logiciel peut être adapté pour de nouveaux besoins. Un système mal conçu pourrait faire
en sorte que tout le système doit être refait afin d'ajouter quelques fonctionnalités que les utilisateurs désirent. Un
système ne serait alors pas extensible.
Réutilisabilité
C'est la capacité à utiliser certaine partie du logiciel pour créer d'autre logiciel. Une telle approche permet
de diminuer les coûts et risques lors de la construction d'un système.
Vérifiabilité
C'est la facilité à créer des tests pour un logiciel.
Intégrité
C'est l'aptitude d'un logiciel à se protéger contre les accès interdits au niveau du code et des données
Robustesse
C'est la capacité du logiciel à bien répondre lorsque ses conditions d'utilisation sont anormales. Un logiciel
pourrait être conçu pour qu'environ 100 utilisateurs puissent l'utiliser simultanément. Des tests avec 1000 utilisateurs
pourraient être faits afin de savoir si le logiciel est encore capable de répondre convenablement aux usagers.
D'autres qualités peuvent exister pour un système. Un logiciel ne peut combler toutes ces qualités.
Cycle du développement du logiciel
Le développement de logiciel, peut se résumer en 7 étapes :
- Déterminer les besoins
- Conception préliminaires
- Conception détaillée
- Implémentation
- Intégration
- Test
- Maintenance
Ces étapes peuvent bien sûr varier d'une entreprise à l'autre. Elles constituent néanmoins le squelette
du cycle logiciel. Il est tout à fait possible de retrouver plus ou moins d'étapes dans une entreprise donnée.
Il y a plusieurs variantes.
Déterminer les besoins
La communication est primordiale afin d'arriver au résultat escompté par le client.
Le client doit bien être identifié. Le client n'est pas nécessairement un connaisseur en informatique, c'est
pourquoi que la communication est bien importante. Les deux parties doivent bien s'attendre sur ce qui doit être
réalisé.
Cette section doit spécifier les fonctions nécessaires pour répondre aux besoins du client. Les besoins existants doivent
être traduits en besoin logiciel.
Les connaissances informatiques qu'ont les utilisateurs.
Les performances requises.
Les contraintes de réalisation.
Le nombre de fois que l'usager doit utiliser le système.
Les caractéristiques clés, obligatoires.
Plusieurs moyens sont disponibles pour obtenir ces informations. Il est possible d'effectuer un entretien avec
les clients, les utilisateurs. L'utilisation d'un questionnaire ainsi que l'observation du client dans ses tâches, peuvent
aussi contribuer à répondre à ces questions.
Les besoins du client au niveau des interfaces, performances contraintes, qualités...
doivent être traduit. Les deux parties doivent bien s'attendre afin que la suite
puisse fonctionner.
Conception préliminaire
Cette section décrit de façon globale le produit. Les résultats de l'étape précédente sont utilisés
afin de produire ce que le système doit faire. Cette section doit permettre de savoir
si le projet est faisable au niveau informatique, l'estimation de travail à faire. On doit pouvoir savoir
comment réaliser le logiciel à la fin de cette section.
La solution doit être décomposée en une architecture modulaire.
Tous les besoins doivent être définis et décomposé en fonction.C'est
l'étape du «quoi».
Conception détaillée
La description du logiciel est faite. Maintenant, on doit spécifier davantage les
détails du système afin d'arriver à une description très proche du programme. C'est
l'étape du «comment». Les modules de la section précédente doivent être décrits minutieusement.
Les fonctions doivent être décomposées en élément plus petit.
Les données et algorithme doivent être décrits pour chaque élément.
Les données d'entrée et de sortie doivent être précisées.
Un plan de test doit être fait pour chaque module.
Une bonne estimation du temps et du nombre de personnes nécessaires
peut-être fait à la suite de cette section.
Implémentation
Les modules de la section précédente doivent être codés, réalisés dans un langage de programmation.
C'est souvent cette étape que les gens s'attardent le plus. Les autres étant souvent très négligés, pour ne pas dire
oublié. Des tests des modules séparés sont effectués. (test unitaire).
Intégration
Cette étape vérifie si que l'architecture spécifiée dans la conception préliminaire
est bien respectée. On rassemble les modules entre eux et on fait des tests
Progressivement en vérifiant les résultats obtenus à ceux attendus. Un travail
de modification doit être fait si les résultats ne concordent pas avec ceux escomptés.
Test
Cette étape permet de savoir si on a bien écrit le système que le client désirait,
de savoir si on a répondu à ces besoins. Des tests de validation doivent être faits afin de vérifier si le logiciel est conforme
aux spécifications déjà établies du logiciel. Le système doit être testé par d'autres personnes que
ceux qui l'ont conçu et sur d'autres machines. Le système est installé chez le client.
La formation est donnée. Cette formation peut être faite à l'aide de documentation,vidéo ou cours.
Maintenance
Des anomalies peuvent être trouvées et une ou des personnes sont en
charge de modifier les modules, documentations... afin de résoudre ces problèmes.
Des nouvelles fonctionnalités peuvent être ajoutées. Des tests peuvent être refaits afin
de s'assurer que les corrections n'apportent pas d'autre problème sur le système.
Chaque étape à un temps approximatif. Très souvent la majorité du temps est passé
à l'implémentation. Même si aucun problème n'était trouvé, rien ne garantit, que
le système est bien, celui que le client désirait.
- Déterminer les besoins environ 15%
- Conception préliminaire environ 10%
- Conception détaillée environ 15%
- Implémentation environ 20%
- Intégration environ 10%
- Test environ 30%
Les temps présentés ici peuvent varier, mais ils devraient être près de ces valeurs. Si l'implémentation
dure 80% de la durée du projet, il y a un problème. Les autres étapes vont en subir les conséquences et le projet
risque d'avoir quelques difficultés.
Selon des études (Standish Group par exemple), seulement 30 % des projets informatiques des entreprises connaissent la réussite.
C'est très peu. Environ 15 % d'entre eux sont purement et simplement des échecs et 50 % ne répondent pas aux contraintes
qui leur avaient été imposées, d'où la nécessité de bien s'attendre avec le client sur ce qui doit être fait.
Le cycle présenté ici ne garantit pas que le projet soit une réussite, mais il diminue les risques d'avoir un échec.
Une étape ne doit pas être nécessairement être terminé pour en entamer une autre. Le modèle présenté ici est général.
Nous allons voir plus en détail des modèles de développement qui existe.
