Chapitre 7 : d

1
Chapitre 7 démarche de conception, conduite de
projet SI

• ENSGI Cours MSI 2ème année
• Michel Tollenaere

2
Concepts de systémique
Système
Système de pilotage (ou de décision)
Informations traitées
Décisions
Informations externes
Informations vers lextérieur
Système d informations
Informations collectées
Ordres, consignes
Système opérant
Flux sortants
Flux entrants
3
Cycle de vie dun projet S.I.
1 Analyse de la demande
2 Spécification projet
3 Conception générale
4 Conception détaillée
5 Réalisation
6 Mise en oeuvre
7 Maintenance
Etapes ou phases
Temps
Schéma directeur
Dossier d étude préalable
Dossier de conception
Dossier de conception fonctionnelle détaillée
Documents
Code
Etude d  opportunité
Dossier de planification
Dossier de conception technique détaillée
Dossier d architecture
Décisions
Accord sur linscription du projet
Accord sur les procédures, l architecture ...
Recette logicielle
Réception système
Choix dune organisation du projet
4
Périmètre du projet

• Couverture du projet (domaines abordés les
  achats, la prod)
• préoccupations (fonctions prises en compte)
• Niveau de détail dans la description (dans les
  modèles)

Couverture
préoccupations
Cible à t
Détail
5
Niveaux dabstraction
Etat futur
Etat ancien
Niveau conceptuel
MCD, MCT, MCVO
MOD, MOT
Niveau organisationnel
MLD, MLT
Niveau logique
Tables, code système physique
Niveau physique
6
Cycles en SI (Cascade)

• Modèle de la cascade
• Dans ce modèle le principe est très simple
  chaque phase se termine à une date précise par la
  production de certains
• documents ou logiciels. Les résultats sont
  définis sur la base des interactions entre étapes
  et activités, ils sont soumis à une revue
• approfondie, on ne passe à la phase suivante que
  s'ils sont jugés satisfaisants.
• Les développements récents de ce modèle font
  paraître de la validation-vérification à chaque
  étape
• faisabilité et analyse des besoins
  validation
• conception du produit et conception
  détaillée vérification
• intégration test d'intégration et test
  d'acceptation
• installation test du système.

7
Cycles en SI (cycle en V)
Modèle du cycle en V Le principe de ce modèle
est qu'avec toute décomposition doit être décrite
la recomposition, et que toute description
d'un composant est accompagnée de tests qui
permettront de s'assurer qu'il correspond à sa
description. Ceci rend explicite la préparation
des dernières phases (validation-vérification)
par les premières (construction du logiciel),
et permet ainsi d'éviter un écueil bien connu de
la spécification du logiciel énoncer une
propriété qu'il est impossible de
vérifier objectivement après la réalisation.
8
Cycles en SI (cycle en V)

• Suite ...
• obligation de concevoir les jeux de test et
  leurs résultats
• réflexion et retour sur la description en cours
  
• meilleure préparation de la branche droite du V.
  
• Notons aussi que les activités de chaque phase
  peuvent être réparties en 5 catégories
• assurance qualité
• production
• contrôle technique
• gestion
• contrôle de qualité.

9
Cycle en V dans le développement dun SI
Branche conception
Branche réalisation
Etude dopportunité
Mise en charge
Plan de tests en service

Spécifications de domaine


Plan de tests de recette
Validation
Spécification
Spécifications Conceptuelles
Plan de tests d intégration
Conception générale
Intégration
Spécifications Logiques
Plan de tests unitaires
Conception détaillée
Tests unitaires
Dossiers de validation
Spécications Techniques de Réalisation
Codage des modules
10
Cycle en V dans le développement dun produit
Spécifications Techniques de Besoin
Spécifications Techniques Générales
Spécifications Techniques Détaillées
Spécifications Techniques de Réalisation
11
Cycles en SI (Cascade)
Modèle de la cascade
Proposé par B. Boehm en 1988, ce modèle est
beaucoup plus général que le précédent. Il met
l'accent sur l'activité d'analyse des risques
chaque cycle de la spirale se déroule en quatre
phases 1. détermination, à partir des
résultats des cycles précédents --ou de l'analyse
préliminaire des besoins, des objectifs du cycle,
des alternatives pour les atteindre et des
contraintes 2. analyse des risques, évaluation
des alternatives et, éventuellement maquettage
3. développement et vérification de la solution
retenue, un modèle classique (cascade ou en
V) peut être utilisé ici 4. revue des
résultats et vérification du cycle suivant.
L'analyse préliminaire est affinée au cours des
premiers cycles. Le modèle utilise des maquettes
exploratoires pour guider la phase de conception
du cycle suivant. Le dernier cycle se termine par
un processus de développement classique.
12
Cycles en SI (risques)

• Risques majeurs du développement du logiciel
• défaillance du personnel
• calendrier et budget irréalistes
• développement de fonctions inadaptées
• développement d'interfaces utilisateurs
  inadaptées
• produit plaqué or (pas de résistance à la
  charge)
• validité des besoins
• composants externes manquants
• tâches externes défaillantes
• problèmes de performance
• exigences démesurées par rapport à la
  technologie.

13
Démarche de conception avec Merise
Aspect statique MCD
Aspect dynamique MCT
1) Détermination des traitements essentiels
2) Modèle  local  de données vue
3) Modèle global de données (MCD)
4) Détermination des traitements complémentaires
5) Validation du (MCD) par les traitements
complémentaires
14
Quelques écueils le Mythe de lusager

• Mythes de lusager
• Mythe
• Un énoncé général des objectifs est
  suffisant pour commencer. On verra les détails
  plus tard.
• Les besoins du projet changent
  continuellement, mais ces changements peuvent
  être facilement incorporés parce que le logiciel
  est flexible
• Réalité
• Une définition insuffisante des besoins des
  usagers est la cause majeure d'un logiciel de
  mauvaise qualité et en retard.
• Les coûts pour un changement au logiciel
  pour corriger une erreur augmente dramatiquement
  dans les dernières phases de la vie d'un
  logiciel.

15
Mythe du développeur

• Mythe
• Une fois que le programme est écrit et
  marche, le travail du développeur est terminé.
• Tant qu'un programme ne fonctionne pas, il
  n'y a aucun moyen d'en mesurer la qualité.
• Pour le succès d'un projet, le bien livrable
  le plus important est un programme fonctionnel.
• Réalité
• 50-70 de l'effort consacré à un programme
  se produit après qu'il a été livré à l'usager.
• Les revues de logiciel peuvent être plus
  efficaces pour détecter les erreurs que les jeux
  d'essais.
• Une configuration de logiciel inclut de la
  documentation, des fichiers de régénération, des
  données d'entrée pour des tests, et les résultats
  des tests sur ces données

16
Mythes du gestionnaire

• Mythe
• L'entreprise possède des normes, le logiciel
  développé devrait être satisfaisant.
• Les ordinateurs et les outils logiciels que
  l'entreprise possède sont suffisants.
• Si le projet prend du retard, on ajoutera
  des programmeurs.
• Réalité
• Les standards sont-ils utilisés, appropriés
  et complets.
• Il faut plus que des outils pour réaliser de
  la qualité. Il faut une bonne pratique.
• Le développement du logiciel n est pas une
  activité mécanique. Ajouter des programmeurs
  peut-être pire encore.