introduction
Ceci est la troisième partie du blog se concentrant sur un certain nombre de méthodes de mesure de la taille de logiciels populaires et leur utilité pour l'estimation de projets logiciels.. Dans cette troisième partie, les méthodes de mesure de taille non fonctionnelle sont couvertes. Dans le prochain et dernier blog sur ce sujet les futurs blogs, je couvrirai les méthodes hybrides.
Il est vivement recommandé aux lecteurs intéressés par ce sujet de lire d'abord le première partie et deuxième partie de ce blog avant de lire cette troisième partie de la série de blogs.
Pour qu'une méthode de mesure de taille de logiciel particulière soit utile pour l'estimation de projet logiciel, les caractéristiques suivantes doivent s'appliquer:
- La méthode de mesure de la taille peut être effectuée dans un objectif (indépendamment de la personne qui le fait), répétables, vérifiable et donc défendable façon;
- La taille en elle-même n'est utile que lorsque données historiques est disponible des projets mesurés dans cette méthode de mesure de taille;
- Les méthodes de mesure de la taille doivent être prises en charge par modèles et / ou outils paramétriques afin de prendre en compte avec précision les caractéristiques spécifiques du projet qui influencent l'estimation, comme par exemple QSM SLIM, SEER pour le logiciel, TruePlanning ou COCOMO II.
Bien sûr, toute méthode de mesure de la taille d'un logiciel non conforme à un ou plusieurs de ces critères peut encore être très utile pour une organisation, à condition qu'ils élaborent une procédure garantissant des mesures de taille répétables, collecter et analyser des données historiques et / ou construire leurs propres modèles d'estimation basés sur les données collectées. Pour ce blog cependant, l'accent est mis sur l'utilité théorique de la méthode de mesure spécifique à des fins d'estimation de projets logiciels dans le contexte d'organisations qui n'ont pas encore de processus d'estimation paramétrique en place. Pour ces organisations, qui sont disposés à mettre en œuvre une méthode de mesure de taille afin d'estimer des projets logiciels, ce blog peut servir de guide pour sélectionner une méthode spécifique.
Bien que tout ce qui est écrit dans ce blog soit basé sur une expérience personnelle et sur une documentation accessible au public (référencé), Je tiens à souligner que ce blog ne reflète que mes opinions et croyances personnelles et donc je ne prétends pas que tout ce qui est écrit dans ce blog est une vérité absolue. Mes convictions personnelles ne sont pas nécessairement aussi celles des organisations auxquelles je suis affilié: Mètres, Nesma et ISBSG.
J'encourage tout le monde à soumettre des commentaires et / ou des commentaires sur ce blog.
Méthodes de mesure de la taille non fonctionnelle
Alors que les méthodes de mesure de la taille fonctionnelle ne mesurent que la taille des exigences fonctionnelles des utilisateurs (ce que le logiciel devrait offrir à l'utilisateur), les méthodes de mesure de taille non fonctionnelle mesurent (fait souvent partie du) exigences des utilisateurs non fonctionnels, qui peuvent être les exigences techniques des utilisateurs et / ou les exigences des utilisateurs de qualité (comment le logiciel doit fonctionner). La mesure du code livré est également considérée comme une mesure de taille non fonctionnelle.
La mesure de taille non fonctionnelle la plus utilisée est les lignes de code source (slocs).
Lignes de code source (slocs)
Les lignes de code source plaisent à de nombreuses personnes et organisations car une fois que le système logiciel est prêt, il peut être compté automatiquement par les compteurs de code source. Souvent, les outils de développement mesurent déjà les lignes de code pendant le projet.
De nombreuses organisations utilisent la mesure slocs comme entrée pour leurs processus d'estimation de projets logiciels. C'est remarquable, car le nombre de slocs ne peut être mesuré qu'après achèvement. Cela signifie que pour utiliser des slocs dans l'estimation logicielle, les slocs doivent être estimés, non mesuré. Habituellement, une équipe d'experts estime ensemble le nombre de lignes de code source pour le nouveau projet et / ou utilise des méthodes d'analogie par rapport aux projets déjà achevés afin de fournir une estimation de la taille du logiciel à livrer..
Bien que cela semble être une bonne idée, cette méthode comporte des risques importants pour l'estimation de l'effort. Il n'y a pas de norme ISO (ou toute autre norme) disponible pour les lignes de code source. Différents outils de comptage de code renvoient un (parfois complètement) résultat différent après avoir compté le même code. Parfois, les lignes physiques sont mesurées, mais aussi souvent les déclarations source sont comptées à la place. Puisqu'une instruction peut facilement être écrite sur plusieurs lignes, cela met déjà en évidence un gros problème.
en outre, le nombre de lignes de code source nécessaires dépend de facteurs comme l'environnement technique, complexité et capacités de programmation. Les lignes de code source ne représentent pas non plus vraiment de valeur pour les utilisateurs. Est-il préférable d'avoir plus de lignes de code ou moins de lignes de code? Plus de lignes peuvent signifier plus de fonctionnalités, mais si l'on payait un fournisseur sur la base d'un prix par 1000 lignes de code source une chose est sûre ... le client recevrait beaucoup de code! Les compteurs de code ne doivent pas mesurer le code généré par les outils de développement, mais en réalité il est impossible pour ces outils d'exclure le code généré de la mesure.
Par conséquent, il est généralement très difficile d'utiliser les slocs d'un projet logiciel terminé comme entrée pour le prochain projet logiciel. Utiliser des experts pour estimer le nombre total de lignes de code source pour un nouveau projet, puis utiliser des données historiques basées sur des lignes de code source est extrêmement risqué. En estimant de cette manière, il existe déjà un pourcentage d'incertitude important dans le paramètre d'entrée principal de l'estimation.
Donc, pourquoi de nombreuses organisations estiment-elles leurs projets de cette façon? Quelques publications, par exemple ‘Origines des défauts logiciels et méthodes de suppression‘ par Capers Jones, déclarer que l'estimation des projets de cette façon est une forme de faute professionnelle. Cela peut fonctionner parfois, mais le risque encouru est énorme et les projets qui échouent avec d'énormes dépassements ne peuvent probablement pas être évités. En réalité, c'est exactement ce qui est souvent négligé. Il y a généralement beaucoup de choses qui ne vont pas dans les grands projets, et à la fin il est presque toujours possible de «blâmer» certains problèmes opérationnels qui apparaissent toujours lors d’un projet logiciel… un problème technique, ou un Product Owner qui n'était pas suffisamment impliqué, ou l'environnement OTAP n'a pas été implémenté assez rapidement, ou le client a beaucoup changé ses exigences pendant le projet… et ainsi de suite. Dans la plupart des cas de pannes logicielles cependant, lors de l'analyse de la cause réelle, cela prouve que le projet a démarré avec des attentes trop optimistes… l'équipe est trop petite, la durée trop courte, les coûts trop bas. Estimations d'experts, et des estimations qui ne sont pas basées sur les normes de l'industrie et les données d'expérience commencent généralement par des attentes optimistes. Organisations qui comprennent la relation entre une estimation réaliste et le résultat du projet, se concentrera sur la mise en œuvre d'instruments leur permettant d'estimer le projet le plus précisément possible, pas non plus des estimations trop optimistes fournies par les fournisseurs par exemple. pourtant, les organisations doivent atteindre un certain niveau de maturité pour comprendre cela et ce niveau de maturité est encore loin pour de nombreuses organisations du secteur… même pour celles qui se considèrent assez matures!
Théoriquement, les lignes de code source ne sont pas du tout utiles pour l'estimation logicielle. Certaines personnes rapportent des projets réussis estimés de cette façon, mais d'un point de vue théorique, cela pourrait être le résultat du hasard ou de la chance.
Les caractéristiques permettant d'évaluer l'utilité de cette méthode pour l'estimation de projets logiciels sont répertoriées dans le tableau suivant:
| Caractéristique | Oui Non | Remarques |
| Objectif, répétables, vérifiable et défendable | Non | Les slocs ne peuvent être mesurés qu'après l'achèvement du projet. Pour l’estimation de projet, seuls les «slocs supposés» peuvent être utilisés. |
| Données historiques disponibles | Oui | ISBSG R13: 180 projets. pourtant, impossible de vérifier le type de SLOC mesuré. |
| Soutenu par des modèles / outils | Oui | QSM SLIM, SEER pour le logiciel, TruePlanning, COCOMO II. ISBSG |
Points SNAP
SNAP est l'acronyme de «Software Non-Function Assessment Process,”Une méthode de mesure de la taille du logiciel non fonctionnel. Le dimensionnement des points SNAP est censé être un complément à un dimensionnement des points de fonction, qui mesure la taille du logiciel fonctionnel. SNAP est un produit du Groupe d'utilisateurs des points de fonction internationaux (IFPUG), et est dimensionné en utilisant le Manuel des pratiques d'évaluation des logiciels non fonctionnels, maintenant en version 2.2.
SNAP est vaguement connecté à l'ISO 9126 et ISO 25010 normes de qualité logicielle. Il essaie de dimensionner les exigences non fonctionnelles qui sont implémentées dans un projet logiciel. Bien que cela semble être une bonne idée, la méthode SNAP semble manquer sa cible. Il n'offre pas d'instrument de mesure intégré pour toutes les exigences non fonctionnelles et en outre, un certain nombre d'exigences non fonctionnelles très pertinentes ne sont pas du tout mesurées. Un certain nombre d'observations supplémentaires:
- La plupart de la documentation utilisée dans l'industrie n'indique pas explicitement les informations nécessaires sur les exigences non fonctionnelles que SNAP tente de mesurer. en outre, on ne sait pas quoi faire lorsque ces informations sont manquantes. Comptez quand même quelque chose… ou ne comptez rien?
- Pas tous ISO 9126 ou ISO 25010 les catégories d'exigences non fonctionnelles sont mesurées. Même lorsque les points SNAP peuvent être mesurés à l'aide de la méthode publiée, les exigences non fonctionnelles que les gens considèrent comme d'importants inducteurs de coûts (par exemple. performance ou sécurité, etc), sont ignorés;
- On ne sait pas comment la relation entre les différentes catégories SNAP est déterminée et pourquoi cela serait valable. Pourquoi la complexité de l'interface utilisateur (Points SNAP = Nr de propriétés ajoutées ou configurées… 2, 3 ou 4 fois le nombre d'éléments d'interface utilisateur uniques) être de taille non fonctionnelle égale ... ou supérieure à ... ou inférieure à la taille non fonctionnelle mesurée pour les processus par lots (4 fois, 6 fois ou 10 fois le nombre d'attributs de données). Il ne semble y avoir aucun lien pertinent entre les catégories et la façon dont les points SNAP sont mesurés semble arbitraire;
- Le professeur Docteur Abran a fait remarquer que le preuve statistique de la méthode SNAP ne passe pas les tests de validité méthodiques habituels, car il semble que les valeurs aberrantes de l'ensemble de données utilisé pour démontrer la corrélation entre les points SNAP et l'effort ne semblent pas avoir été supprimées;
- Certaines des exigences non fonctionnelles mesurées sont en fait fonctionnelles et sont également mesurées dans les méthodes NESMA et / ou IFPUG. C'est étrange pour une méthode qui prétend uniquement mesurer les exigences non fonctionnelles.
En tout, bien que l'IFPUG et de nombreux praticiens préconisent la méthode SNAP comme une bonne et valide méthode à utiliser pour estimer, d'un point de vue pratique et théorique, il reste encore de nombreux problèmes à résoudre avant que cette méthode ne devienne utile pour l'estimation de projet. Pour le moment, les données historiques du projet mesurées dans SNAP sont très limitées. Dans 2013, l'International Software Benchmarking Standards Group a publié un Formulaire de collecte de données SNAP, mais jusqu'à présent, aucune soumission de projet avec des points SNAP n'a été reçue.
Pour l'instant, au maximum, il peut être utilisé pour essayer de comprendre les différences de performance ou de productivité entre les projets achevés, mais il ne convient pas encore pour l'estimation de projet.
Les caractéristiques permettant d'évaluer l'utilité de cette méthode pour l'estimation de projets logiciels sont répertoriées dans le tableau suivant:
| Caractéristique | Oui Non | Remarques |
| Objectif, répétables, vérifiable et défendable | Non | Le manuel SNAP doit garantir une mesure objective, mais comme on ne sait pas quoi faire lorsque les informations nécessaires manquent, les mesureurs sont susceptibles de faire des hypothèses différentes résultant en une taille différente. |
| Données historiques disponibles | Non | ISBSG capture les projets en points SNAP, mais aucune donnée n'a encore été soumise. Il existe peut-être des données disponibles dans le groupe IFPUG SNAP. |
| Soutenu par des modèles / outils | Non |
Blog suivant
Dans le prochain blog sur ce sujet, Je donnerai mon avis sur l'utilité des principales méthodes de mesure de taille hybrides pour l'estimation de projets logiciels.
A propos de l'auteur
Harold van Heeringen est consultant senior en benchmarking chez Metri. En dehors de son travail pour Metri, il est impliqué dans Nesma (membre d'équipage), le Groupe des normes Benchmarking Software International (ISBSG, président actuel) et le Consortium international Common Software Metrics (COSMIQUE, Conseil consultatif international, représentant les Pays-Bas).