SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS ... · 10/4/2012 1 SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS SZOFTVERFEJLESZTÉSI MÓDSZERTANOK Cserkúti Péter, BME - AAIT

10/4/2012

1

SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS SZOFTVERFEJLESZTÉSI MÓDSZERTANOK

Cserkúti Péter, BME - AAIT

Miről lesz szó?

� Szoftverfejlesztési projektek menedzsmentje

� Szoftverfejlesztési módszertanok

� eXtreme Programming

� Microsoft Solutions Framework

� Esettanulmány


10/4/2012

2

Szoftverfejlesztési projektek menedzsmentje


Szoftverfejlesztési project

� Kategória:

� Szervezetfejlesztési project

� Cél:

� Szervezet hatékonyabb működése


10/4/2012

3

Projekt háromszögProjekt 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


10/4/2012

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ő


10/4/2012

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éseCserkúti Péter, BME - AAIT


10/4/2012

6

Tervezési folyamatcsoportLé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


10/4/2012

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


10/4/2012

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ó


10/4/2012

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ó) Cserkúti Péter, BME - AAIT

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


10/4/2012

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/4/2012

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ó


10/4/2012

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)


10/4/2012

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


10/4/2012

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, …


10/4/2012

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 Cserkúti Péter, BME - AAIT

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


10/4/2012

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)


10/4/2012

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



10/4/2012

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


10/4/2012

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


10/4/2012

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” Cserkúti Péter, BME - AAIT

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


10/4/2012

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.


10/4/2012

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



10/4/2012

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


10/4/2012

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, ...)


10/4/2012

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


10/4/2012

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



10/4/2012

27



10/4/2012

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


10/4/2012

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


10/4/2012

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


10/4/2012

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 !!!Cserkúti Péter, BME - AAIT

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 tesztCserkúti Péter, BME - AAIT

10/4/2012

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


10/4/2012

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


10/4/2012

34

MSF kulcs elemei

Csapat modell

Kockázat kezelés

funkciók

Folyamat modellminıség

- Project Management Discipline

- Risk ManagamentDiscipline

- Readiness Management Discipline


MSF csapat modell

kommunikáció

elégedett megrendelő

felhasználói hatékonyság

telepítés és karbantartás

minőségbiztosítás

fejlesztés a specifikáció szerint

Development

Test

ReleaseManagement

UserExperience

ProductManagement

Program Management � Független és

együttműködő szerepek

� Mindenki saját küldetéssel és szereppel rendelkezik

� Egyenrangú szerepek

� Nem 6 ember !

Kereteken belül


10/4/2012

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


10/4/2012

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


10/4/2012

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


10/4/2012

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


10/4/2012

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

Vision/Scope

Approved

Project Plans

Approved

Scope

Complete

Release Readiness

Approved

Deployment

Complete


10/4/2012

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ő Elsődleges felelős szerepkör

Vízió/határok elfogadva Product Management

Project terv elfogadva Project Management

Termék elfogadva Development és User Experience

Termék kiadható Testing és Release Managemente

Termék telepítve Release Management


10/4/2012

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


10/4/2012

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


10/4/2012

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

Elképzelés

Termék-elképzeléselfogadva

� A végére� Mindenki érti, hogy mi a végső

cél� Tudjuk, hogy milyen funkciók

kerülnek bele a projektbe és mik nem

� Hozzávetőleges ütemterv� Kockázatok nagyjából ismertek


Belső mérföldkövek

Kockázatértékelő dokumentum v1

Termékelképzelés dokumentum

tervezet

Csapat felállítása

Termékelképzeléselfogadva


10/4/2012

44

Project definíciós dokumentum

� Miért csináljuk

� Honnan tudjuk, hogy sikeresek vagyunk

� Kinek kell segítség

� Feltételezések, függőségek

� Kockázatok

üzletiigények

projektcélok

projektteljesítés

szerepek, felelősségek

feltételezésekkivételek

sikermérő-

számok

kockázatok

projektkompromisz-

szumok


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?)

� email


10/4/2012

45

Kommunikációs terv

� Hogyan kommunikálnak a tagok egymással, ügyfelekkel?

� Megbeszélés

� E-Mail (official, ad-hoc)

� Telefon

� Folyosón

� Új, belépő emberek ?


nuugdíjaskockázatok

kockázat értékelı dokumentum

Top 10

3. terv5. kontrol

2. elemzés1. azonosítás leírás

4. figyelés

Kockázat menedzsment

� 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.


10/4/2012

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 tervekelfogadva 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?


10/4/2012

47


Projekttervelfogadva

� 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

Terjedelemteljes

Fejlesztés


10/4/2012

48


Terjedelemteljes

� 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

� 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

KiadásStabilizálás

� Tesztelés valós körülmények között

� Bugfix


10/4/2012

49


Kiadás� 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


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


10/4/2012

50


� 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


10/4/2012

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

� Aztán IGEN !

– az első héten


10/4/2012

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


10/4/2012

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.)


Skeleton generálás

Minták alkalmazása(minták alapján teljes kódrészek)

Mennyire legyen „okos” a generátor?

Kódgenerálási alapelvek


10/4/2012

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


10/4/2012

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


Cél

• Fejlesztők csereszabatosak, és

• kód áttekinthető, egységes

legyen(ek)

Fejlesztési szabvány

Pl.elnevezési konvenciókminta kódok (pl. exception kezelés)

A generált kód fejlesztési alapelveiCserkúti Péter, BME - AAIT

10/4/2012

56

Napi munkafázisok – fejlesztésDevelop

� Készül az új kód

� A fejlesztő dolgozik a saját gépén

Develop(fejlesztés)

Specify(specifikálás)

módosítottés új kód

módosított és újkövetelmények


Napi munkafázisok – bejelentésCheck-in

� 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


Check-in(beadás)


aktuálisállapot




10/4/2012

57

Napi munkafázisok – buildBuild

� 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

Build(elkészítés)


Check-in(beadás)


aktuálisállapot

napibuild




Napi munkafázisok – tesztelésTest

� 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



Check-in(beadás)

Test(tesztelés)


aktuálisállapot

napibuild

hibák,vissza-jelzésekmódosított

és új kód



10/4/2012

58

Visszacsatolás

� A fejlesztést természetesen befolyásolják a bejelentett hibák és egyéb észrevételek is



Check-in(beadás)

Test(tesztelés)


aktuálisállapot

napibuild


és új kód



A napi ciklusA teljes kép

� A csapat tagjai konkurensen hajtják végre az egyes fázisokat



Check-in(beadás)

Test(tesztelés)


aktuálisállapot

napibuild


és új kód



10/4/2012

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

főág

V1.0

Új technológia próbaág


10/4/2012

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”


10/4/2012

61

Az elkészült kód beadásaCheck-in

� 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ó!



Check-in(beadás)

Test(tesztelés)


aktuálisállapot

napibuild


és új kód



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


10/4/2012

62

A termék megépítéseBuild

� A megépítés során a forráskód futtatható bináris állományokká alakul


aktuálisállapot


és új kód



Test(tesztelés)


napibuild

Check-in(beadá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


10/4/2012

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


10/4/2012

64

A kiadások verziói

� A termék verziószáma mindig tartalmazza a build-számot:� Major.minor.build.serial

� Pl. 2.5.1018.1

� 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 dolgozniCserkúti Péter, BME - AAIT

10/4/2012

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 Cserkúti Péter, BME - AAIT

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 !


10/4/2012

66

22. Biztosítsd, hogy mindenki tudja, milyen nagyon nagyonnehé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égi25. 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


Documents

SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS ... · 10/4/2012 1 SZOFTVERFEJLESZTÉSI PROJECTEK MENEDZSMENTJE ÉS SZOFTVERFEJLESZTÉSI MÓDSZERTANOK Cserkúti Péter, BME - AAIT