Comptage FPA des services Web

[Ilie Boarescu]

Je vous écris au sujet de la méthode que nous devrions utiliser pour compter FPA dans les projets qui utilisent des services Web. Peut-être que tu peux m'aider avec un peu de perspicacité.
Je décrirai deux scénarios hypothétiques afin d'expliquer la situation.

1. Scénario standard - pas de services Web

Exigences:
L'utilisateur doit pouvoir créer, afficher et modifier les informations sur le produit. Dans cette situation, nous compterions:

Transaction	Type	Complexité	Points de fonction
Produit	ILF	Faible	7
Créer un produit	NON	Moyenne	4
Voir le produit	EQ	Moyenne	4
Modifier le produit	NON	Moyenne	4
Total			19

2. Notre scénario - les services Web doivent être utilisés

Exigences:
L'utilisateur doit pouvoir créer, afficher et modifier les informations sur le produit.
Les données sur le produit sont stockées dans une autre application. L'application à développer doit envoyer et récupérer des données via des services web.

Dans cette situation, on peut considérer que la deuxième application qui stocke les informations sur le produit est un deuxième utilisateur.
Nous comptons une transaction pour chaque ensemble de données qui franchit la limite de l'application.

Transaction	Type	Complexité	Points de fonction
Créer un produit	NON	Moyenne	4
Demande: Créer un produit	EQ	Moyenne	4
Répondre: Créer un produit	NON	Moyenne	4
Afficher les détails du produit	EQ	Moyenne	4
Demande: Détails du produit	EQ	Moyenne	4
Répondre: Détails du produit	NON	Moyenne	4
Mettre à jour les détails du produit	NON	Moyenne	4
Demande: Mettre à jour les détails du produit	EQ	Moyenne	4
Répondre: Mettre à jour les détails du produit	NON	Moyenne	4
Total			36

Cette approche est-elle correcte? Quel genre d'expérience avez-vous avec ce genre de situations?

[Martin Jacobs]

Bonjour Ilie,

Je traite une situation comme celle-ci comme indiqué ci-dessous.

• Point de départ: Nesma FPA.

Scénario standard
Ici, nous avons un système et une frontière de système à considérer. Comptez cela comme indiqué.

services Web
Ici, nous avons deux systèmes et deux limites de système à considérer (nous ne considérons pas possible ESB comme système indépendant entre les deux pour cet exemple).

Systèmes:
• L'extrémité avant (FE) pour l'utilisateur final
• Backend (ÊTRE) pour le stockage des données

Le FE envoie des messages au BE et reçoit des messages du BE. Les services Web gèrent les messages et font partie de la FE. Le FE peut être considéré comme un utilisateur du BE (la FE a la tête).
Le système à compter est le FE, l'hypothèse est que le BE existe et ne change pas.

Sur cette base, nous pouvons affirmer que:
• La FE n'a pas d'ILF, ils sont dans le BE.
• Les services Web n'ont pas leur propre frontière.
• ÊTRE: rien à compter.
• Compter: uniquement le FE incluant les services web.

Donc dans la FE, nous recherchons des fonctions transactionnelles. Une fonction transactionnelle est un, fonction élémentaire du point de vue de l'utilisateur. Tenez compte du fait que les messages à destination et en provenance du BE ne sont pas élémentaires. Ils font partie des transactions des utilisateurs.

Alors on compte:
• Créer la moyenne EI du produit 4
• Voir le produit EQ Average 4
• Modifier la moyenne EI du produit 4
Total 12
Dans votre 2. Notre scénario, vous ne comptez pas non plus pour la deuxième candidature, comme vous le considérez comme un utilisateur. Vous considérez donc les messages de cet utilisateur comme uniques, fonctions élémentaires. Selon les définitions de Nesma (par exemple. 7.1) ils ne sont pas élémentaires cependant, donc ils ne devraient pas être comptés.

Si le BE change, alors les messages et / ou les ILF doivent être comptés, pour ce BE, toujours pas pour le FE.

J'espère que cela t'aides!

Cordialement,
Martin Jacobs
QSM Europe

[EdwinvanGorp]

Bonjour Ilie,

Ce n'est pas une question facile à répondre.

Tout d'abord: Avec FPA, vous mesurez la taille de la fonctionnalité qu'une application fournit à un utilisateur (Directives Nesma; v2.1; section 3.1.2).

Maintenant, ajoutons un troisième scénario.
Exigences:
L'utilisateur doit pouvoir créer, afficher et modifier les informations sur le produit.
Les données sur le produit sont stockées dans une autre application, directement par l'application à mesurer.

Dans le scénario 1, vous avez une application de la taille de 19 FP.
Dans le scénario 3, l'application fait exactement la même chose du point de vue de l'utilisateur final (l'utilisateur qui doit pouvoir créer, afficher et modifier les informations sur le produit). Donc, dans les deux scénarios, cet utilisateur bénéficie exactement de la même fonctionnalité. Cela signifie que la taille de la fonctionnalité (du point de vue des utilisateurs finaux) dans les deux scénarios devrait être le même (dans ce cas: 19 FP).

Maintenant ma question est: quel est, logiquement, la différence entre votre scénario 2 et mon scénario 3?
Les webservices mentionnés font partie de la première application et sont capables de stocker et d'éditer les données directement dans le fichier logique, donc il n'y a aucune différence. Et cela signifie que la taille fonctionnelle de la première application est toujours 19 FP, s'il utilise des services Web ou non (les services Web sont une implémentation technique de la fonctionnalité requise).
Ou, pour le dire différemment, les exigences de l'utilisateur final ne changent pas lorsque vous décidez d'utiliser les services Web pour répondre à ces exigences.

[Alexander Vermeulen]

Alors Martin et Edwin,Ce qu'il faut compter pour le développement des webservices dans le backend BE?

Disons que le BE a déjà mis en place les tableaux de produits, mais ne disposez pas des services Web pour fournir les fonctionnalités nécessaires à la prise en charge de Front End?
Pour cela, le BE obtiendra 3 services Web:
* CréerProduit
* GetProduct
* Mettre à jour le produit

Ce qu'il faut compter pour cette fonctionnalité?

[SueHannan]

salut, s'il vous plaît dites-moi dans le scénario 3, L'application en cours de dimensionnement est-elle propriétaire du fichier produit? Ensuite, dans ce cas, je peux voir que la taille est la même. pourtant, si le fichier produit appartient à une application en dehors du système compté, il sera considéré comme un FEI et changera donc la taille.

Je vois clairement comment le scénario 1 et 2 dans la première conversation aboutirait au même 19 FP suppose que le fichier produit appartient à l'application en cours de dimensionnement.

Maintenant, posons cette question, que se passe-t-il si le service Web fait référence à un fichier en dehors de la limite comme dans le cas de google maps, alors on garderait tout pareil sauf qu'au lieu d'un ILF ce serait un FEI?

[Frank Vogelezang]

Dans le scénario 3, comme proposé par Edwin, les webservices font partie de l'application à compter. Je n'ai aucun problème avec le décompte.

La réponse d'Alexandre fait référence à quelque chose que je vois assez souvent, c'est-à-dire que le système back-end propose des webservices pour traiter les requêtes sur les données. Lorsque ces services doivent être construits dans le système back-end, ils seront comptés de la même manière que le scénario 3.

La taille fonctionnelle d'un système frontal ne changera pas, si les services Web sont disponibles ou non. La fonctionnalité qui doit être fournie à l'utilisateur est la même. La productivité sera très différente lorsque la fonctionnalité peut être fournie en appelant des services Web existants plutôt qu'en créant le mécanisme complet pour gérer les données dans le système back-end.

Concernant la première remarque de Sue: Lorsque l'application est capable de modifier ou de créer les données dans le système back-end, le fichier-produit est par définition un ILF, indépendamment du fait que les architectes disent que les données produit appartiennent au système back-end.

[Auteur]

Des postes