Tarkvara disaini etapis peab arendaja mõtlema, kuidas tarkvara teostada. Peamiseks ülesandeks siin etapis on mõelda välja kuidas võimalikult väikeste raha ja ajakuluga teostada tellijale vajalik tarkvaratoode. Tuleb jälgida kuidas loodav tarkvaratoote disain vastaks järgmistele nõudmistele:

1.       Usaldusväärsus
2.       Muutmise võimalikkus
3.       Arusaadavus
4.       Uuestikasutatavus

Usaldusväärsuse all mõeldakse siinkohal tarkvara vastavust tellija vajadustele ja milliselt käitub tarkvara tellija poolt mittekirjeldatud olukordades. Tarkvara loetakse veatuks, kui see rahuldab tellija poolt kirjeldatud vajadusi. Kui tarkvara töötab ootuspäraselt ka olukordades, mida tellija ei ole kirjeldanud, siis loetakse tarkvaratoode viimistletuks (ik robust). Muutmise

Muutmise võimalikkus on tänapäeva tarkvaralahenduste juures samuti väga tähtis, sest iga olemasolev tarkvaratoode võib olla aluseks mõnele uuele tootele. Seega on väga oluline mõelda, mida on vaja teha loodava tarkvara uuesti kasutamiseks sarnastes toodetes. Samuti on muutmise võimalikkus oluline, kui tarkvara tootes leitakse vigu või mittevastavusi vajadustele.

Arusaadavuse vajalikkus on tulenev eelkõige sellest, et tarkvara teostatakse tänapäeval meeskonnatööna ja lahendus peab olema arusaadav kõigile tarkvaratoote teostamise, testimisega ja hooldamisega seotud inimestele ning seda ka hiljem, pärast tarkvara valmimist.

 

Tarkvara disaini etapis tuleb otsustada ka see, kui palju ja millisteks alamosadeks loodav tarkvaralahendus jagatakse. Alamosadeks jaotamisel tuleb eriti arvestada uuestikasutatavuse nõudega- liig suurte alamosade korral võib nende uuestikasutamine osutuda keeruliseks, liig väikeste osade korral võivad esmased arenduskulud muutuda ebaotstarbekalt suureks.  Täna on väga vähe lahendusi, kus on võimalik monoliitne lahendus. Tarkvara lahenduse jagamisel alamosadeks on kaks lähenemist: ülalt-alla (ik top-down) ja alt-üles (ik bottom-up).

Ülalt-alla lähenemisel jagatakse lähteülesanne alamülesanneteks, mis võivad igaüks koosneda omakorda alamülesannetest, seejärel jagatakse saadud alamülesanded omakorda alamülesanneteks kuni lähteülesanne koosneb lihtsatest ja üheselt mõistetavatest alamülesannetest. Sellise lähenemise puuduseks on see, et suurtel lahendustel on seda ebaotstarbekas kasutada, sest lähteülesanne jagatakse sellisel juhul väga paljudeks alamülesanneteks, kusjuures ilmselt esineb olukordi, kus ühte ja sama probleemi lahendatakse korduvalt (sest mitmed alamülesanded nõuavad sarnaste probleemide lahendamist). Lisaks eelnevale peab tarkvaradisainer hakkama üsna varakult mõtlema konkreetsete algoritmide peale, millega  etteantud probleemid lahendatavad oleks.

Alt-üles lähenemise korral jagatakse lähteülesanne alammooduliteks, milliseid käsitletakse „mustade kastidena”. Seejärel kirjeldatakse mida iga alammoodul tegema peab ja milliste teiste moodulitega peab see infot vahetama. Nii on võimalik suur lähteülesanne jagada iseseisvateks alamülesanneteks, mida on võimalik eraldi arendama hakata. Alt-üles lähenemisel on lihtne leida olemasolevatest lahendustest korduvkasutatavaid mooduleid, mida saab uue lahenduse koostamisel kasutada, mis omakorda kiirendab ja lihtsustab oluliselt uue lahenduse väljatöötamist. Sellise lahenduse suurimaks probleemiks on tihti see, et jäetakse täpselt kirjeldamata moodulitevaheline infovahetus ja selle korraldus.

Tihti on kasulik lähteülesanne jagada „alt-üles” lähenemise abil alammooduliteks ja need omakorda „ülalt-alla” lähenemise abil lõplikult lahendada.

Lisalugemist: wikipedia.org