Ipari esettanulmány negyedik rész

Az SPL orientációjú fejlesztése, és egy szisztematikus megközelítése

Az SPL orientációja

Az SPL orientációjú fejlesztés egy szisztematikus megközelítése a cég specifikumainak (pl. szűk keresztmetszetek, szervezeti kultúra) és ezáltal sikeresebbé teszi a vásárlók igényeinek való megfelelést. Mérnöki szempontból pedig ötvözi a fejlesztendő szoftver alapkövetelményeit (requirements), hatókörét (scoping) és így a sikeresség mércéjét is definiálja. Ez az integrált megközelítés viszont egy bonyolult procedúrát vetít előre, ami több kihívást hordozhat, mint elszeparált, egyedi fejlesztések halmaza. A felmerült akadályokat így csoportosították a tanulmány szerzői: nem megfelelő transzferálási stratégia, elégtelen elkötelezettség és rossz menedzsment stratégia. Ezeket a gyengeségeket öt faktor mentén elemezték: erőfeszítés (1), kommunikáció és együttműködés (2), ismétlések és alkalmazkodás, motiváció (3), szükségletek (4) és technológiai volatilitás (5).

Az erőfeszítések

Az „erőfeszítések” tekintetében a szakértelem és az előzetes tapasztalatok hiánya azt eredményezte, hogy a résztvevők sok esetben akkor értették csak meg az adott folyamat lényegét, ha az már elindult, illetve az absztrakciós képességeiken is sok múlt, hiszen még el-nem-készült termékek funkcionalitását kellett „megálmodni”. A priorizálás szabálya jobban kellett volna, hogy megjelenjen az iterációk során, de mivel kevés ismétlést hajtottak végre, ez a fajta szűrés és rendszerezés nem lett akkurátusan végrehajtva. Nem volt egyértelmű a különbség a követelmények és az elérendő tulajdonságok között. Problémák merültek fel a tulajdonságok szemcsésségénél is, ami az adatok nem elég precíz rendszerezésének és elkülönítésének részletességére utal. Az erőfeszítésekre és motivációra általában véve negatívan hatott a kommunikáció és együttműködés hiánya és a már említett technológiai kihívások; kevés ismétlés és az így adódó gyenge adaptálhatóság.

Az ismétlések eredményei

Kevés volt a résztvevők közötti interakció. Arról a kevés ismétlésről is csak a meetingek alkalmával érkezett visszajelzés. A személyes kommunikáció hiánya szintén egyre gyakoribbá vált a projekt előrehaladtával. Kevés ismétlés lett végrehajtva és azok is meglehetősen egyoldalúak voltak. Az ismétlések eredményeit nem vették kellően figyelembe a későbbi mozzanatoknál, például nem módosították a kiindulási paramétereket, nem fejlesztették a folyamatot, nem adresszáltak a csak később felmerült új feladatokat és problémákat. Nem volt „önreflexív” a procedúra. Mindezek a részben motivációs bajok jelentős technológiai volatilitást eredményeztek. Az egész folyamat összemosódott, lehetetlen volt beazonosítani, hogy hol történt hiba, mely mérföldkőhöz kellene visszatérni és onnan újrakezdeni, mint egy kvázi checkpointról.

Követelmények tisztázása

Több dolgot ajánlanak megfontolásra a szerzők, habár az írásuk a problémák felderítését célozta, a javaslataik így csak az adott esetre vonatkoznak, elméleti háttérrel nem lettek megerősítve: szakértők bevonása, különösen a lehetséges termékkombinációk sorra vételénél és elemzésénél; rövidebb iterációs periódusok (rövidebb, de több iteráció); hatókör és követelmények pontosabb tisztázása; holisztikusabb megközelítés - más tudományterületek, avagy céges/vásárlói igények figyelembevételével. Korábbi sikeres projektek elemzése szintén hasznos lehet, még annak fényében is, hogy ilyen projekteket jellemzően multinacionális nagyvállalatok implementálnak és dokumentálnak részletesen. Viszont az agilis metódusok jobban passzolnak a KKV-k kisebb és rugalmasabb struktúráihoz, míg ilyen módszerek nehezebben alkalmazhatók merev konfigurációk esetén, de mindkét esetben nyitottságra és stratégiai gondolkodásra van szükség, révén, hogy az egész céget érintő szoftveres termékcsomagokról, mélyreható átalakításokról beszélünk, amik jelentős anyagi befektetést és időráfordítást igényelnek.

www.sciencedirect.com