- Back
-
-{{< /highlight >}}
+```html
+Back
+```
And the unit test:
-{{< highlight js >}}
+```js
it('goes to the previous page when back button is clicked', () => {
- // mock goToPreviousPage method
- wrapper.vm.goToPreviousPage = jest.fn()
+ // mock goToPreviousPage method
+ wrapper.vm.goToPreviousPage = jest.fn();
- wrapper.find('.btn-arrow').trigger('click')
+ wrapper.find('.btn-arrow').trigger('click');
- expect(wrapper.vm.goToPreviousPage).toHaveBeenCalled()
-})
-{{< /highlight >}}
+ expect(wrapper.vm.goToPreviousPage).toHaveBeenCalled();
+});
+```
-Now we want to change the design by replacing `.btn-arrow` to `.btn-link` css class.
+Now we want to change the design by replacing `.btn-arrow` to `.btn-link` css class.
The design can also change by adding tag like `div`, `a`, `span` etc..
-{{< highlight html >}}
-
- Back
-
-{{< /highlight >}}
+```html
+Back
+```
But now, our test is red because the css selector is `undefined` while the functionality still works.
-## Solution
+## Solution
+
The solution to be resilient to this kind of changes is to introduce HTML `data-*` attributes in your DOM.
Let’s take the World Wide Web Consortium (W3C) definition:
@@ -57,13 +54,17 @@ Let’s take the World Wide Web Consortium (W3C) definition:
We can add to our HTML a `data-test` attribute to test our DOM.
-{{< highlight html >}}
-
- Back
+```html
+.
@@ -26,7 +26,7 @@ Pour illustrer notre propos, nous vous proposons l'exemple ci-dessous, un site e
Il est possible **dans notre exemple** d'organiser les choses de la façon suivante :
-- **Découper au niveau fonctionnel** l'état global que l'on souhaite partager. Exemple : ce qui concerne les articles, les commandes, les consommateurs, les livraisons…
+- **Découper au niveau fonctionnel** l'état global que l'on souhaite partagser. Exemple : ce qui concerne les articles, les commandes, les consommateurs, les livraisons…
- **Exposer des fonctions "utilitaires"** (sans notion métier) permettant l'accès et la modification de ces états. Cette partie n'est pas à négliger puisque le fonctionnement de Vue impose un certain [boilerplate](https://en.wikipedia.org/wiki/Boilerplate_code) lors de la mutation de l'état (cf [documentation](https://fr.vuejs.org/v2/guide/reactivity.html#Limitations-de-la-detection-de-changement)). Note : ces objets représentant généralement des collections d'éléments, on voit alors apparaître quelque chose qui ressemble beaucoup au pattern [Repository](https://martinfowler.com/eaaCatalog/repository.html).
- Enfin, les composants Vue n'ont plus qu'à **utiliser directement ces différent objects**.
@@ -47,71 +47,71 @@ Voilà ce que cela peut donner en terme de découpage :
Avec un `repository` [`inventory`](https://github.com/sogilis/Blog-vuex_alternative/blob/master/src/repositories/inventory.js) qui ressemble à ceci :
```javascript
-import api from "@/api";
+import api from '@/api';
export default {
- state: {
- products: []
- },
- add(product) {
- this.state.products.push(product);
- },
- async fetchProducts() {
- const newProducts = await api.fetchProducts();
- this.state.products = [];
- newProducts.forEach(product => this.add(product));
- },
- get productsCount() {
- return this.state.products.length;
- }
+ state: {
+ products: [],
+ },
+ add(product) {
+ this.state.products.push(product);
+ },
+ async fetchProducts() {
+ const newProducts = await api.fetchProducts();
+ this.state.products = [];
+ newProducts.forEach((product) => this.add(product));
+ },
+ get productsCount() {
+ return this.state.products.length;
+ },
};
```
Et voici le composant [``](https://github.com/sogilis/Blog-vuex_alternative/blob/master/src/components/Inventory.vue):
```javascript
-import Product from "./Product";
-import Alert from "@/components/Alert";
-import Inventory from "@/repositories/inventory";
+import Product from './Product';
+import Alert from '@/components/Alert';
+import Inventory from '@/repositories/inventory';
export default {
- name: "Inventory",
- components: { Product, Alert },
- data() {
- return {
- inventory: Inventory.state,
- isLoading: true
- };
- },
- computed: {
- productsCount() {
- return Inventory.productsCount;
- }
- },
- async mounted() {
- try {
- this.isLoading = true;
- await Inventory.fetchProducts();
- } finally {
- this.isLoading = false;
- }
- }
+ name: 'Inventory',
+ components: { Product, Alert },
+ data() {
+ return {
+ inventory: Inventory.state,
+ isLoading: true,
+ };
+ },
+ computed: {
+ productsCount() {
+ return Inventory.productsCount;
+ },
+ },
+ async mounted() {
+ try {
+ this.isLoading = true;
+ await Inventory.fetchProducts();
+ } finally {
+ this.isLoading = false;
+ }
+ },
};
```
Note : l'état doit être exposé aux composants Vue afin que ceux-ci puissent observer les changements et se mettre à jour le cas échéant. C'est une contrainte de cette solution, qu'il est facile de contourner en automatisant le processus pour tous les composants avec l'utilisation d'un [mixin](https://vuejs.org/v2/guide/mixins.html#Option-Merging) dans un plugin Vue :
```javascript
-import Products from "@/repositories/products";
+import Products from '@/repositories/products';
Vue.use({
- install: function(Vue) {
- Vue.mixin({
- data: function() {
- return { products: Products.state };
- }
- });
- }
+ install: function (Vue) {
+ Vue.mixin({
+ data: function () {
+ return { products: Products.state };
+ },
+ });
+ },
});
```
@@ -129,7 +129,7 @@ VueX nécessite d'avoir **2 modèles de données** :
- un modèle représentant l'état
Ceci n'est ni plus ni moins qu'une architecture [CQRS](https://www.martinfowler.com/bliki/CQRS.html).
-Au-delà de la complexité apportée par CQRS, ce pattern a quelques avantages, mais la plupart n'ont pas de sens côté front (ex: facilite l'event sourcing, la scalabilité horizontale…).
+Au-delà de la complexité apportée par CQRS, ce pattern a quelques avantagses, mais la plupart n'ont pas de sens côté front (ex: facilite l'event sourcing, la scalabilité horizontale…).
Avec la solution sans VueX, cette contrainte d'architecture n'existe plus, on peut alors **choisir l'architecture adaptée à notre besoin** (CQRS ou pas).
@@ -137,11 +137,11 @@ Avec la solution sans VueX, cette contrainte d'architecture n'existe plus, on pe
Une autre contrainte de VueX est l'utilisation de **modèle de programmation basé sur les événements**. En effet, [les mutateurs ne sont pas appelés directement](https://vuex.vuejs.org/guide/mutations.html#mutations), mais par l'intermédiaire d'événements qui sont publiés :
- 1. `store.commit('increment')` publie l'événement `increment`
- 2. Vuex va rechercher le ou les mutateur(s) associé(s) a cet événement
- 3. ces mutateurs sont exécutés
+1. `store.commit('increment')` publie l'événement `increment`
+2. Vuex va rechercher le ou les mutateur(s) associé(s) a cet événement
+3. ces mutateurs sont exécutés
-Encore une fois, ce modèle de programmation a des avantages, mais sont-ils pertinents sur une application front ?
+Encore une fois, ce modèle de programmation a des avantagses, mais sont-ils pertinents sur une application front ?
Toujours est-il que cela a un coût, et notamment au niveau de la navigabilité dans le code. En effet, les éditeurs et autres IDE ne permettent généralement pas de naviguer de `this.commit('increment')` vers les mutateurs associés, voir encore moins dans l'autre sens.
Cependant, certains plugins permettent de remédier à ce problème, mais il n'est pas certain de trouver le et les plugins adaptés qui résolve tous ces problèmes, et ce pour chaque éditeur / IDE et chaque language (JavaScript, TypeScript, etc.).
@@ -200,7 +200,7 @@ En somme, l'utilisation de VueX risque d'enfermer les développements dans une o
## Les points positifs de VueX
-Malgré les nombreux avantages à ne pas utiliser VueX, cette librairie peut dans certains cas s'avérer très intéressante :
+Malgré les nombreux avantagses à ne pas utiliser VueX, cette librairie peut dans certains cas s'avérer très intéressante :
### Aide au débogage avec Vue.js devtools
@@ -216,40 +216,40 @@ VueX impose un cadre, force une certaine architecture, ce qui peut aider une éq
Ah non, en fait, c'est faisable très facilement sans VueX :
```javascript
-import ShoppingCartTotalPrice from "./ShoppingCartTotalPrice";
+import ShoppingCartTotalPrice from './ShoppingCartTotalPrice';
export default {
- name: "ShoppingCart",
- components: { ShoppingCartTotalPrice },
- data() {
- return {
- shoppingCart: this.$shoppingCart.state
- };
- },
- computed: {
- totalPrice() {
- return this.$shoppingCart.getTotalPrice();
- }
- },
- methods: {
- remove(product) {
- this.$shoppingCart.remove(product);
- }
- }
+ name: 'ShoppingCart',
+ components: { ShoppingCartTotalPrice },
+ data() {
+ return {
+ shoppingCart: this.$shoppingCart.state,
+ };
+ },
+ computed: {
+ totalPrice() {
+ return this.$shoppingCart.getTotalPrice();
+ },
+ },
+ methods: {
+ remove(product) {
+ this.$shoppingCart.remove(product);
+ },
+ },
};
```
On peut noter que dans cet exemple, on accède au `repository` `ShoppingCart` par le biais d'un plugin.
-L'avantage est de ne pas importer le `repository` dans chaque composant :
+L'avantagse est de ne pas importer le `repository` dans chaque composant :
```javascript
-import shoppingCart from "@/repositories/shoppingCart";
-import Vue from "vue";
+import shoppingCart from '@/repositories/shoppingCart';
+import Vue from 'vue';
export const ShoppingCart = {
- install: function(Vue) {
- Vue.prototype.$shoppingCart = shoppingCart;
- }
+ install: function (Vue) {
+ Vue.prototype.$shoppingCart = shoppingCart;
+ },
};
Vue.use(ShoppingCart);
@@ -259,7 +259,7 @@ Vue.use(ShoppingCart);
Concrètement, nous avons vu qu'il était **possible de se passer de VueX**.
-En somme : plus grande simplicité du code, plus grande personnalisation de l'architecture, absence de dépendance à une librairie externe, pattern de programmation plus simple, navigabilité dans le code amélioré, moins de boilerplate pour les tests, tels sont les avantages de se passer de la bibliothèque VueX.
+En somme : plus grande simplicité du code, plus grande personnalisation de l'architecture, absence de dépendance à une librairie externe, pattern de programmation plus simple, navigabilité dans le code amélioré, moins de boilerplate pour les tests, tels sont les avantagses de se passer de la bibliothèque VueX.
Une question demeure : pourquoi VueX est-il si répandu ? Nous n'avons su trouver de réponse. Si vous utilisez VueX, donnez-nous les raisons qui vous ont poussées à l'utiliser, nous serions heureux d'en discuter.
@@ -267,4 +267,4 @@ Une question demeure : pourquoi VueX est-il si répandu ? Nous n'avons su trou
Cet article ne traite que de **Vue 2**.
-Avec [Vue 3.x](https://v3.vuejs.org), les objects js partagés entre composants doivent être encapsulés par [`Vue.observable()`](https://vuejs.org/v2/api/#Vue-observable).
+Avec [Vue 3.x](https://v3.vuejs.org), les objects js partagsés entre composants doivent être encapsulés par [`Vue.observable()`](https://vuejs.org/v2/api/#Vue-observable).
diff --git a/site/content/posts/2020-12-07-principes-caches-du-test.md b/blog/_posts/2020-12-07-principes-caches-du-test.md
similarity index 94%
rename from site/content/posts/2020-12-07-principes-caches-du-test.md
rename to blog/_posts/2020-12-07-principes-caches-du-test.md
index 712e8c2e9..62118a290 100644
--- a/site/content/posts/2020-12-07-principes-caches-du-test.md
+++ b/blog/_posts/2020-12-07-principes-caches-du-test.md
@@ -5,7 +5,7 @@ date: 2020-12-07
image: /img/2020-12-07-principes-caches-du-test.jpg
altimage: '"Ten" by Mark Bonica is licensed with CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/'
categories:
- - DÉVELOPPEMENT
+ - Développement logiciel
tags:
- test
---
@@ -44,7 +44,7 @@ L'inconvénient de la seconde solution, c'est qu'il reste encore du bruit dans l
Voilà ce que cela peut donner, en partant de ce test où la majorité du boilerplate est surligné :
-```go {linenos=inline,hl_lines=["3-12","19-25"]}
+```go{3-12,19-25}
func TestHeroDAO_ResurrectAllKnights(t *testing.T) {
// given
sql.Register("mysql", &MySQLDriver{})
@@ -77,7 +77,7 @@ func TestHeroDAO_ResurrectAllKnights(t *testing.T) {
En réduisant le boilerplate a l'extrême, on peut arriver à ceci :
-```go {linenos=inline}
+```go
func TestHeroDAO_ResurrectAllKnights(t *testing.T, heroDAO *HeroDAO) {
// given
dbtest.InsertDeadKnight("Bohort")
@@ -107,6 +107,7 @@ Certains outils, frameworks ou librairies peuvent limiter cette approche, oblige
Un nouveau développeur doit pouvoir comprendre rapidement le cas testé. Pourquoi ? Parce qu'un développeur passe beaucoup de temps à lire du code (notamment des tests), et le cas de test est finalement la première étape permettant de comprendre le code du test. C'est un peu comme n'importe quel sujet : on commence par assimiler les concepts globaux, puis on rentre de plus en plus dans les détails. Faire le chemin dans l'autre sens est plus difficile.
Et pour comprendre ce cas de test rapidement, il n'y a pas 36 solutions : il doit être décrit entièrement dans le code du test[^testcode]. Pas d'indirection, pas de logique cachée dans un autre fichier, etc. Après avoir lu ce code de test, le développeur doit être capable de répondre aux questions suivantes :
+
- quel cas veut-on tester ?
- quel est l'objet du test (la fonction testée) ?
- que veut-on vérifier ?
@@ -115,7 +116,7 @@ Et pour comprendre ce cas de test rapidement, il n'y a pas 36 solutions : il do
Prenons l'exemple suivant :
-```kotlin {linenos=inline}
+```kotlin
@Test
fun `/knights?dummy=true returns dummy knights`() {
mockMvc.perform(get("/knights?dummy=true"))
@@ -128,7 +129,7 @@ D'où sort ce chiffre `7`, ligne 5 ? Pourquoi 7 et pas 42 ? Le problème ici
Quelque chose comme cela aurait été plus limpide pour le lecteur :
-```kotlin {linenos=inline}
+```kotlin
@Test
fun `/knights returns dummy knights`() {
repeat(7) {
@@ -142,19 +143,19 @@ fun `/knights returns dummy knights`() {
Autre exemple :
-```javascript {linenos=inline}
+```javascript
describe('Excalibur', () => {
- it('changeBearer() returns sparkling excalibur when bearer has destiny', () => {
- const hero = buildHero();
- excalibur = buildExcalibur().changeBearer(hero)
- expect(excalibur.isSparkling).toBeTruthy();
- });
+ it('changeBearer() returns sparkling excalibur when bearer has destiny', () => {
+ const hero = buildHero();
+ excalibur = buildExcalibur().changeBearer(hero);
+ expect(excalibur.isSparkling).toBeTruthy();
+ });
});
```
En lisant ce code, on comprend que n'importe quel hero peut faire étinceler excalibur, alors que seuls ceux qui ont une destinée devraient pouvoir. Pourtant le test fonctionne puisque `buildHero()` retourne un héro ayant une destinée :
-```javascript {linenos=inline,hl_lines=["5"]}
+```javascript{5}
function buildHero() {
return {
id: 3,
@@ -166,7 +167,7 @@ function buildHero() {
Soit cette fonction `buildHero()` est mal nommée (et devrait s'appeler `buildHeroWithDetiny()`), soit il manque quelque chose dans le test (comme `hero.hasDestiny = true`).
-**Note :** ce principe allié au précédent n'est finalement que l'expression du principe ["Code at Wrong Level of Abstraction"](https://moderatemisbehaviour.github.io/clean-code-smells-and-heuristics/general/g6-code-at-wrong-level-of-abstraction.html) décrit dans *Clean Code*.
+**Note :** ce principe allié au précédent n'est finalement que l'expression du principe ["Code at Wrong Level of Abstraction"](https://moderatemisbehaviour.github.io/clean-code-smells-and-heuristics/general/g6-code-at-wrong-level-of-abstraction.html) décrit dans _Clean Code_.
## 3. Minimiser le jeu de données
@@ -243,6 +244,7 @@ void parseThrowsParseException() {
```
Le surcoût engendré par cette étape de refactoring peut être amorti :
+
- lorsque la même assertion doit être faite **fréquemment**
- avec l'utilisation d'une lib tierce, et si cette lib tierce est **bien testée** (il y a alors moins de risque de bug)
- l'utilisation d'une **lib tierce largement employée** dans l'écosystème permet d'améliorer la productivité des nouveaux dev (vu qu'il y a de bonnes chances qu'ils connaissent cette lib)
@@ -253,7 +255,7 @@ Le surcoût engendré par cette étape de refactoring peut être amorti :
Lors de l'écriture d'un test nécessitant un état particulier en **base de données**, l'utilisation de fixtures de test[^testfixture] peut se faire de différentes manières, mais toutes posent problème :
-- **Utiliser une fixture existante ?** Le jeu de données sera alors plus important que nécessaire, puisque partagé entre plusieurs tests qui requièrent chacun des données différentes. En cas de test en échec, l'investigation sera plus difficile, les données intéressantes étant polluées.
+- **Utiliser une fixture existante ?** Le jeu de données sera alors plus important que nécessaire, puisque partagsé entre plusieurs tests qui requièrent chacun des données différentes. En cas de test en échec, l'investigation sera plus difficile, les données intéressantes étant polluées.
- **Adapter une fixture existante ?** On prend alors le risque de casser un autre test qui utilise cette fixture car on ne sait pas quel élément de la fixture est important pour quel test.
- **Créer une nouvelle fixture ?** Multiplier les fixtures alourdit la modification du modèle de données.
@@ -279,5 +281,5 @@ Toujours est-il qu'en gardant en ligne de mire ces quelques principes, nous pouv
[^testcode]: le **code du test** est le code présent dans la fonction décrivant le test. On ne parle pas ici du code appelé indirectement.
[^boilerplate]: le mot **boilerplate** est utilisé ici pour décrire du code purement technique nécessaire au fonctionnement du test, mais ne portant aucune information sur le cas testé. Exemples : `TRUNCATE` de tables avant ou après le test, création d'utilisateur par défaut, instanciation d'une classe dont on teste une méthode…
-[^testlevel]: le **niveau d'un test** est lié à son périmètre, c'est-à-dire au code testé. Par analogie avec la *pyramide des tests*, plus le test est haut niveau, plus son périmètre est grand.
+[^testlevel]: le **niveau d'un test** est lié à son périmètre, c'est-à-dire au code testé. Par analogie avec la _pyramide des tests_, plus le test est haut niveau, plus son périmètre est grand.
[^testfixture]: une **fixture de test** est un jeu de données codé ou décrit en dur et utilisé par des tests
diff --git a/docs/prerequisites.md b/docs/prerequisites.md
deleted file mode 100644
index a769a7ea7..000000000
--- a/docs/prerequisites.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## Prerequisites
-
-## GNU Make.
-
-* For Linux, use your distro specific instructions
-* For Windows, see https://stackoverflow.com/questions/32127524/how-to-install-and-use-make-in-windows
- * Actually (at 2020-03-01) GNUWin32 is very outdated (2006), I advise
- you to use Chocolaty (it has built GNU Make from recent sources, as
- we can see in their "Package Source")
-* For mac users, it is installed by default
-
-## Docker
-
-See Docker [installation instruction](https://docs.docker.com/install/)
-
-* Disclaimer:
- * On Windows or Mac, installation of Docker could be
- complicated.
- * Use more disc space. It's not a fake affirmation.
- I've taken fill my free 50Go of disk space simply when I've tested
- several times to adapt the configuration of the current ./Dockerfile
- (you could run `docker system prune`).
- * Takes more resources
- * Build the website is incredibly more long especially if you want
- simply update `node_modules` when package.json is changed.
- With the method without docker, the upgrade with simply
- `yarn install` is very quick.
-* But if you won't install node and yarn in your environment because you
- hate this web tools, and if you have already Docker, it could be a
- solution interesting.
-* During the build, some files are created
- ( ./site/data/webpack.json , ./site/resources/_gen/ ).
- There owner are root. Could cause some problems when you use
- commands as not root user (rm, git, yarn).
- You must delete this file before with `sudo`. It's not cool.
- * Note: with the add of a dockerignore file, this issue should be
- solved.
diff --git a/docs/content-format.md b/docsOld/content-format.md
similarity index 99%
rename from docs/content-format.md
rename to docsOld/content-format.md
index b5464306c..71ed7d8b6 100644
--- a/docs/content-format.md
+++ b/docsOld/content-format.md
@@ -12,6 +12,7 @@ In addition, Hugo provides many [built in shortcodes](https://gohugo.io/content-
:warning: prefer `{linenos=inline}` (instead of `true` or `table`) if you need line number on code block (the stylesheet does not handle these values correctly).
If necessary, `Asciidoc` could be added quite easily. There are many things which prevent use to use this format today:
+
- add `asciidoctor` and mandatory dependency
- make sure `NetlifyCMS` can handle this format
- makre sure `Asciidoc` support is as expected
diff --git a/docs/dev.md b/docsOld/dev.md
similarity index 67%
rename from docs/dev.md
rename to docsOld/dev.md
index 18f1c561a..1d00a0154 100644
--- a/docs/dev.md
+++ b/docsOld/dev.md
@@ -3,6 +3,7 @@
## Upgrade the CMS
Run the following command:
+
```sh
$ yarn upgrade --latest
```
@@ -27,24 +28,25 @@ in a short time.
We should considerate to migrate to a self-hosted GitLab solution for this reason.
See also
-* « Github Backend - API Rate Limiting » https://github.com/netlify/netlify-cms/issues/68
-* « Slow search » https://github.com/netlify/netlify-cms/issues/2350
-* « Paginate published posts in overview » https://github.com/netlify/netlify-cms/issues/50
-* « Netlify CMS Alternative » https://buttercms.com/netlifycms-alternative/
- than explains that a main problem with Netlify is this problem.
+
+- « Github Backend - API Rate Limiting » https://github.com/netlify/netlify-cms/issues/68
+- « Slow search » https://github.com/netlify/netlify-cms/issues/2350
+- « Paginate published posts in overview » https://github.com/netlify/netlify-cms/issues/50
+- « Netlify CMS Alternative » https://buttercms.com/netlifycms-alternative/
+ than explains that a main problem with Netlify is this problem.
## TODO
-* Actually, at the link https://blog.sogilis.fr/admin/#/collections/post
- the grid view with image is very slow. There are several solutions.
+- Actually, at the link https://blog.sogilis.fr/admin/#/collections/post
+ the grid view with image is very slow. There are several solutions.
-* Stylish with our style the preview of https://blog.sogilis.fr/admin/#/collections/post/new
+- Stylish with our style the preview of https://blog.sogilis.fr/admin/#/collections/post/new
-* In package.json remove Linux shell syntax and use only node modules to
- have compatibility with PowerShell or MS Batch. Use also https://www.npmjs.com/package/yarn-or-npm
+- In package.json remove Linux shell syntax and use only node modules to
+ have compatibility with PowerShell or MS Batch. Use also https://www.npmjs.com/package/yarn-or-npm
-* For netlify-cms.js, use https://webpack.js.org/guides/caching/
- (actually reboot.min.css is cached).
+- For netlify-cms.js, use https://webpack.js.org/guides/caching/
+ (actually reboot.min.css is cached).
## Troubleshooting
@@ -72,4 +74,4 @@ Emitted 'error' event on ChildProcess instance at:
}
```
-=> `$ rm -Rf ./node_modules && yarn install`
\ No newline at end of file
+=> `$ rm -Rf ./node_modules && yarn install`
diff --git a/docs/docker.md b/docsOld/docker.md
similarity index 90%
rename from docs/docker.md
rename to docsOld/docker.md
index a5cd8db77..f252594ac 100644
--- a/docs/docker.md
+++ b/docsOld/docker.md
@@ -2,8 +2,8 @@
You have to build the docker image only once, except when one of these file is modified:
-* `Dockerfile`
-* `package.json`:
+- `Dockerfile`
+- `package.json`:
Note: Each time you run `git pull` to update the website, if you don't know if this files are changed, you may rebuild the docker image.
This command is may be very long, even for an upgrade.
diff --git a/docs/infra.md b/docsOld/infra.md
similarity index 97%
rename from docs/infra.md
rename to docsOld/infra.md
index f328139bd..dcec4f818 100644
--- a/docs/infra.md
+++ b/docsOld/infra.md
@@ -6,7 +6,8 @@
Periodically, we check for broken links in deployed blog.
Finding the right tools was not easy (see #44 and linked Pull request for more details) because of the following reasons:
+
- LinkedIn respond with http code 999, which is considered as a broken link by many tools
- Some tool checks markdown links, which is great to check links before Pull request Merge. But some of them does not handle local link (like `img/…`) properly
-When a broken link is found, a Slack notification is sent to `#sites-web-dev` (see secret `SLACK_WEBHOOK_URL` created from [app Webhooks entrants](https://sogilis.slack.com/apps/A0F7XDUAZ-webhooks-entrants)).
\ No newline at end of file
+When a broken link is found, a Slack notification is sent to `#sites-web-dev` (see secret `SLACK_WEBHOOK_URL` created from [app Webhooks entrants](https://sogilis.slack.com/apps/A0F7XDUAZ-webhooks-entrants)).
diff --git a/docsOld/prerequisites.md b/docsOld/prerequisites.md
new file mode 100644
index 000000000..04036c932
--- /dev/null
+++ b/docsOld/prerequisites.md
@@ -0,0 +1,37 @@
+## Prerequisites
+
+## GNU Make.
+
+- For Linux, use your distro specific instructions
+- For Windows, see https://stackoverflow.com/questions/32127524/how-to-install-and-use-make-in-windows
+ - Actually (at 2020-03-01) GNUWin32 is very outdated (2006), I advise
+ you to use Chocolaty (it has built GNU Make from recent sources, as
+ we can see in their "Package Source")
+- For mac users, it is installed by default
+
+## Docker
+
+See Docker [installation instruction](https://docs.docker.com/install/)
+
+- Disclaimer:
+ - On Windows or Mac, installation of Docker could be
+ complicated.
+ - Use more disc space. It's not a fake affirmation.
+ I've taken fill my free 50Go of disk space simply when I've tested
+ several times to adapt the configuration of the current ./Dockerfile
+ (you could run `docker system prune`).
+ - Takes more resources
+ - Build the website is incredibly more long especially if you want
+ simply update `node_modules` when package.json is changed.
+ With the method without docker, the upgrade with simply
+ `yarn install` is very quick.
+- But if you won't install node and yarn in your environment because you
+ hate this web tools, and if you have already Docker, it could be a
+ solution interesting.
+- During the build, some files are created
+ ( ./site/data/webpack.json , ./site/resources/\_gen/ ).
+ There owner are root. Could cause some problems when you use
+ commands as not root user (rm, git, yarn).
+ You must delete this file before with `sudo`. It's not cool.
+ - Note: with the add of a dockerignore file, this issue should be
+ solved.
diff --git a/docs/writing.md b/docsOld/writing.md
similarity index 100%
rename from docs/writing.md
rename to docsOld/writing.md
diff --git a/netlify.toml b/netlify.toml
index 538f72b7f..d1430e511 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -1,9 +1,7 @@
[build]
+ # No need to trigger `yarn install`
command = "yarn build"
- publish = "dist"
-
-[context.deploy-preview]
- command = "yarn build:preview"
+ publish = "blog/.vuepress/dist/"
[build.environment]
NODE_VERSION = "12.20.1"
diff --git a/package.json b/package.json
index a647b6305..7220270ba 100644
--- a/package.json
+++ b/package.json
@@ -1,42 +1,43 @@
{
- "name": "sogilis-blog",
+ "name": "vuepress-1-poc",
"version": "1.0.0",
- "description": "Sogilis SAS's blog",
- "author": "Sogilis SAS",
+ "private": "true",
"license": "UNLICENSED",
- "repository": {
- "type": "git",
- "url": "https://github.com/sogilis/Blog.git"
- },
- "engines": {
- "node": ">=12"
- },
+ "main": "./blog/.vuepress/config.js",
"scripts": {
- "start": "make start",
- "start:netlify": "make start_netlify",
- "build": "make build",
- "build:preview": "make build_preview",
- "prettier:format": "prettier --write \"{,site/**/}*.{json,ts,css,scss,yml}\"",
- "prettier:check": "prettier --check \"{,site/**/}*.{ts,css,scss,yml}\"",
- "lint": "eslint . --ext .js,.ts",
- "lint:fix": "yarn lint -- --fix"
+ "build": "yarn clean && vuepress build blog",
+ "clean": "rm -rf blog/.vuepress/.temp blog/.vuepress/.cache blog/.vuepress/dist",
+ "dev": "vuepress dev blog --no-clear-screen",
+ "postinstall": "husky install",
+ "lint": "export NODE_OPTIONS=\"--max-old-space-size=4096\" && eslint --ext .js,.ts,.vue .",
+ "lint:fix": "yarn lint --fix",
+ "prettier": "prettier . --check --ignore-unknown",
+ "prettier:fix": "prettier . --write --ignore-unknown",
+ "serve": "yarn build && anywhere -h localhost -d blog/.vuepress/dist",
+ "test": "yarn prettier && yarn lint"
},
"devDependencies": {
- "babel-eslint": "^10.1.0",
- "eslint": "^7.20.0",
- "eslint-config-prettier": "^7.2.0",
- "eslint-plugin-prettier": "^3.3.0",
- "netlify-cms-proxy-server": "^1.3.10",
- "prettier": "^2.2.1"
- },
- "dependencies": {
+ "@vuepress/plugin-back-to-top": "^1.8.1",
+ "@vuepress/plugin-blog": "^1.9.4",
+ "@vuepress/plugin-search": "^1.8.1",
+ "anywhere": "^1.5.0",
"bootstrap-reboot": "^4.5.4",
- "hugo-bin": "^0.68.0",
- "netlify-cms": "^2.10.91",
+ "eslint": "^7.20.0",
+ "eslint-config-airbnb-base": "14.2.1",
+ "eslint-config-vuepress": "^3.1.0",
+ "eslint-plugin-import": "^2.22.1",
+ "husky": "^5.0.9",
+ "markdown-it-footnote": "^3.0.2",
+ "node-sass": "^5.0.0",
+ "prettier": "^2.2.1",
+ "sass-loader": "^10.0.0",
+ "sort-package-json": "^1.48.1",
"typeface-eb-garamond": "^1.1.13",
- "typeface-montserrat": "^1.1.13"
- },
- "hugo-bin": {
- "buildTags": "extended"
+ "typeface-montserrat": "^1.1.13",
+ "vuepress": "^1.8.1",
+ "vuepress-plugin-disqus": "^0.2.0",
+ "vuepress-plugin-medium-zoom": "^1.1.9",
+ "vuepress-plugin-reading-progress": "^1.0.10",
+ "vuepress-plugin-reading-time": "^0.1.1"
}
}
diff --git a/site/config.toml b/site/config.toml
deleted file mode 100644
index 6235e5309..000000000
--- a/site/config.toml
+++ /dev/null
@@ -1,23 +0,0 @@
-baseurl = "/"
-languageCode = "fr"
-defaultContentLanguage = "fr"
-title = "Blog Site"
-theme = "sogilis"
-enableEmoji = true
-debug = true
-paginate = 999
-disqusShortname = "sogilisblog"
-enableRobotsTXT = true
-
-[params]
- siteDescription = "Série d'articles écrits par les membres de Sogilis décrivants la vie en entreprise ou des sujets techniques précis"
-
-[languages.fr]
- languageName = "Français"
-
- [languages.fr.params]
- twitter = "https://twitter.com/Sogilis?lang=fr"
- linkedin = "https://www.linkedin.com/company/sogilis/"
-
-[outputs]
- section = ["json"]
diff --git a/site/content/posts/2020-09-09-bdd-qualite-eficience.md b/site/content/posts/2020-09-09-bdd-qualite-eficience.md
deleted file mode 100644
index 104201dfe..000000000
--- a/site/content/posts/2020-09-09-bdd-qualite-eficience.md
+++ /dev/null
@@ -1,179 +0,0 @@
----
-title: BDD - Apport en Qualité et en Efficience dans le développement logiciel
-author: Amin
-date: 2020-09-08
-image: /img/article_bdd/2020_09_09_bdd.jpg
-categories:
- - DÉVELOPPEMENT
-tags:
- - code
- - dev
-
----
-***Résumé*— Pendant plusieurs années, l’industrie logicielle a mis l’accent sur l’évolution des langages de programmation (programmation orientée objet par exemple) et des environnements de développement pour répondre à un besoin d’efficience de développement et d’intégration rapide de plusieurs fonctionnalités. Aujourd’hui, cette industrie est de plus en plus exigeante quant à la qualité, l’évolutivité des logiciels et leurs utilisabilités. Cela nécessite une maîtrise élevée et continue du logiciel tout au long de son cycle de vie. Pour assurer cette maîtrise, de nouvelles méthodes et pratiques d’ingénierie sont indispensables, à savoir les méthodes itératives et incrémentales, les tests, la gestion des exigences, les méthodes de développement TDD (Test Driven Development) et BDD (Behavior Driven Development), etc.**
-
-**Cet article s’intéresse à une méthode de développement qui concentre ses activités techniques autour de la définition du comportement souhaité du logiciel (BDD). Cette méthode permet d’assurer une meilleure compréhension partagée des besoins, tôt dans le cycle de vie de développement logiciel. Dans cet article, nous présentons cette approche, ainsi que ses avantages pour apporter de la qualité et de l’efficience. Nous expliquons également comment l’utilisation de cette approche peut faciliter l’atteinte de certains objectifs normatifs dans le cadre du développement de logiciels critiques et normés (DO-178C pour l’aéronautique, IEC 62304 pour le médical).**
-
-## I. Introduction
-
-Dans l’industrie logicielle, les facteurs de dépassement de coûts, et d’une manière générale de l’échec d’un projet de développement sont multiples. Parmi les principales raisons, et selon les études réalisées durant ces dernières années (Standish Group Chaos Report [ChaosReport]), on retrouve les spécifications incomplètes, non claires, ambiguës qui peuvent changer durant le cycle de vie de développement logiciel (Scope Creep) (figure 1). On retrouve également le manque d’implication des utilisateurs dans les phases de capture de besoins et de validation.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_1.png" title="Figure 1. Principaux facteurs d’échec dans le développement logiciel">}}
-
-Ces facteurs d’échec sont d’autant plus impactants et marquants dans un contexte de développement utilisant une approche à base de cycle en V. En effet, il s’agit d’un modèle de développement rigide ne permettant pas d’intégrer facilement des modifications et des adaptations aux exigences. Il s’agit également d’un modèle de développement favorisant une mauvaise compréhension des exigences, en raison de l’inexistence d’activités techniques permettant la convergence de la compréhension des besoins entre tous les acteurs du projet (l’équipe fonctionnelle, les utilisateurs et l’équipe de développement). D’après les études dans [EcoImp], plus de 65% des anomalies sont identifiées tard dans le cycle de vie de développement logiciel, pendant la phase d’implémentation et d’intégration. Une grande partie de ces anomalies est due à l’incohérence entre le code développé et les exigences définies. Aujourd’hui, des anomalies onéreuses en temps de traitement sont introduites tôt dans le cycle de développement logiciel. Elles résultent d’un manquement et de défaillances dans la capture des besoins et dans la gestion de leurs évolutivités, entre les équipes qui rédigent les exigences et les équipes qui implémentent et testent le logiciel.
-
-Ces facteurs d’échec et de dépassement de coûts pourraient être évités et atténués en ayant recours à des pratiques d’ingénieries et des méthodes de développement comme le BDD. En effet, la méthode de développement pilotée par le comportement (en anglais Behavior-Driven Development ou BDD) a été introduite pour fluidifier et simplifier la compréhension et la validation des besoins entre tous les acteurs qui interviennent dans le cycle de vie de développement du logiciel. Il s’agit d’une démarche où la définition des exigences d’un côté et des scénarios de tests d’un autre côté deviennent intrinsèquement liées. Le développement piloté par le comportement serait bénéfique et facile à appliquer avec les méthodes de développement itératives et incrémentales.
-
-La section II présente un état de l’art des plateformes de développement BDD existantes. La section III discute les avantages d’utiliser l’approche BDD pour améliorer la qualité et l’efficience des développements logiciels. Les sections IV et V expliquent comment une approche BDD peut être utilisée dans le développement et la vérification d’exigences fonctionnelles, y compris dans le cadre du développement de logiciels critiques et normés. La section VI présente le Framework XReq [XReq] et des exemples de cas d’utilisation.
-
-## II. Développement piloté par le comportement
-
-Le développement piloté par le comportement favorise l’utilisation d’un langage naturel et commun pour expliquer les exigences fonctionnelles à travers des scénarios de test. Les scénarios de tests permettent d’apporter des exemples concrets d’application des exigences. Le développement piloté par le comportement permet de s’assurer que les exigences logicielles répondent bien aux besoins utilisateurs. Le langage naturel Gherkin [Gherkin] est utilisé par la plupart des Framework BDD pour écrire les scénarios de tests. Il s’agit d’un langage simple et facile à comprendre et à utiliser pour décrire le déroulement d’une fonctionnalité. Il décompose un scénario de test en trois principales étapes :
-
-- Initialisation du Contexte (Given)
-- Action (When)
-- Résultat attenu (Then)
-
-Le scénario de test est parfois suivi par un jeu de données qui complète l’instanciation du scénario.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_2.png" title="Figure 2. Exemple d’un Scénario de test avec XReq [XReq]">}}
-
-La figure 2 illustre un exemple de scénario de test qui se déroule autant de fois que de nombre de lignes dans le jeu de données avec XReq.
-
-Des Frameworks de développement BDD existent comme Cucumber [Cucumber], XReq [Xreq], SpecFlow [Specflow], Jbehave [Jbehave] et Concordion [Concordion]. Cucumber est le Framework le plus connu, qui propose différentes implémentations pour de nombreux langages de programmation (Java, Go, Javascript, etc.).
-
-SpecFlow a été développé en s’inspirant de Cucumber et utilise le langage Gherkin dans la description des scénarios de tests. Il est dédié aux applications implémentées en .net C# et s’interface avec Visual Studio. Concordion [Concordion] est un Framework de BDD écrit en Java et intègre le Framework de tests unitaires JUnit.
-
-XReq [XReq] est un Framework de test dédié au développement de logiciels embarqués écrits en C/C++ ou en Ada. Avec XReq, il est possible de générer du code de test, en langage C et en Ada et de générer des rapports de tests, en natif ou en mode croisé (tests XReq exécutés sur la plateforme cible). XReq dispose d’un outil de reporting et se greffe facilement avec l’outil de reporting cucumber-report.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_3.png" title="Figure 3. Exemples de Frameworks BDD">}}
-
-La plupart des Frameworks BDD ne se contentent pas de l’aspect documentaire dans l’écriture des scénarios de tests, mais fournissent des outils pour générer le code des squelettes des tests à partir des scénarios. Ils fournissent également des moteurs d’exécution des tests afin de faciliter l’automatisation de l’exécution des scénarios de tests avec le jeu de données correspondant. La figure 4 illustre le cycle de vie d’un scénario de test dans les Frameworks BDD avancés [Cucumber] [Xreq] [SpecFlow] depuis l’écriture des scénarios des tests jusqu’à la génération du rapport des tests, en passant par la génération du code des tests, leurs implémentations et leurs exécutions.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_4.png" title="Figure 4. Cycle de vie d’un scénario de Test dans un Framework BDD">}}
-
-## III. Efficience et Qualité
-
-L’utilisation des techniques BDD dans le développement logiciel pourrait contribuer à l’amélioration de la qualité logicielle et à l’efficience des équipes de développement. Cela peut se traduire à plusieurs niveaux, pour plusieurs activités techniques :
-
-**Maîtriser le niveau de la qualité logicielle et améliorer la qualité des exigences** : la perte de la maîtrise de la qualité d’un logiciel est souvent liée à l’accumulation des anomalies. Ces anomalies sont souvent découvertes tard dans le cycle de vie de développement logiciel et deviennent compliquées à corriger. Elles deviennent coûteuses car les équipes de développement ne disposent pas de moyens suffisants, en termes de tests, pour vérifier la non régression du logiciel suite à la livraison d’un correctif. Une des causes racines de la perte ou la non maîtrise d’un logiciel est l’absence de tests logiciels automatiques couvrant les principales fonctionnalités.
-
-L’application d’une approche BDD durant la phase de capture de besoins permet d’écrire les scénarios de tests à implémenter dans un second temps. Les scénarios de tests écrits en BDD seront les tests de non régression qui vont aider à garantir un niveau de fiabilité du logiciel et à le maintenir plus facilement.
-
-D’un autre côté, nous savons qu’une grande partie des anomalies est due à une incompréhension des exigences. Ces anomalies sont introduites tôt dans le cycle de vie du logiciel. Pour réduire le nombre d’anomalies liées à une mauvaise compréhension des exigences, il faut recourir à des techniques BDD. En effet, les scénarios de tests BDD permettent de vérifier que les exigences ont été correctement écrites et comprises par les équipes de développement avant de procéder à leurs implémentations. Cette phase de vérification, au moyen de scénarios de tests BDD, peut amener à itérer et à améliorer les exigences tant au niveau fonctionnel qu’au niveau des besoin d’utilisabilité.
-
-**Améliorer la qualité des tests logiciels** : généralement, les tests sont écrits par les développeurs après l’implémentation des fonctionnalités. Les développeurs ont toujours tendance à écrire les tests selon leur compréhension des exigences et en fonction des développements qu’ils ont menés. De plus, il n’y a souvent pas d’activités techniques pour vérifier les tests écrits par les développeurs. Cela peut amener à disposer de tests incomplets, ou mal écrits, en face d’une implémentation incorrecte des exigences. Pourtant, les indicateurs de qualité seraient au vert puisque tous les tests passent et on peut disposer d’un taux élevé de couverture de code.
-
-Une approche BDD peut apporter des solutions à ce niveau en améliorant d’une manière considérable la qualité du test logiciel. En effet, l’amélioration de la qualité des tests commence déjà par la lisibilité du format du test. Il est beaucoup plus simple de vérifier un scénario de test écrit en langage naturel Gherkin et de vérifier le jeu de données associé (voir Figure 2), que de vérifier des tests écrits en code avec un jeu de données réparti sur plusieurs lignes de code. Le format d’écriture d’un scénario de test BDD favorise la vérification de la complétude des jeux de données. Les tests BDD sont encore plus simples à lire et à vérifier et sont plus rapides à écrire et à lire.
-
-Les scénarios de tests BDD permettent aux équipes de développement d’apporter plus d’expressivité dans l’écriture des scénarios de tests. En effet, quand les développeurs implémentent les tests après l’implémentation des fonctionnalités, ils sont limités par l’expressivité des composants logiciels déjà implémentés. En écrivant les scénarios de tests au même moment que les exigences, ils peuvent écrire des scénarios qui appellent à la fois des composants logiciels et matériels. L’implémentation de ces tests passent par l’implémentation de composants Stub. Ces pratiques favorisent l’implémentation de tests ayant un important taux de couverture fonctionnelle. Le taux de couverture fonctionnelle est un indicateur pertinent de qualité et pourrait être amélioré et piloté par l’utilisation des techniques de BDD.
-
-**Efficience des équipes de développement** : la mise en œuvre d’une approche BDD permet aux équipes de développement d’exploiter directement des scénarios de tests validés sans passer du temps à les écrire. Nous pensons que les scénarios de tests doivent être écrits par l’équipe fonctionnelle et que l’équipe de développement doit se contenter d’implémenter ces scénarios sans les modifier. Ainsi, l’équipe de développement se contente de générer le code des tests, de les compléter, pour ensuite les exécuter et générer le rapport de tests complet.
-
-L’utilisation des outils automatiques des Framework BDD (génération de code des tests, exécution du jeu de données entier, génération des rapports de tests (Voir figure 4)) permet à l’équipe de développement de gagner en efficience. Le BDD n’est plus seulement une démarche pour améliorer et vérifier la capture des besoins mais un ensemble d’outils pour optimiser le cycle de vie de développement logiciel. Il permet de laisser une trace documentaire à jour aidant à maintenir l’intégrité des développements.
-
-## IV. Remplacer une exigence par des scénarios BDD
-
-Pour certains projets de certains acteurs industriels chez qui nous sommes intervenus, nous avons préconisé de remplacer la définition d’exigences par la description de scénarios de test. Un scénario de test complet avec un jeu de données complet peut remplacer une exigence. Cela peut être fait sous certaines conditions :
-
-- L’équipe de développement doit maîtriser les techniques BDD et être mature sur la technologie.
-- L’équipe de développement doit mettre en place des standards d’architecture logicielle et d’écriture de scénario de tests pour maintenir l’intégrité et la cohérence des exigences.
-- Associer un scénario de test, qui remplace l’exigence, à un composant logiciel.
-- Les scénarios de tests doivent être écrits sous forme de tests logiciels de type boites noires et boites blanches.
-
-Pour réduire l’effort de test et standardiser l’écriture des exigences, certaines équipes ont choisi d’utiliser du pseudo code ou de la preuve formelle dans l’écriture des exigences. Cela nécessite des compétences chez l’équipe fonctionnelle pour maîtriser l’algorithmique et les langages formels, ce qui représente un frein réel et une source de génération d’anomalies. Cependant, ces problèmes peuvent être surmontés quand l’exigence est décrite sous forme de scénarios de tests avec un langage naturel simple et facile à lire et à écrire.
-
-## V. Le BDD pour le développement de logiciels critiques
-
-Le développement de logiciels critiques, pour certains domaines (aéronautique, médical, automobile, ferroviaire, nucléaire, etc.) s’appuie sur des normes, qui déclinent tous de l’IEC 61508 [iec61508]. Chaque norme décrit des objectifs à atteindre (les exigences sont en cohérence avec l’architecture, le code respecte les standards de codage définis, toutes les exigences sont testées, etc.) pour garantir un certain niveau de fiabilité, qui consiste à démontrer et à garantir que le logiciel livré implémente exactement les fonctionnalités souhaitées. La liste des objectifs à atteindre diffère d’un niveau de criticité à un autre.
-
-Dans cette section, et en partant de nos expériences de développement, nous présentons comment le BDD peut répondre à certains objectifs des normes DO-178C/ED12C (développement des logiciels aéronautiques) et IEC 62304 (développements de logiciels pour les dispositifs médicaux (DM)).
-
-Dans la norme DO-178C/ED12C, nous pouvons utiliser les techniques de BDD pour répondre à des objectifs de vérification des exigences de haut niveau de type HLR (High Level Requirement) et des exigences de bas niveau de type LLR (Low Level Requirement) (voir Figure 5.). Les scénarios de tests sont écrits pour produire les tests associés aux exigences (HLT : High Level Test et LLT : Low Level Test).
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_5.png" title="Figure 5. Utilisation du BDD pour satisfaire des objectifs de vérification des HLT dans la DO-178C" width="850">}}
-
-**High/Low Level requirements are accurate and consistent** : grâce à une approche BDD où les scénarios de tests sont écrits en même temps que les exigences, nous pouvons nous assurer du niveau de précision de l’exigence en analysant les scénarios de tests associés ainsi que les jeux de données correspondants. Il s’agit de vérifier l’absence d’ambiguïté dans l’écriture des tests et de réaliser une analyse comportementale de l’exigence. L’activité de vérification consiste également à vérifier la cohérence entre l’exigence et le scénario de test en analysant la cohérence des entrées/sorties, la complétude des scénarios de tests, la couverture des classes d’équivalences et des valeurs limites. Le langage de description des scénarios de tests en BDD favorise ces vérifications grâce au format simple en lecture.
-
-**High/Low level requirements are verifiable**: l’association de scenarios de test BDD aux exigences tôt dans le cycle de vie de développement logiciel nous permet de disposer d’exigences couvertes par des tests et donc vérifiables. Pour valider qu’une exigence est vérifiable, il suffit de vérifier s’il y a des scénarios de tests BDD qui lui sont rattachés. Les scénarios de tests décrivent les cas de tests de l’exigence. Ils seront ensuite implémentés et exécutés pour valider le code des exigences. Une traçabilité de type Scénario de test / Exigence complète avec une vérification de la complétude des cas de tests peut répondre à cet objectif.
-
-L’utilisation d’une approche BDD facilite également la mise en œuvre des activités de vérification tout en assurant l’indépendance des rôles. L ’indépendance des rôles exige une séparation des acteurs qui développent les données et ceux qui la vérifient. Grâce au format lisible et compact des scénarios de tests BDD (voir Figure 2), l’équipe fonctionnelle peut facilement développer les cas de test, sans disposer obligatoirement de connaissances techniques. D’autres personnes de l’équipe fonctionnelle peuvent facilement analyser ces données dans le cadre des activités de vérification. Le BDD permet de fluidifier les activités de relecture et de validation de la cohérence entre les HLR et les HLT et entre les LLR et LLT.
-
-Dans la norme IEC 62304, nous pouvons utiliser les techniques de BDD de la même manière qu’en DO-178C pour répondre à des objectifs de développement et de vérification des exigences logicielles. La norme exige le développement d’exigences logicielles cohérentes, précises et vérifiables (voir figure 6).
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_6.png" title="Figure 6. Développement d’exigences vérifiables dans la norme IEC 62304" width="700">}}
-
-## VI. Le Framework XReq
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_xreq.png" width="350">}}
-
-**XReq (eXecutable Requirements)** est un Framework BDD, développé et commercialisé par Sogilis. XReq est dédié au développement de logiciels embarqués et peut être utilisé dans le développement de logiciels critiques en conformité avec des normes industrielles sectorielles (DO-178B/C, IEC-62304, EN-50128, ISO 26262, etc.).
-
- **XReq** propose une syntaxe d’écriture des scénarios de tests inspirée du langage Gherkin avec des extensions dans le mode d’écriture du contexte des scénarios et dans la description des jeux de données. XReq permet la génération de code des tests en C/C++ et en Ada (squelettes des étapes de tests) (voir figure 7). La génération de code et le moteur d’exécution des tests dans XReq sont dédiés aux applications et aux environnements embarqués. Il est possible d’utiliser XReq pour exécuter des tests en mode natif ou en mode croisé sur la plateforme cible.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_7.png" title="Figure 7. Description des cas de tests et génération du code des step_definitions avec XReq">}}
-
-Après exécution des tests, **XReq** génère un rapport détaillant le statut d’exécution des scénarios de tests en précisant l’état de chaque étape des scénarios (step_def) (voir figure 8).
-
-Aujourd’hui, le **Framework XReq** est utilisé dans plusieurs projets industriels, à la fois dans le développement de logiciels industriels et dans le développement de logiciels critiques normés.
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_8.png" title="Figure 8. Rapport de test généré par XReq">}}
-
-### A. Développement de logiciels normés
-
-Le BDD, à travers XReq est utilisé dans le cadre du développement d’un contrôleur de vol certifié en conformité avec la DO-178C DAL A [Pulsar]. Une des principales raisons du développement de XReq par Sogilis est l’absence sur le marché d’un Framework BDD dédié aux applications embarquées et pour les logiciels critiques. L’utilisation du BDD et de XReq a été introduite dans les plans de certification décrivant les activités des processus de développement et de vérification des données logicielles. Dans ce projet, les équipes de développement ont produit jusqu’à aujourd’hui avec XReq plus de 600 cas de test de haut niveau en face des HLR (~7000 assertions implémentées dans les blocs « Then ») et plus de 1000 cas de test de bas niveau en face des LLR ((~8000 assertions implémentées dans les blocs « Then »). Grâce à cette approche, nous avons pu stabiliser le temps de gestion des anomalies à ~8% du temps total de développement logiciel.
-
-XReq, et l’approche BDD d’une manière générale, a apporté de l’efficience dans ce développement logiciel. Cela nous a fortement aidé à la réalisation de plusieurs activités et pour satisfaire plusieurs objectifs de la norme, à savoir :
-- Favoriser l’indépendance des rôles dans les activités de vérification : Efficience dans la vérification des scénarios de tests, en simplifiant la vérification des jeux de données par exemple (MC/DC, classes d’équivalence, complétude, valeurs limites, etc.) ;
-- Favoriser la séparation des rôles dans l’écriture des cas de test : La personne qui écrit les exigences écrit les scénarios de tests et n’implémente pas la fonctionnalité ;
-- Favoriser l’écriture d’exigences vérifiables, précises et cohérentes ;
-- Intégration facile de l’environnement de test dans une plateforme d’intégration continue (CI)
-- Intégration facile des scénarios de tests dans un environnement de test de type HIL (Hardware
-In the Loop)
-
-### B. Développement de logiciels pour automates PLC
-
-**XReq** est également utilisé pour améliorer l’efficience et la qualité dans le développement de logiciels industriels de contrôle-commande sûrs et embarqués sur des automates PLC. XReq est utilisé pour vérifier et améliorer la qualité des exigences logicielles. Les tests XReq sont implémentés en face des composants logiciels écrits avec le langage Reflex [Reflex]. Reflex est un langage de programmation de haut niveau, de type GALS « Globalement Asynchrone, Localement Synchrone » basé sur le langage Ada. Il permet d’écrire des applications logicielles de haut niveau pour du prototypage virtuel des applications de contrôle-commande. Une fois l’application Reflex testée et vérifiée en utilisant XReq, nous procédons dans un second temps à la génération de code du logiciel final qui sera déployé sur les équipements d’automates cibles.
-
-Aujourd’hui, les développeurs des applications d’automates sont confrontés au manque d’outillage pour tester et vérifier les applications implémentées directement avec les outils des constructeurs des PLC. L’utilisation du BDD avec un langage de haut niveau, comme Reflex permet de vérifier les fonctionnalités et de détecter les anomalies tôt dans le cycle de vie de développement applicatif.
-
-Dans le cadre du développement d’une application simple de gestion d’un réseau de pompes, l’équipe logicielle a produit avec XReq ~60 cas de test en face des exigences avec ~700 vérifications de type « assertion ». A ce stade, les différentes fonctionnalités de l’application ont été testées sans connaissance de plateforme matérielle cible. L’utilisation du BDD a apporté de l’efficience et de la qualité pour les logiciels industriels de contrôle-commande, et cela à plusieurs niveaux :
-- Favoriser et améliorer la qualité et la documentation des exigences logicielles (en renforçant l’expression du besoin) et des liens de traçabilité entre les toutes les données produites (voir Figure 9);
-- Améliorer la qualité des tests en détectant plus rapidement les cas de tests manquants ;
-- Favoriser l’écriture d’exigences vérifiables et de tests logiciels de types « Boite Blanche » et « Boite Noire »
-- Intégration facile de l’environnement de test BDD, et de ses rapports d’exécution, dans une plateforme d’intégration continue (CI).
-
-{{< figure src="/img/article_bdd/2020_09_09_bdd_figure_9.png" title="Figure 9. De l’exigence logicielle au rapport de test : Utilisation de XReq et Reflex dans le développement d’applications de contrôle-commande">}}
-
-## VII. Conclusion
-
-En résumé, le BDD est une approche qui réinvente les stratégies de test et les processus de développement logiciel. Elle permet de réduire considérablement les anomalies dont l’origine est l’imprécision ou l’incohérence des exigences logicielles. En effet, la scénarisation des exigences renforce la qualité de l’expression des besoins et de leur utilisabilité. Nous avons exposé dans cet article comment le BDD peut être compatible et utilisable pour le développement de logiciels industriels critiques et normés, et comment on peut en tirer profit au niveau de la qualité et de l’efficience.
-
-## VIII. Références
-
-**[ChaosReport]** : Standish Group: “Standish Group Chaos Report”
-
-**[EcoImp]** : The Economic Impacts of Inadequate Infrastructure for Software Testing, Studies by the National Institute of Standards and Technology and the National Aeronautics and Space Administration,
-
-https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf
-
-**[Xreq]** : https://sogilis.com/services-safety-critical.html
-
-**[Gherkin]** : https://cucumber.io/docs/gherkin/reference/
-
-**[Cucumber]** : https://cucumber.io/
-
-**[Specflow]** : https://specflow.org/
-
-**[Jbehave]** : https://jbehave.org/
-
-**[Concordion]** : https://concordion.org/
-
-**[iec61805]** : International Electrotechnical Commission, “Functional Safety and IEC 61805”,
-
-https://www.iec.ch/functionalsafety/standards/
-
-**[Pulsar]** : Pulsar Flight System: https://www.hionos.com/#pulsar
-
-**[Reflex]** : https://www.artics.fr/produits
-
diff --git a/site/content/posts/2020-09-15-niveau-qualite-requis.md b/site/content/posts/2020-09-15-niveau-qualite-requis.md
deleted file mode 100644
index f4d701e38..000000000
--- a/site/content/posts/2020-09-15-niveau-qualite-requis.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: Quel besoin en Qualité Logicielle ?
-author: Amin
-date: 2020-09-15
-image: /img/article_niveau_qualite/2020_09_09_quality.jpg
-categories:
- - DÉVELOPPEMENT
-tags:
- - code
- - dev
-
----
-***Résumé—* De plus en plus de composants logiciels sont intégrés dans les solutions et les systèmes développés par l’industrie, avec des contraintes de fiabilité de plus en plus fortes. La défaillance de ces systèmes n’entraîne pas obligatoirement de blessures ou de pertes de vies humaines. Pourtant ces systèmes restent critiques, car leur défaillance pourrait avoir un impact économique important. La fiabilité de ces solutions est fortement couplée à la fiabilité des logiciels qu’elles embarquent, avec un besoin grandissant de prouver cette fiabilité, auprès des clients et des marchés cibles. Pour la plupart des solutions développées, n’impliquant pas de risques humains, il n’existe pas, à ce jour, de standard pouvant être appliqué et à mis en œuvre pour qualifier la fiabilité logicielle.**
-
-**Cet article s’intéresse à la mise en œuvre d’une approche permettant de mesurer le niveau de qualité requis du logiciel à développer, pour garantir un certain niveau de fiabilité de la solution. Cet article souligne les difficultés rencontrées par les acteurs industriels, et discute quelques solutions possibles. Il explique également pourquoi la qualité logicielle ne doit pas être considérée comme une variable d’ajustement dans un projet de développement, et comment cela pourrait se traduire avec la mise en œuvre de méthodes et outils adéquats.**
-
-## I. Introduction
-
-Dans le développement des logiciels non normés (sans objectif de certification en conformité d’une norme donnée), la mise en œuvre d’activités techniques pour garantir un certain niveau de qualité est souvent considérée comme un surcoût et une contrainte supplémentaire aux équipes, entraînant le ralentissement de la production et des livraisons. Les activités techniques peuvent être variées, différentes et mises en œuvre de plusieurs manières (écriture et validation des exigences logicielles, déroulement d’une stratégie de tests, assurance d’une couverture de code fonctionnelle, assurance de la complétude des exigences, revue de code et des résultats de tests, etc.).
-
-D’une manière générale, dans le montage et lors du suivi d’avancement des projets de développement logiciel, trois variables sont définies et ajustées : le périmètre fonctionnel, le budget et les délais de livraison. Les discussions autour de la qualité logicielle apparaissent quand les problèmes de fiabilité, de maintenabilité et de livraisons deviennent critiques et visibles. L’ajout et la maintenance de fonctionnalités peuvent devenir rapidement des tâches très coûteuses et les délais de livraisons deviennent difficiles à respecter. En conséquence, les budgets pourraient être rapidement dépassés.
-
-Certaines tentatives d’ajustement des variables initiales sont appliquées pour reprendre en main et maîtriser les projets qui dérivent, en particulier, sur les aspects de budget et de qualité. Les stratégies peuvent être différentes, allant de la réduction du périmètre fonctionnel, à l’augmentation du budget ou même au décalage des dates de livraison. Certaines entreprises décident à ce stade de restructurer les équipes en montant une équipe d’assurance qualité (QA). Le rôle de cette équipe consiste à identifier et rattraper les défaillances au niveau de la qualité. Cette solution peut s’avérer efficace si les équipes d’assurance qualité logicielle réussissent à définir le bon niveau de qualité requis et travaillent conjointement avec les équipes de développement pour mettre en place les bonnes activités techniques, ce qui n’est pas toujours simple, selon les organismes.
-
-En pratique, les activités techniques de qualité, dans le cycle de développement de logiciel ne sont pas menées par les équipes de développement dès le début des projets, car on considère généralement que les premières phases de prototypage ne requièrent pas un niveau qualité à garantir. Le but étant de sortir un prototype fonctionnel, dans des délais très courts. Les activités techniques de qualité sont ainsi repoussées à la phase de développement industrialisé.
-
-Généralement, durant la phase de développement industrialisé, les équipes logicielles se rendent compte de l’existence d’une dette technique considérable (Exemple : beaucoup de tests à écrire pour couvrir le code précédemment produit), ce qui implique la nécessité de modifier potentiellement l’architecture logicielle et faire certains choix (changer de technologies par exemple). Plusieurs équipes de développement ont souvent suggéré de reprendre les développements « from scratch » au lieu d’essayer de réutiliser le code existant, en améliorant sa qualité. Les activités de qualités ont certainement un coût supplémentaire, mais ne pas les introduire ou les introduire tard risque de coûter encore plus cher, en coût de maintenance et d’évolution.
-
-Nous pensons qu’il est toujours pertinent de définir et à mettre en œuvre un niveau de qualité à garantir dès le démarrage du projet. Ce qui consiste à considérer les aspects de qualité au même niveau que le périmètre fonctionnel, le budget et les délais. Cette configuration à 4 axes ramène plus de cohérence au périmètre fonctionnel et aux aspects budgétaires. La prise en compte de cette variable dès le début permet d’ajuster dès le démarrage les autres variables. L’intégration des activités de qualité tôt dans le projet peut ramener une garantie continue de la fiabilité des développements et apporte de l’efficience au sein de l’équipe développement, tout en respectant les budgets et les délais.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_1.png" title="Figure 1. Définition des besoins initiaux d’un projet de développement logiciel">}}
-
-Durant ces dernières années, nous sommes intervenus chez plusieurs acteurs industriels afin d’évaluer des logiciels existants et pour préconiser des activités de qualité adéquates. Nous nous sommes retrouvés à maintes reprises face à des questions de type « Combien va coûter la mise en place de nouvelles activités techniques ? Combien l’entreprise va gagner une fois ces activités en place ? Ce n’est pas de la sur-qualité ce que vous proposez ? etc. ». Nous remarquons toujours une inquiétude et une crainte d’avoir engagé des activités sans intérêts, souvent qualifiées de sur-qualité, sans pouvoir dimensionner les surcoûts liés au manque de qualité. Malheureusement, très peu d’organismes savent ce que leur coûte la non-qualité, une approche basée sur des organisations et des équipes historiquement en place étant très souvent la règle. Ce type de retour est compréhensible puisqu’il n’existe généralement pas de niveau de qualité défini, et spécifié comme étant un objectif.
-
-Les activités techniques de qualité sont encore plus nombreuses et plus compliquées à modéliser et à mettre en œuvre dans le cadre d’un développement logiciel faisant partie d’un système Logiciel/Matériel. Les activités de tests ne doivent pas se limiter aux composants logiciels mais doivent prendre en compte le comportement du matériel, ce qui représente une complexité et un coût supplémentaire à prévoir.
-
-Cet article aborde le problème de définition d’un niveau qualité adéquat pour les développements logiciels, non soumis à une certification en conformité avec des standards, en soulignant la pertinence de prendre en considération les aspects de qualité au même niveau que le budget, les délais et le périmètre fonctionnel. Il explique les moyens possibles pour s’inspirer des standards existants afin de proposer une approche permettant d’identifier les activités techniques de qualité nécessaires à mettre en œuvre. Cet article explique l’intérêt d’investir dans la qualité logicielle pour éviter des surcoûts de maintenance futures.
-
-La section II présente un état de l’art des standards existants ainsi que les niveaux de criticité ciblés. La section III discute la manière de définir et de garantir des objectifs de qualité, pour les logiciels non soumis à des normes, en se basant sur les standards existants, et en prenant en compte les exigences du marché. La section IV démontre l’importance d’investir dans la qualité, tôt dans le processus de développement logiciel. Elle explique également l’importance de ne pas considérer la qualité comme une variable d’ajustement pour garantir une fiabilité continue des logiciels développés.
-
-## II. Développements normés de logiciels critiques
-
-Le développement de logiciels critiques, pour certains domaines (aéronautique, médical, automobile, ferroviaire, nucléaire, etc.) s’appuie sur des normes, qui déclinent tous de l’IEC 61508 [iec61508].
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_2.png" title="Figure 2. Standards pour le développement de logiciels critiques sectoriels" width="700" align="center">}}
-
-Chaque norme décrit des objectifs à atteindre (les exigences sont en cohérence avec l’architecture, le code respecte les standards de codage définis, toutes les exigences sont testées, etc.) pour garantir un certain niveau de fiabilité, qui consiste à démontrer et à garantir que le logiciel livré implémente exactement les fonctionnalités souhaitées. La liste des objectifs à atteindre diffère d’un niveau de criticité à un autre. Le tableau ci-dessous illustre les principales normes ainsi que les niveaux de criticité associés. La norme DO-178C/ED12C s’intéresse au développement des logiciels aéronautiques. La norme IEC 62304 s’applique aux développements de logiciels pour les dispositifs médicaux (DM). Les normes EN 50128 et ISO 26262 s’appliquent respectivement aux développements de logiciels ferroviaire et automobile.
-
-Chaque niveau de criticité (A, B, C, DAL-A, SIL1, SIL C, etc.) définit un ensemble d’objectifs à atteindre et d’activités à dérouler. La liste des activités techniques et la rigueur de leurs déroulements peuvent varier d’un niveau de criticité à un autre. Par exemple, dans la norme aéronautique DO-178C, et pour le niveau de criticité « DAL-A » les activités de vérification d’une écriture d’une exigence, nécessitent obligatoirement une indépendance des rôles (Les personnes qui écrivent l’exigence et qui la vérifient dans un second temps, sont obligatoirement des personnes différentes). Cette indépendance des rôles n’est pas exigée dans un contexte de développement en conformité avec le niveau de criticité « DAL-C ».
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_tableau_1.png" title="Tableau 1. Niveaux de criticité associés aux standards" width="850">}}
-
-Les niveaux de criticité sont établis selon l’importance des fonctionnalités à développer et l’impact de leurs défaillances, sur les vies humaines. Par exemple, dans la norme médicale IEC 62304, le niveau « C » est le plus haut niveau de criticité. Il correspond à des fonctionnalités pouvant, en cas défaillance, causer la mort ou des blessures humaines sérieuses. Le niveau « B » est associé aux fonctionnalités pouvant causer des blessures non sérieuses et le niveau A pour les fonctionnalités sans impacts sur la santé (voir figure 2).
-
-Dans le développement normé, et avec l’expérience des années, nous avons une idée des coûts approximatifs des développements logiciels, selon les niveaux de criticité et les niveaux de qualité requis. Par exemple, dans le standard aéronautique DO-178C, il existe cinq niveaux différents, allant du DAL-A au DAL-E, le moins critique (voir tableau). À mesure que le niveau de criticité augmente, le niveau de rigueur associé aux activités techniques augmente également, et par conséquence les coûts augmentent et les délais de livraison se rallongent.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_3.png" title="Figure 3. Les niveaux de criticité de la norme IEC-62304" width="350">}}
-
-D’après [Hilderman2009], les coûts associés au niveau D sont 15% supérieurs au développement logiciel du grand marché, qui dispose d’une qualité moyenne. D’après [Louis2019] [Hilderman2009], les coûts supplémentaires entre un développement en DAL-D et un DAL-C est estimé à 30%. La différence en coût entre le niveau C et B est de 15% supplémentaire alors que l’écart entre le niveau A et B est de 5%. D’après notre expérience dans le développement aéronautique, le développement en DAL-A représente un surcoût pouvant varier entre 55% et 70% par rapport à un développement classique, sans activité techniques de qualité.
-
-Pour les applications industrielles, le standard IEC61508 reste largement utilisé. Il s’agit d’un standard à caractère générique qui cible l’obtention de la sécurité fonctionnelle des systèmes, basée sur les risques. Les activités techniques de développement ciblent la détection des pannes aléatoires et systématiques des systèmes, au niveau matériel et logiciel. Cette norme n’a pas été conçue dans un esprit de certification puisqu’elle n’est rattachée à aucune réglementation, et reste un sujet à interprétations divergentes. Elle présente également des inconvénients au niveau de l’attribution du niveau de criticité au logiciel et par rapport à sa capacité à adresser des nouvelles solutions émergentes comme l’IoT, et les applications orientées industrie 4.0. Des travaux sont en cours pour développer une nouvelle norme IEC 63187, pour mieux prendre en compte certains aspects comme l’ingénierie système, ainsi que les exigences et les menaces liées à la cybersécurité.
-
-Aujourd’hui, la gestion des aspects de qualité dans le développement est largement mieux maîtrisée en industrie en présence d’une norme sectorielle, qui encadre les développements, et quand la certification logicielle fait partie d’un cadre réglementaire.
-
-D’un autre côté, l’industrie logicielle a connu ce qu’on appelle une « Crise Logicielle ». Ce terme est apparu à la fin des années 1960 avec la montée en complexité des logiciels et l’apparition de plusieurs problèmes comme les dépassements de budgets et de délais. La qualité du logiciel livré était souvent déficiente ne tenant pas en compte le besoin utilisateur. Les coûts de la maintenance du logiciel (coût, régressions, complexité) n’étaient pas maîtrisés. La complexité du logiciel et son architecture était une conséquence directe de l’évolution du matériel et de la disponibilité des ressources [Yu2009] [Dij79].
-
-En réponse à cette première crise, l’industrie logicielle a introduit des méthodes et des outils de gestion du cycle de vie du développement, en adoptant des approches de développement en cascade et des outils, en particulier des ateliers de développement. Cependant, les problèmes de l’industrie logicielle persistent encore aujourd’hui. Nous continuons de voir toujours les mêmes symptômes de manque de qualité et de dérive financière et temporelle. Dans [Gibbs94], les auteurs parlent d’une crise chronique. D’autres personnes [Fitzgerald2012], considèrent qu’on est en train de vivre la crise logicielle 2.0, puisque les applications logicielles et les technologies ne cessent d’augmenter en complexité. En parallèle, cette complexité n’est pas suivie par le développement de nouvelles méthodes et outils permettant de garantir à la fois la fiabilité et la qualité, tout en respectant les délais et les budgets.
-
-L’industrie du logiciel évolue vite et continue sa progression en termes de complexité. Aujourd’hui, dans un seul système, on peut trouver plusieurs briques logicielles différentes et communicantes, qu’il faut développer, vérifier et livrer. Il pourrait s’agir de développement de logiciel embarqué, de protocoles de communications, d’applications mobiles, d’applications dans le Cloud avec une architecture micro-services et une gestion de données volumineuses, de bases de données NoSQL, d’applications Web, etc.
-
-En conclusion, la qualité ainsi que les dépassements budgétaires et temporels ont toujours été des problèmes dans l’histoire de l’industrie logicielle. Ces problèmes sont nettement mieux gérés quand les développements sont encadrés par des normes et par une réglementation, ce qui est le cas des logiciels développés pour des systèmes critiques. Dans [Spector86], l’auteur estime que les logiciels ne sont jamais développés à temps et dérivent en budget. De plus, ils contiennent plusieurs anomalies. Dans cet article, l’auteur fait une comparaison entre les projets de construction de ponts, qu’il estime efficaces par rapport aux projets de développement de logiciels qui se terminent avec des dérives, sans atteindre les fonctionnalités souhaitées.
-
-Le Chaos Report [Chaosreport18] mentionne que plus de 55% des projets dérivent de plus de 50% de budget, et peuvent atteindre jusqu’à plus de 400%. Seulement 15% des projets dérivent de moins de 20%. La dérive de délais de livraison est supérieure à 50% pour ~70% des projets.
-Dans cet article, nous nous intéressons à la définition et à la mise en œuvre du niveau de qualité requis pour un logiciel donné, sans mettre en place de norme et sans faire de la sur-qualité. Nous aborderons les moyens d’adapter les activités techniques de qualité avec les nouveaux besoins du marché et les nouvelles méthodologies de développement.
-
-## III. Définir un niveau de qualité logicielle requis
-
-Le développement logiciel ne consiste pas uniquement à développer du code. Les données logicielles comportent le code source, les exigences de haut niveau, les exigences détaillées, les tests, les données d’architecture, les données de gestion de projet, etc. C’est grâce à la bonne implémentation de toutes ces données, que l’on peut garantir un niveau de fiabilité et de confiance du code source exécutable, livré et déployé en production. C’est grâce à ces données également que l’on peut garantir une maintenance maîtrisée du logiciel.
-
-### A. Définition et Calcul d’un niveau de qualité
-
-La définition d’un niveau de qualité requis d’un logiciel peut se faire lors du démarrage d’un projet ou pendant la phase d’un développement en cours. Il est évident qu’il est beaucoup plus simple et efficace de prendre en compte les aspects de la qualité tôt dans le processus de développement logiciel. D’après notre expérience, la plupart des demandes d’amélioration de la qualité logicielles surviennent durant des phases avancées de développement. Les interventions sur ces projets surviennent pour les besoins suivants :
-
-- L’industriel qui remarque que son projet dérive et lui échappe et souhaite reprendre la maîtrise et garantir un certain niveau de qualité auprès de son marché. Il s’agit d’industriels en train de perdre des parts de marché à cause du manque de fiabilité et de la qualité déficiente de leurs logiciels.
-- L’industriel n’a pas beaucoup avancé sur le projet et souhaite analyser et faire évoluer les activités techniques de qualité déjà mise en œuvre. Il s’agit d’industriels qui souhaitent garantir un niveau de qualité adéquat.
-
-Pour mesurer et qualifier le niveau de qualité requis, nous proposons une approche générale qui se base sur une analyse de la solution à développer à plusieurs niveaux. Cette analyse prend en compte à la fois les aspects fonctionnels, les exigences du marché, les aspects systèmes, la stratégie de développement et l’analyse de l’existant si le logiciel ciblé est en cours de développement.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_4.png" title="Figure 4. Flot d’analyse du niveau de qualité logicielle requis">}}
-
-Pour les aspects fonctionnels (figure 4.1), une analyse de risques est requise pour identifier les fonctionnalités les plus importantes, et analyser les conséquences de leurs défaillances au regard du contexte métier. A ce niveau, les risques encourus par le client en relation avec l’usage et au contexte métier sont prises en compte. Des exigences de sécurité ou de cybersécurité peuvent en être déclinées à partir de cette analyse. La volumétrie et la criticité des fonctionnalités du logiciel et l’importance des exigences de sécurité pourraient être des indicateurs importants à prendre en compte dans la définition d’un niveau de qualité requis.
-
-L’analyse de l’architecture système (figure 4.2) est nécessaire pour évaluer le niveau de tests requis à mettre en place. L’architecture système représente le logiciel qu’on souhaite développer dans son environnement global (solution IoT, pilotage d’une machine, logiciel embarqué sur une carte électronique pouvant être disponible ou en cours de conception, logiciel utilisé pour communiquer et piloter un autre logiciel, logiciel mobile qui doit se synchroniser avec d’autres applications, etc.). La complexité de l’architecture système est importante pour identifier les activités techniques de qualité requises. L’analyse de la démarche de développement (figure 4.3) consiste à analyser les éventuelles phases de prototypage prévues, et leurs objectifs. Nous analysons également la démarche de réutiliser les prototypes, et le nombre ainsi que le taux de complexité des verrous techniques à lever. Nous analysons à ce stade le taux de couverture des verrous techniques par les prototypes.
-
-L’analyse de l’existant (figure 4.4) concerne uniquement les logiciels en cours de développement. Il s’agit d’identifier les déficiences en qualité et de mesurer la dette technique associée. Nous analysons également les activités techniques de qualité déjà existantes.
-
-Le niveau de qualité global requis (figure 4) d’un développement logiciel est calculé à partir du besoin en qualité technique croisé avec le besoin en qualité fonctionnelle. Ces métriques sont suffisantes pour un projet en cours de démarrage. Pour les projets en cours, nous rajoutons des métriques liées à la dette technique.
-
-La qualité technique requise (figure 5) est mesurée à partir du niveau de complexité de l’architecture système et de la démarche de développement adoptée (prototypes, objectifs des prototypes, couverture des verrous techniques, etc.). La qualité fonctionnelle est mesurée à partir de l’analyse fonctionnelles des risques en identifiant les fonctionnalités critiques et leur poids dans l’application, ainsi que les exigences du marché et le contexte métier du logiciel.
-
-Pour simplifier la mesure des métriques, nous avons défini 3 niveaux de complexité par mesure :
-- L (Low) => Complexité Basse
-- M (Medium) => Complexité Moyenne
-- H (High) => Complexité Elevée
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_5.png" title="Figure 5. Niveau de complexité de la qualité technique requise" width="650">}}
-
-Dans notre démarche, nous proposons de classifier les niveaux de qualité qui en résultent en trois grandes catégories (voir figure 6). Le niveau 1 concerne le niveau de qualité que l’on voudrait atteindre pour un logiciel faisant partie d’une architecture système simple, sans verrous techniques importants à lever et avec des fonctionnalités non critiques. Le niveau 1 pourrait être un objectif de qualité raisonnable et réaliste pour des logiciels existants, ayant une dette technique élevée. Il peut être considéré comme le canot de sauvetage pour les projets en cours, souffrant de déficience de qualité, et qu’on souhaiterait maîtriser. Dans le niveau 1, nous préconisons le développement de tests fonctionnels en fixant un objectif de couverture de code élevée, sans faire de tests unitaires. L’automatisation des tests fonctionnels est fortement conseillée à ce niveau pour vérifier facilement les régressions. La gestion d’exigences et leurs traçabilités avec les tests fonctionnels est également conseillée.
-
-Le niveau 2 concerne les logiciels comportant certaines fonctionnalités critiques qui s’intègrent dans une architecture système moyennement compliquée, avec des verrous techniques identifiés et atteignables. Par rapport au niveau 1, des activités techniques de qualité supplémentaires doivent être faites uniquement pour l’implémentation des fonctionnalités critiques. En plus des tests fonctionnels, il est recommandé de faire des tests unitaires, des tests boites noires / blanches sur tous les composants logiciels utilisés par les fonctionnalités critiques. Des bancs de tests sont à développer également pour réaliser les tests sur la plateforme cible, ainsi que des tests systèmes et d’intégration.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_6.png" title="Figure 6. Calcul du niveau de qualité logicielle requis" width="750">}}
-
-Le niveau 3 concerne les logiciels comportant plusieurs fonctionnalités critiques dans une architecture système complexe, avec des verrous techniques identifiés et présentant des risques. Par rapport au niveau 2, les activités à faire sont : décrire l’architecture système, vérifier la cohérence entre l’architecture système et les exigences logicielles, gérer les liens de traçabilité, etc. Côté tests, des simulateurs de certains composants du système peuvent être développés pour écrire plus de tests d’intégration, de performance et de gestion d’erreurs (simulation de comportements erronés des sous-systèmes qui communiquent avec le logiciel). Pour le niveau 3, il est recommandé de construire une équipe d’assurance qualité qui va travailler avec les équipes de développement pour garantir la qualité des données produites. Un récapitulatif des niveaux de qualité, et des activités associées, est présenté dans le tableau 2.
-
-### B. Pratiques d’ingénierie pour répondre aux besoins de la qualité logicielle
-
-En plus des activités techniques de qualité que nous préconisons pour chaque niveau de qualité requis, nous pensons que la manière de les développer et de les organiser est aussi important que les activités elles-mêmes. Les pratiques d’ingénierie sont complémentaires aux activités techniques pour garantir un bon niveau de qualité et la fiabilité du logiciel.
-
-Nous préconisons par exemple de mettre l’accent sur l’automatisation des tests, pour vérifier rapidement les fonctionnalités ainsi que les non régressions. La mise en œuvre d’une plateforme d’intégration continue peut faciliter l’automatisation des tests. Mais certains peuvent se poser la question : En quoi l’automatisation des tests peut améliorer la qualité du logiciel ? Pour y répondre, prenons un exemple concret que nous avons vu lors de certaines de nos interventions. Dans une équipe de test logiciel, dont le rôle est de valider les développements logiciels, les testeurs déroulent manuellement un plan de test d’intégration d’un logiciel qui pilote une machine. Plus l’équipe de développement avance et livre de nouvelles fonctionnalités et plus le plan de test à dérouler se rallonge et devient difficile à maintenir. L’équipe de test se retrouve vite débordée. Elle n’arrive plus à finir les tests d’une version avant l’arrivée de la version suivante. L’équipe de test est devenue alors le goulot d’étranglement du cycle de développement logiciel. Elle se trouve obligée de livrer des versions partiellement testées, ce qui représente une source de défaillance de qualité.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_tableau_2.png" title="Tableau 2. Classification des niveaux de qualité requis pour un développement logiciel non soumis à une norme">}}
-
-Nous conseillons également une démarche de développement itérative et incrémentale qui représente un cadre pour développer un logiciel de qualité. Cette approche favorise la prise en compte des modifications fonctionnelles, et permet de rendre possible la révision et l’amélioration de certains choix et certains aspects du logiciel. La démarche itérative et incrémentale permet de livrer rapidement des fonctionnalités, avant la fin de la rédaction de toutes les spécifications de l’application. Cela permet d’identifier rapidement les problèmes et les erreurs injectées lors de la phase d’écriture des exigences.
-
-En adoptant une telle démarche itérative et incrémentale, le cycle de vie de développement logiciel (écriture d’exigences, tests, architecture, code, etc.) est appliqué plusieurs fois. Ces répétitions vont permettre son amélioration continue et l’efficience du processus va s’améliorer considérablement au fur et à mesure que le projet avance.
-
-Dans les normes décrites dans la section II concernant le développement de logiciels critiques, nous trouvons des objectifs à atteindre décrits et classés selon le niveau de criticité du logiciel. Notre approche de définition d’un niveau de qualité requis, pour les logiciels non soumis à des normes, ne se limite pas à la définition d’objectifs et d’activités techniques. Elle préconise également des pratiques d’ingénierie à mettre en œuvre. Cette vision de la qualité combine à la fois la fiabilité des données logicielles produites et l’efficience des processus et des activités techniques. Rendre certaines activités plus efficientes et plus fiables aura un impact direct sur la maitrise du budget et des délais de livraison.
-
-Nous pensons qu’il est pertinent que ces pratiques d’ingénierie soient communes à tous les niveaux de qualité requis. Il s’agit d’un ensemble de méthodes et d’outils ayant un coût dans les premières phases du projet. L’objectif de ces pratiques d’ingénierie est de ramener de l’efficience et de la rigueur dans le développement logiciel, en particulier, quand on adopte une démarche itérative et incrémentale.
-
-En faisant une comparaison des niveaux de qualité introduits dans cette section avec les niveaux de criticité définis dans les normes existantes de développement de logiciels critiques, nous pouvons, à titre indicatif, mentionner les équivalences suivantes :
-
-- Le niveau 3 peut correspondre au niveau DAL-C (DO-178C) / SIL2 (EN-50128)
-- Le niveau 2 peut correspondre à un niveau qui va se positionner entre le DAL-D et le DAL-C (DO-178C) / entre SIL1 et SIL 2 (EN-50128).
-- Le niveau 1 peut correspondre au niveau DAL-D (DO-178) / SIL 1 (EN-50128)
-
-Nous savons qu’un développement en DAL-C peut coûter environ +35% à +40% de surcoût par rapport à un développement classique. Nous estimons que la mise en œuvre du niveau 3 correspond à ~30% de coût supplémentaire à prévoir (activités techniques de qualité et pratiques d’ingénierie), puisque ce niveau n’intègre pas toutes les activités de la DO-178C DAL-C. Pour le niveau 2, nous estimons le coût supplémentaire entre 20% et 25% et entre 10% et 15% pour le niveau 1.
-
-Ce surcoût reste un très bon investissement comparé aux surcoûts de maintenance pour des développements de logiciels ayant des déficiences de qualité. Dans ce cas, le coût de maintenance représente au moins 60% du coût total de développement logiciel, et ~50 % des coûts de maintenance concernent la gestion et la correction des anomalies.
-
-### C. Stratégie de Test
-
-Tout au long de la crise sanitaire liée au virus COVID-19, le mot d’ordre était « faire des tests, plus de tests, et des tests rapides pour identifier le plutôt possibles les personnes contaminées ». Dans le monde du logiciel, les tests sont également indispensables pour maîtriser la qualité du logiciel et garantir sa fiabilité. Les tests permettent de vérifier que les exigences ont été correctement implémentées et pour identifier les anomalies.
-
-Si l’équipe projet n’écrit pas suffisamment de tests, ou les écrit tard dans le processus de développement, les anomalies seront découvertes également tard dans le cycle de vie de développement logiciel. Il s’agit d’une course pour identifier les erreurs avant qu’elles ne soient plus rattrapables. Le coût de résolution d’une anomalie logicielle évolue exponentiellement en fonction du moment de sa découverte. Dans [Jones Capers], l’auteur estime que le coût de résolution d’une anomalie peut être multiplié par 4 si elle est découverte par les tests unitaires et par 10 si elle est découverte par les tests fonctionnels. Ce coût explose rapidement quand l’anomalie est découverte par des tests systèmes (x 40). Le coût peut être multiplié par 640 quand l’anomalie n’est pas découverte lors du cycle de vie de développement et quand elle apparaît après la livraison.
-
-Dans les processus de développement logiciel itératifs et incrémentales que nous avons mis en œuvre jusqu’à maintenant, la gestion des anomalies représente 8% à 10% du temps total de développement avec un vélocité de 1,5 jours pour la correction d’une anomalie. La détection rapide des anomalies explique bien ces métriques.
-
-Ainsi, la qualité logicielle devient une variable indispensable pour l’équilibre des projets (maîtrise de budget, maîtrise des délais). Considérer la qualité comme une variable d’ajustement dans un projet implique forcément une perte de la maîtrise du projet au niveau de la fiabilité, du budget et des délais.
-
-Pour identifier les anomalies et les maîtriser tôt dans le cycle de vie de développement logiciel, nous proposons dans les niveaux de qualité requis plusieurs activités techniques et des pratiques d’ingénierie associées. L’objectif des activités techniques est de fournir une couverture complète du code et des scénarios d’exécution des fonctionnalités à travers des tests (unitaires, fonctionnels, systèmes, boites blanches, boites noires, etc.), ayant un jeu données complet. L’objectif des pratiques d’ingénierie est de garantir la rapidité de l’exécution des tests et leur intégration au plus tôt dans les processus de développement. Cela peut être fait en utilisant les techniques et les outils TDD (Test Driven Development) et BDD (Behaviour Driven Development). Nous préconisons l’écriture des scénarios de tests au même moment que les exigences, et par la même personne pour éviter de potentielles incompréhensions des exigences par les développeurs. Nous estimons que la personne qui écrit l’exigence est la mieux placée pour décrire le test correspondant. Ainsi, nous pouvons vérifier très tôt dans le processus que toutes les exigences sont vérifiables puisqu’on dispose d’un scénario de test avec un jeu de données par exigence. L’équipe de développement implémente l’exigence et le scénario de test en même temps, sans le modifier.
-
-{{< figure src="/img/article_niveau_qualite/2020_09_15_qualite_figure_7.png" title="Figure 7. Détection des anomalies : Impact sur les coûts de corrections [Capers2008] [Hicken2018]" width="700">}}
-
-L’intégration d’un outillage d’automatisation d’exécution des tests TDD/BDD, tel une plateforme d’intégration continue, avec la génération de rapports de tests, donne à l’équipe de développement un outil puissant pour exécuter rapidement les nouveaux tests, ainsi que les tests de non régression.
-A Sogilis, nous avons développé le framework de test BDD XReq (eXecutable Requirements) [Xreq], dédié pour le développement de logiciels embarqués (en Ada et en C/C++). Les rapports de tests natifs, ou croisés sont générés et intégrés automatiquement dans la plateforme d’intégration continue.
-
-### D. Garantir un niveau de qualité en continu
-
-Parmi les principaux avantages de la mise en œuvre des pratiques d’ingénierie mentionnées dans le tableau 2, nous pouvons évoquer la garantie de livrer à chaque fin d’une tâche une version ayant le niveau de qualité requis des données développées jusque-là. La qualité n’est plus une variable qu’on peut ajuster quand le projet dérape, mais plutôt un critère de livraison de chaque tâche et de chaque incrément du développement logiciel. Combiner les activités techniques de qualité aux pratiques d’ingénierie (Tableau 2) permet d’intégrer plus étroitement les activités de qualité au cycle de vie de développement logiciel. Cela permet d’apporter de façon continue des garanties du niveau de qualité requis.
-
-La pression de livrer rapidement et en continu des logiciels fonctionnels en respectant des contraintes de coûts et de délais a été toujours un argument des équipes de projets pour laisser de côté les activités de qualité. La solution consiste à coupler fortement les activités de qualité aux activités de développement dans le cycle de vie de développement logiciel. Ce couplage fort passe par une définition claire d’une tâche « terminée / done». Une tâche serait considérée comme « terminée » si et seulement si toutes les activités techniques de développement et de vérification ont été bien réalisées. La plateforme d’intégration continue servira simplement d’outil pour exécuter systématiquement toutes les activités de la chaîne de livraison : compilation, exécution de tous les tests, vérification des cohérences entre les données développées, calcul des métriques de qualité, packaging, etc.
-
-## IV. Conclusions
-
-En résumé, nous avons exposé, dans cet article, la problématique de la qualité logicielle des développements non soumis à des normes industrielles sectorielles. Nous avons proposé une approche pour mesurer le niveau de qualité requis d’un logiciel en fonction de plusieurs critères, à savoir, la complexité fonctionnelle, le contexte métier, les exigences du marché, la complexité technique et le niveau de la dette technique.
-
-Dans notre proposition, l’atteinte du niveau de qualité requis passe par la mise en œuvre d’activités de qualité techniques et par la mise en œuvre de pratiques d’ingénierie innovantes (Tests TDD/BDD, développement itératif et incrémental, Intégration continue, etc.).
-
-L’investissement dans la qualité logicielle garantit une fiabilité et une qualité continue du logiciel sur sa durée de vie et sur ses versions postérieures. C’est également une garantie pour mieux maîtriser les budgets et les délais, et surtout pour diminuer d’une manière considérable les coûts de maintenance.
-
-## V. Références bibliographiques
-
-**[iec61805]** : International Electrotechnical Commission, “Functional Safety and IEC 61805”, https://www.iec.ch/functionalsafety/standards/
-
-**[Gibbs94]** : W. Gibbs, “Software's Chronic Crisis”, Scientific American 271 (3), 1994, pp. 86-95.
-[Dij79] Edsger Dijkstra, Le programmeur Humble (PDF), Dans Classics en génie logiciel, Yourdon Press, 1979.
-
-**[Louis2019]** : V. Louis, C. Baron “ Vers une certification continue de logiciels critiques en aéronautique », Novembre 2019, « https://hal.archives-ouvertes.fr/hal-02372069 »
-
-**[Yu2009]** : A. G. Yu, "Software Crisis, What Software Crisis ?, « 2009 International Conference on Management and Service Science, Wuhan, 2009, pp. 1-4.
-
-**[Hilderman 2009]** : Hilderman, Vance. “DO-178B Costs Versus Benefits”, https://vancehilderman.com/2015/12/23/do-178c-costs-versus-benefits/
-
-**[Fitz2012]** : B. Fitzgerald, "Software Crisis 2.0," in Computer, vol. 45, no. 4, pp. 89-91, April 2012.
-
-**[Spector86]** : Alfred Z. Spector, David K. Gifford: “A Computer Science Perspective of Bridge Design. Commun. ACM 29(4): 267-283 (1986)
-
-**[Chaosreport18]** : https://www.standishgroup.com/store/
-
-**[Capers2008]** : C. Jones. 2008. Applied Software Measurement: Global Analysis of Productivity and Quality (3 ed.). McGraw-Hill Osborne Media.
-
-**[Hicken2018]** : A. Hicken. 2018, “The Shift-Left Approach to Software Testing », https://www.stickyminds.com/article/shift-left-approach-software-testing
-
-**[Xreq]** : https://sogilis.com/services-safety-critical.html
-
-
-
diff --git a/site/content/posts/2020-10-27-uas_cybersecurity.md b/site/content/posts/2020-10-27-uas_cybersecurity.md
deleted file mode 100644
index dde36d142..000000000
--- a/site/content/posts/2020-10-27-uas_cybersecurity.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: Toward Cybersecurity - UAS operations use case
-author: Duc, Amin
-date: 2020-10-26
-image: /img/article_uas_cybersecurity/2020_10_27_cybersecurity.jpg
-categories:
- - DÉVELOPPEMENT
-tags:
- - code
- - dev
- - cybersecurity
- - drone
----
-***Abstract —* For several years, the civil Unmanned Aircraft System (UAS) has become more and more popular with many applications such as aerial photography, goods transportation, surveillance, etc. However, the lack of human observation, communication capacities, and protection makes UAS a good target for cyber-attacks. Therefore, the risk related to the cybersecurity of UAS should be assessed and taken into account in the early phase of UAS development.**
-
-## I. Introduction
-
-To deal with the progressive increase in the number of UAS operations, the European Aviation Safety Agency (EASA) classified UAS operations into three categories according to their risk levels: **Open**, **Specific** and **Certified**. In the **Specific** category, we could expect the operation of large drones flying above populated areas, out of the visual line of sight of the pilot and sharing the airspace with manned aircrafts. These operations could pose significant harm to the people overflown and the manned aircraft, especially in the case of a cyber-attack.
-To the best of our knowledge, the most common risk assessment methodology in the UAS domain is Specific Operation Risk Assessment (SORA), which is endorsed by the European Union Aviation Safety Agency (EASA) as an acceptable means to fulfill the requirements of the EU regulations related to UAS. However, at this moment, the methodology focuses on only the safety aspect and ignores the cybersecurity aspect.
-
-## II. General concept of the SORA methodology
-
-### A. Risk Model
-
-At this moment, the SORA methodology considers only risks of harms to a person’s life: “fatal injuries to third parties on ground”, “fatal injuries to third parties in air”. To illustrate the risk scenarios related to these harms (or how these harms could happen), the methodology provides a risk model as shown in Figure 1. It includes three major segments: Harms, Hazard, Threats. The direct causes of these harms is a generic hazard “UAS operation out of control” shown in the center of the model. This hazard is defined as an operation being conducted outside of the operator’s intention
-(e.g the aircraft flies outside of visual observation of the pilot in a Visual Line Of Sight operation). The hazard could be caused by several threats which are grouped into categories in the left part of the model. Because SORA methodology considers only the safety aspect but not the security aspect, only unintentional threat categories are represented in the model.
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_001.png" title="Figure 1. Risk Model of the SORA methodology" width="700">}}
-
-### B. Assessment process
-
-1) Quantitative approach:
-Traditionally, the risk assessment process requires to analyze two parameters of risk:
-- Likelihood,
-- Severity.
-
-However, the risks in the SORA methodology is tied to only likelihood parameters because the methodology basically focuses on only risks of harms to the person’s life. The severity of these harms could be considered as extremely high. In other words, the safety objectives will be determined to maintain the likelihood of each harm under the acceptable value (10-6 fatal injuries per flight hour, equivalent to some manned aircraft operation).
-
-2) Qualitative approach:
-The SORA methodology proposes a qualitative approach based on the main ideas of the quantitative approach. First, we determine two qualitative factors:
-- Ground Risk Class (GRC),
-- Air Risk Class (ARC).
-
-These factors represent qualitatively the likelihoods that the harms occur in the case of UAS operation out of control. The GRC and ARC are determined based on the intrinsic characteristics of the operation such as operational area, attitude, weight of the UAS and the availability of harm barriers.
-
-Then, we determine two Specific Assurance and Integrity Levels (SAIL) values, which represent the
-level of confidence that the UAS operation will stay under control. One SAIL value corresponds to GRC and the other corresponds to ARC. Then, the higher SAIL value will be chosen as an objective to drive the required safety objectives.
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_002.png" title="Figure 2. SAIL Determination" width="300" align="center">}}
-
-## III. Toward Cybersecurity
-
-Our proposed solution consists of two parts which are called Harm Extension and Threat Extension.
-
-**Harm Extension** extends the risk scenarios under consideration with new harms; and completes the evaluation of critical level of a given UAS operation.
-
-**Threat Extension** extends the scenarios under consideration with new cybersecurity threats; and determines the corresponding threat barriers for a given UAS operation.
-
-In Harm Extension, we concern the harm-side of the risk model. Besides the harms to the person’s life, the public concerns also the other harms such as:
-- Privacy Violation
-- Physical damages to infrastructure
-- Digital damages to infrastructure
-
-Therefore, these new harms come to mind as important issues that should be taken into account in the methodology. In Harm Extension, our strategy to address the new harms includes four steps as follows:
-
-1) Chose a new harm that needs to be addressed
-2) Determine factors/characteristics of the UAS operation, which have an impact on the likelihood of the chosen harm.
-3) Establish formulas or tables to evaluate qualitatively the likelihood based on the determined factors
-4) Extend “SAIL determination” step to cover the likelihood of the new harm.
-
-In Threat Extension, we will concern the threat-side of the risk model. The potential cybersecurity threats need to be identified and grouped in new threat categories. To illustrate the new scenarios, the new threat categories will be added into the threat-side of the risk model as shown in Figure 3. Corresponding to each new threat category, a list of possible threat barriers will be also established. For a given UAS operation, the new threat barriers are chosen in correspondence with the value of the SAIL factor.
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_003.png" title="Figure 3. Extended risk model" width="700" align="center">}}
-
-## IV. Cybersecurity for privacy issues in UAS operations
-
-Nowadays, the privacy violation is one of the most concerned issues for public acceptance of UAS application. However, the general privacy is a very large term and it’s difficult to define it precisely and to address it. We will focus on only three aspects of this harm:
-
-1) Disclosure of personal information,
-2) Illegal personal surveillance,
-3) Intrusion into private location.
-
-We first analyze the likelihood of the privacy violation to determine the possible factors related to this harm, which could be used for the assessment. Then we propose extensions for the assessment process by adding a new step called “Privacy Risk Class (PRC) determination”. With the privacy harm taken into account, the objective of risk assessment is extended to maintain the harm likelihood to privacy under a certain acceptable level.
-
-Similar to the likelihood of harms to the person’s life, the one of the privacy harm could be decomposed as shown in Figure 4. The combination of the two components (2) and (3) of this equation represents the likelihood that the privacy of third parties is violated after ”UAS operation out of control”.
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_004.png" title="Figure 4. Likelihood of privacy violation" width="700" align="center">}}
-
-We identified three intrinsic features of a UAS operation to evaluate the likelihood of privacy violation in case of “UAS operation out of control”:
-
-- Density of operational area: urban zone vs. rural zone,
-- Type of operation: BLOS vs. BVLOS (Beyond Visual Line of Sight),
-- Level of detail of the captured images.
-
-Similar to harms introduced in the classical SORA methodology, the likelihood of privacy harm could be reduced by applying some harm barriers. In this extension, we address three types of harm barriers to mitigate the privacy harms:
-
-- Privacy protection filters: these algorithms reduce unnecessary information that could violate the privacy of person from the video/image such as Blurring, Pixelization, Masking, Warping
-- Restriction on private space: the operator avoids making a flight path across a private space
-- Operation-aware announcement to public: the public under observation of a UAS operation should be informed about it.
-
-The likelihood of privacy violation in the case of “UAS operation out of control” is represented qualitatively by the Privacy Risk Class (PRC) value. The intrinsic PRC value is determined based on the intrinsic features of operation as shown in Figure 5.
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_005.png" title="Figure 5. Intrinsic PRC Determination" width="600" align="center">}}
-
-{{< figure src="/img/article_uas_cybersecurity/uas_cybersecurity_006.png" title="Figure 6. PRC Correction factor of harm barriers" width="600" align="center">}}
-
-Then the determined intrinsic PRC could be reduced by the harm barriers: “Privacy protection filters”, “Restriction on private space” and “Operation-aware announcement to public”. Each harm barrier corrects the intrinsic PRC with a reduction factor shown in figure 6.
-
-According to figure 5, the intrinsic PRC is at the C level. Upon analysis of the privacy issue, the operator decides to upgrade the onboard camera with a digital filter that makes image of a person blur and unable to be recognized. In this case, the PRC is reduced with 1 level from the C to B level.
-
-The last step consists in new SAIL determination, the process is described as follows:
-
-1) Determine a SAIL corresponding to the values of ARC and GRC (see Figure. 2) (classical SORA methodology). This value is called 2D-SAIL.
-2) Determine SAIL value corresponding to PRC value.
-3) Choose the higher SAIL value (more critical) between the two determined SAIL values as the 3D-SAIL or the final SAIL corresponding to the operation.
-
-The 2D-SAIL and 3D-SAIL mentioned above are two different values. The main different point between them
-is only the way that they are determined. The 2D-SAIL is a combination of GRC and ARC without taking into account PRC (privacy harm). Meanwhile 3D-SAIL takes into account the privacy harm. But both of them represent the level of confidence that “the UAS operation will stay under control” that needs to be achieved.
-
-## V. Conclusions
-
-The risk assessment process could be resumed as:
-
-1) Evaluation of the critical level of a UAS operation based on the likelihood of harms,
-2) Determination of safety objectives corresponding to the critical level.
-
-Based on this concept, we proposed a general approach to extend the existing methodology to support cybersecurity aspect by adding new relevant threats and harms. New harms will be taken into account to evaluate the critical level of the UAS operation. Meanwhile, new threats will be added to anticipate new causes of incidents related to cybersecurity and determine corresponding means of mitigation (or cybersecurity objectives).
diff --git a/site/static/.keep b/site/static/.keep
deleted file mode 100644
index e69de29bb..000000000
diff --git a/site/static/admin/config.yml b/site/static/admin/config.yml
deleted file mode 100644
index 82e314e1b..000000000
--- a/site/static/admin/config.yml
+++ /dev/null
@@ -1,51 +0,0 @@
-backend:
- name: git-gateway
-publish_mode: editorial_workflow
-media_folder: 'site/static/img' # Folder where user uploaded files should go
-public_folder: '/img' # The src attribute for uploaded media will begin with this
-
-collections: # A list of collections the CMS should be able to edit
- - name: 'post' # Used in routes, ie.: /admin/collections/:slug/edit
- label: 'Post' # Used in the UI, ie.: "New Post"
- folder: 'site/content/posts' # The path to the folder where the documents are stored
- create: true # Allow users to create new documents in this collection
- fields: # The fields each document in this collection have
- - { label: 'Title', name: 'title', widget: 'string' }
- - { label: 'Publish Date', name: 'date', widget: 'datetime' }
- - { label: 'Intro Blurb', name: 'description', widget: 'text' }
- - {
- label: 'Image Alt',
- name: 'altimage',
- widget: 'string',
- required: false,
- }
- - { label: 'Image', name: 'image', widget: 'image', required: false }
- - label: 'Tags'
- name: 'tags'
- widget: 'select'
- required: true
- multiple: true
- options:
- [
- 'dev',
- 'test',
- 'sécurité',
- 'design',
- 'conférences',
- 'process',
- 'vie à Sogilis',
- ]
- - { label: 'Body', name: 'body', widget: 'markdown' }
-
-# Working with a Local Git Repository
-# ==============================================================================
-# Beta Features
-# added in netlify-cms@2.10.17 / netlify-cms-app@2.11.14 (02/2020)
-# Use these features at your own risk.
-# https://www.netlifycms.org/docs/beta-features/#working-with-a-local-git-repository
-
-# when using the default proxy server port
-local_backend: true
-# when using a custom proxy server port
-# local_backend:
-# url: http://localhost:8081/api/v1
diff --git a/site/static/admin/index.html b/site/static/admin/index.html
deleted file mode 100644
index 13d934321..000000000
--- a/site/static/admin/index.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
-
-
+ Back
-{{< /highlight >}}
+```
-{{< highlight js "hl_lines=5">}}
+```js{5}
it('goes to the previous page when back button is clicked', () => {
// mock goToPreviousPage method
wrapper.vm.goToPreviousPage = jest.fn()
@@ -72,20 +73,20 @@ it('goes to the previous page when back button is clicked', () => {
expect(wrapper.vm.goToPreviousPage).toHaveBeenCalled()
})
-{{< /highlight >}}
+```
Now our unit test has become resilient to design changes because we used data attribute as css selector.
## This tip has some drawbacks
-* Bigger HTML, degraded readability.
-* Take time to add data attributes.
+- Bigger HTML, degraded readability.
+- Take time to add data attributes.
## See also
-* W3C official definition: https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#custom-data-attribute
-* MDN explanations: https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
-* W3Schools summary: https://www.w3schools.com/tags/att_data-.asp
+- W3C official definition: https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#custom-data-attribute
+- MDN explanations: https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
+- W3Schools summary: https://www.w3schools.com/tags/att_data-.asp
**Alban Bertolini**
diff --git a/site/content/posts/2020-10-02-retex-bdd-do178c.md b/blog/_posts/2020-10-02-retex-bdd-do178c.md
similarity index 68%
rename from site/content/posts/2020-10-02-retex-bdd-do178c.md
rename to blog/_posts/2020-10-02-retex-bdd-do178c.md
index 91c17a5ca..9206478d4 100644
--- a/site/content/posts/2020-10-02-retex-bdd-do178c.md
+++ b/blog/_posts/2020-10-02-retex-bdd-do178c.md
@@ -4,38 +4,37 @@ author: MousS'
date: 2020-10-02
image: /img/20201002/drone.jpg
categories:
- - DÉVELOPPEMENT
+ - Développement logiciel
tags:
- do-178c
- bdd
- xreq
-
---
## Introduction
Dans le cadre du projet de recherche **CAP 2018**, nous avons été amenés à développer le logiciel d’un contrôleur de vol pour drone en conformité avec le standard aéronautique **DO-178C**. Le processus de développement logiciel mis en place par l’équipe a intégré plusieurs pratiques provenant du **BDD** : le Behaviour-Driven Development. Cet article constitue un retour d’expérience qui explique les raisons pour lesquelles ces pratiques ont été mises en place et comment elles nous ont aidé à répondre à un certains nombre de problématiques. Nous présentons donc ici la solution vers laquelle l’équipe a finalement aboutie, qui a conciliée l’approche **BDD** avec la réalisation d’un logiciel soumis à de fortes contraintes de développement. Nous abordons également l’outil **XReq** supportant le **BDD** que nous avons développé et utilisé, et les raisons qui nous ont amené à créer et à faire évoluer notre propre outil plutôt que d’en utiliser un déjà existant.
-
## Contexte du projet
Le retour d’expérience abordé dans cet article s’appuie sur le projet de recherche et développement **CAP 2018** concernant la réalisation d’un contrôleur de vol pour drone en conformité avec le standard aéronautique **DO 178C DAL A** (le niveau le plus critique) : **PULSAR**. Le processus de développement mis en place par l’équipe est un processus itératif incrémental qui intègre plusieurs pratiques issues du **BDD**. L’objectif de l’équipe lors de la mise en place de ce processus était d’allier :
- * l’efficacité de l’itératif incrémental qui permet une détection des erreurs liées au développement au plus tôt,
- * la rigueur du standard aéronautique ayant pour but de cibler un logiciel fiable et ne contenant pas de défaut à terminaison.
+- l’efficacité de l’itératif incrémental qui permet une détection des erreurs liées au développement au plus tôt,
+- la rigueur du standard aéronautique ayant pour but de cibler un logiciel fiable et ne contenant pas de défaut à terminaison.
+
+Le standard **DO-178C** pour un niveau **DAL A**, requiert de produire plusieurs types de données. La liste qui suit n’est pas exhaustive mais identifie les données auxquelles nous nous intéressons dans cet article et leur périmètre dans le cadre de notre projet :
-Le standard **DO-178C** pour un niveau **DAL A**, requiert de produire plusieurs types de données. La liste qui suit n’est pas exhaustive mais identifie les données auxquelles nous nous intéressons dans cet article et leur périmètre dans le cadre de notre projet :
- * Les *HLR* (High Level Requirement) : Exigences de haut niveau, il s’agit d’exigences dont le périmètre est celui du logiciel dans son ensemble.
- * Les *LLR* (Low Level Requirement) : Exigences de bas niveau, il s’agit d’exigences dont le périmètre correspond à celui d’une brique logicielle.
- * Le code
- * Les *HLT* (High Level Test) : Tests de haut niveau, qui ont pour but de vérifier que le comportement du logiciel est conforme aux *HLR* (tests boîte noire)
- * Les *LLT* (Low Level Test) : Tests de bas niveau, qui ont pour but de vérifier que le code est conforme aux *LLR* (tests boîte blanche)
+- Les _HLR_ (High Level Requirement) : Exigences de haut niveau, il s’agit d’exigences dont le périmètre est celui du logiciel dans son ensemble.
+- Les _LLR_ (Low Level Requirement) : Exigences de bas niveau, il s’agit d’exigences dont le périmètre correspond à celui d’une brique logicielle.
+- Le code
+- Les _HLT_ (High Level Test) : Tests de haut niveau, qui ont pour but de vérifier que le comportement du logiciel est conforme aux _HLR_ (tests boîte noire)
+- Les _LLT_ (Low Level Test) : Tests de bas niveau, qui ont pour but de vérifier que le code est conforme aux _LLR_ (tests boîte blanche)
Dans un processus traditionnel en cycle V (modèle en cascade) ces données sont représentées de la manière suivante :
-Dans ce type de cycle, on va développer les données par types : d’abord toutes les exigences, puis le code et enfin les tests. La détection d’un défaut par les tests (*HLT* ou *LLT*) se fait en fin de cycle. Il peut donc s’écouler un temps relativement long entre la production des données et la détection puis la correction d’un problème dans les exigences (*HLR* ou *LLR*) ou le code.
+Dans ce type de cycle, on va développer les données par types : d’abord toutes les exigences, puis le code et enfin les tests. La détection d’un défaut par les tests (_HLT_ ou _LLT_) se fait en fin de cycle. Il peut donc s’écouler un temps relativement long entre la production des données et la détection puis la correction d’un problème dans les exigences (_HLR_ ou _LLR_) ou le code.
Un processus de développement itératif incrémental préconise de développer l’intégralité d’une fonctionnalité, et donc toutes les données qui s’y rapportent, avant de passer à la fonctionnalité suivante. Dans ce type de processus, la durée des cycles dépend de la fonctionnalité à implémenter ce qui la rend beaucoup plus courte que dans un cycle en V. La détection d’un défaut par les tests se fait donc de manière beaucoup plus rapide.
On pourrait schématiser de manière simpliste le processus itératif incrémental comme étant une succession de petits cycles en V qui s’enchaînent.
@@ -50,10 +49,11 @@ Le Behavior-Driven Development consiste à identifier de manière exhaustive l
Dans le cadre de notre projet, tirer crédit de l’expression des comportements à la fois en terme d’exigences et de tests semblait compliqué pour pouvoir satisfaire tous les objectifs demandés par le standard aéronautique. C’est pourquoi, nous avons maintenu les exigences d’une part, et utilisé d’autre part les scénario comportementaux en tant que tests.
-L’impact lié au **BDD** sur notre processus de développement itératif incrémental s’est fait sur les deux niveaux d’exigences *HLR* et *LLR*, et a eu les répercussions suivantes sur le cycle de production des données :
- * A haut niveau (*HLR* / *HLT*) : Pour une fonctionnalité, on exprime l’ensemble des besoins relatifs à la fonctionnalité en spécifiant les *HLR*. On identifie en parallèle les comportements du logiciel attendus sur un ensemble de jeux de tests exhaustifs exprimés au travers des cas de tests et des procédures de tests qui constituent les *HLT*. Au cours de cette étape, les incohérences entre ces deux types de données tels que les trous de spécifications ou les ambiguïtés sont corrigés. Une fois ces deux types de données finalisées, elles sont vérifiées. Cette vérification est requise par le standard aéronautique et a pour but de s’assurer que les objectifs **DO-178C** ont bien été atteints de manière à avoir un niveau de confiance élevé sur le fait que les données ne contiennent plus de défaut. Si ce n’est pas le cas, les données sont corrigées avant de pouvoir passer à l’étape suivante.
- * A bas niveau (*LLR* / *LLT*) : Pour chaque brique logicielle impliquée dans la réalisation de la fonctionnalité, on exprime les besoins que doit remplir la brique qui entre en oeuvre dans la fonctionnalité au travers des *LLR*. On identifie en parallèle les comportements attendus de cette brique logicielle sur un ensemble de jeux de tests exhaustifs exprimés au travers des cas de tests et des procédures de tests qui constituent les *LLT*. Une fois ces données finalisées, elles sont vérifiées et les défauts sont corrigés avant de pouvoir passer à la phase de codage.
-
+L’impact lié au **BDD** sur notre processus de développement itératif incrémental s’est fait sur les deux niveaux d’exigences _HLR_ et _LLR_, et a eu les répercussions suivantes sur le cycle de production des données :
+
+- A haut niveau (_HLR_ / _HLT_) : Pour une fonctionnalité, on exprime l’ensemble des besoins relatifs à la fonctionnalité en spécifiant les _HLR_. On identifie en parallèle les comportements du logiciel attendus sur un ensemble de jeux de tests exhaustifs exprimés au travers des cas de tests et des procédures de tests qui constituent les _HLT_. Au cours de cette étape, les incohérences entre ces deux types de données tels que les trous de spécifications ou les ambiguïtés sont corrigés. Une fois ces deux types de données finalisées, elles sont vérifiées. Cette vérification est requise par le standard aéronautique et a pour but de s’assurer que les objectifs **DO-178C** ont bien été atteints de manière à avoir un niveau de confiance élevé sur le fait que les données ne contiennent plus de défaut. Si ce n’est pas le cas, les données sont corrigées avant de pouvoir passer à l’étape suivante.
+- A bas niveau (_LLR_ / _LLT_) : Pour chaque brique logicielle impliquée dans la réalisation de la fonctionnalité, on exprime les besoins que doit remplir la brique qui entre en oeuvre dans la fonctionnalité au travers des _LLR_. On identifie en parallèle les comportements attendus de cette brique logicielle sur un ensemble de jeux de tests exhaustifs exprimés au travers des cas de tests et des procédures de tests qui constituent les _LLT_. Une fois ces données finalisées, elles sont vérifiées et les défauts sont corrigés avant de pouvoir passer à la phase de codage.
+
Le processus de développement logiciel mis en place peut donc être représenté de la manière suivante :
@@ -62,65 +62,69 @@ Le processus de développement logiciel mis en place peut donc être représent
Lors de la mise en place de notre processus de développement logiciel, l’équipe a été confronté à plusieurs problématiques. Certaines d’entre elles ont pu être résolues au travers de pratiques provenant du **BDD**.
-Une des principales raisons était une volonté de l’équipe d’avoir des données vérifiées ne contenant plus de défaut avant d’avancer dans les étapes du développement. En effet, plus un défaut est détecté tard plus son impact est important car le nombre de données sur lesquelles il se répercute augmente au fil des développements. Cela implique :
- * La vérification des *HLR* et des *HLT* avant l’écriture des *LLR* et des *LLT*,
- * La vérification des *LLR* et des *LLT* avant l’écriture du code.
+Une des principales raisons était une volonté de l’équipe d’avoir des données vérifiées ne contenant plus de défaut avant d’avancer dans les étapes du développement. En effet, plus un défaut est détecté tard plus son impact est important car le nombre de données sur lesquelles il se répercute augmente au fil des développements. Cela implique :
+
+- La vérification des _HLR_ et des _HLT_ avant l’écriture des _LLR_ et des _LLT_,
+- La vérification des _LLR_ et des _LLT_ avant l’écriture du code.
De cette manière on garantit la maturité des entrants de chaque type de données avant leur production.
-La vérification des exigences *HLR* et *LLR* passe par l’atteinte d’un certain nombre d’objectifs du standard **DO-178C**, dont certains sont assurés par l’écriture des données de tests correspondantes (*HLT* et *LLT*). L’approche **BDD** est donc plutôt adaptée pour répondre à cette problématique et permet de vérifier les points suivants :
- * La *testabilité* : si le besoin exprimé dans l’exigence est testable alors on doit être en mesure de pouvoir observer des comportements du logiciel relatif à ce besoin. L’écriture des cas de tests et des procédures de tests (aussi bien *HLT* que *LLT*) met en évidence cette testabilité.
- * La *précision et la cohérence des exigences* : un problème de précision ou de cohérence peut se traduire par une ambiguïté sur le comportement attendu du logiciel. L’écriture des jeux de tests permet de détecter un défaut de cette nature et donc de corriger l’exigence en conséquence pour lever les ambiguïtés.
- * La *couverture de l’exigence par les tests* : Cet objectif a pour but de vérifier que l’intégralité des besoins exprimés dans les exigences soient couverts par des tests. L’écriture des jeux de tests en parallèle de l’écriture des exigences permet de faire l’analyse de cette couverture au plus tôt et d’identifier rapidement certains problèmes tels qu’un trou de spécification.
+La vérification des exigences _HLR_ et _LLR_ passe par l’atteinte d’un certain nombre d’objectifs du standard **DO-178C**, dont certains sont assurés par l’écriture des données de tests correspondantes (_HLT_ et _LLT_). L’approche **BDD** est donc plutôt adaptée pour répondre à cette problématique et permet de vérifier les points suivants :
+
+- La _testabilité_ : si le besoin exprimé dans l’exigence est testable alors on doit être en mesure de pouvoir observer des comportements du logiciel relatif à ce besoin. L’écriture des cas de tests et des procédures de tests (aussi bien _HLT_ que _LLT_) met en évidence cette testabilité.
+- La _précision et la cohérence des exigences_ : un problème de précision ou de cohérence peut se traduire par une ambiguïté sur le comportement attendu du logiciel. L’écriture des jeux de tests permet de détecter un défaut de cette nature et donc de corriger l’exigence en conséquence pour lever les ambiguïtés.
+- La _couverture de l’exigence par les tests_ : Cet objectif a pour but de vérifier que l’intégralité des besoins exprimés dans les exigences soient couverts par des tests. L’écriture des jeux de tests en parallèle de l’écriture des exigences permet de faire l’analyse de cette couverture au plus tôt et d’identifier rapidement certains problèmes tels qu’un trou de spécification.
Une autre raison importante était une autre volonté de l’équipe de garantir la mise en place de tests cohérents des besoins exprimés dans les exigences (de même granularité). C’est à dire, des tests ne vérifiant que ce qui est exprimé au travers des exigences, quelle que soit la manière dont les exigences sont implémentées. Cela signifie :
- * Des *HLT* complètements indépendants de ce qui est exprimé dans les *LLR*,
- * Des *LLT* complètements indépendants de l’implémentation du code.
+
+- Des _HLT_ complètements indépendants de ce qui est exprimé dans les _LLR_,
+- Des _LLT_ complètements indépendants de l’implémentation du code.
En écrivant les scénarios de tests avant toute implémentation comme le préconise le **BDD**, on répond à notre problématique, car il est difficile de se faire influencer par une donnée si celle-ci n’existe pas.
Dans un processus en cycle en V, comme les tests sont produits en fin de cycle de développement, il est possible de se retrouver avec des tests vérifiant à la fois les besoins exprimés dans les exigences et la manière dont celles-ci sont implémentées.
-*Par exemple, si on considère une exigence spécifiant que sous certaines conditions une LED verte doit s’éclairer pendant 3 secondes, l’opération de contrôle effectuée au moment du test devrait être du type “la LED verte s’éclaire pendant 3 secondes”. Si le code développé s’appuie sur une boucle d’exécution de période 100 millisecondes, et qu’on écrit le test ensuite, on peut facilement être amené à remplacer l’opération de contrôle par “la LED verte s’éclaire pendant 30 cycles”. Par la suite, si l’implémentation du code est modifiée et que la période de la boucle d’exécution est changée, cette deuxième opération de contrôle devra être corrigée alors que le besoin exprimé dans l’exigence n'aura pas changé.*
+_Par exemple, si on considère une exigence spécifiant que sous certaines conditions une LED verte doit s’éclairer pendant 3 secondes, l’opération de contrôle effectuée au moment du test devrait être du type “la LED verte s’éclaire pendant 3 secondes”. Si le code développé s’appuie sur une boucle d’exécution de période 100 millisecondes, et qu’on écrit le test ensuite, on peut facilement être amené à remplacer l’opération de contrôle par “la LED verte s’éclaire pendant 30 cycles”. Par la suite, si l’implémentation du code est modifiée et que la période de la boucle d’exécution est changée, cette deuxième opération de contrôle devra être corrigée alors que le besoin exprimé dans l’exigence n'aura pas changé._
Une autre raison qui nous a amené à aller vers une approche **BDD**, est la mise en application du **TDD** (Test Driven Development). En effet, le **TDD** est une pratique importante pour l’équipe et nous voulions que le processus mis en place nous permette d’aller naturellement vers cette méthode de développement. En produisant les cas de tests avant toute implémentation du code, on amorce naturellement le développement piloté par les tests.
Enfin, la dernière raison qui nous a motivé dans l’approche **BDD** est la capacité à exprimer des tests sous forme de scénario formalisé dans un langage naturel. En effet, les personnes constituants l’équipe ne sont pas nécessairement des développeurs, tout particulièrement en ce qui concerne l’écriture des exigences. L’écriture de scénarios de tests directement exécutables dans un langage compréhensible par tous ouvre la possibilité à n’importe quel membre de l’équipe de produire les données de tests. Cela évite un effort de traduction des cas de tests dans un format interprétable par le logiciel. De plus, lorsque les exigences et les tests correspondants sont exprimés dans un langage identique il est plus facile de vérifier la cohérence des deux et donc l’atteinte des objectifs mentionnés plus haut.
-
## L’outil XReq
### Présentation
L’interprétation et l’exécution des scénarios de tests définis au travers des analyses comportementales se fait grâce à des outils spécifiques qui supportent le **BDD** et qui permettent de rendre ces scénarios directement exécutables. Dans le cadre du projet, nous en avons créé un adapté à nos contraintes : **XReq**.
Cet outil permet de gérer des scénarios de tests écrit dans une syntaxe inspirée du langage Gherkin. Cette syntaxe s’articule autour de 3 principaux mots clefs :
- * *Given* : Décrit les mises en condition du logiciel, tels que le positionnement des entrées ou d’actions préalables à l’exécution de la fonctionnalité logicielle à tester.
- * *When* : Lance les actions permettant la mise en oeuvre de la fonctionnalité qu’on souhaite tester.
- * *Then* : Permet de vérifier l’état de sortie du logiciel suite aux actions effectués (*When*) dans les conditions définies au préalable (*Given*).
+
+- _Given_ : Décrit les mises en condition du logiciel, tels que le positionnement des entrées ou d’actions préalables à l’exécution de la fonctionnalité logicielle à tester.
+- _When_ : Lance les actions permettant la mise en oeuvre de la fonctionnalité qu’on souhaite tester.
+- _Then_ : Permet de vérifier l’état de sortie du logiciel suite aux actions effectués (_When_) dans les conditions définies au préalable (_Given_).
Les fonctions remplis par **XReq** sont :
- * Analyser la syntaxe utilisée dans les scénarios et vérifier sa conformité avec la syntaxe Gherkin.
- * Pour chacune des lignes du scénario, générer un prototype de fonction (si aucun n’a encore été défini) qui devra être complété par l’utilisateur pour assurer l’interface avec le logiciel à tester. Ces fonctions sont appelées *step_definition*. Un comportement par défaut est défini qui fera échouer le test, rendant le scénario exécutable même si l’utilisateur n’a pas encore interfacé la fonction avec le logiciel à tester.
- * Générer l’exécutable mettant en oeuvre le ou les scénarios de tests (les séquencements des *step_definition*).
+
+- Analyser la syntaxe utilisée dans les scénarios et vérifier sa conformité avec la syntaxe Gherkin.
+- Pour chacune des lignes du scénario, générer un prototype de fonction (si aucun n’a encore été défini) qui devra être complété par l’utilisateur pour assurer l’interface avec le logiciel à tester. Ces fonctions sont appelées _step_definition_. Un comportement par défaut est défini qui fera échouer le test, rendant le scénario exécutable même si l’utilisateur n’a pas encore interfacé la fonction avec le logiciel à tester.
+- Générer l’exécutable mettant en oeuvre le ou les scénarios de tests (les séquencements des _step_definition_).
# Pourquoi développer un outil spécifique?
-Il existe plusieurs outils supportant le **BDD** aujourd’hui, mais au moment où le projet à démarré le choix était plus restreint et les outils moins évolués. Nous voulions également en créer un, qui serait adapté aux logiciels soumis à de fortes contraintes de développement (aéronautique, médical, etc.).
+Il existe plusieurs outils supportant le **BDD** aujourd’hui, mais au moment où le projet à démarré le choix était plus restreint et les outils moins évolués. Nous voulions également en créer un, qui serait adapté aux logiciels soumis à de fortes contraintes de développement (aéronautique, médical, etc.).
Il y a donc plusieurs raisons et besoins qui nous ont amenés à développer **XReq** :
- 1. La **qualification** de l’outil : Les outils utilisés dans le développement de logiciels conformes au standard **DO-178C** peuvent être soumis à une qualification (standard DO-330). Il fallait donc que l’équipe ait la maîtrise sur toutes les données constituant l’outil utilisé pour pouvoir répondre aux contraintes liées à cette qualification.
- 2. Le couplage au langage **Ada 2012** : En plus de pouvoir gérer des langages de programmation courant comme le langage **C**, nous avions besoin d’un outil compatible avec l’**Ada 2012** qui est le langage de prédilection de l’équipe et celui qui a été choisi pour produire le code source du projet. Ce langage est fortement typé et supporte la programmation par contrat. Ces deux aspects permettent de prévenir l’introduction d’un certains nombre de défauts dans le code, ce qui en fait un langage particulièrement adapté au développement de ce type de logiciels.
- 3. L’extension de la syntaxe Gherkin : Les mots clefs “*Test Case Template*” et “*Test Case Data*“ ont été ajoutés pour adapter l’outil à la terminologie du standard aéronautique. Ils sont les équivalents de “*Scenario Outline*” et “*Examples*”, qui sont égalements supportés par l’outil, et permettent de gérer plusieurs cas de test s’exécutant selon un même scénario. Le scénario est défini au travers du “*Test Case Template*” qui fait référence à des données exprimées dans un tableau “*Test Case Data*”. Chaque colonne représentant une donnée, et chaque ligne un jeu de données. Cela permet de produire plusieurs cas de tests pour une même procédure de test.
- 4. L’implémentation des mécanismes de *Setup* et *Teardown* : Ces mécanismes courant, utilisés dans beaucoup de frameworks de tests ont été également implémentés dans **XReq**. Ils permettent d’exécuter des opérations en début et fin de tests. Ces opérations sont purement logicielles (le redémarrage du logiciel par exemple) et n’apparaissent pas dans les scénarios. C’est à l’utilisateur de les définir.
- 5. La séparation de l’analyse syntaxique de la génération de code : **XReq** offre la possibilité d’effectuer l’analyse syntaxique et la génération de code (source et exécutable) de manière indépendante. Cette fonctionnalité permet de vérifier que les scénarios écrits sont corrects sans regénérer, et donc sans modifier le moindre fichier de code. Cette fonctionnalité s’avère intéressante tout particulièrement pendant les phases de mises au point des scénarios.
+1. La **qualification** de l’outil : Les outils utilisés dans le développement de logiciels conformes au standard **DO-178C** peuvent être soumis à une qualification (standard DO-330). Il fallait donc que l’équipe ait la maîtrise sur toutes les données constituant l’outil utilisé pour pouvoir répondre aux contraintes liées à cette qualification.
+2. Le couplage au langage **Ada 2012** : En plus de pouvoir gérer des langages de programmation courant comme le langage **C**, nous avions besoin d’un outil compatible avec l’**Ada 2012** qui est le langage de prédilection de l’équipe et celui qui a été choisi pour produire le code source du projet. Ce langage est fortement typé et supporte la programmation par contrat. Ces deux aspects permettent de prévenir l’introduction d’un certains nombre de défauts dans le code, ce qui en fait un langage particulièrement adapté au développement de ce type de logiciels.
+3. L’extension de la syntaxe Gherkin : Les mots clefs “_Test Case Template_” et “_Test Case Data_“ ont été ajoutés pour adapter l’outil à la terminologie du standard aéronautique. Ils sont les équivalents de “_Scenario Outline_” et “_Examples_”, qui sont égalements supportés par l’outil, et permettent de gérer plusieurs cas de test s’exécutant selon un même scénario. Le scénario est défini au travers du “_Test Case Template_” qui fait référence à des données exprimées dans un tableau “_Test Case Data_”. Chaque colonne représentant une donnée, et chaque ligne un jeu de données. Cela permet de produire plusieurs cas de tests pour une même procédure de test.
+4. L’implémentation des mécanismes de _Setup_ et _Teardown_ : Ces mécanismes courant, utilisés dans beaucoup de frameworks de tests ont été également implémentés dans **XReq**. Ils permettent d’exécuter des opérations en début et fin de tests. Ces opérations sont purement logicielles (le redémarrage du logiciel par exemple) et n’apparaissent pas dans les scénarios. C’est à l’utilisateur de les définir.
+5. La séparation de l’analyse syntaxique de la génération de code : **XReq** offre la possibilité d’effectuer l’analyse syntaxique et la génération de code (source et exécutable) de manière indépendante. Cette fonctionnalité permet de vérifier que les scénarios écrits sont corrects sans regénérer, et donc sans modifier le moindre fichier de code. Cette fonctionnalité s’avère intéressante tout particulièrement pendant les phases de mises au point des scénarios.
## Conclusion
Le processus de développement mis en place a été éprouvé pendant deux ans et demi par l’équipe et a confirmé son efficacité jusqu’à la livraison de la première version de **PULSAR**. L’aboutissement du projet a conduit à l’émergence de la société **[Hionos](https://www.hionos.com/)**, filliale de **[Sogilis](https://sogilis.fr/)** spécialisée dans le développement de solutions logicielles pour drone. Le processus défini au cours de la réalisation du projet constitue aujourd’hui le socle des développements logiciels effectués par la société, et est retravaillé continuellement dans un soucis récurrent d’amélioration. De son côté, **XReq** est devenu un outil incontournable dans l’élaboration des données de tests en conformité avec ce processus. Les méthodes de travail et pratiques mis en place au cours de ce projet ont suscité l’intérêt de plusieurs acteurs majeurs du secteur aéronautique et d’institutions gouvernementales avec qui des partenariats se sont engagés.
Le processus utilisé au cours de ce projet a pu mettre en évidence l’applicabilité du **BDD** au domaine aéronautique pour lequel le développement logiciel est fortement contraint, mais doit pouvoir également s’adapter à d’autres secteurs d’activités tels que le médical (IEC 62304) ou au ferroviaire (EN 50128 / IEC 62279).
-*Exemple de test **XReq** :*
+_Exemple de test **XReq** :_
-***[XReq](https://www.youtube.com/watch?v=-l3EGGfxIz0&ab_channel=Gr%C3%A9goryFretz)** en action :*
+**\*[XReq](https://www.youtube.com/watch?v=-l3EGGfxIz0&ab_channel=Gr%C3%A9goryFretz)** en action :\*
diff --git a/site/content/posts/2020-11-06-vuex-alternative.md b/blog/_posts/2020-11-06-vuex-alternative.md
similarity index 72%
rename from site/content/posts/2020-11-06-vuex-alternative.md
rename to blog/_posts/2020-11-06-vuex-alternative.md
index e4b78ceb4..09611337a 100644
--- a/site/content/posts/2020-11-06-vuex-alternative.md
+++ b/blog/_posts/2020-11-06-vuex-alternative.md
@@ -3,21 +3,21 @@ title: Un état centralisé, oui, mais sans Vuex !
author: Alban et Jean-Baptiste
date: 2020-11-06
image: /img/2020-08-31-vuex-alternative/title.jpeg
-altimage: "Vuex article illustration with a big X capital letter"
+altimage: 'Vuex article illustration with a big X capital letter'
categories:
- - DÉVELOPPEMENT
+ - Développement logiciel
tags:
- Js
- VueJs
---
-Lorsque l'on a besoin de **partager un état entre plusieurs composants** [VueJS](https://vuejs.org) quelque soit leur lien de parenté, [VueX](https://vuex.vuejs.org) est très souvent utilisé.
+Lorsque l'on a besoin de **partagser un état entre plusieurs composants** [VueJS](https://vuejs.org) quelque soit leur lien de parenté, [VueX](https://vuex.vuejs.org) est très souvent utilisé.
Pourtant, on peut se poser la question de son intérêt dans le monde Vue.
En effet, nous allons voir ici comment adresser le même problème, mais **à la main**, **en plus simple**, y compris sur une vraie application qui part en production !
## Comment est-ce possible ??!
-C'est tout bête, il suffit de **profiter du mécanisme de réactivité de Vue** pour partager la même source de vérité entre composants, comme décrit dans la documentation [VueJS](https://fr.vuejs.org/v2/guide/state-management.html#Gestion-d’etat-simple-a-partir-de-rien).
+C'est tout bête, il suffit de **profiter du mécanisme de réactivité de Vue** pour partagser la même source de vérité entre composants, comme décrit dans la documentation [VueJS](https://fr.vuejs.org/v2/guide/state-management.html#Gestion-d’etat-simple-a-partir-de-rien).
Pour illustrer notre propos, nous vous proposons l'exemple ci-dessous, un site e-commerce de jeux de plateaux :