Elaborer un logiciel,        une solution informatique                  Extraits des supports de cours de J.P. CarmonaLe c...
Elaborer une solution           informatique• analyser QUOI faire :   – clarifier la connaissance métier ;   – définir pér...
Chemin du        Quoi et du Comment             client   fournisseur   client   fournisseur   client     fournisseurMarket...
Spécification• Etudier QUOI faire : build the right system• Déterminer les éléments intervenant dans le logiciel• L’analys...
Comment faire un logicielEtudier COMMENT faire : build the system rightApporter une solution technique au QUOI faireDétail...
Du cahier des charges      Cahier des                                 à la solution informatique       charges            ...
Démarche projet 2TUP                                                      Définition des                                  ...
Premiers pas pour            débuter l’analyse1. Limiter et clarifier le périmètre du logiciel à développer   o Ce qui ne ...
LexiqueIntérêts du lexique :• Clarifier les termes utilisés pour la documentation de la solution    • Eliminer les redonda...
Exigences•   Définir les exigences à partir de lexpression de besoins    dans le cahier des charges•   Identifier chaque e...
les diagrammes de   Cas d’Utilisation (UML)• Un cas dutilisation présente les acteurs de la solution   o Humain : utilisat...
Diagramme de cas   d’utilisation                   12
Règles sur les                   cas dutilisation• Chaque cas dutilisation doit avoir   o un nom avec au moins un verbe et...
Analyse des donnéesLanalyse de données peut se faire avec• lanalyse du contexte de la solution peut se faire à   laide du ...
Exemple de DFD de contexte           annonces                           annonces                               SiteAcheteu...
Illustration delanalyse descendantelanalyse descendante estprésentée ici avec SADTlanalyse descendante consiste àdécompose...
Modèle de données• Représente les entités gérées par le logiciel    o Entité : population homogène dindividu• Guide de cré...
Exemple de modèle de     données spontané• Site de petites annonces :   o met en relation des utilisateurs vendeurs et ach...
Architecture• Structurer la solution en composant• Organiser les composants• Décompose le système à concevoir en   o appli...
Architecture logique n tiers • IHM (ou GUI) : client                                   T1 • Frontal (ou front-end) :   pré...
Décomposition logique    proposée•   Choix de larchitecture logique n tiers•   T2 : Arborescence dIHM et MVC              ...
Les différentes architectures            en informatiques• Architectures logiques  o   applicative,  o   métier.  o   le c...
Analyse descendante•   Descendante = du général au détaillé•   Niveau 1     o Diagramme de cas d’utilisation, DFD     o Di...
Pour continuer• utiliser UML et 2TUP pour lanalyse descendante• et plus spécifiquement   o pour la définition des IHM     ...
Prochain SlideShare
Chargement dans…5
×

Elaborer un logiciel

1 743 vues

Publié le

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

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 743
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
70
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Elaborer un logiciel

  1. 1. Elaborer un logiciel, une solution informatique Extraits des supports de cours de J.P. CarmonaLe 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. 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. 3. Chemin du Quoi et du Comment client fournisseur client fournisseur client fournisseurMarketing ou MOA MOE ou Sous-traitantsDirection 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. 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. 5. Comment faire un logicielEtudier COMMENT faire : build the system rightApporter une solution technique au QUOI faireDétailler la solution en terme de données traitements architecturePrise en compte des problématiques techniquesChoisir une stratégie de réalisation 5
  6. 6. Du cahier des charges Cahier des à la solution informatique charges Analyse du cahier des charges aa bb cc Spécification Conception d ede générale générale ff hh ii 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. 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 dUtilisation 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 Exploitation7/15
  8. 8. Premiers pas pour débuter l’analyse1. 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 dautres logiciels) o Clarifier les termes métier dans un lexique o Structurer lexpression de besoin en exigences2. Identifier les utilisateurs et ce qu’ils pourront faire o Les fonctions disponibles par utilisateurs seront les cas dutilisation o Le détail des cas dutilisation donnera les traitements3. 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. 9. 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 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. 10. Exigences• Définir les exigences à partir de lexpression 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 lexigence 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 navoir quune 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. 11. les diagrammes de Cas d’Utilisation (UML)• Un cas dutilisation présente les acteurs de la solution o Humain : utilisateur final (client), administrateur (employé) o Logiciel : applications externes à la solution• Un cas dutilisation présente les fonctions utilisées par acteur o 1 fonction pour un 1 acteur = 1 cas dutilisation• La liste des cas dutilisation limite le périmètre du logiciel à créer• Chaque cas dutilisation possède un ou plusieurs scénarios o le scénario nominal ; o éventuellement des scénarios particuliers 11 o éventuellement des scénarios derreurs complexe
  12. 12. Diagramme de cas d’utilisation 12
  13. 13. Règles sur les cas dutilisation• Chaque cas dutilisation doit avoir o un nom avec au moins un verbe et un complément • un scénario nominal• Granularité dun cas dutilisation • un seul acteur qui initie laction • un seul but pour lacteur • pas dinterruption • un cas dutilisation se déroule indépendamment des autres • regrouper les cas dutilisations qui • senchainent toujours • se décrivent, se testent ou se modifient ensemble • un cas dutilisation trop complexe est à découper 13
  14. 14. Analyse des donnéesLanalyse de données peut se faire avec• lanalyse du contexte de la solution peut se faire à laide 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"– lanalyse du modèle de données – représente et structure les données traitées par la solution 14
  15. 15. Exemple de DFD de contexte annonces annonces SiteAcheteur d’annonces Vendeur enchère notification ordre de de paiement paiement demande confirmation de paiement de paiement Solution Paiement 15
  16. 16. Illustration delanalyse descendantelanalyse descendante estprésentée ici avec SADTlanalyse descendante consiste àdécomposer pour réduire lacomplexité la solution àconcevoir 16
  17. 17. Modèle de données• Représente les entités gérées par le logiciel o Entité : population homogène dindividu• 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. 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. 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. 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. 21. Décomposition logique proposée• Choix de larchitecture logique n tiers• T2 : Arborescence dIHM et MVC T1• T3 : Modules gestionnaires• Choix technologiques T2 V C M T3 Gestion Gestion Gestion Paiements Clients Annonces T4
  22. 22. Les différentes architectures en informatiques• Architectures logiques o applicative, o métier. o le client, la maitrise douvrage 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. 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) dune 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. 24. Pour continuer• utiliser UML et 2TUP pour lanalyse 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 lergonomie (critères de Bastien et Scapin, heuristique de Nielsen) o pour lanalyse des données : la méthode Merise o pour larchitecture logicielle : les design patterns o pour lorganisation 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 doeuvre, les conditions financières et juridiques 24

×