ÉCOLE DE TECHNOLOGIE SUPÉRIEURE UNIVERSITÉ DU QUÉBEC

RAPPORT TECHNIQUE PRÉSENTÉ À ALAIN APRIL

DANS LE CADRE DU COURS MGL804­01 ­ RÉALISATION ET MAINTENANCE DE LOGICIELS

TRAVAIL DE SESSION #4 UTILISATION DE LA NORME ISO 14764

DANS L’ENTREPRISE B­CITI SOLUTIONS INC.

PAR Ricardo­Jorge COUTO MACHADO

COUR30047706

GÉNIE LOGICIEL

ÉCOLE DE TECHNOLOGIE SUPÉRIEURE MONTRÉAL, 18 JUIN 2016

ÉTÉ 2016

REMERCIEMENTS

J’aimerais remercier particulièrement Vivianne Gravel, présidente chez B­CITI, d’avoir autorisé la rédaction de ce rapport technique sur les processus de développement logiciel de l’entreprise ainsi que sur l’état de la documentation et les environnements d’opération. J’aimerais aussi remercier Mathieu Hémon avec qui j’ai mis en place les processus actuels de développement logiciel et de maintenance chez B­CITI. Un mot spécial pour remercier Benoit Potvin et toute l’équipe de m’avoir fait confiance et de m’avoir supporté par rapport à mes choix de conception logicielle. Finalement, j’aimerais remercier Alain April pour ses conseils de rédaction au niveau de la structure du document et de l’approche à employer.

2 / 37

RÉSUMÉ Le présent rapport technique est effectué dans le cadre du projet personnel pour le cours MGL804 Réalisation et maintenance de logiciels donné à l’ÉTS à l’été 2016. La visée de ce travail est l'utilisation de la norme ISO 14764 en entreprise (travail #4 page 26). L’entreprise choisie est B­CITI SOLUTIONS INC (www.b­citi.com), une start­up de la région de Montréal qui offre le logiciel B­CITI sur le Web, en mode SaaS ( Software as a Service ), aux villes du Québec et à leurs citoyens. L’entreprise connaît une croissance soutenue. Son équipe de développement est passée de trois à neuf développeurs en moins de 12 mois. L’entreprise développe en mode Agile avec un processus de gestion Kanban­Scrum adapté à ses besoins. Le service B­CITI est en ligne depuis janvier 2016. De nouveaux développements sont planifiés pour les 18 prochains mois. De nombreuses demandes de changement surgissent de façon soutenue et non planifiée. L’entreprise n’a présentement pas les ressources nécessaires pour former une équipe dédiée spécifiquement à la maintenance. Conséquemment, les développeurs doivent assurer, au­delà de leurs responsabilités, les tâches liées à la maintenance. Les changements incontrôlés à l’application depuis janvier 2016 ont forcé récemment une réingénierie importante d’un module de l’application, ce qui a causé une perturbation du calendrier de livraison. L’entreprise cherche à améliorer son processus de gestion des demandes de changement pour assurer un service efficace à ses clients, tout en maintenant une bonne cadence de développement. Ce rapport est divisé en trois chapitres. Premièrement, le processus de développement et de maintenance utilisé actuellement chez B­CITI sera présenté. Par la suite, ce même processus sera évalué en fonction des requis ( shall ) de la norme ISO 14764. Au besoin, des actions et estimations d’effort seront formulées de façon à ce que l'entreprise puisse être en conformité avec la norme. Finalement, un plan d’amélioration sera proposé à l’entreprise afin d’intégrer les actions formulées. L’activité de retrait du logiciel (clause 5.6 de la norme) ne fait pas partie de la portée du présent travail.

3 / 37

TABLE DES MATIÈRES

Introduction 1. Présentation de la situation actuelle chez B­CITI

1.1 Le logiciel B­CITI 1.2 Processus de développement et maintenance actuels

1.2.1 Rôles dans le processus 1.2.2 Le processus en workflow et en tableau Kanban

1.3 Documentation 1.4 Environnements d’opération

2. Évaluation de la conformité du processus actuel de maintenance 2.1 Implémentation du processus (Clause 5.1) 2.2 Analyse de modification et de problème (Clause 5.2) 2.3 Implémentation des modifications (Clause 5.3) 2.4 Revue et acceptation (Clause 5.4) 2.5 Migration (Clause 5.5) 2.6 Retrait du logiciel (Clause 5.6) 2.7 Tableaux résumés

2.7.1 Conformité et effort pour les quatre premiers processus 2.7.2 Effort pour le processus de migration

3. Plan d’amélioration 3.1 Ajustements supplémentaires 3.2 Stratégie d’amélioration

Conclusion Références bibliographiques

4 / 37

LISTE DES TABLEAUX

Page

Tableau 1 Tableau Kanban utilisé chez B­CITI 13

Tableau 2 Documentation chez B­CITI 14

Tableau 3 Résumé du niveau de conformité et de l’effort requis (quatre premiers processus)

31

Tableau 4 Résumé du niveau de conformité et de l’effort requis (Processus Migration)

32

Tableau 5 Stratégie d’amélioration du processus de maintenance : Étapes essentielles

34

Tableau 6 Stratégie d’amélioration du processus de maintenance : Étapes optionnelles

35

LISTE DES FIGURES ET ILLUSTRATIONS

Page

Figure 1 Workflow utilisé chez B­CITI 12

Figure 2 Gabarit d’évaluation du niveau de conformité à la norme ISO 14764­2006

16

5 / 37

LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES

ISO 14614 ISO/IEC 14764­2006 Software Engineering ­ Software Life Cycle Processes ­ Maintenance, International Standard

MR Modification request ­ Requête de modification

P.O. Product Owner. Rôle dans la méthodologie Agile Scrum

PR Problem request ­ Requête de problème

SaaS Software as a service ­ Logiciel en tant que service

S.M. Scrum Master ­ Rôle dans la méthodologie Agile Scrum

LISTE DES LOGICIELS ET OUTILS

Confluence Wiki et base de connaissances offert en mode SaaS. [Confluence]

JIRA SaaS hautement configurable, offrant la gestion collaborative de issues , workflows , et tableaux Kanban et Scrum. [JIRA]

EXPRESSIONS TECHNIQUES ANGLAISES

Issue Toute tâche à exécuter, cas d’utilisation, MR, PR dans le SaaS JIRA.

Multi­tenant Une seule instance d’une application logicielle partagée par plusieurs clients.

Story Description de l’utilisation d’un logiciel en termes de langage d’affaires.

Workflow Flux de travail, processus de travail, réalisation d'une suite de tâches ou d’opérations effectuées par une personne, un groupe de personnes ou un organisme. [Workflow]

6 / 37

NOTES AU LECTEUR La norme ISO 14764­2006 n’est pas présentée dans ce travail dans le but d’alléger le document. Il est assumé que le lecteur connaît la norme. Dans le cas contraire, le lecteur est invité à lire les six premières pages de la norme pour se mettre en contexte. Dans ce travail il est question d’évaluation de l’effort. L’auteur de ce texte travaille chez B­CITI depuis sa création. L’estimation de l’effort est intuitive et est basée sur la connaissance de l’état de la documentation. Cet effort est évalué en heures totales. Sauf mention explicite, il est possible de partager cet effort entre plusieurs personnes. Il sera aussi question de code source. À moins d’indication contraire, le code source inclus aussi sa documentation, principalement les commentaires.

7 / 37

Introduction Le présent rapport technique est effectué dans le cadre du projet personnel pour le cours MGL804 Réalisation et maintenance de logiciels donné à l’ÉTS à l’été 2016. Portée de ce rapport technique La visée de ce travail, qui se divise en trois chapitres, est l'utilisation de la norme ISO 14764 en entreprise (travail #4 page 26). Premièrement, le processus de développement et de maintenance utilisé actuellement chez B­CITI sera présenté. Par la suite, ce même processus sera évalué en fonction des requis ( shall ) de la norme ISO 14764. Au besoin, des actions et estimations d’effort seront formulées de façon à ce que l'entreprise puisse être en conformité avec la norme. Finalement, un plan d’amélioration sera proposé à l’entreprise afin d’intégrer les actions formulées. Une première migration d'environnement est prévue pour le logiciel B­CITI à la fin de l’été 2016. Des actions sont proposées en regard de cette migration et du respect de la norme (clause 5.5 de la norme). L’implémentation des changements aux processus de l’entreprise ainsi que l’activité de retrait du logiciel (clause 5.6 de la norme) ne font pas partie de la portée du présent travail. Présentation de l’entreprise B­CITI B­CITI SOLUTIONS INC (www.b­citi.com) est une start­up de la région de Montréal qui offre un logiciel sur le Web, en mode SaaS ( Software as a Service ), aux villes du Québec et à leurs citoyens.

B­CITI est un système d’optimisation de données multi­sources facilitant l’offre de services numériques pour les villes intelligentes.

­ www.b­citi.com L’entreprise connaît une croissance soutenue. En moins de 12 mois, son équipe de développement est passée de trois à neuf développeurs. L’entreprise développe en mode Agile avec un processus de gestion Kanban­Scrum adapté à ses besoins.

8 / 37

Le service B­CITI est en ligne depuis janvier 2016. De nouveaux développements sont planifiés pour les 18 prochains mois. De plus, de nombreuses demandes de changement surgissent de façon soutenue. L’entreprise n’a présentement pas les ressources nécessaires pour former une équipe dédiée spécifiquement à la maintenance. Conséquemment, les développeurs doivent assurer, au­delà de leurs responsabilités, les tâches liées à la maintenance. Défis de l’entreprise L’entreprise cherche à améliorer son processus de gestion des demandes de changement pour assurer un service efficace à ses clients, tout en maintenant une bonne cadence de développement. Certains clients se sont montrés inquiets sur la capacité de l’entreprise à gérer les demandes de changements étant donné la croissance rapide de l’entreprise. Les fournisseurs actuels des villes accusent de façon générale de grands délais de réponse aux demandes de changements Les changements incontrôlés à l’application depuis janvier 2016 ont forcé récemment une réingénierie importante d’un module de l’application, ce qui a causé une perturbation du calendrier de livraison. Bénéfices pour l’entreprise avec l’application de la norme ISO/IEC 14764 Les bénéfices recherchés par l’introduction de cette norme chez B­CITI sont :

une gestion efficace des demandes de changement un logiciel de qualité une démarche qui peut amener à la certification ISO/IEC 12207 Maintenance Process un argument de vente et de marketing.

9 / 37

1. Présentation de la situation actuelle chez B­CITI Pour que le lecteur soit en mesure de comprendre l’évaluation du niveau de conformité des processus de maintenance de l’entreprise en rapport avec la norme ISO 14764, une présentation du processus actuel est nécessaire. De plus, pour bien mettre en contexte le processus, les différents environnements d’opération et l’architecture du logiciel sont expliqués brièvement.

1.1 Le logiciel B­CITI B­CITI est une application Web multi­tenant où tous les utilisateurs partagent la même application et la même base de données. Les clients étant des villes et les utilisateurs des citoyens de ces villes, le schéma de données offre un lien fort entre les clés étrangères pour être en mesure d’identifier quelles données appartiennent à quelle ville. De plus, les citoyens peuvent être associés à plusieurs villes (un citoyen de la ville A utilisant les services de la ville B). Au niveau architectural, B­CITI est composé de trois pôles :

un backend qui interagit avec la base de données, gère les règles d’affaires et offre un API Rest ;

un frontend Web en mode Single Page Application qui utilise les fonctionnalités de l’ API Rest .

des application natives mobiles (iOS, Android) qui utilisent les fonctionnalités de l’ API Rest .

1.2 Processus de développement et maintenance actuels Les processus de maintenance et de développement chez B­CITI sont à toutes fins identiques. La maintenance et le développement sont réalisés par les mêmes développeurs, quoique la maintenance est majoritairement effectuée par les développeurs les plus expérimentés. Ces processus sont inspirés des méthodes Agiles Scrum et Kanban.

10 / 37

1.2.1 Rôles dans le processus Les cinq rôles suivants sont présents dans les processus de maintenance et développement chez B­CITI. Certaines personnes changent de rôle au besoin. Le rôle de Product Owner (P.O.) (aussi appelé le Directeur de produit) est assuré par une seule personne, dont la responsabilité est de capter les requis des clients ainsi que toute demande de changement et de les transmettre par écrit aux programmeurs. De plus, le P.O est responsable de la validation de l’application. Ce rôle n’est pas partagé par d’autres. Le rôle de Scrum Master (S.M.) est assuré par une seule personne qui joue le rôle de coach d’équipe. Il s’occupe de la conception logicielle, traite la majorité des demandes de changements et de corrections et joue aussi le rôle de “gardien du code source” au niveau des règles syntaxiques et de la structure. Il est aussi responsable de s’assurer de maximiser la productivité des programmeurs en fonction de leurs compétences. Ce rôle n’est pas partagé par d’autres. Les développeurs sont les programmeurs qui développent le produit en fonction des requis et de la conception de haut niveau. Ils sont présentement au nombre de neuf. Les mainteneurs sont le Scrum Master les mêmes programmeurs cités précédemment. Les programmeurs assistent le Scrum Master lorsque nécessaire. Le testeur s’occupe de la vérification de l’application. Une personne occupe ce rôle.

11 / 37

1.2.2 Le processus en workflow et en tableau Kanban Des issues voyagent à différentes étapes du processus. Ces issues peuvent être des user stories (requis Agiles à haut niveau), des tâches (découpage de stories ), des demandes de changements ou des corrections de défauts. Bref, toute chose à faire en relation avec le code source, la documentation de l’application ou l’infrastructure d’opération est un issue .

Figure 1 ­ Workflow utilisé chez B­CITI

Le processus est linéaire. Tout issue peut retourner à “in progress” à n’importe quelle étape du processus.

12 / 37

Un tableau Kanban est associé à ce processus. Il contient les sept colonnes suivantes.

Colonnes du Tableau Kanban

Étapes du workflow Intervenants (Rôles) Action par qui

Commentaires

To Do Open Re­opened

Tous Le P.O. rédigent les nouveaux requis et les demandes de changement. Tous peuvent rapporter un bug. Tous peuvent ajouter une modification jugée nécessaire sous approbation du P.O. ou du S.M.

In progress In Progress Développeur Mainteneurs

Le issue est assigné à une personne et est en cours de développement / correction. Tout issue rejeté au test ou au UAT retombe dans cette colonne.

Dev completed Dev Completed Testeur Indique au testeur qu’il y a des issues prêts à tester.

Test Ready for test Testeur Indique les issues déployés sur l’environnement de test et présentement en test.

UAT (User Acceptance Test)

Ready for UAT Production Owner Indique au P.O. les issues qui ont passé les tests et qui sont en attente d’approbation.

Approved UAT Approved Testeur Indique les issues prêts pour la prochaine mise en production. Le testeur fait la mise en production.

Deployed Delivered

­ Indique les issues déployés en production. Les mises en production sont fréquentes. Parfois, plusieurs fois par semaine.

­ Closed ­ Le P.O. peut, à sa discrétion fermer tout issue .

Tableau 1 ­ Tableau Kanban utilisé chez B­CITI

13 / 37

1.3 Documentation La documentation se trouve à différents endroits et sa qualité varie selon le type. Type Endroit Fréquence des mises à

jour et qualité. Commentaires

Schémas de données Google Docs À chaque changement au modèle de données. De bonne qualité.

Code source Dépôt GIT À chaque commit. Il y a deux versions de code source :

développement / maintenance;

production. La version en développement / maintenance est stabilisée avant une mise en production.

Documentation de code source

À même le code source. De la même forme qu’un Javadoc

Insuffisante et mal documentée.

Par contre, le nom des variables et méthodes sont très explicites et suivent une convention comprise de tous.

Conventions de programmation

Google Docs Insuffisante et mal documentées.

Communiquées oralement, strictement renforcées et comprises de tous. Inspiré des normes Java.

Documentation d’API Base de données À chaque changement. De très bonne qualité.

Disponible sur un outil Web qui offre la recherche et l’édition.

Produit (requis) Confluence Version initiale de chaque fonctionnalité seulement. De bonne qualité.

Organisé par date. Information difficile à retrouver.

Issues Requis détaillés Demandes de changement Rapport de problèmes

JIRA Très fréquente. Parfois incomplète.

L’analyse, les étapes de résolution et les résultats de tests y sont documentés au besoin.

Tableau 2 ­ Documentation chez B­CITI

14 / 37

1.4 Environnements d’opération Il y a trois environnements d’opération chez B­CITI. DEV (Développement) Un environnement MAMP ou WAMP (Mac/Windows Apache, mySQL, PHP) installé sur les ordinateurs des développeurs, Mac et Windows. Connecté à une base de données locale. TEST (test) Une VM Linux avec un environnement LAMP (Linux, Apache, mySQL, PHP). Connecté à la base de données de test. PROD (production) Identique à l’environnement de test, mis à part quelques détails de configuration tels que URLs autorisés, RAM, CPU. Connecté à la base de données de production. Le logiciel B­CITI détecte l’environnement sur lequel il tourne à l’aide de l’URL appelant (localhost, test.bciti.info, etc) et se configure lui­même au run­time . Ceci permet des déploiements sans effort sur les environnements de TEST et DEV en plus d’éviter des erreurs de manipulation de configuration.

15 / 37

2. Évaluation de la conformité du processus actuel de maintenance La conformité de chaque clause obligatoire ( shall ) de la norme ISO 14764­2006 sera évaluée selon le gabarit suivant.

x.x.x.x Clause (numéro et nom de la clause) Le texte de la clause obligatoire. Les textes des clauses sont copiés ici uniquement pour faciliter la lecture et la compréhension. Vous référer au texte officiel de la norme pour tous les détails. Conformité Évaluation du niveau de conformité du processus actuel. Explication et détails sur la situation actuelle. Actions requises Les actions et changements à apporter pour être en conformité avec la norme. Effort requis Une évaluation sommaire de l’effort requis en temps pour apporter les actions requises.

Figure 2 ­ Gabarit d’évaluation du niveau de conformité à la norme ISO 14764­2006

16 / 37

2.1 Implémentation du processus (Clause 5.1) 5.1.2.1 Maintenance plans and procedures The maintainer shall (ISO/IEC 12207 sub­clause 5.5.1.1) develop, document, and execute plans and procedures for conducting the activities and tasks of the Maintenance Process. Conformité Non­conforme. Il n’y a pas de plan de maintenance documenté. Il y a une procédure générale de maintenance définie dans un workflow JIRA. Celle­ci est aussi communiquée oralement aux nouveaux arrivants. Cette dernière ne fait pas de distinction entre les différents types de maintenance (corrective, préventive, etc.). Il y a une procédure écrite de mise en test et de mise en production. Celle­ci ne couvre pas les cas particuliers. Les autres procédures sont communiquées oralement au besoin. Actions requises Formaliser les procédures existantes et écrire un plan de maintenance en s’inspirant des tâches évoquées au point 5.1.2.1 de la norme. Effort requis 80 heures. Ceci est évaluation approximative de l’effort requis. 5.1.2.2 MR/PR procedures The maintainer shall (ISO/IEC 12207 sub­clause 5.5.1.2) establish procedures for receiving, recording, and tracking problem reports and modification requests from the users and providing feedback to the users. Whenever problems are encountered, they shall (ISO/IEC 12207 subclause 6.8) be recorded and entered into the Problem Resolution Process. Conformité Conforme. Le processus actuel est conforme à la norme. La réception se fait par une seule personne qui occupe de rôle de helpdesk soit par téléphone ou par courriel. Le rapport de problème / modification est enregistré dans JIRA. L’analyse, implémentation et acceptation sont gérées dans un workflow JIRA. Le feedback aux utilisateurs est automatisé sous forme d’un rapport disponible en ligne sur demande.

17 / 37

Actions requises Formaliser ces actions dans le plan et procédures de maintenance. Effort requis Inclus dans l’effort du point 5.1.2.1. 5.1.2.3 Configuration management The maintainer shall (ISO/IEC 12207 sub­clause 5.5.1.3) implement (or establish organizational interface with) the Configuration Management Process (ISO/IEC 12207 sub­clause 6.2) for managing modifications to the existing system. Conformité Partiellement conforme. Améliorations possibles. Le code source est contrôlé dans différents dépôts GIT : un pour le backend et frontend Web, et deux autres pour Android et iOS respectivement. D’autres types de documentation sont contrôlés dans Confluence, JIRA ou Google Docs. Ces outils permettent la visualisation des différentes versions et le contrôle des accès. L’outil de documentation d’API n’offre pas la gestion de versions. Il est cependant possible de retracer les changements à l’API à travers les changements au code source. Actions requises Il n’y a pas d’utilisation de branches GIT présentement. Tout le code source est sur la branche master . Quoique que cette méthode réponde bien aux besoins de l’entreprise, il y a parfois des “blocages” de mise en production, soit des délais occasionnés par du code source instable ou non terminé. Suggestions pour les branches GIT :

Master : Le code source prêt pour la mise en production. Maintenance : Corrections et améliorations demandant moins de X jours. Une branche

pour toute la maintenance. De façon générale, un seul item à la fois est en cours de résolution.

Développement : Nouveau développement, corrections ou modifications demandant plus de X jours. Chaque développement ayant sa propre branche.

Sur approbation du P.O. (étape U.A.T du processus), les branches de maintenance et de développement seraient fusionnées au master. Effort requis 20 heures effectives pour la formation de l’équipe sur une période de deux semaines.

18 / 37

Cela inclus une formation de groupe d’une heure pour les neuf développeurs (9 heures) et 11 heures d’accompagement.

2.2 Analyse de modification et de problème (Clause 5.2) 5.2.2.1 MR/PR analysis The maintainer shall (ISO/IEC 12207 sub­clause 5.5.2.1) analyze the problem report or modification request for its impact on the organization, the existing system, and the interfacing systems for the following:

a) Type; for example, corrective, improvement, preventive, or adaptive to new environment; b) Scope; for example, size of modification, cost involved, time to modify; c) Criticality; for example, impact on performance, safety, or security.

Conformité Non­conforme Les catégories actuellement utilisées sont bug pour les corrections et improvement pour les demandes de changement. L’impact est analysé de façon intuitive, sans réelle étude. Celui­ci est très rarement documenté. Les coûts, l’effort et la taille de modification sont évalués seulement si la modification / correction semble être de grande taille (plus d’une semaine à une personne). Actions requises Formaliser l’analyse dans le plan et les procédures de maintenance. Modifier les catégories dans JIRA pour l’utilisation correcte des types de maintenance : corrective, préventive, adaptative et perfective . Modifier le formulaire JIRA pour les MR/PR avec les champs appropriés pour renforcer le processus d’analyse. Effort requis La formalisation de l’analyse est incluse dans l’effort du point 5.1.2.1. La modification de la configuration de JIRA devrait demander quatre heures. La formation du personnel devrait demander quatre heures par personne. Il y a 10 personnes à former (neuf développeurs et un P.O.) pour un total de 40 heures, sur une période de deux semaines (neuf développeurs et un P. O.). Un grand total de 44 heures pour cette clause.

19 / 37

5.2.2.2 Verification The maintainer shall (ISO/IEC 12207 sub­clause 5.5.2.2) replicate or verify the problem. Conformité Conforme. Tout problème est systématiquement reproduit avant correction. Aucune modification au code source n’est effectuée si le problème n’est pas reproduit d’abord. Lorsque nécessaire, la personne ayant rapporté le problème en fait une démonstration. Actions requises Aucune Effort requis Aucun 5.2.2.3 Options Based upon the analysis, the maintainer shall (ISO/IEC 12207 sub­clause 5.5.2.3) develop options for implementing the modification. Conformité Partielle. Des options sont évaluées seulement lorsque l’impact de la modification est substantiel. Actions requises Développer au moins deux options pour chaque modification, dans le but de favoriser de la créativité et de trouver une solution optimale. Pour chaque option, être en conformité avec 5.2.2.1 MR/PR analysis . Modifier le formulaire JIRA pour les MR/PR pour y inclure les options. Effort requis La formalisation des options est incluse dans l’effort du point 5.1.2.1 Maintenance plans and procedures . L’effort de modification à JIRA est inclus dans le point 5.2.2.1 MR/PR analysis .

20 / 37

5.2.2.4 Documentation The maintainer shall (ISO/IEC 12207 sub­clause 5.5.2.4) document the problem/modification request, the analysis results, and implementation options. Conformité Non conforme. Non conforme car les points 5.2.2.1 MR/PR analysis et 5.2.2.3 Options ne sont pas conformes. Actions requises Les actions requises définies dans 5.2.2.1 MR/PR analysis et 5.2.2.3 Options rencontrent l’exigence de cette clause. Effort requis Inclus dans l’effort des points 5.2.2.1 MR/PR analysis et 5.2.2.3 . 5.2.2.5 Approva l The maintainer shall (ISO/IEC 12207 sub­clause 5.5.2.5) obtain approval for the selected modification option as specified in the contract. Conformité Conforme, dans la mesure où lorsque des options sont émises, l’option choisie est approuvée. Lorsqu’il s’agit d’une modification de type “produit”, celle­ci est approuvée par le Product Owner, qui évalue au cas par cas, s’il doit faire approuver l’option par le client. Lorsqu’il s’agit d’une modification de type “technique”, celle­ci est approuvée par le Scrum Master ou par le développeur le plus familier avec la partie du logiciel visée par la modification. Action requises Aucune. Effort requis Aucun.

21 / 37

2.3 Implémentation des modifications (Clause 5.3) 5.3.2.1 Analysis The maintainer shall (ISO/IEC 12207 sub­clause 5.5.3.1) conduct analysis and determine which documentation, software units, and versions thereof need to be modified. These shall (ISO/IEC 12207 sub­clause 5.5.3.1) be documented. Conformité Partiellement conforme. Avant toute modification, une analyse est exécutée et est révisée par un pair. Cette analyse inclus les fichiers de code source à modifier et la structure de données le cas échéant. La documentation se retrouve à différents endroits, selon le type de documentation et est documentée à différents niveaux. Voir le point 1.3 Documentation pour plus détails. Pour les modifications triviales, comme par exemple la modification d’un texte, il n’y a pas de révision par un pair. Actions requises Pour les commentaires de code source, le retard accumulé doit être rattrapé et tout nouveau code source doit être systématiquement documenté. Pour la documentation du produit, celle­ci doit être organisée par fonctionnalité et mise à jour pour refléter la dernière version du produit et aussi être mise à jour à chaque demande de changement. Effort requis Commentaires de code source

deux mois à une personne pour rattraper le retard (320 heures); un coût récurrent supplémentaire de 10% à 20% du temps de développement et

maintenance pour commenter le nouveau code source de façon systématique. Documentation produit

deux mois à une personne pour la documentation du produit (320 heures); un coût récurrent supplémentaire de 25% à 50% du temps de gestion des demandes de

changement pour mettre à jour la documentation du produit.

22 / 37

5.3.2.2 Development process The maintainer shall (ISO/IEC 12207 sub­clause 5.5.3.2) enter the Development Process (ISO/IEC 12207 sub­clause 5.3) to implement the modifications. The requirements of the Development Process shall (ISO/IEC 12207 sub­clause 5.5.3.2) be supplemented as follows:

a) Test and evaluation criteria for testing and evaluating the modified and the unmodified parts (software units, components, and configuration items) of the system shall (ISO/IEC 12207 sub­clause 5.5.3.2 a) be defined and documented.

b) The complete and correct implementation of the new and modified requirements shall (ISO/IEC 12207 sub­clause 5.5.3.2 b) be ensured. It also shall (ISO/IEC 12207 sub­clause 5.5.3.2 b) be ensured that the original, unmodified requirements were not affected. The test results shall (ISO/IEC 12207 sub­clause 5.5.3.2 b) be documented.

Conformité Conforme. Partie a)

Lorsque nécessaire, selon la complexité de modification, les composantes logicielles visées par le changement sont indiquées dans JIRA et des tests sont suggérés par le développeur.

De plus, la liste des fichiers modifiés est gérée dans GIT pour chaque modification. Partie b)

Toute modification est systématiquement vérifiée par un testeur (bien faire la chose) et validée par le Production Owner (faire la bonne chose).

Les effets de bord potentiels ( unmodified requirements ) au backend sont systématiquement testés par un outil automatisé de test d’API qui s'exécute une fois par jour.

Les applications Web, Android et iOS ne sont pas testées pour les effets de bord car elles ne présentent aucune criticité à l’intégrité des données.

Actions requises Aucune Effort Requis Aucun

23 / 37

2.4 Revue et acceptation (Clause 5.4) 5.4.2.1 Reviews The maintainer shall (ISO/IEC 12207 sub­clause 5.5.4.1) conduct review(s) with the organization authorizing the modification to determine the integrity of the modified system. Conformité Conforme. Dans le processus actuel l’ organisation autorisant la modification est un comité formé des clients et du Product Owner (PO). Le P.O. intervient à la fin du processus, soit à l’étape de UAT (User Acceptance Test). Comme entrées, le P.O. a la demande (requis), le logiciel modifié et le résultat des tests. Le P.O. vérifie lui même le changement d’un point de vue utilisateur, pour valider que le changement est conforme à ses attentes. Au niveau de l’intégrité du système, il y a deux aspects:

l'interaction entre les composantes logicielles; vérifiée par les développeurs pendant l’analyse ( 5.3.2.1 Analysis ).

la cohérence des règles d’affaires (une modification à une règle d’affaires peut être en contradiction avec une autre règle d’affaires existante).

validée par le P.O. avant la rédaction du MR ou PR; validée aussi par les développeurs pendant l’analyse ( 5.3.2.1 Analysis ).

Actions requises Aucune Effort requis Aucun

24 / 37

5.4.2.2 Approval The maintainer shall (ISO/IEC 12207 sub­clause 5.5.4.2) obtain approval for the satisfactory completion of the modification as specified in the contract. Conformité Conforme Dans le processus actuel, le P.O. approuve la demande de changement à l’étape “Approved”. Dans le cas d’un refus, la demande de changement retourne en “In progress”. Actions requises Aucune Effort requis Aucun

25 / 37

2.5 Migration (Clause 5.5) Une première migration d'environnement est prévue pour le logiciel B­CITI à la fin de l’été 2016. Un début de stratégie de migration a été formulée verbalement. Celle­ci n’est pas formalisée. Il n’existe pas de plan de migration. Mise à part la documentation dans le code source concernant les différents environnements de DEV, TEST, et PROD (voir point 1.2.4 Environnements d’opération ), aucune documentation n’existe sur l’opération du logiciel sur des environnements distincts. Le nouvel environnent a été imposé pour des questions contractuelles. Il s’agit du cloud Microsoft Azure. L’équipe technique devra donc composer avec cette décision. Cette section du travail consiste à évaluer l’effort requis et les actions à prendre pour accomplir la migration planifiée tout en étant conforme avec la norme. Il n’y a pas d’évaluation de conformité pour le processus de migration car celui­ci est à définir en entier. 5.5.2.1 Migration If a system or software product (including data) is migrated from an old to a new operational environment, it shall (ISO/IEC 12207 sub­clause 5.5.5.1) be ensured that any software product or data produced or modified during migration are in accordance with ISO/IEC 12207. Actions requises et effort L’évaluation des actions et de l’effort requis pour cette clause est fusionnée avec la clause suivante 5.5.2.2 Migration Plan .

26 / 37

5.5.2.2 Migration Plan A migration plan shall (ISO/IEC 12207 sub­clause 5.5.5.2) be developed, documented and executed. The planning activities shall (ISO/IEC 12207 sub­clause 5.5.5.2) include users. Items included in the plan shall (ISO/IEC 12207 sub­clause 5.5.5.2 ) include the following:

a) Requirements analysis and definition of migration; b) Development of migration tools; c) Conversion of software product and data; d) Migration execution; e) Migration verification; f) Support for the old environment in the future.

Actions requises Une stratégie a déjà été établie verbalement pour évaluer l’effort de migration. L’environnement de test sera d’abord migré sur le nouvel environnement. Le code source sera modifié selon la même méthodologie employée actuellement qui permet au produit de s'exécuter parallèlement sur les environnements de DEV, TEST et PROD. Il y aura donc à ce moment quatre environnements distincts : DEV, TEST (Microsoft Azure), TEST et PROD (environnements actuels). Pendant cette migration, les tests devront être conduits sur les deux environnements de tests, ce qui doublera l’effort de test. Les six items (de a) à f)) requis par cette clause devront être documentés. Lorsque que le plan de migration sera considéré comme prêt, “une répétition générale” avec les données de production, devra être effectuée pour assurer que tout se déroule bien. Effort requis L’effort de migration est difficile à évaluer avant d’entreprendre la migration de l’environnement de test. Un à trois mois d’effort à une personne, semble une estimation raisonnable. Cela inclus la documentation du plan de migration et les modifications au code source. L’effort de test devra être doublé pendant la migration. Actuellement une ressource à temps plein est assignée aux tests. Lors de la répétition générale et pendant la migration sur le nouvel environnement de production, les développeurs les plus expérimentés seront mis à disposition de l’opération de migration, soit trois personnes pendant une journée. Finalement une stratégie de “retour en arrière” devra être prévue pour réduire les risques en cas de problèmes de migration avec l'environnement de production.

27 / 37

5.5.2.3 Notification of intent Users shall (ISO/IEC 12207 sub­clause 5.5.5.3) be given notification of the migration plans and activities. Notifications shall (ISO/IEC 12207 sub­clause 5.5.5.3) include the following:

a) Statement of why the old environment is no longer to be supported. b) Description of the new environment with its date of availability. c) Description of other support options available, if any, once support for the old environment has been

removed. Actions requises Le P.O. sera en charge de notifier et de répondre aux questions des utilisateurs. Efforts requis Une journée (8 heures) pour la rédaction de la notification. Deux journée effectives (16 heures) sur une période de deux semaines pour les réponses aux questions des utilisateurs. 5.5.2.4 Implement operations and training Parallel operations of the old and new environments may be conducted for smooth transition to the new environment (ISO/IEC 12207 sub­clause 5.5.5.4). During this period, necessary training shall (ISO/IEC 12207 sub­clause 5.5.5.4) be provided as specified in the contract. Actions requises Comme expliqué précédemment (5.5.2.2 Migration Plan), le nouvel et ancien environnements de test seront en opération en parallèle. Du point de vue de l’utilisateur, la formation ne devrait pas être nécessaire. Le produit est composé d’une application Web et d’applications mobiles. Aucun changement fonctionnel n’est envisagé suite à cette migration. Il est toutefois possible que des restrictions venant du nouvel environnement imposent de légères modifications à l’application. Du point de vue des développeurs, il est fortement possible que des changements à la façon de coder soient nécessaires en ce qui a trait au backend seulement. La partie client des applications communiquent exclusivement par API REST. Aucun impact n’est donc à prévoir pour les développeurs affectés à la partie client de l’application. Effort requis Prévoir 40 heures de formation pour les développeurs backend .

28 / 37

5.5.2.5 Notification of completion When the scheduled migration arrives, notification shall (ISO/IEC 12207 sub­clause 5.5.5.5) be sent to all concerned. All associated old environment’s documentation, logs, and code should be placed in archives (ISO/IEC 12207 sub­clause 5.5.5.5). Actions requises Le P.O. sera en charge de notifier et de répondre aux questions des utilisateurs. La documentation pertinente devra être archivée, avant la début de la migration, en changeant les droits d’accès des documents existants en lecture seule. Par la suite, une copie de ces documents sera faite pour leur utilisation et évolution post­migration. La gestion du code source est sous gestion de configuration (GIT). Un tag “migration” sera créé pour identifier le code source pré et post migration. Efforts requis Une journée (huit heures) pour la rédaction de la notification. Deux journée effectives (16 heures) sur une période de deux semaines pour les réponses aux questions des utilisateurs. Trois heures pour changer les droits en lecture seule de la documentation actuelle. 5.5.2.6 Post­operation review A post­operation review shall (ISO/IEC 12207 sub­clause 5.5.5.6) be performed to assess the impact of changing to the new environment. The results of the review shall (ISO/IEC 12207 sub­clause 5.5.5.6) be sent to the appropriate authorities for information, guidance, and action. Actions requises Comme exigé dans cette clause, une analyse d’impact post­migration devra être effectuée. Le résultat sera communiqué aux parties prenantes pertinentes. De plus, cet impact pourra être anticipé lors de la migration de l’environnement de test. Rappelons que l’environnement de test actuel et de production sont identiques. Effort Prévoir un maximum de 40 heures d’effort pour la revue, l’analyse d'impact et les différentes communications avec les parties prenantes.

29 / 37

5.5.2.7 Data archival Data used by or associated with the old environment shall (ISO/IEC 12207 sub­clause 5.5.5.7) be accessible in accordance with the contract requirements for data protection and audit applicable to the data. Actions requises Toute donnée et code source en rapport avec l’ancien environnement devront être archivés et maintenus disponibles pendant quelques années ou pour toute autre durée jugée nécessaire. Les données devront être facilement accessibles. Prévoir deux formats d’archivage pour augmenter la pérennité de l’information. Si l’entreprise cesse d’utiliser les outils actuels de gestion de la configuration, une attention particulière devra être apportée pour ne pas perdre cette information. Efforts requis Une journée maximum de huit heures d’effort pour archiver l’information.

2.6 Retrait du logiciel (Clause 5.6) Cette activité ne fait pas partie de la portée de ce travail. Le logiciel B­CITI est appelé à évoluer et a rester en service pour de nombreuses années. La fermeture du service B­CITI n’est pas envisagée.

30 / 37

2.7 Tableaux résumés

2.7.1 Conformité et effort pour les quatre premiers processus Pour les quatre premiers processus : (1) implémentation du processus, (2) analyse de modification et de problème, (3) implémentation des modifications et (4) revue et acceptation l’effort total pour amener les processus actuels au niveau de conformité prescrit par la norme est de 784 heures. De plus, s’ajoute à cela une augmentation de l’effort de développement d’environ 15% avec une augmentation du temps de gestion des demandes de 37,5%.

Clause Niveau de conformité actuel Efforts requis

5.1.2.1 Maintenance plans and procedures

Non­conforme 80 heures de rédaction

5.1.2.2 MR/PR procedures Conforme

5.1.2.3 Configuration management Conforme. Améliorations possibles. 20 heures formation GIT

5.2.2.1 MR/PR analysis Non­conforme 44h (4 heures pour modifier JIRA, 4 heures x 10 personnes de formation)

5.2.2.2 Verification Conforme

5.2.2.3 Options Partielle Inclus ailleurs

5.2.2.4 Documentation Non conforme Inclus ailleurs

5.2.2.5 Approval Conforme

5.3.2.1 Analysis Conforme, sauf pour la documentation.

640h (320 code source, 320 documentation produit + 10% à 20% du temps de développement et maintenance + 25% à 50% du temps de gestion des demandes de changement

5.3.2.2 Development process Conforme

5.4.2.1 Reviews Conforme

5.4.2.2 Approval Conforme

Tableau 3 ­ Résumé du niveau de conformité et de l’effort requis (quatre premiers processus)

31 / 37

2.7.2 Effort pour le processus de migration L’effort de migration au cloud Microsoft Azure est calculé séparément des autres processus, car cette migration est un projet en soit. L’effort total en heures pour tout le personnel est d’environ 483 heures. À cela s’ajoute le double de l’effort de test pendant la migration.

Clause Niveau de conformité actuel Efforts requis

5.5.2.1 Migration À faire. Inclus ailleurs

5.5.2.2 Migration Plan À compléter et à formaliser. Min : 160 heures, max : 480 heures pour le plan et la modification du logiciel. Moyenne de 320 heures. + 100% d’effort de test pendant migration 24 heures pour la répétition générale et la migration de l'environnement de production

5.5.2.3 Notification of intent À faire. 24 heures

5.5.2.4 Implement operations and training

À faire. 40 heures

5.5.2.5 Notification of completion

À faire. 27 heures

5.5.2.6 Post­operation review À faire. 40 heures

5.5.2.7 Data archival À faire. 8 heures

Tableau 4 ­ Résumé du niveau de conformité et de l’effort requis (Processus Migration)

32 / 37

3. Plan d’amélioration Dans ce chapitre, une stratégie d’amélioration est proposée à l’entreprise dans le but d’intégrer les actions requises décrites au chapitre précédent. Cette stratégie est formulée de façon à optimiser le retour sur investissement à court terme. Rappelons l’objectif de l’entreprise en ce qui concerne la maintenance logicielle :

“améliorer son processus de gestion des demandes de changement pour assurer un service efficace à ses clients, tout en maintenant une bonne cadence de développement”

L’effort de migration est exclus de cette stratégie d’amélioration car il s’agit d’un événement ponctuel et aussi car l’objectif recherché par cette stratégie est l’optimisation du cours normal des activités de maintenance.

3.1 Ajustements supplémentaires Avant d’appliquer la stratégie décrite au point 3.2, les quelques ajustements ci­dessous sont fortement recommandés à l’entreprise. Maintenance ou développement ? Dans la littérature, la développement logiciel est défini comme une activité caractérisée par la notion de gestion de projet [Abran]. Le consensus général est que toute tâche de plus de cinq jours est considérée comme du développement [Cours]. L’entreprise devra se fixer une limite en nombre de jours et traiter toute demande comme maintenance ou développement selon la limite établie. Organisation des développeurs et mainteneurs Il faut assigner de nouvelles ressources à la maintenance, car la personne actuellement assignée à la maintenance (le Scrum Master) n’est pas en mesure de traiter suffisamment rapidement les demandes de changements et de correction. À partir de l’équipe de développement, il est recommandé d’assigner un développeur par pôle technologique (backend, frontend et mobile) à la maintenance. Cette équipe virtuelle de maintenance traitera en priorité les demandes de changement, corrections et autres tâches de maintenance. L’équipe de maintenance sera donc interrompue régulièrement dans ses tâches de développement. Il faut donc prévoir pour cette équipe des projets de développement avec des dates de livraison flexibles.

33 / 37

Les autres développeurs resteront concentrés sur leurs projets de développement. Il est préférable que ces mainteneurs occasionnels soient ceux qui connaissent le mieux l’application pour éviter des erreurs de régression dans l’application. De cette façon, l’entreprise aura une meilleure réactivité aux demandes de changements et aux corrections qui sont actuellement assumées en majeure partie par une seule personne. Catégorisation correcte Comme mentionné précédemment dans les “actions requises”, mais réitéré ici pour en souligner son importance, la catégorisation de la maintenance est essentielle pour être en conformité avec la norme, mais aussi pour orienter la priorité des travaux (les activités correctives sont généralement plus urgentes) et aussi pour produire des analyses et observer les tendances de l’activité de maintenance [Abran] Swimlanes JIRA Actuellement, les activités de maintenance et de développement sont regroupées dans le même tableau Kanban­Scrum. Ce tableau offre peu de visibilité sur l’état des tâches de maintenance. Il est recommandé de configurer JIRA avec des deux swimlanes , un pour la maintenance et un pour le développement, pour bien exposer à toutes les parties prenantes les tâches de maintenance en cours.

3.2 Stratégie d’amélioration La stratégie proposée consiste à maximiser l’investissement rapidement. Les actions demandant peu d’effort sont donc priorisées. Les tableaux ci­dessous regroupent l’effort précédemment cité par catégories d’actions.

Étapes Action Effort

1 Adapter JIRA 4 heures

2 Formation de l’équipe au JIRA modifié 40 heures (4 heures x 10 personnes)

3 Formation de l’équipe au processus GIT modifié

20 heures (1 heure x 9 personnes et 11 heures d’accompagnement)

À ce stade­ci, l’équipe de développement commente de façon systématique tout nouveau code source. + 10% à 20% du temps de développement et maintenance

Tableau 5 ­ Stratégie d’amélioration du processus de maintenance : Étapes essentielles Les étapes un (1) à trois (3) sont essentielles pour obtenir une amélioration du processus de maintenance. L’adaptation de l’outil JIRA aura comme résultat de reproduire le processus de maintenance à même l’outil, forçant les mainteneurs à suivre le processus ajusté.

34 / 37

De plus à l’étape 3, il a été entendu avec tous les développeurs que le nouveau code source est documenté convenablement.

Étapes Action Effort

4 Rédaction du plan de maintenance 80 heures de rédaction

À ce stade­ci, l’entreprise doit prendre une décision si elle veut investir 320 heures pour rattraper le retard de documentation dans le code source, ou encore si ce retard sera repris sur plusieurs mois (voire des années) par les activités de maintenance.

5 Reprendre le retard de documentation dans le code source

320 heures

Selon la même logique qu’avec le code source, l’entreprise doit prendre une décision si elle veut investir 320 heures pour rattraper le retard de documentation produit. Si oui : continuer à l’étape 6. Si non : fin du plan d’amélioration.

6 Reprendre le retard de la documentation du produit.

320 heures

À ce stade­ci, la documentation du produit est mise à jour systématiquement. + 25% à 50% du temps de gestion des demandes de changement

Tableau 6 ­ Stratégie d’amélioration du processus de maintenance : Étapes optionnelles Les étapes de quatre (4) à six (6) sont optionnelles si l’entreprise décide de ne pas obtenir la conformité à la norme. Par contre, l'omission de ces étapes aura un coût sur l’activité de maintenance. Ce coût est difficile à évaluer car il ne se calcule pas directement. Il inclus entre autres :

pertes de temps dues à une documentation incomplète, mal classée ou inexistante; des erreurs de programmation dues à une mauvaise interprétation du code (lorsque la

documentation est absente). D’un point de vue purement économique, est­ce que d’investir le temps requis dans le rattrapage de la documentation sera rentable, et après combien de temps ? Recommandation Il est recommandé à l’entreprise de procéder au rattrapage de la documentation. Le temps total à prévoir pour les étapes quatre (4) à six (6) est de 720 heures, ce qui revient à 80 heures par développeur / mainteneur pour une équipe de neuf développeurs, ou encore l’équivalent 4% de leurs temps de travail sur une année.

35 / 37

Conclusion Dans ce rapport, il a été question de l’utilisation de norme ISO 14764 dans l’entreprise B­CITI. Retour sur le rapport La situation actuelle de l’entreprise B­CITI a été présentée, soit le logiciel B­CITI, les processus de développement et de maintenance, l’état de la documentation ainsi que les environnements d’opération. Une évaluation de la conformité actuelle des processus de maintenance en regard de la norme ISO 14764 à été présentée. Pour les 12 clauses des quatre premiers processus de la norme :

six sont respectées; trois sont partiellement respectées; trois ne sont pas respectées.

Des actions ont été proposées pour que l’entreprise se mette en conformité avec ces quatre processus. L’effort total requis pour implémenter ces actions est d’environ de 784 heures. En regard du processus de migration, des actions ont été proposées en rapport avec la migration prévue de B­CITI vers le cloud de Microsoft Azure. L’effort de migration a été évalué à 483 heures et respecte les clauses du processus migration de la norme ISO 14764. Observation de l’auteur L’auteur de ce rapport a été présent de la conception initiale de B­CITI jusqu’à la rédaction de ce rapport. Il a entre autres participé à l’implémentation des processus de développement et de maintenance actuels ainsi qu’à leurs mise en oeuvre dans l’outil JIRA. Avant de débuter ce rapport, l’auteur s’attendait à un niveau de conformité nettement inférieur. Il est donc recommandé à cette jeune entreprise de se conformer à la norme dans les plus brefs délais et de ne pas laisser le retard s’accumuler. Une fois les points d’amélioration corrigés, il est aussi recommandé de demander une évaluation de la conformité à un consultant externe avant de s’engager dans les processus d’audits officiels qui peuvent se révélés coûteux. Une première version de ce rapport a été remis à la direction de l’entreprise, mais n’a pas été présenté ni discuté dans l’organisation vu les urgences de livraison.

36 / 37

Références bibliographiques [Abran] Abran A. et Nguyenkim H., Measurement of the Maintenance Process from a Demand­base Perspective , Software Maintenance: Research and Practice, vol. 5. 63­90, 1993 [April] April A., Abran A., Améliorer la maintenance du logicie . 2ième édition, Loze‑Dion éditeur, 2016, 341 p. [Confluence] Atlassian, Confluence ­ Team Collaboration Software , https://www.atlassian.com/software/confluence , consulté le 1er juin 2016. [Cours] April A., MGL804­01 Cours Magistral , École de technologie supérieure, Été 2016. [ISO 12207] ISO/IEC, ISO/IEC 12207 Systems and software engineering — Software life cycle processes , ISO, 2008. [ISO14764] ISO/IEC, ISO/IEC 14764 Software Engineering — Software Life Cycle Processes — Maintenance , ISO, 2006. [JIRA] Atlassian, JIRA Software ­ Issue & Project Tracking for Software Teams , https://www.atlassian.com/software/jira , consulté le 1er juin 2016. [Workflow] Auteur Variés, Workflow , https://fr.wikipedia.org/wiki/Workflow , consulté le 1er juin 2016.

37 / 37