SlideShare une entreprise Scribd logo

Elaborer un logiciel

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

1  sur  24
Télécharger pour lire hors ligne
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
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
             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
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
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
Publicité

Recommandé

Contenu connexe

Tendances

Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 
Cours génie logiciel
Cours génie logicielCours génie logiciel
Cours génie logicielaraddaoui
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieMohammed Amine Mostefai
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logicielMajid CHADAD
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logicielguest0032c8
 
Convergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XPConvergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XPAgile Tour Genève
 
Modèle en v
 Modèle en v Modèle en v
Modèle en vbouye2209
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMireille Blay-Fornarino
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logicielRabia AZIZA
 
Pres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 frPres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 frPatrick Sarfati
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle managementKlee Group
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1DIALLO Boubacar
 
Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesMohammed Amine Mostefai
 

Tendances (20)

cycle de vie
cycle de vie cycle de vie
cycle de vie
 
Cmmi
CmmiCmmi
Cmmi
 
Maintenance logicielle
Maintenance logicielleMaintenance logicielle
Maintenance logicielle
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Cours génie logiciel
Cours génie logicielCours génie logiciel
Cours génie logiciel
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
Convergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XPConvergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XP
 
Modèle en v
 Modèle en v Modèle en v
Modèle en v
 
Psp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 FrPsp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 Fr
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifié
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
Pres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 frPres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 fr
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle management
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
 
Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architectures
 

Similaire à Elaborer un logiciel

Friday Web 16 01 2009
Friday Web 16 01 2009Friday Web 16 01 2009
Friday Web 16 01 2009Arnaud_Pukan
 
Industrialisation des développements CRM 2011
Industrialisation des développements CRM 2011Industrialisation des développements CRM 2011
Industrialisation des développements CRM 2011Microsoft
 
Projet COM02.ppt
Projet COM02.pptProjet COM02.ppt
Projet COM02.pptPtidej Team
 
La mise en œuvre d’un ERP
La mise en œuvre d’un ERPLa mise en œuvre d’un ERP
La mise en œuvre d’un ERPAyoub Minen
 
Genie logiciel eseo-v1.1-1spp
Genie logiciel eseo-v1.1-1sppGenie logiciel eseo-v1.1-1spp
Genie logiciel eseo-v1.1-1sppLaurent Guérin
 
Présentation des métiers du design numérique, janvier 2009
Présentation des métiers du design numérique, janvier 2009Présentation des métiers du design numérique, janvier 2009
Présentation des métiers du design numérique, janvier 2009designers interactifs
 
Introduction colloque ALPI sur la maquette numérique
Introduction colloque ALPI sur la maquette numériqueIntroduction colloque ALPI sur la maquette numérique
Introduction colloque ALPI sur la maquette numériqueALPI
 
Soft fluent@md day2011
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011MDDAY11
 
M02 dessin assisté par ordinateur ac tsgo btp-tsgo
M02 dessin assisté par ordinateur ac tsgo btp-tsgoM02 dessin assisté par ordinateur ac tsgo btp-tsgo
M02 dessin assisté par ordinateur ac tsgo btp-tsgoimad-sektaoui
 
3 ds prg_cdfva2013
3 ds prg_cdfva20133 ds prg_cdfva2013
3 ds prg_cdfva2013jln94
 

Similaire à Elaborer un logiciel (20)

Friday Web 16 01 2009
Friday Web 16 01 2009Friday Web 16 01 2009
Friday Web 16 01 2009
 
Industrialisation des développements CRM 2011
Industrialisation des développements CRM 2011Industrialisation des développements CRM 2011
Industrialisation des développements CRM 2011
 
Projet COM02.ppt
Projet COM02.pptProjet COM02.ppt
Projet COM02.ppt
 
Support programmation orientée aspect mohamed youssfi (aop)
Support programmation orientée aspect mohamed youssfi (aop)Support programmation orientée aspect mohamed youssfi (aop)
Support programmation orientée aspect mohamed youssfi (aop)
 
La mise en œuvre d’un ERP
La mise en œuvre d’un ERPLa mise en œuvre d’un ERP
La mise en œuvre d’un ERP
 
Algorithme
AlgorithmeAlgorithme
Algorithme
 
Acfas 13-05-2010
Acfas 13-05-2010Acfas 13-05-2010
Acfas 13-05-2010
 
Fiche Ci2 Mei
Fiche Ci2 MeiFiche Ci2 Mei
Fiche Ci2 Mei
 
Batir Un Site Web 2011
Batir Un Site  Web 2011Batir Un Site  Web 2011
Batir Un Site Web 2011
 
Tableau cd p_m2_2012
Tableau cd p_m2_2012Tableau cd p_m2_2012
Tableau cd p_m2_2012
 
Genie logiciel eseo-v1.1-1spp
Genie logiciel eseo-v1.1-1sppGenie logiciel eseo-v1.1-1spp
Genie logiciel eseo-v1.1-1spp
 
Présentation des métiers du design numérique, janvier 2009
Présentation des métiers du design numérique, janvier 2009Présentation des métiers du design numérique, janvier 2009
Présentation des métiers du design numérique, janvier 2009
 
Introduction colloque ALPI sur la maquette numérique
Introduction colloque ALPI sur la maquette numériqueIntroduction colloque ALPI sur la maquette numérique
Introduction colloque ALPI sur la maquette numérique
 
Soft fluent@md day2011
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011
 
Agl2012
Agl2012Agl2012
Agl2012
 
LMO02.ppt
LMO02.pptLMO02.ppt
LMO02.ppt
 
M02 dessin assisté par ordinateur ac tsgo btp-tsgo
M02 dessin assisté par ordinateur ac tsgo btp-tsgoM02 dessin assisté par ordinateur ac tsgo btp-tsgo
M02 dessin assisté par ordinateur ac tsgo btp-tsgo
 
BiZness CardZ
BiZness CardZBiZness CardZ
BiZness CardZ
 
3 ds prg_cdfva2013
3 ds prg_cdfva20133 ds prg_cdfva2013
3 ds prg_cdfva2013
 
WONC DOVA
WONC DOVAWONC DOVA
WONC DOVA
 

Plus de Jean-Paul CARMONA

OpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur InternetOpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur InternetJean-Paul CARMONA
 
5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACA5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACAJean-Paul CARMONA
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logicielJean-Paul CARMONA
 

Plus de Jean-Paul CARMONA (6)

Modèle cas d'utilisation
Modèle cas d'utilisationModèle cas d'utilisation
Modèle cas d'utilisation
 
Cartopartie de fuveau #1
Cartopartie de fuveau #1Cartopartie de fuveau #1
Cartopartie de fuveau #1
 
OpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur InternetOpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur Internet
 
Objets métier
Objets métierObjets métier
Objets métier
 
5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACA5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACA
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 

Elaborer un logiciel

  • 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