Introductie Use Case Point Analyse
SYSQA B.V. Almere
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
2 van 10 1.2 16-03-2011
Inhoudsopgave 1
Managementsamenvatting .............................................................................. 3
2
Inleiding ............................................................................................................ 4
3
Use Case Points ............................................................................................... 5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
Geschiedenis van de Use Case ......................................................................... 5 Use Case Points ................................................................................................ 5 Bepalen van de Unadjusted Use Case Points .................................................... 5 Bepalen van de technische complexiteit ............................................................. 6 Bepalen van de omgevingscomplexiteit ............................................................. 7 Bepalen van de Adjusted Use Case Points ........................................................ 7 Het afleiden van de begroting ............................................................................ 8 Relativering van de waarde van de begroting ..................................................... 8
4
Test Case Point Analyse ................................................................................. 9
5
Gebruikte literatuur ........................................................................................ 10
Versiebeheer Versie 0.1 1.0 1.1 1.2
Datum 10-08-2008 18-08-2008 16-03-2010 16-03-2011
Opmerkingen Initiele versie, ter review voor expertisegroep Definitief gemaakt Opmerking Sysqa verwerkt Aanpassen opmaak
Almere © 2011
Auteur Sysqa Sysqa Sysqa Sysqa
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
3 van 10 1.2 16-03-2011
1 Managementsamenvatting Deze introductie beschrijft de Use Case Point Analyse. Use Case Point Analyse is gebaseerd op het gebruik van UML, Unified Modeling Language. Binnen UML wordt er gebruikt gemaakt van Use Cases. Op basis van deze Use Cases is het mogelijk de (test)begroting op te stellen. De stappen die hiervoor ondernomen moeten worden, worden in dit document beschreven. Tevens wordt er kort stilgestaan bij de Test Case Point Analysis. Deze introductie is in samenhang met de introductie Test begrotingen en planning geschreven.
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
4 van 10 1.2 16-03-2011
2 Inleiding Een effectieve begroting van een software ontwikkeltraject is één van de moeilijkste en belangrijkste activiteiten van een software project. Een tijdige oplevering van de software aan de opdrachtgever kan niet bereikt worden zonder een accurate en betrouwbare begroting. Er zijn meerdere populaire modellen voor het begroten van test impacts. Traditioneel zijn deze begrotingsmethodieken in meer of in mindere mate gebaseerd op verhoudingsgetallen, toeslag percentages enz. Maar geen van de modellen sluit goed aan bij begroten van testtrajecten gebaseerd op het gebruik van Use Cases in het ontwikkeltraject. Dit terwijl de Use Cases een goede basis kunnen vormen voor het bepalen van de systeemgrootte. Use Case Point Analyse werkt op een vergelijkbare manier als FunctiePuntAnalyse (FPA), zie introductie functiepuntanalyse [6]. Daar waar de Engelse termen meer algemeen gebruikt en bekend zijn dan de Nederlandse termen, worden de Engelse termen gebruikt.
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
5 van 10 1.2 16-03-2011
3 Use Case Points 3.1 Geschiedenis van de Use Case De basis van de Use Case werd in het einde van de jaren ’60 gelegd bij Ericsson door Ivar Jacobson. Ericsson had haar systeem opgedeeld in blokken die met elkaar verbonden waren. In UML werd dit later bekend als ‘subsystems’. Deze blokken werden vastgesteld op wat toen ‘trafic cases’ werden genoemd, later bekend als Use Cases [3,5]. In 1987 heeft Jacobsen een tekentechniek ontwikkeld voor het concept Use Case [3]. In 1992 bedacht Jacobsen de software ontwikkelmethodiek OOSE (Object Oriented Software Engineering). Dit is een Use Case gedreven methode waarbij Use Cases gebruikt worden voor alle stadia van software ontwikkeling. Inclusief analyse, ontwerp en test [3]. In 1993 heeft Gustav Karner een use case point methode ontwikkeld voor het begroten van object georiënteerde software [3,4]. Alistair Cockburn heeft het ‘Actors and Goals’ concept geïntroduceerd als handleiding voor het schrijven en structureren van Uses Cases. Hij onderscheidt 5 niveaus van Use Cases [1,3]: Very high summary Summary User Goal Sub function Too low Cockburn adviseert de gebruiker vooral op User Goal niveau een goed doordachte set van Use Cases te beschrijven. Dit is ook het laagste niveau waarop de Use Case nog waarde heeft voor de business [1]. In het document van Kirsten Ribu [3] is het gehele concept van Use Cases en Actors and Goals zeer duidelijk uitgewerkt.
3.2 Use Case Points Het aantal Use Case Points in een project is afhankelijk van de volgende factoren [1,3,4]: Aantal en complexiteit van de Use Cases in het systeem Aantal en complexiteit van de Actors in het systeem Non-functional requirements zoals portabiliteit, performance en onderhoudbaarheid die niet beschreven worden in Use Cases De omgeving waarin het project ontwikkeld wordt (taal, team motivatie, ervaring en kennis) Op basis van de eerste twee factoren worden de zogenaamde Unadjusted Use Case Points bepaald. Op basis van de laatste twee factoren worden de Unadjusted Use Case Points gecorrigeerd tot Adjusted Use Case Points. De gedetailleerde werkwijze hiervoor is weergegeven in paragraaf 3.3 tot en met 3.6. De Use Cases die worden gebruikt voor het begroten, moeten allen op hetzelfde niveau zijn, bij voorkeur op het User Goal niveau [1].
3.3 Bepalen van de Unadjusted Use Case Points Allereerst moeten de Use Cases en de Actors geclassificeerd worden om de Unadjusted Use Case Points (UUCP) te bepalen. Dit wordt gedaan op basis van het aantal Use Cases en Actors en wordt hieronder beschreven.
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
6 van 10 1.2 16-03-2011
3.3.1 Classificatie van Use Cases De Use Cases worden in 3 groepen onderverdeeld, afhankelijk van het aantal transacties (stappen in een use case) die ze te weeg brengen. Op basis van deze onderverdeling wordt de relatieve complexiteit bepaald. Door het aantal Use Cases per groep te bepalen en te vermenigvuldigen met de bijbehorende factor wordt de Unadjusted Use Case Weights (UUCW) bepaald. Het volgende rekenmodel wordt hiervoor voorgeschreven[1,3]: Type Use Case Aantal transacties Factor Aantal Use Cases Totaal Simpel 3 of minder 5 Gemiddeld 4 tot en met 7 10 Complex meer dan 7 15 Totaal UUCW
De kolom ‘Totaal’ wordt bepaald door het aantal Use Cases te vermenigvuldigen met de factor. Het ‘Totaal UUCW’ is de sommatie van deze totalen. Szongott gebruikt dezelfde klassen met dezelfde factoren, alleen vindt de classificatie niet plaats enkel op basis van ‘aantal transacties’. Hij hanteert het type use case waarbij naast het aantal transacties ook naar het aantal geraadpleegde gegevensbronnen (databanken) en aantal gegevensgroepen (classes) wordt gekeken [4].
3.3.2 Classificatie van Actors Ook de Actors worden in drie klassen onderverdeeld, net als de Use Cases. Een Actor uit de eenvoudigste klasse is bijvoorbeeld een API (Application Programming Interface). Een gemiddelde Actor is bijvoorbeeld een ander systeem dat middels TCP/IP samenwerkt. Tot slot de complexe Actor. Dat is bijvoorbeeld een gebruiker via een GUI of een webinterface [1,3,4]. Net zoals voor de Use Case de waarde UUCW bepaald moet worden, moet dit ook voor de Actor. Dit heet de Unadjusted Actor Weight (UAW). Het volgende rekenmodel wordt hiervoor voorgeschreven[1,3,4]: Type Actor Simpel Gemiddeld Complex
Factor
Aantal Actors
Totaal
1 2 3
Totaal UAW
Totaal wordt bepaald door het aantal Actors te vermenigvuldigen met de factor.
3.3.3 Bepaling UUCP De bepaling van de Unadjusted Use Case Points is nu als volgt: UUCP = UUCW + UAW
3.4 Bepalen van de technische complexiteit Hierboven is bepaald hoeveel Unadjusted Use Case Points het systeem kent. Nu wordt dit getal aangepast voor de technische complexiteit van het systeem. Hiervoor wordt allereerst de Tfactor bepaald. De TFactor is het totaal van 13 technische items die een rol spelen bij de technische complexiteit. In het onderstaande schema is dat uitgewerkt [1,3,4].
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
Item T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13
Omschrijving Factor Gewicht Distributed System 2 Performance 1 End User Efficiency 1 Complex Internal Processing 1 Reusability 1 Easy to Install 0,5 Easy to Use 0,5 Portability 2 Easy to Change 1 Concurrency 1 Special Security Features 1 Provides Direct Access for Third Parties 1 Special User Training Facilities Are Required 1
7 van 10 1.2 16-03-2011
Totaal
Totaal TFactor
De werking is als volgt. Per technisch item bepaal je het gewicht, het gewicht heeft een waarde tussen de 0 (niet relevant) en 5 (heel belangrijk). Hier komt per item een totaal uit en samen vormen die de TFactor. De Technical Complexity Factor (TCF) wordt dan als volgt bepaald: TCF = 0,6 + (0,01*TFactor)
3.5 Bepalen van de omgevingscomplexiteit Niet alleen de technisch complexiteit heeft invloed op het aantal Use Case Points. Ook de omgeving waarin het project plaatsvindt heeft hier invloed op. Dit gebeurd op basis van 8 omgevingsfactoren, Environmental Factors (EF). In het onderstaande schema is dat uitgewerkt [1,3,4]. Item E1 E2 E3 E4 E5 E6 E7 E8
Omschrijving Familiarity with development process Application Experience Object-Oriented Experience Lead Analyst Capability Motivation Stable Requirements Part-time Workers Difficult Programming Language
Factor
Gewicht
Totaal
1,5 0,5 1 0,5 1 2 -1 -1
Totaal EFactor
De werking is als volgt. Per omgevingsitem bepaal je het gewicht, het gewicht heeft een waarde tussen de 0 (geen invloed), naar 1 (sterk negatieve invloed), 3 (gemiddelde invloed) en 5 (sterk positieve invloed) op het project [1,3,4]. Hier komt per item een totaal uit en samen vormen die de EFactor. De Environmental Factor (EF) wordt dan als volgt bepaald: EF = 1,4 + (-0,03*EFactor)
3.6 Bepalen van de Adjusted Use Case Points
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
8 van 10 1.2 16-03-2011
Tot slot kan de Adjusted Use Case Points (UCP) waarde bepaalde worden. De formule hiervoor is als volgt [1,3,4]: UCP = (UUCW + UAW) x TCF x EF of UCP = UUCP x TCF x EF De waarde van UCP vormt de basis voor de begroting.
3.7 Het afleiden van de begroting Karner stelt voor om per UCP 20 uur te rekenen voor de totale ontwikkelbegroting [1,3]. Maar hier maken verschillende bronnen kanttekeningen bij. Onder andere Ribu heeft een productiviteit variërend van 15 tot 30 uren per UCP gevonden [3]. Schneider en Winters suggereren een verfijning van de norm van Karner op basis van de ervaring van het team en de stabiliteit van het project. Tel het aantal omgevingsitems uit de reeks E1 - E6 die een waarde groter dan 3 hebben en van E7 – E8 welke een waarde onder de 3 hebben en groter dan 0. Als het aantal omgevingsitems 2 of lager is, dan kan 20 uur per UCP aangenomen worden. Is het 3 of 4, neem dan 28 uur per UCP. Is het aantal meer dan 4, dan zijn er te veel omgevingsfactoren die een negatieve invloed op het project hebben. Het project kan dan beter stilgelegd worden om vervolgens de omgevingsfactoren te verbeteren [1,3]. Szongott suggereert een andere aanpak. Hij stelt om eerst uit te gaan van 20 uur per UCP en in de loop van het project een al nauwkeuriger productiviteitsfactor (PF) te bepalen. Dit kan middels de volgende formule [4]: PF = bestede uren project / UCP’s project. Bij bestede uren project zijn dit de uren van de reeds afgeronde UCP’s, deze worden dan gedeeld door het aantal afgeronde UCP’s. In de gebruikte literatuur wordt geen nadere specificatie richting testbegrotingen gegeven. Op basis van verhoudingsgetallen valt de testbegroting af te leiden.
3.8 Relativering van de waarde van de begroting In de geraadpleegde documentatie wordt de berekenwijze op verschillende wijzen bekritiseerd. Ribu heeft een studie gemaakt van een aantal projecten waarbij vooraf op basis van UCP’s begroot was en op basis van UUCP’s met een iets andere factor waarbij vervolgens geen rekening meer werd gehouden met de technische complexiteit en de omgeving. De conclusie hier was dat de zuiverheid van de standaard rekenwijze via UCP’s niet nauwkeuriger was dan de nieuw ontwikkelde methodiek via de UUCP’s [3]. Cohn schrijft dat het volledig uitwerken van Use Cases op User Goal niveau tegen de principes van Agile software development gaat [1]. De vraag is echter gerechtvaardigd of het toepassen en uitwerken van Use Cases wel past bij Agile software development.
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
9 van 10 1.2 16-03-2011
4 Test Case Point Analyse Als tegenhanger van de Use Case Point Analyse heeft Patel de Test Case Point Analyse (TCP) beschreven [2]. De kracht van dit model is dat het duidelijk onderscheid maakt tussen geautomatiseerde testcases en handmatige testcases. Aangezien dit tot nu toe de enige bekende bron is waarin deze methodiek beschreven is en geen praktijk ervaringen gevonden zijn, blijft het bij een globale beschrijving. Patel gaat in zijn model uit van 2 activiteiten, testcases voorbereiden en test cases uitvoeren. Dit kan geautomatiseerd in zijn model alsook handmatig. TCP volgt 7 stappen: 1. Identificeer de Use Cases 2. Bepaal de Test Cases 3. Bepaal de TCP voor handmatige testcase voorbereiding 4. Bepaal de TCP voor geautomatiseerde testcase voorbereiding 5. Bepaal de TCP voor handmatige testcase uitvoering 6. Bepaal de TCP voor geautomatiseerde testcase uitvoering 7. Bepaal het totaal TCP Met de Use Cases als basis wordt het aantal testcases bepaald. Ook hier wordt, gelijk aan de Use Case Point Analyse, geclassificeerd op basis van complexiteit, gemeten naar het aantal teststappen voor een testcase, de samenhang tussen de verschillende testcases en de moeilijkheidsgraad van de uitkomst van de testcase. Dit wordt verder uitgewerkt voor de verschillende stappen. Een duidelijk rekenvoorbeeld ontbreekt in de geraadpleegde documentatie evenals metrics voor het omzetten van Test Case Points naar te begroten uren.
Almere © 2011
Proud of it
Organisatie Titel Onderwerp
SYSQA B.V. Use Case Point Analyse Introductie
Pagina Versie Datum
10 van 10 1.2 16-03-2011
5 Gebruikte literatuur 1. 2. 3. 4.
5. 6.
Cohn, Mike; Estimating With Use Case Points; in Methods and Tools; Volume 13 number 3; 2005 Patel, Nirav e.a.; Test Case Point Analysis ; White Paper; versie 1.0; 2001 Ribu, Kirsten; Estimating Object-Oriented Software Projects with Use Cases; Master of Science Thesis; University of Oslo, Department of Informatics; 2001 Szongott, Christian; Werkzeuggestützte Aufwandsagschätzung bei Erstellung von Use Cases; Bachelorarbeit im Studiengang Informatik; Gottfried Wilhelm Leibniz Universität Hannover, Fakultät für Elektrotechnik und Informatik, Institut für Praktische Informatik, Fachgebiet Software Engineering; 2007 OMG; OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2; 2007; www.omg.org Introductie Functiepuntanalyse, Kennisbank Sysqa
Almere © 2011
Proud of it
