Quelles sont les métriques à utiliser et comment faire des calculs si écrire des spécifications pour un nouveau projet de programmation en vaut la peine et passer du temps (et de l'argent)?Quelles sont les mesures à calculer si l'écriture d'une spécification en vaut la peine?
Je pense que vous vous retrouverez dans un coin inconfortable si vous essayez d'utiliser n'importe quelle mesure pour prédire ou contrôler définitivement le résultat de votre projet. En fin de compte, votre sponsor/propriétaire du projet posera les questions "combien de temps/combien"? Le mieux que vous puissiez faire est une de prévision qui est basée sur votre connaissance actuelle du projet à ce moment-là - et cela vient juste de l'expérience et devine littéralement.
Et voici la capture: vos estimations seront probablement de plusieurs ordres de grandeur. Ils deviennent seulement plus précis que votre équipe comprend le domaine du problème et ils estiment pas plus de 2-4 semaines en avant, max. Barry Boehm (et Steve McConnell) illustre cet effet avec le principe du « cône d'incertitude »:
Plus vous êtes de la mise en œuvre d'un système ou d'une fonction (côté gauche), plus la innacuracy de votre estimations (-0.25x - 4x).À mesure que vous vous rapprochez, et que vous comprenez mieux le problème, les estimations commencent à prendre plus de précision (0,8x - 1,0x). C'est pourquoi, dans les projets logiciels où il y a beaucoup de «bruit» ou de «complexité» (c'est-à-dire presque tous les projets), nous voulons laisser une estimation concrète jusqu'au dernier moment responsable - pas plus de 2 à 4 semaines.
Vous pouvez également vous attendre à une chose avec une certitude absolue: Les spécifications vont changer avec le temps. Comment vous prévoyez d'adapter et de gérer ce changement permettra de mesurer votre succès. Donc, le meilleur jugement qui peut être fait pour évaluer votre travail serait de réunir l'équipe qui travaillera sur le projet et le «client» pour élaborer ensemble les grands coups de pinceau - les principales caractéristiques du projet. Écrivez-les comme des user stories que l'équipe estime en utilisant des points de poids relatifs (voir le livre de Mike Cohn sur Agile Estimating and Planning) et élaborez un plan de lancement qui fournira au client une prévision provisoire sur ce qu'il faut prévoir. l'investissement générera le rendement recherché.
Bien sûr, je suppose que vous allez sortir tôt/souvent afin que votre client soit toujours en possession d'un incrément fonctionnel du produit final - essentiel pour leur évaluation continue du projet.
En général, petit, simple, projet non critique: pas de spécifications. Projet important, complexe et critique: définitivement les spécifications.
Il n'y a peut-être pas de métriques coupées ici. Vous devrez compter sur votre jugement en génie logiciel.
En général, vous devez toujours écrire les spécifications. Vous devriez avoir besoin d'être convaincu pas à.
Les objectifs et les visions d'affaires globaux. J'aime le « test d'ascenseur » - pour être en mesure d'expliquer ce que votre produit fait dans moins de deux minutes:
pour (client cible)
qui (déclaration de besoin ou d'opportunité)
le (nom du produit) est une (catégorie)
que (avantage clé, raison impérieuse d'acheter)
contrairement (principale alternative compétitive)
notre produit (déclaration de différenciation primaire)
(du livre de Geoffrey Moore Crossing the Chasm)
Peut-être que cela ne répond pas à votre question, mais écrire un si petit « cahier des charges » pourrait être fait pour n'importe quel projet.