Développement efficace d'application logicielle
Upcoming SlideShare
Loading in...5
×
 

Développement efficace d'application logicielle

on

  • 2,193 views

- Efficacité et productivité

- Efficacité et productivité
- Taille du logiciel
- Résultats de productivité
- Pratiques observables

Présenté le 14 mai 2008 à une midi-conférence du CRIM

Statistics

Views

Total Views
2,193
Views on SlideShare
2,183
Embed Views
10

Actions

Likes
0
Downloads
48
Comments
0

3 Embeds 10

http://www.slideshare.net 7
http://www.linkedin.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Développement efficace d'application logicielle Développement efficace d'application logicielle Presentation Transcript

  • Développement efficace d'application logicielle Présenté par Sylvie Trudel Conseillère senior, CRIM Présenté à Montréal, le 14 mai 2008 Présenté à Québec, le 21 mai 2008 Midi-conférences du CRIM
  • Contenu
    • Efficacité et productivité
    • Taille du logiciel
    • Résultats de productivité
    • Pratiques observables
    • Références
  • Efficacité et productivité Évoluer du qualitatif au quantitatif
  • Indicateurs de performance Date de livraison Coûts/effort Productivité Qualité/contenu
  • Efficacité et productivité : concepts
    • Productivité finale = Sorties / Entrées
    • Coût unitaire = Entrées / Sorties
    • Maturité du processus de gestion : Qualitatif  Quantitatif
    Processus Entrées Sorties Ressources
  • Productivité de projet logiciel
    • Forte corrélation entre:
      • Taille et effort
      • Taille et temps écoulé
    • Productivité finale = Taille / Effort
    • Coût unitaire = Effort / Taille
    • Taux de livraison = Taille / Temps
    Effort Taille Temps Taille
  • Estimation de projet logiciel : concepts Estimer l’effort de base Taille Effort préliminaire Estimer les risques Risques Effort contingenté Ajouter les autres coûts Autres coûts Coûts estimés
  • Taille du logiciel De la taille physique à la taille fonctionnelle
  • Historique de la taille fonctionnelle IFPUG : I nternational F unction P oint U sers G roup COSMIC : Co mmon S oftware M easurement I nternational C onsortium Avant 1979, mesure de la taille physique avec le # lignes de code Albrecht, 1 ère méthode de mesure de taille fonctionnelle Formation d’IFPUG Albrecht v2, appellation des « Points de fonction » Symons Mark II Function Points IFPUG v3.0 IFPUG v4.0 Abran propose les FFP comme extension à IFPUG IFPUG v4.1 Mark II ISO 20968 Formation de COSMIC COSMIC v2.2 ISO 19761 IFPUG v4.2 ISO 20926 NESMA v2.1 ISO 24570 COSMIC v3.0
  • Taille fonctionnelle du logiciel
    • Quantification de la taille du logiciel à partir des exigences fonctionnelles de l’utilisateur
      • Exigences = spécifications  comportement
        •  exemple: cas d’utilisation
      • Excluant exigences techniques et de qualité
        •  c’est-à-dire non fonctionnelles
    • Se mesure tôt dans le cycle logiciel
  • Normes ISO/IEC relatives à la mesure de taille fonctionnelle Cadre normatif de base des mesures de taille fonctionnelle 14143-1 Définition des concepts 14143-2 Évaluation de la conformité avec 14143-1 14143-3 Vérification des méthodes 14143-4 Modèles de référence 14143-5 Détermination des domaines fonctionnels 14143-6 Guide de sélection de méthode Processus de mesure 15939 Processus de mesure en génie logiciel Méthodes de mesure de taille fonctionnelles 19761 COSMIC 20926 IFPUG 4.1 20968 Mark II 24570 NESMA
  • La méthode COSMIC
    • Nouvelle génération de mesure de taille fonctionnelle
    • Cofondée par des québécois
    • Norme nationale au Japon
    • Traduit ou en voie de l’être dans 12 langues
    • Guide de mesure gratuit en français (v2.2) http://www.gelog.etsmtl.ca/cosmic-ffp/manual.html
    • Unité de mesure: pfc (point de fonction COSMIC)
  • Les mouvements de données Données Logiciel à mesurer Matériel de stockage Écritures (C) Lectures (L) … Acteurs Utilisateurs ou autres systèmes Matériel d’entrée/ sortie Entrées (E) Sorties (S) Entrées (E) Sorties (S) Frontière Processus fonctionnel 1 Processus fonctionnel 2 Processus fonctionnel n ‘ Interfaces’ ‘ Infrastructure’
  • Autres indicateurs avec la taille
    • Densité des défauts = # anomalies / taille
    • Coût relatif des correctifs = effort correctif /taille
    • Facteur d’échelle préliminaire/final = taille fin / taille début
    • Taille des modifications = valeur absolue de la taille affectée
  • Résultats de productivité Quelques exemples québécois, canadiens et internationaux
  • Exemples de mesures de productivité: en heures/pfc 0 10 20 30 40 50 60 70 80 A B C D E F 1,5 2 6 12 12 40 77 Organisations québécoises 4,6 8,5 16,6 Q1 Q3 Médiane BD internationale de projets ISBSG Projets VB et VB.NET
  • Corollaires
    • Augmentation de la productivité chez toutes les organisations qui la mesurent
      • Certaines l’ont triplé: 6 h/pfc  2 h/pfc
    • Identification des ambiguïtés aux exigences fonctionnelles
      • Réduction importante du travail à refaire
    • Comparaison de productivité avec des projets de même nature ailleurs dans le monde
    • Permettre de quantifier l’amélioration des processus
  • Pratiques observables Entre le noir et le blanc, il y a toutes les teintes de gris…
  • Préoccupations et directives
    • Budget
    • Date de livraison
    • Qualité
    • Contenu à valeur ajoutée
    • Productivité
  • Processus et outils
    • Processus en cascades
    • Description textuelle lourde
    • Outils disparates, peu intégrés
    • Processus itératif
    • Description graphique légère (BPMN, TQM, etc)
    • Outils intégrés de collaboration
    Architecture Analyse Design Program. Test Architecture Analyse Design Program. Test Livraison
  • Méthodologie et documentation
    • Méthodologie de 20 ans+
      • Améliorations rares, ponctuelles
      • Documentation lourde, dogmatique, peu gérée
      • Bilans de projet comptables
    • Méthodologie Agile (Scrum, TDD)
      • Améliorations mensuelles
      • Documentation réfléchie, améliorée et gérée
      • Rétrospectives régulières
    Architecture Analyse Design Program. Test
  • Équipes et leadership
    • Structure hiérarchique et/ou matricielle
      • Groupe de développement éloigné des utilisateurs
      • Peu d’importance sur les connaissances du domaine
      • Spécialistes en héros
    • Rôles et responsabilités flous
      • Chevauchements
    • Structure d’équipes autogérées
      • Utilisateurs intégrés à l’équipe de développement
      • Importance accordée aux connaissances du domaine
      • Généralistes en équipe
    • Rôles et responsabilités clairs
      • Définis et appliqués
  • Valeurs
    • Secrets et mensonges
    • Respect des budgets
    • Individualisme et CYA
    • Traditionalisme
    • Transparence
    • Respect des compétences
    • Travail d’équipe
    • Innovation
  • Gestion de projet et gouvernance
    • Gros projets non morcelés
      • Tendance à regrouper des petits projets en projets plus gros
      • Favoriser des phases de plus de 6 mois
      • Mécanismes décisionnels en comités de plus de 8 personnes
      • Information mal communiquée au personnel
      • Suivis mensuels
    • Gouvernance déficiente ou absente
    • Gros projets morcelés
      • Pour obtenir des projets de taille gérable plus facilement
      • Favoriser la livraison itérative courte (2-4 sem)
      • Mécanismes décisionnels alignés sur l’imputabilité des rôles
      • Personnel informé chaque jour
      • Suivis quotidiens
    • Gouvernance amorcée ou assurée
      • Architecture planifiée et maintenue
  • Exigences, tests et assurance qualité
    • Architecture et analyse
      • Financement global du projet fixé avant de rédiger les exigences
      • Exigences fonctionnelles et solution organique entremêlées
    • Tests escamotés
      • Effort dépensé sur les devis d’essais mais pas suffisant sur l’exécution
      • Environnement insuffisants
    • Assurance qualité = tests
    • Phase de développement d’exigences
      • Rédaction budgétée séparément, souvent à l’heure
      • Exigences fonctionnelles exprimées dans le langage des utilisateurs
      • Fonctionnalités alignées sur les processus d’affaires
    • Tests systématiques
      • Intégration continue
      • Environnement contrôlé
    • Assurance qualité
      • Processus appliqué!
  • Références
  • Références
    • Méthode COSMIC – ISO 19761 http://www.gelog.etsmtl.ca/cosmic-ffp/
      • Manuel de mesure en français et autres langues
      • Articles, présentations et études de cas
    • Base de données internationale de projets ISBSG * http://www.isbsg.org/
    • Normes ISO http://www.iso.org
    *ISBSG : I nternational S oftware B enchmarking S tandards G roup