Iterative Rework The Good, the Bad

1
 Iterative Rework The Good, the Bad the Ugly 

• -Magazine Computer, Septembre 2005
• Présentation de Pascal Guy
• Dans le cadre du cours MGL7460

2
Introduction

• Ré-usinage (ou maintenance)
• Inévitable et bénéfique
• On ne réussit pas du premier coup
• Processus créatif sujet à des forces externes
• Processus de développement itératifs
• Prototypage itératif
• Développement Agile
• Construction incrémentale (incremental build)
• Modèle en spirale

3
Introduction

• Ré-usinage (ou maintenance)
• Processus de développement itératif
• Défauts découverts plus tôt dans le cycle
• Maintenance mieux répartie
• Trop ou pas assez ?
• Besoin de comprendre sa nature

4
Développements Itératifs

• Qualités
• Validation et intégration continues du produit
• Démonstration de progrès fréquent
• Découverte et correction des défauts tôt dans le
  cycle
• Livraison rapide de sous-systèmes
• Développement Agile et Construction
  incrémentale
• Ré-usinage lors de changements aux exigences,
  contraintes de conception, etc...

5
Développement Agile

• Implication continue du client
• Développer scénarios de tests avant
  limplémentation
• Implémentation et test de la version
• Présenter au client et prendre nouvelles
  exigences
• Mettre périodiquement des versions en opération

6
Développement Incrémental

• Partition des exigences et de larchitecture et
  hiérarchisation de lassemblage
• Petites équipes (2 à 6, plus Team lead)
• Test indépendant des sous-systèmes
• Présentation des sous-systèmes
• Intégration incrémentale des sous-systèmes

7
Les 4 dimensions

• Fonctionnalité
• Structure
• Comportement
• Attributs de qualité du logiciel
• performance, fiabilité, sûreté, sécurité,
  modifiabilité, etc...

8
Type ré-usinage

• Refactoring
• Technique pour améliorer le design du code
• Série de petites transformations
• Individuellement trop petites pour quelles en
  vaillent la peine
• Mais dont leffet cumulatif est très significatif
• Conserve la sémantique et le comportement
• Par de petites transformations
• On évite lintroduction de bugs
• On obtient un système toujours fonctionnel (le
  plus souvent possible)

9
Catégorie de ré-usinage

• Ré-usinage inévitable
• Ré-usinage évitable

10
Ré-usinage inévitable

• Évolutif (evolutionary)
• Transformations qui ajoutent de la valeur au
  produit en évolution en modifiant une des 4
  dimensions
• En réponse à des changements aux exigences (ou
  autres conditions) non prévus ou impossibles de
  prévoir

11
Ré-usinage évitable

• En théorie
• Travail incorrect, incomplet et/ou inconsistant
• En pratique
• Inévitable et même souhaitable
• Taux insuffisant pourrait indiqué un manque de
  refactoring, de revues ou de tests
• Par contre - taux excessif réduit la
  productivité, augmente les coûts et délais, sape
  le moral des troupes et ronge la confiance du
  client

12
Ré-usinage évitable

• Rétrospectif
• Les besoins sont connus, mais pas implémentés
• Correctif
• Correction des défauts

13
Is it good or bad ?

• Évolutif ou Rétrospectif ?
• Ligne floue
• Interprétation
• Rétrospectif les développeurs auraient du
  comprendre
• Évolutif le client a changé les exigences
• XP
• La solution la plus simple
• Ne pas essayer de prédire le futur

14
La collecte et lanalyse des données

• Identifier les tendances majeures
• Déterminer les causes du ré-usinage
• 4 techniques
• Données informelles
• Anecdotes (à la machine à café)
• Observation
• Données formelles
• Collecte individuelle
• Système de gestion de version du code source (ou
  bug-tracking)

15
Le graphe de contrôle

• UCL LCL
• Upper Control Limit et Lower Control Limit
• Causes ordinaires
• Causes spéciales

16
Quest-ce qui est acceptable ?

• 10 à 20 de leffort total
• Plus de 20 de ré-usinage (total)
• Indique des problèmes au niveau du processus
• Ré-usinage Inévitable problème au niveau des
  exigences, conception, ou lenvironnement
• Ré-usinage Évitable outils, méthodes, qualité
  ou motivation des développeurs
• Moins de 10
• Peut indiquer manque de revue et/ou de test

17
Le graphe de contrôle

• UCL LCL
• Upper Control Limit et Lower Control Limit
• UCL 20
• LCL 10

18
Amélioration des processus

• NASA 40-50 ré-usinage évitable
• Analyse des données de Cocomo2
• Raytheon a réduit de 41 à 11 en 4 ans

19
Tenter de répondre aux questions suivantes

• Comment peut-on accumuler des données sans
  déranger les développeurs ?
• Quel pourcentage de ré-usinage évitable est
  rétrospectif ? Et pour quels attributs ?
• Comment peut-on mieux anticiper nos besoins pour
  éviter du travail rétrospectif ?
• Quel type derreur fait-on ? Quand ? Pourrait-on
  les détecter plus tôt ? Pourrait-on les prévenir
  ?
• Combien de travail correctif doit-on effectuer
  pour réparer nos erreurs ?
• Comment peut-on améliorer nos processus pour
  réduire et éliminer ce type derreurs ?

20
Conclusion

• Se positionner selon besoins
• Boehm Basili
• 80 du ré-usinage se fait dans 20 du code
• Peer reviews attrape 60 de defauts
• Revue dirigée 35 de plus que revue non-dirigée
  
•  La maintenance de logiciels est loin dêtre
  destinée à seulement corriger des erreurs, mais à
  apporter des améliorations  - Glass

21
Références

•  Iterative rework - The good, the bad the
  ugly
• Magazine Computer, Septembre 2005
• http//ieeexplore.ieee.org/iel5/2/32339/01510567.p
  df?arnumber1510567
• Boehm et Basili
•  Software defect reduction Top 10 list 
• Magazine Computer Janvier 2001
• Robert X. Cringely
• http//www.pbs.org/cringely/pulpit/pulpit20030508.
  html
• http//www.refactoring.com
• http//www.martinfowler.com

22
The End

• Merci.
• Questions ?