• Aucun résultat trouvé

Méthodologie de design

N/A
N/A
Protected

Academic year: 2022

Partager "Méthodologie de design"

Copied!
91
0
0

Texte intégral

(1)

Ingénierie des systèmes complexes Méthodologie de design

Méthodologie de design

Denis Laurendeau Professeur

Génie électrique et génie informatique Génie électrique et génie informatique

Université Laval

(2)

Note: ces notes s’inspirent du cours:

« Systems Engineering Training »

« Systems Engineering Training », Joe Jenney and Scott Armstrong

ITT Industries, Fort Wayne, IN, USA , y , ,

(3)

Table des matières

ƒ Historique des processus d’ingénierie des systèmes

ƒ Approche d’ingénierie simultanée («

concurrent design

»)

• Les étapes en bref

• Etape 1: Focalisation de l’équipe de design

• Etape 1: Focalisation de l équipe de design

• Etape 2: Planification du projet

• Etape 3: Développement du baseline du système

• Etape 4: Développement des sous-systèmes

• Etape 5: Définition des performances du système

• Etape 6: Vérification des performances du systèmep p y

• Etape 7: Intégration du système

(4)

Ingénierie des systèmes complexes

ƒ Historique

• Avant 1940

• 1940-19801940 1980

• 1980-20??

(5)

Historique

ƒ Avant 1940

• Projets simples

• Formation de l’équipe:

¾ Un ingénieur chef de projet

¾ Un ingénieur chef de projet

¾ Une équipe de développeurs

• Avantages:

¾ Communication facile à l’intérieur de l’équipe

¾ Communication facile à l intérieur de l équipe

• Inconvénients:

¾ Approche limitée aux systèmes simples

(6)

Historique des approches de design de systèmes

ƒ 1940-1980

• Projets plus complexes

• Formation de l’équipe:

¾ Ingénieurs de systèmes et équipe de développement formée

¾ Ingénieurs de systèmes et équipe de développement formée de spécialistes

Approche séquentielle de design avec revues de design périodiques.

p q

Avantages de cette approche:

¾ Possibilité de concevoir des projets plus gros grâce à l’ajout de spécialistes du domainep

Inconvénients de l’approche:

¾ Les longues périodes de temps entre les revues de design ne permettent pas de découvrir les faiblesses du design assez tôt g

(7)

Historique (suite)

¾ Le processus séquentiel tente d’estimer simultanément le coût, l’échéancier et la qualité du système Seulement deux de ces l échéancier et la qualité du système. Seulement deux de ces quantités sont indépendantes

¾ Le produit arrive à l’étape de la fabrication en série

(manufacturing) avant que la méthodologie de fabrication ne (manufacturing) avant que la méthodologie de fabrication ne soit complètement terminée

(8)

Historique (suite)

ƒ 1980-20??

• Nouvelles méthodes de d’ingénierie simultanée afin de contourner les difficultés propres à l’approche séquentielle

¾ Approche:

• Développement simultané des sous systèmes

• Développement simultané des sous-systèmes

• Implication hâtive des différents intervenants dans la conception et la fabrication du système:

» Manufacturing

» Contrôle de qualité

» Contrôle de qualité

» Service des achats

» Fournisseurs

» Etc.

¾ Objectif:

¾ Objectif:

Prévenir les problèmes plutôt que les solutionner

• Concevoir le bon système dès la première itération (do it right the first time!)

(9)

Approche d’ingénierie simultanée des systèmes Approche d ingénierie simultanée des systèmes

(Concurrent Engineering)

ƒ Les étapes du processus moderne de conception des

ƒ Les étapes du processus moderne de conception des systèmes complexes

Focalisation de l’équipe

Planification du projet

• Développement du baseline

• Développement desDéveloppement des sous systèmessous-systèmes (allocated baseline)(allocated baseline)

Définition des performances

Vérification des performances

I té ti d tè

Intégration des sous-systèmes

• Support à la production

(10)

L’approche d’ingénierie simultanée de systèmes complexes

?

?

(11)

Etape 1 Etape 1

Focalisation de l’équipe de design

(12)

Etape 1: focalisation de l’équipe de design…

ƒ Activités de cette étape:

• (*)Etablir les rôlesrôles et les responsabilitésresponsabilités de chaque membre de l’équipe

• (*)Concevoir un diagramme de contexte( ) diagramme de contextegg décrivant l’essence du système à réaliser

• (*)Utiliser le concept de DPFDPF (Description des Propriétés Fonctionnelles) pour établir clairement les exigences du ) p g client

client et la proposition de l’équipe de développement (le fournisseur

fournisseur) pour répondre à ces exigences

• Concevoir des diagrammes de Kanodiagrammes de Kanogg pour maximiser les p chances de succès et anticiper les développements futurs

(*) Les items marqués d’une étoile sont à considérer dans le cadre du cours de Design III) ( ) Les items marqués d une étoile sont à considérer dans le cadre du cours de Design III)

(13)

Etape 1: focalisation de l’équipe de design (suite)

ƒ Diagramme de contexte:

•• IsoleIsole le système du reste de l’univers

•• NommeNomme le système

•• CacheCache les parties internesparties internes au système

• Met en évidence les entréesentrées fournies au système et les actions actions effectuées par celui

effectuées par celui--cici en forçant leur identification et leur définition

• Rend la fonctionnalité principalefonctionnalité principale du système évidente

P t d é ifié ifi l li t l’ tit d d l éh i

• Permet de vérifiervérifier avec le client l’exactitude de la compréhension du problème par l’équipe de design

• Plusieurs itérationsitérations sont nécessaires pour arriver à un diagramme complet Des révisions sont nécessaires (et bénéfiques)

complet. Des révisions sont nécessaires (et bénéfiques).

• Exemple de diagramme de contextediagramme de contexte pour la conception d’un système d’alarme

(14)

Etape 1: … Concept de DPF

ƒ Une DPFDPF est un outil utile pour formulerformuler un problème

ƒ La DPF focalise l’équipe sur les exigencesexigences et les attentesattentes du client

ƒ La DPF identifie les fonctionnalités (et sous-fonctionnalités) que doit offrir le système pour satisfaire les exigences et les paramètresparamètres

offrir le système pour satisfaire les exigences et les paramètres paramètres critiques

critiques (PC) associés à chaque fonctionnalité

ƒ Les fonctionnalités sont décrites par des verbes d’actionverbes d’action

ƒ La DPF doit être utilisée tout au long du cycle de développement du système

ƒ La DPF ne tient pas immédiatement compte des risques associés à chaque fonctionnalité. Voir notions de risque et de registre de risques p. 43.

(15)

Etape 1 … Comment concevoir une DPF

ƒ Remue-méninges sur quiqui est le client et les autres parties impliquées dans le projet

impliquées dans le projet

ƒ Remue-méninges sur les exigencesexigences du client

ƒ Classer les exigencesexigences en ordre de prioritépriorité

Remue méninges sur les forcesforces de la compagnie et sur les

ƒ Remue-méninges sur les forcesforces de la compagnie et sur les fonctionnalités

fonctionnalités requises pour le produit (voir p. 30 pour une définition précise de « fonctionnalité »)

ƒ Organiser ces fonctionnalitésOrganiser ces fonctionnalitésfonctionnalités enfonctionnalités en catégories (et leur associer catégories (et leur associercatégories (et leur associercatégories (et leur associer les paramètres critiques)

les paramètres critiques)

ƒ Construire une matrice de relationsmatrice de relations entre les exigences du client et les fonctionnalités

ƒ Tenter d’estimer les valeurs souhaitées de performancevaleurs souhaitées de performance pour les fonctionnalités (dans le cadre du cours, cette étape n’est pas couverte)

(16)

Etape 1 … Concept de DPF (suite) Structure d’une

DPF

Matrice de couplage

DPF

couplage

Fonctionnalités nécessaires pour satisfaire les exigences

Quoi?

Comment?

Catégorie 1 Catégorie 2

Fonct. 1

Paramètres critiques Fonct. 2

Paramètres critiques Fonct. 1 Fonct. 2

Exigences

du Matrice de

P e r c e

d u c

Paramètres critiques Paramètres critiques

Exigence 1 Exigence 2

2 5

Nombre entre 0 et 5 estimant

Voir matrice de couplage

i t Exemple d’une

du

client relations e

p ti o n

c l i e n t 0 et 5 estimant

la dépendance entre une exigence et une fonctionnalité

page suivante p

DPF

DPF pour le

Système d’alarme

Combien?

Estimation des avantages compétitifs

(17)

Etape 1 … Concept de DPF (suite)

Matrice de couplage

Cat. 1 Cat 2

Matrice de couplage

Cat. 1 Fonct 1

Fonct. 1 Fonct. 2 Fonct. 1 Fonct. 2

Fonct. 1 Fonct. 2

Fonct. 1 Fonct. 2

(18)

Etape 1 … Concept de DPF (suite)

Dans les systèmes complexes pour lesquels le projet doit tenir t d l f b i ti l f ti lité d’ ét

compte de la fabrication, les fonctionnalités d’une étape deviennent les exigences de l’étape suivante

Planification Design Planification du Planification des

du produit

Design

processus opérations

Besoins du

client Usine

(19)

Etape 1 … Construction de diagrammes de Kano

ƒ Les diagrammes de Kano diagrammes de Kano permettent d’identifier le design gagnant

design gagnant auprès du client.

ƒ Ils illustrent graphiquement le niveau de satisfaction niveau de satisfaction du client en fonction de la présence présence ou de l’absence l’absence du client en fonction de la présence présence ou de l absence l absence de caractéristiques sur le produit

ƒ Ce niveau de satisfaction se trace pour trois cas:

Caractéristiques obligatoiresobligatoires

Caractéristiques obligatoires amélioréesobligatoires améliorées et caractéristiques optionnelles mineuresq optionnelles mineurespp

Caractéristiques optionnelles majeuresoptionnelles majeures

(20)

Etape 2 Etape 2

Planification du projet

(21)

Etape 2: Planification du projet

ƒ Principaux buts buts de cette étape

•• IdentifierIdentifier et documenterdocumenter les tâches techniques critiquestâches techniques critiques qui doivent être implantées pour mener à un projet fonctionnel

•• IdentifierIdentifier et documenterdocumenter les autres facteurs critiques au q fonctionnement du projet

ƒƒ Approche Approche pour la planification du projet

Développement d’ un plan de gestion intégréplan de gestion intégré (PGI!)

Développement d un plan de gestion intégréplan de gestion intégré (PGI!)

(*)Développement d’un diagramme de flux des activitésdiagramme de flux des activités techniques (PERT flow chart et Gantt Chart)

l t d’ ll dd délidéli titi t dt d ii l til ti

Développement d’un plan de modélisation et de simulationplan de modélisation et de simulation (PMS)

(22)

Etape 2 … Plan de Gestion Intégré (PGI)

ƒ Le PGI est formé des éléments suivants:

Une description de haut niveau du projet

¾ (*)Liste des biens livrables critiques (milestones)

¾ (*)Description des biens livrables et les standards de qualité ( ) p q associés

¾ Liste des objectifs à long terme (par rapport à la gamme des produits déjà supportés par l’entreprise)

¾ Diagramme PERT au niveau système

Un arbre des plans de haut niveau

¾ Hardware/software

¾ Développement à l’interne ou achat des sous systèmes

¾ (*)Description technique du système

(23)

Etape 2 … Plan de Gestion Intégré (PGI) (suite)

ƒ PGI (suite)

(*)Un Work Breakdown Structure (WBS)

¾ (*)Identification des coûts de fabrication

¾ Budget préliminaire, liste des sources de financementg p ,

Un plan d’utilisation des ressources en personnel

¾ Prévisions préliminaires des besoins en personnel (en mois-

¾ Prévisions préliminaires des besoins en personnel (en mois homme)

¾ Identification des ressources critiques

¾ Identification des rôles

¾ Identification des ententes de formation des équipes

Une liste des hypothèses fondamentales

(*)Une liste des risques (risk register)( )Une liste des risques (risk register)

(24)

Etape 2 … Plan de Gestion Intégré (PGI) (suite)

ƒ PGI (suite)

Liste des interdépendances et des inter-relations entre les différents programmes en cours de développement

Un plan préliminaire de support au développement:p p pp pp

¾ Plan de gestion des documents (Configuration Management Control Plan)

¾ Plan d’assurance qualité

¾ Plan de logistique et de support sur le terrain (field support)

¾ Plan de gestion des dépenses

¾ Plan de mesures environnementales et de santé/sécurité

ƒ Le PGI est un document d’environ 7 à 10 pages

(25)

Etape 3 Etape 3

Développement du baseline du système

(26)

Etape 3: Définition du baseline du système

ƒ Le baseline baseline du système comprend les éléments i t

suivants:

•• (*)Diagramme des fonctionnalités(*)Diagramme des fonctionnalités du système

•• (*)Diagrammes(*)Diagrammes--PP

• (*)Liste de compromiscompromis (Matrice de Pugh)

•• SpécificationsSpécifications pour le système et arbre des spécificationsarbre des spécifications

• Spécification de l’interfacel’interface du système

• Modèle de simulationsimulation du système

•• (*)Diagramme(*)Diagramme du système physique

•• (*)Plan de repli(*)Plan de repli( )( ) pp face aux risques (registre de risque et plan q ( g q p de réaction face au risque)

• Base de données de « tracabilitétracabilité » des « requirements »

• Liste des technologies critiquestechnologies critiques

(27)

Etape 3… Définition du baseline du système (suite)

ƒ Le baseline du système comprend les éléments suivants (suite):

• Identification des fournisseurs principauxfournisseurs principaux

• Identification desIdentification des installations principalesinstallations principalesinstallations principalesinstallations principales (et/ou critiques) de(et/ou critiques) de test

test et de fabricationfabrication

(28)

Etape 3…(suite)

ƒ Diagramme des fonctionnalités fonctionnalités

• Illustre la segmentationsegmentation du système en fonctionnalitésfonctionnalités sans considérer l’implantation physique des fonctionnalités

• Les fonctionnalités sont les actionsactions que le système doit q y

prendre pour rencontrer les exigencesexigences (« requirements ») et pour produire la réponseréponse désirée aux excitations d’entrée

¾ Les fonctionnalités n’occupent aucun volume, n’ont aucune masse et ne sont pas « visibles »

¾ Elles commencent par un verbe d’action suivi de noms

• Les fonctionnalités complexes sont décomposées en fonctionnalités plus simples

(29)

Etape 3…(suite)

ƒƒ Diagramme du système physique Diagramme du système physique

• Les fonctionsfonctions identifiées dans le diagramme des

fonctionnalités sont accomplies par des dispositifs physiquesdispositifs physiques réels

• Les composantes hardware/software complexescomposantes hardware/software complexes sont

composées d’un assemblageassemblage de composantes plus simples

• Un modulemodule (ou un sous-système) du diagramme peut ( y ) g p

implanter une ou plusieurs fonctionnalités ou seulement une fraction de fonctionnalité

(30)

Etape 3…(suite)

ƒ La conception conception (design) du système consiste à ff t ii d f f ti ti lité lité ( ’ t

effectuer un mapping mapping des fonctionnalités fonctionnalités («qu’est-ce que doit accomplir le système »…what do I need to do) vers les sous-systèmes formés de dispositifs dispositifs

h d / ft tt t d’i l t ll i

hardware/software permettant d’implanter celles-ci (« que faut-il pour accomplir ces actions » … what do I need to do it)

ƒ Une matrice matrice est utile pour illustrer le mapping entre les fonctionnalités et les sous-systèmes et leurs

dispositifs physiques p p y q

ƒ Un mapping 1Æ 1 entre les fonctionnalités et les

sous-systèmes physiques est hautement souhaitable parce que cela:

parce que cela:

(31)

Etape 3…(suite)

• Simplifie la préparation des spécificationsspécifications

• Simplifie les procédures de testtest

• Simplifie la spécification et l’implantation des interfacesinterfaces

• Facilite la misemise--àà--niveauniveau (« upgrade ») du système( pg ) y

• Facilite le découpage du travaildécoupage du travail

ƒƒ (*)Exemple de (*)Exemple de diagramme des fonctionnalités diagramme des fonctionnalités pour le pour le système d’alarme

système d’alarme système d’alarme système d’alarme

ƒƒ (*)Exemple de (*)Exemple de diagramme physique diagramme physique pour le système pour le système d’alarme

d’alarme

(32)

Etape 3…(suite)

ƒƒ GuideGuide de préparation des spécifications. Une spécification

défi it i d it êt tt i t t d èt iti

définit ce qui doit être atteint en termes de paramètres critiques du systèmes:

• Définir l’utilitél’utilité de la spec. Et celui vers qui elle est destinée S i l tt dd dd ié (MIL STD 490 h d MIL

• Suivre les standardsstandards appropriés (MIL-STD-490 hardware, MIL- STD-498 software)

• Préparer l’arbre des spécificationsl’arbre des spécifications avant d’écrire les specs.

¾ Permet d’établi un plan de ce que l’on a à faire

¾ Permet d établi un plan de ce que l on a à faire

¾ Assure un flux logique des specs

• Réfléchir attentivement à la spécificationspécification et à sa portéeportée (scope)

• Disposer d’unDisposer d un plan de contrôle de configurationplan de contrôle de configurationplan de contrôle de configurationplan de contrôle de configuration (configuration(configuration control)

• Préparer le formatformat (template) des spécifications avant de les écrire

(33)

Etape 3…(suite)

A faire lors de la préparation des spécifications

ƒ Définir l’utilitél’utilité de la spec

ƒ Avant d’écrire une spec:

• Raffiner le modèle des

ƒ Inclure les élémentséléments suivants dans les spécifications:

Interfaces

Diagramme physique

Raffiner le modèle des spécifications au besoin

ƒ Préparer l’arbre des l’arbre des spécifications

spécifications du projet

Diagramme physique

Diagramme fonctionnel

Description des modes d’utilisation du système M t i d é ifi ti

spéc cat o s

spéc cat o s p j

ƒ Nommer un responsableresponsable du document des spécifications

ƒ Définir un plan d’écritureplan d’écriture

Matrice de vérification

ƒ Inclure à la fois les exigences fonctionnelles

fonctionnelles et les exigences physiques

physiques Définir un plan d écritureplan d écriture

des specs Utiliser TBRTBR (To Be Revised) quand une spec. est

préliminaire (ex. le poids de la brocheuse ne devrait pas dépasser 0 5 Kg)

dépasser 0,5 Kg)

(34)

Etape 3…(suite)

• Inscrire TBDTBD (To Be

Defined) quand la valeur de

ƒ Ecrire les spécifications clairement

Defined) quand la valeur de la spec est inconnue et

qu’une estimation ne peut être faite lors de l’écriture (exemple: couleur du

clairement

• Toutes les exigences doivent être nécessaires

• La spec doit définir ce qui (exemple: couleur du

revêtement du boîtier du système d’alarme)

•• MinimiserMinimiser le nombre de TBR t TBD

p q

doit être atteint et non comment l’atteindre

• Devrait être indépendante des autres specs

TBR et TBD

• Inclure les limiteslimites et le domaine de variation

domaine de variation de la spec (ex. le système

des autres specs

• Décrire la spec en un seul paragraphe

•• Le système doit être en Le système doit être en d’ i d l d’ i d l d’alarme doir pouvoir

fonctionner entre +40 et -40 degrés Celsius

mesure d’atteindre la spec mesure d’atteindre la spec

• La spec doit pouvoir être vérifiée

vérifiée

(35)

Etape 3…(suite)

ƒ Les spécifications portant sur les performances obligatoires

ƒ Les versions de la rédaction des spécifications devraient être

les performances obligatoires doivent utiliser le mot « doitdoit » (shall) dans leur définition

ƒ Les spécifications portant sur

spécifications devraient être soumises à des révisions par révisions par les pairs

les pairs

ƒ Les spécifications peuvent être Les spécifications portant sur

les performances non-

obligatoires doivent utiliser le mot « devraitdevrait » (should) dans l défi iti

Les spécifications peuvent être rédigées pour les soussous--

systèmes

systèmes (ou les modulesmodules), ce qui rend leur performances plus

l i i l’ t t d l

leur définition

ƒ Le mot « devradevra » (will) ne doit être utilisé que pour exprimer une déclaration mais ne doit

claires que si l’on tente de les déduire à partir des

spécifications de chacune de leurs composantes

une déclaration, mais ne doit jamais apparaître dans la définition d’une spécification

p

(36)

Etape 3…(suite)

ƒ GARDER LES SPECIFICATIONS SIMPLES…elles ne sont pas une solution de design, mais désignent plutôt ce que le système doit atteindre comme

performance pour répondre aux exigences.

performance pour répondre aux exigences.

(37)

Etape 3…(suite)

A NE PAS faire lors de la préparation des spécifications

ƒ Ne pas rédiger les specs avant que:

• L’analyse soit complétée sur

ƒ Ne pas documenter inutilement

ƒ Sans garder le bon niveau

y p

l’item pour lequel la spec est rédigée

• Le rôle de la spécification

it i t l

Sans garder le bon niveau de contrôle de configuration

ƒ Sans garder une

« tracabilité » des specs soit compris par tous les

intervenants

• L’arbre des spécifications du projet soit complété

tracabilité des specs

du projet soit complété

ƒ Ne pas inclure de solutions de design dans la

description de la spec description de la spec

(38)

Etape 3 …(suite) – La gestion du risque

ƒ Eléments fondamentaux:

• Comprendre ce qu’est le risquerisque

• Comprendre comment le risque doit être abordé abordé (notion de risk management

risk management)

• (*)Comprendre l’importance du registre de risques (risk risk register

register)

(39)

Etape 3 …(suite) – La gestion du risque

ƒ Qu’est-ce que le risque?

é é

• Probabilité qu’un événement indésirableindésirable se produise

•• ConséquencesConséquences de l’occurrence d’un événement indésirable

(40)

Etape 3 …(suite) – La gestion du risque

ƒ Attitudes dangereuses dangereuses face au risque:

•• IgnoranceIgnorance (jouer à l’autruche)

•• NierNier son existence en adoptant des échéanciers optimistes

•• Cacher des contraintesCacher des contraintesCacher des contraintesCacher des contraintes (parfois planifiées mais non(parfois planifiées, mais non diffusées aux membres de l’équipe)

• Cacher le plus longtemps possible les dépassementsdépassements de cédule

cédule

• Faire de la rétention d’informationrétention d’information

(41)

Etape 3 …(suite) – La gestion du risque

ƒ Attitudes positives positives face au risque:

• Etre honnêtehonnête et ne rien cacher

• Etre objectifobjectif et utiliser des faits concrets plutôt que des impressions pour identifier les risquesp p q

•• PrécisionPrécision: vérifier les calculs d’estimation des risques

•• DiffusionDiffusion de l’information et justificationjustification claire des décisions

décisions

(42)

Etape 3 …(suite) – La gestion du risque

ƒ Cinq facettes du risque à prendre en compte:

• Aspects techniquestechniques relatifs à la performance du système face aux attentes du client

• Aspects relatifs à l’environnement du programmep l’environnement du programmepp gg de

développement du système (ressources, clients, production, sous-contracteurs, fournisseurs)

• Aspects relatifs au support p support du produit (entretien, formation, pppp p ( , , etc.)

• Aspects relatifs au coûtcoût

• Aspects relatifs àAspects relatifs à l échéancierl’échéancierl’échéancierl échéancier

(43)

Etape 3 …(suite) – La gestion du risque

ƒ Approches de prise en compte du risque

• Utilisation d’un registre de risquesregistre de risques

¾

¾ ListeListe des risques identifiés par le rapport coût/bénéficecoût/bénéfice associé à chaque risque

¾ Stratégies de réductionréduction des risques

¾ Identification de l’entité responsableresponsable de gérer le risque jusqu’à son élimination

• Associer un niveau de prioritépriorité à chaque risque

• Etablir une liste de critèrescritères selon lesquels les décisions sur chaque risque sont prises

• Le chef de projetchef de projet crée et met à jour le registre de risques

• La stratégie de réductionréduction des risques doit faire partie du budget et de l’échéancier du projetg p j

(44)

Etape 3 …(suite) – La gestion du risque

ƒ Approches de prise en compte du risque (suite)

• Le budgetbudget doit prévoir un coût pour les risques afin de minimiser le coût global du projet en respectant les exigences de performance et l’échéancier

La liste des risques (stockée dans le registre de risques) doit

• La liste des risques (stockée dans le registre de risques) doit être établie lors de la préparationpréparation de la proposition du projet (en réponse à un appel d’offres par exemple).

• Le registre de risques ne doit pas seulementLe registre de risques ne doit pas seulement énumérerénumérerénumérerénumérer lesles risques, mais également les décriredécrire en détails.

• Il faut estimer le niveau de vraisemblanceniveau de vraisemblance d’occurrence d’un risque et estimer les conséquences de sa présence en termes de coûts directs et indirectscoûts directs et indirects, de même qu’en

termes de délaisdélais et de dégradation des performancesdégradation des performances du système

•• RevoirRevoir régulièrement la liste des risques et la mettre à jour

•• RevoirRevoir régulièrement la liste des risques et la mettre à jour

(45)

Etape 3 …(suite) – La gestion du risque

Registre de risques

(46)

Etape 3 …(suite) – La gestion du risque

ƒ La matrice de Pugh Pugh est un bon moyen de réduire les risques. q

ƒ Pour construire la matrice de Pugh Pugh:

• Un concept est choisi comme référenceréférence (benchmark)

• Des concepts alternatifsconcepts alternatifs sont comparés au concept de

• Des concepts alternatifsconcepts alternatifs sont comparés au concept de référence selon des critères clairement établis

Matrice de Pugh

Nombre entre -5 et +5

Fonctionnalité Concept référence

Détecter une intrusion Détecteur mouvement IR Détecteur Mouvement laser -1

Détecteur ouverture magnétique Détecteur ouverture mécanique 0

Déclencher une alarme Sirène électrique Haut-parleur de caisse de son -1

Concept alternatif 1

Alimenter le système Pile 9 volts Secteur 1

Avantage global -1

(47)

Etape 4 Etape 4

Développement des sous-systèmes

(allocated baseline)

(48)

Etape 4 Développement des sous-systèmes

ƒ Cette étape consiste à:

• Développer le partitionnementpartitionnement optimal des sous-systèmes

•• DéfinirDéfinir et documenterdocumenter les exigences (requirements) requises pour chaque sous-système et chaque interfaceinterface entre les sous systèmes

entre les sous-systèmes

• Établir les spécificationsspécifications pour chaque sous-système aux niveaux matérielmatériel et logiciellogiciel

• Établir les spécificationsspécifications des interfacesinterfaces entre les sous

• Établir les spécificationsspécifications des interfacesinterfaces entre les sous- systèmes

• Concevoir les diagrammesdiagrammes--blocsblocs des sous-systèmes (matériel et logiciel (potentiellement en UML))

( g (p ))

ƒ Les principes vus précédemment pour la description du système complet s’appliquent à chaque sous-

système

système

(49)

Etape 5 Etape 5

Définition

Définition des performances du système

(50)

Etape 5 Définition des performances du système

ƒ Cette étape consiste à:

• Développer des outils permettant de prédireprédire les

performances du système et des sous-systèmes critiques

• Définir la méthodologieméthodologiegg pertinente à la vérificationp vérification de chaque performance du système

•• ObserverObserver le niveau de performance des paramètres

critiques tout au long du processus de design (notamment q g p g ( lors de changements ou lors du choix de concepts alternatifs pour réduire les risques)

(51)

Etape 5 … (suite)

ƒ Cette étape est accomplie en:

• Effectuant des simulationssimulations pour les sous-systèmes et le système complet

• Développant et en tenant à jour une matrice de vérificationpp j matrice de vérification des performances

• (*)Identifiant et observant l’évolution des mesures de mesures de performances techniques

performances techniques (MPT) (Technical Performance

p q

p q ( ) (

Measures ou TPM)

(52)

Etape 5 … (suite)

ƒ Qu’est-ce qu’une mesure de performance mesure de performance technique

technique (MPT)?

•• IndicateurIndicateur clé des performances techniques du système ou de l’un de ses sous-systèmesy

¾ Valeur attendue

¾ Marge de sécurité

¾ Variations

• Choisie en utilisant la matrice de DPFDPF

ƒ La MPT est observée périodiquement observée périodiquement (par exemple

b ll ) é ifi l i ti

sur une base mensuelle) pour en vérifier la variation au cours du processus de développement (voir

exemple).

(53)

Etape 5 … (suite)

ƒ Avantages associés à l’utilisation des MPT:

• Permet de visualiservisualiser l’historique des performances par rapport aux performances spécifiées

• Permet la prédictionprédictionpp et la détectiondétection hâtives des problèmesp

• Permet de suivre les « zoneszones » à risque» à risque du projet

•• DocumenteDocumente les principales hypothèses techniques et la direction que celles-ci prennent tout au long du

direction que celles ci prennent tout au long du développement du projet

(54)

Etape 5 … (suite)

ƒ Méthodologie de génération des MPT:

• Identifier les paramètres critiques à suivre (à partir de la matrice DPF)

• Identifier les spécifications et les valeurs-cibles pour chaque p p q paramètre identifié

• Déterminer les valeurs de performances présentes par modélisation, simulation, analyse, estimation ou mesure, , y ,

• Tracer l’évolution temporelle des paramètres pour analyser les tendances et prendre les actions nécessaires en cas de problème

p

(55)

Exemple de MPT pour le système d’alarme

Design III – Système d’alarme MPT

27/01/2005

MPT: Tension d’alimentation 15

Tension

Spécification

Zone de Variation permise

Temps

Livrable 1 Livrable 2 Livrable 3

(56)

Etape 6 Etape 6

Vérification

Vérification des performances du système

(57)

Etape 6: Vérification

ƒ Une fois les performances définies définies, il convient de vérifier

vérifier si celles-ci respectent les exigences

attendues du système (« requirement compliance »)

ƒ Approche généralement adoptée:

ƒ Approche généralement adoptée:

•• (*)Identifier(*)Identifier les exigences imposées pour les performances du système (« requirements ») en construisant une matrice matrice de vérification

de vérification (« Requirement Verification Matrix) de vérification

de vérification (« Requirement Verification Matrix)

• (*)Le résultatrésultat des vérifications est une matrice de respect matrice de respect des exigences

des exigences (« Requirements Compliance Matrix)

(58)

Etape 6: Vérification (suite)

ƒ (*)La matrice de vérification des exigences vérification des exigences (Requirements Verification Matrix):

•• IdentifieIdentifie la méthodeméthode retenue pour vérifier chaque exigence (inspection, test, démonstration, analyse,

( p , , , y ,

différence/similitude)

•• IdentifieIdentifie le niveauniveau pour lequel les vérifications seront effectuées (module, assemblage,sous-système, système)( , g , y , y )

(59)

Etape 6: Vérification (suite)

ƒ Méthodes de vérification:

t ti

t ti é ifi ti d l f ti lité d té i l d

•• DémonstrationDémonstration: vérification de la fonctionnalité du matériel ou du logiciel sanssans l’aide d’outils de test (en faisant fonctionner le bidule)

•• InspectionInspection: vérification visuellevisuelle de la forme, de l’ajustement et de la configuration du matériel ou du logiciel (regarder la pièce pour g g ( g vérifier qu’elle est bien bleue)

•• SimilitudeSimilitude: vérifie le respect des exigences en se basant sur l’utilisation garantie de composantes similairescomposantes similaires dans des

conditions identiques ou plus sévères (diode utilisée est la même conditions identiques ou plus sévères (diode utilisée est la même que dans un design similaire)

•• TestTest: utilise des techniquestechniques (potentiellement sophistiquées ) pour vérifier les performances (utiliser un interféromètre pour vérifier la courbure d’une surface)

courbure d une surface)

•• AnalyseAnalyse: utilisation d’outils eux mêmes vérifiés pour vérifier les performances. Peut demander l’analyse de donnéesl’analyse de données

expérimentales recueillies lors de mesures spécifiques (lors

d’ t t t l i é ti )

d’autres tests par exemple via une équation).

(60)

Etape 6: Vérification (suite)

ƒ (*)Matrice de vérification des performances vérification des performances:

• Liste les performancesperformances pour toutes les exigencesexigences (requirements)

• Liste les performances du simplep simplepp au complexecomplexepp (c’est-à-dire ( composante->sous-système->système)

• Identifie les sourcessources des données de mesure des performances

p

• Montre si le design atteint le niveau de performance design atteint le niveau de performance requis

requis

• Montre tôt dans le processus de design si une performanceMontre tôt dans le processus de design si une performance n’est pas atteinte (non-compliance) et permet de concevoir un planplan pour faire face à ce problème (mitigation plan).

(61)

Etape 6: Vérification (suite)

ƒƒ Objectifs Objectifs de l’étape de vérification:

• Développer la stratégiestratégie et la méthodologieméthodologie de test et les inclure dans le processus de design dès le début de manière à ce que les tests s’effectuent de manière optimale.

• Développer les plans d’intégrationd’intégration et de testtest pour le système complet

• Assurer que les exigences principalesq exigences principalesgg pp pp (« cardinal (

requirements) seront vérifiées via la matrice de vérification des exigences (« requirements compliance matrix »)

•• DocumenterDocumenter tous les tests importants des systèmes et p y sous-systèmes

•• AnalyserAnalyser les données de test

(62)

Etape 6: Vérification (suite)…planification des tests

ƒƒ (*)Planification (*)Planification des tests tests…objectifs:

• Définir le processusprocessus de test (« Test Plan »)

• Développer les équipementséquipements de test en utilisant la même approche de design de système que pour la conception du pp g y q p p système lui-même

• Développer les procédures de testprocédures de test (« test procedure »), le processus d’analyse des donnéesd’analyse des données de test (nature, format,

p yy ( , ,

etc) et les logicielslogiciels d’analyse (type, nom, fournisseurs) en parallèle

parallèle avec le design du système

• Développer la procédure de supportpp procédure de supportpp pppp à l’équipe de test, q p , l’approche d’intégration du système et les approches de solution de problèmes

solution de problèmes

(63)

Etape 6: Vérification (suite)…planification des tests

ƒ Les étapes de planification des tests:

• Identification des objectifsobjectifs et définition des prioritéspriorités afin de réduire l’impact potentiel de conflits de ressources

• Identifier les paramètresparamètrespp sujets à vérification et nécessitant j des mesures (MPT)

• Identifier les besoins en termes de données à recueillirdonnées à recueillir pour les tests

p

ƒƒ QuantitéQuantité de données à recueillir en relation de la

méthodologie de test (des données inutiles pour un test sans objet sont inutiles…De mauvaises données pour un test

ti t t é l t i til ) pertinent sont également inutiles)

(64)

Etape 6: Vérification (suite)…planification des tests

Développer la méthodologieméthodologie de test et les procédures de test:

¾

¾ DocumenterDocumenter validervalider et diffuserdiffuser la méthodologie

¾

¾ DocumenterDocumenter, validervalider, et diffuserdiffuser la méthodologie

¾ Définir les conditions initialesconditions initiales d’exécution des tests, les conditions d’interruption

d’interruption, et les conditions d’acceptation ou de rejetd’acceptation ou de rejet des résultats des tests

¾ Réduire la dépendance de la procédure de test par rapport au reste

¾ Réduire la dépendance de la procédure de test par rapport au reste de la documentation (la documentation de test devrait autant que possible être autosuffisante)

Préparer le plan d’analyseplan d’analyse des données

¾ Déterminer la q antitéq antité et le t pet pe de données à rec eillir

¾ Déterminer la quantitéquantité et le typetype de données à recueillir

¾ Définir les procédures d’analyseprocédures d’analyse de même que les outilsoutils qu’elles requièrent

¾

¾ ValiderValider les procédures et les outils avant leur utilisation

Ceci peut avoir des conséquences sur les paramètres à mesurer (par exemple, il se peut qu’un test soit impossible à effectuer

parce que le paramètre d’intérêt soit très difficile à mesurer…(ex.

Columbia 01/02/03)

(65)

Etape 6: Vérification (suite)…planification des tests

ƒƒ Produits Produits résultant de la planification des tests:

•• MéthodologieMéthodologie de test du système (commentcomment le système sera-t-il testé)

•• Plan de testPlan de test du système (« Test Plan ») (quey ( ) (qqueq veut-on tester dans le système)

•• Matrices de vérificationMatrices de vérification

•• ListeListeListeListe et des équipements de test de même que leurset des équipements de test de même que leurs spécifications

spécifications

Gabarit pour le rapport des tests

(66)

Etape 6: Vérification (suite)…planification des tests

ƒƒ Avantages Avantages offerts par la planification planification hâtive des tests:

• Permet d’améliorerd’améliorer le design pour faciliterfaciliter les tests

• PermetPermet d intégrerd’intégrerd’intégrerd intégrer les tests à la procédure deles tests à la procédure de vérificationvérificationvérificationvérification

• Permet d’identifier les montagesmontages de même que les outils outils logiciels

logiciels requis pour effectuer les tests

• Permet de définir la séquence des testsséquence des tests en fonction de la

• Permet de définir la séquence des testsséquence des tests en fonction de la séquence d’implantation du hardware et du logiciel

séquence d’implantation du hardware et du logiciel

• Permet de réduireréduire les risques

(67)

Etape 6: Vérification (suite)…planification des tests

ƒ Remarques générales sur les tests

• La planification des tests devrait faire partie intégrale des plans de développement d’un produit

• La planification des tests devrait être faite par des membres p p appartenant à toutes les disciplinestoutes les disciplines

• Des tests appropriés pour les soussous--systèmessystèmes favorisent le test du système intégréy g

• Les équipementséquipements de tests devraient faire l’objet d’une documentation complète

• La conduite des tests est un élément important duLa conduite des tests est un élément important du budgetbudgetbudgetbudget pour les systèmes complexessystèmes complexes (par exemple les systèmes pour l’exploration spatiale)

(68)

Exemple de plan de test pour le système d’alarme

Niveau Sous-niveau Exigence Méthode de vérification Équipement requis Méthode d'analyse

Détecter intrusion Détecter mouvement Vmin Test Chronomètre

Ruban à mesurer Source d'alimentation Détecteur XP-112 Oscilloscope numérique Un passant

Vmax Test Chronomètre

Mesurer la vitesse avec le chronomètre et le ruban. Mesurer le signal à la sortie du

Mesurer la vitesse

Vmax Test Chronomètre

Ruban à mesurer Source d'alimentation 5 v Détecteur XP-112 Oscilloscope numérique Un passant

Taille Test Règle Mesurer dimensions

Dét t t O t i T t Dét t C t t XP 23

Mesurer la vitesse avec le chronomètre et le ruban. Mesurer le signal à la sortie du

Dé l ti

Détecter ouverture Ouverture min Test Détecteur Contact XP-23 Source alimentation 5 v

Vernier de déplacement linéaire Système de fixation du détecteur et du vernier

Spreadsheet Amorcer/Désamorcer…

Déplacer une partie du détecteur avec la vis en laissant l'autre fixe. Noter la tension aux bornes du

(69)

Etape 7 Etape 7

Intégration

Intégration du système

(70)

Etape 7 Intégration du système

ƒ (*)Le plan d’intégration sert de guide à l’intégration des

diffé t ti ( tè d di h i ) d

différentes parties (sous-systèmes du diagramme physique) du système complet

ƒ Le plan d’intégration définit les étapes d’intégration et leur

d t t l

ordonnancement temporel

ƒ Le plan d’intégration, dont le déroulement fait partie intégrante du diagramme Gantt, est conçu tôt dans le processus de

dé l t fi d id l’é i t d tt i i

développement afin de guider l’équipe et de permettre un suivi serré de étapes de design et d’implantation

ƒ Le plan d’intégration doit être cohérent avec le plan de test

ƒ L’intégration des sous-systèmes doit se faire le plus tôt possible afin de favoriser une étape de test rigoureuse et complète

(71)

Etape 7 Intégration du système – Exemple plan d’intégration

Afficher Un site Déclencher

l Détecter

i t i

Amorcer/

Alimenter Un site

d’intrusion alarme

intrusion Alimenter désamorcer

Phase 1

Phase 2

Phase 3

Système D’alarme

(72)

Les étapes du processus de développement (en bref - 1)

(73)

Les étapes du processus de développement (en bref - 2)

(74)

Les étapes du processus de développement (en bref - 3)

(75)

Documents importants du processus de développement

Documents importants du processus de développement

(76)

Documents importants...

Documents à caractère technique

Diagramme Contexte

Description propriétés fonctionnelles

Diagramme des fonctionnalités Besoins

du client

Matrice de Pugh Diagramme

physique

Mesure des

performances Diagrammes-P physique

techniques

Matrice de vérification des

exigences

Matrice de vérification des

performances

Design du système

(77)

Documents importants...

Documents de planification et de gestion

Diagramme

WBS Pl

Diagramme

de Gantt WBS

Registre Plan de

Plan d'intégration

de risques test

(78)

Analyse Approche séquentielle Design

Implantation

Intégration

Test

(79)

Approche d’ingénierie simultanée

O t ité

Proposition

Opportunité

Définition et

Preliminary Design Review

Définition et

Choix de concept

l t

PDR

Début

Technical Readiness Review

Développement

Validation TRR

CDR

Gel progressif

Gel progressif

Critical Design Review

Production CDR

Gel progressif

(80)

Références

Documents relatifs

 Une liaison pivot glissant entre 2 pièces est réalisée à partir d’une contrainte de coaxialité entre 2 surfaces cylindriques..  Une liaison pivot entre 2 pièces

Avant d’imposer une solution, il faut se tourner vers le demandeur, pour aboutir de manière structurée à la solution. En effet, le but d'un projet est de satisfaire le besoin.

Remarque : Les fonctions de service peuvent être classées suivant leur importance, le concepteur devra donc privilégier certaines fonctions en terme de

B. La repr´esentation du syst`eme dans l’ing´enierie syst`eme L’expression des exigences repose sur une vue abstraite du syst`eme, repr´esentant diff´erents niveaux de

Avec ce point de vue, l’ensemble des solutions est soit vide (deux droites non sécantes), soit réduit à un point (droites non parallèles), soit une droite (les deux droites

En posant la question : devant le

 Je sais reconnaître un nom propre dans une phrase... ● J'habite dans un

©lutinbazar.frIllustrations : copyright © Muriel Sevestre«Mes fiches mémo» Magnard..