Le dveloppement de SI

1
Le développement de SI

• Le guide de DMR

2
Généralités

• Ce guide de développement dun système fait
  partie dun ensemble de guides, les autres
  couvrent 
• La gestion de projet
• Le prototypage
• Le pilotage
• Intégrés et cohérents pour en faire un système et
  jouir des avantages dutiliser un système

3
Pour répondre à des lacunes

• Dans la démarche
• Dans l architecture

4
Lacunes dans la démarche

• Définition des besoins laborieuse
• Évaluation de faisabilité tardive
• Vue densemble absente
• Réajustements trop nombreux
• Bousculade de la fin de projet
• Outils pas très productifs

5
Lacunes dans l architecture

• Opaque, compliquée et documentation vite désuète
• Faible capacité dévolution
• Solutions trop attachées à la technique plutôt
  quaux problèmes daffaires

6
Objectifs au point de vue de la démarche

• Améliorer la définition des besoins, donc du
  dialogue avec usagers
• Permettre que le changement soit amené
  progressivement dans lorganisation 
• Donner à chaque participant une définition des
  produits quil doit livrer  discipline
• Maintenir une vue densemble et évaluer le risque
  et la complexité
• Assurer la livraison des produits et assurer leur
  qualité
• Documenter au fur et à mesure
• Informatiser le travail routinier des développeurs

7
Objectifs au point de vue de l architecture

• Un système aligner sur les objectifs de
  lorganisation, compris et validé par les usagers
  et tenant compte des facteurs critiques de succès
• Capable dévoluer pour sajuster à des besoins
  changeants
• Un système dont les parties sintègrent bien
• Un système qui pourra sintégrer aux autres
  systèmes, en place et surtout ceux à venir

8
Caractéristiques

• Intégrer modélisation de données et analyse
  structurée
• Reconnaître que la stabilité est dans les données
• Définir des produits à livrer et non pas des
  activités à accomplir (plus facile à mesurer)
• Réalisation graduelle  la documentation dun
  produit sera réalisée au fur et à mesure et
  livrée avec ce produit
• Trois phases initiales sappliquant à tout le
  système
• Suivies de trois phases sappliquant à des
  sous-ensembles généralement des fonctions ce qui
  permet
• Parallélisation et livraison de certains produits
  avant dautres
• Lutilisation dun atelier de génie logiciel qui
  facilite la tâche, favorise lévolution et
  améliore la productivité

9
Démarche adaptable

• À la taille du projet
• Au contexte courant
• Au système à développer
• À lorganisation

10
Principes de la démarche

• La construction de modèles
• Importance accordée aux données
• Du général au particulier
• Du conceptuel au physique
• Une solution d affaires
• Architecture et cohésion
• Le contrôle de la qualité
• Le contrôle du système

11
La construction de modèles

• Utilité des modèles  comme en architecture, en
  génie et en architecture navale
• Le modèle une représentation simple
• Modèles de données vs modèles de traitements

12
Du général au particulier

• Hiérarchie de modèles
• Frontières et interfaces
• Partition des traitements et partition des données

13
Du conceptuel au physique

• Trois types de question 
• Trois étapes de modélisation
• Interdépendance des données et des traitements
  (fig. 1.3.3.1 p 24) et de leurs modèles (fig.
  1.3.3.2 p 25)
• Vision intégrée (fig. 3.11.1.1)

14
Fig. 3.11.1.1
15
Trois types de questions trois niveaux de
modélisation

• Questions de définition (problème à résoudre)
• Questions de fonctionnement (solution adoptée)
• Questions d organisation physique (réalisation)
• Modèle conceptuel (choix de gestion)
• Modèle fonctionnel (choix d utilisation)
• Modèle physique (choix techniques)

16
Une solution d affaires

• Dépense vs investissement  productivité,
  ressource stratégique équilibre nécessité et
  sophistication (fig.1.4.1.1)
• Bénéfices escomptés/pôle dintégration syst.
  opérationnel vs syst. de contrôle vs syst.
  informationnel (fig. 1.4.2.1)
• Rapport coût/bénéfices  adéquation
  architecture face aux objectifs et à lusage

17
Architecture et cohésion

• Pourquoi
• Anticiper les problèmes de fonctionnement
• Harmoniser les parties du système
• Réduire la marge derreur des estimés
• Architecture fonctionnelle
• Architecture organique
• Règles d architecture

18
Architecture fonctionnelle et organique

• Architecture fonctionnelle  la structure de
  fonctionnement appropriée pour remplir les
  fonctions en tenant compte des contraintes
  administratives et financières réaliser les
  bénéfices et respecter le devis
• Architecture organique  linfrastructure
  informatique appropriée au mode de fonctionnement
  et aux contraintes techniques

19
Règles d architecture

• Analyse des enjeux pour arrêter son choix
• Trois pôles  données, activités et
  communications
• Harmonisation et imbrication
• Réduction de la marge derreur  devrait se
  rapprocher dune marge nulle (15) (fig. 1.5.4.1)

20
Contrôle de la qualité (fig. 1.6.1.1)

• Vérification du système  conforme à modèles
• Validation des modèles  conformes aux besoins
  (objectifs) et cohérents entre eux
• Utiliser les représentations graphiques résultant
  de lapplication des techniques de modélisation
  
• Utiliser le prototypage 

21
Les techniques de prototypage

• Elles se distinguent selon
• Les techniques de construction (fig. 1.6.3.1 et
  1.6.3.3)
• Maquette  visualiser surtout utile au niveau
  fonctionnel
• Exploratoire  permet de mieux comprendre aux
  trois niveaux
• Évolutif  les trois niveaux de modèles sont
  comprimés dans le temps
• Le niveau de modèle quils concrétisent (fig.
  1.6.3.2)
• Dorientation Conceptuel
• De comportement Fonctionnel
• Dinfrastructure Physique

22
Mise à lessai (fig. 1.6.4.1)

• Unitaire  pièce par pièce (section de programme,
  programme, groupe de programmes)
• Fonctionnel  intégration de toutes les
  composantes dune ou plusieurs fonctions,
  environnement complet et reproductible
• De système  dans lenvironnement réel pour voir
  si le système est acceptable, soumis au stress du
  débit etc.

23
Le contrôle du système (fig. 1.7.3.2)

• Fonctionnement  fonctionne-t-il comme prévu ?
  sinon il y a une carence (fig. 1.7.2.1)
  Exactitude et Rendement
• Auto contrôle ou contrôle par le sous-système de
  pilotage Ajuster les paramètres si possible ou
  faire une demande de correction
• Évolution  répond-il encore aux objectifs ?
  sinon il y a une anomalie (fig. 1.7.3.1)
• Stratégie
• Changement dans lenvironnement (affectant les
  besoins)
• Évolution des activités (affectant les besoins)
• Demande de modification

24
Les phases du développementVue densemble (fig.
2.1.1.1)

• Phases décrivent le processus
• La notion de livraison permet de découper,
  déphaser certaines parties et responsabiliser les
  personnes impliquées
• Sépare lensemble des phases en deux groupes
• Les trois premières pour lensemble du système
• Les trois dernières pour une partie du système à
  la fois, pour une livraison

25
Documentation

• Permet datteindre le but de la phase
• Devient un intrant aux phases suivantes
• Devient pour une grande partie la documentation
  du système

26
Techniques de modélisation et d essai

• Lintégration des techniques de modélisation est
  présentée à la figure 3.11.1.1
• Plus de détail dans le document intitulé Séquence
  des activités et documents utilisés dans la
  méthode de développement de DMR
• Les techniques dessai sont résumées à la figure
  3.11.2.1

27
Vocabulaire comparé