Santrauka
Reikalavimų atsekamumas paprastai laikomas proceso problema: komandoms nurodoma palaikyti sąsajas tarp reikalavimų, darbo elementų ir testų, o nesėkmės priskiriamos nepakankamai proceso drausmei. Šiame straipsnyje teigiama, kad didelė dalis atsekamumo nesėkmių yra struktūrinės, o ne elgsenos nulemtos. Reikalavimų sistemoje egzistuoja keturių rūšių teiginiai: norma (kaip sistema turi elgtis), pokytis (vieno perėjimo įrašas), būsena (kaip sistema elgiasi dabar) ir verifikavimas (būsenos patikrinimas pagal normą). Šių keturių rūšių teiginių gyvavimo ciklai tarpusavyje nesuderinami. Kai du iš jų talpinami viename artefakte, atsiranda konkreti ir nuspėjama nesėkmė, o jos tipą lemia tai, kurios dvi rūšys buvo suplaktos. Iš reikalavimo kaip normatyvinio teiginio prigimties išvedame būtinas reikalavimų artefakto savybes, pateikiame šešių porinių suplakimų tipologiją ir vieną degeneracinį atvejį, susijusį su tapatybe, kiekvieną jų susiejame su stebimu simptomu ir iliustruojame tipologiją pramoniniu atveju, kai organizacija teisingai pašalino vieną suplakimą ir dėl to sukūrė kitą. Straipsnio pabaigoje analizuojama, kada suplakimas yra racionalus ekonomiškumo sprendimas, o kada jo kaina viršija naudą.
1. Įvadas
Kiekviena brandi kūrimo organizacija anksčiau ar vėliau susiduria su tuo pačiu klausimu: ar sistema iš tikrųjų daro tai, ką nurodo reikalavimai, ir kaip mes tai žinotume? Standartinis atsakymas yra atsekamumas – palaikomas sąsajų tinklas nuo reikalavimų iki projektavimo, kodo, darbo elementų ir testų. Tyrimų literatūroje atsekamumas kaip atskira problema nagrinėjamas jau tris dešimtmečius, pradedant Gotel ir Finkelstein (1994) analize; taip pat yra daug darbų apie sąsajų kūrimą, atkūrimą ir palaikymą (Cleland-Huang, Gotel ir Zisman, 2012). Pramoniniai standartai, tokie kaip ISO/IEC/IEEE 29148, nustato atsekamumą kaip reikalavimų specifikacijų kokybės atributą.
Vis dėlto praktikoje atsekamumas nyksta, ir šis nykimas yra stebėtinai panašus organizacijose, kurios skiriasi naudojamais įrankiais, sritimi ir procesų brandumu. Komandos, susiejančios testus su vartotojo istorijomis, po kelių leidimų pastebi, kad nebegali pasakyti, ką apima jų regresijos testų rinkinys. Komandos, kurios dabartinės sistemos apėjimo sprendimus dokumentuoja reikalavimuose, pastebi, kad skaitytojai nebegali atskirti ketinimo nuo aprašymo. Komandos, kurios pernumeruoja specifikacijos žingsnius, pastebi, kad visos išorinės nuorodos tyliai persislinko. Šios nesėkmės paprastai diagnozuojamos kaip proceso drausmės trūkumai ir į jas atsakoma dar didesniu proceso kiekiu.
Šiame straipsnyje siūloma kita diagnozė. Aukščiau aprašytos nesėkmės nėra drausmės trūkumo pasekmė – jas lemia pasirinktas artefaktų modelis. Jos deterministiškai kyla iš sprendimų, kuris artefaktas turi talpinti kokios rūšies teiginį. Reikalavimų sistema, nepriklausomai nuo naudojamų įrankių, turi sutalpinti keturių rūšių teiginius, kurių gyvavimo ciklai nesuderinami. Artefaktas gali saugiai talpinti vieną iš jų. Kai tik jis talpina du, jų gyvavimo ciklų neatitikimas sukuria konkrečią nesėkmės rūšį, kurią galima nuspėti vien iš šios poros, dar prieš atsirandant projekto istorijai. Taigi atsekamumas žlunga dėl konstrukcijos: jokia drausmė negali palaikyti nuorodų, kurių atraminis objektas struktūriškai nepajėgus išlaikyti.
Šio straipsnio indėlis yra trejopas. Pirma, būtinas reikalavimų artefakto savybes išvedame iš pačios reikalavimo prigimties, o ne postuluojame jas kaip gerąją praktiką (3 skyrius). Antra, pateikiame gyvavimo ciklų suplakimų tipologiją, kur kiekvienas suplakimas turi savo nesėkmės mechanizmą ir stebimą simptomą, todėl praktikui leidžiama diagnozuoti artefaktų modelį vien jį apžiūrint (5 skyrius). Trečia, pateikiame pramoninį atvejį, parodantį neakivaizdžią tipologijos pasekmę: vieno suplakimo pašalinimas, net ir teisingai bei dėl gerų priežasčių, gali sukurti kitą, jei nenustatomas tapatybės sluoksnis (6 skyrius).
2. Susiję darbai ir vieta tyrimų kontekste
Atsekamumo literatūroje, pradedant Gotel ir Finkelstein (1994), klausiama, kaip galima kurti, atkurti ir palaikyti sąsajas tarp artefaktų. Joje numanoma prielaida, kad sąsajų galiniai taškai yra tinkami, o sunkumas slypi pačiame susiejime. Šiame straipsnyje abejojama šia prielaida: teigiame, kad sąsajų nykimą dažnai lemia ne silpna susiejimo praktika, o galiniai taškai, kurių gyvavimo ciklas neleidžia jiems būti stabiliais atramos taškais. Šia prasme šis darbas nagrinėja ankstesnę problemą nei atsekamumo literatūra – sąlygas, kuriomis jos metodai apskritai gali veikti.
Klasikinį aprašomųjų ir normatyvinių teiginių skirtumą reikalavimuose pateikia Zave ir Jackson (1997), atskirdami indikatyvius teiginius apie aplinką nuo optatyvių teiginių apie pageidaujamą sistemą. Remiamės šiuo nuosakų skirtumu, tačiau išplečiame jį laiko ašyje: mūsų keturios teiginių rūšys skiriasi ne tik nuosaka, bet ir gyvavimo ciklu, o būtent gyvavimo ciklų nesuderinamumas, o ne nuosakos skirtumas, sukuria nesėkmių tipologiją.
Agile metodai, reikalavimų dokumentą iš esmės pakeitę darbų sąrašu, efektyviai suliejo reikalavimą su darbo elementu; elgsenos skatinamas kūrimas (BDD, North, 2006) pasiūlė reikalavimą sulieti su vykdomu verifikavimu. Abu šie judėjimai čia analizuojami ne kaip metodologinės pozicijos, už kurias reikia arba nereikia pasisakyti, o kaip suplakimo atvejai, kurių kaštus ir naudą galima tiksliai įvardyti (5 ir 7 skyriai). Reikalavimų valdymo įrankiai DOORS tradicijoje suteikia reikalavimų objektams unikalius identifikatorius; 4 skyriuje pažymime, kad identifikavimo schema savaime neapsaugo nuo suplakimo, nes problema slypi tame, ką identifikuotas objektas talpina, o ne tame, ar jis turi pavadinimą.
3. Reikalavimo prigimtis ir būtinos jo savybės
Reikalavimas yra teiginys apie sistemos elgseną, kurio galiojimas nėra apribotas laike. Jis teigia, kaip sistema turi elgtis, o ne kaip ji elgėsi vienos iteracijos metu ar iki tam tikros datos. Tai normatyvinis teiginys ta prasme, kad sistema gali jo nesilaikyti, bet negali jo paneigti: neatitikimas tarp sistemos ir reikalavimo yra sistemos defektas arba reikalavimo savininko sprendimo taškas, bet ne automatinis reikalavimo pataisymas.
Iš šios prigimties kyla kelios savybės. Tai nėra konvencijos ar gerosios praktikos – kiekviena jų išplaukia iš to, kas yra reikalavimas.
Pirma, reikalavimas turi turėti nuo turinio atskirtą tapatybę. Teiginys per savo gyvavimo laiką yra tikslinamas, performuluojamas ir taisomas, tačiau išlieka tas pats teiginys. Jei tapatybė būtų susieta su turiniu, kiekvienas redakcinis patobulinimas sukurtų naują reikalavimą ir paliktų be savininko viską, kas buvo susieta su senuoju.
Antra, tapatybė turi būti atskirta nuo pozicijos. Reikalavimai gyvena kompozicijose, dokumentuose, srautuose ir hierarchijose, o kompozicijos pertvarkomos. Jei tapatybė būtų pozicinė, kiekvienas perrikiavimas tyliai nukreiptų visas išorines nuorodas į kitus objektus. Tai blogesnė nesėkmė nei nuorodų nutrūkimas, nes jos neįmanoma aptikti.
Trečia, reikalavimas neturi turėti galutinės būsenos. Norma neužsidaro. Artefaktas, kuris kartais būna baigtas, išspręstas ar atliktas, negali talpinti reikalavimo, nes uždarymo momentu reikalavimas arba miršta kartu su juo, arba turi būti perkeltas, o perkėlimas spaudžiant terminams neįvyksta.
Ketvirta, reikalavimo artefakto detalumo lygis turi atitikti lygį, kuriuo sistema keičiama ir tikrinama. Darbo elementai ir testavimo atvejai siejami su reikalavimais; jei reikalavimo objektas yra stambesnis už pokyčio ar verifikavimo vienetą, sąsaja priverstinai keliama į objektą, kuriame yra daug elgsenų, ir tikslumas prarandamas būtent ten, kur jo labiausiai reikia.
Penkta, reikalavimas turi būti atskirtas nuo faktinių teiginių apie dabartinę sistemą. Šių dviejų rūšių teiginių tiesos sąlygos skiriasi: normą pažeidžia realybė, o aprašymą realybė paneigia. Laikyti juos viename lauke yra kategorijos klaida, kurios praktinė pasekmė aprašyta 5 skyriuje.
4. Keturi dalyviai ir vienas atramos taškas
Veikianti reikalavimų sistema apima keturių rūšių teiginius. Toliau juos taip vadinsime.
Norma: kaip sistema turi elgtis. Normatyvinė. Nuolatinė, tikslinama, bet niekada neuždaroma; kiekvienu momentu egzistuoja tik viena galiojanti formuluotė.
Pokytis: vieno perėjimo nuo vienos numatytos ar faktinės elgsenos prie kitos įrašas. Įvykdytas jis tampa istorinis. Jis baigtinis: prasideda, yra atliekamas, užbaigiamas ir kaupia istoriją. Daugumoje organizacijų tai yra vartotojo istorija (user story), pakeitimo užklausa arba defekto taisymas.
Būsena: kaip sistema elgiasi dabar. Aprašomoji. Nuolatinė, bet kintanti: ji egzistuoja nuolat ir perrašoma kiekvieno diegimo metu, įskaitant nesėkmingus ar dalinai pavykusius diegimus. Svarbiausia, būsena nėra įvykdytų pokyčių suma; pokyčiai gali būti įgyvendinti su defektais, atšaukti ar perrašyti, todėl būsena turi būti registruojama, o ne išvedama.
Verifikavimas: patikrinimas, ar būsena atitinka normą. Pakartojamas. Jis egzistuoja tol, kol egzistuoja norma, ir vykdomas pakartotinai; vieną kartą atliktas patikrinimas yra pokyčio priėmimas, o ne verifikavimas.
Šių keturių gyvavimo ciklai tarpusavyje nesuderinami: nuolatinis ir baigtinis, normatyvinis ir aprašomasis, vienkartinis ir kartotinis. Joks artefaktas negali talpinti dviejų iš jų taip, kad vienas gyvavimo ciklas neiškraipytų kito.
Yra penktas elementas, kuris nėra teiginys, o atramos taškas: tapatybė. Tapatybė yra beprasmiškas, niekada pakartotinai nepanaudojamas referentas, prie kurio prijungiamos visos keturios teiginių rūšys. Norma yra tapatybės turinys; pokytis į ją nurodo; būsena registruojama jos atžvilgiu; verifikavimas nukreiptas į ją. Tapatybė turi būti išskirta kaip savarankiškas elementas su savomis taisyklėmis: ji turi būti beprasmiška, nekintama, niekada nepanaudojama pakartotinai ir gyvuoti ilgiau nei bet kas, kas į ją nurodo.
Pagrindinė šio straipsnio mintis yra ta, kad tapatybės negalima palikti numanomos. Jei ji neišskiriama, jos vaidmenį perima tai, kas tuo metu prieinama – dažniausiai žingsnio pozicija dokumente arba darbo elemento raktas, o abiejų gyvavimo ciklai šiam vaidmeniui yra netinkami, kaip parodo tipologija.
Pastaba apie įrankius: unikalių identifikatorių priskyrimas reikalavimų objektams, kaip tai jau dešimtmečius daro reikalavimų valdymo įrankiai, nustato tapatybę tik tuo atveju, jei identifikuotas objektas talpina vien normą. Identifikatorius, priskirtas objektui, kuris taip pat talpina pokytį, paveldi pokyčio mirtingumą; tuomet identifikatorius įvardija uždarytą istorinį įrašą, o ne gyvą normą. Identifikatoriai yra būtini tapatybei, bet jų nepakanka.
5. Suplakimų tipologija
Kiekvienas keturių teiginių rūšių porinis suplakimas sukuria atskirą nesėkmę, turinčią stebimą simptomą. Simptomai svarbūs todėl, kad juos galima nustatyti projekto artefaktuose vien juos apžiūrint, neapklausiant komandos ir net jei komanda nepripažįsta problemos. Tai perkelia tipologiją iš nuomonės į patikrinamą teiginį.
5.1 Norma su pokyčiu
Reikalavimas parašytas darbo elemente: vartotojo istorija yra specifikacija. Norma paveldi baigtinį pokyčio gyvavimo ciklą. Kai elgseną reikia pakeisti, autorius susiduria su dilema, neturinčia gero sprendimo: perrašyti uždarytą istoriją reiškia suklastoti istorinį įrašą apie tai, kas buvo pristatyta; parašyti naują istoriją reiškia dabartinę galiojančią elgsenos formuluotę išskaidyti per pokyčių grandinę.
Simptomas: norėdamas sužinoti, kaip elgiasi vienas laukas ar funkcija, skaitytojas turi rasti ir chronologiškai perskaityti N uždarytų darbo elementų, o N didėja su kiekvienu leidimu. Antrinis simptomas – senuose elementuose atsirandančios anotacijos, nurodančios, kurios dalys yra pakeistos.
5.2 Norma su būsena
Normatyviniai ir aprašomieji teiginiai dalijasi vienu tekstu be žymos, kuri juos atskirtų. Dažniausiai tai prasideda nekaltai: apėjimo sprendimas dokumentuojamas ten, kur jo ieškos skaitytojas – reikalavime. Kategorijos klaida tyliai kaupiasi, nes abi teiginių rūšys atskirai yra teisėtos, o tekstas išlieka lokaliai suprantamas.
Simptomas: reikalavimų tekste atsiranda laikinumo ir faktualumo žymenys, tokie kaip „kol kas“, „šiuo metu sistema“, „kaip laikinas sprendimas“, „reikalauja didelio pakeitimo“. Po pakankamo kaupimosi skaitytojas nebegali nustatyti, kurie sakiniai nusako, ko sistema privalo laikytis, o kurie tik praneša, kad sistema to nedaro.
5.3 Norma su verifikavimu
Reikalavimas egzistuoja tik kaip jo vykdomas patikrinimas, specifikacijos pavyzdžiu principą perkeliant iki galo. Norma paveldi verifikavimo reikalavimą būti vykdoma.
Simptomas: sunkiai automatizuojamos elgsenos lieka nedokumentuotos, o testų rinkinio pertvarkymas tyliai pakeičia specifikaciją, nes nėra antro artefakto, pagal kurį būtų galima pastebėti pakeitimą.
5.4 Pokytis su būsena
Dabartinė sistemos būsena niekur nefiksuojama; prireikus ji išvedama pakartojant pokyčių istoriją. Tai veikia tol, kol istorija trumpa ir tvarkinga, ir žlunga vos tik pokyčiai įgyvendinami dalinai, su defektais arba atšaukiami, nes išvedimas remiasi prielaida, kad kiekvienas uždarytas pokytis yra visiškai ir teisingai įsigaliojęs.
Simptomas: į klausimą „ar tai veikia produkcinėje aplinkoje?“ atsakoma analizuojant leidimų istoriją, o po kelių tokių bangų skirtingų žmonių pateikti atsakymai pradeda skirtis.
5.5 Pokytis su verifikavimu
Testai siejami su darbo elementais. Verifikavimas paveldi pokyčio mirtingumą: kai istorija uždaroma, objektas, į kurį nurodo testas, tampa istoriniu įrašu, o nuolatinis testo objektas – elgsena – neturi atvaizdavimo.
Simptomas: regresijos testų rinkinio neįmanoma susieti su elgsenomis. Niekas negali pasakyti, kokios elgsenos yra padengtos, nes padengimas išreiškiamas pristatymais, o pristatymai nepadalija elgsenos. Testuotojai nuolat ir pagrįstai klausia: „Prie ko man prijungti šį testą?“, o modelyje atsakymo nėra.
5.6 Būsena su verifikavimu
Testų rezultatai laikomi sistemos aprašymu: tai, kas praėjo, veikia; tai, kas nebuvo testuota, neegzistuoja aprašyme.
Simptomas: nesėkmės nebuvimas interpretuojamas kaip atitiktis. Testų padengimo spragos tampa nematomomis spragomis organizacijos žiniose apie savo pačios sistemą ir išaiškėja tik produkcinėje aplinkoje.
5.7 Degeneracinis atvejis: tapatybė su pozicija
Tai nėra porinis teiginių suplakimas, o atramos taško uzurpavimas. Tapatybės elementas nėra išskirtas, todėl jo vaidmenį perima pozicija kompozicijoje: srauto 5 žingsnis, dokumento 3.2 skyrius. Pozicija turi netinkamą invariantiškumo klasę tapatybei, nes kompozicijos pertvarkomos kaip įprastas redagavimo veiksmas.
Simptomas: nuorodų poslinkis. Įterpus ar perrikiavus elementus, kiekviena išorinė nuoroda į „5 žingsnį“ pradeda rodyti į kitokią elgseną nei anksčiau, dokumentai viduje išlieka nuoseklūs, o niekas neparodo įvykusio poslinkio. Tai yra dar blogiau nei nutrūkusios nuorodos, kurios bent jau parodo problemą.
Tipologija leidžia taikyti diagnostinį metodą: gavus artefaktų modelį, reikia išvardyti, kokias teiginių rūšis talpina kiekvienas artefaktas; kiekvienas artefaktas, talpinantis dvi rūšis, leidžia nuspėti jo simptomą; tuomet simptomus galima patikrinti realiuose projekto artefaktuose. Prognozė atliekama prieš stebėjimą, ir būtent tai struktūrinį paaiškinimą atskiria nuo paaiškinimo po įvykio.
6. Atvejis: vieno suplakimo pašalinimas sukuriant kitą
Atvejis susijęs su didele, ilgai gyvuojančia reguliacine informacine sistema, sukurta viešojo sektoriaus klientui, kurios specifikacijų korpusą sudarė keli šimtai dokumentų, o pokyčių procesas buvo grindžiamas formaliomis pakeitimų užklausomis. Detalės anonimizuotos; svarbi yra epizodo struktūra.
Pirmajame organizacijos modelyje specifikacija buvo sudaryta iš darbo elementų. Kiekvienas elgsenos srauto žingsnis sekimo sistemoje buvo vartotojo istorija; specifikacijos dokumentas buvo generuojamas užklausa, kuri surinkdavo istorijas pagal žymas ir epinės grupės narystę bei išrikiuodavo jas pagal verslo identifikatoriaus lauką. Todėl dokumentas visada buvo aktualus ir jo nereikėjo rankiniu būdu surinkti. Modelis suplakė normą su pokyčiu (5.1), o kaip šalutinį efektą – ir pokytį su verifikavimu (5.5), nes testai buvo siejami su tomis pačiomis istorijomis.
Numatyti simptomai pasireiškė. Esamos elgsenos pakeitimai neturėjo kur būti įrašyti: paveiktos istorijos buvo uždarytos, todėl pokyčiai buvo registruojami kaip anotacijos jose, antros taisyklių nuorodos prirašomos šalia originalių, kūrėjų pastabos žymėdavo, kurios dalys buvo paveiktos. Kaip antrinė problema atsirado normos ir būsenos suplakimas (5.2): kadangi nebuvo kitos vietos, dabartinės dalinės realizacijos aprašymai, aiškiai pažymėti „kol kas“, buvo rašomi tiesiai į reikalavimo tekstą. Po kelių pokyčių bangų skaitytojas nebegalėjo nustatyti, kuri elgsena taikoma bendrai, kuri variantui ir nuo kada.
Organizacijos atsakas buvo teisingas savo esminiu sprendimu: specifikacija buvo atskirta nuo darbo elementų. Elgsenos srautai tapo rankiniu būdu rengiamais dokumentais su sunumeruotais žingsniais; istorijos vėl tapo grynais pokyčiais, susietais su dokumentu, bet jo nebesudarančiais. Normos ir pokyčio suplakimas buvo pašalintas, o kartu išnyko ir 5.1 skyriuje aprašyta perrašymo dilema.
Tačiau tapatybės sluoksnis nebuvo išskirtas. Senajame modelyje tapatybę netobulai, bet pakankamai gerai atliko darbo elemento raktas ir verslo identifikatoriaus laukas. Naujajame modelyje jie dingo kartu su istorijomis ir niekas jų nepakeitė. Tapatybės vaidmenį perėmė dokumento žingsnio pozicija, sukurdama 5.7 skyriuje aprašytą degeneracinį atvejį, o trys teiginių rūšys vienu metu prarado savo tikslą: pokyčiai galėjo nurodyti tik visą dokumentą, realizacijos būsena negalėjo būti registruojama smulkesniu nei dokumento lygiu, o verifikacijos neturėjo prie ko patikimai prisirišti. Numatyti simptomai pasirodė per kelis mėnesius, o labiausiai matomas buvo nuolatinis testuotojų klausimas „Prie ko dabar prijungti testus?“, nukreiptas analitikams, nes tik jie galėjo atsakyti remdamiesi atmintimi.
Iš to galima apibendrinti dvi pamokas. Pirma, teisingai pašalinus vieną suplakimą galima sukurti kitą, jei tapatybė paliekama numanoma, nes tapatybės vaidmuo nedingsta – jis persikelia į artimiausią prieinamą struktūrą. Antra, reformos kryptis yra mažiau svarbi už jos išbaigtumą: ir senasis, ir naujasis modelis žlugo priešingais būdais dėl tos pačios pagrindinės priežasties – nebuvo išskirto, beprasmiško, neuždaromo referento, kurio detalumo lygis atitiktų pokyčio ir verifikavimo lygį.
Verta užfiksuoti, ko reikėjo galutiniam stabilizavimui, nes tai buvo nedaug: srautų lentelėse buvo pridėtas stabilios nuorodos stulpelis su trimis taisyklėmis: nuorodos niekada nepernumeruojamos, niekada nepanaudojamos pakartotinai ir keičiamos tik tada, kai keičiasi pati elgsena, o ne jos formuluotė. Praktinis paskutinės taisyklės kriterijus buvo tai, ar esama verifikacija išlieka galiojanti. Naujų įrankių ar naujo artefakto tipo nereikėjo. Problema niekada nebuvo technologinė.
7. Kada suplakimas yra racionalus
Tipologija neturėtų būti suprantama kaip draudimas. Suplakimas yra ekonomiškumo sprendimas: keturi atskirti elementai kainuoja keturių objektų kūrimo, susiejimo ir priežiūros sąnaudas, o daugeliui sistemų toks taupymas yra pagrįstas. Trumpai gyvuojantis produktas, sistema, kurioje esama elgsena keičiama retai, arba pakankamai maža komanda, kad sistemos būsena tilptų į jos darbinę atmintį, gali neribotai naudoti normos su pokyčiu modelį, kai istorija yra specifikacija, ir niekada nesumokėti kainos, nes ji atsiranda tik antrą kartą keičiant tą pačią elgseną ir pirmą kartą uždavus regresijos klausimą.
Kainos kreivę lemia trys kintamieji: numatoma sistemos gyvavimo trukmė, esamos elgsenos keitimo greitis, palyginti su naujos elgsenos pridėjimu, ir verifikavimo korpuso santykis su komandos atmintimi. Suplakimo kaštai didėja kartu su visais trimis. Iš to kyla praktinė sprendimo taisyklė: keturis elementus atskirti ir išskirti tapatybę reikia tada, kai tikimasi, kad ta pati elgsena bus keičiama daugiau nei vieną kartą ir verifikuojama neribotą laiką. Iki to momento atskyrimas yra formalumas; po jo suplakimas tampa skola su sudėtinėmis palūkanomis, mokama būtent 5 skyriuje aprašytais simptomais.
Ši taisyklė taip pat paaiškina nuolatinį pramonės svyravimą tarp sunkaus reikalavimų valdymo ir specifikacijos laikymo tik darbų sąraše. Abi stovyklos teisios dėl kitos stovyklos nesėkmės, nes kiekviena yra mačiusi realią suplakimo kainą, tačiau abi klysta universalizuodamos savo išvadą, nes pirmiau išvardyti kintamieji skirtinguose kontekstuose skiriasi. Į klausimą „ar vartotojo istorija yra reikalavimas?“ nėra bendro atsakymo; yra apskaičiuojamas atsakymas.
8. Apribojimai ir tolesni darbai
Atvejo duomenys gauti iš vienos organizacijos, kurią stebėjo vienas dalyvis, todėl jų pakanka tipologijai iliustruoti, bet ne jos dažniui nustatyti. Vis dėlto 5 skyriaus simptomai sukurti taip, kad juos būtų galima aptikti vien tik tikrinant artefaktus: laikinumo žymenys reikalavimų tekste (5.2), testų ir darbo elementų nuorodų topologija (5.5), nuorodų poslinkis tarp dokumento versijų (5.7). Natūralus kitas žingsnis būtų kelių projektų auditas, taikant šiuos detektorius specifikacijų korpusams ir tikrinant, ar kiekvienas prognozuojamas simptomas, ir tik jis, pasireiškia kartu su atitinkamu suplakimu. Antroji kryptis – ekonominė: 7 skyriaus sprendimo taisyklę pritaikyti prie išmatuojamų pokyčių srauto duomenų.
9. Išvada
Atsekamumas paprastai skiriamas kaip drausmės reikalaujantis procesas, tačiau būtent kaip procesas jis ir žlunga. Šiame straipsnyje teigiama, kad nesėkmė dažnai prasideda anksčiau nei drausmės klausimas: ji nusprendžiama tuo momentu, kai artefaktų modelis vienam artefaktui priskiria dvi iš keturių teiginių rūšių – normą, pokytį, būseną ir verifikavimą – arba leidžia tapatybę uzurpuoti pozicijai. Kiekvienas toks priskyrimas turi iš anksto nuspėjamą nesėkmės mechanizmą ir stebimą simptomą artefaktuose. Praktinę išvadą galima sutalpinti į vieną sakinį: kiekvienai elgsenai suteikite beprasmišką, nemirtingą, niekada pakartotinai nenaudojamą referentą tokiu detalumo lygiu, kuriuo sistema keičiama ir verifikuojama, visa kita susiekite su tuo referentu ir niekada neleiskite vienam artefaktui talpinti dviejų gyvavimo ciklų.
Literatūra
- Cleland-Huang, J., Gotel, O. ir Zisman, A. (sud.) (2012). Software and Systems Traceability. Springer.
- Gotel, O. ir Finkelstein, A. (1994). An analysis of the requirements traceability problem. In Proceedings of the First International Conference on Requirements Engineering. IEEE.
- ISO/IEC/IEEE 29148 (2018). Systems and software engineering, Life cycle processes, Requirements engineering.
- North, D. (2006). Introducing BDD. Better Software Magazine.
- Zave, P. ir Jackson, M. (1997). Four dark corners of requirements engineering. ACM Transactions on Software Engineering and Methodology, 6(1), 1–30.