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ó

2 Dokumentáció Egy korszerű dokumentáció ábrákat, hang és video anyagokat tartalmaz és a szöveges leíró részét hypertext formátumban is olvashatja a felhasználó. Vannak olyan részek, amit on-line a program futása közben is el lehet érni (on-line súgó).

3 Dokumentáció típusai Műszaki (technikai) – a fejlesztő számára
Felhasználói – üzemeltető számára

4 Tesztrendszer specifikáció
Szinte lehetetlen hibamentes programrendszert készíteni, ezért fontos a tesztelési dokumentáció. A tesztelést végző személyek szempontjából 3-féle esetet különböztetünk meg: Szoftverfejlesztői tesztelés Független személyek általi tesztelés Felhasználói tesztelés

5 Szoftverfejlesztői tesztelés
Elemi egységet tesztje (unit teszt), ami a metódusok (eljárások, függvények) tesztje. Gondoljunk csak egy házépítésre, nem mindegy milyen alapanyagokból építkezünk. Az objektumorientált rendszerekben az öröklés miatt egy ősosztályban maradt hiba végzetes lehet a programra nézve!

6 Szoftverfejlesztői tesztelés
Programteszt a következő lépés. Egy alkalmazás többnyire több programból áll. A programok az elemi metódusok halmaza, amely egy részfeladat megoldását végzi. A programteszt, így az adott részfeladat tesztelését végzi.

7 Szoftverfejlesztői tesztelés
Rendszerteszt. Különösen fontos az egyes részfeladatok kapcsolódásának ellenőrzése, miután itt kerül sor elsőként az alkalmazás tesztelésére. Itt kell megvizsgálni, milyen az alkalmazás kapcsolata az operációs rendszerrel és a külvilággal.

8 Független személyek általi tesztelés
A minőségbiztosítási tesztet csak az erre a célra létrejött cégek végezhetik, valamilyen speciális automatizált módszerrel. Ez azonban elég drága mulatság! Ennek hiányában valamely rendszerfejlesztő kollégát érdemes megkérni a tesztelésre. Saját programot soha ne csak saját magunk teszteljünk!!!

9 Felhasználói tesztelés
Ide már csak a korábbi tesztek elvégzése után juthat a programunk. Mivel manapság már a szoftverfejlesztési életciklusban szinte a kezdetektől ott van a felhasználó, így részt tud venni ebben a tesztelésben is. A szoftverfejlesztő és a felhasználói teszt így nem különül el időben, hanem párhuzamos futhat. Felhasználó szemszögből 4 fázisra bontható

10 Felhasználói tesztelés
Prototípus A teljes prototípusnak menühierarchiát, adatmegjelenítést és néhány fontosabb jelentést kell tartalmaznia.

11 Felhasználói tesztelés
Alfa teszt Ha a felhasználó elégedett a prototípussal, akkor lehet azt tovább csiszolni és a funkciókat bővíteni rajta, ez az alfa teszt. Közben a felhasználók tesztelik és közlik a véleményüket. Olyan, mint amikor egy macska a saját farkát kergeti!!!

12 Felhasználói tesztelés
Béta teszt Ez az a fázis, amikor az új verzió készítése során a szoftverfejlesztő több időt tölt a felhasználó által detektált hiba javítására, mint az új elemek beépítésére. Közben történhet a kódhatékonyság vizsgálat, valamint a tipográfiai és kozmetikai finomítgatások is zajlanak.

13 Felhasználói tesztelés
Elfogadási teszt Ha a felhasználó aktív szerepet játszott a rendszerfejlesztés során, akkor csak formalitás. Ekkor már ismerni fogja a rendszer képességeit és korlátait!

14 Tesztelési terv Olyan forgatókönyvszerű dokumentáció, amelyből kiderül, hogy mit, milyen módon és milyen környezetben fogunk tesztelni, ki fogja a tesztelést végezni, mit várunk eredményként és a tesztelés végeztével mi a tényleges eredmény. Elemei: Program logika ellenőrzése Felhasználói interfész működése Adatbekérés ellenőrzés (érvénye, érvénytelen, félig kitöltött adatokkal) Különféle output adatok (lista, output állomány) tartalma

15 Felhasználói dokumentáció
4 részből állhat: Felhasználói útmutató Oktató kézikönyv (tutorial) Referenciakártya On-line segélyrendszer

16 Felhasználói útmutató
Egy teljes körű és részletes leírás arról, amit a felhasználónak ismernie kell az alkalmazás működtetéséhez. Enélkül ma már egy egyszerű hajszárító sem lehet eladni!!! A felhasználói útmutató szerkezeti felépítése leginkább egy szakkönyvhöz hasonlítható.

17 Felhasználói útmutató
Részei: A dokumentáció eleje (azonosítók, jogosultságok, tipográfiai formázási konvenciók, tartalomjegyzék, ábrajegyzék és bevezetés) Installálás bemutatása (alkalmazás futtatásának hardver és szoftver követelményei valamint a telepítés lépései)

18 Felhasználói útmutató
A tartalmi fejezetek (rendszerfunkciók részletes bemutatása képernyőképekkel, a szoftvertervezéskor használt objektummodell jó alap lehet ehhez, pl. osztályokra bontva tárgyaljuk, rendelés-nyilvántartóban külön van a rendelés és a partner) Hibaüzenetek függeléke és adatszótár (az adatszótár a műszaki dokumentációban szereplő adatszerkezeti információk részhalmaza, ami a felhasználók számára fontos, itt szerepelhet, hogy kit kell keresni probléma esetén)

19 Oktató kézikönyv Főleg kezdő felhasználóknak nagy segítség. Mintapéldák segítségével magyarázza el egy-egy funkció használatát lépésről lépésre! Ez inkább problémaorientált, míg a felhasználói útmutató funkcióorientált!

20 Referenciakártya A gyakorlottabb felhasználók kedvelt eszköze. Nem magyarázza el a dolgokat, csak emlékezteti a felhasználót az egyes funkciók illetve parancsok pontos végrehajtási szintaktikájára. Hajtogatott változatban vagy billentyűzetre ragasztható csík formájában szokott készülni!

21 On-line segélyrendszer
A program futása közben is elérhető szöveges, hang és video információkat tartalmazza. Teljes körűsége és problémaorientált jellege révén ötvözi a felhasználói útmutató és az oktató kézikönyv előnyeit. A hypertext formátuma révén még népszerűbb lett a felhasználók körében!

22 On-line segélyrendszer
Mivel kell rendelkezniük? Állandó rendelkezésre állás (nem kell kilépni a felhasználónak a programból, hogy elérje) Naprakész és pontos legyen (kövesse a verzióváltást) Teljes körű legyen (valamennyi funkcióhoz nyújtson segítséget) Konzisztencia (a különféle segítő információk egységes terminológiát tükrözzenek)

23 On-line segélyrendszer
Mivel kell rendelkezniük? Rugalmasság (minden felhasználó ugyanazt a segítséget kapja, pedig lehetne követni, hogy milyen szintű dolgokhoz kér segítséget a felhasználó és más más szintű segítséget lehetne neki adni) Ne legyen tolakodó és erőszakos (ne szóljon bele a munkánkba kérés nélkül, csak akkor szóljon, ha kérjük)