Élaborer un cas conceptuel pour Open Source

Avant toute forme de développement ou d’acquisition, les propriétaires fonctionnels devraient définir à la fois un cas conceptuel et une exigence opérationnelle pour tout projet numérique.

Un cas conceptuel détermine les renseignements clés sur lesquels un projet numérique possible doit être fondé, et doit être achevé avant que l’exigence opérationnelle ne soit établie.

Une exigence opérationnelle est différente des exigences fonctionnelles, et plus grandes, ou des exigences techniques d’un projet numérique seulement. Une exigence fonctionnelle définit une fonction particulière du logiciel afin d’obtenir un résultat et répond à une exigence opérationnelle plus précise. Une exigence technique définit une capacité ou les attributs nécessaires pour travailler avec d’autres logiciels, et exprime la décision architecturale plus vaste d’appuyer le projet.

L’exigence opérationnelle comprend l’examen des exigences fonctionnelles et techniques, mais aussi d’autres éléments généraux, afin de répondre à la nature, à l’objectif et aux besoins du projet numérique à un niveau élevé. Par conséquent, l’exigence opérationnelle dictera la voie à suivre pour l’acquisition et le développement de logiciels, et les exigences techniques et fonctionnelles ne peuvent être utilisées seules comme justification aux fins d’une évaluation des avantages des logiciels libres ou des logiciels propriétaires.

L’annexe C de la Politique sur la planification et la gestion des investissements prévoit des procédures obligatoires pour les cas conceptuels pour les projets numériques. Même si la directive ne s’applique qu’aux projets dépassant un certain seuil, il est important de noter que la grande majorité des cadres de gestion de projets agiles commencent par un artefact qui correspond à un cas conceptuel comme une vision de projet ou des objectifs de projet.

Évaluer les exigences

Les exigences techniques et fonctionnelles ne peuvent être utilisées comme justification aux fins d’évaluation des logiciels libres et des logiciels propriétaires, uniquement pour les exigences opérationnelles. Voici des exemples d’éléments qui peuvent être pris en compte dans la création d’exigences opérationnelles, mais il est important de se rappeler que les règles d’approvisionnement peuvent requérir que les exigences opérationnelles permettent l’offre de logiciels propriétaires et de logiciels libres.

Utilisation des normes internationales ou canadiennes

Les exigences opérationnelles peuvent requérir que la demande sous-jacente soit conforme aux normes internationales ou canadiennes, par exemple, sans toutefois s’y limiter, l’exigence selon laquelle les langues officielles exigeant que le logiciel soit disponible dans les deux langues officielles.

Flexibilité de la licence

Les licences de logiciels libres peuvent offrir plus de flexibilité qu’une licence propriétaire pour les produits livrables d’un projet numérique. Si l’exigence opérationnel profiterait de la réutilisation du logiciel, le GC peut acquérir un logiciel afin de pourvoir l’utiliser dans des projets ultérieurs au GC. Un titulaire de licence de logiciel propriétaire peut accorder ce droit de réutilisation sur demande, mais par sa nature, tous les logiciels libres sont réutilisables et donc conformes à cette demande par défaut.

Possibilité d’utiliser à n’importe quel usage

Les exigences opérationnelles peuvent être définies de telle sorte que le logiciel puisse être utilisé à n’importe quel usage, sans aucune restriction, ou permettre à d’autres utilisateurs d’utiliser le logiciel. Les conditions du logiciel libre sont plus susceptibles de respecter cette exigence.

Capacité d’évaluer le code

Le GC peut fixer ses exigences de sorte que le code source soit disponible aux fins d’audit par un tiers afin de déterminer la qualité, la fonctionnalité et la sécurité du logiciel.

Harmonisation avec le Gouvernement ouvert

En outre, le GC peut fixer ses exigences de sorte que le code source soit fourni au public afin de permettre une plus grande transparence et de s’harmoniser avec les principes du gouvernement ouvert dans la charte du D9.

Possibilité de distribuer le logiciel

On peut établir des exigences opérationnelles de telle sorte que le logiciel puisse être distribué à n’importe qui, par choix, afin de s’assurer que les autres institutions de la Couronne n’ont pas besoin de devenir des clients du fournisseur initial pour accéder aux services fournis par un autre organisme et les utiliser. Par exemple, la Couronne fédérale pourrait souhaiter pouvoir fournir le logiciel sans frais supplémentaires aux institutions provinciales ou municipales.