Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique

1. Processus de développement logiciel classiques vs modernesGEF492A Automne 2014[Roy ch. 1,4 & 17] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL07-ClassiqueVModerne.pdf

2. Aperçu • Motivation pour le changement • Caractéristiques de processus de développement classiques • Caractéristiques de processus de développement évolutionnaires • Comparaison de principes • Faire la transition • Résistance culturelle versus résistance objective • Difficultés spécifiques au MDN GEF492

3. Motivation pour le changement • Synopsis de l'histoire du développement logiciel • Le développement logiciel est très difficile à prédire • Environ 15 % des projets de développement logiciel finissent en temps, selon le budget alloué • La discipline de gestion est un meilleur indicateur de succès que les avances technologiques • Des changements réels et permanents doivent avoir lieu! • Le taux de rebuts ou de logiciel devant être refait indique un processus immature (et inacceptable) • Le MDN et ses sous-traitants doivent changer GEF492

4. L’identification des besoins du système En théorie L’identification des besoins du logiciel L’analyse En pratique Le design Le codage Le testage La maintenance Processus de développement classique GEF492

5. Processus de développement classique • Décomposition fonctionnelle, selon les besoins • Les besoins sont spécifiés complètement et de façon précise avant que le développement commence. • Traite naïvement tous les besoins comme étant également important • Seulement 1 % — 5 % des besoins pousse le design et la performance • Présume que les besoins demeurent constants • Tracer chaque besoin (entier ou partiel) au travers de chaque stade de design, codage et test est onéreux et non efficient • Créer un cauchemar de traçabilité et de testage • La décomposition fonctionnelle est souvent ancrée dans les contrats et dans la structure de répartition du travail GEF492

6. Processus de développement classique • Intégration retardée et émersion du design tardive • Succès initialement démontré à l'aide de design papier et par révisons détaillées • Plusieurs formats papier pour chaque stade • Codage arrive tard dans le cycle de vie (gel du design) • Cauchemars d'intégration causés par des problèmes inattendus et interfaces ambigües • Les tests consomment généralement plus de 40 % de l'horaire • Fortes pressions au budget et à l'horaire pour rendre le système fonctionnel • Le rapiéçage de dernière minute donne des résultats non optimaux • Trop tard (et trop de pression horaire) pour capturer le nouveau design • Résultats: un système très fragile, difficile à maintenir, de qualité douteuse (du point de vue du client) qui est livré en retard GEF492

7. Processus de développement classique • Résolution de risques tardive • Les activités du début du cycle de vie mettent l'accent sur les révisions papier. Le design, l'implémentation et les éléments à haut risque d'intégration sont difficiles à cerner sur papier • Ex.: les facteurs de performances en temps réels comme le synchronisme et les interblocages • Les facteurs de design importants ne sont souvent identifiés que lors de l'intégration • Habituellement trop tard pour considérer des compromis d'ingénierie sérieux • Les changements importants faits lors de l'intégration sont très dispendieux – en partie parce que les artefacts papier « gelés » sont nombreux et difficiles à changer. • Intégration est retardée • L'intégrité du design est compromise, la qualité est dégradée • Les risques font l'objet de débats chauds, les problèmes sont souvent cachés GEF492

8. Processus de développement classique • Accent sur les documents et les réunions de révisions • Beaucoup de documents volumineux sont créés pour démontrer le progrès. • Souvent des tonnes de papier (littéralement) • Réunions cérémonieuses, centrées sur l’achèvement de documents importants • REL, RDP, RDC • Grande auditoire, réviseurs souvent incapables de comprendre les détails de bas niveau. Résultant en plusieurs personnes qui révisent les mêmes détails étant simples et non-risqués – peu de valeur • Ressources précieuses consommées pour activités à basse valeur • Le producteur est habituellement content de participer dans ces taches inutiles, puisque ces paiements sont basés sur le papier et non le produit GEF492

9. Processus de développement classique • Relations contradictoires entre les parties prenantes • Les besoins gelés causent de la friction • Les révisions subjectives des documents causent souvent des échanges très néfastes Processus typique de soumission/approbation de document • Le sous-traitant prépare une ébauche (délibérément) incomplète de la donnée livrable • Le client doit fournir des commentaires dans les x prochains jours (15-30) • Le sous-traitant incorpore les commentaires dans les y jours qui suivent • Répétez au besoin • Un processus avec tant de surcharge encourage de hauts niveaux de sensibilités et de méfiance GEF492

10. 2. Évaluez les alternatives pour les produits et le processus; identifier et résoudre les risques 1. Établir les objectifs, limitations, et alternatives du prochain niveau 5. Examinez le progrès, confirmez l’engagement à continuer 3. Développez et vérifiez le produit du prochain niveau 4. Planifiez les prochaines phases Processus de développement évolutionnaire GEF492

11. Processus de développement évolutionnaire • L'architecture a priorité • Le raffinement des besoins est balancé par le design architectural • Bien sûr, les besoins influencent le design, mais … • … le design influence les besoins • Les décisions de design principales sont prises plus tôt pour éliminer (réduire) les grands risques • Une (ou plusieurs) itération du cycle de vie est exécutée, et les autres itérations sont planifiées avant de commettre les ressources pour l'implémentation complète • On utilise une approche basée sur les démonstrations pour augmenter l'appui du client GEF492

12. Processus de développement évolutionnaire • Développement basé sur les composantes Définition: une composante est un ensemble cohésif de lignes de code déjà existantes, en format source ou exécutable, avec une interface et un comportement bien définis • L‘accent passe de la ligne de développement axé sur les lignes de code au développement axé sur les composantes • Développement plutôt que construction • Le but est de réduire le montant de code source généré par des humains et le développement privé • N'est pas synonyme avec COTS (Commercial Off-The-Shelf) GEF492

13. Processus de développement évolutionnaire • Environnement de gestion de changements • L'aspect dynamique du développement itératif dicte que l'environnement doit supporter une ligne de base contrôlée objectivement. • L'environnement doit supporter des flots de travaux concurrents par différentes équipes • Ingénierie circulaire • Un environnement intégré doit supporter la transformation de l'information (vers l'avant et vers l'arrière) • De phase en phase: besoins, design, codage, déploiement • Sans le soutien d'outils automatisés, le temps requis pour compléter les itérations devient non convenable GEF492

14. Processus de développement évolutionnaire • Notation basée sur modèles • Une approche basée sur les modèles supporte l'évolution de notations graphiques et textuelles très riches en sémantiques • Une image vaut mille mots • Les langages de modélisation visuels et les langages formels lisibles par les machines donnent des mesures plus objectives pour les révisions et traçages du progrès. • Donne également accès à l'avantage d'étapes générées par les machines • Ex.: génération automatique de code à partir de la notation de design • UnifiedModelingLanguage (UML) GEF492

15. Processus de développement évolutionnaire • Contrôle de la qualité et évaluation de progrès objectifs • L'évaluation de la qualité et du processus est intégrée dans le processus même • Les mesures sont dérivées directement des artefacts de génie • Tente de minimiser les artefacts papier ayant peu de valeur • La qualité est la responsabilité de l'équipe, et non d'une organisation séparée GEF492

16. L’identification des besoins du système 2. Évaluez les alternatives pour les produits et le processus; identifier et résoudre les risques 1. Établir les objectifs, limitations, et alternatives du prochain niveau L’identification des besoins du logiciel L’analyse 5. Examinez le progrès, confirmez l’engagement à continuer Le design Le codage 3. Développez et vérifiez le produit du prochain niveau 4. Planifiez les prochaines phases Le testage La maintenance Classique vs Evolutionnaire • Basée sur les besoins • Basée sur l'architecture • Développent privé • Basée sur les composantes • Évite les changements • Gestion de changements • Outils ad hoc/papier • Ingénierie circulaire GEF492

17. Faire la transition • Résistance culturelle vs. Résistance objective • Les gestionnaires doivent être impliqués intimement • Les gestionnaires créent le plan; ils ne le révisent pas • Les besoins et le design sont fluides (réalisez ceci tout de suite!) • L'accent sur la production et sur le gel des documents intermédiaires n'est pas productif • On doit encourager les démonstrations ambitieuses • Les échecs tôt dans le cycle de vie sont positifs! • Les premiers incréments seront immatures et incomplets • Les clients doivent être éduqués vis-à-vis le processus • On doit absolument investir dans l'automatisation • Les bénéfices à long terme sont plus importantes que les dépenses à court terme GEF492

18. Difficultés spécifiques au MDN • Travaux publics et Services gouvernementaux Canada (TPSGC) et le processus d'attribution de contrats • Les contrats axés sur les normes favorisent les processus traditionnels vis-à-vis les processus modernes • Les contrats à prix fixe encouragent les relations contradictoires • Manque de confiance historique envers les sous-traitants • Les bonnes firmes doivent pouvoir faire des profits • Les mauvaises firmes doivent être responsables de leurs actions • Très grands projets inusités (uniques) • Impossible de réussir avec un processus axé sur les besoins fixes • Éducation en génie logicielle/gestion de projet • Le MDN est particulièrement en retard sur l'industrie dans ce domaine GEF492

19. Prochaine séance: La gestion de configuration et de changements GEF492