Ingnierie du Systme Logiciel Etude de cas

Christine FORCE Cdric GUITTARD

Christine.force@isima.fr

guittard.cedric@wanadoo.fr

Objectif
objectif : mettre en uvre les lments de gnie logiciel abords Cas 1 : Obtenir une base de spcification cohrente permettant un dbut danalyse La modlisation mtier La spcification par use case Lestimation de charge Cas 2 : Conception et suivi de projet Dimensionnement du projet Mise en uvre du suivi de projet
mardi 15 mars 2011 ISIMA 3

Rappel : le Processus Unifi

A c t i v i t s d u

p r o c e s s u s

Modlisation Mtier Spcification systme Analyse et Architecture Ralisation Tests Dploiement

A c t i v i t s S u p p o r t

Gestion de la configuration et du changement Gestion de projet Gestion de lenvironnement

mardi 15 mars 2011

ISIMA 3

Qui fait Quoi ?

MOA Modle mtier Les processus mtier Les concepts mtier <UML> Business Use case Squence Activit Classe <BPMN> Analyste mtier Analyste logiciel
mardi 15 mars 2011 ISIMA 3

MOA - MOE

MOE

Modle des besoins

Requirement Modle de conception Architecture Modle danalyse

Architecte / Dveloppeur 4

BPMN : Un exemple en illustration

Business Process Modeling Notation OMG Final Adopted Specification in 02/2006

BPMN1_1_Poster_EN[1].pdf

mardi 15 mars 2011

ISIMA 3

Rappel !
Le contexte, Le modle de l'entreprise, Les objets mtier, les rgles mtier, les processus mtier.

Modle de mtier

Modle de service

fusion

Modle de conception

Modle de code

Les cas dutilisation Les spcifications fonctionnelles

Modle de ressources La plate-forme (CORBA, J2EE, .Net)

Le code excutable

2003 ATLAS Nantes J. Bzivin

mardi 15 mars 2011

ISIMA 3

Les outils du BM
La description des cas dutilisation Le modle danalyse Lextension au modle mtier Business Actor Client, fournisseur Business Worker Case worker Interface Internal Worker Processus mtier (business use case)

mardi 15 mars 2011

ISIMA 3

Droulement dun cas dutilisation

Scnario : Instance dun cas dutilisation pour une chane particulire de dcision
vnement Dbut

Scnario nominal:

SUCCES

Scnario de base, amenant a un succs du cas dutilisation

Branche alternative:

SUCCES

Autre chemin amenant au mme rsultat.

Exception

Exception :

EXCEPTION

Exception pouvant se produire une tape donne dun scnario

Succs

mardi 15 mars 2011

ISIMA 3

Rgles de mise en uvre des cas dutilisation

La description des cas dutilisation comprend :

Le dbut du cas dutilisation (pr condition), La fin du cas dutilisation (post condition), Un vnement dclenchant, Linteraction entre le systme et les acteurs, Les changes dinformations (paramtres des interactions), La chronologie et lorigine des informations, Les rptitions de comportement, Les situations optionnelles et exceptionnelles (cas derreur).

mardi 15 mars 2011

ISIMA 3

Exemple: Entrer dans un btiment (1)

Primary Actor: Employee Purpose: The Employee identifies itself at security gates to enter the building Activation: Event: Use case starts when the Employee presents identification card before the gates Precondition: opening hours only ! Post-condition: the Employee is in the building Basic scenario:
1- the System reads identification cards content 2- the System verifies that the identification card content is valid and belongs to an authorized personnel of the company 3- the System opens the gates 4- once the Employee has passed through, the System closes the gates 5- The use case ends successfully
mardi 15 mars 2011 ISIMA 3

10

Exemple: Entrer dans un btiment (2)

Basic scenario:
1- the system reads identification cards content 2- the system verifies that the identification card content is valid and belongs to an authorized personnel of the company 3- the system opens the gates 4- once the employee has passed through, the system closes the gates 5- The use case ends successfully

Alternate scenario: on step 3: Employee access grant has to be

renewed
1- the System opens the gates 2- the System informs the Employee that access will not be granted next time if not renewed by company authority 2- the use case ends successfully

mardi 15 mars 2011

ISIMA 3

11

Exemple: Exemple: Entrer dans un btiment (3)

Basic scenario:
1- the system reads identification cards content 2- the system verifies that the identification card content is valid and belongs to an personnel of the company 3- the system opens the gates 4- once the employee has passed through, the system closes the gates 5- The use case ends successfully authorized

Alternate scenario: on step 3: Employee access grant has to be renewed

1- the System opens the gates 2- the System informs the Employee that access will not be granted next time if not renewed by company authority 2- the use case ends successfully

Exception scenario: on step 2: Identification card is not valid

1- the System informs the Employee that he cannot be granted access to the building 2- the System alerts Security Guard about a potential intrusion 3- the use case fails
mardi 15 mars 2011 ISIMA 3

12

Le modle dAnalyse
Le concept : Frontire / Entit / Contrleur

mardi 15 mars 2011

ISIMA 3

13

Le modle dAnalyse
Les classes de ce strotype correspondent des objets du systme qui sont sa frontire. Ces objets forment donc ses limites. Ils correspondent par nature aux interfaces avec les acteurs, quels que soient ces acteurs. Une limite peut tre dfinie pour chaque acteur.

Ces classes recouvrent les aspects contrle au sens squencement, coordination, etc. Un contrleur peut tre dfini pour chaque cas dutilisation. Il peut encapsuler le squencement des interactions entre objets danalyse (boundaries...) ou bien une logique mtier complexe.

Les objets entit sont souvent persistants. Ils existent probablement dans le modle de domaine ou mtier obtenu en expression de besoins. Les classes entity modifient ces classes de domaine indpendantes du systme pour les adapter au systme et ainsi prparer leur conception

mardi 15 mars 2011

ISIMA 3

14

Le modle dAnalyse
Les restrictions entre classes du modle danalyse

mardi 15 mars 2011

ISIMA 3

15

A vous maintenant
Quel est le modle mtier dun garage automobile ? La dmarche ?
class Frameworks

Identifier et dcrire les entits mtier

ActivityInitial

Identifier les acteurs et les processus mtier Dcrire les processus mtier

Consolider ActivityFinal

mardi 15 mars 2011

ISIMA 3

16

Les acteurs et processus mtier

Document Microsoft Office Word 97 - 2003

mardi 15 mars 2011

17

Dcrire les entits mtiers

mardi 15 mars 2011

ISIMA 3

18

Dcrire les entits mtiers

mardi 15 mars 2011

ISIMA 3

19

Dcrire les entits mtiers

mardi 15 mars 2011

ISIMA 3

20

Dcrire le processus mtier

mardi 15 mars 2011

ISIMA 3

21

Le passage au spcification

uc Primary Use Cases Poste de travail Chef Atelier

Grer les RDV Clients

Chef d'Atelier

Etablir un dev is

mardi 15 mars 2011

ISIMA 3

22

Liens avec la modlisation mtier et SysML

Les actions des processus mtier deviennent des cas dutilisation candidats Les Workers mtier concerns par ces actions deviennent les acteurs du systme Utiliser UML pour la modlisation mtier permet une continuit entre les phases Utiliser SysML permet en plus dintgrer les exigences, de les allouer des blocs et de faciliter leur traabilits . mais le modle devient vite illisible et complexe Objectif : Fusionner UML / SysML avec un outils de gestion des exigences textuelles, avec 23 lien par rfrence mardi 15 mars 2011 ISIMA 3

Estimation des charges lors de ltude dopportunit

Objectif : calibrer la complexit du projet

Estimation projet Moyen < Grand > 240j 240J Le domaine cible 1 ou 2 3 -5 +5 <3 3-5 +5 <5 3-10 +10 1 ou 2 3-5 +5 Taille du domaine cible <5 5 -10 +10 1 ou 2 <10 +10 Qualit Faible Modr fort Technologie Ergonomie Mixte Ergonomie connue connue Petit <60j

Business Use case Interfaces avec dautres systmes Concepts importants Algorithmes Acteurs /services utilisateurs Sites Niveau dexigence Nouvelle techno

mardi 15 mars 2011

ISIMA 3

24

Quelques mtriques de calibration de projet

Calibrage Spcification :
Interview / enqute Architecture fonctionnelle Conception IHM Interfaces Systme Rdaction du dossier 1 3 jours par utilisateurs 5-20 jours selon la taille du projet 1.5 jours / cran 3 jours par systme 5-20 jours

Calibrage Conception :
Conception architecture technique
o Rcurrente o Innovante <20 jours (adaptation) 60-200 jours 2-8 jours 1-3 jours 1 jour / table 20-100 jours

Conception architecture applicative

o o o o Use case IHM BDD Prototype

Calibrage ralisation
Exploitation Plateforme IHM Impression Architecture technique charge fixe de 10 50 jours 1 3 jours par cran 2 5 jours par ditions 20 100 jours

mardi 15 mars 2011

ISIMA 3

25

Estimation des charges

MTHODE DES POINTS DE FONCTIONS II [Albrecht - Gaffney - Simons] Simons] MARK

La spcifications des exigences :

Analyser le domaine dapplication, valuer les lments prendre en compte,

Des hypothses sur la complexit :

Dterminer le niveau de complexit de chaque lment, Dterminer les facteurs externes (globaux, propres lapplication)
PF = (

nombre x poids) x Facteur Multiplicatif

(complexit)
mardi 15 mars 2011 ISIMA 3

26

Estimation des charges

MTHODE DES POINTS DE FONCTIONS Avantages
Bases sur la dfinition des besoins. Peuvent tre appliques assez tt dans le processus de dveloppement. Estimation fonde sur les entres/sorties et non sur la dcomposition modulaire.

Inconvnients
valuation base sur des donnes subjectives. Coefficients calculs pour des application de type SI. Les coefficients doivent tre rvalus pour chaque entreprise et peuvent varier au cours du temps. Il faut traduire le nombre de points de fonctions en terme d'effort.
mardi 15 mars 2011 ISIMA 3

27

Estimation des charges

Pondrer les acteurs
Simple (poids1) : un autre systme muni d'une API dfinie, Moyen (poids 2) : un autre systme qui communique via un protocole, ou une personne qui communique via une interface de type texte, Complexe (poids 3) : une personne qui interagit avec une interface graphique.

Pondrer les cas d'utilisation

Simple (poids 5) : trois transactions ou moins ou 5 classes d'analyse ou moins, Moyen (poids 10) : 4 7 transactions ou 5 10 classes, Complexe (poids 15) plus de 7 transactions ou plus de 10 classes.

UUCP
28

mardi 15 mars 2011

ISIMA 3

USE CASE POINTS

Tfactor = notes x poids TCF=0.6+0.01xTFactor

Poids 2 1 1 1 1 0.5 0.5 2 1 1 1 1 1

N de Facteur T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13

Description Systme distribu Exg de performance en tps de rponse ou dbit Interactif Traitement interne complexe Code rutilisable Facile installer Facile utiliser Portable Facile modifier Concurrent Scurit particulire Accs distant Facilit de formation des utilisateurs

mardi 15 mars 2011

ISIMA 3

29

USE CASE POINTS

CALCUL DE EF FACTOR) FACTOR)
N de Fact F1 F2 F3 F4 F5 F6 F7 F8 Description Familier avec UML/UP Exprience sur le type d'application Exprience en dveloppement objet Capacit en analyse Motivation Exigences stables Temps partiels Langage de programmation difficile

(ENVIRONMENTAL

Poids 1.5 0.5 1 0.5 1 2 -1 -1

Efactor =

notes x poids

UCP = UUCP x TCF x EF 20 Personnes/heure par UCP

mardi 15 mars 2011 ISIMA 3

EF = 1.4 - 0.03 x EFactor

30

La rpartition de leffort

Toutes les activits techniques sont elle prsentes ? Et les activits transverses telle que GDP & AQ ?
mardi 15 mars 2011 ISIMA 3

31

Mais en pratique comment faire ?

Discipline Spcification / analyse Architecture / design Codage Validation (TU, TI, VA) Livraison et recette Documentation Total ralisation Gestion projet Gestion de conf. / gestion du changement Qualit Total management Charges 12.65 12.65 37.95 16.87 1.69 2.53 84.33 8.43 4.22 2.53 15.18 % 15% 15% 45% 20% 2% 3% 100% 10% 5% 3% 18%

10 40 % 10 40 % Doc externe type MUT 10 20 % selon client 2 10 %

Les ratios utiliss dpendent de la nature du projet, du niveau de qualit attendue sur le projet, du niveau de couverture des tests , du retour dexprience capitalise de lentreprise (expertise)

mardi 15 mars 2011

ISIMA 3

32

Une estimation TMA . Cest Quoi ?

Notion de type de Mission
AT : Assistance Technique Engagement de moyen FO : Ralisation FOrfaitaire Engagement de rsultat TMA : Tierce Maintenance Applicative Engagement de long terme ayant pour objet de maintenir en conditions oprationnelles un ensemble de systmes logiciels selon un niveau de service prdfini Et les plateaux externaliss Puis les plateformes Off-Shore, Sea Shore .

mardi 15 mars 2011

ISIMA 3

33

Dcoupage en Unit uvre Units duvres (1/3)

Audit
Prciser le contexte et les objectifs Etat des lieux de la V3 Plan Qualit Environnement Suivi Modliser les processus et objets mtier Audit site pilote Spec. fonctionnelle Spec. IHM

T1 Prise en main

T2 Mise en place

T6 Modlisation mtier T6 Analyse fonctionnelle T6 Exigences techniques T7 Analyse technique

Plan de validation

Interfaces Infrastructures

Audit du socle technique, propositions damlioration Axes damlioration pour larchitecture logicielle Conception de larchitecture logicielle Design, Codage & tests, Intgration Dploiement

T6 Architecture

T6 Ralisation

T10 Rversibilit

Documentation Transfert

34 34

Une estimation TMA

Description des units d'uvre
Catgorie Audit T1 Prise en main T2 Mise en place Domaine Prciser le contexte et les objectifs Etat des lieux V3 Plan Qualit Environnement Suivi + de 10 activits + de 3 acteurs 5 10 activits 2 3 acteurs 1 5 activits 1 2 acteurs Typologie Caractristation

Estimation
Charge hj 2 5 5 Nombre 1 1 1

Processus complexe

15

T6 Modlisation mtier

Modliser les processus et les objets mtier

Processus moyen

Processus simple

Audit site pilote

Audit

Interview utilisateur vigilance (identification des volutions et limitations du systme) Analyse et rdaction de rapport

Cas d'utilisation complexe

+ de 4 acteurs + 5 scnarios +de 8 interactions 2 4 acteurs 2 5 scnarios 4 8 interactions 1 2 acteurs 1 2 scnarios 1 4 interactions + de 4 zones +de 7 actions lments graphiques 2 4 zones 3 7 actions 1 zone 1 3 actions

Spcification fonctionnelle T6 Analyse fonctionnelle (expression du besoin)

Cas d'utilisation moyen

Cas d'utilisation simple

Interface complexe

Spcification IHM

Interface moyenne

Interface simple

mardi 15 mars 2011

ISIMA 3

35

Une estimation TMA

Catgorie Domaine Typologie Interface complexe Description des interfaces T6 Exigences techniques Description du socle technique Audit socle technique Interface moyenne Interface simple Infrastructures Etudes et prospectives Caractristation Support "fichier" Support donnes relationnelles (SQL, XML,) Accs API Nuds de dploiement et logiciel de base Analyse + rapport Charge hj 4 2 1 1 5 Nombre 2 2 3 1 1

T7 Analyse technique

Propositions damlioration du socle technique

Etudes et prospectives

Analyse + rapport

Axes damlioration pour larchitecture logicielle Dfinition et mise en place du framework T6 Architecture Modlisation de la ralisation des cas d'utilisation

Etudes et prospectives Framework spcifique Framework standard Cas d'utilisation complexe Cas d'utilisation moyen Cas d'utilisation simple Composant complexe

Analyse + rapport Conception de framework Mise en uvre cf. Spcification fonctionnelle cf. Spcification fonctionnelle cf. Spcification fonctionnelle cf. Codage et test unitaire cf. Codage et test unitaire cf. Codage et test unitaire + de 3 interfaces structure complexe + de 5 contrleurs 2 3 interfaces structure complexit moyenne 3 5 contrleurs 1 interface structure simple 1 2 contrleurs cf. Codage et test unitaire cf. Codage et test unitaire cf. Codage et test unitaire

10 5 2 4 2 1 3 2 1 9

1 1 1 3 6 3 5 12 8 5

Design dtaill (interne composant)

Composant moyen Composant simple Composant complexe

T6 Ralisation d'un composant

Codage & test unitaire (interne composant)

Composant moyen

12

Composant simple Composant complexe Intgration de composant au sein de l'architecture Composant moyen Composant simple

3 2 1 0.5

8 5 12 8

mardi 15 mars 2011

ISIMA 3

36

Une estimation TMA

Description des units d'uvre

Plan de validation Dossier de validation (cas de test associs aux cas d'utilisation) Dossier de recette Validation oprationnelle Mise en production Stratgie de test Cas d'utilisation complexe Cas d'utilisation moyen Cas d'utilisation simple Recette usine Vrification d'aptitude Dploiement Fait technique complexe T6 Dploiement Support VSR Fait technique moyen T6 Validation cf. Spcification fonctionnelle cf. Spcification fonctionnelle cf. Spcification fonctionnelle Fiches de test Scnarios de test Plate-forme d'intgration + de 5 composants composants complexes 3 5 composants composants moyens 1 2 composants composants simples Guide d'utilisation Conseils d'utilisation Procdures d'exploitation

Estimation
2 4 2 1 3 5 1 3 6 3 1 1 1 5

Fait technique simple Manuel d'utilisation Documentation T10 Rversibilit Notice utilisateur Manuel d'exploitation

1 5 1 2 1 3 1

Plan de transfert

Transfert de connaissance

Plan de formation

mardi 15 mars 2011

ISIMA 3

37

Aprs lestimation la ralisation

La phase de lancement
ACTIVITES_LANCEMENT.pdf

La phase de ralisation La phase de terminaison Les supports

Feuille Microsoft Office Excel 97-2003

ACTIVITES_REALISATION.pdf

ACTIVITES_TERMINAISON.pdf

Feuille Microsoft Office Excel 97-2003

mardi 15 mars 2011

ISIMA 3

38