Integrált információs rendszerek - Projektmenedzsment jegyzet 2007 forrásának megtekintése

==Mintakérdések==
Néhány, utolsó órán elhangzott mintakérdés a témában.

* Mi egy projekt?
* Időbecslés hogyan...
* Kockázatkezelés
* Fejlesztési folyamat

==Jegyzet==
'''Begépeltem a 2007 őszi félévének utolsó négy előadásáról készült szkennelt jegyzetet. Csak gépelés, helyesírási és egyéb hibák sem lettek átnézve, strukturálni is lehetne, de holnap vizsga, így kevés az idő rá. Az olvashatatlan részeket dollárjellel jelöltem.'''  -- [[KarakoMiklos|palacsint]] - 2008.01.07.

* Projektirodák ahol a projekteket gyűjtik - ki mire vágyik és miért szeretné azt a projektet megvalósítani
* felmérési fázis
** interjúk
** ami le van írva, írásos, azzal lehet mit kezdeni
** a szónak kérnek írásos megerősítést - mindent írásban
* milyen kommunikációt vár el, milyen biztonsági$ megoldások
** az adatvédelmi biztosra és törvényekre is hivatkozik az ajánlatkérés

==Bevezetés==
* miért akarjuk megvalósítani - mit azok a stratégiai célok
* belehelyezi a környezetébe a projektet
* hivatkozza a tekintetendő$ jogszabályokat
** 1,5-3 oldal, mert döntéshozó vezetők eddig jutnak el
** 2 oldal - jól összefoglalni amivel el lehet érni, hogy mellénk álljanak
==Terminológia==
* módosítási igény
* tesztelés
* ki mit ért ezek alatt
==Projektflow==
* ez még nem a specifikáció
* legmagasabb szintű követelmények
* egy blokkábrát mindenki megér, látni lehet, ki honnan kap adatot

ábra:
* Projekt Felügyelő Bizottság: pénzről dönt, legfelsőbb vezetői szintről kerülnek ide emberek
* Projektvezetés: operatív
* Szervezők: 
** valamikor kapcsolatban voltak a fejlesztéssel
** ők dokumentálnak, és vannak kapcsolatban a vezetéssel
** nekik van szüksége az iparágban eltöltött hosszú időre (évekre)
* Fejlesztők

(2. oldal)
Hozzánk tartozó felelősségek körbekerítése
* muszáj lerögzíteni, mert különben folyton ránk mutogatnak
* "mi csak ezzel és ezzel foglalkozhatunk"
* minél szigorúbban és sokáig jól gondolkozzunk ezen
* dobozos szoftver szállításakor is
** mik azok amikkel mi foglalkozunk?
* Amikor valaki módosítást akar kérni kész rendszerrel kapcsolatban
** szigorú szabályokat fektetni, amik mellett kérhet módosítást
* Az ügyfélnek sürgős minden, ami ezt tereljük normális mederbe
** sok-sok oldalon keresztül

Projekt mérföldkövek - határidővel együtt - hozzárendelt pénzösszeg

==Tervezés==
* a munkának ez a jelentős része
* Az elvégzett munka itt 30-40%
* költségben is legyen ennyi
* Prototípus: 20%
* Fejlesztés: 20%
* Tesztelés: 20%
* Átadás: 10%

* Tervezés: általában itt kell küzdeni, láttatni kell az ügyféllel, hogy a papírokkal nagyon sok munka van. 

==Projektszervezet==
* Célszerű lerajzolni az embereknek
* kik foglalkoznak a szervezéssel, fejlesztéssel, hardverrel

==Kommunikáció==
* havi, mérföldkő utáni beszámoló
** mit csináltunk, milyen nehézség volt, csúszunk-e, miért, jó volt
* a papírmunka
* Mindenkinek tudnia kell egy projekt hogyan halad előre.

==Kockázatkezelés==
* pozitív-negatív kockázat
** pozitív kockázat: amivel le lehet rövidíteni a fejlesztést
* kockázatkezelés az ügyfélnek
** olyanokat írok le, ami az ügyfélviszonyt érinti
*** pl.: jogszabálykörnyezet változásai, új igények, változtatás
** Az ügyfélnek is dolgozni kell, sok! Abból indul ki, ő fizet, mi mindent megcsinálunk. Nem!
** Ha azt látjuk, hoyg az ügyfélnél nincs elég erőforrás a projektre fordítva meg mondani a vezetésnek, ha ő nem tesztel, akkor nem tudunk fejleszteni, mással kell foglalkoznunk.
** Az ügyfelet a tervezés minden fázisába vonjuk be.
*** a tervezéstől a tesztelésig
*** ültessük oda, vele együtt történjen a tervezés
** Előre megmondjuk az ügyfélnek, hogy mi nem csak egy projekttel foglalkozunk, nincs arra mód, hogy az ember teljes idejében foglalkozzon, más projekteket kell csinálni, és ha éppen $$$ nem tud mást csinálni
** Csapatépítés egy hétvégén a projekt elején! Vannak csapatépítő cégek. Értelme az, hogy az emberek megismerjék egymást egy más környezetben.
** Ha egy olyan csapat épül, ami ütőképes már megérte.
** Fejlesztési szinten ne pénzről beszéljenek, fejlesztési szinten szerződésről $
** Jöjjenek elő a technológiai kérdések
** Ki kell kényszeríteni a cégektől, hogy tényleg jöjjön el egy-két ember az ügyféltől, különben nincs meg a szükséges kontroll - csak így lehet fejleszteni.

==Feltételek==
* Akkor vállaljuk időre, ha egy dokumentumot x napon belül elbírálnak.
* Mindenféle feltételek
* ha tesztelésre átadunk, akkor megfelelő tudású/képzettségű embereket biztosítsanak
* A rajtam kívülálló problémákat egymással megoldják, én azt várom, hogy hozzám már valami viszonylag végleges kerüljön követelményként

=Fejlesztési módszertanok=
=Projektvezetési módszertan=

==Rendszerüzemeltetési módszertan==
* Arra törekszünk, hogy mi vigyük tovább az üzemeltetést, hogy ne fordítsunk hátat az ügyfélnek
* ár becslése (üzemeltetési ár)
* milyen terül$$ ilyen típusú szakember kell
* 20% évente pl (eredeti ár 20%-a)
* garancia a szerződésben van leírva - szavatosság más, jogász kell
** 1 év
** 5 év garancia, de csak akkor, ha más nem nyúl hozzá
** lefagy a rendszer kéthetente - a hiba kinyomozása a supportban benne van
*** ha nem a szoftver hibája, akkor kifizettetjük vele a nyomozás költségét
* Minden újfajta szerződést jó ha megnézi vagy több jogász külön-külön.
* Szépen kikötni, hogy a szoftver hibájából eredő következményes kár nincs benne
** jogászok fontosak

* Dokumentálás
** elnevezési szabályok
** Microsoft Sharepoint (vagy más hely, ahonnan mindenki elérheti a doksikat, legyen rendezett, stb.)
** külön emberek - ők tartsák rendben a doksikat
*** 30 fős csapat: biztos kell ilyen

* Eszközök - milyen PowerPointot, Excelt, stb-t használ mindenki
** mindet le kell írni! szigorú$, buta bürokratikus$ szabályokkal, ez erősen védi a projektet

* Mindig van projektváltoztatás. Lényeg, hogy az átadáskor olyan legyen, amit az ügyél szeret.
** Módosítás: ami nem strukturál át semmit
** Változtatás: az eredeti projektterjedelem változik

* Két része:
** Milyen hatással van a projekt egészére: megvizsgálni, beárazni
*** ha jóváhagyjuk, akkor milyen feltételekkel tudjunk elfogadni
** alátámasztjuk, javaslatokat adunk
*** fejlesztés

==Átadás==
* Dokumentumok megvitatása$, elfogadtatása
* oktatás
* szoftver átadása
** tesztterv: el kell fogadtatni
** minden teszt megismételhető legyen: valamikor 1 hónap eltelik, szétszedték$ már a tesztkörnyezetet
*** ezért kell nagyon jól meghatározni a tesztkörnyezetet$
** tesztesetek be és kilépő kritériumait mind leírni
** Nagyon jó szakmai tapasztalattal rendelkező embereket kell magunk köré gyűjtenünk.
** Szerződés körülbástyázása ismeretlen rendszer esetén.

=2007. 12. 11=
* Hibáról értesítés pillanatában tilos becslést adni a hiba kijavításának idejéről.
* Üzemeltetői szervezet - nekik jelentsék be a hibát.
** Itt kell kitölteni a hibajelentő lapot, ez a szervezet szűr, hogy ne a fejlesztőnek kelljen mindennel foglalkoznia.

* Külső minőségbiztosító
** Nem kell értenie a rendszert, sem a követelményeket
** csak a doksikat nézi, a fejlesztés hogy zajlik, a módszertan szerint-e, megfelel-e a követelményeknek

* WBS
** a projekt terjedelmét/méretét felbontja kis részekre, 1-2 hetes feladatcsomagokra

(itt volt vmi krupmlis ábra)
Specifikálás -> tervezés -> fejlesztés -> teszt/megnézés -> fejlesztés -> teszt -> fejlesztés -> teszt/megnézés -> oktatás, éles teszt/integrációs teszt, dokumentációk

* A ki nem mondott kimondottá kellene tenni!

* Az ügyfél vegyen meg piacon kapható teszteszközöket
* Üzemeltetési dokumentáción a rendszer életben tartásához szükséges rendszeres / nem rendszeres tevékenységek
* hogy kell új felhasználót felvenni, milyen logokat kell olvasni

* Ha log van, nagyon jó.
* Fejlesztői dokumentáció: védjük ki azt, hogy a megrendelőnek oda kelljen adni
* Minden bonyolult rendszert fel lehet osztani, fel kell bontani apró részekre.
** Minden projekt fejlesztésnek ugyanazok a lépései.

* Projekttervező: g$$$ diagram
** kritikus út
** a többivel van kis játékterünk

* Költségoldalon az árban a ráfordított erőforrásmennyiségének meg kell jelennie.

==Költségvetés==
* elején: -50%/+100 (2-szeres szorzó mindkét irányban)
* projekt során pontosodik: +/- 15%, +/- 25%
* részletekből induló becslés: bottom-up
* Két típus:
** ráfordítás alapú 
*** Nekünk sokkal jobb: általában csak konzulensként
** fix áras
*** kockázati tartalék kell: +15-25%
**** mennyire komplex, sok rendszer?
**** van már tapasztalatunk? volt már ez az ügyfél?
* Napidíj: sem alsó, sem felső határon nem lepődnek meg
** néhány éves tapasztalat: 2x
** bankipar: 2x
* rendszertervező: 2x
* senior konzulensek az iparágban: 2x: ő az, aki ha dolgozik 1 órát, akkor tud már olyat mondani, amin más két hétig gondolkodik
* szumma: 16x

=utolsó előadás=
Költségbecslés, kommunikáció, kockázatkezelés
* kutatások, a szoftverprojektek hány százaléka sikeres
* trendek
** figyelni, mikor miben gondolkodnak az ügyfelek
*** régen: 
**** CRM
**** adattárház, vállalatirányítási rendszerek
** közigazgatási jellegű ismeretek
** minden figyelni milyen irányban érdemes tudást szerezni

* Becslés: bottom-up: ez a legpontosabb
* Parametrikus becslés:
** amikor az elején még nem látszik milyen munkacsomagok vannak
** Ft/valami
** múltbeli tapasztalatok alapján
** táblák számából, bemenő paraméterek számából pl.

==Költségfelügyelet==
* Jelentéseket kérnek a projektben dolgozók$$
* tervezett érték, megtermelt érék, tényleges költség
* Hogy áll most? 
** Jól -> ahelyett: még nem lehet megmondani, hogy állnak, amíg nem mutattam egy verziót és nem kaptam visszajelzést a megrendelőtől
* Legyen egészen addig 0%, amíg nincs kész
** akkor 50%, amikor az ügyfél már látta, és mondott pár kisebb észrevételt
*** betervezni, hogy megváltozhat

* befejezésig hátralévő becsült költség (Estimate to complete)
* Költségeltérés (Cost Variance = EV - AC)
* Ütemezés eltérés (SV, Schedule Variable  = EV - pV)
* CV + SV: ezekből együtt lehet elszállás
* Kockázati tartalékok!
* Miért kell kimutatni? Hogy lehessen reportot írni, és lehessen akciót hozni$

==Kommunikációs tervezés==
* Milyen doksik, milyen formában? Milyen sűrűn$? Mérföldkövek
* havi reportok - milyen előfeltételek vannak a következőkhöz, akár rendelői oldalról

* Status meetingnél: döntéshozók összehozása azokról, amik nem feltétlenül szakmai kérdések
** Konstruktív együttdolgozás, följebb viszik a problémákat a döntéshozóknak
* Válságmenedzsment
** Minden nap report, előre a következő hét feladatai napról-napra lebontva - overheadet jelent

* Megbeszélések
** felkészülni
** a végén szülessen róla beszámoló
** az emberek fele (az előadók fele) felkészületlenül megy a meetingre, pedig a megfelelő témákról kell, hogy szó essen!
** $$lni kell, milyen kérdéseket akar, hogy megválaszoljanak
** a jó tárgyaló tudja, mik az ő ellene szóló érvek, előre tudni$, mit fognak mondani
** tárgyalástechnika tréningek: a komfortzónán kívül eső témák, legközelebb jobb lesz
** prezentációtechnika
** lejegyezni ki mikor mi mellett állt, ezzel kivédeni lehet dolgokat
*** emlékeztetni rá, hogy két hete azt mondta

Kockázatok
* risk: jó vagy rossz
* annál jobb, minél több kockázatot sikerül előre felmérni
*** azért fog csúszni, mert...
*** ez a fejlesztőeszköz azért nem alkalmas, mert ...
*** humán jellegű kockázatok
* melyeket kell figyelembe venni
* mi a kockázat fellépésen a valószínűsége? milyen hatással lenne

{| border="1"
| bekövetkezési valószínűség || kár || szorzat 
|-
| 10% || x || 0,1x 
|-
| 20% || 4x || 0,8x 
|-
| 10% || 10x || 1,0x 
|}
szumma: 1,9x - ez a kockázatra allokált pénzösszeg

* tenni kellene arról, hogy a kockázati tények ne lépjenek fel
*** hátratoljuk a határidőt arra számítva, hogy tutira bekövetkezik
*** áthárítjuk a kockázatot (pl. a biztosítás is egy kockázatáthárítás)
*** kockázatok káros hatásának csökkentése - megelőző tevékenységekkel
* Kötendő szerződés: mik azok, amiket magunkról át akarunk hárítani

* Kötbér: 
*** csúszáskor minden napért fizetni kell
*** ezt vállalta a fővállalkozó, áthárítja az alvállalkozóra
*** legrosszabb esetben is csak a projektnek a kis részéért, az alvállalkozóra eső része után elfogadni a kötbért

* Szerződésbe
*** A szoftver hibáiból, következmények károkért nem vállalni a felelősséget
*** a leégett számítógépet kifizetem, de azt, hogy addig nem tudott számlázni, azt már nem
* Jogászt kell alkalmazni, hogy képviselje az érdekeinket profin.

==Alvállalkozók kezelése==

Minőségmenedzsment:
* Jó minőségű rendszer: a specifikációhoz képest
* A projekt folyamatának minőségmenedzsmentje
*** ha a folyamat jól megy, akkor a rendszer is jó lehet
* külső cég felügyelheti a fejlesztési folyamatát
* minőségbiztosítások: nem az, hogy jó-e hanem az, hogy mindig ugyanazt kapjuk

Projektzárás
* kritérium: a megrendelő átvegye, aláírja a teljesítési igazolást
* 99% aláírja, ha jó a rendszer, az jól dokumentált
* csak írásban megrendelt rendszer szabad elkészíteni, a vállalattól.
*** tanulságok összegyűjtése: új embereknek is meglegyen a tudás (knowledge experience).

Vállalati kultúra
* anyagiak
* milyen munkát biztosítanak
* milyen a légkör
* felettessel őszintén
* fontos a csapatépítés: informális kapcsolatok a főnökkel
* a főnök azért tart téged, hogy ezt megmondd neki

[[Kategória:Mérnök informatikus MSc]]