LOENG 5 | Süsteemiarendus ja arendusmeetod

LOENG 5 | Süsteemiarendus ja arendusmeetod

Eesmärk

Mis on arendusmeetod? Vajadus meetodite järele süsteemide tegemisel. Kuidas valida arendusmeetodit? Millised ohud on meetodite kasutamisega seotud? Kui palju on erinevaid arendusmeetodeid? Millised meetodid on populaarsemad ja paremad?

SISUKORD

Vajadus meetodi järele
Meetodi mõiste
Seonduvad mõisted – metoodika, tehnika
Metoodilisuse printsiip
Oskusteabe sh meetodite ülekandmise probleem
Kuidas luuakse meetod
Kui palju on ettevõttes meetodeid vaja?
Meetodi täpsusaste
Meetodid süsteemiarenduses
Kuidas süsteemiarenduse meetodit tundma õppida
Meetodi paindliku rakendamise vajadus
Meetod ja professionaal
Arendusmeetodid IT-firma konkurentsieelisena
Arendusmeetodite ühtlustamise vajadus
Meetodite valik konkreetsesse arendusprojekti
Olulisi teetähiseid infosüsteemide arendusmeetodite alal
Probleemid/harjutused
Kirjandus

1. VAJADUS MEETODI JÄRELE

Üks mees Saksamaalt, Mainzi linnast – Johann Gutenberg – tuli 1430tel aastail mõttele lõigata õhukesest puitplaadist välja tähtede kujutised ja seada need ritta, moodustades nii sõnu, lauseid ja terveid lehekülgi. Ta leiutas raamatute trükkimise ja andis sellega kirjapandud infole juurdepääsu olulisemalt laiemale inimeste ringile kui enne teda.

1839. aastal märkas Louis Daquerre, et teatud keemilisi nähtusi, mida ta juhtus tundma, on võimalik kasutada kujutiste reprodutseerimiseks. Ta leiutas fotograafia – ja andis sellega võimaluse piltkujutiste kergeks paljundamiseks ja laiaks levitamiseks.

1877. aastal tuli Thomas Edisonile idee konstrueerida silindrikujuline seada – fonograaf – ja kasutada seda mitmesuguste helide salvestamiseks tinakilele tõmmatud vagude abil. 1920. aastal toimus esimene raadioülekanne. Nende leiutistega sai võimalik muusika ja kõne levitamine laiale kuulajate ringile.

Mis on ühist nendes kolmes avastuses? Erinevalt paljudest teistest avastustest (Kopernik, Einstein) olid Gutenbegi, Daguerre ja Edisoni uuendused otsese praktilise suunitlusega. Nad kasutasid varem teada olevaid teaduslikke fakte või lihtsalt käepäraseid materjali ja lõid mooduse nende uuel viisil kasutamiseks. Võib öelda, et nad lõid uued meetodid.

Gutenberg ei leiutanud raamatut. Raamatuid valmistati enne Gutenbergi avastust käsitsi ümberkirjutamise teel. Kõik materjalid, mida Gutenberg kasutas, olid hästi tuntud: puit, lõikeriistad, värv, paber. Gutenberg ainult andis uue viisi (meetodi) nende tuntud elementide ühendamiseks kasulikul viisil. Trükiridade (trükilao) kooshoidmiseks oli vaja leida lahendus trükiraami jm. näol. Trükkimise praktiliselt võimalikuks tegemiseks oli vaja küllaltki palju sättimist (väikesi parandusi). Ka selles mõttes on Gutenbergi ajalooline näide õpetlik – meetodi leidmine ei toimu harilikult hetkega, vaid nõuab kuid või aastaid.

2. MEETODI MÕISTE

Meetod on kindlapiiriline moodus või viis mingi töö tegemiseks.

Meetod on teave –oskusteave– teave, teadmine selle kohta, kuidas midagi teha. Inglise keelesknow-how.

Meetod ontegevusele suunatud(action-oriented) teave. Meetodit saame lugeda omandatuks alles siis, kui oskame seda rakendada. Oluline on eristada teadmist (to know) ja võimet seda teadmist rakendada (to do).

3. SEONDUVAD MÕISTED – METOODIKA, TEHNIKA

„Meetod” ja „metoodika” on eesti keeles süsteemiarenduses käibel praktiliselt samas tähenduses. Inglise keeles on üks sõna:method.Tehnika(technique) on tihti kasutusel kitsama kasutusulatusega oskusteabe tähistamiseks. Näiteks võivad ühe meetodi koosseisus olla ette nähtud mitmed kitsamad tehnikad.

4. METOODILISUSE PRINTSIIP

Töö on efektiivsem ja tulemuslikum, kui kasutatakse otstarbekat meetodit.

Üldiselt on parem teha tööd mingi meetodiga kui ilma meetodita.

Meetod võib ollateadvustatud(töö tegija mõtleb oma meetodile) võiteadvustamata(töö tegija võib tegutseda efektiivselt, ilma mõtlemata, kuidas ta seda teeb). Näiteks andekas sportlane võib intuitiivselt leida efektiivse mooduse mingi füüsilise soorituse tegemiseks. Kogenud töötaja võib olla leidnud töövõtted, mida ta endale ei teadvusta (teadvustamata kompetents või oskused).

Meetod võib ollaartikuleeritud(sõnastatud ja kirja pandud, näiteks tööprotseduuris või tööjuhendis) võiartikuleerimata(meetod on inimestes mõttes, kuid seda ei ole kirja pandud). Näiteks rahvapärimuse osaks olevad, ühise töö ja meistrilt õpilasele antud suuliste juhise kaudu edasi antavad tööoskused.

Tänapäeva majanduselus on töömeetodid väga oluliseks info liigiks, mille käitlemine nõuab küllaltki palju ressursse. Näiteks – uute tehnoloogiatega tulevad kaasa kasutusjuhendid, keerukamate seadmete operaatoreid on vaja välja õpetada kursustel või kutseõppeasutustes. Ka arvuti on vaadeldav seadmena, mille kasutamise õppimine nõuab spetsiaalset õpet.

Töömeetodite tähtsus on ajalooliselt tõusnud tehnoloogia keerukuse tõustes ja teaduse are­ne­des. Tähtsaks teetähiseks on filosoof Rene Descartes’i raamataDiscourse on the Method(1637), milles sõnastati teadusliku uurimismeetodi alused. (Ka teadus on üks tegevusala, mis nõuab oma spetsiifilisi meetodeid).

5. OSKUSTEABE SH MEETODITE ÜLEKANDMISE PROBLEEM

Ettevõte tahab loomulikult kasutada kõige efektiivsemaid töömeetodeid. Kuid töömeetodite ülevõtmine (ehk oskusteabe ülekandmine), kas sama ettevõtte ühest allüksusest teise, või ühest firmast teise – osutub praktikas vägagi raskeks. Autoriteetsed ärijuhtimise uurijad (Appel) on kasutusele võtnud mõiste oskusteabe “kleepuvus” (knowledge is sticky), millega mõistetakse seda, et ühe inimese või inimeste rühma oskusteavet ei ole lihtne välja selgitada, “pakendada” ja teisele rühmale üle kanda. Tõepoolest, mingil alal töötava meistri kogemust ei saa me kiiresti välja selgitada, ega ka kiiresti üle võtta (õppida). Teadmuse (teadmiste) ülekanne inimeste vahel (knowledge transfer) on infotehnoloogia/infokäitluse ala üheks suureks väljakutseks; sellega on aastakümneid tegelenud tehisintellekti ala (artificial intelligence). On selge, et kui organisatsiooni infotehnoloogilise infrastruktuuri (võrgud, IT keskkond) küsimused saavad enam-vähem lahendatud ja lihtsamad rakendused (transaktsioonide töötlus) tööle pandud, siis pöördub huvi keerukamate rakenduste loomise poole – milleks on sageli just inimeste oskusteave haldamine või oskusteave rakendamise toetamine IT abil.

6. KUIDAS LUUAKSE MEETOD

Meetod on enamasti vähemalt osaliseltkondenseeritud kogemus. Tööd tehes leitakse efektiivsed töövõtted ja –viisid, väheefektiivseks osutunud jäetakse kõrvale. Nii kujunebki välja meetod. Seda võib nimetadakogemusepõhiseks meetodiloomeks. Eeliseks on protsessi kulgemise loomulikkus ja vähene ressursinõudlikkus. Puuduseks on meetodi väljakujunemise pikk aeg (aastates) ja kindluse puudumine leitud meetodi kvaliteedi suhtes. Kõige tõhusamaid töömeetodeid ei ole sageli võimalik kogemuse alusel välja töötada.

Sihiteadlik meetodiarendus.Meetodeid võib välja töötada ka teisiti, sihiteadliku meetodiloomena. Tavaliselt toimub see uurimis- või arendusprojekti vormis, milles seatakse kindel eesmärk uuritava tööprotsessi parima läbiviimise leidmiseks, analüüsitakse protsessi, viiakse läbi eksperimendid jne.

7. KUI PALJU ON ETTEVÕTTES MEETODEID VAJA?

Kas ettevõttes peaks iga äri- ja tööprotsessi, iga tegevuse jaoks määratlema tegemise meetodi?

Vastus sõltub mitmetest teguritest – ettevõtte suurus, tegevusala, keskkond, milles ettevõte tegutseb, ettevõtte äristrateegia. Paljudel tegevusaladel on tegevuse loomulikuks aluseks kujunenud vastava alahea tava(raamatupidamiseks, meditsiinis, ehituses jm.),kvaliteedistandardid,tehnoloogilised nõudedvõiseadused.

Üldiselt on tegevus nii või teisiti, suuremal või väiksemal määral reguleeritud. Niisiis ei või ehitada nii, kuidas ehitaja ise heaks arvab, vaid tuleb järgida head ehitustava, kasutatavate materjalide paigaldusjuhiseid, ehitusseadusandlust jm. ISO 9000 kvaliteedisüsteemide standard nõuab, etkõik toodangu kvaliteedi seisukohalt olulised tööprotsessid tuleb läbi analüüsida, kirjeldada ja varustada tööjuhistega(kehtestada protseduurid). Selle nõude täitmisel peab loomulikult järgima mõistlikkuse printsiipi. Kõike ei saa ega ole vaja meetodiga ette kirjutada. Tänapäevase arenenud tootmisprotsessi põhimõtteline nõue on siiski selge – iga olulise tööprotsessi või toimingu sooritamise meetod peab olema läbi mõeldud.

8. MEETODI TÄPSUSASTE

Meetod või olla määratletud suurema või väiksema täpsusastmega. Kõige täpsem on samm-sammuline meetodi määratlus (step-by-step method, nimetatakse ka nn. kokaraamatu vormikscookbook approach), mis kirjeldab meetodi rakendaja tegevuse ette üksikasjalikult. Samm-sammulise meetodi eelised on selged: täitja ei pea enam mõtlema, vaid saab tegutseda mehhaaniliselt; tegevuse tulemuse kvaliteet ei sõltu enam eriti palju sooritaja isikuomadustest (kui tootmisprotsess on standardiseeritud, siis on töötaja isiku omadustel väiksem tähtsus). Samm-sammulise meetodi üheks eeliseks on kakergem automatiseeritavusvõrreldes vähem artikuleeritud protsessidega. Töömeetodite määratlemine samm-sammuline täpsusega on sageli eelduseks protsessidele IT lahenduste loomisele.

9. MEETODID SÜSTEEMIARENDUSES

Infosüsteemide arendus on (vähemalt ideaalis) meetodipõhine. See tähendab, et süsteemi ehitamist käsitatakse kui kindlat tüüpi tegevuste kogumit.

Näide. SCRUM süsteemiarendusmeetod.


Süsteemiarenduse meetodeid on välja töötatud palju.

10. KUIDAS SÜSTEEMIARENDUSE MEETODIT TUNDMA ÕPPIDA

Süsteemiarendaja, eriti rahvusvahelises keskkonnas tegutseja, puutub oma töös tõenäoliselt kokku paljude arendusmeetoditega. IT firmal tuleb otsustada, milliseid arendusmeetodeid kasutatakse. Selleks on vaja hinnata teadaolevate meetodite potentsiaali ja sobivust. Väga tihti toob uus IT projekt, eriti mitmete firmade koostöös tehtav projekt kaasa vajaduse „käigult” (töö käigus) omandada uus meetod.

Süsteemiarenduse meetodiga tutvumisel tuleks silmas pidada järgmist:

- Iga terviklik meetod (näiteks Extreme Programming, Information Architecture, jt.) on üles ehitatud teatud põhimõtetele (ideoloogiale). Meetod on rohkem kui tähistuste süsteem. Tihti on meetodite võrdlemisel ja õppimisel tähelepanu notatsioonil ja üksikutel silmatorkavatel tehnikatel või võtetel. Kasutusjuhtude meetod (use case, UML keele üks osa) on kindlasti midagi enamat, kui „kriipsujukude diagramm”. E.Goldratti Piirangute teooria (Theory of Constraints) põhineb küll ühel väga lihtsalt ideel, kuid sisaldab siiski oluliselt rohkem olulis mõisteid kui see peamine.

Arendusmeetodiga tutvumisel tuleks tähelepanu pöörata nendele ideedele, millest lähtudes meetod on loodud.Ekstreemprogrammeerimise rajajad on oma meetodi lähtekohad väga selgelt sõnastanud (ekstreemprogrammeerimise 4 väärtust).

- Igal meetodil on oma sisemine ülesehitus, struktuur. Selle struktuuri elemendid ei ole enamasti ühel tasandil. Heaks näiteks on Ekstreemprogrammeerimise meetodi ülesehitus:



Tarkvaraarendusvõime küpsusmudel (Capa­bility Matu­rity Model) kasutab sa­muti nelja abstrakt­si­oo­ni­tasandit.



Meetod võib anda tähistuste süsteemi (notatsiooni). Näiteks Andmevoogude diagrammide meetod (Data flow diagrams) annab lihtsa neljaelemendilise notatsiooni – kuid lisaks sellele ka rea põhimõtteid ja soovitusi diagrammide koostamiseks.

Arendusmeetodiga tutvudes tuleks leida, millistes vormides oskusteave on antud (samm-sammulised juhised, tähised, printsiibid, väärtused, eesmärgid).

- Meetodi tundmaõppimine võtab aega. Programmeerimiskeeled on samuti meetodid. Keele süntaksiga tutvumine on keele õppimisel alles algus.

- Skeptiline tuleks olla universaalsete meetodite suhtes. Igal meetodil on oma kasutusulatus (skoop,scope) olukordade hulk, milles meetodi kasutamine annab kasu. Näiteks UML keelt on keele arendajad püüdnud välja pakkuda kui universaalset vahendit äriprotsesside kirjeldamiseks – nii IT inimeste kui ka „äripoole” inimeste vaatepunktist. Idee on selles, et kui UML on laia tunnustust leidnud äriprotsesside kirjeldamisel (modelleerimisel, spetsifitseerimisel) IT rakenduste loomist silmas pidades, siis ­– UMLi loojate arvates – on see keel sama sobiv äriprotsesside kirjeldamiseks puhtalt ärijuhtimise eesmärkidel. Universaalset keelt ei ole siiski suudetud leida. [Küsimus: miks? miks on maailmas u. 6000 keelt, programmeerimiskeeli aga vähemalt kümneid?] UML diagrammid on mitmete kasutaja arvates äriinimestele siiski mitte kõige sobivamad.

- Tähele tasub panna ka seda, kes ja millistest motiividest lähtudes meetodit kasutamiseks välja pakub. Kas meetodile teeb reklaami firma või organisatsioon, kelle huviks on müüa meetodi kasutamiseks vajalikke töövahendeid (arendustarkvara,Computer-Aided Software EngineeringCASE tarkvara) või teenuseid (koolitus, auditeerimine, sertifitseerimine)? Võistupakkumiste protsessis võidakse kindla arendusmeetodi kasutamise nõuet kasutada ka valikuprotsessi mõjutamiseks.

11. MEETODI PAINDLIKU RAKENDAMISE VAJADUS

Ilma meetodita tegutsemine on halb, kuid meetodi ebamõistlik rakendamine on samuti halb. Arendusmeetodi kasutamisel on paindlikkus hädavajalik. Konkreetselt tuleks arvestada, et:

- Ükski meetod ei tohiks olla tingimusteta ette antud. Meetodi rakendamisele peaks alati eelnema otsustus – valik. See on oluline, sesttöö tegemiseks on tihti rohkem kui üks võimalik meetod.

- Süsteemi suurus on meetodite valikul oluline. Probleemid tekivad sageli just sellest, et projekti tähtsust rõhutades rakendatakse liiga keerukat, liiga „rasket” meetodit. (See ei rakendu meetodi õppimisele).

Tuleks vaadata, kas meetodist saab kasutada lihtsustatud versiooni. (Vrdl. mitmesugused lihtsustatud kohtumenetluse vormid).

- Sageli on meetod projekteeritudlaiendatavana. Mitmetes programmeerimiskeeltes on ette nähtus keele kohandamiseks või laiendamiseks (uute keelekonstruktsioonide lisamine,alias,preprocessorja makrode võimalused jm.). Diagrammide tüüpe määravad meetodid võivad lubada tähistuste lisamist või kohandamist. Elutsükli (life cycle) meetodid võivad lubada modifikatsioone projekti etappide nomenklatuuris. Neid võimalusi tuleks kasutada.Meetodi kohandamineon väga oluline.

12. MEETOD JA PROFESSIONAAL

Meetodi küljes ei tohiks rippuda. Tõelist professionaali iseloomustab vabadus meetodite valikul. Professionaal tunneb erinevaid meetodeid ja oskab neid õigetes olukordades rakendada.

13. ARENDUSMEETODID IT-FIRMA KONKURENTSIEELISENA

Unikaalsed oskused ja teadmised võivad olla oluliseks või isegi määravaks konkurentsieeliseks. Ettevõte, kes loob või omandab parema tootmisprotsessi, omandab sellega eelise konkurentide ees. Süsteemiarenduses sõltub siiski palju konkreetse turu iseärasustest. Kui tellija ei nõua arendusmeetodi olemasolu, siis võib põhjalikku arendusmeetodit rakendav firma meetodite tegutsejaga võrreldes sattuda isegi halvemasse olukorda.

Kaks teed arendusmeetodite kasutuselevõtmiseks IT-firmas:

- võtta mujalt üle (erialasest kirjandusest, koolitustelt, konkurentidelt);

- luua ise.

14. ARENDUSMEETODITE ÜHTLUSTAMISE VAJADUS

Unikaalse arendusmetoodika puuduseks võib olla selle mitteühilduvus koostööpartnerite arendusmetoodikatega. Kui projektis teevad koostööd mitu firmat või organisatsiooni, siis on ju äärmiselt oluline, et ei pea elementaarseid asju hakkama üle kontrollima (arendusmeetod on ka suhtlemiskeele rollis arendusprojektis osalejate vahel). Selle tõttu on arendusmetoodikat võimalusel mõistlik välja töötada üheskoos koostööpartneritega. Näiteks DSDM meetod on välja töötatud UK IT-firmade ja arendustööde suurklientide konsortsiumi ühistööna.

15. MEETODITE VALIK KONKREETSESSE ARENDUSPROJEKTI

Suuremas arendusfirmas, kus on kompetents mitmete erinevate arendusmeetodite kasutamiseks ja teisest küljest, projektid on erinevad, tekib küsimus projekti jaoks õige(te) arendusmeetodi(te) valikust. Väga heaks näiteks on IBMis välja töötatud süsteem, mis on kirjeldatud Cameroni artiklis (vt. Kirjandus).

16. OLULISI TEETÄHISEID INFOSÜSTEEMIDE ARENDUSMEETODITE ALAL

-No silver bullet. F. Brooks, 1987, artikkelNo Silver Bullet: Essence and Accidents of Software Engineering. Hõbekuuli, s.o. maagilist vahendit tarkvaraarenduse protsessi raskuste kõrvaldamiseks ei ole.

-Rational design process: how and why to fake it.D. Parnas, 1986. Arendusprotsess on süvaolemuselt loominguline, kuid seda on mitmel põhjusel mõtet näidata välja ratsionaalsena (süstemaatilisena).

- Prototüüpimine ja evolutsiooniline arendusmudel. Erinevad autorid, 1980ndad. Süsteemi arendamine käib läbi mitmete versioonide.

- Ekstreemprogrameerimine. K. Beck, 1990ndad.

PROBLEEMID/HARJUTUSED

1.Küsitlege inimest, kes tegeleb mingi tööga. Kas ja millist meetodit ta kasutab? Kas ta arvab, et see on õige viis töö tegemiseks? Kust meetod pärit on? Kas kaastöötajad töötavad sama moodi või kasutavad teisi meetodeid?

2. Uurige IT lahenduste või infosüsteemidega arenduse tegelevast firmast järele, milliseid arendusmeetodeid nad kasutavad. Leidke TLÜ Informaatika osakonna kodulehelt magistritööd, kus uuriti arendusmeetodite kasutamist Eesti IT-firmades. Milliseid arendusmeetodeid Eesti firmad kasutavad? Milliseid probleeme arendusmeetodite ala uurimus välja tõi?

3. Tutvuge mõne meetodiga ning selgitage välja meetodi struktuur: millised on meetodi alusidee(d)? millised on põhimõisted meetodis? milliseid notatsioone, töövahendeid jms. meetod pakub?

4. Leidke kaks sama või osaliselt kattuva rakendusalaga meetodit ja võrrelge neid.

KIRJANDUS

MacCormack, A. (2001) How Internet Companies Build Software.Sloan Management Review, 75-84. – Tarkvaraarenduse uuematest meetoditest.

Sprott, D. (2000) Componentizing the Enterprise Application Packages.Communications of the ACM, 4, 63-69. – Komponentide-põhine arendus.

Baster G., Konana, P., Scott, J. (2001) Business Components: A Case Study of Bankers Trust Australia Limited.Communications of the ACM, 5, 92-98. – Komponentide-põhine arendus.

Cameron, J. (2002) Configurable Development Processes.Communications of the ACM, 3, 72-77. – Aren­dus­meetodite konfigureerimine; IBM'i käsitlus.Soovitatav.

Truex, D., Baskerville, R., Travis, J. (2000) Amethodical systems development: the deferred meaning of systems development methods.Accounting, Management & Information Technology, 10, 53-79. – Kas süsteemiarendus peab alati olema meetodikohane?