Cond-projet.ppt

Cours MSI, conduite de projets 1
version 1.2 du 10 décembre 2007
Démarche de conception,
conduite de projet SI
ENSGI Cours MSI 2ème année
Michel Tollenaere
http://www.g-scop.fr/~tollenam/msi/diaporamas/Cond-projet.ppt

Système opérant
Flux entrants Flux sortants
Système
Système d ’informations
Informations
externes
Informations
vers l’extérieur
Informations
collectées
Ordres,
consignes
Système de pilotage
(ou de décision)
Informations
traitées
Décisions
Concepts de systémique

Exemple : une bibliothèque
Flux Physiques :
Flux d’information :
Système de décision :
Contraintes
Les livres, les abonnés de la bibliothèque, les prêts consentis aux
abonnés, les restitutions des exemplaires d’ouvrages empruntés, les
renouvellements des abonnements, l’entrée d’ouvrages nouveaux, les
réparations d’ouvrages
Des informations sur les ouvrages : numéro ISBN, titre, auteur,
éditeur, année d’édition, nombre de pages… Des informations sur les
abonnés : nom, prénom, adresse, date de validité… Des informations
sur les prêts : date des prêts, durée, numéro d’abonné, numéro du livre
…Nombre moyen de prêts par jour, historique des ouvrages non
restitués dans les délais, ouvrages les plus empruntés,…
Tarif des abonnements, durée d’un prêt, nombre maximal
d’ouvrages prêtés simultanément, sanction des prêts non
restitués, acquisition de nouveaux ouvrages…

Exemple : une compagnie de transport (SNCF)
Flux Physiques :
Flux d’information :
Système de décision :
Contraintes
Les trains, les wagons, les voyageurs, les billets, les réservations, les
départs et les arrivées, les trajets (par exemple : Paris – Grenoble), le
paiement d’un billet,…
Le trajet : n° de trajet, nom ville de départ et nom ville d’arrivée,
fréquence, heure de départ et heure d’arrivée, n° billet, n° réservation,
n° siège réservé, heure effective d’un départ et heure effective d’une
arrivée…
CA d’une ligne, fréquentation d’une ligne selon période de l’année….
Définition de la grille tarifaire, définition des trajets pour une
période donnée, ouverture de nouveaux trajets, achat de
nouveaux équipements (TER)…..

Fonctions d’un S.I.
Le SI comporte une représentation ou modèle :
- du système opérant
- des décisions issues du système de décision
Le SI permet aux processus de s’exécuter :
- CRM
- SRM
- Supply chain
- Processus de création de l’offre

Fonctions d’un S.I.
Système opérant
Flux entrants Flux sortants
(ou de décision)
Système d ’informations
Système opérant
(ou de décision)
Flux physique
entrant
Flux physique
sortant
Saisie
Stockage
Traitement
Restitution
Transmission
et
communication
Transmission
et
communication

Fonctions d’un S.I. : la saisie (1)
Lecteur code barre (bluetooth)
Scanner
• Reconnaissance vocale
• Reconnaissance écriture manuscrite
• Reconnaissance de caractères
Clavier + souris

Fonctions d’un S.I. : la saisie (2)
Fonctions de localisation et de communication
GPS + GSMdata / GPRS
GPS + bluetooth

Fonctions d’un S.I. : le stockage
Archivage courte et longue durée
Disque dur
CD
DVD
Bande magnétique
Logiciel de gestion de fichiers
Logiciel de SGBD
L’archivage long terme nécessite de conserver
toute la chaîne matérielle et logicielle
Savoir où
se trouve
l’information.
sécurité

Fonctions d’un S.I. : le traitement
Créer de nouvelles informations à partir de celles existantes avec
des opérations de tri, de calculs, de regroupements ….
Cette fonction utilise des ordinateurs, serveurs, systèmes
d’exploitation, logiciels d’application …..
En 1944, le premier prototype des calculateurs électroniques,
l'ENIAC (Electronic Numerical Integrator and Computer).
5.000 addition par seconde (calcule la trajectoire d'un obus
avant qu'il n'arrive à destination). 1.000 fois plus rapide que
les autres machines de son époque. Mais utilise 18.000 tubes
électronique. L'aération nécessite des ventilateurs de 24 CV.
La consommation électrique est de 150 kW (plusieurs rames
de métro). 30 tonnes sur 1.000 mètres carrés. Multiplication
en 3 millisecondes, fréquence d'horloge : 100kHz. Construit
par Eckert et Mauchly, pour le compte de l'US army
(calculateur balistique). Divulguée deux ans plus tard, avec
un relookage de la machine pour le marketing (panneau
lumineux).

Fonctions d’un S.I. : la restitution (1)
• électronique :
protocole WEB (en
Internet, extranet,
Intranet)
• restitution de
rapports, états, …
imprimés

Fonctions d’un S.I. : la restitution (2)
• revue de maquette numérique Airbus

Fonctions d’un S.I. : transmission
communication
• Interopérabilité entre WEB et téléphonie GSM/GPRS
Déplacer l’information d’un point à un autre
réseaux hertziens
transmission par satellites
réseaux privés d’entreprises
fibre optique
connnexion infra-rouge
messagerie électronique
protocole « Bluetooth »
voir cours « Réseaux »

Notion de modèle
• Qu’est ce qu’un modèle ? (Minsky 1968)
http://web.media.mit.edu/~minsky/papers/MatterMindModels.txt
A* est un modèle de A pour un observateur O
ssi A* aide O à répondre aux questions qu’il se pose sur A.
Système observé
Modèle
Observateur
Où sont construites les ailes ?

1
Analyse de
la demande
Temps
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
Documents Schéma
directeur
Etude d ’
opportunité
Dossier
d ’étude
préalable
Dossier
de
planification
Décisions
Dossier
de
conception
Dossier de
conception
fonctionnelle
détaillée
Dossier de
conception
technique
détaillée
Cycle de vie d’un projet S.I.
Code
Accord sur
l’inscription
du projet
Dossier
d ’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)
préoccupations

Etatfutur
Etatancien
Niveau
conceptuel
Niveau
organisationnel
Niveau
logique
Niveau
physique
Niveaux d’abstraction
MCD, MCT, MCVO
MOD, MOT
MLD, MLT
Tables, code
système physique

Modèles de processus
Modèle Organisationnel de
Traitements (MOT) de Merise
• Enchaînement des opérations ou taches
• condition d’enchaînement
• acteur affecté (qui ?)
• période de traitement (quand ?)

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.

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.

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 tests
Dossiers de validation
Tests
validation
composants
Plan de tests
Tests
Définition
organes
Plan de tests
Intégration organe
et composants
validation
physiques
Plan de tests Intégration organe
validation besoins
Spécifications
Techniques
de Besoin
Spécifications
Techniques
Générales
Spécifications
Techniques
Détaillées
Spécifications
Techniques
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.

Quelques écueils : le Mythe de l’usager
Mythes de l’usager
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.

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.

De la Gestion des Données Techniques
pour l’ingénierie de production
Référentiel du domaine et cadre méthodologique pour l’ingénierie
des systèmes d’information techniques en entreprise.
Jean-Marc CELERIER
GSP - DR - DARP
Renault Technocentre
CENTRALE
P A R I S
Bernard YANNOU
Laboratoire CGI
École Centrale Paris
Présentée par Rebiha BACHA
pour GILCO/ENSGI
Le 11 décembre 2001

Architecture du référentiel : quatre méta-entités
Contexte Problématique État de l’art Plan d’actions Contribution
Bilan Perspective
PRODUIT
RESSOURCE
SYSTEME INDUSTRIEL
PROCESS
Investissement techno
Line balancing
Affectation process
Contrôle de validité
Cas d'emploi
Flux de pièces
….
Conditionnement Ordonnancement
de pièces...
Faisabilité robotique, Contrôle du process...
Activités d'ingénierie
de production
Implantation
Allocation de surfaces
Terminologie
MANDATE
Terminologie
PSL

Architecture du référentiel : principaux composants
Nomenclatures
Entreprise
Processus
Fonctions
objets
indécomposables
Bilan Perspective
Cas
d'emploi
Chiffrage
Analyse des
temps
Contrôle
qualité
Cas d'utilisation métier
Équilibrage
de ligne
Implantation
Caractéristiques du site
Hypothèses
projet
Maquette
d'effectifs
Schéma des
flux
Répartition
des
surfaces
Investissement
technologique
Spécificités de GDT
Cycle de vie des
objets
Structure
de
documents
Matrice
CRUD
Versionnement

Zoom sur l'objet : Bord de Chaîne (BdC)
Bilan Perspective
BdC
Site
Atelier
Ligne
Tronçon
Poste
Le BdC appartient
à la structure SI
SYSTEME INDUSTRIEL RESSOURCE PROCESS PRODUIT
Robot
Opérateur
Réception &
stockage
Pièces, opérations et
ressources affectées au BdC
Engageur
Implanteur
Contrôleur
Ergonome
Chef d'atelier
Préparateur
Cumul : chiffrage,
surfaces allouées...
Fiabilité, cotation
Champ de vision
de l'opérateur...
Gamme opératoire,
Analyse Temps...
Allocation de surfaces
Équipements installés
Mode opératoire
Ordonnancement
de pièces...

Expérimentation : cas de la GED pour le SPR - Le contexte
Bilan Perspective
Intentions du projet Nouveau système documentaire
Produit final attendu Application de grande taille
Contraintes environnementales Réutilisation des SIT existants
Quel contenu informationnel des documents ?
Quelle structure d'accueil de la GED ?
Y-a-t-il des liens potentiels entre documents ?
Questionnements...

Expérimentation : cas de la GED pour le SPR - l'application
Nom Opération
Raccordement câblage moteur / boîtier
d'injection
Numéro Opération
B 015 010-X74
Page
1/1
Véh.
X74
N° F.E.
F14110 / F10128
N° Opés SITMO
265 1110 / 198 2005
Diversité prise en compte
T.T.
Commentaires
Initialisation
Feuille OPERATION PROCESS 'A'
Appr
EM
Niv
N
Date
09/00
Prep
BK
Approuvé Emetteur
Date
PROCEDURE :
1- Aligner le câblage moteur sur support
calculateur
2- Raccorder les 3 connecteurs (S -
gris), (T - marron) et (U - noir), dans
l'ordre (S, T, U) sur le boîtier d'injection
(R) par verrouillage des leviers.
3- Fixer le collier (V) du câblage moteur
sur le goujon du support calculateur,
avec l'écrou (A).
NOTES :
IMMO
Une mauvaise connexion engendre une
panne immobilisante pour le client.
11/09/00 B. KEIB
EM
A garantir
A
R
Serrage
Couple : 6,8 - 9,2
Cible : 8 Nm
Marquage :
Ref. outil :
Méth. de Ctrl
U
T
S
V
SIT de la GED :
données et
documents
Sites
Accès et
distribution WEB
Bilan Perspective
Consolider
Structurer
Nouvelles
données SPR
Données réelles
Référentiel
Pièces
géométriques...
SI d'entreprise
Technologie GED
Création dynamique
de documents
Workflow, gestion
de configurations
Gestion CRUD,
maturité...

Cond-projet.ppt

Recommandé

Recommandé

Contenu connexe

Similaire à Cond-projet.ppt

Similaire à Cond-projet.ppt (20)

Cond-projet.ppt