---
# System prepended metadata

title: Ligne de produit

---

# Ligne de produit

Hugo Questroy, Ayrwan Guillermo et Enzo Ledentu

___________________

Ensta Bretagne 




[TOC]

## Ingénierie d'application

### 1. Management de la configuration de de la personnalisation



#### 	1.1. Ingénierie des exigences de l'application

| id   | Provenance   | Exigence                                                     |
| ---- | ------------ | ------------------------------------------------------------ |
| 1    | Clients      | Les clients souhaitent un système de transport               |
| 2    | Clients      | Le système de transport doit être le moins volumineux possible |
| 3    | Clients      | Le système de transport doit garantir le transport du pédalo sans dégâts sur une route, dans un milieux sableux / aquatique |
| 4    | Clients      | Le système de transport doit aussi être utilisable en tant que système de stockage |
| 5    | Actionnaires | Le pédalo doit satisfaire les tests de sécurité avec un taux de réussite de plus de 96 % |
| 6    | Actionnaires | Le système de transport doit satisfaire des tests de sécurité en durée de vie, solidité et sécurité en cas d'accident de la route |



#### 1.2. Configuration des modèles de variabilité

| n° du modèle | Composant                                      |
| ------------ | ---------------------------------------------- |
| 1            | Réfrigérateur, GPS, siège confort, coque mer   |
| 2            | Toboggan, GPS, siège confort, coque mer        |
| 3            | Réfrigérateur, GPS, siège chauffant, coque mer |
| 4            | Toboggan, GPS, siège chauffant, coque mer      |
| 5 et plus    | Tout  sous ensemble d'un modèle ci-dessus      |

Ici nous voulons définir les exigences du processus de configuration des modèles de variabilité. 

L'architecture minimale se forme ainsi : châssis, coque, sièges, batterie et ecran.  Ces éléments sont donc considérés comme "mandatory". 

Pour certains éléments comme les sièges, le client aura le choix du type (chauffant ou non). 

Ensuite il y aura les éléments qui sont des "options" comme le GPS, le frigo, le tobboggan etc... 

Ces éléments sont donc optionnels dans le model de variabilité et certains éléments sont compatibles entre eux ou non. 



#### 1.3. Définition de l'architecture de l'application

L'architecture finale d'un produit est composée de son architecture minimale, à laquelle s'ajoute une configuration optionnelle comme définie au dessus.

L'architecture minimale se forme ainsi : châssis, coque, sièges classiques, volant, pédales, kit de survie, tableau de bord, système de stockage et transport. 

Ces composant sont de base à un état classique, mais peuvent êtres commandés sous des formes plus recherchés (coque mer, siège chauffant...), formant ainsi un des produit listé au dessus.



#### 1.4. Personnalisation et améliorations

Pour répondre aux différents besoins des produits que l'on a iplémenté, nous avons du modifier l'architecture de base et nous avons rajouté certains objets: 

- Une batterie haute capacité : qui est primordiale pour faire fonctionner le réfrigirateur et les sièges chauffant. 
- Un système wifi : En effet le modèle de GPS que nous avons séléctionné nécessite un système WIFI.
- Des hauts parleurs : Nous donnons le choix aux clients de choisir un GPS qui possède une voide de guidage. Ce GPS nécessite donc un système de hauts parleurs. 

Le service client sera proche des demandes et des constructeurs et pourra dans la mesure du possible gérer toutes les demandes de personnalisation du produit. 

Si un client arrive avec ses idées, qu'elles soient innovantes ou non, nous aurons les équipes compétentes pour écouter ces demandes et donc pour prendre en compte ces idées au niveau technique et au niveau du domaine. Si ces demandandes sont faisables, celà entrainerait des innovations qui n'étaient pas prévues au départ et qui élargiraient la gamme des possibles. C'est une grande aide pour continuer l'innovation de notre ligne de produit. 

Feature Diagram :  
![](https://i.imgur.com/5FDajvn.png)

Fichier .pl associé : 

```
productline(L):-
L=[F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14,F15,F16,F17,F18,F19,F20,F21,F22],
fd_domain(L,0,1),
% F1 = Pedalo , F2 = Connectivité , F3 = Media , F4 = Sièges , F5 = Tobogan
% F6 = Batterie , F7 = Réfrigirateur , F8 = Ecran , F9 = Coque
% F10 = 4G, F11 = Bluetooth , F12 = Wifi, F13 = GPS, F14 = HP
% F15 = Siege Confort , F16 = Siege Chauffant , F17 = Batterie Standard
% F18 = Batterie haute capacité , F19 = GPS Standard , F20 = GPS Parlant
% F21 = Coque Mer F22 = Coque Lac
F1 #= 1,
F1 #>= F2,
F1 #>= F3,
F1 #= F4,
F1 #>= F5,
F1 #= F6,
F1 #>= F7,
F1 #= F8,
F1 #= F9,
F2 #=< F10 + F11 + F12,
F3 #=< F13 + F14,
F4 #= F15 + F16,
F6 #= F17 + F18,
F13 #= F19 + F20,
F7 #==> F18,
F16 #==> F18,
F13 #==> F12,
F20 #==> F14,
F9 #= F21 + F22,
fd_labeling(L).

```

Et voici les résultats du solver : 
![Imgur](https://i.imgur.com/tIDytgW.png)

On a donc utilisé le logiciel GNU Prolog pour résoudre ce système et on a donc un total de 1860 produits possibles. 

### 2. Procédé de variabilité

Le procédé de variabilité se déroule en 4 étapes : 

La première étape est d'identifier les variabilités possibles : 

Par exemple plusieurs types de GPS peuvent correspondrent à la demande d'un GPS.

La deuxième étape est de délimiter les variabilités : Combien de variabilités on autorise ? Quand est-ce qu'on choisi d'implementer cette variabilité ? Et peut-on oui ou non ajouter d'autres elements associés à cet variabilité?

Ici le GPS serait alors le "variation point " et une des alternative serait un GPS basique, l'autre alternative est un GPS avec voix.

La troisième étape est de choisir l'implémentation de cette variabilité. Cette implémentation dépend de quand on a choisi de l'implémenter. 

La dernière étape est de contrôler et de maintenir en place cette variabilité. Cette étape permet de constater l'évolution de la variabilité au fil du temps.