Miről lesz szó... Bevezető. Együttműködést támogató eszközök. költségei (erőforrások) meghatározottak. kívánatos jövőbeni állapot

Átírás

1 Projektmenedzsment Miről lesz szó... Általános projektmenedzsment Fejlesztési módszertanok Fejlesztési módszerek Együttműködést támogató eszközök Verzió követő eszközök Albert István BME Automatizálási és Alkalmazott Informatikai Tanszék Bevezető Globalizáció alkalmazkodás, változásmenedzsment Stratégia, stratégiai célok Projektmenedzsment Vezetési dimenziók operatív stratégiai projekt Szervezeti stratégia Stratégia kívánatos jövőbeni állapot döntések kiválasztása eszközök, erőforrások Hierarchikus rendszer Jövőkép célkitűzések (kvalitatív) konkrét célok (vegyes) stratégiai programok és akciók (kvantitatív) Stratégiai elemzés Lehetőségek, irányok, stb. megfogalmazása Külső környezet makrogazdaság Belső adottságok humán, technikai, pénzügyi, stb. gyenge pontok Külső és belső érdekcsoportok elvárásai tulajdonos, fogyasztó, vezető, stb. Feltételrendszer kialakítása Realizálás (projektek) Projekt Projekt minden olyan tevékenység, amely egy szervezet számára olyan egyszeri és komplex feladatot jelent, amelynek teljestési időtartama (kezdés és befejezés) valamint teljesítésének költségei (erőforrások) meghatározottak és egy definiált cél (eredmény) elérésére irányul. 1

2 Projektkarakterisztika cél (eredmény, specifikáció, funkciók) időtartam (kezdet és vég határidők) költségkeret (erőforrások) spec. Projekttipológia Beruházási projektek létesítmény Kutatási és fejlesztési projektek termék, technológia Szellemi szolgáltatási projektek működési körülmények, keret feltételek határidő költségek Külső, belső projektek Projektciklus Előkészítés döntési pont utóelemzés fizikai megvalósítás Szervezeti stratégia előkészítés odaítélés döntési pont Igények Variációk kialakítása Megvalósíthatósági tanulmányok Variáció választás Döntési pont: projektcélok rögzítése döntési pont Odaítélés Projektstratégia (szerződésstratégia) Ajánlati felhívások Ajánlat értékelés Szerződés Döntési pont: az eredményért és a megvalósítás idő- és költség kereteiért való felelősség, kockázat rögzítése Fizikai megvalósítás Tervezés Megvalósítás Tesztelés Üzembehelyezés Próbaüzem Döntési pont: az eredmény műszaki elfogadása (átadás-átvétel) átvétel) 2

3 Utóelemzés Az eredmény illeszkedése a szervezeti stratégiába A megvalósítási folyamat elemzése Projektstratégia Kockázat és felelősség allokálás Szerződéstípus teljesség, minőség, funkcióképesség, időtartam Pénzügyi elszámolás módja költségkockázat Szerződés típusok Tradicionális típusú szerződés résztevékenységek más-más alvállalkozó Kulcsrakész típusú szerződés egyetlen közreműködő viseli a felelősséget Menedzsment típusú szerződés átmenet spec: menedzsmentvállalkozó Elszámolás módja Ár bázisú a projekttulajdonos által fizetett rész előzetesen rögzítésre kerül Átalányár vagy egységárak Merev az inflációval, változásokkal szemben (...) Költség bázisú közvetlen költségek + nyereség Erőteljes projekttulajdonosi résztvétel, konfliktushelyzet Cél bázisú elsődleges célokhoz kötött Közös kockázatvállalás Projektkockázatok Bizonytalanság: a teljesítés kockázatainak forrása operatív működési folyamatok újszerűsége a spec. terjedelmi és tartalmi rögzítése, mértéke az eredményt megvalósító tevékenységfolyamat újszerűsége gazdasági környezet stabilitása infláció Versenyeztetési eljárás Nyílt mindenki Szelektív minősítés szükséges az ajánlattételhez Kétszintű Minősítési anyag + ajánlat Műszaki + kereskedelmi ajánlat Tervezés előtti + megvalósításra adott ajánlat Meghívásos csak meghívottak adnak be ajánlatot 3

4 Projektalakítás Befolyásoló tényezők Funkciók tartalma és száma Egyes funkciók kapacitásjellemzői és minőségkövetelményei Az operatív működést biztosító eszközök, alkotóelemek száma, összetettsége Funkcióstruktúra (hierarchikus kövspec. követelmény jegyzék) Tevékenységstruktúrák Hierarchikus struktúra Fentről lefelé egyszerűbb Lentről felfelé ellenőrzés Ez alapján kilakíthatók a projekt költség- és időkorlátai A tevékenységstruktúra felhasználása Teljesítési tervek Tevékenységek kapcsolata Munkafolyamat interdependenciák Bizonytalansági források, kockázatok Fentiek elemzése -> szervezeti forma Erőforrás szükségletek tervezése Monitoring- és projektkontrollrendszer Projektirányítás információs rendszere Mérföldkövek Külső függések Időterv A tevékenységfolyamatok elemeinek időbeli összefüggései Grafikai megjelenés oszlopdiagramok (sávdiagram) Gantt-diagram LOB (Line of Balance) hálódiagramok tevékenység = nyíl tevékenység = geometriai alakzat 4

5 tevékenység = nyíl Egy csomópont eseményei a befutó nyilak által reprezentált tevékenységek befejezése a kiinduló nyilak tevékenységének elkezdése Minden tevékenység azonosítható egy i-j számpárral (csomópontazonosítók) Sorrendiség és párhuzamosság Nem jeleníti meg az átfedést további bonyolítás CPM, PERT tevékenység = geometriai alakzat A nyilak csak a kapcsolatot fejezik ki Minden tevékenység csak egy szám Sorrend és párhuzamosság Átfedés egyszerűbb MPM Összehasonlítás GANTT tevékenységek események kevésbé (max. mérföldkövek) folyamatos teljesítés CPM események eseményszerű teljesítés időskálázott CPM PERT tevékenységszemléletű valószínűség Erőforrástervezés Beruházási projekt elsősorban materiális erőforrások Kutatási és fejlesztési szellemi erőforrások is Emberi erőforrások szakmai leltárának mátrixa feladat/felelősség mátrix Szakmai leltár mátrix Projekt menedzs- ment Kis G. * Informatika Beszerzés Holló G. * Nagy P. * 5

6 Feladat/felelősség mátrix Projekt-irányítás Felhasználói igények rögzítése Kis G. Nagy P. Holló T. F F K Erőforrástervezési módszerek Időkorlátos az idő kötött korlátlan erőforrások Erőforráskorlátos erőforrások kötöttek az idő mindegy Hardver beszerzés K K Gyakorlatban ezek keveréke, kompromisszumok időterv kritikus útjának rövidítése erőforráskiegyenlítés Időterv kritikus útjának rövidítése Egyfajta időterv optimalizáció Több erőforrás egyszerű, költséges Több párhuzamos rész több erőforrás, rövidebb időre Átfedések növelése terv részletesség Hatékonyság növelése pl: komponensek vásárlása Logikai függőségek újrarendezése Erőforráskiegyenlítés Egyenletesebb erőforrásfelhasználás Nem kritikus tevékenységek csúsztatása Csúcsidőszakokra bérlet alvállalkozásba adás Költségtervezés Általában kétszeres költségek Okai: korai szakasz becsléseinek hibái előre nem látható technikai problémák projektalakítás hiányosságai teljesítés közbeni változtatások a projekt terjedelmében gazdasági és egyéb tényezők Paraméteres költségbecslés Projektindítás korai fázisában Egy korábbi projekttel összevetve Bizonyos paraméterek eltérésével Egyéb tényezők infláció valutaárfolyamok 6

7 Tevékenység alapú költségbecslés Kész a projekt tevékenységi struktúrája Ismert az időterv és erőforrás-szükséglet szükséglet is Tényleges tevékenység költségek Általános terhelés Egységár jól kvantifikálható projekt esetén Tartalékkeret (puffer) A tartalékkeret nagysága arányos legyen a meghatározó kockázatokkal Érintett tevékenységhez rendeljük a puffert A becsült költségeket és a hozzájuk tartozó tartalék keretet külön kell kezelni Tervezési lépések Funkcióstruktúra Tevékenységek meghatározása Logikai kapcsolat, függőségek Erőforrás allokáció Időtartamok beállítása Időterv ábrázolása Költségtervezés Időterv elemzés (kritikus út) Időterv optimalizálás Projekt kontroll, monitoring A megvalósítás (teljesítési szakasz) rendszeres nyomonkövetése, elemzések, korrekciós lépések Változtatások szándékolt eltérés az elsődleges (stratégiai) céloktól Eltérések nem széndékolt, minimalizálás Normarendszer információgyűjtés, elemzés Elvárások Jelezze a normáktól való várható eltéréseket Összhang a szervezettel, rugalmasság Elemzési eredmények jól értelmezhetőek Nem cél a személyi felelősségrevonás Jövőre orientált irányítási rendszer Értekezletek, stb... Projektirányítás szervezeti formái A szervezet alapfunkciója: a tevékenységfolyamatok koordánciója Térbeli, időbeli, szakmai elkülönülés Közvetlen felügyelet standardizált folyamat kevés ismeretlen tényező Közös egyeztetés nem standard folyamat sok bizonytalansági tényező 7

8 Szervezeti megoldások Lineáris-funkcionális A tevékenységeket a funkcionális szervezeti egységek végzik Nincs projektmenedzseri hatáskör koordinátori szerep információs központ Felelősség és hatáskör nincs összhangban Kicsi koordinatív kapacitás standard tevékenységfolyamatok Projekt-orientált orientált Elkülönült szervezeti egység végzi a projekt teljesítését Felelősség és hatáskör azonos szinten Jó koordináció Rossz skálázhatóság Mátrix-szervezet Megosztott hatáskörök: Funkcionális szervezeti egységek teljesítenek hogyan (és ki)? De a projektmenedzsmentnek is van hatásköre mit és mikor(ra)? Sérülékeny de van kohézió Jó koordinációs kapacitás Miről lesz szó... Általános projektmenedzsment Fejlesztési módszer(tan)ok és rendszer architektúrák Informatikai projektek menedzsmentje gyakorlati módszerek Együttműködést támogató eszközök Verzió követő eszközök 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 8

9 Meghatározó tényezők Erőforrások Funkciók Határidő Válassz kettőt! Projekt jellemzők Méret Határidők Állapot 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 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 inkább ajánlás gyűjtemény (pl. MSF) művészet A projektmenedzsment szempontja Most nem arról lesz szó elsősorban, hogy milyen tervezési/fejlesztési módszereket alkalmazzunk, hanem arról, hogy hogyan alkalmazzuk a különböző tervezési/fejlesztési módszereket 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 9

10 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. A megrendelő, menedzser és programozó szerepére, valamint az ezekben a szerepeket végző emberek jogaira és kötelezettségeire helyezi a hangsúly. 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 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, 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

11 Spike solutions Kis technológiai prototípusok a user sztorikban felmerülő problémákra Pontosítja a user sztorikat Nevezési konvenciók Nemcsak változók, osztályok, kisbetű/nagybetű Üzleti objektumok közös elnevezések ne hozzuk létre kétszer ne kelljen megkérdezni mi az 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,...) Iterációs tervek Minden iteráció elején Egy iteráció 1-3 hét hosszú Feladatok, taszkok a fejlesztőknek user sztorik az 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 Projektsebesség Hány user sztori készül el... Drasztikus változás esetén pl. üzembehelyezés release planning Ü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 taskotszabad választani, amennyit az előző iterációban sikerült megcsinálni 11

12 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 White box Regresszió biztonságos refaktoring Stand-up meeting Minden nap Egy közös gyűlés mindenki áll rövid! spontán 12

13 Közös kódtulajdonlás Bárki bármi 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 Tervezés Minden legyen a lehető legegyszerűbb Egyszerű megoldással kell indulni Utána kell újabb funkcionalitást hozzáadni Architektúrálisan stabilnak kell lennie 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ó 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 Osztály tulajdonosok integráció nem feltétlenül kell Egyszerre egy pár integrál (check-in-el) pl. egy dedikált számítógép 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!!! 13

14 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 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 Agile Modeling Hatékony modellezés és dokumentálás nem programozás Kiterjeszti az XP elveit Értékek Elvek Gyakorlati útmutatás AM Értékek Kommunikáció Csoportokon belül (fejlesztő-fejlesztő) fejlesztő) Csoportok között (fejlesztő-tervező) tervező) Csoporton kívül (megbízóval) Egyszerűség Jól értett egyszerű modellek evolúciója Visszacsatolás Az optimizmus egy szakmai ártalom a visszacsatolás gyógymód. Bátorság Döntések meghozatala, ragaszkodás és változtatás Szerénység Mindenki tud olyat, amit Te nem. Kezeljük egymást e szerint. Nincs helye a hiúságnak megbukhat a projekt AM alap elvek 1 Egyszerűség - KISS Nem szabad túlmodellezni, a mindenkori igényeknek kell megfelelni A változások természetesek Változnak a követelmények, azok értelmezése Projekttagok jönnek-mennek itt is ott is Következő verzió Most megfelelni a követelményeknek nem elég a jövőre is gondolni kell AM alap elvek 2 Evolváló modellek Nem kell rögtön a legjobb, legrészletesebb Takarékosság Mintha a saját pénzed volna Céltudatosság Mitől lesz egy model, dokumentum, stb. jó? Hogy a céljának megfelel ezt kell szem előtt tartani. Ezt kell megkérdezni! Több modell A szoftver több aspektusát le kell fedni De nem kell mindig az összeset 14

15 AM alap elvek 3 Minőség Gyors visszacsatolás Minden területen: követelmények, tervezés, fejlesztés Csak annyi, amennyi kell Nem a dokumentumok karbantartása a cél A CÉL minden előtt: a jó szoftver. AM kiegészítő elvek A tartalom többet ér mint a külalak Nem kell mindent dokumentálni, ha megfelel a célnak pl modellek -> forráskód Mindenki tanulhat mindenkitől A változás az informatika istene Ismerd a modelleket és eszközöket Alkalmazkodás Nyitott és őszinte kommunikáció I Can feel them... Bízz a megérzésekben a programozás művészet AM gyakorlati útmutatások 1 Ügyfél aktív bevonása Nem csak projektmenedzsment, felhasználók, helpdesk, admin, stb. Bárki dolgozhat bármin Tesztelhetőség Írd meg a tesztet a program előtt Nyilvánosság A modellek legyenek a falon, stb. A modellezés a megértés útja Együtt kell dolgozni másokkal AM gyakorlati útmutatások 2 Szabványos modell reprezentáció például UML Az átemeneti modelleket dobjuk ki Lusta változtatás 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 RUP 15

16 RUP Rational Unified Process Módszertanok és a fejlesztések pozitív tapasztalatait integráló -- komponens alapú, modellszemléletű, -- Use case vezérelt -- Architectúra centrikus -- Iteratív és inkrementális, -- Folyamatorientált fejlesztési paradigmákat követő filozófia, módszertani keretrendszer. RUP Két dimenzióba szerveződik: idő (iterációk), fejlesztési feladatok (feladatok, aktivitások) Fejlesztési feladatok: követelmények gyűjtése, analízis, tervezés, implementáció, tesztelés Fázisok: kiindulás, részletes kidolgozás, építkezés, átmenet Ha programozás közben még mindig azt akarod megfejteni, hogy milyen is legyen a végtermék, akkor bajban vagy 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 MDD Integráció legacy apps Rugalmas architektúra Alacsonyabb fejlesztési költség Rendszer specifikáció és fejlesztés UML alapján Platform specifikus UML modell származtatás Platform Independent Model Technológia független Üzleti logika, funkcionalitás Nagyon részletes Pre-, post conditions OCL Action Language PIM leképezése PDM-re A PIM leképezése platform függő modellre Eszközök segítségével Automatikusan Akár sokfajta middleware-re A kód nagy részének automatikus generálása 16

17 Integráció SOA Meglévő alkalmazások reverse engineering Abból kód generálás csomagoló kód Híd megoldások átjárás a különböző middleware-ek ek között MSF Projektmenedzsment keret Útmutatás a sikeresebb IT megoldásokhoz: Gyorsabban, Kevesebb emberrel, Kisebb kockázattal Jobb minőségben Elvek, folyamatok, best practice-ek ek gyűjteménye NEM módszertan! Minimális/ideális méret Hibák forrásaií Nem minden projekthez De minden méretre e vannak használható részek Elsősorban nagyobb projektekre 3-12 hónap (leginkább 4-6) 6), minimum 3 (ideálisan ) létszámú csapatban Skálázás: feature team-ekek A cél és funkció eltolódása Az üzlet és a technológia távolsága A közös nyelv és folyamatok hiánya Csapatmunka hiánya Változással foglalkozó folyamat hiánya Megoldás? A bukás oka ritkán technikai. Jim Johnson, The Standish Group Átlagos költségtúllépés: 189% Újrakezdett projektek: 94% Időtúllépés: 222% Szállított funkcionalitás: 61% Standish Group 17

18 Általános jellemzők Key Parts of MSF A csapat minden tagja tudja, hogy mi történik, miért ki a felelős Elosztott kötelezettségek Fő cél: üzleti érték szállítása Befektet a minőségbe Az időket a csapattagok becslik így az idők jobban tarthatók és jobban betartathatók Az időbecslés bottom-up típusú Agilitás: számít a változásokra Tanul a tapasztalatokból Csapat modell Folyamat modell minőség funkciók Kockázat kezelés MSF csapat modell Product Management User Experience felhasználói hatékonyság kényszerek Program Management kommunikáció Release Management telepítés és karbantartás fejlesztés a specifikáció szerint Development Test minőségbiztosítás elégedett megren- delő Független és együttműködő szerepek Mindenki saját küldetéssel és szereppel rendelkezik Megosztott projekt- menedzsment Nem 6 ember! Mért ez a 6 szerep? Kulcs célok az azonosan értékes szerepekhez: Felhasználói elégedettség: Product Manager Időben, jó technológiával: Program Manager Specifikáció szerint: Development Minőség - minden bug ismert: Testing Hatékonyabb felhasználók: User Education Telepítés, karbantartás, támogatás: Logistics Szerep alapú megoldás Egyenrangú szerepek Mindenki feladata, hogy terméket készítsen A szerepkör másodlagos Motiváltság maximalizálása Sör, póló, stb. Mindenki részt vesz a tervezésben is Skálázás Szerepek összevonása, korlátozásokkal Például Product és Program Manager-t, vagy a Developer-t bárkivel Skálázás felfelé (több 1000 ember) : Functional Teams (több ember egy csoportban) Feature Teams (alcsapatok egy feature-höz) 18

19 Product manager Program manager Ügyfél elégedettség Marketing Üzleti értékek képviselete Megoldás szállítása a kereteken belül Pénz, idő, Projektmenedzser Folyamatos ellenőrzés Adminisztratív teendők Mérföldkövek, ütemezés Kozkázatkezelések Development Tesztelés Specifikáció szerinti megvalósítás Fizikai réteg tervezése Becslések Technológia Minőségi jellemzők meghatározása Ellenőrzése Tesztelési tervek, User exprience Release manager Felhasználói hatékonyság növelése Továbbképzés, tréning Használhatóság Többnyelvűség Elérhetőség Gördülékeny szállítás Csomagolás Telepítés, konfigurálás, testreszabás 19

20 MSF folyamat modell Fő elemek a folyamatban Release Readiness Approved Scope Complete Deployment Complete Vision/Scope Approved Project Plans Approved Ügyfél A megrendelő, aki fizet Üzleti értéket kell szállítani Be kell vonni! Felhasználó Aki használja a programot Megoldás solution Teljes: doc,, training, support MSF Mérföldkövek Jellemző mérföldkövek A mérföldkövek felülvizsgáló és szinkronizációs pontok 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 Belső mérföldkövek: a projekt folyamat és az elért eredmények értékelése A leszállítandó közbenső termékek a fizikai bizonyítékai annak, hogy a csapat elérte a mérföldkövet Mérföldkő Termékelképzel és elfogadva Projekttervterv elfogadva Terjedelem teljes Kiadás Elsődleges felelős Termékmenedzsmentenedzsment Programmenedzsmentmenedzsment Fejlesztés és Felhasználói élmény Tesztelés és Logisztikai menedzsment Terjedelem definiálása Kiindulópont Funkciók Projekt definíciós dokumentum Miről szól a projekt Időterv Mikorra mit Felelősség Kommunikációs terv Mikor, mit, honnan... Hogyan, kinek szóljunk: gond, bug, spec. változás (request change), stb. 20

21 1-Vízionálás Mérföldkő: Terjedelem-vízió elfogadva Termékelképzelés Jelzi az egyetértést A projekt céljait és korlátait A lehetőségeket és kockázatokat A projekt struktúráit illetően Elképzelés A projekt okait A kívánt kimenetet A projekt megvalósít- hatóságát Termék- elképzelés elfogadva Belső mérföldkövek Termékelképzelés elfogadva Csapat felállítása Termékelképzelés dokumentum tervezet Kockázatértékelő dokumentum v1 Termékek Aktuális infrastruktúra állapota Funkció javaslatok Projekt struktúra Kockázat menedzsment dokumentum Terjedelem-vízió dokumentum Project definíciós dokumentum Időterv 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 Mért csináljuk Honnan tudjuk, hogy sikeresek vagyunk Kinek kell segítség Feltételezések, függőségek Kockázatok 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?) projekt kompromiszszumok 21

22 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 nuugdíjas kockázatok leírás 5. kontrol 2. elemzés kockázat értékelő dokumentum Top figyelés 3. terv 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. Projektterv elfogadva 2-Tervezés Mérföldkő: Projekt terv elfogadva Jelzi az egyetértést a Projekt-egyensúlyi egyensúlyi változók Projekt-kockázatokkockázatok Ki? Mit? Mikor? Hogyan? tekintetében Projektterv elfogadva Tervezés Belső mérföldkövek Termékek Projektterv elfogadva Követelmény-specifikáció és Használatieset-leírások leírások tervezet Mester projektterv tervezet Szakmai tervek tervezet Rendelkezésre állás Mentés-visszaállítás Pénzügyi terv Kapacitás terv Kommunikációs terv Telepítési terv Fejlesztési terv Végfelhasználó támogatási terv Projekt terv Funkcionális spec. Migrációs terv Monitorozási terv Karbantartási terv Teljesítmény terv Pilot tervek Beszerzési terv Biztonsági terv Tesztelési terv Tréning terv 22

23 MSF Application Model Design Process Overview felhasználói réteg üzleti réteg Application 1 Application 2 koncepciók esetek logikai terv objektumok, felhasználói felület logikai adatbázis fizikai terv komponensek fizikai adatbázis adat réteg Terjedelem teljes Jelzi az egyetértést a Tervezett funkciók (szakmai tervek) 3-Fejlesztés Tervezett funkciók fejlesztése Felhasználói dokumentáció Terjedelem teljes Mérföldkő: Terjedelem kész Stabilizációs folyamat indíthatósága kérdésekben Fejlesztés Belső mérföldkövek Termékek n. belső kiadás... belső kiadás 2. belső kiadás 1. belső kiadás Terjedelem teljes Termék Telepítővel Konfigurációval Dokumentációval Tesztelési tervek kidolgozása Tesztesetek felvétele Tesztelés és bug riport Audit 23

24 4-Stabilizáció Mérföldkő: Kiadhatóság Kiadás mérföldkő Jelzi az egyetértést a Stabilizálás 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ás Belső mérföldkövek Stabilizáció Kibocsátásra előkészített kiadás Nulla-programhiba kiadás Programhiba konvergencia Arany kiadás Kiadás Aláírás Tesztelés specifikációja A stabilizáció szakaszba lépés jelzi az átmenetet az ütemezés-vezérelt fókuszból a szállítás-vezérelt fókuszba Termékek Telepítés a megrendelőnél Beálltás, testreszabás 5-Telepítés Mérföldkő: Telepítés kész Elemzés Záró riport 24

25 Miről lesz szó... Általános projektmenedzsment Fejlesztési módszer(tan)ok és rendszer architektúrák Informatikai projektek menedzsmentje gyakorlati módszerek Együttműködést támogató eszközök Verzió követő eszközök 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! 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 KÓD dokumentált, helyesen működő, tesztelhető, forduló, a tervnek megfelelő, (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 (Visio, XDE) Nagy projekt Inkrementális kódgenerálás, szinkron (STP) Nagyon nagy projekt MDA 25

26 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 Kódgenerálási alapelvek Minták alkalmazása Mennyire legyen okos a generátor? 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 (reverse engineering) Nem válik szét a fejlesztő és a tervező Sérül: a terv a elsődleges példány (baj?) Nincs master példány A módosítások követése nehéz Felelősség (kövspec.) 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 Inkrementális kódgenerálás STP, 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 A generált kód fejlesztési alapelvei 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) 26

27 Napi munkafázisok fejlesztés Develop KÓD dokumentált, helyesen működő, tesztelhető, forduló, a tervnek megfelelő, módosított és új kód módosított és új követelmények Develop (fejlesztés) Specify (specifikálás) Készül az új kód A fejlesztő dolgozik a saját gépén 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őkezelő szabályok 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, vissza- jelzé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 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 27

28 A napi ciklus A teljes kép 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 csapat tagjai konkurrensen hajtják végre az egyes fázisokat A forrásfa A forráskód a rendszer komponensienek megfelelő irányított gráf A levélelemek tartalmazzák az egyes komponensek forráskódját Hogyan építsük fel a forrásfát? Legyen benne minden, ami a termék elkészítéséhez kell Forráskód + eszközök = termék (ez a build környezet) A dokumentumoknak is a forráskód követő rendszerben a helyük Ne szennyezzük a fordítás során előálló fájlokkal Minden egyes ágnak gazdája kell, hogy legyen Az eszközöket célszerű külön, több projekt számára közös ágban elhelyezni Példa forrásfa szerkezet d:\sources \foo \binary_release \x86 \specs \src \feature1 \feature2 \testsrc \bvt \feature1 \feature2 \tools Külső függőségek Amikor egy másik csapat vagy projekt eredményeit kell felhasználnunk Microsoft komponensek ActiveX kontrollok A forrásfa meghatározott részére kerül a másik projekt bináris-fájának egy része Követelmények az átadott binárisokkal szemben: Binárisok és teljes debug info (PDB) az összes támogatott platformra Forrásfa házirend Meghatározza, hogy milyen szabályok szerint lehet kódot elhelyezni a forrásfában Milyen időközönként Milyen jóváhagyást igényel Milyen minőségi feltételeknek kell eleget tegyen Beadási szabályok (Checkin policy) Adminisztratív eszközökkel betartandó A fejlesztőket oktatni kell Ha nem lehet betartani, elágaztatásra van szükség 28

29 Mikor ágaztassunk el? Ha szükség van rá, mert Inkompatibilis házirend Termék kiadása Új funkciók fejlesztése Ne másoljunk, ha elágaztatás a cél Ha egy ág befagyasztására van szükség Tesztelési okok Termék kiadása Elágaztatás - alapok Promóciós modell Hátrányai: Az adott elágazáshoz tartozó szabályok változnak A fejlesztőknek munkájukat folytonosan át kell helyezni más ágakba V2.0 Új technológia próbaág V1.0 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 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 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ő kezelő nem biztonsági mentésre való! 29

30 A beadás lépései Mások változásainak szinkronizálása Build a fejlesztő gépén Fejlesztői regresszióteszt Kódellenőrzés (code review) Beadás Társ-build (buddy-build) build) Hibanyilvántartás frissítése Beadási levél A termék megépítése 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 Test (tesztelés) hibák, visszajelzések Specify (specifikálás) 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 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 A legfőbenjáróbb bűn A build break A fejlesztő nem ellenőrizte, hogy minden fájlt betett-e e a forráskód-követő követő rendszerbe Mások munkájával inkompatibilis változtatást hajtott végre Jutalma a Buildmeister cím elnyerése Az ő feladata a napi build-ek elkészítése, a build scriptek karbantartása A build szabályainak betartatására A fejlesztői kézikönyv... 30

31 Utó-build Parancsfájlok végrehajtásából áll Batch, perl, stb. Ezeket szintén a forráskód-követő követő rendszerben tároljuk Minden egyes termékre egyedi Eredménye mindaz, ami a termék telepítéséhez és használatához kell Ideális esetben a telepítő CD A postbuild lefutása után következik a termék kiadása A kiadások verziói A termék verziószáma mindig tartalmazza a build-szá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 KÓD dokumentált, helyesen működő, tesztelhető, forduló, a tervnek megfelelő, Tesztelé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) Minőséget nem lehet beletesztelni a szoftverbe A teszt célja: ellenőriz és visszajelez, hogy a szoftver megfelel-e e a kitűzött követelményeknek specifikált működés elvárt teljesítmény üzembiztonság egyéb általános elvárások Tesztek a napi ciklusban Kiadható-e tesztelésre? Fejlesztői regresszióteszt a fejlesztő végzi, még beadás előtt kibírja-e a termék a változást? white box, automatizált Telepítési teszt telepíthető-e? e? Build Verification Test megvannak-e e az alapvető működések ki lehet-e e adni a build-et további tesztelésre? automatizált Tesztek a napi ciklusban Részletes Unit Test az egyes modulok, funkciócsoportok részletes tesztje Regression Test visszajöttek-e e egyszer már kijavított hibák? bugs tend to cluster a baj nem jár egyedül változások átvezetése a forrásfa egyes ágai között 31

32 Tesztek a napi ciklusban a funkcionális követelményeken túlmutató Stress test Megpróbáljuk szétverni a szoftvert Érvénytelen input, óriási adatkészlet, erőforrások mesterséges korlátozása Általában éjszaka fut, reggel debugoljuk a döglött példányokat. Komoly tervezést és infrastruktúrát igényel! Terhelési teszt ha van teljesítmény-kritérium gondos tervezést igényel Tesztek a napi ciklusban hagyományos Ad-hoc teszt játszunk a szoftverrel, és figyeljük, mit csinál (szimuláljuk az egyszerű felhasználót) nem determinisztikus nagyon kell figyelni, hogy reprodukálható legyen legtöbbször kiinduló pont az automatizált tesztekhez A megtalált hibák kezelése Minden hiba, ami valamilyen szempontból nem felel meg a követelményeknek az elvárásoknak Jelentjük. Az összeset. Adatbázisban rögzítjük statisztikák hibák életciklusának követése Egy hiba adatai Rögzítendő azonosító (automatikusan generált egyedi kulcs) tárgy (rövid leírás) szoftver verziószáma konfiguráció oprendszer, hardver, egyéb szoftverkörnyezet a hiba részletes leírása reprodukciós lépések a szükséges csatolt állományok fontossági / súlyossági besorolás (severity/priority) terület / alterület Fontosság Fontosság (priority): milyen fontos megjavítani Pri 4: majd Pri 3: amikor időnk engedi még a termék kiadása előtt Pri 2: még ebben a szakaszban Pri 1: most Pri 0: azonnal Pri 0 HOT: már kész kéne, hogy legyen áll a vezér gépe Súlyosság Mekkora galibát okoz? Sev 4: nem szép Sev 3: kicsit zavar a működésben, elkerülhető Sev 2: komolyabb hiba, hiányosság Sev 1: adatvesztés, összeomlás, súlyos hiba valamilyen szempontból használhatatlanná teszi a terméket 32

33 Kategóriák A hiba életciklusa Súlyosság fontosság de nem automatikusan Pri 1, Sev 4: Micorosoft Office XP Pri 4, Sev 1: a teszter otthoni XT-jén letörli a FAT-táblát, ha a program indításával egyidejűen dugja be a mentéshez használt VHS- videomagnót. Aktív A hiba gazdája aki az adott hibával foglalkozik az életciklus minden stádiumában létezik egyéni vagy csoport A hiba életciklusa Megoldási módok Aktív megoldás Megoldott A megoldás visszaküldi a hibát ahhoz, aki megnyitotta Feladat: ellenőrizni a megoldást Javítva Megoldás Elhalasztva (kockázatkezelés) Nem javítjuk (alapvető probléma, erőforráshiány) Így terveztük It s not a bug, it s a feature Már létező hiba (duplikált) Ki teheti Fejlesztő Program-menedzsermenedzser Program-menedzsermenedzser Program-menedzsermenedzser Fejlesztő Tesztelő További teendő ellenőrizni dokumentálni későbbi követelmény dokumentálni végfelhasználói dokumentáció, ha szükséges megadni az eredeti hiba azonosítóját Nem reprodukálható ált. fejlesztő A hiba életciklusa A hiba életciklusa Aktív Megoldott Lezárás ha a hiba gazdája elégedett a javítással Aktív reaktiválás Megoldott Lezárás ha a hiba gazdája elégedett a javítással Reaktiválás ha elégedetlen Lezárt lezárás Lezárt 33

34 A hiba életciklusa Aktív reaktiválás Lezárt Megoldott Lezárás ha a hiba gazdája elégedett a javítással Reaktiválás ha elégedetlen Lezárt hiba is reaktiválható regressziós teszt további ellenőrzés során Mire használjuk az adatbázist? Aktív hibák: megoldjuk Megoldott hibák: megnyitóik ellenőrzik Lezárt hibák: elhalasztott, nem javítandó: dokumentáljuk javított: bevesszük a tesztekbe regressziós teszt unit teszt Összességében: statisztikák Statisztikák Új hibák beérkezési sebessége Hibamegoldási sebesség javítási sebesség: tervezhető, kb. 2/fejlesztő/nap Konvergencia amikor többet oldunk meg, mint ahányat találunk a stabilizáció kezdete Statisztikák Jóslás Mikor lesz kész a szoftver? aktív hibák számának csökkenő trendje adja meg Kiadási stádiumok konvergencia Nulla aktív hiba ZBB: zero bug bounce RC Gold Kiadás Példa Tesztek típusai konvergencia ZBB Coverage testing (ideális célok) A A termék összes funkcióját teszteli A A termék minden kódsorát teszteli Elsősorban a fejlesztési fázisban használatos Usage testing Tipikus feladatok végrehajtása Tesztelés az éles környezetben Elsősorban a stabilizációs fázisban Átadás átvételi teszt A A rendszer megfelel-e e a specifikációnak Felhasználó résztvételével 34

35 Automatizálás Többrétegű alkalmazás esetén érdemes rétegenként, komponensenként teszteket készíteni Minimálisan Megbízható Mag A teszt tesztje... Teszt adatbázis tesztadatok! Teszt keretrendszerek NUnit (junit-ból), cstest, harnessit, x- unity szerelvény alapú attribútummal jelölt metódusokat futtatnak több szál VS.NET integrációs ACT: application center test webes alkalmazások sebességtesztje Szinkroniáció KÓD dokumentált, helyesen működő, tesztelhető, forduló, a tervnek megfelelő, Az a legjobb, ha az eszközből lehet generálni metódus fejlécek architektúra ábrák képernyők stb. Miről lesz szó... Általános projektmenedzsment Fejlesztési módszer(tan)ok és rendszer architektúrák Informatikai projektek menedzsmentje gyakorlati módszerek Együttműködést támogató eszközök Verzió követő eszközök 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ő (elég részletes terv!) 3. A projekt vezetés feladata az akadályok elhárítása a fejleszők elől 4. Prioritások és minőségi követelmények 5. Hibajavítás azonnal! 6. Minden szabály legyen csak útmutatás 7. Mindig a valódi problémán kell dolgozni 35

36 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élyztesse 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. Postmortem 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 demorlizálja a csapatot 17. Legyen az időterv elég aggresszív a fókuszhoz, de teljesíthető 18. Bontsd a hosszú projekteket kicsikre 19. Ne tartsd a programozókat egy területen 20. Néhány havonta mindenki tanuljon meg valami újat 21. Amint tudod, hogy baj van, rögtön cselekedj! 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 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 némi élvezzen 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 Miről lesz szó... Általános projektmenedzsment Fejlesztési módszer(tan)ok és rendszer architektúrák Informatikai projektek menedzsmentje gyakorlati módszerek Együttműködést támogató eszközök Verzió követő eszközök Groupware Egy technológia, mely a csoportok munkáját segíti a kommunikáció, együttmûködés, koordináció, problémamegoldás és a tárgyalás területein. telefon is, de most számítógép + hálózat 36

37 Kategóriák Hely \ Idő szinkron aszinkron azonos különböző prezentáció videokonferencia instant messenger megosztott számítógép newsgroup, fórum Az alap technológia: 2 szereplő között plain text üzenetformátum Támogatott protokollok: HTTP, SMTP, IMAP (de facto szabvány), POP, POP3, X.400 (Európa, ITU, több szabvány) Címtár A hálózaton keresztül elérhető erőforrások azonosításához, eléréséhez szükséges adatok tárolásához használják LDAP, X.500 (ITU) szabványok nincs teljesn X.500 kompatibilis rendszer Csoportnaptár kooperáció és koordináció támogatás scheduling: megosztott erõforrások allokálása, lefoglalása (projektor, tárgyaló, stb.) projektmenedzsment (határidők, stb) FONTOS: személyes adatok védelme Newsgroupok, levelezési listák NNTP szabvány newsgroup: a felhasználó akkor kapja meg az üzenetet, ha lekéri Workflow Workflow rendszerekben a dokumentumok egy elõre definiált folyamat keretén belül vándorolnak a szervezeten (vállalaton) belül. információ elõállítás routolása formok létrehozása szerepek és privilégiumok 37

38 Dokumentumkezelés Verzionálás Sok formátum Közös szerkesztés Keresés (indexelés) Több nézet Archiválás Instant Messaging valósidejû kommunikáció fontos lehet az anonimitás ICQ, AIM, MSN, Y!, IRC, MSN, Lotus SameTime (intranetes),... Miről lesz szó... Általános projektmenedzsment Fejlesztési módszer(tan)ok és rendszer architektúrák Informatikai projektek menedzsmentje gyakorlati módszerek Együttműködést támogató eszközök Verzió követő eszközök Forráskód követő rendszerek célja Közös munka Munka ne vesszen el Lehetőség tesztelésre (próbaágak) kiadási verzió rögzítésére) stb. Verziókövetés Elágazások tesztelés új verzió Összevonások bugfix Feliratozás kiadott termékek visszakeresése Rendszerek MSVSS Perforce ClearCase CVS Minden eszköz annyira jó, ahogy használod... 38