Szoftver dokumentáció

Az előadások a következő témára: "Szoftver dokumentáció"— 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 10.1.1. 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 10.1.3. 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 10.1.4. 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 10.2.1. 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 10.2.1.2. Traceable - Visszakövethető
Minden követelményt úgy kell dokumentálni, hogy fejlesztéskor, teszteléskor visszakövethető legyen honnan hová jutottunk el!

29 10.2.1.3. 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 10.2.1.6. 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 10.2.2.1. 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 10.3.4. 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 nem csak user guide, tartalmazhat
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 10.4.3. 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 10.4.4. 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 nem csak szoftverre kell dok.
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 útjelző: előre – vezet a célhoz, vissza - rekordok
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!