Programozsi Technolgik

ttekints

Rendszerfejleszts lpsei:
1. Kvetelmnyek feltrsa. Amikor megfogalmazzuk azt, hogy a kifejlesztend informcis
rendszernek (egyszerbben fogalmazva szoftvernek) milyen krlmnyek kztt s mit kell
tudnia. Teht meghatrozzuk a kvetelmnyeket.
2. Elemzs (analzis, kalkulus). Amikor a kvetelmnyeket megvizsgljuk, elemezzk,
csoportostjuk olyan szempontbl s azrt, hogy majd a szoftvert megfelelen tudjuk
kifejleszteni.
3. Architekturlis tervezs (logikai, magas szint tervezs). Az architektrlis tervezs a
szoftver struktrjnak a kialaktsra vonatkozik (lehetleg mindenfle platformtl,
hardvertl, szoftvertl s egyebektl fggetlenl).
4. Tervezs (fizikai, alacsony szint tervezs). A tervezsben viszont mr figyelembe vesszk
ezeket. Teht a struktrnak a felptse figyelembe vve azt, hogy a kvetkez fzisban
majd hogyan s mit csinlunk.
5. Implementls. Kdols, megvalsts, amelynek nem elhanyagolhat rsze a tesztels.
Ennek a vgn kszl el maga a szoftver.
6. zembe helyezs (bevezets)
7. zemeltets. Futtatjuk a szoftvert.
8. Karbantarts. Ha hibs a szoftver, akkor a hibkat kijavtjuk.
9. A szoftver fejldik (Evolci). Gyakran a karbantarts helyett. A szoftver mdosul,
fejldik, mert vltoznak a gazdasgi, jogi, stb. viszonyok, amelyek kztt hasznljuk.
10. zemen kvl helyezs. ltalban nem szoktak hangslyt fektetni r.

(Mi a logikai tervezssel, fizikai tervezssel s implementlssal foglalkozunk.)

Szoftver alatt a program, a dokumentci s az adatok egyttest rtjk! Klns tekintettel a
dokumentcira. A dokumentci a teljes letciklust vgigksri.

A szoftver egy termk. Egyrszt ugyanolyan termk, mint brmely ipari termk, msrszt van egy
alapvet klnbsg: ez egy szellemi termk, ennek az sszes htrnyval. Specilis, mert szellemi
termk, ez alapveten megklnbzteti ms ipari termkektl.

A szoftvert, mint termket, el kell lltani. Projektben lehet ellltani. Rszben azonos
jellemzkkel rendelkeznek, rszben specilisak. A minsg alapvet szerepet jtszik. A projekt id,
pnz s egyb erforrs.


Szabvnyok

Szabvnyok fajti:
- de jure. Amelyeket mindenfajta szabvnygyi testletek, hivatalok, intzetek definilnak,
formalizlnak. Kt legnagyobb: ISO ANSI. Az ezek ltal ellltott szabvnyokat
mindentt, mindenki elfogad. Legfeljebb nmi mdostssal. Senki nem vitatja ket.
Problmi:
Elviekben angolul vannak, nehz olvasni ket, formalizltak s a szhasznlat sokkal
bonyolultabb, mint a jogszablyokban. ltalban nagy terjedelmek.

- de facto. Nagyobb szerepet jtszanak. Ezek ipari szabvnyok. Egy-egy szakterletnek a
szabvnyai, nem ltalnosak. Az adott szakterlet vezet cgei ltal deleglt emberek
fogalmazzk meg ket. Az adott szakterlet legjobb gyakorlatt gyjtik ssze. Az
informatikban az egyik legnagyobb szabvnygyrt konzorcium az OMG (Nagyon sok
OMG szabvny van. Kzel 2000 tagja van. http://www.omg.org). A msik a W3C. Az OMG
a nylt, elosztott objektum orientlt rendszerek ipari szabvnyait lltja el. Az ipari
szabvnyok azrt lnyegesek, mert az adott szakterlet minden jelents tnyezje hozz
rakja a sajt magt. Szabvny mdon szletnek. Fejldsi trendeket jellnek ki.
- Piaci de azrt is. Szakterletekhez ktdik. Az adott szakterleten van egy, vagy tbb
nagyon ers cg s, amit a cg csinl, azt kell csinlnia a tbbi cgnek is. Van egy fajta
gyakorlat, s mindenki ahhoz igazodik.
- Vllalati. A legszkebb. Egy-egy adott cgen, intzmnyen, vllalaton bell sajt
szabvnyok lteznek, amelyek igazodnak az elzekhez, abbl szrmaznak, testre szabott
szabvnyok. Bizonyos nagysgrenden fell minden vllalatnak lennie kell vllalati
szabvnynak. Ez a legflexibilisebb szabvny.

A szoftverkrzis egyrszt ltrehozott sok j informatikai eszkzt, paradigmt, msrszt ltrejttek a
programozsi mdszertanok (modulris, struktrlt, OO).

Az egsz informatikai fejlds arrl szl, hogy olyan paradigmk, eszkzk jelennek meg,
melyekben egyrtelm cl az absztrakcis szint nvelse, modellezs. Egy msik fontos fogalom az
jrafelhasznls. Ezek kr formldik a ma informatikja.

Minsgbiztostsi szabvnyok

Nagy szabvnygyrt cgek: ISO, ANSI, IEEE, (NATO)
ISO9000 az ltalnos folyamatszabvny. Specilisan informatikai az ISO9001.
Minden termkre alkalmazhat szabvny. Amit minden cg sajt magra szabhat, s ltrehozza a
sajt minsgi kziknyvt. Ez a minsgbiztosts. Ezeket szabja r a projektekre, s gy trtnik a
minsg-ellenrzs. Gyakorlatilag egy sajt szervezeti minsgkezelsi folyamatot definil.
(bra)
Vannak auditor cgek amelyek, minsgi tanstvnyokat adnak ki. Az auditl cgek ltal adott
tanstvny arrl ad tanbizonysgot, hogy az adott cgnek van minsgi kziknyve, van
minsgtervezse, s minsg-ellenrzse.

Dokumentcis szabvnyok

Minden cg sajt dokumentcis szabvnyt dolgoz ki. A minsgkezels lnyeges adminisztratv
rsz. Ehhez a csoporthoz 3 szabvny tartozik:
1. Dokumentcis folyamatszabvnyok - Kvetni kell a dokumentci ellltsa sorn.
2. Dokumentumszabvnyok - Hogyan nzzen ki egy doksi. Ezen bell szoks ezeket
megadni:
a. Dokumentum azonosts szabvnyai, ahhoz hogy hivatkozhatk, kezelhetk
legyenek a dokumentumok.
b. Szerkezetre vonatkoz szabvnyok, melyek meghatrozzk milyen rszekbl
lljanak az egyes dokumentumok.
c. Kinzetre vonatkoz szabvnyok, pl.: logo, sajt font stb.
3. Dokumentumcsere szabvnyok - Hogyan kell vgrehajtani a vltoztatst a
dokumentumon, s hogyan jelljk a vltozst.
A dokumentumokat jv kell hagyni!


UML (Unified Modelling Language)

Grafikus modellez nyelv. OMG szabvny.
Az OO a 80-as vekben rendszerfejlesztsi mdszertann vlt. (90 -es vek elejre tbb, mint 100.)
A 80-as vek elejn 3 nagy irnyzat: Booch-Jacobson-Rumbaugh. Ms-ms dolgokra helyezik a
hangslyt. A strukturlt mdszertanokbl vesznek t bizonyos elemeket, s azok mell raknak OO
elemeket. A 90-es vek elejn sszefogtak, sszevontk a mdszertanaikat. Egy egysges
mdszertan kidolgozst tztk ki clul. 95-ben megjelent az UML 0.9. 97-ben OMG szabvnyknt
megjelenik az UML 1.1. Ez az els szabvny. 2001-ben az 1.4, majd az 1.5, innentl kezdve kezd
romlani. 2005-ben megjelenik az UML 2.0, majd 2007-ben az UML 2.1 (Ez az az OMG szabvny,
amit ma UML alatt rtnk).
Az UML legnagyobb elnye az, hogy mindenkitl fggetlen, nem ktdik semmilyen
informatikai cghez. Mindenki elfogadja, mert nem ktdik a msikhoz. Idben jtt, a 90-es vek
kzepn megszlettek az OO szabvnyok, megszletik a web, az OO szemllet, mint paradigma
teljesen ltalnoss vlik. Az UML azonnal belp a kvetelmny-feltrsnl, kvetelmny-
elemzsnl s tovbb folytatdik az implementls vonatkozsban. Illetve, mint modell, a
tervezsnl jtssza a legalapvetbb szerepet.
Az OMG megalkot egy sajt formalizmust, egy szabvny defincis formalizmust, minden
szabvnyt ennek a formalizmusnak a segtsgvel definilja. Ez egy meta-cirkulris szabvny,
alapja az UML. Ahhoz, hogy ezt a formalizmust tudjam, ismerni kell az UML-t, de az is ebben a
szabvnyban van definilva. A szabvnydefinci cscsn a MOF (Meta Object Facility) ll. Ez az
egsz szabvnydefincis formalizmus egy 4 szint architekturlis minta.

Az UML, mint szabvny legfontosabb tervezsi elvei a kvetkezk:
- Modularits. A nyelvi konstrukcikat csomagokba szervezi.
- Rtegzettsg. A klnbz szintek pldnyai a magasabb szinteknek (4 szint).
- Particionls. A csomagokat klnbz partcikra osztja a szabvny.
- Kiterjeszthetsg. UML profilok hozhatk ltre. UML, mint nyelv, kiterjeszthet
platformspecifikus profilok fel. Profilok hozhatk ltre a szakterletre.
- jrafelhasznlhatsg. Az UML jelen pillanatban ltez elemeit jra felhasznlhatom.
CWM (Common Warehouse Metamodel - Adattrhz Metamodel) szabvny.

Egy nyelv megalkotshoz a kvetkezk kellenek:
- Absztrakt szintaxis: definilja a nyelv konstrukcijt jellstl fggetlenl.
- Konkrt szintaxis: ez a jells.
- Statikus szemantika: megmondja, hogy egy nyelvi konstrukci pldnyai hogyan
kapcsoldnak ms pldnyokhoz.
- Dinamukis szemantika: jl formlt konstrukcik jelentst definilja.

Az UML a 4 szint formalizmussal zrt. A szabvny konstrukcin kvl semmi ms nem szksges
a defincihoz s brmilyen modell lershoz. A szemantikt termszetes nyelven (angol) adja meg,
kivve az OCL.

A diagramok egy rsze a viselkeds lerst, ms rszk a struktra lerst adja.

Diagramok:
Csomag:

A csomag tulajdonkppen egy nvtr. Tpusokat s csomagokat tartalmaz. Teht az UML
tpus-alap rendszer. A hatskr elhatrolsra csomagokat alkalmaz. A csomagnvvel val
minsts :: .


Megjegyzs:

Brmely konstrukcielemhez fzhetnk megjegyzst.

Sztereotpus (sztereotpia):
Ezt is adhatunk brmely elemhez. Vagy pontostja az adott elemet, vagy a kiterjesztsben
jtszik szerepet, vagy egy j modellelemet hoz ltre.
<<sztereotpus_neve>>
A szabvnyban sok beptett sztereotpia van.
Legfels szint csomag:
<<system>>.

Fggsgek:
Egy csomagon bell elhelyezett alcsomagok kztt rtelmezettek. A fggsg jele:
<----
Pl.: <----<<import>> csomagok kztti publikus import az adott irnyban.

Osztly:
(A legfontosabb.) Az OO paradigma azt mondja, hogy a val vilg modellezse kzben a
vilgot objektumokra robbantjuk szt s a kvetelmny-feltrs s elemzs feladata az, hogy
az adott problmhoz tartoz objektumokat kidertsk, majd az elemzs sorn ezeket, az
objektumokat kategorizljuk, osztlyokba soroljuk. Az OO rtelemben vett osztlyokba
soroljuk s ezeket, az osztlyokat formalizljuk az osztlydiagram segtsgvel.
Az UML vonatkozsban az osztlynak 4 fajta kzeltse lehet:
a) Fogalom. A kvetelmny-feltrsnl alapvet, amikor egy szakterleti fogalom
absztrakcija jelenik meg egy osztlyban. (pl. tanulmnyi rendszernl a hallgat.).
b) Tpus. Az osztly, mint absztrakt adattpus. Az elemzsnl.
c) Az osztly, mint objektumoknak egy halmaza. Ez az adatbzisokhoz ktd
objektumorientlt adatmodellezs krnykn egy kzelts. Tipikusan ebben a
kzeltsben, amikor halmazknt tekintjk az osztlyt, azt mondjuk, hogy van egy
szuperosztly, meg egy alosztly. Az alosztly, mint halmaz, minden eleme eleme a
szuperosztlynak, mint halmaznak.
d) Az osztly, mint implementci. Mint egy Java osztly, vagy egy C# osztly.
Az UML mind a 4-et segti, lehetv teszi.
Osztlydiagram:

Nv: Nagybetvel kezddik, kzpre igaztott s a krnykn sztereotpik, megjegyzsek
lehetnek.
Attribtumok:
nv [:tpus] [=kezdrtk]
Adhatok neki tpust, kezdrtket, de egyik sem ktelez. Az attribtumok neve kisbetvel
kezddik, a tbb szbl ll nevek msodik, harmadik stb. szavnak kezdbetje nagybet.
A szrmaztatott attribtumok neve eltt egy / ll. Az osztlyszint attribtumokat alhzzuk.
Mveletek: pontosabban a mveletek szignatrja.
nv (paramterek) [:tpus]
A nvre ugyanaz vonatkozik, mint az attribtumok nevre. A zrjel a nvhez tartozik, a
paramtereket vessz vlasztja el egymstl, ha tbben vannak. Ha van tpus, akkor
fggvny-jelleg mvelet, ha nincs tpus, akkor eljrs jelleg mvelet.
Egy paramter a kvetkezkppen nz ki:
[md] nv : tpus [=kezdrtk] (paramter)
A md lehet IN=csak olvashat, OUT=csak rhat, INOUT=rhat/olvashat,
RETURN=visszatrsi paramter (ek).

Nagyon gyakran, ha nem lnyegesek a rszletek, vagy nagyvonal elemzsrl s tervezsrl
van sz, az osztlydiagram gy jelenik meg, hogy csak a nv van benne, nincsenek
attribtumok s mveletek.



Bezrs, lthatsg:
Vagy minden attribtum s mvelet neve eltt megadjuk, vagy bezrsi szekcikat hozunk
ltre.
+ public
# protected
- private
~ (csomaglthatsg)

Megszorts:
Brmely elem mellett {} kztt megadhatok megszortst. A megszortshoz kapcsoldik az
OCL (Object Language Constraint). Adatbzis rtelemben vett megszorts.

Objektumdiagram (pldnydiagram):

Pldny: megnevezem a pldnyt, a pldnyost osztlyt.
Attribtum = rtk: ezzel adom meg a kezdllapotot.

Asszocici:

Osztlyok kztti strukturlis viszonyt modelleznk vele. (Ez egy kapcsolattpus.) Az
asszocici tetszleges fok, de minimum 2. Jellse az osztlyok kztt folytonos vonal.
Nincs kizrva, hogy az asszocici ugyanazt az osztlyt ksse ssze nmagval. Van kt
vge. Az asszocici vgei megnevezhetek szerepkrk segtsgvel. Ltezik az
asszocicinak szmossga. Kt beptett megszorts, ami az asszocicihoz ktdik:
{ordered}, {sorted}.
sorted: a kapcsolatban a pldnyok rendezettek.
ordered: meghatrozott sorrendben rhetk el, de nem mond semmit errl a sorrendrl.
rule: szerepkr. Egy kapcsolat mindkt vgn elhelyezhet.


Az asszocicinl a folytonos vonalon lehet jellni a naviglhatsgot. Ez vagy egy nyitott
vg nyl a cg pldnyai hivatkozhatjk az alkalmazott pldnyokat, fordtva
nem mond semmit. Letiltani a naviglhatsgot gy lehet: a cg pldnyai
hivatkozhatjk az alkalmazott pldnyokat, fordtva ez nem igaz.

Aggregci:
Osztlyok kztti specilis viszony. Szoks ezt egsz-rsz viszonynak hvni. Aszimmetrikus
viszony, nem kommutatv, de tranzitv. Az egsz oldali attribtumok s mveletek
megjelennek a rsz oldalon. Az aggregci a legvitatottabb UML fogalom.
(bra projekt,alprojekt)

Kompozci:
Az aggregcira rrak egy kezelsi szemantikt. A rsz nem lheti tl az egszet.

rklds (UML-ben ltalnosts, pontosts):
Klasszikus rklds, tbbszrs. A helyettesthetsg elvn alapul. A 2.0, 2.1-es UML az
egysgessg elvt vallja. Teht minden nyelvi konstrukci objektum, minden nyelvi
konstrukci egy osztlynak pldnya.

Az UML szabvnyrl:

Kt alap eszkzrendszer van, az infrastruktra s a szuperstruktra. Az infrastruktra knyvtr
az, amelyik a nyelvi alapeszkzket tartalmazza, ezeknek az alap szintaxist rja le.
(bra Az SQL92 create table utastsa )

A val vilgot modellezzk, a modellt meg kezelni kell. Az OO paradigma egytt kezeli a struktrt
s a viselkedst. Ahhoz, hogy a modellt kezelni tudjuk, kell egy kezel nyelv. Mindenfle
modellnek kell egy kezel nyelv. A vals vilg modellezsnl megjelenhetnek a kvetkez
egyedtpusok (OO-ban osztlyok): Hallgat, Oktat, Tantrgy stb., amelyeknek a pldnyai a
tnyleges egyedelfordulsok. s mondjuk a modell kezel nyelve, lehet a Java, vagy a C#, vagy az
SQL stb.
A kezel nyelv kezeli az osztlyokat s kezeli a pldnyokat is. De van egy alapvet klnbsg. Az
egyedtpusok, az osztlyok, azok modellbeli eszkzk, a modell eszkzei. s a konkrt pldnyok
az egyedek. s lnyeges, hogy absztrakcik. A modell elemei absztrakcik. Ezeket az absztakcikat
le kell tudni rni. A pldnyok s az egyedek viszont konkrt dolgok. Csak ezek a konkrt dolgok.
s, amikor futtatjuk a Java, C#, vagy SQL scripteket, akkor lteznek, teht futsi idej dolgok.
A kezel nyelvet is definilni kell, formalizlni kell. Van szintaxisa s szemantikja. Ezeket
valamilyen mdon meg kell adni. Ezek a nyelvek szveges nyelvek, szveges eszkzrendszerrel
rendelkezik.

Az UML grafikus nyelv. j formalizmust kerestek s j mdszert talltak. Ugyanis az OMG azt
mondja, hogy a kezel nyelvet ne egy szintaxist ler formalizmus segtsgvel definiljuk, hanem
egy metamodell segtsgvel. Teht adjunk egy modellt a kezel nyelv fogalmainak a megadshoz.
Ez lesz a metamodell. A modellt ler kezel nyelv elemei, azok a metamodell osztlyainak a
pldnyai. Teht a metamodellben osztlyokat definilok, s azok pldnyai lesznek a kezel nyelv
elemei. A kzelts teljesen ms, nem nyelvet definilok, hanem metamodellt definilok.


Az OMG a 4 szintet M0, M1, M2, M3-nak nevezi.
M0:(rendszerszint, pldnyszint, konkrt szint) Itt vannak a konkrt pldnyok. Ezek pldnyai a
megfelel modellben definilt osztlyoknak.
M1:(modellszint) Azok az osztlyok, melynek a pldnyai az M0 szinten vannak.
M2:(metamodell) Ezeknek a pldnyai a modell szint fogalmak.
M3:(MOF) Meta Object Facility. nmagval van definilva. Egyetlen MOF ltezik. s az elbbi
metaosztlyok mind MOF osztly pldnyaknt jnnek ltre.


Mintk (Patterns)

A mintk az elmlt 15 vben kapnak egyre nagyobb szerepet. A minta egy olyan ltalnos
megolds, amely mkdtt a mltban s jrafelhasznlhat mdon mkdni fog a jvben is. A
mintk receptek. Mint a receptek ltalban, a mintk is vagy jl hasznlhatk, vagy rosszul. A
mintk a GoF-nak beczett 4 ember knyvben jelentek meg elszr. k rtk le szisztematikusan a
mintkat.

Egy minta a kvetkez sszetevkkel mindenflekppen rendelkezik:
- Nv.
- Problma, amely problma megoldsra szletett.
- Krnyezet, amiben hasznlhat.
- Knyszerek, felttelek, amelyek mellett hasznlhat a minta.
- Megolds a problmra, amit a minta kezel.
- Alkalmazsi pldk.


Az informatikn bell a mintkat a kvetkez flekppen szoks csoportostani:
- Analisis (elemzsi mintk)
- Architecture styles (architekturlis mintk, stlusok)
- Design (tervezsi mintk)
- Programming idioms (programozsi idimk)
- Process (folyamat mintk)
- Antipatterns (ellenmintk)

Az els 4 termk minta, implementcis minta.
Nincs les hatr. Ezek az osztlyok tfedik egymst.


Elemzsi mintk

Az elemzsi mintk szakterlet specifikusak. Az adott szakterlet alapvet szakterleti
absztrakciit tudjuk velk kezelni.

Architekturlis mintk

Az architekturlis mintk a teljes rendszerre s alrendszerekre vonatkoznak. Teht nagyon magas
absztrakcis szint mintk. A MOF egy 4 szint specilis architekturlis minta.

Tervezsi mintk

A tervezsi mintk kzepes absztrakcis szinttel rendelkez mintk. Ezek vltak elszr hress.
Sok tervezsi minta van, klnbz osztlyokba vannak sorolva.



A tervezsi minta lersra szolgl elemek:
- Nv s osztlyba sorols.
- A problma, elrend cl ismertetse.
- Szinonima nevek.
- Motivci. Mi indokolja, hogy egy ilyen mintval egyltaln foglalkozzunk?
- Alkalmazhatsg. Azok a terletek, ahol jrafelhasznlhat a minta.
- Struktra.
- sszetevk.
- Egyttmkds ms mintkkal.
- Kvetkezmnyek az alkalmazsra vonatkozan.
- Implementci.
- Pldakd.
- Plda a hasznlatra. Esettanulmny jelleg.
- Kapcsold mintk.

A leghresebb tervezsi minta a Smalltalk krnykn kialakult MVC (Model View Controller).
(http://java.sun.com/javaee/5/docs/tutorial/doc/bnahb.html)



Ebbl ksbb kialakul a klasszikus 3 rteg alkalmazs. Az MVC szerint szt kell vlasztani az
adatkezelst (model), szt kell vlasztani a megjelentst (view), s szt kell vlasztani a vezrlst
(control). s ebbl lesz ez a bizonyos 3 rteg alkalmazs. Mai terminolgival: adat rteg, zleti
logika rteg, prezentcis rteg.

A tervezsi mintk nagy rsze az objektumok kztti kommunikcirl szl.
ltalban a mintkat felfedezik. A msik kzelts szerint jzan paraszti sz.

A tervezsi mintknak 3 nagy kategrija van:
- Ltrehoz mintk: Azt mondjk meg, hogy hogyan kell vgrehajtani egy pldnyostst.
Magyarul legyrtanak szmunkra objektumokat. Nem n pldnyostok, hanem a minta
alapjn legyrtatom az objektumokat.
- Strukturlis mintk: Objektumcsoportok kezelsre vonatkoznak.
- Kommunikcis mintk, viselkedsi mintk: Az objektumok kztti kommunikcit, a
vezrls legjobb gyakorlatt rjk le.

Az OO vilg tervezsi minti azt szolgljk, hogy az OO vilgban a legszigorbb mdon
megvalstsuk az ADT szemlletet. Az osztlyok minl lazbban kapcsoldjanak, az rkldst
komolyan vegyk, az jrafelhasznls rklds alap legyen.
Tervezsnl az ADT-re s az rkldsre kell koncentrlni.

klszably az absztrakci. Tervezsnl interfszek vannak. Magyarul az rklds viselkedsi
s nem strukturlis rklds, amiben a tervezsnl gondolkodni kell. Absztrakt viselkedst
definil interfszek s a kzttk lev rkldsi kapcsolatok, vannak krlfogva. Tervezsnl
absztrakt osztlyban gondolkozunk, ha az interfsz tl absztrakt. Legvgs soron konkrt osztly.

Gyakran az OO alkalmazsfejlesztsnl, rendszerfejlesztsnl az rklds helyett
objektumkompozcit kell hasznlni. Magyarul kontnereket, kollekcikat kell hasznlni.
Ugyanis ezen imperatv OO paradigmban az rkldssel van egy problma. Az rklds
megzavarhat a bezrssal, teht kicsit ellentmondanak egymsnak. Az imperatv OO paradigma
egyrtelmen a helyettesthetsgen pl fel, amihez kell a lthatatlan rklds.

A tervezsi mintk ma megjelennek fejleszti krnyezetekben beptett mdon.

Programozsi idimk

Legelszr a programozsi idimk jelentek meg. Ezek programnyelvhez ktdnek. Totlisan
konkrtak.

Egy adott programnyelven megtanulni programozni a kvetkezket jelenti:
- Meg kell ismerni az adott nyelv szintaktikjt s szemantikjt (3 nap)
- Meg kell ismerni egy fejlesztkrnyezet eszkzrendszert (3 v)
- El kell sajttani az adott programnyelv programozsi stlust (30 v)

A programozsi mintk konkrt nyelvhez ktd, nagyon alacsony szint mintk, amelyek a j
programozsi stlust szolgljk.

A j programozsi stlushoz hozztartozik:
- Elnevezsi konvencik.
- Forrsszveg formzsa.
- Az adott nyelv elemeinek a j hasznlata.

Egy adott problmt egy adott nyelven sokflekppen meg lehet oldani.
Pl.: a s b rtknek felcserlse:
a = a + b
b = a b
a = a b

Az idimk a legjobb gyakorlatot gyjtik ssze. Ezek azok a fogsok, melyek gyakran nincsenek
mg lerva sem. Bizonyos idimkat bizonyos cgek abszolt bels titokban kezelnek. Klnsen
igaz ez az adatbzis programozs terletn.
Minden nyelv mgtt ott vannak a programozsi idimk.
(Java-hoz egyik legjobb knyv: Bloch Effective Java Programming Language Guide)


Folyamatmintk

A folyamatmintk a rendszer ellltsnak folyamatra vonatkoznak.

Antimintk (http://www.sourcemaking.com/antipatterns)

Az antimintk, szemben a mintkkal, a legrosszabb gyakorlatot gyjtik ssze. Olyan problmkat,
hibs szitucikat, nem megfelel gyakorlatot, amit el kell kerlni. Az antimintk olyan mintk,
melyek megadjk a megoldst is, teht a hiba javtst, elkerlst, megoldst.

A kvetkez krdsekre lehet vlaszt adni az antimintk segtsgvel:
- Melyek a legltalnosabb szoftvertervezsi, szoftver fejlesztse sorn elfordul hibk?
- Hogyan ismerhetk ezek fl?
- Hogyan javthatk?
- Hogyan lehet felismerni, hogy egy szoftver projekt zskutcba jutott, s hogyan lehet onnan
kihozni?
- Hogyan lehet felfedezni azt, hogy a szoftvergyrt tvert bennnket, vagyis nem azt adta,
amit grt?
- Hogyan lehet eldnteni, hogy a legjabb termk, szabvny, technolgia vlaszt ad a
jelenlegi problmnkra?
- Melyek az jrafelhasznls veszlyei, problmi?

Egy minta nagyon hamar antimintv vlhat, ha az alkalmazs felttelei nem megfelelek!

Antimintk 3 nagy kategrija:
1. Folyamatok s az emberek menedzselse.
2. Architekturlis ellenmintk.
3. Implementcis ellenmintk.

Az ellenmintknl a problma megoldst hvjuk refactoringnek. Legalbbis az implementcis
ellenmintknl a j megoldst a refactoring segtsgvel rjk el.

Blob:

Mikor ll el?
- Akkor ll el, ha egy programot gy runk meg, hogy egy osztly kizrlagosan uralja a
vezrlst (blob osztly), s hozz kapcsoldnak kismret osztlyok, amelyek az adatokat
kezelik, tartalmazzk.
- Ha egy EO mdon megrt kdot ltetnk t OO krnyezetbe refactoring nlkl.


Mik a jellemzi?
- Egy osztly, ami 50-nl tbb tagot tartalmaz mr blob osztly.
- Ha egymstl fggetlen metdusok s attribtumok jelennek meg az osztlyban. Vagyis
olyan atribtumok vannak, amelyeket nem hivatkozik metdus.
- A programban egy aktv s sok passzv osztly jelenik meg.

Mirt ll el?
- Az OO paradigma flrertelmezse, flrealkalmazsa okn. Teht az OO vilgban EO
mdon programozok. A fprogramot megrom egy blob osztlyban.
- Architekturlis tervezsi problma. Rosszul tervezem meg az architektrjt, mert a
felelssget bezsfolom egy osztlyba.
- Lehet j a tervezs, vagyis az architektra, de rossz az implementci.

Kvetkezmnyek:
- A rendszer nehezen mdosthat.
- A funkcionalitsokrt felels szoftverrszt nehz megtallni.
- Tipikusan nem jrafelhasznlhat.
- Egy blob osztly sok rendszererforrst kt le, a futsi hatkonysg gyenge.

Megolds:
Refactoring, vagyis a bezsfolt funkcionalitst, viselkedsmdot szt kell tagolni! A komplexitst
radiklisan cskkenteni kell!
Refactoring lpsei:
1. A szttagolsnl meg kell hatrozni azokat az attributum csoportokat, s metdusokat,
amelyek sszetartoznak, amelyeket egysgbe kell zrni! Vagyis ezeket az attributum,
metdus csoportokat ki kell emelni, s egy kln osztlyba helyezni!
2. Meg kell szntetni a redundns kapcsolatokat, viszonyokat! ltalban meg kell szntetni a
laza kapcsolatokat!
3. Az eddig lpsek sorn megstrukturltuk az OO szemlletnek megfelelen az
osztlyszerkezetet. Megszntettk a nagy komplex osztlyt, szttagoltuk a funkcionalitst,
s megvalstottuk az egysgbezrst. Ezutn meg kell csinlni az absztrakcit! Vagyis fl
kell pteni egy osztlyhierarchit, egy rkldsi hierarchit!


Fogalmak:
- Sima-, vagy elretervezs (Forward engineering). Amikor a terv hamarabb kszl el, mint
a szoftver.
- Visszatervezs (Reverse engineering). Egy meglv kd alapjn ksztem el a tervet.
- srendszerek. Jl mkdnek viszont rgen terveztk ket, s gyengn dokumentltak.
Problmjuk mg, hogy gyakran hardver s opercisrendszer fggek. Viszont mivel a
funkcionalitsuk tkletes rdemes megtartani ket. Ki is lehet dobni. Vagy migrljuk
ket (jra legyrtjuk), de ehhez tudni kell, hogy mit csinl. Itt jn a visszatervezs, vagyis a
kd alapjn ksztnk egy tervet, aminek a segtsgvel jra felpthetjk a rendszert j
technolgival. SOA: az srendszerek megmaradnak, s fl hznak egy j architektrt.
- jratevezs (Reengineering). A rendszert jratervezem a tervek s az implementci
ismeretben.

Refactoring, jrastruktrls (http://www.refactoring.com)

Lnyege a kvetkez: Adva van egy implementlt szoftver, ekkor a szoftvert vltoztatjuk meg gy,
hogy a vltoztats rintetlenl hagyja a kd kls viselkedst, vagyis a funkcionalits nem vltozik
semmit, de a kd struktrja igen. Teht a refactoring egy kd jrastrukturls, szisztematikus
kdtisztts. Termszetesen, ha jrastrukturlom a kdot, az visszahat a tervre, de ez nem egy
jratervezs, hanem egy tervjavts a funkcik megtartsa mellett.

(bra. lsd. Refactoring Improving the Design of Existing Code - Fowler-Beck-Brant-Opdyke-
Roberts.chm First Example)

jrastruktrls fbb szablyai:
- Mindig egy teszttel kell kezdeni, s azzal is folytatni. Mieltt jrastrukturlunk egy kdot,
le kell futtatnunk olyan teszteket, amelyeknl pontosan ismerjk az outputot s inputot. Ez
egy olyan teszt, ami a funkci megtartst szolglja, teht nem egy hinyossgi tesztels.
Minden refactorizlsi lps utn tesztelnk.

- Cskkentsk a metdusok komplexitst. Ehhez a metduson bell meg kell tallni a kd
logikai hatrait. A rvidebb metdus jobban tesztelhet, vltoztathat, megrthet. A
vltoztats sorn a funkcionalitst meg kell tartani, s nem szabad hibkat rakni a kdba.
Kln figyelemmel kell lenni a paramterekre s a loklis vltozkra.

- Fontos, hogy minl kevesebb paramterrel s minl kevesebb loklis vltozval ptsk
fel a kdot. Ha van olyan loklis vltoz, aminek az rtkt nem mdostjuk, akkor az
jrastrukturlst ignyel, vagyis paramter lesz belle.

- Kerljk az ideiglenes vltozk hasznlatt, mert nvelik a komplexitst! Vagyis rjuk t
az ilyen rszeket, ahol lehet metdushvsokra!(Fowler szerint)

- Egy attribtum hivatkozs helyett mindig ptsnk be egy lekrdez metdust!
ltalban a metdusok nagyon rvidek. Egy-kt utastsbl ll a trzsk, amik ltalban
maguk is metdushvsok. Metdushvsok sorozatra kell bontani a kdot!

- Hasznljunk beszl neveket.

- Laza-, szoros ktds. A metdust azon osztllyal kell egysgbe zrni, amelynek az
objektumt manipullja. Vagyis ha lehet ne paramterknt, kapja meg a metdus az
objektumot, amin dolgozik. Ezutn a metdushvst mdostani kell. Ekkor a kd
jrastrukturlsa mdostja a tervet.

- Ne elgaz struktrt hasznljunk, hanem tbbszrs rkldst a klnbz kategrik
megklnbztetsre!

Mikor kell refactoringot csinlni?
- Ismtelt kdrszletek: Ha van egy osztly, s annak kt klnbz metdusban ismtld
kdrszletek vannak, akkor abbl a kt metdusbl egyet kell csinlni. Elkpzelhet az,
hogy ez a szituci azrt jtt ltre, mert ugyanazt a dolgot kt klnbz algoritmussal
csinltk meg. Ekkor az egyiket ki kell dobni, s a msikat kell megtartani. Klnbz
osztlyok metdusaiban is lehetnek ismtld kdrszletek. Ez lehet tervezsi s
implementcis hiba is. Meg kell vizsglni, hogy tnylegesen melyik osztlyhoz kell, hogy
tartozzon ez a metdus, s abban kell megrni.

- Hossz metdus: A metdusoknak nagyon rvideknek kell lennik, a hossz metdusokat
szt kell vlasztani, s tbb rvidet kell rni. (Pici megjegyzse: elbb-utbb megtelhet a
rendszerverem a sok metdushvs miatt, gyhogy clszer inkbb megtallni az arany
kzputat.)

- Nagymret osztly: Sok az attribtum, sok a metdus. Vagy az egysgbe zrssal lehet a
baj, vagy tervezsi problma, vagy strukturlt mdon programoztuk le az osztlyt. Megolds
az egysgbezrs megvalstsa szttagolssal, megfelel felelssg hozzrendelssel.

- Metdusoknl sok a formlis paramter: Nehezebben rthet, nehezebben hasznlhat.
Sok paramter esetn valsznsthet, hogy a metdus nem sajt osztlyon operl. A
metdust t kell helyezni abba az osztlyba, amelynek az objektumain operl.

- Klnbz vltoztatsi ignyek: Akkor ll el, ha egy osztlyt meg kell vltoztatni, s ez a
vltoztats msknt trtnik, klnbz szitucikban. Pl.: Ha az adatbzisban vltozs ll
el, vagy j jogszably rkezik, msknt kell vltoztatni az osztlyon. Ekkor az
egysgbezrssal lehet a gond. Szt kell tagolni, mert ms-ms viselkedst mutat az osztly
ms-ms szitucikban.

- Srt effektus: Rendszernkn kis vltoztats is sok osztlyt rint. Egysgbezrsi gond,
teht valsznsthet, hogy az osztlyoknl a struktra tbbszrzdik. t kell alaktanunk
a kdot ennek megfelelen.

- Versengs: Amikor egy metdus nem sajt adatot hasznl, vagyis nem sajt osztlynak
objektumain operl. Az osztlyok versengenek egyms objektumairt. Erre ltezik egy
kln tervezsi minta a Visitor.

- Adatcsoportosuls: Akr attribtumok, akr formlis paramterek esetn jelenik meg. Azt
kell megvizsglni, hogy az adatcsoport egy elemt tudom-e gy manipullni, hogy a csoport
tbbi elemt nem rinti. Ha igen, akkor ez a csoportosuls flsleges.

- Primitv tpusok: Ha olyan osztlyt tallunk, amely lnyegben, funkcionalitsban
megegyezik valamilyen beptett tpussal, akkor ez nylvn flsleges. Beptett tpus
osztlyt megrni flsleges.

- Tbbszrs elgaztats: Hasznljunk helyette polimorfizmust!

- Prhuzamos rkldsi hierarchik: Az alkalmazs szempontjbl tbb hierarchia van, s
ua. az osztly megjelenik tbb hierarchiban.

- Lusta (semmittev) osztly: Egy alkalmazsbl azt az osztlyt, amelyet nem hivatkozunk,
el kell tvoltani.

- Spekulatv ltalnosts: Tipikus implementcis hiba, tipikus programozi hozzllsi
hiba. A programban hagyom az osztlyt, br nem kell.

- tmeneti/Ideiglenes mezk: Tbb hibalehetsg, nehezebben rthet a kd, ezrt
prbljuk kihagyni, paramterr, visszatrsi rtkk alaktani.

- zenetlncok: Amikor egy objektum egy msik objektumot hivatkozik. Valsznleg
implementcis hiba, flrertett tervezs.

- Nem megfelel bizalmassg: Nem megfelel bezrsi szint. Amikor egy osztly tl sokat
mutat meg az eszkzeibl, olyanokat is, amik flslegesek.

- Alternatv osztlyok klnbz interfsszel: Ugyanolyan funkcionalits metdusok
szignatrja, specifikcija klnbzik. Klnbz osztlyokban, klnbz szignatrj
metdusok ugyanazt csinljk. Metdusokat ssze kell vonni, esetleg tnevezni s egy
osztlyba gyjteni.

- Adatosztlyok: Csak attribtumaik vannak, esetleg bellt s lekrdez metdusaik, nincs
viselkedsmdjuk.

- Elutastott rksg: A bizalmassg ellenttje. Rossz az rkldsi hierarchia. Amikor egy
alosztly tveszi a viselkedsmdot, de nem tmogatja a szuperosztly interfszt.

- Az alkalmazott API osztlyai nem egszen gy mkdnek, ahogy kell.

Fowler szerint egy jragyrtott kdban flslegesek a megjegyzsek.

Az jragyrtsnak van katalgusa ezzel a felptssel:
- Nv
- sszefoglal rsz - Mikor s mire hasznlhat.
- Motivc - A felhasznls krlmnyeire vonatkozik.
- Mkds - Lpsrl lpsre megadja, hogy az adott jragyrtsnl mit, hogyan kell csinlni.
- Alkalmazsi pldk

Verifikci s validci

A terv alapjn implementljuk a szoftvert. Szkebb rtelemben a verifikci s a validci a
programra vonatkozik. ltalnosabb rtelemben a teljes rendszerfejlesztsi folyamatban beszlnk
verifikcirl s validcirl.
A verifikci azt vizsglja, hogy a szoftver (program, dokumentci s adatok) megfelel-e a
specifikcijnak. Verifiklni mindent kell.
A validci azt vizsglja, hogy a felhasznl szmra megfelel-e a szoftver, vagyis a szoftver
specifikcija. A hangsly itt mr a programon van. ltalnosabban mindkett valamilyen
megfelelst vizsgl.

Mi befolysolja a szoftver elfogadsi szintjt?
- A funkcija, vagyis mire akarjuk hasznlni. Pl. Pakson rtelemszeren magasabb.
- Elvrs. Manapsg a szoftvertl nem vrjuk el, hogy megfelelen mkdjn, mert erre
kondcionlt minket a szoftveripar.
- Piac knyszert ereje arra kszteti a cgeket, hogy minl hamarabb ksz legyen a szoftver
-> rengeteg bta.

V&V technikk:
1. tvizsgls:
Statikus technika. A szoftver valamilyen reprezentcijt nzzk t, vizsgljuk meg. Lehet
ez dokumentci, forrskd, specifikci, brmi, amihez nem kell a program futtatsa.
tvizsglsnak egyik mdja az emberi szemmel trtn tvizsgls. A msik az automatikus
statikus elemzs: A program forrsszvegt nem ember, hanem program (egy intelligens
fordt) vizsglja t. Elkszti az emberek feladatt, sok plusz informcit szolgltat.

tvizsgls megkzeltsek:
- Vezrls: A felesleges, vagy nem hasznlt kdrszletek felderthetek sokkal
knnyebben, mint kzzel.
- Adathasznlat: A vltozk egyms utni rtkadsainak kidertse. Feladata a nem
tpusos nyelveknl nagyobb szerepet jtszik.
- tvonalelemzs
- A formlis mdszerek: Formalizlt tervekbl generl kdot, vagy megvizsglja,
hogy a kd szrmaztathat-e a specifikcibl. Reprezentci-transzformci
trtnik. Drga, idignyes. A formlis mdszerek csak igen nagy biztonsgot
ignyl rendszereknl fontosak. Alapja a matematikai logika.
Formlis mdszertanok: B, SDL, BDM, Clean Room.
Inkbb eszkzk: VDM, Z.

tvizsgls elnyei a tesztelssel szemben:
- A tesztels nem dert fel hibacsoportokat.
- A tesztelsnl a mellkhatsok soha nem derlnek ki.
- Tesztelst csak futtathat kdon lehet vgezni.
- Az tvizsgls olyan verifikcis szempontokra is figyelemmel lehet, amikre
tesztelsnl ltalban nem. Pl. Bizonyos szabvnyok betartsa. A rossz programozsi
stlus kidertse. Kd megrthetsgnek a vizsglata.

Az tvizsglst is csapat vgzi, amelynek rsze a program rja. Elszr tnzik
specifikcit kzsen, s aztn egyedileg nzik t. Aztn sszelnek s megbeszlik.
Megllaptjk a specifikcinak nem megfelelst. Ezutn a program rja megcsinlja a
belvst. Majd megint sszelnek, s kezdik elrl. Az tvizsglst vgzknek jratosnak
kell lennik az adott nyelvben, az adott szakterleten.


Milyen jelleg hibkat tud felderteni egy ilyen csapat?
- Adathibk. Minden vltoz kapott-e rtket.
- Tmb indexszelse megfelel-e.
- Van-e puffertlcsorduls.
- Vezrlsi hibk.
- Elgaztat utastsok.
- Ciklusok szablyosan fejezdnek-e be.
- I/O hibk.
- Vratlan inputok esete.
- Interfszhibk.
- Paramterkirtkels, -tads.
- Trkezels.
- Kivtelkezels.

2. Tesztels:
Dinamikus technika. A programot teszteljk futtatssal. Nagyon ritkn vgzi a program
rja. Kln tesztel csoportok vannak. A tesztels nem bizonyt semmit. Plne azt nem,
hogy hibtlan a szoftver. A rendszerteszteket a legtapasztaltabb embereknek kellene
vgeznik, ezzel szemben sok cg friss diplomsokat alkalmaz tesztelsre.

Fajti:
1. Validcis: A tesztelssel azt prbljuk beltni, hogy a felhasznlnak
megfelel-e a program. Azt prbljuk bizonytani, hogy a szoftver j.
a) Statisztikai - Metrikk lsd. ksbb. Valamit mrnk, s abbl prblunk
kvetkeztetseket levonni.
b) Megbzhatsgi - A felhasznl szmra trtn megbzhatsg
tesztelse.
2. Hinyossg - A programban lv problmk feldertst szolglja. Akkor
sikeres, ha minl tbb hibt feldertnk.

Belvs: lesen szemben ll a tesztelssel. Belvskor megprbljuk kijavtani a hibkat.
Ami azzal kezddik, hogy megprbljuk behatrolni a hiba helyt. A tesztels csak felderti
a hibt. A debugger belvsi eszkz ppen ezrt. Mindig a program rjnak a feladata.

Tesztels, belvs:


Regresszis vagy jratesztels. jra lefuttatjuk a tesztet, ugyanazokra az input adatokra,
amelyek korbban a hibt okoztk. Ezzel bizonytjuk, hogy a javts sikeres volt.

A verifikci s validci az egsz fejlesztsi folyamaton vgigvonul, nem az
implementcinl kezddik. Erre utal a klasszikus 3. V bet.
V&V elemei (a 3. V bet):



A nagymret informcis rendszerek alrendszerekre bomlanak. A rendszerarchitektra
igazndibl alrendszerarchitektra elsdlegesen.
Az alrendszerek modulokra bomlanak. Az alrendszer s modul kztt a kvetkez a
klnbsg. Az alrendszerek nllak, megfelel rendszeren belli funkcionalitssal.
Az alrendszerek megfelel interfszeken keresztl kommuniklnak. Magyarn ha egy
alrendszert kiemelek, attl mg a rendszer megy tovbb, max. a kivett funkcionalits
hinyzik belle. A modulok nem nllak. A modulok egymsra plnek, egyms
funkcionalitst hasznljk.
A tesztels lekveti a rendszer struktrjt. A tesztelst is tervezzk.
Mit kell tartalmaznia egy teszttervnek?
- Le kell rni a tesztelsi folyamatot magt.
- Le kell rni azt, hogy melyik kvetelmny tesztelse folyik az adott lpsben.
- Meg kell mondani, hogy a rendszer melyik rszt teszteljk. Metdus, osztly stb.
- A teszttervben kell lennie temezsnek.
- Meg kell hatrozni, hogyan trtnik a dokumentlsa a tesztnek.
- Meg kell adni a hardver s szoftverkvetelmnyeket.
- A tesztelsre vonatkoz korltokat, megszortsokat.
A teszttervek nem statikus dokumentcik.

Az agilis fejlesztsi mdszertan nem vlasztja el a tesztelst az egyb lpsektl.


Modulteszt, egysgteszt: A modul az a legkisebb egysg, amit a programoz fejleszt ki.
Pl. egy metdus vagy egy osztly, de osztlynl nem nagyobb. Ezeket a modulokat ssze
kell integrlni alrendszerr.
Az alrendszer integrcis teszt terve a rendszertervezsbl jn. Az integrcis tesztet kln
tesztel csapatok vgzik. Az alrendszerekbl ssze kell integrlni a rendszert.
tvteli teszt, vagy tadsi teszt: Amg az eddigi tesztek tipikusan hinyossgtesztek, az
tvteli teszt az validcis teszt. Az tvteli teszt demonstrlja a felhasznlnak, hogy azt a
rendszert kapja, amit vrt. A kvetelmnyekbl s a specifikcibl jn.


Teszteset: Adott tesztben szerepl inputok s outputok egyttese. Az outputtal van a
problma. A felhasznlk ismereteit kell felhasznlni, teszteseteket nem lehet automatikusan
ellltani. A tesztesetet meg kell tervezni. Vgigksri a teljes tervezsi folyamatot.

Teszt adat: ellltsuk vagy manulisan, vagy automatikusan trtnik.

Kimert tesztels: az sszes elkpzelhet vgrehajtsi szekvencit leteszteljk. Ha van
ciklus, a szekvencik szma vgtelen. (Ki kell alaktani tesztelsi irnyelveket!)
Ha menvezrelt a program, akkor minden menpontot tesztelni kell. A
funkcikombincikat is tesztelni kell. Azokat a szekvencikat tesztelni kell, amikben az
sszes utasts benne van. Az input adatokat is jl meg kell vlasztani, helytelen inputra is
tesztelni kell.
OO rendszerekben metdusokat, objektum klnbz llapotait, az osztlyt, framework-
ket tesztelhetjk.


Tesztels fajti:
- Rendszertesztels kt fajtja:
1. Integrcis tesztels: Alrendszerek sszeptst teszteli. Tipikus hinyossg
tesztels. Regresszis teszten alapul. Trtnhet:
a) Lentrl felfel:
A modulok sszeptsbl kapjuk a rendszert.
Teszt meghajtk kellenek, melyen a krnyezet viselkedst
szimullhatjuk. Akkor hasznljuk, ha az architekturlis terv ksbb alakul
ki. Nehezebb a teljes rendszer mkdst demonstrlni.
b) Fentrl lefel:
Az egsz rendszert teszteljk.
A magas szint elemek tesztelsvel kell kezdeni.
Bizonyos funkcik mg nem implementltak mikor tesztelnk, ezrt
szimullni kell ket. A szimulci idnknt problms.
2. Kiadsi tesztels: Validcis tesztels. Ha a felhasznlt is bevonjuk a tesztelsbe,
akkor elfogadsi tesztels. Itt az n. fekete doboz tesztet alkalmazzuk. Nem
ismerjk a kdot, inputokat adunk neki s figyeljk az outputot.

Az inputokat hogyan tervezzk meg?
o A rendellenes inputokat vissza kell dobnia a rendszernek.
o Ki kell derteni a puffertlcsordulst okoz inputot.
o Ugyanazt az inputot tbbszr is ki kell prblni.
o Minden inputnak van egyfajta tartomnya. A tartomny szlssges adataira
is tesztelni kell.

A szoftvereknl egy j kiads ellltsnl a kiadsi tesztet a cg vgzi. s, ha egy
adott szinten megbzhatnak minstik a rendszert, akkor azt mondjk, hogy elllt
egy alfa verzi. Ekkor jn a bta teszt, amibe mr kls embereket is bevonnak.
Ezutn elll egy olyan kiads, amiben a hibk szmt lecskkentettk. Ezek utn
megjelenik a szoftver. Adott megbzhatsgi szint, senki sem lltja, hogy nincs
benne hiba.


- Stressztesztels:
Teljestmny teszt. A rendszert megprbljuk egyre nagyobb tesztelsnek kitenni. Kt
irnyba mehet el. Egyre nagyobb adatokkal tesztelnk, vagy a rendszerrel val
interakcik szmt nveljk. A normlis rendszer a stressztesztels hatsra is
mkdkpes marad. Folyamn kimrhet a mkdsi profil. Az a rendszer a j, ami
hibatr, nincs olyan inputja, ami kifekteti, hangolhat. A mkdsi profil a hangolshoz
fontos. Pl.: tartalmazza azt az informcit, hogy a program mely funkcikat hasznlja
sokszor. Ezeknek a funkciknak kell nagyon jl mkdnik.
Ma problmt jelent, hogy a rendszerek kis rsze hangolhat. Nagy rendszerek esetn kevs
informatikus kpes arra, hogy hangolja.

- Interfsztesztels:
Az OO rendszerekben felersdtt. (Itt interfsz alatt a kommunikcis felletet rtjk).
Kvetkez mdon osztlyozhat:
o Paramter interfsz: Ezeken keresztl adatok tovbbtdnak. Nha fggvny
referencik.
o Osztott memria interfsz: A modulok kzs memriaterletet hasznlnak.
o Procedurlis interfsz: Osztlyok kommunikcis interfsze, vagy egy csomag
interfsze.
o zenettovbbt interfsz: zenetek segtsgvel interfsztesztels, mint
kommunikcis teszt.

- Komponenstesztels, modultesztels, egysgtesztels:
A fejleszt vgzi. A rendszer olyan kis rszeire vonatkozik, melyek nllan tesztelhetk. A
belvsi folyamat is egyszerbb. A komponenstesztels majdnem minden esetben
hinyossg tesztels is.
Teszteset tervezs modultesztelsnl:
1. Kvetelmny alap tesztels: A rendszerfejleszts megkezdse eltt jelenik meg.
Magas szint tesztek, a validcis s hinyossgi tesztelst egyarnt szolgljk

2. Partcis tesztels: A fekete dobozos tesztelsnek egyfajta vltozata. Az input
adatokon vgrehajtunk egy gynevezett ekvivalencia osztlyozst. Partcis
tesztelsnl meghatrozzuk az ekvivalencia osztlyokat rszben a specifikci
alapjn, rszben az adott szakterlet ismeretben. ltalban felttelezzk, hogy ha
egy ekvivalencia osztlyt feldertettnk, akkor ebbe az osztlyba es brmely adatra
a program ugyangy fog viselkedni, mint brmelyik msik ekvivalencia osztlybeli
adatra.
Partcis teszt klszablyok:
o Egy elem sorozatot is tudni kell kezelni (nem csak tbb elemt) amikor
valamilyen sorozatot kezelnk. Gyakran egyelem sorozatokat nem kezelik
az alapszoftverek.
o Ugyanarra a tesztadat sorozatra tbbszr is le kell futtatni a programot.
o Klnbz mret input adatra kell futtatni teszteket.
o Az ekvivalencia osztlyba tartoz adatok, ha rendezettek, akkor olyan
tesztadat sorozatokat kell vlasztani, amiben az ekvivalencia osztly szls
elemei s kzepn lv elemek is benne vannak. s ezekre kell tesztelni a
programot.

3. Struktra teszt (fehr doboz):

A fekete doboz teszttel szemben itt ismerjk a kdot, s a kd ismeretben
hatrozzuk meg a tesztesetet, a kd ismeretben generljuk az adatokat. Tipikus
modul teszt. Az adott modul rja ezzel a mdszerrel tesztel. Integrcis tesztnl nem
jhet szba.
A kd ismeretben jabb ekvivalencia osztlyok hozhatk ltre mondjuk a partcis
tesztelshez, jabb tesztesetek adhatk meg, mintha csak a specifikcit ismernnk.

4. tvonaltesztels: Tipikus modultesztelsi eljrs. Tudjuk, hogy a kimert
tesztelsnl az sszes lehetsges vgrehajtsi szekvencit teszteljk. E helyett jn az
tvonal teszt, amikor klnbz futsi szekvencikra tesztelek. A program vezrlsi
szerkezetben felfedezhet ton legalbb egyszer vgigmegyek. Ehhez megadhatjuk
a program folyamatgrfjt, ami a vezrlsi szerkezetet tkrzi. Ha nincs goto, akkor
ez meglehetsen gyorsan, s automatikusan megy.

Automatizlt teszteszkzket hasznlnak ltalban.
(bra)
A dinamikus elemznek az a feladata, hogy futsi profilt lltson el.


Minsgkezels

A szoftvernek, mint minden ipari termknek van minsg aspektusa. Ez annyit jelent, hogy az adott
termk megfelel a specifikcijnak. A szoftver specilis termk, mert nem lehet gyrtani, hanem
szellemi termkknt lltjk el. A szoftvert a kvetelmnyek alapjn tervezik, de a problma ott
van, hogy a kvetelmnyek nem biztos, hogy pontosan felderthetk, kiderthetk, elemezhetk,
tervezhetk. Egy verifiklt szoftver lehet a specifikcijnak megfelel, de nem biztos, hogy
validlt. Az ipari termkeknl egy verifiklt szoftver ltalban validlt, mert a specifikcija
validlt. A specifikcit mg nem tudjuk validlni a szoftvernl.

Fogalmak a minsgkezels vonatkozsban:
- Minsgbiztosts: A j minsg szoftverek ellltst eredmnyez szabvnyok s
elrsok. A minsgbiztosts egy szabvnyeggyttes, vagy eljrseggyttes.
- Minsgtervezs: Amikor egy konkrt szoftverprojekt vonatkozsban, kivlasztjuk az
elbbi szabvny s eljrseggyttesbl azokat, amelyek illeszkednek, megfelelnek az adott
projekthez. A projektre szabjuk a minsgbiztosts ltal adott szabvnyokat, eljrsokat.
- Minsg-ellenrzs: Azoknak a folyamatoknak a meghatrozsa s ktelez kvetse,
amelyek biztostjk, hogy a projekt fejlesztcsapata alkalmazza a minsgtervezsben
meghatrozott szabvnyokat s eljrsokat.

A minsgkezelshez kell egy mindenkori szoftverfejlesztsektl fggetlen minsgkezel,
minsgbiztost csapat, amely folyamatosan fejleszti, karbantartja a vllalati minsgbiztostsi
szabvnyokat, eljrsokat.
Kell egy minsgtervez csapat, amelyben benne kell legyen a projektvezet.
A minsg-ellenrzs pedig teljesen fggetlen a fejlesztcsapattl.

Az ipari termkeknl a minsgbiztostsi szabvnyok egyrtelmen folyamatszabvnyok.
Klasszikus minsgkezels azt mondja, hogy biztostani kell, meg kell hatrozni a folyamatot,
aminek eredmnyeknt elll a termk, s ha a folyamat j a termk is j lesz. Szoftvernl ez kicsit
mskpp van, nem elg csak a folyamatot kezelni, mert gy mg nem garantlt a minsgi szoftver.

(bra)

Szoftver minsgbiztostsnl a szabvnyok kt nagy fajtjrl beszlnk:
1. Folyamatszabvnyok, amelyek a tevkenysghez ktdnek. Vgigkvetik a
szoftverfejleszts teljes ciklust.
2. Termkszabvnyok a folyamat vgeredmnyeknt elll szoftvertermkre vonatkoznak.

A szoftverfejlesztsben a szabvnyok a kvetkez 3 terleten nyjtanak segtsget,
tmutatst:
1. A termk s folyamatszabvnyokban sszegyjtjk a legjobb s a legrosszabb
gyakorlatokat.
2. A szabvnyok jl definilt keretrendszert adnak. Ez a keretrendszer minden
szoftverprojektre jl testreszabhat. Keretrendszer, amelyben a projektet meg lehet
szervezni a szabvnyok mentn.
3. Egy szoftverprojektben a szabvnyok biztostjk a folytonossgot. Ha valaki kiszll a
fejlesztsbl, s szabvnyosan fejlesztettk a projektet, akkor brki be tud szllni.


Minsgkezels lpsei:
1. Minsgbiztosts
Minsgkezels 1. lpse a minsgbiztosts. Minsgbiztosts alatt a j minsg
szoftverek ellltst eredmnyez szabvnyokat s elrsokat rtjk. A minsgbiztosts
egy szabvnyeggyttes, vagy eljrseggyttes.

2. Minsgtervezs
Minsgkezels 2. lpse a minsgtervezs. A minsgkezels szabvnyait az adott
projektre szabjuk. Megtervezzk, hogy az adott fejlesztsi projektben milyen eljrsokat,
mdszereket, szabvnyokat fogunk alkalmazni s hogyan. Ha a projekt j eljrsokat,
mdszereket, szabvnyokat kvn, akkor ezeket meg kell alkotni s bepteni az eddigi
rendszerbe.
Minsgtervezsnl a kvetkez krdsekre kell kitrni (klszablyok):
- Be kell mutatni a szoftvert, abban az rtelemben, hogy a szoftverrel szemben
milyen minsgi elvrsok vannak.
- Meg kell tervezni a szoftver kibocstst. Mikor jelenik meg a szoftver, vagy mikor
adjuk t, milyen ktelezettsgeket vllalunk a szoftver mkdtetse idejn, milyen
kvetst vllalunk.
- Meg kell tervezni a fejlesztsi folyamatot, vagyis hogy milyen minsgi
szabvnyokat hasznljunk a fejlesztsi folyamat kzben.
- Meg kell mondani, hogy a szoftver minsgi jellemzi kzl, melyeket tekintnk
alapvetnek. Milyen minsgi clokat tznk a szoftver el.
- Kockzatelemzsi fzis, vagyis a projekten bell milyen kockzatok merlhetnek
fel, amelyek befolysolhatjk a minsget.

Minsgi jellemzk (kls tulajdonsgok, a nem funkcionlis kvetelmnyeknek megfelel
jellemzk):
- Biztonsgossg. A szoftver nem okoz krt.
- Biztonsg. A szoftver vdett a szndkos vagy vletlen krokozssal szemben (hack,
crack ellen vdett).
- Megbzhatsg. Ha lefuttatok egy scriptet, akkor lefut, s ugyanazt az eredmnyt
adja ma is, holnap is, meg tegnap is:-)
- Robosztussg. A felhasznli hlyesgek ellen vdett a rendszer. Hibatr rendszer.
- Rugalmassg
- rthetsg
- Tesztelhetsg. A felhasznl oldali tesztels. A nagyobb rendszerek
rendszerverzikban mkdnek.
Alapveten 3 olyan rendszerverzi van, amit ma alapveten, a nagyobb
rendszerektl megkvetel a piac:
o Termel rendszer vagy les rendszer: Ez az, ami folyamatosan mkdik.
o Fejleszti rendszer: Ebben az zemeltet cg informatikusai dolgoznak,
hangolnak, fejlesztenek.
o Tesztrendszer: Ebben a felhasznlk a felhasznli tesztesetek alapjn
generlt tesztadatokkal tesztelik a rendszert.
o (Homokoz): Teljes rendszer melyben pl. sajt mintaalkalmazsokat, lehet
kiprblni mindenfle kvetkezmny nlkl.

Az els 3 rendszer egyms mellett fut. Fejleszti rendszerbl a termeli rendszerbe
csak akkor kerlhet t egy program, ha azt leteszteltk, s a tesztek azt mutatjk,
hogy az adott rendszer le van tesztelve egy adott mrtkben. Csak tesztrendszerben
tesztelnk (lsd ETR 1-es szrs esete)!
- Alkalmazhatsg. Az adott felhasznli krkben val felhasznlhatsgot jelenti.
Szoks testreszabhatsgnak is hvni. Ez ltalban azon szoftvereknl kerl el,
amelyek nem clrendszerek, hanem ltalnos clra fejlesztik ket (pl. ETR).
- Hordozhatsg. Platformok kztt a rendszer tvihet-e.
- Hatkonysg
- Tanulhatsg
- jrafelhasznlhatsg
- Karbantarthatsg

Ezek a tulajdonsgok egyszerre nem optimalizlhatk, elgg ellentmondanak, egymst
ronthatjk. Ezrt kell kivlasztani a f tulajdonsgokat, f minsgi clokat, s a
minsgtervezst arra optimalizlni. Pl. robosztussg s hatkonysg, egyszerre nem megy.

3. Minsg-ellenrzs
Minsgkezels 3. lpse a minsgellenrzs.
A minsgellenrzsnek kt kzeltse van:
a) Minsgi fellvizsglat. Programvizsglat a minsg szempontjbl. Emberek
vgzik, az adott szoftverreprezentcit tekintik t, s ellenrzik, hogy a
minsgtervezsnl testreszabott eljrsok, szabvnyok betartsra kerltek-e. Kln
minsgellenrz csapatok vannak, amely csapatokba termszetesen be kell vonni a
projektvezett is.

b) Automatikus szoftvermrs. A szoftvermrs azzal foglalkozik, hogy hogyan lehet
egy szoftver bels-, vagy kls jellemzjhez hozzrendelni egy numerikus rtket,
hogy lehet megmrni a jellemzt, s aztn hogyan lehet rtelmezni ezt a numerikus
rtket. Ezt az rtket nevezzk metriknak, szoftvermetriknak.

A szoftvermrs alapveten kt dologra hasznlhat:
1. ltalnos elrejelzst tudunk adni segtsgvel a szoftverrl. Fontos lehet az
erforrsignyek elrejelzse.

2. A szoftver rendellenesen mkd komponenseit kiszrjk a segtsgvel.

Amikor szoftvermrst vgznk, s ellltunk metrikkat, akkor ezekkel a kvetkezket
tehetjk meg:
- Trolhatjuk adatbzisban, s ekkor egy j mrst sszehasonlthatunk az
adatbzisban trolt adatokkal. Ez alapjn becslhetnk, jelezhetnk elre bizonyos
dolgokat, vagy ez alapjn mondhatjuk azt, hogy valami rendellenessg van, mert a
mrt rtk nagyon eltr az elzektl. Az 1. esetben a hasonlsgot hasznljuk fel,
vagyis mrtem valamit s most is hasonlt, teht ksbb is gy fog menni. A 2.
esetben pont az ellenkezje kvetkezik be.
- Bizonyos metrikkra lehetnek szabvnyok, s ekkor a mrt rtket a szabvnyhoz
hasonltjuk, s ez alapjn tudunk valamire kvetkeztetni.

A bels jellemzk jl mrhetk. Ezekbl mindenfle metrika jl szmolhat,
szrmaztathat. Kls jellemzk tbbnyire nem mrhetk, teht metrika bellk kzvetlenl
nem szmolhat, ezrt a kls jellemzket megprbljk visszavezetni valamilyen bels
jellemzre, vagyis bels jellemzhz tartoz metrikbl prblnak kvetkeztetni a kls
jellemzkre.
Egy bra a kls-, bels jellemzk kapcsolatrl.
(bra)

Megjegyzs:
Lthat, hogy a kziknyv hossza nagyszeren mrhet mondjuk karakterek szmval, s
ebbl valamilyen mdon kvetkezik a hasznlhatsg, rthetsg. Viszont a
hordozhatsgra hiba mondom, hogy 21.


Metrikk

Metrika osztlyok:
1. Termkmetrika - A szoftverre, mint termkre vonatkozik. A termkmetrikkon bell:
a) Dinamikus metrika - A programhoz kthetk, s csak a futs kzben llthat el,
mrhet meg.
b) Statikus metrika - A szoftver brmely elemre vonatkozik (doksi, forrs stb.), s
nem kell futatni, mivel nem is lehet. ltalban knnyen szmolhatk.
2. Folyamatmetrika - A szoftver ellltsnak letciklusra, mint folyamatra vonatkozik.

Az 1, 2 is lehet:
a) Primitv metrika Az, ami kzvetlenl szmolhat valamilyen jellemz alapjn.
b) Szrmaztatott metrika - Nylvn ms metrikkbl szmolhat. ltalban sokkal jobban
szmolhatk, mint a primitv metrikk, taln azrt is, mert gyakran dinamikus s statikus
metrikk egyttesbl szrmazik.

Szoftvermrs-folyamata:

1. Meg kell fogalmazni a szoftverrel kapcsolatos krdseket! (pl.: Mirt nem tudom felvenni a
trgyamat 3. napja ETR-ben?) Ki kell vlasztani azokat a mrseket, amelyek a krdseket
megvlaszoljk!
2. Ki kell vlasztani azokat a komponenseket, amelyeken a mrst vgezzk!
3. Vgrehajtjuk a mrst. Ellltjuk a metrikkat.
4. A mrt rtkeket szabvnyokhoz, vagy az adatbzisban trolt rtkekhez hasonltom. Relatv
rtkek vannak, vagyis a szoksoshoz kzeli vagy kiugr rtket mrtem-e.
5. Mirt mrtem kiugr rtket? Itt jn a magyarzat. A mrt rtkek mit jelentek. Ehhez vissza
kell nylni a komponenshez. A komponens segtsgvel prblom megmagyarzni. Ez lehet
egy iteratv folyamat, mert a vgeredmnyek segtsgvel pl.: pontostani tudom a
krdseket.

Egy idelis metrika a kvetkez 5 tulajdonsggal rendelkezik:
1. Pontosan definilt. Mindenki szmra vilgos, hogy az adott metrika mit jelent.
2. Objektv. A mrst sokszor meg tudjuk ismtelni, s mindenki vgre tudja hajtani.
3. Validlt. Azt mri, amit kell. A mrs definilsa utn a mrst elg sokszor vgrehajtva, a
metrika valban azt mri, amit kell.
4. Robosztus. A metrika viszonylag rzketlen a folyamat, vagy a termk olyan vltozsaival
szemben, amelyek nem a validlt mrshez tartoznak. Amit nem mrek, az nem befolysolja
a mrst.
5. Knnyen s olcsn vgrehajthat a mrs.

Termkmetrikk kzl nhny:
- Mretre vonatkoz metrikk - A szoftver kiterjedst szmszerstik valamilyen mdon.
o Azonostk hossza - Automatikusan meghatrozhat. Egy hosszabb azonost
valsznleg tbb informcit rul el az adott eszkzrl, mint egy rvidebb (beszl
nevek). Viszont ha az tlagos hossz nagyon nagy, akkor rthetetlenn vlhat a kd.
Egyszeren szmolhat, de nem sok mindenre j.
o LOC - (Lines of Code) Kdsorok szma. Problmja, hogy mit rtnk alatta.
Leggyakrabban hasznlt az effektv LOC, ami a kd azon sorait veszi figyelembe,
amelyek nem resek, s nem megjegyzsek.
Egyszeren szmolhat, de adott nyelvre, adott programozra vonatkozik. LOC-bl
olyan kls jellemzkre kvetkeztethetnk, mint karbantarthatsg, rthetsg,
tanulhatsg, hibk szma.
o FP - (Function Points). A felhasznli inputok, az outputok, a lekrdezsek, s a
program ltal hasznlt trzsllomnyok slyozott egyttes szmt jelenti.
Statikus. Olyan metrika, amelyet a projektre kell szabni. Az adott projekten bell kell
megmondani milyenek a slyok. Pl. input, lekrdezs 4, output 5, trzsllomny 10.
Az gy meghatrozott szmot mg korrigljk. A program implementlsa eltt
meghatrozhat az rtke, a tervezs szakaszban meghatrozhat. ltalban
erforrs-elrejelzsre hasznljk.
- Komplexitsi metrikk - A program sszetettsgt, bonyolultsgt mrik. Statikus, bels
mrtkek. Minl nagyobb az rtke, annl nehezebben rthet, nehezebben
jrafelhasznlhat, karbantarthat, nagyobb valsznsggel hibs a kd.
o Feltteles szerkezetek mlysge.
o Ciklomatikus komplexits - Az tvonaltesztelsnl emlegetett folyamatgrf alapjn
mri a komplexitst. Ha "goto" mentes a program, akkor a kvetkezkppen
szmolhat: az lek szmbl levonjuk a csompontok szmt, s hozzadunk
kettt. Igaz ez akkor, ha nem adatvezrelt a program, mert ebben az esetben nem
biztos, hogy r brmit is.
o Informciram - Alprogramok komplexitst mri. A program mkdsi
komplexitst mri. Ennek segtsgvel a program futsa kzben felpl hvsi lnc
mrete alapjn lltunk el egy metrikt.
C = [alprg. hossza] * b
2
* k
2

b: azon egyb alprogramk szma, melyek az adott alprogramot meghvjk.
k: azon alprogramok szma, melyet az adott alprogram hv.
o Halstead-fle metrikk:
a) n: Programsztr metrika - Megszmolja a klnbz opertorokat, s
operandusokat, s ezeket sszeadja. A szmts komplexitst mri.
b) N: Hosszmetrika - Az sszes opertort, s operandust sszeszmolja, s
sszeadja. Ez egy mretmetrika.
c) Ktetmetrika - A fenntiekbl szrmaztatja Halstead. A program futtatsa
sorn szksges trterletet becsli. V = N * log2(n)
- Hinyossgi metrikk:
o Terv vltozatok szma.
o A szoftvertvizsglsok sorn tallt hibk szma.
o A tesztels sorn adott idegysg alatt szlelt hibk szma.
o Kdmdostsok szma.
o Megbzhatsgi metrikk (dinamikusak)
o POFOD - (Probability Failure On Demand) Annak a valsznsge, hogy a rendszer
adott szolgltatskrs esetn hibzik.
o ROCOF - (Rate Of Failure Occurence) Hibaintenzits. Adott idegysg alatti hiba-
elfordulsok gyakorisgnak a szma.
o MTTF - (Mean Time Of Failure) Kt hiba-elforduls kztt eltelt tlagos id.
o AVAIL - (Availability) Rendelkezsrells. Milyen valsznsggel rhet el a
rendszer.
- OO metrikk kzl nhny:
o Number Of Attributes per class (NOA): Osztlyok belli attributumok szma
o Number Of Methods (NOM): Osztlyok belli metdusok szma.
o Message Passing Coupling (MPC): zenettovbbts szorossga. Van A B osztly...
Az A osztly kt klnbz metdusa meghvja a B ugyanazon metdust.
Megszmoljuk, hogy hnyszor van ilyen szituci. A klnbz metdusai hnyszor
veszik ignybe ugyanazt a szolgltatst B-tl. Tl nagy rtk nem j, valsznleg
tervezsi hiba.
o Data Abstraction Coupling (DAC): A megadott osztly ltal definilt absztrakt
adattpusokat szmllja.
o Lack of Cohesion in Methods (LCOM): A metdusok kohzijnak a hinya. A
metdusok eltrsgt mri az ltaluk hasznlt pldnyszint attribtumokon
keresztl.
m
1
, m
2
, ... , m
n
az osztly metdusai,
{Ij} az mj metdusai ltal hasznlt pldnyszint attribtumok halmaza.
Ekkor legyen
P = {(Ii,Ij)|Ii Ij =0} i j,
Q = {(Ii,Ij)| Ii Ij 0}.
LCOM = |P|-|Q| ha |P|>|Q|,
0 egybknt.
Akkor a j, ha az rtke 0. Ha nem 0, akkor a funkcionalitssal problma van.
Refactoring kell.
o Loose Class Cohension (LCC): Laza osztly kohzi. Az osztly publikus
metdusai kzl azon metdusprok szzalka az sszes lehetsges metduspron
bell, amelyek kzvetlenl, vagy kzvetett mdon azonos attribtumokat
hasznlnak.

Folyamatmetrikk kzl nhny:
- Idmetrikk
- Erforrsok (munkaer, pnz, hardver/szoftver)
- Bizonyos esemnyek bekvetkezsi szmt figyelem
- Tevkenysg (ovlis)
- Rszfolyamat (ovlis akrmi bernykolt rsszel)
- Rsztermk (rnykos tglalap)
- Felttelek, korltozsok, megszortsok (tglalap)
- Kivtelek (dupla fal tglalap)
- Szerepkrk (rnykolt kr)
- Folyamat irnya (nyilak) /balrl jobbra/


Informatikai Projekt


A projekt egy olyan tevkenysgsorozat, amelynek a fbb tulajdonsgai a kvetkezk:
- Van valami meghatrozott konkrt clja.
- A projekt elllt valamit.
- Van kezdete s van vge.
- Van kltsgvetse.
- Erforrsokat hasznl. (hardver, szoftver, humn-erforrs)
- Vannak minsgi kritriumok a projekthez s a termkhez.


Projekt hromszg:


Ezek egyms ellen hatnak.
Minsg: Az elrt termket hasonltjk az elvrsokhoz. Ha 1 krl van a hnyados, akkor j volt a
projekt. Ha 1-nl kisebb, akkor az elvrsokat nem sikerlt teljesteni. (Ha 1-nl nagyobb, az sem
j, mert elknyeztettk a felhasznlt. by Pici)

Az informatikai projektek jelents rsze most is megbukik. (kb. 20%-uk) Ami annyit jelent, hogy a
projekt nem jutott sehova. Kb. 30% krl van a sikeres informatikai projektek szma. A maradk
projektekben valami problma lpett fel.

Ezek a problmk jelentkezhetnek az informatikai projekteknl:
- Nincs vilgosan megfogalmazva a cl.
- Kevs az erforrs.
- Rossz a vlasztott technolgia.
- Gyenge a kommunikci a projekt rsztvevi kztt.
- Nincs kvetelmny-, s vltoztatskezels.
- Nincs normlis dokumentls.
- Gyengk az emberek.
- Vagy egyszeren csak sszevesztek.

Ha nincsenek ezek a problmk, akkor nagy valsznsggel sikeresek a projektek.

Hrom f ok, ami miatt megbukik egy informatikai projekt:
- Id nem relis.
- A humn-erforrs kezelsben problma van.
- A projekt terjedelme nem megfelel. (scope)

Az informatikai projektek specialitsai:
- Ezek a projektek ltalban kicsik.
- Az informatikai projektekben tipikusan okos, rzkeny, individualista emberek vesznek
rszt. Magasan kvalifikltak a rsztvevk.
- ltalban tiszta informatikai projekt nincs; rszei ms projekteknek. Sok mindentl fgg a
projekt.

Informatikai projektek fajti:
- Termkfejlesztsi projekt: Valamilyen dobozos szoftvert lltunk el. A fejleszt cg egy
informatikai termket akar kifejleszteni.
- Alkalmazsfejlesztsi projekt: Megrendelsre kszl. Clszoftvert fejlesztnk. Van egy
megrendel, akinek az ignyeit ki kell elgteni.
- Rendszerintegrlsi projekt: Meglv rendszerek sszepakolst vgzi.
- Bevezetsi projekt: Vagy lecserljk az eddigi rendszernket, vagy eddig nem volt s
bevezetnk egyet.
- Infrastruktrafejlesztsi projekt: Hardvert s alapszoftvereket vesznk.
- Tanulmnyksztsi projekt: Valamilyen krnyezetvizsglat, felmrs, hatsvizsglat a cl.
Vagy magunk vgezzk, vagy megrendeljk.
- Tesztelsi projekt: Valamilyen rendszer tesztelst vgzi.


Projekt folyamatai:
A projekt folyamatok tbb fzist, vagy az egsz projektet vgigksrik. Az egyik legfontosabb
folyamat, amivel indul az egsz: projektbecsls, amibl meg kell mondanunk az idt s a
kltsgeket. Teht a projekt elejn temezni kell. Nincsenek egzakt mdszerek, csak becslsen
alapul mdszerek.
- Projektbecsls:
Kvetkez id -, s kltsgbecslsi technikk alakultak ki:
a. Metrikkon alapul becsls: Vesznk valamilyen termkmetrikt, s errl
prblunk meg valamilyen becslst adni az idre s a kltsgekre. COCOMO
kltsgbecsl modell a leghresebb kltsgbecsl modell:
rfordts = a * (mret)
b

Az a s b olyan lland, amik gyakorlati projektek alapjn lettek becslve.
Rfordts: Az id emberi hnapban.
Mret: Valamelyik mretmetrika. Attl fggen, hogy a vizsglt projekteknek milyen
jellemzi voltak (termk mrete, fejleszt csapat mrete, hatrid szorossga stb.). 3
kategrit llaptottak meg;
egyszer -> bonyolult (a=2,4..3,6; b=1...1,3 krl).
Ha a teljes tfutsi idt is becslni akarjuk (a teljes projekt id hnapban):
2.5*(rfordts)
c

(*C : COCOMO mg ezt hozzrakja)
Teht a teljes projektid stabilabb. Ebben a krnyezetben lehet figyelembe venni a
projekt krnyezett.

b. Terven alapul becsls: A tervezsi fzisban elll terv egyes elemeihez
egyenknt rendelnk idt s kltsget megfelel mdszerrel vgrehajtunk
egy temezst, ha sszeadjuk, megkapunk egy teljes idrfordtst s teljes
kltsgrfordtst.

- Lthatsi idn alapul becsls

a. Termken alapul becsls: A szoftvernek bizonyos jellemzit hamar le kell
s le lehet rgzteni. (A ma divatban lv interfsz alap terveknl a
kifejlesztend szoftver kpernyit hamar rgzteni kell.) A rszre leadott
becsls nem biztos, hogy jl becsli a teljeset.

b. tfutsi idn alapul becsls: gy becsl, hogy megvizsglja egy adott
idintervallumban az adott projektlpst mekkora s milyen minsg csapat
tudja vgrehajtani? Az idt rgztem, s az idhz prblom hozzrendelni a
csapatot, s a kltsget ebbl pakolom ssze.

c. Analgis becsls: Az eddigi lefutott projektek kztt keresnk olyan
projektet, ami a legjobban hasonlt a mostani projekthez s ismervn a
lefutott projektnek az id s kltsg ignyt, s ebbl prblok becslni -> a
projektek adatait trolni kell.
Ma mindenfle adatbzisok rendelkezsre llnak, mindenfle elemzst
vgrehajthatok, klns tekintettel az analgis elemzsre. (A komoly projektek
analgis becslseket hasznlnak.)

- Nyer r: Melyik az az r, amelyiken megnyerem a projektet? Az kapja a projektet,
aki a legolcsbban meg tudja csinlni. Veszlyes, mert abbl kell kifejleszteni, de
kevs pnz mg mindig tbb, mint a semmi.

- Design-&-schedule: Adva van a termk kifejlesztsi hatrideje. Innentl kezdve
visszafel tervezek. Idcsszs nincs.

- Van x emberem, a felhasznl y id alatt akarja a programot, a becslsem x*y.


Scope:
Arra vonatkozik, hogy meghatrozzuk a projekt mivel foglalkozik s mivel nem. Ennek
sorn meghatrozzuk a projektkvetelmnyeket, s ezek adjk a projekt scope-jt.

Projektkvetelmnyek:
- Stratgiai.
- Technikai/technolgiai.
- Ms rendszerekkel val kapcsolatra vonatkoz.
- Logisztikai.
- Minsgi.

Kvetelmnymenedzsment: Kezeli a kvetelmnyeket. Az egsz projektmenedzsment
kulcsa a vltoztatskezels. Mivel vltoznak a termkkvetelmnyek, vltoznak a
projektkvetelmnyek, vltoznak a csapat tagjai, vltoznak a felhasznli ignyek.
A vltoztatst mindig dokumentlni kell, s a vltoztatst mindig engedlyezni kell. A nem
engedlyezett vltoztatst nem lehet vgrehajtani. Vltoztatskezelsi szabvnyok s
technikk vannak. Ezek ltalban bels szabvnyok, mindenfajta dokumentumokat kell
kitlteni sokszor. De ezt vgig kell csinlni. A vltoztatskezelsnek vannak automatizlt
szoftverei (a projekt vonatkozsban).

Konfigurcikezels:
A projekt rendelkezsre ll hardver-, s szoftverforrsoknak a kezelse.

Kockzatkezels:
Kockzat alatt egy olyan esemnyt rtnk, amely nem tervezett, de valamilyen
valsznsggel a jvben bekvetkezhet. Fel kell kszlnnk egy ilyen esemnyre, meg
kell becslnnk, hogy milyen esemnyek milyen valsznsggel s mikor kvetkezhetnek
be. A kockzat nem biztos, hogy negatv (zmben az).

Kockzat kategrik:
- Technolgiai, mdszertani.
- Pnzgyi.
- Kereskedelmi.
- Szervezeti.
- Humn-erforrs kockzatok.

Kulcs-kockzatok:
- A projekt mrete nvekszik (mert a felhasznl ignyei nnek, az elvrsok nnek).
Ezzel szmolni kell.
- Rossz volt a becsls.
- A csapatbl tvoznak alapvet szerepeket betlt munkatrsak.
- A csapat inhomogn. A termelkenysg nagyon szr. Programozk hatkonysga
nagyon eltr lehet. Csapatproblmkat vethet fel.
- Alkalmazsfejlesztseknl a megrendel, s a szllt sszeveszik.

Kockzatkezels felderteni a kockzatokat! Megbecslni, hogy milyen valsznsggel
kvetkeznek be! Megbecslni, hogy milyen krokat okozhatnak a kockzatok!
Kockzati mtrix: 3*3

Megjegyzs:
A szrkkkel nem foglalkozunk.
Valsznsg lehet kicsi, kzepes, nagy. Minden kockzat vonatkozsban elhelyezzk a
mtrixban.


Informatikai projektek dokumentcija, jogi vonatkozsok

Megrendel <- Fejleszt

Fogalmak:
- Ajnlat: az ajnlat elfogadsa a megrendel rszrl szerzdsnek minsl. A magyar
jogrend szerint szban is lehet szerzdst ktni.
Egy ajnlatnak a kvetkezket kell tartalmaznia:
o Meg kell nevezni, hogy ki teszi az ajnlatot.
o Le kell rni, hogy mi az ajnlat
o Le kell rni azokat a feltteleket, amelyek mellett az ajnlat rvnyes (hatrid,
mennyirt?)
o Le kell rni, hogy meddig rvnyes az ajnlat
- Szerzds: meghatrozza azokat a kereteket, melyek mentn a projekt szervezdik.
Szerzds fajtk:
o Munka-szerzds: A cg embert alkalmaz. Munkaviszonynak minsl.
o Vllalkozsi-szerzds: Jl krlhatrolt, konkrt feladatra vonatkoz szerzds.
Vllalkozsi djjal egyenlti ki a megrendel.
o Megbzsi szerzds: Nem egy konkrt cl, hanem valamilyen tevkenysg elltst
clozza meg. ltalban valamilyen mdon mrjk a befektetett munka mennyisgt
s valamilyen egysgekben fizet a megrendel.
o Kutatsi szerzds: A vllalkoz semmilyen garancit nem vllal.
o Licensz szerzds: Valamilyen informatika szolgltatst cloz. Ma meglehetsen
divatos.

Az ajnlatot s a szerzdst is cgszeren kell alrni. Minden cgnek megvan, hogy milyen
a cgszer alrs.
A szerzds ltalban tartalmaz hatridket. Adott hatridre adott rsztermknek el kell
kszlnie.

- Projekt defincis dokumentumnak, amely pontosan lerja magt a projektet s mellette
szoks egy minsgkezelsi dokumentumnak is lennie. Ezek nlkl projekt nem indthat.

- Szakmai dokumentum: kimondottan az informatikai oldalrl lnyeges. Mszaki
dokumentumok.

- Projekt dokumentumok: A projekt folyamn mindenflekppen van naplzs, vannak
emlkeztetk s jegyzknyvek. Emlkeztet minden meetingrl. Jegyzknyv minden
dntsrl.

- Teljestsigazolsok: annak az igazolsa, hogy a szerz eleget tett a szerzdsben
lertaknak.

- Zr dokumentum: megllaptjuk, hogy sikerlt-e, vagy nem leszlltani a projektet.

- Projekt iroda: Ennek a szervezetnek a feladata a vllalati projekt-szabvnyoknak a
kidolgozsa. Projekt folyamatok kezelse, modellezse, projekt-irnytsi eszkzk
kidolgozsa stb.

Jogi formulk:
- Jtlls (garancia): A garancit adott idre nyjtja a termk, vagy a szolgltats ellltja.
Az adott idn bell vllal garancit. s, ha garancilis problma van, akkor az ellltnak
kell bizonytania, hogy a felhasznl rosszul hasznlta a termket s ezrt addtak
problmk. Az ellltnak kell orvosolnia a problmt.
- Szavatossg: A termkben nincs rejtett hiba. A szavatossg nem idkorltozott dolog.
Annyit jelent, hogy validlt s verifiklt a rendszernk. A felhasznlnak kell bizonytania,
hogy nem megfelel a szolgltats.
- Felmonds: A felmonds idpontjban rvnyes, nincs visszamenleges hatlya. Brki
felmondhatja a szerzdst. Az adott pillanatban a felek elszmolnak egymssal. Egy id
eltti szezdsbonts.
- Ellls: Vissza kell lltani a szerzds eltti llapotot.
- Elleg: el-finanszrozs. A megrendel fizeti elre. A szerzds nemteljestse esetn az
elleg visszafizetend.
- Foglal: Egy mellk-ktelezettsg. Biztostand a projekt vgrehajtst. A megrendel fizeti
s, ha a projekt, vagy a szerzds a megrendel hibjbl teljesl, akkor a foglalt elveszti.
Ha viszont a vllalkoz hibjbl nem teljesl, akkor a foglal ktszerest kell
visszafizetnie.
- Bnatpnz: az elllshoz kapcsoldik. Annak az ra, hogy elllhasson a szerzdstl a kt
fl. Ha valamelyik fl elll, akkor azt a pnzt fizeti a msiknak.


Szoftverfejlesztsi folyamat

A szoftverfejlesztsi folyamat jellemzi:
- rthetsg: Mennyire pontosan definilt a folyamat, s az mennyire knnyen foghat fel a
definci alapjn.
- Lthatsg: Mennyire lthat kvlrl, hogy a folyamat egyes tevkenysgei mit
eredmnyeznek.
- Tmogatottsg: Mennyire vannak automatikus eszkzk a folyamat egyes
tevkenysgeihez?
- Elfogadhatsg: A projekt egyes szerepli szmra mennyire elfogadhat, hasznlhat a
folyamat, vagy a folyamat tevkenysgei.
- Megbzhatsg
- Stabilits
- Karbantarthatsg
- Sebessg (Abban az rtelemben, hogy az adott tevkenysg alapjn milyen gyorsan lehet
leszlltani a szoftvertermket)

A szoftverfejlesztsi folyamat tovbbfejlesztse:
mrs->elemzs->vltoztats->mrs...
Mrni az aktulis projektet mrjk. Lehet, hogy nem csak folyamatot mrnk, hanem termket is.
Az elemzs fzisban kidertjk a gyengesgeket, (elkpzelhet, hogy folyamatmodellt alkalmazunk,
adaptlunk, vagy testreszabunk). A vltoztats fzisban ezeket a gyengesgeket kszbljk ki.

Egy folyamat megvltoztatshoz a kvetkezk kellenek:
- Azonostani kell valamilyen mdon a msodik lpsben (elemzs), hogy mit akarunk
megvltoztatni a folyamaton bell.
- Tbb vltoztats is kiderl, sorrendbe kell lltani ket.
- El kell dnteni, hogy melyek azok, amelyek nagyobb minsgjavulst biztostanak.
- Bevezetjk a vltoztatsokat.
- Majd jn egy betantsi lps, mert meg kell szokni az j folyamatmodell alapjn trtn
munkt.



A termk minsgre a kvetkez 4 dolog van alapveten hatssal:
- Technolgia.
- Emberek.
- Folyamat.
- A projekt olyan dolgai, mint kltsg s id.

Alapveten befolysolja, hogy e 4 dolog kzl melyik a lnyeges, hogy mekkora mret a projekt.
Kis projekteknl a technolgia s az emberek az alapvetk. Nagy projekteknl a msik kett a
lnyeges. A nagy projekten sok ember dolgozik s az emberek minsge helyett sokkal inkbb
lnyeges az, hogy legyen egy folyamatmodell, amit kvetni lehet. s sokkal lnyegesebb a
projektnek a megszervezse, alapvet a kommunikci.