Projektmenedzsment módszertanok

A szoftverfejlesztésben többfajta projektmenedzsment modell alakult ki az évek során. Ezek célja, hogy egy vázlatos keretrendszert alkossanak a fejlesztés folyamatáról, ezáltal útmutatót adva a hatékony és átgondolt fejlesztéshez, megszabva az egyes folyamatlépések sorrendjét, elvégzésük módját, idejét.

Az adott projekt tulajdonságaihoz leginkább illeszkedő módszertan megválasztása alapvető sikertényező, hiszen kihatással van a projekt ütemezésére, az erőforrások felhasználására, ezáltal a végtermék minőségére. Ezért létfontosságú már a projekt elején tisztázni a megrendelő és a fejlesztő között a módszertannal kapcsolatos döntéseket, kérdéseket.

A szoftverfejlesztési modellek használata és követése nem csak a hagyományos, hanem a mobil eszközökre történő fejlesztés során is elengedhetetlen.

A strukturált módszertanok az 1960-as években jelentek meg először. Az első átfogó, és széles körben elterjedt a vízesés modell volt, amit a mai napig használnak bizonyos területeken.

Szoftverfejlesztési modellek történeti fejlődése

  • Vízesés modell – 1970 (ahol a folyamatlépések kötötten, mélyen dokumentálva, egymás után, meghatározott sorrendben zajlanak le)
  • Iteratív modellek – 1980-as évek (melyekben a folyamatlépések nem lineárisan következnek egymás után, hanem a fázisok a fejlesztés előrehaladtával ismétlődnek)
  • Evolúciós modellek – 1980-as évek (a fókusz a gyorsan elkészülő prototípuson van, melyet azután iteratívan tökéletesítenek)
  • Újrafelhasználás alapú modell – 1990-es évek (a hagyományos objektum orientált fejlesztési paradigma helyett újrafelhasználható komponensek készítése és használata)
  • V modell -1990 (a vízesés továbbfejlesztése a tesztelés kihangsúlyozásával)
  • Agilis modellek – 2000-es évek (Az eddigi modellekkel ellentétben itt a fókusz az interakciókon, a prototípusokon, az együttműködésen és a változáskezelésen van)

Alábbiakban részletesen bemutatjuk ezeket a modelleket.

Vízesés modell

A tradicionális szoftverfejlesztési módszertanok legjelentősebbje a Vízesés modell (Waterfall). 1970-ben írta le Winston W. Royce egy tanulmányában. A fejlesztés folyamata eszerint több, egymás után lezajló részkomponensből tevődik össze. Minden fázis megkezdésének feltétele az előző fázis befejezése. A fejlesztés folyamatát a következő ábra mutatja be:

img20

Előnyök:

  • Ha a követelmények már a fejlesztés legelején teljesen ismertek, akkor jól használható
  • Nem csak szoftverek fejlesztésénél használható, hanem egyéb termékfejlesztési projekteknél is
  • Kevésbé komplex projektek esetén előnyös a modellel járó magas fokú szabályozottság
  • Biztosítja a követelmények rögzítését a folyamat elején
  • Feszes ellenőrzést biztosít
  • Ha valaki készen van az adott fázisban rá kiosztott munkával, másik projekten dolgozhat, míg a többiek is elérik a fázis lezárásához szükséges állapotot.
  • Határozott, könnyen érthető mérföldkövek

Hátrányok:

  • Nincs lehetőséget arra, hogy a fejlesztés reagáljon a felhasználói igények időközben történő megváltozására, már az életciklus elején befagyasztják a követelményeket
  • Ebből kifolyólag már a fejlesztés kezdetén ismernünk kell valamennyi követelményt, azok későbbi módosítására vagy bővítésére nincs lehetőség.
  • Lineáris (nincsenek iterációk), így nehéz a visszalépés a felmerült problémák megoldására, és ez jelentősen megnöveli a javítás mind költség-, mind időigényét.
  • A megrendelő csak a folyamat végén láthatja a rendszert, menet közben nincs lehetősége véleményezni azt.
  • Az integráció a teljes folyamat végén, egyben, robbanásszerűen történik.
  • Minden egyes fázis az előző fázis teljes befejezésére épít, ami tovább növeli a kockázatokat
  • A tesztelés a projekt kései szakaszában kezdődik el, így a hibák sokáig rejtve maradhatnak, ami növeli a kockázatokat és a költségeket
  • Dokumentum-vezérelt, és túlzott dokumentálási követelményeket állít fel
  • Az egész szoftvertermék egy időben készül, nincs lehetőség kisebb részekre osztására

V-modell

A V-modell a vízesésmodell módosításával keletkezett, annak továbbfejlesztéseként. A német védelmi minisztérium fejlesztette ki, és tette a német hadsereg szoftver-fejlesztési modell szabványává 1992-ben. Minden tervezési fázisnak van egy párja a tesztelési fázisok között, ezáltal a tesztelés jóval nagyobb hangsúlyt kap a modellben. Felépítése:

img21

Az egyes szakaszokban létrehozott termékek közvetlenül átkerülnek a következő szakaszba. A bal oldali ágon a tervezési, a jobb oldalin pedig a tesztelési fázisok találhatóak, amelyek párhuzamosan mennek végbe. Azokat a termékeket, amiket le kell ellenőrizni, eltérő szintű hibaellenőrzési eljárásokkal kapcsolja össze, világosan és expliciten kijelölve ezeket a szinteket. A V-modell a szoftverfejlesztési életciklus minden fázisára alkalmazza a validációt (jó minőség, ügyféligények kielégítése) és verifikációt (dokumentációnak, követelményeknek való megfelelés) tevékenységét.

Előnyök

  • Egyszerű a használata
  • A tesztelés már jóval a kódolás előtt elkezdődik, ezzel megteremtve a lehetőségét a hibák korai és így költséghatékony kijavításának
  • A felmerült hibát javítják az adott fázisban, nem gyűrűzik tovább
  • Kis projektek számára praktikus, ahol a követelmények jól ismertek

Hátrányok

  • Túlságosan merev, nem rugalmas modell
  • A kódolás az implementációs fázisban történik (a folyamat vége felé), ezért nem készül korai prototípus, használható szoftver
  • Ha menet közben bármilyen változás történik, minden dokumentációt frissíteni kell

Iteratív modellek

// Spirál

A spirál modell egy kockázatvezérelt szoftverfejlesztési modell. Iterációkból áll, melyek folyamatosan ismétlődnek a projekt során. Egy iteráció négy nagyobb fázisból áll. Ahogy fejlődik a termék, ugyanazokon a fázisokon megy keresztül újra és újra. Ezáltal lehetővé válik a kockázatok korai felismerése. Az egyes iterációk végén a követelmények egyre nagyobb részhalmazát kielégítő rendszer áll elő. Az iterációk során a rendszer szélességében bővül, és nem bonyolódik. Hangsúlyos a megrendelő folyamatos, aktív bevonása a fejlesztési tevékenységes során. Hátránya, hogy a nagyszámú köztes iteráció miatt sok, végül felesleges dokumentáció születhet.

img22

1. ábra – Forrás
// RUP (Rational Unified Process)

A RUP egy iteratív szoftverfejlesztési keretrendszer. A RUP nem egy kész, követendő eljárást ad minden projektre, sokkal inkább egy könnyen változtatható keretet azok kézbentartásához. Célja az olyan termékek előállításának biztosítása, melyek rendelkeznek elég magas minőségi színvonallal és a kívánt szolgáltatásokkal, miközben az időbeli ütemezés és a költségvetés határokat nem lépték át.

A RUP alapja az iteráció. Azaz a különböző szakaszokban ugyanazokkal a területekkel foglalkozunk, egyre finomabb megoldáshoz jutva. Az iterációk által könnyebben alkalmazkodhatunk az új követelményekhez és hamarabb tudjuk azonosítani és megoldani a projekt kockázatait.

A RUP használati eset alapú, és architektúra központú. Szinte minden tervezési fázisban viszontlátjuk a használati eset (use case) fogalmát különböző nézetekből.

A RUP több feladatra bontja a projektfejlesztési folyamatot (Core Process Workflows):

  • Tervezés (planning)
  • Üzleti folyamatok elemzése (Business Modeling)
  • Követelményelemzés (Requirements)
  • Elemzés és tervezés (Analysis & Design)
  • Implementáció (Implementation)
  • Teszt (Test)
  • Átadással kapcsolatos tevékenységek (Deployment)

Támogató tevékenységek:

  • Konfiguráció menedzsment és változáskövetés (Configuration & Change Management)
  • Projektvezetés (Project Management)
  • Programozó környezet felállítása (Environment)

img23

2. ábra – Forrás

Minden tevékenység minden iterációkban előfordul, de különböző súllyal. Kezdetben az üzleti folyamatok elemzése a hangsúlyos, majd ez eltolódik követelményelemzés felé, és így tovább. Így az életciklus lépései nem egymást követik, hanem átfedik egymást.

Agilis modellek

Az agilis projektmenedzsment a mai formájában 2001-ben alakult ki, az Agile Manifesto publikálásával. Ez a kiáltvány röviden, de tökéletesen összefoglalja az agilis megközelítések fókuszát:

„Egyének és interakciók a kőbe vésett folyamatok és eszközök helyett

Működőképes szoftver a dokumentáció helyett

Együttműködés az ügyféllel a szerződés körüli tárgyalások, viták helyett

Válasz a változásokra a tervek betartása helyett”

Az agilis szoftverfejlesztés alapelvei:

  • Ügyfél elégedettség elérése használható termék gyors leszállításával
  • Örüljünk a változó követelményeknek, még a fejlesztés végén is
  • Rendszeresen szállítsunk működőképes terméket (inkább hetente, mint havonta)
  • A haladás elsődleges mértéke a működőképes szoftver
  • Fenntartható fejlesztés, mely egy állandó ütemet képes tartani
  • Közel mindennapos együttműködés az üzleti oldal és a fejlesztők között
  • A szemtől-szembeni kommunikáció a kommunikáció legjobb módja
  • A projektek motivált egyének köré épülnek, akikben meg kell bíznunk
  • A technikai kiválóságra és a jó minőségű szoftver dizájnra való folyamatos koncentrálás
  • Egyszerűség. Az el nem elvégzett munka mennyiségének maximalizálása alapvető fontosságú.
  • Önszerveződő csoportok.
  • Rendszeres alkalmazkodás a változó körülményekhez
// Scrum

A Scrum egy agilis és inkrementális szoftverfejlesztési / projektmenedzsment módszertan.

A módszertan jelentős szerepet tulajdonít a csoporton belüli összetartásoknak. A csoporton belül sok a találkozó, és a szóbeli kommunikáció.

A scrum szabályai, definíciói

  • Csapat: Egy scrum csapat kisméretű, keresztfunkcionális (különböző szakértelmű, különböző szakterületű) emberekből áll, és önszerveződő
  • Backlog: Folyamatosan össze kell gyűjteni, nyilván kell tartani az elvégzendő feladatokat, prioritást rendelve hozzájuk. Ez a lista a backlog.
  • Sprint: Fix hosszúságú szakaszokban (1–4 hét) szállítsunk le a backlogból választott feladatok közül potenciálisan élesíthető, kész megoldásokat. Ezeket a szakaszokat hívjuk sprinteknek.
  • Standup/daily meeting: Mindennapos, rövid, hatékony megbeszéléseket kell tartani. Mindenki három főkérdésre kell, hogy válaszoljon:
    • Mit csináltál az előző megbeszélés óta?
    • Mit fogsz csinálni a következőkben?
    • Akadályozza valami a munkádat?
  • Hatékonyságnövelés: A sprint lezárásakor értékeljük az eltelt időt, összegyűjtve a jó és rossz elemeket, majd keressünk megoldást az utóbbiakra. A backlog tartalmát, ha kell, folyamatosan értékeljük át.

A scrum szereplői

  • Scrum master: A folyamatokat adminisztrálja, s a legfőbb felelős azért, hogy minden a tervek szerint haladjon. Ő teszi fel a standupokon a kérdéseket, őhozzá lehet fordulni, ha akadály merül fel. Egy scrum csapatnak csak egy scrum mastere lehet, de egy scrum master elláthatja szerepét akár 2-3 csapaton belül is.
  • Product owner: Rövidítve PO. Az a személy, aki meghatározza a fejlesztések sorrendjét, priorizálva a backlog feladatait. Ő írja a story-kat, hozzá lehet fordulni a feladatokkal kapcsolatos kérdésekkel. Szigorúan egyetlen egy PO-ja lehet csak egy csapatnak. A PO nem feltétlenül termékmenedzser, az ő feladata a kívülről (termékmenedzser, tulajdonos, ügyfél, sales stb.) és belülről (leginkább a fejlesztők) érkező igények fogadása, illetve az egyeztetés ezzel kapcsolatosan.
  • Megrendelők: A feladatokat nem feltétlenül a PO találja ki, azok sok irányból érkezhetnek, a különböző megrendelők felől. Megrendelőből jellemzően több van, ők szigorúan csak a PO-val kommunikálhatnak.
  • Fejlesztők: A fejlesztő a backlogból kiválasztott feladatokat valósítja meg, továbbá az oda újonnan bekerülő feladatok egymáshoz képesti bonyolultságát is ő becsli meg.

A scrum folyamata

Egy projekt általában egy ötlettel kezdődik. Először elkezdik címszerűen összeírni, hogy mit is kell tartalmaznia a terméknek ahhoz, hogy az ötlet megvalósuljon. Ezt a terméket leíró listát nevezzük product backlog listának. Majd ha az ötletek összegyűltek, elkezdik kidolgozni a mögöttes tartalmat is – hasonlóan a követelmény-specifikációkhoz.

A projekt elindításához nem szükséges a teljes product backlog, viszont nagyon fontos a már meglévő elemek priorizálása (Business Value). Aki képviseli és tulajdonolja ezt a listát, az a Product Owner. A kick-off meeting-en ő tájékoztatja a fejlesztőcsapatot a projektről.

Ezt követően elkezdődnek az iterációk, amiket a Scrumban sprinteknek nevezünk. A product owner és a fejlesztőcsapat a sprint elején összeül, és ennek a listának egy, a tetején lévő részhalmazát, (amiről a product owner úgy gondolja, hogy belefér egy sprintbe) odaadja a csapatnak véleményezésre. A team és a product owner kompromisszumot köt, és megállapodnak az elvégzendő feladatok mennyiségéről. Innentől kezdve a product backlog ezen része a sprint backlog, ami már nem módosítható. A lista elemeit (story) feladatokra (task) bontják, és ezeket a task-okat kivitelezik a fejlesztők, míg egy story el nem készül, majd folytatják a következő story-val a sprint backlog végéig. Szintén fontos elem, hogy minden nap van egy úgynevezett daily scrum, amikor a team maga (az önszervezésből adódóan) megbeszéli, hogy mit csináltak az előző napon, hova jutottak, és az adott napon mivel folytatják. Nagyon fontos, hogy a sprint backlog listában nem rétegeket felépítő dobozok vannak, hanem függőleges szoftver funkciók. Azaz ezekben benne van a UI, a backend munka, az adatbázis munka, és minden, ami csak szükséges a feature működéséhez. Így a sprint végére a feature-ökhöz többé már nem kell hozzányúlni, és így ragasztjuk a termékhez minden sprintnél az újabb feature-öket. A szakaszos munka miatt időnként elkerülhetetlen a refaktorizálás, vagyis a programkód tisztítása, strukturálása, optimalizálása.

Egy sprint részletesebben:

img24

3. ábra – Forrás
// XP

Az Extreme Programming (XP) szintén egy agilis módszertan, hasonló a Scrum-hoz. Szintén iterációkat alkalmaz, fontos eleme a kommunikáció, és a rendszeres ügyfél oldali visszajelzés, valamint a backlog catalog-hoz hasonló követelménylistából dolgozik (az XP esetében az ügyfél által meghatározott, nagy prioritású követelményeket „user story”-nak hívjuk). Az XP azonban még nagyobb szakértelmet és még gyakorlottabb tesztelői csapatot igényel, mint a Scrum.

A scrum és az XP különbségei:

  • A XP rövidebb iterációkkal dolgozik. Míg a Scrum-nál jellemzően 2-4 hét hosszúságúak, addig az XP esetében ez az időtartam 1-2 hét
  • A Scrum-ban a sprint tartalmának elfogadása után azon már nem lehet változtatni, nem kerülhetnek be újabb backlog elemek. Az XP ezzel szemben képes kezelni az iterációk közbeni változtatásokat. Amíg nem kezdődik el a munka egy konkrét funkcióval, addig az bármikor felcserélhető egy hasonló fejlesztési igényű funkcióval.
  • Az XP esetében a fejlesztők szigorúan ragaszkodnak az ügyfél által meghatározott prioritási sorrendhez.
  • A Scrum módszertana nem hangsúlyoz konkrét szoftverfejlesztési gyakorlatokat, eljárásokat. Ezzel szemben az XP több ajánlott fejlesztési módszert is javasol:
  • Teszt-vezérelt fejlesztés (TDD) (Lényege, hogy a fejlesztő először a saját programjának tesztjeit írja meg, csak ez után a programkódot)
  • Páros kódolás (két fejlesztő dolgozik egy munkaállomáson, egyikőjük írja a kódot, a másik rögtön felülvizsgálja. A szerepek időközönként felcserélődnek)
  • Kód refactoring (kód újratervezés, lényege, hogy a programkódon a fejlesztők olyan transzformációkat alkalmaznak, amelyek úgy változtatják meg a kód bizonyos tulajdonságait, hogy a kód működése változatlan marad)

Az Extreme Programming 4 fő fókusza:

  • Kódolás
    • Fontos elem
    • Problémák itt jelennek meg ténylegesen
    • Programozók közötti kommunikáció
  • Tesztelés
    • Test-First Development
    • Előrehozott teszteléssel történő fejlesztés – Inkrementális tesztfejlesztés, forgatókönyv alapján
    • XP szerint:
      • Kevés teszt – kevés hiba
      • Sok teszt – összes hiba
    • Tesztelés segíti a dokumentációt
    • Maga a teszt a dokumentáció (a metódusokat írja le)
    • Felhasználók bevonása a tesztek fejlesztésébe
    • Automatizált tesztelő eszközök használata
  • Odafigyelés
    • Kapcsolat a megrendelővel
    • Folyamatos kommunikáció
  • Tervezés
    • Fontos
    • Rugalmasság
      • Esetleges későbbi változások miatt
      • Független komponensek
      • OOP elvek (objektumorientált programozás, három fő elve: egységbezártság, öröklés, többalakúság)

Az XP 5 alapértéke:

  • Kommunikáció
  • Egyszerűség
  • Visszacsatolás
    • Visszacsatolás a rendszer felől
    • Visszacsatolás a megrendelő felől
    • Visszacsatolás a csapat felől (Planning Game)
  • Bátorság
  • Tisztelet

Prototípusos (evolúciós) fejlesztés

Az evolúciós fejlesztés alapötlete, hogy a kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyűlt tapasztalatokat építsük be egy újabb termék verzióba. Ezt a folyamatot mindaddig ismételjük, amíg el nem érjük a kívánalmaknak már megfelelő rendszert.

Tehát célja a megrendelővel folyamatosan együttműködve a kezdeti vázlatos specifikációt folyamatosan finomítva kialakítani a végleges rendszert.

Ez a megközelítési mód sokkal inkább lehetővé teszi párhuzamosságot és a sokkal gyorsabban csatolja vissza a fejlesztési folyamatba a menet közben felmerülő felhasználói igényeket.

A projekt első fázisában, viszonylag gyorsan elkészül egy prototípus, amelyben a tervek fő gyengeségei kiderülhetnek, és megoldhatjuk az esetleges technológiai kérdéseket is.

img25

Alkalmazhatósága:

  • Rövid élettartamú kis rendszerek esetében
  • Kis és közepes méretű rendszerek esetében
  • Nagy rendszerek részeiként (pl. GUI)

Hátrányai – problémák:

  • Előrehaladás nehezen mérhető
  • Folytonos változások miatt a rendszer egésze kevésbé átlátható és strukturálatlan
  • Specifikáció hiánya megdrágítja a karbantartást
  • Fontos rendszerjellemzőket (teljesítményt, biztonságosságot, megbízhatóságot) feláldozzák a gyorsaságért
  • Nem készül komoly rendszerdokumentáció az időigényessége miatt.

Újrafelhasználás-alapú (komponens) fejlesztés

Az újrafelhasználás-alapú fejlesztés az 1990-es évek végén alakult ki, a „hagyományos”, OO (objektum-orientált) alapú fejlesztésben való csalódottság eredményeként. A módszer lényege, hogy már kész (lefejlesztett vagy megvásárolt), szoftverkomponenseket (függvényeket) használnak fel újra és újra szisztematikusan. A (későbbi) újrafelhasználhatóságot már a tervezésnél figyelembe kell venni.

Újrafelhasználás követelményei:

  • Elérhetővé kell tenni az újrafelhasználható komponenseket
  • A komponensek felhasználóinak bízni kell a komponensek helyes és biztonságos működésében
  • A komponenshez tartozó dokumentációnak segíteni kell az újrafelhasználót az illesztésben
  • Az elérhető újrafelhasználható komponensek és a kulcsrakész rendszerek egy szerkezetbe történő integrációját valósítja meg, ezáltal lecsökkenti a költségeket és a kockázati tényezőket.

A követelményeknél hozott kompromisszumok olyan rendszerhez vezethetnek, amely nem teljesen felel meg a felhasználó valódi igényeinek.

img26

  • Előnyei:
    • Csökkenő költségek
    • Gyorsabb fejlesztés
    • Kisebb kockázat
    • Fokozott megbízhatóság
  • Hátrányai, problémák:
    • Növekvő karbantartási költségek
    • COTS-rendszerek (commercial off-the shelf, készen megvásárolható szoftverek) együttműködési képességeinek problémái
    • COTS-rendszerek szállítói által nyújtott támogatás eltér színvonala
    • NIH szindróma (olyan vállalati filozófia, melynek lényege, hogy el kell kerülni a más (külső) forrásból származó termékek, kutatások, sztenderdek és tudás használatát)