• 20 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

Ce cours est diplômant et vous permet d'obtenir des crédits universitaires européens (ECTS).

J'ai tout compris !

Mis à jour le 24/04/2019

Quelle démarche suivre ?

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Je vous rappelle qu’UML ne préconise aucune démarche spécifique. Si vous voulez commencer votre phase d’analyse en réalisant un diagramme de classes, libre à vous.

Toutefois, je suis d’avis qu’il y ait un minimum d’analyse du besoin à faire avant de se ruer sur le diagramme de classes. Rappelez-vous, l’analyse du besoin est la partie centrale des 4+1 vues. Je vais donc ici vous présenter les principales étapes de développement et quelques démarches.

Les étapes de développement logiciel

Le processus de développement logiciel contient un certain nombre d’étapes :

  1. Définir les besoins et les exigences du client et des utilisateurs

  2. Analyser le système 

  3. Concevoir le système 

  4. Programmer le logiciel

  5. Tester le logiciel

  6. Déployer 

  7. Maintenir le système

Les étapes d'un projet
Les étapes d'un projet

 

 

ÉTAPES

DESCRIPTIF

Définition des besoins et des exigences

La définition des besoins et des exigences correspond à l’étape dans laquelle nous discutions avec le client et les futurs utilisateurs afin de comprendre de quoi ils ont besoin : QUI doit pouvoir faire QUOI ?

Lors de cette étape, nous définissions également les demandes précises, telles que le respect de certaines normes graphiques, les temps de réponse, le matériel sur lesquels le logiciel devrait fonctionner, etc.

Analyse du système

L’analyse du système permet d’affiner ce qui a été défini dans l’étape précédente. On y détaille davantage le fonctionnement interne du futur logiciel (COMMENT cela doit-il fonctionner ?).

Conception du système

La conception du système correspond à la définition de choix techniques.

La programmation

La programmation est l’étape dans laquelle les informaticiens se donnent à cœur joie ! Ils réalisent le logiciel à l’aide de langages de programmation, de systèmes de gestion de bases de données, etc.

Les tests

Durant les tests, les informaticiens vérifient que le logiciel fonctionne et répond aux besoins définis en début du projet. Cette phase de tests peut intégrer des validations du logiciel avec le client et/ou les utilisateurs. C’est même plus que souhaité.

Le déploiement

Lors du déploiement, les informaticiens installent le logiciel sur le matériel et réalisent des ajustements pour faire fonctionner le logiciel dans l’environnement de travail des utilisateurs.

La maintenance du système

La maintenance correspond à la période qui suit l’installation et pendant laquelle les anomalies et problèmes doivent être corrigés.

Ces étapes ne sont pas forcément utilisées de façon linéaire. On parle souvent de cycles de vie, qui ont pour but d’organiser ces étapes de différentes manières en fonction d’un certain nombre de critères relatifs au projet de développement. Ci-dessous, quelques exemples de cycle de vie.

  • La cascade

  • Le modèle en V

  • Le modèle en W

  • La spirale

  • Le RAD

  • Etc.

Voyons ensemble deux exemples afin d'illustrer cela. 

Le Cycle de vie en cascade

Exemple d’utilisation :

Le cycle de vie en cascade peut être utilisé lorsqu’un projet est relativement simple, c’est-à-dire pour lequel nous avons la quasi-certitude que les besoins ou exigences n’évolueront pas en cours de projet. En pratique, une étape ne démarre que si la précédente ait été validée par le client et/ou les utilisateurs.

Le cycle de vie en cascade
Le cycle de vie en cascade

Les étapes :

Vous constatez probablement que les termes utilisés dans le schéma sont légèrement différents des 7 étapes indiquées précédemment. Chaque cycle utilise sa propre terminologie, mais nous pouvons voir des correspondances :

ÉTAPES

ÉTAPES DU CYCLE DE VIE EN CASCADE

Étape n°1 :
Étude de faisabilité

Cette étape permet de décider de la nécessité et de l’opportunité de lancer le projet.

Étape n°2 :
Analyse des besoins

Cette étape permet de définir les besoins et les exigences des utilisateurs. Cela renvoie à l’étape n°1 énoncé ci-dessus : La définition des besoins et des exigences.

Étape n°3 : Conception générale

La conception générale renvoie à l’étape Analyse du système.

Étape n°4 : Conception détaillée

Cette étape est équivalente à l’étape Conception du système.

Étape n°5 : Réalisation

Cette étape équivaut à l’étape La programmation.

Étape n°6 : Intégration

Cette étape équivaut à une partie de l’étape La programmation.
Notez que l’étape Tests n’est pas vu ici comme une étape, mais comme des validations. Les tests unitaires permettent de tester chaque fonctionnalité du logiciel séparément, alors que les tests d’intégration sont destinés à tester le logiciel dans sa totalité. Ces tests peuvent être faits avec le client et les utilisateurs.

Étape n°7 :
Le déploiement

Cette étape est identique.

Notez que ce cycle ne mets pas en avant l’étape de Maintenance.

 

Le cycle de vie en V

Exemple d’utilisation :
Un projet plus important dont les besoins et les exigences risquent d’évoluer pourrait avoir un cycle en V. Comme illustré dans la figure suivante, le système à développer serait décomposé en modules. Chaque module serait conçu, développé et testé séparément. Les différents modules pourraient alors être intégrés dans le système global au fur et à mesure. Des tests d’intégration permettraient alors de garantir que l’ensemble fonctionne de façon à répondre à la conception générale du système. Les tests d’acceptation permettent ensuite de vérifier la cohérence du système avec les besoins.

Le cycle en V
Le cycle de vie en V

 

Les étapes :

ÉTAPES

ÉTAPES DU CYCLE DE VIE EN V

Étape 1 :

Analyse des besoins

Cette étape est identique à l’étape n°1 : Définition des besoins et des exigences.

Étape 2 :

Conception système

Cette étape couvre une partie de l’étape : l’analyse du système et de l’étape : la conception du système. Il s’agit d’une vision globale du logiciel à développer.

Le système est divisé en composants pour lesquels on réalisera :

Étape n°3 :

Conception composant

  • La conception du composant, c’est-à-dire l’analyse et la conception détaillée du composant

Étape n°4 :

Réalisation composant

  • La réalisation ou la programmation du composant

Étape n°5 :

Test composant

  • Les tests du composant. Cela correspond donc aux étapes la programmation et les tests.

Étape n°6 :

Tests d’intégration

Les différents composants sont alors intégrés dans un logiciel. Le cycle en V ne mentionne pas d’étape de déploiement mais on pourrait aisément le voir ici.

Étape n°7 :

Test d’exploitation

Les tests d’acceptation correspondent à la validation du logiciel par le client et les utilisateurs.

Ce cycle ne met pas en évidence l’étape de Maintenance.

Loin de moi l’idée de vous faire un cours sur les cycles de vie. Je voulais juste attirer votre attention sur le fait que les étapes d’analyse et de conception ne sont pas forcément à réaliser comme deux gros blocs qui se suivent. Nous allons toutefois les traiter de cette façon dans la suite des chapitres afin de rendre clairement visible la différence entre ces deux étapes.

Quel diagramme pour quelle étape ?

Comme je vous le disais plus haut, la définition d’un logiciel peut être grossièrement divisée en deux :

  • l’étape de l’analyse (analyse des besoins, du domaine, applicative) ;

  • la conception de la solution.

Dans chacune de ces deux parties, nous utilisons un certain nombre de diagrammes UML.

ETAPE : ANALYSE

QUAND ?
Pour définir les besoins (contexte et système)

QUEL DIAGRAMME?

POURQUOI?

Diagramme de contexte

Pour identifier les acteurs qui utiliseront le système

Diagramme de cas d’utilisation

Pour indiquer de quelles façons les acteurs utiliseront le système

QUAND ?
Analyse de domaine

QUEL DIAGRAMME?

POURQUOI?

Diagramme de cas d’utilisation

Pour détailler les fonctionnalités en y ajoutant des liens entre cas d’utilisation

Diagramme d’activité

Afin de décrire le déroulement des cas d’utilisation

Diagramme de classes

Pour préciser les informations nécessaires pour les actions d’un cas d’utilisation

QUAND ?
Analyse applicative (ou analyse de la solution)

QUEL DIAGRAMME?

POURQUOI?

Diagramme de séquences

Afin de détailler le déroulement d’un cas d’utilisation tout en indiquant les informations à utiliser

Diagramme d’état-transition

Afin d’identifier tous les états par lequel un objet peut passer et donc
de trouver les actions qui permettent d’obtenir un changement d’état

Diagramme de collaboration (de communication)

Pour identifier les messages échangés entre objets et trouver de nouvelles actions.

ETAPE : CONCEPTION

QUAND ?
Conception de la solution

QUEL DIAGRAMME?

POURQUOI?

Tous les diagrammes précédents

Afin de vérifier la cohérence des diagrammes et d’apporter des détails nécessaires à l’implémentation de la solution.

Diagramme de composants

Pour indiquer de quelle façon le logiciel sera construit. Un composant
pouvant être un exécutable, un fichier, un module, une base de données,
etc.

Diagramme de déploiement

Afin de montrer sur quel matériel chacun des composants devra être installé et pour indiquer les éventuels moyens de communication entre les parties.

Les prochaines parties du cours vous apprendront comment réaliser des diagrammes UML dans la phase d’analyse des besoins et du domaine (hors diagramme de classes).

Le diagramme de classes et les diagrammes utiles dans la phase d’analyse de la solution ne seront pas traités dans ce cours. 

Le principe d’itération en UML  

Pour rappel, l’itération signifie que l’on fera plusieurs allers-retours sur les diagrammes avant d’avoir un dossier d’analyse entièrement satisfaisant.

Il est utopique de penser que nous pourrons comprendre un besoin exprimé totalement dès le début du projet.

Oui, il nous arrive parfois d’être très optimistes et de penser avoir tout bon du premier coup. Malheureusement, la réalité nous rattrape toujours… souvent un peu trop tard !

Comprendre ce que veut un client ou un utilisateur n’est pas toujours évident. Les termes utilisés peuvent avoir des sens cachés que nous ne saisissons pas tout de suite. Un besoin peut évoluer en fonction de l’analyse que nous présentons. Notre vision du système peut évoluer en fonction des détails mis en évidence par certains diagrammes.

Toutes ces raisons font que nous devons revenir sur nos diagrammes un certain nombre de fois.

Je préconise de revenir systématiquement sur l’ensemble des diagrammes lorsque vous modifiez quelque chose dans un diagramme précis. De cette façon, vous allez adoptez la démarche par itérations, de façon assez « naturelle ».

N’est-ce pas ce que l’on a vu précédemment ?

Prenons l’exemple de la réalisation du diagramme de classes.

Lors de la phase d’analyse du besoin, on fait généralement une première version de diagramme de classes après avoir décrit les interactions entre les acteurs et le système (dans les descriptions des cas d’utilisation). Puis, après la description du déroulement des cas d’utilisation, à l’aide de diagrammes de séquence, le diagramme de classes devra être complété avec des éléments complémentaires. Il en va de même après la réalisation d’un diagramme d’état-transition ou d’un diagramme de collaboration. Chacun des diagrammes réalisés pourrait mettre en évidence des éléments à ajouter ou à modifier.

Dans une démarche de modélisation d’un projet informatique avec UML, les points clés sont :

  • une démarche guidée par les besoins utilisateurs ;

  • une démarche itérative et incrémentale ;

  • une démarche centrée sur l’architecture logicielle ;

  • une mise en évidence des liens qui existent entre les actions et les informations.

En résumé

  • UML ne préconise aucune démarche. 

  • La définition d’un logiciel peut être scindée en deux étapes majeures : l’analyse (analyse des besoins, du domaine et de la solution applicative) et la conception.

  • L’étape d’analyse comprend 6 diagrammes : diagramme de contexte, diagramme de cas d’utilisation, diagramme de classe, diagramme de séquence, le diagramme d’état-transition et le diagramme de collaboration. 

  • L’étape de conception apporte des précisions aux diagrammes réalisés lors de l’analyse et comprend 2 diagrammes supplémentaires : le diagramme de composants et le diagramme de déploiement.

  • Une démarche itérative permet de garantir que l’analyse soit cohérente et complète.

 

Cette partie est maintenant terminée. N'oubliez pas de faire vos exercices avant de passer à la partie suivante. ‌À vous de jouer!

Exemple de certificat de réussite
Exemple de certificat de réussite