La documentation des systèmes d’information

Les principales méthodes de développement de systèmes d’information sont la méthode structurée et la méthode orientée objet. Alors que la méthode structurée ne s’intéresse principalement qu’à la hiérarchisation et l’organisation des processus, la méthode orientée objet s’intéresse aux relations entre les processus et les données.  Que les développeurs de systèmes d’information préconisent des méthodes structurées, des méthodes orientées objet, ou un mix des deux méthodes, ils doivent nécessairement utiliser des stratégies pour développer leurs systèmes. J’examinerai aujourd’hui les stratégies de développements de systèmes d’information basées sur l’utilisation de progiciels ou de logiciels libres. Je mettrai l’emphase sur l’importance de la documentation dans le choix d’une ou l’autre de ces stratégies.

La méthode structurée

La méthode structurée est une méthode classique pour hiérarchiser des processus en fonction de leur importance. C’est la fameuse arborescence qui sert à visualiser l’architecture structurelle des besoins d’un système. Au haut de la pyramide se trouvent les processus les plus généraux qui sont divisés et subdivisés jusqu’au bas de la pyramide en processus de moins en moins génériques et de plus en plus spécifiques.

Méthode structurée - source: www.francparler.org

L’arborescence de la méthode structurée est un bon outil pour établir les similarités structurelles de l’ensemble des processus d’un système. En ce sens, la méthode structurée peut être utile pour visualiser les relations de la méthode orientée objet. De plus, elle établit des bases solides pour comprendre l’utilisabilité d’un système, c’est-à-dire la convivialité avec laquelle les utilisateurs pourront interagir avec les processus de celui-ci.

La méthode orientée objet

La méthode orientée objet est non seulement très utile aux développements de systèmes d’information, mais peut aussi être utilisée pour structurer les informations d’un système en objets réutilisables. Si, par exemple, un site de commerce électronique contient 10 000 items, il est fort probable que ces « objets » possèdent des caractéristiques communes et que l’ensemble des interactions possibles avec ces « objets » soit généralisé pour l’ensemble du site. Les caractéristiques communes des objets sont par exemple leur prix, leur poids, leur provenance, leur couleur, etc. Les interactions possibles avec ces objets peuvent être le fait qu’un utilisateur puisse en visualiser les caractéristiques, les ajouter à un panier de commerce électronique, ou les acheter.

Méthode orientée objet | Source : www.sitepoint.com

La programmation orientée objet considère un système en tant qu’un ensemble organisé, un assemblage de blocs qui possèdent des attributs et des méthodes.  Les attributs forment l’essence d’un objet (ses caractéristiques) alors que les méthodes lui permettent de communiquer avec son environnement ou avec d’autres objets. La méthode orientée objet représente donc les objets et leurs relations ainsi que les façons dont ils communiquent entre eux afin de produire les fonctionnalités voulues. C’est donc dire que ce ne sont pas seulement les processus qui sont importants, mais bel et bien les données qui entrent en relation avec ces processus.

Les relations entre les processus et les données

Puisqu’elle doit définir un ensemble de propriétés et de relations, la méthode orientée objet nécessite une mise en place plus longue, mais son pouvoir d’abstraction permet des développements plus rapides dans le futur.   D’une part, puisque les attributs et les méthodes des objets sont encapsulés,  ils peuvent être modifiés sans que cela nuise au fonctionnement des systèmes ou aux interactions avec les utilisateurs. D’autre part, puisque les attributs et les méthodes sont des abstractions, ils peuvent facilement être réutilisés et adaptés pour d’autres développements. On perd donc du temps à utiliser des méthodes orientées objet pour gagner du temps plus tard.

Pour des projets à court terme, il n’y a pas davantage à utiliser des méthodes orientées objet, tant pour le client que pour le développeur. Le temps que nécessite le développement d’une boîte à outils d’objets génère en effet des coûts de production plus élevés. C’est sans compter le grand nombre d’heures qui doit être consacré à la documentation des attributs de ces objets et de leurs méthodes afin d’assurer les développements futurs. Il n’en demeure pas moins qu’il peut être avantageux d’assumer ces frais afin d’améliorer la productivité future. À moyen et à court terme, des objets bien conçus permettent en effet au développeur de recycler rapidement les objets, ou d’en adapter et d’y ajouter des méthodes pour répondre aux exigences d’un nouvel environnement. Le client peut aussi profiter de cette malléabilité, surtout s’il favorise le prototypage (version Beta) aux processus formels de cycles de vie (Diagramme de Gantt de MS project), et qu’il considère son système d’information comme un moyen terme pour réaliser ses besoins d’affaires et non pas comme sa finalité.

L’utilisation des progiciels ou des logiciels libres

Les progiciels et les logiciels libres résultent de l’implémentation d’objets et de leur structuration dans des systèmes d’information qui sont offerts aux organisations pour répondre à des besoins d’affaires précis. Alors que les logiciels libres sont gratuits et sont développés par une communauté mondiale de contributeurs, les progiciels sont des applications ou des services payants qui sont développés par des compagnies privées. Les nombreux services de cloud computing (informatique dématérialisée ou l’informatique dans les nuages) sont des exemples populaires de progiciels. Les gestionnaires de contenu Web (CMS) comme Drupal ou Joomla! ou le logiciel pour bloguer de WordPress sont d’excellents exemples de logiciels libres.

L’avantage des méthodes de développement qui se basent sur des progiciels ou sur des logiciels libres est de bénéficier du pouvoir d’abstraction mis en place par d’autres développeurs et de se les réapproprier pour les besoins de son entreprise. Au lieu de développer un système d’information pendant plusieurs semaines pour répondre aux besoins d’affaires spécifiques d’une entreprise, les fondements existants d’une infrastructure, d’une plateforme, ou d’une application peuvent être réutilisés, ce qui fait diminuer radicalement le temps de conception et les prix que les clients doivent payer pour la mise en place de leurs solutions. Plutôt que de payer pour le développement du système en tant que tel, les clients paient pour sa mise en place, son paramétrage, sa personnalisation ou la programmation de nouveaux modules et de nouveaux objets.

Les problèmes de la documentation

Il est à noter que, tant pour les logiciels libres que pour les progiciels, la documentation laisse souvent à désirer. Les logiciels libres sont souvent accompagnés d’une documentation non exhaustive, conçue trop rapidement et de façon non systématique, dans la frénésie des développements chaotiques et collaboratifs des communautés de programmeurs. L’économie de temps pour mettre en place un système peut parfois être perdue à chercher la documentation afin d’en modifier tel ou tel aspect. Même s’il faut payer pour acheter des progiciels, leur documentation est souvent déficiente. Des forums sont souvent mis à la disposition des développeurs à l’intérieur desquels il est souvent très difficile de trouver des sources véridiques d’informations, car les modérateurs laissent tout le monde dire n’importe quoi (une stratégie très bénéfique pour le référencement sur les moteurs de recherche)

Les logiciels libres ont la réputation d’être plus adaptables, mais moins bien documentés que les progiciels qui sont “mieux documentés” mais moins bien adaptables. Les questions principales à se poser quand vient le temps de choisir entre l’utilisation des progiciels ou des logiciels libres sont :

1. Est-ce que je peux trouver une solution que je n’ai pas besoin d’adapter et qui réponde parfaitement à mes besoins d’affaires?
2. Si c’est le cas, quelles sont les perspectives de développements futurs de cette solution? Et quelle est la qualité de sa documentation ou de son service à la clientèle?
3. Si ce n’est pas le cas, est-ce que je peux adapter la solution afin qu’elle réponde parfaitement aux besoins d’affaires de mon organisation? Est-ce que je dispose d’une documentation convenable pour m’aider dans mes développements?
4. D’une manière ou d’une autre, quels seront mes besoins d’affaires dans 5 ans?

Que ce soit dans le cas d’un progiciel ou d’un logiciel libre, la qualité de la documentation des systèmes d’information qui sont sélectionnés ne doit pas être sous-estimée. Alors qu’il est primordial que la documentation des progiciels mette en évidence les liens structuraux d’un système (son guide d’utilisation), c’est plutôt du côté des composantes du système et des relations entre les processus et les données que réside le pouvoir attractif de la documentation des logiciels libres. En ce sens, l’utilisation des systèmes d’information basés des progiciels découle peut-être d’un style plus structuré alors que la mise en place d’un système d’information basé sur des logiciels libres répond à un style orienté objet.

*

Considérez-vous votre style comme étant plus structurel ou plus orienté objet? Est-ce que vous utilisez des progiciels ou des logiciels libres dans votre organisation? Préférez-vous développer vos systèmes d’information à l’interne ou utilisez-vous plutôt des ressources externes pour vous aider dans vos développements? Quelle importance accordez-vous à la documentation? Utilisez-vous d’autres stratégies pour développer vos systèmes d’information? Tant de questions, si peu de temps.

La photo provient du site du Centre for the advanced study of contemporary performance practice at Lancaster University (CASCPP).