Introduction

Le problème de l'analyse

Partir des besoins client exprimés en langue naturelle et concevoir un composant logiciel qui permet d'y répondre. Dans la vraie vie, les besoins arrivent par des entretiens avec le client et les utilisateurs, des documents décrivant l'existant, des réglementations. Dans ce cours : un résumé écrit des besoins et le sujet de SAé.

La difficulté fondamentale : la langue naturelle est ambiguë. Comment s'y prendre ? En discutant — écouter, proposer, recommencer — et en s'appuyant sur l'expérience et une méthodologie.

L'analogie de la maison

La cliente dit : « Je voudrais un logement de 90 m² à 2 niveaux. En bas : entrée, salon-cuisine, salle de bains. En haut : 4 chambres. »

• Étape 1 : l'architecte dessine un plan simple — base de discussion, suggestions — qui précise et explicite le besoin.
• Étape 2 : le plan d'architecte détaillé et contractuel, les plans techniques à l'attention des entreprises — qui décrivent précisément ce qui sera fait.

L'analyse suit exactement ce mouvement : du besoin flou vers des documents explicites, d'abord pour discuter, puis pour construire.

Les outils méthodologiques

1. Comprendre, préciser et expliciter les besoins : diagramme de cas d'utilisation, prototype d'interface.
2. Décrire une solution : diagramme de classes, scénarios d'interaction.

Organisation et évaluation

• Module de 3 semaines : par semaine 1 h de cours d'amphi, 1 h 30 de TD, 2 h de TP.
• Aucune note ni diapo fournies : il faut prendre des notes en amphi (ou s'approprier les notions par soi-même — le cours de conception orientée objet de Pierre Gérard, DUT 2013, couvre la plupart des sujets).
• Évaluation : DS de 1 h 30 sur 18,5 pts (seules les notes manuscrites de cours et de TD autorisées), TD/TP rendus en fin de séance (1,5 pt), et le dossier d'analyse de la SAé 3.02 (5 h d'accompagnement).
• Poids : UE 3.1 = 12/60, UE 3.2 = 5/60, UE 3.5 = 10/60 — soit 27/360 au total, plus que Dév efficace et presque autant que R3.04.