Cserkúti Péter, BME - AAIT. Szoftverfejlesztési projektek menedzsmentje Szoftverfejlesztési módszertanok

Átírás

1 SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS SZOFTVERFEJLESZTÉSI MÓDSZERTANOK Miről lesz szó? Szoftverfejlesztési projektek menedzsmentje Szoftverfejlesztési módszertanok extreme Programming Microsoft Solutions Framework Esettanulmány 1

2 Szoftverfejlesztési projektek menedzsmentje Szoftverfejlesztési project Kategória: Szervezetfejlesztési project Cél: Szervezet hatékonyabb működése 2

3 Projekt háromszög Projekt követelmények Projekteredmények: funkciók Kettő szabadon választható, a harmadik ezek függvénye Projekt életciklus Kezdeményezési folyamatcsoport Projekt indítása Tervezési folyamatcsoport Projekteredmény behatárolása Projektterv kialakítása Végrehajtási folyamatcsoport Követési és felügyeleti folyamatcsoport Projekt kontroll Változás menedzsment Zárási folyamatcsoport Projekt befejezése Projekt kiértékelése 3

4 Kezdeményezési folyamatcsoport Vízió megfogalmazása Projekt kereteinek a meghatározása Felelős szervezeti egységek kijelölése Tervezési folyamatcsoport Lépések 1 Cél: projektmenedzsment terv elkészítése Projekteredmények behatárolása Projekt terjedelmének behatárolása Feladatlebontási struktúra (WBS Work Breakdown Structure) Projekt menedzser határozza meg, az egyes elemek delegálhatók szakértőknek WBS elemek konkrét tevékenységekre (Activity) bontása Terület szakértője végzi Tevékenységekhez költség, erőforrás és időtartam rendelhető 4

5 Tervezési folyamatcsoport Lépések 2 Ez alapján: ütemterv, becsült erőforrás terhelés Ütemezés vizuális szemléltetése Sávos diagramok: Gannt-diagram, Hálódiagramok, Erőforrás profilok Kritikus tevékenységek és utak meghatározása (ha az csúszik, minden csúszik) Költség becslés Kiadások és költségek meghatározása tevékenységenként Projekt marketing megtervezése Hogyan kommunikáljunk az egyes érdekcsoportokkal? Hogyan legyen a végtermék elfogadott? Kockázatelemzés Kockázatok azonosítása Valószínűségük, hatásuk meghatározása Alternatívák, kezelés, intézkedések kidolgozása Beszállítókkal való szerződéskötések tervezése 5

6 Tervezési folyamatcsoport Lépések 3 Eredményként előáll a projektmenedzsment terv Ez alapján számos további bázisterv készíthető az esetleges kockázatok csúszások kezelésére Végrehajtási folyamatcsoport Projektmenedzsment terv szerint halad Emberek és erőforrások koordinálása Tevékenységek (Activity) végrehajtása Minőségbiztosítás, információk begyűjtése Beszállítókkal szerződések kezelése 6

7 Követési és felügyeleti folyamatcsoport Projekt előrehaladásának monitorozása Cél: Problémákat időben felismerni Az eredeti bázistervtől/projektmenedzsment tervtől való eltérést időben detektálni Projektkontroll lépések Projektkontroll Típusok: Eredménykontroll, folyamatkontroll Normák meghatározása: viszonyítási alap Folyamatkontroll: idő és költségterv (időben vagy pénzben csúszunk-e) Eredménykontroll: WBS-ben rögzített mérföldkövek Információ gyűjtése: napi/heti/havi Elemzés: terv vs. tény adatok összehasonlítása Korrekció Erőforrás, idő és költségterv módosítása Projektterv módosítása Új bázisterv alkalmazása 7

8 Zárási folyamat Projekt eredmény átadása Projekteredmény dokumentálás Szerződések lezárása Projekt értékelése Szervezeti formák Lineáris-funkcionális struktúrán alapuló Projektre orientált Mátrix struktúrán alapuló 8

9 Lineáris-funkcionális A tevékenységeket a funkcionális szervezeti egységek (részlegek) végzik (pénzügy, számvitel, értékesítés, termelés, ) A projektvezető a részlegektől külön helyezkedik el Nincs projektmenedzseri hatáskör koordinátori szerep, információs központ Felelősség és hatáskör nincs összhangban Hátrány: Napi operatív teendők mellett a projektre nem marad idő A részlegben a projekt háttérbe szorul Közvetett kommunikáció, részlegek várnak egymásra Előny: Azonos szakmai képzettségűek egy helyen -> hatékony munkaidő Tapasztalat későbbi projektekben jól hasznosítható (szervezeti struktúra állandó) Projektre orientált Elkülönült szervezeti egység végzi a projekt teljesítését Minden projektre külön csapat Kiveszik az embereket az egyes részlegekből (átkerülnek a projekt vezető hatáskörébe) Felelősség és hatáskör azonos szinten Előny: Közvetlen információáramlás Nem kell a napi operatív feladatokkal foglalkozni Hátrány: A projekt háttérbe szorítja a funkcionális szakmai feladatokat Változó összetétel Megszerzett tapasztalat jelentős része eltűnik 9

10 Mátrix struktúrán alapuló Megosztott hatáskörök Projektvezető Ütemezés Mit és mikor(ra)? Funkcionális szervezeti egység vezetője Szakmai kérdések Hogyan (és ki)? Projektteljesítési stratégiák Szerződés típusok Elszámolási módok 10

11 Szerződés típusok Kérdés: hova helyezzük a kockázatot és felelősséget? (projekt tulajdonos vs. kivitelező) Típusuk Tradicionális szerződéstípus Kulcsrakész szerződéstípus Menedzsment szerződéstípus Tradicionális Az egyes tevékenységeket más-más külső partnerre bízza a projekt tulajdonos Mindenkivel külön szerződés. Mindenki csak a saját részéért felel. A teljes projekteredmény kockázata a tulajdonosé Előny: A tulajdonos (és csak ő) átlátja a projektet Változások rugalmasan kezelhetőek Szélesíthető a verseny, csökkenthető az ár Hátrány: Kockázat a tulajdonosnál Közvetett információáramlás a külső közreműködők között Szoftverfejlesztéshez általában nem jó 11

12 Kulcsrakész A projekt tulajdonos egyetlen fővállalkozóval szerződik (neki lehetnek alvállalkozói) Csak a fővállalkozó felelős a projekt eredményért Előny: Felelősség a fővállalkozónál Kevesebb munka a tulajdonosnál (projektvezetést a vállalkozó végzi) Hátrány: Módosítási igény nehezebb (alku) Nehezebben áttekinthető, ellenőrizhető Kisebb a verseny (kevesebb a kulcsrakész vállalkozó) Drágább: a vállalkozó beárazza a kockázatot Menedzsment típusú A kettő ötvözése A projekt tulajdonos és a külső közreműködők között egy menedzsment vállalkozó A menedzsment vállalkozó Vezeti a projektet Köti a szerződéseket a külső közreműködőkkel Fizeti a számlákat a tulajdonos számlájáról Nála van a projekt kockázata és felelőssége (nagyrészt) 12

13 Elszámolási módok Ár bázisú pénzügyi elszámolás Költség bázisú pénzügyi elszámolás Cél bázisú pénzügyi elszámolás Ár bázisú elszámolás Előre rögzítésre kerül a fix ár Nem függ a tényleges költségektől Szoftverfejlesztéshez általában jó Kiszámítható a megrendelő szempontjából Kockázat a kivitelezőnél Szélsőséges ajánlattevői magatartások Irreálisan magas költségtartalékok Költségtartalékok hiánya -> rossz minőség, csúszás 13

14 Költség bázisú elszámolás Nincs fix ár előre Tényleges költségek + vállalkozói nyereség Kockázat a projekttulajdonosnál Rugalmas Vállalkozónak kiszámítható (nincs szélsőséges ajánlattevői magatartás) A megrendelőnek kevésbe kiszámítható Cél bázisú elszámolás Teljesítmény motiválása Az előzőek kiegészítése lehet Költségcél, határidőcél, 14

15 Szoftverfejlesztési projekt lépései 1. Követelmény elemzés (requirements engineering) Jövőkép, célok Üzleti és funkcionális igények analizálása 2. Tervezés (design) Rendszermodell megalkotása 3. Implementáció (programming) Implementációs terv Megvalósítás Implementációs teszt Összeépítés (build management) Rendszerteszt 4. Integráció (integration) Rendszerbevezetés Funkcionális teszt Üzemeltetési teszt Projekt indítása, árajánlat Pontos árajánlathoz részletesen ismerni kell a feladatot, feltételez egy rendszertervet De ez gyakran nincs Megoldások Két lépcsős árajánlat: rendszerterv, majd megvalósítás Együtt a kettőre, de megfelelő tartalékokkal (itt is cél a lehető legjobban megismerni a rendszert) A megrendelő megbíz egy külső tanácsadó céget a funkciókövetelmény analízissel. Teljesítési mód: szerzős típus, elszámolási mód meghatározása Megbeszélések alapján WBS fa felállítása, aktivitások meghatározása -> költség számítása 15

16 Mit tartalmazzon a szoftverspecifikáció? Aktorok: szerepkörök Felhasználói esetek aktorok szerinti bontásban Entitások: milyen adatokat tároljunk a rendszerben Adatbázis séma Rendszer architektúra terve: blokkos felépítés, felhasznált technológiákkal Folyamatábrák: a rendszer üzleti folyamatai Menüszerkezet: aktorok szerint Navigációs digram: oldalak, képernyők közötti átmenet Képernyőtervek: mockup, űrlapok felépítése Design: űrlapok design-ja Projekt finanszírozás, pénzáramlási tervek A bevételek és kiadások összeírása (táblázatban vagy grafikusan) A projektek általában utófinanszírozottak (+ résszámlák) 16

17 Tipikus hibák a gyakorlatban Megrendelő szemszögéből Tisztázatlan projektcélok, nincs tisztában a lehetőségekkel Módosítási igények kezelése (drága) Project marketing: ellenállás a projekttel szemben cégen belül Üzemeltetés, karbantartás, support: ez is kell? Fejlesztői szemmel: Kockázatok: túl vagy alulárazza a projektet Nem vonja be a felhasználót, megrendelőt. Nem egyeztetnek egymással eleget, megfelelő mélységben, nem értik meg egymást A vezetés nem koordinálja eléggé a folyamatot Nincs megfelelő tervezés Kontroll hiánya ÁLTALÁBAN: hiányos projekt menedzsment, gyakran nincs rá pénz 17

18 Szoftverfejelsztési módszertanok Mi az amit csinálni akarunk? Szoftver fejlesztés cél: gyártás Milyen a jó szoftver... kielégíti az igényeket belefér a budgetbe határidőre kész van 18

19 Meghatározó tényezők Projekt jellemzők Méret Határidők Architektúra Módszerek(tanok) projekt vezetési módszer tervezési módszer fejlesztési módszer tesztelési módszer karbantartási módszer DE... Nem nagyon van olyan módszertan, amely az összes területet lefedné A különböző módszerek a tényezők bizonyos intervallumában hatékonyak azon belül is testreszabandók 19

20 fejlődés klasszikus módszerek tökéletesség szabályok kevés rugalmasság tudomány modern módszerek nem kell a tökéletességre törekedni legyen pont elég jó nagyon rugalmas (cél a megelégedett felhasználó) inkább ajánlás gyűjtemény (pl. MSF) művészet Módszertanok XP extreme Programming AM Agile Modeling UP Unified Process RUP Rational Unified Process MDD Model Driven Development SODA Serviceoriented Development of Applications MSF Microsoft Solutions Framework Scrum 20

21 extreme programming Egy fegyelmezett és szabályozott szoftverfejlesztési megközelítés Elsősorban nagy bizonytalanságú, dinamikusan változó követelményekkel rendelkező projektekhez Ügyfélbevonás, csapatmunka Kis méret: 2 10 fős csapatok számára XP I. Módszertan, amely az egyszerűséget, kommunikációt, visszajelzést és bátorságot tekinti a legfontosabb értéknek a fejlesztés során. Fontos a kód minősége, a tesztelés, nincs felesleges dokumentáció (ami nem produktív, az nem kell) A megrendelő, menedzser és programozó szerepére, valamint az ezekben a szerepeket végző emberek jogaira és kötelezettségeire helyezi a hangsúly. 21

22 XP II. Projekt életciklus A megrendelő határozza meg a számára üzleti értéket jelentő funkcionalitást A programozó megbecsüli a költségeket A megrendelő meghatározza a prioritást A programozó implementálja a kialkudott funkcionalitást release-eken/iterációkon keresztül 22

23 Projektbontás Releasek (release plan, release meeting) mérföldkövek, dátumokkal user sztorikból Iterációk elsősorban prioritás alapján Taskok technológiai funkciók a fejlesztők számára User stories Mint a Use Case-ek, de mégis mások 3 sor, kártyák formájában Az ügyfelek írják nem technikai, nem limitált, nemcsak felhasználói felület Az üzleti érték a lényeg Nem túl részletes becsléshez, később pontosítják ideális időbecslés (hetek) Forrásul szolgálnak Relesase Planning Meeting elfogadási tesztek 23

24 Spike solutions Kis technológiai prototípusok a user sztorikban felmerülő problémákra Pontosítja a user sztorikat Release plan A teljes projekt terv (szerű) Időbecslés ideális, nincsenek problémák, várakozások tesztelés benne van priorizálás (ügyfél) A sztorikból kiválasztani a release halmazokat dátumok utána az iterációs halmazokat Amíg meg nem egyezik mindenki költségek, idő, tartalom, minőség (teszteltség,...) 24

25 Iterációs tervek Minden iteráció elején Egy iteráció 1-3 hét hosszú Feladatok, taszkok a fejlesztőknek user sztorik a release planből előző iterációk hibajavításai 1-3 nap Részletes, az implementációra koncentrál Elfogadási tesztek User sztorikból az iterációk alatt Ügyfél adja meg forgatókönyvek Tesztadatok Black Box Minőségbiztosítás 25

26 Projektsebesség Hány user sztori készül el... Ügyfél: Egy iterációra csak annyi user sztorit szabad választani, amennyit az előző iterációban sikerült megcsinálni Fejlesztő: Egy iterációra csak annyi taskot szabad választani, amennyit az előző iterációban sikerült megcsinálni 26

27 27

28 Páros programozás Két ember, egy gép Jobb kódminőség ami később megtérül Egyikük operatív gyártja a kódot A másik stratégiai gondolkodás gondolkodik a következő lépésen Cserélnek! meg kell szokni Bugok, tesztek Elfogadási tesztek mielőtt debuggolnánk Minden talált hibára újabb teszt vissza ne jöjjön Unit tesztek legyen meg előbb, mint a kód Automatikus biztonságos refaktoring 28

29 Stand-up meeting Fontos a jó és hatékony kommunikáció a csapaton belül Minden nap Egy közös gyűlés mindenki áll rövid! spontán Közös kódtulajdonlás Bárki bármit módosíthat új funkciók, bugfixek, stb. Nincs egy főnök még vezető programozó sem mindenki tévedhet és téved is Unit tesztek 29

30 Könyörtelen refaktorálás A kódújrafelhasználás valóban költséghatékony? Reaktorálás redundancia megszüntetése újraírás minták frissítés Egyszerű, jó minőségű kód unit tesztek Gyakori integráció (check-in) Max 1 nap, de inkább néhány óránként Mindig a legutóbbi kóddal dolgozzunk Kompatibilitási problémák hamar előjönnek 30

31 Ember mozgatás Nem támaszkodhatunk egy emberre Tudás megosztás duplikációk minták best practices Probléma elosztás Segítség mindenki ért mindenhez load balancing Párok!!! extreme programming Foglalkoztatott megrendelő Felhasználói történetek (user sztori) Elfogadási teszt Költségbecslés Rövid iterációk, folyamatos program kibocsátás A felhasználó határozza meg a program kibocsátást Gyors tervezés Páros programozás Kollektív kód birtoklás Unit teszt 31

32 Microsoft Solutions Framework (MSF) Microsoft Solutions Framework (MSF) Útmutatás a sikeresebb IT megoldásokhoz: Gyorsabban, Kevesebb emberrel, Kisebb kockázattal Jobb minőségben Elvek, folyamatok, best practice-ek gyűjteménye NEM módszertan! Projektmenedzsment keretrendszer, amely testreszabható MS koncepció: nincs egyetlen struktúra, folyamat, ami mindig jó Alkalmazható kis és nagy, bonyolult projektetkben is Lehet közben követni vízesés modellt vagy akár valamilyen agilis módszertant is 32

33 Általános jellemzők Nyílt, őszinte kommunikáció támogatása Mindenki számára ismert, közös cél A csapat felépítése nem hierarchikus, inkább egy hálózatra hasonlít Mindenkinek megvan a saját szerepköre és felelőssége, de végső sikerért mindenki felel (MSF Team Model) Cél: üzleti érték előállítása Maradjunk agilisak, készüljünk fel a változásokra Fektessünk be a minőségbe Építsük be a tapasztalatainkat Minimális/ideális méret Nem minden projekthez De minden méretre vannak használható részek Elsősorban nagyobb projektekre 3-12 hónap (leginkább 4-6), minimum 3 (ideálisan 7-11) létszámú csapatban Skálázás: feature team-ek 33

34 MSF kulcs elemei Csapat modell minıség funkciók Kockázat kezelés Folyamat modell - Project Management Discipline - Risk Managament Discipline - Readiness Management Discipline MSF csapat modell elégedett megrendelő Product Management User Experience felhasználói hatékonyság kommunikáció Kereteken belül Program Management Független és Release Management telepítés és karbantartás fejlesztés a specifikáció szerint Development Test együttműködő szerepek Mindenki saját küldetéssel és szereppel rendelkezik Egyenrangú szerepek minőségbiztosítás Nem 6 ember! 34

35 Product Management Cél: elégedett ügyfél Igények felmérése. Olyan szoftver készüljön meg, amire szükség van. Feladatok Termék megtervezése Piackutatás, felhasználói igények felmérése Mikor mondható sikeresnek a termék? Milyen verziók (release-ek) legyenek a termékből? Marketing Üzleti érték meghatározása/megfogalmazása Megrendelő/felhasználók bevonása Program Management A termék előállítása a rendelkezésre álló keretek körött, kényszereket betartva A megrendelő legyen elégedett Ütemezés, funkcióhalmaz, költségek arányosítása Feladatok Klasszikus projekt menedzsment feladatok (költségek kezelése, projekt terv, kockázat kezelés, kommunikáció megszervezése, erőforrás kezelés) Folyamatos ellenőrzés Mérföldkövek, ütemezés Minőség ellenőrzés Adminisztratív feladatok 35

36 Development Specifikáció szerinti megvalósítás Segítenek a specifikáció elkészítésében is Tervezés Rendszer és részletes tervek Becslések Könnyebben betartathatóak a határidők (ők mondták) Technológia szakértők Technológia kiválasztása Testing Minőségi jellemzők meghatározása Ellenőrzése Tesztelési tervek, Automatikus tesztelés megtervezése 36

37 User Exprience Cél: felhasználói hatékonyság növelése Továbbképzés, tréning Használhatóság Visszajelzések begyűjtése Use case-ek finomítása Többnyelvűség Elérhetőség Release Management Gördülékeny szállítás (telepítés) Csomagolás Telepítés, konfigurálás, testreszabás 37

38 Vízesés modell Egy részfeladatot be kell fejezni a következő elkezdése előtt Mérföldköveket definiál Mikor használjuk? Jól definiálhatóak az egyes fázisok Nincs sok változás menet közben Spirális modell A követelmények folyamatosan finomodnak Előny Megrendelő és kivitelező kommunikációja erős Hátrány Nincsenek tisztán megfogalmazott ellenőrzési pontok. A fejlesztési folyamat kaotikus lehet 38

39 A kettő együtt Mérföldkövek a vízesésből Kreativitás, visszacsatolás a spirális modellből MSF folyamat modell Deployment Complete Release Readiness Approved Vision/Scope Approved Scope Complete Project Plans Approved 39

40 MSF Mérföldkövek Az MSF folyamat modell egy mérföldkő alapú modell A mérföldkövek felülvizsgáló és szinkronizációs pontok (az egyes szerepek között) A mérföldkövek lehetővé teszik az addigi végrehajtás értékelését és a szükséges korrekciók megtételét Mérföldkövek típusai Elsődleges mérföldkövek Belső mérföldkövek Egy elsődleges mérföldkő elérése mindig a csapat és az ügyfél közötti egyetértés kérdése. Projektenként tipikusan azonosak. Belső mérföldkövek: a projekt folyamat és az elért eredmények értékelése. Projektenként változhat. A leszállítandó közbenső termékek a fizikai bizonyítékai annak, hogy a csapat elérte a mérföldkövet Jellemző mérföldkövek Minden fázishoz, minden mérföldkőhöz tartoznak tipikus felelős szerepkörök Mérföldkő Vízió/határok elfogadva Project terv elfogadva Termék elfogadva Elsődleges felelős szerepkör Product Management Project Management Development és User Experience Termék kiadható Termék telepítve Testing és Release Managemente Release Management 40

41 Iteratív fejlesztés Minden iterációnak új funkciókat adunk hozzá Version relese itáráció végén Nem szokás egyben kifejleszteni egy nagy projektet, célszerű felbontani Nem feltétlen szekvenciális Párhuzamosan Külön verzió csapatok Verzió release-ek kezelése Fel kell készülni arra, hogy nem csak egy verzión dolgozunk, hanem lesz következő is Kell egy release stratégia Melyik release-be milyen feature kerüljön Release határidők Alapfunkciókat először Egy már használható, minimális funkciójú verzióval kell indítani Funkciók priorizálása kockázat alapján Iteráció ne legyen túl hosszú A felhasználónak ne kelljen sokat várnia Változás kezelés Új funkciókról egyeztetés, hatásaik, költségeik, prioritásuk vizsgálata 41

42 Fejlesztés és telepítés A telepítés is a folyamat fontos része Telepítéstől képez üzleti hasznot a termék Az iteráció részét képezi mind a kettő Egy iteráció a folyamatban 42

43 Vizionálás fázis (termék elképzelés) Jelzi az egyetértést A projekt okait A kívánt kimenetet A projekt megvalósít-hatóságát A projekt céljait és korlátait A lehetőségeket és kockázatokat A projekt struktúráit illetően A végére Elképzelés Termékelképzelés elfogadva Mindenki érti, hogy mi a végső cél Tudjuk, hogy milyen funkciók kerülnek bele a projektbe és mik nem Cserkúti Péter, BME Hozzávetőleges - AAIT ütemterv Kockázatok nagyjából ismertek Belső mérföldkövek Csapat felállítása Termékelképzelés elfogadva Termékelképzelés dokumentum tervezet Kockázatértékelő dokumentum v1 43

44 Project definíciós dokumentum siker mérőszámok szerepek, felelősségek üzleti igények projekt célok projekt teljesítés feltételezések kivételek kockázatok Miért csináljuk Honnan tudjuk, hogy sikeresek vagyunk Kinek kell segítség Feltételezések, függőségek Kockázatok projekt kompromiszszumok Időterv Funkciókon és mérföldköveken a hangsúly ~1 naptól egy hétig Milyen gyakran frissítsük az időtervet? Kell részletes cseklista? Idő vagy munka alapú becslés? Erőforrsás követés plussz 50-75% karbantartási idő (megéri?) 44

45 Kommunikációs terv Hogyan kommunikálnak a tagok egymással, ügyfelekkel? Megbeszélés (official, ad-hoc) Telefon Folyosón Új, belépő emberek? Kockázat menedzsment 1. azonosítás leírás 2. elemzés nuugdíjas kockázatok 5. kontrol kockázat értékelı dokumentum 3. terv Top figyelés Mindig csinálni kell egyébként elfogadod a kockázatokat Felhasználható: csinálni vagy sem, milyen feltételekkel, milyen erőforrásokkal, stb. 45

46 Tervezés fázis Követelmény lista leképzése megvalósítható funkciókra Use case-ek meghatározása Szintek Koncepcionális Logikai Fizikai Funkcionális specifikáció elkészítése A megvalósítandó funkciók listája Ez alapján időbecsülhetünk Projekt tervek elfogadva Tervezés Elfogadási feltételek Az érintettek és a fejlesztők egyetértenek Belső mérföldkövekben, azok határidejében Szerepkörökben és felelősségekben Kockázat kelezésben Funkcionális specifikáció Projekt ütemezési terv Melyik funkciót, ki és mikor? 46

47 Belső mérföldkövek Projektterv elfogadva Technológiák és felhasználandó termékek kiválasztása Funkcionális specifikáció Master project plan Master schedule plan Fejlesztő és tesztelő környezet felállítása Fejlesztés fázis A funkciók kifejlesztése Elfogadási feltétel Az összes funkció kifejlesztve Tesztelésre kész Eredmény Forráskód Futtatható fájlok, binárisok Telepítő Megvalósított funkciók listája befagyasztva (nincs több új funkció) Teszt esetek meghatározása Terjedelem teljes Fejlesztés 47

48 Belső mérföldkövek Terjedelem teljes Proof of concept verzió Belső build-ek (n., n+1. build) Előrehaladás mérhető Belső szinkronizációs pontok a párhuzamosított munkákban Stabilizáció fázis Stabilizálás Tesztelés valós körülmények között Bugfix Kiadás Jelzi az egyetértést a Termék stabilitása Minden programhiba ismert vagy megoldott Termék ügyféloldali elfogadása Rendszer menedzsment és támogathatóság Csapat fókusza a következő kiadáson kérdésekben 48

49 Belső mérföldkövek Bug convergence A javított hibák száma utoléri a jelentett hibák számát Zero bug bounce Amikor a bugfix utoléri a tesztelőket és nincs aktív bug Release cancidate Ez megy majd ki a pilot group-oknak Pre-production test complete User acceptance test complete Pilot complete Kiadás Telepítés fázis Előkövetelmény szoftverek feltelepítése Termék feltelepítése Konfiguráció Utána: felhasználói megelégedettség mérése 49

50 Belső mérföldkövek Szükséges háttérszoftverek, keretrendszerek feltelepítve Termék feltelepítve Ekkor még lehetnek felhasználói visszajelzések problémákról Telepített verzió stabil Egyetért mindenki abban, hogy a szoftver az elvárásoknak megfelelően működik Telepítetés kész A stabil verzió után van egy csendes időszak, amíg a csapat nem dolgozik a projekten, de készenlétben vannak (15-30 nap) Informatikai projektmenedzsment gyakorlati módszerek 50

51 Napi build A termék minden egyes nap elkészül A napi build előnyei: Jelzi, hogy a csapatmunka működik, a termék készül A termék és a termék fejlődése látható, tapasztalható A fejlesztési folyamat szívritmusa vannak zavarai Tényleg tudok minden nap buildelni? Egy tipikus 4-6 hónapos projektnél tényleg nehéz buildelni az első héten Aztán IGEN! 51

52 Néhány tipp Forráskód követő rendszer Minden fejlesztő lokálisan dolgozik Minden este / éjjel megtörténik a rendszer összeépítése és a fejlesztők minden reggel az új verzióval kezdenek Minőségi elvárások forduljon, füstteszt, stb. Automatizálás a környezet kiépítése erőforrásokat igényel Ennek a felépítése egy folyamatos munka, még az első projekt végén sem lesz tökéletes (fél)kész tervből hogyan lesz forduló kód? Nagyon kis projekt Nincs terv, csak kód Kis projekt Terv csak papíron esetleg Wordben Projekt Egyszeri kódgenerálás Nagy projekt Inkrementális kódgenerálás, szinkron Nagyon nagy projekt MDA 52

53 Kódgenerálás előnyei Tervezni kell A kód legalábbis hasonlítani fog a tervre Sok mechanikus munkától kímélhet meg Egységes, minta alapú megoldások a teljes rendszerben A kód és terv szinkronban tartása esetén nagyon erős eszköz (felelősség, kövspec.) Kódgenerálási alapelvek Skeleton generálás Minták alkalmazása (minták alapján teljes kódrészek) Mennyire legyen okos a generátor? 53

54 Egyirányú kódgenerálás Visio, XDE A terv sosincs kész A változások követése nehézkes A kód felülíródik vagy nem konzisztens a tervvel A szinkron a terv és a kód között megoldható de nem biztosítható Van terv Ha teljesen kész a terv, akkor jó Szinkronizáció XDE, Visio, VS (reverse engineering) Nem válik szét a fejlesztő és a tervező Sérül: a terv az elsődleges példány (baj?) Nincs master példány A módosítások követése nehéz Kis projektek esetén működhet A fejlesztő és tervező ugyanaz a személy Valódi szinkron a terv és kód között 54

55 Inkrementális kódgenerálás Orcas Kis projektekhez drága A fejlesztőknek meg kell szokni A terv az elsődleges példány A módosítások szigorúan egy irányúak Sablon alapú megoldások, minták alkalmazása Egyszerű módosítás A generált kód fejlesztési alapelvei Cél Fejlesztők csereszabatosak, és kód áttekinthető, egységes legyen(ek) Fejlesztési szabvány Pl. elnevezési konvenciók minta kódok (pl. exception kezelés) 55

56 Napi munkafázisok fejlesztés Develop Készül az új kód A fejlesztő dolgozik a saját gépén módosított és új kód Develop (fejlesztés) módosított és új követelmények Specify (specifikálás) Napi munkafázisok bejelentés Check-in aktuális állapot Check-in (beadás) módosított és új kód módosított és új követelmények Develop (fejlesztés) Specify (specifikálás) Az elkészült munkadarab integrációja a szoftver aktuális állapotába Változás! tehát változáskezelést kell alkalmazni forráskód-kezelő szabályok 56

57 Napi munkafázisok build Build aktuális állapot Check-in (beadás) módosított és új kód módosított és új követelmények Build (elkészítés) Develop (fejlesztés) napi build Specify (specifikálás) A szoftver aktuális állapotának leképezése telepíthető termékké Ha a projekt elkészült, ennek az eredményét adjuk ki a megrendelőnek Napi munkafázisok tesztelés Test aktuális állapot Check-in (beadás) módosított és új kód módosított és új követelmények Build (elkészítés) Develop (fejlesztés) napi build Test (tesztelés) hibák, visszajelzések Specify (specifikálás) A termék aktuális állapotának összevetése a követelményekkel általános elvárásokkal A visszajelzéseket rögzítjük 57

58 Visszacsatolás aktuális állapot Check-in (beadás) módosított és új kód módosított és új követelmények Build (elkészítés) Develop (fejlesztés) napi build Test (tesztelés) hibák, visszajelzések Specify (specifikálás) A fejlesztést természetesen befolyásolják a bejelentett hibák és egyéb észrevételek is A napi ciklus A teljes kép aktuális állapot Check-in (beadás) Build (elkészítés) napi build Test (tesztelés) A csapat tagjai konkurensen hajtják végre az egyes fázisokat módosított és új kód Develop (fejlesztés) hibák, visszajelzések módosított és új követelmények Specify (specifikálás) 58

59 Mikor ágaztassunk el? Ha szükség van rá, mert Inkompatibilis házirend Termék kiadása Új funkciók fejlesztése Ha egy ág befagyasztására van szükség Tesztelési okok Termék kiadása Elágaztatás alapok Főág (mainline) modell A fejlesztők a főágban vagy egy adott funkció fejlesztési ágában tevékenykednek A kiadott termékverziók ágában csak kritikus hibajavítások történnek V1.0 főág Új technológia próbaág 59

60 Változások propagálása A változtatásokat lehetőleg az elágaztatás óta legkevesebbet módosult ágban tegyük meg Propagáljunk sűrűn és a lehető legkorábban Az összefésülést mindig a megfelelő tudással bíró ember végezze (vezető vagy senior fejlesztő) A jó forráskódkövető rendszer Támogatja az elágaztatást (branching) Támogatja a háromutas összefésülést (three way merge) Integrálható a fejlesztők által használt környezetbe Nincs útban 60

61 Az elkészült kód beadása Check-in aktuális állapot Check-in (beadás) módosított és új kód módosított és új követelmények Build (elkészítés) Develop (fejlesztés) napi build Test (tesztelés) hibák, visszajelzések Specify (specifikálás) Az elkészült munkadarabok kódjának elhelyezése a forráskód kezelő rendszerbe Csak a forrásfa házirend feltételeinek megfelelő kód A forráskód-kezelő nem biztonsági mentésre való! A beadás lépései Mások változásainak szinkronizálása Build a fejlesztő gépén Fejlesztői regresszióteszt (elrontott-e valamit a szinkronizálás) Kódellenőrzés (code review) Beadás Társ-build (buddy-build) Hibanyilvántartás frissítése 61

62 A termék megépítése Build aktuális állapot Check-in (beadás) Build (elkészítés) napi build Test (tesztelés) A megépítés során a forráskód futtatható bináris állományokká alakul módosított és új kód Develop (fejlesztés) hibák, visszajelzések módosított és új követelmények Specify (specifikálás) Miért kell build környezet? Konzisztens fordítási beállítások az egész forrásfára Bármikor byte-helyesen reprodukálható eredmény A forrásfa tetszőleges al-fájának megépítése A fejlesztők saját gépén megépíthető legyen a termék Teljesen automatizált (telepítőkészletet produkál) utólagos telepítőkészlet 62

63 A build fő fázisai Build A forráskódból a bináris állományok elkészítése Eredménye a bináris-fa Utó-build (postbuild) A bináris állományok utófeldolgozása a bináris-fából Telepítőkészlet készítése Build Verification Test (BVT) Az elkészült termék alapfunkcióinak ellenőrzése A build típusai Minden egyes build több platformra készülhet Pl. x86, ia64, amd64, arm Az egyes platformokon belül legalább kétfélét készítünk: Checked (debug) : teljes debug-info Free (release) : a debug info csak a globálisokat és a függvénydefiníciókat tartalmazza 63

64 A kiadások verziói A termék verziószáma mindig tartalmazza a buildszámot: Major.minor.build.serial Pl A build-szám minden nap más A serial az egy napon belüli build-eket különbözteti meg A napi build ideális szinkronizálási pont a másnapi munka elkezdéséhez Ne feledjük: ha egyszer kiadtunk valamit, az örökké él 1. Mindig kérdezd meg: Mit akarok mindenképpen elérni? Mit tudok tenni, hogy a projekt úton maradjon? 2. Minden munka ami nem javítja a terméket, kidobott idő 3. A projekt vezetés feladata az akadályok elhárítása a fejlesztők elől 4. Hibajavítás azonnal! 5. Minden szabály legyen csak útmutatás 6. Mindig a valódi problémán kell dolgozni 64

65 8. Sose vállalj olyan határidőt, amit tudod, hogy nem tudsz teljesíteni 9. Ne hagyd, hogy a megfelelni vágyás veszélyeztesse a projektet 10. Ha Te vagy a felelős akkor viselkedj úgy 11. Nincs 10 perces feature vagy bugfix 12. Csak olyan riportot kérj, ami megéri a fáradtságot 13. Post-mortem elemzésből nagyon sokat lehet tanulni, csapatot építeni 14. Tervezd úgy a megbeszéléseket, hogy megérje őket megtartani 15. A megbeszélés előtt tudd, hogy mit akarsz elérni és ahhoz mi kell majd érd el! 16. Ne hagyd, hogy az időterv irányítsa a projektet vagy demoralizálja a csapatot 17. Legyen az időterv elég agresszív a fókuszhoz, de teljesíthető 18. Néhány havonta mindenki tanuljon meg valami újat 19. Amint tudod, hogy baj van, rögtön cselekedj! 65

66 22. Biztosítsd, hogy mindenki tudja, milyen nagyon nagyon nehéz bug mentes kódot írni 23. Ha valaki azt mondja, hogy nem lehet, biztosan téved csak akarni kell 24. Feature-t akkor szállíts, ha minőségi 25. Mindenki úgy nézze a terméket mint a végfelhasználó 26. A közösen felhasználható kód élvezzen némi prioritást (erőforrás!) 27. Ha a projekt csúszik akkor valami gond van. Nem (csak) többet kell dolgozni, hanem meg kell találni az okokat. 28. A több munka nem jelent jobb produktivitást 29. A hétvége a családé! 30. Gondolkozz többet, dolgozz kevesebbet! 31. A vezetők a csapat tagja, nem felsőbbrendűek 32. Csak az nem hibázik, aki nem dolgozik 66