Architecture Conception Développement Déploiement Architecture d'information Architecture d'affaires Architecture fonctionnelle Plan de réalisation Règles d'affaires Scénarios Interfaces Formation utilisateurs Maintenance et évolution Soutien 2ème ligne Codage Tests unitaires Tests fonctionnels

Voici de façon sommaire mais globale, la manière dont nous abordons les projets de réalisation de systèmes d’information corporatifs. Notre approche de développement puise ses origines dans la théorie du système général, Datarun et les méthodes dites agiles .
L’approche se décline en 4 grandes phases :

  1. Architecture;
  2. conception;
  3. développement;
  4. déploiement.

 

Architecture

La phase architecture se décline en la réalisation de l’architecture d’affaires, l’architecture d’information, l’architecture fonctionnelle et un plan de réalisation.

Architecture d’affaires

L’architecture d’affaires consiste à décrire dans un formalisme rigoureux, les processus de travail de l’ensemble des secteurs d’activité de l’organisation dans le cas d’une architecture d’affaires globale ou d’un secteur en particulier si le besoin est circonscrit et spécifique à une division ou un service de l’organisation.
La conception de cette architecture vise à atteindre cinq objectifs :

  1. Représenter et formaliser le fonctionnement de tous les secteurs d’activité de l’organisation;
  2. cristalliser une vision commune du fonctionnement et la partager;
  3. identifier les flux d’information consommés et générés par les différents processus de l’organisation. Ceci constitue un préalable à la réalisation de l’architecture d’information;
  4. garantir une vision centrée sur les besoins d’affaires de l’organisation pour mieux concevoir ou choisir les outils informatiques. L’idée maîtresse est de subordonner les choix informatiques aux besoins d’affaires et d’éviter la sophistication à outrance;
  5. assurer le maintien d’une vision intégrée lors de la mise en place des solutions informatiques.

La réalisation de l’architecture d’affaires se fait en 8 étapes :

  1. Identification des secteurs d’activités de l’organisation à couvrir;
  2. identification des ressources représentatives de chaque secteur d’activité;
  3. lecture de la documentation pertinente de chaque secteur d’activité;
  4. réalisation d’entrevues individuelles (durée approximative d’une heure et demie) avec chaque ressource identifiée ;
  5. élaboration d’une première version du modèle de fonctionnement de chaque secteur d’activité;
  6. validation individuelle avec la ressource identifiée;
  7. présentation à la direction générale;
  8. dépôt d’un document final qui consigne l’architecture d’affaires.

 

Architecture d’information

L’architecture d’information constitue la fondation du futur système d’information. Elle permet de recenser et d’organiser la structure d’information que le système manipulera. Les biens livrables de cette architecture sont un modèle de données et un référentiel décrivant l’ensemble des entités informationnelles (exemple : Membre, Établissement, Mandat, etc.) et leurs caractéristiques. Le modèle de données est une représentation schématique des entités informationnelles, leurs propriétés et leurs relations les unes avec les autres. Il constitue l’intrant principal à la structure de la future base de données du système.

Architecture fonctionnelle

L’élaboration de l’architecture fonctionnelle consiste à identifier et décrire de façon précise et exhaustive les modules du futur système d’information et pour chaque module, l’ensemble des fonctions qui seront implantées. Le vocable pour désigner chacune de ces fonctions est cas d’utilisation. Un cas d’utilisation est une façon d’exprimer l’interaction entre un utilisateur et le système dans le cadre de la réalisation d’une tâche précise. À ce stade, les cas d’utilisation sont identifiés et décrits en termes généraux. Les acteurs des cas d’utilisation sont aussi identifiés. Les acteurs sont les entités (personnes ou autres programmes) qui interagiront avec le système.

Estimés et plans de réalisation

L’architecture d’affaires consiste à décrire dans un formalisme rigoureux, les processus de travail des secteurs d’activité de l’organisation. Il peut s’agir d’une architecture d’affaires globale ou encore d’une architecture à portée réduite si le besoin est circonscrit et spécifique à une division ou un service.

Conception

Cette phase se déroule de façon concomitante avec la phase Développement. Elle est menée par les analystes d’affaires et consiste pour chaque cas d’utilisation identifié dans l’architecture fonctionnelle, à élaborer les scénarios d’interaction détaillés entre l’utilisateur et le système, à concevoir les interfaces utilisateurs et à identifier et formuler les règles de validation qui doivent être mises en place pour garantir l’intégrité et la qualité des données manipulées par le système.
Une interaction continue entre l’analyste et l’utilisateur à ce niveau garantit que ce qui est conçu correspond bien au besoin. Cela dit, nous prenons grand soin de ne pas déranger indûment les utilisateurs. L’interaction prend souvent la forme d’une réunion initiale pour circonscrire l’étendue fonctionnelle, une présentation d’une première ébauche de solution pour fin de validation et une présentation finale. Entre temps, il est possible que l’analyste communique de façon ad-hoc et pour des questions très précises avec l’utilisateur pour clarifier certains points de détails.

Scénarios d’interaction

L’élaboration du scénario d’interaction entre un acteur et le système constitue le noyau du cas d’utilisation. Les analystes d’affaires s’appuient sur la connaissance de l’organisation acquise pendant la phase d’architecture pour établir de façon détaillée, pour chaque cas d’utilisation, les informations que le système devra présenter à l’utilisateur et la manière dont ce dernier réagira pour lui permettre d’accomplir ses fonctions organisationnelles.

Conception des interfaces

La conception des interfaces pour chaque cas d’utilisation est la matérialisation du scénario d’interaction. Un même scénario peut être matérialisé par des interfaces différentes en fonction par exemple, du type de dispositif (ordinateur de table, tablette, téléphone intelligent ou système téléphonique) sur lequel s’exécute le cas d’utilisation. Ici, l’analyste propose une ébauche d’interface au développeur qui en évalue la faisabilité et l’adéquation avec les outils de développement à sa disposition.

Règles d’affaires

Une règle d’affaires est une assertion dont le système se doit d’assurer le respect en tout temps. À titre d’exemple, un compte de dépenses ne peut être payé sans l’autorisation préalable d’un directeur, est une règle d’affaires qui bien implantée, garantira que le système ne permettra à aucun utilisateur de payer un compte de dépenses non autorisé.   Il est important de mentionner ici que les règles d’affaires sont indépendantes des cas d’utilisation: quelle que soit la façon dont le paiement du compte de dépenses sera effectuée par le système, cette règle doit être respectée en tout temps.  En ce sens, il est possible de concevoir les règles d’affaires en dehors du contexte du cas d’utilisation avec lequel elles ont une affinité.  Cela dit, nous avons fait le choix méthodologique de nous servir du cas d’utilisation comme vecteur d’identification des règles d’affaires par souci d’efficacité.  Nous avons constaté que la personne qui conçoit le cas d’utilisation est la mieux préparée à découvrir les règles d’affaires qui lui sont sémantiquement liées.

Développement

Cette phase est menée par les développeurs logiciels en interaction avec les analystes d’affaires. En général, un analyste et un développeur sont jumelés pour la réalisation de chaque cas d’utilisation. Comme nous croyons que la réflexion se bonifie dans l’action, nous n’attendons pas que l’analyse d’un cas d’utilisation soit terminée pour en commencer le développement. Aussitôt qu’une première ébauche d’analyse est terminée, le développement commence et c’est le produit de ce développement qui est utilisé pour valider avec l’utilisateur. La validation est de meilleure qualité lorsqu’elle est basée sur un système qui fonctionne que sur une documentation théorique.

Codage

Il s’agit ici de la programmation proprement dite des cas d’utilisation. Nous disposons d’une « boite à outils » que nous avons développée et que nous appelons les « Fondations ». Elle fournit un cadre formel de programmation qui garantit une certaine uniformité quant aux standards de programmation et une uniformité certaine quant aux interfaces développées. En plus d’augmenter considérablement notre productivité en permettant une véritable réutilisation de code commun, les Fondations nous permettent de réagir très rapidement aux changements qui ne manquent de survenir en cours de développement et après le déploiement.

Tests unitaires

Les tests unitaires se font au fur et à mesure que le développement avance. Ce sont des tests programmés par les développeurs et qui garantissent que les programmes informatiques développés remplissent leur « contrat ». Ces tests sont automatisés et exécutés régulièrement. Ils garantissent que les modifications apportées aux programmes n’introduisent pas d’erreurs et minimisent l’apparition d’effets de bord non-désirés.

Tests fonctionnels

Les tests fonctionnels sont réalisés par les analystes d’affaires. Ils visent à vérifier la conformité des cas d’utilisation développés avec les spécifications demandées et le déclanchement approprié des règles de validation. Les bogues et erreurs trouvés sont consignés dans une base de données conçue à cet effet et sont corrigés par ordre de priorité par les développeurs.

Déploiement

Le déploiement consiste à mettre le système en production après avoir formé les utilisateurs et à les soutenir pendant les premières semaines d’utilisation. Le soutien est fait par les analystes d’affaires quand il s’agit de répondre à des questions d’utilisation ou de compréhension de la fonctionnalité du système et par les développeurs pour corriger et redéployer le système en cas de découverte de bogues qu’on n’a pas réussi à découvrir pendant la phase de tests.

Formation des utilisateurs

La formation des utilisateurs au nouveau système se fait dans les jours qui précèdent sa mise en production. Elle est en général, livrée par les analystes d’affaires qui ont participé à la conception des cas d’utilisation. Si le nombre d’utilisateurs à former est grand, il n’est pas rare que les développeurs participent aussi aux formations.

Soutien de deuxième ligne

En plus de former les utilisateurs du futur système, nous formons aussi le personnel de soutien du client pour qu’il soit en mesure de venir en aide aux utilisateurs. De façon générale, le soutien de première ligne est donné par le personnel interne du client. Cela dit, dans les jours qui suivent la mise en production, nous pouvons participer au soutien de première ligne. Nous restons toujours à la disposition du client pour effectuer le soutien de 2ème ligne et nous l’abordons de telle sorte que le personnel interne du client devienne de plus en plus autonome quant à l’aide apportée aux utilisateurs et à l’administration du système.

Maintenance et évolution

Suite au déploiement du système, nous restons disponibles pour en effectuer la maintenance et l’évolution dans le but de le garder à jour technologiquement parlant mais aussi pour l’adapter aux réalités changeantes de l’organisation.

Si vous désirez en savoir plus sur ce que nous faisons et sur nos méthodes, n’hésitez pas à nous contacter