A szoftverfolyamat során négy alapvető folyamattevékenységet különítünk el:
specifikáció, fejlesztés, validáció és evolúció. Ezeket a különféle fejlesztési folyamatok
27
különféleképpen szokták szervezni. A vízesés modell esetében ezek a tevékenységek szigorúan egymás után következnek, míg az evolúciós fejlesztésnél a tevékenységek összefésülődnek. Az, hogy hogyan szervezzük ezeket a tevékenységeket, függ a fejlesztendő szoftver típusától, a fejlesztő csapat összetételétől, illetve a fejlesztést végző szervezettől és annak felépítésétől.
4.3.1 Szoftverspecifikáció
A szoftverspecifikáció vagy követelményelemzés az a folyamat, amelynek során megértjük és definiáljuk, hogy a kifejlesztendő rendszernek milyen funkciókat kell biztosítania a felhasználó felé, továbbá azonosítjuk a rendszer üzemeltetésének és fejlesztésének megszorításait. A követelmények tervezése és kezelése a szoftverfolyamat különösen kritikus szakasza. Az ebben a szakaszban mutatkozó hiányosságok és elkövetett hibák a rendszertervezés és implementáció fázisok megismétlését vonhatják maga után, amely a projekt késését, és a fejlesztési költségek jelentős növekedését okozhatja.
A követelménytervezési folyamat végeredménye a részletes szoftverspecifikációt tartalmazó dokumentum. A követelmények tervezésének négy fázisát különböztethetjük meg:
1. Megvalósíthatósági tanulmány. Egy új rendszer kifejlesztésekor az első munkafolyamat, amelyet el kell végezni a hozzá kapcsolódó problémakör, problémák elemzése. A fejlesztésben érdekeltek azonosítása után egyetértésre kell jutni a probléma kérdését tekintve. Meg kell határozni a kifejlesztendő rendszer határait. Azonosítani kell a rendszer kifejlesztésével kapcsolatos feltételeket és megszorításokat. Az elemzésnek végül el kell döntenie, hogy a fejlesztés az adott megszorítások mellett üzleti szempontból megvalósítható-e.
2. Követelmények feltárása és elemzése. Ez a folyamat a rendszer funkcionális követelményeinek meghatározásával foglalkozik. Ez történhet a meglévő rendszerek használata során szerzett tapasztalatok, illetve a megrendelőkkel és felhasználókkal folytatott interjúk alapján.
3. Követelményspecifikáció. A követelményspecifikáció folyamatában az elemzési tevékenységek során összegyűjtött információkból egy egységes dokumentum kialakítása a cél, amely a részletes szoftverspecifikációt tartalmazza. A dokumentumnak a felhasználói (funkcionális) és rendszerkövetelményeket (nem-funkcionális) kell tartalmaznia.
4. Követelmény validáció. Ennek a tevékenységnek a célja az, hogy ellenőrizzük a követelmények valószerűségét és teljességét. Meg kell győződni arról is, hogy a követelmények konzisztensek-e egymással.
4.3.2 Szoftvertervezés és implementáció
A szoftver tervezése során létrehozzuk az implementálandó szoftver struktúráját, a rendszerkomponensek által használt adatszerkezetek és algoritmusok leírását és a rendszerkomponensek közötti interfészek definícióját. A szoftverfejlesztés implementációs szakasza során a szoftvertervezés eredményéből indulunk ki és a rendszerspecifikációt megvalósító futtatható rendszert hozzuk létre programkód elkészítésével. Ez mindig magában foglalja a szoftver tervezését és a programozást. A tervezési folyamat tevékenységei:
28
1. Architekturális tervezés. A rendszert funkcionális működését biztosító alrendszereket és a köztük található kapcsolatokat azonosítani és dokumentálni kell.
2. Absztrakt specifikáció. Az egyes alrendszer esetében meg adni a funkcióit leíró pontos alrendszer specifikációt.
3. Interfész tervezése. Az alrendszerek az interfészeiken keresztül biztosítják a szolgáltatásaikat és kommunikálnak más alrendszerrel. Minden alrendszer számára meg kell tervezni és dokumentálni kell az interfészeit.
4. Komponens tervezése. Az egyes szolgáltatásokat el kell helyezni a különböző komponensekben, és meg kell tervezni a komponensek egymással érintkező interfészeit.
5. Adatszerkezet tervezése. Részletesen meg kell tervezni a rendszer implementációjában használt adatszerkezeteket.
6. Algoritmus tervezése. Meg kell tervezni azokat a számítási algoritmusokat, amelyek implementációja az alrendszerek szolgáltatásait biztosítják.
A fenti folyamat a tervezési folyamat egy általános elméleti modelljét mutatja be, amely a gyakorlatban különböző módokon alkalmazható. A szoftvertervezés egy szervezettebb megközelítési módját biztosítják a strukturált módszerek, amelyek grafikus modellezési nyelveken készített modelleken alapulnak. A strukturált módszerek olyan rendszermodelleket és grafikus jelölésrendszert tartalmaznak, amelyek alkalmazásával a szoftver strukturális felépítését és dinamikai viselkedését modellezhetjük.
A különböző objektum-orientált tervezési megközelítéseket az 1990-es években egyesítették, és létrejött a Unified Modeling Language (UML) és a hozzá kapcsolódó egységes objektum-orientált tervezési folyamat.
4.3.3 Szoftver validáció
A szoftver verifikáció és validáció (V & V) tevékenység során a cél, hogy megmutassa, hogy a kifejlesztett rendszer megfelel a szoftverspecifikációnak, a megrendelő részéről pedig az általa támasztott funkcionális követelményeknek. Ez különböző szemléket és felülvizsgálatokat foglal magában a szoftverfolyamat minden szakaszában. A legnagyobb validációs költségek azonban az implementáció után jelentkeznek, amikor a működő rendszert teszteljük.
A szoftver tesztelése egy háromlépéses tesztelési folyamat, amelynek során teszteljük a rendszer komponenseit, majd az integrált rendszert, és végezetül a teljes rendszert a felhasználó adataival. A komponensek hibái általában már a tesztelési folyamat korai szakaszaiban felfedezhetők, míg az integrációs szakaszban a komponens interfészek problémáit deríthetjük ki. A tesztelési folyamat szakaszai:
1. Komponens vagy egységteszt. Az egyedi komponensek funkcionalitását teszteljük különböző tesztesetekkel. Minden komponenst az egyéb rendszerkomponensektől függetlenül kell tesztelni.
2. Rendszerteszt. A szoftverkomponensek integrált egysége alkotja a teljes rendszert.
Ez a tesztelési folyamat az alrendszerek és interfészeik közötti hibák felderítésével foglalkozik. Ezen túl teszteljük azt is, hogy a teljes rendszer eleget tesz-e a rendszer funkcionális és nem-funkcionális követelményeinek.
29
3. Átvételi vagy funkcionális tesztelés. Az átvételi teszt során a megrendelő adataival kell tesztelni a rendszert. Az átvételi tesztelés olyan hibákat és hiányosságokat fedhet fel a rendszerkövetelményekben, melyekhez csak a rendszer valós adatokkal történő vizsgálata vezethet.
A komponensek fejlesztési és tesztelési folyamatának sorrendjét a különböző szoftverfejlesztési módszerek eltérően kezeli. Számos folyamatmodell esetén (V-modell, Test Driven Development, Extrém Programozás, stb.) esetén már a tervezéssel egyidőben elkészülnek a tesztesetek. Más folyamatokban a tesztelés tevékenységei az implementáció fázisát követően kezdődnek csak el (pl. vízesés modell). A programozók elkészítik a saját tesztadataikat és elvégzik az általuk fejlesztett kód tesztelését. Mivel a programozó ismeri az általa fejlesztett komponenst leginkább, ily módon ő a legalkalmasabb személy arra, hogy a lehető legjobb teszteseteket állítsa elő. A tesztesetek megfelelő tervezése alapvető feltétele a sikeres tesztelési folyamatnak. A gyakorlatban egy hibás kódot nem teljeskörű teszttel is lehet tesztelni, amely ahhoz vezethet, hogy nem minden hiba kerül felderítésre.
4.3.4 Szoftverevolúció
A szoftver evolúció vagy szoftverkarbantartás, a szoftverfejlesztésben használt kifejezés, amely arra utal, hogy a kezdetben kifejlesztett szoftvert a későbbiek rendszeresen frissítjük. A szoftver evolúció célja az esetlegesen jelentkező változások implementálása. A meglévő rendszerek soha sem teljesek, és folyamatosan fejlődnek.
Ahogy fejlődnek, a rendszer összetettsége úgy növekszik. A szoftver evolúció fő célja, hogy folyamatosan biztosítsuk a rendszer megbízhatóságát és rugalmasságát. A karbantartás költsége gyakran többszöröse a szoftver kezdeti kifejlesztése költségeinek.