1 LE PROJET eBill
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 [email protected] o Mehdi El Moutaouakkil [email protected] o Lulzim Laloshi [email protected] o Eric Mechaly [email protected]
• 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