1

LE PROJET

eBill

2

Préface

L’avancement technologique du 20ième siècle est en train de prendre une grande partie du marché informatique. Nos comptes en banque se gèrent par ordinateur, on informatise toutes les données des clients afin de conserver une base de données sur leurs états et tout le monde se retrouve avec des cartes magnétiques qui facilitent leur vie. Or, un problème semble ne pas vouloir disparaître : Les factures. Combien de fois nous sommes nous retrouvez dans cette situation? Le consommateur achète un article chez un détaillant. On lui remet une facture qu’il conserve précieusement. Quelques temps plus tard, le consommateur désire retourner l’article. Évidemment, la première chose qu’il doit retrouver est sa facture d’achat. Malheureusement, le client ne retrouve plus la facture ou bien ne l’a pas conservée. Le consommateur se retrouve ainsi dans une impasse.

3

Table des matières

Index des figures ................................................................................................4 1. Synoptique ......................................................................................................5

1.1. Besoins.......................................................................................................6 1.1.1. Général ................................................................................................6 1.1.2. Enregistrement des clients...................................................................7 1.1.3. Description de la carte .........................................................................7 1.1.4. Description du système........................................................................7 1.1.5. Contraintes du système .......................................................................8

2. Références.......................................................................................................8 3. Définitions .......................................................................................................8 4. Organisation du projet ...................................................................................8

4.1. Structures externes ....................................................................................8 4.2. Structures internes .....................................................................................9 4.3. Rôles et responsabilités .............................................................................9 4.4. Analyse du risque.......................................................................................9

5. Plans du processus de gestion ...................................................................11 5.1. Énumération des activités (WBS).............................................................11 5.2. Planification – ordonnancement ...............................................................12 5.3. Estimation des ressources .......................................................................14

5.3.1. Pourquoi fait-on des estimations?....................................................14 5.3.2. Points de fonction (la première méthode) ..........................................15 5.3.3. Deuxième méthode pour trouver les PF ............................................22

5.3.3.1. Identification des processus et qualité de la documentation .................................................22 5.3.3.2. Identification des groupes de données ...................................................................................23 5.3.3.3. Dénombrement des points de fonctions .................................................................................24

5.3.4. Type du projet....................................................................................27 5.3.5. Estimation avec méthode COCOMO .................................................27 5.3.6. Estimation avec méthode des trois valeurs........................................30

6. Planification de la qualité .............................................................................33 6.1 Qualités attendues d’un logiciel.................................................................33 6.2 Contrôle de progrès...................................................................................34

Réunion : 1 ..................................................................................................35 Réunion : 2 ..................................................................................................36 Réunion : 3 ..................................................................................................37 Réunion : 4 ..................................................................................................38 Réunion : 5 ..................................................................................................39 Réunion : 6 ..................................................................................................40 Réunion : 7 ..................................................................................................41 Réunion : 8 (dernière avant la présentation)................................................42

6.3. Contrôle du budget...................................................................................43 6.4. Contrôle de la qualité ...............................................................................44 6.5. Gestion de crises :....................................................................................46 6.6. Organisation de la maintenance :.............................................................47 7. Conclusion :.................................................................................................51

Annexe...............................................................................................................51

4

Index des tables Table 1: Identification des risques.......................................................................10 Table 2: Points de fonctions................................................................................16 Table 3: Dépôts internes.....................................................................................16 Table 4: Intrants ..................................................................................................17 Table 5: Extrants.................................................................................................18 Table 6: Interrogations ........................................................................................18 Table 7: Grille de calcul des points de fonctions:................................................19 Table 8: Évaluation des facteurs d’ajustement ...................................................19 Table 9: Processus du système..........................................................................22 Table 10: Groupe de données ............................................................................23 Table 11: Identification des sous processus .......................................................26 Table 12: Table d'ajustement des points de fonctions ........................................30 Table 13: tableau des controles des risques.......................................................32

Index des figures Figure 1: WBS du projet eBill généré par les logiciels Microsoft Project 2003 et Critical Tools WBS ChartPro 4.4.........................................................................11 Figure 2: Diagramme PERT du projet eBill généré par les logiciels Microsoft Project 2003 et Critical Tools PERT Expert 2.2 ..................................................12 Figure 3: Tableau Gantt avec les horaires et les ressources requises................13 Figure 4: Calendrier des réunions du groupe......................................................34

5

1. Synoptique 1.0. Introduction

Projet eBILL

Notre Client : Association Interac

La compagnie Interac désire offrir un système à tous les commerces aux détails qui utilisent et/ou effectuent des transactions avec leurs clients et remettent une facture aux clients comme preuve d’achat. Ce système, par l’entremise d’une carte magnétique, permet au consommateur de consulter son dossier de factures soit par Internet

But : Permettre aux consommateurs de ne plus conserver leurs factures papier lors d’un achat.

Notre Compagnie : BLEM Informatique Inc.

• Fondée à Montréal en 2004 par des nouveaux finissants • 4 fondateurs

o Daniel Brami bramidan@iro.umontreal.ca o Mehdi El Moutaouakkil elmoutam@iro.umontreal.ca o Lulzim Laloshi laloshil@iro.umontreal.ca o Eric Mechaly mechalye@iro.umontreal.ca

• Budget: 200 000$ Nous sommes une PME qui a pour objectif de fournir des solutions informatiques de façon contractuelle.

Échéance : 1er avril 2005 Structure externe: Par projet

Structure interne: Egoless.

6

1.1. Besoins

1.1.1. Général

L’Association Interac est l’organisme responsable de la mise au point et de l’exploitation du réseau national de deux services financiers électroniques : le retrait en mode partagé dans les guichets automatiques et le Paiement direct Interac, le service national canadien de débit. L’Association connecte les Canadiens à leur argent depuis plus de quinze ans et les services partagés InteracMD continuent à avoir un impact sur la vie des Canadiens de tout le pays à chaque minute de chaque jour. À présent, l’association Interac a fait appelle à la compagnie BLEM Inc. pour créer un nouveau système, relié à l’existant, pour que les clients utilisent une nouvelle carte magnétique lors de leurs achats et cela pour ne plus conserver leurs factures. BLEM inc. est une compagnie qui a été fondée en 2004 par quatre finissants au baccalauréat en informatique qui ont déjà développé des petits logiciels pour d’autres compagnies. Le chef de projet du logiciel, ayant dirigé plusieurs projets antérieurs pour différentes entreprises et ayant plein pouvoir pour le projet de l’association Interac, a décidé de mettre en place un comité réduit de gestion de projet.

7

1.1.2. Enregistrement des clients

Cette nouvelle carte permet aux consommateurs de ne plus conserver leurs factures et en cas de remboursement ils doivent juste la présenter aux magasins. Il y a trois manières pour acquérir la carte :

• Dans un point de vente (lors des périodes promotionnelles). • Par Internet. • Dans la banque du client.

Dans les trois cas il faut remplir un formulaire qui contient le nom, l’adresse et l’ID du client, puis le client reçoit sa carte par la poste après quelques jours.

1.1.3. Description de la carte

À la réception de la carte, le client peut modifier ses informations dans un point de vente, par Internet ou dans sa banque. Ainsi, il pourra se retirer du système, supprimer les achats fait dans un magasin, supprimer des factures ou les archiver. Cependant il peut seulement rechercher, créer une liste ou imprimer des factures par Internet ou dans sa banque.

1.1.4. Description du système

Pour chaque carte, le système contient le « ID » du client – lié à son compte de débit, son nom et son adresse. Et pour chaque client, le système contient les informations suivantes :

• Pour un magasin : � L’ID � Le nom � L’adresse � Le numéro de téléphone

• Pour une facture : � L’ID � Le montant � Le nom du magasin � Le nom du client � La date � La durée de la garantie

8

1.1.5. Contraintes du système

Afin de minimiser la réticence immédiate sur l’adoption du produit, Interac désire pouvoir utiliser le système eBill avec le « hardware » déjà en place.

2. Références

3. Définitions • BLEM ou blem : Nous désignons par « Blem » le nom donné à notre

association composée de quatre membres. • eBill : le produit développé par BLEM afin de répondre à l’offre émise par

Interac.

4. Organisation du projet

4.1. Structures externes Nous avons choisis la structure « par projet » car nous estimons que c’est la structure qui nous convient et qui nous ressemble le plus. Les ressources diverses sont rassemblées uniquement pour la complétion de ce projet en particulier – la structure de travail doit donc être particulièrement adaptée à ce projet. Aucun membre de notre groupe n’est particulièrement spécialisé dans un domaine particulier. Nous travaillerons tous à temps pleins afin de compléter les différentes taches identifiées. Les décisions sont prises de façon rapide, sans revues de conseils d’administration, commissions d’enquêtes etc. Cette structure encourage la motivation accrue de notre personnel, étant donné que le capital nécessaire pour faire démarrer notre entreprise vient en partie de notre poche. La dernière raison qui nous a poussé à choisir cette forme est la pleine responsabilité donnée au chef de projet (voir structures internes)

9

4.2. Structures internes

4.3. Rôles et responsabilités

Liste du personnel: Analystes : Luzim Laloshi, Eric Mechaly Concepteur : Daniel Brami Programmeur / Testeur: Mehdi el Moutaouakkil

4.4. Analyse du risque

Risque Impact Probabilité Justification

Calendrier

2 50%

Il n'y a pas de contraintes de temps due à un évènement quelconque

Budget optimiste

3 80%

Pour le moment, 200 K$ sont suffisant pour 4 développeurs et 6 mois

Manque d'expérience du personnel 4 90%

Nous n'avons jamais travaillés sur un tel projet avec de tels enjeux

Chef de projet inexpérimenté 3 70%

Chef de projet a autant d'expérience que les autres

Changement continuel des 2 60%

Produit n'a qu'une seule utilité via deux interfaces

Nous avons choisis la structure de « egoless programming team ». Étant donné que l’on investit tous le même montant de capital et que nous avons tous à peu près le même niveau d’expérience en matière de gestion de projet, les décisions et les réalisations sont communes (« aussi appelé démocratique décentralisé »).

10

Risque Impact Probabilité Justification

spécifications distincts

Absence de soutien 1 30%

C'est l'idée d'Interac!

Perte de personnel

3 20%

Un investissement initial de chaque fondateur l'empêchera

Changement de matériel / technologie

4 10%

Si par exemple Interac Utilise des cartes a puces, tout change mais puisque leurs idée, c'est peu probable qu'arrivera dans futur proche

Table 1: Identification des risques

11

5. Plan

s du

pro

cessus d

e gestio

n

5.1. Énum

ération des activités (WB

S)

Nous avons énum

éré toutes les activités, par niveau hiérarchique de détail, qui organ

ise le travail à faire en activités courtes,

gérables, ayant des entrées et des orties spécifiées. Ceci s’appel un W

BS

ou « Work B

reakdown S

tructure ». N

otre WB

S est représenté par la figu

re 1.

F

igu

re 1: WB

S d

u p

rojet eB

ill gén

éré par les lo

giciels M

icroso

ft Pro

ject 2003 et Critical T

oo

ls WB

S C

hartP

ro 4.4

12

5.2. Planification – ordonnancem

ent

F

igu

re 2: Diag

ramm

e PE

RT

du

pro

jet eBill g

énéré p

ar les log

iciels Micro

soft P

roject 2003 et C

ritical To

ols P

ER

T E

xpert 2.2

Ci haut se trouve le diagram

me P

ER

T qui représente la séquence d’activité à suivre afin de com

pléter le projet. Les valeurs

optimistes se trouvent dans la partie gauche de chaque case et les valeurs pessim

istes se trouvent dans la partie droite de

chaque case. La rangée du haut identifie le g

enre ou le thème de l’activité à effectuer.

La page suivante contient le diagramm

e de Gantt généré à l’a

ide de Microsoft P

roje

ct 2

003. C

’est une représentation visuelle du

cheminem

ent du projet à travers ces différentes étapes. V

oir l’annexe

pour des

versions plus

lisibles

des diagram

mes

PE

RT

et

les G

antt optim

istes, attendus

et pessim

istes.

Légende :

13

F

igu

re 3: Tab

leau G

antt avec les h

oraires et les resso

urces req

uises

14

5.3. Estimation des ressources

5.3.1. Pourquoi fait-on des estimations?

Nous avons utiliser deux méthodes différent pour calculer les point de fonction de notre système pour avoir une meilleur estimation des coûts, du personnel et du calendrier durant différent phase de développement : la première méthodes c’est celle utiliser en classe et la deuxième la méthode d’évaluation de la qualité de la documentation selon la norme ISO 19761 (COSMIC-FFP).

Soumission

Pour être compétitif

Évaluation

Déterminer si une tendance est réaliste en terme de coûts et de calendrier de réalisation.

Planification

Déterminer les besoin en personnel durant les différent phase de développement

Contrôle

Permettre le suivie le contrôler les coûts

15

5.3.2. Points de fonction (la première méthode)

Modules Sous modules Fonctionnalités Gestion des clients • Créer client

• Modifier client • Supprimer client

Gestion des magasins • Créer magasin • Modifier magasin • Supprimer magasin

Gestion dans le point de vente

Gestion des factures • Créer facture • Supprimer facture • Archiver facture

Gestion des clients • Créer client • Modifier client • Supprimer client

Gestion des magasins • Créer magasin • Modifier magasin • Supprimer magasin

Gestion depuis le site web

Gestion des factures • Créer facture • Supprimer facture • Imprimer facture • Archiver facture • Rechercher une facture • Créer rapport de factures

(liste de factures) • Imprimer rapport de

factures (liste de factures) • Imprimer la liste des

magasins pendant une période donnée

• Imprimer la liste de tous les magasins

Gestion des clients • Créer client • Modifier client • Supprimer client

Gestion depuis l’application de la banque

Gestion des magasins • Créer magasin • Modifier magasin • Supprimer magasin

16

Gestion des factures • Créer facture • Supprimer facture • Archiver facture • Rechercher une facture • Créer rapport de factures

(liste de factures) • Imprimer rapport de

factures (liste de factures) • Imprimer la liste des

magasins pendant une période donnée

• Imprimer la liste de tous les magasins

Table 2: Points de fonctions

Table 3: Dépôts internes

Entité Attributs Complexité Valeur Client IdClient

nomClient adresseClient (op)

Simple 7

Magasin IdMagasin nomMagasin adresseMagasin numeroTelephon

Simple 7

Facture IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Simple 7

17

Table 4: Intrants

Entité Attribut Dépôt_references

complexité Valeur

Créer client IdClient nomClient adresseClient

Client 1

Simple 3

Modifier client

IdClient nomClient adresseClient

Client 1

Simple 3

Client

Supprimer client

IdClient nomClient adresseClient

Client 1

Simple 3

Créer magasin

IdMagasin nomMagasin adresseMagasin numeroTelephon

Magasin 1

Simple 3

Modifier magasin

IdMagasin nomMagasin adresseMagasin numeroTelephon

Magasin 1

Simple 3

Magasin

Supprimer magasin

IdMagasin nomMagasin adresseMagasin numero_Tel

Magasin 1

Simple 3

Créer facture

IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture Client Magasin 3

Complexe

6 Supprimer facture

IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture Client Magasin 3

Complexe

6

Facture

Archiver facture

IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture Client Magasin 3

Complexe 6

18

Table 5: Extrants

Attribut Dépôt_references

complexité Valeur

Imprimer facture

IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture Client Magasin 3

Moyenne

5 Imprimer rapport de

factures IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture Client Magasin 3

Moyenne

5 Imprimer la liste

des magasins pendant une période donnée

IdMagasin nomMagasin adresseMagasin numero_Tel

Magasin 1

Simple 4

Imprimer la liste de tous les magasins

IdMagasin nomMagasin adresseMagasin numero_Tel

Magasin 1

Simple 4

Table 6: Interrogations

Attribut Dépôt_references

complexité Valeur

Rechercher une facture

En entre : IdFacture En Sortie : IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Facture 1

Simple 1

3

19

Créer rapport de factures (liste de factures

En entre : idClient En Sortie : IdFacture Montant nomMagasin nomClient dateAchat dure_Garantie

Client Facture 2

Simple 1

3

Les points de fonction non ajustés sont calculés avec la grille suivante : Table 7: Grille de calcul des points de fonctions:

Complexité Composants Simple Moyenne Complexe Totale Dépôts internes 7*3 0 0 21 Dépôts internes 0 0 0 0 Intrants 6*3 0 3*6 36 Extrants 2*4 2*5 0 18 Interrogations 2*3 0 0 6 Nombre Totales 81

Table 8: Évaluation des facteurs d’ajustement

Facteur Degré d`influence

Justification

Télécommunication

3

Le programme permet la saisie en direct des données ou sert de soutien au télétraitement (front-end) et à un traitement différé ou constitue un système d’interrogation

Traitement distribué

4

Les traitements distribués et le transfert des données sont en direct dans les deux sens

Performance

3

Le temps de réponse est critique toute la journée. Aucune conception spéciale n’est requise pour l’utilisation du CPU. L’heure limite de traitement, permettant de satisfaire les systèmes connexes, est une contrainte

20

Charge de l’équipement

3

Le processeur impose des contraintes particulières pour certaines composantes du programme

Taux de transaction Saisie des données en direct

4

Les taux élevés de transactions décrits par les utilisateurs dans les spécifications du programme ou les ententes de niveau de service sont suffisants pour justifier une analyse des performances dans la phase de conception

Convivialité

3

Six catégories ou plus s’appliquent, mais il n’y a aucun besoin relié spécifiquement à l’efficacité

Mise à jour en direct

5

Mise à jour en direct des principaux dépôts internes. En plus des mises à jour en direct, la protection contre les pertes de transaction est essentielle et incluse dans le programme. De plus, 7 des volumes élevés de transactions entraînent des considérations de coûts dans le processus de récupération, car l’hôtel compte 2000 chambres

Complexité de traitement

1

Traitement par exception, résultant en transactions incomplètes devant être traitées de nouveau

Réutilisation

4

Le programme a été spécifiquement conçu et documenté pour faciliter sa réutilisation et est adapté aux besoins spécifiques des utilisateurs au niveau du code source

21

Facilité d’installation

5

Aucune spécification n’a été précisée, cependant, le logiciel sera installé sur différents postes et doit assurer la conversation des données existantes aussi nous considérons que les utilisateurs ont émis des spécifications de conversion et d’installation et que les procédures d’installation et de conversion doivent être automatisées

Utilisabilité

2

Des procédures efficaces de démarrage, de sauvegarde et de récupération sont mises en place mais elles ne nécessitent aucune intervention

Sites multiples

2

Les besoins d’opération sur plusieurs sites ont été pris en considération et le programme a été conçu pour être utilisé dans des environnements indiqués

Changeabilité

1

Aucune considération spéciale n’a été formulée par les utilisateurs relativement à la conception d’un programme permettant de minimiser ou de faciliter les modifications

Saisie des données en direct

5

Plus de 30 % des transactions sont entrées en mode interactif (en faite, toutes les transactions sont en directes)

Nombre Totales

45

22

Calcul du nombre de points de fonction ajusté VAF = DTI ��0,01 + 0,65 VAF = 45 * 0,01 + 0,65 = 1.10 PFA = PF x VAF PFA = 81 x 1.10

= 89.1

5.3.3. Deuxième méthode pour trouver les PF

5.3.3.1. Identification des processus et qualité de la documentation Le tableau présenté ci-dessous présente tous les processus identifiés dans la documentation des besoins. Chacun des processus reconnus a été évalué selon les catégories étudiées, afin de se soumettre à la méthode d’évaluation de la qualité de la documentation selon la norme ISO 19761 (COSMIC-FFP). Les catégories sont évidemment définies, à titre de rappel, dans la légende qui accompagne le tableau des résultats.

Table 9: Processus du système

No Pr. ID Process Description Qualité

1

PR001 Créer client B

2 PR002 Modifier client B

3 PR003 Supprimer client B

4 PR004 Créer magasin B

5 PR005 Modifier magasin B

6 PR006 Supprimer magasin B

7 PR007 Créer facture B

8 PR008 Supprimer facture B

9 PR009 Archiver facture B

10 PR010 Imprimer facture B

11 PR011 Rechercher une facture B

12 PR012 Créer rapport de factures (liste de factures) B

13 PR013 Imprimer rapport de factures (liste de factures) B

14 PR014 Imprimer la liste des magasins pendant une période donnée B

15 PR015 Imprimer la liste de tous les magasins B

Légende: Qualité de la documentation

A Le processus est documenté complètement B Le processus est seulement mentionné mais pas documenté C Le nombre de processus est identifié D Le mesureur identifie un processus implicite

23

5.3.3.2. Identification des groupes de données Suite a l’identification des processus, des groupes de données ont été identifiés afin de facilité la division des processus en sous processus. Conceptuels ou réels, ces groupes de données représentent tous des objets d’intérêt du point de vue fonctionnels de l’utilisateur qui sont requis pour la manipulation des données. Voici un tableau résumant les groupes de données extraits de la documentation.

Table 10: Groupe de données

No Groupe de données

1 Client 2 nom Client 3 adresse Client 4 idMagasin 5 nom Magasin 6 adresse Magasin 7 numeroTelephon 8 IdFacture 9 Montant 10 nomMagasin 11 dateAchat 12 dure_Garantie

24

5.3.3.3. Dénom

brement des points de fonctions

Suite à l’identification des processus et des groupes de données, l’identification des sous processus fut nécessaire pour u

n

dénombrem

ent efficace des points de fonction. Chacun des processus étudié a été décom

posé en de simples m

ouvements de

données CO

SM

IC-F

FP

. En effet, le tableau ci-dessous présente chacun des processus décom

posé en sous processus, et chacun de ceux-ci ont été relié a un groupe de donnée et identifié selon un type de donné tel entré, sortie, lecture ou écriture. C

ette méthodologie perm

et de valider que chacun des sous processus ne déplace seulem

ent qu’un groupe de données. No Pr. I

D

Process Descrip

tion

Sub-Process Descrip

tion

Data Group

TP

FFP

Somme

1

PR001

Créer client

Créer id_C

lient S

aisir nomC

lient É

crire nomC

lient S

aisir adresseClient

Écrire adresseC

lient

Id_Client

nomClient

nomClient

adresseClient

adresseClient

W

E

W

E

W

1

1

1

5

5

13

2

PR002

Modifier client

Saisir id

_Client

Faire

la m

odific

ation

Id _Client

nomClient o

u adresse

R

W

1

1

2

3

PR003

Supprim

er client Saisir id

_Client

Supprim

er monC

lient S

upprimer adresseC

lent S

upprimer Id_C

lient

Id_Client

nomClient

adresseClient

E

W

W

W

1

1

5

1

8

4

PR004

Créer m

agasin

Créer id_M

agasin S

aisir nomM

agasin É

crire nomM

agasin S

aisir adresseMagasint

Écrire adresseM

agasin S

aisir numeroT

el É

crire numeroT

el

IdMagasin

nomMagasin

adresseMagasin

numeroTelephon

W

E

W

E

W

E

W

1

1

1

5

5

1

1

15

5

PR005

Modifier m

agasin

Saisir id

_Magasin

Faire

la m

odific

ation

IdMagasin

nomMagasin

(ou)

adresseMagasin

(ou)

numeroTelephon

E

W

1

5

6

25

6

PR006 S

upprimer m

agasin

Saisir id

_Magasin

S

upprimer m

onMagasin

S

upprimer adresseM

agasin S

upprimer num

eroTel

Supprim

er Id_Magasin

IdMagasin

nomMagasin

adresseMagasin

numeroTelephon

E

W

W

W

W

1

1

5

1

1

9

7

PR007

Créer facture

Créer id_F

acture S

aisir Montant

Écrire M

ontant S

aisir nomM

agasin É

crire Nom

Magasin

Saisir nom

Client

Ecrire nom

Client

Saisir dateA

chat E

crire dateAchat

Saise dure_G

arantie E

crire dure_Garantie

IdFacture

Montant

nomMagasin

nomClient

dateAchat

dure_Garantie

W

E

W

E

W

E

W

E

W

E

W

1

1

1

1

1

1

1

1

1

1

1

11

8

PR008

Supprim

er facture

Saisir Id

_Magasin

Supprim

er M

ontant

Supprim

er monM

agasin S

upprimer m

onClient

Supprim

er dateAchat

Supprim

er dure_Garantie

Supprim

er Id_Facture

IdFacture

Montant

nomMagasin

nomClient

dateAchat

dure_Garantie

E

W

W

W

W

W

W

1

1

1

1

1

1

1

7

9

PR009

Archiver facture

S

asir id_Facture

Écrire M

ontant É

crire Nom

Magasin

Ecrire nom

Client

Ecrire dateA

chat E

crire dure_Garantie

IdFacture

Montant

nomMagasin

nomClient

dateAchat

dure_Garantie

E

W

W

W

W

W

1

1

1

1

1

1

6

10

PR010

Imprim

er la liste des m

agasins pendant une période donnée

Sasir date début

Sasir date fin

nomMagasin

X

1

1

26

11

PR011 Im

primer facture

S

asir id_Facture

Écrire M

ontant É

crire Nom

Magasin

Ecrire nom

Client

Ecrire dateA

chat E

crire dure_Garantie

IdFacture

Montant

nomMagasin

nomClient

dateAchat

dure_Garantie

E

X

X

X X

X

1

1

1

1

1

1

6

12

PR012 R

echercher une facture

S

asir id_Facture

IdFacture

R

1

13

PR013

Créer rapport de factures

(liste de factures) S

aisir Id_client

Id_Client

IdFacture

E

R

1

1

2

14

PR014 Im

primer rapport de

factures (liste de factures) S

aisir Id_client

Id_Client

X

1

1

15

PR015

Imprim

er la liste de tous les m

agasins

Saisir id

_Client

Id_Client

X

1

1

Nom

bre total de points de fonction 89

Tab

le 11: Iden

tification

des so

us p

rocessu

s

27

5.3.4. Type du projet

En examinant les définitions et les caractéristiques des trois classes de projet nous concluons que le projet est de type semi-détaché, ses contraintes de sécurité et surtout sa forte connexion avec le matériel et les autres systèmes de l’atelier. Projets de mode semi-détaché : Ce mode représente un intermédiaire entre le mode organique et le mode embarqué. Pour des projets de mode semi-détaché, l'équipe projet peut être composée de programmeurs de divers niveaux d'expérience, comme dans notre cas. Les systèmes embarqués sont d’habitudes réservés pour les applications critiques – ou des vies humaines sont en jeux. Bien que des vies ne soient pas en jeux, les enjeux monétaires sont primordiaux. Les contraintes sur le matériel rigide sont également importantes. Les membres de l'équipe ont une expérience limitée de ce type de système. Ils peuvent être totalement inexpérimentés en ce qui concerne quelques-uns des aspects du système à développer, mais pas tous. Le nombre de code de C++ équivalent à 149,94 points de fonction est : 89.1 × 64 = 5702,4 ~ 6 000 lignes de code (il n’existe pas de fraction de lignes de code !). Ce nombre de ligne de code Suggère que la taille du logiciel développé est « petite. Les deux résultats étant basés sur des estimations et Donnant des résultats différents, le chef de projet devrait recourir à une troisième méthode d’estimation (la méthode de Delphes) pour estimer avec plus de certitude la taille du futur programme.

5.3.5. Estimation avec méthode COCOMO

Justification pour COCOMO :

1. C’est une métrique facile à utiliser 2. Les membres de notre équipe sont des experts dans ces estimations 3. C’est une métrique standard que notre entreprise utilise pour estimer l’effort et la

durée 4. Facilite la communication avec le client

Modèle d’estimation COCOMO basique : ai = 3,00 bi = 1,12 ci = 2,50 di = 0,35 (puisque semi-détaché) ECOCOMO basique = 3,00 ��KLOC1,12 = 3,00 ��61,12 = 22.31 homme-mois(~23 homme-mois) DCOCOMO basique = 2,50 ��E0,35 = 2,50 ��230,35 = 7.49 mois(~8 mois)

28

Modèle d’estimation COCOMO intermédiaire Nous savons que : ECOCOMO intermédiaire = ECOCOMO basique x ��FA Les facteurs d’ajustements sont au nombre de quinze :

Facteurs d’ajustement

Qualificatifs Valeurs Justifications

RELY

Fiabilité

Très haut

1.40

La fiabilité du nouveau logiciel est la raison principale de son développement

DATA

Taille des données

Haut

1.08

Nous avons certainement des dizaines de milliers de clients

CPLX

Complexité des traitements

Nominal

1.0

Le logiciel ne requiert certainement pas de traitement mathématique ou d’entrées–sorties compliquées

TIME

Contraintes sur les temps de calcul, temps de réponse

Très haut

1.30

Le temps de réponse doit être élevé car les clients et les utilisateurs ne doivent pas avoir à attendre à cause du programme

STOR

Contraintes sur la mémoire

Nominal

1.0

Il ne devrait pas y avoir de contraintes particulière en termes de mémoire et de stockage physique

VIRT

Volatilité de la machine virtuelle (logiciel et matériel) sur laquelle le logiciel est développé

Nominal

1.0

Nous n’avons pas d’information sur ce facteur

TURN

Temps de latence dans l’utilisation des ordinateurs utilisés pour développer le logiciel

Bas

0.87

Les langages de programmation C et C++ sont outillés avec des programmes performants et intégrés, les développeurs n’auront pas de problème de ce côté là

29

ACAP Capacité des analystes

Bas

0.86 L’entreprise n’a pas d’expérience dans le domaine.

AEXP

Expérience dans le développement de ce logiciel

Très Bas

0.82

L’entreprise n’a pas d’expérience dans le développement de ce type de logiciel

LEXP

Expérience dans le langage de programmation utilisé

Bas

1.07

Les programmeurs sont experts en C et testent C++, ils ne sont donc pas experts en C++

PCAP

Capacité des programmeurs

Nominal

1.0

Nous n’avons pas d’information sur la capacité de développement des programmeurs

VEXP

Expérience dans la machine virtuelle pour laquelle le logiciel est développé (?)

Nominal

1.0

Nous n’avons pas d’information sur l’expérience des programmeurs sur les plates-formes utilisées et cibles

MODP

Pratiques modernes du génie logiciel

Nominal

1.0

Les programmeurs testent de nouvelles pratiques modernes de génie logiciel (programmation par objets et outils de conception orientée objets) mais ne sont pas encore des experts

TOOL

Utilisation d’outils de génie logiciel

Haut

0.91

les programmeurs utilisent des outils de développement intégré pour C, C++ et Rational Rose

SCED

Contrainte sur le temps de développement

Nominal

1.0

Nous avons identifié le calendrier comme étant un risque dans le TP 1. Cependant, du point de vue du développement et sans information complémentaire, nous considérons le calendrier comme n’induisant pas de pression.

30

Facteurs d’ajustements

1.96

Table 12: Table d'ajustement des points de fonctions

Ainsi : ECOCOMO intermédiaire = ECOCOMO basique x ��FA

= 23 x ��1,96 = 45.08 personnes-mois (~46 personnes-mois)

DCOCOMO intermédiaire = 2,50 x �ECOCOMO intermédiaire0,35

= 2,50 x �45.080,35 = 9.48 mois (~10 mois)

5.3.6. Estimation avec méthode des trois valeurs

Justifications : Nous avons consulter un expert dans la domaine pour pouvoir comprendre mielleux le type de logiciel et nous avons demandé son avis : E : estimé cherché ; Eo : estimé optimiste ; Eprob : estimé le plus probable Ep : estimé pessimiste

E = (E0+4*Eprobable+Epesimiste)/6

Eo = 33 personnes-mois (avis d’expert). Eprobable = 47 personnes-mois (avis d’expert). Epesimist = 55 personnes-mois (avis d’expert). E = (33 + 4*47+55)/6

= 46 (personnes-mois).

31

5.4. Planification du contrôle de risq

ues

No

du

ris

qu

e

Ris

qu

e

Imp

ac

t P

rob

ab

ilité

Ris

k E

xp

os

ition

In

dic

ate

ur

Rés

olu

tion

Q

ui

Qu

an

d

-Engager

d’autres program

meurs

1 C

alendrier 2

50%

1.00 Incapacité d’atteindre les délais établis

-Prolonger les

délais

Les m

embres

fondateurs de B

LEM

inc.

Lorsque la date prévue pour une

certaine activité est dépassée de 2

semaines

2 B

udget optim

iste 3

80%

2.40

Le budget atteint des niveau

x critiques bien avant la fin du projet

-Dem

ander une avance sur la rém

unération Le chef de projet

Quatre sem

aines avant l’évaporation

des fonds

- Le projet n’avance pas.

- Ajouter un

mem

bre à l’équipe ayant les connaissances nécessaires dans le dom

aine de l’inform

atique bancaire.

3

Manque

d’expérience du personnel

4 90%

3.60

- Aucune connaissance

de systèmes et

méthodes déjà en

place dans les dom

aines bancaires

- Sous-traiter à

une com

pagnie ayant les com

pétences nécessaires

Les m

embres

fondateurs de B

LEM

inc

Dès le début du

projet

4 C

hef de projet ine

xpérimenté

3 70%

2.10

Le chef de projet pren

d des décision

s qui s’avèrent in

correctes au sujet des

techn

ologies et des

méth

odologies en place.

Recruter un

chef de projet avec les com

pétences nécessaires

Les m

embres

fondateurs de B

LEM

inc.

Dès le début du

projet

5

Changem

ent continuel des spécifications

2 60%

1.20

Les algorithmes et

méthodologies

anticipées ne

Établissem

ent de spécifications

Le chef de projet

Lors de la conception du

logiciel

32

fonctionnent pas régulièrem

ent – elles ne répondent pas au

x attentes anciennem

ent spécifiées

imm

uables

6 A

bsence de soutien

1 30%

0.30

Lors des entretiens avec le client, il n’a pas l’air « chaud », ou songe abandonner el projet.

Revendre

l’idée au client Le chef de projet

A chaque occasion

possible!

7 P

erte de personnel

3 20%

0.60

Départ d’un des

mem

bres fondateurs de B

LEM

inc

Trouver du

personnel pour le rem

placer Le chef de projet

Dès le départ

8

Changem

ent m

atérielle / technologie

4 10%

0.40

Notre approche ne

fonctionne pas sur le point de vue com

patibilité matérielle

Revoir notre

approche Le chef de projet

Après l’échec des

tests T

able 13: tab

leau d

es con

troles d

es risqu

es N

ous avons choisis une valeur de "cut-off" de 1.50

33

6. Planification de la qualité

6.1 Qualités attendues d’un logiciel

Basée sur certaines normes ISO 9126: Voici celles que l’on a choisit:

1. Intégrité: Protection contre l’accès non autorisé;Ceci est primordial pour tout système bancaire.

2. Interopérabilité: Système doit pouvoir fonctionner de façon

harmonieuse avec la banque, le détaillant et le client.

3. Portabilité: Nous estimons que nous allons devoir écrire un module de code à incorporer dans les logiciels des détaillants selon quelques normes préexistantes établies par Interac. Ce code doit fonctionner sur les différentes plateformes et systèmes des détaillants.

4. Fiabilité: Doit opérer en tout temps? Doit être aussi fiable que le

système Interac en place.

5. Maintenabilité: Doit être capable de se faire changer au même rythme que le système Interac.

6. Faciliter de tester: pas primordial

7. Réutilisabilité: Pas besoin de fonctionner avec d’autres systèmes.

8. Conformité: Doit adhérer à la spécification imprimée pour remplir sa mission.

9. Utilisabilité: Grande facilité d’apprentissage sur technologie existante, créer manuel d’utilisation

34

6.2 Contrôle de progrès

Afin d’assurer le contrôle du progrès, nous avons décider de se réunir en groupe régulièrement. Étant donné la grande disparité de nos horaires respectifs, il est impossible de garantir la tenue d’une réunion selon l’horaire prévue. Nous nous sommes malgré donnés rendez-vous les mardis. Cela a bien fonctionné pour le mois d’octobre. En décembre, nous avions été contraints à déplacer les réunions les lundis.

Figure 4: Calendrier des réunions du groupe Les pages suivantes contiennent les rapports d’activité et les réunions de projet telles que remises a notre démonstrateur responsable (Driton).

Octobre 2004

D L M M J V S

26 27 28 29 30 1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30

31 1 2 3 4 5 6

Novembre 2004

D L M M J V S

31 1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 1 2 3 4

Légende : Rencontre planifiée non effectuée Rencontre effectuée avec planification Rencontre effectuée hors du calendrier établi au début du projet

35

Mardi 12 octobre 2004 BLEM

Réunion : 1 Participants: Eric Louis Daniel Mehdi Lieu de réunion : Département d’informatique Durée de réunion : 3 heures Objectif de la réunion : -Identification de risques. -Recherche des besoins. Résume des Décision prises : -Établir les limites de nos livrables.

Problèmes rencontrés : Aucun Objectifs de la prochaine réunion : -Identification des risques du projet et des structures de la compagnie. La date de prochaine réunion : Mardi 19 octobre 2004

36

Mardi 19 octobre 2004

BLEM

Réunion : 2 Participants: Eric Louis Mehdi Daniel Lieu de réunion : Cafeteria du pavillon Roger Gaudry Durée de réunion : 3 heures Objectif de la réunion : -Identification des structures internes et externes. -Gestion des besoins. -Identification des qualités du logiciel. Résume des Décision prises : -Identification de risques additionnels. -Élaboration des qualités. Problèmes rencontrés : -Incertitude de sélection entre une structure « egoless » ou « par projet ». -Manque de spécificité du fonctionnement du projet et de ses livrables. Objectifs de la prochaine réunion : -Planification du développement par la méthode du WBS. La date de prochaine réunion : Mercredi 27 octobre 2004

37

Mercredi 27 octobre 2004 BLEM

Réunion : 3 Participants: Daniel Eric Mehdi Louis Client (Driton) Lieu de réunion : Local Z255 Durée de réunion : 1 heure Objectif de la réunion : -Élaboration du WBS. Résume des Décision prises : -Consultation avec un expert requise. Problèmes rencontrés : -Lacune d’expérience empêche l’élaboration d’un WBS réaliste. Objectifs de la prochaine réunion : -Estimation par les méthodes de PERT et GANTT. La date de prochaine réunion : Vendredi 29 octobre 2004

38

Vendredi 29 octobre 2004 BLEM

Réunion : 4 Participants: Daniel Eric Mehdi Louis Client (Driton) Lieu de réunion : Département d’informatique Durée de réunion : 2 heures Objectif de la réunion : -Finalisation du WBS. -Estimation avec PERT et GANTT. Résume des Décision prises : -Consultation avec un expert requise. Problèmes rencontrés : -Difficultés d’utilisation des outils : création des diagrammes de PERT et du WBS a partir du diagramme de GANTT. Objectifs de la prochaine réunion : -Établir les points de fonctions. La date de prochaine réunion : ???

39

Jeudi 18 novembre 2004 BLEM

Réunion : 5 Participants: Louis Daniel Eric Mehdi Client (Driton) Lieu de réunion : Laboratoire d’infographie Durée de réunion : 2 heures Objectif de la réunion : -Finaliser les besoins immédiats du client afin de pouvoir établir les points de fonctions du logiciel et estimer les ressources nécessaires à sa production. Résume des Décision prises : - Élaboration des 3 façons d’interagir avec un usager - Élaboration d’un plan de fonctions disponibles pour chacune de ces interactions possibles. Problèmes rencontrés : -Oubli dans le plan de certaines fonctions. Objectifs de la prochaine réunion : -Déterminer les points de fonctions du logiciel et estimer les ressources nécessaires selon COCOMO La date de prochaine réunion : Vendredi 19 novembre 2004

40

Vendredi 19 novembre 2004 BLEM

Réunion : 6 Participants: Mehdi Louis Eric Daniel Lieu de réunion : Bibliothèque d’informatique Durée de réunion : 3 heures Objectif de la réunion : -Calculer les points de fonctions et estimer les ressources selon deux méthodes différentes Résume des Décision prises : -Énumération des points de fonctions selon les différents modules de notre système Problèmes rencontrés : -Ajouts de certaines fonctions par rapport au plan de fonctions dressé lors de réunion précédente. Objectifs de la prochaine réunion : -Discussion sur les notions de qualité et de gestion de la maintenance La date de prochaine réunion : Lundi 22 novembre 2004

41

Lundi 22 novembre 2004 BLEM

Réunion : 7 Participants: Mehdi Louis Eric Daniel Lieu de réunion : Laboratoire Turing Durée de réunion : 2 heures Objectif de la réunion : -Prévoir et planifier les conséquences de la qualité. Résume des Décision prises : -organisation de la qualité. Problèmes rencontrés : -Manque d’expérience. Objectifs de la prochaine réunion : -Planification du contrôle. La date de prochaine réunion : Lundi 29 novembre 2004

42

Lundi 29 novembre 2004 BLEM

Réunion : 8 (dernière avant la présentation) Participants: Mehdi Louis Eric Daniel Lieu de réunion : Département d’informatique Durée de réunion : 2 heures Objectif de la réunion : - Planification du contrôle. Résume des Décision prises : -organisation contrôle. Problèmes rencontrés : -Manque d’expérience.

43

6.3. Contrôle du budget

Budget du projet :

Planifier $

Dépense $

Établissement de l’environnement

5000

8000

L’expert

14400

24000

Frais mensuel de fonctionnement

1600

1600

Frais de développement :

• Identification et analyse de risques

• Définir les métriques

• Gérer la qualité du logiciel

• Analyser les fonctions

• Développer les besoins et les

spécifications

• Définir les besoins sur l’interface

• Concevoir l’interface graphique

• Concevoir le module détaillant

• Concevoir les bases de données

• Implanter et tester les bases de données

• Coder et tester les interfaces

graphiques

400

500

1400

1800

2400

600

1400

1800

600

32000

5500

1000

1200

1800

2600

3000

900

1800

1800

800

44

• Coder et tester les librairies

détaillants

• Documentation

40000

6000

115400

48500

Dans ce tableau, nous nous sommes basés sur les prévisions de temps établis dans le diagramme de Gantt attendu. Le coût alloué jusqu à ce point est de 48 500$ et le coût attendu était de 31 900$. La différence budgétaire est donc de -16 400$.

6.4. Contrôle de la qualité

Nous avons mis en œuvre plusieurs mesures pour réduire l’effort de développement : Acquisition de ressources matérielles et logicielles, des outils de génie logiciel qui génère le code directement depuis des modèles du programme ou l’utilisation systématique du matériel et du logiciel (machine virtuelle) du client pour limiter le temps passer dans les tests d’intégration et d’acceptation et les risques associés ; Adaptation du plan de projet, nous avons consulté le calendrier du développement pour réduire la durée du développement sans augmenter le nombre de personnes nécessaires ; Transfert de l’effort, nous avons consulté une entreprise pour sous-traiter certaines parties du programme ou pour acheter directement certains composants déjà existants. Cependant, pour cette mesure nous avons pris en compte le risque associé à la sous-traitance (en particulier la qualité) et à l’utilisation de composants « génériques » (en particulier le temps para métrisation d’adaptation des programmeurs à ce modèle de développement) ; Adaptation du modèle de développement, l’entreprise Hottentot peut se mettre D’accord avec notre entreprise pour utiliser un modèle de développement par prototypes incrémental) qui nous permettra de livrer avec un effort et une durée minimum un logiciel avec les fonctionnalités centrales puis d’offrir de nouvelles versions plus complètes plus tard.

45

Nous avons décidé de mettre en œuvre un système de management de la qualité pour ses services en ligne par l'Internet.

Site web ou page web de le banque : 1. Consulter les factures (parmi toutes les factures) 2. Imprimer une facture 3. Archiver une facture 4. Désarchiver une facture 5. Créer rapport / liste - factures 6. Imprimer rapport / liste - factures

Nous assurons que notre manuel de qualité précise clairement que les services traditionnels sont inclus dans notre système de management de la qualité. Tout en adoptant les exigences d'ISO 9001:2000, nous avons trouvé dans ISO 9000:2000 des indications pour interpréter des mots et phrases utilisés pour l'application d'ISO 9001. Nous avons appliqué toutes les exigences de l'article 7, en reconnaissant que la conception et le développement forment une part importante de la création de nouveaux processus de service.

Nous avons appliqué le même principe pour les services : logiciel au point de vente et Service à la clientèle à la banque respective du client : Service à la clientèle à la banque respective du client :

1. Consulter les factures (parmi toutes les factures) 2. Imprimer une facture 3. Archiver une facture 4. Créer rapport / liste - factures 5. Imprimer rapport / liste - factures

Logiciel au point de vente : 1. Ajouter facture 2. Consulter une facture (du même détaillant) 3. Modifier une facture (du même détaillant)

46

6.5. Gestion de crises :

La majorités des compagnies font souvent face a des situations de crises. Une crise va généralement mettre en péril le succès d’un projet sans pour autant mettre la vie de l’entreprise en danger. Or dans la plupart des cas, une crise est un changement imprévu du comportement normale d’un plan de projet. Ceci devrait généralement susciter un réveil de la part des employés afin de contrôler ce risque. Cependant, il est très peu évident de maintenir le ‘statut quo’ dans un état de crise. Ainsi, la modification d’un des paramètres du projet est inévitable pour résoudre ce problème.

Dans le cadre de notre projet, Il nous paraissait évident de mentionner deux types de crises sérieuses. Premièrement, la perte de membre clé de notre infrastructure. En effet, étant donné le manque d’expérience des fondateurs et employés de la compagnie BLEM, il a été primordial d’engager un expert dans le domaine afin de régulariser et maintenir une qualité adéquate tout au long du projet. Ce dernier, conseillera les membres de l’équipe, tranchera sur toute les décisions techniques et conceptuelles et travaillera conjointement avec le chef de projet dans le but de prendre les décisions importantes. Ainsi, le départ inattendu de cet expert causera inévitablement une crise dans le développement du projet eBill. Son départ pourrait être engendrer par plusieurs facteurs soient un conflit avec les membres de l’équipe ou du chargé de projet, une offre extérieure plus intéressante ou bien la perte d’intérêt pour le projet. Du côté du projet, il faudra trouver un autre expert qualifié qui pourra non seulement se familiariser avec la charge du projet mais aider les employés à garder la motivation et à avancer dans le projet afin de ne pas dépasser l’échéance. Ceci représente un grand problème qui ne peut pas se permettre d’arriver car la survie même du projet pourrait être en jeu.

Pour éviter ce problème, il faudra satisfaire les demandes de l’expert dans la mesure du possible. Dans le cas contraire, il faudra pas paniquer et essayer de trouver un compromis et renégocier une échéance avec nos superviseurs

47

6.6. Organisation de la maintenance :

Pour la maintenance de notre logiciel nous allons utiliser la norme ISO 9126 La norme ISO 9126 définit six caractéristiques de la qualité des produits logiciels. Ce sont des points de repères pour les raffinements subséquents. On peut définir chacune des caractéristiques en termes de plusieurs attributs (ou sous caractéristiques). Chacun des attributs doit avoir une définition précise et posséder des indicateurs mesurables.

Par exemple, une de ces caractéristiques est la facilité d’entretien (maintenabilité) qui peut être définit par l’effort nécessaire pour modifier le logiciel. Les attributs de cette caractéristique sont :

� L’analysibilité

� La changeabilité

� La stabilité

� La testabilité

48

49

Nous allons utiliser Logiscope qui est un logiciel dédié à l'évaluation de la qualité, aux tests et à la maintenance des logiciels. Logiscope propose un ensemble très riche d'outils pour la rétro conception, les tests, l'analyse de la qualité et la vérification de règles de programmation. Il est composé d’un ensemble d'outils tel le CodeChecker, le TestChecker et le RuleChecker. Nous allons maintenant expliquer en détail chacun de ces outils. Le rôle principal du CodeChecker est d’aider le programmeur à identifier les parties de son code qui ne suivent pas le modèle de la qualité du projet. Ce type d'analyse est appelé l'analyse statique puisqu’il n'exige pas l'exécution du code. Logiscope CodeChecker reçoit normalement comme entrée:

� Le code source sur lequel il évaluera un ensemble de métrique � Le modèle de la qualité duquel il interprète et affiche les résultats.

Logiscope CodeChecker supporte plusieurs langages de programmation (Java, C, C++, Fortran...) et leurs syntaxes. Le rôle du TestChecker de Logiscope est d’analyser et d’identifier des portions de codes qui n'ont pas été exécutés pendant les tests du logiciel. Le programmeur peut alors concevoir de nouvelles épreuves afin de couvrir le plus de code ou laisser tomber les épreuves redondantes qui couvrent le même code. Ce type d'analyse est appelé l'analyse dynamique puisqu’il exige une exécution du code. Logiscope TestChecker reçoit comme entrée:

� Le code source sur lequel il évaluera un ensemble de métrique � Le modèle de la qualité duquel il interprète et affiche les résultats.

Logiscope TestChecker supporte le même ensemble de langages que le Logiscope CodeChecker.

50

Logiscope a adopté le “ TRW, 1975, B.W.Boehm “ et “ General Electric n.77C1502, June 1997, J.A.McCall ” qui sont des approches de modèle de la qualité. Cette approche définit la qualité du logiciel comme l’ensemble des caractéristiques suivantes :

Factor : MAINTAINABILITY

MAINTAINABILITY = ANALYZABILITY + CHANGEABILITY + STABILITY + TESTABILITY

Criteria : ANALYZABILITY

ANALYZABILITY = ap_inhg_levl + AVG_CBO + ap_aif + ap_mif + ap_cof + RECU_Ratio

Criteria : CHANGEABILITY

CHANGEABILITY = ap_inhg_levl + URI_Ratio + NMM_Ratio + ap_pof + ap_mif

Criteria : STABILITY

STABILITY = AVG_CBO + ap_inhg_cpx + ap_mhf + ap_ahf + ap_cof

Criteria : TESTABILITY

TESTABILITY = AVG_VG + NMM_Ratio + ap_mhf + ap_ahf + ap_cg_levl

URI_Ratio: Ratio of repeated inheritances in the application. NMM_Ratio: Percentage of non-member functions. AVG_CBO: Average coupling between objects. AVG_VG: Average of the VG of the application's functions. RECU_Ratio: Ratio of recursive edges on the call graph. ap_mhf: Method hiding factor (MOOD). ap_ahf: Attribute hiding factor (MOOD). ap_mif: Method inheritance factor (MOOD). ap_aif: Attribute inheritance factor (MOOD). ap_pof: Polymorphism factor (MOOD). ap_cof: Coupling factor (MOOD). ap_inhg_levl: Number of Levels in the Inheritance Graph. ap_inhg_cpx: Hierarchical Complexity of the Inheritance Graph. ap_cg_levl: Number of Levels in the Call Graph. ap_inhg_uri: Number of Repeated Inheritances. ap_inhg_edge: Number of Edges in the Inheritance Graph. ap_func: Number of application functions. ap_nmm: Number of application member functions. ap_cbo: Coupling between objects. ap_clas: Number of application classes.

51

7. Conclusion :

La compagnie Interac désire implémenter un système de gestion de

factures pour tous ses clients. Cette idée sauvera beaucoup de temps et

d’argents aux clients. La compagnie BLEM, qui est une compagnie jeune et

dynamique mais qui manque d’expérience, s’engage à affronter ce défit de

numériser les factures des clients à l’aide d’une bande magnétique. Ce

développement permettra une révolution chez tous les détaillants et permettra

aux clients de ne plus conserver de factures lorsqu’ils le désireront. Le système

eBill, par l’entremise de la carte magnétique et du réseau Interac, facilitera

l’échange d’informations et assurera une qualité comparable à celle d’une carte

de débit. Elle sera appréciée par tous et le client ne voudra que magasiner là ou

la carte eBill est acceptée. Il va de l’avantage de client de s’engager dans cette

ligne directive qui sera bientôt très utilisée dans le monde.

Cette idée est à l’aube de prendre une envergure énorme et de se mêler

au développement informatique du 21ième siècle. Le travail est long mais très

réalisable. L’idée ingénieuse attirera la plupart des entreprises et surtout les

clients. Pour le client, ou les détaillants, il sera avantageux d’avoir ce système

car une trace d’achat sera toujours gardée par le détaillant et le client voudra

aller seulement dans des endroits ou l’utilisation de la carte eBill est disponible.

Pour une fois, il semblera que les compagnies désirent aider les consommateurs!

Annexe