Sikeres szoftverfejlesztés: a pontosság, ellenõrzés és irányítás fontossága (II. rész)

Minden jó szoftverprojekt mögött

Új megközelítésre van szükség. A mai fragmentált gyártói ökoszisztémának jobb támogatásra van szüksége. A vállalati IT modern szoftverfejlesztõi láncának megtestesülése a háziiparosoknak ez a 21. századi hálózata, legyen a vállalaton belül vagy kívül. És ezek az iparosok saját eszközeikkel és platformjaikkal, választott módszertanukkal és fortélyaikkal egyszerûen nem mûködnek hatékonyan, együttesen és együttmûködõen, ha nincsenek meg az alap keretek, amelyek a szükséges precizitást, ellenõrzést és irányítást nyújtják.

PRECIZITÁS

A projektek eredménytelenségének legelsõ okai mindig is a követelmények voltak. Az iparág statisztikái évek óta ezt tükrözik: a hibák túlnyomó része a követelmények felállításának szakaszából ered, és az elhárításukhoz kapcsolódó költségek exponenciálisan nõnek az életciklusuk során. Ha a követelményeket már eleve megfelelõen tisztáztuk, nemcsak az ügyfél elégedett, de jelentõsen csökken az újra elvégzendõ fejlesztési és tesztelési feladatok is.

Sajnos a technológia irtózatos fejlõdési üteme azt jelenti, hogy ma a fejlesztõ csapatok számára többféle értelemben is még nehezebb pontosan megfogalmazni és megvalósítani az ügyfél kívánságait. Legtöbbször egyszerûen nem tudják, mi a kérés, de ha még tudják is, mire tisztába kerülnek vele, minden esély megvan rá, hogy az ügyfél már inkább valami mást akar.

Az együttmûködés roppant jelentõségû. Az üzletág szereplõinek korai bevonása kritikus fontosságú. De ez még nem elég. A követelmények változnak, és a projekt sikeréhez elengedhetetlen, hogy ne csak bevonjuk õket, de a projektben is maradjanak a tesztelés végéig és a kibocsátás indításáig. Az ilyen szintû folyamatos bevonáshoz hatékony technológiai platformot kell nyújtani; ez lesz a siker alapköve. Csak így lehet az összes vonatkozó követelményt tisztázni és folyamatosan finomítani. Csak így lehet az összes technikai problémát kellõ idõben megbeszélni és megoldani. És csak így lehet a teszteseteket a munka életciklusa alatt végig szinkronban tartani, vagyis biztosítani, hogy amit tesztelnek azt az ügyfél is valóban így szeretné majd látni.

De ez nem jelenti, hogy mindenre ez lenne a megoldás. Sõt, a történelem tanúsága szerint nincsenek szabvány megoldások.

Változóban van az együttmûködés természete. Már az is kihívást jelenthet, hogy minden információnk naprakész legyen, és kapcsolatot tartsunk a vállalaton belüli csapattal. A mobil, közösségi és felhõalapú lehetõségek egyesített erõi azt jelentik, hogy az újítások nemcsak elárasztják az iparágat és gyorsítják a fejlesztések ütemét, de arra is hatással vannak, ahogyan a kérések eleve keletkeznek.

Az együttmûködés mobil, közösségi és ad hoc. A távoli iroda táblájára vagy egy éttermi szalvétára felvázolt követelmények ugyanannyira érvényesek, mint amelyeket táblázatba foglalnak vagy „hivatalosan“, követelménykezelõ rendszeren keresztül nyújtanak be. A mai szoftvergyártó láncban sikerrel érvényesülõ csapatok arra is készek, hogy követelményeket fogadjanak bármilyen forrásból. Méghozzá az egyenlõ elbánás elvei szerint, függetlenül attól, hogy a formátum grafika vagy szöveg, közösségimédia- vagy e-mail üzenet, videó vagy hangrögzítés. Készek tárgyalást kezdeni a lazán meghatározott elképzelésekrõl és borítékok hátára skiccelt tervekrõl, és a megfelelõ kontextusban kezelni a kérdéseket, nem egy olyan zárt ökoszisztémában, ahová a bemeneti információknak csak a fele jut el.

A fogyasztói nyomás eredményeként kritikusabban választjuk meg, hogyan bánunk az alkalmazásokkal. Felhasználóként korábban a funkcionalitás volt a fõ szempont, de az elvárások változnak. A funkcionalitás csupán az „induló alap“; nem kérdés, hogy szükséges. Döntéseink alapja egyre inkább az adott alkalmazás használati élménye, legyen szó személyes vagy munkacélú használatról illetve, hogy a szoftvert, amit kaptunk, használjuk vagy inkább töröljük.

Ennek folytán az üzleti elemzõk, felhasználóiélmény- és egyéb tervezõk érdekes kihívásokkal találkoznak, amikor próbálják vegyíteni a funkcionalitással kapcsolatos és az attól független követelményeket, és akkor még nem szóltunk a szoftverfejlesztõkrõl, akiknek le kell gyártani azt a mûködõképes szoftvert, ami majd elbûvöli az ügyfelet.

A követelmények legyenek képileg kifejezõek és késedelem nélkül lehessen áttekinteni, finomítani és átadni õket. Az összes csapattag számára folyamatosan nyomon követhetõeknek kell lenniük. A vállalatok csak így érhetik el a szükséges agilitást, amivel megfelelnek a szükségleteknek, és elkerülik a követelmények kétértelmûségébõl eredõ frusztrációt és végtelen késedelmeket.

ELLENÕRZÉS

A szoftvergyártó lánc összetettsége sok kihívást eredményez, és ezt a leginkább a szoftvertesztelõ csapat érzi meg. A terméket gyorsan kell piacra dobniuk, ugyanakkor biztosítaniuk kell, hogy minõségi szoftvert bocsátanak ki, és ez finom egyensúly; a neves IT kudarcainak története hosszú, gyakran nagyon személyes és elágazó, de ha valaki késõn érkezik a piacra hiányos funkcionalitással és silány felhasználói élménnyel, az ugyanolyan végzetes lehet a vállalkozása jövõjét tekintve.

A szoftvergyártás fejlõdése a rövidebb kibocsátási idõ, valamint az Agile és Lean folyamatok azt jelentik, hogy a minõségbiztosítás már nem mûködhet önmagában, klasszikus vízesés-modellben, programhibákra vadászva, majd a hibás szoftvert visszaküldve a fejlesztési osztályra „tudtok ennél jobbat is“ feliratú bélyegzõvel.

Az ellenõrzés többszintû. Meg kell ismerni az adott követelmény mögötti szándékot, és biztosítani kell, hogy ezt tükrözze a kibocsátott szoftver. Ez talán nyilvánvalónak tûnik, de gyakran szem elõl tévesztik a szoftver tesztelésekor. A követelmények az üzleti igények magas szintû kifejezésével kezdõdnek. Onnantól kezdõdik a funkcionális és nem funkcionális építõelemek tervezése és finomítása.

Az ellenõrzés annak biztosításával kezdõdik, hogy a teszteseteket a követelmények fent vázolt hierarchiája szerint hozzák létre, és tükrözik a szükségletek legmagasabb és legalacsonyabb szintjét akár egy alkalmas kinézetében, akár egy összetett pénzügyi algoritmus megvalósításában.Hadd említsek egy hasonlatot. A különbség olyan jellegû, mint a között, hogy valaki autóvezetõi képességeit a közlekedési szabályok ismerete szerint mérjük fel (ami persze fontos, alapvetõ követelmény), vagy azt vizsgálva, hogy képes-e a jármûvet irányítani valós körülmények között (ami a biztonság szempontjából döntõ fontosságú). Vagy talán akkor bíráljuk el a legjobban, hogy kaphat-e jogosítványt, ha megvizsgáljuk jó útvonalat választ-e az úti céljához és jól teljesít-e abból a szempontból, amely miatt általában autóba ülünk: hogy biztonságosan és szabályosan eljussunk az adott helyre.

Más szóval, az elkészült termék vizsgálata semmitmondó, ha nem az alapkövetelmények szerint történik. Sõt nem is semmitmondó, hanem félrevezetõ ha a követelmények nem frissülnek és nem nyilvánvalóak a termék életciklusa alatt. A hatékony ellenõrzés biztosítja, hogy az ekvivalens teszteseteket nemcsak létrehozzák, hanem a hozzájuk tartozó követelményekhez kapcsolják az egész gyártási láncban, hogy azonnal módosuljanak, amint az igények változnak.

És megint csak oda jutunk, hogy az együttmûködés roppant fontos. De míg az Agile fejlesztés a tesztelési funkciót közelebb hozza a fejlesztõ csapatokhoz, ami arra utalhat, hogy ezek a szoros és folytonos kapcsolatok könnyebben megteremthetõk, a gyártólánc különféle pontjainál egyre gyakoribb kiszervezés ugyanakkor azt jelenti, hogy nehezebb hatékonyabb együttmûködést elérni, ha nem használnak megfelelõ technológiát arra, hogy a résztvevõ felek megegyezésre jussanak abban a kérdésben, az ügyfél szempontjából vajon mi számít sikernek elvégre tõle ered az üzleti kereslet.

Az Agile fejlesztéshez, amelynek a hangsúlya a mûködõ szoftveren és a rendszeres tesztelésen van, automatizált tesztelésre van szükség. A kézi tesztelés egyszerûen nem tud lépést tartani a „korán tesztelj, gyakran tesztelj“ követelményével, és az olyan szélsõségesebb gyakorlatokból eredõ nyomást sem tudja kezelni, amilyen például a folyamatos integráció, ahol minden fejlesztõ által tesztelt összetevõt naponta többször egy frissített mûködõ rendszerbe integrálnak.

És még ahol fennmaradnak vízesés- vagy hibrid folyamatok, a tesztelés automatizálása ott is olyan szintû teszteltséget és magabiztosságot tesz lehetõvé, ami más módon nem megvalósítható.

Az automatikus tesztelés nem csak hamarabb észleli a hibákat, de ténylegesen minõséget épít a rendszerbe. Ahogy Hibbs, Jewett és Sullivan írják „A Lean fejlesztés mûvészete“ címû munkájukban:

„Ha a forráskódban automatikus tesztek teljes rendszere van, akkor az önellenõrzõ. Így csökken annak valószínûsége, hogy észrevétlen hiba marad a szoftverben.“

A tesztek beépíthetõk az integrált fejlesztési környezetbe, vagy lehetnek nem kód-alapúak, amikor például a követelmények meghatározásába bevont üzleti elemzõk olyan helyzetben vannak, hogy teszteket hozhatnak létre és végezhetnek el.

Alapvetõen elmondhatjuk, hogy lehetetlen mindent tesztelni. És ha csak minden új kibocsátáskor ellenõrizzük, hogy ami korábban mûködött, most sem hibás, az bizony kevés.

Automatizálással és az eredeti üzleti szükségletekhez kapcsolódó, közösen megállapított tesztkezelési szabályokkal, célokkal és prioritásokkal még a legtöredezettebb gyártói lánc is biztosíthatja, hogy az ellenõrzés nem csupán a követelményeken alapul a megfelelõ szinteken, hanem mérhetõ és nagy hatékonyságú is.


Szerző: Borland