Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Szoftver dokumentáció Roskó Tibor. Dokumentáció: a felhasználói igények átfordítása, hogy az adott program megfelelő legyen működés és felhasználói szempontból.

Hasonló előadás


Az előadások a következő témára: "Szoftver dokumentáció Roskó Tibor. Dokumentáció: a felhasználói igények átfordítása, hogy az adott program megfelelő legyen működés és felhasználói szempontból."— Előadás másolata:

1 Szoftver dokumentáció Roskó Tibor

2 Dokumentáció: a felhasználói igények átfordítása, hogy az adott program megfelelő legyen működés és felhasználói szempontból.

3 Miért jó az SQS? –megoldást ad a fejlesztés nagy részében nincs dokumentálás az eredeti követelmények hiányosak a design csak a fejlesztés közben alakul ki, a kód részben csak szimulálja a designt teszteléskor csak a hibákat keresi, nem ellenőrzi a követelmények betartását a felhasználói dokumentáció sem tér ki részletesen a hibákra

4 A dokumentáció pontjai olyanok, mint az autópálya útjelzői, irányt mutatnak a cél felé, előre tekintve. Visszatekintve követhető az eddig megtett minden lépés. Az SDLC minden fázisa előkészíti a következő fázisba való átlépést, és rögzítik mi történt az adott fázisban.

5 SDLC fázisai követelmények design: meghatározza a kódolást kódolás: párhuzamosan a teszt dok. tesztelés

6

7 Ahhoz, hogy egy szoftver továbbfejlesztését is SLC-ben tudjuk kezelni –menedzsment –fejlesztési –tesztelési –felhasználói dokumentációknak kell a szoftver dokumentációhoz tartozni.

8 Az elkészített dokumentációkat naprakészen kell tartani –új fejlesztések –hibák –hiányosságok –hiányos specifikáció –szükséges kiegészítések –törlések nyilvántartása!

9 A dokumentációkat is CM-elni kell! –a továbbfejlesztések kimaradhatnak –a design lemarad a kódolástól –nem lehet visszakövetni a kódot a követelmények mentén –A felhasználó szemszögéből a program csinál valamit, de nem azt amit konkrétan elvárt tőle.

10 Miért kell jó dokumentáció? jó alap CM-re Ha hiányos v megengedi, hogy eltérjen a fejlesztési folyamat bizonyos keretektől –a szoftver ellenőrizhetetlen/kontrollálhatatlan lesz –a CM nem fogja tudni lekövetni a változásokat A fejlesztő elveszti a kontrollt és a szoftver továbbfejleszthetetlenné válik.

11 kis projekt követelmény dok. design leírás teszt riport tervek: fejlesztés, SQS, CM közepes +előzetes design +részletes design (build-to) +teszt terv nagy +teszt esetek, forgatókönyvek +interfész követelmények, design

12 Egyéb, nem méretfüggő dok. DB követelmények, design felhasználói kézikönyv továbbfejlesztési terv képzési terv: felhasználók kockázatkezelési terv szoftverbiztonság terv

13 10.1. Menedzsment dokumentumok minden fejlesztést menedzselni kell menetrend, erőforrás tervek kiadás előtt teszt kiadáskor rögzíteni a szoftver állapotát, komponenseit a visszakövethetőség miatt

14 Alapvető dokumentumok SDP: Software Development Plan SQS(P): Software Quality System (Plan) CMP: Configuration Management Plan Ezek kontrollálják a teljes fejlesztési folyamatot, a részletesség mérete, mélysége a projekt méretétől, összetettségétől függ.

15 Kis projekt esetén az egész lehet egy dok. A tartalma minden esetben fontos, hogy leírja kellő részletességgel hogyan lesz végigmenedzselve a projekt. A formális tervezés, fejlesztés ezek által hatékonyabb és megbízhatóbb lesz.

16 SDP az alap: menetrend, erőforrásigény meghatározása SDLC szerint halad a fejlesztés személyi feltételek, erőforrásigények –szükséges szaktudás –hardver, környezet, processzor órajel kis rendszernél külön fejezetben beépíthető az SQS, CM ha vannak interfészek, ezek specifikációi költségvetés, költségkezelési terv

17 SQSP a szoftver minőségi követelményei kombinálható a CMP-vel

18 CMP 6. fejezetben be lett mutatva metódusok, követelmények, használt eszközök megadása kis projektnél berakható az SDP-be személyzeti, erőforrásigények az SDP-ben a CM specifikus adatok itt kerülnek megadásra –ellenőrzések, auditing –repository

19 Kiegészítő tervek szoftver biztonság kockázatkezelés DB megvalósítás

20 10.2. Fejlesztési dokumentumok

21 az SDLC folyamatot lefedő dokumentációk biztosítják az egyre komplexebb alkalmazások megfelelését a felhasználói követelmények felé: –követelmény specifikáció –előzetes design –részletes design (build-to) –design leírás (as-built) –DB specifikáció –interfész specifikáció

22 Sokféle dokumentáció készíthető, ez a projekt méretétől, komplexitásától függ. A tartalmuk mérvadó, erre cégenként és egységesen is kialakíthatóak különböző standardok.

23 Követelmény specifikáció

24 a fejlesztés alapeleme meghatározza hogyan fog működni a szoftver megad korlátozásokat, megszorításokat, be és kimenetekre, hardverre, szoftverre ha nem teljes, a fejlesztéskor adódhat felelősség a kiegészítésre az ügyfél elvesztheti a kontrollját, ami miatt nem megfelelő működések jelentkezhetnek

25 sokszor bekerülhetnek hasonló hibák, ezeket az SQ ellenőrnek kell kiszűrni elsősorban és szabályokat megadni a dokumentum formátumára, tartalmi követelményeire előfordul, hogy nem ismeri a technikai részleteket, ezek felülvizsgálatához a fejlesztőket szükséges bevonni

26 Mitől lesz jó a követelmény specifikáció?

27 Correct Hogy a fejlesztett termék elfogadhatóan működjön, pontosan és részletesen kell dokumentálni az igényeket, követelményeket és hogy mit vár el a felhasználó a működés során!

28 Traceable - Visszakövethető Minden követelményt úgy kell dokumentálni, hogy fejlesztéskor, teszteléskor visszakövethető legyen honnan hová jutottunk el!

29 Szükségesség szükségtelen követelmények, megszorítások –nő a fejlesztési idő, költség túl pontos számítások indokolatlanul túl kis memóriakorlátozás lehetnek jól hangzó, fontosnak tűnő dolgok, de ezek szükségtelen mivoltuk miatt rontják a későbbi továbbfejleszthetőséget –napi 200E ellenőrzési lehetőség, de nincs napi 50E sem

30 Complete Mindent dokumentálni kell!

31 Measurable - Mérhető a tesztelés kulcsa a mérhető követelmények használata –gyors válasz, többelemű tároló –2 sec a fejlesztő szerint gyors, az ügyfél szerint lassú –20 a többelemű a fejlesztő szerint, de az ügyfél már 10-ért sem akar fizetni

32 Unambigous - Félreérthetetlen Úgy kell fogalmazni, hogy mindenki számára egyértelmű legyen minden, mit és hogyan kell megvalósítani! –kellene, hogy négyzetgyököt számoljon milyen pontossággal? : 3 tizedes

33 Consistent A követelményeknek egymással és a külső világgal is konzisztensnek kell lenniük! –1E check/óra, máshol 10E check/óra nem lesz konzisztens –de a külső világ felé sem, pl. 900 check/óra nem lesz = 1E check/óra-val

34 Design specifikáció

35 Előzetes A követelmények összekötése a fejlesztéssel. A rendszer architektúráját írja le, DB, interfészek külső rendszerekhez.

36 Build-to Leírja, hogy az 1. pontban megadottak hogyan lesznek lekódolva. Fontos, hogy a design teljesen dokumentálva legyen, mert a fejlesztők itt lépnek be és nekik nem kell! a design-al foglalkozni.

37 As-built A fejlesztés, tesztelés fázisok után kell elkészíteni, leírja mi hogyan lett lekódolva és mi lett módosítva az eredeti specifikációban. A továbbfejlesztés alapja, fontos, hogy mindig aktualizálva, CM-elve legyen.

38 Egyéb dokumentációk

39 Nagyobb rendszereknél szükséges lehet a DB és interfész dokumentációkat külön leírásokban megadni. Kevésbé komplex rendszereknél a build-to tervbe is berakható.

40 10.3. Tesztelési dokumentáció

41 Magába foglalja a teszt terveket, adatokat és a végső teszt riportot is. Az SDLC mentén haladva, a folyamatos dokumentálás mellett kell megadni a teszteseteket, egységtesztek eredményeit. A 4. fejezetben volt részletezve.

42

43 Az SQ ellenőrnek felügyelnie kell a teljes tesztelési folyamatot, hogy hibamentes, elfogadott szoftver kerüljön kiadásra. Az elsődleges cél a hibamentes működés, a másodlagos, megfelelni a megrendelő elvárásainak. Ezt legtöbbször a megrendelő bevonásával lehet elérni.

44 Tesztelési terv A követelményeken alapszik és a DLC alatt ezekkel együtt növekszik. A korai tesztesetek bevezetése segíti, hogy a követelmények mérhetőek, tesztelhetőek legyenek. készülhet speciális eszközökkel, adatgenerátorral, szimulátorral

45 Test cases Ha már a design kész és a funkciók is be vannak azonosítva, megadhatóak tesztesetek. Ezeket logikai alapon nagyobb csoportba lehet rendezni –ha a követelmények is csoportosítva voltak vmilyen szempont szerint, ezeket is hasonlóan lehet

46 Teszt adat A teszt adatok célja, hogy biztosítsa a szoftver helyesen, a követelményeknek megfelelően működik ezért a lehető legnagyobb spektrumot le kell fedniük legális/illegális bemenetekre. előidézni a helytelen működésre adott válaszokat

47 Test procedures Tartalmazza az elvárt és kapott eredményeket Ezekből összegzést, elemzést készít Kulcs, hogy meghatározzuk eredményes volt-e a tesztelés

48 10.4. Felhasználói dokumentáció

49 A legjobb szoftver is használhatatlan, ha a felhasználó nem tudja hogyan kell használni nem csak user guide, tartalmazhat –fejlesztési –tréning –verzió leírásokat is Instrukciókat ad a végfelhasználónak mit, hogyan használjon

50 Input requirements Megadja milyen bemenő adatokra van szüksége a rendszernek –adat formátum –helyes értékhatárok –input schedule Honnan jön az adat? –regiszter, billentyűzet, DB Mikor kell az adat? –minden kedd, amikor bekéri

51 Output description hogyan értelmezzük a nem standard kimeneteket –error msg, hibás leállás

52 Operation instructions A rendszer működésének laikus leírása –hogy tölt be –milyen adattároló, periféria kell gyors nyomtató, online HDD –rendszer leállítása ha kész a művelet Nagyobb rendszereknél operation manual ált. az egyszer installáltak önellátóak

53 Továbbfejlesztés a forráskód, objektumok listázása as-built dok. minden a fejlesztést segítő dok.

54 10.5. Tréning dokumentáció

55 ha szükséges fejlesztői v felhasználói tréning komplex fejlesztés esetén, ha valaki nem gyakorlott –prog. nyelv, környezet –adott projekt környezete orvosi, könyvelés

56 10.6. Dokumentálási standardok

57 Mivel sokféle szabvány közül választhatunk, az első és legfontosabb, hogy megadjuk a dokumentációk szabványait nem csak szoftverre kell dok. –pl. IEEE (30.o.) a Nemzetvédelmi minisztérium és a NIST (Nat. Inst. of Standards) többféle szabványt is kiadott ezek néhány esetben 1:1-ben átvehetők, de legtöbbször testreszabni kell

58 Összegzés

59 a dokumentáció célja, hogy végigkövesse és dokumentálja az SLC minden részletét –CM –fejlesztés –teszt –user dokumentáció útjelző: előre – vezet a célhoz, vissza - rekordok

60 SDP: menetrend mikor, mit hogyan SQSP: minőségi szoftver –támogassa a menedzsment és a fejlesztők Kulcs a pontos, érthető követelmény specifikáció

61 Köszönöm a figyelmet!


Letölteni ppt "Szoftver dokumentáció Roskó Tibor. Dokumentáció: a felhasználói igények átfordítása, hogy az adott program megfelelő legyen működés és felhasználói szempontból."

Hasonló előadás


Google Hirdetések