|
MODULE No 8 |
|
Titre : Quelques mots à propos de la norme ISO 12207 |
|
But : Montrer la norme pour mieux situer le travail de l’analyste. |
|
Antécédents : Module 3 |
|
Corps : 1. Introduction Avant d’introduire la norme (ISO 12207[1]), quelques mots à propos de l’intérêt et de l’importance de la normalisation dans la technique et en GL en particulier. Ce n’est certainement pas étonnant si j’écris qu’afin que deux entités communiquent (c’est-à-dire afin qu’elles échangent des informations qui influencent leur comportement) il faut qu’elles partagent :
Si les deux entités sont des machines les trois éléments précédents doivent être définis de manière non ambiguë. On peut, par exemple, considérer que le protocole http est défini sans ambiguïtés et cela permet à deux machines de réaliser certains types d’échanges dans un environnement Internet. Ce qui est loin de vouloir dire que http permet de comprendre la sémantique de ce qu’il « porte sur son dos » : ce qui est contrainte entre des mots du protocole dont la sémantique est complètement définie. Lorsque la communication se passe entre des êtres humains on peut se permettre beaucoup plus d’ambiguïtés, même si les ambiguïtés sont dangereuses et génèrent parfois d’énormes problèmes. Il est donc très importants de différencier les normes qui règlent les communications entre les humains de celles qui règlent les communications entre les machines. En GL les normes pour la communication entre les humains sont particulièrement nombreuses et importantes. L’organisation des ingénieurs en électricité et en électronique américains (IEEE) a produit un grand nombre de normes pour la communication entre humains en GL. 2 ISO 12207 Attention : elle donne un cadre en définissant des activités mais elle ne donne pas d’indications sur comment les activités devraient s’agencer : c’est-à-dire qu’elle ne donne pas de description du cycle de vie du logiciel. Mais, qu’est-ce qu’un processus ? Une suite d’activités reliées entre elles qui transforment des entrées en sorties pour atteindre un certain but. La norme définit 17 processus pour la réalisation, l’entretien et l’opération d’un produit logiciel. Trop ? Pas assez ? Difficile de le dire sans regarder ce que chaque processus contient (C’est-à-dire ses activités). Ce qui est certain, c’est que 17 est trop pour pouvoir avoir une perception claire de comment doit être structuré le travail en GL. En effet les 17 processus ont été organisés en 3 grandes catégories :
Les processus sont constitués d’activités et les activités de tâches. Les tâches étant les constituants de base pour la gestion de projet. Voici une manière de représenter ce que l’on vient de dire avec
Cette figure est l’occasion pour un deuxième contact avec Voir les modules 4 pour l’explication de la notation employée dans la figure précédente La figure suivante montre une autre manière de montrer un processus : Un processus reçoit des artefacts en entrée que les ressources employé dans le processus transforment dans des artefacts en sortie su processus (Extrants). La transformation est faite via les activités (A1 et A2 dans la figure). Un déclencheur fait commencer les activités du processus. Une activité peut avoir des intrants qui proviennent d’une activité interne au processus ou d’une activité d’un autre processus. Les extrants d’une activité peuvent être des intrants pour une activité interne au processus ou pour une activité externe. Dans la figure A1 a les deux types d’extrants. Un contrôle permet de faire le suivi des tâches pour maîtriser la production du logiciel. Les tâches (parties d’activités ne sont pas représentées dans la figure.
Les cinq notes suivantes aident à éclaircir la portée de la norme. Note 1 : la norme n’a pas comme but de définir les intrants et les extrants des activités qui composent le processus ni d’en donner l’enchaînement temporel. On laisse les ingénieurs du logiciel libres de choisir le modèle du cycle de vie du logiciel qui mieux s’adapte à leur projet et à leur entreprise. Note 2 : la norme ne s’applique pas aux « produits tablette » à moins que ceux-ci ne soient pas intégrés dans un produit assujetti à un contrat de fourniture/acquisition. On suppose, justement, que les « produits tablette » ont besoin de moins de formalismes de contrôle. Note 3 : Il est bien sûr conseillable d’appliquer la norme même à un développement interne quitte à faire tomber les processus reliés à l’acquisition. Trop souvent le fait que le développement soit interne pousse les ingénieurs du logiciel et les gestionnaires à laisser flotter les rênes. Note 4 : la liste des tâches, contrairement à la liste des activités et des processus, n’est pas exhaustive. Ce qui donne de degrés de liberté supplémentaires : non seulement les activités ne sont pas ordonnées mais leurs « parties » (leur constituant) peuvent être augmentées. Note 5 : un processus d’adaptation (tailoring) est prévu dans l’Annexe A pour enlever les processus, les activités et les tâches qui ne sont pas jugées nécessaires dans le cadre du projet. Pour chaque élément enlevé il faut donner une justification (rational) écrite. L’ensemble des intervenants dans le CVL est divisé en cinq groupes et chaque groupe est responsable d’un processus dit « primaire ». Les groupes (ou organisations) peuvent appartenir à la même compagnie. Par exemple un département de développement de Bell peut développer du logiciel pour lui-même, pour un autre département ou pour une autre compagnie. Voici les cinq organisations primaires prévues :
La norme organise les processus en trois catégories : 1. Processus primaires du CVL : il s’agit des processus associés aux cinq groupes d’intervenants que nous venons de lister. 2. Processus auxiliaires (ou de support) du CVL : il s’agit des processus de soutient des processus primaires. Un processus auxiliaire est exécuté par un processus primaire quand celui-ci en a besoin. 3. Processus organisationnels du CVL : Il s’agit des processus organisationnels qui veillent à ce que dans l’entreprise le personnel, les normes et les processus s’intègrent de manière efficace pour fournir des services de qualité. La figure suivante présente tous les processus prévus par la norme.
Dans la figure suivante, pour améliorer la lecture des activité du processus de développement (celui qui nous intéresse le plus dans ce cours-ci), nous avons introduit de nouveaux types de processus primaires : DéveloppementSystème (activités qui concernent le tout : matériel, logiciel, humains, procédures,,,) et DéveloppementLogiciel (activités qui ne concernent que le logiciel).
Les deux figures suivantes présentent les activités du processus de développement concernées par le système comme un tout et par le logiciel
Nous n’analyserons pas dans ce cours la partie développement système lorsque le système a des composants matériels importants à développer. Note Une application a toujours besoin de matériel ! Mais très souvent on n’a pas besoin de développer du nouveau matériel : on achète des ordinateurs existants sur le marché qui sont livrés avec les options dont on a besoin. Ce qui ne veut pas dire qu’il soit facile de choisir les options ! Fin de la note La figure précédente présente les activités suivantes : ·
MEO du processus. Mise en œuvre du
processus. (voir la description dans · Analyse des ES. Analyse des exigences du système (indépendamment de la mise en œuvre par matériel ou logiciel). · Conception de l’AS. Conception de l’architecture système. C’est-à-dire définir la structure dans laquelle sont agencés les sous-systèmes. · Intégration système. Intégration des différents sous-systèmes (matériels et/ou logiciels). Exemple : intégrer des applications dans des ordinateurs ayant des composants matériels spéciaux et reliés par un réseau local). · Test de qualification système. Valider que le système fait ce qu’il est censé faire : c’est-è-dire qu’il satisfait les exigences.
Les trois
diagrammes UML précédents sont des diagrammes qui montrent la structure des
relations conceptuelles de Note Il faudra toujours avoir l’esprit la différence entre des modèles statiques ou architecturaux (ils ne sont pas concernés par le temps qui passe) et les modèles dynamiques (le temps étant la variable indépendante la plus importante). Fin de la note 2.1 Processus de développement Parmi ces processus dans notre cours nous sommes intéressés surtout par le processus de développement. Le processus de développement est constitué des treize (13) activités suivantes : 1. Mise en œuvre du processus. C’est ici que l’on choisit le type de CVL à adopter (et adapter) pour le projet. Il y a plusieurs manières d’agencer les activités choisies. Ces agencements sont déterminés par les réponses que l’on donne à des questions du genre (on verra le détail dans un autre cours) : § Les activités s’agencent-elles selon un ordre préétabli ? § Avant de commencer l’activité n+1 faut-il terminer l’activité n ? § L’application (la machine, le système) à produire peut-elle être livrée de manière incrémentielle (composant 1, ensuite 1 et 2, ensuite 1,2 et 3, etc.) ? 2. Analyse des exigences du système. Fonctions, caractéristiques de qualité, etc. Le Conops est généré lors de cette activité. 3. Conception de l’architecture du système. Trouver et décrire les « piliers » de l’édifice (indépendamment du fait qu’il s’agisse de matériel, de logiciel ou de personnes) qui devra permettre de répondre aux besoins des utilisateurs. « Piliers » qui dépendent des points de vues des intervenants, du fait que l’on considère le système du point de vue logique ou physique. Dans le module 4.2 nous verrons un modèle conceptuel pour l’architecture 4. Analyse des exigences du logiciel. C’est ici, en théorie, que nous (ingénieurs du logiciel) devrions être le plus à l’aise. Parmi les exigences qui concernent le tout (le système) il faut choisir et détailler celles concernant le logiciel. Notre cours adresse surtout cette partie 5. Conception de l’architecture du logiciel. Il s’agit de donner la structure pour chaque élément du logiciel : on passe des exigences à comment on organise à haut niveau le logiciel. Cette activité est couverte par le cours INF 5153. 6. Conception détaillée du logiciel. Il s’agit de décrire en détail tous les composants. Par exemple : le paramètres de toutes les méthodes, leurs antécédents et conséquents, leur but, etc. Cette activité est couverte par le cours INF 5153. 7. Codage et essais du logiciel. Rien à dire ici : vous êtes des experts 8. Intégration du logiciel. Il s’agit d’intégrer les différentes unités qui ont été codées et testées dams l’activité précédente. Pour employer une association spéciale de UML on peut dire que l’on doit créer et tester un agrégat dont les parties sont les unités. On aura bien sûr aussi des agrégats d’agrégat… 9. Essais de qualification du logiciel. Il s’agit de s’assurer que les éléments logiciels satisfont les exigences et sont prêts à être intégrés dans le système. Cette activité peut être employée dans les processus auxiliaires de Validation et de Vérification. Cette activité est couverte par le cours INF 6160 10. Intégration du système. Les éléments logiciels sont intégrés avec les éléments matériels dans les procédures de travail prévues par les spécifications du système. 11. Essais de qualification du système. Ce sont les essais qui assurent que le système dans son ensemble satisfait les besoins des différents intervenants. 12. Installation du logiciel. Il s’agit d’installer le logiciel dans l’environnement cible (auparavant on était dans un environnement de test). 13. Support pour l’acceptation du logiciel. Il s’agit de faire de revues conjointes avec le client, de le former et de l’aider (l’étendue de cette activité dépend de clauses du contrat). 2.2 Processus auxiliaires Très peu de mots sur ces processus malgré leur importance car ils sont traités dans d’autres cours (INF 6150 et INF6160). En particulier nous ne considérerons que la vérification, la validation et L’assurance de la qualité. Vérification « Le processus de vérification est un processus qui permet de déterminer si les produits logiciels d’une activité satisfont les exigences ou les conditions que les activités précédents leurs imposent. » On parle de produits logiciels d’une activité donc non seulement le code, mais tout artefact généré dans un projet ; ce qui ne veut pas dire qu’on vérifie de la même manière une spécification des exigences ou un compte rendu de réunion ! « Pour diminuer les coût et améliorer les performances, la vérification doit être intégrée le plus tôt possible avec le processus qui l’emploie (par exemple fourniture, développement, opération ou maintenance). » Étant donné que la vérification est un processus auxiliaire (ou de support) il faut un processus qui l’emploie. Exemple : après avoir terminé une activité de conception on fait appel au processus de vérification pour évaluer la qualité de ce qu’on vient de concevoir. Critères pour la vérification des exigences : « i. Les exigences système sont cohérentes, faisables et testables. ii. Les exigences système ont été allouées à des éléments matériels, logiciels ou à des humains selon les critères de conception (système). Note : j’ai ajouté « système » car c’est la seule manière de rendre compréhensible la phrase. iii. Les exigences logicielles sont cohérentes, faisables et testables et reflètent exactement les exigences système. iv. Les exigences logicielles concernant la sûreté, la sécurité et la criticité sont décrites avec des méthodes rigoureuses et convenables. » Une manière concise de définir la vérification : S’assurer que l’on réalise bien le produit. Validation « Le processus de validation est un processus qui permet de déterminer si les exigences et le système ou le produit logiciel finaux satisfont un emploi spécifique visé. » Dit d’une autre manière : le produit et les exigences doivent satisfaire les besoins (explicites et implicites) des utilisateurs. Valider le produit final par rapport aux exigences écrites ne suffit pas, contrairement à ce que pensent les dogmatiques des exigences. « La validation peut être faite aux premiers stades. » Où on ne peut certainement pas évaluer le produit final et donc on ne peut qu’évaluer les exigences. Une manière concise de définir la validation : S’assurer que l’on réalise le bon produit. Assurance de la qualité Il s’agit d’assurer tous les intervenants que la qualité des artefacts est conforme aux exigences de qualité pour le produit et que la qualité des processus est conforme aux exigences des l’entreprise. Voici deux diagrammes UML qui nous permettent de voir graphiquement certains éléments de la qualité tout en nous permettant d’améliorer nos connaissances de UML.
|
|
Conséquents :
· Avoir une bonne idée de la norme ISO 12207 · Avoir une première idée de UML |
|
Note 01 : ce module renvoie vers le module 4.1 (logiquement imbriqué) |
