Treasury Board of Canada
Secretariat	Secrétariat du Conseil du Trésor 
du Canada	

Cadre amélioré de la gestion
Procédure de base d'estimation de la taille du produit logiciel

Révision : ébauche 1.0
Date de publication : janvier 2000

Administrateur du processus : Cadre amélioré de la gestion

PPTO-PD-001

Table des matières
1.	Introduction	1
1.1	Objet	1
1.2	Portée	1
1.3	Rôles	1
1.4	Définitions et acronyms	2
1.5	Références	3
1.6	Demandes de renseignements	4
2.	Procédure	5
2.1	Critères d'entrée	5
2.2	Tableau de concordance du processus	5
2.3	Intrants	7
2.4	Activités	9
2.5	Extrants	12
2.6	Vérification et validation	12
2.7	Critères de sortie	13
2.8	Mesures	13
2.9	Tableau de contrôle des enregistrements	13
2.10	Tableau des documents contrôlés	13

Annexe A — Lexique
Annexe B — Acronymes
Annexe C — Symboles d'ordinogramme
Annexe D — Bibliographie
Annexe E — Suivi de modification des documents
Annexe F — Documentation des formules d'estimation du projet aux fins de la taille du produit logiciel — Feuille 1

1.	Introduction
1.1	Objet
La procédure est une activité du processus de planification de projet (PPTO‑PS‑002). Elle se sert des exigences pour calculer une mesure de la taille fonctionnelle qui est convertie en lignes de codes source (KLCS). L'estimation de la taille est entrée dans d'autres activités du processus de planification de projet, notamment la procédure de base d'estimation des ressources et du calendrier du projet.
1.2	Portée
Le document s'applique aux projets de gestion de l'information et de technologie de l'information (GI/TI) livrant des logiciels.
Il faut veiller à ce que toutes les hypothèses, contraintes et justifications (c'est‑à‑dire les décisions) soient documentées dans le plan de projet.
1.3	Rôles
Chaque membre de l'organisation a un rôle à jouer dans l'exécution de cette procédure. 
Rôle	Description/responsabilités	
Chef de projet (CP)	Personne que le ministère parrain a chargée de rendre compte de tous les aspects internes et externes d'un projet d'investissement. http://www.publiservice.tbs-sct.gc.ca/Pubs_pol/dcgpubs/TBM_122/ABKGLOS_f.html	
Gestionnaire de projet (GP)	Personne officiellement chargée de gérer un projet et assumant la responsabilité particulière de la réalisation des objectifs du projet dans les limites des ressources allouées. Le gestionnaire de projet a accès au chef de projet auquel le projet en cause a été alloué, avec lequel il a des relations définies officiellement. http://www.publiservice.tbs-sct.gc.ca/Pubs_pol/dcgpubs/TBM_122/ABKGLOS_f.html 	
Membre de l'équipe de projet (MEP)	Ingénieur en logiciel ou auteur de logiciel assigné à un projet.
Chargé d'exécuter les tâches du projet, de fournir des intrants aux plans et d'indiquer l'état d'avancement.	
Bureau de gestion de projet (BGP)	Unité organisationnelle temporaire distincte, dirigée par le gestionnaire du projet. Le BGP est composé de membres du ministère parrain affectés à plein temps ou à temps partiel et, le cas échéant, de représentants des ministères participants qui travaillent ensemble conformément aux accords ou protocoles d'entente interministériels pertinents. http://www.publiservice.tbs-sct.gc.ca/Pubs_pol/dcgpubs/TBM_122/ABKGLOS_f.html 	
Assurance de la qualité (QA)	Service chargé de soutenir les activités d'assurance de la qualité.	
Gestion de la configuration (GC)	Service chargé de soutenir les activités de gestion de la configuration.	

1.4	Définitions et acronymes
Algorithme	(1) Ensemble ordonné de règles bien déterminées servant à résoudre un problème dans un nombre fini d'étapes; par exemple, une spécification complète d'une séquence d'opérations mathématiques pour évaluer le sinus x à un degré donné de précision. [IEEE-STD-610]
(2) Séquence d'opérations permettant d'exécuter une tâche précise. [IEEE-STD-610] 
(3) Ensemble de règles devant être exprimées complètement pour qu'un important problème de calcul puisse être réglé. [Capers Jones]	
Intrant	Écrans ou formulaires grâce auxquels les utilisateurs humains d'une application ou d'autres programmes ajoutent de nouvelles données ou mettent à jour les données existantes. Si, en raison de la taille de l'intrant, plus d'un écran est nécessaire, l'ensemble correspond à un intrant. Il faut tenir compte des intrants exigeant un traitement particulier. [Capers Jones]	
Demandes de renseignements	Écrans grâce auxquels les utilisateurs peuvent interroger une application et demander de l'aide ou de l'information, comme les écrans d'AIDE.  [Capers Jones]	
Interface	Fichiers partagés avec d'autres applications comme les fichiers sur bande magnétique reçus et envoyés, les bases de données partagées et les listes de paramètres.  [Capers Jones]	
Fichier maître	Fichiers de données représentant des collections logiques d'enregistrements qui sont modifiés ou mis à jour par l'application.  [Capers Jones]	
Extrant	Produit des données dérivées. [Garmus, Herron]
Les extrants sont des écrans ou des rapports produits par l'application pour que les humains puissent s'en servir ou pour d'autres programmes. Il convient de signaler que les extrants exigeant un traitement distinct représentent les unités à compter. Dans une application de paye, l'extrant qui a créé 100 chèques compte toujours pour un seul extrant. [Capers Jones]	
Voir le lexique du Cadre amélioré de la gestion.
Voir les acronymes du Cadre amélioré de la gestion.
Voir les liens Web du Cadre amélioré de la gestion.

1.5	Références
1.5.1	Traçabilité
La procédure a été conçue pour qu'il soit satisfait aux objectifs du niveau 2 du Modèle d'évaluation des capacités logicielles du SEI. Pratique clé : planification de projet de logiciel.
1.5.2	Politiques
Politiques du Secrétariat du Conseil du Trésor :
•	Plans d'immobilisations — glossaire
•	Gestion des grands projets de l'État
•	Politique d'examen des marchés
•	Gestion de projet
•	Approbation de projet
Vous trouverez ces politiques à l'adresse URL suivante :
http://www.publiservice.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_122/siglist_f.html 
1.5.3	Normes
Annexe A – Symboles d'ordinogramme
1.5.4	Processus
PPTO-PS-002  Processus de planification de projet
PPTO-PS-003  Processus de suivi et de surveillance de projet
PEER-PS-001  Processus d'examen par les pairs
1.5.5	Procédures
PPTO-PD-002  Procédure de base d'estimation des ressources et du calendrier de projet
1.5.6	Lignes directrices
Ne s'appliquent pas pour l'instant.
1.5.7	Modèles
PPTO-TM-001  Modèle du processus et de la procédure
PPTO-TM-002  Modèle du plan de projet
PPTO-TM-003  Modèle des estimations de projet
1.5.8	Listes de contrôle
PPTO-CK-001  Liste de contrôle de la gestion de projet
1.5.9	Formation
Pour en savoir davantage sur la formation, consulter le site à l'adresse :
http://www.cio-dpi.gc.ca/emf/EMFIndex_f.html 
1.5.10	Outils
Pour en savoir davantage sur les outils, consulter le site à l'adresse :
http://www.cio-dpi.gc.ca/emf/Publications/SoftwareToolsReport/stf_f.html 

1.6	Demandes de renseignements
Pour en savoir davantage sur le processus, consulter le site à l'adresse :
http://www.cio-dpi.gc.ca/emf/EMFIndex_f.html 
2.	Procédure
2.1	Critères d'entrée 
Les critères d'entrée suivants décrivent l'état des intrants, un événements ou l'expiration d'un délai, qui doivent survenir avant que le processus ne puisse commencer.
Détails des critères d'entrée	
•	Analyse de rentabilisation approuvée
•	Charte de projet approuvée
•	Série d'exigences approuvées, conformément aux méthodologies GI/TI
•	Plan de projet initial	

2.2	Tableau de concordance du procédure
L'acheminement général du processus qui figure ci‑après indique les interactions et le cheminement entre les processus. Pour de plus amples précisions sur les processus, consulter la rubrique 2.4 Activités.  

2.3	Intrants
Les intrants suivants sont utilisés dans le cadre de la procédure. S'ils n'existent pas, il faut cerner les éventuels risques connexes.
Intrant	Détail des intrants et remarques	Référence	
Analyse de rentabilisation	Identification et justification d'un projet de GI/TI qui établissent le lien entre le projet et les priorités de programmes ainsi que les améliorations quantifiables du rendement de programmes.
•	Indique l'occasion.
•	Décrit la valeur ajoutée.
•	Décrit la solution de GI/TI.
•	Cerne les identificateurs permettant de mesurer les améliorations du rendement de programmes.	Lignes directrices sur l'analyse de rentabilisation du CAG	
Charte de projet	Entente entre les groupes technique et opérationnel qui définit :
•	les partenaires et les intervenants externes,
•	le cadre de la gestion de projet,
•	les rôles, responsabilités, reddition de compte et activités,
•	les engagements de la direction,
•	le cadre d'habilitation.	Modèle de charte de projet du CAG	
Plan de projet initial	Ententes entre les groupes technique et opérationnel décrivant de manière plus détaillées :
•	Quoi : produits livrables intérimaires et finals.
•	Pourquoi : objet et objectifs.
•	Où : portée.
•	Qui : rôles, responsabilités, reddition de comptes.
•	Comment : processus gestionnels et techniques, plans à l'appui.
•	Quand : calendrier provisoire.
•	Combien : estimation des ressources.
Documenter les détails connus. 	PPTO-TM-002	
	•	Les décisions relatives aux documents qui ont été prises à ce jour influeront sur les risques, les contraintes, les hypothèses et les estimations.		
Exigences	•	Documenter les exigences conformément aux méthodologies retenues.		
Base de données de l'entreprise	•	Données réelles de projets antérieurs de GI/TI utilisées à des fins de comparaison et de vérification du processus de planification.		

2.4	
Activités 
Utiliser les normes, méthodes d'estimation, outils et techniques de l'organisation pour estimer la taille du produit logiciel.
Voici une liste partielle des normes de l'industrie en matière d'estimation de la taille du logiciel.
•	Points fonctionnels   http://www.ifpug.org/
•	L'Agence des douanes et du revenu du Canada recommande fortement d'utiliser les points fonctionnels.
•	Lignes de codes sources (LCS)
•	Mark II UKSMA.CO.UK
•	COSMIC  
•	COSMICON.com
•	http://www.lrgl.uqam.ca  
•	Points fonctionnels tridimensionnels
•	Points caractéristiques www.spr.com
Si l'organisation n'a pas adopté de méthode normalisée, utiliser la méthode suivante à titre de solution provisoire en attendant que l'organisation choisisse une méthode d'estimation de la taille du logiciel.
Les activités suivantes sont exécutées dans le cadre de la procédure. Il faut documenter l'ensemble des hypothèses, des risques, des contraintes, etc. dans le plan de projet.
No	Activités	Mesure prise par	Détail des activités et remarques	Référence	
1	Calculer la mesure de la taille fonctionnelle

Documenter les hypothèses utilisées pour calculer la mesure de la taille fonctionnelle.

	GP	•	Compter et entrer les éléments suivants dans la colonne Dénombrement :
•	intrants,
•	extrants,
•	fichiers maîtres,
•	demandes de renseignements,
•	interfaces,
•	algorithmes – facultatif lorsque les algorithmes sont beaucoup utilisés (ICP) et que les gestionnaires de projet optent pour la documentation distincte. 
•	Chaque dénombrement (1A) est automatiquement multiplié par son facteur de pondération correspondant (1B) créant ainsi un total pour chaque rangée. 
•	La mesure de la taille fonctionnelle (1C)  fait automatiquement la somme des totals des rangées.
Lignes directrices sur le dénombrement :
•	L'interface applicative (API) exige le logiciel offert dans le commerce, et les autres logiciels réutilisés sont comptés comme des interfaces.
•	Les fonctions sont associées aux groupes logiques ou aux écrans de données plutôt qu'aux paramètres de données individuels.
•	S'assurer que les exigences et les fonctions ne sont pas comptées plus d'une fois lorsqu'elles sont décrites à plusieurs endroits.
•	Les messages d'erreur comptent habituellement pour un seul extrant et un fichier maître.	Annexe F
PPTO-TM-003	
2	Déterminer la complexité du problème

Documenter les hypothèses ayant servi à déterminer la complexité du problème.	GP	•	Évaluer la complexité des algorithmes et des calculs en se servant de la description qui décrit le mieux le logiciel.
•	Choisir un rajustement de la complexité du problème (2B) dans le tableau (2A).
•	Ce numéro est automatiquement multiplié par la mesure de la taille fonctionnelle (1C) pour donner la complexité du problème (2C).
	PPTO-TM-003	
3	Déterminer la complexité des données

Documenter les hypothèses ayant servi à déterminer la complexité des données.	GP	•	Évaluer la complexité des données entreposées en se servant de la description qui décrit le mieux le logiciel.
•	Choisir un rajustement de la complexité des données (3B) dans le tableau (3A) et l'entrer.
•	Ce numéro est automatiquement multiplié par la mesure de la taille fonctionnelle (1C) pour donner la complexité des données (3C).
•	La complexité du problème (2C), la complexité des données (3C) et la mesure de la taille fonctionnelle (1C) sont additionnées pour donner la mesure de la taille fonctionnelle totale (3D).
	PPTO-TM-003	
4	Déterminer le multiplicateur du langage

Documenter les hypothèses ayant servi à déterminer le multiplicateur du langage
	GP	•	Déterminer le ou les langages ayant servi à élaborer le logiciel.
•	Choisir un multiplicateur du langage (4B) dans le tableau (4A) et l'entrer.
•	Le multiplicateur du langage est automatiquement multiplié par la mesure de la taille fonctionnelle (3D) puis divisé par 1000 (pour obtenir des KLCS)  et donne les KLCS estimatives (4C).
Nota : pour obtenir d'autres langages de programmation, consulter le tableau au site à l'adresse : http://www.spr.com/library/0langtbl.htm
Trouver le langage voulu, puis entrer le numéro qui figure dans la colonne des instructions source moyennes selon le point fonctionnel (dernière colonne).	PPTO-TM-003	
5	Déterminer le niveau de confiance

Documenter les hypothèses ayant servi à déterminer le niveau de confiance	GP	•	Évaluer la condition qui décrit le mieux la spécification ou d'autres documents décrivant le logiciel. 
•	Utiliser la description qui décrit le mieux le document, choisir le niveau de confiance (5B) dans la colonne (5A) et l'entrer.
Le niveau de confiance est automatiquement multiplié par les KLCS estimatives (4C) pour arriver aux KLCS totales (5C) et donner la valeur du niveau de confiance.	PPTO-TM-003	
6	Examiner les estimations	GP	•	Comparer les KLCS totales à celles de projets de taille semblable dans la base de données (historiques) de l'entreprise. Si l'estimation de la taille varie considérablement, revenir à la mesure de la taille fonctionnelle de l'activité 1 pour déterminer s'il y a eu des omissions ou des comptes en double.
•	Examiner l'estimation de la taille et les hypothèses documentées en collaboration avec les groupes et les particuliers touchés et obtenir leur approbation.
Nota : la prudence est de mise dans le cas des estimations de moins de 30 KLCS car il est presque impossible de fournir une fonctionnalité réelle à ce niveau.	PPTO-TM-003 
PEER-PS-001	

2.5	Extrants 
Les extrants suivants sont produits ou modifiés par les activités menées dans le cadre de la procédure.
Extrant	Détails de l'extrant et remarques	Référence	
Taille du logiciel	•	Information de base (hypothèses).
•	Utiliser le chiffrier pour calculer l'estimation de la taille du logiciel.
•	Annexer le chiffrier au plan de projet.
•	Il faut documenter l'ensemble des hypothèses, des risques, des contraintes, etc. dans le plan de projet.	PPTO-TM-002
PPTO-TM-003	

2.6	Vérification et Validation
Validation des extrants	Voir Activité 6 – Examen des estimations
Pour déterminer si les extrants sont conformes à la spécification : 
•	Utiliser le processus d'examen par les pairs (PEER-PS-001) et toute autre technique décrite dans la méthodologie de GI/TI.
•	Utiliser les techniques de validation mentionnées dans la méthodologie de GI\TI comme la mise à l'essai, la démonstration, l'analyse et l'inspection.

2.7	Critères de sortie
Détails des critères de sortie	
•	Tous les groupes et les particuliers touchés conviennent de l'estimation de la taille du produit et l'approuvent.	

2.8	Mesures
Voir le Cadre amélioré de la gestion, Présentation préliminaire de la boîte à outils du cadre, du 22 novembre 1999, pour connaître le tableau de bord du contrôle de la santé du projet.
2.9	Tableau de contrôle des enregistrements
Ne s'applique pas pour l'instant. Remplir le tableau si la certification ISO est demandée. Pour de plus amples renseignements, consulter le modèle du processus et de la procédure (PPTO-TM-001).
Description
(numéro et nom)	Lieu d'entreposage	Classement / Index	Délai minimum d'entreposage	

				

2.10	Tableau des documents contrôlés
Ne s'applique pas pour l'instant. Remplir le tableau si la certification ISO est demandée. Pour de plus amples renseignements, consulter le modèle du processus et de la procédure (PPTO-TM-001).
Numéro	Nom	Date de révision 
(ou version)	Administrateur	

Annexe A – Lexique
Voir le lexique du Cadre amélioré de la gestion ou insérer un renvoi au lexique de l'organisation.

Annexe B – Acronymes
Voir les acronymes du Cadre amélioré de la gestion ou insérer un renvoi aux acronymes de l'organisation.

Annexe C – Symboles d'ordinogramme

		
Les parallélogrammes représentent des intrants et des extrants à un processus ou à une procédure ou provenant d'un processus ou d'une procédure.		

		
Les rectangles représentent des activités de processus ou procédures particuliers.  	Les losanges représentent des points de décision importants du processus ou de la procédure.	

		
Les lignes avec des pointes de flèches lient des symboles pour montrer la progression ou la direction des activités.	Les cercles représentent des connexions lorsque l'ordinogramme du processus ou de la procédure continue sur une autre page.	

Annexe D – Bibliographie
Boehm, Barry, Software Engineering Economics, Prentice Hall, New Jersey, 1991.
Garmus, David, Herron, David, Measuring the Software Process: A Practical Guide to Functional Measurements, Yourdon Press, 1996. 
Jones, Capers, Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, Inc., New York, 1996.
Voir les liens Web du Cadre amélioré de la gestion.

 

Annexe E – Suivi de modification des documents
Le tableau présente l'historique des révisions du document. Le document lui‑même devrait être entreposé au contrôle des révisions et une brève description de chaque version doit être entrée dans le système de contrôle des révisions et répétée dans cette section.  
Numéro de révision	Date de publication	Auteurs	Brève description du changement	
0.1	1999-08-24	EMF/PPTO	Ébauche initiale	
0.2	1999-09-06	EMF/PPTO	Ébauche révisée	
0.3	1999-09-14	EMF/PPTO	Commentaires des examinateurs	
0.4	1999-09-23	EMF/PPTO	Ajout de l'annexe du chiffrier	
1.0	1999-11-09	EMF/PPTO	Première ébauche	
1.0	2000-01-18	EMF/PPTO	Deuxième ébauche	

Annexe F – Documentation des formules d'estimation du projet aux fins de la taille du produit logiciel – Feuille 1
1. Mesure de la taille fonctionnelle	

Éléments	Dénombrement(1A)	Facteur de pondération (1B)	Total	
Intrants 		4	(1A)*(1B)	
Extrants		5	(1A)*(1B)	
Fichiers maîtres		7	(1A)*(1B)	
Demandes de renseignements		4	(1A)*(1B)	
Interfaces		7	(1A)*(1B)	
Algorithmes (facultatif)		3	(1A)*(1B)	
(1C)  Mesure de la taille fonctionnelle  	Somme de la colonne	

2. Complexité du problème		
Sens	Description	Entrée(2A)		
Très faible	Algorithmes et calculs simples.	-20 %		
Faible	Majorité d'algorithmes et de calculs simples.	-10 %		
Moyenne	Algorithmes et calculs de complexité moyenne. Utilisation de routines mathématiques et statistiques normalisées. Opérations matricielles et vectorielles de base. 	0 %		
Grande	Quelques calculs difficiles ou compliqués. Analyse numérique de base, interpolation de variables multiples, équations différentielles ordinaires, troncature de base et problèmes d'arrondissement.	+10 %		
Très grande	Nombreux algorithmes difficiles et calculs compliqués. Analyse numérique difficile, équations différentielles partielles, équations matricielles difficiles, analyse de données bruitées.	+20 %		
 (2B) Rajustement de la complexité du problème	Choisir dans la colonne 2A	
(2C) Complexité du problème	(1C)*(2B)	
3. Complexité des données		
Sens	Description	Entrée (3A)		
Très faible	Données simples comportant peu de variables, faible complexité.	-20 %		
Faible	Nombreuses variables mais relations simples entre les données.	-10 %		
Moyenne	Champs multiples. Champs et interactions entre les données multiples.  	0 %		
Grande	Structures de fichiers et interactions entre les données complexes.	+10 %		
Très grande	Structure de fichiers et interactions entre les données très complexes.	+20 %		
(3B) Rajustement de la complexité des données	Choisir dans la colonne 3A	
(3C) Complexité des données	(1C)*(3B)	
(3D) Mesure de la taille fonctionnelle totale  	(1C) + (2C) + (3C)	

4. Multiplicateur du langage
Voir la table des langages de programmation à l'adresse : http://www.spr.com/library/0langtbl.htm 	
Langage	(4A) Multiplicateur		
COBOL II	107		
C++	53		
PowerBuilder	16		
Smalltalk	21		
Program Generator	16		
SQL	13		
Database	40		
Visual Basic 5	29		
 (4B) Multiplicateur du langage	Choisir dans la colonne 4A	
(4C) KLCS estimatives  	(3D)*(4B)/1000	

5. Niveau de confiance		
Sens	Description	Entrée (5A)		
Faible connaissance	Si peu de choses sont connues concernant les exigences.	2,5		
Beaucoup d'éléments à déterminer	Si les exigences sont bien comprises mais que certains éléments de la documentation les décrivant restent à déterminer (AD).	2,0		
Quelques éléments à déterminer	Si les exigences sont bien comprises mais que beaucoup d'éléments de la documentation les décrivant restent à déterminer (AD).	1,5		
Aucun élément à déterminer	Si les exigences sont bien comprises et qu'aucun élément de la documentation les décrivant n'est à déterminer (AD).	1,0		
(5B) Niveau de confiance 	Choisir dans la colonne 5A	
(5C) KLCS totales  	(4C)*(5B)