FPA telling van web-services

[Elia Boarescu]

Ik schrijf u over de methode die we moeten gebruiken bij het tellen van FPA in projecten die webservices gebruiken. Misschien kunnen jullie mij helpen met wat inzicht.
Ik zal twee hypothetische scenario's beschrijven om de situatie uit te leggen.

1. Standaardscenario – geen webservices

Deze tool is gebaseerd op Natural Language Processing en kan tekst in het Engels en Nederlands lezen:
De gebruiker moet kunnen creëren, Productinformatie bekijken en bewerken. In deze situatie zouden we optellen:

Transactie	Type	Complexiteit	Functie punten
Product	ILF	Laag	7
Product maken	NIET	Gemiddelde	4
Bekijk product	EQ	Gemiddelde	4
Product bewerken	NIET	Gemiddelde	4
Totaal			19

2. Ons scenario – webservices moeten worden gebruikt

Deze tool is gebaseerd op Natural Language Processing en kan tekst in het Engels en Nederlands lezen:
De gebruiker moet kunnen creëren, Productinformatie bekijken en bewerken.
De gegevens over het product worden opgeslagen in een andere applicatie. De te ontwikkelen applicatie moet data versturen en ophalen via webservices.

In deze situatie, we kunnen ervan uitgaan dat de tweede applicatie die de productinformatie opslaat, een tweede gebruiker is.
Voor elke set gegevens die de grens van de applicatie overschrijdt, tellen we een transactie.

Transactie	Type	Complexiteit	Functie punten
Product maken	NIET	Gemiddelde	4
Verzoek: Product maken	EQ	Gemiddelde	4
Antwoord: Product maken	NIET	Gemiddelde	4
Bekijk productdetails	EQ	Gemiddelde	4
Verzoek: Productdetails	EQ	Gemiddelde	4
Antwoord: Productdetails	NIET	Gemiddelde	4
Productdetails bijwerken	NIET	Gemiddelde	4
Verzoek: Productdetails bijwerken	EQ	Gemiddelde	4
Antwoord: Productdetails bijwerken	NIET	Gemiddelde	4
Totaal			36

Is deze aanpak juist? Wat voor ervaring heb jij met dit soort situaties?

[Martin Jacobs]

Hallo Ilie,

Ik behandel een situatie als deze zoals hieronder aangegeven.

• Vertrekpunt: Nesma FPA.

Standaardscenario
Hier moeten we rekening houden met één systeem en één systeemgrens. Tel dit zoals aangegeven.

webservices
Hier hebben we twee systemen en twee systeemgrenzen waarmee we rekening moeten houden (voor dit voorbeeld beschouwen we mogelijke ESB niet als een onafhankelijk tussensysteem).

Systemen:
• Voorkant (FE) voor de eindgebruiker
• Backend (ZIJN) voor de dataopslag

De FE verzendt berichten naar BE en ontvangt berichten van de BE. De webservices verzorgen de berichten en zijn onderdeel van de FE. De FE kan worden beschouwd als gebruiker van de BE (de FE heeft de leiding).
Het te tellen systeem is de FE, De veronderstelling is dat de BE bestaat en niet verandert.

Op basis hiervan kunnen we dat stellen:
• De FE heeft geen ILF's, ze staan ​​in BE.
• De webservices hebben geen eigen grens.
• ZIJN: niets te tellen.
• Tellen: alleen de FE inclusief de webservices.

In de FE zijn we dus op zoek naar transactionele functies. Een transactionele functie is uniek, elementaire functie vanuit het oogpunt van de gebruiker. Houd er rekening mee dat de berichten van en naar de BE niet elementair zijn. Ze maken deel uit van de gebruikerstransacties.

Dus wij tellen:
• Maak een product-EI-gemiddelde 4
• Bekijk product EQ Gemiddeld 4
• Bewerk het EI Gemiddelde product 4
Totaal 12
In uw 2. onze scenario, Ook voor de tweede aanvraag telt u niet mee, zoals jij het als gebruiker beschouwt. U beschouwt de berichten van die gebruiker dus als uniek, elementaire functies. Volgens Nesma-definities (bv. 7.1) ze zijn echter niet elementair, ze mogen dus niet meegeteld worden.

Als de BE verandert, dan moeten berichten en/of ILF's worden geteld, voor deze BE, nog steeds niet voor de FE.

Ik hoop dat dit helpt!

vriendelijke groeten,
Martin Jacobs
QSM Europe

[EdwinvanGorp]

Hallo Ilie,

Dit is geen gemakkelijke vraag om te beantwoorden.

omdat het het belang van deze maatregel ernstig vermindert: Met FPA meet je de omvang van de functionaliteit die een applicatie aan een gebruiker biedt (Nesma-richtlijnen; v2.1; sectie 3.1.2).

Nu, laten we een derde scenario toevoegen.
Deze tool is gebaseerd op Natural Language Processing en kan tekst in het Engels en Nederlands lezen:
De gebruiker moet kunnen creëren, productinformatie bekijken en bewerken.
De gegevens over het product worden opgeslagen in een andere applicatie, direct door de applicatie die gemeten moet worden.

In scenario 1, je hebt een applicatie met de grootte van 19 FP.
In scenario 3, de applicatie doet precies hetzelfde vanuit het oogpunt van de eindgebruiker (de gebruiker die moet kunnen creëren, productinformatie bekijken en bewerken). Zo, in beide scenario’s krijgt deze gebruiker exact dezelfde functionaliteit aangeboden. Dit betekent dat de omvang van de functionaliteit (vanuit het oogpunt van de eindgebruiker) in beide scenario's zou hetzelfde moeten zijn (in dit geval: 19 FP).

Nu is mijn vraag: wat is, logisch, het verschil tussen uw scenario 2 en mijn scenario 3?
Genoemde webservices maken deel uit van de eerste applicatie en kunnen de gegevens rechtstreeks in het logische bestand opslaan en bewerken, dus er is helemaal geen verschil. En dat betekent dat de functionele omvang van de eerste applicatie nog steeds aanwezig is 19 FP, of het nu webservices gebruikt of niet (webservices zijn een technische implementatie van de benodigde functionaliteit).
Of, anders gezegd, de eisen die de eindgebruiker heeft veranderen niet wanneer u besluit webservices in te zetten om aan deze eisen te voldoen.

[Alexander Vermeulen]

Dus Martin en Edwin,Wat te tellen voor het ontwikkelen van de webservices in de backend BE?

Laten we zeggen dat BE de producttabellen al heeft opgesteld, maar beschikken niet over de webservices voor het leveren van de functionaliteit ter ondersteuning van Front End?
Hiervoor krijgt de BE 3 webservices:
* CreëerProduct
* Product ophalen
* Product bijwerken

Wat te tellen voor die functionaliteit?

[SueHannan]

Hoi, Vertel het me alsjeblieft in Scenario 3, is de applicatie waarvan de grootte wordt bepaald, eigenaar van het productbestand? Dan zie ik dat de maatvoering hetzelfde is. Echter, Als het productbestand eigendom is van een applicatie buiten het systeem dat wordt geteld, wordt het als een EIF beschouwd en wordt de grootte gewijzigd.

Ik zie echter duidelijk hoe het scenario is 1 en 2 in het eerste gesprek zou hetzelfde resulteren 19 FP gaat ervan uit dat het productbestand eigendom is van de applicatie waarvan de grootte wordt bepaald.

Nu, laten we deze vraag stellen, wat als de webservice verwijst naar een bestand buiten de grens, zoals in het geval van Google Maps, dan zouden we alles hetzelfde houden, behalve dat het in plaats van een ILF een EIF zou zijn?

[Frank Vogelezang]

In scenario 3, zoals voorgesteld door Edwin, de webservices maken deel uit van de te tellen applicatie. Ik heb geen probleem met de telling.

Het antwoord van Alexander verwijst naar iets dat ik heel vaak zie, dat wil zeggen dat het back-endsysteem webservices aanbiedt om verzoeken om de gegevens af te handelen. Wanneer deze services in het back-endsysteem moeten worden ingebouwd, worden ze op dezelfde manier geteld als in het scenario 3.

De functionele omvang van een front-end systeem verandert niet, of de webservices beschikbaar zijn of niet. De functionaliteit die aan de gebruiker moet worden geboden, is dezelfde. De productiviteit zal heel anders zijn wanneer de functionaliteit kan worden geleverd door bestaande webservices aan te roepen in plaats van het volledige mechanisme te bouwen om de gegevens in het back-endsysteem te verwerken.

Wat betreft de eerste opmerking van Sue: Wanneer de applicatie de gegevens in het back-endsysteem kan wijzigen of aanmaken, het productbestand is per definitie een ILF, ongeacht het feit dat de architecten zeggen dat productdata tot het back-endsysteem behoort.

[Auteur]

Berichten