GEF Processus de développement logiciel conventionnels vs

Présentation au sujet: "GEF Processus de développement logiciel conventionnels vs"— Transcription de la présentation:

1 GEF492 - 07 Processus de développement logiciel conventionnels vs
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 Processus de développement logiciel classiques vs modernes GEF492A Automne 2014 [Roy ch. 1,4 & 17] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL07-ClassiqueVModerne.pdf Sylvain P. Leblanc

2 Aperçu Motivation pour le changement
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

3 Motivation pour le changement
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

4 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 Processus de développement classique L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le testage Le codage La maintenance En théorie En pratique La rétro-action est très peu utilisée Automne 2014 GEF492 Sylvain P. Leblanc

5 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

6 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

7 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

8 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 REL – Révision d'exigences logicielles, Révision de design préliminaire, Révision de design complet. TCCCS a vue une lettre donnée comme une donnée livrable pour remplacer une fonctionalité Automne 2014 GEF492 Sylvain P. Leblanc

9 Processus de développement classique
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

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

11 Processus de développement évolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

12 Processus de développement évolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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) Automne 2014 GEF492 Sylvain P. Leblanc

13 Processus de développement évolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

14 Processus de développement évolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Unified Modeling Language (UML) Finit les documents à n'en plus finir Automne 2014 GEF492 Sylvain P. Leblanc

15 Processus de développement évolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

16 Classique vs Evolutionnaire
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 Classique vs Evolutionnaire L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le testage Le codage La maintenance 1. Établir les objectifs, limitations, et alternatives du prochain niveau 2. Évaluez les alternatives pour les produits et le processus; identifier et résoudre les risques 3. Développez et vérifiez le produit du prochain niveau 4. Planifiez les prochaines phases 5. Examinez le progrès, confirmez l’engagement à continuer • 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 Automne 2014 GEF492 Sylvain P. Leblanc

17 Faire la transition Résistance culturelle vs. Résistance objective
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 Il y a toujours résistance au changement; on doit éliminer la résistance culturelle. L'automation requière un investissement – il faut payer tout de suite pour retirer des bénéfices plus tard. Automne 2014 GEF492 Sylvain P. Leblanc

18 Difficultés spécifiques au MDN
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 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 TPSGC est les "négociateur" du gouvernement; il ne comprennent pas le logiciel Automne 2014 GEF492 Sylvain P. Leblanc

19 La gestion de configuration et de changements
GEF Processus de développement logiciel conventionnels vs. modernes Automne 2013 Prochaine séance: La gestion de configuration et de changements Automne 2014 GEF492 Sylvain P. Leblanc