Oma hea töö esitamine teadmistebaasi on lihtne. Kasutage allolevat vormi
Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.
Postitatud aadressil http://www.allbest.ru/
COCOMO, COCOMO II mudelid, funktsioonipunkti meetod. Nende võrdlev analüüs ja ulatus
Tarkvaratööriista elutsükli võib jagada kaheks osaks, mis erinevad oluliselt protsesside ja ressursside majanduslike iseärasuste, omaduste ja neid mõjutavate tegurite poolest. PS elutsükli esimeses osas viiakse läbi süsteemianalüüs, projekteerimine, arendus, testimine ja põhiversiooni katsetused tarkvaratoode. Tööde valik, nende töömahukus, kestus ja muud majanduslikud omadused neil elutsükli etappidel sõltuvad oluliselt objekti, tehnoloogia ja arendusvahendi keskkonna omadustest. Eriti oluline on võimaliku kogukulude kasvuga arvestada siis, kui tarkvaratoote kvaliteedile esitatavad nõuded on ülehinnatud. Nagu ka muud tüüpi tööstustoodete puhul, saavutatakse tarkvarapakettide kvaliteedi parandamine tavaliselt mitte proportsionaalse, vaid selleks vajaminevate ressursside märkimisväärsema suurendamisega. Selle ressursivajaduse vähendamine on sageli võimalik ainult põhimõtteline muutus ning disaini- ja arendustehnoloogia täiustamine.
Selle sammude osa jaoks elutsükkel mida iseloomustab töömahukuse, kestuse ja spetsialistide arvu ebaühtlane jaotus peamiste tööetappide lõikes. Maksimaalne töömahukus ja spetsialistide arv ilmneb komponentide programmeerimise ja testimise etappides, kui kaasatakse suurem osa programmeerijaid ja kodeerijaid. Kell aktiivne kasutamine ja tehnoloogiate täiustamine süsteemi analüüs ja disain, toimub igat tüüpi kulude ümberjagamine arengu algetappide töömahukuse suurendamise suunas. Selle tulemuseks on kogu projekti ressursikasutuse oluline vähenemine. Vähem on uuritud vajalike ressursside jaotamist tööetappide kaupa, võttes arvesse tarkvara kvaliteedi nõutavate spetsiifiliste omaduste realiseerimist. Avaldatud andmed ja sõltuvused erinevate tarkvaraklasside kohta võimaldavad prognoosida projekti kogukulusid ja muid peamisi tehnilisi ja majanduslikke näitajaid (TEI), selle töö plaane ja ajakavasid vastloodud tarkvaratoodete puhul.
Elutsükli teine osa, mis kajastab tarkvara käitamist, hooldust, muutmist, konfiguratsioonihaldust ja teistele platvormidele ülekandmist, on vajalike ressursside mahu osas vähem sõltuv objekti ja arenduskeskkonna funktsionaalsetest omadustest. Tööde ulatus nendes etappides on enam-vähem määratletud, kuid nende keerukus ja kestus võivad olla väga erinevad, olenevalt massist ja muudest välised tegurid tarkvaratoote konkreetsete versioonide levitamine ja kasutamine. Tarkvaratööriista edu kasutajate seas ja turul ning versiooniarenduse edasine protsess on raskesti prognoositav ning see ei ole otseselt seotud tarkvaraarendusprotsesside majanduslike parameetritega. Määravaks saavad toote tarbijaomadused ja nende majanduslikud omadused Arendajate vaatenurgast jäävad järgmise versiooni jaoks investeeritud ressursid tagaplaanile.
Sellest tulenevalt võib nende elutsükli etappide toetamiseks vajalike spetsialistide töömahukus ja arv olla väga erinev. See raskendab erinevate projektide tehniliste omaduste statistilist üldistamist ja nende põhjal uue arenduse sarnaste omaduste prognoosimist. Seetõttu on nendes etappides plaanidel töö sisu üldised seosed, mis nõuavad aja jooksul jaotamist iga projekti jaoks eraldi. Sellest tulenevalt tuleb nende etappide töömahukuse ja kestuse prognoosimine ja planeerimine toimuda iteratiivselt, lähtudes kogemuste kogumisest ja konkreetsete tarkvaraversioonide väljatöötamise analüüsist, samuti arvestades nende edukust turul.
Objektide (eriti tarkvara) protsesside või omaduste prognoosimiseks ja planeerimiseks kasutatakse kahte tüüpi lähteandmeid:
· prognoositava objekti või protsessi funktsioonid ja tunnuste nomenklatuur, mille elutsükkel on vajalik;
· prototüüpide ja pilootprojektide omadused, mis on mingil määral sarnased kavandatava objektiga, mille puhul on teada elluviidud plaanid ja juba lõppenud sarnaste protsesside vajalikud majanduslikud omadused nende loomiseks.
Nende kahe tüüpi lähteandmete ühine korrektne töötlemine võimaldab projekteerimise käigus hinnata ja saada uusi, prognoositavaid protsesse, plaane ja omadusi. majandusnäitajad PS loomine. Esimest tüüpi algandmed peegeldavad konkreetse loodava objekti või protsessi omadusi, kättesaadavad meetodid Ja tööriistad töö automatiseerimine nende loomise ajal. Need andmed on projekteerimise ja edasise juurutamise käigus järjepidevalt üksikasjalikud ja täpsustatud, mis võimaldab eelkõige selgitada sarnaste objektide komponentide valikut ja nende omadusi teist tüüpi lähteandmete jaoks.
Teist tüüpi lähteandmed tarkvara arendamise põhjendamiseks ja planeerimiseks koosnevad üldistatud projekteerimiskogemustest ja loodud tarkvaratoote prototüüpide majanduslikest omadustest. Usaldusväärseks planeerimiseks on vaja koguda, üldistada ja uurida konkreetseid andmeid elluviidud plaanide, kulude ja ressursside kohta, mida on kasutatud tarkvara arendusteks aastal. erinevaid aspekte. Selliseid tehnilisi ja majanduslikke näitajaid ja neid määravaid tegureid uuriti reaalsete kodu- ja välismaiste tarkvaraprojektide olulise statistilise materjali töötlemise protsessis ning kasutati allpool käsitletud prognoosimeetodites.
Tarkvaraprojekti teostatavusuuringu läbiviimisel mis tahes tasemel on soovitatav kasutada meetodeid ja tehnikaid, mis sobivad selle rakendamise eesmärkide ja etappidega. TEP hindamise eesmärgid tuleks ühildada teabevajadusega, mis toetaks otsuste tegemist tööjõu ja muude ressursside planeerimisel. Üldjuhul on erinevate tunnuste hindamisel vaja saavutada tasakaalustatud eesmärkide koosseis, mis annaks hinnangute määramatuse taseme absoluutväärtuse ligikaudu ühesuguse absoluutväärtuse kõikide tarkvara komponentide puhul. Lisaks peab iga tehniliste ja majanduslike näitajate hindamisega kaasnema märge selle määramatuse astme kohta. Projekti arenedes tuleks need hinnangud üle vaadata ja muuta, kui see osutub kasulikuks.
Kliendi kaasamine aitab ressursipiiranguid arvestades lahendada vähem valusalt projekti mastaabi ja teostatavate funktsioonide juhtimise probleeme. Sõltuvalt keeruka programmikomplekti väljatöötamise etapist ja tarkvaraprojekti omaduste ja funktsioonide algandmete usaldusväärsusest on soovitatav valida ja rakendada erinevaid tehnikaid ja stsenaariumid projekti teostatavusuuringuks ning selle tehniliste ja majanduslike näitajate prognoosimiseks. Projektiga töötamise algusest peale on oluline hoida pidevalt arvestust selle tegeliku tööjõumahukuse, kulude ja kulude dünaamika kohta ning võrrelda neid andmeid prognoositud projekti omaduste hinnangutega vastavalt projektile. järgmistel põhjustel:
· algandmete ebatäiuslikkus tehniliste ja majanduslike näitajate hindamisel sunnib projektijuhti hinnanguid üle vaatama, võttes arvesse uut teavet luua realistlikum alus edasiseks projektijuhtimiseks;
· PS hindamismeetodite ebatäiuslikkuse tõttu tuleks hinnanguid võrrelda tehniliste ja majanduslike näitajate tegelike väärtustega ning neid tulemusi kasutada hindamismeetodite täiustamiseks;
· Tarkvaraprojektid kipuvad muutma omadusi ja majanduslikke tegureid ning projektijuht peab need muudatused tuvastama ja kuluprognoose realistlikult värskendama.
Peamised ressursid arendajatele keerukate tarkvarapakettide loomisel on järgmised:
· vastuvõetavad tööjõukulud (kulu) nõutava kvaliteediga tarkvara arendamiseks;
· aeg – tarkvaratoote loomise täistsükli kestus;
· vajalik ja olemasolev arv vastava kvalifikatsiooniga spetsialiste.
Nende ressursside vajadus sõltub kõige suuremal määral arendatava tarkvara suurusest (mastaabist) ja keerukusest. Tarkvaratööriista ja selle komponentide suuruse täpsustamise saab otsustada järjestikku detailprojekti lõpuks, kuid tarkvarakompleksi suuruse ja selle töömahukuse hindamisel jääb ebakindlus suurusjärgus 5 - 10%. seotud sellega, kui hästi programmeerijad mõistavad spetsifikatsioone, mille kohaselt nad peavad programmi kodeerima. Soovitatav on arvestada sellega, et:
· tehniliste ja majanduslike näitajate hindamise eesmärgid peavad olema kooskõlas tarkvaraprojekti sobivas etapis otsuste tegemist hõlbustava teabe vajadusega;
· hinnangute usaldusväärsus peab olema tasakaalus erinevaid komponente süsteemid ja iga komponendi määramatuse tase peaksid olema ligikaudu samad, kui otsustusprotsessis on kõik komponendid ühesuguse kaaluga;
· tuleks naasta varasemate tehniliste ja majanduslike näitajate hindamise eesmärkide juurde ning neid vajadusel muuta varajases staadiumis tehtud ja järgnevaid etappe mõjutavate vastutustundlike eelarveotsuste jaoks.
Ilma usaldusväärse teabeta selle suuruse kohta on üsna raske hinnata ülesande täitmiseks vajalikku tööjõu hulka. Seega eelneb tehniliste ja majanduslike näitajate hindamisele suuruse (keerukuse) mõõtmine ning see hindamine omakorda töögraafiku koostamisele.
Ebapiisavalt usaldusväärsed hinnangud põhjustavad probleeme arendaja ja kliendi vahelises suhtluses ning suurendavad projekti riskiastet.
Tarkvara suuruse hinnang
Tarkvara suuruse määramise ja hindamise tegevused sisalduvad tarkvaraprojekti planeerimise ülesannete jadas. Neile eelneb projekti eesmärkide ja ulatuse määratlemine, tööjaotuse struktuuri (WBS) loomine ning ülesannete ja tegevuste määratlemine. Tarkvara suuruse prognoosimise ülesannete järel on arenduse kestuse ja maksumuse hindamise ülesanded, mille käigus toimub ressursside eraldamine, arvestades sõltuvusi ning töögraafiku koostamine.
Koodi suuruse ja taaskasutuspotentsiaali hindamine toimub elutsükli alguses. Suuruse ja pingutuse hindamisi tehakse projekti edenedes korduvalt, kusjuures iga hindamine suurendab kindlustunnet saadud tulemuste suhtes. Hea juht Projekt peab lihtsalt kehtestama reegliks hinnata tarkvara suurust, kasutades hindamistulemusi elutsükli iga etapi väljundparameetritena.
Tarkvaraarendusorganisatsioonid on aastaid otsinud vastuvõetavaid kvantitatiivseid meetodeid tootlikkuse mõõtmiseks, protsesside tõhususe hindamiseks ja tarkvaraarenduse kulude haldamiseks. Komistuskiviks oli tarkvara suuruse usaldusväärse mõõtühiku puudumine.
Praegu kasutatakse tarkvara suuruse hindamisel kõige sagedamini kahte peamist mõõtühikut - koodiridu (LOC) ja funktsioonipunkte.
Samuti saate kasutada atribuudipunkte, paksude punktide arvu andmevooskeemil (DFD), olemi diagrammil olevate olemite arvu, dokumentatsiooni hulka, objektide, atribuutide ja teenuste arvu objektiskeemil. mõõtühikud. Olenemata sellest, kas hinnatakse lõpptoodet, nagu LOC puhul, või selle mingit abstraktsiooni või mudelit, hinnatakse midagi, mida looduses veel ei eksisteeri. Seetõttu tekitab suuruste hindamine suuri raskusi.
LOC kasutamine mõõtühikuna tarkvara toote suurus
LOC-skoor on kõige universaalsem mõõdik, kuna seda saab kasutada mis tahes tarkvaratoote loomiseks. See on lihtsam ja arusaadavam nii spetsialistidele kui ka klientidele ja investoritele. Näiteks kui öeldakse, et tarkvarasüsteemi üks komponent, mis koosneb n komponendi jaoks on keskmiselt vaja kirjutada umbes 1000 rida programmi kood, siis oskab igaüks seda hinnata üldine suurus ja vähemalt ligikaudselt hinnata selle loomiseks kuluvat tööjõudu, lähtudes eeldusest, et ühe programmeerija keskmine tootlikkus on ikkagi umbes 3000 koodirida aastas.
Paljud tarkvaraarenduse eksperdid väidavad aga, et see on kehv mõõtühik. Kõige olulisem küsimus, mis LOC-hinnangute kasutamisel tekib, on see, mis moodustab ühe koodirea? Lisaks tekitab LOC-i kasutamine mõõtühikuna kahtlusi tulemuste usaldusväärsuse suhtes, kuna arvesse ei võeta järgmist:
ridade arv lähtekoodi oleneb programmeerija oskuste tasemest. Tegelikult, mida kõrgem on programmeerija oskus, seda vähem koodiridu suudab ta hallata tarkvara teatud funktsionaalsuse (või funktsionaalsuse) rakendamiseks;
· kõrgetasemelised keeled või visuaalsed programmeerimiskeeled nõuavad palju väiksem arv koodirida kui näiteks Assembly keel või C, et kajastada sama funktsiooni. Piisab ette kujutada kahte rakendust, millel on samad funktsioonid (samad ekraanid, aruanded, andmebaasitabelid), kuid mis on realiseeritud erinevaid keeli. Ilmselgelt on keeletaseme ja programmeerija toodangu vahel pöördvõrdeline seos;
· LOCide tegelik arv jääb teadmata, kuni projekt on peaaegu valmis. Seetõttu ei saa LOC-i kasutada arendustegevuse eelhinnanguks ja projekti ajakava koostamiseks;
· Programmeerimisringkonnas puudub kokkulepe koodiridade loendamise meetodi osas. Keelekonstruktsioonid, mida kasutatakse näiteks Visual C++, Assembly, Cobol või SQL-is, on täiesti erinevad. Meetod jääb üldiseks kõigi rakenduste jaoks, kaasa arvatud need, mis kasutavad erinevaid keeli;
· kliendil on raske aru saada, milline on seos tema poolt määratud tarkvarale esitatavate funktsionaalsete ja mittefunktsionaalsete (tehniliste) nõuete ning programmeerimistöö mahu vahel.
Samal ajal on hinnangute usaldusväärsuse suurendamiseks mitu piisavat lihtsad soovitused:
· Veenduge, et iga loendatav lähtekoodi rida sisaldab ainult ühte väidet. Kui üks rida sisaldab kahte semikooloniga eraldatud käivitatavat lauset, tuleb need arvestada kahe reana. Kui üks väide on jagatud mitmeks "füüsiliseks" realeks, loetakse see üheks reaks. Programmeerimiskeeled võimaldavad kasutada erinevaid kodeerimisreegleid, kuid tavaliselt on lihtsam määratleda üksikut lauset real, mida kompilaator või tõlk töötleb.
· Kaaluge kõiki käivitatavaid lauseid. Lõppkasutaja ei pruugi praktiliselt kõiki operaatoreid kasutada, kuid toode peaks toetama kõiki operaatoreid, sealhulgas utiliite.
· Kaaluge andmete määratlusi ainult üks kord.
· Ignoreeri kommentaare sisaldavaid ridu.
· Ärge lisage silumiskoodi ega muud ajutist koodi (proovitarkvara, testimistööriistad jne).
· Loendada iga initsialiseerimist, kõnet või makro (kompilaatori direktiiv) lisamist lähtekoodi osana, milles mõni toiming sooritatakse. Ärge arvestage uuesti kasutatud avaldusi.
Praktikas kasutatakse suurte tarkvarasüsteemide suuruse hindamisel sageli KSLOC-i tuhandete ridade lähtekoodi mõõdikut. Seda mõõdikut kasutatakse kõige sagedamini tootlikkuse hindamisel, mis arvutatakse kui KSLOC/SM, kus SM on personalikuu.
LOC-i hindamine eksperthinnangu ja alt-üles summeerimise abil.
Eeldusel, et struktuur Arendatava tarkvara WBS on jaotatud mitmeks dekomponeerimistasemeks, mis tõstavad esile tarkvarasüsteemi tegelikud komponendid ja annavad aluse ka edasiste detailide jaoks, on võimalik luua mingisugune “statistiline” suuruse mõõt, mida saab mis saadakse mõõtmise ja summeerimise protsesside abil.
Iga komponendi suuruse saab teada küsitledes selliseid süsteeme välja töötanud eksperte või küsitledes selliste süsteemide potentsiaalseid arendajaid. Selle tulemusena on võimalik iga ploki suurust hinnata madalam tase WBS-i struktuurid. Pärast hinnanguliste hinnangute liitmist ilmub ettekujutus tarkvarasüsteemi kui terviku suurusest. Seda meetodit nimetatakse alt-üles suuruse määramiseks.
Seda näitajat saab parandada, kui iga hindaja näitab mitte ühte, vaid kolme võimalikku suurusväärtust: pessimistlik, optimistlik ja enam-vähem realistlik. Seejärel liidetakse optimistlikud ja pessimistlikud hinnangud realistlikule väärtusele, mis on korrutatud 4-ga, ja kogusumma jagatakse 6-ga.
See meetod võimaldab saada tasakaalustatuma hinnangu, mis võtab arvesse ebakindluse tingimusi, milles hindamisprotsess ise toimub.
Näiteks kui mõni WBS-i struktuuris kuvatav objekt võib võtta 200–400 koodirida ja tõenäoliselt on selle suurus lähemal 200-le, siis pakutud lähenemisviisi kasutades saate järgmise hinnangu: (200+(250*4) +400)/6 = 266 LOC.
LOC-de arvu hindamine analoogia põhjal
Üks viise tarkvarasüsteemi hindamiseks projekti etapis on selle funktsionaalsete omaduste võrdlemine olemasolevate analoogidega.
Näiteks on meil valmis moodul A, mille suurus on 2345 LOC. Soovime luua uue mooduli, mis sarnaneb paljuski mooduliga A, kuid millele on lisatud mõned täiendavad omadused. Lisaks mõtlesime välja, kuidas programmi koodi kompaktsemaks muuta. Selle tulemusena võib mooduli A" suuruseks hinnata 3000 LOC.
Muidugi pole see meetod kuigi täpne, kuna mooduli A kirjutamisel sai kasutada erinevaid programmeerimiskeeli, kasutada erineva keerukusastmega algoritme ja erinevas mahus modelleerimist (simulatsioon, emuleerimine, tõeline rakendus), kuid sellisel hinnangul on siiski mõningane kvantitatiivne põhjendus.
LOC-i mõõtühikuna kasutamise eelised
· Need üksused on laialt levinud ja kohandatavad.
· Need võimaldavad võrrelda suurust ja jõudluse mõõtmise meetodeid erinevad rühmad arendajad.
· Otseselt seotud lõpptootega.
· LOC ühikuid saab hinnata enne projekti lõppu.
· Tarkvara suuruse hindamine viiakse läbi arendajate seisukohta arvestades.
· Pidevad parendustegevused põhinevad kvantitatiivsetel hinnangutel. Sel juhul saab prognoositavat suurust hõlpsasti võrrelda tegelik suurus projektijärgse analüüsi etapis. See võimaldab ekspertidel kogemusi omandada ja hindamismeetodeid ise täiustada.
· Tarkvaratoodete suuruse teadmine LOC-üksustes võimaldab projekti tehniliste ja majanduslike näitajate (nagu tööjõukulud, projekti kestus, maksumus jne) hindamiseks rakendada enamikke olemasolevaid meetodeid.
LOC-hinnangute kasutamisega seotud puudused
· Neid mõõtühikuid on raske rakendada elutsükli algfaasis, kui määramatuse tase on kõrge.
· Esialgsed juhised võib varieeruda olenevalt programmeerimiskeeltest, disainimeetoditest, stiilist ja programmeerijate võimetest.
· Ridade loenduse hindamismeetodite kasutamist ei reguleeri sellised tööstusstandardid nagu ISO.
· Tarkvaraarendust võib seostada suurte kuludega, mis ei sõltu otseselt programmikoodi suurusest. Need on nn püsikulud, mis on seotud nõuete spetsifikatsioonide väljatöötamisega, kasutaja dokumentatsiooni koostamisega jne, mis ei sisaldu kodeerimise otsekuludes.
· Programmeerijaid võidakse kõrgete LOC-näitajate saavutamise eest ebaõiglaselt premeerida, kui juhtkond peab seda tootlikkuse kõrgeks märgiks. Kuigi mõnikord näitab suur hulk kodeerimist programmi ebapiisavalt hoolika ülesehituse kohta. Lähtekood ei ole loomisel eesmärk omaette valmistoode, palju olulisem on tagada tarkvara vajalik funktsionaalsus ja saavutada kõrge meeskonna tööviljakus.
· LOC ühikute arvutamisel peaksite eristama automaatselt genereeritud koodi ja käsitsi kirjutatud koodi. See muudab selle kasutamise väga keeruliseks automaatsed meetodid loendamine.
· LOC indikaatoreid ei saa normaliseerimise ajal läbi viia, kui neid kasutati erinevad platvormid või programmeerimiskeelte tüübid.
· Ainus viis LOC-hinnangute saamine on võrdlus sarnaste arengute või ekspertarvamustega ja neid hinnanguid ei peeta esialgu täpseks.
· Koodigeneraatorid põhjustavad sageli liigset koodimahtu, mis võib põhjustada olulisi vigu koodi suuruse hindamisel.
Programmeerija tootlikkust mõõdetakse sageli toodetud koodiridade arvu järgi, kuid see ei vasta alati tõele. Kui programmeerija kirjutab kuus 200 rea asemel 250, ei tähenda see, et temast on kindlasti saanud parem töömees ja ta väärib julgustust. Õigem oleks võtta arvesse mitte ainult kirjutatud koodi kvantiteeti, vaid ka selle kvaliteeti, mida saab teha järgmise valemi abil:
Defektide arv / koodiridade arv
Enamiku projektide kodeerimisfaas võtab 7–20% jõupingutustest, seega on koodi kvaliteet olulisem kui koodi hulk.
Funktsioonipunktide kasutamine programmi suuruse ühikutena.
Esimene ja edukaim alternatiiv koodi lähtekoodiridade loendamise meetodile oli 1979. aastal IBM-i esindaja Allan Albrechti poolt välja töötatud metoodika, mida nimetatakse funktsioonipunktide analüüsiks (FPA, Function Points Analysis). See põhineb vaatel tarkvarale väljastpoolt, süsteemi kasutaja positsioonilt, mitte aga selle sisemiste omaduste (nt LOC) “väljastpoolt”. Analüüsi tulemusena esialgsed nõuded PS-le ja täpsustus tegelikud vajadused kasutajad määratakse helitugevuse järgi funktsionaalsust süsteemid, mille indikaatoriteks on infotöötlusfunktsioonid nii madal tase, kui palju need sobivad kasutaja mõtlemissüsteemi ja lisaks funktsioonidele ka andmeid, mida need funktsioonid töötlevad. Seega põhineb FPA metoodika ideel jagada funktsioonid ja andmed maksimaalselt vastuvõetavale (kasutaja seisukohast) tasemele. PS-i funktsionaalsete võimete maht (edaspidi lihtsalt funktsionaalne suurus) määratakse nn tavalistes funktsionaalsuse ühikutes FP - alates Funktsioonipunktid
Viie aasta jooksul alates selle loomisest lihvis FPA metoodika ja suuruse määramise meetod A. Albrecht ja läbis praktilise testimise ning 80ndate keskel loodi International Function Points User Group (IFPUG, International Function Points User Group). mis toetab meetodi edasist arengut.
Funktsioonipunkti meetod võimaldab teil lahendada järgmised probleemid:
· Lahendage probleem, mis on seotud LOC hinnangute saamise raskustega elutsükli varases staadiumis.
· Määrata sisend- ja väljundandmete hulk ja keerukus, nende struktuur ning tarkvarasüsteemiga seotud välised liidesed.
Funktsioonipunkti meetod kasutab 5 teabekarakteristikut.
1. Väliste sisendite arv. Arvestatakse kõiki kasutaja sisestusi, mis pakuvad erinevaid rakenduse andmeid. Kirjed tuleb eraldada päringutest, mida loetakse eraldi.
2. Väliste tihvtide arv. Kõik kontaktid loendatakse ja tarkvararakenduse arvutatud tulemused tagastatakse kasutajale. Väljundite all mõeldakse selles kontekstis aruandeid, ekraane, väljatrükke, veateateid. Aruande üksikuid andmeühikuid eraldi ei arvestata.
3. Väliste päringute arv. Päring on määratletud kui dialoogisisend, mille tulemuseks on kohene programmivastus dialoogiväljundi kujul. Sel juhul dialoogisisendit rakendusse ei salvestata ja dialoogiväljund ei vaja arvutusi. Kõik taotlused loetakse – igaüht loetakse eraldi.
4. Sisemiste loogiliste failide arv. Kõik loogilised failid (st loogilised andmerühmad, mis võivad olla andmebaasi või eraldi faili osad) loendatakse.
5. Välise liidese failide arv. Arvesse lähevad kõik teiste rakenduste loogilised failid, millele see rakendus viitab.
Sisendid, väljundid ja päringud liigitatakse tehinguteks. Tehing on kasutaja määratletud põhiprotsess, mis liigutab andmeid väliskeskkonna ja tarkvararakenduse vahel. Oma töös kasutavad tehingud sisemisi ja väliseid faile, mille jaoks võetakse kasutusele järgmised definitsioonid.
Välissisend on elementaarne protsess, mis liigutab andmed väliskeskkonnast rakendusse. Andmed võivad pärineda sisestusekraanilt või mõnest muust rakendusest. Andmeid saab kasutada sisemiste loogiliste failide värskendamiseks. Andmed võivad sisaldada nii juhtimis- kui ka äriteavet. Juhtandmed ei tohi sisemist loogilist faili muuta.
Väline järeldus on algeline protsess, mis viib rakenduses arvutatud andmed väliskeskkonda. Lisaks võidakse selle protsessi käigus värskendada sisemisi loogilisi faile. Andmed loovad aruandeid või väljundfaile, mis saadetakse teistele rakendustele. Aruanded ja failid luuakse sisemiste loogiliste failide ja väliste liideste failide põhjal. Lisaks võib see protsess kasutada sisendandmeid, mis sisaldavad otsingukriteeriume ja parameetreid, mida sisemised loogilised failid ei toeta. Sisendandmed tulevad väljastpoolt, kuid on ajutised ja neid ei salvestata sisemisse loogilisse faili.
Väline päring on elementaarne protsess, mis töötab nii sisend- kui ka väljundandmetega. Selle tulemuseks on sisemistest loogikafailidest ja välistest liidesefailidest tagastatud andmed. Protsessi sisendosa ei muuda sisemisi loogilisi faile ja väljundosa ei kanna rakenduse arvutatud andmeid (see on päringu ja väljundi erinevus).
Sisemine loogiline fail on kasutaja poolt äratuntav loogiliselt seotud andmete rühm, mida majutatakse rakenduses ja edastatakse väliste sisendite kaudu.
Välise liidese fail on kasutaja poolt äratuntav loogiliselt seotud andmete rühm, mida majutatakse ja hooldatakse mõnes teises rakenduses. Väline fail see rakendus on sisemine loogiline fail teises rakenduses.
Tehingute puhul põhineb järjestus faililinkide arvul ja andmeüksuste tüüpide arvul. Failide puhul põhineb järjestus failis sisalduvate kirjeelementide tüüpide ja andmeelementide tüüpide arvul.
tarkvara jõupingutuste elutsükkel
Postitatud saidile Allbest.ru
...Sarnased dokumendid
Elutsükli mudeli kasutamise otstarbekus muutuste juhtimise vahendina ettevõtetes. Elutsüklite tüüpide analüüs, nende seoste uurimine sobivatel majandusjuhtimise tasanditel. Muutusprotsesside dünaamika.
test, lisatud 12.11.2008
Projekt kui omavahel seotud tööde kogum, mille eesmärk on luua unikaalne tulemus aja- ja eelarvepiirangute raames, selle peamised omadused. Sisu ja ressursside, projekti aja ja maksumuse planeerimine, nõuete kogumine.
esitlus, lisatud 02.09.2015
Tarkvaratoote eesmärk. Nõuded jaoks funktsionaalsed omadused. Toote turu-uuring. Toote elutsükkel. Programmi arendamise töömahukuse arvutamine. Arendaja ettepaneku hinna kujunemine, kapitalikulude arvestus.
kursusetöö, lisatud 28.12.2012
Projekti elutsükkel ja selle faasid. Projekti jätkusuutlikkuse hindamine (riskid ja tasuvustase). Ajakao tegurid selle rakendamisel. Kavandatakse tööd piljardiklubi loomise projektiga 51 nädala jooksul, mille maksumus ei ületa 3,5 miljonit rubla.
kursusetöö, lisatud 22.12.2011
Organisatsiooni elutsükkel on arenguetappide kogum, mille ettevõte oma eksisteerimise jooksul läbib. Kollegiaalsuse etapi tunnused, tegevuse formaliseerimine, ümberstruktureerimine, majanduslangus. Elutsükli mudeli võimalused ja piirangud.
esitlus, lisatud 28.11.2013
Organisatsiooni elutsükli mõiste, selle erinevaid mudeleid ja peamised etapid. Juhi tegevused organisatsiooni erinevatel arenguetappidel, paljutõotavad selle arengumudelid. Ettevõtte Lecrus Ural LLC näitel läbitud elutsüklite analüüs.
kursusetöö, lisatud 28.02.2012
Organisatsiooni elutsükli olemus ja struktuur, selle peamised etapid ja tähendus. Organisatsiooni elutsükli analüüsi metoodika. Mehhanism organisatsiooni juhtimiseks selle elutsükli etappide kaupa. Organisatsiooni eluiga mõjutavad tegurid.
kursusetöö, lisatud 10.11.2010
Põhitootmise korraldus. Tootmisprotsesside mõiste ja klassifikatsioon. Toodete valmistamise tehnoloogiline ahel. Tootmistsükli kestuse arvutamine lihtne protsess. Tootmistsüklite kestuse vähendamise viisid.
esitlus, lisatud 06.11.2012
Üldine kontseptsioon projekti elutsükli kohta. Põhilised projektijuhtimise protsessid. Nafta- ja gaasiprojekti elutsükli ja protsesside analüüs OAO LUKOIL tegevusprojekti näitel. Projekti elutsükli faasi hindamine ja soovitused selle juhtimiseks.
kursusetöö, lisatud 13.01.2014
Restorani avamisprojekti juhtimise organisatsiooniline struktuur. Projektitöö jaotus. Haldusjuhtimise ülesannete jaotuse maatriks. Sisemise töömahukuse suhteliste näitajate määramine. Töömahukuse ja kasulikkuse võrdlus.
Tehingutega seotud funktsioonipunktide loendamine on funktsioonipunktide analüüsi neljas samm.
Tehing- see on elementaarne jagamatu suletud protsess, mis esindab kasutaja jaoks väärtust ja viib toote ühest järjekindlast olekust teise.
Meetod erineb järgmised tüübid tehingud (tabel 9):
- EI (external inputs) - välised sisendtehingud, elementaarne toiming andmete töötlemiseks või väljastpoolt süsteemi siseneva teabe kontrollimiseks.
- EO (välised väljundid) – välised väljundtehingud, elementaarne toiming andmete genereerimiseks või teabe kontrollimiseks, mis väljub süsteemist. Eeldab teatud loogikat ühe või mitme ILF-i teabe töötlemiseks või arvutamiseks.
- EQ (external inquiries) - välispäringud, elementaarne toiming, mis vastuseks välisele päringule hangib andmeid või kontrolliteave ILF-ist või EIF-ist.
Tabel 9. Peamised erinevused tehingutüüpide vahel. Legend: O - peamine; D - täiendav; NA – ei kohaldata.
Tehingu keerukuse hindamine põhineb järgmistel tunnustel:
- FTR ( failitüüp viidatud) - võimaldab teil arvu lugeda erinevaid faile(teabeobjektid) tüüpi ILF ja/või EIF, mida on tehingus muudetud või loetud.
- DET (andmeelemendi tüüp) – kordumatu kordumatu andmeväli. Näited. EI: sisestusväli, nupp. EO: aruande andmeväli, veateade. EQ: otsingu sisestusväli, otsingutulemuste väljundväli.
Tehingute keerukuse hindamiseks kasutatakse maatrikseid, mis on toodud tabelis 10 ja tabelis 11.
Tabel 10. Väliste sisendtehingute keerukuse maatriks (EI)
Tehingute hinnangu joondamata funktsioonipunktides (UFP) saab maatriksist (tabel 12)
Tabel 12. Tehingu keerukus joondamata funktsioonipunktides (UFP)
Näiteks vaadake kontrolltehingu (EI) hindamist dialoogiboksi jaoks, mis määrab MS-is õigekirjakontrolli valikud Office Outlook(Joonis 40).
Joonis 40. Dialoogiboks, mis juhib MS Office Outlooki õigekirjakontrolli
Iga märkeruudu väärtus on 1 DET. Rippmenüü - 1 DET. iga juhtnupp tuleks käsitleda eraldi tehinguna. Näiteks kui hindame kontrolltehingut nupuga “OK”, siis selle tehingu jaoks on meil 1 FTR ja 8 DET. Seetõttu saame maatriksi (tabel 10) järgi hinnata tehingu keerukust madalaks. Ja lõpuks, kooskõlas maatriksiga (tabel 12), see tehing tuleb hinnata kolmes joondamata funktsioonipunktis (UFP).
Joondamata funktsioonipunktide (UFP) koguarvu määramine
Toote kogumaht joondamata funktsioonipunktides (UFP-d) määratakse kõigi summeerimise teel infoobjektid(ILF, EIF) ja elementaaroperatsioonid (tehingud EI, EO, EQ).
Joondusteguri väärtuse (FAV) määramine
Lisaks funktsionaalsetele nõuetele kehtivad tootele kogu süsteemi hõlmavad nõuded, mis piiravad arendajaid lahenduse valikul ja suurendavad arenduse keerukust. Selle keerukuse arvessevõtmiseks kasutatakse tasandustegurit (VAF). VAF-teguri väärtus sõltub 14 parameetrist, mis määravad toote süsteemiomadused:
1. Andmevahetus(0 – toode on eraldiseisev rakendus; 5 – toode suhtleb rohkem kui ühe sideprotokolli kaudu).
2. Hajutatud andmetöötlus (0- toode ei liiguta andmeid; 5 - hajutatud andmetöötlust teostavad mitmed süsteemikomponendid).
3. Jõudlus (0- kasutaja jõudluse nõudeid ei ole kehtestatud; 5 - reageerimisaeg on tugevalt piiratud, kriitiline kogu äritegevuse jaoks, nõuete täitmiseks on vaja erinõudeid disainilahendused ja analüüsivahendid.
4. Riistvararessursside piirangud (0- piiranguid pole; 5 – kogu toode peab töötama kindlal protsessoril ja seda ei saa levitada).
- pole palju tehinguid, pole tippe; 5 - tehingute arv on suur ja ebaühtlane, vaja on erilahendusi ja tööriistu).6. Kasutaja interaktsiooni intensiivsus (0- kõik tehingud töödeldakse sisse partiirežiim; 5 – üle 30% tehingutest on interaktiivsed).
7. Ergonoomika(lõppkasutaja jõudlus) (0 – erinõudeid pole; 5 – väga ranged efektiivsusnõuded).
8. Andmete muutumise kiirus(ILF) kasutajate poolt (0 - ei nõuta; 5 - intensiivsed muudatused, ranged taastamisnõuded).
9. Töötlemisraskused (0- töötlemine on minimaalne; 5 - turvanõuded, loogiline ja matemaatiline keerukus, mitme keermega).
10. Taaskasutamine(0 – ei nõuta; 5 – toode on mõeldud standardse korduvkasutatava komponendina).
11. Paigaldamise lihtsus (0- puuduvad nõuded; 5 - tarkvara installimine ja värskendamine toimub automaatselt).
12. Haldamise lihtsus(0 – ei nõuta; 5 – süsteem taastab ennast automaatselt).
13. Kaasaskantavus(0 - tootel on ainult 1 installimine ühele protsessorile; 5 - süsteem on hajutatud ja nõuab installimist mitmele riistvarale ja operatsioonisüsteemile).
14. Paindlikkus (0- ei nõuta; 5 - paindlik süsteem päringuid ja kohandatud aruandeid koostades muudab andmemudelit kasutaja interaktiivne režiim).
14 süsteemi parameetrid(mõjuaste, DI) hinnatakse skaalal 0 kuni 5. Süsteemi 14 karakteristiku kogumõju (mõju koguaste, TDI) arvutatakse lihtsa liitmise teel:
TDI = ∑DI
Tasandusteguri väärtus arvutatakse valemi abil
VAF = (TDI *0,01) + 0,65
Näiteks kui kõik 14 süsteemiparameetrit said hindeks 3, on nende kogumõju TDI = 3 * 14 = 42. Sel juhul on tasandusteguri väärtus: VAF = (42 * 0,01) + 0,65 = 1,07
Joondatud funktsioonipunktide (AFP) arvu arvutamine
Edasine hindamine joondatud funktsioonipunktides sõltub hindamise tüübist. Esialgne hinnang joondatud funktsioonipunktide arvule tarkvararakendus määratakse järgmise valemiga:
AFP = UFP * VAF.
See võtab arvesse ainult tootes rakendatud uusi funktsioone. Tootearendusprojekti hinnatakse DFP-s (developmentfunctional point) järgmise valemi abil:
DFP = (UFP + CFP) * VAF,
Kus ÜKP(konversiooni funktsionaalne punkt) - funktsionaalsed punktid, mis arvutatakse toote installimisel vajalike lisafunktsioonide jaoks, näiteks andmete migratsioon.
Toote täiustamise ja täiustamise projekti hinnatakse EFP-s (täiustamise funktsionaalses punktis) järgmise valemi abil:
EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB),
- LISA- funktsioonipunktid funktsionaalsuse lisamiseks;
- CHGA- muudetud funktsioonide funktsioonipunktid, mis arvutatakse pärast muutmist;
- VAFA- pärast projekti lõpetamist arvutatud tasandusteguri väärtus;
- DEL- kaugfunktsionaalsuse ulatus;
- VAFB- enne projekti algust arvutatud tasandusteguri väärtus.
Joondamisprotseduuri kogumõju jääb ±35% piiresse UFP-s arvutatud mahust.
Funktsioonipunktide analüüsi meetod ei ütle midagi hinnatava toote väljatöötamise töömahukuse kohta. Probleem lahendatakse lihtsalt siis, kui arendajaettevõttel on funktsionaalsete punktide rakendamiseks oma tööjõukulude statistika. Kui selline statistika ei ole kättesaadav, saab COCOMO II meetodit kasutada projekti töömahukuse ja ajastuse hindamiseks.
Tarkvaratoote funktsionaalsete punktide arvu hinnang tuletatakse andmete põhjal, mis määratakse programmi teabeala analüüsimise ja selle toimimise funktsioonide uurimise tulemusena.
Teabeparameetrid on määratletud järgmiselt:
Kasutajate sisselogimiste arv. Arvestatakse iga kasutaja sisendit, mis toodab erinevaid sihitud andmeid. konkreetne rakendus. Sisendid peavad erinema kasutaja päringutest, mida loendatakse eraldi.
Kasutajate väljumiste arv. Iga kasutaja väljund loendatakse, mis loob kasutaja jaoks rakendusepõhise teabe. Väljundid hõlmavad aruandeid, ekraane, veateateid jne. Üksikud elemendid väljundandmeid ei arvestata.
Kasutajate taotluste arv. Iga päring loendatakse ja seda käsitletakse eraldi võrgusisendina, mille tulemusel genereeritakse kohene tarkvaravastus võrguväljundi kujul.
Failide arv. Loendatakse peamiste loogiliste failide (andmete loogiliste rühmade) arv, mis võivad olla osa piisavalt suurest andmebaasist.
Väliste liideste arv. Loendatakse kõik masinloetavad liidesed (näiteks juurdepääsud välisel andmekandjal olevatele andmefailidele, mida kasutatakse teabe edastamiseks teistele süsteemidele).
Igale numbrilisele parameetri väärtusele omistatakse vastav kaalutegur, mis võtab arvesse, kui raskelt või lihtsalt saab kõnealust parameetrit realiseerida. Ilmselgelt on selline keerukuse hinnang asjatundlik ja üsna subjektiivne.
Funktsionaalsete punktide arvu, s.o kogu tarkvaratoote FT-mõõdu lõplikuks arvutamiseks on vaja lisaks arvesse võtta 14 tegurit, mille jaoks on koostatud kaalumiskoefitsientide skaala, mis kajastab tarkvara mõjuastet. eriline tegur tarkvaratoote töötamise ajal. Koefitsiendi skaala on järgmine:
Ei mõjuta - 0.
Juhuslik mõju -1.
Mõõdukas mõju - 2.
Keskmine mõju - 3.
Oluline mõju – 4.
Märkimisväärne mõju - 5.
Selle skaala abil hinnatakse asjatundlikult ka iga järgmise teguri mõju taset, mis määravad toote toimimise omadused:
1. Kas süsteem vajab usaldusväärset varundamist ja sellele järgnevat taastamist pärast riket?
2. Kas andmeedastus on vajalik?
3. Kas on olemas hajutatud töötlemisfunktsioonid?
4. Kas tarkvaratoote jõudlus on kriitiline?
5. Kas süsteem toimib olemasolevas või keerulisemas töökeskkonnas?
6. Kas süsteem nõuab andmete veebis sisestamist?
7. Kas on nõutav internetis tehingute sisestamine, mis võimaldaks luua erinevad ekraanid kasutatakse paljude operatsioonide puhul?
8. Kas põhifaili värskendatakse võrgus?
9. Kas sisendid, väljundid, failid või päringud on keerulised?
10. Are keerulised algoritmid andmetöötlus
Kaalukoefitsiendid on toodud tabelis.
Arvutusprotseduur
1. Määrake süsteemi parameetrid (sisendid/väljundid)
2. Igale parameetrile määratakse oma kaalutegur, võttes arvesse parameetri rakendamise keerukust
3. Määrake kõigi parameetrite üldtulemus
4. FT-de arv määratakse valemiga FT=üldsumma(0,65+0,01 koefitsientide summa)
FT abil saab määrata tööviljakust, ühe punkti väljatöötamise maksumust, dokumentatsiooni lehekülgede arvu punkti kohta jne.
Seda meetodit kasutatakse jõudluse mõõtmiseks vananenud lineaarse lähenemisviisi asendajana, kus jõudlust mõõdeti koodiridade arvu järgi. Funktsioonipunktid pakkus esmakordselt välja IBMi töötaja Alan Albrecht 1979. aastal.
Eelis seda meetodit seisneb selles, et kuna funktsioonipunktide rakendamine põhineb nõuete uurimisel, saab projekti kõige varasemates etappides koostada vajaliku tööjõukulu hinnangu. Selle meetodi toetamiseks ja arendamiseks loodi 1986. aastal International Function Point User Group (IFPUG – International Function Point User Group).
Meetod on järgmine.
Esiteks tuuakse välja arendatava tarkvara funktsioonid ja seda kasutajate tasemel, mitte programmikoodi. Näiteks kaaluge tarkvarapaketti, mis rakendab ühemõõtmeliste massiivide sortimiseks erinevaid meetodeid. Selle kompleksi kasutaja üheks funktsiooniks on meetodi valik ja me kirjeldame seda näitena.
Meetodi järgmine samm on allpool toodud tegurite arvu loendamine:
- välised sisendid. Erinevad on ainult need sisendid, mis funktsiooni erinevalt mõjutavad. Meetodi valiku funktsioonil on üks väline sisend;
- välised väljapääsud. Väljundid jaoks erinevaid algoritme. Kujutagem ette, et meie funktsioon koostab sõnumi - valitud meetodi tekstikirjelduse ja kutsub välja teise funktsiooni, mis rakendab otseselt valitud sorteerimisalgoritmi, seega on sellel kaks väljundit;
- välised taotlused. Meie näites pole ühtegi;
- sisemised loogilised failid - funktsiooni poolt loodud või hooldatud andmerühm loetakse üheks. Me võtame oma funktsiooni sisemise loogilise failina tekstifail, mis sisaldab algoritmide kirjeldusi;
- välised loogilised failid - kasutajaandmed, mis asuvad selle funktsiooni välistes failides. Iga andmerühm võetakse üheks. Meie funktsiooniväline on töötlemistulemuse fail.
Seejärel korrutatakse saadud väärtused iga teguri keerukuskoefitsientidega (vastavalt 1PP1Yu andmetele) ja summeeritakse, et saada tarkvaratoote täissuurus. Nende koefitsientide väärtused on toodud tabelis. 9.1.
Tabel 9.1. Raskuskoefitsiendi väärtused
Vaadeldava näite jaoks võtame tabelis toodud väärtused. 9.2.
Meie funktsiooni suurus on järgmine:
FR = 1x3+1x4+1x5+1x7+1x7 = 26.
See number on eelhinnang ja vajab selgitust.
Tabel 9.2. Raskuskoefitsientide näide
|
Parameeter | ||||||
|
Välised sisendid |
||||||
|
Välised väljundid |
||||||
|
Välised taotlused |
||||||
|
Sisemised loogilised failid |
||||||
|
Välised loogilised failid |
||||||
Järgmine samm funktsioonipunkti meetodi abil koodi suuruse määramisel on igale disainitunnusele kaal (0 kuni 5). Loetleme järgmised omadused:
- 1. Kas see on nõutav varukoopia andmed?
- 2. Andmevahetus on vajalik?
- 3. Kas kasutate hajutatud andmetöötlust?
- 4. Kas jõudlus on oluline?
- 5. Kas programm töötab tugevalt koormatud riistvaraga?
- 6. Kas andmete veebis sisestamine on vajalik?
- 7. Kas kasutate andmete sisestamiseks palju vorme?
- 8. Kas andmebaasivälju uuendatakse kiiresti?
- 9. Kas sisend, väljund, päringud on keerulised?
- 10. Kas sisemised arvutused on keerulised?
- 11. Kas kood on ette nähtud taaskasutamiseks?
- 12. Kas andmete teisendamine ja tarkvara installimine on vajalik?
- 13. Kas vajate erinevates organisatsioonides palju installatsioone?
- 14. Kas peate säilitama kohandamise ja kasutusmugavuse?
Nende omaduste väärtused on määratletud järgmiselt: 0 - mitte kunagi; 1 - mõnikord; 2 - haruldane; 3 - keskmine; 4 - sageli; 5 - alati.
Need näidisfunktsiooni omadused on kokku võetud tabelis. 9.3.
Tabel 9.3. Näide projekti omadustest
|
Iseloomulik |
Näidisväärtus |
Iseloomulik |
Näidisväärtus |
Defineeri 5 – kõigi kaalude summa.
Lõpuks arvutatakse rafineeritud funktsionaalne suurus valemi abil
UFR = FR X (0,65 + 0,01 X 5). (9.3)
Funktsiooni valimise meetodi täpsustatud funktsionaalne suurus on järgmine:
UFR = 26 x (0,65 + 0,01 x 29) = 17,19.
Saadud tulemus näitab, et meetodi valimise funktsioon on üsna lihtne ega nõua palju tööjõudu. Saadud väärtusi kasutatakse seejärel projekti maksumuse hindamiseks.
Praegu on funktsioonipunkti meetodil mitu modifikatsiooni.
Omandi punktid
Kui ülalkirjeldatud omadused ei peegelda rakendamise tegelikku keerukust (näiteks väljatöötamisel operatsioonisüsteemid), kasutatakse funktsioonipunkti meetodi asemel selle täiustatud versiooni, mille pakkus välja 1988. aastal Capers Jones – omaduspunkti meetodit. See meetod kohandab funktsioonipunkti meetodil saadud hinnanguid, võttes arvesse tarkvaratoote algoritmilist keerukust.
Mark II meetod
Mark II meetodi võttis Charles Simons kasutusele ka 1988. aastal. See meetod sobib keerukamate süsteemide hindamiseks paremini kui klassikaline funktsioonipunkti meetod. See võimaldab teil saavutada sama tulemuse nii süsteemi kui terviku hindamisel kui ka selle koostisosade allsüsteemide kohta saadud hinnangute summeerimisel.
3D funktsioonipunktid
1991. aastal pakkus Boeing Corporationi tarkvaraosakond välja teise lahenduse – kolmemõõtmelise funktsioonipunkti meetodi. Erinevus klassikalisest meetodist seisneb selles, et tarkvaratoote keerukust hinnatakse kolmes valdkonnas – andmed, funktsioonid ja haldus. Meetodi eeliseks on selle rakendatavus mitte ainult tarkvaraprojektide hindamisel, vaid ka muude tegevusvaldkondade ülesannete töömahukuse hindamisel.
Objekti punktid
Objektipunkti meetod kohandab algse funktsioonipunkti meetodi objektorienteeritud programmeerimistehnoloogiaga.
Tarkvara piiride määratlemine
Arendatav tarkvara on täielikult lokaalne ega võimalda andmevahetust muu tarkvaraga kohalike või globaalsete võrkude kaudu.
Andmete funktsionaalsuse tuvastamine ja hindamine (ILF, EIF)
Tarkvara pakub tööd ühe sisemise loogilise failiga (ILF). IN see fail Salvestatud on kogu tarkvara jaoks vajalik info: maatriksi suurus, selle koefitsiendid, arvutuste täpsus ja esialgne lähendus.
Sisemise loogikafaili andmeelementide tüüpide (DET) arv on kuus:
1. n - ridade arv maatriksis. Ridade arv on võrdne veergude arvuga, kuna arvutused tehakse nn ruutmaatriksite jaoks.
2. Mas - antud maatriks.
3. - määratud täpsus.
4. x 0 - esialgne lähendus.
5. - arvutuste tulemuseks on antud maatriksi maksimaalne omaväärtus.
6. k - iteratsioonide arv, mis on vajalik maatriksi maksimaalse omaväärtuse arvutamiseks etteantud täpsusega.
Sisemise loogikafaili kirjeelementide tüüpide (RET-de) arv on neli:
1. Mas - maatriks.
2. x 0 - vektor.
3. n, k - täisarvud.
4. , - reaalarvud.
Seetõttu määratakse sisemise loogikafaili keerukuse tase madalaks.
Sellel tarkvaral ei ole väliseid liidesefaile (ELF).
Tehingu funktsionaalsuse tuvastamine ja hindamine (EI, EO, EQ)
Sellel tarkvaral on kaks välist sisendit (EI): klaviatuuri sisend ja failisisend.
Klaviatuurisisestuse puhul on andmeelementide tüüpide (DET) arv viis: Mas, x 0 , n ja nupp „Sisesta klaviatuurilt andmed”. Kasutatavate tüüpide arv (FTR) on viis.
Raskusaste jaoks seda tüüpi sisend on määratletud kõrgena.
Failisisestuse puhul on tulemused samad, mis klaviatuurisisestuse puhul, välja arvatud kasutamine märgistring failinime ja vastava nupuga andmete laadimiseks. See tähendab, et DET = 6, FTR = 5. Seda tüüpi sisendi raskusaste on määratletud kõrgena.
Sellel tarkvaral on ainult üks väline päring (EQ) – päring sisestatud andmete õigsuse kohta. Selleks on vaja muutujaid Mas, x 0 , n, nende väärtusi kontrollitakse vastavalt: maatriksi jaoks - kontrollige kehtetute sümbolite - märkide või tähtede - sisestamist, esialgse lähenduse jaoks - nulliga võrdsust, valede märkide sisestamist, maatriksi suuruse jaoks - määratud piiridesse kuulumine, täpsuse jaoks - järjekorra piirang. Seega DET=4, FTR=3. Selle päringu väljundteave on "Sisestatud teave on õige" või "Sisestatud teave on vale". See tähendab, et DET=FTR=1. Seega on välise päringu keerukusaste määratletud keskmisena.
Sellel tarkvaratööriistal on kaks välist väljundit: andmeväljund faili ja andmete väljund ekraanile. Andmete kuvamiseks ekraanil on DET-andmeelementide tüüpide arv võrdne neljaga: määratud täpsus, sellest tulenev maatriksi maksimaalne omaväärtus, iteratsioonide arv ja nupp “Arvuta tulemused”. Kasutatud FTR tüüpide arv on kolm. Seega on kuvari keerukusaste määratletud keskmisena.
Andmete faili kirjutamiseks on DET-andmeelementide tüüpide arv viis: maksimaalne omaväärtus, määratud täpsus, iteratsioonide arv, faili nimi ja nupp “Kirjuta tulemused faili”. Kasutatud FTR tüüpide arv on neli. Seega määratletakse faili väljundi keerukuse tase keskmisena.
Normaliseeriva teguri (VAF) määramine
Arvutame mittestandardiseeritud funktsioonipunktide arvu.
Tabel 1. UPPC arvutus
Süsteemi peamised omadused:
· Tarkvara on realiseeritud ühe paketina autonoomses personaalarvutis - 0.
· Andmeid ei edastata tarkvara ja süsteemikomponentide vahel – 0.
· Tarkvara jõudluse ja disaini nõuded on kehtestatud ja üle vaadatud, kuid nende täitmiseks pole vaja erimeetmeid võtta – 1.
· Ressursikasutusel ei ole otseseid ega kaudseid piiranguid – 0.
· Tehingu tippperioode pole oodata – 0.
· Interaktiivsete tehingute keerukus - üle 30% töödeldakse interaktiivselt - 5.
· Tarkvara tõhusus lõppkasutaja - 2.
· Reaalajas värskendus puudub - 0.
· Andmetöötluse keerukus – 3.
· Korduskasutuseks mõeldud tarkvaras puudub kood – 0.
· Ei erinõuded kasutaja ja spetsiaalset installiprogrammi pole vaja - 0.
· Kasutuslihtsus – 1.
· Projekteerimisel on arvestatud tarkvara installeerimise nõuetega ning tarkvara saab teostada ainult sarnasel (ühilduval) riistvaral ja/või tarkvara - 2.
· Tarkvara muutmist ei pakuta - 0.
Arvutame normaliseerimisteguri (VAF) järgmiselt:
VAF=0,65+0,01*TDI=0,65+0,01*(1+5+2+3+2)=0,78
Funktsioonipunktide normaliseeritud arvu arvutamine
Funktsioonipunktide normaliseeritud arv on määratletud järgmiselt:
APFC=UPFC*VAF=35*0,78=26,3
Lähtekoodi ridade arvu hindamine tagasilöögi meetodil
Tarkvaratööriista arendatakse MS Visual Studio 2008 keskkonnas, seega on keelekordaja väärtus 34. Seega on valminud programmi ligikaudne ridade arv MS Visual Studio 2008 keskkonnas võrdne.
