Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Szoftvertechnológia 2015/2016 – 1. félév.

Hasonló előadás


Az előadások a következő témára: "Szoftvertechnológia 2015/2016 – 1. félév."— Előadás másolata:

1 Szoftvertechnológia 2015/2016 – 1. félév

2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Előadó Dr. Johanyák Zsolt Csaba Tel.: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

3 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Követelményrendszer Dr. Johanyák Zs. Csaba - Szoftvertechnológia

4 Követelményrendszer nappali tagozaton1
Vizsgára bocsátás feltétele: 50 pont megszerzése Megajánlott vizsgajegy 65 ponttól Előadás ZH (végleges kérdéslista a honlapon okt. 1-től) November 26., pótlási lehetőség: december 10. Megszerezhető pontszám: 40 Kötelező minimum: 21 Projektfeladat Első konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Második konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Végső bemutatás: megszerezhető pontszám: 50, kötelező minimum: 25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

5 Követelményrendszer nappali tagozaton2
Egyéb Ha egy csoport minden tagja minden gyakorlaton jelen van, akkor a csoport minden tagja 5 pontot kap az utolsó gyakorlaton. 15 perces kiselőadás tartása. Témaválasztás és jelentkezés a CooSpace-ben Megszerezhető: 5 pont/kiselőadás (angol nyelvű előadás esetén maximálisan 10 pont szerezhető) Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az oktató által a félév során kiadott pontszerző feladat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

6 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Házi feladat nappali tagozaton azoknak, akik gyakorlattal vették fel a tárgyat Első gyakorlaton egy 4-5 fős csoport kialakítása (egy laborgyakorlaton legfeljebb három csoport lehet) A gyakorlatvezető által kiadott szoftverfejlesztési téma egyes részfeladatainak megoldása Értékelés a beadott projektdokumentáció és a bemutató előadás alapján a gyakorlatvezető pontozza a feladatmegoldást (FM) Minden csoporttag nyilatkozik arról, hogy a társak a as skálán milyen teljesítményt nyújtottak (T) Minden hallgató kap egy átlagértékelést a csapattársak értékelése alapján (ÁT) Végleges pontszám=FM*ÁT/100 Pl. ha FM=40 pont, T={80,90,90,100}→ÁT=90 VP=40*90/100=36 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

7 Követelményrendszer levelező tagozaton1
Vizsgára bocsátás feltétele: 50 pont Megajánlott vizsgajegy Elmélet ZH (végleges kérdéslista a honlapon okt. 1-től) November , pótlási lehetőség: nov Megszerezhető pontszám: 40 Kötelező minimum: 21 Házi feladat Megszerezhető pontszám: 50 Kötelező minimum: 25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

8 Követelményrendszer levelező tagozaton2
Egyéb Egy kiválasztott témakör esszé jellegű kidolgozása (irodalomfeldolgozás, nem másolás!) . Jelentkezés a kiírt témákra a CooSpace-ben Megszerezhető: 5 pont/témakör Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az egyéb kategóriában kötelezően megszerzendő pontszám: 4 pont Dr. Johanyák Zs. Csaba - Szoftvertechnológia

9 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használt szoftverek MS Project 2013 Software Ideas Modeler Microsoft Visual Studio 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

10 Kötelező és ajánlott irodalom
Előadásdiák - minden előadást követően frissített változatot töltök fel [ Szabolcsi Judit: Szoftvertechnológia (a honlapomról letölthető) Ajánlott: Mileff Péter: Szoftverfejlesztés seg. [link] Tarczali Tünde: UML diagramok a gyakorlatban [link] A ppt-ben csak néhány fontosabb téma kerül vázlatosan ismertetésre. A ZH-ra való felkészüléshez a fent megadott irodalmak áttanulmányozása szükséges! Dr. Johanyák Zs. Csaba - Szoftvertechnológia

11 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ajánlott irodalom Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Ian Sommerville: Szoftverrendszerek fejlesztése Szentirmai Róbert: Projektirányítás Microsoft Office Project 2007 segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

12 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Témakörök Szoftverfejlesztési projektek menedzselése Szoftver életciklus modellek UML Alap tevékenységek Elvárások elemzése és specifikáció Tervezés Implementálás + tervezési minták Ellenőrzés Objektum orientált szoftverfejlesztési módszerek Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

13 Szoftverfejlesztési projektek menedzselése
Szoftvertechnológia Szoftverfejlesztési projektek menedzselése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

14 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Projekt definíciók Egy időben behatárolt erőfeszítés, egy egyedi termék, szolgáltatás vagy eredmény létrehozása céljából (PMBOK GUIDE magyarul: Projektmenedzsment útmutató, Akadémia Kiadó 2009) Egyedi folyamatrendszer, amely kezdési és befejezési dátumokkal megjelölt, specifikus követelményeknek – beleértve az idő-, költség- és erőforrás korlátokat – megfelelő célkitűzés elérése érdekében vállalt, koordinált és kontrollált tevékenységek csoportja (ISO 8402) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

15 A menedzselés fontossága
A menedzselés szükségessége igen fontos eltérés a professzionális szoftverfejlesztés és az amatőr programozás között A jó menedzsment nem garantálja a projekt sikerét A rossz menedzsment biztos kudarcot eredményez Idő-költség-minőség Idő Erőforrás Minőség A projekt végrehajtása során fontos követelmény az idő- és erőforrásigény (költségigény) csökkentése a legjobb minőség biztosítása mellett. Ezt a három jellemzőt a projekt három dimenziójának is nevezik. Gyakran kompromisszumot kell kötni, mert mindhárom elvárás egyszerre igen ritkán biztosítható. Tipikus problémák Nem készül el határidőre Tervezettnél nagyobb költségek Nem felel meg a követelményeknek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

16 A szoftvermenedzselés sajátosságai
A szoftver nem kézzelfogható termék Gyakori technológiai váltások A nagy projektek gyakran eltérnek a korábbi projektektől A szoftverfejlesztés sajátosságai számos bizonytalansági tényezőt eredményeznek. Mivel nem kézzelfogható, így nehéz követni az előrehaladást – itt fontos szerepe lesz a dokumentációnak és az ún. mérföldköveknek. A szoftverfejlesztés egy viszonylag új (nem több évszázados) technológia, ami komplex rendszerek használatát és együttműködését igényelheti, így könnyebben előfordulhat előre nem látható probléma A projektek sikeres menedzseléséhez tapasztalatokra van szükség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

17 A szoftverprojekt vezetőjének feladatai
Indítványok készítése, célok meghatározása és tervek készítése Csapattagok kiválogatása A projekt költségeinek figyelemmel kísérése A projektmegvalósulás követése és felülvizsgálata Beszámolók készítése és előadása A projekt menedzsere kell biztosítsa, hogy a projekt a megfelelő időterv és költségvetés szerint haladjon. A konkrét feladatok akár projektenként is eltérhetnek, de általánosan a dián szereplő feladatokkal kell számolni. Indítványok és tervek Mi a projekt célja? Hogyan érhető el? Költség és ütemezési becslések (erőforrás igények becslése). A tevékenységek, mérföldkövek azonosítása. Részeredmények biztosítása. Megvalósíthatósági tanulmányt is magába foglalhatja. Tervekről ld. a következő dia. Csapattagok kiválasztása Ideális esetben tapasztalt csapattagok. A nem ideális csapatfelépítés okai lehetnek Költségvetési korlátok – tapasztalt fejlesztő drága Nem érhető el megfelelő tapasztalattal rendelkező szakember megfelelő mennyiségben (más projektek) Új alkalmazottat be kell tanítani, be kell venni a csapatba Ha senkinek nincs tapasztalata az adott típusú rendszer fejlesztésében, biztosan lesznek problémák. Költségek Milyen erőforrások szükségesek a terv megvalósításához? Felügyelet A végrehajtás és költségek nyomon követése és tervhez hasonlítása. Problémák feltárása és menedzselése (szakértő rendelése a megoldáshoz). A felülvizsgálat a leállításhoz is vezethet. Hosszú lefolyású projekteknél változhatnak a megrendelő szervezet céljai, a szoftver feladatai, vagy akár feleslegessé válhat a szoftver. A szoftvert folyamatosan az új célokhoz kell igazítani. Beszámoló Megrendelő és a saját szervezet irányába – hatékony kommunikációs készség szükséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

18 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervek készítése Projektterv és PDD Minőségbiztosítási terv Validációs terv Konfigurációkezelési terv Karbantartási terv Munkaerő-fejlesztési terv Projektterv Bővebben a következő diákon. Egyes cégeknél a projektterv magába foglalja a listában szereplő többi tervtípust is. PDD – projekt definíciós dokumentum. A PDD az ügyfél és a vállalat közti kapcsolat alapja. Ha a megrendelő egy külső fél, akkor általában neki egy rövidebb változat készül, amiben nincsenek benne a titkosnak minősített részek vagy feleslegesnek ítélt részletek. Minőségbiztosítási terv Milyen minőségügyi szabványokat és eljárásokat kell használni a projektben? Validációs terv Milyen erőforrásokkal és milyen ütemterv szerint kell validálni a szoftverrendszert? Konfigurációkezelési terv Milyen eljárásokat és eszközöket kell alkalmazni a konfigurációkezeléshez? (verziókezelő rendszer, CASE eszközök) Karbantartási terv A rendszer karbantartási követelményeinek meghatározása és a kapcsolódó költségek, erőforrásigények tervezése. Munkaerő-fejlesztési terv Hogyan kell bővíteni a csapat ismeretanyagát? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

19 A projekttervezési és vezetési folyamat 1.
Projektcél? Megállapítani a projekt megszorításait Szervezeti keretek, felelősök A projekt paramétereinek egy kezdeti összegzését elkészíteni Definiálni a projekt részeredményeit és mérföldköveit A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Mi a projekt célja? Mik az ügyfél elvárásai? Az ügyfél és a vállalat közti felelősség-megosztás. Használni kívánt hardver és szoftver eszközök. A projekt tervezése és vezetése egy iteratív folyamat (ld. a két diát), ami igazából a projekt befejezésével fejeződik be. Azaz a projektmegvalósulás során folyamatosan bővülhet és módosulhat a terv. Megszorítások: szállítási határidő, csapattagok, költségvetés, stb. Paraméterek: a projekt szerkezete, mérete, funkcióinak eloszlása. Mérföldkövek: ld. 2 diával hátrébb A dokumentálás magába foglalja: A projekt alapnaptárát Az erőforráskészletet Fő tevékenységeket, résztevékenységeket, mérföldköveket Résztevékenységek, tevékenységek, mérföldkövek kapcsolatait Erőforrások tevékenységekhez rendelését Költségek rendelését a tevékenységekhez és az erőforrásokhoz A projekt indító értekezleten a résztvevők megismerik egymást és a PDD-t. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

20 A projekttervezési és vezetési folyamat 2.
Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása A pr. következő szakasza egy ciklus. Mivel a paramétereket általában csak becsülni lehet, ezért minden ciklusban felülvizsgálatra kerülnek és módosulhatnak. A felügyelet (követés) lehetővé teszi A problémák felismerését felbukkanásukkor vagy esetleg egyes esetekben az előrejelzést is. Helyzetelemzések készítését Tökéletesen lefutó projekt nincs, probléma, eltérés a kezdeti céloktól mindig előfordulhat. A projekt lezárása egy elemzés kell legyen, ami lehetővé teszi, hogy a későbbi projektekben elkerüljük az itt vétett hibák megismétlését. Utókalkulációk készítése Projekt záró értekezlet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

21 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A projekt ütemezése A folyamat tevékenységekre bontása Az egyes tevékenységekhez szükséges idő és erőforrások becslése Idő tartalékolása problémák megoldására és előre nem látott feladatokra (pl. Sommerville: +30% probl. +20% fel.) Mely tevékenységek végezhetőek párhuzamosan? Összefüggő sorozatba rendezés Erőforrások (pl. munkatársak) tevékenységekhez rendelése Felelősségi körök meghatározása (felelősségi mátrix) Költségek becslése A munkaerő kihasználtsága optimális legyen Grafikus megjelenítés Erőforrások: ember, lemezterület, hardver, szoftver, egyéb költségek (pl. utazás) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

22 Hierarchikus tevékenység/feladat lebontás 1.
Projekt Fázis Szakasz Tevékenység Feladat Végrehajtás Bonyolultabb szoftver projekteknél nehéz egyből átlátni az egész feladatot, ezért hierarchikus lebontást alkalmaznak. A lebontás történhet végrehajtási sorrend szerint, termék összetevők szerint, funkciók (használat) szerint, munkacsoportok szerint, stb. A cél az, hogy azonosítsuk azokat az elemi tevékenységeket, amelyeket már jól át tudunk látni, tudunk hozzá végrehajtási időt, erőforrást rendelni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

23 Hierarchikus tevékenység/feladat lebontás 2.
Film Forgatókönyv Szereposztás Helyszín Rendező Zene Író Stílus Téma Casting Külső Belső Stáb Szerzés Sci-fi Horror stb. Színészek Díszlet Operatőr Háttér munkások Gyártás v. Illesztés Vágás v. Képi világ Utómunka v. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

24 Mérföldkövek és részeredmények
A mérföldkő a szoftverfolyamat tevékenységeinek egy ellenőrző pontja, egy logikai szakasz vége. Egy vagy több olyan részfeladat után helyezzük el, ahol a részfeladatok eredményes befejezése nélkül nem lehet továbbhaladni. A részeredmények a projekt olyan eredményei, amelyek átadhatók a megrendelőnek. Ezek általában mérföldkövek is, de a mérföldkő nem szükségszerűen részeredmény. A mérföldköveket úgy kell meghatározni, hogy validálható legyen a teljesítésük. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

25 Tevékenységek és mérföldkövek
Megvalósíthatósági vizsgálat Követelmény elemzés Prototípus fejlesztés Terv-tanulmány Követelmények meghatározása Megvalósíthatósági jelentés Prototípus fejlesztés Terv-tanulmány Követelmények meghatározása Forrás: Ian Sommerville: Szoftverrendsszerek fejlesztése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

26 Könyvesboltban történő vásárlás menete
Tevékenység neve Időtartam Kezdés Befejezés Megelőzés (1) Vásárlás 2 óra K (2) Vevő szempontjából 40 perc (3) Katalógus megtekintés 5 perc (4) Könyv kiválasztása 1 óra 3 (5) Könyv megtekintése 10 perc 4 (6) Könyvből való következtetés levonása 5 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

27 Könyvesboltban történő vásárlás menete
Tevékenység neve Időtartam Kezdés Befejezés Megelőzés (7) Alkalmazott szempontjából 20 perc K (8) Alkalmazott hitelesítés 1 perc (9) Hitelesítés létrejövetele 0 perc 8 (10) Kiválasztott könyv rögzítése 5 perc 4, 8 (11) Vevő adatainak bevitele (ha számlát kér) (12) Könyv kifizetése 2 perc Dr. Johanyák Zs. Csaba - Szoftvertechnológia

28 Tevékenység – Időtartam – Függőségek táblázat
Időtartam napban Függőségek T1 8 T2 15 T3 T1;M1 T4 10 T5 T2;T4;M2 T6 5 T1;T2;M3 T7 20 T8 25 T4;M5 T9 T3;T6;M4 T10 T5;T7;M7 T11 7 T9;M6 T12 T11;M8 T – tevékenység M – mérföldkő Az A-B tevékenységek között négyféle kapcsolat lehetséges (B az ún. függő tevékenység): B csak akkor kezdődhet el, ha A befejeződött B csak akkor kezdődhet el, ha A is elkezdődött B csak akkor fejeződhet be, ha A már befejeződött B csak akkor kezdődhet el, ha A már elkezdődött A függőségi kapcsolat lehet Kemény (kötelező) Lágy (ajánlás) Az egyes tevékenységekre időbeli korlátok is vonatkozhatnak: Befejezés nem később, mint … Befejezés nem korábban, mint … Kezdés nem később, mint … Kezdés nem korábban, mint … Befejezés pontosan …-án. Kezdés pontosan …-án. A projektütemezés annál rugalmasabb, minél kevesebb a korlát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

29 Tevékenység – Időtartam – Függőségek táblázat – MS Project 2013
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

30 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tevékenységháló T9 15 nap M4 03/8/4 M1 03/7/14 M6 03/8/25 T3 15 nap T1 8 nap T11 7 nap M3 03/7/25 T6 5 nap Kezdet 03/7/4 T2 15 nap T7 20 nap M8 03/9/5 M2 03/7/25 M7 03/8/11 T4 10 nap T5 10 nap T10 15 nap T12 10 nap A hálóterv elkészítéséhez számos módszer áll rendelkezésre: ADM, CRM, GERT, PDM, PERT. Téglalap: tevékenység Lekerekített sarkú téglalap: mérföldkő és részeredmény Egy tevékenység akkor indulhat, ha az őt megelőző mérföldkő teljesült. Kritikus út: a projekt teljes időtartamát meghatározó útvonal (vastag vonal). A tevékenységháló segít áttekinteni, hogy melyek a párhuzamosan végrehajtható tevékenység sorozatok. Törekedni kell a tevékenységek oly módon történő felülvizsgálatára esetleg átszervezésére, hogy a kritikus út hossza csökkenjen. Minden útvonalhoz célszerű meghatározni a teljes tartalék időt. M5 03/7/18 Vég 03/9/19 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése T8 25 nap Dr. Johanyák Zs. Csaba - Szoftvertechnológia

31 Tevékenység háló – MS Project 2013
A lecsapott sarkú: mérföldkő. Részletes nézetben minden tevékenységhez egy táblázat kapcsolódik, amiben megjelennek a tevékenységhez kapcsolódó fontosabb adatok. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

32 Tevékenység (Gantt) diagram
Kezdet 7/4 7/11 7/18 7/25 8/1 8/8 8/15 8/22 8/29 9/5 9/12 9/19 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 Sáv diagram – Henry L. Gantt Első sor: időpontok hónap/nap formátumban Rombusz: mérföldkő Fehér kitöltésű téglalap: tevékenység tervezett időtartammal. Szürke kitöltésű téglalap: egy mérföldkőhöz vagy tevékenységhez kapcsolódik, és azt jelöli, hogy az adott m/t mennyit csúszhat időben anélkül, hogy kockáztatná a projekt tervezett időre történő befejezését. A sáv diagram jobban mutatja a projekt időbeli lefolyását. Minden időszakra jól láthatjuk, hogy melyek az elvégzendő feladatok. A tevékenységháló és a tevékenység diagram alapján lehet megtervezni a munkaelosztást a csapattagok között. A TD a projekt naptára. A projekt lefolyása során a TH-t és TD-t folyamatosan frissíteni kell, követni, hogy a megvalósítás hogyan halad az eredeti tervhez képest. Időnként a projekt újraszervezése is szükségessé válhat. T10 M6 T11 M8 T12 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Befejezés

33 Gantt diagram – MS Project 2013
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

34 Szervezet lebontási struktúra
Rektor GAMFK Informatika tanszék Járműtechnológia tanszék TFK KFK Nagyobb projektnél szükséges lehet a szervezet lebontási struktúra, ha külön csoportokat hozunk létre. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

35 Felelősségi mátrix OBS WBS Tervezés Előállítás Oktatás és dokumentálás Fejlesztő főosztály Műszaki támogatás Logikai Fizikai Kódolás Tesztelés Oktatás Felhasználói kézikönyv Tervező osztály Programozási osztáy Tesztelő osztály A felelősségi mátrixot megadhatjuk csoportok szintjén (ha vannak munkacsoportok) vagy egyének szintjén. Oktatási osztály Dokumentációs osztály Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

36 Erőforrások ütemezése
Gépek, berendezések, alap- és segédanyagok, tartozékok és egyéb költségforrások A projekt szempontjából lényeges erőforrás Korlátozott mennyiségben áll rendelkezésre Mérhető a költsége Erőforrás típusok Anyag Költség (összeg) Munka (alap óradíj, túlóra díj) – ide tartoznak általában a dolgozók is Eddig van egy ideális tevékenység-időigény alapú ütemezésünk. Ezt finomítjuk az erőforrások rendelkezésre állásának és egyéb szempontoknak a figyelembe vételével. Egy erőforrást nem kell felvenni a projektbe, ha korlátlan mennyiségben rendelkezésre áll. Az erőforrások figyelembe vétele történhet egy vagy két lépésben. A kétlépéses változatnál Logikai erőforrásokat határozunk meg: pl. projektvezető, rendszerelemző, IT architekt, C# programozó, stb. Fizikai erőforrás rendelése a logikaihoz: pl. konkrét személyek Több erőforrás igénybe vétele általában rövidebb lefutást eredményez és fordítva. Ha nincs idő/pénz kényszer, akkor hatékonyabb a kevesebb erőforrás - pl. dolgozó, mert kevesebb az adminisztráció, kevesebb kommunikációs idő szükséges, DE hosszabb ideig tart a projekt, ami eltompulás, elunás veszélyével jár. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

37 Munkatársak lekötöttségi diagramja – MS Project 2013
Csapattervező diagram. Az LD ábrázolja a munkatársak feladatokhoz rendelését. Elkészítésekor figyelembe kell venni a más projektekben történő részvételt, továbbképzést, szabadságot, egyéb tevékenységeket (pl. értekezletek). Mivel egyes szakaszok csúszhatnak, ezért érdemes periodikusan szabad (tartalék) időszakot betervezni különösen több projektben foglalkoztatott dolgozóknál. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

38 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Túlterhelés Megoldási lehetőségek Elcsúsztatás tartalékidő felhasználással Több erőforrás bevonásának megkísérlése Munkaóra növelés (túlóra) Zárási határidő elcsúsztatásának megkísérlése A szűk keresztmetszeteknél túlterhelés léphet fel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

39 Költségvetés készítése
Alap órabér számítási megközelítési módok Minden érintett munkatársnál visszaszámoljuk az órabért --> nem megoldható Projektszerep és végzettség szerint átlagos órabért határozunk meg  problémás Egységes átalánnyal számolunk Az órabérhez hozzáadunk átalányköltséget (pl. áram, szoftverbérlet, irodaszer) A teljes projektköltséghez hozzáadunk konkrét költségtételeket (pl. utazás) A költség döntő többségét a munkabér szokta adni, ezért ez a számítás alapja. A vállalati politika dönti el, hogy egy konkrét költségtípus mely kategóriába kerül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

40 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázatkezelés Def.: A kockázatok azonosítását és az azok hatásának minimalizálása érdekében történő tervek felvázolását együtt kockázatkezelésnek nevezzük. A kockázatkezelés célja az, hogy megkönnyítsük az esetlegesen felmerülő problémák kezelését, és elkerüljük a költségek jelentős emelkedését és a határidők nem teljesítését. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

41 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázati kategóriák Projekt: a projekt ütemtervére vagy az ott használt erőforrásokra ható kockázat Termék: a fejlesztett szoftver minőségére vagy teljesítményére ható kockázat Üzleti: a szervezetre ható kockázat Ez csak általános osztályozás. A konkrét típusok projektenként és szervezetenként változhatnak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

42 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Konkrét példák Tapasztalt programozó elhagyja a projektet – projekt Hardver elérhetetlensége – projekt CASE-eszköz alulteljesítése – termék A fejlesztendő szoftver méretének alulbecslése – termék Technológia megváltozása – üzleti Versenyképes termék kerül piacra, mielőtt a rendszer elkészülne - üzleti Dr. Johanyák Zs. Csaba - Szoftvertechnológia

43 A kockázatkezelés folyamata
Kockázat azonosítása Kockázat elemzése (valószínűség és következmények) Kockázat tervezése (hogyan kerülhetjük el) Kockázat figyelése  2 A kockázatkezelés iteratív folyamat, ami jelen van a projekt teljes időtartamában. Mi keletkezik az egyes szakaszokban? 1: kockázati lista 2: sorbarendezett k. lista 3: kockázat elkerülési/vészhelyzeti terv 4: folyamatos becslések, ahogy több/új információ áll rendelkezésre Dr. Johanyák Zs. Csaba - Szoftvertechnológia

44 1. A kockázat azonosítása Kockázattípusok
Technológiai - A rendszerhez használt adatbázis nem tud mp-ként annyi tranzakciót feldolgozni, mint amit elvárunk tőle. Emberi - A kulcsfontosságú munkaerő megbetegszik. Szervezeti - A projekt vezetősége megváltozik. Eszköz - A különböző típusú CASE-eszközöket nem lehet integrálni. Követelmény - A megrendelők nem képesek megérteni, hogy az általuk kívánt szolgáltatások miért lennének olyan drágák. Becslési - A szoftver kifejlesztéséhez szükséges időt alábecsülték. A kockázat azonosítása fázisban csapatmunkaként vagy egyszerűen a menedzser tapasztalatait hasznosítva egy listát állítunk össze a lehetséges kockázatokról. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

45 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázati tényezők Kockázattípus Potenciális jelzés Technológiai A hardver vagy a támogató szoftver kései leszállítása, számos jelzett technológiai probléma. Emberi Szegényes munkamorál, rossz kapcsolatok a csapatok között. Szervezeti Munkahelyi pletykák, a felső vezetés tevékenységének hiánya. Eszköz A csapatok eszközökkel szembeni idegenkedése, a CASE eszközök körüli panaszok, nagyobb teljesítményű munkaállomások iránti igény. Követelmény Igény számos követelmény megváltoztatására, panaszok a megrendelő felől. Becslési Az elfogadott ütemtervet nem sikerül betartani, nem lehet tisztázni a jelentett hibákat. Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

46 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Halszálka diagram Ishikawa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

47 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

48 Vizuális programozás projektfeladat sikertelensége
#1 Személyi #4 Módszer ----> Lustaság Részfeladatokra bontás Nem megfelelő végzettség Nem megfelelő kommunikáció Együttműködő képesség hiánya Objektumorientáltsági problémák #2 Eszközök #5 Környezet Számítástechnikai eszközök hiánya Távolság Fejlesztőkörnyezet hiánya Túlterheltség Jegyzetek hiánya Internet hiánya #3 Ismeretek Hiányos programozói ismeretek Hiányos nyelvi ismeretek Hiányos matematikai ismeretek Dr. Johanyák Zs. Csaba - Szoftvertechnológia Enter specific causes associated with respective major causes below. Be precise and include data whenever possible. Click "finished" to continue.

49 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Halszálka diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

50 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
2. A kockázat elemzése Valószínűség: 1 - nagyon kicsi (<10%), 2 - kicsi (10-25%), 3 - mérsékelt (25-50%), 4 - magas (50-75%) vagy 5 - nagyon magas (>75%); A kockázat hatása: 1 - nem jelentős, 2 - elviselhető, 3 - közepes, 4 - súlyos, 5 - katasztrofális Minden kockázatot értékelni kell valószínűség és komolyság szerint. Az elemzési folyamat eredményeit súlyosságuk szerint táblázatba rendezzük és ebből a táblázatból kiválasztjuk azt a néhány tételt, amit a projekt során végig figyelemmel kell kísérni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

51 Kockázatelemzési táblázat
Valószínűség (1-5) Hatás (1-5) V*H Lustaság 5 25 Nem megfelelő végzettség 3 15 Együttműködő képesség hiánya Távolság 4 12 Túlterheltség 2 10 Részfeladatokra bontás 9 Hiányos nyelvi ismeretek 8 Nem megfelelő kommunikáció 1 Hiányos matematikai ismeretek Objektumorientáltsági problémák Internet hiánya Fejlesztőkörnyezet hiánya Jegyzetek hiánya Számítástechnikai eszközök hiánya Hiányos programozói ismeretek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

52 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Pareto Az elemzés szakaszban gyakran alkalmaznak Pareto elemzést. Cél a lényeges/kritikus kis hányad (20%, 1/3) beazonosítása, ha sok a kozkázat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

53 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

54 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

55 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

56 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
SWOT elemzés Belső tényezők Strengths erősségek Weaknesses gyengeségek Külső tényezők Opportunities lehetőségek Threats veszélyek A kockázat elemzés része lehet a SWOT elemzés is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

57 SWOT elemzés (vállalati példa)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

58 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Erősségek Meghatározó a vállalat piaci szerepe? Jó a vásárlók véleménye? Fejlett technológiát használ a vállalat? Egyedülálló versenyelőnnyel rendelkezik? Jók a piaci erőforrásai? Gazdaságos üzemméretet használ? Jó a vállalat menedzsmentje? Kimagasló szakértelműek az alkalmazottak? Sikeres a vállalati stratégia? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

59 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Gyengeségek Elavult a technológia? Romlik a piaci pozíció? Nincs egyértelműen meghatározott stratégia? Hiányzik a megfelelő szakértelem? Elhasználódtak a létesítmények? Rossz a vállalat imázsa? Nem sikeres a kutatás-fejlesztési részleg? Rosszul funkcionál a menedzsment? A pénzügyi háttér nem rendezett? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

60 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Lehetőségek Gyorsabb piaci növekedés? Kiegészítő termékek fejlesztése? Új piacokra való belépés? Új technológia alkalmazása? A termékcsoport továbbfejlesztése? További célcsoportok feltérképezése? Egy nyersanyagforrás megszerzése? Beszállítás helyett saját előállítás? Új szervezeti felépítés kidolgozása? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

61 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Veszélyek Új versenytársak megjelenése a piacon. A piaci növekedés lassulása. Változó fogyasztói igények. Szigorodó szabályozás. Helyettesítő termékek megjelenése. Hátrányos demográfiai változások. Kedvezőtlen gazdasági ciklusok hatása. A beszállítók javuló alkupozíciója. Fogyasztói érdekvédelem fokozódó nyomása. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

62 Kockázat tervezése és menedzselése
Stratégiák Elkerülési stratégiák Minimalizációs stratégiák Vészhelyzeti tervek A kockázat tervezése fázisban az előző fázisban kiválasztott néhány kulcskockázat kezelési stratégiáját határozzuk meg. Elkerülési stratégiák Cél: csökkenteni a bekövetkezés valószínűségét. Minimalizációs stratégiák Cél: a hatás csökkentése. Vészhelyzeti tervek Mit kell tenni, ha már bekövetkezett a kockázat által jelölt probléma. Alkalmazható módszerek Brainstorming Kártyatechnikák Dr. Johanyák Zs. Csaba - Szoftvertechnológia

63 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázat tervezése Kockázat Stratégia Szervezeti pénzügyi problémák Elkészíteni egy részletes dokumentumot a felső vezetés részére, amely bemutatja, hogy a projekt mennyire fontos kapcsolatban áll az üzleti célokkal Toborzási problémák Riasztani a megrendelőt, hogy potenciális nehézségek és lehetséges késések várhatók, kutatni a megvásárolható komponensek után. Munkaerő megbetegedése Újraszervezni a csapatot úgy, hogy a munkák jobban átfedjék egymást, így az emberek jobban megértik mások munkáit is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

64 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A kockázat figyelése Változott-e az azonosított kockázatok bekövetkezési valószínűsége hatása Minden vezetőségi felülvizsgálaton minden kulcskockázatot meg kell vizsgálni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

65 Az 1. előadás tartalmából
Ismétlés Az 1. előadás tartalmából Projekt A vezető feladatai A projekttervezési és vezetési folyamat Hierarchikus tevékenység/feladat lebontás Mérföldkövek és részeredmények Tevékenység – Időtartam – Függőségek - Erőforrások Ütemezés Kockázatkezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

66 A projekttervezési és vezetési folyamat 1.
Ismétlés A projekttervezési és vezetési folyamat 1. Projektcél? A projekt megszorításai Szervezeti keretek, felelősök A projekt paramétereinek kezdeti összegzése A projekt részeredményeinek és mérföldköveinek definiálása A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

67 A projekttervezési és vezetési folyamat 2.
Ismétlés A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel, elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Az első pontban megjelenő ciklus az ún. projekt követési folyamat. Itt három fő tevékenység jelenik meg. Ezek az Információgyűjtés Elemzés Cselekvés A továbbiakban az első két tevékenység néhány fontosabb lépését/elemét fogjuk áttekinteni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

68 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Információgyűjtés Kitöltött űrlapok jelentések, jegyzőkönyvek, programok kimenetei, értekezleteken elhangzott információk Óraelszámolások Állapotjelentések Óraelszámolások Az élőmunka-ráfordítás költségszámításának alapját képezik. Vállalati szabályozástól függ lebontása: havi, heti, napi. Nagyobb pontosság=jobb kép a költségekről, DE nagyobb adminisztrációs teher a dolgozónak. Állapotjelentés A projektvezető tájékoztatja a projektet felügyelő vezető(ke)t az előrehaladásról. Ajánlott a heti gyakoriság. Tartalmaz összesítéseket, vizualizációs eszközöket (főként diagramok). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

69 Elemzés - alapfogalmak
ACWP – Actual Cost Of Work Performed – az elvégzett munka tényleges költsége BCWP – Budget Cost Of Work Performed – az elvégzett munkára ennyi költséget terveztünk BCWS – Budget Cost Of Work Scheduled – a tervezett (ütemezett) munkára ennyi költséget terveztünk Az ideális eset az lenne, ha egyetlen számmal teljes körűen jellemezhető lenne a projekt állapota. A valóságban több mérőszám is számítható, amik különböző jellemzőket mutatnak. Igaz ezekből előállítható kombinált értékelési mutató, de az elfedi azt, hogy hol a gond és néha magát a probléma meglétét is. A továbbiakban az "Megtermelt érték számítási módszere"nevű megközelítést mutatjuk be. Eszerint a projekt egy adott időpillanatában az itt (ezen a dián) megnevezett három költségtípust számítjuk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

70 Elemzés – származtatott fogalmak
CV – Cost Variance – költségeltérés CV=BCWP-ACWP SV – Schedule Variance – ütemezéstől való eltérés SV=BCWP-BCWS CPI – Cost Performance Index – költséghatékonysági mutató CPI=BCWP/ACWP SPI – Schedule Performance Index – ütemterv teljesülési mutató SPI=BCWP/BCWS CR – Critical Ratio – kritikus arány CR=SPI*CPI A három alapfogalomból (költségtípusból) kétfajta eltérési mennyiséget és kétfajta mutatót állíthatunk elő. A CPI az elvégzett munka (Work Performed) tervezett (Budget Cost) és tényleges (Actual Cost) költségének arányát mutatja. Ha értéke kisebb mint 1, akkor a tervezettnél nagyobb költséggel hajtotta végre eddig a csapat a feladatokat. Az SPI a tervben szereplő költségeket (Budget Cost) használva értékelő számként a ténylegesen elvégzett munkamennyiséget (Work Performed) a tervezetthez (ütemezetthez) (Work Scheduled) hasonlítja. Ha értéke kisebb mint 1, akkor a tervezettnél kevesebb munkát végzett eddig el a csapat. Ezt a mutatót a tervezett és a valójában megtermelt érték arányának is nevezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

71 Diagram Költség Most BCWS ACWP CV SV BCWP Idő
Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

72 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Felügyelet Beavatkozási határokat meghatározni Pl. 0,9…1,1 - OK 0,8…0,9 vagy 1,1…1,2 - tendenciafigyelés 0,8 alatt vagy 1,2 felett - cselekvés Az SPI és CPI értékét folyamatosan figyelni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

73 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Minta BCWS BCWP ACWP CV SV CPI SPI Értelmezés 100 1 Időben és költségen 125 25 1,25 Időelőny és költségen -25 0,8 Késés és költségen Időben és túlköltekezés 150 0,83 Időelőny és túlköltés Késés és túlköltés Időben és megtakarítás Időelőny és megtakarítás Késés és megtakarítás Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

74 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Projekt lezárása A projekt akkor fejeződik be, ha teljesül a projektcél (elfogadták a projekt eredményét) Projektzáró dokumentum Projektadatok (…, tervezett és tényleges befejezési idő, bevétel, tervezett és tényleges költségek, emberóra ráfordítás) Lezárást követő teendők Vevői elégedettség Projekt általános értékelése Projektzáró értekezlet – értékelik a projekt lefutását A termék átadását követő garanciális időszak, karbantartás, követés, ügyfélszolgálati tevékenység már nem része a projektnek. A projektzáró dokumentum segít abban, hogy a későbbi projektjeinket jobban tervezhessük. A projekt értékelés hosszú távon is hat a cégre, a vállalati kultúrára. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

75 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A projekt utóélete Szoftverrendszerrel kapcsolatos költségek 1/3-a fejlesztés és 2/3-a működtetés Projektzárást követő tevékenységek Üzemeltetés Garanciális javítások Későbbi karbantartás Támogatás (tanácsadás) Követés (változó jogi, hardver és szoftver környezet) Továbbfejlesztés A projektzárást követő tevékenységek nem projekt jellegűek, hanem folyamatosak. Egy munkafolyamat leírás vezérli őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

76 Bejelentések fogadása
Service Level Agreement (SLA) rögzíti Bejelentések súlyosság és prioritás szerinti kategorizálása Vállalt reakcióidők Informatikai infrastrukturális szolgáltatások módszertana (ITILv3) - Information Technology Infrastructure Library (ISO/IEC ) Informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény Dr. Johanyák Zs. Csaba - Szoftvertechnológia

77 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Bejelentéskezelés Fontos a bejelentések és kezelésük pontos dokumentálása és a folyamat követése. Ezt a munkafolyamatot egy állapotgép diagrammal vagy állapotátmenet mátrixxal lehet leírni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

78 Szoftver életciklus modellek
Szoftvertechnológia Szoftver életciklus modellek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

79 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Mi a szoftver? A számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége Két fő csoport Általános termékek és Rendelésre készített Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftver a számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége. A szoftvertermékeknek két fő csoportja van: általános termékek és rendelésre készített (egyedi igényeknek megfelelő) termékek. Az általános termékeket nevezik dobozos szoftvereknek is. Ezeket egy fejlesztő szervezet készíti és adja el a piacon bármely vevőnek. Itt a vevők közvetlenül nem befolyásolhatják a termék jellemzőit, a szoftverspecifikációt a gyártó cég tartja kézben. Ilyenek a játékok, az operációs rendszerek, az adatbázis-kezelők, a szövegszerkesztők, a különböző rajz- és tervezőprogramok, fordítóprogramok és a projektmenedzselési eszközök. A rendelésre készített termékek esetében a megrendelő igényei szerint kell a terméket kifejleszteni. Itt a megrendelő adja meg a specifikációt (vagy legalábbis annak a vázlatát) és az elkészült szoftverterméket ez alapján ellenőrzi. Ilyenek lehetnek: könyvelőprogramok, egyéni üzleti folyamatokat támogató rendszerek, forgalomirányító (pl. légi, vasúti), elektromos eszközök vezérlőrendszerei vagy ellenőrző rendszerek. A kétfajta termékcsoport közötti választóvonal egyre inkább elmosódik, mivel egyre több szoftvercég fejleszt általános termékeket, amiket azután a vásárlók igénye szerint testre szab. A vállalatirányítási rendszerek (ERP – Enterprise Resource Planning), mint pl. az SAP jó példa erre. Ezeket tekinthetjük egy harmadik csoportnak is, amely részben az általános termékek, részben a rendelésre készítettek tulajdonságaival rendelkezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

80 Igény a rendszerezett munkára
Kezdetben kis programok Hardverfejlődés → bonyolultabb feladatok Folyamatábra, metanyelvű algoritmus leírás, stb. Szoftvertechnológia Az első számítógép programok viszonylag egyszerűek és a hardverkorlátokból adódóan kis méretűek voltak, így gyakran egyetlen programozó is át tudta látni a feladatot, és meg tudta írni a programot. Mindenki tudna mondani programozási tanulmányaiból/gyakorlatából olyan egyszerű feladatot, amit bárki, aki megfelelő programozási ismeretekkel rendelkezik, különösebb előzetes tervezés vagy „vázlat készítés” nélkül azonnali kódolással meg tudna oldani. Például ilyen két szám átlagának a kiszámítása. A hardver robbanásszerű fejlődésével egyre nagyobb lélegzetű, komplexebb problémák váltak a számítógép által megoldhatóvá. A bonyolultabb feladatok előkészítést, rendszerzett munkát kívántak meg. Egyszerűbb esetekben elegendő volt egy folyamatábra vagy más ezzel egyenértékű eljárás segítségével felvázolni a megoldás algoritmusát, majd ezt követhette a kódolás valamilyen programozási nyelven. A mai valós feladatok azonban a legtöbb esetben olyan nagy méretűek, hogy programozó csoportok dolgoznak a megoldásukon, és az eredmény nem ritkán egy sok százezer utasításból álló szoftver monstrum. Egy ilyen termék előállítása, karbantartása és a folyamatosan változó környezeti feltételekhez, vevői elvárásokhoz igazítása elképzelhetetlen precíz és jól előkészített, szervezett, összehangolt, ellenőrzött és dokumentált munka nélkül. Az erre a célra alkalmazott módszerek és eljárások összességét szoftvertechnológiának nevezzük. A szoftvertechnológia fontos célja a költséghatékony fejlesztés. Nézzünk meg két definíciót erre a fogalomra. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

81 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Boehm A szoftvertechnológia tudományos ismeretek gyakorlati alkalmazása számítógépes programok előállításához, a fejlesztéshez, a használathoz és karbantartáshoz szükséges dokumentációk tervezésében és előállításában. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

82 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
IEEE A szoftvertechnológia olyan technológiai és vezetési alapelvek összessége, amelyek lehetővé teszik a programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

83 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftverfolyamat Bár a szoftver sokban különbözik más hagyományos, kézzel fogható terméktől, és az elmúlt években sokféle modell és ajánlás született arra, hogy hogyan is állítsuk elő, azonban szinte minden ilyen modellben visszaköszönnek olyan lépések és tevékenységek, amelyekkel más területek és iparágak mérnöki tervezési és előállítási folyamataiban is találkozhatunk. Ezek a következőek. 1. Követelményelemzés A vevői /megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?), a rendszer környezetének felmérése, feladat leírása. Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása. Ezt követi a feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. 2. Tervezés Az elemzés és a tervezés szorosan összekapcsolódó feladatok. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. 3. Implementálás (megvalósítás) A technológiai részletek kidolgozása, a tényleges kód előállítása. Ide tartozik a komponens tervezés, adatszerkezet tervezés és algoritmus tervezés. Felhasználói interakció megtervezése, felülettervek. Ide tartozik még az integrálás (modulok összekapcsolása). Dokumentáció: objektum diagramok, rendszer montázsdiagramok. 4. Kipróbálás, validálás, bevezetés Tesztelés és telepítés. Kipróbálás valós környezetben. Két módszer: szoftverátvizsgálás és tesztelés. Ide tartozik még a felhasználói dokumentáció elkészítése. Kihelyezési diagram. 5. Működtetés, karbantartás, továbbfejlesztés, leállítás A felismert hibák javítása, esetleg új igényeket kielégítő új funkciók megvalósítása – folyamatos fejlesztés (igény esetén). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

84 Szoftverfolyamat modellek
Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V RUP (Rational Unified Process) ISO/IEC (1995, 2008) A rendszerezett/módszeres szoftverfejlesztés iránti igény olyan technikák (modellek) megjelenését eredményezte, amelyek eligazítást adnak, meghatározzák, hogy milyen lépéssorozattal (hogyan) célszerű előállítani úgy a szoftvert, hogy az lehetőleg minden érintett fél elégedettségét eredményezze. Hasonlóan más technológiákhoz itt is megfigyelhető a fejlődés, továbbá itt sem mondhatjuk el egyetlen megközelítésről sem, hogy ő az egyedüli üdvözítő megoldás. Az előnyöket és hátrányokat mérlegelve a lehetőségek/körülmények ismeretében választhatjuk egyiket vagy másikat optimális megoldásként. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

85 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Vízesés modell A vízesés modellt széles körben használták a gyakorlatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra forrása: Ficsor Lajos:

86 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Vízesés modell A következő fázis addig nem indulhat el, amíg az előző be nem fejeződött. Ez a modell akkor működik jól, ha a követelmények teljesen ismertek. Előny: Jól menedzselhető és ellenőrizhető. Minden fázisban jól definiált feladatok. Minden fázis jól dokumentálható. Előre jól definiálható követelmények esetén jól alkalmazható. Hátrány: Nagyon sok probléma csak az utolsó fázisban derül ki, így a javítás nagyon költséges. Korán kell jelentős döntéseket hozni, ez hibás döntésekhez vezethet. Nehéz a rendszert a fejlesztés közben változó követelményekhez igazítani. Sok dokumentációs munkát igényel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

87 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál modell megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftverfolyamatot spirálként kezeli. Minden egyes körben a spirál a szoftverfolyamat egy-egy fázisát reprezentálja. A legbelső kör a megvalósíthatósággal foglalkozik, a következő a rendszer követelményeinek meghatározásával, aztán a rendszer tervezéssel, stb. A spirál minden egyes ciklusát négy szektorra osztjuk fel: célok, alternatívák meghatározása; kockázat becslése és csökkentése; a fázis termékének megvalósítása és validálása; következő fázis tervezése. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

88 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál Modell Elemzés Prototípus 3 Igények és Célok Prototípus 2 Prototípus 1 Megvalósítás Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

89 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál modell Előny: a kockázati tényezőkkel explicite számol. A spirális modellben nincsenek rögzített fázisok, és felölelhet más folyamatmodelleket is (vízesés, evolúciós, stb.). Hátrányai: a modell alkalmazása bonyolult, munkaigényes feladat; a párhuzamos foglalkoztatás csak a 3. szektorban lehetséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

90 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
V modell Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

91 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
V modell Egy módosított vízesés modell. Megkülönbözteti a fejlesztésen belül a konstrukciós és a tesztelési fázisokat. Definiálja a tesztelés szintjeit. Szemlélteti, hogy a tesztelési munka végigköveti a teljes fejlesztési folyamatot. Összefüggést tételez fel az egyes konstrukciós fázisok és az egyes tesztelési szintek között. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

92 Inkrementális (evolúciós)
Analízis Specifiká-ció Tervezés Specifiká-ció Implemen-táció Tervezés Specifiká-ció Tesztelés Implemen-táció Tervezés Tesztelés Implemen-táció Tesztelés Implemen-táció Ábra forrása: Ficsor Lajos:

93 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Evolúciós modell Ki kell fejleszteni egy kezdeti implementációt (prototípust), azt a felhasználókkal véleményeztetni, majd sok-sok verzión át addig finomítani, amíg megfelelő nem lesz. Iterációs modellnek is nevezik. Objektum orientált fejlesztésben gyakran használják. Ez a modell a felhasználó kívánságait jobban kielégítő programot eredményez. A kis (< programsor) és közepes (<= programsor) rendszerek fejlesztéséhez ideális. Hátrányai: a folyamat nem látható; a rendszerek gyakran szegényesen strukturáltak; a gyors fejlesztés rendszerint a dokumentáltság rovására megy. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

94 Újrafelhasználás orientált fejlesztés (komponens alapú)
Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Fejlesztés és integráció Forrás: Szabolcsi Judit: Szoftvertechnológia Ez a módszer nagymértékben az elérhető újrafelhasználható szoftverkomponensekre támaszkodik. A komponensek lehetnek teljes rendszerek, pl. egy szövegszerkesztő, vagy kisebb egységek (osztályok, modulok, stb.) A fejlesztés szakaszai: Komponenselemzés: Adott a követelményspecifikáció, ami alapján megkeressük, hogy milyen kész komponensek valósítják meg. A legtöbb esetben nincs egzakt illeszkedés, és a kiválasztott komponens a funkcióknak csak egy részét nyújtja. Követelménymódosítás: A követelmények elemzése a megtalált komponensek alapján. A követelményeket módosítani kell az elérhető komponenseknek megfelelően. Ahol ez lehetetlen, ott újra a komponenselemzési tevékenységet kell elővenni, és más megoldást keresni. Rendszertervezés újrafelhasználással: A rendszer szerkezetét kell megtervezni, vagy egy már meglévő vázat felhasználni. A tervezőknek figyelembe kell venniük, hogy milyen újrafelhasznált komponensek lesznek, és úgy kell megtervezni a szerkezetet, hogy ezek működhessenek. Ha nincs megfelelő újrafelhasználható komponens, akkor új szoftverrészek is kifejleszthetők. Fejlesztés és integráció: A nem megvásárolható komponenseket ki kell fejleszteni és a COTS (Commercial-Off-The-Shelf – kereskedelemben kapható)-rendszerekkel össze kell kapcsolni. A rendszerintegráció itt sokkal inkább tekinthető a fejlesztési folyamat részének, mint különálló tevékenységnek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

95 Komponens alapú modell
Előnye: lecsökkenti a kifejlesztendő részek számát, így csökkenti a költségeket és a kockázatot. Ez általában a kész rendszer gyorsabb leszállításához vezet. Hátrányai: a követelményeknél hozott kompromisszumok elkerülhetetlenek, és ez olyan rendszerhez vezethet, ami nem felel meg a felhasználó valódi kívánságának. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

96 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP Munkafolyamatok Munka- folyamatok Követelmények Tervezés Implementáció Teszt Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra:

97 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP - dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

98 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
ISO 12207 Forrás: Tarczali Tünde: UML diagramok a gyakorlatban [link] Dr. Johanyák Zs. Csaba - Szoftvertechnológia

99 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
CASE eszközök Computer-Aided Software Engineering Követelményspecifikáció: grafikus rendszermodellek, üzleti és domain Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfész-leírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP);verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Forrás: Szabolcsi Judit: Szoftvertechnológia A számítógéppel támogatott szoftvertervezéshez (Computer-Aided Software Engineering - CASE) használt szoftvereket nevezzük CASE-eszközöknek. A szoftverfolyamatban a következő tevékenységeket támogatják a CASE eszközök: Követelményspecifikáció során: grafikus rendszermodellek, üzleti és domain (a modellezni kívánt terület) modellek megtervezése. Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfészleírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP); verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Mindegyik fázisban alkalmazható: automatikus dokumentumgenerálás; projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) A CASE-eszközök korai pártolói azt jósolták, hogy a szoftverek minőségében és a termelékenységben nagyságrendi javulást okoznak ezek az eszközök, de valójában csak 40% körüli a javulás. Az eredményességet két tényező korlátozza: A szoftvertervezés lényegében tervezői tevékenység, amely kreatív gondolkodást igényel. A létező CASE-eszközök automatizálják a rutintevékenységeket és hasznosítják a mesterséges intelligencia bizonyos technológiáit, de ez utóbbival még nem értek el átütő eredményt. A legtöbb szervezetben a szoftvertervezés csoportos tevékenység, és a benne résztvevők rengeteg időt töltenek a csapat más tagjaival való eszmecserével. A CASE-technológia ehhez nem nyújt túl nagy segítséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

100 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
CASE eszközök Automatikus dokumentumgenerálás; Projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

101 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Dr. Johanyák Zs. Csaba - Szoftvertechnológia

102 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Unified Modeling Language Egységes modellező nyelv 2.4.1 (2.1.2 ISO/IEC ) Object Management Group Eric J. Naiburg, Robert A. Maksimchuk: UML földi halandóknak. Kiskapu Kiadó, Budapest, 2006. A továbbiakban röviden áttekintjük a diagram típusokat. A részletes ismertetésre a szoftverfejlesztési folyamat főbb lépései szerinti csoportosításban kerül sor a későbbiekben. Néhány diagramtípus több lépésben is felhasználásra, finomításra kerül, ezek általában az első olyan lépésnél lesznek bemutatva, ahol hasznosítjuk őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

103 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Dokumentálható A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Grafikus elemek Nem programozási nyelv Nem módszertan „Csak” segédeszköz Az UML egy eszköztár, amelynek segítségével ember és számítógép által jól érthető/kezelhető/feldolgozható módon dokumentálhatóak a A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Az UML grafikus elemei a szoftver fejlesztés minden fázisában jól alkalmazhatóak. Számos szoftver nyújt támogatást az UML használatához. Létezik pl. osztálydiagramból kódot generáló és kódból osztálydiagramot generáló implementáció. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

104 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Mire jó az UML? 1. szemléltetésre a fejlesztői csoporton belül, illetve a fejlesztők, tesztelők, menedzserek és a megrendelők közötti kommunikációra specifikálásra megvalósításra dokumentálásra Dr. Johanyák Zs. Csaba - Szoftvertechnológia

105 Mire jó az UML? 2. „szoftver mag ültetés és hajtatás”
Evolúciós programfejlesztés „szoftver mag ültetés és hajtatás” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

106 Sikeres szoftverfejlesztési folyamat
Jelölésrendszer (notation) – ez lehet az UML Folyamat (process) – pl. RUP (Rational Unified Process) Eszköz (tool) – pl. Enterprise Architect, Rational Rose, Visual Studio 2010 osztálydiagram készítő része, stb. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

107 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML szabvány részei 1. Infrastructure (4 rétegű metamodell, a nyelv alapvető szerkezetei, a „mag”) Pdf 32. oldal négyrétegű metamodell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

108 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

109 A metamodell architektúra
Meta-metamodell EBNF (Extended Backus-Naur Form) MOF M2 metamodell A C# nyelv nyelvtana UML M1 modell Egy C# program Számkitaláló M0 rendszer Egy konkrét C# program végrehajtása A program futásának egy állapota EBNF egy metanyelv, környezetfüggetlen nyelvtan, programozási nyelvek és más formális nyelvek leírására szolgál Dr. Johanyák Zs. Csaba - Szoftvertechnológia

110 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az UML szabvány részei 2. Superstructure (a felhasználó milyen diagramokat, azon belül milyen elemeket és kapcsolatokat használhat; mi főleg ezt tanuljuk) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

111 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az UML szabvány részei 3. UML Diagram Interchange (UMLDI) – lehetővé teszi a különböző UML szerkesztő szoftverek közötti dokumentumcserét UML Human-Usable Textual Notation – egyes UML diagramokból ember által is olvasható szöveget generál MOF 2 XMI Mapping – MOF = Meta Object Facility XMI = XML Metadata Interchange – XML adatok és objektumok cseréje, manipulálása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

112 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Modell - diagram A kettő nem ugyanaz! „A modellek (tehát) több diagramból állnak, a diagramok pedig az elemek és azok más elemekkel való kölcsönhatásának ábrázolásai.” (Forrás: UML földi halandóknak könyv) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

113 Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class)
Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés d. (timing) Kontextus diagram Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

114 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Kontextus d. , Szakarchitektúra d. Összetett szerkezet diagram (composite stucture) Kihelyezési/telepítési/kihelyezési diagram (deployment) Viselkedési diagramok: Tevékenység diagram (activity) Használati eset vagy feladat diagram (use-case) Állapotautomata vagy állapotgép diagram (state machine) Kölcsönhatási diagramok: Sorrend diagram (sequence) Kommunikációs diagram (communication) Időzítés diagram (timing) Kölcsönhatás áttekintő diagram (interaction overview) Az UML vizuális megjelenítést, ún. diagramokat használ a modell elemek leírására. Ezek két fő csoportba sorolhatók. Forrás: Szabolcsi Judit: Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

115 Szerkezeti és viselkedési
A szerkezeti diagramok (statikus) nem törődnek az időbeli változással, ők a modellezett rendszer állapotát egy adott időpillanatban mutatják be. Viselkedési diagramok (dinamikus) folyamatában, változásában mutatják ugyanazt a modellezett rendszert. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

116 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerkezeti diagramok1 Osztálydiagram: az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Objektumdiagram: a rendszer egy adott időpontban érvényes pillanatképét határozza meg. Az osztálydiagramból származtatjuk. Csomagdiagram: a csomagok olyan modellelemek, amelyek más modellelemek csoportosítására szolgálnak, és ezeket valamint a köztük lévő kapcsolatokat ábrázolja ez a fajta diagram. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

117 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerkezeti diagramok2 Összetevő diagram: az összetevő vagy komponens a rendszer fizikailag létező és lecserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Főleg implementációs kérdések eldöntését segíti. A megvalósításnak és a rendszeren belüli elemek együttműködésének megfelelően mutatja be a rendszert. Összetett szerkezeti diagram: A modellelemek belső szerkezetét mutatja. Kialakítás/kihelyezés/telepítési diagram: A fizikai (kész) rendszer futásidejű felépítését mutatja. Tartalmazza a hardver és a szoftverelemeket is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

118 Viselkedési diagramok
Tevékenységdiagram: A rendszeren belüli tevékenységek folyamatát jeleníti meg. Általában üzleti folyamatok leírására használjuk. Használati eset/feladat diagram: A rendszer viselkedését írja le, úgy, ahogy az egy külső szemlélő szemszögéből látszik. Állapotautomata diagram: Az objektumok állapotát és az állapotok közötti átmeneteket mutatja, valamint azt, hogy az átmenetek milyen esemény hatására következnek be. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

119 Kölcsönhatási diagramok
Kommunikációs diagram: Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. Sorrenddiagram: Az objektumok közötti üzenetváltás időbeli sorrendjét mutatja. Időzítés diagram: A kölcsönhatásban álló elemek részletes időinformációit és állapotváltozásait vagy állapotinformációit írja le. Kölcsönhatás áttekintő diagram: Magas szintű diagram, amely a kölcsönhatás-sorozatok közötti vezérlési folyamatról ad áttekintést. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

120 Elvárások elemzése és specifikáció
Szoftvertechnológia Elvárások elemzése és specifikáció Dr. Johanyák Zs. Csaba - Szoftvertechnológia

121 Elvárások elemzése és specifikáció
A vevői/megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?) A rendszer környezetének felmérése A feladat leírása Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása A feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. Egyszerűsítve a használati eset az üzleti folyamat egy lépése, viszonylag rövid idő alatt lefut. Az üzleti folyamat megszakításokkal akár hónapokig is eltarthat. Egyszerűbb alkalmazásoknál csak használati esetek vannak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

122 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Lépések Szakterületi fogalomtár Interjú – leírás szabad szöveges formában Interjú – leírás strukturáltan rendezve Az üzleti folyamatok táblázatos leírása egyenként Használati eset diagram elkészítése Használati esetek részletes, táblázatos dokumentálása Folyamatok (lépések) modellezése tevékenység diagram segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

123 Szakterületi fogalomtár
A témakörhöz, feladathoz kapcsolódó fontosabb kifejezések, elnevezések felsorolása és magyarázata Nem szükséges minden esetben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

124 Interjú leírása szabad szöveges formában
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

125 Interjú leírása strukturált szövegként
Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

126 Az üzleti folyamatok táblázatos leírása egyenként
Az aktor lehet fizikai személy vagy a rendszerrel kapcsolatba kerülő másik szoftver/hardver. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

127 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

128 Használati eset diagram
Leggyakrabban a követelményelemzés és a specifikáció során alkalmazzák A rendszer viselkedését írja le, ahogyan az egy külső szemlélő szemszögéből látszik Összetevői Használati eset Szereplő Rendszerhatár Használati eset : tevékenységek sorozata, amelyet a rendszer végre tud hajtani a szereplőkkel kommunikálva. Rajzjele az ellipszis, amibe vagy alá odaírjuk a nevét. Szereplő (Actor): személy, csoport, szervezeti egység vagy fizikai eszköz, aki vagy ami kapcsolatba lép a rendszerrel. Rajzjele egy pálcikaemberke. Rendszerhatár (Boundary): a megvalósítandó rendszer és a szereplők közötti határ. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

129 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kapcsolatok Asszociáció Általánosítás Asszociáció: szereplő és használati eset között Általánosítás/specifikálás: szereplők között, használati esetek között Dr. Johanyák Zs. Csaba - Szoftvertechnológia

130 Kapcsolatok - függőségek
<<include>> <<extend>> Use-case-ek között <<include>> és <<extend>> kapcsolat szokott leggyakrabban előfordulni. Az <<include>> kapcsolat azt jelenti, hogy egy résztevékenységet kiemelünk az alap use-case tevékenység sorozatából, és azt külön use-case-ben tüntetjük fel. Ezt a résztevékenységet aztán más use-case-ek is használhatják. Az <<extend>> kapcsolatnál a kiterjesztő megszakíthat egy másik use-case-t a működésében. Include: valamilyen résztevékenységet külön megnevezünk, kiemelünk. Kiemeljük, egyértelműsítjük, hogy a főtevékenység ezt is magába foglalja. Extend: egy speciális funkció, ami kiegészíthet egy alaptevékenységet. A nyíl mindig a kiegészített alaptevékenység felé mutat. Ez olyan értelemben opcionális, hogy az alaptevékenység enélkül is végrehajtható. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

131 Használati eset diagram készítése Enterprise Architectben
Könyvtári rendszer használati eset diagramja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

132 Folyamatok modellezése
Tevékenység diagram Állapotautomata Dr. Johanyák Zs. Csaba - Szoftvertechnológia

133 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tevékenység diagram A probléma megoldásának a lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt Hasznos az üzleti vagy munkafolyamatok modellezésére, használati esetek vagy konkrét algoritmusok lefutásának leírására Az állapotautomata egy változatának is tekinthető, ahol az állapotok helyére a végrehajtandó tevékenységeket tesszük, az állapotátmenetek pedig a tevékenységek befejezésének eredményeként valósulnak meg. Action, Activity Action – Egy rövid időt igénylő/pillanatszerű tevékenység, nevezhetjük egy lépésnek Activity – Hosszabb lefolyású tevékenység, ami több lépésre bontható (több lépéssel – Action-nel – írható le). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

134 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Pénzfelvétel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

135 Másodfokú egyenlet megoldása
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

136 Párhuzamos feladatvégrehajtás
Elágazás (fork) Csatlakozás (join) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

137 Tevékenység diagram aktorok szerinti partícióval
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

138 Kivétel Mi idézheti elő?
Külső esemény (pl. adathordozóval megszakad a kapcsolat) Időpont (pl. inaktív ftp kapcsolat megszakítása) Esetválasztás (pl. hibás paraméterezés következtében a hívott metódus kivételt idéz elő) Célzott előidézés - továbbadás (throw) Forrás: Szabolcsi Judit: Szoftvertechnológia: Eddig jól, szabályosan lefutó tevékenységeket modelleztünk, de előfordulhat, hogy feldolgozási hiba miatt egy tevékenységet meg kell szakítani, hogy a hiba kezelése a tevékenységen kívül végbemehessen. A kivétel tulajdonképpen egy jól definiált, nemlokális vezérlési ág. A kivételkezelésnek két része van: egyrészt a kivételt ki kell váltani, másrészt el kell kapni és kezelni kell. Külső esemény: valamilyen esemény lép fel a feldolgozás alatt lévő tartományba,n és ez kihat a feldolgozás lefutására. Pl.: ez a helyzet az operációs rendszeren belüli folyamatváltáskor. Időpont: Egy időpontot érünk el, és ezért speciális feldolgozás válik esedékessé. Pl.: az internetes jegyfoglalási folyamat bizonyos idő után inaktivitás miatt megszakad. Esetválasztás: Egy kivétel kiváltódhat még célzottan, esetválasztás eredményeképpen is, pl. ha olyan hibát fedezünk fel, amelyet nincs lehetőség helyben (lokálisan) kezelni. Tevékenység (közvetlen): egy kivételt egy normál tevékenység is kiválthat, pl. ha a fenti három ok valamelyike miatt kiváltott kivétel után kivétel objektum előállítása szükséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn

139 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftver életciklus fontosabb lépései/tevékenységei. Ezek szinte minden modellben előfordulnak. Előző órán az első két lépéssel foglalkoztunk. A tervezésből még maradt egy kis rész mára, ami az állapotgép diagramok használatához kapcsolódik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

140 Tevékenység d. (activity) Használati eset d.(use-case)
Ismétlés Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés diagram (timing) Kontextus diagram A kivastagított diagram típusokat előző órán már megismertük. Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

141 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapotgép Az objektumok, a használati eseteknek és a protokollok dinamikus viselkedését mutatja, vagy a dialógusok lefutásának leírására is alkalmas Állapot: az objektum állapotát az attribútumai konkrét értékeinek n-esével jellemezzük. Tervezés és implementálás során Állapotátmenet: két állapot közötti kapcsolat, amely kifejezi, hogy egy adott állapotban lévő objektum egy esemény vagy valamely feltétel bekövetkezésének hatására milyen másik állapotba kerül Tervezés során kezdetben még nem ismerjük az attribútumokat, így az egyes állapotokat csak nevekkel (szöveges leírással különböztetjük meg). Ezt fokozatosan finomítjuk. A végső változat az implementálás fázisban készül el, amikor már ismerjük az osztályokat, objektumokat és azok attribútumait. Esemény: tevékenység, történés, ami valamely objektum állapotát megváltoztatja. Ha az esemény végrehajtása időben elhúzódik, megkülönböztethetjük tőle a pillanatszerű akciót. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

142 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

143 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapot Osztály és a belőle készült objektum egy állapota Dr. Johanyák Zs. Csaba - Szoftvertechnológia

144 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Álapotdiagram Egy kezdő és egy vagy több végállapot. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

145 Diszjunkt alállapotok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

146 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapotátmenetek A kezdő és végállapot nem mindig értelmezhető vagy elfordulhat, hogy nincs jelentősége. Az állapotok közötti átmenetet irányított szakaszokkal jelezzük. Az átmenetet előidéző esemény vagy feltétel rövid leírása a vonal mellé kerül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

147 Egy kezdőállapot, több végállapot
A diagram feltétele elágazásokat is tartalmazhat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

148 Állapotgép könyv – könyvtári rendszer
Komplex rendszereknél előfordulhat, hogy elsőként csak az állapotokat és a köztük lehetséges átmeneteket vázoljuk fel és az átmenetek esetleges lépéseit, az alkalmazott feltételes elágazásokat, stb. csak később építjük be vagy külön tevékenység diagramot készítünk hozzájuk. Pl. állapot diagram a könyvtári rendszerhez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

149 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Összetett állapotok Állapotok aggregációja Diszjunkt szub- vagy alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

150 Állapotok aggregációja
A B és C alrendszerek párhuzamosan működnek Az A állapotát a B és C állapotának az „összege” adja. Ezek egymással párhuzamosan kerülnek különböző állapotokba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

151 Diszjunkt alállapotok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

152 Emlékező vagy történeti állapot
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

153 Állapotátmenetek

154 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Történeti állapot Egyszerű történeti állapot H – csak az állapotkonfiguráció legfelső szintjét őrzi meg Mély történeti állapot H* - teljes mélységében megőrzi az állapotkonfigurációt Dr. Johanyák Zs. Csaba - Szoftvertechnológia

155 Állapotgép - tanulmányi rendszer - tantárgyfelvétel
Nézzünk egy ETR-szerű rendszert példaként, ahol a hallgató jelszóval tud bejelentkezni és felvenni egy tárgyat. A példában egy csoportban maximum 10-en lehetnek: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

156 Állapotgép - párátlanító
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

157 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

158 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

159 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezés Szoftverarchitektúra beazonosítása (K-A-RM) Felhasználói interfészeken lefutó interakciók modellezése Osztályok és felépítésük Objektum életciklusok és objektum interakciók kidolgozása A tervezés során alkalmazható diagramok: kontextus d., architektúra d., rendszer-montázs d., tervezési osztálydiagram Az architektúra beazonosítása magában foglalja az alrendszerek komponensek fokozatos finomítással több lépésben történő megnevezését. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

160 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kontextus diagram Rendszerek, szereplők és a rendszerrel kapcsolatba kerülő más rendszerek beazonosítására szolgál. Példák kapcsolatra egy külső rendszerrel ATM a banki back office rendszerrel Raktáros példában a kezelőszoftver és a robotok szoftvere Könyvtári rendszer kapcsolata regionális vagy országos rendszerrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

161 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Táblázat Ügyfél Feladat Pénzkivétel, mobil egyenleg feltöltés, stb. Mennyiség * Fajta Természetes személy Betanítási idő - A kontextus diagramhoz kapcsolódhat az aktorok feladatait megadó táblázat. ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

162 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Táblázat Alkalmazott (pénzfeltöltő) Feladat Készpénz elhelyezése az automatába Mennyiség Heti két alkalom Fajta Alkalmazott Betanítási idő Fél nap ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

163 Szakarchitektúra diagram
A kontextus diagram alrendszerek jelölésével kibővített változata. Megadja, hogy az egyes aktorok mely alrendszerekkel kerülnek kapcsolatba. Lehet, hogy egy aktor minden alrendszerrel kapcsolatba kerül. Ilyenkor nem kell összekötni minden alrendszerrel. A könyvtári rendszer példában pl. alrendszerek lehetnek a keresés, ügyfélkezelés, kölcsönzés és előjegyzés. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

164 Összetett szerkezeti diagram
Composite structure diagram Megmutatja egy osztály belső szerkezetét és az egységek közötti együttműködési lehetőséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

165 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram Az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Általában a rendszer logikai és fizikai felépítésének ábrázolására szolgál. UML-beli osztály NEM UGYANAZ, mint a programozási nyelvek osztályfogalma! – többféle jelentés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

166 UML-beli osztály jelentései
Fogalom: Ez az elemzési/ tervezési fázisban gyakori, ahol a szakterület fogalmait nevezzük osztálynak Típus: Ez már programozási nyelv közelibb; az objektumok az osztály típus értékei, példányai. Objektumhalmaz: Az osztály itt csak egy csoportosítás, az azonos felépítésű objektumok halmaza Implementáció: Az OOP nyelvekben az osztály egyszerűen csak egy implementáció (kód) is lehet, amin az objektumai osztoznak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

167 Szoftver életciklus fázisai 1.
Elemzési fázisban az osztály mint Fogalom – igen Típus – esetleg Objektumhalmaz – nem Implementáció (kód) - nem Dr. Johanyák Zs. Csaba - Szoftvertechnológia

168 Szoftver életciklus fázisai 2.
Tervezési fázisban az osztály mint Fogalom – esetleg Típus – igen Objektumhalmaz – igen Implementáció (kód) - esetleg Dr. Johanyák Zs. Csaba - Szoftvertechnológia

169 Szoftver életciklus fázisai 3.
Megvalósítási fázisban az osztály mint Fogalom – nem Típus – igen Objektumhalmaz – igen Implementáció (kód) - igen Dr. Johanyák Zs. Csaba - Szoftvertechnológia

170 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

171 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram Egyszeresen összefüggő gráf, amelynek csomópontjai osztályokat, élei pedig relációkat fejeznek ki. Az osztály jele egy általában három részre osztott téglalap, ahol a felső sávba az osztály nevét, a középsőbe az osztály attribútumait, az alsóba pedig az osztály műveleteit írjuk. A statikus adattagokat vagy műveleteket aláhúzással jelöljük, az absztrakt osztály neve pedig dőlt betűs. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

172 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

173 Az osztályok közötti kapcsolatok
Asszociáció/társítás (association) Aggregáció/rész-egész kapcsolat (aggregation) Általánosítás (generalization) Függőség (dependency) Megvalósítás (realization) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

174 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Asszociáció Reflexív asszociáció – Többes asszociáció Valamilyen használati kapcsolat a két osztály között, amelyek egymástól függetlenek, de legalább az egyik ismeri/használja a másikat. (Egy kutyának pontosan egy gazdája van, és minden gazdának legalább egy, legfeljebb akárhány kutyája van. Attól lesz gazda, hogy van legalább egy kutyája.) A vonalra a multiplicitást írjuk. Reflexív asszociáció: amikor egy osztály saját magával van kapcsolatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

175 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Aggregáció Kompozíció (erős tartalmazás) Gyenge tartalmazás Aggregáció: Erősebb kapcsolat, mint az asszociáció. Egész-rész kapcsolat. Két fajtája van: gyenge és erős. A gyenge tartalmazásnál, ha elvágjuk a kapcsolatot, a részek akkor is „életképesek” maradnak, az erős tartalmazásnál (kompozíció) viszont külön-külön működésképtelenek. Kompozíció Az egyik osztály objektumai a másik osztály objektumait fizikailag tartalmazzák. Egy komponens objektum legfeljebb egy aggregációs objektumhoz tartozhat. Az aggregációs objektum és annak komponensei azonos életciklusban léteznek, azaz egyszerre jönnek létre és egyszerre szűnnek meg. Az erőskapcsolat és az attribútum kapcsolat ugyanazt jelenti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

176 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Példák Dr. Johanyák Zs. Csaba - Szoftvertechnológia

177 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
További kapcsolatok Általánosítás Függőség Megvalósítás Általánosítás: a reláció azt fejezi ki, hogy a speciális osztály az általánosból származtatással (örökléssel) jön létre. Függőség: Két elem közötti kapcsolat, ahol az egyik változása befolyásolja a másikat. A vállalkozás fejlődésével/csődbe jutásával párhuzamosan változtathatja a törzstőkéje összegét. Megvalósítás: A fogalom és annak megvalósítója közötti kapcsolat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia


Letölteni ppt "Szoftvertechnológia 2015/2016 – 1. félév."

Hasonló előadás


Google Hirdetések