MODULE No 17

Titre : Principes d’opération

But : Présenter une table des matières pour le document « Principes d’opération » (Concept of Operation) selon IEEE std. 1362

Antécédents : Module 16

Corps :

Le chemin du « problème » aux programmes qui le résolvent est souvent un chemin long et tortueux. Mais s’il est vrai que l’un des mots les plus importants du GL est « maîtrise » (c’est-à-dire contrôle des coûts, de l’échéancier et de la qualité) alors il faut au moins deux éléments pour « avoir une certaine assurance que l’on s’en va dans la bonne direction » :

1. une méthode de travail qui facilite l’enchaînement des activités et qui décrit plus ou moins en détail ce qu’il faut faire à un moment donné, afin que la progression du travail soit sous contrôle ;
2. un certain nombre d’artefacts dont on connaît l’organisation et le type de contenu attendu. Lorsque l’artefact est un document, une façon de donner l’organisation, c’est d’en donner la table des matières commentée.

Si on ne veut pas partir dans une mauvaise direction, l’un des premiers artefacts que l’on doit produire est un document qui décrit au moins :

1. La situation actuelle (celle dans laquelle il y a un manque, un problème) ;
2. Ce que l’on aimerait avoir pour régler la situation actuelle

Il existe un standard de IEEE (IEEE Std 1362-1998) qui donne une table de matière pour ce type de document que l’on appelle « Principes d’opération » et Concept of Operation en anglais, dont l’abréviation, parmi les ingénieurs du logiciel, est ConOps.

On peut considérer le ConOps comme le premier élément stable que l’on bâtit après la « découverte » du problème et la décision de chercher une solution.

On peut considérer le ConOps comme le premier artefact

officiel sur lequel l’on peut s’appuyer pour viser un plus grand

détail et une plus grande précision, celle qui caractérisera les artefacts

suivants. Combien d’artefacts faut-il réaliser avant le programme final (avant le codage) ? Cela dépend des méthodes de l’entreprise, du type d’application, des exigences contractuelles, etc.

Ce qui est certain, c’est qu’un artefact du genre du ConOps est essentiel.

Note : un appelle « officiel » un artefact qui constitue le logiciel (à ne pas oublier que le logiciel en GL n’est pas seulement le programme final !) et dont on contrôle l’évolution. En GL on appelle Contrôle de la configuration le processus constitué des activités qui permettent de s’assurer que, à chaque moment, on dispose des bonnes versions des artefacts.

Vous pouvez consulter les deux liens suivants :

http://www.trempet.uqam.ca/Enseignement/Cours/MGL7260/Hiver2006/NotesdeCours/Conops.mht

http://www.trempet.uqam.ca/Enseignement/Cours/INF5151/Hiver2008/ConOpsEte2007.pdf

Le premier lien vous donne un fichier Power Point qui décrit en détail la table des matières.

Le deuxième vous donne un ConOps (pas nécessairement fantastique !) écrit par une équipe de INF5151 à l’été 2007.

Conséquents :

· Connaître les buts du ConOps et le type de contenu.

· Pouvoir consulter un exemple assez simple réalisé par des étudiants

Note 01 : Une seule modification de la table des matières d’IEEE 13622-1998 d’une certaine importance a été introduite : le chapitre 9 a été intégré dans le chapitre 2.