Évaluation de Projet utilisant Métrique de Cas d’Utilisation
Enterprise Architect fournit un outil d’estimation complet de projet qui calcule l’effort de cas d’utilisation et des objets d’acteur, couplés avec des
configurations de projet définissant la complexité de l'environnement de travail. Cette méthode est basée sur le Cas d’Utilisation de Karner Dirige la Méthode,
avec plusieurs variations indiquées ci-dessous. Vous pouvez également produire un rapport contenant l'analyse des paramètres d’estimation du projet à intégrer
dans la documentation de votre projet.
Un l’exemple est ici .
Avant d’estimer la taille du projet, vous devrez d’abord configurer les facteurs techniques et environnementaux (voir la Configuration d’article de menu - la Métrique et des Types d’Évaluation - TCF et des valeurs d’ECF). Pour les deux TCF (technique facteur de complexité) et ECF (environnement facteur de complexité), une table modifiable contient une liste de facteurs qui influent sur la productivité du projet. Un poids est associé à chaque élément, ce qui reflète la quantité de facteur qui affecte la productivité relativement; un poids inimportante à un projet. Les facteurs fournis et leurs poids associés sont définis par la méthode des points de cas d’utilisation, même si elles peuvent être adaptées aux besoins spécifiques d’un projet. Pour la plupart des fins, la seule colonne de table besoin ajustement sera 'Valeur', qui indique le degré d’influence d’un facteur particulier détient sur le projet. Comme un indicateur suggéré, une valeur 'de 0' indique aucune influence, 'un 3' indique que l'influence moyenne et 'un 5' indique l’influence forte.
Comme vous construisez votre projet en utilisant des cas d’utilisation UML pour décrire la fonctionnalité proposée, vous devriez assigner une évaluation à chaque cas d’utilisation:
- Facile (5 points): Le cas d’utilisation est considéré comme un simple morceau de travail, utilise une interface utilisateur simple et touche seulement une entité de base de données seule; son scénario de réussite a moins de 3 étapes; sa mise en ouvre implique moins de 5 classes
- Moyen (10 points): Le cas d’utilisation est plus difficile, implique plus de design d’interface et touche deux ou plusieurs entités de base de données; son scénario de réussite a entre 4 et 7 pas; sa mise en oeuvre implique de 5 à 10 classes
- Complexes (15 points): Le cas d’utilisation est très difficile, implique une interface utilisateur complexe ou de la transformation et touche trois ou plusieurs entités de base de données; son scénario de réussite a plus de sept pas; sa mise en ouvre implique plus de 10 classes
Le ci-dessus sont différentes méthodes acceptées pour attribuer complexités, mais servir de lignes directrices rugueuses. Si vous écrivez une application sans persistance, mais un traitement complexe, vous devrez utiliser votre jugement pour assigner des évaluations de complexité.
Alors que la construction des cas d’utilisation, noter que vous pouvez également leur assigner aux phases (par exemple 1.0, 1.1) et plus tard Filtrez votre estimation basée sur la phase. Vous pouvez également saisir un texte libre dans le champ de Tag d’un cas d’utilisation et filtrer l'estimation basée sur des informations d’étiquette (par exemple < URGENT >).
La méthode UCP de Karner calcule également les efforts du projet en considérant les acteurs du projet, et leur complexité de contribution. Il ya une option pour inclure les acteurs dans le calcul d’évaluation; par défaut, seulement des cas d’utilisation sont considérés. Si les acteurs du projet sont également inclus, assurez-vous de leur complexité a été affecté par une méthode; des lignes directrices générales à cette attribution sont fournis ci-dessous:
- Facile: l’acteur représente un autre système avec une API définie
- Moyen: l’acteur représente un autre système interagissant par un protocole, comme le TCP/IP
- Complexe: l’acteur est une personne interagissant via une interface.
Que vous avez installé les cas d’utilisation, des acteurs et d’environnement, mettre en évidence le paquetage dans le navigateur de projet dont le contenu vous voudriez évaluer; pour l’ensemble du projet, sélectionnez la vue racine. Ensuite, sélectionnez Projet - Métrique de Cas d’Utilisation du menu. L’écran suivant apparaît:
Ces détails les informations de complexité pour votre projet:
| 1. | Le facteur de complexité technique est calculé des valeurs que vous mettez |
| 2. | La complexité environnementale est calculée des valeurs que vous mettez |
| 3. | Les points de cas d’utilisation non ajustés (UUCP) = la somme de complexité de cas d’utilisation ratings* |
| 4. | L'UUCP est multiplié ensemble avec le TCF et les facteurs ECF pour produire un Cas d’Utilisation pondérée Nombre de Points (UCP) |
| 5. | Le nombre résultant est multipliée avec les heures par défaut par UCP pour produire une estimation finale |
| 6. | Les heures moyennes par Cas d’Utilisation facile, moyen et difficile sont aussi affichées |
* Bien que la méthode UCP de Karner recommande d’exclure inclus et étendant les cas d’utilisation dans ce compte, Enterprise Architect examine tous les cas d’utilisation dans son calcul. Si ces cas d’utilisation exigent que la fonctionnalité soit développée, l'effort qui reste existe et doit être pris en compte.
Un facteur critique est la variable des 'Heures de défaut' - qui est le mieux définie en utilisant l'expérience de projets similaires. Bien que le défautd’ EA soit mis à 10 heures, cette variable pourrait facilement excéder 30 heures, selon l'environnement.
La meilleure façon de configurer avec précision un nouveau projet à votre environnement unique est en considérant les cas d’utilisation de projets achevés. Après la configuration d’un projet réalisé comme indiqué ci-dessus, et l'exécution d’un rapport de mesures, les facteurs disponibles peuvent être ajustés pour donner une estimation correspondant aux heures réelles. Ensuite, vous pouvez commencer à utiliser ces chiffres comme votre ligne des bases.
Notez qu’un bon contrôle de validité est de regarder les "Heures Ave par cas d’utilisation" chiffre: si vous croyez que vous pouvez construire un cas d’utilisation facile dans le temps permis (y compris vos procédures de conception, les tests, la documentation, la révision, etc.) et le moyen et difficile de même, alors vous êtes sur la bonne voie.
Ne vous attendez pas une réponse magique à la question 'combien?' ou "combien de temps?" - Recueillir des statistiques et de l'expérience pour guider les estimations de nouveaux projets.