# Journée Thématique QeR Assurance Qualité Logiciel :

## Zenaida Tucsnak

► To cite this version:

Zenaida Tucsnak. Journée Thématique QeR Assurance Qualité Logiciel :. École thématique. Journée thématique Assurance Qualité Logiciel, France. 2019. cel-02111908

HAL Id: cel-02111908

https://hal.science/cel-02111908v1

Submitted on 26 Apr 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Journée thématique QeR
## Assurance Qualité Logiciel

18 avril 2019 à Paris
# Maitrise du processus de développement

<table><thead><tr><th colspan="3">50 ans d'informatique</th></tr><tr><th></th><th>Logiciel</th><th>Langages</th></tr></thead><tbody><tr><td>1945</td><td>Logiciels sur mesure, calcul scientifique</td><td>Assembleur<br>ENIAC</td></tr><tr><td>1958</td><td>Logiciels scientifiques et de gestion</td><td>FORTRAN<br>COBOL</td></tr><tr><td>1970</td><td>CRISE</td><td>CRISE</td></tr><tr><td>1990</td><td>Logiciels scientifiques temps réel<br>ERP</td><td>UNIX<br>Bases de données</td></tr><tr><td>2000</td><td>E business</td><td>Client-serveur</td></tr></tbody></table>

Absence de maitrise des projets
Mauvaise qualité des produits (logiciels défaillants)

## Réponse à la crise

Appliquer un modèle de cycle de vie

Développement
Définition des besoins
Spécifications
Conception
Codage
Tests

Prototypage
Documentation

Changement de phase

Gestion de projets
# Quatre phases de développement logiciel – cas d'un gros projet

1. Définition des besoins

2. Architecture et design

3. Développement

4. Test, livraison et feedback
# Méthodes classiques: Modèle en cascade

<figure><img src="image_2.png" /></figure>
# Méthode « Cycle en V »
## Etapes

Méthode introduite des 1966,
formalisé en 1970

<figure><img src="image_3.png" /></figure>
Méthode « Cycle en V »
Rôles / Maîtrise d'Ouvrage (MOA)

* Le maître d'ouvrage stratégique (MOAS)

* Le maître d'ouvrage délégué (MOAD)

* Le maître d'ouvrage opérationnel (MOAO)

* L'assistant à la maîtrise d'ouvrage (AMOA ou AMO)

* L'expert métier

* L'utilisateur, au service duquel se trouvent toutes les autres fonctions
# Méthode « Cycle en V »
## Rôles / Maîtrise d'Oeuvre (MOE)

### MOE et MOED (Maîtrise d'œuvre délégué)

* L'équipe architecturale

* L'équipe de développement

* Titulaire du marché

<table><thead><tr><th colspan="11">Répartition des rôles en fonction des étapes</th></tr><tr><th>ROLES</th><th>Analyse de besoins et faisabilité</th><th>Spécifications</th><th>Conception architecturale</th><th>Conception détaillé</th><th>Codage</th><th>Test unitaires</th><th>Test d'intégration</th><th>Test de validation</th><th>Recette fonctionnelle</th></tr></thead><tbody><tr><td>FONCTIONNEL<br>MOA-AMOA</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>SYSTÈME<br>MOE-MOED</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TECHNIQUE<br>Equipe<br>Architecturale</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Equipe de<br>développement</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
# Méthode « Cycle en V »
## Avantages/Risques

Acteurs principaux: le chef de projet, le MOA (maîtrise d'ouvrage) et le MOE (maîtrise d'œuvre).

**Avantage :** gains d'échelle

**Risques :**

* Manque de communication

* Manque de souplesse

* Durée potentiellement longue

* Manque de feedback
Cycle en spirale (itératif et incrémental)
(Boehm, 1988)

<figure><img src="image_4.png" /></figure>
# Méthodes agiles

<figure><img src="image_5.png" /></figure>
# Manifeste agile – 2001
un changement culturel

## Valeurs principales

1. La priorité est donnée aux personnes ainsi qu'à leurs interactions plutôt qu'au processus et aux outils.

2. La priorité est donnée à la collaboration avec le client plutôt qu'à la négociation avec le client.

3. La priorité est donnée à la production de fonctionnalité plutôt qu'à la rédaction de document.

4. La priorité est donnée à souplesse ainsi qu'à l'éventualité d'un changement plutôt qu'au suivi du plan d'origine.

## Principes fondamentaux

1. Priorité à la satisfaction client

2. Les changements dans le projet ne sont pas un point négatif, ils doivent être exploiter pour satisfaire au mieux les clients.

3. Des livraisons régulières d'un logiciel opérationnel sous formes de cycles le plus court possible.

4. Le développement du projet devra être fait de façon collaborative entre les développeurs, les utilisateurs et les représentants et ce durant toute la durée du projet.

5. Le projet devra être réalisé par des personnes motivés.

6. La transmission d'information devra se faire par le biais d'un dialogue en face à face.

7. L'avancement du projet est connu par le fait que le logiciel livré à l'issu de chaque cycle fonctionne.

8. Le rythme de travail devra être constant et soutenable par tous les membres participants au projet.

9. L'excellence technique ainsi que la bonne conception permettent de renforcer l'agilité.

10. Minimiser la quantité de travail sera une partie indispensable de l'agilité.

11. Une équipe auto organisées fournira les meilleures architectures, spécifications et conceptions.

12. Adapter et faire évoluer son comportement.
# Méthodes agiles
## Méthode SCRUM (1996)

<figure><img src="image_6.png" /></figure>
# Les piliers de SCRUM

1. Transparence : langage commun entre l' équipe et le management

2. Inspection : faire le point sur les différents artéfacts produits

3. Adaptation : si une dérive est constatée pendant l'inspection, le processus doit être adapté

Évènement: Réunion de planification de sprint

Évènement:
Mêlée quotidienne

Évènement:
Revue de sprint

Évènement:
Rétrospective de sprint
Les rôles dans le Framework Scrum

1. Propriétaire du produit (Product Owner) : vision du produit à réaliser (client)

2. Maître de mêlée (Scrum Master) : garant de la méthodologie Scrum

3. L'équipe de développement qui réalise le produit
# La vie d'un projet Scrum

* Planification du Sprint (Sprint = itération)

* Revue de Sprint

* Rétrospective de Sprint (principe d'amélioration continue)

* Mêlée quotidienne

1. Qu'est ce que j'ai terminé depuis la dernière mêlée ?

2. Qu'est ce que j'aurai terminé d'ici la prochaine mêlée ?

3. Quels obstacles me retardent ?
# Quelques évènements et artéfacts

* Definition of done ou DoD :
  définition de fini

* Sprint (itération)

* Product Backlog (Carnet du produit ) : il n'est jamais fini

* Sprint Backlog (Carnet de sprint)
# Méthode SCRUM
## Avantages/Risques

### Avantages :

* produit proche des besoin du client

* La communication entre les acteurs du projet est facilité

### Risques :

* Manque de documentation

* Mauvaise interprétation des « daily scrum meetings »
# Méthode agile eXtreme Programming

<figure><img src="image_7.png" /></figure>
# Les valeurs dans la méthodologie eXtreme

1. Communication (programmation en binôme)

2. Simplicité

3. Feedback

4. Courage (estimations, changements, adapter les processus)

5. Respect (qualité, meilleure solution, refactoring)
# Conception et développement

<figure><img src="image_8.png" /></figure>
# Méthode Agile vs Méthode Classique

## MÉTHODE CLASSIQUE
(PRÉDICTIVE, CYCLE EN V, EN W..)

<figure><img src="image_9.png" /></figure>

### UTILISATION OPTIMALE

<figure><img src="image_10.png" /></figure>

Si vous avez une idée très précise de votre projet

avec un cahier des charges et planning très détaillé ou vous avez anticipé tous les risques possibles

Pour les gros projets meilleure adaptabilité, visibilité et gestion des risques

Pour les projets où il n'y pas de documentations détaillées, où le client est indécis le client peut alors voir l'évolution du projet et l'adapter selon ses besoins.

## 3 RÔLES IMPORTANTS

<figure><img src="image_11.png" /></figure>

### Le product owner

Chargé de représenter le client et sec ententes

<figure><img src="image_12.png" /></figure>

### Le scrum master

Veille au bon déroulement du projet

<figure><img src="image_13.png" /></figure>

### La team members

Chargée de la réalisation du sprint

## MÉTHODE AGILE
SCRUM

<figure><img src="image_14.png" /></figure>