Démarche pour spécifier et concevoir un logiciel ou une solution informatique (extrait de cours)

1. Elaborer un logiciel,
une solution informatique
Extraits des supports de cours de J.P. Carmona
Le contenu de ce document est mis à disposition selon les termes de la Licence Creative Commons
Attribution - Partage dans les Mêmes Conditions 3.0 France.
1

2. Elaborer une solution
informatique
• analyser QUOI faire :
– clarifier la connaissance métier ;
– définir périmètre ;
– rédiger la spécification de la solution
• analyser COMMENT faire :
– faire la conception de la solution ;
– élaborer les architectures,
– décomposer pour réduire la complexité du travail à faire ;
– modèles, diagrammes ;
• intérêt :
– évaluer la charge de travail (coût, délai)
– bien réaliser le bon logiciel
2

3. Chemin du
Quoi et du Comment
client fournisseur client fournisseur client fournisseur
Marketing ou MOA MOE ou Sous-traitants
Direction générale Direction métier Direction ou expert technique
informatique
Quoi Comment
faire Faire
Quoi Comment
faire Faire
Quoi Comment
faire Faire
3

4. Spécification
• Etudier QUOI faire : build the right system
• Déterminer les éléments intervenant dans le logiciel
• L’analyse décrit un logiciel selon 3 axes :
Axe fonctionnel : liste des fonctionnalités
Axe statique : structure des données gérées
Axe dynamique : traitements sur les données gérées
4

5. Comment faire un logiciel
Etudier COMMENT faire : build the system right
Apporter une solution technique au QUOI faire
Détailler la solution en terme de
données
traitements
architecture
Prise en compte des problématiques techniques
Choisir une stratégie de réalisation
5

6. Du cahier des charges
Cahier des
à la solution informatique
charges
Analyse du
cahier des charges a
a b
b c
c Spécification Conception d
e
d
e générale générale f
f h
h i
i
Itération ou lot
v3
v1 a
b
Logiciel(s) Conception détaillée c
Campagne de
et Réalisation #1 d
et documentation Conception détaillée e
test f
et Réalisation h
i

7. Démarche projet 2TUP
Définition des
besoins
Spec. fonctionnelles
Branche Technique
Quoi faire générales Conception Comment faire
Diagrammes de générale
Diagrammes de
Spec. fonctionnelles
• Cas d'Utilisation détaillées • Composant
Architectures
• Séquence niveau 1 • Classes technique
• MCD • Choix technologique
Maquettage Atelier logiciel
(framework, langage, outils)
• Séquence niveau n
Conception
Réalisation itérative
détaillée
Développement
Intégration
Validation
Recette
Mise en
production
Exploitation
7/15

8. Premiers pas pour
débuter l’analyse
1. Limiter et clarifier le périmètre du logiciel à développer
o Ce qui ne sera pas fait (limites, fonctionnalités manuelles, fonctions
assurées par d'autres logiciels)
o Clarifier les termes métier dans un lexique
o Structurer l'expression de besoin en exigences
2. Identifier les utilisateurs et ce qu’ils pourront faire
o Les fonctions disponibles par utilisateurs seront les cas d'utilisation
o Le détail des cas d'utilisation donnera les traitements
3. Analyser les données
o Identifier les flux de données (entrés / sorties du logiciel)
o Identifier les données dont le logiciel doit traiter
pour assurer les fonctions
8

9. Lexique
Intérêts du lexique :
• Clarifier les termes utilisés pour la documentation de la solution
• Eliminer les redondances, synonymes, polysémies
• Définir les termes et concepts métier clés à la MOE
• Présenter et expliquer les termes et concepts informatique clés à
la MOA
jargon jargon
métier Lexique informatique
• Les termes largement utilisés dans chaque jargon sont candidats
à entrer dans le lexique
• Quelques catégories de terme : métier, informatique, entreprise
9

10. Exigences
• Définir les exigences à partir de l'expression de besoins
dans le cahier des charges
• Identifier chaque exigence avec un numéro unique.
• Exemple :
o Format “<categorie>_<numero>”
o Exemple de catégories:
• IHM Interface Homme Machine; FON Fonctionel
• PER Performance; DES Design; CU Cas d’Utilisation
• IMP Implementation; LIV Livraison; ORG Organisation projet
• Les exigences doivent être :
o Mesurable : il doit y avoir un moyen de vérifier l'exigence
o Utile : ne porter que sur les éléments nécessaires au système
o Simple : une seul exigence à la fois
o Traçable : numéroter chaque exigence, historiser les modifications
o Non ambiguës : susceptible de n'avoir qu'une seule interprétation
o Cohérente : ne pas contredire un autre exigence, utiliser le même
vocabulaire
o Réalisable : réaliste quant aux moyens mis en oeuvre pour le projet

11. les diagrammes de
Cas d’Utilisation (UML)
• Un cas d'utilisation présente les acteurs de la solution
o Humain : utilisateur final (client), administrateur (employé)
o Logiciel : applications externes à la solution
• Un cas d'utilisation présente les fonctions utilisées par acteur
o 1 fonction pour un 1 acteur = 1 cas d'utilisation
• La liste des cas d'utilisation limite le périmètre du logiciel à créer
• Chaque cas d'utilisation possède un ou plusieurs scénarios
o le scénario nominal ;
o éventuellement des scénarios particuliers
11
o éventuellement des scénarios d'erreurs complexe

12. Diagramme de cas
d’utilisation
12

13. Règles sur les
cas d'utilisation
• Chaque cas d'utilisation doit avoir
o un nom avec au moins un verbe et un complément
• un scénario nominal
• Granularité d'un cas d'utilisation
• un seul acteur qui initie l'action
• un seul but pour l'acteur
• pas d'interruption
• un cas d'utilisation se déroule indépendamment des autres
• regrouper les cas d'utilisations qui
• s'enchainent toujours
• se décrivent, se testent ou se modifient ensemble
• un cas d'utilisation trop complexe est à découper
13

14. Analyse des données
L'analyse de données peut se faire avec
• l'analyse du contexte de la solution peut se faire à
l'aide du Diagramme de Flux de Données (DFD)
– montre les échanges de données entre
la solution et les entités extérieures ;
– Le DFD de contexte est le premier créer, où la solution est
définie comme une "boite noire"
– l'analyse du modèle de données
– représente et structure les données traitées par la solution
14

15. Exemple de DFD de contexte
annonces annonces
Site
Acheteur d’annonces Vendeur
enchère
notification
ordre de de paiement
paiement
demande confirmation
de paiement de paiement
Solution
Paiement
15

16. Illustration de
l'analyse descendante
l'analyse descendante est
présentée ici avec SADT
l'analyse descendante consiste à
décomposer pour réduire la
complexité la solution à
concevoir
16

17. Modèle de données
• Représente les entités gérées par le logiciel
o Entité : population homogène d'individu
• Guide de création :
o Lister les données sauvées, diffusées, traitées
o Eliminer redondance, synonyme, polysémie : utiliser et compléter le lexique
o Repérer les groupes nominaux et les classer par identifiants :
• les identifiants aident à déterminer les entités
o Repérer les verbes : ils aident à déterminer les associations
o Regrouper les données dans les bonnes entitées
Utilisateurs
Annonces
Nom
Prénom créér Titre
Date de naissance Description
Nom de rue
Code Postal
17

18. Exemple de modèle de
données spontané
• Site de petites annonces :
o met en relation des utilisateurs vendeurs et acheteurs. Les
vendeurs créent des annonces. Les acheteurs les
consultent et peuvent faire un paiement pour une
annonce. Les utilisateurs se contactent par leurs adresses.
créer
Utilisateurs Annonces
consulter
habiter payer est payée
Adresse Paiements
18

19. Architecture
• Structurer la solution en composant
• Organiser les composants
• Décompose le système à concevoir en
o applications, en composants applicatifs,
o analyse descendante jusqu’aux modules, aux composants ou
classes gestionnaires, aux fonctions ou méthodes
19

20. Architecture logique n tiers
• IHM (ou GUI) : client
T1
• Frontal (ou front-end) :
présentation T2
T2+T3
• Dorsal (ou back-end) : T3
métier
• Persistence : base de données
T4

21. Décomposition logique
proposée
• Choix de l'architecture logique n tiers
• T2 : Arborescence d'IHM et MVC T1
• T3 : Modules gestionnaires
• Choix technologiques
T2
V C
M
T3
Gestion Gestion Gestion
Paiements Clients Annonces
T4

22. Les différentes architectures
en informatiques
• Architectures logiques
o applicative,
o métier.
o le client, la maitrise d'ouvrage peut la comprendre
o non technique
• Architectures techniques
o logicielle, déploiement, système, réseau, matérielle
o créées et utilisées par des techniciens
o répond aux exigences techniques :
performance, robustesse, volumétrie, compatibilité, etc.
22

23. Analyse descendante
• Descendante = du général au détaillé
• Niveau 1
o Diagramme de cas d’utilisation, DFD
o Diagramme de séquence de niveau 1 (scénario)
o MCD
Niveau 1
• Niveau 2
o Conception de l’architecture logique
Niveau 2
• nombre de tiers logique
• identification des modules gestionnaires
o Create, Read, Update, Delete (CRUD) d'une ou plusieurs entités métier
o Conception des IHM
• Liste et enchainements d’écrans et fonctionnalités disponibles par écran
o Diagramme de séquence de niveau 2
• Détaille les modules gestionnaires, écrans et services métier utilisés dans un
scénario (CRUD, find, etc.)
o MLD
• Niveau 3 et suivants
o Décomposition de chaque module gestionnaire
o Détaille les écrans et les services métier
o Définition des architectures techniques
23

24. Pour continuer
• utiliser UML et 2TUP pour l'analyse descendante
• et plus spécifiquement
o pour la définition des IHM
• la méthode MACAO
• la méthode conception orientée utilisateur (user centered design)
• les bases de l'ergonomie (critères de Bastien et Scapin, heuristique de
Nielsen)
o pour l'analyse des données : la méthode Merise
o pour l'architecture logicielle : les design patterns
o pour l'organisation projet : PMBOK, SCRUM, eXtreme Programming
o pour les critères de choix technologiques des architectures système, réseau, et
matérielle : la veille technologique, le savoir faire de la maitrise d'oeuvre, les
conditions financières et juridiques
24