ELTE Programtervező matematikus szak szoftvertechnológia sáv záróvizsga tételei Bánsághi Anna 2010
Ha hibát találtok, ne habozzatok írni: bansaghi kukac inf pont elte pont hu
Tartalom 1. tétel Követelmények és tervezés Szoftverfejlesztési folyamatmodellek . . . Vízesés folyamatmodell . . . . . . . Evolúciós folyamatmodell . . . . . . Formális folyamatmodell . . . . . . Komponens alapú folyamatmodell . Inkrementális folyamatmodell . . . Spirális folyamatmodell . . . . . . . A szoftverfejlesztés fő folyamatai . . . . Specifikáció (követelmény-tervezés) Tervezés/implementáció . . . . . . . 2. tétel Szoftverarchitektúrák Szoftverarchitekúra tervezése . Szoftverarchitektúra modellek . Vezérlési modellek . . . . . Adatközpontú modellek . . Többprocesszoros modellek Virtuális gép modell . . . . Objektumorientált modell .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
4 4 4 5 6 6 7 7 8 8 9
. . . . . . .
11 11 12 12 12 13 13 13
3. tétel Minőségbiztosítás és tesztelés A minőségbiztosítás alapfogalmai . A szoftverminőség megközelítései . Termék alapú modellek . . . . Folyamat alapú modellek . . . Szoftvertesztelés . . . . . . . . . . . A tesztelés alapelvei, típusai és Teszttervezési technikák . . . . Tesztmenedzsment . . . . . . . Teszteszközök . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . szintjei . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
14 14 15 15 15 16 17 17 18 18
4. tétel Alkalmazásfejlesztés Webes technológia . . . . . . . . . Kliens-szerver architektúra . . Alkalmazás platform . . . . . Alkalmazások . . . . . . . . . . . . Fejlesztőeszközök . . . . . . . . . . Projektmenedzsment eszközök Követelménykezelő eszközök . Keretrendszerek . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
19 19 19 20 20 22 22 23 23
5. tétel Projektirányítás A projektirányítás alapfogalmai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projekttervezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24 24 24
. . . . . . . .
. . . . . . . .
2
. . . . . . . .
. . . . . . . .
Feladatlebontási struktúra . . Szervezetlebontási struktúra . Tevékenységek hálóterve . . . Gantt diagram ütemezéssel . . Gantt diagram erőforrásokkal Költségvetés . . . . . . . . . . Projektkövetés . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Irodalom
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
24 25 25 25 26 26 26 27
3
1. tétel
Követelmények és tervezés Vesse össze a szoftverfejlesztés különböző folyamatmodelljeit! Részletezze a követelményelemzés és tervezés folyamatait!
Szoftverfejlesztési folyamatmodellek A szoftvertervezés felöleli a szoftver előállításának minden szempontját. Egyrészt a szoftvert, mint terméket tekintjük, és termék alatt a kész programot/rendszert és az azzal összefüggő összes dokumentációt értjük, másrészt a szoftverfolyamatot vizsgáljuk, mely a termék fejlesztésében résztvevő tevékenységeket öleli fel. Ezek az alapvető tevékenységek: • • • •
specifikáció (követelmény-tervezés) tervezés / fejlesztés (implementáció) validáció (tesztelés) evolúció (karbantartás)
Különféle termékekhez/rendszerekhez és eltérő vállalati strukturához más és más szoftverfejlesztési folyamat az ideális, ezért különféle szoftverfejlesztési folyamatmodellek alakultak ki. Valamennyi modell tartalmazza az alapvető tevékenységeket, ám ezeket különféle módon szervezi: célokban, időben, felbontásban eltérőek. A következő modelleket tekintjük át: • Hagyományos modellek – – – –
vízesés evolúciós formális komponens alapú
• Iteratív modellek – inkrementális – spirális
Vízesés folyamatmodell Jellemzők • A szoftverfejlesztés fázisokra bontható, az egyes fázisok jól elkülöníthetők egymástól. • A lefelé nyilak jelzik a fejlesztés irányát, az előző fázis kimenete a következő fázis bemenete. • A fázisokban megadott feladatok elvégzését valamilyen tárgyi eredmény (dokumentáció, program) jelzi. • Csak a szomszédos fázisok között történhet információcsere. • A felfelé nyilak jelzik a módosítások, javítások irányát: ha az integráció során probléma merült fel, akkor először az implementációban keresik a baj okát, ha ott nincs meg, akkor terjed feljebb, a tevezési fázishoz. 4
követelmények elemzése
tervezés
implementáció és egységteszt
integráció és rendszerteszt
működtetés és karbantartás
Előnyök • Ha a követelmények már a kezdet kezdetén tiszták és világosak, akkor nagyon jól használható modell. Hátrányok • Korai fázisokban kell állástfoglalnunk olyan kérdésekben, melyek a gyakorlatban később módosulni, változni szoktak. • Fontos az ütemterv tartása, ez pedig az eredmény minőségének kárára lehet. • A hibajavítás vagy a karbantartás egészen a követelményelemzési fázisig is visszagyűrűzhet.
Evolúciós folyamatmodell
kezdeti verzió
vázlat
specifikálás fejlesztés validálás
közbeeső verziók
végleges verzió
Jellemzők • Kezdeti vázlat a rendszerről, a megrendelő sem tudja pontosan, mit szeretne. • Vagy kevés számú, de jól megfogható követelményből indulunk ki, kísérletező fejlesztés. 5
• Vagy a homályos követelményekből indulunk ki, eldobható prototípust készítve, ezzel tisztázzuk a tényleges követelményeket. • A szoftver/rendszer folyamatosan finomodó és javuló verziók végeredménye. Előnyök • Gyors visszacsatolás az egyes verziók elkészülte után. • A prototípus azonnal használatba vehető. Hátrányok • Nem látható át a fejlesztési folyamat. • Az elkészülő rendszer strukturáltsága egyre rosszabb lesz. • Speciális szoftverfejlesztési eszköz szükséges a verziók és branch-ek karbantartásához.
Formális folyamatmodell
követelmények elemzése
formális specifikáció
formális transzformációk
program
integráció és rendszerteszt
Jellemzők • Ezzel a módszerrel több tárgy foglalkozott a tanulmányaink során: Fóthi Ákos és Horváth Zoltán tárgyai. • Magas biztonságú, megbízhatóságú és védelemi igényű rendszereknél hasznos. Előnyök • Nem kell tesztelni, hiszen a specifikáció finomítása adja végül a programot. Hátrányok • A fejlesztés nem lesz hatékonyabb a formalizmus ellenére sem. • Speciális szaktudású szakemberek szükségesek a formális specifikációk létrehozásához.
Komponens alapú folyamatmodell követelmények elemzése
komponensek elemzése
követelmények módosítása
komponensekből rendszertervezés
fejlesztés és integráció
validáció
Jellemzők • Különböző szintű komponenseket használhatunk: a programkönyvtáraktól kezdve a webszolgáltatásokig. • Egyre bővül ennek a modellnek a használhatósága, ahogy a szabványok fejlődnek. 6
Előnyök • A fejlesztés költsége és kockázata csökkenthető. • Elősegíti a gyors fejlesztést. Hátrányok • Kompromisszumot kell kötnünk a létező komponensek és a vágyaink között. • Az integráció nehézkes.
Inkrementális folyamatmodell
inkremensek fejlesztése
vázlatos követelmények
követelmények meghatározása az inkemensekhez
rendszerarchitekúra tervezése
inkremensek validálása
rendszer validálása
inkremensek integrálása
Jellemzők • • • • •
folyamatiteráció kezelésére alkalmas Általában projektcsapatban történik a fejlesztés. Egy inkrementum nagyjából néhány hét alatt elkészül és átadásra kerül. A legfontosabb funkciókkal kezdünk. Ahogy egy inkremens fejlesztése elkezdődik, befagyasztjuk az ehhez tartozó követelményeket.
Előnyök • Az első néhány inkrementum után már használható a szoftver. • A projekt nem fulladhat teljes egészében kudarcba az előzőek miatt. • A legfontosabb részfeladatok készülnek el a leghamarabb, a rendszer validálása során ezeket teszteljük le a legtöbbször. Hátrányok • Nehéz az inkrementumokra bontás. • Vannak olyan feladatok, melyeket minden inkrementum használ, így van egymásra következés.
Spirális folyamatmodell Jellemzők • • • •
folyamatiteráció kezelésére alkalmas A spirál egy hurka jelképezi a fejlesztés egy fázisát A hurkokat az igényeknek megfelelően alakítjuk ki Négy szektorra bontható egy-egy hurok 7
Előnyök • Ez az egyetlen modell, melybe be van építve a kockázatelemzés. Hátrányok • Nagyfokú szervezeti fegyelem szükséges, hogy megvalósítsuk a spirális modellt.
A szoftverfejlesztés fő folyamatai A szoftverfejlesztés négy alapvető tevékenységét vizsgáljuk meg részletesebben, és így mint a szoftverfejlesztési folyamat négy fő folyamatára hivatkozunk. A követelmény-tervezés és a tervezés/fejlesztés főfolyamatokkal foglalkozunk ebben a tételben részletesen.
Specifikáció (követelmény-tervezés) A követelmény-tervezés célja, hogy meghatározzuk a rendszer szolgáltatásait, megadjuk a fejlesztés és a működtetés megszorításait. A követelmény-tervezés alfolyamatai: • megvalósíthatósági tanulmány készítése magában foglalja a piackutatást, a versenytermékek elemzését. • követelmények feltárása, elemzése iteratív folyamat. A feltárás során a szakterület megismerése a cél, az elemzés során pedig osztályozzuk, rangsoroljuk, ellenőrizzük a követelményeket, sőt szervezeti és szociális tényezők alapján is elemezzük. Eredményeképpen jön létre a rendszermodell, mely több szempont szerint készül, ezek: környezeti, viselkedési, információs és adat szempontok. • követelményspecifikáció elkészítése a specifikáció a rendszermodell egy formális leírása. Ezen a szinten háromféle követelményt különböztetünk meg: – felhasználói követelmények: természetes nyelven 8
– rendszerkövetelmények, azaz a funkcionális specifikáció: ez tartalmazza a funkcionális, a nem funkcionális és a szakterületi követelményeket. A funkcionális követelmények jellemzője, hogy teljesek és ellentmondásmentesek legyenek, a nem funkcionális követelmények vonatkozhatnak a termékre, a szervezetre és külső tényezőkre (jog, törvény). – szoftverterv specifikációja: félformális, formális nyelven • követelményvalidáció a rendszerterv helyességét és elllentmondásmentességét ellenőrizzük, illetve a műszaki és szervezeti megvalósíthatóság feltételeit igazoljuk. Eszközként a felülvizsgálat és a prototípus létrehozása használhatók.
Tervezés/implementáció Különféle témája lehet egy tervnek, így ez alapján csoportosíthatjuk a tervezést: • • • • • •
architekturális tervezés absztrakt specifikáció interfész tervezés komponens tervezés adatszerkezet tervezés algoritmus tervezés
A tervezés alapelvei: • absztrakció • finomítás • modularitás (mérőszámai a kohézió: egy komponensen belüli interakciók mértéke, és a csatolás: a komponensek közötti interakciók mértéke) • kontroll hierarchia (mennyi komponens legyen egy adott komponens alatt: hányan kapcsolódnak hozzá, hányakat kapcsol magához) • információelrejtés A terv
fizikai részletes magasszintű logikai köv.
A jó terv megfelel a funkcionális és nem funkcionális követelményeknek, jó iránymutatója az implementálásnak és a tesztelésnek, valamint az implementáció szemszögéből mutatja a szoftvert. A terv egy kétfázisú iterációs folyamat eredménye. A fázisokban két különböző szintű tervez hozunk létre: • logikai terv megmondja a felhasználónak, hogy a szoftver/rendszer pontosan mit is csinál. Inkább a kövertelményspecifikációhoz kapcsolódik, implementáció független. 9
• fizikai terv tartalmazza a szoftver és a hardver igényeket, melyekkel a probléma megoldható. Megadjuk a fő hardverkomponenseket és azok funkcióit, megadjuk a szoftver komponensek funkcióit és hierarchiáját, és megadjuk az adatszerkezeteket és az adatfolyamokat. A szoftver komponensek funkciói megadásakor különféle dekompozíciós fajtákat alkalmazhatunk: – – – – – –
funkcionális moduláris adatorientált személyorientált outside-in objektumorientált
A két fázis közötti építkezés egy fordított piramissal ábrázolható, lásd a fenti ábrát. A tervezést megkönnyítik a tervezési minták, ezeket nem részletezem. A tervezés nézetei két tengelyre fűzhetők: dinamikus
statikus
külső
interakciók
funkciók
belső
viselkedés
szerkezet
A különféle nézeteket tervezési sablonok segítségével írhatjuk le: • a műveleti sablon a felhasználói interakciók leírására, pl. használati esetekkel vagy UML-ből szekvencia diagrammal • a funkcionális sablon a szoftver funkcióira, ezek működése és kapcsolata más funkciókkal, pl. UML-ből osztálydiagrammal • az állapot specifikációs sablon a rendszer viselkedésére. Az egyes funkciók végrahajtásának állapotátmenet gráfja, pl. workflow-val vagy UML-ből állapotdiagrammal • a logikai specifikációs sablon a funkciók szerkezetére, belső logikájára, pl. pszeudokód, formális nyelv
10
2. tétel
Szoftverarchitektúrák Ismertesse a különféle szoftverarchitektúrákat!
Szoftverarchitekúra tervezése A szoftverarchitektúra a rendszer komponenseinek és a közöttük lévő kapcsolatoknak a leírása. Egy olyan magasszintű terv, amely a rendszer strukturáját több nézetben ábrázolja. A szoftverarchitektúra feladata, hogy a különböző szaktudású szakemberek kommunikációját biztosítsa, a döntéselőkészítést támogassa, valamint az újrafelhasználhatóságot elősegítse. A fő tényezők, melyek befolyásolják a szoftverarchitektúra kialakítását azok a következők: az üzleti és a technológiai döntések, a vállalati környezet és a fejlesztők célja és stratégiája is. A rendszer tervezésére a minőségi elvárások és az elvárt funkcionalitás együttesen hatnak. A tervezés eredményeként alakul ki az architektúra, majd végül az alkalmazás. Az architektúra hatással van a rendszer minőségére, mert az üzleti célok nagyban befolyásolják, hogy melyik architektúrát valósítják meg, és a választott architektúra hatással van a költségekre és a nem funkcionális követelményekre, melyek együttesen adját egy rendszer értékét. Egy szoftverarchitektúra minőségét növelik a következő tényezők: kevés tervező készíti, jól dokumentált, a kialakítás értékelésében minden érintett résztvett, mérhető jellemzőkkel bír és támogatja az inkrementális fejlesztést. A szoftverarchitektúra kialakításának ökölszabályai: • a modularitás: az információelrejtést és az interfészek létrehozását vonja maga után, • az architekturális taktikák alkalmazása: magas rendelkezésreállás a hibák detektálásában, azok javításában, megelőzősében, • egyszerű interakciós minták alkalmazása. Az architektúra kialakításának folyamata: először felvázoljuk a rendszernek megfelelő architektúrális mintát és kiválasztjuk az ennek megfelelő architektúra referencia modellt. A referencia modellt finomítjuk és igazítjuk, így készül el a referencia architektúra, mely alapja lesz a szoftverarchitektúrának. A szoftverarchitektúra tervezése során megválaszolandó kérdések: • • • • •
milyen legyen a rendszer elosztása hogyan bontsuk modulokra a rendszert milyen legyen az alkalmazás vezérlési szerkezete hogyan lehet a különféle architektúrákat összehasonlítani milyen módon dokumentáljuk
A tervezés során a következő konfliktusokkal nézünk szembe: • ha nagy a rendszer, akkor jó a teljesítménye, de a karbantartás nehézzé válik • ha redundáns a rendszer, akkor magas a rendelkezésreállás, de az adatbiztonság csökken • ha biztonságos a rendszer, akkor nő az adatmozgás 11
Szoftverarchitektúra modellek A modelleket többféle szempont szerint lehet osztályozni: a rendszer nézete alapján (vezérlési vagy adatközpontú), a rendszer felépítése alapján, végül megemlítjük a virtuális gép és az objektumorientált modelleket.
Vezérlési modellek Központosított modell Példa
Közlekedésirányításban, logisztikában használt szoftverek
Jellemzők • • • •
a a a a
rendszer elemei között van egy kitüntetett, központi komponens központi komponens felügyeli a többi komponens munkáját központi komponens a rendszer állapota alapján irányítja a többi komponenst többi komponens csak a központi komponenssel van kapcsolatban, egymással nem
Eseményvezérelt modell Példa
Grafikus felhasználói felületek
Jellemzők • a rendszer és a környezete között történik a kommunkáció • a rendszert a környezet által kiváltott külső események vezérlik • az esemény kiváltója nem tudja, mikor dolgozza fel a rendszer a kérését
Adatközpontú modellek Adatfolyam vagy csővezeték modell Példa
Grafikus csővezeték az OpenGL
Jellemzők • • • • • •
a rendszer elemei egy-egy funkciót valósítanak meg a funkciók egy adott sorrendben hajtódnak végre az adatok a rendszer elemei között mozognak kötegelt feldolgozás jól bővíthető a rendszer közös adatátviteli formátum szükséges
Tárolási modell Példa
Mesterséges intelligencia rendszereknél használt tábla (blackboard) modell
Jellemzők • • • •
a rendszer elemei az osztott adatbázis és az azt használó elemek az elemek nagyon egyszerűek az adatbázis és az elemek között üzenetváltások történnek az elemek az adatbázison keresztül kommunikálnak 12
Rétegzett modell Példa
Számítógép hálózatok modellje: az OSI referencia modell
Jellemzők • a szolgáltatások rétegekben szervezett modulokba vannak csoportosítva • a rétegek jól meghatározott interfészeken keresztül kommunikálnak egymással • csak a szomszédos rétegek kommunikálnak
Többprocesszoros modellek Kliens-szerver modell Példa
Vékony vagy vastag kliensek az üzleti alkalmazásokban
Jellemzők • • • • •
a a a a a
kliensektől független szerverek szolgáltatásokat biztosítanak kliensek hálózaton keresztül érik el a szolgáltatásokat kliensek változatosak lehetnek, bonyolult funkciókat valósítanak meg szerverek integrált szolgáltatási felületet biztosítanak a különféle kliensek számára kliensek egymással nem kommunikálnak
Osztott architektúrák Példa
Szolgáltatásorientált architektúra (SOA), CORBA
Jellemzők • • • •
a rendszer elemei akár különböző vállalatok birtokában lehetnek (e-business) az elemek szolgáltatásokat nyújtanak más elemeknek az elemek aszinkron módon, üzenetekkel kommunikálnak üzleti folyamatba szervezett szolgáltatások
Virtuális gép modell Példa
Operációs rendszerek emulációja, Java interpreter
Jellemzők • • • • •
a rétegzett modell általánosítása az operációs rendszer is egy réteg egy operációs rendszer felett több virtuális gép fut egy virtuális gép az operációs rendszeri funkciókat biztosítja a processzusoknak a processzusok illúziója, hogy egyedül használják az operációs rendszer által nyújtott szolgáltatásokat
Objektumorientált modell Példa
Objektumközpontú tervezési minták sokasága
Jellemzők • a rendszer elemei objektumok • az objektumok más objektumok által biztosított szolgáltatásokat vesznek igénybe • magas az újrafelhasználhatóság mértéke
13
3. tétel
Minőségbiztosítás és tesztelés Elemezze a szoftverminőség termék és folyamat alapú megközelítéseit! Sorolja fel és részletezze a szoftvertesztelés elemeit!
A minőségbiztosítás alapfogalmai
Jellemzők
A fogalmak fő kategóriái: szubsztancia (állomány), mennyiség, minőség, viszony, hely, idő, fekvés, bírás (a létezés módja), cselekvés és szenvedés. Mi most a minőségről fogunk beszélni. A minőség definíciója manapság: az előállított termék vagy szolgáltatás azon elemei, melyek hozzájárulnak az ügyfél igényeinek kielégítéséhez. Mérhető az átadandók és az elvárások hányadosával. A szoftverminőség speciálisabb eset, mert a szoftverben mindig vannak hibák, a feladat pedig komplex, így itt meg kell határoznunk az elfogadható hibák arányát. Az idők folyamán több definíció született a szoftver minőségére: kezdetben a szoftvert mint terméket tekintették, később a szoftverterméket előállító folyamatot vizsgálták, majd a felhasználás és az érték alapján minősítették, manapság egy integrált minőségbiztosítási modellt állítanak fel. A minőségügyi keret egy mátrix, melyben a fenti modellek által figyelembe vehető tényezők szerepelnek. Mivel minden szempontot nem tudunk figyelembe venni, ezért kiválogatjuk azokat, melyekre fókuszálni fogunk. A minőségügyi keretből általunk kiválogatott elemek halmazát minőségügyi profilnak nevezzük.
Mérőszám Minőségi attribútum Definíció Objektumok
at
rás
ék rm olyam rőfor Te F E
• A termék alapú modellek a termék jellemzőire fókuszálnak • A folyamat alapú modellek a termék minőségi attribútumait és a folyamat definicióját és minőségi attribútumait tekintik • A fejlesztési, tesztelési módszertanok a folyamat definícióját és az erőforrások jellemzőit tekintik • A mérési módszerek a jellemzők közül a mérőszámokat tekintik
14
Jellemzők
Jellemzők Mérőszám
Mérőszám
Minőségi attribútum
Minőségi attribútum
Definíció
Definíció Objektumok
Objektumok
rás ék rm olyam rőfor Te F E
at rás ék rm olyam rőfor e T F E
(a) Minőségügyi profil: Boehm, McCall
(b) Minőségügyi profil: ISO, CMM, CMMI
at
A szoftverminőség megközelítései Termék alapú modellek A termék alapú modellek a termék minőségügyi jellemzőire és ezek értékének mérésére koncentrálnak. A Boehm és a McCall modellek egyértelmű módon rögzítik a szoftverminőség jellemzőit, megadják a minőségfaktorokat és a felhasználói alapszempontokat. Az ISO/IEC 9126 szabvány pedig megadja a szoftvertermék esetében alkalmazandó minőségi modellt. folyamatminőség
belső minőségi attribútumok
külső minőségi attribútumok
használat közbeni min. attr.
A külső és belső minőségi attribútumok: • • • • • •
funkcionalitás megbízhatóság haszálhatóság hatékonyság karbantarthatóság hordozhatóság
A használat közbeni minőségi attribútumok: • • • •
hatásosság termelékenység biztonság elégedettség
Folyamat alapú modellek A folyamat alapú modellek a szoftvertermék előállításhoz szükséges folyamatok megfelelőségét vizsgálják. Ha garantáljuk a termelési folyamat minőségét, akkor ezen folyamat során létrehozott termék is megfelelő minőségű lesz. Kétféle folyamat alapú modell alakult ki. Az ISO 9001:2000 szabványcsalád egy minőségügyi rendszerben szabályozza a vállalat szabványoknak való megfelelését. Ekkor a vállalat létrehozza saját belső minőségügyi szervezetét, mely megismeri a szabvány ajánlásait és követelményeit, saját tevékenységeire kidolgozza a belső minőségügyi rendszert, majd biztosítja, hogy a vállalat a továbbiakban 15
ezen rendszernek megfeleljen. A tanúsító audit során megfigyelésre kerül, hogy a vállalat minőségügyi rendszere megfelel-e a szabványoknak, illetve hogy a vállalat valóban ezen rendszer szerint működik. A másik modell folyamatfejlesztés szemléletű. Két irányból lehet közelíteni a folyamatok javítására: vagy a szervezetek érettségi szintjeit, vagy a szervezetek folyamatainak képességi szintjeit vizsgáljuk. Az érettségi és a képességi modellek szoros kapcsolatban vannak egymással, mert egy adott érettségi szinten lévő vállalatnál adott képességi szinten lévő folyamatoknak kell jelen lenniük. Attól függően, hogy a folyamatfejlesztés/javítás szakaszosan vagy folyamatosan történik, a folyamatfejlesztési modellek két (illetve három) csoportra bonthatók: lépcsős modellek a teljes szervezetre koncentrálnak, a vállalat érettségi szintjét bizonyos folyamatok jelenléte és azok képességi szintje határozza meg. Ide tartoznak az érettségi modellek (CMM) folytonos modellek az egyes folyamatokra koncentrálnak, átfogó keretrendszer a folyamatok erősségeinek és gyengeségeinek feltérképezésére, és ezzel képességi szintekbe sorolására. Ide tartoznak a képességi modellek (SPICE) integrált modellek ötvözik a fenti kétféle modellt, a vállalat összes folyamatának egy adott képességi szintet kell elérnie ahhoz, hogy a vállalat megfeleljen egy érettségi szintnek. Ezek a képességi-érettségi modellek (CMMI) A szervezetek érettségi szintjei a lépcsős modellben: 0. szint: kaotikus a szervezet az ott dolgozók egyéni elhivatottsága miatt van talpon 1. szint: ismételhető létezik projektirányítás 2. szint: meghatározott kidolgozott metódusok a projektirányításra és a műszaki eljárásokra 3. szint: menedzselt a folyamatokat mérik, elemzik 4. szint: optimalizáló a folyamatokat optimalizálják A folyamatok képességi dimenziói a folytonos modellben: 0. nem végrehajtott nincsenek folyamatok 1. végrehajtott folyamatokat hajtanak végre, de nincsenek azonosítható jellemzőik 2. menedzselt a folyamatokat tervezik, irányítják 3. meghatározott léteznek a folyamatokra szervezeti szintű szabványos leírások, a végrehajtás során vannak visszajelzések 4. jósolható a folyamatokat mérik, elemzik, ellenőrzik 5. optimalizáló a folyamatokat javítják
Szoftvertesztelés Az első tételben beszéltünk a szoftverfejlesztési folyamatról, melynek négy alapvető tevékenysége volt: • • • •
specifikáció (követelmény-tervezés) tervezés / fejlesztés (implementáció) validáció (tesztelés) evolúció (karbantartás)
A tesztelés áll a validálásból, mikoris azt vizsgáljuk, hogy a rendszer megfelel-e a célnak, és áll a verifikációból, mikor azt vizsgáljuk, hogy a rendszer megfelel-e a specifikációnak. Az, hogy melyik szoftverfejlesztési folyamatmodellt választjuk, hatással lesz a tesztelés kivitelezésére. 16
A tesztelés alapelvei, típusai és szintjei Hét alapelve van a tesztelésnek: • • • • • •
a tesztelés megmutatja a hibák jelenlétét lehetetlen a teljes szoftverre/rendszerre kiterjedő tesztelés: prioritások felállítása szükséges a korai tesztelés fontossága a hibák csomósodása: a hibák nem egyenletesen elszórtan jelentkeznek a teszteseteket folyamatosan karban kell tartani a tesztelés környezetfüggő: a fejlesztési, a tesztelési és az éles rendszerben más és más jellegű problémák merülhetnek fel • a hibahiány téveszméje: ha nem találunk hibát, az nem jelenti azt, hogy nincsenek, hanem rosszul kerestük Különféle tesztcélok érdekében különféle típusú teszteléseket végzünk: • specifikáció alapú (feketedoboz) tesztek: a követelményspecifikáción alapul (funkcionális, nem funkcionális követelmények) • lehetetlen a teljes szoftverre/rendszerre kiterjedő tesztelés: prioritások felállítása szükséges • nem funkcionális tesztek: terheléses, teljesítmény és stressz tesztek • struktúra alapú (fehérdoboz) tesztek: kódlefedettség alapján tesztelnek • változáshoz kapcsolódó tesztek: regressziós tesztek, melyek a hibajavítások vagy módosítások után futtathatók A tesztelésnek különféle szintjei vannak: modulteszt: önnállóan végrehajtható egységtesztek, általában a fejlesztők végzik integrációs teszt: a komponensek közötti kommunikáció és az interfészek tesztje, általában egy különálló tesztelőcsapat végzi rendszerteszt: az vizsgáljuk, hogy a rendszer megfelel-e a követelményspecifikációnak, általában üzleti szakértők végzik elfogadási teszt: egy élethű tesztkörnyezetet állítanak fel, általában a leendő felhasználók egy csoportja tesztel
Teszttervezési technikák Két alapvetően eltérő tesztterezési technikát használunk attól függően, hogy a rendszer/program működik vagy sem, mialatt a teszteket végrehajtjuk. Statikus Statikus a teszt, mert a tesztelés alatt a program nem fut. Egy felülvizsgálati folyamat során különféle szakterületi szakemberek a dokumentációt, a rendszer programkönyvtárát és a kódot olvasva elemzik a szoftvert. A felülvizsgálat lehet teljesen formális is: ekkor egy moderátor vezeti a vizsgálatot, a résztvevők az elemzéseket, kérdéseket írásban rögzítik, a válaszok is írásban érkeznek. Dinamikus A rendszert futás közben vizsgáljuk. Kialakítjuk a tesztelési eljárásokat a tesztek létrehozására, ütemezésére, futtatására. Tesztterveket állítunk össze, teszteseteket készítünk. A dinamikus tesztek lehetnek: struktúra alapú (fehérdoboz) tesztek a tesztelés alaposságának mérésére többféle mértéket használunk (kódlefedettség, utasítás lefedettség, döntési lefedettség) tapasztalat alapú tesztek specifikáció alapú (feketedoboz) tesztek általában ekvivalenciapartíciós módszereket használunk a tesztesetek létrehozásához 17
Tesztmenedzsment Egy tesztmenedzsment felállítása a független és tervezett tesztelést segíti elő. A független tesztelés során a tervezéstől vagy a fejlesztéstől független szakemberek végzik az ellenőrzést, így objektív és hiteles eredményeket kapunk, bár fennáll a tesztelők elszigetelődésének veszélye. A teszttervezés során többféle szabványos startégiát követketünk, becsülni tudjuk az erőforrást, az időt és a költséget, illetve kockázatelemzést végezhetünk.
Teszteszközök Vannak olyan eszközök, melyek nem kifejezetten a tesztelésre jöttek létre, ám nagyon jól használhatók. Projektirányítás felhasználható a tesztelési projekt irányítására, ütemezésére, nyomonkövetésére és jelentések készítésére. Konfigurációkezelés a tesztesetek karbantartására Követelménykezelés teszesetek visszaellenőrzése Monitorozás Teszttervezés a dinamikus tesztekhez bemenő tesztadatok generálhatók a követelményekből, a modellekből, a kódból. A tesztvégrehajtási eszközök pedig a regressziós tesztelésnél használhatók, makrók rögzíthetők.
18
4. tétel
Alkalmazásfejlesztés Mutassa be az internetes alkalmazásfejlesztés tervezési, kivitelezési, tesztelési technológiáit; a fejlesztőeszközök típusait, szolgáltatásait!
Webes technológia A kritikusság és a grafikai intenzivitás alapján többféle szoftvert különböztetünk meg, ezek: beágyazott (real-time) kernelközeli rendszerek; operációs vagy adatbáziskezelő rendszerek; vállalati és internetes alkalmazások; desktop alkalmazások; elektronikai eszközök szoftverei; grafikus játékok. Ebben a tételben a vállalati és internetes alkalmazásokkal foglalkozunk.
Kliens-szerver architektúra Manapság a vállalati internetes alkalmazások háromrétegű kliens-szerver architektúrával rendelkeznek. Az adatréteg (Data Tier) az adatok manipulálására magasszintű adatbázisműveleteket biztosít a felette lévő rétegnek. Az alkalmazás réteg (Application Tier) tartalmazza a webes megjelenítéshez szükséges adatátalakító műveleteket és az üzleti logikát. Az üzleti logika az alkalmazás funkcionalitását tartalmazza. A kliens vagy megjelenítési réteg (Client Tier) felelős az információ megjelenítéséért: egyrészt a felhasználó által megadott adatokat továbbítja az alsóbb réteg felé, másrészt az alulról érkező adatokat jeleníti meg.
4.1. ábra. Rendelési folyamat a rétegeken keresztül
19
Alkalmazás platform Az alkalmazás futtatásához nem elegendőek az operációs rendszeri funkciók, hanem ennél többre van szükség. Egy webalkalmazás platformot (Application Server) telepítünk, mely biztosítja a webes alkalmazások létrehozásához, telepítéséhez szükséges szolgáltatásokat. A platform tartalmaz egy futtatókörnyezetet (Runtime Environment), mely olyan alapvető szolgáltatásokat biztosít az alkalmazások számára, mint a memóriakezelés, a szálkezelés, a hálózati kommunikáció és a biztonság. Tartalmazza továbbá az alkalmazásfejlesztés során felhasználható alapvető programkönyvtárakat. Ez a környezet fogja az alkalmazásunkat, mint egy programkönyvtári funkciót meghívni a felhasználók kiszolgálásához. Amikor egy felhasználó a böngészőjén keresztül megnyitja a webes alkalmazást, akkor valójában a webalkalamzás platformmal tartja a kapcsolatot, és ez a platform hívja meg a konkrét alkalmazásokat mint komponenseket. A vezérlés általában a platformnál van. A keretrendszerek (Framework) alk.
alk.
webalkalmazás platform
virtuális gép, adatbáziskezelő-rendszer
operációs rendszer
hardver
a tervezési és fejlesztési feladatok elvégzését megkönnyítő fejlesztőkörnyezetek. Megadható az alkalmazás váza, az adatbázis modellje, tervezési mintákat, programkönyvtárakat biztosítanak. Valamint rengeteg kisegítő alkalmazást tartalmaznak, ilyenek például az automatikus dokumentációkészítés, a tesztelés, a loggolás, a verziókezelés. A keretrendszerekről később bővebben lesz szó. webalkalmazás platformok Zend Server WebSphere, WebLogic, IAS, JBoss Windows Server
futtatókörnyezetek Zend Engine J2EE CLR
keretrendszerek Zend Studio JDeveloper, NetBeans .NET Framework
A továbbiakban J2EE futtatókörnyezetre épülő alkalmazásokról és keretrendszerekről fogunk beszélni.
Alkalmazások Attól függően, hogy milyen típusú alkalmazást készítünk, a rétegek szét- vagy összecsúszhatnak, ez látható a 4.2 ábrán. A három réteg jól elkülöníthető, és az alkalmazás réteg meglehetősen változatos. Az üzleti logika (Business Logic) írja le az alkalmazás funkcionalitását, a webes réteg (Web Tier) a kliens réteg számára biztosítja a megjelenítendő adatokat. A 4.3 ábrán látható az alkalmazás működése. A felhasználó a böngészőjében megnyit egy dinamikus weboldalt. Ez a megnyitás úgy történik, hogy a böngészőbe írt URL kérésként kerül továbbításra a szerverhez. A webes réteg kikeresi a megfelelő weblapot, illetve ha a weblap adatmegjelenítést is tartalmaz, akkor továbbítja az adatkérést az üzleti logikai réteghez. Ez a réteg úgynezevezett bean-ek közvetítésével lekéri az adatbázisból a megfelelő adatokat, majd átadja ezeket a webes rétegnek. Itt a kliensbeli prezentációnak megfelelően átalakításra kerülnek az adatok: más szerkezetű és feladatú bean-ekbe csomagolódnak. Ha a webes réteg előállította az új bean-eket és lekérte weblapot, akkor 20
4.2. ábra. J2EE alkalmazás architektúra változatok
ezeket továbbítja a böngészőhöz, ahol megjelenik a kért weboldal, benne a megfelelő adatokkal.
4.3. ábra. A rétegek közötti kapcsolatok A J2EE-t támogató webalkalmazás platform látható a 4.4 ábrán. A komponensek, azaz a konténerek (container) weblapokat (servlet), bean-eket tárolnak, illetve ezek kezelését biztosító funkciókat tartalmaznak. A webkonténer felügyeli az alkalmazás JSP vagy JSF oldalait, illetve az ezekből generált servlet-eket. A bean-ek tárolását és kezelését az EJB konténer végzi. Többféle bean létezik. A session bean-ek jellemzően valamilyen funkciót valósítanak meg. Két fajta session bean van, a stateful és a stateless. Az egy felhasználó session-jének teljes élettartama alatt őrzik az információt a stateful session beanek, míg a stateless session bean-ek rövid ideig élnek, és éppen ahhoz a felhasználóhöz kapcsolódnak, amelyiknek szüksége van az adott bean-re. A message driven bean-eket üzenetekkel lehet működtetni. 21
Az objektumrelációs adatbázis tartalmát nem direktben, hanem entity-k közbeiktatásával vehetjük igénybe. Minden táblához tartozik egy entity osztály, és az osztály egy példánya egy adott táblabeli sornak felel meg.
4.4. ábra. J2EE webalkalmazás platform
Fejlesztőeszközök Projektmenedzsment eszközök A projektirányítással foglalkozó tétel részletezi, hogy milyen feladatok ellátását kívánjuk egy projektirányító szoftvertől. A választott szoftverfejlesztési folyamatmodell alapján válasszuk a projektirányító szoftvert: vannak olyan eszközök, melyek a hagyományos fejlesztési modelleket (vízesés, evolúciós), és vannak, melyek az iteratív modelleket támogatják. A hagyományos modellek esetén a következő feladatokat tudja kezelni az eszköz: kezdeti tevékenységek projektcélok, stratégia rögzítése. tervezés és szervezés feladat lebontás, feladat ütemezés, felelősségi mátrix létrehozása, kritikus utak és kritikus láncok kezelése, kockázatelemzés, költségvetés. végrehajtás a csapat irányítása, az erőforrások biztosítása, a projektterv és a valóság összevetése. monitorozás és ellenőrzés a felmerülő problémák megoldása, a szükséges változtatások kezelése. A minőség, az idő és a költség hármas egyensúlyának felügyelete. zárás szerződés lezárás a megrendelő felé, projektértékelés a tagok felé. Az agilis projektirányítás fő feladatai: munka a termékhez magasszintű terv az elvégzendő feladatokról, a projektcélnak megfelelően prioritással, rákövetkezésekkel és fejlesztései ráfordítással ellátva. munka az iterációkhoz 2-4 hét alatt elvégezhető iterációk meghatározása. Egy-egy iteráció kb. hetek vagy napok alatt elvégezhető taszkok gyűjteménye. A taszkok pontosan meg vannak határozva. Egy iteráció taszkjai lehetnek: egy funkció tervezése, implementálása, egységtesztje, elfogadási tesztje. az iterációk monitorozása vizuális megjelenítése az iterációk naprakész állapotának, mely taszkok vannak kész, melyek problémásak, stb. 22
Követelménykezelő eszközök A választott szoftverfejlesztési folyamatmodell alapján többféle eszköz létezik, legtöbbje projektirányítási feladatokat is el tud látni, de valamennyi tartalmazza a következő elemeket: szószedet megadása, előzetes követelménygyűjtemény létrehozása, funkcionális és nem funckionális követelmények szisztematikus leírása, használati esetek és az ezekhez kapcsolódó aktorok, taszkok és események megadása, funkciók tervezése, valamint az inkrementális folyamatmodell esetén az iterációk kezelése.
Keretrendszerek A keretrendszerek segítségével hozzuk létre az alkalmazásainkat, melyeket mint komponenseket fog futtatni az alkalmazás-szerver. A komponenseken belül a funkcionális kohézió magas, ám a komponensek egymástól függetlenek, interfészeken keresztül kommunikálnak. A komponenseket tervezési minták (pl. session façade) alapján hozzuk létre. A keretrendszer hierarchiába szervezi a forrásokat (kód, stílusfájlok, képek, többnyelvűséget támogató szótárfájlok). Általában egy munkaterület (workspace) több alkalmazást (application) foglal magába. Az alkalmazások projektekből állnak, és a projektek alatt helyezkednek el a forrásfájlok – a Java-ban megszokott csomag (package) sturktúrába szervezve. A keretrendszer számos kisegítő funkciót biztosít a fordítóprogramon túl. A szövegszerkesztő sokkal több, mint a különféle jellegű szavak szinezése. Többféle perspektívában szemlélhetjük a kódot, így más és más felületi elemek kerülnek előtérbe. Szintaktikus ellenőrzés, blokk-elrejtés, osztályok felismerése, kód aszisztencia, refaktorálás, kódvázak létrehozása néhány tipikus jellemzője a szövegszerkesztőknek. A hibakereső vagy nyomkövető (debugger) funkcióval futás közben monitorozhatjuk az alkalmazásunk állapotát. Töréspontokat, feltételes törépontokat állíthatunk be, kifejezések kiértékelését, változók értékének megtekintését biztosítja. Az alkalmazás futási idejét, memóriahasználatát monitorozhatjuk a profilozó (profiler) segítségével. Figyelhetjük a szálak működését, az eljárások hívási gráfját kérhetjük, különféle statisztikákat hívhatunk le (pl. az egyes osztályok metódushívásainak száma). Ezeket a kéréseket különféle szűrőkkel precizionálhatjuk. A Java nyelvű osztályok dokumentálására ipari szabványra emelt dokumentáció-generáló eszköz a Javadoc. Nemcsak szöveges dokumentáció, hanem a program szerkezetét feltérképező gráf is generálható a megfelelően elhelyezett kommentekből. Egy alkalmazás működtetése során fontos rögzíteni a felhasználói aktivitást. Erre való a logger, mellyel különféle szintű eseményeket definiálhatunk (kivétel, figyelmeztetés, egyéb információ), és későbbi elemzés céljából ezek bekövetkezésének adatait logfájlokba gyűjthetjük. Az egységteszteket (unit testing) a fejlesztők végzik el, és erre is van támogatás a keretrendszerekben. Külön tesztprojektet készíthetünk, teszteseteket rögzíthetünk, melyeket teszttervek alá szervezhetünk. Az, hogy a fejlesztők állítják össze a futtatható egységteszteket, jobb kódminőséget eredményez. A vállalati alkalmazások nagy méretűek, ezért általában többen vesznek részt a fejlesztésben. Továbbá éveken keresztül működnek, általában folyamatos karbantartás, módosítás, változtatás mellett. Ezért hasznosak a verziókezelők és a konfigurációkezelők. Az előbbi a csapatmunkát támogatja: ha többen dolgoznak egy fájlon, akkor a különböző módosítások összefésülhetők (merge). Az utóbbi az alkalmazás változatainak követését és ellenőrzését biztosítja.
23
5. tétel
Projektirányítás Sorolja fel a projektmenedzsment fő folyamatait, és ezen belül részletesebben ismertesse a projektütemezés lépéseit!
A projektirányítás alapfogalmai A projekt valamilyen eredmény (termék/szolgáltatás) létrehozására irányuló időleges erőfeszítés. A projektnek van egy konkrét célja, tevékenységekből áll, és három egymás ellen ható tényezővel egyensúlyoz (idő, költség, minőség). Az informatikai projekt specialitása, hogy egyedi, sokszereplős és kb. egy év a futamideje. A projekt környezete a külvilág és a vállalati környezet. A külvilág esetén a politikai, jogi és gazdasági szempontokat vesszük figyelembe, vállalati környezet esetén a szervezet struktúráját. Ez a struktúra lehet egyszintű, egy főnökkel és 4-6 alkalmazottal, vagy funkcionális, aholis divíziókra van osztva a vállalat, vagy lehet mátrix szervezet, mely szintén funkcionális egységekre van osztva, de ezen egységeken keresztül ível a projektcsapat, végül lehet igazi projektcsapatra épülő. Itt a csapatok csak a projekt idejére állnak össze. A projekt belülről egy hierarchikus szervezet, ahol a csapattagok több szerepet is betölthetnek. A projekt résztvevői között még az alvállalkozókat is megemlítjük. A projekt négy nagy ütemre bontható: előkészítés három tevékenységből áll: az értékesítési folyamatból, melyet kereskedők végeznek, ajánlatkészítés és szerződéskötés. Az ajánlat általában egy szerződés-szintű dokumentum, tartalmazza a projektdefiníciós dokumentumot és a szerződést. indítás egy olyan értekezlet, ahol az összes résztvevő jelen van, és a célok világos kijelölése történik. végrehajtás ez a leghosszabb ütem, függ a választott szoftverfejlesztési folyamatmodelltől. A hagyományos folyamatmodellek esetén két tevékenységből áll: a projekttervezésből és a projektkövetésből. Mindkettőt alább részletezzük. lezárás amikor teljesült a projektcél, azaz a megrendelő elfogadta az eredményt, akkor célszerű egy projektzáró dokumentumot készíteni, és egy pozítív kicsengésű értékelő vacsorát szervezni.
Projekttervezés A projekttervezés során a következő kérdésekre adjuk meg a választ: KI MIT HOGYAN MIKOR MENNYIÉRT
Feladatlebontási struktúra A MIT kérdésre egy feladatlebontási sturktúrát készítünk, általában dekompozíciós technikákat alkalmazva, az „oszd meg és uralkodj” elvét követve. 24
Szervezetlebontási struktúra A KI kérdés részleges megválaszolásához egy szervezetlebontási struktúrát állítunk össze, mely megadja, hogy a szervezet funkcionális egységeiből mennyi szakemberre van szükség. Ezen a szinten tehát nem a konkrét személyekről döntünk, hanem arról, hogy milyen tudású emberekre van szükségünk. A fenti két lebontási struktúrát összevetve előállítjuk a felelősségi mátrixot, melyben a KI és MIT kérdésekre adott terveket összekapcsoljuk.
Tevékenységek hálóterve A HOGYAN kérdés megválaszolásához a feladatlebontási struktúrából indulunk ki. A feladatok hierarchikus lebontásából a levelekben található tevékenységeket a hálótervezés elvei alapján átszervezzük. A hálóban az elemi tevékenységek közötti különféle rákövetkezéseket ábrázoljuk. A háló egy irányított gráf, és kétféle hálótervezési módszer van: • tevékenység a nyílon: a nyilak a tevékenységek, a csomópontok a létrehozott eredmények. A csomópontok között befejezés vagy kezdés kapcsolatok lehetnek. • tevékenység a csomóponton: a nyilak a rákövetkezések, a csomópontok a tevékenységek. A csomópontok között négyféle kapcsolat lehet. – – – –
a megelőző tevékenység befejezése után kezdődhet el a rákövetkező tevékenység a megelőző tevékenység befejezése után fejeződhet be a rákövetkező tevékenység a megelőző tevékenység indítása után elkezdődhet a rákövetkező tevékenység a megelőző tevékenység indítása után fejeződhet be a rákövetkező tevékenység végrehajtása
Gantt diagram ütemezéssel A MIKOR kérdés megválaszolásához a tevékenységek hálótervéből indulunk ki. A tevékenységek ütemezését a tevékenység a csomóponton típusú hálóterven tudjuk elvégezni. A tevékenység csomópontok legyenek a következő felépítésűek: legkorábbi kezdés
időtartam
legkorábbi befejezés
tevékenységazonosító legkésőbbi kezdés
teljes tartalékidő
legkésőbbi befejezés
Határozzuk meg az egyes tevékenységek végrahajtási idejét. A becslés történhet optimistán, pesszimistán vagy átlagos értékeket felhasználva. A hálóban töltsük ki az időtartam mezőket a végrehajtási időkkel. Az időelemzéshez vegyük a hálón a legelső csomópontot, és a legkorábbi kezdésnek adjuk meg a projekt kezdőidőpontját. A legkorábbi befejezés legyen a legkorábbi időpont + az időtartam. A következő kapcsolódó tevékenységek legkorábbi kezdése a megelőző tevékenységek közül a legkésőbben befejeződő legkorábbi befejezése legyen. Így haladjunk végig a hálón. A hálón visszafelé haladva tudjuk kitölteni a legkésőbbi időpontokat. Az utolsó tevékenység legkésőbbi befejezése legyen ugyanezen tevékenységnek a legkorábbi befejezése. A legkésőbbi kezdés legyen a legkésőbbi befejezés - az időtartam. A megelőző tevékenységek legkésőbbi befejezése a rákövetkező tevékenyésgek közül a legkorábban elkezdődő legkésőbbi kezdése legyen. Így haladjunk előre a hálón. Egy tevékenység teljes tartalékideje az jelenti, hogy a tevékenység bármikor elkezdődhet a legkorábbi kezdés és befejezés között. A nulla teljes tartalékidejű tevékenységek a kritikus tevékenységek. A projekt kritikus útjai azok az utak a hálóban, melyek kritikus tevékenységeket tartalmaznak. Miután elkészítettük a hálón az időelemzést, képezzük le Gantt (sáv) diagramra. A Gantt diagramon vizuálisan jobban látható a tevékenységekre fordított idő és a tevékenységek rákövetkezése. 25
Gantt diagram erőforrásokkal A projekttervezésnek ebben a fázisában tudjuk a KI kérdésre megadni a konkrét választ. Az erőforráshozzárendelés célja az erőforrások optimális elosztása. A Gantt diagram alkalmas arra, hogy erőforrásokat rendeljünk a tevékenységekhez. Az erőforrás lehet logikai, ekkor projektszerepet rendelünk a tevékenységhez. Az erőforrás lehet fizikai, ekkor konkrét személyt rendelünk a tevékenységhez. Ha visszatérünk a hálódiagramra, és kiegészítjük a tevékenység csomópontokat az erőforrásokkal, akkor lehetőségünk van a kritikus láncok meghatározására. A kulcsszakemberek olyan dolgozók, akik szűk keresztmetszetét alkotják az erőforrásoknak. Cél, hogy ezek a szakemberek folyamatosan foglalkoztatva legyenek. A kritikus lánc az a leghosszabb út a hálóban, ahol kulcserőforrások vannak jelen. A kulcserőforrások tevékenységei előtt a láncban biztonsági puffereket alakítunk ki: ha a megelőző tevékenységek késnek is, a kulcserőforrás nem fog várakozni.
Költségvetés A költségvetés adja meg, hogy MENNYIÉRT végezzük el a feladatokat. A költségvetés tervezésének több módja van, nagyban függ a projekt szervezeti környezetétől. A költségek két nagy részre bonthatók, ezek a bérköltség és a vállalati költségek (berendezés, ingatlanbérlet, stb). Döntés kérdése, hogy a vállalati költségeket az élőmunkaköltségbe porlasztjuk vagy a projektre terheljük. Fontos szempont, hogy a projekt végrehajtása során mikor merül fel a kifizetés kérdése.
Projektkövetés A projektkövetés egy iteratív folyamat, melynek során inforációt gyűjtünk a projekt haladásáról állapotjelentések formájában, majd ezeket elemezzük, összegezzük. Összevetjük az aktuális költségeket és időráfordítást a tervezettel, pl. költséghatékonysági és ütemterv teljesülési mutatókat elemzünk. A projektet kísérő folyamatok a következők: projektbecslés a becslés lehet metrikán, projektterven, átfutási időn, terméken alapuló vagy analógiás. dokumentálás a dokumentumok irányítási vagy műszaki típusúak követelménykezelés fontos feladat a projekt terjedelmének behatárolása, vagyis, hogy mi a projekt feladata, és mi nem az. multiprojekt irányítás ha több projektet koordinálunk jogi feladatok különösen a szerződéskötés során fontos változáskezelés a projekt végrehajtása során kiderülhet, hogy a követelményekben változtatni kell kockázatkezelés kockázati mátrixban a kár nagyságát és a bekövetkezés valószínűségét vizsgáljuk minőségbiztosítás
26
Irodalom [1] Bakay Árpád, 2008-2009. Szoftverfejlesztési projektmunka a gyakorlatban II – III, előadás. [2] Balla Katalin: Minőségmenedzsment a szoftverfejlesztésben. 2007, Panem. [3] Dorothy Graham – Erik van Veenendaal – Isabel Evans – Rex Black: Foundations of Software Testing: ISTQB Certification. 2008, CENGAGE Learning Business Press. [4] Kovács Attila, 2007. A szoftverfejlesztés módszertana, előadás. [5] Kovács Attila, 2007. A szoftverfejlesztés minőségi aspektusai, előadás. [6] Langer Tamás: Projektmenedzsment a szoftverfejlesztésben. 2007, Panem. [7] Oracle University Budapest, 2008. Fusion Middleware Development, Köztesréteg technológia szemináriumsorozat. [8] Ian Sommerville: Szoftverrendszerek fejlesztése. 2007, Panem. [9] Wikipedia: Scrum. http://en.wikipedia.org, 2010. május.
27
