Fontos szem előtt tartani, hogy ezek a folyamatelemek bár jól meghatározott ki és bemeneti adatokkal rendelkeznek nem biztos, hogy egyszerűen elkészíthetők. Ilyen nagy komplexitású programoknál hiába határozzuk meg jól a követelményeket, nem leszünk képesek eredményesen dolgozni, ha nem tervezzük meg működésének részleteit. Gondoljunk csak arra, hogy egy épületet sem kezdenek el ötletszerűen felépíteni, hanem előtte gondosan megtervezik. Különösen igaz mindez, hogyha több embernek kell az adott feladaton együtt dolgoznia, hiszen ekkor még a hatékony együttműködés sem automatikusan biztosított.

Amennyiben előrelátóan megfogadtuk a fenti tanácsot, választanunk kell egy tervezési módszert. Az első lehetőség, hogy papíron kézzel vagy egy egyszerű rajzprogrammal próbáljuk vizualizálni a készítendő alkalmazást. Ekkor azonban hamarosan több nehézséggel szembesülünk. Mivel nem céleszközökről van szó nehezen kezelhetőek lesznek terveink: gond lesz a módosítás, a csoportmunka, a verziókezelés, stb. Könnyen abba a hibába eshetünk, hogy nem igazodunk semmilyen szabványhoz a tervben megjelenő elemek terén. Ez a csapatmunkát lehetetlenné teszi, de még mi magunk sem fogunk tudni kiigazodni terveinken egy idő után.

Megállapíthatjuk tehát, hogy a tervezésre szükség van, mindenképpen valamilyen szabványos modellezés eljárást kell alkalmaznunk és lehetőleg egy erre alkalmas CASE eszközzel kell dolgozni. A modellezési eljárás attól függően változhat, hogy milyen programozási módszert használunk. A két nagy ág a strukturális és az objektum-orientált metodológia, manapság ez utóbbira helyeződik át a hangsúly. A legelterjedtebb, lassanként de facto objektum-orientált tervezési szabvány a Unified Modeling Language (UML).

A tervezés során tulajdonképpen az alkalmazás modelljét készítjük el, és azt dolgozzuk ki, hogy ez a modell adott hatásokra hogyan reagáljon. Elsőnként meg kell határozni hogy a szoftver környezetében milyen kulcsszereplők (aktorok) vannak hatással rendszerünkre, tehát ki és mire használja azt. Ezek után lebontjuk a teljes rendszert a komponensekre és definiáljuk a köztük létező statikus és dinamikus kapcsolatokat. A tervezőeszköz segítségével könnyen végezhetjük ezt az alábontást több kis lépésen keresztül is (inkrementális tervezés), egészen a legkisebb már atominak tekinthető elemekig például OO fejlesztésnél az objektumokig. Így különböző szintű terveink lehetnek, attól függően, hogy milyen részletességű a felbontás. Egy elterjedt felosztás szerint a folyamat az elemzéstől a magasszintű tervezésen át az alacsonyszintű tervezésig tart. Az elemi komponenseknek meg kell határozni a tulajdonságait: konstansok, attribútumok, metódusok, fejlesztő nyelv specifikus információk. Fontos, hogy a tervben nem kell szerepelnie az alkalmazás architekturális részeinek részletei, amennyiben Architektúra Központú Fejlesztéssel (ACD) dolgozunk. Ezek a részletek egy külön tervben vagy tervekben szerepelhetnek, és itt csak hivatkozni kell rájuk (lásd még: Az architektúra tervezés helye a szoftvergyárban).

Az ilyen módon való tervezés előnyei akkor igazán érezhetőek, ha a bevitt információk szervesen kapcsolódnak a szoftvergyár többi eleméhez. Először is a terv elemeit összekapcsolhatjuk azokkal a követelményekkel, amiket kielégítenek. Ezáltal egy automatikus ellenőrzési lehetőségünk van arra, hogy mely követelmények nincsenek kielégítve illetve milyen felesleges komponenseink vannak. Jóval hatékonyabbá tehetjük a következő területeket:

• Dokumentumkészítés - a legtöbb tervező eszköz kapcsolatot biztosít valamilyen dokumentumgenerálóhoz. Így a tervbe bevitt minden információ igényeink szerint megjelenhet nyomtatott formában is.

• Kódgenerálás - szinte minden CASE termék biztosít valamilyen szintű kód előállítására lehetőséget a tervből meghatározott nyelvekre. Ez általában deklarációs kódot jelent (4-5%), de köztes meta-modellt használó módszer esetén kihasználhatjuk az állapot illetve kommunikációs diagrammok plusz információit is (12-15%). Hozzávéve ehhez, hogy minta alapú generátor esetén új célnyelvspecifikus információk teljes kihasználása is gyorsan elérhető, még magasabb szintre juthatunk (15-20%). Ha mindezek mellett kihasználjuk az Architektúra Központú Fejlesztés lehetőségeit is, előállíthatunk 30-70%-os tisztán generált kódot.

• Tesztelés - már a terv alapján készülhetnek olyan tesztágyak, amit a tesztelő programok fel tudnak használni, gondoljunk például az osztályok attribútumainak értékhatáraira.