METHODES / METHODS > Analyse fonctionnelle (Méthode APTE) et SysML

JOURNAL-NEWS
 
CYCLES ROUTES
CYCLE ROUTES 09-10
CYCLE ROUTES 10-11
CYCLE ROUTES 2010
LE CESROUTE DE 1997 à 2009

METHODES / METHODS
A- ACTUALITES / NEWS
B- DEMARCHES / APPROACHES
C- PROCESSUS / PROCESS
D- REFERENCES
E- Formations en support de ces méthodologies
F- Les logiciels supports de ces méthodologies et processus

CYCLES INTERNATIONAUX / INTERNATIONAL SEMINARS
Česky
Arabia - عربية
Bahasa Malaysia
Balgarski
Deutsch
Eesti
English
Español
Français
Hanyu - 汉语
Italiano
Kokugo - 国語
Latviski
Lietuviskai
Magyar
Nederlands
Polski
Portugues
Româneste
Ruski - по русски
Slovensky

METRATECH
PARTENAIRES-PARTNERS
RESULTATS / RESULTS
TOURISME & VIE SOCIALE / TOURISM & SOCIAL LIFE

PUBLICATIONS
DOSSIERS PEDAGOGIQUES / PEDAGOGICAL FILES
PRESSES DE L’ENPC

SITE
Comment utiliser le site / How to use this site
Comment y participer / How to contribute

Analyse fonctionnelle (Méthode APTE) et SysML
(projet de texte)
mercredi 19 décembre 2012 , Catherine Laval


L’analyse fonctionnelle et une démarche de type SysML ne s’opposent pas mais se complètent !

Préalable : ce texte constitue un projet d’article, susceptible d’évolution et complément.

L’analyse fonctionnelle s’intéresse aux finalités du système et aux besoins et contraintes de toutes parties prenantes

Rappel : La notion de parties prenantes comprend les acteurs suivants
  - Les utilisateurs, à l’origine des besoins, et réels juges de la solution,
  - Les parties intéressées, contributeurs ou acteurs tout au long du processus de vie,
  - Les parties impliquées dans le projet (développement, réalisation, qualification…).

C’est l’analyse fonctionnelle qui apporte la base objective des exigences, à travers des notions qui lui sont propres, dont notamment :
  - Finalités et limites du système,
  - Cycle de vie, situations de vie,,..
  - Modes dégradés (en différenciant « conditions dégradées » et « modes défaillants »),
  - Besoins, contraintes, Fonctions, sous-fonctions, principes,…
  - Critères ou exigences, hiérarchisation,…

Dans un premier temps, elle se place en amont de toute modélisation du système lui-même (et s’attache essentiellement à ses interactions avec ses environnements tout au long de son cycle de vie).

En approche systémique, on parle alors de « boîte noire ».

Seule l’analyse fonctionnelle permet de balayer tout le cycle de vie d’un produit ou système, et d’étudier toutes ses interactions avec les éléments de son/ses environnements, ce qui garantit une certaine exhaustivité dans la recherche ou la validation des besoins et contraintes. Elle permet également d’éviter toute expression de besoin en terme de solution.

Dans un deuxième temps, en conception, elle facilite une recherche créative de principes de solutions, puis structure les logiques de choix et leurs justifications, jusqu’aux choix d’architecture. Elle recherche ainsi une réelle traçabilité entre exigences et concepts.

Couplée avec une démarche d’Analyse de la Valeur, elle permet d’optimiser un système, produit ou service en s’assurant, en amont de cerner les besoins et contraintes « juste nécessaires », et en aval de construire une réponse pertinente répondant aux besoins et contraintes, au moindre coût.

Couplée à une démarche de maîtrise des risques, elle permet l’exhaustivité de l’inventaire des modes de défaillance et une vision claire des conséquences des défaillances sur les services attendus et sur l’environnement (ou sur le projet lui-même).

C’est une méthodologie au sens propre du terme.

SysML est un « langage » de modélisation.

SysML se positionne en processus de développement, avec un point de vue industriel/concepteur (maitre d’œuvre), en réponse aux exigences du maître d’ouvrage (le maître d’ouvrage étant responsable de l’expression des besoins et contraintes des parties prenantes).

Ses données d’entrée sont essentiellement issues de l’analyse fonctionnelle (document d’entrée que l’on appelle « expression de besoin » ou « cahier des charges fonctionnel » ou « spécifications fonctionnelles » voire cahier des charges client », ou « exigences du maître d’ouvrage » ou « CCTP », ou autre dénomination selon secteur d’activité).

Nota : ce document d’entrée constitue la base du contrat de l’industriel vis-à-vis du maître d’ouvrage – on parle alors « d’exigences initiales ».

Sans ces données d’entrée (externes à SysML), les modélisations sous SysML ne peuvent être validées.

Le « diagramme d’exigences » sous SysML est une traduction, par l’industriel, des données de l’analyse fonctionnelle, par adoption d’un point de vue « conception système » - une déclinaison des exigences client en exigences fonctionnelles et techniques (spécifications techniques).


  - Il y a alors transcription, par le maître d’œuvre, des exigences initiales (issues de l’analyse fonctionnelle) sur un concept système donné, proposé par le maître d’œuvre et retenu par le maître d’ouvrage (concrètement, si un autre concept est retenu, cette transcription sera différente).


  - Cette traduction est complétée par d’autres types d’exigences, dites « exigences techniques » :

o Exigences liées au montage industriel retenu pour le développement et la réalisation du système (exigences d’interfaces entre plusieurs industriels, entre industriel et ses sous-traitants,…),

o Exigences liées aux propres contraintes de l’industriel (exigences techniques, financières, exigences de management,…),

o Voire modifications d’exigences initiales, relevant de compromis entre exigences ou de non-faisabilité technologique.


  - Ces exigences techniques sont proposées au maître d’ouvrage : leur validation les transforme en « spécifications » (ou exigences spécifiées).

Le diagramme d’exigences sous SysML (comme d’autres outils de traçabilité des exigences, de type DOORS) permet une représentation graphique et textuelle des exigences, de les hiérarchiser et ensuite de les associer aux éléments du modèle du système (par des liens de dépendance de type : « dérive de », « satisfait », « vérifie »,…).

SysML s’attache ensuite davantage à ce que l’on appelle en systémique une vue « boîte blanche » du système (vue interne, fonctionnement).

La partie exigences/spécifications ci-dessus fait le lien entre la vue « boite noire » (besoins, environnements) avec un concept de « boîte blanche ».

Les diagrammes « de cas d’utilisations » consistent à identifier les acteurs et les cas d’utilisations d’un point de vue utilisation du système (ou partie du système), et les interactions acteurs/système lors de ces utilisations.

Ainsi le terme « acteur » dans SysML (diagramme « cas d’utilisation ») ne différencie pas le fait qu’il s’agisse d’un utilisateur final ou d’un opérateur du système (d’un point de vue analyse fonctionnelle, l’utilisateur est celui pour lequel est créé le système, l’opérateur est un élément de la solution de système envisagé, c’est un « moyen » qui serait différent si l’on change de choix de conception pour le système).

Les objectifs d’autres diagrammes sous SysML illustrent également bien ce point de vue « interne » :

Diagrammes de comportement :
  - Diagramme « de séquences » : pour décrire chronologiquement « comment » s’enchaînent les fonctions élémentaires dans le temps, au sein du système. Un tel diagramme représente les éléments intervenant dans un scénario ou un processus, ainsi que les messages échangés cela dans un ordre chronologique.
  - Diagramme « Etats-Transitions » : pour décrire le comportement interne du système,
  - Diagramme « d’activité » : pour décrire l’enchaînement d’actions élémentaires lors d’une activité du système. Il représente les étapes d’un processus, avec els éléments requis en entrée d’une activité ou action, et les éléments générés en sortie (avec, notamment, les actions de contrôle des actions).

Diagrammes de structure :
  - Diagramme « de définition de bloc » : pour représenter le système sous forme de constituants hiérarchisés,
  - Diagramme « de bloc interne » : pour montrer comment se réalisent les liens entre blocs/constituants.

.. à poursuivre…

Catherine LAVAL

Société APTE System

2 rue GARREAU – 75018 PARIS

Tél : 01 42 51 21 70

Mob : 06 13 24 79 14

Fax : 01 42 51 61 31

catherine.laval@apte-system.com

répondre / to answer
   


COMMUNIQUE DE PRESSE : les logiciels TDC d’analyse fonctionnelle et AIRBUS
Témoignage de SANOFI AVENTIS sur TDC Need
Témoignage DEFONTAINE sur le logiciel TDC FMEA poru les études AMDEC
Témoignage du CIRAD sur l’utilisation de TDC Need
Définitions Secteur Médical
Témoignage d’un chargé de Prévention sur l’utilisation du logiciel TDC Sécurité
Témoignage SMI - KOYO sur le logiciel TDC FMEA - études AMDEC Produit / Process
Témoignage d’un enseignement sur l’utilisation de TDC Need
ICAM Nantes et les logiciels TDC & CreaTRIZ
Témoignage de Plastic Omnium sur l’utilisation de TDC FMEA




Home | Contact | Site | Plan | Admin