vendredi 16 septembre 2005

Cycle du développement du logiciel


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.