Upload
jaafar
View
21
Download
0
Embed Size (px)
DESCRIPTION
Chapitre 7 : démarche de conception, conduite de projet SI. ENSGI Cours MSI 2ème année Michel Tollenaere. Concepts de systémique. Système. Système de pilotage (ou de décision). Décisions. Informations traitées. Informations externes. Informations vers l’extérieur. - PowerPoint PPT Presentation
Citation preview
Chapitre 7 : démarche de conception, conduite de projet SI
ENSGI Cours MSI 2ème année
Michel Tollenaere
Système de pilotage (ou de décision)
Système d ’informations
Système opérantFlux entrants Flux sortants
Informations externes
Système
Informations vers l’extérieur
Informations collectées
Ordres, consignes
Informations traitées
Décisions
Concepts de systémique
1Analyse de la demande
Temps
2Spécification
projet
3Conception
générale
4Conception
détaillée
5Réalisation
6Mise en oeuvre
7Maintenance
Etapesou phases
Documents Schéma directeur
Etude d ’opportunité
Dossier d ’étude préalable
Dossier de
planification
Décisions
Dossierde
conception
Dossier de
conceptionfonctionnelle
détaillée
Dossier de
conceptiontechniquedétaillée
Cycle de vie d’un projet S.I.
Code
Accord sur l’inscription
du projet
Dossierd ’architecture
Choix d’une organisation
du projet
Accord sur les procédures,
l ’architecture ...
Recette logicielle
Réception système
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)
Cou
vertu
re
pré
occu
pat
ion
s
DétailCible à t
Etat futurEtat ancien
Niveau conceptuel
Niveau organisationnel
Niveau logique
Niveau physique
Niveaux d’abstraction
MCD, MCT, MCVO
MOD, MOT
MLD, MLT
Tables, codesystème physique
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 certainsdocuments ou logiciels. Les résultats sont définis sur la base des interactions entre étapes et activités, ils sont soumis à une revueapprofondie, 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.
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'uncomposant 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), etpermet ainsi d'éviter un écueil bien connu de la spécification du logiciel : énoncer une propriété qu'il est impossible de vérifierobjectivement après la réalisation.
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é.
Spécification
Branche conception Branche réalisation
Dossiers de validation
Codage des modules
Plan de tests
unitaires
Plan de tests d ’intégration
Intégration
Plan de tests de recette
Spécifications de domaine
Spécifications Conceptuelles
Spécifications Logiques
Spécications Techniques
de Réalisation
Cycle en V dans le développement d’un SI
Validation
Conception générale
Conception détaillée
Tests
unitaires
Etude d’opportunité
Mise en charge
Plan de tests en service
réponses :
Solutions
physiques
STB
Définition
organes
STG
Définition
composants
des organes
STD
Concrétisation
des pièces
STR
Fonctions
/
besoins clients
Branche conception Branche intégration
Plan de testsDossiers de validationTests
validation
composants
Plan de testsTests
Définition
organes
Plan de tests Intégration organe
et composantsvalidationphysiques
Plan de tests Intégration organe
validation besoins
Spécifications Techniques
de Besoin
SpécificationsTechniques Générales
SpécificationsTechniques
Détaillées
SpécificationsTechniques
de Réalisation
Cycle en V dans le développement d’un produit
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.
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.
Démarche de conception avec Merise
Aspect statiqueMCD
Aspect dynamiqueMCT
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
Quelques écueils : le Mythe de l’usager
Mythes de l’usagerMythe• 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.
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
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.