code
Loeng 5 · Süsteemiarendus ja arendusmeetod
- IT-arenduse õppetunde
- Meetod
- Oskusteabe ülekandmine
- Kuidas luua meetodit?
- Kui palju on meetodeid vaja?
- Meetodi täpsusaste
- Meetodid süsteemiarenduses
- Kuidas meetodit tundma õppida?
- Paindlik rakendamine
- Meetod ja professionaal
- Arendusmeetod firma konkurentsieelisena
- Arendusmeetodite ühtlustamine
- Meetodite valik konkreetsesse arendusprojekti
- Mõned teetähised tarkvaraarendusmeetodite ajaloost
- Probleemid ja harjutused
IT-arenduse õppetunde
Mida siis raha eest saime? (koodistatistika)
Praktika näitab, et tehnilisi küsimusi ei õnnestu hoida lahus ärilistest.
IT-ga on võimalik teha kõike, aga kui hakkame tegema, siis selgub, et kõik maksab.
Seetõttu on oluline analüüsida, mida arendusraha kulutamine annab. Mõned elementaarsed arvutused ühe projekti kolme etapi kohta:
| DHX Etalonteostus | DVK täiendamine | DHX Adapter | |
|---|---|---|---|
| Olulisus | MUST HAVE | MUST HAVE | NICE TO HAVE |
| (peaaegu) | |||
| Kasutuslugusid | 6 | n/a | 6 |
| Testilugusid | 9 | 33 | 34 |
| Dok-n, ridu | 1130 | n/a | 6250 |
| Koodiridu (LOC) | 2000 | 21 400 | 45 000 |
| Faile | 125 | 3374 | |
| Kaustu | 58 | 273 | |
| Maksumus | €31,580 | €19,900 | €35,800 |
| €/LOC | €16 | €0.93 | €0.80 |
| €/Kasutuslugu | €5300 | €6000 | |
| LOC/Kasutuslugu | 333 | 7500 |
Odav tarkvara? (koodistatistika)
| Projekt A (üks moodul) | Projekt B | Projekt C | |
|---|---|---|---|
| Meetod | Kosemudel | Kosemudel | Agiilne |
| Eesmärk | täislahendus | täislahendus | MVP* |
| Koodiridu (LOC) | ca 30 000 | 5000 | 4000 |
| Maksumus | €11,500 | €150,000 | €10,000 |
| €/LOC | €0.33 | €30 | €3 |
| Kasutuslugusid | ca 8 | n/a | 8 + 2 |
| Dokumentatsioon | jah | jah | ei |
| Dok-ni kvaliteet | kehv | suurepärane | |
| Kasutatav | ei | jah | jah |
| Üldkvaliteet | kehv | suurepärane | väga hea |
*MVP, Minimal Viable Product, minimaalne toimiv lahendus
- Alice Cooper (1973) No More Mr Nice Guy
- Glover, R (2003) No More Mr Nice Guy. A Proven Plan For Getting What You Want in Love, Sex, And Life.
Kosemudeliga või agiilselt?
Sama funktsionaalsus, pärast kosemudeli ebaõnnestumist:
| Kosemudeliga | Agiilselt | |
|---|---|---|
| Eesmärk | “Täisvärk” | MVP* |
| Maksumus | €190,000 | €10,000 |
| Teostatud | ei (katkestatud) | jah |
| Aeg | 9 kuud (katkestatud) | 2 nädalat |
| Tulemus kasutatav | õppetunnina, koodi kasutamine problemaatiline | jah |
*MVP, Minimal Viable Product, minimaalne toimiv lahendus
Arvutus näitavad, et agiilarendus võib sama funktsionaalsuse anda 10-15 korda odavamalt ja 10-20 korda kiiremalt.
Asi ei tarvitse olla 10X kiiremates programmeerijates - tõenäoliselt ei olegi - vaid selles, et agiilne projekt sunnib Tellijat teisiti tegutsema.
Vali jõukohane raskus
Ambitsioonitase on äärmiselt oluline.
Teeme kõigepealt baastaseme ära, siis täiendame ja alles seejärel viime asja ägedaks ja ülikõvaks - kui veel tahtmist, ressurssi ja tegelikku vajadust tolleks momendiks jagub.
Codemonkeyism
| Projekt A | Projekt B | |
|---|---|---|
| Programmeerimine | C | B/A |
| Infohaldus | C | C |
| Joonis | C | C/A |
| Kaardistav analüüs | B | B |
| Kontseptsiooni loov analüüs | C | B |
| Optimeeriv analüüs | C | A |
| Originaalne mõtlemine | C | B |
| Probleemi analüüs | C | A |
| Protsessi v töövoo kujundamine | C | C |
| Kasutajaliides | C | C |
| Lihtsus | C | C/A |
| Kavast kinnipidamine | C | B |
| Kirjutamine | C | B/A |
| Raporteerimine | C | C |
| Selgitamine | C | A/C |
| Spetsifitseerimine | C | C/A |
| Tegevuskava koostamine | C | C |
| Muutuste eestvedaja | C | C |
C- nõrk, vajalik Tellija tugev järelevalve ja osade asjade ise ette- või ärategemine; B - hea; A - väga hea, üle ootuste.
Rida probleeme:
- Eesti IT-firmade* võime tööd korraldada on madal
- töökorralduslikud oskused ei ole aastatega tõusnud, pigem vastupidi
- oskuste profiilid on ebaühtlased; vajalikud kompetentsid tavaliselt kaetud ebaühtlaselt
- võimekaid, häid spetsialiste ei osata täie efektiivsusega rakendada - ebakompetentne juhtimine
- tellijal ei jää muud üle, kui nõrgad kompetentsid oma tööga täita
- IT-arenduse tuumaks peetakse firmades koodi kirjutamist; tarkvaraarendus on aga ainult üks element; paralleelselt peaks käima äriprotsesside ja töövoogude arendus ja muutuste eestvedamine; organisatsiooniliste muutuste juhtimise oskusi IT-firmadel pole.
*kindlasti on tugevaid, välisturule või erasektorile töötavaid ettevõtteid, kelle suhtes väide ei kehti.
Kust tekib keerukus?
Keerukus tekib juba haridussüsteemis.
- mentaliteet “Rohkem on parem”
- Eesti kultuuris puudub lihtsuseguru
- Eesti IT-s puudub oma Standish Group.
Tulemuseks on inimesed ‘not capable of simple’.
Ilmingud:
- mahu pärast genereeritud projektiplaanid, arendusdokumendid
- äriprotsessi kirjeldus 80 lk. See ei ole kasutatav.
If I Had More Time, I Would Have Written a Shorter Letter – Blaise Pascal (1657)
Lihtsus ei teki iseenesest.
Lihtsuse saavutamine nõuab jõupingutust.
Lihtsus võib nõuda rohkem oskust kui keerukus.
- One-liner-i kirjutamine pole lihtne.
Lihtsuse hoidmine nõuab jõupingutust.
Lihtsusele pürgiva jõu olemasolu on projekti õnnestumise eeldus.
Minimeeri vaheprodukti
80 mlrd $ aastas - ostab IT-d USA föderaalvalitsus.
Kasutust leiab ainult 1/3 ostetud tarkvarast.
End users fail entirely to use nearly 45% of features procured and rarely use another 19% percent of those features. – Balter, B (2011) Toward a More Agile Government: The Case for Rebooting Federal IT Procurement. Public Contract Law Journal.
Vaheprodukt (WIP, Work-In-Progress):
- strateegia, tegevuskava, raamistik, juhend
- arhitektuurne mudel, äriprotsessi kirjeldus jne
- üleminekukava
- projekti- ja arendusdokumentatsioon.
Lõpp-produkt (End Product):
- töötav tarkvara, mida ka tegelikult kasutatakse.
Minimeeri töösolevat produkti (minimise WIP).
Projekti- ja arendusdokumentatsiooni rohkus ainult suurendab WIP-i.
Mis töötab? (dokumentatsioon)
| Projekt A | Projekt B | Project C | Projekt D | Projekt E | |
|---|---|---|---|---|---|
| Dok kvaliteet | 3+ | 5 | 3 | 4- | 5+ |
| Eraldi dok-ja | ei | jah | ei | ei | jah |
5+ suurepärane, üle ootuste, Tellija osalusvajadus minimaalne; 4- hea, vajalik suur Tellija osalus; 3 - vastuvõetav, suure Tellijapoolse tagaajamisega.
Kvaliteetdokumentatsioon ei teki muu arendustöö kõrvalt, vaja eraldi inimest.
Inimene teeb kvaliteetset dokumentatsiooni, kui
- tal on selleks talenti
- talle antakse selleks aega.
Mis töötab (hankimine)
Nordeconi projektijuht: “Allhankijate probleeme? Ei ole. Kui tahad järgmine kord ka tööd saada, siis teed korralikult”.
Meetod
Meetod on kindlapiiriline moodus või viis mingi töö tegemiseks.
Meetod on teave –oskusteave– teave, teadmine selle kohta, kuidas midagi teha. Inglise keeles_know-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).
Töö on efektiivsem ja tulemuslikum, kui kasutatakse otstarbekat meetodit.
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 tõusnud tehnoloogia keerukuse tõustes ja teaduse arenedes. Tähtsaks teetähiseks on filosoof Rene Descartes’i raamata_Discourse on the Method_(1637), milles sõnastati teadusliku uurimismeetodi alused. (Ka teadus on üks tegevusala, mis nõuab oma spetsiifilisi meetodeid).
Oskusteabe ülekandmine
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.
Kuidas luua meetodit?
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.
Kui palju on 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.
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 vormiks_cookbook 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.
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.
Kuidas 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 (Capability Maturity Model) kasutab samuti nelja abstraktsioonitasandit.
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 Engineering_CASE tarkvara) või teenuseid (koolitus, auditeerimine, sertifitseerimine)? Võistupakkumiste protsessis võidakse kindla arendusmeetodi kasutamise nõuet kasutada ka valikuprotsessi mõjutamiseks.
Paindlik rakendamine
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,preprocessor_ja 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.
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.
Arendusmeetod 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.
Arendusmeetodite ühtlustamine
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.
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).
Mõned teetähised tarkvaraarendusmeetodite ajaloost
-_No silver bullet_. F. Brooks, 1987, artikkel_No 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 ja 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
Cameron, J. (2002) Configurable Development Processes.Communications of the ACM, 3, 72-77. – Arendusmeetodite 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?