• 8 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 21/11/2019

Structurez votre démarche d’analyse

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Définissez les fonctions du système dans le contexte opérationnel

L'approche systémique et les données de marché nous donnent les informations sur le contexte applicatif de notre développement.

Sauf pour de très rares exceptions, tout ce que nous concevons crée de la valeur pour celui qui va l'utiliser, celui qui va le vendre, celui qui finance les développements. Cette valeur peut être financière mais pas uniquement ; elle peut :

  • permettre de créer ou de préserver de l'emploi ;

  • permettre de pénétrer de nouveaux secteurs économiques ou de créer une relation avec de nouveaux partenaires ;

  • permettre d'acquérir des connaissances nouvelles qui pourront servir par la suite sur de nouveaux sujets ;

  • améliorer notre propre image, permettre à des individus de se sentir mieux.

Autant de raisons qui font qu'il est fondamental de bien comprendre :

  • ce que nous avons à faire et pourquoi nous le faisons ;

  • quel est le sens de nos travaux ;

  • quel est l'état d'esprit et la volonté des parties prenantes du projet, de ceux qui nous demandent de faire quelque chose.

Ceci étant dit, nous devons à présent définir les fonctions de notre système dans leur contexte opérationnel. Nous devrons vérifier ensuite avec les parties prenantes à la fois la cohérence de la performance attendue par rapport au contexte d'emploi et la cohérence du besoin exprimé relativement aux vraies attentes.

Les besoins sont tout d'abord définis en grandes caractéristiques auxquelles le système doit répondre. Nous les exprimons dans le cadre opérationnel afin de vérifier leur intérêt.

Le partitionnement du besoin sous forme de "features" (caractéristiques principales) et de "user stories" est relativement efficace pour définir les éléments attendus de valeur. Le langage employé est celui de l'utilisateur, ce qui facilite la compréhension et les échanges.

Identifiez les “features” et “user stories”

Dans notre cas, les features peuvent concerner :

  • le déplacement (de l'engin) ;

  • la télémétrie (qui envoie de l'information à distance) ;

  • le télécontrôle (le pilotage à distance).

Les features correspondent à des grandes caractéristiques que nous allons demander de réaliser au calculateur que nous développons. Elles définissent son cadre de référence. Une feature peut également concerner le boîtier électronique lui-même, qui agrège les incréments de valeur du système physique à travers lequel s'opéreront les services applicatifs proposés. Ces features vont être ensuite précisées en éléments fonctionnels amenant une valeur d'usage à une partie prenante ou à l'équipe, à savoir les "user stories".

Pour illustrer simplement ces notions, abordons les aspects "télémétrie" :

Posons-nous la question : de quelles informations aimerions-nous pouvoir disposer à distance ?

  • état de santé des éléments du système de pilotage (pas de défaut, pas de panne) ;

  • position de l'engin dans le champ et sa cinématique (engin arrêté, engin en déplacement, par exemple) ;

  • état d'avancement de la mission courante (mission exécutée à 45 %, aucun incident de mission détecté, fin prévue à 17 h 12, par exemple).

Chaque service de haut niveau est ainsi découpé en fonctionnalités opérationnelles. La performance attendue de ces fonctionnalités est quantifiée afin de pouvoir être mesurable.

Prenons comme exemple le boîtier, et procédons de façon similaire à ce que vous avez vu lors de l'étape de prototypage rapide du boîtier du détecteur de fumée connecté, qui était pris comme cas d'étude dans le cours "Concevez un détecteur de fumée connecté".

Ce chapitre faisait mention de plusieurs stories possibles, décrivant les fonctionnalités attendues au cours de la montée en maturité du développement du détecteur.

Relisez ce chapitre pour en extraire les user stories possibles. Pour mémoire, nous rechercherons un statut opérationnel stable et fini à chaque fin de story. Notez que l'on va généralement rechercher à limiter le couplage entre les constituants pour favoriser leur potentielle réutilisation, faciliter leur maintenance et leur évolution.

Les acteurs en interaction avec les fonctionnalités décrites sont cités dans les stories pour étayer le cadre d'emploi. Nous pouvons ainsi interagir au cours du développement avec les vrais acteurs, et vérifier l'adéquation de ce qui est développé avec l'usage réel souhaité.

Ces fonctionnalités vont ensuite devoir être opérées sur un support physique. C'est là que l'analyse organique intervient.

Le résultat de cette analyse s'exprime sous forme de "stories techniques" ou de nouvelles user stories :

  • elles complètent les features et users stories précédentes ;

  • elles mentionnent des contraintes additionnelles à respecter ;

  • elles apportent des éléments quantitatifs attendus.

Contrairement au cas du détecteur de fumée, le produit à développer est un système embarqué industriel qui a pour objectif d'être à la fois fiable et réparable, fabriqué en série par lots de 100 pièces par an et d'une durée de vie de 15 ans. Le choix de l'architecture et des composants physiques doit être tout particulièrement soigné. Pour répondre aux besoins de fiabilité et de maintenance du produit sur une période aussi longue que 15 ans, des composants éprouvés sur des programmes similaires, non soumis à obsolescence, seront privilégiés.

Cette information peut, par exemple, s'exprimer sous la forme de user stories relatives à la feature "boîtier" :

"En tant qu'exploitant, je peux disposer de composants électroniques du boîtier déjà utilisés sur des programmes similaires, afin de favoriser l'obtention d'une performance opérationnelle minimale dans l'environnement d'emploi, et d'un soutien communautaire en cas de besoin".

Ou encore, on peut exprimer une autre story qui pourrait être :

"En tant que fabricant, je peux bénéficier de composants électroniques du boîtier non soumis à un avis d'obsolescence dans les 5 prochaines années, afin de pouvoir réaliser la fabrication et la réparation du boîtier".

Un des critères de diminution du risque est de choisir des composants :

  • pouvant s'approvisionner par plusieurs sources ;

  • étant fabriqués par des sociétés différentes ;

  • dans tous les cas, dont la courbe de vie n'est pas, dans la mesure du possible, trop au début.

Quelle serait pour vous, dans ce cas, une story envisageable?

En transverse de ces analyses, d'autres facteurs doivent être considérés.

Le choix des fabricants est un de ces facteurs à prendre en compte. En effet, nous sommes dans un schéma d'achat des composants en quantité (quelques centaines de pièces à produire par an) sur une période longue (15 ans). Nous devons, dans la mesure du possible, choisir des fabricants compatibles avec ce type de marché exigeant.

Le choix des distributeurs doit être compatible avec ces critères afin de pouvoir bénéficier de ces informations.

Choisissez les prestataires

Des critères similaires sont à prendre en compte dans le choix des prestataires qui rentrent dans la chaîne de fabrication du produit. Ils doivent être en mesure d'assurer la qualité des produits qu'ils fabriquent, avoir la capacité d'absorber notre charge d'activité et avoir l'assise économique et financière pour que le partenariat soit sur toute la durée du projet.

Là encore, en fonction de votre stratégie, il est bon de présélectionner 2 prestataires pour chaque élément à fabriquer puis, soit de séparer la production, soit d'avoir un prestataire principal et un prestataire en back-up.

Pour chaque bloc fonctionnel, les membres de l'équipe vont alors pouvoir croiser leurs critères techniques et non techniques pour définir les composants matériels et logiciels applicables. Concernant la fabrication des circuits imprimés, du câblage des cartes, la fabrication mécanique des éléments de packaging, une bonne connaissance des contraintes de fabrication de ces métiers est la garantie d'un coût de fabrication maîtrisé.

Toute story ne pouvant pas être réalisée dans la période de temps choisie (pour un sprint, généralement de 3 semaines) est appelée une "epic" du système (épopée).

L'ensemble des features, des epics et des premières stories ayant été définies, le travail va ensuite consister à définir collectivement la complexité relative à les réaliser par l'équipe, et à les prioriser en fonction du besoin des parties.

Synthèse et intérêts de l'approche

L'analyse préliminaire couvre l'ensemble des services attendus dans le cadre d'emploi du système embarqué.

  • Elle exprime de façon rigoureuse les besoins d'usage, les contraintes technologiques et environnementales.

  • Elle décrit les interfaces du système.

  • Elle mentionne le cadre normatif et réglementaire applicable.

  • Elle explique les livrables attendus et quand les obtenir de façon préférentielle.

La démarche que vous avez suivie jusqu'à présent a pour objectif de vous sensibiliser à l'ensemble des éléments à prendre en compte et à la manière de les mettre en œuvre.

Le travail de reformulation explicite des « features » et des « stories », réalisé en relation avec les acteurs du projet, les impliquera et limitera les risques.

  • Ce travail itératif vous amènera à augmenter votre périmètre d'analyse pour mieux définir ce qui sera conservé, de façon consciente et sans oubli majeur.

  • Vous pourrez ainsi vous adapter au mieux aux changements que vous rencontrerez en minimisant leur impact.

  • Vous augmenterez enfin la satisfaction de vos clients et limiterez des développements inutiles.

 

En résumé de la partie 1

Dans cette partie, nous avons poursuivi notre analyse du projet en précisant les fonctions que le système devait assurer dans son contexte opérationnel, selon une approche agile, dont nous avons souligné les intérêts.

Les chapitres de la partie suivante vont détailler les domaines métiers du cas d'étude. Nous prendrons leurs conclusions comme données d'entrée de la conception et de la réalisation du calculateur, que nous aborderons dans un chapitre ultérieur.

Exemple de certificat de réussite
Exemple de certificat de réussite