Uw goede werk indienen bij de kennisbank is eenvoudig. Gebruik onderstaand formulier

goed werk naar de site">

Studenten, promovendi en jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Geplaatst op http://www.allbest.ru/

COCOMO-, COCOMO II-modellen, functiepuntmethode. Hun vergelijkende analyse en reikwijdte

De levenscyclus van een softwaretool kan in twee delen worden verdeeld, die aanzienlijk verschillen wat betreft de economische kenmerken van processen en hulpbronnen, kenmerken en factoren die deze beïnvloeden. In het eerste deel van de PS-levenscyclus worden systeemanalyse, ontwerp, ontwikkeling, testen en testen van de basisversie uitgevoerd softwareproduct. Het scala aan werken, hun arbeidsintensiteit, duur en andere economische kenmerken in deze fasen van de levenscyclus zijn in belangrijke mate afhankelijk van de kenmerken van het object, de technologie en de omgeving van het ontwikkelingsinstrument. Het is vooral belangrijk om rekening te houden met de mogelijke stijging van de totale kosten wanneer de eisen aan de kwaliteit van een softwareproduct te hoog worden gesteld. Net als bij andere soorten industriële producten wordt het verbeteren van de kwaliteit van softwarepakketten doorgaans niet bereikt door een proportionele, maar door een significantere toename van de daarvoor benodigde middelen. Het verminderen van deze behoefte aan middelen is vaak alleen mogelijk door fundamentele verandering en het verbeteren van ontwerp- en ontwikkelingstechnologie.

Voor dit deel van de stappen levenscyclus gekenmerkt door een ongelijke verdeling van de arbeidsintensiteit, de duur en het aantal specialisten over de belangrijkste fasen van het werk. De maximale arbeidsintensiteit en het aantal specialisten vindt plaats in de fasen van het programmeren en testen van componenten, wanneer het grootste deel van de codeerders erbij betrokken is. Bij actief gebruik en verbetering van technologieën systeem analyse en ontwerp is er sprake van een herverdeling van alle soorten kosten in de richting van het vergroten van de arbeidsintensiteit in de eerste ontwikkelingsfasen. Dit resulteert in een aanzienlijke vermindering van het totale resourcegebruik voor het hele project. De verdeling van de noodzakelijke middelen per werkfase, rekening houdend met de implementatie van de vereiste specifieke kenmerken van de kwaliteit van de software, is minder bestudeerd. Gepubliceerde gegevens en afhankelijkheden voor verschillende softwareklassen stellen ons in staat de totale kosten en andere belangrijke technische en economische indicatoren (TEI) van het project, de plannen en werkschema's voor nieuw gemaakte softwareproducten te voorspellen.

Het tweede deel van de levenscyclus, dat de exploitatie, het onderhoud, de wijziging, het configuratiebeheer en de overdracht van de software naar andere platforms weerspiegelt, is wat betreft de hoeveelheid benodigde resources minder afhankelijk van de functionele kenmerken van het object en de ontwikkelomgeving. De reikwijdte van het werk in deze stadia is min of meer gedefinieerd, maar hun complexiteit en duur kunnen sterk variëren, afhankelijk van de massaschaal en andere omstandigheden. externe factoren distributie en gebruik van specifieke versies van het softwareproduct. Het succes van een softwaretool bij gebruikers en op de markt, evenals het toekomstige proces van versieontwikkeling, is moeilijk te voorspellen en houdt niet direct verband met de economische parameters van softwareontwikkelingsprocessen. De consumentenkenmerken van het product worden doorslaggevend, en hun economische kenmerken Vanuit het oogpunt van de ontwikkelaars verdwijnen de geïnvesteerde middelen voor de volgende versie naar de achtergrond.

Als gevolg hiervan kunnen de arbeidsintensiteit en het aantal specialisten dat nodig is om deze fasen van de levenscyclus te ondersteunen, sterk variëren. Dit maakt het moeilijk om de technische kenmerken van verschillende projecten statistisch te generaliseren en op basis daarvan vergelijkbare kenmerken van een nieuwe ontwikkeling te voorspellen. Daarom hebben plannen in deze stadia de aard van algemene relaties tussen de inhoud van het werk, die een verdeling in de tijd vereisen, individueel voor elk project. Als gevolg hiervan moet het voorspellen en plannen van de arbeidsintensiteit en de duur van deze fasen iteratief gebeuren op basis van de accumulatie van ervaring en analyse van de ontwikkeling van specifieke versies van de software, en rekening houdend met hun succes op de markt.

Om eventuele processen of kenmerken van objecten (met name software) te voorspellen en te plannen, worden twee soorten brongegevens gebruikt:

· functies en nomenclatuur van kenmerken van het voorspelde object of proces waarvoor het nodig is de levenscyclus te plannen;

· kenmerken van prototypes en proefprojecten, tot op zekere hoogte vergelijkbaar met de geplande faciliteit, waarvan de geïmplementeerde plannen en de noodzakelijke economische kenmerken van reeds voltooide soortgelijke processen voor de creatie ervan bekend zijn.

Gezamenlijke, correcte verwerking van initiële gegevens van deze twee typen maakt het tijdens het ontwerp mogelijk om nieuwe, voorspelbare kenmerken van processen, plannen en planningen te evalueren en te verkrijgen. economische indicatoren oprichting van een PS. Initiële gegevens van het eerste type weerspiegelen de kenmerken van het specifieke object of proces dat wordt gecreëerd, beschikbare methoden En hulpmiddelen automatisering van arbeid tijdens hun creatie. Deze gegevens worden tijdens het ontwerp- en verdere implementatieproces consistent gedetailleerd en verfijnd, wat het met name mogelijk maakt om de selectie van componenten van vergelijkbare objecten en hun kenmerken voor het tweede type initiële gegevens te verduidelijken.

Het tweede type initiële gegevens voor het rechtvaardigen en plannen van de ontwikkeling van software bestaat uit algemene ontwerpervaring en economische kenmerken van prototypen van het gecreëerde softwareproduct. Voor een betrouwbare planning is het noodzakelijk om specifieke gegevens over geïmplementeerde plannen, kosten en middelen die worden gebruikt voor voltooide softwareontwikkelingen te verzamelen, te generaliseren en te bestuderen. verschillende aspecten. Dergelijke technische en economische indicatoren en de factoren die deze bepalen, werden bestudeerd tijdens het verwerken van aanzienlijk statistisch materiaal van echte binnenlandse en buitenlandse softwareprojecten en werden gebruikt in de hieronder besproken voorspellingsmethoden.

Bij het uitvoeren van een haalbaarheidsstudie van een softwareproject op welk niveau dan ook, is het raadzaam methoden en technieken te gebruiken die geschikt zijn voor de doelen en fasen van de implementatie ervan. De doelstellingen van de TEP-beoordeling moeten in overeenstemming worden gebracht met de behoefte aan informatie ter ondersteuning van de besluitvorming over de planning van arbeid en andere middelen. In het algemene geval is het noodzakelijk om een ​​evenwichtige samenstelling van doelen te bereiken voor het beoordelen van verschillende kenmerken, die ongeveer dezelfde absolute waarde zouden opleveren van het onzekerheidsniveau van schattingen voor alle componenten van de software. Bovendien moet elke beoordeling van technische en economische indicatoren vergezeld gaan van een indicatie van de mate van onzekerheid. Naarmate het project zich ontwikkelt, moeten deze schattingen worden herzien en aangepast wanneer dit nuttig wordt.

Het betrekken van de klant helpt bij het minder pijnlijk oplossen van de problemen bij het beheren van de schaal van het project en de functies die worden geïmplementeerd, rekening houdend met de beperkingen van de middelen. Afhankelijk van het ontwikkelingsstadium van een complexe reeks programma's en de betrouwbaarheid van de initiële gegevens over de kenmerken en kenmerken van het softwareproject, is het raadzaam om verschillende technieken en scenario's voor de haalbaarheidsstudie van het project en het voorspellen van de technische en economische indicatoren ervan. Vanaf het allereerste begin van het werken aan een project is het belangrijk om voortdurend gegevens bij te houden over de werkelijke arbeidsintensiteit, de kosten en de kostendynamiek en deze gegevens te vergelijken met voorspelde schattingen van de projectkenmerken op basis van volgende redenen:

· imperfectie van de initiële gegevens bij het beoordelen van technische en economische indicatoren zet de projectmanager ertoe aan de schattingen te herzien, rekening houdend met nieuwe informatie een meer realistische basis bieden voor verder projectmanagement;

· vanwege de imperfectie van PS-beoordelingsmethoden moeten schattingen worden vergeleken met de werkelijke waarden van technische en economische indicatoren en moeten deze resultaten worden gebruikt om beoordelingsmethoden te verbeteren;

· Softwareprojecten hebben de neiging kenmerken en economische factoren te veranderen, en de projectmanager moet deze veranderingen identificeren en realistische updates maken van de kostenramingen.

De belangrijkste bronnen voor ontwikkelaars bij het maken van complexe softwarepakketten zijn:

· aanvaardbare arbeidskosten (kosten) voor softwareontwikkeling met de vereiste kwaliteit;

· tijd - de duur van de volledige cyclus van het maken van een softwareproduct;

· het benodigde en beschikbare aantal specialisten met de juiste kwalificaties.

De behoefte aan deze middelen hangt voor het grootste deel af van de omvang (schaal) en complexiteit van de te ontwikkelen software. Verduidelijking van de omvang van de softwaretool en zijn componenten kan achtereenvolgens worden besloten aan het einde van het gedetailleerde ontwerp, maar er blijft een onzekerheid bestaan ​​bij het schatten van de omvang van het softwarecomplex en de arbeidsintensiteit ervan in de orde van 5 - 10%. geassocieerd met hoe goed programmeurs de specificaties begrijpen op basis waarvan ze het programma moeten coderen. Het is raadzaam om er rekening mee te houden dat:

· de doelstellingen van het beoordelen van technische en economische indicatoren moeten consistent zijn met de behoefte aan informatie om de besluitvorming in de juiste fase van het softwareproject te vergemakkelijken;

· de betrouwbaarheid van beoordelingen moet in evenwicht zijn diverse componenten systemen en het onzekerheidsniveau voor elke component moeten ongeveer hetzelfde zijn als in het besluitvormingsproces alle componenten hetzelfde gewicht hebben;

· men moet terugkeren naar de eerdere doelstellingen, namelijk het beoordelen van technische en economische indicatoren, en deze indien nodig wijzigen voor verantwoorde begrotingsbeslissingen die in een vroeg stadium worden genomen en die van invloed zijn op de daaropvolgende fasen.

Het is vrij moeilijk om de hoeveelheid arbeid die nodig is om een ​​taak te voltooien in te schatten zonder betrouwbare informatie over de omvang ervan. Het meten van de omvang (complexiteit) gaat dus vooraf aan de beoordeling van technische en economische indicatoren, en deze beoordeling gaat op zijn beurt vooraf aan het opstellen van een werkschema.

Onvoldoende betrouwbare inschattingen leiden tot problemen in de interactie tussen ontwikkelaar en klant en verhogen de risicograad van het project.

Schatting van de softwaregrootte

Activiteiten voor het dimensioneren en schatten van software zijn opgenomen in de takenreeks voor softwareprojectplanning. Ze worden voorafgegaan door het definiëren van de doelstellingen en reikwijdte van het project, het creëren van een Work Breakdown Structure (WBS) en het identificeren van taken en activiteiten. Na de taken van het voorspellen van de omvang van software, zijn er taken voor het schatten van de duur en de kosten van de ontwikkeling, waarbij de toewijzing van middelen plaatsvindt, rekening houdend met afhankelijkheden, en het opstellen van een werkschema.

Het beoordelen van de omvang en het hergebruikpotentieel van code gebeurt vroeg in de levenscyclus. Naarmate het project vordert, worden herhaaldelijk beoordelingen van omvang en inspanning uitgevoerd, waarbij elke beoordeling het vertrouwen in de verkregen resultaten vergroot. Goede beheerder Het project moet er eenvoudigweg een regel van maken om de omvang van de software te schatten met behulp van de evaluatieresultaten als de outputparameters van elke fase van de levenscyclus.

Szijn al jaren op zoek naar aanvaardbare kwantitatieve methoden om de productiviteit te meten, de procesefficiëntie te evalueren en de ontwikkelingskosten van software te beheren. Het struikelblok was het ontbreken van een betrouwbare meeteenheid voor de omvang van software.

Momenteel worden bij het schatten van de omvang van software het vaakst twee hoofdmeeteenheden gebruikt: coderegels (LOC) en functiepunten.

U kunt ook eigenschapspunten, het aantal “vetgedrukte punten” op een gegevensstroomdiagram (DFD), het aantal entiteiten in een entiteitsdiagram, de hoeveelheid documentatie, het aantal objecten, attributen en services in een objectdiagram gebruiken als meeteenheden. Ongeacht of het eindproduct wordt geëvalueerd, zoals in het geval van LOC, of ​​een abstractie of model daarvan, wat wordt geëvalueerd is iets dat nog niet bestaat in de natuur. Daarom levert het schatten van de omvang aanzienlijke problemen op.

LOC gebruiken als meeteenheid softwareproductgrootte

De LOC-score is de meest universele maatstaf, omdat deze kan worden gebruikt bij het maken van softwareproducten. Het is eenvoudiger en begrijpelijker, zowel voor specialisten als voor klanten en investeerders. Als er bijvoorbeeld wordt vermeld dat één onderdeel van een softwaresysteem bestaat uit Voor n componenten zijn gemiddeld ongeveer 1000 regels nodig programmacode, dan kan iedereen het inschatten totale grootte en op zijn minst een ruwe schatting maken van de arbeid die nodig is om het te maken, gebaseerd op de veronderstelling dat de gemiddelde productiviteit van één programmeur nog steeds ongeveer 3000 regels code per jaar bedraagt.

Veel softwareontwikkelingsexperts beweren echter dat dit een slechte meeteenheid is. De belangrijkste vraag die zich voordoet bij het gebruik van LOC-schattingen is wat een enkele regel code is? Bovendien roept het gebruik van LOC als meeteenheid twijfels op over de betrouwbaarheid van de resultaten, aangezien er geen rekening wordt gehouden met het volgende:

aantal lijnen broncode hangt af van het vaardigheidsniveau van de programmeur. Hoe hoger de vaardigheid van de programmeur, hoe minder regels code hij zal kunnen beheren om een ​​bepaalde functionaliteit (of functionaliteit) van de software te implementeren;

· Talen op hoog niveau of visuele programmeertalen vereisen veel kleiner aantal regels code dan bijvoorbeeld Assembleertaal of C om dezelfde functionaliteit weer te geven. Het volstaat om twee applicaties voor te stellen die dezelfde functionaliteit hebben (dezelfde schermen, rapporten, databasetabellen), maar dan geïmplementeerd verschillende talen. Het is duidelijk dat er een omgekeerde relatie bestaat tussen het taalniveau en de productie-output van de programmeur;

· Het werkelijke aantal LOC's blijft onbekend totdat het project bijna voltooid is. Daarom kan LOC niet worden gebruikt om de ontwikkelingsinspanningen vooraf in te schatten en een projectplanning op te stellen;

· Er bestaat binnen de programmeergemeenschap geen overeenstemming over een methode voor het tellen van coderegels. De taalconstructies die bijvoorbeeld in Visual C++, Assembly, Cobol of SQL worden gebruikt, zijn totaal verschillend. De methode blijft algemeen voor alle toepassingen, inclusief toepassingen die een combinatie van verschillende talen gebruiken;

· het is voor de klant moeilijk te begrijpen wat de relatie is tussen de functionele en niet-functionele (technische) eisen aan de door hem gespecificeerde software en de omvang van het programmeerwerk.

Tegelijkertijd zijn er verschillende voldoende om de betrouwbaarheid van schattingen te vergroten eenvoudige aanbevelingen:

· Zorg ervoor dat elke regel broncode die u telt slechts één verklaring bevat. Als een enkele regel twee uitvoerbare instructies bevat, gescheiden door een puntkomma, moeten deze als twee regels worden geteld. Als één verklaring wordt opgesplitst in meerdere ‘fysieke’ regels, wordt deze als één regel geteld. Programmeertalen maken verschillende coderingsregels mogelijk, maar het is meestal eenvoudiger om één enkele instructie op een regel te definiëren die door de compiler of tolk wordt verwerkt.

· Houd rekening met alle uitvoerbare instructies. De eindgebruiker kan mogelijk niet praktisch elke operator gebruiken, maar alle operators moeten door het product worden ondersteund, inclusief de hulpprogramma's.

· Houd rekening met gegevensdefinities slechts één keer.

· Negeer regels met commentaar.

· Voeg geen foutopsporingscode of andere tijdelijke code (proefsoftware, testtools, enz.) toe.

· Tel elke initialisatie, aanroep of opname van een macro (compilerrichtlijn) als onderdeel van de broncode waarin een bepaalde actie wordt uitgevoerd. Tel hergebruikte uitspraken niet mee.

In de praktijk wordt bij het schatten van de omvang van grote softwaresystemen vaak de KSLOC-metriek van duizenden regels broncode gebruikt. Deze maatstaf wordt het vaakst gebruikt bij productiviteitsbeoordelingen en wordt berekend als KSLOC/SM, waarbij SM de personeelsmaand is.

Het schatten van de LOC met behulp van het oordeel van deskundigen en bottom-up sommatie.

Ervan uitgaande dat de structuur De WBS voor de software die wordt ontwikkeld, is opgesplitst in verschillende decompositieniveaus die de feitelijke componenten van het softwaresysteem benadrukken en ook een basis bieden voor verdere details. Het is mogelijk om een ​​soort ‘statistische’ maatstaf voor de omvang te creëren die kan worden verkregen met behulp van de processen van meten en optellen.

De omvang van elke component kan worden bepaald door deskundigen te interviewen die dergelijke systemen hebben ontwikkeld, of door potentiële ontwikkelaars van dergelijke systemen te interviewen. Hierdoor wordt het mogelijk om de grootte van elk blok te schatten lager niveau WBS-structuren. Na het optellen van de geschatte schattingen ontstaat er een idee van de omvang van het softwaresysteem als geheel. Deze methode wordt bottom-up dimensionering genoemd.

Deze indicator kan worden verbeterd als elke schatter niet één, maar drie mogelijke groottewaarden aangeeft: pessimistisch, optimistisch en min of meer realistisch. Vervolgens worden de optimistische en pessimistische schattingen opgeteld bij de realistische waarde vermenigvuldigd met 4, en het totaal gedeeld door 6.

Met deze methode kunnen we een evenwichtiger oordeel verkrijgen, waarbij rekening wordt gehouden met de onzekere omstandigheden waarin het beoordelingsproces zelf plaatsvindt.

Als een object dat in de WBS-structuur wordt weergegeven bijvoorbeeld 200 tot 400 regels code kan bevatten en de grootte ervan hoogstwaarschijnlijk dichter bij de 200 ligt, kunt u met de voorgestelde aanpak de volgende schatting krijgen: (200+(250*4) +400)/6 = 266 LOC.

Naar analogie het aantal LOC's schatten

Een van de manieren om een ​​softwaresysteem in de projectfase te evalueren, is door de functionele eigenschappen ervan te vergelijken met bestaande analogen.

We hebben bijvoorbeeld een kant-en-klare module A, waarvan de grootte 2345 LOC is. We willen een nieuwe module maken die veel op Module A lijkt, maar waaraan enkele extra eigenschappen zijn toegevoegd. Daarnaast hebben we ontdekt hoe we de programmacode compacter kunnen maken. Als gevolg hiervan kan de omvang van module A" worden geschat op 3000 LOC.

Deze methode is uiteraard niet erg nauwkeurig, omdat bij het schrijven van module A verschillende programmeertalen gebruikt kunnen worden, algoritmen met verschillende niveaus van complexiteit gebruikt kunnen worden en er verschillende hoeveelheden modellering gebruikt kunnen worden (simulatie, emulatie, echte toepassing), maar een dergelijke beoordeling heeft nog steeds enige kwantitatieve rechtvaardiging.

Voordelen van het gebruik van LOC als meeteenheid

· Deze eenheden zijn wijdverspreid en aanpasbaar.

· Ze maken vergelijking van maatvoering en prestatiemetingsmethoden mogelijk diverse groepen ontwikkelaars.

· Direct gerelateerd aan het eindproduct.

· LOC-eenheden kunnen worden geschat voordat het project is voltooid.

· Bij het beoordelen van de softwaregrootte wordt rekening gehouden met het standpunt van de ontwikkelaars.

· Activiteiten voor continue verbetering zijn gebaseerd op kwantitatieve beoordelingen. In dit geval kan de voorspelde grootte eenvoudig worden vergeleken werkelijke grootte in de fase van de post-projectanalyse. Hierdoor kunnen experts ervaring opdoen en zelf de beoordelingsmethoden verbeteren.

· Als u de omvang van softwareproducten in LOC-eenheden kent, kunt u de meeste bestaande methoden toepassen voor het beoordelen van de technische en economische indicatoren van een project (zoals arbeidskosten, projectduur, kosten, enz.).

Nadelen verbonden aan het gebruik van LOC-beoordelingen

· Deze meeteenheden zijn moeilijk toe te passen in de vroege stadia van de levenscyclus, wanneer de onzekerheid hoog is.

· Eerste instructies kan variëren afhankelijk van de programmeertalen, ontwerpmethoden, stijl en capaciteiten van programmeurs.

· Het gebruik van schattingsmethoden voor het aantal regels wordt niet gereguleerd door industriestandaarden zoals ISO.

· Softwareontwikkeling kan gepaard gaan met grote kosten die niet direct afhankelijk zijn van de grootte van de programmacode. Dit zijn de zogenaamde vaste kosten die verband houden met het ontwikkelen van eisenspecificaties, het opstellen van gebruikersdocumentatie, enz., die niet zijn inbegrepen in de directe kosten van het coderen.

· Programmeurs kunnen onverdiend worden beloond voor het behalen van hoge LOC-indicatoren als het management dit als een hoog teken van productiviteit beschouwt. Hoewel soms een grote hoeveelheid codering een bewijs is van onvoldoende zorgvuldig programmaontwerp. Broncode is bij het maken geen doel op zich eindproduct, is het veel belangrijker om de vereiste functionaliteit van de software te garanderen en een hoge teamproductiviteit te bereiken.

· Bij het berekenen van LOC-eenheden moet u onderscheid maken tussen automatisch gegenereerde code en handmatig geschreven code. Dit maakt het gebruik erg lastig automatische methoden tellen.

· LOC-indicatoren kunnen niet worden uitgevoerd tijdens normalisatie als ze werden gebruikt verschillende platforms of soorten programmeertalen.

· De enige manier het verkrijgen van LOC-schattingen is een vergelijking met soortgelijke ontwikkelingen of meningen van deskundigen, en deze schattingen worden in eerste instantie niet als accuraat beschouwd.

· Codegeneratoren veroorzaken vaak een buitensporig codevolume, wat kan leiden tot aanzienlijke fouten bij het schatten van de grootte van de code.

De productiviteit van programmeurs wordt vaak gemeten aan de hand van het aantal geproduceerde regels code, maar dit is niet altijd waar. Als een programmeur 250 in plaats van 200 regels per maand schrijft, betekent dit niet dat hij beslist een betere werker is geworden en aanmoediging verdient. Het zou juister zijn om niet alleen rekening te houden met de hoeveelheid geschreven code, maar ook met de kwaliteit ervan, wat kan worden gedaan door de volgende formule toe te passen:

Aantal defecten / aantal regels code

De codeerfase neemt bij de meeste projecten tussen de 7% en 20% van de inspanning in beslag, dus de kwaliteit van de code is belangrijker dan de hoeveelheid code.

Functiepunten gebruiken als eenheden van programmagrootte.

Het eerste en meest succesvolle alternatief voor de methode voor het tellen van broncoderegels was een methodologie die in 1979 werd ontwikkeld door Allan Albrecht van IBM, genaamd Function Points Analysis (FPA, van Function Points Analysis). Het is gebaseerd op een blik op de software van buitenaf, vanuit de positie van de gebruiker van het systeem, en niet ‘van buitenaf’ op de interne eigenschappen ervan (zoals LOC). Als resultaat van de analyse initiële vereisten naar PS en verduidelijking echte behoeften gebruikers wordt bepaald door het volume functionaliteit systemen, waarvan de indicatoren informatieverwerkingsfuncties zijn laag niveau, hoeveel ze passen in het denksysteem van de gebruikers, en naast de functies, de gegevens die deze functies verwerken. De FPA-methodologie is dus gebaseerd op het idee om functies en gegevens te ontleden tot het maximaal aanvaardbare (vanuit het oogpunt van de gebruiker) niveau. Het volume aan functionele mogelijkheden van de PS (hierna eenvoudigweg functionele omvang) wordt bepaald in de zogenaamde conventionele eenheden van functionaliteit FP - van Functiepunten

Binnen vijf jaar na de oprichting werden de FPA-methodologie en de dimensioneringsmethode verfijnd door A. Albrecht en praktisch getest, en halverwege de jaren 80 werd de International Function Points User Group (IFPUG, van International Function Points User Group) opgericht, wat de verdere evolutie van de methode ondersteunt.

Met de functiepuntmethode kunt u de volgende problemen oplossen:

· Het probleem oplossen dat verband houdt met de moeilijkheid om LOC-beoordelingen te verkrijgen in de vroege stadia van de levenscyclus.

· Bepaal de hoeveelheid en complexiteit van invoer- en uitvoergegevens, hun structuur en externe interfaces die verband houden met het softwaresysteem.

De functiepuntmethode maakt gebruik van 5 informatiekenmerken.

1. Aantal externe ingangen. Alle gebruikersinvoer die verschillende toepassingsgegevens oplevert, wordt geteld. Inzendingen moeten gescheiden worden gehouden van aanvragen, die afzonderlijk worden geteld.

2. Aantal externe pinnen. Alle pinnen worden geteld en de door de softwareapplicatie berekende resultaten worden teruggestuurd naar de gebruiker. Onder output worden in deze context verstaan: rapporten, schermen, afdrukken, foutmeldingen. Individuele gegevenseenheden binnen een rapport worden niet afzonderlijk geteld.

3. Aantal externe verzoeken. Een verzoek wordt gedefinieerd als dialooginvoer die resulteert in een onmiddellijk programmaantwoord in de vorm van dialooguitvoer. In dit geval wordt de dialooginvoer niet opgeslagen in de toepassing en zijn voor de dialooguitvoer geen berekeningen nodig. Alle verzoeken worden geteld - elk verzoek wordt afzonderlijk geteld.

4. Aantal interne logische bestanden. Alle logische bestanden (dat wil zeggen, logische gegevensgroepen die deel kunnen uitmaken van een database of een afzonderlijk bestand) worden geteld.

5. Aantal externe interfacebestanden. Alle logische bestanden van andere applicaties waarnaar door deze applicatie wordt verwezen, worden geteld.

Invoer, uitvoer en verzoeken worden gecategoriseerd als transacties. Een transactie is een door de gebruiker gedefinieerd basisproces dat gegevens verplaatst tussen een externe omgeving en een softwareapplicatie. In hun werk maken transacties gebruik van interne en externe bestanden, waarvoor de volgende definities worden gehanteerd.

Externe invoer is het elementaire proces dat gegevens van de externe omgeving naar de applicatie verplaatst. De gegevens kunnen afkomstig zijn uit het invoerscherm of uit een andere applicatie. De gegevens kunnen worden gebruikt om interne logische bestanden bij te werken. De gegevens kunnen zowel management- als bedrijfsinformatie bevatten. Controlegegevens mogen het interne logische bestand niet wijzigen.

Externe gevolgtrekking is een rudimentair proces dat gegevens die in een toepassing zijn berekend, naar de externe omgeving verplaatst. Bovendien kunnen tijdens dit proces interne logische bestanden worden bijgewerkt. Met de gegevens worden rapporten of uitvoerbestanden gemaakt die naar andere applicaties worden verzonden. Rapporten en bestanden worden gemaakt op basis van interne logische bestanden en externe interfacebestanden. Bovendien kan dit proces invoergegevens gebruiken die zoekcriteria en parameters bevatten die niet worden ondersteund door de interne logische bestanden. De invoergegevens komen van buitenaf, maar zijn tijdelijk en worden niet opgeslagen in een intern logisch bestand.

Een extern verzoek is een elementair proces dat werkt met zowel invoer- als uitvoergegevens. Het resultaat zijn gegevens die worden geretourneerd uit interne logische bestanden en externe interfacebestanden. Het invoergedeelte van het proces wijzigt de interne logische bestanden niet, en het uitvoergedeelte bevat geen gegevens die door de toepassing zijn berekend (dit is het verschil tussen een verzoek en een uitvoer).

Een intern logisch bestand is een door de gebruiker herkenbare groep logisch gerelateerde gegevens die binnen een applicatie worden gehost en via externe invoer worden aangeboden.

Een extern interfacebestand is een door de gebruiker herkenbare groep logisch gerelateerde gegevens die binnen een andere applicatie worden gehost en onderhouden. Extern bestand deze applicatie is een intern logisch bestand in een andere applicatie.

Voor transacties is de rangschikking gebaseerd op het aantal bestandslinks en het aantal typen gegevensitems. Voor bestanden is de rangschikking gebaseerd op het aantal recordelementtypen en gegevenselementtypen dat in het bestand is opgenomen.

levenscyclus van software-inspanningen

Geplaatst op Allbest.ru

...

Soortgelijke documenten

De haalbaarheid van het gebruik van het levenscyclusmodel als instrument voor het beheren van veranderingen in ondernemingen. Analyse van soorten levenscycli, studie van hun relatie op de juiste niveaus van economisch management. Dynamiek van veranderingsprocessen.

test, toegevoegd op 11/12/2008


Een project als een reeks onderling verbonden werken gericht op het creëren van een uniek resultaat binnen het kader van tijd- en budgetbeperkingen, de belangrijkste kenmerken ervan. Planning van inhoud en middelen, tijd en kosten van het project, verzamelen van vereisten.

presentatie, toegevoegd 02/09/2015


Doel van het softwareproduct. Vereisten voor functionele kenmerken. Productmarktonderzoek. Levenscyclus van producten. Berekening van de arbeidsintensiteit van programmaontwikkeling. Vorming van de prijs van het voorstel van de ontwikkelaar, berekening van kapitaalkosten.

cursuswerk, toegevoegd op 28/12/2012


Projectlevenscyclus en de fasen ervan. Beoordeling van de duurzaamheid van projecten (risico's en break-even niveau). Factoren van tijdverlies tijdens de implementatie ervan. Planning van de werkzaamheden aan het project om in 51 weken een biljartclub te creëren, met kosten van niet meer dan 3,5 miljoen roebel.

cursuswerk, toegevoegd op 22/12/2011


De levenscyclus van een organisatie bestaat uit een reeks ontwikkelingsfasen die een bedrijf tijdens zijn bestaan ​​doorloopt. Kenmerken van de fase van collegialiteit, formalisering van activiteiten, herstructurering, recessie. Kansen en beperkingen van het levenscyclusmodel.

presentatie, toegevoegd op 28-11-2013


Het concept van de levenscyclus van een organisatie, haar diverse modellen en hoofdpodia. Acties van een manager in verschillende stadia van de ontwikkeling van een organisatie, veelbelovende modellen van zijn evolutie. Analyse van de levenscycli van een bedrijf aan de hand van het voorbeeld van Lecrus Ural LLC.

cursuswerk, toegevoegd op 28-02-2012


De essentie en structuur van de levenscyclus van een organisatie, de belangrijkste fasen en betekenis ervan. Methodologie voor het analyseren van de levenscyclus van een organisatie. Een mechanisme voor het beheren van een organisatie volgens de fasen van haar levenscyclus. Factoren die de levensduur van een organisatie beïnvloeden.

cursuswerk, toegevoegd op 11/10/2010


Organisatie van de hoofdproductie. Concept en classificatie van productieprocessen. Technologische keten van productproductie. Berekening van de duur van de productiecyclus eenvoudig proces. Manieren om de duur van productiecycli te verkorten.

presentatie, toegevoegd 11/06/2012


Algemeen concept over de levenscyclus van een project. Basisprojectmanagementprocessen. Analyse van de levenscyclus en processen van een olie- en gasproject aan de hand van het voorbeeld van het activiteitenproject van OAO LUKOIL. Beoordeling van de levenscyclusfase van het project en aanbevelingen voor het beheer ervan.

cursuswerk, toegevoegd op 13-01-2014


Organisatiestructuur voor het beheren van een restaurantopeningsproject. Uitsplitsing van projectwerkzaamheden. Matrix van verdeling van administratieve beheertaken. Bepaling van relatieve indicatoren van de interne arbeidsintensiteit. Vergelijking van arbeidsintensiteit en bruikbaarheid.

Het tellen van de functiepunten die aan transacties zijn gekoppeld, is de vierde stap van de functiepuntanalyse.

Transactie- dit is een elementair, ondeelbaar gesloten proces dat waarde vertegenwoordigt voor de gebruiker en het product van de ene consistente staat naar de andere overbrengt.

De methode verschilt volgende typen transacties (Tabel 9):

• EI (externe inputs) - externe inputtransacties, een elementaire bewerking voor het verwerken van gegevens of controle-informatie die van buitenaf het systeem binnenkomt.
• EO (externe outputs) - externe outputtransacties, een elementaire bewerking om gegevens of controle-informatie te genereren die verder gaat dan het systeem. Veronderstelt enige logica voor het verwerken of berekenen van informatie van een of meer ILF's.
• EQ (externe vragen) - externe vragen, een elementaire bewerking die, in reactie op een extern verzoek, gegevens ophaalt of controle informatie van ILF of EIF.

Tabel 9. Belangrijkste verschillen tussen transactietypen. Legenda: O - hoofd; D - extra; NA - niet van toepassing.

Het beoordelen van de complexiteit van een transactie is gebaseerd op de volgende kenmerken:

• FTR ( bestandstype waarnaar wordt verwezen) - hiermee kunt u het aantal tellen diverse bestanden(informatieobjecten) van het type ILF en/of EIF gewijzigd of ingelezen in een transactie.
• DET (data element type) - een niet-herhaalbaar uniek dataveld. Voorbeelden. EI: invoerveld, knop. EO: rapportgegevensveld, foutmelding. EQ: zoekinvoerveld, uitvoerveld voor zoekresultaten.

Om de complexiteit van transacties te beoordelen, worden matrices gebruikt, die worden weergegeven in Tabel 10 en Tabel 11.

Tabel 10. Matrix van complexiteit van externe inputtransacties (EI)

De evaluatie van transacties op niet-uitgelijnde functiepunten (UFP) kan worden verkregen uit de matrix (Tabel 12)

Tabel 12. Transactiecomplexiteit in niet-uitgelijnde functiepunten (UFP)

Beschouw als voorbeeld de evaluatie van de controletransactie (EI) voor een dialoogvenster waarin opties voor spellingcontrole in MS worden gespecificeerd Kantoorvooruitzichten(Figuur 40).

Figuur 40. Dialoogvenster dat de spellingcontrole in MS Office Outlook regelt

Elk "Checkbox" wordt gewaardeerd als 1 DET. Vervolgkeuzelijst - 1 DET. Elk bedieningsknop moet als een afzonderlijke transactie worden behandeld. Als we bijvoorbeeld een controletransactie evalueren met de knop “OK”, dan hebben we voor deze transactie 1 FTR en 8 DET. Daarom kunnen we, volgens de matrix (Tabel 10), de complexiteit van de transactie als Laag beoordelen. En tenslotte, in overeenstemming met de matrix (Tabel 12), deze transactie moet worden gescoord op 3 niet-uitgelijnde functiepunten (UFP).

Bepaling van het totale aantal niet-uitgelijnde functiepunten (UFP's)

Het totale productvolume op niet-uitgelijnde functiepunten (UFP's) wordt bepaald door alles bij elkaar op te tellen informatie objecten(ILF, EIF) en elementaire operaties (transacties EI, EO, EQ).

Bepaling van de waarde van de uitlijningsfactor (FAV)

Naast functionele vereisten is het product onderworpen aan systeembrede vereisten die ontwikkelaars beperken bij het kiezen van een oplossing en de complexiteit van de ontwikkeling vergroten. Om rekening te houden met deze complexiteit wordt een nivelleringsfactor (VAF) gebruikt. De waarde van de VAF-factor is afhankelijk van 14 parameters die de systeemeigenschappen van het product bepalen:

1. Gegevensuitwisseling(0 - het product is een zelfstandige toepassing; 5 - het product communiceert via meer dan één telecommunicatieprotocol).

2. Gedistribueerde gegevensverwerking (0- het product verplaatst geen gegevens; 5 - gedistribueerde gegevensverwerking wordt uitgevoerd door verschillende systeemcomponenten).

3. Prestaties (0- er zijn geen gebruikersprestatie-eisen vastgesteld; 5 - de responstijd is ernstig beperkt en van cruciaal belang voor alle bedrijfsactiviteiten. Er zijn speciale vereisten vereist om aan de vereisten te voldoen ontwerp oplossingen en analysehulpmiddelen.

4. Beperkingen van hardwarebronnen (0- geen beperkingen; 5 - het volledige product moet op een specifieke processor werken en kan niet worden gedistribueerd).

- weinig transacties, geen pieken; 5 - het aantal transacties is groot en ongelijk, speciale oplossingen en hulpmiddelen zijn vereist).

6. Intensiteit van gebruikersinteractie (0- alle transacties worden verwerkt batch-modus; 5 - meer dan 30% van de transacties is interactief).

7. Ergonomie(eindgebruikersprestaties) (0 - geen speciale eisen; 5 - zeer strenge efficiëntie-eisen).

8. Wijzigingssnelheid van gegevens(ILF) door gebruikers (0 - niet vereist; 5 - intensieve wijzigingen, strikte herstelvereisten).

9. Verwerkingsproblemen (0- de verwerking is minimaal; 5 - beveiligingsvereisten, logische en wiskundige complexiteit, multi-threading).

10. Hergebruik(0 - niet vereist; 5 - product is ontworpen als een standaard herbruikbaar onderdeel).

11. Installatiegemak (0- geen vereisten; 5 - software-installatie en -update worden automatisch uitgevoerd).

12. Gemak van administratie(0 - niet vereist; 5 - het systeem herstelt zichzelf automatisch).

13. Draagbaarheid(0 - het product heeft slechts 1 installatie op één processor; 5 - het systeem is gedistribueerd en vereist installatie op verschillende hardware en besturingssystemen).

14. Flexibiliteit (0- niet vereist; 5 - flexibel systeem queries en het bouwen van aangepaste rapporten, wordt het datamodel door de gebruiker gewijzigd interactieve modus).

14 systeemparameters(mate van invloed, DI) worden beoordeeld op een schaal van 0 tot 5. Berekening van het totale effect van 14 systeemkenmerken (totale mate van invloed, TDI) wordt uitgevoerd door eenvoudige optelling:

TDI = ∑DI

De waarde van de nivelleringsfactor wordt berekend met behulp van de formule

VAF = (TDI *0,01) + 0,65

Als elk van de 14 systeemparameters bijvoorbeeld een score van 3 heeft gekregen, is hun totale effect TDI = 3 * 14 = 42. In dit geval is de waarde van de egalisatiefactor: VAF = (42 * 0,01) + 0,65 = 1,07

Berekening van het aantal uitgelijnde functiepunten (AFP)

Verdere evaluatie op uitgelijnde functiepunten is afhankelijk van het evaluatietype. Initiële schatting van het aantal uitgelijnde functiepunten voor softwaretoepassing bepaald door de volgende formule:

AFP = UFP * VAF.

Er wordt alleen rekening gehouden met nieuwe functionaliteit die in het product is geïmplementeerd. Een productontwikkelingsproject wordt beoordeeld in DFP (ontwikkelingsfunctioneel punt) met behulp van de formule:

DFP = (UFP + GVB) * VAF,

Waar GVB(conversiefunctioneel punt) - functionele punten berekend voor extra functionaliteit die vereist is tijdens de productinstallatie, bijvoorbeeld gegevensmigratie.

Een productverfijnings- en verbeteringsproject wordt beoordeeld op EFP (verbeteringsfunctioneel punt) met behulp van de formule:

EFP = (ADD + CHGA + GVB) * VAFA + (DEL* VAFB),

• TOEVOEGEN- functiepunten voor extra functionaliteit;
• CHGA- functiepunten voor gewijzigde functies, berekend na wijziging;
• VAFA- de waarde van de nivelleringsfactor berekend na voltooiing van het project;
• DEL- reikwijdte van functionaliteit op afstand;
• VAFB- de waarde van de nivelleringsfactor berekend vóór de start van het project.

De totale impact van de uitlijningsprocedure ligt binnen ±35% van het berekende volume in UFP.

De functiepuntanalysemethode zegt niets over de arbeidsintensiteit van het ontwikkelen van het geëvalueerde product. Het probleem wordt eenvoudig opgelost als het ontwikkelaarbedrijf zijn eigen statistieken heeft over de arbeidskosten voor de implementatie van functionele punten. Als dergelijke statistieken niet beschikbaar zijn, kan de COCOMO II-methode worden gebruikt om de arbeidsintensiteit en timing van het project te schatten.

Een schatting van het aantal functionele punten voor een softwareproduct wordt afgeleid op basis van gegevens die worden bepaald als resultaat van het analyseren van het informatiegebied van het programma en het bestuderen van de kenmerken van de werking ervan.

Informatieparameters worden als volgt gedefinieerd:

Aantal gebruikersaanmeldingen. Elke gebruikersinvoer die andere, gerichte gegevens oplevert, wordt geteld. specifieke toepassing. Invoer moet verschillen van gebruikersverzoeken, die afzonderlijk worden geteld.

Aantal gebruikersuitgangen. Elke gebruikersuitvoer wordt geteld, waardoor toepassingsspecifieke informatie voor de gebruiker ontstaat. Uitgangen zijn onder meer rapporten, schermen, foutmeldingen, etc. Individuele elementen uitvoergegevens worden niet meegeteld.

Aantal gebruikersverzoeken. Elk verzoek wordt geteld en behandeld als een afzonderlijke online-invoer, wat resulteert in het genereren van een onmiddellijk softwareantwoord in de vorm van een online-uitvoer.

Aantal bestanden. Er wordt geteld hoeveel logische hoofdbestanden (logische gegevensgroepen) deel kunnen uitmaken van een voldoende grote database.

Aantal externe interfaces. Alle machineleesbare interfaces worden geteld (bijvoorbeeld toegang tot gegevensbestanden op externe media die worden gebruikt om informatie naar andere systemen over te brengen).

Aan elke numerieke parameterwaarde wordt een overeenkomstige weegfactor toegekend, waarbij rekening wordt gehouden met hoe moeilijk of eenvoudig de betreffende parameter kan worden geïmplementeerd. Het is duidelijk dat een dergelijke beoordeling van complexiteit een deskundige en tamelijk subjectieve beoordeling is.

Voor de uiteindelijke berekening van het aantal functionele punten, d.w.z. de FT-maatstaf voor het gehele softwareproduct, is het noodzakelijk om bovendien rekening te houden met 14 factoren, waarvoor een schaal van wegingscoëfficiënten is vastgesteld, die de mate van invloed van een bepaald product weergeeft. bijzondere factor tijdens de werking van het softwareproduct. De coëfficiëntenschaal is als volgt:

Geen invloed - 0.

Willekeurige invloed -1.

Matige invloed - 2.

Gemiddelde invloed - 3.

Aanzienlijke invloed - 4.

Aanzienlijke invloed - 5.

Met behulp van deze schaal wordt ook de mate van invloed van elk van de volgende factoren die de kenmerken van de werking van het product bepalen, beoordeeld:

1. Heeft het systeem een ​​betrouwbare back-up en daaropvolgend herstel nodig na een storing?

2. Is gegevensoverdracht vereist?

3. Zijn er gedistribueerde verwerkingsfuncties?

4. Zijn de prestaties van een softwareproduct van cruciaal belang?

5. Zal het systeem functioneren in een bestaande of complexere besturingsomgeving?

6.Vereist het systeem online gegevensinvoer?

7. Is het vereist om online transacties in te voeren die het creëren van een transactie mogelijk maken? verschillende schermen toegepast op veel operaties?

8. Wordt het hoofdbestand bijgewerkt? online?

9. Zijn de inputs, outputs, bestanden of queries complex?

10. Zijn complexe algoritmen gegevensverwerking

Wegingscoëfficiënten worden gegeven in de tabel.

Berekeningsprocedure

1. Systeemparameters bepalen (ingangen/uitgangen)

2. Aan elke parameter wordt een eigen wegingsfactor toegekend, rekening houdend met de complexiteit van de parameterimplementatie

3. Bepaal het totaalresultaat voor alle parameters

4. Het aantal FT's wordt bepaald door de formule FT=eindtotaal(0,65+0,01 som van coëfficiënten)

FT kan worden gebruikt om de arbeidsproductiviteit, de kosten voor het ontwikkelen van één punt, het aantal pagina's documentatie per punt, enz. te bepalen.

Deze methode wordt gebruikt om de prestaties te meten ter vervanging van de verouderde lineaire benadering waarbij de prestaties werden gemeten aan de hand van het aantal regels code. Functiepunten werden voor het eerst voorgesteld door IBM-medewerker Alan Albrecht in 1979.

Voordeel deze methode is dat, aangezien de toepassing van functiepunten gebaseerd is op het bestuderen van de vereisten, er in de vroegste fasen van het project een schatting van de benodigde arbeidskosten kan worden gemaakt. Om deze methode te ondersteunen en te ontwikkelen, werd in 1986 de International Function Point User Group (IFPUG - International Function Point User Group) opgericht.

De werkwijze is als volgt.

Ten eerste worden de functies van de software die wordt ontwikkeld benadrukt, en wel op het niveau van de gebruikers, en niet op het niveau van de programmacode. Beschouw bijvoorbeeld een softwarepakket dat verschillende methoden implementeert voor het sorteren van eendimensionale arrays. Een van de functies van de gebruiker van dit complex is de keuze van de methode, en we zullen dit als voorbeeld beschrijven.

De volgende stap van de methode is het tellen van het aantal onderstaande factoren:

• externe ingangen. Alleen de ingangen die de functie op een andere manier beïnvloeden, zijn verschillend. De methodeselectiefunctie heeft één externe ingang;
• externe uitgangen. De uitgangen voor verschillende algoritmen. Laten we ons voorstellen dat onze functie een bericht produceert - een tekstbeschrijving van de geselecteerde methode, en een andere functie aanroept die het geselecteerde sorteeralgoritme direct implementeert, en daarom twee uitgangen heeft;
• externe verzoeken. In ons voorbeeld zijn er geen;
• interne logische bestanden - een groep gegevens die door een functie wordt aangemaakt of onderhouden, telt als één. Als het interne logische bestand voor onze functie zullen we nemen tekstbestand, met beschrijvingen van algoritmen;
• externe logische bestanden - gebruikersgegevens in bestanden buiten deze functie. Elke gegevensgroep wordt als één beschouwd. Extern aan onze functie bevindt zich het bestand met het verwerkingsresultaat.

Vervolgens worden de verkregen waarden vermenigvuldigd met de complexiteitscoëfficiënten voor elke factor (volgens 1PP1Yu-gegevens) en opgeteld om de volledige grootte van het softwareproduct te verkrijgen. De waarden van deze coëfficiënten staan ​​in de tabel. 9.1.

Tabel 9.1. Moeilijkheidscoëfficiëntwaarden

Laten we voor het voorbeeld dat we overwegen de waarden uit de tabel nemen. 9.2.

De omvang van onze functie zal zijn:

FR = 1x3+1x4+1x5+1x7+1x7 = 26.

Dit nummer is voorlopige beoordeling en behoeft verduidelijking.

Tabel 9.2. Voorbeeld van moeilijkheidscoëfficiënten

Parameter
Externe ingangen
Externe uitgangen
Externe verzoeken
Interne logische bestanden
Externe logische bestanden

De volgende stap bij het bepalen van de codegrootte met behulp van de functiepuntmethode is het toekennen van een gewicht (van 0 tot 5) aan elk ontwerpkenmerk. Wij zetten deze kenmerken op een rij:

• 1. Is het vereist? back-up gegevens?
• 2. Gegevensuitwisseling nodig?
• 3. Maakt u gebruik van gedistribueerd computergebruik?
• 4. Zijn prestaties belangrijk?
• 5. Draait het programma op zwaar belaste hardware?
• 6. Is online gegevensinvoer vereist?
• 7. Gebruikt u veel formulieren voor gegevensinvoer?
• 8. Worden databasevelden snel bijgewerkt?
• 9. Zijn input, output en queries complex?
• 10. Zijn interne berekeningen complex?
• 11. Is de code bedoeld voor hergebruik?
• 12. Is dataconversie en software-installatie vereist?
• 13. Heeft u veel installaties nodig in verschillende organisaties?
• 14. Wil je maatwerk en gebruiksgemak behouden?

De waarden voor deze kenmerken zijn als volgt gedefinieerd: 0 - nooit; 1 - soms; 2 - zeldzaam; 3 - gemiddeld; 4 - vaak; 5 - altijd.

Deze kenmerken voor een voorbeeldfunctie zijn samengevat in de tabel. 9.3.

Tabel 9.3. Voorbeeld van projectkenmerken

Kenmerkend	Voorbeeld waarde	Kenmerkend	Voorbeeld waarde

Bepaal 5 - de som van alle gewichten.

Tenslotte wordt de verfijnde functionele omvang berekend met behulp van de formule

UFR = FR X (0,65 + 0,01 X 5). (9.3)

De verfijnde functionele omvang van de functieselectiemethode zal als volgt zijn:

UFR = 26 x (0,65 + 0,01 x 29) = 17,19.

Het resulterende resultaat laat zien dat de methodeselectiefunctie vrij eenvoudig is en niet veel arbeid vereist. De resulterende waarden worden vervolgens gebruikt om de kosten van het project te schatten.

Momenteel zijn er verschillende wijzigingen in de functiepuntmethode.

Eigendomspunten

In het geval dat de hierboven beschreven kenmerken niet de werkelijke complexiteit van de implementatie weerspiegelen (bijvoorbeeld bij het ontwikkelen besturingssystemen), in plaats van de functiepuntmethode, wordt de verbeterde versie ervan, voorgesteld in 1988 door Capers Jones, gebruikt: de eigenschapspuntmethode. Deze methode past schattingen aan die zijn verkregen door de functiepuntmethode, rekening houdend met de algoritmische complexiteit van het softwareproduct.

Mark II-methode

De Mark II-methode werd eveneens in 1988 door Charles Simons geïntroduceerd. Deze methode is geschikter voor het evalueren van complexe systemen dan de klassieke functiepuntmethode. Hiermee kunt u hetzelfde resultaat bereiken, zowel bij het beoordelen van het systeem als geheel als bij het optellen van de beoordelingen die zijn verkregen voor de samenstellende subsystemen.

3D-functiepunten

In 1991 stelde de softwaredivisie van Boeing Corporation een andere oplossing voor: de driedimensionale functiepuntmethode. Het verschil met de klassieke methode is dat de complexiteit van een softwareproduct op drie gebieden wordt beoordeeld: data, functies en beheer. Het voordeel van de methode is dat deze niet alleen toepasbaar is op de beoordeling van softwareprojecten, maar ook op de beoordeling van de arbeidsintensiteit van taken op andere activiteitsgebieden.

Objectpunten

De objectpuntmethode past de oorspronkelijke functiepuntmethode aan de objectgeoriënteerde programmeertechnologie aan.

Softwaregrenzen definiëren

De software die wordt ontwikkeld is volledig lokaal en voorziet niet in gegevensuitwisseling met andere software via lokale of mondiale netwerken.

Identificatie en evaluatie van datafunctionaliteit (ILF, EIF)

De software biedt werk met één intern logisch bestand (ILF). IN dit bestand Alle informatie die nodig is voor de software wordt opgeslagen: de grootte van de matrix, de coëfficiënten, de nauwkeurigheid van de berekeningen en de initiële benadering.

Het aantal data-elementtypen (DET's) van het interne logische bestand is zes:

1. n - aantal rijen in de matrix. Het aantal rijen is gelijk aan het aantal kolommen, aangezien de berekening wordt uitgevoerd voor zogenaamde vierkante matrices.

2. Mas - gegeven matrix.

3. - gespecificeerde nauwkeurigheid.

4. x 0 - initiële benadering.

5. - het resultaat van berekeningen is de maximale eigenwaarde van een gegeven matrix.

6. k - het aantal iteraties dat nodig is om de maximale eigenwaarde van de matrix met een gegeven nauwkeurigheid te berekenen.

Het aantal recordelementtypen (RET's) voor het interne logische bestand is vier:

1. Mas-matrix.

2. x 0 - vector.

3. n, k - gehele getallen.

4. , - reële cijfers.

Daarom wordt bepaald dat het complexiteitsniveau van het interne logische bestand laag is.

Deze software beschikt niet over externe interfacebestanden (ELF).

Identificatie en evaluatie van transactiefunctionaliteit (EI, EO, EQ)

Deze software biedt twee externe ingangen (EI): toetsenbordinvoer en bestandsinvoer.

Voor toetsenbordinvoer is het aantal data-elementtypen (DET's) vijf: Mas, x 0, n en de knop "Gegevens invoeren vanaf toetsenbord". Het aantal gebruikte typen (FTR) bedraagt ​​vijf.

Moeilijkheidsgraad voor van dit type input wordt als hoog gedefinieerd.

Voor bestandsinvoer zijn de resultaten hetzelfde als voor toetsenbordinvoer, behalve bij gebruik tekenreeks met de bestandsnaam en de bijbehorende knop om de gegevens te laden. Dat wil zeggen, DET = 6, FTR = 5. De moeilijkheidsgraad voor dit type invoer is als hoog gedefinieerd.

Deze software heeft slechts één extern verzoek (EQ) - een verzoek om de juistheid van de ingevoerde gegevens. Hiervoor zijn de variabelen Mas, x 0 , n nodig, hun waarden worden dienovereenkomstig gecontroleerd: voor de matrix - controleer op het invoeren van ongeldige symbolen - tekens of letters, voor de initiële benadering - op gelijkheid aan nul, invoeren van ongeldige tekens, voor de grootte van de matrix - behorend tot de gespecificeerde limieten, voor nauwkeurigheid - ordebeperking. Dus DET=4, FTR=3. De uitvoerinformatie van dit verzoek is 'De ingevoerde informatie is correct' of 'De ingevoerde informatie is onjuist'. Dat wil zeggen: DET=FTR=1. Het complexiteitsniveau van het externe verzoek wordt dus als gemiddeld gedefinieerd.

Deze softwaretool biedt twee externe uitgangen: gegevensuitvoer naar een bestand en gegevensuitvoer naar het scherm. Om gegevens op het scherm weer te geven, is het aantal typen DET-gegevenselementen gelijk aan vier: de opgegeven precisie, de resulterende maximale eigenwaarde van de matrix, het aantal iteraties en de knop "Bereken resultaten". Het aantal gebruikte FTR-typen is drie. Het complexiteitsniveau van het display wordt dus als gemiddeld gedefinieerd.

Om gegevens naar een bestand te schrijven, is het aantal typen DET-gegevenselementen vijf: maximale eigenwaarde, gespecificeerde precisie, aantal iteraties, bestandsnaam en de knop "Resultaten naar bestand schrijven". Het aantal gebruikte FTR-typen bedraagt ​​vier. Het niveau van complexiteit van de uitvoer naar een bestand wordt dus als gemiddeld gedefinieerd.

Bepaling van de normaliserende factor (VAF)

Laten we het niet-gestandaardiseerde aantal functiepunten berekenen.

Tafel 1. UFPC-berekening

Belangrijkste kenmerken van het systeem:

· De software is geïmplementeerd als één pakket op een autonome personal computer - 0.

· Gegevens worden niet overgedragen tussen de software en systeemcomponenten - 0.

· Softwareprestatie- en ontwerpvereisten zijn vastgesteld en beoordeeld, maar er zijn geen speciale maatregelen vereist om hieraan te voldoen - 1.

· Er zijn geen expliciete of impliciete beperkingen op het gebruik van middelen - 0.

· Er worden geen piektransactieperioden verwacht - 0.

· Complexiteit van interactieve transacties - ruim 30% wordt interactief verwerkt - 5.

· Efficiëntie van de software voor eindgebruiker - 2.

· Live-update afwezig - 0.

· Complexiteit van gegevensverwerking - 3.

· Er zit geen code in de software die bedoeld is voor hergebruik - 0.

· Nee speciale vereisten gebruiker en er is geen speciaal installatieprogramma vereist - 0.

· Gebruiksgemak - 1.

· Bij het ontwerp is rekening gehouden met de vereisten voor het installeren van de software en kan de software alleen worden uitgevoerd op vergelijkbare (compatibele) hardware en/of software - 2.

· Het wijzigen van de software is niet voorzien - 0.

De normalisatiefactor (VAF) berekenen we als volgt:

VAF=0,65+0,01*TDI=0,65+0,01*(1+5+2+3+2)=0,78

Berekening van het genormaliseerde aantal functiepunten

Het genormaliseerde aantal functiepunten wordt gedefinieerd als:

APFC=UPFC*VAF=35*0,78=26,3

Het schatten van het aantal regels broncode met behulp van de backfire-methode

De softwaretool zal worden ontwikkeld in de MS Visual Studio 2008-omgeving, dus de taalvermenigvuldigingswaarde is 34. Het geschatte aantal regels van het voltooide programma in de MS Visual Studio 2008-omgeving zal dus gelijk zijn aan.