Tarkvara loomine

Tarkvara ei toodeta nagu teisi tooteid, vaid arendatakse. Suuremate tarkvarapakettide loomine on üsna keerukas. Umbes 25% suurtest tarkvaraprojektidest ei saa iialgi valmis. Enamus suuri tarkvaraprojekte kestavad aasta võrra kauem ja maksavad 100% rohkem, kui ette nähtud. See näitab, et tarkvaraprojektide läbiviimine on sageli halvasti organiseeritud. Mida suurem projekt, seda tähtsam on enne programmeerimist täpselt kindlaks määrata, kuidas ja mida üldse programmeerida soovitakse. Programmeerimise käigus avastatud loogilised struktuurivead võivad kogu eelneva töö asjatuks muuta.

Sageli soovivad ka kliendid lasta peale tarkvara üleandmist teha mitmesuguseid muudatusi. Nii kulutatakse sageli 60-80 % rahast hilisemate muudatuste tegemiseks (tarkvara hooldamine). Tarkvara hooldamist raskendab sageli ka asjaolu, et algsed plaanid ja vahel ka programmitekstid (*.C ja *.H failid) on kuhugi kadunud. Lisaks sellele võivad selle programmi loonud programmeerijad juba ammu töötada mingis muus firmas ja nii ei tea keegi enam täpselt, kuidas seda programmi muuta. Seda probleemi saab lahendada hästi struktureeritud programmeerimisstiili ja korraliku dokumentatsiooniga.

Tarkvara loomine jaotatakse järgmistesse etappidesse:

Vastavalt projekti suurusest võib osa etappe kasutuks osutuda või vastupidi - omakorda etappideks jaguneda. Suuremate projektide puhul tuleks iga etapi lõpus tehtud otsused dokumenteerida. See lihtsustab programmi hilisemat muutmist ja kohendamist.

Tarkvara väärtuse hindamisel peetakse silmas järgmisi omadusi:

Ilmselt on osa toodud nõudmisi üksteisega osaliselt vastuolus. Näiteks porteeritavus näeb ette, et ei tohiks kasutada mingeid selle arvuti omapärasid, mis ei esine muude arvutite puhul. See aga on vastuolus efektiivusega. Siin tuleb leida sobiv tasakaal kõigi oluliste omaduste vahel.

Lihtsaim tarkvara loomiseviis on luua võimalikult kiiresti mingi programm ja siis teda proovida. Seejärel asutakse vigu parandama ja programmi soovitud suunas muutma. Selline viis sobib aga ainult väga väikeste programmide jaoks.

Täielik struktureeritud looming: analüüs - algoritmide loomine - kodeerimine - kontroll - hooldamine on aga sageli natuke liiga aeganõudev ja kohmakas. Seepärast kasutatakse sageli mingit vahepealset vormi. Üks selline viis on näiteks kiire näite meetod (rapid prototyping). Siin kasutatakse seda, et sageli ei tea klient veel tarkvara tellimise järguski päris täpselt, mis ta tegelikult saada tahab. Nii tehakse kliendi soovidele vastavalt kiiresti näiteprogramm, mis osaliselt juba täidab nõutud ülesanded ja omab sellist välimust (menüüd jms) nagu valmis programm seda omama saab, kuid ei ole veel optimeeritud jne. Selle näiteprogrammi alusel otsustab klient, mida (veel) vaja on. Vajaduse korral luuakse enne täielikult optimeeritud lõpliku programmi loomist veel paar näiteprogrammi. Näiteprogrammi järgi on ka lihtsam otsustada, kui palju aega ja raha on vaja antud projekti läbiviimiseks. Enne tegeliku programmi loomisega alustamist luuakse kliendiga leping, mis punktikaupa täpselt määrab kõik programmile esitatud nõudmised. Hilisemate lahkarvamuste lahendamiseks (programmi üleandmisel) kontrollitakse ülesande tätmist nimetatud lepingupunktide järgi.