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

Ingénierie des systèmes complexes

H-2018 Design III / Projet multi 1

Ingénierie des systèmes complexesMéthodologie de design

Denis LaurendeauProfesseur

Génie électrique et génie informatiqueUniversité Laval

Revue par Dominic Grenier



Note: inspiré du cours: « Systems Engineering Training », Joe Jenney and Scott Armstrong ITT Industries, Fort Wayne, IN, USA

§ 9500 employés§ chiffre d’affaire 2.5 G$



Joe Jenney§ Dr. Joe Jenney writes from the experience of having practiced effective leadership methods and achieved dramatic improvements in organizations. He is an executive with more than 35 years of leadership experience. This experience is in a variety of organizations. Positions have been in small and large organizations from entrepreneurial startups to corporate staff of multi billion dollar enterprises. He led research and development, manufacturing, services and projects organizations. § He learned the principles and practices of leadership from mentoring, training and hands-on practice. He had the good fortune to receive mentoring from famous management experts and leadership authors. He received management training from numerous company-sponsored programs and the Wharton School of the University of Pennsylvania.§ Dr. Jenney’s management skills and experience with process improvement methodologies led to his selection as the first President and Chief Executive Officer of the National Center for Quality, an organization formed to provide quality management training for Northeast Tennessee. The National Center for Quality was the genesis for the Tennessee Quality Award, a model for quality management worldwide.


4

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 2: Planification du projet•  Etape 3: Développement de la base de référence 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ème•  Etape 7: Intégration du système

H-2018 Design III / Projet multi


5


§  Historique•  Avant 1940•  1940-1980•  1980-20??




Historique

§  Avant 1940•  Projets simples•  Formation de l’équipe:

Ø Un ingénieur chef de projetØ Une équipe de développeurs

•  Avantages:Ø Communication facile à l’intérieur de l’équipe

•  Inconvénients:Ø Approche limitée aux systèmes simples


7

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 de spécialistes

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

•  Avantages de cette approche:Ø Possibilité de concevoir des projets plus gros grâce à l’ajout de

spécialistes du domaine•  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



8

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 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 soit complètement terminée



9

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•  Implication hâtive des différents intervenants dans la conception et

la fabrication du système:»  Fabrication»  Contrôle de qualité»  Service des achats»  Fournisseurs»  Etc.

Ø 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!)



10

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

?



11

Une Approche d’ingénierie simultanée des systèmes(Concurrent Engineering)

§  Étapes (selon une des approches possibles) du processus moderne de conception des systèmes complexes•  Focalisation de l’équipe•  Planification du projet•  Développement de la base de référence (baseline) •  Développement des sous-systèmes (allocated baseline)•  Définition des performances•  Vérification des performances•  Intégration des sous-systèmes•  Support à la production



12

Etape 1

Focalisation de l’équipe de design



13

Etape 1: Focalisation de l’équipe de design

§  Activités de cette étape:•  (*)Etablir les rôles et les responsabilités de chaque membre

de l’équipe•  (*)Concevoir un diagramme de contexte décrivant l’essence

du système à réaliser•  (*)Utiliser le concept de DPF (Description des Propriétés

Fonctionnelles) pour établir clairement les exigences du client et la proposition de l’équipe de développement (le fournisseur) pour répondre à ces exigences

•  Concevoir des diagrammes de Kano pour maximiser les 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)



14

Etape 1 – Diagramme de contexte

§  Diagramme de contexte:•  Isole le système du reste de l’univers•  Nomme le système•  Cache les parties internes au système•  Met en évidence les entrées fournies au système et les actions

effectuées par celui-ci en forçant leur identification et leur définition•  Rend la fonctionnalité principale du système évidente•  Permet de vérifier avec le client l’exactitude de la compréhension

du problème par l’équipe de design•  Plusieurs itérations sont nécessaires pour arriver à un diagramme

complet. Des révisions sont nécessaires (et bénéfiques).•  Exemple de diagramme de contexte pour la conception d’un

système d’alarme



15

Etape 1 – Concept de DPF (1/6)

§  Description des propriétés fonctionnelles (DPF):

•  Une DPF est un outil utile pour formuler un problème

•  La DPF focalise l’équipe sur les exigences et les attentes 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ètres critiques (PC) associés à chaque fonctionnalité

•  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. 42.


Très Important


Étape 1… – Fonctionnalités (2/6)

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

•  Les fonctionnalités sont les actions que le système doit prendre pour rencontrer les exigences du clientØ n’ont aucun volume, aucune masse et ne sont pas « visibles »Ø commencent par un verbe d’action suivi de noms

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



17

Etape 1 – Comment concevoir une DPF (3/6)

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

§  Remue-méninges sur les exigences du client§  Classer les exigences en ordre de priorité§  Remue-méninges sur les forces de la compagnie et sur les

fonctionnalités requises pour le produit§  Organiser ces fonctionnalités en catégories (et leur associer les

paramètres critiques si nécessaire)§  Construire une matrice de relations entre les exigences du

client et les fonctionnalités§  Estimer grossièrement les valeurs souhaitées de performance

pour les fonctionnalités (cette étape n’est pas couverte en Design III)



18


Structure d’uneDPF

Matricede

couplage

Fonctionnalités nécessaires poursatisfaire les exigences

Exigencesdu

client

Matrice derelations

Quoi?

Comment?

Combien?

Estimation des avantagescompétitifs

Perception

du

client

Catégorie 1 Catégorie 2Fonct. 1

Paramètres critiquesFonct. 2

Paramètres critiques

Exigence 1Exigence 2

Fonct. 1 Fonct. 2

2 5

Nombre entre0 et 5 estimantla dépendanceentre une exigenceet une fonctionnalité

Voir matricede couplagepage suivante



19


Cat. 1Fonct. 1

Fonct. 2

Fonct. 1

Fonct. 2

Cat. 1 Cat 2

Fonc

t. 1

Fonc

t. 2

Fonc

t. 1

Fonc

t. 2

Matrice de couplage



20


Dans les systèmes complexes pour lesquels le projet doit tenir compte de la fabrication, les fonctionnalités d’une étape deviennent les exigences de l’étape suivante

Besoins duclient Usine

Planificationdu

produit

Design Planification duprocessus

Planification desopérations



Étape 1 – Exemples

§  (*)Exemple de Diagramme des propriétés fonctionnelles pour le système d’alarme

§  Exemple de Matrice de couplage pour le système d’alarme



22

Etape 1 – Construction de diagrammes de Kano

§  Les diagrammes de Kano permettent d’identifier le design gagnant auprès du client.

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

§  Ce niveau de satisfaction se trace pour trois cas:•  Caractéristiques obligatoires•  Caractéristiques obligatoires améliorées et

caractéristiques optionnelles mineures•  Caractéristiques optionnelles majeures



23

Etape 2

Planification du projet



24

Etape 2: Planification du projet

§  Principaux buts de cette étape•  Identifier et documenter les tâches techniques qui doivent

être implantées pour mener à un projet fonctionnel•  Identifier et documenter les paramètres critiques qui

assurent le bon fonctionnement du projet§  Approche pour la planification du projet

•  (*)Développement d’un plan de gestion intégré (PGI) (réalisé en partie dans Design III)

•  (*)Développement d’un diagramme de flux des activités techniques (Gantt Chart)

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



25

Etape 2 – Plan de Gestion Intégré (PGI) (1/3)

§  Le PGI est formé des éléments suivants:•  Une description de haut niveau du projet

Ø Liste des biens livrables critiques avec étapes importantesØ Description des biens livrablesØ Liste des objectifs à long terme (par rapport à la gamme des

produits déjà supportés par l’entreprise)Ø Diagramme PERT (Program Evaluation Review Technique) au

niveau système•  Un arbre des plans de haut niveau

Ø (*)Matériel (description des prototypes) Ø (*)Logiciel (diagramme de séquences, diagramme de classes, cas

d’utilisation)Ø Description technique du système



26

Etape 2 – Plan de Gestion Intégré (2/3)

§  PGI (suite)•  Une Structure de découpage du projet (Work Breakdown

Structure WBS)Ø (*)Identification des coûts de fabrication (factures pour Design

III ne dépassant pas le montant fixé)Ø Budget préliminaire, liste des sources de financement

•  Un plan d’utilisation des ressources en personnelØ Prévisions des besoins en personnel (en jours/personne)Ø Identification des ressources critiquesØ Identification des rôles

•  Une liste des risques potentiels initiaux, stockée dans le registre de risques (risk register)



27

Etape 2 – Plan de Gestion Intégré (3/3)

§  PGI (suite)•  Liste des interdépendances entre les différents programmes

en cours de développement •  Plan préliminaire de support au développement:

Ø 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Ø Plan de santé et sécurité



28

Etape 2 – Diagramme de Gantt et Structure de découpage du projet (1/3)

§  Le diagramme de Gantt représente une description graphique:

•  Du déroulement des tâches du projet dans le temps•  Des liens entre les tâches et des contraintes imposées par

certaines tâches sur d’autres tâches•  Des ressources humaines affectées à l’exécution des

tâches•  (*) Du temps consacré par ressource (feuilles de temps en Design III)

•  Du coût associé à l’exécution des tâches



29


§  Les tâches dans le diagramme de Gantt:

•  sont en liens directs avec les fonctionnalités retrouvées dans la DPF

•  incluent éventuellement les phases d’intégration des fonctionnalités en suivant la chronologie présentée par le plan d’intégration

•  contiennent aussi la planification des réunions de l’équipe et les items des 4 biens livrables



30


§  La structure de découpage du projet (Work Breakdown Structure - WBS) illustre de manière différente les tâches montrées dans le diagramme de Gantt•  Les tâches sont regroupées en classes propres à différents

types d’activités (rapports, conception, etc)•  Les tâches sont illustrées en termes de blocs de travail sans

lien avec la distribution temporelle sur laquelle elles seront exécutées

•  Par phases de développement ou par livrables•  En général, le client paie sur les tâches complétées (i.e. un

work unit correspondant à une case du WBS), à condition qu’elles soient effectuées dans les temps prévus




Etape 2 – Exemple Gantt et WBS (3/3)


32

Etape 3

Développement de la base de référence du système (baseline)



33

Etape 3: Définition de la base de référence du système

§  La base de référence du système comprend les éléments suivants:•  (*)Diagramme des fonctionnalités du système•  (*)Diagramme physique du système•  Spécifications pour le système•  Spécifications de l’interface du système•  (*)Registre de risque et plan de contingence face au risque•  Liste de compromis (Matrice de Pugh)•  Modèle de simulation du système•  Liste des technologies critiques•  Identification des fournisseurs principaux•  Identification des installations principales de test et de

fabrication



34

Etape 3 – Diagramme des fonctionnalités

§  Diagramme des fonctionnalités•  Segmentation du système en fonctionnalités que l’on

retrouve dans la DPF, sans considération de leur implantation physique

•  Montre les relations entre les fonctionnalités (i.e. les influences entre fonctionnalités et non entre les signaux: la fonctionnalité 1 est reliée à la fonctionnalité 2 si elle a besoin de la fonctionnalité 1 pour être opérationnelle.)

•  Les différentes entrées et sorties du système du diagramme de contexte, y apparaissent aussi

•  N’est pas un diagramme de flux des actions (« flowchart »)•  Rappel : Les fonctionnalités sont les actions que le

système doit prendre pour rencontrer les exigences du client



35

Etape 3 – Diagramme physique (1/2)

§  Diagramme physique du système•  Disposition des fonctionnalités identifiées dans le

diagramme des fonctionnalités, en un assemblage de modules (ou sous-systèmes)

•  Les fonctionnalités devront être accomplies par des dispositifs physiques réels (cela peut être un ordinateur, un micro-contrôleur, ou un FPGA pour le logiciel)

•  La conception (design) du système consiste à effectuer un mapping des fonctionnalités («que doit accomplir le système ») vers les modules formés de dispositifs matériels/logiciels permettant d’implanter celles-ci (« que faut-il faire pour accomplir ces actions »)



36

Etape 3 – Diagramme physique (2/2)

§  Un module peut implanter une ou plusieurs fonctionnalités ou seulement une fraction de fonctionnalité

§  Une matrice est utile pour illustrer le mapping entre les fonctionnalités et les modules avec leurs dispositifs physiques

§  Un mapping 1à 1 entre les fonctionnalités et les modules physiques est hautement souhaitable parce que cela:Ø  Simplifie la préparation des spécificationsØ  Simplifie les procédures de testØ  Simplifie la spécification et l’implantation des interfacesØ  Facilite la mise-à-niveau (« upgrade ») du systèmeØ  Facilite le découpage du travail

§  Les parties matérielles/logicielles complexes sont décomposées en sous-parties plus simples



37

Etape 3 – Exemples

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

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



38

Etape 3 – Spécifications (1/7)

§  Guide de préparation des spécifications.Une spécification définit ce qui doit être atteint en termes de paramètres critiques du systèmes:•  Définir l’utilité de la spécification•  Suivre les standards appropriés (MIL-STD-490 hardware, MIL-

STD-498 software) s’ils existent•  Réfléchir attentivement à la spécification et à sa portée (scope)



39


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

•  Interfaces•  Diagramme physique•  Diagramme des fonctionnalités•  Description des modes

d’utilisation du système•  Matrice de vérification

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


§  Définir l’utilité de la spec§  Raffiner le modèle des

spécifications au besoin§  Préparer l’arbre des

spécifications du projet§  Nommer un responsable du

document des spécifications



Arbre des spécifications:§  permet de visionner l'ensemble des opérations appliquées à

un objet§  montre les dépendances entre les spécifications §  fournit une description hiérarchique des différentes

spécifications d’un système en développement



Etape 3 – Spécifications (3b/7)


§ Logiciel pour réaliser un arbre des spécifications


42


§  Termes à utiliser:•  Inscrire TBR (To Be Revised)

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

•  Inscrire TBD (To Be Defined) quand la valeur de la spec est inconnue et qu’une estimation ne peut être faite lors de l’écriture (ex. la couleur du revêtement du boîtier du système d’alarme)

•  Minimiser le nombre de TBR et TBD

•  Inclure les limites et le domaine de variation de la spec (ex. le système d’alarme doit pouvoir fonctionner entre +40°C et -40°C)

§  Ecrire les spécifications clairement•  Toutes les exigences

doivent être nécessaires•  La spec doit définir ce qui

doit être atteint et non comment l’atteindre

•  Chaque spec devrait être indépendante des autres

•  Décrire la spec en un seul paragraphe

•  Le système doit être en mesure d’atteindre la spec

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



43


§  Les spécifications portant sur les performances obligatoires doivent utiliser le mot « doit » (shall) dans leur définition

§  Les spécifications portant sur les performances non-obligatoires doivent utiliser le mot « devrait » (should) dans leur définition

§  Le mot « devra » (will) ne doit être utilisé que pour exprimer une déclaration, mais ne doit jamais apparaître dans la définition d’une spécification

§  Les versions de la rédaction des spécifications devraient être soumises à des révisions par les pairs

§  Les spécifications peuvent être rédigées pour les sous-systèmes (ou les modules), ce qui rend leur performances plus claires que si l’on tente de les déduire à partir des spécifications de chacune de leurs composantes



44


§  Garder les spécifications 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

•  Une spécification non atteinte = échec de la conception



45


§  Ne pas rédiger les specs avant que:•  L’analyse soit complétée sur

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

•  Le rôle de la spécification soit compris par tous les intervenants

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

§  Ne pas inclure de solutions de design dans la description de la spec

§  Ne pas documenter inutilement

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



Design III, c’est…



47

Etape 3 – La gestion du risque (1/8)

§  Gestion du risque

•  Comprendre ce qu’est le risque•  Comprendre comment aborder le risque (notion de risk

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

register)



48


§  Qu’est-ce que le risque?

•  Probabilité qu’un événement indésirable se produise•  Ne doit pas être confondu avec une mauvaise conception

•  Conséquences de l’occurrence d’un événement indésirable•  Conséquences d’un choix de conception intéressant mais

novateur (expérience limitée avec cette technologie, technologie immature)



49


§  Aspects du risque à considérer

•  Aspects relatifs aux performances techniques du système face aux spécifications attendues

•  Aspects relatifs à l’environnement de développement du système (ressources, sous-contracteurs, fournisseurs)

•  Aspects relatifs au support (entretien, formation)•  Aspects relatifs au coût•  Aspects relatifs à l’échéancier



50


§  Attitudes dangereuses face au risque:•  Ignorance (jouer à l’autruche)•  Nier son existence en adoptant des échéanciers optimistes•  Faire de la rétention d’information

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

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



51


§  Attitudes positives face au risque:•  Etre honnête et ne rien cacher•  Etre objectif et utiliser des faits concrets plutôt que des

impressions pour identifier les risques•  Diffusion de l’information•  Justification claire des décisions•  Calculer correctement l’estimation des risques



52


§  Approches de prise en compte du risque•  (*)Faire un registre de risques

Ø Liste des risques identifiésØ Association d’un niveau de priorité à chaque risqueØ Estimation du niveau de vraisemblance d’occurrence du risqueØ Estimation des conséquences de la présence du risque en

termes de coûts directs et indirects, de même qu’en termes de délais et de dégradation des performances du système

Ø Stratégies de réduction des risques (plan de contingence)Ø Identification de la personne responsable de gérer le risque

jusqu’à son élimination•  Exemple d’un registre de risques pour le système d’alarme



53


§  Approches de prise en compte du risque (suite)•  Établir la liste des risques (stockée dans le registre) dès la

préparation de la proposition du projet (c.f. Plan Gestion Intégré).•  Établir une liste de critères selon lesquels les décisions sur

chaque risque sont prises•  Le chef de projet crée, revoie régulièrement et met à jour le

registre de risques•  La stratégie de réduction des risques doit faire partie du

budget et de l’échéancier du projet•  Le budget 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

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



54

Etape 3 – La gestion du risque (8/8)§  La matrice de Pugh est un bon moyen de réduire les

risques de choix de conception.§  Pour construire la matrice de Pugh:

•  Un concept est choisi comme référence (benchmark)•  Des concepts alternatifs sont comparés au concept de

référence selon des critères clairement établis

Matrice de PughFonctionnalité Concept référence

Détecter une intrusion Détecteur mouvement IR Détecteur Mouvement laser -1Détecteur ouverture magnétique Détecteur ouverture mécanique 0

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

Alimenter le système Pile 9 volts Secteur 1

Avantage global -1

Concept alternatif 1

Nombre entre-5 et +5



55

Etape 4

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



56

Etape 4: Développement des sous-systèmes (1/2) §  Cette étape consiste à:

•  Développer le partitionnement optimal des sous-systèmes•  Définir et documenter les exigences (requirements)

requises pour Ø chaque sous-système aux niveaux matériel et logicielØ des interfaces entre les sous-systèmes

•  Établir les spécifications pourØ chaque sous-système aux niveaux matériel et logicielØ des interfaces entre les sous-systèmes

•  Concevoir les diagrammes-blocs des sous-systèmes (matériel et logiciel — potentiellement en UML)



Etape 4: Développement des sous-systèmes (2/2)

§  Les principes vus précédemment pour le développement de la base de référence du système s’appliquent maintenant à chaque sous-système

•  Diagramme des fonctionnalités des sous-systèmes•  Diagramme physique des sous-systèmes•  Spécifications pour les sous-système et leurs interfaces

(paramètres critiques dans la DPF)•  Gestion du risque



58

Etape 5

Définition des performances du système



59

Etape 5: Définition des performances du système (1/2)

§  Principaux buts:•  Développer des outils permettant de prédire les

performances du système et des sous-systèmes•  Définir la méthodologie pertinente à la vérification de

chaque performance du système•  Observer le niveau de performance de certains paramètres

critiques qui apparaissent dans la DPF, tout au long du processus de design, notamment lorsØ de changements ou Ø du choix de concepts alternatifs pour réduire les risques.



60

Etape 5: Définition des performances du système (2/2)

§  La définition des performances du système est accomplie à l’aide des éléments suivants:•  simulations/modélisations pour les sous-systèmes et

le système complet•  (*)matrice de vérification des exigences•  mesures de performances techniques (MPT) de certains

indicateurs clés, observés et suivis



61

Etape 5 – Vérification des exigences (1/3)

§  (*)Matrice de vérification des exigences

Identifie le niveau (et sous-niveau) pour lequel les vérifications seront effectuées (module ou sous-système)•  Identifie les paramètres critiques indiqués dans la DPF,

qui seront observés•  Identifie la méthode retenue pour vérifier chaque exigence

(inspection, test, démonstration, analyse, différence/similitude)



Design III, c’est…



63

Etape 5 – Vérification des exigences (2/3)

§  Méthodes de vérification:

•  Démonstration: vérification de la fonctionnalité du matériel ou du logiciel en fonctionnement sans faire appel à des mesures ou outils de test (le comportement est celui désiré)

•  Inspection: vérification qui repose sur les sens humains (e.g. vision ou manipulation) pour l’ajustement et la configuration du matériel ou du logiciel (regarder la pièce pour vérifier qu’elle est de la bonne couleur)

•  Similitude: vérifie le respect des exigences en se basant sur l’utilisation garantie de composantes similaires dans des conditions identiques ou plus sévères (diode utilisée est la même que dans un design similaire)



Étape 6 – Vérification des exigences (3/3)

§  Méthodes de vérification (suite)•  Test: utilise des techniques (potentiellement sophistiquées) pour

vérifier les performances de manière directe ou indirecte (utiliser un interféromètre pour vérifier la courbure d’une surface). Des e ́quipements de tests, standard ou spe ́cifiques sont habituellement requis. Une proce ́dure est a ̀ e ́tablir (voir Plan de test)

•  Analyse: vérification par calcul sans intervention aucune sur le produit. Les techniques employe ́es sont la mode ́lisation, la simulation, la pre ́diction. Peut demander l’analyse de données expérimentales recueillies lors de mesures spécifiques (lors d’autres tests par exemple par le biais d’une équation).

§  (*)Exemple de matrice de vérification des exigences du système d’alarme



65

Etape 5 – Mesure de performances techniques (1/3)

§  mesure de performances techniques (MPT)?•  Indicateur clé de performances (KPI-Key Performance Indicator)

du système ou de l’un de ses sous-systèmesØ Valeur attendueØ Marge de sécuritéØ Variations (entre la mesure et la valeur attendue)

•  Choisie parmi un ou des paramètres critiques de la DPF§  La MPT est observée périodiquement (par exemple

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

§  Exemple d’une MPT (tension d’alimentation) pour le système d’alarme



66


§  Avantages associés à l’utilisation des MPT:•  Permet de visualiser l’historique des performances par

rapport aux performances spécifiées•  Permet la prédiction et la détection hâtives des problèmes•  Permet de suivre les « zones » à risque du projet•  Documente les principales hypothèses techniques et la

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



67


§  Méthodologie de génération des MPT:•  Identifier les paramètres critiques à suivre (à partir de la

matrice DPF)Pour chaque paramètre critique identifié:•  Identifier les spécifications et les valeurs-cibles•  Déterminer les valeurs de performances présentes par

modélisation, simulation, analyse, estimation ou mesure•  Tracer l’évolution temporelle de ces valeurs de

performances pour analyser les tendances et prendre les actions nécessaires en cas de problème



68

Etape 6

Vérification des performances du système



69

Etape 6: Vérification des performances (1/2)§  Une fois les exigences attendues définies, il convient

de vérifier si les performances atteintes les respectent (« requirement compliance »)

§  Approche généralement adoptée:•  (*) planification des tests1

qui indique comment faire les vérifications•  (*) matrice de vérification des performances

qui identifie les exigences imposées (comme dans la matrice de vérification des exigences); mais elle donne en plus le résultat des vérifications d’après les tests effectués

1. Plan de test combiné avec matrice de vérification des exigences en Design III



70

Etape 6: Vérification des performances (2/2)

§  Objectifs de l’étape de vérification des performances:•  Développer la stratégie et la méthodologie de test et les

inclure dans le processus de design le plus tôt possible de manière à ce que les tests s’effectuent de manière optimale.

•  Développer la planification des tests pour le système complet

•  Documenter tous les tests importants des systèmes et sous-systèmes

•  Analyser les données des tests•  Assurer que les exigences principales identifiées dans la

matrice de vérification des exigences, seront vérifiées



71

Etape 6 – Planification des tests (1/6)

§  Objectifs de la planification des tests•  Développer les procédures de test, le processus d’analyse

des données des tests (nature, format, etc) et les logiciels d’analyse (type, nom, fournisseurs) en parallèle avec la conception du système

•  Développer les équipements de test en utilisant la même approche de conception que celle utilisée pour le système lui-même

•  Développer la procédure de support à l’équipe de test, et les approches de solution de problèmes (au cas où…)



72


§  Étapes de la planification des tests:•  Identifier les objectifs et définir les priorités afin de réduire

l’impact potentiel de conflits de ressources•  Identifier les paramètres critiques sujets à vérification et

ceux nécessitant des mesures en continue (MPT)•  Identifier les besoins en termes de données à recueillir

pour les tests§  Quantité de données en relation de la méthodologie de test§  Qualité des données (des données pour un test sans objet

sont inutiles… de mauvaises données pour un test pertinent sont également inutiles)



73


•  Développer la méthodologie de test (comment le système sera testé):Ø  Documenter, valider, et diffuser la méthodologie

(il se peut qu’un test soit impossible à effectuer parce que le paramètre d’intérêt est très difficile à mesurer)

Ø  Définir•  les conditions initiales d’exécution des tests,•  les conditions d’interruption (ne pas attendre que ça pète!), •  les conditions d’acceptation ou de rejet des résultats des tests

Ø  Réduire la dépendance de la méthodologie de test par rapport au reste de la documentation (la documentation des tests doit être autosuffisante autant que possible)

Ø  Préparer le plan d’analyse des données•  Déterminer le type de données à recueillir•  Définir les procédures d’analyse de même que les outils requis•  Valider les procédures d’analyse et les outils avant leur utilisation



74


§  Produits résultant de la planification des tests:•  (*) Plan de test1 du système (« Test Plan »)

Ø  Liste des paramètres à tester dans le systèmeØ  Méthodologie de test du système

•  déroulement des test•  conditions et décisions•  analyse des résultats

Ø  Liste des équipements de test de même que leurs spécifications

Ø  Gabarits pour le rapport des tests


1. Plan de test combiné avec matrice de vérification des exigences en Design III


75


§  Avantages offerts par la planification hâtive des tests:•  Permet d’ajuster/améliorer la conception pour faciliter les

tests•  Permet d’intégrer les tests à la procédure de vérification•  Permet d’identifier/concevoir les montages matériels de

même que les outils logiciels requis pour effectuer les tests•  Permet de définir la séquence des tests en fonction de la

séquence d’implantation du matériel et du logiciel qui est définie dans le Plan d’intégration

•  Permet de réduire les risques définis dans le Régistre de risques



76


§  Remarques générales sur la planification des tests•  La planification des tests devrait faire partie intégrante des

plans de développement d’un produit•  La planification des tests devrait être faite par des membres

appartenant à toutes les disciplines•  Des tests appropriés pour les sous-systèmes favorisent

les tests sur le système intégré•  Les équipements de tests devraient faire l’objet d’une

documentation complète•  La conduite des tests est un élément important du budget

pour les systèmes complexes (par exemple les systèmes pour l’exploration spatiale)



77

Etape 6: Vérification (suite)

§  (*) Matrice de vérification des performances•  Donne les performances pour toutes les exigences

(requirements) listées dans la matrice de vérification des exigences, selon la procédure indiquée dans le plan de test

•  Montre si la conception atteint le niveau de performance requis

•  Montre tôt dans le processus de conception si une performance n’est pas atteinte (« non-compliance ») et ainsi suivre le plan de repli pour faire face à ce problème.



78

Etape 6…(suite)

§  (*)Exemple de plan de test pour le système d’alarme§  (*)Exemple de

matrice de vérification des performances pour le système d’alarme



79

Etape 7

Intégration du système



80

Etape 7 Intégration du système

§  (*) Plan d’intégration•  sert de guide à l’intégration des différentes parties (sous-

systèmes du diagramme physique) du système complet•  définit les étapes d’intégration et leur ordonnancement

temporel•  est conçu tôt dans le processus de développement afin de

guider l’équipe et de permettre un suivi serré des étapes d’implantation

•  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 rigoureuse et complète de tests finaux

§  Exemple de plan d’intégration pour le système d’alarme



81

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



82




83




84

Documents importants...Documents à caractère technique

DiagrammeContexte

Descriptionpropriétés

fonctionnelles

Diagrammedes

fonctionnalités

Matricede Pugh

Diagrammephysique

Mesure desperformances

techniquesDiagrammes-P

Matrice devérification des

exigences

Matrice devérification desperformances

Design dusystème

Besoinsdu client



85

Documents importants...

Documents de planification et de gestion

Diagrammede Gantt WBS

Registrede risques

Plan detest

Pland'intégration


Structure de

découpage du projet


86

Design

Implantation

Intégration

Test

Analyse Approche séquentielle



87

Approche d’ingénierie simultanée

Opportunité

Définition etChoix de concept

Développement

Validation

Production

PDR

TRR

CDR

Proposition

Début

Gel progressif

Gel progressif

Gel progressif

Preliminary Design Review

Technical Readiness Review

Critical Design Review



88

Systèmed’alarme

07/09/2007

Design III – Système d’alarme – Diagramme de contexte

Sonner alarme

Emettre un signal sonored’amorçage/

désamorçage

Coded’amorçage/désamorçage

Identifier la source d’une alarme



Exemple de DPF pour le système d’alarme


Suite

Retour

Exigences du clientAfficher

provenanceAlimentersystème

Respecterstandards

Respecterfaiblecoût

Respecterapparence

Respecterentretienminimum

Délai CodeSignalsonore

Vitessemin

(m/s)

Vitessemax(m/s)

Taillemin(cm

Ouv.Min

(mm)

Tauxdét.(%)

deltaT(sec) nbDigits

Intensité(db) no

Intensité(db)

Tempsréponse

(sec)Durée(sec)

Valim(volts)

Détecte ouverture porte 5 5 3 5Détecte ouverture fenêtre 3 5 3 5Détecte mouvement 5 5 5 5Amorcage aveccode secret 4 5 3 3Désamorcage aveccode secret 4 5 3 3Emission signalsonore amorcage 3 2Emission signalsonore désamorcage 3 2

Déclenchement d'une alarmelors d'une intrusion 3 5 4 5Affichage de lasource de l'intrusion 5 1Apparence discrète 5Facilité d'entretien 3 5Standards nord-américains 5 5Faible coût 4 5

Déclencher alarme

Fonctionalités

Détecter ouverture

porte / Détecter mouvement

Détecter intrusion

Amorcer/désamorcer

système


Exemple de matrice de couplage pour le système d’alarme


Dét

ecte

r int

rusi

on

Amor

cer/D

ésam

orce

r

Affic

her p

rove

nanc

e

Déc

lenc

her a

larm

e

Alim

ente

r sys

tèm

e

Res

pect

er S

tand

ards

Res

pect

er fa

ible

coû

t

Res

pect

er a

ppar

ence

Res

pect

er e

ntre

tien

min

.

Détecter intrusion 5 2 3 5 4 2 3Amorcer/Désamorcer 5 4 2 3Afficher provenance 2 5 2 4 2 1Déclencher alarme 3 2 5 5 4 3 3Alimenter système 5 2 2 5 5 3 3 3Respecter Standards 3 5Respecter faible coût 4 4 4 4 3 5 4 3Respecter apparence 4 5 2Respecter entretien min. 3 3 1 3 3 3 2 5


91

Réa

ctio

n du

clie

nt

Caractéristiques

Neutre

Nég

ativ

eP

ositi

ve

Différents types de sonneries

Ajout de plusieurs codes secretsAjout de communication avec police

Possibilité d’alimenter le système avec des piles et avec le secteur

Système à piles seulement à l’intérieur du budget minimum

26/10/2004

Diagramme de KANO – Système d’alarme



Exemple de diagramme des fonctionnalités pour le système

d’alarme AmorcerLe

système

DésamorcerLe

système

DétecterUne intrusion

Déclencher une alarme

AfficherUn site

D’intrusion

Code secret

Alarme Sonore Numéro site

Signal sonore

13/09/2007

Design III – Système d’alarmeDiagramme de fonctionalités

À noter que l’alimentationDu système n’est pas une fonctionnalité deCelui-ci. Par conséquent, elle n’apparaît pasDans le diagramme.



Exemple de diagramme physique pour le système d’alarme

13/09/2007

Design III – Système d’alarmeDiagramme physique

Code secret

Micro-contrôleur8051

Lien

Par

allè

le

Affichage LCDLM018L

Lien Parallèle

Bus

Dét. ContactXP-23

Dét. ContactXP-23

Dét. MvtXP-112

Dét. MvtXP-112

Numéro site

Sirène

Conv. N-A

Ampli OP Alarme Sonore

Haut-parleur Signal sonore

MémoireClavier

HP-8263

Alimentation

LogicielVoir diagramme de classes dansFichier alarmSystem.tpr

DétecterUne

intrusion

AmorcerLe

système

DésamorcerLe

système

AfficherUn site

D’intrusion

DétecterUne

intrusion



94

Exemple de registre de risquespour le système d’alarme



95

Exemple de matrice de vérification des exigencespour le système d’alarme

Document Niveau Sous-niveau Exigence NSP Méthode de vérification CommentairesDPF Détecter intrusion Détecter mouvement Vmin (m/s) Test

Vmax (m/s) TestTaille min (cm cube) Test

Détecter ouverture Ouverture min. (mm) TestTaux détection (%) Démonstration Essayer 100 fois et voir le nombre de

succès

DPF Amorcer/désamorcer Délai deltaT (sec) TestCode nbDigits Démonstration Faire fonctionner le systèmeSignal sonore Intensite (db) Test

DPF Affichage source no Inspection

Paramètre critique


fonctionnalité sous-fonctionnalité


96

27/01/2005

Design III – Système d’alarmeMPT

MPT: Tension d’alimentation

Tens

ion

TempsLivrable 1 Livrable 2 Livrable 3

15

Spécification

} Zone deVariation permise



97

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'analyseDétecter intrusion Détecter mouvement Vmin Test Chronomètre

Ruban à mesurerSource d'alimentationDétecteur XP-112Oscilloscope numériqueUn passant

Vmax Test ChronomètreRuban à mesurerSource d'alimentation 5 vDétecteur XP-112Oscilloscope numériqueUn passant

Taille Test Règle Mesurer dimensionsDétecter ouverture Ouverture min Test Détecteur Contact XP-23

Source alimentation 5 vVernier de déplacement linéaireSystème de fixation du détecteur et du vernierSpreadsheet

Amorcer/Désamorcer…

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

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

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


Param critiquefonctionnalité sous-fonctionnalité


98

Exemple de matrice de vérification des performancespour le système d’alarme

Document Niveau Sous-niveau Exigence NSP Méthode de vérification Spécification Performance Marge CommentairesDPF Détecter intrusion Détecter mouvement Vmin (m/s) Test 0.50+/-0.1 0.52+/-0.1 0.02

Vmax (m/s) Test 1.5+/-0.1 1.6+/-0.2 0.1Taille min (cm cube) Test 12 10 2

Détecter ouverture Ouverture min. (mm) Test 1 1 0Taux détection (%) Démonstration 98% 99% 1%

DPF Amorcer/désamorcer Délai deltaT (sec) Test 1.5 1 0.5Code nbDigits Démonstration 4 4 -

Signal sonore Intensite (db) Test 10 9.8 -0,2

Malgré que la spécificationne soit pas rencontrée, on constate que l'alarme est audible de très loin et qu ele niveau est parconséquent suffisant

DPF Affichage source no InspectionDans les cas détectés,le numéro est toujours exact

Param. critique


sous-fonctionnalitéfonctionnalit

é


99

Exemple de plan d’intégration pour le système d’alarme

AfficherUn site

d’intrusion

Déclencheralarme

Détecterintrusion

Amorcer/désamorcer

SystèmeD’alarme

Alimenter

Phase 1

Phase 2

Phase 3


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

Documents

Transcript of Ingénierie des systèmes complexes Méthodologie de...