Vous êtes sur la page 1sur 29

Réf.

: H3278 V2

Apport
Date de publication :
10 août 2017
de la norme ISO/IEC 12207
(2008) pour l’utilisation d’UML

Cet article est issu de : Technologies de l'information | Technologies logicielles


Architectures des systèmes

par Marie Christine LAFAYE, Annick LASSUS

Mots-clés Résumé Cet article traite de la norme de qualité ISO/CEI 12207 : 2008 (E) IEEE Std
UML | développement logiciel | 12207™ intitulée «Ingénierie des systèmes et du logiciel - Processus du cycle de vie du
RUP | Approche Agile SBOK
pour Scrum | UML en mode logiciel». Il est montré comment cette norme applique les principes de base de
esquisse l’assurance qualité. Puis la norme est comparée avec deux cadres de référence de
production du logiciel: RUP et l’approche Agile décrite par SBOK™ pour la mise en
œuvre de Scrum. La mise en œuvre de cette norme est détaillée à travers l'utilisation du
langage de modélisation UML et son impact sur les caractéristiques des modèles de
produit UML associés est étudiée. Un exemple d’illustration est fourni.

Keywords Abstract This article presents the second edition of the quality standard ISO/IEC 12207:
UML | Software development | 2008 (E) IEEE Std 12207™:‘Systems and software engineering - software life cycle
RUP | Agile process SBOK for
Scrum | UML as sketch processes’. It shows how this standard implements the basic principles of quality
assurance. It compares this ISO standard with two usual software production frameworks,
namely RUP and the Agile approach described in SBOK™ for implementing Scrum. It
then explains how this standard can be put into practice via UML language. Its impact on
the features and use of the related UML product models is detailed. An illustrative
example is provided.

Pour toute question :


Service Relation clientèle
Techniques de l’Ingénieur
Immeuble Pleyad 1 Document téléchargé le : 06/11/2019
39, boulevard Ornano
93288 Saint-Denis Cedex Pour le compte : 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Par mail :
infos.clients@teching.com
Par téléphone :
00 33 (0)1 53 35 20 20 © Techniques de l'Ingénieur | tous droits réservés
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Apport de la norme ISO/IEC 12207


(2008) pour l’utilisation d’UML
par Marie Christine LAFAYE
Maı̂tre de conférences honoraire
Université de La Rochelle, France

et Annick LASSUS
Professeur Agrégé
IUT, Université de La Rochelle, France
Note de l’éditeur : Cet article est la version actualisée de l’article intitulé « Apport
d’une norme de qualité dans la conduite d’un projet logiciel basé sur UML », écrit par
Marie Christine LAFAYE et publié par nos éditions en 2009.

1. Norme ISO/IEC 12207 version 2008 ............................................ H 3 278v2 – 2


1.1 Processus spécifiques au logiciel ...................................................... — 4
1.2 Prise en compte des principes d’assurance qualité .......................... — 5
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

1.2.1 Prise en charge du principe de définition du mode de travail


(PLAN) ...................................................................................... — 5
1.2.2 Prise en charge du principe de contrôle (CHECK) .................. — 5
1.2.3 Prise en charge du principe d’amélioration continue (ACT) .. — 7
2. Indépendance de la norme vis-à-vis des modèles de cycle
de vie ................................................................................................. — 7
2.1 Application de la norme avec RUP .................................................... — 7
2.2 Application de la norme avec l’approche Agile SBOK™
pour Scrum ......................................................................................... — 7
2.3 Bilan .................................................................................................... — 9
3. Langage UML et norme ISO/IEC 12207....................................... — 10
3.1 Les différents types de diagrammes ................................................. — 11
3.2 Modèles de produit associés à un diagramme de paquetages
(D_Packages) ...................................................................................... — 13
3.3 Modèles de produit associés à un diagramme de séquence
(D_Seq) ............................................................................................... — 13
3.4 Modèles de produit associés à un diagramme de classes (D_CL) ... — 14
3.5 Modèles de produit associés à un diagramme d’activités (D_Act) .. — 19
3.6 Modèles de produit associés à un diagramme états-transitions (DET) — 19
4. Conclusion........................................................................................ — 19
5. Annexe : Exemple d’illustration du cas gestion de projet ...... — 20
Pour en savoir plus.................................................................................. Doc. H 3 278v2

P our représenter les systèmes d’information, plusieurs types de modèles (ou


modèles de produit) sont élaborés. La complexité d’un système d’informa-
tion est telle qu’il est nécessaire de combiner plusieurs points de vue avec
différents niveaux d’abstraction. On distingue classiquement les points de vue
fonctionnel, dynamique et ontologique et les niveaux conceptuel, organisation-
nel, logique et physique. Nous nous intéressons au cas où le projet logiciel à
conduire est intégré dans un système d’information particulier.
Les normes de la famille ISO 9000 : 2000, dont la dernière révision date d’octo-
bre 2015, sont la référence internationale en assurance qualité. Pour faciliter leur
application, des normes outils sont proposées, telle la norme ISO/IEC 12207,
elle-même révisée en 2008. Nous montrons comment cette norme applique

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 1

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

les principes de base de l’assurance qualité. Cette norme préconise une


approche processus. Un « processus » y est défini comme un « ensemble d’acti-
vités corrélées ou interactives qui transforment des éléments d’entrée
en éléments de sortie ». Les éléments de sortie sont dans la plupart des cas
des modèles de produit. Pour décrire les différents modèles de produit, nous
disposons depuis plusieurs années du langage de modélisation UML (Unified
Modeling Language).
La mise en œuvre avec le langage UML est généralement associée au modèle
de processus RUP (Rational Unified Process). L’usage des méthodologies
« Agiles », apparues depuis le début des années 1990, s’est répandu au sein
des entreprises de services numériques. Ces méthodologies sont, quant à
elles, indépendantes d’UML, ce qui ne veut pas dire qu’on s’y interdit l’usage
d’outils de modélisation. Parmi elles, nous avons choisi de présenter Scrum et
plus particulièrement sa déclinaison processus : le guide de connaissance
SBOK™ (Scrum Body of Knowledge). RUP et SBOK™ sont des processus géné-
riques, c’est-à-dire qu’ils proposent une trame commune à adapter en fonction
du projet traité. Nous montrons que chacun d’eux correspond à une mise en
œuvre particulière de la norme ISO/IEC 12207.
Dans la version 2.5, UML propose 14 types de diagrammes différents. Cette
richesse de représentation a pour corollaire une difficulté de mise en œuvre :
quel diagramme choisir ? Comment utiliser les différents éléments de modéli-
sation associés en fonction du point de vue et du niveau d’abstraction ? Quel
objectif poursuit-on en utilisant UML : mode « esquisse » pour communiquer
certains aspects du système, ou mode « plan » qui permet de préparer la géné-
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

ration du code ? Quoi qu’il en soit, le but de cet effort de modélisation est
d’améliorer la qualité du logiciel produit en améliorant la qualité de son mode
de production.
Dans cet article, nous privilégions l’étude des types de modèles de produit
élaborés avec UML pouvant être construits pour chaque activité des processus
d‘implantation de logiciel : analyse des exigences, conception de l’architecture,
conception détaillée et pour les processus d’ingénierie du domaine et de
conception de l’architecture système. Nous fournissons en annexe des exem-
ples de diagrammes UML correspondant à ces modèles de produit et illustrant
comment mettre en œuvre une approche Agile avec l’AGL (Atelier de Génie
Logiciel) UML Modelio.

Certains processus sont eux-mêmes décomposés en processus.


1. Norme ISO/IEC 12207 La norme est présentée comme une collection d’articles numéro-
version 2008 tés. Un article numéroté 6.a (respectivement 7.a) correspond à un
ensemble de processus de type système (respectivement spéci-
fique au logiciel). La numérotation 6.a.b (respectivement 7.a.b) est
attribuée à un processus système (respectivement spécifique au
La norme ISO/IEC 12207, dont la première version date de logiciel).
1995 [1] propose un cadre de référence qui distingue plusieurs Un processus est un ensemble d’activités corrélées ou inter-
processus regroupés par type en distinguant ceux qui relèvent du agissantes qui transforme des entrées en sorties et dont le res-
contexte système et ceux spécifiques au logiciel [H 4 028]. Cette ponsable est identifiable. Chacun des processus est décrit par un
norme part du principe qu’un logiciel n’existe que comme partie titre, une finalité explicitant les objectifs d’exécution du processus
d’un système même si ce dernier ne comporte que le processeur (purpose, numérotation : 6.a.b.1 ou 7.a.b.1), un bilan des résultats
sur lequel il est exploité. Elle a été rédigée à l’attention des acqué- observables (outcomes, numérotation : 6.a.b.2 ou 7.a.b.2). Chaque
reurs de systèmes, de logiciels et de prestations logicielles ainsi processus est décomposé en activités (numérotation : 6.a.b.3.c ou
que pour les fournisseurs, les développeurs, les personnes 7.a.b.3.c), les activités sont elles-mêmes décomposées en tâches
chargées de l’exploitation et de la maintenance. (numérotation : 6.a.b.3.c.d pour les tâches de l’activité 6.a.b.3.c
Note : les textes en italique sont des citations littérales de la norme. ou 7.a.b.3.c.d pour celles de l’activité 7.a.b.3.c). Une tâche est soit

H 3 278v2 – 2 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

une exigence (verbe : shall ou doit), soit une recommandation Dans cet article, nous avons pour objectif de montrer comment
(verbe : should ou devrait), soit une possibilité (verbe : may ou cette norme aide à utiliser le langage UML dont le champ d’action
pourrait). est le logiciel, aussi nous ne détaillons que les processus spécifi-
Un panorama des processus considérés par la norme est fourni ques au logiciel. Le langage BPMN (Business Process Model and
dans le tableau 1. Notation) et le référentiel TOGAF‚ (The Open Group Architecture
Framework) pour l’architecture d’entreprise sont adaptés, quant à
La version de 1995 ne distinguait pas aussi clairement ce qui eux, aux processus du contexte système suivants :
relève du système et ce qui est spécifique au logiciel. La gestion de
projet était trop peu détaillée. Les ajouts faits dans la version de – processus contractuel d’acquisition (6.1.1) ;
2008 sont conformes aux propositions de la norme ISO/IEC 15288 – processus techniques :
sur le cycle de vie des systèmes.  de définition des exigences des parties prenantes (6.4.1) ;

Tableau 1 – Norme ISO/IEC 12207 (version 2008) : Vue générale des processus
Processus pour le SYSTÈME Processus pour le LOGICIEL

Processus de gestion de Processus d’implantation Processus de support du


Processus contractuels Processus techniques
projet du logiciel logiciel
(6.1) (6.4)
(6.3) (7.1) (7.2)

Processus d’Acquisition
Processus de définition Processus de management Processus de gestion de la
(6.1.1) Processus de planification
des exigences des parties d’implantation du logiciel documentation du logiciel
Processus de Fourniture de projet (6.3.1)
prenantes (6.4.1) (7.1.1) (7.2.1)
(6.1.2)
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Processus organisationnels Processus de contrôle et Processus de gestion de


Processus d’analyse des Processus d’analyse des
de mise en œuvre d’un d’évaluation de projet configuration du logiciel
exigences système (6.4.2) exigences du logiciel (7.1.2)
projet (6.2) (6.3.2) (7.2.2)

Processus de management Processus de management Processus de conception Processus de conception


Processus d’assurance
du modèle de cycle de vie de la prise de décision de l’architecture système de l’architecture du logiciel
qualité du logiciel (7.2.3)
(6.2.1) (6.3.3) (6.4.3) (7.1.3)

Processus de management Processus de management Processus Processus de conception Processus de vérification


de l’infrastructure (6.2.2) des risques (6.3.4) d’implémentation (6.4.4) détaillée du logiciel (7.1.4) du logiciel (7.2.4)

Processus de management
Processus de gestion de Processus d’intégration Processus de construction Processus de validation du
du portefeuille de projets
configuration (6.3.5) système (6.4.5) du logiciel (7.1.5) logiciel (7.2.5)
(6.2.3)

Processus de management Processus de tests de


Processus de gestion de Processus d’intégration du Processus de revue
des ressources humaines qualification du système
l’information (6.3.6) logiciel (7.1.6) conjointe du logiciel (7.2.6)
(6.2.4) (6.4.6)

Processus de test de
Processus d’assurance Processus de mesure Processus d’installation du Processus d’audit du
qualification du logiciel
qualité (6.2.5) (6.3.7) logiciel (6.4.7) logiciel (7.2.7)
(7.1.7)

Processus d’assistance à
Processus de résolution de
l’acceptation du logiciel
problème (7.2.8)
(6.4.8)

Processus d’exploitation
Processus de réutilisation du logiciel (7.3)
du logiciel (6.4.9)

Processus de maintenance Processus d’ingénierie du


du logiciel (6.4.10) domaine (7.3.1) Processus de management
du programme de
réutilisation (7.3.3)
Processus de retrait du Processus de management
logiciel (6.4.11) des actifs réutilisés (7.3.2)

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 3

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

 d’analyse des exigences système (6.4.2) ; de tâches. Certains processus ne comportent qu’une seule activité.
 de conception de l’architecture système (6.4.3). Les rédacteurs de la version 2008 ont transformé des activités de la
version précédente de 1995 en processus car elles en avaient les
Nous montrons ensuite comment la norme met en œuvre les propriétés.
principes de l’assurance qualité.
Les différents processus d’implantation du logiciel concernent le
logiciel à produire qu’il soit un ensemble de programmes et de pro-
1.1 Processus spécifiques au logiciel cédures, avec si nécessaire la documentation et les données asso-
ciées (software product), ou bien la mise en œuvre d’un produit
Cette norme distingue les processus d’implantation du logiciel (service). On y distingue trois niveaux d’étude :
(7.1), les processus de support du logiciel (7.2) et les processus de
réutilisation du logiciel (7.3), ces derniers étant introduits dans la  compréhension du problème ou analyse des exigences (§ 7.1.2
version 2008. Le tableau 2 décrit, pour chaque type, les processus de la norme) ;
spécifiques au logiciel qu’ils contiennent et permet d’en appréhen-  élaboration de la solution en distinguant la conception de
der la complexité en indiquant pour chacun le nombre d’activités et l’architecture (§ 7.1.3 de la norme) qui permet de définir pour

Tableau 2 – Norme ISO/CEI12207 (version 2008) : Complexité des processus spécifiques au LOGICIEL
Numéro Nombre Nombre de
Type Processus
norme d’activités tâches

Processus de management d’implantation du logiciel 7.1.1 1 5

Processus d’analyse des exigences du logiciel 7.1.2 1 3


Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Processus de conception de l’architecture du logiciel 7.1.3 1 7


Processus d’implantation
du logiciel (7.1)
7 processus, Processus de conception détaillée du logiciel 7.1.4 1 8
7 activités
40 tâches
Processus de construction du logiciel 7.1.5 1 6

Processus d’intégration du logiciel 7.1.6 1 6

Processus de test de qualification du logiciel 7.1.7 1 5

Processus de gestion de la documentation du logiciel 7.2.1 4 7

Processus de gestion de configuration du logiciel 7.2.2 6 6

Processus d’assurance qualité du logiciel 7.2.3 4 16

Processus de support du
logiciel (7.2) Processus de vérification du logiciel 7.2.4 2 11
8 processus,
25 activités Processus de validation du logiciel 7.2.5 2 10
68 tâches

Processus de revue conjointe du logiciel 7.2.6 3 8

Processus d’audit du logiciel 7.2.7 2 8

Processus de résolution de problème 7.2.8 2 2

Processus d’ingénierie du domaine 7.3.1 5 23


Processus de réutilisation
du logiciel (7.3)
3 processus Processus de management des actifs réutilisés 7.3.2 3 15
14 activités
62 tâches
Processus de management du programme de réutilisation 7.3.3 6 24

H 3 278v2 – 4 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

chaque exigence requise les composants à produire soit de intégrante de la norme bien qu’il soit décrit dans l’annexe A de la
type logiciel (software unit), soit de type paramétrage (confi- norme. Pour effectuer cet ajustement, il est nécessaire de considé-
guration item) ; rer les caractéristiques du projet telles que le coût, le délai, le
 conception détaillée (§ 7.1.4 de la norme) qui décrit chacun des contexte juridique, les exigences en termes de sûreté et de sécurité.
éléments ainsi définis. Cette norme n’impose pas de modèle de cycle de vie mais propose
un processus dédié à son choix : Processus de management du
La construction proprement dite (processus 7.1.5) comprend le modèle de cycle de vie (6.2.1).
codage, la documentation et les tests sans omettre ceux des
données. La granularité de mise en œuvre du processus 7.1.5 qui D’autres choix sont à effectuer. Dans le processus de manage-
concerne un composant logiciel ou une unité de configuration ment de l’implantation du Logiciel (7.1.1), l’activité 7.1.1.3.1 Stratégie
implique une phase d’intégration prise en charge par le proces- d’implantation du logiciel comprend notamment les tâches
sus 7.1.6. Enfin le processus de test de qualification (7.1.7) permet suivantes :
de vérifier que l’intégration précédemment réalisée satisfait aux
7.1.1.3.1.1 Si ce n’est pas stipulé au contrat, le développeur doit
exigences.
définir et sélectionner un modèle de cycle de vie logiciel approprié
Le processus de gestion de la documentation (7.2.1) est mis en au domaine d’application, à l’ampleur et à la complexité du projet.
œuvre par tous les autres processus. Quelles que soient les Les activités et les tâches de ce processus de développement doi-
précautions prises au lancement d’un projet, la demande du vent être sélectionnées et mises en correspondance avec le modèle
client se précise et évolue au cours du cycle de vie du logiciel. de cycle de vie.
Il faut donc aussi définir le processus de gestion des change-
Note : ces activités et ces tâches peuvent se recouvrir ou agir l’une sur l’autre, et peu-
ments, c’est ce que permet de faire le processus 7.2.2 de gestion vent être mises en œuvre de manière itérative ou récursive
de configuration. Le processus 7.2.8 de résolution de problème
permet de faire face à toutes les situations non prévues : l’objec- 7.1.1.3.1.3 Le développeur doit choisir, ajuster, et utiliser des
tif est de fournir un moyen pertinent et documenté qui permet normes, des méthodes, des outils et des langages de program-
de garantir que tous les problèmes identifiés sont analysés et mation (si ce n’est pas spécifié au contrat) qui sont documentés,
résolus. Les autres processus supports sont dédiés à l’assurance appropriés et établis par l’organisme pour exécuter les activités
qualité. du processus d’implantation du logiciel et des processus
support.
La version de 2008 de la norme introduit des processus favori-
sant la réutilisation d’éléments logiciels (software item : code La plupart des processus comportent une activité permettant de
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

source, code objet, code de test, contrôle des données ou préciser le mode de mise en œuvre choisi pour ce processus. Cette
collection d’éléments de ce type) communs à plusieurs projets. activité est intitulée soit implantation du processus, soit plan de
Le processus de gestion du domaine (7.3.1) a pour objectif de gestion, soit stratégie.
développer et de maintenir les modèles de domaine, les architec-
tures de domaine et les actifs logiciels associés (spécification,
code, et documentation). Le processus de gestion des actifs
1.2.2 Prise en charge du principe de contrôle
logiciels réutilisés (7.3.2) prend en charge, de la conception (CHECK)
au retrait, leur cycle de vie. Enfin, le processus de gestion du
Le contrôle est effectué à plusieurs niveaux : processus, activité
programme de réutilisation (7.3.3) recherche toutes les opportu-
et tâche. Certains processus lui sont dédiés ainsi les processus de
nités de réutilisation, planifie leur mise en œuvre, les gère et les
test de qualification système (6.4.6), celui du logiciel (7.1.7) et,
contrôle.
parmi les processus de support du logiciel, le processus de vérifica-
tion du logiciel (7.2.4) et le processus de validation du logiciel
1.2 Prise en compte des principes (7.2.5). Les autres processus de support du logiciel, processus de
revue conjointe (7.2.6) et processus d’audit (7.2.7), décrivent le
d’assurance qualité mode de mise en œuvre possible des processus 7.2.4 et 7.2.5. Un
L’assurance qualité préconise de se placer systématiquement audit est toujours réalisé par des personnes qui ne sont pas direc-
dans une approche contractuelle « client – fournisseur » même tement responsables des logiciels ou des activités qu’elles
dans le cas d’une étude interne. Cette norme applique ce principe auditent.
par la mise en œuvre des processus contractuels d’acquisition Tous les autres processus techniques du contexte Système com-
(6.1.1), et de fourniture (6.1.2). De plus, un processus lui est dédié portent à la fois des activités (ou des tâches) de production et
à la fois dans le contexte système (6.2.5) lequel vise à garantir que d’autres de contrôle garantissant la traçabilité et la cohérence avec
les produits, les services et la mise en œuvre des processus sont les activités amont et une évaluation de la faisabilité des activités
conformes aux objectifs de qualité de l’organisation concernée en aval. Par exemple pour le processus d’analyse des exigences
et permettent d’obtenir la satisfaction du client, et pour le logiciel système, la norme propose avec l’activité 6.4.2.3.1 d’établir les spé-
(7.2.3 de la norme). cifications des exigences. L’activité 6.4.2.3.2 d’évaluation des exi-
La norme permet aussi d’effectuer les différentes étapes classi- gences composée uniquement de la tâche 6.4.2.3.2.1 prend en
quement retenues dans une approche qualité (roue de Deming) : compte les critères suivants :
définition du mode de travail (PLAN), mise en œuvre du mode
a) traçabilité avec les besoins d’acquisition ;
de travail défini (DO), contrôle (CHECK) et prise en compte des
résultats dans un objectif d’amélioration continue (ACT). Dans b) cohérence avec les besoins d’acquisition ;
le tableau 3, les processus et leurs activités sont classés par rap-
c) testabilité ;
port à chacune de ces étapes. L’étape d’amélioration (ACT) n’y
est pas traitée et pour le logiciel, nous avons uniquement consi- d) faisabilité de la conception de l’architecture du système ;
déré les processus d’implantation du logiciel (7.1).
e) faisabilité de l’exploitation et de la maintenance.

1.2.1 Prise en charge du principe de définition Cette structuration de la norme se retrouve dans les processus
du mode de travail (PLAN) d’implantation du logiciel et s’appuie sur les mêmes types de critè-
res. Bien que la structuration soit différente, les processus de réuti-
Les processus proposés doivent être ajustés pour chaque projet lisation du logiciel (processus d’ingénierie du domaine (7.3.1) et
logiciel. Cette adaptation consiste à choisir les processus, les activi- processus de management des actifs réutilisés (7.3.2)), comportent
tés ou les tâches. Le processus d’ajustement fait, lui aussi, partie des tâches de type CHECK.

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 5

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Tableau 3 – Norme ISO/CEI12207 (version 2008) : Mise en œuvre de l’approche qualité (extrait)
PLAN DO CHECK

SYSTÈME

6.4.1 Processus de définition des exigences des parties prenantes

activités 6.4.1.3.1, 6.4.1.3.2 activités 6.4.1.3.3, 6.4.1.3.4, 6.4.1.3.5

6.4.2 Processus d’analyse des exigences du Système

activité 6.4.2.3.1 activité 6.4.2.3.2

6.4.3 Processus de conception de l’architecture du Système

activité 6.4.3.3.1 activité 6.4.3.3.2

6.4.5 Processus d’intégration du Système

activité 6.4.5.3.1 activité 6.4.5.3.2

6.4.6 Processus de tests de


qualification du Système

6.4.7 Processus d’installation du Logiciel


Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

tâche 6.4.7.3.1.1 tâche 6.4.7.3.1.2 tâche 6.4.7.3.1.2

6.4.8 Processus d’assistance à l’acceptation du Logiciel

tâches 6.4.8.3.1.2, 6.4.8.3.1.3 tâche 6.4.8.3.1.1

6.4.9 Processus d’exploitation du Logiciel

activité 6.4.9.3.1 tâche 6.4.9.3.2.2 tâche 6.4.9.3.2.1

activités 6.4.9.3.3, 6.4.9.3.4, 6.4.9.3.5

6.4.10 Processus de maintenance du Logiciel

activité 6.4.10.3.1, tâche 6.4.10.3.5.2 activités 6.4.10.3.2, 6.4.10.3.3, 6.4.10.3.5 activité 6.4.10.3.4

6.4.11 Processus de retrait du Logiciel

tâche 6.4.11.3.1.1 tâche 6.4.11.3.1.2

LOGICIEL les processus d’implantation 7.1

7.1.1 Processus de management de 7.1.2 Processus d’analyse des exigences du Logiciel 7.1.7 Processus de test de
l’implantation du Logiciel qualification du Logiciel
Activité 7.1.1.3.1 7.1.3 Processus de conception de l’architecture du Logiciel
Stratégie d’implantation du Logiciel
Tâches 7.1.1.3.1.1 choix du modèle 7.1.4 Processus de conception détaillée du Logiciel
du cycle de vie si non prévu au
contrat, choix des activités et des 7.1.5 Processus de construction du Logiciel
tâches à réaliser, 7.1.1.3.1.3 choix et
définition des adaptations des 7.1.6 Processus d’Intégration du Logiciel
normes, des méthodes, outils, et
langages de programmation,
contraintes technologiques
à respecter

Commun au système et au logiciel

6.2.1 Processus de management du


modèle de cycle de vie, activité
6.2.1.3.1 mise en place du processus

H 3 278v2 – 6 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

1.2.3 Prise en charge du principe d’amélioration les travaux sur le cycle de vie en spirale de Boehm [2]). Les diffé-
continue (ACT) rents prototypes peuvent être développés en parallèle par plusieurs
équipes. Nous nous intéressons dans cet article à deux approches
L’amélioration continue (ACT) concerne à la fois le mode de tra- de ce type : RUP (Rational Unified Process) et Agile SBOK™ pour
vail et le résultat à produire. La norme prend en charge ces deux Scrum. À la différence de RUP, les approches Agiles sont indépen-
aspects : dantes d’UML. Toutes deux sont des processus génériques propo-
 par le processus de management du modèle de cycle de vie sant une séquence d’étapes en partie ordonnées permettant de
(6.2.1) avec les activités ou tâches : 6.2.1.3.1.1 pour définir le construire ou d’améliorer un système logiciel. Comme leurs
mécanisme à mettre en œuvre, 6.2.1.3.3 pour effectuer les auteurs eux-mêmes l’indiquent, ces processus fournissent une
contrôles nécessaires et en évaluer les résultats pour propo- trame commune qui doit être adaptée au projet considéré. Nous
ser des améliorations ; détaillons ci-après l’application de la norme avec les approches
 par le processus de management de la prise de décision itératives et incrémentales retenues en utilisant le mode de
(6.3.3) tâche 6.3.3.3.2.2 ; présentation de [6].
 par le processus de management des risques (6.3.4) tâches
6.3.4.3.1.5 et 6.3.4.3.6.1, l’une définissant le processus à met-
tre en œuvre et l’autre collectant les informations permettant 2.1 Application de la norme avec RUP
de définir les améliorations ;
 par le processus de mesure (6.3.7) tâche 6.3.7.3.3.2 qui doit La mise en œuvre avec le langage UML est très souvent associée
identifier et communiquer les améliorations potentielles à au processus RUP recensant les meilleures pratiques de développe-
effectuer ; ment orienté objet. Ce processus générique [3] propose un déve-
 pour le produit par le processus de maintenance du logi- loppement itératif et incrémental, centré sur l’architecture, piloté
ciel (6.4.10) avec l’activité 6.4.10.3.2 analyse de problème par les risques et les cas d’utilisation et il assure la gestion des exi-
ou de demande de modification, et par le processus de gences. Il est adapté à la prise en compte des changements conti-
management des programmes réutilisés (7.3.3), tâche nuels imposés aux systèmes d’information et donc aux projets de
7.3.3.3.3.4. construction de systèmes logiciels. Il recommande d’utiliser des
architectures à base de composants, de modéliser de façon gra-
phique le logiciel avec UML ([4] [5]) et en utilisant un AGL : RUP
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

dès 1998 et l’outil RMC (IBM Rational Method Composer) depuis


2. Indépendance de la norme le rachat en 2003 de la société Rational par IBM.
Ce processus (figure 1) comporte deux dimensions. L’axe hori-
vis-à-vis des modèles zontal, qui représente le temps, s’exprime en termes de phases et
de cycle de vie d’itérations. L’axe vertical détaille les différents types de tâches (dis-
ciplines) à mettre en œuvre pour chaque itération (modélisation
métier, besoins, analyse et conception, implémentation, tests,
déploiement). L’intensité de chaque type de tâche varie pour
Dès le début des années 1970, des modèles de processus de chaque type de phase.
développement du logiciel ont été identifiés et qualifiés de
modèles de cycle de vie. Un modèle de cycle de vie propose Par exemple la discipline Implémentation est principalement mise
non seulement les types de tâche à effectuer, mais aussi leur en œuvre à la phase de construction.
enchaı̂nement.
Le cycle de vie en cascade permet principalement d’identifier La figure 2 détaille la conformité du processus RUP à la version
les différentes phases de production du logiciel et met en 2008 de la norme ISO/IEC12207. Le processus RUP est pratiquement
œuvre un chaı̂nage avant pour le projet par validation de chaque conforme à la norme ISO/IEC12207 : plusieurs articles ont étudié en
phase avant le passage à la phase suivante. Ce modèle a pour détail cette conformité pour la version 1995 de la norme ([6] [7]).
inconvénient d’entraı̂ner de nombreux retours arrière, car il La version de 2008 a bien séparé les aspects SYSTÈME et LOGI-
arrive fréquemment que des corrections sur les phases précé- CIEL. Le champ d’application de RUP concerne le logiciel, aussi cer-
dentes soient nécessaires. Ce modèle reste néanmoins valable tains points de la version de 2008 ne sont pas pris en compte par
pour les projets de petite taille (avec une phase de codage ce processus.
réduite), dont les besoins sont parfaitement connus et stables,
et pour lesquels l’équipe projet maı̂trise les difficultés. La
norme ISO/IEC12207 permet d’appliquer ce modèle de cycle de 2.2 Application de la norme
vie. Il suffit d’effectuer les différentes activités qu’elle propose
dans l’ordre de numérotation de la norme. ™
avec l’approche Agile SBOK™
Le cycle en V concerne des projets de taille plus importante pour Scrum
car il permet de les fractionner et de réduire le délai de produc-
tion en décomposant la phase de validation en deux temps : Parmi les approches Agiles (XP, TDD, Kanban, Lean..), nous pré-
la spécification des tests de validation et d’intégration se fait en sentons uniquement la méthodologie Scrum ([8], [9]) et un guide
même temps que l’analyse et la conception. Leur exécution est de sa mise en œuvre SBOK™ [10]. Le choix de la méthodologie
réalisée après la phase de codage. L’activité 6.4.3.3.1 du proces- Scrum nécessite une implication forte du métier ainsi que la mise
sus de conception de l’architecture du système (6.4.3) permet en place d’une démarche itérative d’affinement du besoin et une
de fractionner le projet en identifiant notamment les différents construction évolutive de l’architecture.
éléments logiciels qui seront ensuite étudiés au cours de Le manifeste Agile prône d’accorder plus d’importance « aux per-
l’activité 7.1.2.3.1 du processus d’analyse des exigences du logi- sonnes et à leurs interactions (éléments de gauche) qu’aux proces-
ciel (7.1.2). sus et aux outils (éléments de droite) », mais cela ne veut pas dire
Pour garantir que le logiciel produit correspond aux attentes des qu’il ne donne pas d’importance aux processus, car il dit également
utilisateurs qui évoluent avec le temps et qu’il est difficile de cerner, « Bien que les éléments à droite aient de la valeur, nous en accor-
la construction finale du produit logiciel s’obtient par une suite de dons plus aux éléments de gauche ». Dans ce cadre, le guide
prototypes réalisant des évolutions incrémentales (voir à ce sujet SBOK™ fournit un référentiel de bonnes pratiques de mise en

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 7

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Phases

Principaux enchaînements Inception Élaboration Construction Transition


du processus

Modélisaton métier

Gestion des exigences

Analyse et conception

Implémentation

Tests

Déploiement

Principaux enchaînements
de soutien

Gestion de la configuration
et des changements
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Direction de projet
Environnement
itération(s) itér. itér. itér. itér. itér. itér. itér.
préliminaires(s) #1 #2 #n #n+1 #n+2 #m #m+1

Itérations

Figure 1 – RUP : Différentes étapes [3]

œuvre de Scrum. Il propose de définir des phases et des processus d’itération permettant la fourniture d’un produit partiellement utili-
(tableau 4). sable comme décrit dans la figure 3.
Le cadre global Scrum se caractérise par : Dans le domaine de l’agilité, l’usage de la modélisation se veut
pragmatique, participatif (on parlera de modélisation collaborative)
 une équipe avec 3 rôles définis (Scrum Master, Product
et non obligatoire ([11], [12]). Cet usage porte essentiellement sur
Owner, équipiers Scrum) ;
quatre points. Il doit permettre :
 des itérations (appelées Sprint) dont la durée, fixe pour tout le  la compréhension partagée du produit par l’équipe (lors de la
projet, est déterminée au début du projet ; phase initiale de construction de la vision et au début de cha-
 le travail à faire et les exigences à respecter (Product Backlog) cune des itérations) ;
décomposé en éléments (Product Backlog Items – PBI) com-  la traçabilité de la spécification d’une User Story dans une ité-
prenant les caractéristiques attendues du produit : des épo- ration : de la conversation entre le Product Owner et l’équipe
pées (Epics), fonctionnalités (Features) et/ou des histoires à sa traduction en critères d’acceptation définissant le niveau
utilisateurs (User Stories), la correction d’anomalies, des fini (done) de la User Story ;
demandes d’évolution et les éléments architecturaux (PBI  de maı̂triser au cours du temps la vision globale du produit
techniques) ; grâce à la documentation des éléments stabilisés du produit
 la définition du contenu d’une itération et de ses priorités (importance de maintenir le modèle métier du domaine et la spé-
(Backlog du Sprint) à partir du Product Backlog ; cification de la base de données correspondante par exemple) ;
 l’utilisation d’une approche pragmatique pour affiner et docu-  de soutenir l’amélioration du fonctionnement de l’équipe en
menter chaque histoire utilisateur (User Story) ; documentant les bonnes pratiques de codage à suivre et les
spécifications de codage de l’architecture à respecter.
 l’acceptation du changement suite aux retours utilisateur pour
faire évoluer la définition du produit ; Il est à noter que, dans le cadre SBOK™, l’usage de la modélisa-
tion UML est possible uniquement dans les phases d’Initialisation
 l’amélioration du fonctionnement de l’équipe en plus de celle
et de Planification Estimation.
du produit par la mise en place de rétrospective.
Le processus Scrum défini dans SBOK™ est partiellement
Scrum débute par l’élucidation d’une problématique métier conforme à la norme ISO/IEC 12207, il fournit globalement un
conduisant à l’élaboration d’une vision produit partagée par cadre favorisant la mise en œuvre d’une grande partie de la
l’équipe et les parties prenantes. Cette vision est concrétisée par le norme sans rendre obligatoire sa réalisation détaillée. Le niveau
Product Backlog priorisé qui sera lui-même découpé en Backlog de prise en charge sera un choix de l’équipe projet. La figure 4

H 3 278v2 – 8 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

Processus pour le SYSTÈME Processus pour le LOGICIEL

Processus de gestion Processus d’implantation Processus de support


Processus contractuels Processus techniques
de projet du logiciel du logiciel
(6.1) (6.4)
(6.3) (7.1) (7.2)

Processus d’Acquisition
Processus de définition Processus de gestion
(6.1.1) Processus Processus de management
des exigences de la documentation
de planification de projet d’implantation du logiciel
des parties prenantes du logiciel
Processus de Fourniture (6.3.1) (7.1.1)
(6.4.1) (7.2.1)
(6.1.2)

Processus organisationnels Processus de contrôle Processus d’analyse Processus d’analyse Processus de gestion
de mise en œuvre d’un projet et d’évaluation de projet des exigences système des exigences du logiciel de configuration du logiciel
(6.2) (6.3.2) (6.4.2) (7.1.2) (7.2.2)

Processus de management Processus de management Processus de conception Processus de conception Processus d’assurance
du modèle de cycle de vie de la prise de décision de l’architecture système de l’architecture du logiciel qualité du logiciel
(6.2.1) (6.3.3) (6.4.3) (7.1.3) (7.2.3)

Processus de management Processus de management Processus Processus de conception Processus de vérification


de l’infrastructure (6.2.2) des risques (6.3.4) d’implémentation (6.4.4) détaillée du logiciel (7.1.4) du logiciel (7.2.4)

Processus de management Processus de gestion Processus Processus de construction Processus de validation


du portefeuille de projets de configuration d’intégration système du logiciel du logiciel
(6.2.3) (6.3.5) (6.4.5) (7.1.5) (7.2.5)
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Processus de management Processus de gestion Processus de tests Processus d’intégration Processus de revue
des ressources humaines de l’information de qualification du système du logiciel conjointe du logiciel
(6.2.4) (6.3.6) (6.4.6) (7.1.6) (7.2.6)

Processus de test
Processus Processus Processus d’installation Processus
de qualification du logiciel
d’assurance qualité (6.2.5) de mesure (6.3.7) du logiciel (6.4.7) d’audit du logiciel (7.2.7)
(7.1.7)

Processus d’assitance Processus de résolution


Légende à l’acceptation du logiciel de problème
(6.4.8) (7.2.8)

Totalement pris en charge Processus d’exploitation Processus de réutilisation du logiciel


dans RUP du logiciel (6.4.9) (7.3)

Processus d’ingénierie
Partiellement pris en charge Processus de maintenance
du domaine Processus de management
dans RUP du logiciel (6.4.10)
(7.3.1) du programme
Non pris en charge Processus de management de réutilisation
Processus de retrait
par RUP qui est centré des actifs réutilisés (7.3.3)
du logiciel (6.4.11)
sur les produits logiciels (7.3.2)

Figure 2 – RUP : Mise en œuvre de la norme ISO/IEC12207

détaille la conformité du processus SBOK™ à la version 2008 de la maintenance et réutilisation du logiciel ne sont pas présentées
norme ISO/IEC 12207. dans le processus.
Les processus de planification de projet et de contrôle de
projet sont globalement pris en charge dans la partie processus
pour le système [13]. Le cadre Scrum d’une itération (gestion du
Backlog, spécification des User Stories et contrôle de validité
2.3 Bilan
lors des revues de sprint) favorisent la mise en œuvre de (7.1.5)
(7.1.6) (7.1.7) et (7.2.4) (7.2.5) (7.2.6) dans le processus pour le La mise en œuvre de la norme ISO/IEC 12207 pour un projet
logiciel. donné consiste à :

Cependant il est à noter que tous les aspects conception et mise – identifier le(les) processus concerné(s) parmi les processus
en œuvre de l’architecture du logiciel ne sont pas présentés contractuels, les processus techniques, les processus d’implanta-
comme processus à part entière dans SBOK™. L’architecture, tion du logiciel, les processus support du logiciel et les processus
présentée comme émergente du travail de l’équipe auto-organisée de réutilisation. Les processus organisationnels de mise en œuvre
dans le cadre du projet, est intégrée à la détermination du terminé d’un projet et les processus de gestion de projet sont, quant à eux,
(done) des stories et complétée par la mise en place d’un guide de obligatoires ;
bonnes pratiques (Scrum Guidance Body Expertise) et supervisée – choisir, parmi les activités et les tâches des processus concer-
par la présence d’un rôle de type leader technique. Les parties nés, celles qui seront effectuées et l’ordre dans lequel elles seront

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 9

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

mises en œuvre (cycle de vie, ou processus générique choisi). Il est


™ : Processus Scrum définis
Tableau 4 – SBOK™ possible de mettre en œuvre avec cette norme les modèles de cycle
de vie en cascade, en V ainsi que le processus RUP et l’approche
Phase Processus Agile SBOK™ pour Scrum ;

Création de la vision projet – choisir les outils de modélisation et les modèles de produit cor-
Identification du « Scrum Master » respondants aux tâches effectuées. C’est à cette étape que nous
et des parties prenantes choisissons d’utiliser UML.
Formation de l’équipe Scrum
Développement des épopées
Initialisation (I)
(Epics)
Création du catalogue priorisé
du produit (Product Backlog)
Mise en place de la planification 3. Langage UML et
(Road Map Product) des versions (Releases)
norme ISO/IEC 12207
Création des histoires utilisateurs
(User Stories)
Approbation, estimation
Planification et et validation des User Stories UML est le langage de modélisation utilisé en ingénierie logi-
Estimation (PE) Création des tâches cielle. C’est le standard de fait proposé par l’OMG (Object Mana-
Estimation des tâches gement Group), la version 1.1 a été publiée en novembre 1997, la
Création du catalogue priorisé version 2 en 2003. La dernière version (2.5) a été publiée en mars
de l’itération (Sprint Backlog) 2015. Cette notation graphique peut être utilisée en mode
« esquisse » pour comprendre, décrire, spécifier et documenter
Création des livrables des systèmes, et /ou des logiciels. Il est aussi possible de l’utili-
Gestion des réunions journalières
Mise en œuvre ser en mode « plan » pour générer du code, soit directement,
(Daily Standup)
(Imp) soit en utilisant les techniques de transformation de modèles.
Gestion de la priorisation
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Dans ce dernier cas, il permet de mettre en œuvre une Ingénierie


du Backlog de Produit
Dirigée par les Modèles (IDM c’est-à-dire : Model-Driven Archi-
Gestion des projets tecture/MDA).
multi-équipes Scrum Nous supposons que le lecteur connaı̂t le langage UML ([4], [5]).
Revue et rétro- Démonstration et validation Nous rappelons les différents types de diagramme proposés ainsi
spective (R&R) du Sprint que leur rôle. Les différents diagrammes UML ne sont pas utilisa-
Réalisation de la rétrospective bles de façon similaire suivant l’objectif d’étude. UML est un
de Sprint
langage à adapter en fonction du contexte. Les ouvrages publiés
Gestion des Livrables sur ce langage ([4], [5], [14] et [15]) décrivent des modes d’utilisa-
Release tion de chaque type de diagramme. Nous appelons modèle de pro-
Réalisation de la rétrospective de projet
duit le résultat de cette adaptation.

Daily
Standup
Release Planning
Schedule

Create
Deliverables

Project Project Vision Prioritized Sprint Accepted


Business Case Statement Product Backlog Backlog Deliverables

Figure 3 – Scrum : déroulement pour une itération [10]

H 3 278v2 – 10 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

Processus pour le SYSTÈME Processus pour le LOGICIEL

Processus de gestion Processus d’implantation Processus de support


Processus contractuels Processus techniques
de projet du logiciel du logiciel
(6.1) (6.4)
(6.3) (7.1) (7.2)

Processus d’Acquisition
Processus de définition Processus de gestion
(6.1.1) Processus Processus de management
des exigences de la documentation
de planification de projet d’implantation du logiciel
des parties prenantes du logiciel
Processus de Fourniture (6.3.1) (7.1.1)
(6.4.1) (7.2.1)
(6.1.2)

Processus organisationnels Processus de contrôle Processus d’analyse Processus d’analyse Processus de gestion
de mise en œuvre d’un projet et d’évaluation de projet des exigences système des exigences du logiciel de configuration du logiciel
(6.2) (6.3.2) (6.4.2) (7.1.2) (7.2.2)

Processus de management Processus de management Processus de conception Processus de conception Processus d’assurance
du modèle de cycle de vie de la prise de décision de l’architecture système de l’architecture du logiciel qualité du logiciel
(6.2.1) (6.3.3) (6.4.3) (7.1.3) (7.2.3)

Processus de management Processus de management Processus Processus de conception Processus de vérification


de l’infrastructure (6.2.2) des risques (6.3.4) d’implémentation (6.4.4) détaillée du logiciel (7.1.4) du logiciel (7.2.4)

Processus de management Processus de gestion Processus Processus de construction Processus de validation


du portefeuille de projets de configuration d’intégration système du logiciel du logiciel
(6.2.3) (6.3.5) (6.4.5) (7.1.5) (7.2.5)
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Processus de management Processus de gestion Processus de tests Processus d’intégration Processus de revue
des ressources humaines de l’information de qualification du système du logiciel conjointe du logiciel
(6.2.4) (6.3.6) (6.4.6) (7.1.6) (7.2.6)

Processus de test
Processus Processus Processus d’installation Processus
de qualification du logiciel
d’assurance qualité (6.2.5) de mesure (6.3.7) du logiciel (6.4.7) d’audit du logiciel (7.2.7)
(7.1.7)

Processus d’assitance Processus de résolution


Légende à l’acceptation du logiciel de problème
(6.4.8) (7.2.8)

Globalement pris en charge Processus d’exploitation Processus de réutilisation du logiciel


dans SBOK™ du logiciel (6.4.9) (7.3)

Partiellement pris en charge


dans SBOK™ Processus de management
Processus de maintenance Processus d’ingénierie du programme
du logiciel (6.4.10) du domaine (7.3.1) de réutilisation
Non pris en charge (7.3.3)
par SBOK™

™ : Mise en œuvre de la norme ISO/IEC 12207


Figure 4 – SBOK™

La notation UML, bien que riche, ne peut satisfaire à tous 3.1 Les différents types de diagrammes
les besoins. Aussi un mécanisme d’extension a été fourni.
Il consiste à spécialiser un concept de base du langage par ajout
d’un stéréotype et de propriétés complémentaires (étiquettes ou Pour représenter un système logiciel, UML distingue plusieurs
‘tag values’). Un profil est un ensemble de stéréotypes. points de vue. Les modèles élaborés se complètent et peuvent
Pour chaque type de diagramme, avec, si nécessaire, les stéréoty- être assemblés.
pes et étiquettes ajoutés, nous présentons les modèles de produit
La vue fonctionnelle permet de décrire les fonctions que
que nous utilisons dans la mise en œuvre de la norme ISO/IEC 12207
le système doit remplir en se plaçant du point de vue de
(version 2008). Dans le tableau 5, nous indiquons les processus pour
lesquels nous utilisons une modélisation UML, et pour chacun nous l’utilisateur. Elle est représentée par le diagramme des cas d’utili-
précisons le modèle de produit adéquat. Notre expérimentation ne sation (D_Cas_Util) qui décrit les fonctionnalités du système et
concerne pas tous les diagrammes proposés par UML 2.5. leur utilisation par les acteurs (figure 5). Ce diagramme très syn-
thétique doit être complété par la description de chaque cas d’uti-
Les exemples de diagramme donnés en illustration dans l’an- lisation. Dans les premières étapes de l’étude où le modèle produit
nexe (figures 5 à 22) portent sur une étude de cas concernant la sert à communiquer avec la maı̂trise d’ouvrage, une description
gestion de projets, mise en œuvre en suivant une organisation de
textuelle s’impose. Elle peut être plus ou moins détaillée.
projet Agile.

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 11

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Tableau 5 – UML : Diagrammes appropriés à chaque étape des processus LOGICIEL les figures listées
dans le tableau sont celles de l’exemple d’illustration proposé en annexe

Étape de la norme Outil UML Figure

Processus d’ingénierie du domaine (7.3.1), tâche D_CL_Domaine + contraintes Fig. 7


7.3.1.3.2.3 DET_CL_Domaine Fig. 17 et Fig. 18

Processus de conception de l’architecture système


(6.4.3), activité 6.4.3.3.1 identification

• des éléments matériels, D_Déploiement Fig. 8


• des éléments logiciels D_Composants avec packages Fig. 9

Processus de management d’implantation du logiciel


D_Pack_Projet Fig. 5, et Fig. 11
(7.1.1),

Processus d’analyse des exigences du logiciel (7.1.2),


activité 7.1.2.3.1, tâche 7.1.2.3.1.1

D_Cas_Util, D_Seq_Système Fig. 6, Fig. 12


a) spécifications relatives aux fonctions D_CL_Signaux, D_CL_Part_CU Fig. 14, Fig. 15
D_Act_CU ou DET_CU Fig. 18 Maquettes IHM :

et aux capacités (performances), caractéristiques


physiques et conditions d’environnement dans fréquence EVT (cf D_CL_Signaux) Fig. 13
lesquelles l’élément logiciel fonctionnera
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

g) exigences pour la définition des données et pour la D_CL_Domaine Fig. 7


base de données + DET Classes Fig. 16, Fig. 17

Processus de conception de l’architecture du logiciel


(7.1.3), tâche 7.1.3.3.1.1

identification des composants logiciels, décrit la D_Pack_Comp, D_Composants Fig. 21, Fig. 9
structure haut niveau de l’architecture D_Seq_Architecture Fig. 10

tâche 7.1.3.3.1.2 conception de haut


D_Act_navig Fig. 19
niveau des interfaces internes et externes

D_CL_Persistantes
tâche 7.1.3.3.1.3 conception de haut
+ DET Classes Persistantes
niveau de la base de données
D_Act_Util

tâche 7.1.3.3.1.4 version préliminaire


D_Seq_test
manuel utilisateur

tâche 7.1.3.3.1.5 version préliminaire


préparation des tests

Processus de conception détaillée du logiciel (7.1.4)

D_Composants
tâche 7.1.4.3.1.1 décomposition de chaque composant
D_CL_Conception Fig. 21
logiciel en unités à coder, compiler et tester
DET_CL_Conception

DET_IHM
tâche 7.1.4.3.1.2 conception détaillée des interfaces Fig. 20
D_Seq_Algo

tâche 7.1.4.3.1.3 conception détaillée de la base de D_CL_ Impl (modèle graphique BD, profil pour
Fig. 22
données CWM™)

tâche 7.1.4.3.1.4 mise à jour des manuels utilisateurs si


D_Act_Util
nécessaire

tâche 7.1.4.3.1.5 préparation des tests D_Seq_Test

D_CL_Impl
Processus de construction du logiciel (7.1.5)
DET_CL_Impl, D_Seq_Impl

H 3 278v2 – 12 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

Vision Conception Domaine


architecture

Organisation Zend Projet


Métier
Collaborateur

Composants Tâche
Responsable développement

ConceptionBD

BacklogProduit
road map produit

fonctionnalités - release 1
story mapping par
les cas d’utilisation

Release 2
Suivre projets
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Figure 5 – Diagramme de packages du projet Agile (D_Pack_Projet)

Exemple du cas d’utilisation « suivre projets » : scénario d’exécution du cas. Le diagramme d’activités permet de
Ce cas d’utilisation (CU) permet à un chef de projet responsable représenter un ensemble des scénarios. Avec la version 2.5
d’un projet en cours de modifier la planification des tâches ainsi que d’UML, grâce aux adjonctions faites, il est possible d’utiliser le dia-
l’affectation des collaborateurs. La gestion de l’historique des affecta- gramme de séquence comme un diagramme d’activités au service
tions des collaborateurs aux tâches en cours est prise en charge. de la description d’un cas d’utilisation. Nous ne considérerons pas
Ce CU permet aussi de visualiser un bilan des charges (estimées et dans cet article les diagrammes de communication et chrono-
consommées) de tous les projets en cours. gramme UML (timing diagram).

La vue statique comprend plusieurs diagrammes. Le dia-


gramme de classes (D_CL) est le plus important des diagrammes 3.2 Modèles de produit associés
proposés par UML. Il est basé sur le paradigme objet et permet de à un diagramme de paquetages
générer du code. Le diagramme d’objets permet de représenter (D_Packages)
les instances des classes définies et ainsi de vérifier que les clas-
ses modélisées couvrent la totalité des besoins. Le diagramme de
paquetages (D_Packages) permet de structurer le projet. Le dia- Mécanisme général de regroupement d’éléments de modélisa-
gramme de déploiement (D_Déploiement) représente l’agence- tion en UML, le paquetage (package) a de multiples utilisations.
ment physique d’un système, précisant entre autres sur quels Chaque élément de modélisation (une classe, un objet, un cas d’uti-
composants matériels s’exécutent les composants logiciels lisation, etc.) appartient à un seul paquetage. Un diagramme de
(figure 8). Le diagramme de composants (D_Composant) permet paquetages ou de packages est un cas particulier de diagramme
de représenter la structure et les connexions entre composants de classes. Avec ce diagramme, il est possible de représenter :
logiciels (figure 9).  la structure du système étudié et le cas échéant de ses sous-
systèmes ;
Pour décrire le comportement, UML propose plusieurs types de
diagrammes. Le diagramme états-transitions (DET) représente le  l’organisation et le découpage souhaités du projet (D_Pack_-
cycle de vie commun aux objets d’une même classe à l’aide d’un Projet : figures 5 et 11) ;
automate à états finis. Le diagramme d’activités (D_Act) représente  les différents composants d’une application (D_Pack_Comp) et
les règles d’enchaı̂nement des activités. Ce type de diagramme est son architecture logicielle (figure 21).
bien adapté à la représentation de comportements à la fois séquen-
tiels et parallèles.
Les diagrammes d’interaction (diagramme de séquence (D_Seq),
diagramme de communication) permettent de représenter les coo-
3.3 Modèles de produit associés
pérations entre objets. Le diagramme de séquence met l’accent sur à un diagramme de séquence (D_Seq)
le déroulement temporel ; le diagramme de communication sur les
échanges réalisés. Pour compléter la description textuelle d’un cas Le diagramme de séquence décrit les interactions entre objets.
d’utilisation, on détaille avec un diagramme de séquence chaque Ces interactions consistent soit en demande de service et donc

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 13

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Fonctionnalités
< <extend> >

Créer projet

Affecter ressources projet

Gérer collaborateur

Responsable développement

Gérer avancement projet

Éditer bilans projets


Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Membre_service
Consulter caractéristiques projets

Planifier projet
Chef de projet

Suivre projets

Suivre tâches

Collaborateur

Figure 6 – Diagramme des cas d’utilisation du cas gestion de projet (D_Cas_Util)

indiquent le nom de l’opération à activer dans l’objet récepteur, Le diagramme de séquence permet aussi de détailler le fonc-
soit en envoi de message. Les diagrammes de séquence permet- tionnement d’un modèle d’architecture : par exemple, comme
tent de représenter avec plus ou moins de détails le fonctionne- dans la figure 10, les types d’interaction dans un modèle MVC
ment d’un cas d’utilisation. En général un cas d’utilisation com- (D_Seq_Architecture). C’est aussi le moyen de spécifier les scéna-
porte plusieurs scénarios. En mode « esquisse », on associe à rios des tests (D_Seq_Test). Enfin les diagrammes de séquence,
chaque scénario un diagramme de séquence qui comprend unique- utilisant les adjonctions de la version 2 d’UML, fournissent la
ment les lignes de vie de deux objets : une instance d’acteur et une description d’un algorithme (D_Seq_Algo).
instance du cas d’utilisation. Pour améliorer la lisibilité du dia-
gramme de séquence, nous attribuons le nom du scénario à l’ins-
tance du cas d’utilisation qui est considérée comme une boı̂te
noire. Ce diagramme est intitulé diagramme de séquence système 3.4 Modèles de produit associés
(D_Seq_Système). Il décrit l’enchaı̂nement des échanges entre à un diagramme de classes (D_CL)
l’acteur et le cas d’utilisation. Nous proposons comme [12] la cor-
respondance scénario de cas d’utilisation/user story. La figure 12
présente le diagramme de séquence système du scénario nominal Le modèle du domaine (D_CL_Domaine) permet de représenter
(ou user Story US1) : « Mise à jour planning » (MAJ Dates) du cas les concepts du système d’information étudié. Il fournit une repré-
d’utilisation « Suivre Projets ». sentation synthétique des termes du glossaire du projet à travers

H 3 278v2 – 14 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

Tâche Projet
* 1
refTâche : string nomProjet : string
description : string descriptionProjet : string
dateDebPrévue : date dateCréation : date
/dateDebRéelle : date [0..1] debutPrévu : date
dateFinPrévue : date /débutRéel : date [0..1]
/dateFinRéelle : date [0..1] finPrévue : date
chargeEstimée : integer /finRéelle : date [0..1]
chargeConsomméeTotale : integer [0..1] chargeEstimée : integer
/chargeConsommée : integer
/nbTâchesTotal : integer
/nbTachesTerminées : integer
* *

* projet *

Affectation historique
affectation projet
/dateDébut : date
/dateFin : date prévision charge affectée : integer
/chargeConsommée : integer [0..1] /charge_consommée : integer
motifChangement : string
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

chef projet collaborateur potentiel


1 *

Collaborateur
collaborateurHisto <<DataType>>
nomPrénom : string T Adresse
* login : string
fonction : string adresse1 : string
collaborateurActuel adresse2 : string
adresse : Adresse
e-mail prof : string code Postal : string
1 tel prof : string ville : string
Affectation actuelle tel mobile : string [0..1] pays : string
dateAssignation : date
chargeConsommée_RespActuel : integer [0..1]

Figure 7 – Diagramme de classes (modèle du domaine) du cas gestion de projet (D_CL_Domaine)

Serveur Web
Application web gestProjet : ApplWeb

1 1
1

*
SGBD
base de données gestProjet : ComponentBD
Chef Navigateur
de projet

Figure 8 – Diagramme de déploiement architecture de haut niveau (D_Déploiement)

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 15

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Extraits des composants zend utilisés


Comment
zend_validator zend_router zend_DB
Liste non
exhaustive

zend_Form Zend_http Zend_controller

<<use>>

Un Module générique

Controleur Form Model

controleur.php Entité.php EntiteTable.php


Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

View

nomControleur
module.php

nomaction.phtml

Figure 9 – Diagramme de composants Zend génériques (D_Composants avec packages)

les noms de classe, d’attribut dérivé ou non, d’association et de


rôle (figure 7). En général dans un modèle du domaine, on ne
: Navigateur client : controller : Model : View
décrit pas les opérations, ni le sens de navigation des associations,
ni la visibilité des attributs (privé, public ou protégé). Les classes
http request
sont en « 1FN » au sens du modèle relationnel (pas d’attribut multi-
request data
valué). Le type des attributs est en général un type primitif d’UML
(entier, chaı̂ne de caractères, etc.) ou un type simple comme date.
return data Ce modèle permet de collecter des indications sur la capacité du
système : cardinal des classes (par exemple : nombre de projets),
estimation des multiplicités (par exemple : en moyenne 80 tâches
par projet).
send data retrieved from model
Le diagramme de classes participantes (D_CL_Part_CU) repré-
sente les classes nécessaires à la réalisation d’un cas d’utilisation.
formated output Il est possible de construire le modèle du domaine par fusion des
diagrammes de classes participantes des cas d’utilisation du logi-
ciel à développer. Il est aussi possible d’utiliser ce type de dia-
gramme pour valider, en cohérence et complétude, un modèle
http response
du domaine préexistant. La figure 15 décrit la version partielle
obtenue à partir du scénario nominal/US1 « MAJ Dates » du dia-
gramme de classes participantes du CU Suivre_Projets. Au préa-
lable, en lien avec la réflexion sur les besoins en informations et
Figure 10 – Diagramme de séquence Modèle-Vue-Contrôleur (MVC) les interactions utilisateur, il est possible de matérialiser les infor-
simplifié Zend (D_Seq_Architecture) mations structurées échangées sous la forme d’un diagramme de

H 3 278v2 – 16 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

Description
Comment
Objectif produit release 1 :
Vue incomplète du contenu de l’itération 1
– découpage en itération + objectif produit de chacune des itérations

release 1

Itération1 Release 2

SuivreProjet
itération2
Story US1 / Scénario MAJ Dates

ClassesPart
Us1-Scénario – Extrait
Nominal MAJ Dates Domaine
Description
- D_Seq_Système

Objectif produit
release 2
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Figure 11 – Diagramme de paquetages vu du contenu du Package Road Map Produit (D_Pack_Projet)

: Chef de projet : US1 MAJ Dates : Suivre projets

InfosUtilisateur + Date Jour

Liste mes projets en cours

0() chercherProjet (projetChoisi)

DétailProjet

0() ChoisirTache (tacheChoisie)

DétailTacheEncours

DateFinPrevTâcheMAJ

0() validerMAJtâches ()

DétailProjet

0() ChoisirTache (tacheChoisie)

DétailTachePrévue

0() validerMAJtâches ()

Figure 12 – Diagramme de séquence scénario nominal/US1 : MAJ Dates (D_Seq_Système)

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 17

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

1 – Mes projets en cours 2 – Détail projet


Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

3 – Détail tâche 11 cas en cours 4 – Détail tâche 12 cas prévue

Figure 13 – Maquettes IHM scénario nominal/US1 : MAJ Dates

classes de signaux (D_CL_Signaux : figure 14). Il faut alors avoir Par exemple pour le modèle MVC, on peut utiliser dans le dia-
enrichi chaque message des interactions d’un diagramme de gramme de conception les stéréotypes <<vue>>, <<contrôleur>> et
séquence de type D_Seq_Système avec le signal associé <<model>> (figure 21).
(figure 12).
Par principe, il doit être possible de générer du code à partir
Le diagramme de classes peut être utilisé en conception et en du diagramme de classes d’implantation (D_CL_Impl) et inverse-
implantation. L’ensemble des notations possibles sera alors utilisé : ment d’obtenir à partir du code par rétro-ingénierie un dia-
visibilité des attributs, sens de navigation des associations, opéra- gramme de classes d’implantation. Le métamodèle CWM™ pro-
tions et visibilité des opérations. L’utilisation d’un framework, dans posé par l’OMG, implanté sous forme de profil dans plusieurs
notre exemple Zend, conduit à fusionner les diagrammes de AGL UML, permet de générer le DDL (Data Definition Language)
conception et d’implantation. Pour matérialiser le choix d’architec- et SQL (Structured Query Language) d’une base de données
ture logicielle retenu, un stéréotype est ajouté aux classes d’un relationnelle. La modélisation UML n’est alors plus utilisée en
diagramme de classes de conception (D_CL_Conception). mode « esquisse » mais en mode « plan » (figure 22).

H 3 278v2 – 18 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

InfosUtilisateur + Date DétailTacheEncours DateFinPrevTâcheMAJ


Jour
refTâche : string dateFinPrévue : date
nomPrenom : string description : string
datejour : date chargeEstimée : string
dateDebPrévue : date
dateDebRéelle : date NouvellesDatesTacheMAJ
dateFinPrévue : date
nomResponsableActuelTâche : string dateFinPrévue : date [0..1]
dateAssignation : date dateDebPrévue : date [0..1]
chargeConsommée_RespActuel : integer
Liste mes projets en cours etatTâche : EtatsTâche
chargeConsommeeTotale : integer
projetAffiché : ProjetEncours [1..*] histoAffectation : HistoAffectationEnCours [1..*] T HistoAffectationEnCours
dateDébut : date
nomCollaborateur : string
motifChangement : string
dateFin : date
DétailTachePrévue chargeConsommee : integer
refTâche : string
T ProjetEncours description : string
nomProjet : string chargeEstimée : string 12… EtatsTâche
chargeEstimée : integer dateDebPrévue : date
dateFinPrévue : date EnCours
chargeConsommée : integer Prévue
nomResponsableActuelTâche : string
dateAssignation : date
etatTâche : EtatsTâche
histoAffectation : HistoAffectationPrévue [1..*]
DétailProjet
T HistoAffectationPrévue
dateDébut : date
nomProjet : string
dateFin : date
descriptionProjet : string
T TâcheEnCoursEtPrévue nomCollaborateur : string
débutPrévu : date
motifChangement : string
débutRéel : date refTâche : string
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

finPrévue : date description : string


chargeEstimée : integer etatTâche : EtatsTâche
chargeConsommée : integer responsableTâche : string
nbTâchesTotal : integer 12… EtatsProjet
dateDebRéelle : date [0..1]
nbTâchesTerminées : integer dateFinPrévue : date EnCours
etatProjet : EtatsProjet dateDebPrévue : date
tâchesAffichées : TâcheEnCoursEtPrévue [1..*]

Figure 14 – Diagramme de classes des signaux scénario nominal/US1 : MAJ Dates (D_CL_Signaux)

3.5 Modèles de produit associés instance d’une classe. Le DET peut donc être utilisé à la fois
pour une classe d’un modèle de domaine, d’un modèle d’applica-
à un diagramme d’activités (D_Act) tion mais aussi d’un CU qui, dans le méta-modèle d’UML, est un
cas particulier de classe. La complétude est un des objectifs
Le diagramme d’activités a de multiples utilisations qui dépen- poursuivis pour produire une modélisation fiable. Le diagramme
dent de la granularité choisie pour la notion d’activité. Une acti- états-transitions est un des moyens les plus efficaces pour attein-
vité peut aussi bien représenter un applicatif, une tâche dre cet objectif.
manuelle, un cas d’utilisation ou une opération d’une classe.
Pour un cas d’utilisation, il permet d’obtenir sur un seul dia- Le DET associé à une classe du modèle du domaine (DET_CL_Do-
gramme (D_Act_CU) la représentation de tous les scénarios maine) permet notamment de vérifier que des opérations, des attri-
(figure 18). buts, voire des cas d’utilisation, n’ont pas été oubliés. Cet effort de
modélisation n’est pas considérable car il n’est pas utile de produire
Il est aussi possible d’utiliser ce type de diagramme comme un DET pour chaque classe du modèle du domaine. Pour l’exemple
support d’un manuel d’utilisation (D_Act_Util). Un diagramme est d’illustration, les figures 16 et 17 correspondent respectivement au
alors réalisé pour chaque cas d’utilisation. Il comporte deux lignes DET des classes Tâche et Projet.
de nage, celle de l’acteur et celle du cas d’utilisation (approche
boı̂te noire). Il est possible d’utiliser un diagramme états-transition pour
modéliser le comportement d’un cas d’utilisation et donc tous
Le diagramme d’activités permet aussi de modéliser le schéma ses scénarios (DET_CU). C’est aussi un moyen de décrire les
de navigation d’un site web ou des menus d’une application. Ce contraintes d’activation des cas d’utilisation en tenant compte
diagramme (D_Act_Navig) ne comporte ni ligne de nage, ni flot de l’état du système. On aussi peut se limiter à la représentation
d’information. Un profil spécifique est alors nécessaire [15]. Pour du fonctionnement de l’IHM (DET_IHM) dans l’exemple de la
le schéma de navigation d’un site web, les stéréotypes associés figure 20.
aux activités sont les suivants : <<page>>, <<frame>>, <<action>>,
<<exception>>, <<connector>> (figure 19).

3.6 Modèles de produit associés 4. Conclusion


à un diagramme états-transitions
(DET)
La norme ISO/CEI 12207 nous permet de disposer d’un référentiel
Le diagramme états-transitions permet de représenter les chan- pour élaborer un modèle de processus et définir les modèles pro-
gements d’état d’un objet au cours de sa vie. Un objet est une duits associés à chaque projet d’étude d’un logiciel en tenant

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 19

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Projet
Tâche nomProjet : string
refTâche : string 1 descriptionProjet : string
*
description : string debutPrévu : date
dateDebPrévue : date /debutRéel : date [0..1]
/dateDebRéelle : date [0..1] finPrévu : date
dateFinPrévue : date /finRéelle : date [0..1]
/dateFinRéelle : date [0..1] chargeEstimée : integer
chargeEstimée : integer /chargeConsommée : integer
/chargeConsomméeTotale : integer [0..1] /nbTâchesTotal : integer
/nbTachesTerminées : integer

* *

Affectation actuelle
dateAssignation : date
/chargeConsommée_RespActuel : integer [0..1]

collaborateurActuel Collaborateur
chef projet
nomPrénom : string
1
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

* 1
collaborateurHisto
Affectation historique
Comment
/dateDébut : date
/dateFin : date “les attributs états décrits dans les signaux mettent en évidence
/chargeConsommée : integer [0..1] le besoin de modéliser la dynamique des objets des classes
motifChangement : string Tache et Projet par un DET (cf fig. 14 et fig. 15)”

Figure 15 – Diagramme des classes participantes du scénario nominal/US1 : MAJ Dates (D_CL_Part_CU)

compte du système d’information dans lequel il sera intégré. Elle d’utilisation, puis ont maintenant évolué vers une mise en pra-
n’impose aucun modèle de cycle de vie, aucune méthode, ni tique de modélisation Agile au sein d’une démarche de type
aucun langage de modélisation. Bien qu’elle ait été élaborée en Scrum. Ces projets avaient soit pour objectif de produire du
1995 et revue en 2008, cette norme est exploitable dans le contexte code, soit uniquement de spécifier les besoins et les exigences
technologique actuel. Couplée à la puissance d’expression du lan- afin de construire un cahier des charges ou une spécification du
gage de modélisation UML, elle permet d’améliorer la qualité des « terminé » d’une itération. Tous ont été réalisés avec un AGL
spécifications du logiciel. UML qui permet de produire automatiquement la documenta-
tion du projet et de valider partiellement la cohérence des modè-
La plasticité des outils de modélisation d’UML rend plus com- les de produit.
plexe leur utilisation. La mise en perspective de leurs différents
contextes d’utilisation en fonction des tâches de la norme ISO/ La norme ISO/IEC 12207 et le langage de modélisation UML ont
IEC 12207 permet de déduire des règles de bonne modélisation été et demeurent des socles de référence permettant de présenter
pour chaque diagramme en fonction des objectifs d’étude. Il serait les caractéristiques de la production du logiciel en prenant en
nécessaire de spécifier les caractéristiques de chaque type de compte l’évolution des technologies et des pratiques de
développement.
modèle UML indiqué dans le tableau 5, et d’outiller en consé-
quence un AGL UML.
Le travail présenté dans cet article résulte d’une expérimenta-
tion de plus de 15 années aussi bien sur la notation UML que
dans la mise en œuvre de la norme ISO/CEI 12207 sur des pro-
5. Annexe : Exemple
jets réalisés dans le cadre de l’enseignement d’analyse et d’illustration du cas
conception des systèmes d’information dans un département
informatique d’IUT (délai moyen de 15 semaines et charge gestion de projet
moyenne de 1,5 mois*homme). Ces projets ont concerné des
systèmes d’information très divers : sites web dynamiques de
toutes natures, utilisation de systèmes d’information géographi- Cette annexe présente des usages possibles de modélisation uti-
ques (SIG), gestion de production, gestion électronique de docu- lisant le langage UML dans une mise en œuvre d’un cycle itératif et
ments. Ils ont d’abord utilisé une approche par les cas incrémental de type Scrum avec SBOK™, en suivant les phases et

H 3 278v2 – 20 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

/modification priorité()

Actif

/modification chef projet()

défini chef de projet affecté

En initialisation
[état avant = défini]
[état avant = chef projet affecté] Avec tâches

[état avant = avec tâches ou avec équipe]


Avec équipe
terminé

suspendu en cours
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

[état avant = en cours]

abandonné

Figure 16 – DET Classe Projet (DET_CL_Domaine)

/modifier_planification()

/créer_tâche()
planifiée /affecter_collaborateur()

Comment
Prévue (collaborateur affecté)
En bleu les états gérés /enregistrer_date_début_reel()
par le CU suivre projets
Do/modifier_affectation-
collaborateur()

/enregistrer_date_fin_reelle()
en cours
/modifier_planification()
Do/modifier_affectation-
collaborateur()

terminée
abandonnée
/modifier_planification()

Figure 17 – DET Classe Tâche (DET_CL_Domaine)

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 21

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

utilisateur connecté

[quitter]
Afficher Liste
de ses projets
en cours

Projet Choisi

[autre projet]
Afficher détail projet [quitter]
+ liste de tâches
en cours et prévues

tâche choisie

Afficher détail
tâche en cours
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

ou prévue
[autre tâche]

[Tache En Cours]
[modification assignation]
[Tache Prévue] nouvelle date Fin
prévue Afficher liste collaborateurs
nouvelles dates
disponibles période

[modification assignation]
[aucun collaborateur disponible]

[validation modification]
nouveau
collaborateur affecté

[retour modification]
Confirmer
modification
planification [Quitter]
tâche choisie

Figure 18 – Diagramme d’activités global du cas d’utilisation Suivre Projets (D_Act_CU)

les processus du tableau 4. Les diagrammes présentés reflètent & Phase Initialisation
l’état de la modélisation à l’issue de la spécification de la User
Story : US1/MAJ Dates correspondant au scénario nominal du cas La vision projet permettant d’avoir une vue de haut niveau du
d’utilisation Suivre Projets. catalogue de produits peut être obtenue :
 par la définition des cas d’utilisation et leur représentation
Les organisations du projet et de sa documentation sont décrites par un diagramme de cas d’utilisation accompagné de la
dans un diagramme de packages (figure 5). Dans cet exemple, description textuelle de chacun d’eux (figure 6) ;
nous retrouvons un package dédié à la vision, un autre à la gestion
du BacklogProduit, et un autre pour les itérations. Même si ce n’est  par le diagramme de classes modèle du domaine pour fournir
pas explicitement prévu par SBOK™, nous choisissons de stocker une vue métier globale correspondant au contexte de l’appli-
les versions stabilisées de l’architecture et celle de la conception cation (figure 7) ;
de la base de données issue de la modélisation du domaine dans  par la réalisation d’un diagramme de déploiement de l’archi-
des packages spécifiques. tecture de haut niveau (figure 8), d’un diagramme de

H 3 278v2 – 22 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML

http://www.ProjWeblUTLR.com/MesProjetsEncours

<<Page>>
[étatTache = Encours] Détail tâche en cours
<<Page>> <<Page>> <<Page>>
Page Accueil MesProjetsEnCours Détail projet

<<Page>>
Détail tâche prévue
[étatTache = Prévue]

Figure 19 – Diagramme d’activités schéma de navigation permettant la mise en œuvre scénario nominal/US1 : MAJ Dates (D_Act_Navig)
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

changer assignation

retour projet choisi confirmation assignation

en détail tâche
En attente choix tâche
détail projet choisi

En attente choix en détail tâche


projets en cours en cours En modification
assignation

retour mes projets


en détail tâche annuler modification
détail tâche choisie [EtatTâche = EnCours] prévue

détail tâche choisie [EtatTâche = Prévue]

confirmer modification

retour mes projets

Figure 20 – DET du scénario nominal/US1 : MAJ Dates (DET_IHM)

composants générique Zend (figure 9) et d’un diagramme de de visualiser un bilan des charges (estimée et consommée)
séquence MVC simplifié (figure 10) qui permettent d’avoir de tous les projets en cours.
une vue globale de l’architecture cible du produit. Nous choi-
sissons d’utiliser le cadriciel (framework) Zend pour PHP 5 qui
permet d’utiliser le principe de conception MVC (Modèle-Vue-
Contrôleur). À l’issue de la phase d’initialisation, nous disposons d’une
planification de haut niveau du produit appelée Road Map Produit.
Description textuelle du cas d’utilisation « suivre projets » : & Phase Planification et Estimation
Ce cas d’utilisation permet à un chef de projet responsable
d’un projet en cours de modifier la planification des tâches Pour notre exemple, l’itération 1 est centrée sur la spécification
ainsi que l’affectation des collaborateurs. La gestion de l’his- du cas d’utilisation Suivre Projets. Comme tout cas d’utilisation, il
torique des affectations des collaborateurs aux tâches en comporte plusieurs scénarios. Dans le cadre d’une approche Agile,
cours est prise en charge. Ce cas d’utilisation permet aussi nous choisissons d’assimiler un scénario à une User Story.

Copyright © - Techniques de l’Ingénieur - Tous droits réservés H 3 278v2 – 23

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

APPORT DE LA NORME ISO/IEC 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Zend
Modèle

Component <<modèle>>
TableGateway <<modèle>>
Projet ProjetTable
+ select()
+ $nomProjet : string # $projetTable : TableGateway
+ $chargeEstimee : integer
+ getProjetsEnCoursByCP(in $idChefProjet: string)
+ $chargeConsommee : integer
+ $idChefProjet : integer
AbstractController + $idProjet : integer

+ exchangeArray(in $data: string)

{Règles de nommage du framework:}

Vue Controleur

<<Artifact>> <<contrôleur>>
<<vue>> ProjetController
mes-projets-en-
cours.phtml # projetTable : string
+ mesProjetsEnCoursAction()

Figure 21 – Diagramme de classes partiel de conception/implantation du scénario nominal/US1 : MAJ Dates (D_CL_Conception)
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

<<Table>>
<<Table>>
Tache Projet

<<DataBaseAttribute, PropertyNotNull>> + T_DESCRI : VARCHAR2 A <<DataBaseAttribute, PropertyNotNull>> + PR_CHARGE_ESTIMEE : INT A


<<PrimaryKey, PropertyNotNull>> + ID_TACHE : INT A <<PrimaryKey, PropertyNotNull>> + PR_DESCRIPTION : VARCHAR2 A
<<ForeignKey, PropertyNotNull>> + ID_PROJET : INT A <<DataBaseAttribute, PropertyDefault>> + PR_CHARGE_CONSOMMEE : INT A
<<DataBaseAttribute, PropertyNotNull>> + T_DEBUT_PREV : DATE A <<PrimaryKey, PropertyNotNull>> + ID_PROJET : INT A
<<DataBaseAttribute, PropertyDefault>> + T_DEBUT_REEL : DATE A <<ForeignKeyLink>> <<ForeignKey, PropertyNotNull>> + PR_NOM : VARCHAR2 A
<<DataBaseAttribute, PropertyNotNull>> + T_FIN_PREV : DATE A <<DataBaseAttribute, PropertyNotNull>> + PR_DEBUT_PREV : DATE A
<<DataBaseAttribute, PropertyDefault>> + T_FIN_REEL : DATE A <<DataBaseAttribute, PropertyDefault>> + PR_DEBUT_REEL : DATE A
<<DataBaseAttribute, PropertyNotNull>> + T_CHARGE_ESTIMEE : INT A <<DataBaseAttribute, PropertyNotNull>> + PR_FIN_PREV : DATE A
<<DataBaseAttribute, PropertyDefault>> + T_CHARGES_CONSOMMEES : INT A <<DataBaseAttribute, PropertyDefault>> + PR_FIN_REEL : DATE A
<<DataBaseAttribute, PropertyNotNull>> + T_ETAT : VARCHAR2 A <<DataBaseAttribute, PropertyNotNull>> + PR_DATE_CREA : DATE A
<<ForeignPrimaryKey, PropertyDefault>> + T_COLLAB_ACTUEL : INT A <<DataBaseAttribute, PropertyNotNull>> + PR_ETAT_ACTIF : VARCHAR2 A
<<ForeignKey, PropertyNotNull>> + ID_CHEF_PROJET : INT A
<<DataBaseAttribute, PropertyNotNull>> + PR_ETAT : VARCHAR2 A

<<ForeignKeyLink>>
<<ForeignKeyLink>>

<<Table>>
Collaborateur
<<PrimaryKey, PropertyNotNull>> + ID_COLLAB : INT A Comment

A compléter

™ pour la base de données (D_CL_Impl)


Figure 22 – Extrait du diagramme de classes d’implantation conforme à CWM™

Le scénario nominal « MAJ Dates » sera traduit par la story US1 :


En tant que chef de projet, je veux pouvoir mettre à jour la pla-
nification de certaines tâches.

H 3 278v2 – 24 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

P
O
U
Apport de la norme ISO/CEI 12207 R
(2008) pour l’utilisation d’UML
E
par Marie Christine LAFAYE N
Maı̂tre de conférences honoraire
Université de La Rochelle, France

Annick LASSUS
et
Professeur Agrégé
IUT, Université de La Rochelle, France
S
A
Sources bibliographiques V
[1] AFNOR. – Ingénierie et qualité du logiciel
et des systèmes, Tome 1, Définition des
du.org/references/papers/pdf/ISO12207-
RUPv3.pdf (2004).
[11] ROQUES (P.). – UML est il soluble dans les
méthodes agiles. http://valtech.developpez.
O
processus et qualité des produits. com/articles/modelisation/uml/agile/ (2008).

[2]
ISBN 2-12-236141-7 (2002).

BOEHM (B.). – A Spiral Model of Software


[7] REINEHR (S.), BALDUINO (R.), MACHADO
(C.) et De PAULA PESSÔA (M.). – Implemen-
[12] AMBLER (S.). – Agile Modeling. http://www.agi-
lemodeling.com/.
I
R
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

ting ISO/IEC12207 Standard using Rational


Development and Enhancement. ACM
Unified Process. Proceedings of the Interna- [13] IRRAZABAL (E.), VASQUEZ (F.), DIAZ (R.) et
SIGSOFT Software Engineering, Volume 11
tional Conference on Software Engineering GARZAS (J.). – Applying ISO/IEC 12207 :
Issue 4, August 1986 Pages 14-24 (1986).
Research and Practice, SERP ’03, June 23 - 2008 with Scrum and Agile Methods.
[3] KRUTCHEN (P.). – Introduction au Rational 26, 2003, Las Vegas, Nevada, USA, Volume 2, R.V. O’Connor et al. (Eds.) : SPICE 2011,
Unified Process. Eyrolles (2000). p 667-680 (2003). CCIS 155, pp. 169-180 (2011).

[4] BOOCH (G.), RUMBAUGH (J.) et JACOBSON


(I.). – Le guide de l’utilisateur UML. Eyrolles
[8] SCHWABER (K.) et SUTHERLAND (J.). – 2016
Scrum Guide (2016).
[14] LARMAN (C.). – UML2 et les design patterns,
analyse et conception orientée objet et déve-
P
[5]
(2000).

FOWLER (M.). – UML 2.0. Campus Press


[9] AUBRY (C.). – SCRUM Le guide pratique de
loppement itératif. Pearson Education
France, 3ème édition (2005). L
la méthode agile la plus populaire. 4ème édi-

[6]
(2004).

KRUTCHEN (P.). – How the Rational Unified


tion, Dunod (2015).
[15] ROQUES (P.). – Les cahiers du programmeur,
UML modéliser un site e-commerce. Eyrolles
(2002).
U
[10]
Process Supports ISO 12207. The Rational
Edge : IBM Rational 2004, http://www.upe-
SCRUMSTUDY. – A Guide to the Scrum Body
of Knowledge. SBOK™ Guide (2016). S
À lire également dans nos bases
PINET (C.). – Référentiels normatifs – Proces- [H 3 228], Génie Logiciel, Technologies logi- CANALS (A.). – UML : une notation pour spé-
sus d’ingénierie informatique. [H 4 028], Gé- cielles – Production de logiciels (2004). cifier et concevoir des logiciels. [H 3 886]
nie Logiciel, Technologies logicielles – Archi- (2016).
tectures des systèmes (2012).
PRINTZ (J.). – Méthodes agiles. [H 3 202], Gé- CANALS (A.). – Sys ML/UML : comment les
PINET (C.). – Référentiels normatifs – Gestion nie Logiciel, Technologies logicielles – Archi- utiliser ? Avec quelle méthode ? Un exemple
du cycle de vie du logiciel. [H 4 031], Génie tectures des systèmes (2012). d’application avec UML-CS et Sys ML-CS.
Logiciel, Technologies logicielles – Architec- [H 3 887] (2016).
tures des systèmes (2012).
CANALS (A.). – Sys ML : une notation pour CANALS (A.). – Sys ML/UML-CS : une étude
GIROUX (P.). – Langage UML : développe- spécifier et concevoir des systèmes. [H 3 885] de cas. [H 3 888] (2017).
ment de logiciel et modélisation visuelle. (2015).

Outils logiciels
Modelio version 3.5.0, http://www.modeliosoft.com/fr.html Zend Framework version 2, https://framework.zend.com/learn

Sites Internet
Scott Ambler Modélisation Agile, http://www.agilemodeling.com

Copyright © - Techniques de l’Ingénieur - Tous droits réservés Doc. H 3 278v2 – 1

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

P APPORT DE LA NORME ISO/CEI 12207 (2008) POUR L’UTILISATION D’UML ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

O
U Normes et standards
R ISO/IEC 12207 IEEE Std 12207-2008 Second Edition 2008- OMG Unified Modeling Language (UML), http://www.uml.org.
02-01‘Systems and software engineering – OMG Model-Driven Architecture (MDA) http://www.omg.org/mda.
software life cycle processes’.
OMG Common Warehouse Metamodel (CWM™), http://www.omg.org/
ISO/IEC/IEEE 15288:2002 Ingénierie des systèmes et des logiciels – spec/CWM/.
E Processus du cycle de vie du système.
OMG Business Process Model and Notation (BPMN), http://www.bpmn.org.
The Open group Architecture framework (TOGAF‚), http://www.open-
group.org/togaf/.

S
A
V
O
I
R
Parution : août 2017 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

P
L
U
S

Doc. H 3 278v2 – 2 Copyright © - Techniques de l’Ingénieur - Tous droits réservés

tiwekacontentpdf_h3278 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
GAGNEZ DU TEMPS ET SÉCURISEZ VOS PROJETS
EN UTILISANT UNE SOURCE ACTUALISÉE ET FIABLE

Techniques de l’Ingénieur propose la plus importante


collection documentaire technique et scientifique
en français !
Grâce à vos droits d’accès, retrouvez l’ensemble
des articles et fiches pratiques de votre offre,
leurs compléments et mises à jour,
et bénéficiez des services inclus.

   
RÉDIGÉE ET VALIDÉE MISE À JOUR 100 % COMPATIBLE SERVICES INCLUS
PAR DES EXPERTS PERMANENTE SUR TOUS SUPPORTS DANS CHAQUE OFFRE
NUMÉRIQUES

 + de 350 000 utilisateurs


 + de 10 000 articles de référence
 + de 80 offres
 15 domaines d’expertise
Automatique - Robotique Innovation
Biomédical - Pharma Matériaux
Construction et travaux publics Mécanique
Électronique - Photonique Mesures - Analyses
Énergies Procédés chimie - Bio - Agro
Environnement - Sécurité Sciences fondamentales
Génie industriel Technologies de l’information
Ingénierie des transports

Pour des offres toujours plus adaptées à votre métier,


découvrez les offres dédiées à votre secteur d’activité

Depuis plus de 70 ans, Techniques de l’Ingénieur est la source


d’informations de référence des bureaux d’études,
de la R&D et de l’innovation.

www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com
LES AVANTAGES ET SERVICES
compris dans les offres Techniques de l’Ingénieur

  
ACCÈS

Accès illimité Téléchargement des articles Consultation sur tous


aux articles en HTML au format PDF les supports numériques
Enrichis et mis à jour pendant Pour un usage en toute liberté Des contenus optimisés
toute la durée de la souscription pour ordinateurs, tablettes et mobiles

 
SERVICES ET OUTILS PRATIQUES

Questions aux experts* Articles Découverte Dictionnaire technique multilingue


Les meilleurs experts techniques La possibilité de consulter des articles 45 000 termes en français, anglais,
et scientifiques vous répondent en dehors de votre offre espagnol et allemand

 
Archives Impression à la demande Alertes actualisations
Technologies anciennes et versions Commandez les éditions papier Recevez par email toutes les nouveautés
antérieures des articles de vos ressources documentaires de vos ressources documentaires

*Questions aux experts est un service réservé aux entreprises, non proposé dans les offres écoles, universités ou pour tout autre organisme de formation.

ILS NOUS FONT CONFIANCE

www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com

Vous aimerez peut-être aussi