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

10/4/2012

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

Cserkúti Péter, BME - AAIT

1

10/4/2012

Szoftverfejlesztési projektek menedzsmentje


Szoftverfejlesztési project

Kategória: Szervezetfejlesztési

project

Cél: Szervezet

hatékonyabb működése


2

10/4/2012

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

Tervezési folyamatcsoport

Projekteredmény behatárolása Projektterv kialakítása

Végrehajtási folyamatcsoport Követési és felügyeleti folyamatcsoport

Projekt indítása

Projekt kontroll Változás menedzsment

Zárási folyamatcsoport

Projekt befejezése Projekt kiértékelése Cserkúti Péter, BME - AAIT

3

10/4/2012

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

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

Projekt terjedelmének behatárolása

Terület szakértője végzi

Tevékenységekhez költség, erőforrás és időtartam rendelhető Cserkúti Péter, BME - AAIT

4

10/4/2012


Ez alapján: ütemterv, becsült erőforrás terhelés Ütemezés vizuális szemléltetése

Kritikus tevékenységek és utak meghatározása (ha az csúszik, minden csúszik) Költség becslés

Hogyan kommunikáljunk az egyes érdekcsoportokkal? Hogyan legyen a végtermék elfogadott?

Kockázatelemzés

Kiadások és költségek meghatározása tevékenységenként

Projekt marketing megtervezése

Sávos diagramok: Gannt-diagram, Hálódiagramok, Erőforrás profilok

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


5

10/4/2012


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

10/4/2012

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:

Normák meghatározása: viszonyítási alap

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

7

10/4/2012

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

10/4/2012

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

Felelősség és hatáskör nincs összhangban Hátrány:

koordinátori szerep, információs központ

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

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 Hogyan

kérdések (és ki) ?


Projektteljesítési stratégiák

Szerződés típusok Elszámolási módok


10

10/4/2012

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:

Hátrány:

A tulajdonos (és csak ő) átlátja a projektet Változások rugalmasan kezelhetőek Szélesíthető a verseny, csökkenthető az ár 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ó Cserkúti Péter, BME - AAIT

11

10/4/2012

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

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

12

10/4/2012

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

13

10/4/2012

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

10/4/2012

Szoftverfejlesztési projekt lépései 1.

Követelmény elemzés (requirements engineering)

2.

Tervezés (design)

3.

Rendszermodell megalkotása

Implementáció (programming)

4.

Jövőkép, célok Üzleti és funkcionális igények analizálása

Implementációs terv Megvalósítás Implementációs teszt Összeépítés (build management) Rendszerteszt

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

Megoldások

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

15

10/4/2012

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

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

10/4/2012

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


17

10/4/2012

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

10/4/2012

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

10/4/2012

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

20

10/4/2012

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

21

10/4/2012

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

10/4/2012

Projektbontás

Releasek (release plan, release meeting) mérföldkövek, user

sztorikból

Iterációk elsősorban

dátumokkal

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

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

3 sor, kártyák formájában

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

10/4/2012

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

24

10/4/2012

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

10/4/2012

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

10/4/2012



27

10/4/2012

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

Minden talált hibára újabb teszt

mielőtt debuggolnánk vissza ne jöjjön

Unit tesztek legyen meg előbb, mint a kód Automatikus biztonságos refaktoring


28

10/4/2012

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

10/4/2012

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

10/4/2012

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

31

10/4/2012

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

32

10/4/2012

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

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

10/4/2012

MSF kulcs elemei

Csapat modell

Folyamat modell minıség

funkciók - Project Management Discipline - Risk Managament Discipline - Readiness Management Discipline

Kockázat kezelés


MSF csapat modell Kereteken belül

Program Management

elégedett megrendelő

Product Management

fejlesztés a specifikáció szerint

Development

kommunikáció

User Experience felhasználói hatékonyság

Test minőségbiztosítás

Független és együttműködő szerepek Mindenki saját küldetéssel és szereppel rendelkezik Egyenrangú szerepek Nem 6 ember !

Release Management telepítés és karbantartás


34

10/4/2012

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

10/4/2012

Development

Specifikáció szerinti megvalósítás Segítenek

Tervezés Rendszer

a specifikáció elkészítésében is

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

Testing

Minőségi jellemzők meghatározása Ellenőrzése Tesztelési tervek, … Automatikus tesztelés megtervezése


36

10/4/2012

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

10/4/2012

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

10/4/2012

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

Scope Complete

Vision/Scope Approved

Project Plans Approved Cserkúti Péter, BME - AAIT

39

10/4/2012

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

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

40

10/4/2012

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

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ú

Melyik release-be milyen feature kerüljön Release határidők

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

10/4/2012

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

10/4/2012

Vizionálás fázis (termék elképzelés) 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

Termékelképzelés elfogadva

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 Cserkúti Péter,BME - AAIT Kockázatok nagyjából ismertek

Belső mérföldkövek Csapat felállítása Termékelképzelés dokumentum tervezet Kockázatértékelő dokumentum v1

Termékelképzelés elfogadva


43

10/4/2012


Project definíciós dokumentum üzleti igények projekt célok

siker mérőszámok

kockázatok

projekt teljesítés

szerepek, felelősségek

feltételezések kivételek

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


44

10/4/2012

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 ?



Kockázat menedzsment 1. azonosítás

nuugdíjas kockázatok

leírás

5. kontrol

2. elemzés

kockázat értékelı dokumentum

3. terv

Top 10

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

10/4/2012

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

Projekt tervek elfogadva Tervezés

A megvalósítandó funkciók listája Ez alapján időbecsülhetünk Cserkúti Péter, BME - AAIT

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

10/4/2012

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

Terjedelem teljes

Eredmény Forráskód Futtatható fájlok, binárisok Telepítő Fejlesztés Megvalósított funkciók listája – befagyasztva (nincs több új funkció) Teszt esetek meghatározása


47

10/4/2012

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

Kiadás

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

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

48

10/4/2012


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

Pre-production test complete User acceptance test complete Pilot complete

Kiadás

Ez megy majd ki a pilot group-oknak


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

10/4/2012


Szükséges háttérszoftverek, keretrendszerek feltelepítve Termék feltelepítve

Telepített verzió stabil

Ekkor még lehetnek felhasználói visszajelzések problémákról 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) Cserkúti Péter, BME - AAIT

Informatikai projektmenedzsment – gyakorlati módszerek


50

10/4/2012

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

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

10/4/2012

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

Kis projekt

Egyszeri kódgenerálás

Nagy projekt

Terv csak papíron esetleg Wordben

Projekt

Nincs terv, csak kód

Inkrementális kódgenerálás, szinkron

Nagyon nagy projekt

MDA Cserkúti Péter, BME - AAIT

52

10/4/2012

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

10/4/2012

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

10/4/2012

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

10/4/2012


Napi munkafázisok – fejlesztés Develop

Készül az új kód A fejlesztő dolgozik a saját gépén

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

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

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


(fejlesztés)



56

10/4/2012

Napi munkafázisok – build


Build aktuális állapot

napi build

Build (elkészítés)

Check-in

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

(fejlesztés)



Napi munkafázisok – tesztelés


Test aktuális állapot

napi build


A termék aktuális állapotának összevetése a követelményekkel általános elvárásokkal

Check-in

Test

(beadás)

(tesztelés)


(fejlesztés)


hibák, visszajelzések

A visszajelzéseket rögzítjük


57

10/4/2012


Visszacsatolás aktuális állapot

napi build


Check-in

Test

(beadás)

(tesztelés)

(fejleszté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

napi build


Check-in

Test

(beadás)

(tesztelés)


(fejlesztés)


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



58

10/4/2012

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

10/4/2012

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

10/4/2012

Az elkészült kód beadása


Check-in aktuális állapot

napi build


Check-in

Test

(beadás)

(tesztelé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ó!


(fejlesztés)




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

10/4/2012


A termék megépítése Build aktuális állapot

(elkészítés)

Check-in

Test

(beadás)

(tesztelés)


(fejlesztés)


napi build

Build

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



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

10/4/2012

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

10/4/2012

A kiadások verziói

A termék verziószáma mindig tartalmazza a buildszá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 Cserkúti Péter, BME - AAIT

1.

Mindig kérdezd meg: Mit akarok mindenképpen elérni? Mit tudok tenni, hogy a projekt úton maradjon?

2.

3.

4. 5. 6.

Minden munka ami nem javítja a terméket, kidobott idő A projekt vezetés feladata az akadályok elhárítása a fejlesztők elől Hibajavítás azonnal ! Minden szabály legyen csak útmutatás Mindig a valódi problémán kell dolgozni Cserkúti Péter, BME - AAIT

64

10/4/2012

8.

9.

10. 11. 12. 13.

14.

15.

16.

17.

18. 19.

Sose vállalj olyan határidőt, amit tudod, hogy nem tudsz teljesíteni Ne hagyd, hogy a megfelelni vágyás veszélyeztesse a projektet Ha Te vagy a felelős akkor viselkedj úgy Nincs 10 perces feature vagy bugfix Csak olyan riportot kérj, ami megéri a fáradtságot Post-mortem elemzésből nagyon sokat lehet tanulni, csapatot építeni Tervezd úgy a megbeszéléseket, hogy megérje őket megtartani Cserkúti Péter, BME - AAIT

A megbeszélés előtt tudd, hogy mit akarsz elérni és ahhoz mi kell – majd érd el! Ne hagyd, hogy az időterv irányítsa a projektet vagy demoralizálja a csapatot Legyen az időterv elég agresszív a fókuszhoz, de teljesíthető Néhány havonta mindenki tanuljon meg valami újat Amint tudod, hogy baj van, rögtön cselekedj ! Cserkúti Péter, BME - AAIT

65

10/4/2012

22.

23.

24. 25. 26.

27.

Biztosítsd, hogy mindenki tudja, milyen nagyon nagyon nehéz bug mentes kódot írni Ha valaki azt mondja, hogy nem lehet, biztosan téved – csak akarni kell Feature-t akkor szállíts, ha minőségi Mindenki úgy nézze a terméket mint a végfelhasználó A közösen felhasználható kód élvezzen némi prioritást (erőforrás!) Ha a projekt csúszik akkor valami gond van. Nem (csak) többet kell dolgozni, hanem meg kell találni az okokat. Cserkúti Péter, BME - AAIT

28. 29. 30. 31. 32.

A több munka nem jelent jobb produktivitást A hétvége a családé! Gondolkozz többet, dolgozz kevesebbet! A vezetők a csapat tagja, nem felsőbbrendűek Csak az nem hibázik, aki nem dolgozik


66

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

Recommend Documents