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.

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

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.

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

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.

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!

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.

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.

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

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

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

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.

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.

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

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

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

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

10.2. Fejlesztési dokumentumok

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ó

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.

10.2.1. Követelmény specifikáció

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

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

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

10.2.1.1. 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!

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!

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

10.2.1.4. Complete Mindent dokumentálni kell!

10.2.1.5. 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

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

10.2.1.7. 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

10.2.2. Design specifikáció

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.

10.2.2.2. 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.

10.2.2.3. 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.

10.2.3. Egyéb dokumentációk

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ó.

10.3. Tesztelési dokumentáció

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.

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.

10.3.1. 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

10.3.2. 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

10.3.3. 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

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

10.4. Felhasználói dokumentáció

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

10.4.1. 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

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

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

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

10.5. Tréning dokumentáció

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

10.6. Dokumentálási standardok

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

Összegzés

ú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

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ó

Köszönöm a figyelmet!