Page 1

FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

WHO, WHAT, WHEN, HOW

STATUT document de travail version interne soumis à acceptation Approuvé

X

PUBLICATION DU DOCUMENT Starteam Desktop 1 Xwiki infrastructure

F:\FUP\FUP 1.0\Disciplines\Aperçu - Cycle de vie - synthèse\FUP-WhoWhatWhenHow.doc F:\FUP\FUP 1.0\Disciplines\Aperçu - Cycle de vie - synthèse\FUP-WhoWhatWhenHow.doc

1 Les documents relatifs à la méthodologie FUP peuvent être téléchargés localement sur votre disque dur au moyen de l’application Starteam projet FUP – fonctionnalité check out all.

Mise à jour Octobre 2007

Version

Page

0.5

1/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

HISTORIQUE DES MODIFICATIONS Date

Auteur

FUP

Version

Nature

29/07/2008

SUPDEV FOD – G.Merlini

1.0

0.1

Final Draft

RÉFÉRENCES FUP1/0/Disciplines/D1/FUP-D1-Modélisation Métier.doc

FUP 1.0 Discipline Modélisation Métier (vers. 0.9)

FUP1.0/Disciplines/D2/ FUP-D2-Exigences

FUP 1.0 Discipline Exigences (vers. 0.15)

FUP1.0/Disciplines/D3/ FUP-D3-Analyse et Conception.doc

FUP 1.0 Discipline Analyse et Conception (vers. 0.18)

FUP1.0/Disciplines/D4/ FUP-D4Implémentation.doc

FUP 1.0 Discipline Test (vers. 0.7)

FUP1.0/Disciplines/D5/ FUP-D5-Test.doc

FUP 1.0 Discipline Tests (vers.0.7)

FUP1.0/Modèles/D5/Stratégie de Tests Maitre.doc

FUP 1.0 Stratégie de Tests Maître (vers 0.2)

Mise à jour Octobre 2007

Version

Page

0.5

2/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

LÉGENDE

D1:

Discipline Modélisation Métier

D2:

Discipline Exigences

D3:

Discipline Analyse et Conception

D4:

Discipline Implémentation

D5:

Discipline Tests

UC:

Use Case / Cas d’Utilisation

CP:

Chef de Projet ICT

AF:

Analyste Fonctionnelle

ARC:

Architecte

AT:

Analyste Technique

PO:

Programmeur Opération

PD :

Programmeur Développement

TF:

Testeur Fournisseur

TSPF : Testeur SPF Finances

Mise à jour Octobre 2007

Version

Page

0.5

3/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

TABLE DES MATIERES 1.

INTRODUCTION............................................................................................................................... 6

2.

WHO – LES RÔLES FUP................................................................................................................. 7 2.1 WHO - CHEF DE PROJET ICT (CP) ....................................................................................................... 7 2.2 WHO - ANALYSTE FONCTIONNELLE (AF) ............................................................................................... 7 2.3 WHO - ARCHITECTE (ARC) .................................................................................................................. 8 2.4 WHO - ANALYSTE TECHNIQUE (AT) ...................................................................................................... 8 2.5 WHO - PROGRAMMEURS DÉVELOPPEMENT (PD) ................................................................................... 8 2.6 WHO - PROGRAMMEUR OPÉRATIONS (PO) ........................................................................................... 9 2.7 WHO - TESTEUR FOURNISSEUR (TF) .................................................................................................... 9 2.8 WHO - TESTEUR SPF (TSPF) .............................................................................................................. 9

3.

WHAT – LES DISCIPLINES, ARTEFACTS ET LIVRABLES FUP ............................................... 10 3.1 WHAT - SYNTHÈSE DES DISCIPLINES FUP .......................................................................................... 10 3.1.1 D1 - Modélisation Métier............................................................................................................ 10 3.1.2 D2 - Discipline Exigences .......................................................................................................... 10 3.1.3 D3 - Discipline Analyse et Conception....................................................................................... 11 3.1.4 D4 Discipline Implémentation .................................................................................................... 11 3.1.5 D5 Discipline Tests .................................................................................................................... 11 3.2 WHAT – LES ARTEFACTS ET LIVRABLES FUP PAR RÔLES .................................................................... 11 3.2.1 WHAT - Chef de Projet ICT ....................................................................................................... 12 3.2.2 WHAT - Analyste Fonctionnelle................................................................................................. 13 3.2.3 WHAT - Architecte ..................................................................................................................... 14 3.2.4 WHAT - Analyste Technique ..................................................................................................... 14 3.2.5 WHAT - Programmeurs Développement ................................................................................... 15 3.2.6 WHAT - Programmeur Opérations ............................................................................................ 15 3.2.7 WHAT - Testeur Fournisseur (TF) / Testeur SPF...................................................................... 16

4 WHEN – CYCLE DE VIE FUP ................................................................................................................ 17 4.1 WHEN - SYNTHÈSE DES PHASES ET ITÉRATIONS DU FUP .................................................................... 17 4.1.1 WHEN - Phase INCEPTION...................................................................................................... 17 4.1.2 WHEN - Phase ELABORATION................................................................................................ 17 4.1.3 WHEN - Phase CONSTRUCTION ............................................................................................ 18 4.1.4 WHEN - Phase TRANSITION.................................................................................................... 18 4.2 WHEN – CYCLE DE VIE FUP PAR RÔLE .............................................................................................. 19 4.3 WHEN – CYCLE DE VIE FUP PAR DISCIPLINE ...................................................................................... 20 5. HOW – L’UTILISATION DES OUTILS FUP.......................................................................................... 21 5.1 HOW - SYNTHÈSE DES OUTILS FUP.................................................................................................... 21 Mise à jour Octobre 2007

Version

Page

0.5

4/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

5.1.1 HOW - BORLAND Starteam...................................................................................................... 21 5.1.2 HOW - BORLAND CaliberRM ................................................................................................... 21 5.1.3 HOW - BORLAND Together ...................................................................................................... 22 5.1.4 HOW - BORLAND JBuilder ....................................................................................................... 22 5.1.5 HOW - MERCURY Quality Centre............................................................................................. 22 5.1.6 HOW - MERCURY Load Runner............................................................................................... 23 5.1.7 HOW - MERCURY Quick Test Professional ............................................................................. 23 5.1.8 HOW - EMBARCADERO ER/studio .......................................................................................... 23 5.2 HOW – LES OUTILS ET LES RÔLES FUP.............................................................................................. 23 5.2.1 HOW – Chef de Projet ............................................................................................................... 25 5.2.2 HOW – Analyste Fonctionnel..................................................................................................... 26 5.2.3 HOW – Architecte ...................................................................................................................... 28 5.2.4 HOW – Analyste Technique ...................................................................................................... 29 5.2.5 HOW - Programmeur Développement....................................................................................... 30 5.2.6 HOW - Programmeur Opérations .............................................................................................. 31 5.2.7 HOW - Testeur Fournisseur / Testeur SPF ............................................................................... 32 ANNEXE – CORRESPONDANCES RÔLES FUP ET RÔLES FILIÈRE COBOL2JAVA ........................ 33

Mise à jour Octobre 2007

Version

Page

0.5

5/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

1. INTRODUCTION Ce document a pour but de donner une vision de synthèse sur la méthodologie FUP (Finance Unified Process) de point de vue des rôles participants. Il est structuré dans les sections suivantes

-

WHO - Le résumé des rôles qui interviennent dans la mise en oeuvre de la méthodologie FUP et ses disciplines

-

WHAT –Le résumé des artefacts et livrables produits par chaque rôle avec une courte description des disciplines associés a ces artefacts.

-

WHEN – Le résumé du Cycle de Vie de la méthodologie par rôle et par discipline avec une courte description des différentes phases du Cycle de Vie

-

HOW – Les outils méthodologiques, les modèles et les rapports utilisés pour la production des se propre artefacts par rôle

Ce document se base sur les rôles et leurs responsabilités tels que spécifiés par les documents FUP 1.0 qui décrivent plus en détail chaque discipline de la méthodologie (voir section références).

La lecture de ce document ne remplace pas la lecture de la documentation FUP, en particulier la lecture des documents des disciplines FUP.

Mise à jour Octobre 2007

Version

Page

0.5

6/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

2. WHO – LES ROLES FUP Les rôles identifiés par les documents des disciplines du FUP (et par le document D5 – Strategie de Tests Maire) sont résumés dans la suite. ¾

Chef de Projet ICT (CP)

¾

Analyste Fonctionnelle (AF)

¾

Architecte (ARC)

¾

Analyste Technique (AT)

¾

Programmeur Développement (PD)

¾

Programmeur Opérations (PO)

¾

Testeur Fournisseur (TF)

¾

Testeur SPF (TSPF)

Le même membre de l’équipe du projet de développement ICT pourra correspondre à un ou plusieurs rôles selon ses propres compétences et le plan de gestion de ressources humaines du projet. La gestion des ressources humaines dans le cadre du développement ICT ne rentre pas dans le scope du FUP.

2.1 WHO - Chef de Projet ICT (CP) Bien que la discipline de Gestion du Projet ne soit pas reprise par la méthodologie FUP, le Chef de Projet ICT (CP) reste quand même responsable primaire de l’application de la démarche méthodologique. Elle/il est donc indirectement responsable de tous artefacts et livrables. L’application du FUP lui apporte plusieurs bénéfices, il ne devra se soucier de la définition des rôles nécessaires, des artefacts et livrables à produire, des activités associées et de leurs relations ainsi que des outils de travail à utiliser. Par contre sa capacité de sponsoriser l’utilisation du FUP au sein de son équipe et de motiver ses collaborateurs à appliquer les changements nécessaires dans la culture de travail, devient un facteur de succès nécessaire et critique. Le CP est aussi responsable primaire de la production de tous artefacts qui concernent: •

la communication avec les acteurs externes du projet (document de vision)

la planification de la mise en œuvre de la méthodologie (stratégie tests, gestion exigences, plan qualité du code)

Dans l’exécution de cette tache elle/il recevra la collaboration étroite d’autres membres de l’équipe spécialisés pour la discipline concernée.

2.2 WHO - Analyste Fonctionnelle (AF) L’Analyste Fonctionnelle (AF) est responsable de la définition et de la modélisation UML des fonctionnalités offertes par l’application ICT et de leur correspondance aux exigences exprimées par le métier. L’AF définit et modélise rigoureusement les fonctions et les changes des données qui ont lieu à l’interface entre l’application ICT et ses acteurs (utilisateurs ou autres applications externes) sans rentrer dans la description technique de ses composants internes. Elle/il utilise les termes du business auxquels elle/il ajoute les termes nécessaires pour la description des interfaces externes de l’application (page web, formulaire, poste client, poste serveur, database etc.) mais sans descendre dans la terminologie utilisée par le technique d’implémentation.

Mise à jour Octobre 2007

Version

Page

0.5

7/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

Elle/il est directement responsable de: •

La modélisation métier (optionnelle)

La description textuelle des Use Cases système et leur modélisation

La modèle conceptuelle des classes et des données persistants

La définition des toutes exigences (fonctionnelles et non)

2.3 WHO - Architecte (ARC) L’Architecte (ARC) doit garantir la cohérence de l’application à travers toutes disciplines. En particulier elle/il est responsable de la conformité de l’architecture technique de l’application ICT (en terme des composants principaux et de leurs relations) aux exigences fonctionnels et non fonctionnelles exprimés. Elle/il connait bien avantages et disavantages des technologies et standards disponibles, leurs options, et sait faire les choix technologiques qui mieux se conforment aux exigences exprimées. En particulier elle/il est responsable directe de : •

La découpe de l’application en ses composants principaux

Le choix des solutions technologiques et leurs options dans le respect des standards utilisés au SPF Finances

2.4 WHO - Analyste Technique (AT) L’Analyste Technique (AT) est responsable de la définition et modélisation UML des tous composants de l’application ainsi que de la définition de détail de leurs interfaces et de leurs relations. Elle/il définit rigoureusement les méthodes et propriétés qui décrivent les composants de l’application, classes et ou sous-système, et complète le packaging de l’application sur base des modules de l’architecture définis par l’ARC. L’AT complète le travail de l’AF en ajoutant les classes et objets nécessaires pour prendre en compte les solutions techniques (JSP, ASP, EJB, DB2, CCFF etc.) choisit par l’ARC et utilise la terminologie dérivée de ces solutions. Elle/il transforme donc l’Analyse Fonctionnelle dans une Analyse Technique qui sera implémentée dans le langage de programmation appropriée au composant. Elle/il est directement responsable de la modélisation technique de tous composants à tous niveau de l’application: •

Modèle Interface Utilisateur

Modèle Physique Données Persistants

Modèle de Conception des composants internes

N.B. Compte tenu de la multitude des technologies disponibles, et des leurs aspects volatiles, nous préférons ici éviter pour simplicité toutes spécialisation technique (analyste JSP, analyste EJB, analyste AJAX, analyste IBATIS, analyste DB2 etc.). Bien sure le profile de l’AT devra correspondre aux choix technologiques faites par l’ARC pour le composant de sa responsabilité.

2.5 WHO - Programmeurs Développement (PD) Le Programmeur Développement (PD) est responsable de l’implémentation des composants spécifiés par les modèles UML élaborés par l’AT (Modèle Interface Utilisateur, Modèle Données Persistants, Modèle Analyse et Conception). Le PD est responsable du codage de chaque composant en utilisant le langage de programmation propre à la technologie utilisée (HTML, Scriptlet/JSP, SQL/DB2, JAVA/J2SE etc.).

Mise à jour Octobre 2007

Version

Page

0.5

8/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

Elle/il est aussi responsable de l’exécution des tests de qualité (Revue du Code, Tests Unitaires, Test de Couverture, Métriques) de chaque composant logiciel de l’application.

N.B. : Compte tenu de la multitude des langage de programmation associés aux différents technologies disponibles, nous préférons ici pour simplicité éviter toutes terminologies de spécialisation technique (programmeur JSP, programmeur HTML, programmeur SQL, programmeur J2SE, programmeur J2EE etc.).

2.6 WHO - Programmeur Opérations (PO) Le Programmeur Opérations (PO) est responsable du plan et de l’exécution de l’intégration des composants dans l’application même. Elle/il connaît bien l’architecture spécifiée par l’ARC, les composants produits par le PD ainsi que leurs relations. Le PO utilise les langage des BuildScripts (ex. MAVEN2 ou ANT) pour construire/intégrer l’application et la configurer pour son installation dans les environnement de tests (Tests Intégration, Test d’Acceptation).

2.7 WHO - Testeur Fournisseur (TF) Le Testeur Fournisseur (TF) est responsable de la définition, organisation et exécution des Tests d’Intégration à la fin de chaque itération de construction de l’application. Le but de chaque campagne de Tests d’Intégration est de vérifier la qualité (fonctionnelles et non fonctionnelles) associé à chaque itération et déclarer en temps utiles les anomalies identifiés. Elle/il pourra demander la collaboration de l’AF pour la définition du Dossier des Tests et pour l’interprétation dans le Bilan des Tests des résultas obtenus. Elle/il pourra aussi demander l’assistance du PD pour l’exécution des tests et du PO pour la configuration de l’environnement d’Intégration. Le TF est associé à l’équipe qui fournit le développement de l’application ICT, peu importe que il s’agisse d’une équipe composée du personnelle interne au externe au SPF.

2.8 WHO - Testeur SPF (TSPF) Le Testeur SPF est responsable de la définition, organisation et exécution des Tests d’Acceptation à la fin du cycle de développement de l’application. Le TSPF pourra utiliser pour le dossier de Tests d’Acceptation, un sous ensemble du dossier de tests définis par le TF pour le Tests d’Intégration. Elle/il pourra demander la collaboration de l’AF, du PD et du PO respectivement pour l’interprétation des résultas, l’exécution des instructions des tests, la configuration de l’environnement de test. Elle/il est aussi responsable de la récolte et mise à disposition des données nécessaires à la campagne des Tests d’Acceptation et de la production du Bilan de Tests sur le quel se basera l’acceptation de l’application ICT. Le TSPF est associé au service du SPF Finance qui est client de l’application ICT et est indépendant de l’équipe qui fournit l’application même.

Mise à jour Octobre 2007

Version

Page

0.5

9/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

3. WHAT – LES DISCIPLINES, ARTEFACTS ET LIVRABLES FUP Cette section synthétise les disciplines, les artefacts et les livrables FUP en association à chaque rôle FUP décrit dans la section précédente.

Nous rappelons ici la distinction entre « artefact » et « livrable » :

-

Artefact : le produit de l’activité de chaque discipline définis par la méthodologie FUP. Un artefact FUP peut être un model UML (exemple «D3 - Diagramme des Cas d’utilisation ») ou bien un document («D2 - Vision ») ou bien un rapport («D2 - Liste des Exigences).

-

Livrables : document qui contient un ou plusieurs artefacts en rélation entre eux et qui est délivré au SPF Finances pour acceptation. La description de chaque livrable est contenue dans un document « Modèle » (voir FUP1.0/Modèles).

Le lecteur est prié de s’adresses aux documents de discipline FUP pour une compréhension plus détaillée des artefacts de chaque discipline et des activités correspondantes 2 .

3.1 WHAT - Synthèse des Disciplines FUP Les artefacts, et leurs activités de production, sont groupés dans les disciplines FUP suivantes : 3.1.1 D1 - Modélisation Métier L’objectif de la discipline D1 est de comprendre, documenter et expliquer les activités et les processus métier des utilisateurs de l’application ICT. La discipline D1 est optionnelle. Sa prise en compte dans le développement de l’application ICT dépendra de la connaissance des processus et du domaine métier par l’équipe du développement et de la disponibilité de la documentation correspondante. La technique de l’analyse des UCs est au centre de la démarche et les interactions enter les acteurs du métier sont pris en considération sans prendre encore en compte leur automatisation par l’application ICT à developper. Le langage utilisé dans D1 est purement Métier on parlera donc à ce niveau de « UC Métier ». 3.1.2 D2 - Discipline Exigences L’objectif de la discipline D2 est la définition de toutes exigences (fonctionnelles et non fonctionnelles) dérivés des besoins initiales et des fonctionnalités offertes par l’application ICT. La technique de l’analyse des UCs est au centre de la démarche. Les UCs doivent décrire toutes interactions entre les acteurs et l’application ICT. On parlera donc à ce niveau de « UC Système ». Le langage utilisé dans D2 comprend les termes métier nécessaires pour décrire les acteurs du métier et les données échangés entre les acteurs et l’application. Il comprend aussi les termes ICT nécessaires à décrire les fonctions d’accès à l’application ICT à un niveau de détail indépendant de la technologie utilisée (page web, formulaire, application ou database externe, station client, station serveur etc.).

2

Les activités décrites par les documents des disciplines FUP ne sont pas ici mentionnées. Dans une large majorité des cas la correspondance entre activité FUP et artefacts FUP est univoque et donc la différence entre artefact et activité n’apporte pas à ce synthèse un important valeur ajouté (l’activités « D1 - Produire le Glossaire » est associé à l’artefact « D1 - Glossaire », l’activité « D3 - Elaborer le modèle Conceptuel es Données » est associé à l’artefact « D3 - Modèle Conceptuel des Données » etc)

Mise à jour Octobre 2007

Version 0.5

Page 10/34


FUP 1.0 Who, What, When, How.

Support au développement support.supdev@minfin.fed.be

3.1.3 D3 - Discipline Analyse et Conception L’objectif de la discipline D3 est l’analyse de la réalisation des fonctionnalités et de toutes exigences (fonctionnelles et non) identifiés par D2 sur base des composants techniques. La définition de l’architecture logicielle et la réalisation des UCs sont au centre de la démarche qui est itérative et incrémentale. Chaque artefact est enrichit après analyse de la réalisation d’un nouvel ensemble des UCs à chaque itération (voir aussi Cycle de Vie). La réalisation des UCs se fait par extension de leur description D2 aux composants techniques dérivées de l’architecture logicielle. Le langage utilisé dans D3 est technique est doit permettre une correspondance facile et directe entre les objets spécifiés dans les artefacts D3 et leur programmation dans D4. 3.1.4 D4 Discipline Implémentation L’objectif de la discipline D4 est le codage des composants techniques et de leurs relations, tels que spécifiés par les artefacts de D3, l’intégration des composants en modules exécutables et le contrôle de la qualité de ces activités. La démarché est itérative et incrémentale et suit l’évolution de la discipline D3. 3.1.5 D5 Discipline Tests L’objectif de la discipline D5 est de définir et exécuter la vérification de l’implémentation des exigences de l’application ICT. Il s’agit donc de définir et d’exécuter des tests de type « blackbox » (avec regard sur les interfaces externes et sans regard sur le fonctionnement interne) sur base de la définition des exigences fonctionnelles et non fonctionnelles définis par D2 et sans rentrer dans le détail de la structure interne de l’application définis par D3. Le contrôle de la qualité des livrables de la discipline D4 fait quand même partie des aspects à prendre en compte lors de l’acceptation de l’application ICT afin de vérifier sa maintenabilité. La démarche est encore une fois itérative et incrémentale. A chaque itération on ajoute la définition et l’exécution des tests d’intégration pour les fonctionnalités implémentés dans la même itération par la discipline D4. Cela sous la responsabilité de l’équipe fournisseur. A la fin du développement une nouvelle campagne des tests est prévue pour l’acceptation sous responsabilité du service client du SPF Finances.

3.2 WHAT – Les Artefacts et livrables FUP par Rôles Pour chaque rôle de la méthodologie FUP cette section montre la correpondance entre :

-

Discipline

-

Nom de l’Artefact FUP produit par le rôle

-

Courte description de l’artefact

-

Livrable FUP associé à l’artefact

Mise à jour Octobre 2007

Version 0.5

Page 11/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

3.2.1 WHAT - Chef de Projet ICT Discipline

Artefact

Courte Description

Livrable

D2

O21 – Document de Vision

Synthèse des besoins, des objectifs, du périmètre et du contexte du projet.

L21 – Vision

D2

O26 – Plan Gestion des Exigences

Définition des méthodes de gestion et de la classification des exigences (fonctionnelles et non fonct.)

L26 – Plan gestion des Exigences

D4

O41 – Rapport d’Installation des Environnements

Demande d’installation des environnements (développement, intégration, acceptation).

L41 – Rapport d’Installation des Environnements

D4

O42 – Plan de la Qualité du Code

Définition des procédures et du plan d’exécution des vérifications de la qualité du code.

L42 – Plan Qualité Discipline D4

D5

O51 – Critères d’Acceptation

Sélection et pondération des exigences spécifiées

L51 – Stratégie de Tests

D5

O52 – Stratégie des Tests Déclinés

Customisation du document « Stratégie de Tests Maître » sur base des exigences spécifiques.

Mise à jour Octobre 2007

Version 0.5

Page 12/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

3.2.2 WHAT - Analyste Fonctionnelle Discipline D1 (opt.)

Artefact O11 – Modèle des Cas d’Utilisation (UC) Métier O11.1 – Diagramme des UCs Métier

Courte Description

Livrable

Modélisation et description des processus métier sous forme des Cas d’Utilisation (UC)

n.a.

Modélisation et description des classes identifiées dans les UCs métier et de leurs relations.

n.a.

O11.2 – Description Textuelle UC Métier O11.3 – Diagramme Séquence UC Métier O11.4 – Diagramme Activité UC Métier (opt.) O11.5 – Diagramme des Acteurs Métier

D1 (opt.)

O12 – Modèle du Domaine Métier O12.1 – Diagrammes des Classes Métiers O12.2 – Diagrammes d’Etats des Classes Métiers

D1 (opt.)

O13 – Glossaire

Termes du domaine métier (FR, NL) décrits pour éviter les ambiguïtés et interprétations erronées.

n.a.

D2

O22 – Modèle des Cas d’Utilisation Système (UCs)

Identification des Acteurs et les Cas d’Utilisation (UC) du système et leur répartition en modules fonctionnels (UC)

L22 – Dossier Architecture Fonctionnelle

Modélisation et description des Cas d’Utilisation (UC) systèmes pour capturer toutes interactions entre l’application ICT et ses acteurs.

L23 – Spécification des Cas d’Utilisation

O22.1 – Diagramme des UCs Système O22.2 – Description Textuelle UC Système O22.3 – Diagramme Sequence UC Système O22.4 – Diagramme Activité UC Système (opt.) O22.5 – Diagramme des Acteurs Système

Mise à jour Octobre 2007

Version 0.5

Page 13/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

D2

O23 – Spécification exigences non fonctionnelles (ou supplémentaires)

Définition des exigences non fonctionnelles (performance, sécurité, ergonomie, capacité etc.)

L24 – Spécification Exigences Non Fonctionnelles

D2

O24 – Liste complète des Exigences

Liste exhaustive de toutes exigences de l’application (fonctionnelles et non fonct.)

L25 – Liste Complète des Exigences

D3

O33.1 – Modèle Conceptuelle des Données

Modèle des classes persistantes dentifiées par la description des UCs de la discipline D2.

L33 – Modèle des Données

3.2.3 WHAT - Architecte Discipline D3

Artefact O31 – Dossier Architecture Logicielle

Courte Description Spécifications des technologies utilisées, des composants principaux et de leurs relations.

Livrable L31 – Dossier Architecture Logicielle

3.2.4 WHAT - Analyste Technique Discipline D3

Artefact O32 – Modèle Interface Utilisateur O32.1 – Maquette Statique des écrans O32.2 – Modèle Cinématique des Écrans

Courte Description

Livrable

Spécification de l’interface utilisateur, avec définition des écrans statiques, du flux qui devra être implémenté et des données utilisées.

L32 – Modèle Interface Utilisateur

O32.3 – Description des Données de l’Écrans D3

O33.2 – Modèle Physique des Données

Modèle physique des données persistantes sous forme de diagramme E/R.

L33 – Modèle des Données

D3

O34 – Modèle d’Analyse et conception

Présentation de toutes classes participants, de leurs packages et de leurs relations (O34.1). Pour chaque UC modélisation de toutes interactions entre classes participants et acteurs (O34.2).

L34 – Modèle d’Analyse et Conception

O34.1 – Modèle de Conception O34.2 – Réalisation des Cas d’Utilisation

Mise à jour Octobre 2007

Version 0.5

Page 14/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

3.2.5 WHAT - Programmeurs Développement Discipline

Artefact

Courte Description

Livrable

D4

O44 – Eléments d’Implémentation

Code source de l’application implémentée (java, html, sql etc.)

L44 – Eléments d’Implémentation

D4

O45 – Rapport Qualité du Code

Rapport des résultas de la vérification de la qualité du code.

L45 – Rapport de la Qualité de la Discipline D4

O45.1 – Rapport Revue du Code O45.2 – Rapport Tests Unitaires O45.3 – Rapport de Couverture des Tests O45.4 – Rapport des Métriques 3.2.6 WHAT - Programmeur Opérations Discipline

Artefact

Courte Description

Livrable

D4

O43 – Plan Intégration des Builds

Documenter et planifier les procédures à appliquer pour produire l’application sur base des différents modules et leurs dépendances.

L43 – Plan d’Intégration des Builds

D4

O46 – Builds des Système Exécutables

Intégration des composants de l’application sur base de O43.

L46– Builds des Système Executables

Mise à jour Octobre 2007

Version 0.5

Page 15/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

3.2.7 WHAT - Testeur Fournisseur (TF) / Testeur SPF Discipline D5

Artefact O53 – Dossiers de Tests O53.1 – Cas de Test O53.2 – Scripts de Test Automatisés

D5

O54 – Bilan de Tests O54.1 – Résultas de Tests

Courte Description

Livrable

Description détaillée des cas des tests en terme d’exigences à vérifier, des actions à exécuter, des données à utiliser, des résultats attendus.

L52 – Dossier de Tests

Rapport d’exécution des tests avec statistiques de couverture, taux de réussite et liste des anomalies détectées.

L53 – Bilan de Tests

O54.2 – Fiche des Anomalies

Mise à jour Octobre 2007

Version 0.5

Page 16/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

4 WHEN – CYCLE DE VIE FUP Le Cycle de Vie FUP est synthétisé dans la suite sur base de deux points de vue : ¾

Cycle de Vie par Rôle : les activités de production des artefacts sont groupées par chaque rôle

¾

Cycle de Vie par Discipline : les activités de production des artefacts sont groupées par discipline

Dans les deux cas le Cycle de Vie FUP est décomposé dans un nombre limité des phases décrites dans la suite.

Avant toutes descriptions et synthèses c’est peut être utile préciser que le Cycle de Vie FUP ne représente pas un modèle du Plan du Projet de développement. Le Plan du Projet pourra s’inspirer au Cycle de Vie pour le phasage du projet et pour les relations entre les activités de production des artéfacts FUP mais devra aussi considérer les taches propres à la Gestion du Projet (Gestion des Risques, de la Configuration, de la Communication, Documentation Utilisateur etc.). On notera aussi que le Cycle de Vie FUP ne prends pas en compte la durée des activités de la méthodologie qui est spécifiques à chaque projet. Sur la base de l’expérience on peut quand même remarquer que les itérations des phases Inception, Elaboration et Transition ont souvent une durée majeure (un ou plusieurs mois) des itérations de la phase de Construction (quelques semaine).

4.1 WHEN - Synthèse des Phases et Itérations du FUP 4.1.1 WHEN - Phase INCEPTION Dans cette phase les objectifs, les exigences à la base du projet, le périmètre fonctionnel et technique ainsi que la stratégie d’exécution du projet de développement sont définis. Les disciplines impliquées sont : -

D1 : le projet de développement ICT clarifie les besoins business faisant recours, optionnellement, à la discipline Modélisation Métier pour décrire le processus et le domaine business

-

D2 : on identifie les objectifs principaux du développement, en terme des UCs système et des Exigences (Fonctionnelles et non) fondamentaux.

-

D5 : on défini les Critères d’Acceptation principales et la Stratégie de Tests.

Dans le cas d’un développement Externalisé les artefacts produits dans cette phase seront publiés avec le Cahier de Charge (hors FUP). En tous les cas cette phase se terminera avec le « scheduling » de l’équipe fournisseur (interne, externe au SPF Finance ou mixte). 4.1.2 WHEN - Phase ELABORATION Après avoir choisi et mobilisé l’équipe de développement (externe ou interne) on consolide et on finalise tous artefacts initialisés en Inception (1) et on produit tous artefacts nécessaires à la construction d’un prototype de l’application (2). Pour mettre en évidence ces deux étapes la phase et divisé en deux itérations : ¾

Consolidation

¾

Construction Prototype

Mise à jour Octobre 2007

Version 0.5

Page 17/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

Le prototype réalise un nombre limité des UCs, même partiellement, afin de valider en temps utile la satisfaction des besoins business stratégiques qui justifient le ROI (Retour des Investissements) de l’application, et les solutions techniques plus significatives pour la gestion des risques technologiques. Tous disciplines sont impliquées : -

D1 : on consolide et finalise les besoins du métier (optionnellement la Modélisation Métier).

-

D2 : on consolide la Vision du projet, on finalise la description des Use Cases systèmes et la spécification de tous types d’Exigences.

-

D3 : on produit une version complète du Dossier d’Architecture Logicielle et on initialise les autres artefacts plus détaillés en ciblant la construction du prototype.

-

D4 : on construit le prototype (réalisation même partiel d’un nombre limité des UCs stratégiques).

-

D5 : on débute le dossier de tests et on exécute les tests d’intégration du prototype 4.1.3 WHEN - Phase CONSTRUCTION

Après avoir pris en considération le feed-back du prototype sur les artefacts déjà produit, en particulier sur les artefacts de la discipline D2, on construit l’application avec une approche itérative et incrémental basé sur les fonctionnalités. Cette approche se réalise en divisant la phase en un nombre prédéfinis d’itérations et en associant chaque itération à l’implémentation complète, avec tous ses scénarios, d’un ensemble des UCs. Les disciplines impliquées sont les suivants : -

D3 : à chaque itération on incrémente le contenu des artefacts d’analyse en considérant les nouveaux UCs

-

D4 : à chaque itération on incrémente l’implémentation avec le codage des nouveaux composants

-

D5 : à chaque itération on incrémente le dossier des tests avec description des tests associés aux nouvelles exigences et on exécute les tests d’intégration correspondants. 4.1.4 WHEN - Phase TRANSITION

Après la Construction de l’application ICT, la phase de Transition prépare la mise en opération définitive de la même application. Cette phase est divisée en trois itérations : ¾

Acceptation:

acceptation formelle de l’application sous responsabilité du service client du SPF Finance

¾

Pilote:

mise en exploitation par un nombre limité d’utilisateurs et prise en compte de leur feed-back.

¾

Généralisation:

déploiement de l’application vers tous utilisateurs.

Actuellement la « Géneralisation » est sous responsabilité du service ICT Opération du SPF Finance et est donc hors FUP.

Les disciplines impliquées sont les suivantes : -

D5 : un sous ensemble du dossier des tests d’acceptation est définis sous responsabilité du service client du SPF Finance, les tests sont exécutés et les éventuelles anomalies déclarées.

-

D1-D5 : sur base de la procédure de Gestion du Changement (Change Requests) le service client du SPF Finance demandera à l’équipe fournisseur la correction des anomalies ou l’implémentation des améliorations éventuels et cela pour tous artefacts FUP.

Mise à jour Octobre 2007

Version 0.5

Page 18/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

4.2 WHEN – Cycle de Vie FUP par Rôle

Mise à jour Octobre 2007

Version 0.5

Page 19/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

4.3 WHEN – Cycle de Vie FUP par Discipline

Mise à jour Octobre 2007

Version 0.5

Page 20/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5. HOW – L’UTILISATION DES OUTILS FUP 5.1 HOW - Synthèse des Outils FUP Des outils méthodologiques sont fournis par SUPDEV afin de mettre en œuvre la méthodologie FUP 1.0. Leur installation et/ou configuration peut être demandée par les utilisateur du SPF Finances à l’adresse

« support.supdev@minfin.fed.be »

Nous invitons le lecteur à ne pas confondre la méthodologie FUP 1.0 avec les outils méthodologiques mises à disposition par SUPDEV. Les outils méthodologiques sont au service de la méthodologie et pas le contraire. La simple utilisation d’une ou plusieurs outils méthodologiques ne constitue pas une méthodologie en soi même.

Dans la suite une courte description est fournie par chaque outil méthodologique. 5.1.1 HOW - BORLAND Starteam BORLAND Starteam est un outil de gestion de la configuration. Dans la mise en œuvre de la méthodologie FUP son utilisation est recommandée pour toutes disciplines afin de:

-

Stocker sur un serveur centralisé les différents releases des artefacts et livrables du projet de développement ICT, inclus les diagrammes UML, les documents et les fichiers sources Gérer l’accès aux artefacts et livrables du projet par différents profiles d’utilisation Identifier et grouper les différents releases des artefacts et livrables du projet dans des version cohérents associé aux itérations du projet (labelling). Permettre la synchronisation de plusieurs membres du projet sur les artefacts et livrables (check in, check out). Maintenir l’historique des différents releases de chaque artefact ou livrable (history) Gérer les changements des artefacts et livrable du projet (change request)

L’outil STARTEAM s’intègre avec CALIBER RM, TOGETHER et JBUILDER pour faciliter la gestion de la configuration et du changement des artefacts produits par ces outils ainsi que pour permettre la synchronisation des accès utilisateurs à ces artefacts. 5.1.2 HOW - BORLAND CaliberRM BORLAND Caliber RM est un outil de gestion des exigences. Dans la mise en œuvre de la méthodologie FUP son utilisation est recommandée dans le cadre de la discipline « D2 – Exigences » pour :

-

Stocker sur un serveur centralisé la définition textuelle des exigences du projet, leur statu ainsi que la documentation associée Gérer l’accès aux exigences du projet par différents profiles d’utilisation Grouper et hiérarchiser les exigences en catégories Eteindre la structure de catégorie spécifique des exigences par des attributs spécifiques. Définir le glossaire du projet avec lien entre la description des exigences et la description des termes. Gérer la traçabilité entre les exigences et entre les exigences et autres artefacts du projet. Produire des rapports formatés des exigences

Mise à jour Octobre 2007

Version 0.5

Page 21/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

L’outil CALIBER RM s’intègre avec STARTEAM pour la gestion de la configuration des artefacts de FUP 1.0 et avec TOGETHER pour définir des liens de traçabilité entre les exigences de l’application et la modélisation UML.

Les exigences définies dans CALIBER RM peuvent être associées à la description des cas de tests définis dans MERCURY QC. 5.1.3 HOW - BORLAND Together BORLAND Together est un outil de modélisation. Dans la mise en œuvre de la méthodologie FUP son utilisation est recommandée pour les disciplines D1, D2, D3 afin de:

-

Produire tous diagrammes UML demandés par les artefcts de la discipline Spécifier les propriétés et méthodes des objets de la modélisation UML et leurs relations (use cases, acteurs, classes, diagrammes de séquence etc.) Structurer les objets UML dans des containers (packages) correspondants aux composants du « design » de l’application Produire des rapports UML à intégrer dans les livrables FUP 1.0 (fichier « .tpl »)

TOGETHER est une application client intégrée avec un serveur STARTEAM. Le projet de modélisation avec ses diagrammes et ses objets UML est centralisé dans le serveur STARTEAM et les outils de synchronisation d’accès STARTEAM sont mis à disposition de l’utilisateur TOGETHER.

TOGETHER s’intègre aussi avec CALIBER RM pour définir des liens de traçabilité entre les exigences de l’application et les objets (classes, diagrammes) de la modélisation UML. 5.1.4 HOW - BORLAND JBuilder BORLAND JBuilder est une IDE (Integrated Développement Environment). Depuis sa version 2007 il est dessiné pour la Eclipse Open Source Platform. Dans la mise en œuvre de la méthodologie FUP son utilisation est recommandée pour la discipline D4 afin de:

-

Faciliter la programmation des modules d’une application JAVA/J2EE Faciliter l’accès de ces modules avec les libraries spécifiques au SPF Finances, tels que le CCFF Intégrer les extensions nécessaires au contrôle de la qualité du code (COBERTURA, CHECKSTYLE, PMD et les fonctions de Métriques) Intégrer les extensions nécessaires à l’exécution des Buildscripts (ANT ou MAVEN2)

JBUILDER s’intègre avec STARTEAM pour gérer la configuration des modules logiciel et du source code de l’application. Il est ainsi possible de donner une structure commune aux modules logiciel, de les partager antre plusieurs développeurs, de synchroniser les activités entre plusieurs développeurs. 5.1.5 HOW - MERCURY Quality Centre MERCURY Quality Centre est un outil de Contrôle de la Qualité des applications ICT centré sur la vérification des fonctionnalités. Dans la mise en œuvre de la méthodologie FUP son utilisation est recommandée pour la discipline D5 afin de:

-

Définir un ensemble complet de cas de test de l’application (test plan) Associer les exigences à vérifier pour chaque cas de test Vérifier que toutes exigences sont pris en compte et vérifié par un cas de test (tracabilité tests/exigences) Configurer et executer une campagne de test partiel ou complète de l’application (test lab)

Mise à jour Octobre 2007

Version 0.5

Page 22/34


FUP 1.0 Who, What, When, How

-

Support au développement support.supdev@minfin.fed.be

Exécuter les tests manuellement ou par des scripts automatiques et enregistrer les résultas (test lab) Enregistrer les anomalies identifiées (defects) Produire le rapport et statistiques de la campagne de tests

MERCURY QC peut importer automatiquement les exigences définies dans CALIBER RM et les associer à la définition des cas de tests. 5.1.6 HOW - MERCURY Load Runner MERCURY Load Runner est un outil de Contrôle de la Qualité des applications ICT centré sur la vérification des performances et basé sur les modules suivants:

-

Virtual User (Vuser) Generator, qui permet la création et l’exécution de scripts Vuser. Les scripts peuvent être créés par enregistrement ou « from scratch ». Dans les deux cas, ils peuvent évidemment être modifiés;

-

Controller, qui permet la définition et l’exécution de scénarii (composé de scripts) ;

-

Load Generator / Load Generator, qui permet l’exécution de Vusers pour générer la charge ;

-

Analysis, qui permet l’analyse offline des résultats et mesures collectée lors d’une exécution ;

-

Tuning, qui permet une analyse dans le but optimiser l’ensemble du système par identification et élimination des éventuels « goulots d’étranglement ».

La licence actuelle offre la possibilité de définir et gérer jusqu’à 250 Vusers (type Web) lors de l’exécution de scenarii. 5.1.7 HOW - MERCURY Quick Test Professional MERCURY Quick Test est un outil de Contrôle de la Qualité des applications ICT qui vérifie la non régression fonctionnelle de l’application vis-à-vis des releases précédents. QUICKTEST permet l’exécution automatique des tests fonctionnels et identifie automatiquement les différences entre résultas obtenus et résultas attendus. 5.1.8 HOW - EMBARCADERO ER/studio EMBARCADERO ER/Studio est une application de modélisation des données destinée à la conception et réalisation de bases des données tant au niveau logique que physique. Entre autres ER/Studio permet la génération d’une base de donnée relationnelle à partir de sa modélisation (Diagramme E/R).

5.2 HOW – Les Outils et les Rôles FUP Pour chaque rôle de la méthodologie FUP 1.0 cette section montre la correspondance entre

-

Artefact et sa Discipline (voir aussi section WHAT)

-

Type de l’Artefact (Document, Tableau, Diagramme UML, Code, Script)

-

Outil à utiliser pour la production de l’artefact

-

Livrable associé (voir aussi section WHAT)

Mise à jour Octobre 2007

Version 0.5

Page 23/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

-

Modèle (ou « Template » du document correspondant au livrable)

-

Rapport (script de l’outil que permet d’extraire l’information nécessaire à la production du livrable)

Mise à jour Octobre 2007

Version 0.5

Page 24/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.1 HOW – Chef de Projet Discipline

Artefact

Outil

Format

Livrable

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

D2

O21 – Document de Vision

Document

L21 – Vision

D2/FUP-TPL21-D2-Vision.doc

D2

O26 – Plan Gestion des Exigences

Document

L26 – Plan gestion des Exigences

D2/FUP-TPL26-D2-Plan de gestion des exigences.doc

D4

O41 – Rapport d’Installation des Environnements

Document

L41 – Rapport d’Installation des Environnements

D4

O42 – Plan de la Qualité du Code

Document

L42 – Plan Qualité Discipline D4

D4/FUP-TPL42-D4-Plan Qualité Discipline D4.doc

D5

O51 – Critères d’Acceptation

Document

L51 – Stratégie de Tests

D5

O52 – Stratégie des Tests Déclinés

Document

D5/FUP-Stratégie de test maître.doc

Mise à jour Octobre 2007

Version 0.5

Page 25/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.2 HOW – Analyste Fonctionnel Discipline

D1 (opt.)

D1 (opt.)

D1

Artefact

Outil

O11 – Modèle des Cas d’Utilisation (UC) Métier

UML

O11.2 – Description Textuelle UC Métier

Document

O11.3 – Diagramme Séquence UC Métier

UML

O11.4 – Diagramme Activité UC Métier (opt.)

UML

O11.5 – Diagramme des Acteurs Métier

UML

UML

O12.2 – Diagrammes d’Etats des Classes Métiers

UML

CALIBER RM

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

Document, UML

O12.1 – Diagrammes des Classes Métiers

O13 – Glossaire

Octobre 2007

TOGETHER

Livrable

Document, UML

O11.1 – Diagramme des UCs Métier

O12 – Modèle du Domaine Métier

Mise à jour

TOGETHER

Format

Document

O22.1 – Diagramme des UCs Système

UML

O22.2 – Description Textuelle

Document

L23 – Spécification des Cas d’Utilisation

Version 0.5

D2/FUP-TPL23-D2Spécification cas utilisation.doc

D2/RPT23_ProjectSpecifica tionxx.tpl, D2/RPT23_PackageSpecific ationxx.tpl,

Page 26/34


FUP 1.0 Who, What, When, How

Discipline

Artefact

Outil

Format

Livrable

Support au développement support.supdev@minfin.fed.be

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

UC Système O22.3 – Diagramme Séquence UC Système

UML

O22.4 – Diagramme Activité UC Système (opt.)

UML

O22.5 – Diagramme des Acteurs Système

UML

D2/RPT23_UCSpecification xx.tpl

D2

O23 – Spécification exigences non fonctionnelles (ou supplémentaires)

CALIBER

Document

L24 – Spécification exigences non fonctionnelles

D2/FUP-RPT24-D2-Liste exigences supplémentaires.dot

D2

O24 – Liste complète des Exigences

CALIBER

Document

L25 – Liste complète des exigences

D2/FUP-RPT25-D2-Liste complète des exigences.dot

D3

O33.1 – Modèle Conceptuelle des Données

TOGETHER

Document, UML

L33 – Modèle des Données

Mise à jour Octobre 2007

Version 0.5

D3/FUP-TPL33-1-D3Modèle conceptuel des données.doc

D3/RPT33_ModeleConcept uel.tpl

Page 27/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.3 HOW – Architecte Discipline

D3

Mise à jour Octobre 2007

Artefact

O31 – Dossier Architecture Logicielle

Outil

TOGETHER

Format

Livrable

Document, UML

L31 – Dossier Architecture Logicielle

Version 0.5

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

D3/FUP-TPL31-D3-Dossier architecture logicielle.doc

Page 28/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.4 HOW – Analyste Technique Discipline

D3

Artefact

O32 – Modèle Interface Utilisateur

Outil

TOGETHER

Format

Livrable

Document, UML

L32 – Modèle Interface Utilisateur

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

D3/FUP-TPL32-D3-UIxxxDialogName.doc

D3/RPT_32_UserInterface.tpl

UML

O32.2 – Modèle Cinématique des Écrans

Tableau

O32.3 – Description des Données de l’Écrans

D3/FUP-TPL32.1-D3-UIxxxDialogName.xls

D3

O33.2 – Modèle Physique des Données

TOGETHER ou ER/STUDIO

E/R Diagram

L33 – Modèle des Données

D3

O34 – Modèle d’Analyse et Conception

TOGETHER

Document, UML

L34 – Modèle d’Analyse et Conception

Octobre 2007

Rapport

Document

O32.1 – Maquette Statique des Ecrans

Mise à jour

Modèle

O34.1 – Modèle de Conception

UML

O34.2 – Réalisation des Cas d’Utilisation

UML

Version 0.5

FUP-TPL34-D3-Modèle d'analyse et de conception.doc

Page 29/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.5 HOW - Programmeur Développement Discipline

Artefact

Outil

Format

D4

O44 – Eléments d’Implémentation

JBUILDER

Code

D4

O45 – Rapport Qualité du Code

JBUILDER

Document

O45.1 – Rapport Revue du Code O45.2 – Rapport Tests Unitaires O45.3 – Rapport de Couverture des Tests O45.4 – Rapport des Métriques

Mise à jour Octobre 2007

Livrable

L45 – Rapport de la Qualité de la Discipline D4

CHECKSTYLE, PMD

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

D4/FUP-TPL45-D4-Rapport Qualité Discipline D4.doc

JUNIT COBERTURA JBUILDER

Version 0.5

Page 30/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.6 HOW - Programmeur Opérations Disciplin e

Artefact

D4

O43 – Plan Intégration des Builds

D4

O46 – Builds des Système Exécutables

Mise à jour Octobre 2007

Outil

Format

Document

MAVEN2 ou ANT

Livrable

L43 – Plan d’Intégration des Builds

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

D4/FUP-TPL45-D4Rapport Qualité Discipline D4.doc

.Scripts, JAR, WAR, EAR

Version 0.5

Page 31/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

5.2.7 HOW - Testeur Fournisseur / Testeur SPF Disciplin e D5

Artefact

O53 – Dossiers de Tests O53.1 – Cas de Test O53.2 – Scripts de Test Automatisés

D5

O54 – Bilan de Tests O54.1 – Résultas de Tests

Outil

MERCURY QC

Format

Livrable

Document

MERCURY QC

Report

QUICKTEST,

Script

Modèle

Rapport

(FUP/FUP1.0/Modèles)

(FUP/FUP1.0/Rapports)

L52-Dossier de test

D5/FUP-TPL52-D5Dossier de test.doc

L53 – Bilan de Tests

D5/ FUP-TPL53-D5-Bilan de test.doc

Favoris de MERCURY QC <FUP - Dossier de Test v1.0>

LOAD RUNNER MERCURY QC, STARTEAM MERCURY QC

Document Report

Favoris de MERCURY QC <FUP – Bilan de Test v1.0>

Report

Filtre STARTEAM <FUP Anomalies>

QUICKTEST LOADRUNNER O54.2 – Fiche des Anomalies

Mise à jour Octobre 2007

STARTEAM

Version 0.5

Page 32/34


FUP 1.0 Who, What, When, How

Support au développement support.supdev@minfin.fed.be

ANNEXE – CORRESPONDANCES ROLES FUP ET ROLES FILIERE COBOL2JAVA Cette section est présentée pour répondre à un besoin exprimé par les responsables de l’initiative COBOL2JAVA et sur base de la documentation fourni par le représentant de l’initiative COBOL2JAVA chez SUPDEV.

Role FUP

Rôle COBOL2JAVA

Commentaires Le rôle « Chef de Projet ICT » semble être hors du scope de la filière COBOL2JAVA.

Chef de Projet ICT (CP)

Voir chapitres 2 et 3 pour un résumé de son profile et responsabilités FUP.

Analyste Fonctionnelle (AF)

Analyste

Les rôles « Analyste Fonctionnelle » du FUP et « Analyste » de COBOL2JAVA sont équivalent. Dans les deux cas il s’agit de définir toutes exigences qui doivent être pris en compte par l’application et les fonctionnalités offertes par l’application à l’aide de la modélisation UML et utilisant une démarche « Use Case centric». Pour FUP l’AF est aussi responsable de la « D1 – Modélisation Métier ». Attention à ne pas confondre l’AF avec l’ « Expert Métier » du SPF. L’AF doit savoir communiquer avec les Expert Métier du SPF Finances et savoir modéliser en UML input de ce dernier, mais il n’est pas obligatoirement un « Expert Business ».

Architecte (ARC)

Architecte

Le rôle d’Architecte corresponde bien dans FUP et COBOL2JAVA. Dans les deux cas il s’agit d’un senior expert ICT qui à une très bonne compréhension de l’environnement globale ICT du SPF Finances, qui connaît les exigences et les fonctionnalités offertes par l’application et qui, sur cette base, sait définir l’architecture de l’application, la documenter et la communiquer.

Analyste Technique (AT)

Designer

Le rôle Analyste Technique du FUP corresponde au rôle Designer de COBOL2JAVA. Dans le deux cas il s’agit de compléter l’analyse fonctionnelle sur base de l’architecture définis par l’architecte et sur base de l’expertise dans les mécanismes techniques utilisées. L’Analyste Technique du FUP est donc spécialisé, autre que en UML, dans les technologies (JSP, EJB, DB2, CCFF) sur lesquels se basent les composants dont il est responsable.

Programmeur Développement (PD)

Développeur Front Office / Développeur Back Office

Le rôle « Programmeur Développement » du FUP couvre les rôles « Développeur FO » et « Programmeur BO » de COBOL2JAVA. En effet dans FUP le PD est un terme générale qui indique le spécialiste du langage de programmation (HTML, JAVA, JSP, SQL etc.) des composants dont il est responsable sur base de l’analyse technique de ces composants fournis par l’AT. Donc en FUP le PD qui codifie l’analyse d’un composant JSP en utilisant JAVA et HTML

Mise à jour Octobre 2007

Version 0.5

Page 33/34


FUP 1.0 Who, What, When, How

Role FUP

Rôle COBOL2JAVA

Support au développement support.supdev@minfin.fed.be

Commentaires correspondra au « Dévéloppeur FO » du COBOL2JAVA. Par contre en FUP, le PD qui codifie un composant EJB en utilisant JAVA ou un interface DB en SQL correspondra au « Développeur BO». Le rôle « Programmeur Opération » semble être hors du scope de la filière COBOL2JAVA.

Programmeur Operations (PO) Testeur Fournisseur (TF) / Testeur SPF (TSPF)

Mise à jour Octobre 2007

Voir chapitres 2 et 3 pour un résumé de son profile et responsabilités FUP.

Tester

Les rôles « Testeur Fournisseur » et « Testeur SPF» du FUP correspondent au rôle «Tester » de COBOL2JAVA. La différence entre « Testeur Fournisseur » et « Testeur SPF » dans FUP est là pour rappeler que le 1ere est responsable des tests d’intégration pendant la phase de Construction de l’application alors que le 2me est responsable des tests d’acceptation lors de la phase de Transition. Les deux rôles exécute le même travail mais ont des responsabilités différentes.

Version 0.5

Page 34/34


Who, What, When, How ?  

Méthodologie FUP 1.0

Advertisement
Read more
Read more
Similar to
Popular now
Just for you