versioonimuudatuse jaoks. 2. Süsteemi struktuur kipub halvenema uute osade lisandumisel - pidev muutmine rikub süsteemi struktuuri. Selle vältimiseks ja tarkvara kvaliteedi parandamiseks on vaja kulutada lisaks aega ja raha refaktoreerimisele. Halb struktuur muudab tarkvara hilisema muutmise keerulisemaks ja kulukamaks. 11 4. Agiilsed arendusmeetodid Agiilsete arendusmeetodite jaoks sobib kasutada inkrementaaset mudelit. Agiilse tarkvaraarenduse levimise algus läheb 2001 aastasse, kui senise üliplaanipärase arenduse vastased kirjutasid alla "The Agile Manifesto"-le, mille kõige olulisemates punktides rõhutakse inimesele ja inimeste vahelisele suhtlemisele: Inimesed ja suhtlemine on tähtsamad kui protsessid ja tööriistad. Töötav tarkvara on tähtsam kui dokumentatsioon.
Kvaliteedi mõiste võib tähendada erinevatele kasutajatele erinevaid asju, seega ei saa kõiki rahuldada. 54. Kvaliteet ja organisatsiooni juhtimine Usa, Euroopa ja Jaapani arusaamad kvaliteedist on teistsugused. Usa ja Euroopa kvaliteedijuhtimine on orienteeritud tulemusele, oluline roll on lõpptulemusel, mitte projekti kvaliteedil. Jaapanis on kvaliteedi juhtimine orienteeritud protsessile, on oluline, et kogu tootmine oleks kvaliteetne. 55. Kvaliteedihalduse ja arendusmeetodite seos Kui Usas ja Euroopas tehakse kardinaalselt uusi otsuseid, siis Jaapan on osanud areneda pidevalt, ilma suurte hüpeteta. 56. Kvaliteedihalduse integreerimine tarkvara elutsüklisse Usa ja Euroopa kvaliteedijuhtimine on olnud ajalooliselt enam orienteeritud statistilistele meetoditele. Jaapanis on see seevastu rohkem iga töötaja küsimus. 57. Kvaliteedihalduse käsitlusi, teese, süsteeme ja auhindu
endale vähem kohustusi. 27 Kulude kokkuhoid väljendub ka viimase aja trendis, kus teenused, mis pole soovitud määral kokkuhoidu saavutanud, tuuakse ettevõtte juurde tagasi. Peamised teenused, mis välise teenusepakkuja juurest tagasi tuuakse (insourcing) on tarkvaraarendus ja testimine. 25%-l juhtudest tuuakse põhjenduseks kulude kokkuhoiu, efektiivsuse ja kvaliteedi parandamise eesmärkide mittetäitumine. Lisaks sellele võib ühe põhjusena välja tuua ka paindlike arendusmeetodite laiema leviku, mis on soodustanud testimise funktsiooni ettevõtte juurde tagasi toomist. Riskid Kui ettevõte annab välise teenusepakkuja kätte oma IT-teenused või mõne äriprotsessi, kaasnevad sellega paratamatult ka riskid, millega tuleb arvestada. Kõige suuremate riskidena toodi uuringus välja sõltuvust välisest teenusepakkujast (51%), ohtu kaotada kontroll teenuse üle (43%) ning teenuse kvaliteedi langust (35%).
annaabi.ee 
