Elaborer un logiciel, une solution informatique

1

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.

Extraits des supports de cours de J.P. Carmona

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

Chemin du Quoi et du Comment

3

Quoifaire

Comment Faire

Marketing ouDirection générale

MOADirection métier

Quoifaire

Comment Faire

MOE ouDirection informatique

Sous-traitantsou expert technique

Quoifaire

Comment Faire

client fournisseur client fournisseur client fournisseur

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

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

Spécification générale

Conception générale

Conception détailléeet Réalisation #1

Logiciel(s) et documentation

Cahier des charges

Du cahier des chargesà la solution informatique

Campagne detestConception détaillée

et Réalisation

abcdefhi

v1 abcdefhi

v3

abcdefhi

abcdefhi

Analyse du cahier des charges

Itération ou lot

Démarche projet 2TUP

Bran

che

fonc

tionn

elle

Branche Technique

Spec. fonctionnelles générales

Spec. fonctionnelles détaillées

Maquettage

Conception générale

Atelier logiciel

Architectures

Conception détaillée

Développement

Réalisation itérative

Intégration

Validation

Recette

Définition des besoins

Mise en production

Exploitation

7/15

Quoi faireDiagrammes de• Cas d'Utilisation• Séquence niveau

1• MCD

• Séquence niveau n

Comment faireDiagrammes de• Composant• Classes technique• Choix technologique

(framework, langage, outils)

Premiers pas pourdébuter l’analyse

1. Limiter et clarifier le périmètre du logiciel à développero 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 lexiqueo Structurer l'expression de besoin en exigences

2. Identifier les utilisateurs et ce qu’ils pourront faireo Les fonctions disponibles par utilisateurs seront les cas d'utilisationo Le détail des cas d'utilisation donnera les traitements

3. Analyser les donnéeso 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

LexiqueInté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

• Les termes largement utilisés dans chaque jargon sont candidatsà entrer dans le lexique

• Quelques catégories de terme : métier, informatique, entreprise

9

jargonmétier

jargoninformatiqueLexique

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èmeo Simple : une seul exigence à la foiso Traçable : numéroter chaque exigence, historiser les modificationso Non ambiguës : susceptible de n'avoir qu'une seule interprétationo Cohérente : ne pas contredire un autre exigence, utiliser le même

vocabulaireo Réalisable : réaliste quant aux moyens mis en oeuvre pour le projet

les diagrammes deCas d’Utilisation (UML)

• Un cas d'utilisation présente les acteurs de la solutiono Humain : utilisateur final (client), administrateur (employé)o Logiciel : applications externes à la solution

• Un cas d'utilisation présente les fonctions utilisées par acteuro 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énarioso le scénario nominal ; o éventuellement des scénarios particuliers o éventuellement des scénarios d'erreurs complexe 11

Diagramme de cas d’utilisation

12

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

Analyse des donnéesL'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

Exemple de DFD de contexte

15

Acheteur VendeurSite

d’annonces

SolutionPaiement

enchère

demandede paiement

annonces

confirmationde paiement

annonces

notificationde paiementordre de

paiement

Illustration de l'analyse descendante

16

l'analyse descendante est présentée ici avec SADT

l'analyse descendante consiste à décomposer pour réduire la complexité la solution à concevoir

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éeso Eliminer redondance, synonyme, polysémie : utiliser et compléter le lexiqueo Repérer les groupes nominaux et les classer par identifiants :

• les identifiants aident à déterminer les entitéso Repérer les verbes : ils aident à déterminer les associationso Regrouper les données dans les bonnes entitées

17

NomPrénomDate de naissance

TitreDescription

AnnoncesUtilisateurs

Nom de rueCode Postal

créér

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.

18

Adresse

Utilisateurs

Paiements

Annonces

créer

est payéepayerhabiter

consulter

ce n'est

ni un diagramme de classe

ni un MCD (Merise

)

ni un diagramme ER,

c'est un brouillo

n !

Architecture• Structurer la solution en composant• Organiser les composants

• Décompose le système à concevoir eno applications, en composants applicatifs,o analyse descendante jusqu’aux modules, aux composants ou

classes gestionnaires, aux fonctions ou méthodes

19

Architecture logique n tiers• IHM (ou GUI) : client

• Frontal (ou front-end) : présentation

• Dorsal (ou back-end) : métier

• Persistence : base de données

T1

T2

T3

T4

T2+T3

Décomposition logiqueproposée

T2

T3

T4

T1

V

M

C

GestionClients

Gestion Annonce

s

GestionPaiement

s

• Choix de l'architecture logique n tiers• T2 : Arborescence d'IHM et MVC• T3 : Modules gestionnaires• Choix technologiques

Les différentes architectures

en informatiques

• Architectures logiqueso applicative, o métier.o le client, la maitrise d'ouvrage peut la comprendreo non technique

• Architectures techniqueso logicielle, déploiement, système, réseau, matérielleo créées et utilisées par des technicienso répond aux exigences techniques :

performance, robustesse, volumétrie, compatibilité, etc.

22

Analyse descendante• Descendante = du général au détaillé• Niveau 1

o Diagramme de cas d’utilisation, DFDo Diagramme de séquence de niveau 1 (scénario)o MCD

• Niveau 2o Conception de l’architecture logique

• nombre de tiers logique• identification des modules gestionnaires

o Create, Read, Update, Delete (CRUD) d'une ou plusieurs entités métiero Conception des IHM

• Liste et enchainements d’écrans et fonctionnalités disponibles par écrano 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 suivantso Décomposition de chaque module gestionnaireo Détaille les écrans et les services métiero Définition des architectures techniques

23

Niveau 1

Niveau 2

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 Meriseo pour l'architecture logicielle : les design patternso 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