Conception et développement d'applications (option SLAM)

L’essentiel

• Démarche : le besoin du client (ses mots) devient des spécifications vérifiables, puis un modèle (textes et diagrammes) validé avant de développer.
• Cycles : séquentiel (cascade, V : besoin stable), itératif et incrémental (agile : récits affinés avant chaque sprint), avec prototypage (interface décisive) ; DevOps rapproche développement et exploitation.
• Recueil : entretien, observation (contraintes cachées), atelier, questionnaire, analyse de documents et de l’existant ; repérer les contraintes juridiques (devoir de conseil).
• Formaliser : acteurs (rôles, humains ou systèmes), besoins fonctionnels, exigences non fonctionnelles mesurables (grille ISO/IEC 25010:2023), règles de gestion numérotées, glossaire.
• Récit utilisateur : « En tant que…, je veux… afin de… » ; grille INVEST ; critères d’acceptation Étant donné / Quand / Alors, dont un scénario qui échoue.
• UML 2.5.1 : langage, pas méthode. Cas d’utilisation (qui, pour quoi), classes (notions, liens), séquence (messages d’un scénario), activité (enchaînement, décisions, parallélisme).
• Architecture : client-serveur, trois couches, MVC, monolithe, services et API, microservices, mobile ; hébergement chez le client, un prestataire ou en SaaS.
• Coût : réalisation, acquisition, exploitation, maintenance, coûts internes, sortie : comparer des coûts totaux de possession.
• Interface : maquette (statique), prototype (interactif) ; critères de Bastien et Scapin ; accessibilité dès la maquette (jamais la couleur seule, contraste 4,5 pour 1, cibles de 44 × 44 pixels, étiquettes, clavier).
• Validation : par scénarios et maquettes, accord écrit, traçabilité récit → cas → règles → tests.

Les définitions clés

• Acteur : rôle joué par une personne ou un système extérieur qui interagit avec l’application.
• Règle de gestion : règle du métier du client (calcul, condition, contrainte), écrite en une phrase et numérotée.
• Cas d’utilisation : utilisation qui apporte un résultat observable et utile à un acteur ; verbe à l’infinitif + complément.
• Multiplicité : nombre d’objets d’une classe liés à un objet de l’autre classe.
• Rétro-conception : reconstruction du modèle d’une application à partir de sa base, de son code, de ses écrans.

Code et méthodes

Notation des classes : attribut nom : Type [multiplicité] (dateMes : Date [0..1]) ; multiplicités 1, 0..1, 0..*, 1..*. Composition : losange plein côté du tout ; agrégation : losange creux ; généralisation : triangle creux côté classe générale ; classe abstraite en italique.

Cas d’utilisation : «include» (pointillés, du cas de base vers le cas inclus, toujours exécuté) ; «extend» (du cas qui étend vers le cas étendu, sous condition, au point d’extension).

Séquence : synchrone = pointe pleine ; asynchrone = pointe ouverte ; réponse = pointillés ; fragments opt, alt, loop avec garde [condition] ; tout message reçu est une opération de la classe.

Trouver une multiplicité : depuis un objet d’en face, minimum et maximum (pour un plan : 1 équipement → 1 côté Equipement) → l’autre sens (0..* côté PlanPreventif) → vérifier sur un cas réel.

Rétro-conception : table → classe ; clé étrangère → association (NOT NULL → 1, facultative → 0..1) ; CHECK → règle de gestion ; catalogue information_schema.KEY_COLUMN_USAGE.

Test utilisateur : 3 à 5 vrais utilisateurs → tâches sans mode d’emploi → observer sans aider → taux de réussite, temps, erreurs → corriger par gravité (5 + 3 + 4 réussites sur 15 = 80 %).

Chiffrer : charge en jours-homme × prix de journée ; 12 400 € + 10 % d’aléas = 13 640 € HT, + 1 120 € de coûts internes = 14 760 €.

Les 3 pièges à éviter

1. Écrire la solution au lieu du besoin, ou laisser une exigence non mesurable (« rapide »).
2. Inverser «include» et «extend», ou placer la multiplicité du mauvais côté, ou mettre une clé étrangère dans une classe d’analyse.
3. Faire valider des diagrammes par un client qui ne les lit pas, au lieu de scénarios et de maquettes.