rogramozás

1. rogramozás ódszertan Endrődi Tamás

2. A Vasa és a Kronan • Nem volt írásos specifikáció • Nem mondtak nemet • A felhasználót nem vonták be • Díszítéssel ment el az idő nagy része • Más technika kell egy nagy programhoz

3. Élelmiszerbolt • Vonalkódolvasó helyett kézi beírás • Numerikus azonosítók fejből • Sorbanállás • Ellenpélda (ha áram van, minden van!)

4. Bankjegykiadó automata • Négyjegyű kód + összeg • Kártya+pénz+papír • Négyjegyű kód + nyitó menü + összeg • Kártya+pénz+papír(?) • Kód + nyitó + összeg + újabb menü • Pénz, de a kártya NEM!

5. A szoftverkészítés célfüggvényeinek megváltozása • Adatfeldolgozás • Viszonylag primitív műveletek és algoritmusok • Típusfeladatok • Kliens/szerver és többágú rendszerek elterjedése • Gyors és olcsó kivitelezhetőség • Sok hardverhez sok szoftver kell • Nincs idő egy-egy programmal hónapokat "vacakolni" • Tömegtermelés

6. A szoftverkészítés célfüggvényeinek megváltozása • Könnyebben módosítható, továbbfejleszthető és karbantartható programok • Az adatfeldolgozásban nagyok a változások • Sablonjelleg fontossága • Koncepció és szabványok alkalmazása

7. A szoftverkészítés célfüggvényeinek megváltozása • Megbízhatóság • "Fault-tolerant" rendszerek elterjedése HW téren • Tranzakciókezelés alkalmazása SW területen • A precíz gyártás és a pontos, részletes tesztelés szerepe megnő • Adatvédelem • Nyílt rendszerek védelme az illetéktelen hozzáférés elől

8. Strukturált módszer • Koncepciókészítés (Survey) • Analízis • Tervezés (Design) • Adatbázis (adatmodell) • Felhasználói interfész (ez a legnagyobb rész) • Funkcionális mag (üzleti logika) • Implementáció • Tesztelés

9. Rapid prototípus módszer • Rapid analízis • Prototípus készítés • Tervezés (Design) • Hangolás (Tuning) • Tesztelés • Implementálás • Iteráció a 2. ponttól kezdve

10. Mi a baj a prototípussal? (1) • Könnyen elkészíthetőnek és módosíthatónak kell lennie • A papíralapú tervnél nem tud semmi egyszerűbb lenni • El kell dobni a végén!!! • Sajnos a legtöbbször "termékké csiszolják" • A rapid development csapdája: hamar mutatunk valamit, de közel nem azt, amilyen a végtermék lesz • A prototípust is meg kell tervezni • Helyes sorrend: 1=tervezés, 2=implementálás • Helytelen sorrend: 1=implementálás, 2 újabb verzió implementálása

11. Mi a baj a prototípussal? (2) • A prototípus konfliktus • A felhasználó pontos visszajelzéséhez szinte teljesen funkcionálisan működő program kell • "Ez csak prototípus, az élesben működni fog!?" • A SW specifikációt nem helyettesítheti egy jól működő prototípus sem. • Legtöbbször akkor jön elő, amikor meg kell mutatni, milyen jól áll az adott SW fejlesztése • Pontosan megfogalmazott cél kell, hogy mit akarunk elérni a prototípussal!

12. Milyen a jó prototípus • Meglévő programokból indul ki. • Nem igényel külön munkát, azt mondjuk pl. hogy a csoportkiválasztás úgy fog működni, ahogy a Customize Toolbar működik a Windows-ban • Nem árt, ha sok SW-t nézeget az ember • Papír alapú prototípus • Könnyű elkészíteni és módosítani • Nem kell egy vonalba húzni és méretezgetni a controlokat • A felhasználó is kénytelen a tervet értékelni, és nem hasra esni egy vizuális látványtól • Nem funkcionális, korlátozott • Csak a kritikus részek • Bemutató a felhasználó bevonásával • Forgatókönyv

13. A múlt 5 4 1 3 2

14. A múlt szlogenje Gépidő végén Elhull a virág, eliramlik a gépidő Jöjj kedvesem, add a jobodat ide. Ki most kártyáidat kezembe tevéd le Holnap nem omolsz-e listád fölibe?

15. A jelen és a jövő

16. Felhasználócentrikus módszer • Igényspecifikáció • Rendszeranalízis (OOA) • Felhasználók elemzése • Felhasználói feladatok • Objektummodell • Rendszertervezés • Metafora tervezés • Grafikus felhasználói interfész tervezés • Környezetfüggő interfész tervezés • Implementálás

17. Vision-centered UI design • A felhasználó bevonása fontos, de nem ő definiálja a UI-t • A szélsőséges User-centered UI olyan, mint a halcentrikus akvárium tervezés. Igen nehéz lenne a haltól megkérdezni, mi lenne jó neki! • A felhasználó amúgy is hajlamos önmagát okolni a UI helyett.

18. A felhasználók elemzése • Szerepkör • Szervezeti különbség • Számítástechnikai tudás • Az adott tématerület ismerete • Gyakoriság

19. Szerepkör elemzés • Jogosultsági kérdések • Hozzáférés, elérés, láthatóság • Új adat felvitele • Meglevő adat módosítása • Meglevő adat törlése • Egyszerű helyzetben 2-3 szint • Főnök • Alkalmazott • Külső szemlélő

20. Szervezeti különbség • Ritkán okoz problémát • Számlázásnál pl. érdemes külön szerepkörnek venni a bejövőt és a kimenőt.

21. Számítástechnikai tudás • Kezdők • On-line segítségre szorulnak • Sok hibával dolgoznak • Gyakorlottabbak • Kevesebb hiba, ritkább help használat • Profik • Gyorsbillentyűk, rafinériák használata

22. Az adott tématerület ismerete • Kezdők • A tématerület magyarázata • Sok hiba, helyreállíthatóság • Gyakorlottabbak • Kevesebb hiba, ritkább help használat • Profik • Összetett, bonyolult műveletek kellenek

23. Alkalmazási gyakoriság • Alkalmanként használók • Nem fognak fejlődni • Gyakran használók • A kezdőből profivá válnak idővel

24. A felhasználói feladatok elemzése • GOMS módszer • Goals (Célok) • Operators (Műveletek) • Methods (Metódusok) • Selection Rules (Kiválasztási szabályok) • Cognitive Complexity Theory (CCT) • Task-Action Grammar (TAG)

25. Az objektum modell elemei • Objektumok • Elsődlegesek vagy másodlagosak • Nyelvtani elemzés szerepe • Az attribútumok szétválasztása az objektumoktól • Objektumok közötti kapcsolatok • 1:1, 1:N vagy N:M fokú kapcsolat lehetséges • Egyirányú vagy kétirányú

26. Az objektum modell elemei • Attribútumok • Tématerületi ismeretek kellenek • Csak a nélkülözhetetleneket szabad összeszedni • Származtatott attribútumok is kellenek - pl. alternatív nézet miatt • Műveletek • Ezekkel lehet lekérdezni vagy megváltoztatni az objektum állapotát

27. Az objektum modell elemei • Attribútum arculat • Kezdőérték • Lehetséges értékek halmaza • Alternatív nézetek • Tárgyi eszköz műszaki és számviteli adatai • Szín megjelenítés • Konténer objektum többféle rendezettségben

28. Az objektum modell elemei • Osztályok • Azonos műveletek, azonos attribútumtípusok és arculatok, azonos alternatív nézetek • Aggregátum és konténer osztály • Alosztály, főosztály, absztrakt osztály

29. Metafora tervezési szempontok • A felhasználói tapasztalat szerepe • Strukturáltság • Szelektivitás • Bővíthetőség • Konzisztencia és koherencia

30. Metafora tervezési korlátok • Tág forrásmetafora • Szűk forrásmetafora • Eltérő felhasználói tapasztalat

31. Felhasználói interfész fejlődési szintjei • Main-frame számítógép interfész • Parancssor interfész • Menüvezérelt rendszerek • Grafikus felhasználói interfész (GUI) • Alkalmazásorientált helyett adatorientált lett • Grafikus tervező szakemberek igénybevétele • Funkcionalitás helyett a könnyű használhatóságon van a hangsúly

32. A távirányítók fejlődése • 1. Meglévő technológiára épül • Olyan gombok és doboz, ami már létezik • Egyfajta gombok • 2. Javított elrendezés • Még mindig a meglévő technológiára épül • Kétféle gomb és több szín • 3. Új technológia • A gomb sugallja, hogy mire való • Hiba elleni védelem (pl. a felvétel két gomb)

33. A távirányítók fejlődése • 4. Az új technológia túllihegése • Űrhajó vezérlőpultjához hasonlít • Többféle alakú, színű és viselkedésű gombok dzsungele • Bizonyítani akarták, hogy mi mindent tud a masina. • 5. A felhasználó céljaihoz való visszatérés • Csökkentett bonyolultság • Rejtett gombok • Nem túl sok szín és gombfajta

34. Hadd tegye a felhasználó AZT, amit akarAKKOR, amikor akarja ésÚGY, ahogy akarja! Példa1 Példa2

35. Rugalmasság (Flexibility) • Felhasználói kompatibilitás • Dialógus kezdeményezési mód • Számítógép által kezdeményezett • Felhasználó által kezdeményezett • Munkafolyamat kompatibilitás • Többszálú dialógus • Többdimenziós, multimodális rendszerek

36. Rugalmasság (Flexibility) • Taszk vándorlás • Kooperatív feldolgozási mód • Helyettesíthetőség • "Ami látható, az használható is legyen" • Az interfész testreszabása • Adaptálhatóság • Adaptivitás

37. Könnyű megtanulhatóság • Egyszerűség • Limitált funkciómennyiség • Könnyű elindulás • A tervezési folyamat = az UI egyszerűsítése • Szükségtelen ablakok kiiktatása, dialógusok és üzenetdobozok megszüntetése, stb. • Ismerősség • Korábbi ismeretanyagra támaszkodjon • Megjósolhatóság • Termék kompatibilitás • Taszk kompatibilitás • Konzisztencia

38. Donald A Norman mondja: • "Ha legközelebb találkozunk egy ismeretlen objektummal, és elsőre könnyen kezelni tudjuk, akkor álljunk meg és vizsgáljuk meg: a könnyű kezelhetőség ugyanis nem lehet véletlen:Valaki profi módon megtervezte ezt az objektumot!!"

39. Robosztusság • Nyomonkövethetőség • Böngészési lehetőség • Kiválasztási lehetőség • Tartósság (persistance) • Helyreállíthatóság • Előre • Vissza • Arányos fáradozás elve • Válaszadási készség • Válaszidő stabilitása

40. Robosztusság (Preview) • Icon (konstans bitmap) • Word-ben a szövegigazításra a toolbar gombok • Absztrakt (változó bitmap) • Témák bemutatása Frontpage-ben • Minta (adat is van benne) • Font beállítás a Word-ben • Közelítő replika • Animáció lejátszás a képernyővédőknél • Pontos replika • Print Preview

41. Robosztusság (Default) • Az utolsó állapot visszaállítása • Egy dialógus az utoljára beírt adatokat tartalmazza • Kivétel a nyomtatások száma, ha pl. 58 volt • Alapértelmezés • Veszélyes akció ne legyen default • Sokszor a user által bevitt utolsó (első) adat • Pl. Word-nél az első sort kínálja fel filenévnek • Nem feltétlenül statikus adat (de lehet, pl. darab=1) • Default csoport alkalmazása • Pl. Egy következő csekknél nem az előző csekkből, hanem az adott díjtétel előző csekkjéből származhat a default

42. Default tanácsok • Jó, ha a user meg is tudja változtatni • Komoly döntéseknél ne legyen default, vagy szükséges legyen user beavatkozás is • Rossz példák default-ra: • Windows kikapcsolásakor Restart után újra Restart • Word-ből kilépve üzenet helyett menteni kellene. Csak a profi user érti a különbséget a memória és a lemez között. A user azt hiszi, hogy amit beírt a Kakukk.Doc-ba, az ott van. Ehhez kellene egy "összes módosítás eldobása" gomb.

43. Színek használata • Világos háttéren fekete szöveg Dolgozó neve: Kis Péter Dolgozó neve:Kis Péter

44. Színek használata • A kék szín alkalmatlan információközlésre Dolgozó neve: Kis Péter Dolgozó neve: Kis Péter

45. Színek használata • Kevés, jól elkülöníthető szín kell Ez egy súlyos hiba Ez egy figyelmeztetés Ez egy súlyos hiba Ez egy figyelmeztetés

46. Színek használata • Piros=vészhelyzet • Zöld=normál helyzet • A színen kívül más jelzés is kell

47. Hanginformációk • Kikapcsolható legyen! • Puritán egyszólamú síp • Beszédkommunikáció lehetősége • Van, aki szerint pozitív hangjelzés (pl. lágy "cool") is lehet (Alan Cooper)

48. Gyümölcselemzés - Alma • Ismerősség – jó • Megjósolhatóság – közepes (kukacok!) • Könnyű kezelhetőség – közepes • Mosni kell • Késre és/vagy jó fogakra van szükség • Nincs éles határ a csuma és a lényeg között • Robosztusság – jó • 1-2 alma jó kalóriát adhat

49. Narancs - Citrom • Ismerősség – jó • Megjósolhatóság – gyenge (magok!) • Könnyű kezelhetőség – közepes/jó • Pucolni kell • Robosztusság – jó • 1-2 narancs jó kalóriát adhat • A citrom viszont piszok savanyú

50. Gyümölcselemzés - Kókusz • Ismerősség – közepes/gyenge • Megjósolhatóság – jó • Könnyű kezelhetőség – gyenge • Komoly fegyver (bárd?) kell hozzá • Robosztusság – közepes • ?