Projektek a gyakorlatban Követelmény-kezelés

1. Projektek a gyakorlatbanKövetelmény-kezelés

2. Tartalom • Projektek fázisai • Szoftvefejlesztés a Microsoftnál • A mi projektünk • Követelménykezelés módszerei • Követelményekről általában • Használati esetek

3. I. Rész – Projektek a gyakorlatban

4. 1. Mekkora egy szoftver projekt? Érzékeltetésül: • Kicsi: < 1 emberév, kb. 3 hónap időtartam • Nagy: > 20 emberév, minimum 1 év időtartam • Közepes: ami közte van

5. 2. Szoftver projekt jellemző fázisai • (Koncepcióalkotás, ajánlati szakasz) • Rendszerint a projekt kezdete előtt • Specifikáció 10-40% • Tervezés és implementáció 40-80% • Validálás és bevezetés 10-30% • (Karbantartás, evolúció) • Rendszerint a projekt zárása után

6. Specifikáció • (=követelménykezelés) • Az a folyamat, amelyben meghatározzák és rendszerezik a szoftver szolgáltatásait, egyéb tulajdonságait, ill. a fejlesztési munkával kapcsolatos elvárásokat. • Intenzív együttműködés a felhasználókkal • Főleg nem szoftverfejlesztési ismereteket igényel

7. Tervezés és implementáció • Tervezés: a specifikációt kielégíteni képes szoftver struktúrák kigondolása • Implementáció: a struktúrák kitöltése kóddal; az eredmény futtatható szoftver. • A két tevékenység egyre szorosabban összekapcsolódik (Model-BasedComputing) • Implementációnak már része jelentős mértékű tesztelés!

8. Validálás és bevezetés • Annak ellenőrzése és elősegítése, hogy a rendszer működjék az éles környezetben és felhasználásban, megfeleljen a követelményeknek, és a felhasználói igényeknek. • Ellenőrzések, áttekintések, tesztek • átvételi (funkcionális) tesztek, • teljesítmény-tesztek, • integrációs tesztek (kapcsolat más rendszerekkel) • Dokumentálás és oktatás • Különféle felhasználói csoportok oktatása

9. Karbantartás és evolúció • Futó rendszer monitorozása • Hibák elemzése, javítása, javítások eljuttatása a már működő rendszerekbe • Új felhasználói igények kielégítése rendszer bővítésével.

10. Szoftverfeljesztési metodológia, mint tudomány • Egzakt tudományként nehezen kezelhető, mert • Nincsenek egyértelmű fogalmak, definíciók • Referencia-módszertanok elavultak • Vizsgálatokban keveredik a szoftverfejlesztés a szoftver-projekt vezetéssel • Maga a szoftverfejlesztés egy személyes ügy • MINDEN elvet könnyen túlzásba lehet vinni • A projektek lényegesen különbözők • Felhasználás módja, méret, idő és erőforrás-feltételek, fejlesztési kultúra, stb. • A fejlesztési munkát számszerűsíteni nagyon nehézkes. No Silver Bullet: Essence and Accidents of SoftwareEngineeringby Frederick P. Brooks, Jr.

11. 3 . Szoftverfejlesztés a Microsoftnál • By Michael A. Cusumano & Richard W. Selby, Communications of the ACM, June 1997,vol. 40, no. 6 • Nem túl formális, nem túl strukturált rendszerben fejlesztenek • Párhuzamosan működő kis csoportok (3-8 fő fejlesztő) • Termék-csoportok önállóan tervezik és fejlesztik a termékeket, bátran újítanak • A kompatibilitás érdekében rendszeresen és alaposan egyeztetnek a szomszéd csapatokkal

12. Microsoft vs. Hagyományos fejlesztés Forrás: http://www.cs.umd.edu/~atif/Teaching/Spring2006/Slides/2.pdf

13. Tervezés • Az ötletből (pl. új Windows kereső modul) elkészül egy „Vision statement” • „chief technologist” vagy hasonló személy által • Előzetes követelmény-tervezés • Főszereplő: „Product manager” • Erőforrás és ütemterv, majd a projekt csapat összeállítása • 3-8 fejlesztő • kb. ugyanannyi tesztelő!

14. Fejlesztés • Három fázisban, fázisonként a funkciók 1/3-1/3-1/3-ára • Prioritás szerint: Első körben a legfontosabbakat • Egy fázis így 2-4 hónap • „Synch and stabilize” • A fázisok vége felé már nem az újabb funkciókon, hanem a meglévők stabilizálásán van a hangsúly • Folyamatos, automatizált buildés tesztelés • Integráció, már a csoportok között is naponta • Problémák számának követése, statisztikai elemzése • Együtt élnek változásokkal • max. 30% követelmény változás megengedett • 20-50% idő-tartalékkal számolnak

15. Validálás • „Zerodefecttolerance” • A mű addig nem mehet ki, amíg van ismert hiba • (máshol kis hibák bizonyos számban megengedettek) • Belső tesztek • Külső tesztek • Fizetett beta tesztelők • Baráti cégekkel: OEM, ISV • Nagyközönséggel • Visszajelzések elemzése • Szoftverminőségi és piaci szempontból is

16. Összefoglalás az érdekességekről • Kis, párhuzamosan dolgozó, de gyakran szinkronizáló csoportok • Folyamatos tesztelés • Mindig legyen, minden verzióban egy „leszállítható” termék • A készültség mérése számszerű adatokkal • kész/készülő/hiányzó funkciók • új/javított/lezárt bug-ok • stb. • A fejlesztés fizikailag is egy helyen, egy nyelven, egy környezetben történik

17. Erősségek és hátrányok • Kiscsoportos team-ek • Komplex termékek fejlesztése priorizált fázisokban • Nem konzisztens architektúra alakulhat ki • Folyamatosan alakuló, fejlődő termék • Mindig „szállítható” • Funkciók szépen gyarapodnak • Nemfunc. tényezők: sebesség, egyszerűség, biztonság fokozatosan erodálódhatnak • Alkalmas felhasználói visszajelzések fogadására

18. Ami még a háttérben van • Kiváló, minőség-orientált HR munka • „StructuredHackers” • Cég szinten elkötelezett csapatszellem • Közép-nyugat-USA mentalitás • Csapat szintű sikerélmények • Gyermekded ösztönzőkkel megtámogatva • 30 év tapasztalat • v.ö: Win95 – Win XP fejlesztése

19. A többiek mit csinálnak? Az örök vita:„Vízesés modell” vs. „Extreme programming” • Az XP előnyei • magasabb szintű motiváció, fejlesztőknél, ügyfélnél • adaptív: igazodik a valós, változó követelményekhez • gyakorlatban jobb szoftver-minőség • Viszont a vízesés modell • jobban illeszkedik a szerződéses szoftverfejlesztési projektekhez, • mert előre (pontosabban: előbb) rögzíti a követelményeket és a határidőket • Vízesés modell: klf. szintű terveken át a termékig • XP: klf. szintű prototípusokon át a termékig • piacra történő termékfejlesztésnél ez javasolt! • Gyakori kompromisszum: a projekt szerződés szerint vízesés jellegű, de a vége felé az XP felé hajlik el.

20. 4. „Ursula” - A mi projektünk • Orvosi nyilvántartó rendszer • Egyelőre egy előzetes (informális) specifikációnk van • = „Visionstatement” • Szokás szerint projekt ütemezés a részletes specifikáció előtt szükséges • Hogy pl. lehessen üzleti ajánlatot tenni • Ennek része a precíz specifikáció készítése!!!! Ellentmondás??? Igen!!!

21. Ursula informális specifikáció 1. rész Általános ismertetés Az alkalmazás betegek, kórtörténetek és különféle kezelések (vizsgálat, laborvizsgálat, műtét, rutinellátás, kontroll) nyilvántartására szolgál. Az alkalmazással követhető a betegségek lefolyása, diagnózisa, az egyes kezelések időpontja és adatai, eredménye, valamint az egyes orvosok és kórházi osztályok elszámolható tevékenysége, teljesítménye.

22. Ursula informális specifikáció 2. rész Funkcionális leírás Az alkalmazás felhasználói, és a számukra elérhető főbb műveletek a következők: • Beteg: saját adatok megtekintése, bejelentkezés kezelésre, időpont-módosítás • Adminisztrátor: új beteg és új eset felvétele, bejelentés kezelésre. • Orvos: kezelés adatainak kitöltése, új elvégzendő kezelés rögzítése • Labor: az elvégzett laborvizsgálat eredményének felvitele • Kórházi adminisztráció: új orvos, osztály felvétele, orvosok osztályhoz rendelése, lekérdezések az orvosok és az osztályok munkájáról

23. Ursula informális specifikáció 3. rész Egyéb követelmények • A UI legyen Web-alapú – UI technológia • A rendszer kapacitása legyen elegendő 300 kórházi dolgozó és 5000 beteg, 10000 eset és 100000 kezelés nyilvántartására. -- hatékonyság • Az elvárt teljesítmény 100 párhuzamos felhasználónál, 300 művelet/perc kihasználtságnál is legyen max. 3 sec várakozási idő képernyőként (kivéve a statisztikai, összesítési funkciókat, ahol hosszabb várakozás megengedett). -- hatékonyság • Az alkalmazás valamilyen kereskedelmi relációs adatbáziskezelőben tárolja az adatokat. – karbantarthatóság, teljesítmény, biztonság • Az alkalmazás minden felhasználótól követelje meg a jelszavas bejelentkezést. -- biztonság • Az alkalmazás legyen könnyen bővíthető (pl. diagnosztikai szakértői rendszer, előjegyzési naptár funkciók, betegek értesítése emailben, stb.) -- bővíthetőség • Legyen lehetőség más rendszerekből való automatikus adatcserére (pl. laborszámítógép, központi pénzügyi rendszer, személyzeti rendszer, PalmPilot stb.) -- bővíthetőség

24. Ursula informális specifikáció 4. rész Fejlesztésre vonatkozó követelmények • A rendszert 2008 júniusában kell üzembe helyezni • A GUI prototípusokat is tartalmazó rendszerterv átadásának határideje 2008 április • A fejlesztésnél alkalmazni kell • A használati eset alapú követelménykezelést • Az OO elveket és tervmintákat • A fejlesztői munka összehangolására verzió- és feladatkezelő rendszert

25. II. Rész - Követelménykezelés

26. Egyszerűsített szoftver projektHol tartunk? Projekt tervezés, követés MS Project Követelmények Tervezés, modellezés Implementáció Validálás RequisitePro Feladat és hibakövetés Konfigurációkezelés

27. Követelménykezelés • A követelmények definiálatlansága a projektek bukásának leggyakoribb oka!

28. 1. A követelménykezelés A projektben megvalósítandó szoftver képességeinek meghatározása • Szisztematikus művelet a követelmények összegyűjtésére és rögzítésére • Kifejezi és rögzíti megrendelő és a projekt közötti megegyezés tartalmát. • Egyértelművé teszi a későbbi követelmény változásokat.

29. A követelménykezelés kihívásai(szerződéses fejlesztésnél) • Érdekellentétek • A megrendelő palotát remél, de a fejlesztő legszívesebben kockaházat építene • Világképek különbözősége • „Szakterületi” és „szoftver” tudás • Nemcsak a megrendelő, de a szoftverfejlesztők is csak korlátozottan alkalmasak követelménykezelésre • „Vak vezet világtalant” – de azért van remény • Változó igények, és későn eszmélő / lusta megrendelő • „Featurecreep” – követelmények utólagos belopódzása a fejlesztés során

30. A követelménykezelés kihívásai(piaci fejlesztésnél) • Piaci és felhasználói igények eltalálása • Sőt: más az, amiért megveszik, és más, amiért szeretni fogják! • „Time to market” pressure • Hamarabb kell megjelenni, mint a konkurrencia • „Benefits vs. cost” • Az extra funkcionalitás megéri-e plusz fejlesztési erőforrásokat • Tényleg kell-e? • Reális veszély: dagadt, lassú programok

31. Követelménykezelés lépései • A probléma feltárása és elemzése • A szakma megismerése • Követelmények összegyűjtése • Követelmények részletezése • Két v. többszintű részletezettség • Követelmények rendszerezése • Osztályozás • Összefüggések („kapcsolódik”, „használja”, „felülmúlja”) • Ellenőrzés, ellentmondások feloldása • Változtatások követése, követelmény-karbantartás

32. Tervezés több szinten, mélységben • Három szintű követelmény-struktúra • Felhasználói követelmények • Rendszerkövetelmények • Szoftverterv-specifikáció • Ez már nem is tisztán követelmény… • Egyszerűsített, kétszintű • Ad hoc: rendszerjellemzők + résztvevői igények • Vázlatos, nem rendszerezett, ismétlődéseket, ellentmondásokat tartalmazhat • Rendszerezett követelmények • Szisztematikus, konszolidált, konzisztens • Funkcionális és nem funkcionális követelményeket eredményez • A funkcionális rész általában „használati esetek” formájában Mi ezt követjük (Sőt, a RUP is)

33. 2. Kétszintű követelménykezelés struktúrája Vision Document Résztvevői igények Ad hoc Rendszerjellemzők Rendszerezett Funkcionális Nem funkcionális 1: 2: N:

34. Ad-hockövetelmények/1:Rendszerjellemzők • Rendszerjellemzők = „Features” • A rendszer szolgáltatásainak többé vagy kevésbé szabatos leírása • Forrása zömében a „vision document” = „koncepcióterv”, „rendszerleírás”, „előzetes specifikáció”

35. Vision document • A projekt ötletgazdái által készített leírás • Gyakran ez az ajánlatkérés/projet tervezés alapja • Természetes nyelven, mérsékelten szabatosan írodott • Megfogalmaz funkcionális és nem funkcionális követelményeket is.

36. Ad-hockövetelmények/2:Résztvevői igények • Mind a kezdeti fázisban (pl. „visiondocument”), mind a későbbi időben rögzítésre kerülhet • Gyakran a rendszerjellemzők hiánypótlásaként • Általában rendszer tulajdonságaira, vagy a szolgáltatások pontosítására, részletezésére • Komplett új funkciónak itt már nem szabad megjelenni! • Az rendszerjellemző kell legyen, (a visiondocumentben)! • Kompenzáció nélkül nem érdemes hagyni, hogy pl. szerződéskötés után újabb funkciók jelenjenek meg. • Átszelheti a rendszerleírás logikáját • Pl. általánosan alkalmazandó megoldások • Pl. „A nevek listázási sorrendje legyen minden GUI listában váltható” • Bárki érintett javasolhatja, pl. • Végfelhasználók bármelyik típusa • Projekt szponzor és menedzsment • Fejlesztő, PM, tesztelő, marketing, stb.

37. Igények összegyűjtése:Források • User által írt specifikáció • Pl. Vision Document • Interview-k • Kérdőívek • Megbeszélések, ötletparádék • Forgatókönyvek készítése • (Prototípus) • Dokumentum véleményezés 1. fázis: Ad hoc 2. fázis Rendszerezett

38. Rendszerezett követelmény típusok • Funkcionális: leírja, hogy a felhasználó (avagy „actor”) mit csinálhat és arra mit kap eredményül • Gyakori leírási forma: használati eset = use case • Ezek a rendszer szolgáltatásai • Nem funkcionális követelmények a hatékonyságra, kapacitásra, biztonságra, robosztusságra, kompatibilitásra, szabványokra, technológiára stb. • Lehetőleg „What” és ne a „How” • Ezek a rendszer tulajdonságai

39. Funkcionális követelmények leírása • Szabad szöveges • Strukturált nyelvű • „Szamárvezetők” alapján • Pl. előfeltétel, leírás, bemenet, kimenet, végállapot, mellékhatás, hibák stb. • Ennek példái a használati esetek • Formális specifikációs nyelvek • Pl. VDM, Z, CASL, PDL - nem nagyon használják

40. Nem funkcionális követelmények • Jellemző típusok • Kapacitás, teljesítmény, hatékonyság, • Megbízhatóság, hordozhatóság, • Szabványok, ajánlások, protokollok, az ügyfél saját előírásai • Biztonsági, együttműködési, törvényi (pl. adatvédelem, adatmegőrzés) • Általában csak szabad szövegesen írhatók le

41. Elvárások a rendszerezett követelményekkel szemben • Teljesség igénye -> köv. dia • Ellentmondásmentesség • Előfordul, hogy egyes ad-hoc követelményeket el kell utasítani • Teszt esetek generálása • A követelmények alapján definiálhatók legyenek az átvitel során elvégzendő tesztek • Nem funkcionális követelményekre is

42. A teljesség igénye • Funkcionális követelményeknél a szolgáltatások teljes specifikációja szükséges • Ami nincs definiálva, az nem követelmény! • Nem-funkcionális követelményeknél vannak feltételezhető tulajdonságok • Pl. „adatbiztonság”, „elfogadható” sebesség, „elégséges” kapacitás, IE+Firefox támogatás, stb. • De jobb, ha itt is konkrétan rögzítik az elvárt feltételeket

43. 3. Használati eset – Use case • Funkcionális követelmények egyféle leírása, megadott minta szerint • RUP-ban gyökerező fogalom, de • XP-ben: User Stories – „light” változat • Hasonlók még: Object Behavior Definition, Task modelling • Csak külső viselkedést írjon le! • „What” and not „how” • A „how” már a tervezés része.

44. Definíció • Csak a Use case-re: 18 definíció!!! • A miénk legyen ez: A használati eset (H.E.) egy aktor és a leírt rendszer között folytatott, egy önmagában értelmes célra irányuló lehetséges interakciós sorozatok (szenáriók) gyűjteménye. • Neves Use Case guruk: • Ivar Jacobson (Ericcson 1960-80-as évek) • Alistair Cockburnwww.usecases.org

45. Aktor (Actor) • = specifikált rendszer „kommunikációs partnere” • Természete szerint • Felhasználó • Pl. utastájékoztató terminál, szövegszerkesztő • Másik rendszer • Pl. mail szerver, SNMP lekérdezés • Viselkedés szerint • Aktív • Ő szólítja meg a specifikált renszert • Passzív / szolgáltató • A rendszer szólítja meg • Ezt is aktornak hívják, (nem „passzor”)

46. Use case diagram • Áttekinti a H.E-ket, de nem sokat mond az egyes H.E.-kről… System boundary Új beteg felvétele Adminisztrátor Vizsgálat előjegyzése Beteg keresése <<uses>> Kezelés <<uses>> Orvos <<extend>> <<generalize>>

47. Használati Esetek -célok és lehetőségek • Legyen teljes • A rendszer összes, a felhasználói célokat támogató viselkedése legyen felsorolva • Legyen korlátozott • A felhasználók szempontjából nem lényeges vonásokat ne tartalmazza! • Felhasználási lehetőségek • Követelmények tisztázása a megrendelővel • Fejlesztésben • Projekt tervezés / árazás / követés • Tesztelés, teszt esetek írása • Kiindulási alap a user manuálhoz

48. Használati Eset szintek • Mire vonatkozik (scope): stratégiai, rendszer, v. alrendszer • Stratégiai: a vállalati folyamatok szempontjából. Pl: „számlázó rendszer”, ami akár több szoftver is lehet • Rendszer: egy projektben kifejlesztett szoftver • Alrendszer: ennek egy modulja, komponense • Cél részletezettség (goaldetail): összegző, felhasználói vagy alfunkció • Felhasználói, ami a user munkája szempontjából eredmény • Ö: „ügyfél hívás kiszolgálása”, „beérkezett email-ek kezelése” • F.: „rendelés felvitele”, „előfizető bekapcsolása”, „levél megírása” • A.: „bejelentkezés”, „felhasználó kikeresése”, „nyomtatás” • A F. szint gyakran egy tranzakció, az A. szint gyakran adatok bevitele • Interakció részletezettség (interactiondetail): szemantikai vagy dialógus szint • Sz: „Cím adatok megadása” • D: „Város, utca, házszám ir.szám szövegdobozok kitöltése” • Preferrált a szemantikai: lényeg az átadott információ, nem az átadás módja • Gyakorlatban előforduló kombinációk • S / Ö / Sz inkább vállalatszervezésben használják • S / F / Sz inkább szolgáltatás-fejlesztésnél használják • R / Ö / Sz funkciók csoportosítása (0-10 %) • R / F / Sz ez a leggyakoribb (60-90%) • R / A / Sz ilyen is kellhet (10-20 %) • R / A / D  általában nélkülözhető • Az R / * / * alrendszerekre (A) is alkalmazható, ha külön fejlesztik

49. Mi van egy Haszn. Esetben? • Ahány felhasználói cél (goal), annyi H.E.–t kell definiálni • H.E. = egy célra szolgáló alternatív szcenáriók gyűjteménye • Alternatívák megvalósulhatnak az aktorválasztása szerint • Fizetés készpénzzel/kártyával • Keresés hierarchia szerint vagy szűrőkifejezéssel. • Vagy egyéb feltételek alapján • A login sikeres/sikertelen • A tranzakció eléri a napi limitet vagy nem • A kiválasztott termék csak 18 éven felül vásárolható • A célt nem elérő szcenárió is része a H.E.-nek! • Esetleg lehet belőle nem-funkcionális követelmény • Szcenárió = interakciók sorozata • Interakció = lehet egy elemi művelet, vagy egy alárendelt színtűfh. célnak megfelelő H.E. (pl. felhasználói H.E.-nélalfunkció H.E.) • Pl. „file kiválasztása”, „fizetési részletek megadása”

50. A H.E-kkel kapcsolatos fogalmak osztálydiagramja „tartalmaz” Cél Használati Eset 1 1 N Szenárió „részletez” v. „alkalmaz” Kiegészítőszenárió N (jellemzően 3-9) Interakció Alfunkció H.E: