Hivatkozás: 2. fejezet

A szoftverfolyamat a szoftverrendszer fejlesztéséhez szükséges tevékenységek strukturált halmaza. Vegyük észre, hogy “szoftverfolyamatról” — nem pedig “szoftverfejlesztési folyamatról” — beszélünk.”

A szoftverfolyamatoknak sokféle fajtája létezik, de mindegyiket az alábbi négy alapvető tevékenységtípus alkotja:

• Szoftver specifikáció – annak meghatározása, hogy a rendszernek mit kell tennie;
• Szoftvertervezés és megvalósítás – a rendszer szervezetének meghatározása és a rendszer megvalósítása;
• Szoftver validálás – annak ellenőrzése, hogy a rendszer azt teszi-e, amit az ügyfél akar;
• Szoftverfejlesztés – a rendszer módosítása az ügyfél változó igényeinek megfelelően.

A szoftverfolyamat-modell egy folyamat absztrakt ábrázolása. Egy folyamat leírását mutatja be valamilyen meghatározott nézőpontból. Amikor szoftverfolyamatokat írunk le és tárgyalunk, általában az ezekben a folyamatokban végzett tevékenységekről, például egy adatmodell meghatározásáról, egy felhasználói felület megtervezéséről stb. és e tevékenységek sorrendjéről beszélünk.A folyamatleírások tartalmazhatnak továbbá:

• termékeket, amelyek egy folyamattevékenység eredményei;
• szerepeket, amelyek a folyamatban részt vevő személyek felelősségét tükrözik;
• elő- és utófeltételeket, amelyek olyan állítások, amelyek egy folyamattevékenység végrehajtása vagy egy termék előállítása előtt és után igazak.

A tervvezérelt folyamatok olyan folyamatok, amelyekben az összes folyamattevékenységet előre megtervezik, és az előrehaladást ehhez a tervhez mérik. Az agilis folyamatokban a tervezés inkrementális, és a folyamatot könnyebb a változó vevői igényeknek megfelelően módosítani. A gyakorlatban a legtöbb gyakorlati folyamat mind a tervvezérelt, mind az agilis megközelítés elemeit tartalmazza.

A vízesésmodell Tervvezérelt modell. A specifikáció, a szoftvertervezés, a megvalósítás, a tesztelés és a karbantartás különálló és elkülönült fázisai. Inkrementális fejlesztés A specifikáció, a fejlesztés és a validálás egymásba fonódik. A rendszer fejlesztése verziók (inkrementumok) sorozataként történik, és minden egyes verzió az előző verzióhoz képest új funkciókat ad hozzá. Lehet tervvezérelt vagy agilis. Integráció és konfiguráció Jelentős számú újrafelhasználható komponens/rendszer meglétén alapul. A rendszerfejlesztési folyamat ezeknek az összetevőknek a rendszerbe történő integrálására összpontosít, ahelyett, hogy a semmiből fejlesztené őket. Lehet tervvezérelt vagy agilis.

A gyakorlatban a legtöbb nagy rendszert olyan folyamat segítségével fejlesztik, amely az összes fenti modell elemeit tartalmazza.

A vízesésmodellben külön azonosított fázisok vannak:

Követelményelemzés és -meghatározás A rendszer szolgáltatásait, korlátait és céljait a rendszer felhasználóival konzultálva határozzák meg. Ezután ezeket részletesen meghatározzák, és rendszerspecifikációként szolgálnak. Rendszer- és szoftvertervezés A rendszertervezési folyamat az átfogó rendszerarchitektúra kialakításával a követelményeket vagy hardver- vagy szoftverrendszerekhez rendeli hozzá. A szoftvertervezés magában foglalja az alapvető szoftverrendszer-absztrakciók és kapcsolataik azonosítását és leírását. Implementálás és egységtesztelés Ebben a szakaszban a szoftvertervezés programok vagy programegységek halmazaként valósul meg. Az egységtesztelés magában foglalja annak ellenőrzését, hogy az egyes egységek megfelelnek-e a specifikációnak. Integráció és rendszertesztelés Az egyes programegységeket vagy programokat integrálják és teljes rendszerként tesztelik, hogy megbizonyosodjanak arról, hogy a szoftverkövetelmények teljesülnek. A tesztelés után a szoftverrendszert átadják a megrendelőnek. Üzemeltetés és karbantartás Általában (bár nem feltétlenül) ez a leghosszabb életciklus-fázis. A rendszert telepítik és gyakorlati használatba veszik. A karbantartás magában foglalja az életciklus korábbi szakaszaiban fel nem fedezett hibák kijavítását, a rendszeregységek megvalósításának javítását és a rendszer szolgáltatásainak fejlesztését az új követelmények felfedezésével.

A vízesésmodell legfőbb hátránya, hogy a folyamat elindulása után nehéz a változtatásokat befogadni. Elvileg egy fázisnak be kell fejeződnie, mielőtt a következő fázisra léphetnénk. A vízesésmodell problémái a következők:

Nehéz kezelni a változásokat A projekt különálló szakaszokra való rugalmatlan felosztása megnehezíti a változó vevői igényekre való reagálást.Ezért ez a modell csak akkor megfelelő, ha a követelmények jól ismertek, és a változások meglehetősen korlátozottak lesznek a tervezési folyamat során. Kevés üzleti rendszer rendelkezik stabil követelményekkel. Nagyon kevés valós alkalmazás A vízesésmodellt leginkább olyan nagy rendszerfejlesztési projekteknél használják, ahol egy rendszert több helyszínen fejlesztenek.Ilyen körülmények között a vízesésmodell tervvezérelt jellege segíti a munka koordinálását.

A inkrementális fejlesztés előnyei:

A változások alacsonyabb költségei A változó vevői igényekhez való alkalmazkodás költségei csökkennek. Sokkal kevesebb elemzést és dokumentációt kell újra elkészíteni, mint a vízeséses modell esetében. Gyakori visszajelzés Könnyebb visszajelzést kapni az ügyféltől az elvégzett fejlesztési munkáról. Az ügyfelek véleményezhetik a szoftver bemutatóit, és láthatják, hogy mennyi mindent valósítottak meg. Gyorsabb átadás A hasznos szoftver gyorsabb átadása és az ügyfélhez való eljuttatása lehetséges. Az ügyfelek hamarabb tudják használni és hasznosítani a szoftvert, mint a vízeséses eljárás során.

Az inkrementális fejlesztés problémái (a vezetés szempontjából):

A folyamat nem látható A vezetőknek rendszeres eredményekre van szükségük a haladás méréséhez. Ha a rendszereket gyorsan fejlesztik, nem költséghatékony olyan dokumentumokat készíteni, amelyek a rendszer minden egyes verzióját tükrözik. A rendszer struktúrája hajlamos romlani az új inkrementumok hozzáadásával Hacsak nem fordítanak időt és pénzt a szoftver javítását célzó refaktorálásra, a rendszeres változtatás hajlamos elrontani a szerkezetét. A további szoftvermódosítások beépítése egyre nehezebbé és költségesebbé válik.

Ez a megközelítés szisztematikus újrafelhasználáson alapul, ahol a rendszereket meglévő komponensekből vagy COTS (Commercial-off-the-shelf) rendszerekből integrálják.A folyamat szakaszai:

• komponenselemzés;
• követelmények módosítása;
• rendszertervezés újrafelhasználással;
• fejlesztés és integráció.

Az újrafelhasználás ma már számos típusú üzleti rendszer építésének standard megközelítése.

A szoftverkomponensek típusai:

• Szolgáltatási szabványok szerint fejlesztett, távoli meghívásra elérhető webszolgáltatások.
• Objektek gyűjteményei, amelyeket csomagként fejlesztenek egy komponens keretrendszerrel, például .NET vagy J2EE integrálására.
• Egy adott környezetben való használatra konfigurált, önálló, kereskedelmi forgalomban kapható rendszerek (COTS).

A valódi szoftverfolyamatok technikai, együttműködési és vezetői tevékenységek egymásra épülő sorozatai, amelyek átfogó célja egy szoftverrendszer specifikálása, tervezése, megvalósítása és tesztelése.

A specifikáció, a fejlesztés, a validálás és az evolúció négy alapvető folyamattevékenységét a különböző fejlesztési folyamatokban különbözőképpen szervezik. A vízesésmodellben sorrendben szerveződnek, míg az inkrementális fejlesztésnél egymásra épülnek.

Szoftver specifikáció A rendszer működéséhez és fejlesztéséhez szükséges szolgáltatások, valamint a rendszer működésére és fejlesztésére vonatkozó korlátozások megállapításának folyamata. Követelménytervezési folyamat:

• Megvalósíthatósági tanulmány: műszakilag és pénzügyileg megvalósítható-e a rendszer megépítése?
• Követelmények kiváltása és elemzése: mit igényelnek vagy várnak el a rendszer érdekeltjei a rendszertől?
• Követelményspecifikáció: a követelmények részletes meghatározása
• Követelmények validálása: a követelmények érvényességének ellenőrzése

Szoftvertervezés és megvalósítás A rendszer specifikációjának futtatható rendszerré alakításának folyamata.

• Szoftvertervezés: a specifikációt megvalósító szoftverstruktúra megtervezése;
• Megvalósítás: e struktúra lefordítása futtatható programmá;

A tervezés és a megvalósítás tevékenységei szorosan kapcsolódnak egymáshoz, és átlapolhatók. A tervezési tevékenységek közé tartoznak:

• Építészeti tervezés: a rendszer általános szerkezetének, a fő komponenseknek (néha alrendszereknek vagy moduloknak nevezik őket), azok kapcsolatainak és elosztásuk módjának meghatározása.
• Interfésztervezés: a rendszer komponensei közötti interfészek meghatározása.
• Komponenstervezés: Vegyük az egyes rendszerösszetevőket, és tervezzük meg, hogyan fognak működni.
• Adatbázis-tervezés: tervezze meg a rendszer adatszerkezeteit és azt, hogy ezeket hogyan kell ábrázolni az adatbázisban.

Szoftverérvényesítés Az ellenőrzés és érvényesítés (V & V) célja annak bizonyítása, hogy a rendszer megfelel a specifikációjának és megfelel a rendszer megrendelőjének követelményeinek.

• Validálás: a megfelelő terméket építjük-e (amit a megrendelő akar)?
• Ellenőrzés: helyesen építjük-e a terméket?

A V & V magában foglalja az ellenőrzési és felülvizsgálati folyamatokat és a rendszer tesztelését. A rendszertesztelés magában foglalja a rendszer futtatását olyan tesztesetekkel, amelyek a rendszer által feldolgozandó valós adatok specifikációjából származnak. A tesztelés a leggyakrabban alkalmazott V & V tevékenység, és a következő szakaszokat foglalja magában:

• Fejlesztési vagy komponenstesztelés: az egyes komponenseket egymástól függetlenül tesztelik; a komponensek lehetnek funkciók vagy objektumok, illetve ezek összefüggő csoportosításai.
• Rendszertesztelés: a rendszer egészének tesztelése, különösen fontos a felmerülő tulajdonságok tesztelése.
• Átvételi tesztelés: vevői adatokkal végzett tesztelés annak ellenőrzésére, hogy a rendszer megfelel-e a vevő igényeinek.

A szoftver fejlődése A szoftver eredendően rugalmas és változhat. Ahogy a követelmények a változó üzleti körülmények miatt változnak, az üzletet támogató szoftvernek is fejlődnie és változnia kell.Bár eddig volt egy elhatárolás a fejlesztés és az evolúció (karbantartás) között, ez egyre kevésbé releváns, mivel egyre kevesebb rendszer teljesen új.

A változás minden nagy szoftverprojektben elkerülhetetlen.Az üzleti változások új és megváltozott rendszerkövetelményekhez vezetnekAz új technológiák új lehetőségeket nyitnak a megvalósítások javítására.A változó platformok alkalmazásváltozásokat igényelnek.A változás átdolgozáshoz vezet, így a változás költségei magukban foglalják mind az átdolgozást (pl.pl. a követelmények újraelemzése), valamint az új funkciók megvalósításának költségeit is.

Két stratégia az átdolgozás költségeinek csökkentésére:

Változáselkerülés A szoftverfolyamat olyan tevékenységeket tartalmaz, amelyek előre jelzik a lehetséges változásokat, mielőtt jelentős átdolgozásra lenne szükség. Például prototípus rendszert lehet fejleszteni, hogy a rendszer néhány fő jellemzőjét bemutassák az ügyfeleknek. Változás-tűrés A folyamatot úgy tervezik meg, hogy a változások viszonylag kis költséggel elviselhetők legyenek.Ez általában a növekményes fejlesztés valamilyen formáját foglalja magában. A javasolt változtatásokat olyan inkrementumokban lehet végrehajtani, amelyeket még nem fejlesztettek ki. Ha ez nem lehetséges, akkor csak egyetlen inkrementumot (a rendszer egy kis részét) kell módosítani a változás beépítése érdekében.

A prototípus egy rendszer kezdeti változata, amelyet koncepciók bemutatására és tervezési lehetőségek kipróbálására használnak. A prototípus felhasználható:

• A követelménytervezési folyamatban, hogy segítse a követelmények kiváltását és érvényesítését;
• A tervezési folyamatokban a lehetőségek feltárására és a felhasználói felület kialakítására;
• A tesztelési folyamatban az egymás utáni tesztek futtatására.

A prototípus készítés előnyei:

• A rendszer használhatóságának javítása.
• A felhasználók valós igényeinek való jobb megfelelés.
• A tervezés minőségének javítása.
• A karbantarthatóság javítása.
• A fejlesztési erőfeszítés csökkentése.

A prototípusok alapulhatnak gyors prototípus készítő nyelveken vagy eszközökön. A funkciók elhagyásával járhatnak:

• A prototípusnak a termék azon területeire kell összpontosítania, amelyek nem jól ismertek;
• A hibák ellenőrzése és helyreállítása nem szerepelhet a prototípusban;
• A funkcionális és nem funkcionális követelmények, például a megbízhatóság és a biztonság helyett a funkcionális követelményekre összpontosít.

A prototípusokat a fejlesztés után el kell vetni, mivel nem jó alapot jelentenek egy gyártórendszer számára:

• Lehet, hogy lehetetlen a rendszert úgy hangolni, hogy megfeleljen a nem funkcionális követelményeknek;
• A prototípusok általában nem dokumentáltak;
• A prototípus szerkezete általában a gyors változtatások miatt romlik;
• A prototípus valószínűleg nem felel meg a szokásos szervezeti minőségi szabványoknak.

Ahelyett, hogy a rendszert egyetlen szállításként szállítanák, a fejlesztés és a szállítás inkrementumokra bomlik, és minden egyes inkrementum a szükséges funkciók egy részét szállítja.A felhasználói követelményeket rangsorolják, és a legmagasabb prioritású követelményeket a korai inkrementumok tartalmazzák.Amint egy inkrementum fejlesztése megkezdődött, a követelmények befagyasztásra kerülnek, bár a későbbi inkrementumok követelményei tovább fejlődhetnek.

A inkrementális szállítás előnyei:

• A vevői értéket minden egyes inkrementummal át lehet adni, így a rendszer funkcionalitása korábban elérhetővé válik.
• A korai inkrementumok prototípusként működnek, amelyek segítenek a későbbi inkrementumok követelményeinek megállapításában.
• Kisebb a projekt teljes kudarcának kockázata.
• A legmagasabb prioritású rendszerszolgáltatások általában a legtöbb tesztelést kapják.

Az inkrementális szállítás problémái:

• A legtöbb rendszerhez alapvető eszközökre van szükség, amelyeket a rendszer különböző részei használnak. Mivel a követelményeket nem határozzák meg részletesen, amíg egy inkrementumot meg nem valósítanak, nehéz lehet azonosítani azokat a közös létesítményeket, amelyekre minden inkrementumnak szüksége van.
• Az iteratív folyamatok lényege, hogy a specifikációt a szoftverrel együtt fejlesztik. Ez azonban sok szervezet beszerzési modelljével ellentétes, ahol a teljes rendszerspecifikáció a rendszerfejlesztési szerződés része.

Néhány szoftvercég fordult a szoftverfolyamatok fejlesztéséhez, hogy javítsa a szoftverek minőségét, csökkentse a költségeket vagy felgyorsítsa a fejlesztési folyamatokat. A folyamatfejlesztés a meglévő folyamatok megértését és megváltoztatását jelenti a termékminőség javítása és/vagy a költségek és a fejlesztési idő csökkentése érdekében.

Folyamatérettségi megközelítés A folyamat- és projektmenedzsment javítására és a helyes szoftverfejlesztési gyakorlat bevezetésére összpontosít. A folyamatérettségi szint azt tükrözi, hogy a szervezeti szoftverfejlesztési folyamatokban milyen mértékben vezették be a helyes műszaki és irányítási gyakorlatot. Agilis megközelítés Az iteratív fejlesztésre és a szoftverfolyamat általános költségeinek csökkentésére összpontosít. Az agilis módszerek elsődleges jellemzői a funkciók gyors átadása és a változó vevői igényekre való reagálás.

A folyamatfejlesztési tevékenységek egy visszacsatolási hurokkal rendelkező folyamatos ciklust alkotnak:

• A szoftverfolyamat vagy a termék egy vagy több attribútumának mérése. Ezek a mérések egy alapszintet képeznek, amely segít eldönteni, hogy a folyamatfejlesztések hatékonyak voltak-e.
• Elemzi a jelenlegi folyamatot, és azonosítja a szűk keresztmetszeteket.
• Módosítsa a folyamatot az azonosított folyamat gyenge pontjainak kezelése érdekében. Ezeket bevezetik, és a ciklus folytatódik, hogy adatokat gyűjtsenek a változtatások hatékonyságáról.

Folyamatmérés

• Ahol csak lehetséges, mennyiségi folyamatadatokat kell gyűjteni.
• A folyamatméréseket a folyamatfejlesztések értékelésére kell használni.
• A mérések közé tartozhatnak:
  • A folyamattevékenységek elvégzéséhez szükséges idő, e.pl. naptári idő vagy egy tevékenység vagy folyamat elvégzéséhez szükséges erőfeszítés.
  • A folyamatokhoz vagy tevékenységekhez szükséges erőforrások, pl. a teljes erőfeszítés személynapokban kifejezve.
  • Egy adott esemény előfordulásának száma, pl. a felfedezett hibák száma.

A SEI képességérettségi modell

• Initial: Lényegében ellenőrizetlen
• Megismételhető: Meghatározott és használt termékmenedzsment eljárások
• Meghatározott: Meghatározott és használt folyamatirányítási eljárások és stratégiák
• Irányított: Minőségirányítási stratégiák meghatározása és alkalmazása
• Optimalizálás: Folyamatfejlesztési stratégiák meghatározása és alkalmazása