Önálló labor beszámolókról, dokumentációkról

Mottó: mindig tudd, mi az elérendő cél, milyen megoldást választasz, milyen szempontokat vettél figyelembe és hagytál figyelmen kívül, és milyen alternatív megoldások vannak. Mindig vizsgáld meg a egy munka környezetét, történetét, azonosítsd a motiváló és fékező erőket.

Általános tudnivalók az önlab hátteréről, mérnöki gondolkodásmódról, elvárásokról

Az önálló labornak többrétű célja van. Egyrészt a labor annak előkészítése, ami közvetlenül az egyetemi végzés után vár(hat) a hallgatókra. Először kell „éles" feladatokon egyedül, csakis egyedül dolgozni, nagyobb (de komolyabb tét nélküli) mérnöki problémákkal találkozni. Éppen ezért mindenki itt és most sajátíthat el olyan nagyon-nagyon fontos készségeket, mint

• a szakirodalom feltérképezése, hozzáférési módok alkalmazása
• a szakirodalom megfelelő hatékonyságú olvasása, feldolgozása (state-of-the-art pontos meghatározása)
• megoldott, megoldható, nem megoldott és nem megoldható problémák azonosítása életszerű problémák esetében
• egy probléma célszerű, gyakorlatilag használható megragadása, feldolgozási módszertanának létrehozása és/vagy gyakorlása
• összetett probléma mérnöki elemzése, mérlegelési pontok, döntési helyzet detektálása
• helyzetek, termékek, problémák pontos értékelése, pozitívumok és negatívumok objektív, széleskörű meghatározása
• összetett, szerteágazó informatikai rendszer tervezésének gyakorlása
• informatikai rendszer szereplőinek, gondolkodásmódjuknak, egyedi igényeiknek és konfliktusainak megértése
• összetett rendszerek (részeinek) implementációja, és ezen keresztül
• annak meghatározása, hogy a tervezésben személy szerint milyen pontatlanságokra kell odafigyelnünk, melyek a tervező korlátai
• szakszerű és tényszerű dokumentáció írásának elsajátítása
• szoftvereszközök (közvetlenül hasznosítható tapasztalatok) mély ismerete, vagy ismeretek szélesítése/mélyítése
• szövegszerkesztők üzemszerű, szakszerű alkalmazásának fejlesztése
• a tanult mérnöki eszköztár valós problémákon való első összetett alkalmazása
• szabványok megismerése, alkalmazása
• szabatos kifejezések elsajátítása, mérnöki mondatszerkesztés, formalizmus, és általában a mérnöki kommunikáció fejlesztése

Természetesen, ezekkel nem külön-külön, hanem konkrét élethelyzetből kiragadott problémákon keresztül -- egyfajta mellékhatásként -- gyakorlunk, elsajátítunk. Éppen ezért minden önálló labor mindig hármas céllal indul:

• szeretnénk elérni, hogy az iparban közvetlenül hasznosítható ismeretekre tegyél szert
• minden félévben írj dokumentációt, amely az aktuális félév szakmai anyagait tartalmazza minél kimerítőbb formában
• minden félévben írj egy rövid beszámolót, illetve prezentációt, ahol a saját munkádat pozícionálod, értékeled

Fontos még megemlíteni, hogy milyen kritériumok azok, amelyek alapján Téged mint mérnököt megítélnek. Általában igaz az, hogy aki mérnöki diplomát szerzett, az várhatóan egy adott problémát meg tud oldani, jártas egy fejlesztői vagy működési környezetben, valamilyen piacképes szaktudással rendelkezik. Két mérnök (és fizetése) között az a különbség, hogy az egyik mennyivel sokoldalúbban, előrelátóan, hosszabb távon is fenntartható módon képes egy problémát lényegében azonos feltételek mellett megoldani. Vagyis nem attól jó egy mérnök, hogy egy feladatnak nekiesve eredményre jut -- ezt már szakiskolai tudással, sőt tanfolyamokkal is el lehet érni. A megoldás, ahogy a zárthelyiken is láthattátok, csak elenyésző része a problémának, a körülmények, indoklások sokkal fontosabbak. Ha valakinek megoldása olyan, hogy az a környezeti változások, fejlesztések mentén is gyorsan, egyszerűen javítható, könnyen módosítható, kiterjeszthető, esetlegesen gyorsabb, kompaktabb, egyszerűbb, pontosabb másokénál és -- nagyon fontos, mert eddig ezt kevéssé hangsúlyozták -- a felhasználók jobban kedvelik, az az igazán jó. Az ilyen megoldás több profitot jelent, ez pedig a szakembernek magasabb jövedelmet eredményez inkább előbb, mint utóbb. Éppen ezért szeretném azt nagyon nyomatékosan jelezni, hogy a legegyszerűbb feladatot is érdemes sokoldalúan elemezni. Ha most nem szoksz rá, később már nem fogsz.

Egy másik tipikus téveszme, hogy a szoftver felhasználói ismeretével, programozhatóságával valaki megelégszik. Itt hívom fel a mérnökjelöltek figyelmét arra, hogy elvben a programozási szakokon, a szoftver tanfolyamain sokkal szélesebb körben lehet elsajátítani ezen ismereteket, ezekkel -- normális körülmények között -- nem tudtok érdemben versenyezni, de nem is érdemes. Sokkal fontosabb a szoftverhasználat kellően alapos szintű ismerete mellett az, hogy ismeritek az alternatívákat, a kockázatokat, a gyenge pontokat, és nagyon nem utolsó sorban a szoftver általános működési (akár elvi, akár fizikai szintű) mechanizmusát. Nektek arról kell majd tudni mérnökként felelősen dönteni, hogy egy adott szoftvert egy intézmény bevezessen-e, mikor tegye és mikor ne tegye; pontosan kell tudnod specifikálni az adott probléma megoldásához szükséges eszközöket; tudnod kell, mit várhatsz el egy programozótól és mit kell mondanod neki, hogy pontosan azt tegye, amit specifikálni szándékoztál; előre számolnod kell, vagy fel kell hívnod a figyelmet arra, hogy milyen járulékos költségek és feladatok valószínűsíthetőek egy eszköz alkalmazása esetén; hogyan függ a még papíron sem létező rendszer működni egy adott intézmény és felhasználói szempontjából. A sor, persze, még hosszan folytatható lenne, de azt hiszem, az alapeszme már ebből is érzékelhető.

Fel szokott merülni még egy jellemző mérnöki probléma, különösen friss végzősök esetében -- a túloptimalizálás. Az első félévben nem, de a rendszertervezés kapcsán ez már előjöhet. A betegség nagyon általános, és abból táplálkozik, hogy elfelejtik a mérnökök az idő változóságát. A matematikus a problémát időtlen módon kezeli, ennek megfelelően ad rá megoldásokat. Sajnos, az egyetemen a matematikai látásmód erőltetése nagyon jellemző, ennek nyilvánvalóan vannak pozitívumai is, de negatívumai is. Fontos azonban észrevenni, hogy bármilyen mérnöki alkotás nem egyszeri, nem örökös, és főleg nem állandó. Aki egy konkrét feladatot mindig optimalizál, annak a megoldása az igények változó volta miatt módosíthatatlan marad -- többnyire újra kell írni az egészet az elejéről. A mérnöki szempontból ideális az a megoldás, amely az optimális közelében van a problémakört tekintve, de kellően egyszerű és moduláris ahhoz, hogy bármilyen változás esetén, kevés munkával továbbra is az optimum közelében maradjon. Más szavakkal: a fejleszthetőség, a fenntarthatóság és az optimalitás között kell megtalálni az egyensúlyt. Pontosan az ilyen megoldások megtalálása érdekében fontos ismerni és érteni egy-egy matematikai konstrukció gondolatiságát (függetlenül annak végeredményétől, konklúziójától).

Látnod kell azt is, hogy egy konkrét probléma kapcsán nincsen segítséged, hogy melyik tananyag, melyik zárthelyi-kérdés, vagy melyik info-site lap segít a megoldásban. Egyedül maradsz, tele mindazokkal az ismeretekkel, amelyeket -- remélhetőleg -- itt az egyetemen beléd vertek. A túlélési ösztön csodákra képes, persze, de szerencséje is csak annak van, aki alaposabban tanult a többieknél. Minden probléma, új kihívás esetében gondoljatok arra a kérdésre, hogy találkoztam-e már hasonló problémával? A nem kellően felkészült mérnök azonban csak azt látja, hogy pl. most egy tőzsdei rendszert kell bevezetnem, gazdasághoz nem értek, tehát haszontalan az egyetemi tudásom. Ugyanakkor ha a problémát megfelelően absztrahálná, magas szinten elemezné a helyzetet, akkor bizony felfedezné, hogy a példában szereplő tőzsdei rendszerhez pl. nagyon jól használhatóak a Információelmélet (sorbanállási modellek, Markov-modellek), a Számítógépes grafika (pl. mozgáskövetés!!), Jelek és rendszerek (szabályozó körök viselkedése, visszacsatolás modellálása), Szabályozástechnika (fázistartalékok vezérlésekben, ideális vezérlés megválasztása) egyes elemei. Igen, ezek mással foglalkoztak, de alapvetően ugyanannak az eszköztárnak a különböző problémakörre vetített vetületei. Éppen ezért kérek mindenkit, hogy figyeljen oda a tárgyakban nem csak arra, hogy konkrétan milyen probléma merül fel az órákon, hanem arra is, hogy milyen általános feltételek mellett milyen eszközparkot lehet bevetni egy problémakör leküzdésére.

Beszámolók formai követelményei

Mindenképpen olvasd el először az általános dokumentációírási szabályokról szóló jegyzetet.

Minden tárgynak, tárgyfelelősnek (és témavezetőnek) megvannak a maga rigolyái, kedvenc vesszőparipái. Hogy milyen formában kell beadni a dokumentumot, azt mindig a tárgyfelelős (munkáltató, főnök, vállalati irányelv) határozza meg. Kérlek, erről mindig időben tájékozódj a tárgy honlapján. A beadás lehet

• LaTeX alapú (sosem árt megtanulni)
• Microsoft Word alapú (óvatosan, bármikor elszállhat a dokumentum, a dokumentum hosszával arányos mértékben)
• OpenOffice alapú.

Jelenleg más technológia nem támogatott.

Rövid összefoglaló (külalak, terjedelem, irodalomjegyzék). Betűméret tipikusan 11pt, szimpla sorközzel írandó. Képeket, táblázatokat bármikor beszúrhatsz, ezeket sorszámozni kell, forrásukat (ha nem saját) jelölni. Minden képre és táblázatra hivatkozni kell. Ha valaki ezekre nem hivatkozik, akkor az úgy minősül, mintha díszítő elem lenne - erre pedig mérnököknél nincs szükség. Ne írj át fejlécet, láblécet, ne változtass előre definiált tartalomjegyzéken. A beszámoló hossza - ami a tárgyfelelősnek megy - mindig lehet rövidebb a kiadott oldalszámnál, de sosem lehet hosszabb.

Irodalomjegyzékben arab számokkal jelöljük általában a forrásokat, szögletes zárójelekkel határolva (pl. [1] ...). Az irodalomjegyzékbe csak olyan irodalom kerülhet, amit a szövegben hivatkoztál (tipikusan így: ...[1] vagy [2,3,4]). Minden egyebet az egyéb csatlakozó dokumentációk közé illik beírni. Termék (pl. www.google.com) sosem tekintendő irodalomnak - ezeket a hivatkozás helyén lábjegyzetbe szokás tenni. Csak az lehet irodalmi forrás, amelynek tartalma igazolt forrásból származik, megfelelően képzett személy vagy szervezet írta, vagy ismert személyek, szervezetek ellenőrizték és felelősséggel tartoznak annak tartalmáért. Szerzője egy dokumentumnak, irodalomnak mindig van - de ez nem feltétlenül természetes személy (lehet csoport, vállalat stb.). Éppen ezért - bár fontos forrás lehet a Wikipedia - tilos szakirodalomként hivatkozni rá. Minden dokumentumnak van keletkezési vagy utolsó módosítási ideje - ezeket mindig fel kell tüntetni. Ez még az URL esetében is kinyerhető. Legrosszabb esetben a letöltési idő adandó meg. Minden forrásról jelölni szokás annak típusát (pl. könyv, folyóiratcikk, konferenciacikk, vagy pl. white paper, kutatási jelentés, szabvány), ha ez egyébként nem derülne ki a leírásából. Ha a weben elérhető a Micimackó c. könyv pl. PDF formában, akkor nem az URL, hanem a könyv jellemző paramétere adandó meg, függetlenül attól, hogy hol találtad a könyvet.

Beszámolók tartalmi követelményei

Mindenképpen olvasd el először az általános dokumentációírási szabályokról szóló jegyzetet.

Rövid kivonat. Bár irodalom órán sokat meséltek arról, hogy hányféleképpen lehet egy prózai alkotást komponálni, a mérnökség e téren nagyon konzervatív, jó okkal. A mérnöki dokumentum szerkezete: felütés, tárgyalás, konklúziók. Minden dokumentum bemutatása (felütése) azzal kell kezdődjön, hogy mi ismert a világban, mi megoldott, hol áll a világ egy konkrét probléma kapcsán. Tehát a kérdés az, hogy mi az a probléma, amit ki akarsz pécézni Magadnak, és bemutatod, hogy a problémát más még nem oldotta meg (kellő hatékonysággal, vagy valamivel). Irodalomfeldolgozás esetében is kell legyen probléma (pl. hogyan oldják azt a bonyolult kérdést, hogy... milyen lehetőségeket kínálnak arra, hogy... milyen konkrét kérdéseket támogat és nem támogat egy ... rendszer - fantáziádra bízom). Ha a probléma, illetve a nézőpont már adva van, akkor jön a tárgyalás, amivel a problémát körüljárod, tényeket állapítasz meg, modelleket építesz (pl. tesztmodell!!), feltételezéseket teszel, amelyeket hellyel-közzel alaposan igazolsz, végiggondolsz. Végül a tények alapján konklúziókat vonsz le. A konklúzió rövid, tömör, velős, jól marketingelhető szöveg, ami nem tartalmaz semmilyen szubjektívumot.

Mit kell írni a tárgyfelelősnek?

Cél. A tárgyfelelős az összes hozzá tartozó szakirány dokumentációját kénytelen elolvasni, ami nem rövid, és nem hálás feladat. A háta közepére kíván egy olyan beszámolót, amely egy számára ismeretlen, rosszabb esetben számára teljesen érdektelen témában született. Meg se próbáld meggyőzni a téma szépségéről, mert ez nem csak értelmetlen, de felesleges is. A cél csak az lehet, hogy ő felelősen, biztosan és teljesen egyértelműen eldönthesse: Te megérdemled a laborért járó kreditet vagy sem, azaz kellően sokat dolgoztál-e a félév során. Más szavakkal: a beszámoló arról, hogy milyen nagy feladatot, milyen biztos kézzel és "mennyire rövid" idő alatt sikerült nem csak teljesíteni, de túlteljesíteni is.

Megoldás. A tárgyfelelős a könnyebb eligazodás érdekében sablont és méretkorlátot szokott bevezetni. Bármelyiktől való eltérés főben járó bűn, eszedbe se jusson. A félévi munka prezentálása a szakszerű dokumentációírás mellett arra terjed ki, hogy

1. milyen készültségi foka volt a munkának a félév elején (vagyis mások munkáját folytattad -- ha igen, akkor írd le mi állt rendelkezésedre --, vagy teljesen új témát kezdtél)
2. milyen munkákkal telt a félév 14 hetének megfelelő időszak - lényegében prózai szövegben megírt felsorolás
3. milyen eredményekre jutottál (ez valahogy mindenki szereti kihagyni, de tilos!!!)
4. és ezen eredményekből milyen következtetésekre, értékelésekre jutottál.

• A bónusz feladat -- ezt én kérem általában, nem kötelező, de nagyon-nagyon melegen ajánlott -- az eredményeket számszerűsíteni (K oldal dokumentáció olvasása L szakcikkből, M oldal szakdokumentáció készítése H különböző dokumentumban, P programsor készítése, D óra konzultáció a témavezetőkkel, beleértve az emilre fordított időt is, S darab szoftver telepítése, U darab új eszköz, szoftver, prototípus, mütyűr létrehozása). Ez a rész azért ideális beletenni a beszámolóba, mert ebből a témavezető pontosan átlátja, hogy mekkora időráfordításod volt a félév során.

A beszámolót T időpillanatban kell leadni, akkor T - 3 munkanap legyen legalább arra, hogy a témavezető elolvassa, észrevételeit (ha vannak és egyetértesz vele) átvezesd a dokumentumra. Itt jegyzendő meg, hogy a témavezető véleménye nem kell, hogy befolyásoljon Téged. Te a saját bőrödet viszed a vásárra, csak Te felelsz a kapott jegyekért. Természetesen, a témavezető nem ok és tapasztalat nélkül mondja azt, amit mond, ezért megszívlelendőek a tanácsai, igazodni azonban nem kötelező, semmilyen negatív diszkrimináció nem ér majd emiatt (a témavezetőtől).

Nem csak az a mérnöki eredmény, ha valami megoldható, hanem az is, hogy ha valami nem(!). Utóbbit csak azért nem szeretjük, mert rossz hangulata lesz az embernek tőle, de legalább annyira fontos eredmény lehet ez is. Vigyázat azonban! Ha valami nem megoldható, akkor be kell tudni látni és láttatni, hogy ez nem az állítást megfogalmazójának ügyetlensége miatt nem megoldható, racionális érvek és tények. Nehogy kiderüljön, hogy pl. egy programozási nyelv egyik utasításának ismerete nélkül nem megoldható a feladat, de Te csak nem olvastad kellő mélységben a kézikönyvet.

Minden olyan fogalmat, technológiát, rövidítést be kell vezetned a beszámolóban is, amely nem a törzsanyag (alapképzés) része. A többiről feltételezheted, hogy ismertek, bemutatása akár zavaró is lehet.

Szempontok. Légy tárgyilagos, objektív, pontosan annyit mondj el, amennyit feltétlenül muszáj annak érdekében, hogy a tárgyfelelős szempontjainak eleget tegyél, és mindezt tedd a lehető legegyszerűbben (ez a legnehezebb!). A gondolatmenet legyen következetes és célirányos; ne legyenek mellékszálak. Használj bátran ábrát, ha környezetet írsz le, táblázatot, ha összehasonlítasz, prezentálsz eredményeket. Mindkettőt kellő mélységben, konklúziókkal együtt magyarázd. Csak az számít, hogy dolgoztál-e eleget, hogy milyen minőségben, az a témavezető megítélésére tartozik. Annyira van rutinos a tárgyfelelős, hogy ködösítés, elkenés, mellébeszéd, rizsa esetén felébred benne a gyanú, hogy át akarod verni. Márpedig az alvó oroszlánnak nem piszkáljuk a bajszát. Ha már gyanakodni kezd, akkor eláshatod Magad, mert majdnem minden állításodban kételkedni fog.

Retorikai szempontból az alábbiakra figyelj. Kerüld a feltételes módot, hiszen mérnöki szempontból a feltételes mondatok döntően érdektelenek (kivéve, ha a lehetőség fennállásának eshetőségeit is elemzed!). Ha lehet, csak állításokat mondj, de azt szabatosan, körültekintően. Sose próbálj értékítéletet mondani (valami jó vagy gagyi stb.); csak a tények beszéljenek, ne Te -- de ne félj kimondani az objektív konklúziókat. Az egy másik szakma, amikor véleményt formálhatsz -- mi csak tényeket közlünk. A saját eredményedet a beszámolóban bátran hangsúlyozd egyes szám egyes személlyel -- légy büszke az alkotásra, akkor hihetőbb, hogy az jó is. A mérnökségben nincs blöff, ha valami vacak, az messziről bűzlik, ilyen esetben, ha büszke vagy rá, leírtad Magad. Tehát nagyon légy büszke az eredményeidre, de csak a valós eredményeidre. Hangsúlyozd ki, hogy milyen nehézségeket oldottál meg konstruktívan (a megoldást a beszámolóban nem, attól elkülönülve célszerű tárgyalni). Aki a nehézségekben csak a hátráltatást, a munka ellehetetlenítését látja, annak panaszáradata viszont jó eséllyel visszaüt, mérnöki alkalmatlanságát fogja bizonygatni ezzel.

Alternatív megoldások. Fontos, hogy tisztában legyél az általad elvégzett munka értékével. Ha ez objektívan mérhető, tessék leírni - táblázatban, diagramokban stb.

Mit kell leírni a témavezetőnek (konzulensnek)?

Mit ne írjunk beszámolóba (elrettentő példák)

Az alábbiakban kifejezetten rossz megoldásokat fogok bemutatni - mindegyikhez odaírva zárójelben, hogy mi a baj vele. Kedvenc példáim azok közül, amit amúgy minden hallgató elkövetett már legalább egyszer élete során - beleértve magamat is; van köztük ugyanis saját forrás is:

* Tématerületemben a deduktív objektumorientált adatbázisok axiomatikus felépítésének megalkotásával foglalkoztam. (Egyrészt a mondat önmagában is horror, de az meg külön kiakasztó, hogy a szerző azt hiszi, mindenki érti azt, amit leírt. A beszámoló, a szakdokumentum nem IQ-teszt. Minden, alapképzésben nem szereplő fogalom bevezetésre, magyarázatra, értelmezésre szorul.)

* Három hétig küzdöttem a problémával, igaz volt közben jópár zh-m is, ami akadályozott az előrehaladásban. Ráadásul megbetegedtem... (Vélhetően az éjszakai alvás is akadályozott rövid távon, és még nagyon sok hátráltató körülményt lehetne felsorolni, de a beszámolóban, dokumentációban nem naplót kell írni, nem élménybeszámolót... Az egy másik műfaj, másik szakma. Használj ilyen célokra blogot!!)

* Kifejezetten pozitív élmény volt, amikor végre sikerült feltenni :). (Egyrészt nem rakunk smiley elemeket mérnöki szövegbe, nincs funkciója - igyekszünk komolyan venni a komoly munkát. Nem a tréfát utáljuk, csak a hely (forma, keret, tárgy, idő) nem alkalmas rá. Másrészt nem minősítünk mérnöki szövegben, csak tényeket közlünk. Ugyanezt meg lehetett volna úgy is fogalmazni, hogy pl. "A telepítés során számos hibával találkoztam. Ezek egy része ilyen és ilyen eredetű, egy része azért keletkezett mert, ..., a harmadikat a termék fórumai alapján oldottam meg. A telepítés összességében mintegy 13 órát vett igénybe." <- mindenki pontosan érezni fogja ebből, hogy mekkora munka, kitartás volt a telepítés, és a végén már a halálba kívántad a terméket és alkotóit.)

* ...kipróbáltam a .... szoftvert. (Pongyola, mérnöki szempontból visszataszító megfogalmazás. Próbálgatni ruhát lehet, egy játékot stb. Mérnökként szoftvert nem próbálgatunk. "Nem játszunk az étellel, meg akarjuk enni.")

* A félév során tanulmányoztam a .... irodalmakat. (Nincs olyan, hogy tanulmányoztam - ez egy tipikus elkenés, hiszen nem tartalmaz semmilyen tényszerű állítást. Mérnöki aggyal ez a mondat annyit jelent, hogy belelapoztál a könyvbe.)

* A blokkméret és a sebességeloszlás közötti összefüggést a 3. ábra mutatja. A tesztek azt mutatták... (Az ábrán amúgy számok, görbék, huplik és egyéb furcsa alakzatok láthatóak. Az ábrán látható mérésekről semmi nem derül ki a szövegben, az sem, hogy hogyan jött létre, mit mutat, mi a magyarázata a különböző ingadozó értékeknek stb. Minden ábra magyarázatra szorul - tényleg.)

* Kipróbáltam az X-Window környezetet is, de az még gyerekcipőben jár. (Tipikus esete annak, amikor a minősítés a visszájára sül el. Sosem minősítünk, nincs véleményünk, csak tényünk, következtésünk, érvünk. Jelen esetben az illető a véleményével tökéletesen minősítette - saját magát. Másik hiba, hogy próbálkozni vagy erőlködni nem mérnöki feladat.)

* Egy rendszertervben az alábbi mondatrészlet szerepelt: ...komponens magas szintű üzenetváltást is megvalósíthat. (A feltételes mód, ha az eshetőségek nincsenek számba véve, kifejtve, kielemezve, akkor teljesen értelmetlen a megállapítás. Mit jelent az, hogy egy komponens valamit megvalósíthat. Vagy megvalósít valamit vagy nem. Mi a dilemma tárgya? Miért feltételes mód? Ezzel azt érezteted az olvasóban, hogy bizonytalan van. A bizonytalan mérnök az olyan mint a vak ló. Haladni lehet vele, de nem mindig a jó irányba.)

* ...üzenetet küld az eltárolt felhasználóknak. (Szabatos fogalomhasználat tökéletes hiánya. Képzeld el, amint felhasználókat tárolunk el. A hibernált felhasználó üzenetet kap - de vajon hogyan fogja elolvasni? Természetesen ki lehet hámozni, mit akart az illető mondani, de a projektet tipikus buktatója az, hogy nem értik meg egymást a résztvevők. Törekedj arra, hogy világosan, szabatosan fogalmazod meg a mondanivalódat.)

* A modellezendő világ leképzése során számos alkalommal találkozhatunk olyan esetekkel, amelyek leképzését nem tökéletesen, vagy csak komoly nehézségek árán teszi lehetővé az előbbiekben ismertetett ER modell. Ezen szituációk kezelését könnyíti meg a fejezet során ismertetett kiterjesztett ER vagy EER (enhanced ER) modell. (Mindkét hiba tipikus: az első teljesen értelmetlen mondat - többször átfogalmazás alapján született szörnyszülött. A másik mondatban pedig a hallgatók által nagyon kedvelt mutató névmás szerepel, amelyről eldöntethetlen, hogy mire utal - a leképzésre általában, a nem tökéletes leképezhetőségre, vagy esetleg a "komoly nehézségek" utáni leképezésre. Számold végig, hogy a mondatokban hány utalószó van! Az olvasó úgy érzi, hogy a szerző nem tudja, mit akar végülis mondani.)

* Általánosan elmondható, hogy a gyakorlatban nem érdemes szigorú értelemben ragaszkodni egyikhez sem [miért?], hanem az adott esetnek megfelelően az előnyösebb módszert kell választani. Természetesen mindkét esetben az eljárás... (Nincsenek egy mérnöki dokumentumban ex cathedra kijelentések. Minden állítás indokolandó - vagy irodalomhivatkozással, ahol ezt alátámasztották kellő mértékben, vagy bizonyítással, érvekkel.)

* Úgy vélem, a feladatot sikeresen teljesítettem. (Az értékelés szakaszban nem Magadat kell értékelni, ez mások dolga. Csak az elvégzett munkát szabad "minősíteni" a tények alapján levont konklúziók segítségével.)

* ...vagy continuing vagy retaining átmenet van a két tagmondat között... (Érdemes eldönteni, hogy a dokumentációt magyar vagy angol nyelven írja az ember. Előbbi esetben magyarul írjuk a kifejezéseket - ha nincs bevált magyar terminológia, akkor alkoss egyet(!), és írd oda az első előfordulás után az angol terminust is -, egyéb esetben pedig angolul írjuk a mondat többi részét is. Ez az öszvér megoldás jelentősen rontja a megértést. Különösen problémás, ha olyan szavakat használ valaki angolul, mint domén (vagy domain), dizájn (design) stb. Egyrészt a magyar átvétel szerint ezeket fonetikusan írjuk - ne jöjjön senki azzal, hogy ronda(!) a http betűszó begépelése is az másoknak!! - másrészt az átvett angol szavak jelentéstartalma messze bővebb a magyar megfelelőjüknél. Pl. a domén magyarul lehet értelmezési tartomány és értékkészlet is, de nagyon nem mindegy melyik a kettő közül. A dizájn lehet terv, architektúra, megjelenési forma is - de vajon melyik ezek közül az, amire a szerző gondol? Egyébként is nehezen értjük egymást - maradjunk a közérthető fogalmaknál.)

-- KardkovacsZsolt - 14 Dec 2007